ГОСТ Р 57193-2016. Национальный стандарт Российской Федерации. Системная и программная инженерия. Процессы жизненного цикла систем

(утв. и введен в действие Приказом Росстандарта от 31.10.2016 № 1538-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р ИСО/МЭК 15288-2005"]:::rst
  click n0 "https://bukva.ai/docs/standart-gost-r-isomek-15288-2005" "ГОСТ Р ИСО/МЭК 15288-2005. Национальный стандарт Российской Федерации. Информационная технология. Системная инженерия. Процессы жизненного цикла систем (утв. и введен в действие Пр"
  n1["ГОСТ Р 57193-2016"]:::rst
  click n1 "https://bukva.ai/docs/prikaz-gost-r-57193-2016" "ГОСТ Р 57193-2016. Национальный стандарт Российской Федерации. Системная и программная инженерия. Процессы жизненного цикла систем (утв. и введен в действие Приказом Росстандарта о"
  n2["ГОСТ Р 57193-2025"]:::doc
  click n2 "https://bukva.ai/docs/standart-gost-r-57193-2025" "ГОСТ Р 57193-2025. Национальный стандарт Российской Федерации. Системная и программная инженерия. Процессы жизненного цикла систем (утв. и введен в действие Приказом Росстандарта о"
  n1 --> n2
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

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

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА СИСТЕМ

Systems and software engineering. System life cycle processes

(ISO/IEC/IEEE 15288:2015, NEQ)

ГОСТ Р 57193-2016

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ISO/IEC/IEEE 15288:2015 «Системная и программная инженерия. Процессы жизненного цикла систем» (ISO/IEC/IEEE 15288:2015 «Systems and software engineering — System life cycle processes», NEQ).

5 ВЗАМЕН ГОСТ Р ИСО/МЭК 15288-2005

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

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

1. Обзор

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

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

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

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

Если системный элемент является программным средством, то для реализации системных элементов могут быть использованы процессы жизненного цикла программных средств согласно [43]. Эти два стандарта согласованы для параллельного использования в отдельном проекте или отдельной организации.

1.2. Назначение

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

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

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

1.3. Область распространения

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

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

Настоящий стандарт содержит модель эталонного процесса, характеризуемого в терминах целей и результатов, являющихся итогом успешных действий. Таким образом, настоящий стандарт может применяться как эталонная модель для поддержки процесса оценки согласно ГОСТ Р ИСО/МЭК 15504-2-2009. В приложении C содержится информация относительно использования процессов жизненного цикла системы как эталонной модели процесса. В приложении D описаны конструкции процесса для использования в эталонной модели процесса.

1.4. Ограничения

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

Несмотря на то, что настоящий стандарт не устанавливает какую-либо систему управления, он предназначен для того, чтобы быть совместимым с системой менеджмента качества, приведенной в ГОСТ ISO 9001-2011, с системой управления услугами, определенной в ГОСТ Р ИСО/МЭК 20000-1-2013, и системой управления информационной безопасностью, приведенной в ГОСТ Р ИСО/МЭК 27000-2012.

Настоящий стандарт не детализирует информационные объекты в терминах их названий, формата, явного содержания и записывающих средств массовой информации (СМИ). Содержание информационных объектов (документации) в процессах жизненного цикла отражено в [41].

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

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

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

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

Примечания

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

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

2.2. Полное соответствие

2.2.1 Полное соответствие результатам

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

Примечание — Это возможное использование настоящего стандарта обеспечивает оценку и усовершенствование процесса. Для этих целей задачи каждого процесса описаны в форме «результатов», совместимых с условиями ГОСТ Р ИСО/МЭК 15504-2-2009 и [42]. Эти стандарты предусматривают оценку по настоящему стандарту и обеспечение основ для совершенствования процессов. Пользователи, осуществляющие оценку и совершенствование процесса, могут использовать результаты процесса, изложенные в настоящем стандарте, как «эталонную модель процесса», описанную в ГОСТ Р ИСО/МЭК 15504-2-2009 и [42].

2.2.2 Полное соответствие задачам

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

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

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

Примечания

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

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

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

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

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

Для настоящего стандарта нормативные ссылки отсутствуют.

4. Термины и определения, сокращения

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

В настоящем стандарте применены следующие термины с соответствующими определениями:

4.1.1 приобретающая сторона (acquirer): Заинтересованная сторона, которая приобретает или получает продукт или услугу от поставщика.

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

4.1.2 приобретение (acquisition): Процесс получения системы, продукта или услуги.

4.1.3 деятельность, действие (activity): Множество связанных задач процесса.

4.1.4 соглашение (agreement): Взаимное признание сроков и условий, в соответствии с которыми осуществляются рабочие отношения.

Пример - Контракт, меморандум о соглашении.

4.1.5

4.1.6

4.1.7

4.1.8

4.1.9

4.1.10

4.1.11

4.1.12

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

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

[ГОСТ Р ИСО/МЭК 12207-2010]

4.1.14 проектировать (design, verb): Процесс определения системных элементов, взаимодействий и других характеристик рассматриваемой системы в соответствии с требованиями и архитектурой.

4.1.14.1 проектирование (design, noun): Результат процесса проектирования по определению 4.1.14.

Примечания

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

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

4.1.15

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

Примечания

1 Например, когда рассматриваемая система вступает в стадию производства, требуется обеспечивающая производственная система.

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

4.1.17 основные средства (facility): Физические средства или оборудование, способствующие выполнению действий, например здания, инструменты, принадлежности.

4.1.18 инцидент (incident): Отклонение или неожиданное событие, множество событий, условия или ситуация в любое время во время жизненного цикла проекта, продукции, услуги или системы.

4.1.19 жизненный цикл (life cycle): Развитие системы, продукции, услуги, проекта или другой создаваемой человеком сущности от замысла до списания.

4.1.20 модель жизненного цикла (life cycle model): Структурная основа процессов и действий, относящихся к жизненному циклу, которая также служит в качестве общего эталона для установления связей и понимания.

4.1.21 оператор (operator): Лицо или организация, которые выполняют операции системы (обеспечивают функционирование системы).

Примечания

1 Роль оператора и роль пользователя могут выполняться одновременно или последовательно одним и тем же человеком или организацией.

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

4.1.22

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

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

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

4.1.26

процесс (process): Совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующая входы в выходы.

[ГОСТ ISO 9000-2011]

4.1.27 цель процесса (process purpose): Устремления высокого уровня в выполнении процесса и вероятные выходы эффективной реализации процесса.

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

4.1.28 выход, выходной результат процесса (process outcome): Наблюдаемый результат успешного достижения цели процесса.

4.1.29 продукт, продукция (product): Результат процесса.

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

4.1.31 портфель проектов (project portfolio): Совокупность проектов, направленных на достижение стратегических целей организации.

4.1.32

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

[ГОСТ Р ИСО/МЭК 12207-2010]

4.1.33 гарантия качества (quality assurance): Часть менеджмента качества, сосредоточенная на предоставлении уверенности в том, что требования к качеству будут выполнены.

4.1.34

менеджмент качества (quality management): Скоординированная деятельность по руководству и управлению организацией применительно к качеству.

[ГОСТ ISO 9000-2011]

4.1.35 ресурс (resource): Актив, который используется или потребляется в ходе выполнения процесса.

Примечания

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

2 Ресурсы могут быть многократно используемыми, возобновляемыми или расходуемыми.

4.1.36

4.1.37

4.1.38

4.1.39

4.1.40 услуга (service): Выполнение действий, работы или обязанностей.

Примечание - Услуга самодостаточна, последовательна, дискретна и может быть составлена из других услуг.

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

Примечания

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

2 Стадии могут быть взаимно перекрывающимися.

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

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

Примечание - Некоторые заинтересованные стороны могут иметь противоположные интересы в системе.

4.1.43 поставщик (supplier): Организация или лицо, которые вступают в соглашение с приобретающей стороной на поставку продукта или услуги.

Примечания

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

2 Иногда приобретающая сторона и поставщик являются частью одной и той же организации.

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

Примечания

1 Система может рассматриваться как какой-то продукт или как предоставляемые услуги, обеспечивающие этот продукт.

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

4.1.45 системный элемент (system element): Представитель совокупности элементов, образующих систему.

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

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

4.1.46 рассматриваемая система (system-of-interest): Система, жизненный цикл которой рассматривается в рамках настоящего стандарта.

4.1.47

4.1.48 задача (task): Требование, рекомендация или разрешенное действие, предназначенные для содействия достижению одного или более выходов процесса.

4.1.49 компромисс (trade-off): Действия по принятию решений, в ходе которых на основе конечной выгоды правообладателей производится выбор из различных требований и альтернативных решений.

4.1.50 пользователь (user): Лицо или группа лиц, извлекающих пользу из системы в процессе ее применения.

Примечание - Роль пользователя и роль оператора может выполняться одновременно или последовательно одним и тем же человеком или организацией.

4.1.51 валидация, аттестация (validation): Подтверждение (на основе представления объективных подтверждений) того, что требования, предназначенные для конкретного использования или применения, выполнены.

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

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

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

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

4.2. Сокращения

CM — управление конфигурацией;

CCB — Совет по управлению конфигурацией;

COTS — коммерческий продукт;

NDI — неразрабатываемые объекты;

QA — гарантия качества;

SDP — план разработки программных средств;

PC — рассматриваемая система;

CC — система систем.

5. Основные понятия и приложения настоящего стандарта

5.1. Введение

Настоящий раздел включен для объяснения существенных понятий, на которых базируется настоящий стандарт. Дальнейшая проработка этих понятий может быть найдена в [19], ГОСТ Р 57102-2016/ISO/IEC TR 24748-2:2011 или ГОСТ Р 56923-2016/ISO/IEC TR 24748-3:2011, являющихся руководствами по применению управления жизненным циклом.

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

5.2.1 Системы

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

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

Следующие положения являются основными относительно характеристик рассматриваемой системы:

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

b) существуют иерархические или иные отношения между системными элементами;

c) какая-либо сущность на любом уровне в рассматриваемой системе может быть рассмотрена как система;

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

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

f) люди могут рассматриваться как пользователи, внешние к системе, и как системные элементы (т.е. операторы) в пределах системы;

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

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

5.2.2 Структура системы

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

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

5.2.3 Обеспечивающие системы

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

Отношения между услугами, поставляемыми в эксплуатационной среде рассматриваемой системы, и услугами, поставляемыми обеспечивающими системами рассматриваемой системы, показаны на рисунке 3. Предоставление возможностей со стороны обеспечивающей системы косвенно способствует услугам, оказываемым рассматриваемой системой. Взаимосвязи между рассматриваемой системой и обеспечивающими системами могут быть двунаправленными или односторонними. В дополнение к взаимодействию с обеспечивающими системами рассматриваемая система может также взаимодействовать с другими системами в эксплуатационной среде, показанными как системы A, B и C. Требования для взаимодействий с обеспечивающими системами и другими системами в эксплуатационной среде должны быть включены в требования для рассматриваемой системы.

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

Дальнейшая проработка этих понятий может быть найдена в руководствах, посвященных применению управления жизненным циклом [45].

5.3. Понятия организации и проекта

5.3.1 Организации

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

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

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

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

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

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

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

5.3.2 Принятие на уровне организации и проекта

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

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

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

5.4.1 Модель жизненного цикла системы

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

5.4.2 Стадии жизненного цикла системы

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

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

В [19] типичные стадии жизненного цикла системы включают замысел, разработку, производство, применение, поддержку и выведение из эксплуатации.

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

Дальнейшая проработка этих понятий может быть найдена в руководствах, посвященных применению управления жизненным циклом [45].

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

5.5.1 Критерии для процесса

Определение процессов жизненного цикла в настоящем стандарте основано на трех принципах:

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

5.5.2 Описание процессов

Каждый процесс настоящего стандарта описывается в терминах следующих атрибутов:

• атрибут «Название» передает область процесса в целом;
• атрибут «Цели» описывает цели выполнения процесса;
• атрибут «Выход (выходные результаты)» выражает заметные результаты, ожидаемые от успешной работы процесса;
• атрибут «Действия» — это множества связанных задач процесса;
• атрибут «Задачи» — это требования, рекомендации или допустимые действия, используемые для поддержки достижения конкретных результатов.

Дополнительные детали относительно формы описания процесса — в ГОСТ Р 57098-2016/ISO/IEC TR 24774:2010.

5.5.3 Общие характеристики процессов

В дополнение к основным признакам, описанным в предыдущем пункте, процессы могут быть охарактеризованы другими атрибутами, общими для всех процессов. ГОСТ Р ИСО/МЭК 15504-2-2009 определяет общие атрибуты процесса, которые характеризуют шесть уровней достижения в пределах структуры измерений для обеспечения возможностей процесса. Приложение C включает термины атрибутов процесса, которые способствуют достижению высоких уровней возможности процесса, как это определено в ГОСТ Р ИСО/МЭК 15504-2-2009.

5.5.4 Приспосабливание

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

5.6. Процессы

5.6.1 Введение

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

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

5.6.2 Процессы соглашения

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

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

5.6.3 Процессы организационного обеспечения проекта

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

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

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

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

5.6.4 Процессы технического управления

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

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

Примечание — Техническое управление является применением технических и административных ресурсов для планирования, организации и управления техническими функциями (см. [23]).

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

┌─────────────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│                    Процессы жизненного цикла системы                    │
│┌────────────────────┐  ┌────────────────────┐  ┌───────────────────────┐│
││      Процессы      │  │      Процессы      │  │       Технические     ││
││     соглашения     │  │    технического    │  │        процессы       ││
││                    │  │     управления     │  │                       ││
││┌──────────────────┐│  │┌──────────────────┐│  │┌─────────────────────┐││
│││     Процесс      ││  ││     Процесс      ││  ││   Процесс анализа   │││
│││   приобретения   ││  ││   планирования   ││  ││     бизнеса или     │││
│││     (6.1.1)      ││  ││ проекта (6.3.1)  ││  ││  назначения (6.4.1) │││
││└──────────────────┘│  │└──────────────────┘│  │└─────────────────────┘││
││┌──────────────────┐│  │┌──────────────────┐│  │┌─────────────────────┐││
│││ Процесс поставки ││  ││  Процесс оценки  ││  ││ Процесс определения │││
│││     (6.1.2)      ││  ││и контроля проекта││  ││     потребностей    │││
││└──────────────────┘│  ││     (6.3.2)      ││  ││     и требований    │││
│└────────────────────┘  │└──────────────────┘│  ││   заинтересованной  │││
│                        │┌──────────────────┐│  ││   стороны (6.4.2)   │││
│┌────────────────────┐  ││Процесс управления││  │└─────────────────────┘││
││      Процессы      │  ││решениями (6.3.3) ││  │┌─────────────────────┐││
││  организационного  │  │└──────────────────┘│  ││ Процесс определения │││
││ обеспечения проекта│  │┌──────────────────┐│  ││      системных      │││
││                    │  ││Процесс управления││  ││  требований (6.4.3) │││
││┌──────────────────┐│  ││ рисками (6.3.4)  ││  │└─────────────────────┘││
│││Процесс управления││  │└──────────────────┘│  │┌─────────────────────┐││
│││моделью жизненного││  │┌──────────────────┐│  ││ Процесс определения │││
│││  цикла (6.2.1)   ││  ││Процесс управления││  ││ архитектуры (6.4.4) │││
││└──────────────────┘│  ││  конфигурацией   ││  │└─────────────────────┘││
││┌──────────────────┐│  ││     (6.3.5)      ││  │┌─────────────────────┐││
│││Процесс управления││  │└──────────────────┘│  ││ Процесс определения │││
│││ инфраструктурой  ││  │┌──────────────────┐│  ││   проекта (6.4.5)   │││
│││     (6.2.2)      ││  ││Процесс управления││  │└─────────────────────┘││
││└──────────────────┘│  ││   информацией    ││  │┌─────────────────────┐││
││┌──────────────────┐│  ││     (6.3.6)      ││  ││  Процесс системного │││
│││Процесс управления││  │└──────────────────┘│  ││   анализа (6.4.6)   │││
│││портфелем (6.2.3) ││  │┌──────────────────┐│  │└─────────────────────┘││
││└──────────────────┘│  ││     Процесс      ││  │┌─────────────────────┐││
││┌──────────────────┐│  ││ измерений (6.3.7)││  ││  Процесс реализации │││
│││Процесс управления││  │└──────────────────┘│  ││       (6.4.7)       │││
│││  человеческими   ││  │┌──────────────────┐│  │└─────────────────────┘││
│││ресурсами (6.2.4) ││  ││ Процесс гарантии ││  │┌─────────────────────┐││
││└──────────────────┘│  ││ качества (6.3.8) ││  ││       Процесс       │││
││┌──────────────────┐│  │└──────────────────┘│  ││   комплексирования  │││
│││Процесс управления││  │                    │  ││       (6.4.8)       │││
│││качеством (6.2.5) ││  │                    │  │└─────────────────────┘││
││└──────────────────┘│  │                    │  │┌─────────────────────┐││
││┌──────────────────┐│  │                    │  ││ Процесс верификации │││
│││Процесс управления││  │                    │  ││       (6.4.9)       │││
│││ знаниями (6.2.6) ││  │                    │  │└─────────────────────┘││
││└──────────────────┘│  │                    │  │┌─────────────────────┐││
││                    │  │                    │  ││   Процесс передачи  │││
││                    │  │                    │  ││       (6.4.10)      │││
││                    │  │                    │  │└─────────────────────┘││
││                    │  │                    │  │┌─────────────────────┐││
││                    │  │                    │  ││  Процесс валидации  │││
││                    │  │                    │  ││       (6.4.11)      │││
││                    │  │                    │  │└─────────────────────┘││
││                    │  │                    │  │┌─────────────────────┐││
││                    │  │                    │  ││       Процесс       │││
││                    │  │                    │  ││   функционирования  │││
││                    │  │                    │  ││       (6.4.12)      │││
││                    │  │                    │  │└─────────────────────┘││
││                    │  │                    │  │┌─────────────────────┐││
││                    │  │                    │  ││Процесс сопровождения│││
││                    │  │                    │  ││      (6.4.13)       │││
││                    │  │                    │  │└─────────────────────┘││
││                    │  │                    │  │┌─────────────────────┐││
││                    │  │                    │  ││   Процесс изъятия   │││
││                    │  │                    │  ││ и списания (6.4.14) │││
││                    │  │                    │  │└─────────────────────┘││
│└────────────────────┘  └────────────────────┘  └───────────────────────┘│</pre>
└─────────────────────────────────────────────────────────────────────────┘

5.6.5 Технические процессы

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

5.7. Применение процесса

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

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

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

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

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

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

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

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

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

Дальнейшая проработка этих понятий может быть найдена в руководствах, посвященных применению управления жизненным циклом [45].

5.8. Эталонная модель процесса

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

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

Примечание — В настоящем стандарте термин «эталонная модель процесса» использован с тем же значением, что и в ГОСТ Р ИСО/МЭК 15504-2-2009.

6. Процессы жизненного цикла системы

6.1. Процессы соглашения

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

Процессы соглашения включают в себя:

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

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

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

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

6.1.1 Процесс приобретения

6.1.1.1 Цель

Цель процесса приобретения — получить продукт или услугу в соответствии с требованиями приобретающей стороны.

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

В результате успешного осуществления процесса приобретения:

a) подготавливается запрос о поставке;

b) выбирается один или более поставщиков;

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

d) принимаются продукт или услуга, соответствующие соглашению;

e) удовлетворяются обязательства приобретающей стороны, определенные в соглашении.

6.1.1.3 Действия и задачи

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

Примечание - Действия и итоговое соглашение от реализации этого процесса часто относятся и к поставщикам в системе поставок, включая поставщиков по субконтрактам,

a) готовьтесь к приобретению.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию того, как будет осуществляться приобретение.

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

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

Примечания

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

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

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

b) рекламируйте приобретение и выбирайте поставщика.

Эта деятельность состоит из следующих задач:

1. сообщайте запрос о поставке продукта или услуги определенным поставщикам,

2. выбирайте одного или более поставщиков.

Примечание - Чтобы получить конкурентоспособные варианты, предложения к поставке должны быть оценены и сравнены по критериям выбора и ранжирования. Объявляется обоснование оценки каждого предложения, и поставщикам сообщается, почему они были или не были выбраны;

c) заключайте и сопровождайте соглашение.

Эта деятельность состоит из следующих задач:

1. разрабатывайте соглашение с поставщиком, включающее критерии приемки.

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

2. определяйте необходимые изменения к соглашению,

3. оценивайте воздействие изменений на соглашение,

4. по мере необходимости договаривайтесь и обновляйте соглашение с поставщиком.

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

d) контролируйте соглашение.

Эта деятельность состоит из следующих задач:

1. оценивайте выполнение соглашения.

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

2. обеспечивайте данные, необходимые поставщикам, своевременно разрешайте проблемы;

e) принимайте продукт или услугу.

Эта деятельность состоит из следующих задач:

1. подтверждайте, что поставленные продукт или услуга удовлетворяют соглашению.

Примечание - Исключения, которые возникают во время реализации соглашения с поставленным продуктом или с услугой, разрешаются согласно процедурам, установленным в соглашении,

2. обеспечивайте оплату или другое согласованное действие,

3. принимайте продукт или услугу от поставщика, или другой стороны в соответствии с соглашением,

4. закрывайте соглашение.

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

6.1.2 Процесс поставки

6.1.2.1 Цель

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

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

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

a) производится ответ на запрос приобретающей стороны;

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

c) поставляются продукт или услуга;

d) удовлетворяются обязательства поставщика, определенные в соглашении;

e) ответственность за приобретенный продукт или услугу передается в соответствии с соглашением.

6.1.2.3 Действия и задачи

Относительно процесса поставки поставщик должен реализовать следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к поставке.

Эта деятельность состоит из следующих задач:

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

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

2. определяйте стратегию поставки;

b) отвечайте на запрос (тендер).

Эта деятельность состоит из следующих задач:

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

2. готовьте ответ, который удовлетворяет запросу;

c) заключайте и поддерживайте соглашение.

Эта деятельность состоит из следующих задач:

1. договаривайтесь с приобретающей стороной о соглашении, которое включает критерии приемки.

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

2. определяйте необходимые изменения к соглашению,

3. оценивайте воздействие изменений соглашения,

4. по мере необходимости договаривайтесь и обновляйте соглашение с приобретающей стороной.

Примечание - Об изменениях к любым разделам соглашения договариваются поставщик и приобретающая сторона. Также рассматриваются изменения из-за изменяющегося контекста рынка;

d) выполняйте соглашение.

Эта деятельность состоит из следующих задач:

1. выполняйте соглашение согласно установленным проектным планам поставщика и в соответствии с соглашением.

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

2. оценивайте выполнение соглашения.

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

e) поставляйте и сопровождайте продукт или услугу.

Эта деятельность состоит из следующих задач:

1. поставляйте продукт или услугу в соответствии с критериями соглашения,

2. обеспечивайте помощь приобретающей стороне в сопровождении поставленной системы или услуги согласно соглашению,

3. принимайте оплату или другое согласованное действие,

4. передавайте продукт или услугу приобретающей стороне или другой стороне в соответствии с соглашением,

5. закрывайте соглашение.

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

6.2. Процессы организационного обеспечения проекта

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

Процессы организационного обеспечения проекта включают в себя:

a) процесс управления моделью жизненного цикла;

b) процесс управления инфраструктурой;

c) процесс управления портфелем;

d) процесс управления человеческими ресурсами;

e) процесс управления качеством;

f) процесс управления знаниями.

6.2.1 Процесс управления моделью жизненного цикла

6.2.1.1 Цель

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

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

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

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

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

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

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

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

6.2.1.3 Действия и задачи

Относительно процесса управления моделью жизненного цикла организация должна реализовать следующие действия и задачи в соответствии с применяемой ею политикой и процедурами:

a) устанавливайте процесс.

Эта деятельность состоит из следующих задач.

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

1. устанавливайте политику и процедуры для управления процессом и его развертывания согласно организационным стратегиям,

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

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

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

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

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

Примечание — Модель жизненного цикла включает одну или несколько моделей стадии, если это необходимо. Модель жизненного цикла формируется как последовательность стадий, которые могут соответствующим образом накладываться и/или повторяться для области рассматриваемой системы, ее масштабов, сложности, изменяемых потребностей и возможностей. Стадии отражены в руководстве [19], использующем распространенный пример стадий жизненного цикла. Определенные показатели для систем приведены в ГОСТ Р 57102-2016. Чтобы достичь цели и получить результаты на стадии, выбираются, приспосабливаются и используются соответствующие процессы жизненного цикла и действия;

b) оценивайте процесс.

Эта деятельность состоит из следующих задач.

Примечание - ГОСТ Р ИСО/МЭК 15504 содержит более детальное множество действий оценки процесса и задач, которые совместимы с задачами, приведенными ниже,

1. контролируйте выполнение процесса в организации.

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

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

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

3. определяйте возможности улучшения по результатам оценки;

c) совершенствуйте процесс.

Эта деятельность состоит из следующих задач:

1. располагайте по приоритетам и планируйте возможности улучшения,

2. реализовывайте возможности улучшения и сообщайте соответствующим заинтересованным сторонам.

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

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

6.2.2.1 Цель

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

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

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

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

a) определяются требования для инфраструктуры;

b) определяются и специфицируются элементы инфраструктуры;

c) разрабатываются или приобретаются элементы инфраструктуры;

d) реализуются элементы инфраструктуры;

e) управляется, поддерживается и совершенствуется инфраструктура.

6.2.2.3 Действия и задачи

Относительно процесса управления инфраструктурой организация должна реализовать следующие действия и задачи в соответствии с применяемой ею политикой и процедурами:

a) устанавливайте инфраструктуру.

Эта деятельность состоит из следующих задач:

1. определяйте проектные требования инфраструктуры.

Примечания

1 Примеры элементов инфраструктуры включают услуги, инструментарии, аппаратные средства, программные средства, услуги и стандарты.

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

3 [30] дает представление о том, как гарантировать безопасность инфраструктуры вне организации,

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

Примечание - Чтобы отследить элементы инфраструктуры, часто устанавливается регистрация активов;

b) сопровождайте инфраструктуру.

Эта деятельность состоит из следующих задач:

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

2. определяйте и обеспечивайте улучшения или изменения по ресурсам инфраструктуры как изменения требований проекта.

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

6.2.3.1 Цель

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

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

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

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

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

b) определяются проекты;

c) распределяются ресурсы и бюджеты для каждого проекта;

d) определяются обязанности руководства проектом, ответственность и полномочия;

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

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

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

6.2.3.3 Действия и задачи

Относительно процесса управления портфелем организация должна реализовать следующие действия и задачи в соответствии с применяемой ею политикой и процедурами:

a) определяйте и санкционируйте проекты.

Эта деятельность состоит из следующих задач:

1. определяйте потенциальные новые или измененные возможности или предназначения.

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

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

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

3. определяйте проекты, подотчетности и полномочия,

4. определяйте ожидаемые цели, задачи и результаты каждого проекта,

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

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

Примечание

1 Это включает применение обеспечивающих систем, используемых более чем одним проектом, и общих системных элементов, используемых более чем одним проектом.

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

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

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

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

b) оценивайте портфель проектов.

Эта деятельность состоит из следующих задач:

1. оценивайте проекты для подтверждения продолжающейся жизнеспособности.

Примечание - Жизнеспособность включает:

i) успехи проекта для достижения установленных целей и выполнения задач,

ii) выполнение проектных директив,

iii) осуществление проекта согласно политике жизненного цикла системы, процессам и процедурам,

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

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

c) завершайте проекты.

Эта деятельность состоит из следующих задач:

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

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

Примечание - Закрытие достигается в соответствии с организационной политикой и процедурами и соглашением.

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

6.2.4.1 Цель

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

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

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

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

a) определяются навыки, востребованные проектами;

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

c) развиваются, поддерживаются или расширяются навыки персонала;

d) разрешаются противоречия в многопроектных требованиях ресурсов.

6.2.4.3 Действия и задачи

Относительно процесса управления человеческими ресурсами организация должна реализовать следующие действия и задачи в соответствии с применяемой ею политикой и процедурами:

a) определяйте навыки.

Эта деятельность состоит из следующих задач:

1. определяйте потребности в навыках, основанные на текущих и ожидаемых проектах,

2. определяйте и регистрируйте навыки персонала;

b) развивайте навыки.

Эта деятельность состоит из следующих задач:

1. устанавливайте стратегию развития навыков.

Примечание - Стратегия включает типы и уровни обучения, категории персонала, графики выполнения работ, требования к ресурсам и потребности для обучения,

2. получайте или разрабатывайте ресурсы для обучения, образования или наставничества.

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

3. обеспечивайте запланированное развитие навыков,

4. сопровождайте записи о развитии навыков;

c) приобретайте и обеспечивайте навыки.

Эта деятельность состоит из следующих задач.

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

1. после того, как определен недостаток навыков, получайте квалифицированный персонал согласно планам.

Примечание - Это включает использование производственных ресурсов вне организации (путем аутсорсинга),

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

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

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

5. для разрешения конфликтных ситуаций с персоналом контролируйте взаимодействия при многопроектном управлении.

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

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

6.2.5.1 Цель

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

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

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

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

b) устанавливаются критерии и методы оценки качества;

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

d) собираются и анализируются результаты оценки гарантии качества;

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

Примечание — Эти результаты были написаны для соответствия ГОСТ ISO 9001-2011 (см. 4.1 «Общие требования»). Для информации по установлению полноценной системы управления качеством следует обращаться к ГОСТ ISO 9001-2011.

6.2.5.3 Действия и задачи

Относительно процесса управления качеством организация должна реализовать следующие действия и задачи в соответствии с применяемой ею политикой и процедурами:

a) планируйте управление качеством.

Эта деятельность состоит из следующих задач:

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

Примечания

1 ГОСТ ISO 9001-2011 является моделью процесса для систем управления качеством. ГОСТ Р ИСО 9004-2010 содержит руководящие принципы для улучшения деятельности.

2 Политика и процедуры основаны на бизнес-стратегии для удовлетворения заказчика,

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

3. определяйте критерии и методы оценки качества,

4. обеспечивайте ресурсами и информацией для управления качеством;

b) оценивайте управление качеством.

Эта деятельность состоит из следующих задач:

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

2. оценивайте удовлетворенность заказчика,

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

4. контролируйте статус улучшений качества для процессов, продуктов и услуг;

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

Эта деятельность состоит из следующих задач:

1. планируйте корректирующие действия, когда цели управления качеством не достигнуты,

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

3. осуществляйте корректирующие действия и сообщайте о них соответствующим заинтересованным сторонам.

6.2.6 Процесс управления знаниями

6.2.6.1 Цель

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

Процесс охватывает знания, навыки и активы знаний, в т.ч. относящиеся к системным элементам.

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

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

a) определяется стратегия управления знаниям организации;

b) определяется таксономия для применения активов знаний;

c) разрабатываются или приобретаются организационные знания, навыки и активы знаний;

d) становятся доступными знания, навыки и активы знаний организации;

e) собираются и анализируются данные использования процесса управления знаниями.

6.2.6.3 Действия и задачи

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

a) планируйте управление знаниями.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию управления знаниями.

Примечания

1 Это в общем случае включает:

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

ii) характеристику типов знаний, навыков и активов знаний, которые будут собираться и поддерживаться;

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

iv) процедуры для того, чтобы управлять изменениями к знаниям, навыкам и активам знаний;

v) планы, механизмы и процедуры для защиты, контроля и доступа к классифицированным и важным данным и информации;

vi) механизмы для хранения и поиска.

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

2. определяйте знания, навыки и активы знаний, которые подлежат управлению,

3. определяйте проекты, для которых может быть извлечена выгода из применения знаний, навыков и активов знаний;

b) распределяйте знания и навыки по организации.

Эта деятельность состоит из следующих задач:

1. устанавливайте и поддерживайте классификацию для получения и разделения знаний и навыков по организации.

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

2. получайте или приобретайте знания и навыки,

3. распределяйте знания и навыки по организации;

c) распределяйте активы знаний по организации.

Эта деятельность состоит из следующих задач:

1. устанавливайте таксономию, чтобы организовать активы знаний.

Примечания

1 Таксономия включает следующее:

i) определение границ областей и их отношений,

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

iii) архитектуру для семейства систем в пределах области, включая их общие и различающие свойства.

2 Для получения дополнительной информации о моделях линии продуктов обращайтесь к [46]. Относительно требований по структурам архитектуры, точек зрения, видов моделей, представлений и непосредственно моделей обращайтесь к ГОСТ Р 57100-2016,

2. разрабатывайте или приобретайте активы знаний.

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

3. распределяйте активы знаний по организации;

d) управляйте знаниям, навыками и активами знаний.

Эта деятельность состоит из следующих задач:

1. сопровождайте знания, навыки и активы знаний,

2. контролируйте и регистрируйте использование знаний, навыков и активов знаний,

3. периодически проводите переоценку технологической и рыночной стоимости активов знаний.

6.3. Процессы технического управления

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

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

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

Процессы технического управления включают в себя:

a) процесс планирования проекта;

b) процесс оценки и контроля проекта;

c) процесс управления решениями;

d) процесс управления рисками;

e) процесс управления конфигурацией;

f) процесс управления информацией;

g) процесс измерений;

h) процесс гарантии качества.

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

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

6.3.1.1 Цель

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

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

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

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

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

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

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

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

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

6.3.1.3 Действия и задачи

Относительно процесса планирования выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) определяйте проект.

Эта деятельность состоит из следующих задач:

1. определяйте проектные цели и ограничения.

Примечания

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

2 ГОСТ Р ИСО/МЭК 15026 и [30] обеспечивают дополнительное руководство по целям и ограничениям, связанным с гарантиями и безопасностью,

2. определяйте область проекта, как это установлено в соглашении.

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

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

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

4. устанавливайте структуру разделения работ, основанную на развитии системной архитектуры.

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

5. определяйте и поддерживайте процессы, которые будут применены в проекте.

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

b) планируйте проектное и техническое управление.

Эта деятельность состоит из следующих задач:

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

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

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

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

3. определяйте затраты и планируйте бюджет.

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

4. определяйте роли ответственности, подотчетности и полномочия.

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

5. определяйте инфраструктуру и требуемые услуги.

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

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

Примечания

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

2 [30] дает представление о приобретении инфраструктуры и услуг,

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

Примечания

1 Техническое планирование системы часто отражается в плане управления системным проектированием (SEMP). [21] содержит дополнительную информацию относительно технического планирования в системной инженерии и предоставляет аннотируемую схему для SEMP. Планы для программных средств относительно системы часто отражаются в плане развития программных средств (SDP). [22] содержит дополнительную информацию относительно планирования программных средств и предоставляет аннотируемую схему для SDP. Планирование проекта часто отражается в плане руководства проектом. ГОСТ Р 57101-2016 содержит дополнительную информацию относительно руководства проектом.

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

c) активизируйте проект.

Эта деятельность состоит из следующих задач:

1. получайте полномочия для проекта.

Примечание - Полномочия обеспечиваются с помощью процесса управления портфелем,

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

3. реализуйте проектные планы.

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

6.3.2.1 Цель

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

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

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

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

a) становятся доступными показатели качества функционирования или результаты оценки;

b) оценивается адекватность ролей, ответственностей, подотчетности и полномочий;

c) оценивается адекватность ресурсов;

d) выполняются технические анализы продвижения проекта;

e) исследуются и анализируются отклонения в проектной работе от планов;

f) сообщается о проектном статусе задействованным заинтересованным сторонам;

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

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

i) достигаются цели проекта.

6.3.2.3 Действия и задачи

Относительно процесса оценки и контроля выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) планируйте оценку и контроль проекта:

1. определяйте стратегию оценки и контроля проекта.

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

b) оценивайте проект.

Эта деятельность состоит из следующих задач:

1. оценивайте выстраивание проектных целей и планов с проектным контекстом,

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

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

4. оценивайте адекватность ролей, ответственностей, подотчетности и полномочий.

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

5. оценивайте адекватность и пригодность ресурсов.

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

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

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

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

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

8. контролируйте критичные процессы и новые технологии.

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

9. анализируйте результаты измерений и делайте рекомендации.

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

10. регистрируйте и обеспечивайте статус и результаты задач оценки.

Примечание - В общем случае это определяется в соглашении, политике и процедурах,

11. контролируйте выполнение процесса в пределах проекта.

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

c) управляйте проектом.

Эта деятельность состоит из следующих задач:

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

Примечания

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

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

3 Для подтверждения адекватности и своевременности действий они регистрируются и анализируются,

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

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

3. если это обосновано, санкционируйте продвижение к следующей контрольной точке проекта или событию.

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

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

6.3.3.1 Цель

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

Примечания

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

2 Выполнение детальной оценки какого-либо параметра для одного из критериев осуществляется с использованием процесса системного анализа.

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

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

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

b) определяются и оцениваются альтернативные направления действий;

c) выбираются предпочтительные направления действий;

d) регистрируются обоснования решений и предположений.

6.3.3.3 Действия и задачи

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

a) готовьтесь к решениям.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию управления решением.

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

2. определяйте обстоятельства и потребности в решении.

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

3. вовлекайте соответствующие заинтересованные стороны в принятие решений, чтобы использовать опыт и знания.

Примечание - Такое вовлечение является хорошей практикой субъективной экспертизы, необходимой для анализа и решения;

b) анализируйте информацию для решения.

Эта деятельность состоит из следующих задач:

1. выбирайте и объявляйте стратегию управления решением для каждого из решений.

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

2. определяйте желательные результаты и оцениваемые критерии выбора.

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

3. определяйте области компромиссов и альтернативы.

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

4. оценивайте каждую альтернативу в сравнении с критериями.

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

c) принимайте решение и управляйте решениями.

Эта деятельность состоит из следующих задач:

1. определяйте предпочтительную альтернативу для каждого решения.

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

2. регистрируйте, отслеживайте, оценивайте и делайте отчеты по решению.

Примечания

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

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

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

6.3.4.1 Цель

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

Примечание — Риск определен в [35] как «эффект неопределенности в целях (задачах)». У этого определения имеется Примечание 1: «Эффект — отклонение от ожидаемого — положительного и/или отрицательного». Положительный риск обычно известен как возможности, к нему можно обращаться в пределах процесса управления рисками.

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

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

a) риски идентифицируются;

b) риски анализируются;

c) определяются варианты реакции на риск, они распределяются по приоритетам и делается выбор;

d) реализуются адекватные меры реакции на риск;

e) риски количественно оцениваются для анализа изменений в статусе и развития в условиях реакции на риски.

6.3.4.3 Действия и задачи

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

Примечание - ГОСТ Р ИСО/МЭК 16085-2007 содержит более детальное множество действий и задач по управлению рисками. Этот процесс управления рисками гармонизирован с ГОСТ Р ИСО 31000-2010 «Менеджмент риска. Принципы и руководство» и ГОСТ Р 51897-2011/Руководство ИСО 73:2009 «Менеджмент риска. Термины и определения». ГОСТ ISO 9001-2011 содержит основанные на риске упреждающие требования к действиям по 8.5.3,

a) планируйте управление рисками.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию управления рисками.

Примечание - Стратегия предусматривает процесс управления рисками для всех поставщиков цепочки поставок и описывает то, как риски от всех поставщиков будут возрастать к следующему уровню(ям) для объединения в процессе проектных рисков,

2. определяйте и регистрируйте контекст процесса управления рисками.

Примечания

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

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

b) управляйте профилем риска.

Эта деятельность состоит из следующих задач:

1. определяйте и регистрируйте допустимые уровни рисков и условия, при которых риск может быть принят,

2. устанавливайте и поддерживайте профиль рисков.

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

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

c) анализируйте риски.

Эта деятельность состоит из следующих задач:

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

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

2. оценивайте вероятность возникновения угроз и последствия каждого идентифицированного риска,

3. оценивайте каждый риск в сравнении с его допустимым уровнем,

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

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

d) реагируйте на риски.

Эта деятельность состоит из следующих задач:

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

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

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

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

Примечание - Обращайтесь к процессу оценки и контроля проекта;

e) непрерывно контролируйте риски.

Эта деятельность состоит из следующих задач:

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

2. анализируйте и контролируйте показатели, чтобы количественно оценить эффективность реакции на риски,

3. непрерывно контролируйте появление новых рисков и источников их появления во всем жизненном цикле.

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

6.3.5.1 Цель

Цель управления конфигурацией — управлять и контролировать системные элементы и конфигурации по жизненному циклу. Управление конфигурацией также гарантирует содержательность между продуктом и определением конфигурации, связанным с этим продуктом.

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

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

a) определяются объекты, требующие управления конфигурацией, и осуществляется управление ими;

b) устанавливаются базовые линии конфигурации;

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

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

e) совершаются необходимые аудиты конфигурации;

f) управляются и согласовываются выпуски и поставки системы;

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

6.3.5.3 Действия и задачи

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

a) планируйте управление конфигурацией.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию управления конфигурацией.

Примечания

1 Стратегия предусматривает охват:

i) ролей, ответственностей, подотчетности и полномочий;

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

iii) необходимых базовых линий, которые будут установлены;

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

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

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

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

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

3 Дополнительные руководства относительно действий по управлению конфигурацией может быть найдено в стандартах ГОСТ Р ИСО 10007-2007, [37] и [38]. Кроме того, специфические руководства, например [47], обеспечивают дополнительные прикладные детали для соответствующей области,

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

Примечание - Подход включает процедуры удаления данных;

b) определяйте конфигурацию.

Эта деятельность состоит из следующих задач:

1. Определяйте системные элементы и информационные объекты, которые являются объектами конфигурации.

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

2. определяйте иерархию и структуру системной информации.

Примечание - Это включает иерархию продуктов или системных элементов, декомпозицию системы и т.д.,

3. устанавливайте идентификаторы системы, системного элемента и информационного объекта.

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

4. определяйте базовые линии в течение жизненного цикла.

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

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

Примечание - Чтобы достичь соглашения, используется процесс оценки и контроля проекта;

c) выполняйте управление изменением конфигурации.

Эта деятельность состоит из следующих задач:

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

1. определяйте и регистрируйте заявки по изменениям и заявки по отличиям.

Примечание - Заявки по отличиям часто упоминаются как отклонения, отказы или отступления,

2. координируйте, оценивайте и позиционируйте заявки по изменениям и заявки по отличиям.

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

3. представляйте заявки для анализа и согласования.

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

4. отслеживайте и управляйте согласованными изменениями к базовой линии и заявками по отличиям.

Примечания

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

2 Любые изменения и обоснования в общем случае регистрируются;

d) выполняйте учет статуса конфигурации.

Эта деятельность состоит из следующих задач:

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

Примечания

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

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

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

e) выполняйте оценку конфигурации.

Эта деятельность состоит из следующих задач:

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

2. верифицируйте конфигурацию продукта на соответствие требованиям конфигурации.

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

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

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

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

Примечание - Это иногда называют функциональным аудитом конфигурации,

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

Примечание - Это иногда называют физическим аудитом конфигурации,

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

f) выполняйте контроль за выпуском.

Эта деятельность состоит из следующих задач:

1. согласовывайте выпуски и поставки системы.

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

2. отслеживайте и управляйте выпусками и поставками системы.

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

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

6.3.6.1 Цель

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

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

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

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

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

b) определяются информационные предоставления;

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

d) регистрируется статус информации;

e) информация делается доступной для определяемых заинтересованных сторон.

6.3.6.3 Действия и задачи

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

Примечание - [10] суммирует требования для содержания процесса жизненного цикла информационных объектов (документации) и дает представление об их разработке;

a) готовьтесь к управлению информацией.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию управления информацией.

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

2. определяйте объекты информации, которые подлежат управлению.

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

3. определяйте полномочия и ответственности по управлению информацией.

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

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

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

5. определяйте действия по сопровождению информации.

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

b) выполняйте управление информацией.

Эта деятельность состоит из следующих задач:

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

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

2. поддерживайте информационные объекты и записи об их хранении и регистрируйте статус информации.

Примечания

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

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

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

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

4. архивируйте предназначенную для этого информацию.

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

5. уничтожайте нежелательную, недостоверную или недействительную информацию.

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

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

6.3.7.1 Цель

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

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

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

a) определяются информационные потребности;

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

c) собираются, проверяются и сохраняются необходимые данные;

d) анализируются данные, интерпретируются результаты;

e) информационными объектами предоставляется объективная информация для поддерживающих решений.

6.3.7.3 Действия и задачи

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

Примечания

1 [13] содержит более детальное множество действий измерений и задач, которые обеспечивают выполнение действий и задач, приведенных ниже.

2 Раздел 8 ГОСТ ISO 9001-2011 определяет системные требования к системам менеджмента качества для измерений и контроля процессов и продукции;

a) готовьтесь к измерениям.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию измерений,

2. описывайте характеристики организации, которые относятся к измерениям,

3. определяйте и располагайте по приоритетам информационные потребности.

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

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

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

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

7. определяйте ресурсы для решения задач измерений,

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

b) выполняйте измерения.

Эта деятельность состоит из следующих задач:

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

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

2. собирайте, сохраняйте и проверяйте данные,

3. анализируйте данные и разрабатывайте информационные объекты,

4. регистрируйте результаты и информируйте пользователей по измерениям.

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

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

6.3.8.1 Цель

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

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

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

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

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

b) определяются критерии и методы оценки гарантий качества;

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

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

Примечание — Эти результаты координируются с результатами процесса управления качеством и данными, приведенными в 4.1 ГОСТ ISO 9001-2011 «Общие требования».

6.3.8.3 Действия и задачи

Относительно процесса гарантии качества выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к гарантиям качества.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию гарантии качества.

Примечания

1 Стратегия согласуется с политикой управления качеством и процедурами и включает:

i) определенные роли, ответственности, подотчетности и полномочия;

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

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

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

v) критерии принятия продукта или услуги и оценок процесса, продукта и услуги.

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

2. убеждайтесь, что установленные для обеспечения независимости цели были достигнуты;

b) выполняйте количественные оценки продукта или услуги:

1. оценивайте продукты и услуги для соответствия установленным критериям, контрактам, стандартам и инструкциям,

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

c) выполняйте оценки процесса.

Эта деятельность состоит из следующих задач:

1. оценивайте проектные процессы жизненного цикла для анализа соответствия,

2. оценивайте инструментарии и окружающую среду, которая поддерживает или автоматизирует процессы для анализа соответствия,

3. оценивайте процессы поставщика для анализа соответствия требованиям процессов.

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

d) управляйте записями и отчетами для гарантий качества.

Эта деятельность состоит из следующих задач:

1. создавайте записи и отчеты, связанные с действиями для гарантии качества.

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

2. сопровождайте, сохраняйте и распространяйте записи и отчеты,

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

Примечание - Это предусматривает усвоение изученных уроков.

e) реагируйте на инциденты и проблемы.

Эта деятельность состоит из следующих задач:

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

1. регистрируйте, анализируйте и классифицируйте инциденты,

2. разрешайте инциденты или поднимайте их до уровня проблем,

3. регистрируйте, анализируйте и классифицируйте проблемы.

Примечание - Результаты анализа включают потенциальные варианты реагирования,

4. располагайте по приоритетам реакции на проблемы и реагируйте,

5. отмечайте и анализируйте тенденции в инцидентах и проблемах,

6. информируйте заинтересованные стороны о статусе инцидентов и проблем,

7. отслеживайте инциденты и проблемы до их разрешения.

6.4. Технические процессы

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

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

Технические процессы включают в себя процессы:

a) анализа бизнеса или назначения;

b) определения потребностей и требований заинтересованной стороны;

c) определения системных требований;

d) определения архитектуры;

e) определения проекта;

f) системного анализа;

g) реализации;

h) комплексирования;

i) верификации;

j) передачи;

k) валидации;

l) функционирования;

m) сопровождения;

n) изъятия и списания.

Примечания

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

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

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

6.4.1 Процессы анализа бизнеса или назначения

6.4.1.1 Цель

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

Примечания

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

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

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

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

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

a) определяется множество проблем или возможностей;

b) характеризуется область решений;

c) определяются базовые концепции функционирования (эксплуатационные концепции) и другие концепции в стадиях жизненного цикла;

d) определяются и анализируются альтернативные классы возможных решений;

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

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

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

6.4.1.3 Действия и задачи

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

a) готовьтесь к анализу бизнеса или назначения.

Эта деятельность состоит из следующих задач:

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

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

2. определяйте стратегию анализа бизнеса или назначения.

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

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

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

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

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

b) определяйте множество проблем и/или возможностей.

Эта деятельность состоит из следующих задач:

1. анализируйте проблемы и возможности в контексте факторов, соответствующих области приложений.

Примечания

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

2 Результаты анализа рассматривают как часть решений управления портфелем,

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

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

c) характеризуйте область решений.

Эта деятельность состоит из следующих задач:

1. определяйте базовые концепции функционирования (эксплуатации) и другие концепции в стадиях жизненного цикла.

Примечания

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

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

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

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

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

d) оценивайте альтернативные классы.

Эта деятельность состоит из следующих задач:

1. оценивайте каждый альтернативный класс.

Примечания

1 Каждый альтернативный класс решений оценивается в сравнении по определенным критериям, которые устанавливаются в стратегии организации. Выполнимость класса решений — это один из основных критериев решения. Некоторые из критериев рассматриваются с применением процесса управления портфелем.

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

2. выбирайте предпочтительный альтернативный класс (классы).

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

e) управляйте анализом бизнеса или назначения.

Эта деятельность состоит из следующих задач:

1. поддерживайте прослеживаемость в процессе анализа бизнеса или назначения.

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

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

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

6.4.2 Процесс определения потребностей и требований заинтересованной стороны

6.4.2.1 Цель

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

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

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

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

a) определяются заинтересованные стороны системы;

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

c) определяются ограничения для системы;

d) определяются потребности заинтересованных сторон;

e) потребности заинтересованных сторон располагаются по приоритетам и преобразуются в понятно определенные требования;

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

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

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

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

j) устанавливается прослеживаемость требований заинтересованных сторон к конкретным заинтересованным сторонам и их потребностям.

6.4.2.3 Действия и задачи

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

a) готовьтесь к определению потребностей и требований заинтересованных сторон.

Эта деятельность состоит из следующих задач:

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

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

2. определяйте стратегию определения потребностей и требований заинтересованных сторон.

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

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

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

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

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

b) определяйте потребности заинтересованных сторон.

Эта деятельность состоит из следующих задач:

1. определяйте контекст использования в пределах концепции функционирования (эксплуатации) и начальных понятий жизненного цикла.

Примечание — Контекст применения охватывается путем использования [28]. Базовые концепции жизненного цикла разрабатываются с помощью процесса анализа бизнеса или назначения,

2. определяйте потребности заинтересованных сторон.

Примечания

1 Определение потребностей заинтересованной стороны включает выявление потребностей непосредственно от заинтересованной стороны, определение из неявных потребностей заинтересованной стороны, основанных на знании области и понимании контекста, и зарегистрированных в пересечениях интересов от предыдущих действий. Потребности часто включают показатели эффективности. Чтобы помочь выявлению потребностей, часто используется функциональный анализ. Чтобы выявить и определить нефункциональные требования к качеству, которые часто являются неявными потребностями заинтересованной стороны, также применимы характеристики качества и модели качества согласно ГОСТ Р ИСО/МЭК 25010-2015 и приложения модели качества к анализу требований согласно [26].

2 Потребности заинтересованной стороны описывают потребности, желания, ожидания и воспринятые ограничения определенных заинтересованных сторон. Понимание потребностей заинтересованной стороны в минимальной безопасности и соблюдении требований частной жизни, необходимых для эксплуатационной окружающей среды, минимизирует потенциал нарушений в планах, графиках и работах. Если возникнут существенные проблемы, касающиеся пользователей и других заинтересованных сторон или их взаимодействия с системой, рекомендации для определения и рассмотрения проблем человек-система могут быть найдены в [16],

3. располагайте по приоритетам сверху вниз выбранные потребности.

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

4. определяйте потребности заинтересованных сторон и обосновывайте их.

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

c) разрабатывайте концепции функционирования (эксплуатационные понятия) и другие концепции жизненного цикла.

Эта деятельность состоит из следующих задач.

Примечание — Другие концепции жизненного цикла подразумевают концепции приобретения, развертывания, поддержки, безопасности, изъятия и списания. Базовые концепции жизненного цикла, определенные в пределах процесса анализа бизнеса или назначения, разрабатываются в контексте определенных потребностей заинтересованных сторон, соответствующих сценариев и взаимодействий. Для получения дополнительной информации об эксплуатационных концепциях следует обратиться к [31] (см. разделы 5 и 6), а для аннотируемой схемы эксплуатационных концепций системы — к [31] (см. приложение A),

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

Примечания

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

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

2. определяйте взаимодействие между пользователями и системой.

Примечания

1 Требование применимости принимает во внимание человеческие ограничения по возможностям и навыкам. Где это возможно, используются стандарты, например ГОСТ Р ИСО 9241, и принятые профессиональные методы для определения:

i) физических, умственных способностей и возможностей при обучении;

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

iii) нормальных, необычных и чрезвычайных условий;

iv) требований операторов и пользователей, обучения и культуры.

2 Если важна практичность, соответствующие требования планируются, определяются и реализуются в процессах жизненного цикла. Это рассмотрено в [16], где представлена информация, затрагивающая проблемы систем, ориентированных на человека, и в [27], где дана информация относительно практичности программных средств;

d) преобразовывайте потребности в требования заинтересованных сторон.

Эта деятельность состоит из следующих задач:

1. определяйте ограничения на системное решение.

Примечание - Ограничения возникают из:

1. случаев или областей решений, определенных заинтересованной стороной;

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

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

4. задач допустимости, определенных заинтересованной стороной.

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

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

Примечания

1 Дополнительная информация относительно гарантий программных средств и систем приведена в ГОСТ Р ИСО/МЭК 15026.

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

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

4 Дополнительная информация относительно характеристик качества программных средств при их использовании приведена в [26],

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

Примечания

1 Для получения дополнительной информации о требованиях заинтересованных сторон следует обратиться к разделам 5 и 6 [31], а для аннотируемой схемы эксплуатационных понятий системы — к разделам 8 и 9.

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

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

4 Требования заинтересованных сторон являются основой критериев валидации для системы и системных элементов;

e) анализируйте потребности и требования заинтересованных сторон.

Эта деятельность состоит из следующих задач:

1. анализируйте полное множество требований заинтересованных сторон.

Примечания

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

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

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

Примечание — Это включает определение технических показателей, показателей качества и критичных параметров работы, связанных с каждым из показателей эффективности, определяемых в требованиях заинтересованных сторон. Основные показатели функционирования (например, показатели эффективности и пригодности) определяются, анализируются и рассматриваются для того, чтобы помочь гарантировать заинтересованной стороне соответствие требованиям и обеспечить определение проектной стоимости, сроков или эксплуатационных рисков, связанных с любым несоблюдением. В [13] описан процесс для определения и использования соответствующих показателей. Комплекс стандартов [48] рассматривает соответствующие показатели качества для программных средств,

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

4. разрешайте проблемы относительно требований заинтересованных сторон.

Примечание — Сюда включается рассмотрение проблем, когда нарушаются характеристики для частных требований или множества требований, как это определено в [31];

f) управляйте определением потребностей и требований заинтересованных сторон.

Эта деятельность состоит из следующих задач:

1. получайте полное соглашение по требованиям заинтересованных сторон.

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

2. поддерживайте прослеживаемость потребностей и требований заинтересованных сторон.

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

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

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

6.4.3 Процесс определения системных требований

6.4.3.1 Цель

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

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

В результате успешной реализации процесса определения системных требований:

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

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

c) определяются критичные показатели качества функционирования;

d) анализируются системные требования;

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

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

g) обеспечивается прослеживаемость системных требований к требованиям заинтересованных сторон.

6.4.3.3 Действия и задачи

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

a) готовьтесь к определению системных требований.

Эта деятельность состоит из следующих задач:

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

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

2. вырабатывайте стратегию определения системных требований.

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

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

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

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

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

b) определяйте системные требования.

Эта деятельность состоит из следующих задач:

1. определяйте каждую функцию, которую система должна выполнять.

Примечания

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

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

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

2. определяйте необходимые ограничения реализации.

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

3. определяйте системные требования, которые касаются рисков, критичности системы или критичных характеристик качества.

Примечание — Критичные характеристики качества связаны со здоровьем, безопасностью, обеспечением защищенности, надежностью, пригодностью и сопровождаемостью. Определение системных требований включает анализ и рассмотрение вопросов безопасности, в т.ч. тех аспектов, которые касаются методов функционирования и сопровождения, экологических воздействий и травматизма персонала. Это также включает рассмотрение каждой функции, связанной с безопасностью и соответствующей целостности, выраженной в терминах необходимого снижения риска. Используются применимые стандарты по функциональной безопасности, например ГОСТ Р МЭК 61508, и защите окружающей среды, например ГОСТ Р ИСО 14001-2007. Анализируются рассмотрения вопросов безопасности, включая аспекты, связанные с компромиссами и защитой критичной информации, данных и материалов. Определяются риски, связанные с безопасностью, с применением соответствующих стандартов безопасности, включая (но не ограничиваясь этим) анализ административных, персональных, физических, компьютерных, коммуникационных, сетевых факторов, излучений и факторов окружающей среды. Следует обращаться к ГОСТ Р ИСО/МЭК 15026-4-2016 как руководству по гарантиям для систем и программных средств. [30] содержит руководство по требованиям к информационной безопасности при аутсорсинге продукции и услуг. [26] содержит руководство для показателей внешнего качества системы,

4. определяйте системные требования и давайте обоснование.

Примечания

1 Сюда относится определение всех системных требований, связанных с требованиями заинтересованных сторон, функциональными границами, функциями, ограничениями, целями по стоимости, взаимодействиями и критичными характеристиками качества. Практика показала, что этот процесс требует итеративных и рекурсивных шагов параллельно с другими процессами жизненного цикла по всей иерархии системы. Следует обратиться к разделам 5 и 6 [31] для получения дополнительной информации о системных требованиях и разделам 8 и 9 того же стандарта — для получения описаний аннотируемой схемы для задания системных требований.

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

c) анализируйте системные требования.

Эта деятельность состоит из следующих задач.

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

1. анализируйте полное множество системных требований.

Примечания

1 Системные требования визируются как для характеристик частных требований, так и для характеристик множества требований. Потенциальные характеристики анализа подразумевают, что требования необходимы, свободно реализуемы, непротиворечивы, содержательны, полны, отражают специфику, выполнимы, прослеживаемы, поддаются проверке, приемлемы и имеют границы. [31] предоставляет дополнительную информацию о характеристиках требований. Недостатки, противоречия и «узкие места» определяются и разрешаются в пределах полного множества системных требований.

2 Чтобы оценить выполнимость, приемлемость и сбалансированность, используется процесс системного анализа,

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

Примечание — Сюда относится определение технических показателей, показателей качества и критичных параметров функционирования, связанных с каждым показателем эффективности, определенным в системных требованиях. Критичные показатели качества функционирования (например, показатели функционирования и технические эксплуатационные показатели) анализируются и рассматриваются, чтобы помочь гарантировать удовлетворение системных требований и определение проектной стоимости, сроков или рисков при функционировании, связанных с любым несоответствием. [13] рассматривает процесс идентификации, определения и использования соответствующих показателей. В [49] предоставлена информация относительно выбора, определения и использования критичных показателей функционирования. Комплекс стандартов [48] рассматривает соответствующие показатели качества программных средств,

3. доводите проанализированные требования обратно до соответствующих заинтересованных сторон для рассмотрения.

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

4. разрешайте проблемы, возникающие со стороны системных требований.

Примечание — Это относится к требованиям, которые нарушают характеристики для частных требований или множества требований, как это определено в [31];

d) управляйте системными требованиями.

Эта деятельность состоит из следующих задач.

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

1. получайте подробное соглашение по системным требованиям.

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

2. поддерживайте прослеживаемость системных требований.

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

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

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

6.4.4 Процесс определения архитектуры

6.4.4.1 Цель

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

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

Примечания

1 Архитектура системы имеет дело с фундаментальными принципами, понятиями, свойствами, характеристиками и их объединением в рассматриваемую систему. У определения архитектуры существует большее количество приложений, нежели просто продвижение проекта или его части. ГОСТ Р 57100-2016 содержит дополнительную информацию об описании, природе и использовании архитектуры.

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

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

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

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

a) архитектура обращается к определенным интересам заинтересованных сторон;

b) разрабатываются точки зрения на архитектуру;

c) определяются контекст, границы и внешние взаимодействия системы;

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

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

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

g) оцениваются варианты архитектуры;

h) достигается архитектурная базовая линия для процессов по всему жизненному циклу;

i) достигается выстраивание архитектуры согласно требованиям и характеристикам проекта;

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

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

6.4.4.3 Действия и задачи

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

a) готовьтесь к определению архитектуры.

Эта деятельность состоит из следующих задач:

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

Примечание - Определяются основные факторы продвижения архитектуры с учетом:

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

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

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

2. определяйте интересы заинтересованных сторон.

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

3. определяйте дорожную карту, подход и стратегию для определения архитектуры.

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

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

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

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

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

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

b) разрабатывайте точки зрения на архитектуру.

Эта деятельность состоит из следующих задач:

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

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

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

3. обосновывайте выбор структур (структуры), точек зрения и типов моделей,

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

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

Эта деятельность состоит из следующих задач:

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

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

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

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

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

Примечание - Распределяемые объекты могут быть физическими, логическими или концептуальными,

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

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

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

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

Примечание — Соответствующие правила из структур — это один из способов установления гармонии между представлениями (см. ГОСТ Р 57100-2016);

d) связывайте архитектуру с проектом.

Эта деятельность состоит из следующих задач:

1. определяйте системные элементы, которые касаются архитектурных сущностей и природы этих отношений.

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

2. определяйте интерфейсы и взаимодействия между системными элементами и внешними сущностями.

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

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

4. распределяйте системные элементы и архитектурные сущности по проектным характеристикам,

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

e) оценивайте варианты архитектуры.

Эта деятельность состоит из следующих задач:

1. оценивайте каждый вариант архитектуры в сравнении с ограничениями и требованиями,

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

Примечание - Чтобы обеспечить выполнение этой задачи, допускается использовать процессы системного анализа и управления рисками,

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

Примечание - Чтобы обеспечить выполнение этой задачи, допускается использовать процесс управления решениями,

4. устанавливайте базовую линию архитектуры в выбранном варианте архитектуры.

Примечание - Базовая линия архитектуры формируется из моделей, представлений и других соответствующих описаний архитектуры;

f) управляйте выбранной архитектурой.

Эта деятельность состоит из следующих задач:

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

2. получайте официальное согласование архитектуры заинтересованными сторонами.

Примечания

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

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

3. поддерживайте соответствие и полноту архитектурных сущностей и их архитектурных характеристик.

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

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

5. поддерживайте стратегию определения и оценки архитектуры,

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

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

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

6.4.5.1 Цель

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

Примечания

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

2 Процесс определения проекта рассматривает любые применимые технологии и их вклад в системное решение. Проект обеспечивает «реализацию к» такому уровню определения, как чертежи и детализированные описания проекта.

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

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

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

a) определяются характеристики проекта каждого системного элемента;

b) системные требования распределяются по элементам системы;

c) выбираются или формулируются необходимые определения проекта;

d) определяются или уточняются взаимодействия между системными составными элементами;

e) разрабатываются артефакты проекта;

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

g) устанавливается прослеживаемость характеристик проекта относительно архитектурных сущностей архитектуры системы.

6.4.5.3 Действия и задачи

Относительно процесса определения проекта выполняйте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к определению проекта.

Эта деятельность состоит из следующих задач:

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

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

2. определяйте необходимые типы характеристик проекта.

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

3. определяйте принципы развития проекта.

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

4. вырабатывайте стратегию определения проекта,

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

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

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

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

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

Эта деятельность состоит из следующих задач:

1. распределяйте системные требования по системным элементам,

2. преобразовывайте архитектурные характеристики в характеристики проекта.

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

3. определяйте необходимое обеспечение проекта.

Примечание - При выполнении этой задачи определяются и/или выбираются необходимые виды обеспечения проекта, такие как модели, уравнения, алгоритмы, вычисления, формальные выражения и значения параметров, образцов, эвристики и т.д., которые связаны с проектными характеристиками. Совместимость, приемлемость, безопасность и другие критичные свойства в контексте их запланированной эксплуатационной среды являются объектами рассмотрения во время определения необходимого обеспечения проекта. ГОСТ Р ИСО 9241-210-2012 представляет руководство для ориентированных на человека проектов/эргономического проекта,

4. исследуйте альтернативы проекта.

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

5. уточняйте или определяйте взаимодействия между системными элементами и внешними сущностями.

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

6. устанавливайте артефакты проекта.

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

c) оценивайте альтернативы для получения системных элементов.

Эта деятельность состоит из следующих задач:

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

Примечание - Эти варианты включают готовые продукты («коммерческие»), объекты, предоставленные приобретающей стороной или повторное использование предыдущего проекта,

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

3. определяйте предпочтительную альтернативу среди всех решений из вариантов для неразрабатываемых объектов и новые проектные альтернативы для системного элемента.

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

d) управляйте проектом.

Эта деятельность состоит из следующих задач:

1. увязывайте характеристики проекта с системными элементами.

Примечания

1 Задача состоит из установления прослеживаемости между детальными характеристиками проекта и архитектурными сущностями в архитектуре системы.

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

2. охватывайте весь проект и давайте логическое обоснование.

Примечания

1 Логическое обоснование включает информацию о главных вариантах реализации и видах обеспечения.

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

3. поддерживайте прослеживаемость проекта.

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

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

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

6.4.6 Процесс системного анализа

6.4.6.1 Цель

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

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

Примечание - Этот процесс часто используется в объединении с процессом управления решениями.

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

В результате успешной реализации процесса системного анализа:

a) определяются необходимые исследования системы;

b) согласовываются предположения для системного анализа и результатов;

c) результаты системного анализа предоставляются для принятия решения;

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

e) становятся доступными любые обеспечивающие системы или услуги, необходимые для системного анализа.

6.4.6.3 Действия и задачи

Относительно процесса системного анализа выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к системному анализу.

Эта деятельность состоит из следующих задач:

1. определяйте проблему или вопрос, который требует системного анализа.

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

2. определяйте заинтересованные стороны системного анализа,

3. определяйте область, цели и степень адекватности проводимого системного анализа.

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

4. выбирайте методы системного анализа.

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

5. определяйте стратегию системного анализа,

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

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

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

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

8. собирайте данные и формируйте соответствующие входы, необходимые для анализа;

b) выполняйте системный анализ.

Эта деятельность состоит из следующих задач:

1. определяйте и согласовывайте предположения,

2. применяйте выбранные методы, чтобы выполнить необходимый анализ,

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

Примечание - Результаты координируются с соответствующими исследованиями, которые были завершены ранее,

4. делайте заключения и формируйте рекомендации.

Примечание - Для решения этой задачи привлекаются эксперты в соответствующей предметной области и заинтересованные стороны,

5. регистрируйте результаты системного анализа;

c) управляйте системным анализом.

Эта деятельность состоит из следующих задач:

1. поддерживайте прослеживаемость результатов системного анализа.

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

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

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

6.4.7 Процесс реализации

6.4.7.1 Цель

Цель процесса реализации — реализовать заданный системный элемент.

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

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

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

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

b) реализуется системный элемент;

c) системный элемент комплектуется или сохраняется;

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

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

f) устанавливается прослеживаемость.

6.4.7.3 Действия и задачи

Относительно процесса реализации выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к реализации.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию реализации.

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

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

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

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

Примечание - Сюда включается определение требований и взаимодействий для обеспечивающих систем,

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

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

b) выполняйте реализацию.

Эта деятельность состоит из следующих задач.

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

1. реализуйте или адаптируйте системные элементы согласно определенным процедурам реализации.

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

i) аппаратные средства

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

ii) программные средства

Элементы программных средств или приобретаются, или разрабатываются. Обычно элементы программных средств верифицируются на соответствие системным требованиям и критериям проекта. [43] регламентирует реализацию системных элементов, представимых в виде программных средств,

iii) услуги

Элементы в виде услуг включают множество предоставляемых услуг. Обычно элементы в виде услуг верифицируются на соответствие системным требованиям и критериям оказания услуг. ГОСТ Р ИСО/МЭК 20000 регламентирует системные элементы, реализуемые в виде услуг,

iv) эксплуатационные ресурсы

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

2. комплектуйте и сохраняйте системные элементы.

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

3. регистрируйте объективные доказательства того, что системный элемент удовлетворяет системным требованиям.

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

c) управляйте результатами реализации.

Эта деятельность состоит из следующих задач:

1. регистрируйте результаты реализации и любые отклонения, с которыми сталкиваетесь.

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

2. поддерживайте прослеживаемость реализованных системных элементов.

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

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

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

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

6.4.8.1 Цель

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

Примечания

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

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

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

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

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

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

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

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

e) комплексируется система из реализованных составных системных элементов;

f) проверяются взаимодействия между реализованными системными элементами, составляющими систему;

g) проверяются взаимодействия между системой и внешней окружающей средой;

h) регистрируются отклонения, появившиеся из-за действий по комплексированию.

6.4.8.3 Действия и задачи

Относительно процесса комплексирования выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к комплексированию.

Эта деятельность состоит из следующих задач:

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

Примечания

1 Детальная верификация взаимодействий выполняется с использованием процесса верификации.

2 Обращайтесь к стандартам комплексов ГОСТ Р ИСО/МЭК 15026 и ГОСТ Р ИСО/МЭК 27000 для получения информации относительно гарантий, целостности и безопасности. При определении точек контроля рассматривайте вопросы противодействия контрафактам, защиты от постороннего вмешательства, гарантий системы и программных средств и интероперабельности элементов,

2. определяйте стратегию комплексирования.

Примечания

1 Комплексирование выполняется согласно предопределенной стратегии, которая упорядочивает объединение реализованных системных элементов, основанное на приоритетах системных требований и определении архитектуры, сосредотачиваясь на взаимодействиях, минимизируя время комплексирования, стоимость и риски.

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

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

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

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

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

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

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

b) выполняйте комплексирование — последовательно объединяйте конфигурации системного элемента до полного комплексирования системы.

Эта деятельность состоит из следующих задач:

1. получайте реализованные системные элементы в согласованные сроки.

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

2. осуществляйте сборку реализованных системных элементов.

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

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

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

c) управляйте результатами комплексирования.

Эта деятельность состоит из следующих задач:

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

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

2. поддерживайте прослеживаемость комплексируемых системных элементов.

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

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

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

6.4.9 Процесс верификации

6.4.9.1 Цель

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

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

Примечание - Процесс верификации гарантирует, что «продукт построен правильно». Процесс валидации гарантирует, что «построен правильный продукт».

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

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

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

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

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

d) системный элемент или система проходят верификацию;

e) делается отчет, предоставляющий информацию для корректирующих действий;

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

g) устанавливается прослеживаемость верифицированных системных элементов.

6.4.9.3 Действия и задачи

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

a) готовьтесь к верификации.

Эта деятельность состоит из следующих задач.

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

1. определяйте область верификации и соответствующие действия верификации.

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

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

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

3. выбирайте соответствующие методы верификации или методики и соответствующие критерии для каждого действия верификации.

Примечания

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

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

4. определяйте стратегию верификации.

Примечания

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

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

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

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

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

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

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

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

b) выполняйте верификацию.

Эта деятельность состоит из следующих задач:

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

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

2. выполняйте процедуры верификации.

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

c) управляйте результатами верификации.

Эта деятельность состоит из следующих задач:

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

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

2. регистрируйте эксплуатационные инциденты и проблемы и гарантируйте, что они разрешаются.

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

3. поддерживайте прослеживаемость верифицированных системных элементов.

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

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

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

6.4.10 Процесс передачи

6.4.10.1 Цель

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

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

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

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

В результате успешной реализации процесса передачи:

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

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

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

d) обеспечивается способность системы, установленной в ее эксплуатационном местоположении, к выполнению ее функций;

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

f) установленная система активизируется и делается готовой к функционированию;

g) устанавливается прослеживаемость переданных элементов.

6.4.10.3 Действия и задачи

Относительно процесса передачи выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к передаче.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию передачи.

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

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

Примечание - Сюда относятся изменения, необходимые для инсталляции или использования,

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

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

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

Примечание - Сюда включается определение требований и взаимодействий для обеспечивающих систем,

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

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

7. определяйте и организуйте отгрузку и получение системных элементов и обеспечивающих систем;

b) выполняйте передачу.

Эта деятельность состоит из следующих задач:

1. подготовьте участок местоположения для эксплуатации в соответствии с требованиями к инсталляции.

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

2. поставьте систему для инсталляции в определенное место и указанное время.

Примечание - Такое иногда оказывается востребованным, чтобы обеспечить промежуточное хранение до поставки,

3. инсталлируйте (установите) систему в ее эксплуатационном местоположении во взаимодействии с окружающей средой.

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

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

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

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

6. выполняйте активизацию и контроль системы.

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

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

Примечания

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

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

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

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

9. анализируйте систему на предмет эксплуатационной готовности.

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

10. принимайте систему в эксплуатацию (для функционирования).

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

c) управляйте результатами передачи.

Эта деятельность состоит из следующих задач:

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

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

2. регистрируйте эксплуатационные инциденты и проблемы и гарантируйте, что они разрешаются.

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

3. поддерживайте прослеживаемость переданных системных элементов.

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

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

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

6.4.11 Процесс валидации (аттестации)

6.4.11.1 Цель

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

Примечание - Процесс валидации гарантирует, что «построен правильный продукт». Процесс верификации гарантирует, что «продукт построен правильно».

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

В результате успешной реализации процесса валидации (аттестации):

a) определяются критерии валидации для требований заинтересованных сторон;

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

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

d) непосредственно осуществляется валидация системы или системного элемента;

e) становятся доступными любые обеспечивающие системы или услуги, необходимые для валидации;

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

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

h) устанавливается прослеживаемость системных элементов, прошедших валидацию.

6.4.11.3 Действия и задачи

Относительно процесса валидации выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к валидации.

Эта деятельность состоит из следующих задач.

Примечание - Стратегия валидации в общем случае сосредотачивается на том, чтобы минимизировать стоимость, сроки и/или риски,

1. определяйте область валидации и соответствующие действия валидации.

Примечания

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

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

2. определяйте границы, которые потенциально ограничивают выполнимость действий валидации.

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

3. выбирайте соответствующие методы валидации или методики и соответствующие критерии для каждого действия валидации.

Примечания

1 Метод или методики валидации предусматривают: инспекцию (включая независимое рассмотрение), анализ (включая моделирование, имитацию, аналогию/подобие), демонстрацию или тестирование. Выбор методов или методик валидации делается согласно типу системы, целям проекта и допустимым рискам.

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

4. определяйте стратегию валидации.

Примечания

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

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

5. определяйте ограничения системы из стратегии валидации для их включения в требования заинтересованных сторон.

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

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

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

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

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

b) выполняйте валидацию.

Эта деятельность состоит из следующих задач:

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

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

2. выполняйте процедуры валидации в определенной среде.

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

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

c) управляйте результатами валидации.

Эта деятельность состоит из следующих задач:

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

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

2. регистрируйте эксплуатационные инциденты и проблемы и гарантируйте, что они разрешаются.

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

3. поддерживайте прослеживаемость системных элементов, прошедших валидацию.

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

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

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

6.4.12 Процесс функционирования

6.4.12.1 Цель

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

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

Примечание - ГОСТ Р ИСО/МЭК 20000-1-2013 содержит требования для систем управления услугами.

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

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

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

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

c) становятся доступными обученные, компетентные операторы;

d) поставляются услуги системы, которые отвечают требованиям заинтересованных сторон;

e) контролируется работа системы во время функционирования;

f) оказывается поддержка конкретному заказчику.

6.4.12.3 Действия и задачи

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

a) готовьтесь к функционированию.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию функционирования.

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

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

ii) стратегию укомплектования персоналом и графики выполнения работ для операторов;

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

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

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

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

vii) стратегии защиты окружающей среды и устойчивости функционирования системы;

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

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

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

Примечание - Сюда включается определение требований и взаимодействий для обеспечивающих систем,

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

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

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

6. поручайте обученному квалифицированному персоналу функции операторов.

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

b) выполняйте функционирование.

Эта деятельность состоит из следующих задач:

1. используйте систему в ее намеченной эксплуатационной среде.

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

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

Примечание - Это включает источники энергии для аппаратных средств и условия для операторов,

3. контролируйте функционирование системы.

Примечания

1 Это включает:

i) обеспечение поддержки стратегии функционирования;

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

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

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

3 Стоимость функционирования также контролируется в сравнении с целями и ограничениями, определяется потенциал для совершенствования,

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

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

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

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

c) управляйте результатами функционирования.

Эта деятельность состоит из следующих задач:

1. регистрируйте результаты функционирования и любых отклонений.

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

2. регистрируйте эксплуатационные инциденты и проблемы и гарантируйте, что они разрешаются.

Примечания

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

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

3. поддерживайте прослеживаемость элементов функционирования.

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

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

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

d) поддерживайте заказчика.

Эта деятельность состоит из следующих задач:

1. обеспечивайте помощь и консультации заказчикам согласно просьбам.

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

2. регистрируйте и контролируйте запросы и последующие действия для поддержки,

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

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

6.4.13 Процесс сопровождения

6.4.13.1 Цель

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

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

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

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

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

c) делаются доступными системные элементы для замены, восстановленные или переаттестованные системные элементы;

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

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

6.4.13.3 Действия и задачи

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

a) готовьтесь к сопровождению.

Эта деятельность состоит из следующих задач:

1. Определяйте стратегию сопровождения.

Примечания

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

i) корректирующую и профилактическую стратегии сопровождения для поддержки услуг в эксплуатационной среде для достижения удовлетворенности заказчика;

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

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

iv) количество и типы хранимых системных элементов для замены, их местоположение и условия хранения, ожидаемые расходные нормы замены, история хранение и частота обновления;

v) способы противодействия введению в систему контрафактных (поддельных) системных элементов;

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

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

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

[50] содержит более подробную информацию. Сопровождение, базирующееся на условиях (CBM/CBM+), является стратегией к повышению надежности системы (проводя обычное или корректирующее сопровождение, ведущее к сокращению времени, когда система находится в состоянии неготовности).

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

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

Примечание - Ограничения часто следуют из потребностей к:

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

2. повторному использованию заменяемых системных элементов и приспособлению ограничений в пополнении запасов;

3. проводимому сопровождению в специальном местоположении или окружающей среде,

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

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

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

Примечание - Сюда включаются определения требований и взаимодействий для обеспечивающих систем,

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

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

b) выполняйте сопровождение.

Эта деятельность состоит из следующих задач:

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

2. регистрируйте инциденты и проблемы сопровождения и гарантируйте, что они разрешаются.

Примечания

1 Если инцидент случился во время сопровождения, штатное должностное лицо по сопровождению делает регистрацию инцидента и предпринимает действия, предписанные в аттестованных процедурах сопровождения.

2 Выполнение действий сопровождения по определению и разрешению проблем осуществляется с использованием процессов гарантий качества, оценки и контроля проекта,

3. реализуйте процедуры для исправления случайных ошибок и/или регламентной замены системных элементов.

Примечание - Для случайных системных отказов ошибки изолируются сверху вниз к планируемому уровню замены, ремонта, пересмотра или реконфигурации системного элемента. После этого для системного элемента выполняются корректирующие действия, а корректность функционирования системы подлежит верификации. Действия регистрируются для оценки срока эксплуатации модернизируемых системных элементов,

4. предпринимайте действия по восстановлению системы до ее эксплуатационного статуса после выявления случайных ошибок, которые вызывают отказ системы.

Примечание - Восстановление до полного эксплуатационного статуса может оказаться невозможным, пока не исправлена причина появления ошибки. В этом случае система восстанавливается к запасному (резервирующему) режиму согласно планам действий в непредвиденных обстоятельствах,

5. выполняйте упреждающее сопровождение, заменяя или обслуживая системные элементы до их отказа согласно плановым срокам и процедурам сопровождения,

6. выполняйте действия по идентификации отказов при выявлении несоответствий в системе,

7. определяйте моменты, когда требуется адаптирующее или совершенствующее сопровождение.

Примечание - Адаптирующее или совершенствующее сопровождение обычно влечет за собой изменения в системных требованиях, архитектуре и/или проекте. Это может оказаться необходимым для установления нового проекта, связанного с модификацией существующей системы. В этом случае для открытия работ со стадии разработки применяется процесс управления портфелем;

c) выполняйте поддержку логистики.

Эта деятельность состоит из следующих задач:

1. выполняйте логистику для приобретения.

Примечание - Учет логистики для приобретения включается в соглашение, являющееся результатом выполнения процесса соглашения. Параметры поддержки также рассматриваются на стадии разработки. Это включает анализ функционирования с определением эффективности по затратам с тем, чтобы влиять на начальный проект системы или планировать запасные части и регламентное обслуживание во время эксплуатации. Эти решения часто ограничиваются в соответствии с требованиями пригодности и воздействуют на управления цепочками поставок. Логистика для приобретения рассматривает потребности в сопровождении системы одновременно с определением системных требований,

2. выполняйте логистику для эксплуатации.

Примечание - Логистика для эксплуатации является параллельной настройкой как рассматриваемой системы, так и обеспечивающих систем повсюду в период эксплуатации с тем, чтобы помочь гарантировать эффективное функционирование системы. Это также предусматривает шаги для гарантий того, что необходимый материал и ресурсы в необходимом количестве и качестве доступны в нужном месте и в нужное время,

3. осуществляйте упаковку, обработку, хранение и транспортировку, необходимые по жизненному циклу.

Примечание - Это включает упаковку, обработку, хранение и транспортировку для системы, системных элементов и необходимых замен системных элементов. При этом часто требуется поддерживать цели процессов комплексирования и передачи,

4. подтверждайте, что действия логистики удовлетворяют необходимым уровням пополнения запасов так, чтобы хранимые системные элементы отвечали нормам ремонта и запланированного регламентного обслуживания.

Примечание - Контролируйте качество и пригодность запчастей, их транспортировку и их целостность во время длительного хранения. По мере необходимости приобретайте, обучайте и аттестуйте персонал с тем, чтобы поддерживать число операторов и их профессионализм,

5. подтверждайте, что согласно действиям логистики требования к сопровождаемости системы планируются, поддерживаются ресурсами и являются реализуемыми.

Примечание - Действия логистики позволяют системе достичь эксплуатационной готовности. Эти действия предусматривают укомплектование персоналом, поддержку поставок, оборудование для поддержки, потребности в технических данных (руководствах, инструкциях, перечнях и т.д.), поддержку обучения, поддержку ресурсов оборудования и вычислительных ресурсов, а также основные средства;

d) управляйте результатами сопровождения и логистики.

Эта деятельность состоит из следующих задач:

1. регистрируйте результаты сопровождения и логистики и любые отклонения, с которыми сталкиваетесь.

Примечание - Это предусматривает отклонения из-за некорректностей в стратегии сопровождения, в обеспечивающих системах сопровождения, в выполнении сопровождения и логистики или в определении системы. Чтобы проанализировать данные для определения первопричины отклонения, обеспечивающих действий по корректировке или улучшениям или для записи изученных уроков, используются процессы оценки и контроля проекта,

2. регистрируйте эксплуатационные инциденты и проблемы и гарантируйте, что они разрешаются.

Примечание - Выполняемое разрешение проблем осуществляется с использованием процессов гарантий качества, оценки и контроля проекта. Любые фактические изменения к требованиям, архитектуре, проекту или системным элементам выполняются в пределах других технических процессов,

3. определяйте и регистрируйте тенденции в инцидентах, проблемах и действиях логистики и сопровождения.

Примечания

1 Это используется для сообщения персоналу, обеспечивающему функционирование и сопровождение, и информирования других проектов, которые создают или используют аналогичного рода системные сущности.

2 Отчетность по инцидентам и проблемам, включая предпринятые действия, прослеживается с помощью действий по управлению процессами и инцидентами, применяя процесс гарантий качества,

4. поддерживайте прослеживаемость элементов для сопровождения.

Примечание - В течение жизненного цикла поддерживается двунаправленная прослеживаемость между действиями по сопровождению и системными элементами и жизненным циклом артефактов,

5. поддерживайте основные информационные объекты, которые были выбраны для базовых линий.

Примечание - Чтобы установить и поддерживать объекты конфигурации и базовые линии, используется процесс управления конфигурацией. Этот процесс определяет варианты для базовой линии и затем обеспечивает информационные объекты. Примерами являются планы сопровождения и планы поддержки жизненного цикла,

6. контролируйте удовлетворенность заказчика с помощью поддержки системы и ее сопровождения.

Примечание - Данные об удовлетворенности заказчика используются в процессе управления качеством.

6.4.14 Процесс изъятия и списания

6.4.14.1 Цель

Цель процесса изъятия и списания — завершить существование системного элемента или системы для намеченного использования, обращаясь должным образом с замененными или списанными элементами и проявляя при этом должное внимание к определенным критическим потребностям (например, согласно соглашению, организационной политике или для соблюдения экологических или юридических норм, требований безопасности и защищенности).

Этот процесс прекращает функционирование, демонтирует и удаляет систему или любой из ее системных элементов из заданного использования. Это относится к любым ненужным продуктам с помощью направления их к завершающему условию и возвращения окружающей среды к ее исходному или приемлемому состоянию. Ненужные продукты могут оказаться не завершенными в части стадий их жизненного цикла, например, используемыми для того, чтобы во время изготовления не тратить напрасно материалы. Процесс изъятия и списания разрушает, хранит или исправляет систему, сущности и ненужные продукты экологически чистым способом в соответствии с законодательством, соглашениями, организационными ограничениями и требованиями заинтересованных сторон. Изъятие и списание предусматривают предотвращение возвращения в систему поставок продуктов с истекшим сроком годности, продуктов однократного использования или неадекватных элементов. Где это требуется и подлежит контролю, делаются отчеты в порядке поддержки здоровья операторов и пользователей и обеспечения безопасности окружающей среды. Если часть системы продолжает эксплуатацию в измененной форме, процесс изъятия и списания гарантирует надлежащее обращение с удаляемой частью.

Примечание - Процесс изъятия и списания предназначен к применению в жизненном цикле системы, включая изъятие и списание прототипов на стадиях замысла и разработки, удаления на стадии производства и списания элементов различных модификаций на стадиях применения и поддержки.

6.4.14.2 Выход (выходные результаты)

В результате успешной реализации процесса изъятия и списания:

a) ограничения для изъятия и списания предоставляются как входы к требованиям, архитектуре, проекту и реализации;

b) становятся доступными любые обеспечивающие системы или услуги, необходимые для изъятия и списания;

c) системные элементы или ненужные продукты разрушаются, сохраняются, повторно востребуются или перерабатываются в соответствии с требованиями безопасности и защищенности;

d) окружающая среда возвращается к ее изначальному или согласованному состоянию;

e) становятся доступными отчеты по действиям и анализу процесса изъятия и списания.

6.4.14.3 Действия и задачи

Относительно процессов изъятия и списания выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) готовьтесь к изъятию и списанию.

Эта деятельность состоит из следующих задач:

1. определяйте стратегию изъятия и списания для системы, включая каждый системный элемент и любые получающиеся ненужные продукты.

Примечание - Стратегия предусматривает графики выполнения работ, действия и ресурсы для того, чтобы:

i) завершить оказание услуг системой;

ii) преобразовать систему или сохранить ее в социально и физически приемлемом состоянии, избегая тем самым последующие отрицательные воздействия на заинтересованные стороны, общество и окружающую среду;

iii) принять во внимание аспекты здоровья, безопасности, защищенности и частной жизни, имеющие отношение к действиям по изъятию и списанию и долгосрочным условиям относительно получаемых физических материалов и информации;

iv) рассмотреть передачу системы для будущего использования в измененной или приспособленной форме, включая ее перемещение,

2. определяйте ограничения, способные появиться при изъятии и списании, для системных требований, характеристик архитектуры, свойств проекта или методов реализации системы.

Примечание - Ограничения предусматривают проблемы разборки, включая связанные с этим обеспечивающие системы, доступ к местам хранения и их пригодность, а также требуемые уровни профессионализма,

3. определяйте и планируйте действия относительно необходимых обеспечивающих систем или услуг, которые должны поддерживать списание.

Примечание - Сюда включается определение требований и взаимодействий для обеспечивающих систем,

4. получайте или приобретайте доступ к обеспечивающим системам или услугам, которые будут использоваться.

Примечание - Чтобы объективно подтвердить, что обеспечивающая система достигает своего намеченного использования в предоставлении функциональных возможностей, применяется процесс валидации,

5. определяйте основные средства, места хранения, инспекционные критерии и периоды хранения, если система должна быть сохранена,

6. определяйте упреждающие методы для предотвращения повторного применения в цепочках поставок тех элементов и материалов, которые не следует предлагать вновь, повторно востребовать или использовать;

b) выполняйте изъятие и списание.

Эта деятельность состоит из следующих задач:

1. завершайте функционирование системного элемента или системы, чтобы подготовить их к выведению из эксплуатации.

Примечание - Учитываются взаимодействия с другими системами (например, снабжения энергией или топливом), разъединение происходит в соответствии с инструкциями по разборке и соответствующими требованиями законодательства по охране здоровья, безопасности, защищенности и частной жизни. Если рассматриваемая система модифицируется при технологической или функциональной модернизации, то выводятся из эксплуатации только те системные элементы, которые влияют на модификацию. Это может относиться к прототипу рассматриваемой системы на стадиях замысла или разработки,

2. выводите из эксплуатации систему, системный элемент или материал для соответствующих размещений и действий.

Примечание - Размещение предусматривает повторное использование, переработку, ремонт, перестройку или разрушение. Размещение и последующие действия проводятся в соответствии с соответствующими требованиями по безопасности, защищенности, обеспечению частной жизни и экологическими стандартами, директивами и законами. Системные элементы, которые имеют срок годности в их текущих условиях или при последующей перестройке, передаются другим системам или организациям. Где приемлемо, системные элементы ремонтируются для продления срока их годности. Перераспределяйте, переустраивайте или увольняйте операторов. Если элемент не является повторно используемым или является неадекватным к сложившимся условиям, необходимо препятствовать тому, чтобы подобные элементы возвращались в цепочку поставок. Эта задача предусматривает изъятие ненужного материала от производства или других стадий,

3. выводите штат операторов из системы или системного элемента и регистрируйте соответствующие знания по эксплуатации.

Примечание - Это проводится согласно соответствующим требованиями по безопасности, защищенности, обеспечению частной жизни и экологическим стандартам, директивам и законам. Обеспечивайте охрану и защиту знаний и навыков операторов. Для этого обращайтесь к процессу управления знаниями,

4. разбирайте системный элемент или систему до уровня управляемых элементов с тем, чтобы облегчить их изъятие для повторного использования, переработки, ремонта, перестройки, архивирования или разрушения,

5. разбирайте системные элементы и их части, которые не предназначены для повторного использования, способом, который подтвердит, что они не возвращаются в цепочки поставок,

6. по мере необходимости проводите разрушение системных элементов таким образом, чтобы уменьшить затраты на выполнение работ или облегчить процесс изъятия.

Примечание - Эта деятельность предусматривает получение услуг в части разрушения, например, чтобы расплавить, сломать, сжечь или уничтожить систему или ее элементы по мере такой необходимости;

c) Завершайте изъятие и списание.

Эта деятельность состоит из следующих задач:

1. подтверждайте, что после изъятия и списания отсутствуют факторы, наносящие вред здоровью, безопасности, защищенности и экологии,

2. возвращайте окружающую среду к ее начальному состоянию или состоянию, которое определено в соответствии с соглашением,

3. архивируйте информацию, собранную за всю жизнь системы, чтобы разрешить аудиты и анализы в случаях долговременных опасностей здоровью, безопасности, защищенности и окружающей среде и позволить будущим создателям системы и пользователям строить знания, базирующиеся на накопленном опыте.

A.1 Введение

Данное приложение содержит требования для приспосабливания настоящего стандарта.

Примечания

1 Приспосабливание не является требованием для соответствия стандарту. Фактически, если должно быть обеспечено «полное соответствие», приспосабливание не допускается. Этот процесс применяется лишь тогда, когда декларируется «приспособленное соответствие».

2 Дополнительные материалы для приспосабливания смотри в руководстве по применению процессов жизненного цикла [45].

A.2 Процесс приспосабливания

A.2.1 Цели

Цель процесса приспосабливания — адаптировать процессы, описанные в настоящем стандарте, для соответствия специфическим обстоятельствам или факторам, которые:

a) окружают организацию, использующую настоящий стандарт в соглашении;

b) влияют на проект, который должен удовлетворять соглашению, содержащему ссылку на настоящий стандарт;

c) отражают потребности организации в порядке поставки продукции или услуг.

A.2.2 Выход (выходные результаты)

В результате успешной реализации процесса приспосабливания:

a) определяются измененные или новые процессы жизненного цикла для достижения целей и результатов в некоторой модели жизненного цикла.

A.2.3 Действия и задачи

Если настоящий стандарт приспосабливается, то относительно процесса приспосабливания в организации или проекте выполняйте следующие задачи в соответствии с применяемой организацией политикой и процедурами:

a) определяйте и регистрируйте обстоятельства, которые воздействуют на приспосабливание. Возможные воздействия предусматривают (но не ограничиваются этим):

1. стабильность и разнообразие в эксплуатационной среде,

2. риски, коммерческие или эксплуатационные для заинтересованных сторон,

3. новизну, масштабы и сложность,

4. начало и продолжительность эксплуатации,

5. проблемы целостности, такие как безопасность, защищенность, обеспечение частной жизни, практичность, пригодность,

6. появляющиеся возможности технологий,

7. профиль бюджета и доступные организационные ресурсы,

8. пригодность услуг от обеспечивающих систем,

9. роли, ответственности, подотчетность и полномочия в полном жизненном цикле системы,

10. потребность соответствия другим стандартам;

b) в случае проявления свойств, критичных для системы, уделяйте должное внимание структурам жизненного цикла, рекомендуемым или предписываемым стандартами, относящимся к критичности;

c) получите соответствующие входы от сторон, принимающих решения о приспосабливании. Это включает (но может быть не ограничено этим):

1. заинтересованные стороны системы,

2. заинтересованные стороны к соглашениям, осуществляемым организацией,

3. соответствующие организационные функции;

d) для достижения целей и результатов в выбранной модели жизненного цикла, принимайте решения по приспосабливанию в соответствии с процессом управления решениями.

Примечания

1 Организация устанавливает типовые модели жизненного цикла как часть процесса управления моделью жизненного цикла. Чтобы достичь целей и результатов на конкретных стадиях в устанавливаемой модели жизненного цикла, иногда для организации оказывается приемлемым приспосабливание процессов настоящего стандарта.

2 Проекты выбирают организационно устанавливаемую модель жизненного цикла для конкретного проекта как часть процесса планирования проекта. Чтобы достичь целей и результатов на конкретных стадиях в устанавливаемой модели жизненного цикла, иногда оказывается приемлемым организационно приспосабливать адаптируемые процессы.

3 В случаях, если проекты непосредственно применяют настоящий стандарт, иногда уместно приспосабливать процессы так, чтобы достичь целей и результатов на конкретных стадиях в подходящей модели жизненного цикла;

e) выбирайте процессы жизненного цикла, которые требуют приспосабливания и одновременно удаляют, как неприменяемые, отсеиваемые выходные результаты, действия или задачи.

Примечания

1 Независимо от приспосабливания, организации и проекты всегда разрешают реализовывать процессы, которые достигают дополнительных результатов или выполняют дополнительные действия и задачи, свыше требуемых для соответствия настоящему стандарту.

2 Некоторые организации или проекты иногда сталкиваются с ситуацией, когда есть желание изменить положения настоящего стандарта. В этом случае нужно избегать модификации из-за непредвиденных последствий для других процессов, результатов, действий или задач. Если необходимо, модификация выполняется путем удаления положения (делающего соответствующее требование как «приспособленное соответствие») и с внимательным учетом последствий от реализации процесса, который достигает дополнительных результатов, или выполняют дополнительные действия и задачи, вне таковых из приспособленного варианта стандарта.

B.1 Введение

Приведенная ниже таблица B.1 отражает возможное множество информационных объектов, которые могут быть связаны с каждым процессом.

Примечание - [10] содержит дополнительные сведения об информационных объектах.

C.1 Введение

Следует иметь в виду, что у некоторых пользователей настоящего стандарта может возникнуть желание оценить реализованные процессы в соответствии с ГОСТ Р ИСО/МЭК 15504-2-2009. Данное приложение содержит эталонную модель процесса, приемлемую для использования совместно с указанным стандартом.

Эталонная модель процесса составлена из процессов, описанных в настоящем стандарте, включая название, согласование цели и результатов для каждого процесса. В разделе C.3 определены процессы эталонной модели процесса и указан раздел, где приведено их описание.

C.2 Соответствие ГОСТ Р ИСО/МЭК 15504-2-2009

C.2.1 Общее

В 6.2 ГОСТ Р ИСО/МЭК 15504-2-2009 приведены требования к базовым моделям процесса, подходящим для оценки с помощью указанного стандарта. Ниже приведены требования для эталонных моделей процесса и описывается, как они применяются согласно настоящему стандарту. В каждом из последующих пунктов выделенный курсивом текст указывает на требование из ГОСТ Р ИСО/МЭК 15504-2-2009, а невыделенный текст описывает способ применения этого требования в настоящем стандарте.

C.2.2 Требования к эталонной модели процесса

Базовая модель процесса должна содержать:

a) декларацию области применения базовой модели процесса (см. раздел 1);

b) соответствующее требованиям 6.2.4 ГОСТ Р ИСО/МЭК 15504-2-2009 описание процессов в пределах области действия базовой модели. Это содержится в C.3 (приложение C);

c) описание взаимосвязей между базовой моделью процесса и предполагаемым контекстом ее использования. Это содержится в разделе 5;

d) описание взаимосвязей между процессами, определенными в базовой модели. Это предоставлено в C.3 (приложение C) в описании каждого процесса. Например, некоторые описания процесса включают утверждение, что процесс содержит процессы более низкого уровня.

В базовой модели процесса должны быть документированы сообщество по интересам данной модели и действия, предпринятые для достижения консенсуса в этом сообществе:

a) соответствующее сообщество по интересам должно быть охарактеризовано или специфицировано. Соответствующее сообщество по интересам представляют собой пользователи настоящего стандарта и [43];

b) степень достижения консенсуса должна быть документирована. Настоящий стандарт и [43] являются стандартами, удовлетворяющими требования консенсуса в ИСО/МЭК СТК 1;

c) если действия по достижению консенсуса не были предприняты, то должно быть документировано согласование о последствиях. (Неприменимо).

Определенные в базовой модели процессы должны иметь уникальные описания и идентификацию. Описания процесса уникальны. Определение представляется уникальными именами и нумерацией раздела этого приложения.

C.2.3 Описания процесса

Главными элементами базовой модели процесса являются описания процессов в области применения модели. Описания процессов в базовой модели включают в себя положение о назначении процесса, которое описывает на верхнем уровне общие цели совершения процесса, и совокупность выходов, которая демонстрирует успешное достижение назначения процесса. Эти описания процессов должны удовлетворять следующим требованиям:

a) процесс должен быть описан в терминах назначения и выходов;

b) в любом описании процесса совокупность выходов процесса должна быть необходимой и достаточной для достижения назначения процесса;

c) описания процессов должны быть такими, чтобы в них не были включены или предположены какие-либо элементы схемы измерения, описанной в разделе 5, выше уровня 1 (по ГОСТ Р ИСО/МЭК 15504-2-2009).

Положение о выходе (результатах) процесса описывает одно из следующего:

• продукт или артефакт;
• существенное изменение состояния;
• удовлетворение заданным ограничениям, например, требованиям, задачам и т.п.

Этим требованиям отвечают описания процесса, представленные в приложении C настоящего стандарта. Некоторые результаты могут быть интерпретированы как соответствующие возможностям, выше уровня 1. Однако реализация соответствия конкретных процессов не требует достижения более высоких уровней возможностей.

C.3 Эталонная модель процесса

Эталонная модель процесса формируется из положений цели и результатов для каждого из процессов, включенных в раздел 6. Эталонная модель процесса для жизненного цикла системы формируется из множества процессов, приведенных на рисунке 4.

D.1 Введение

Понятия непрерывного усовершенствования и оценки возможностей процесса гармонично установлены и признаны, а также стандартизованы в комплексе ГОСТ Р ИСО/МЭК 15504. Эталонные модели процесса, содержащиеся в настоящем стандарте (см. приложение C) и [43], предназначены для использования совместно с ГОСТ Р ИСО/МЭК 15504 при оценке возможностей процессов жизненного цикла. Определение возможностей процессов требует, чтобы описания процессов предусматривали ясное установление конкретной цели процесса и представление ожидаемых результатов. Содержательной реализации процессов помогают определенные положения по действиям, задачам и их выполнению. Таким образом, процессы жизненного цикла в обоих стандартах применяют общие конструкции процесса согласно D.2, что совместимо с руководством по определению процесса, содержащимся в ГОСТ Р 57098-2016.

D.2 Конструкции процесса и их использование

В настоящем стандарте описания процесса следуют определенным правилам. Они сгруппированы логическим способом. Такое группирование объясняется:

• логическими отношениями среди процессов;
• ответственностью за выполнение процессов.

Настоящий стандарт группирует действия, которые могут быть выполнены в течение жизненного цикла системы, в четыре группы процессов. Описание высшего уровня этих групп представлено в 5.6. Каждый процесс жизненного цикла в пределах этих групп описан в терминах его цели и желательных результатах. Перечисляются действия и задачи, которые должны быть выполнены для достижения этих результатов:

a) процессы соглашения — два процесса (см. 6.1);

b) процессы организационного обеспечения проекта — шесть процессов (см. 6.2);

c) процессы технического управления — восемь процессов (см. 6.3);

d) технические процессы — четырнадцать процессов (см. 6.4).

Последовательное применение правил описания процесса позволяет упорядоченно пронумеровать элементы раздела 6. В пределах настоящего стандарта подраздел, пронумерованный как 6.x, обозначает группу процесса, пункт 6.x.y обозначает процесс в пределах этой группы. Подпункты, пронумерованные как 6.x.y.1, описывают цель процесса, подпункты 6.x.y.2 — результаты процесса, а подпункты 6.x.y.3 — действия и задачи процесса.

Рисунок D.1 (приложение D) — это представление конструкций процесса, используемых в настоящем стандарте и [43], с помощью унифицированного языка моделирования (UML).

E.1 Введение

Имеют место случаи, когда лица, которые представляют специальный инженерный интерес, хотят видеть объединенным все множество действий процесса, которые непосредственно и напрямую относятся к их интересам. Для этой цели может быть разработано некоторое представление процесса с тем, чтобы организовать процессы, действия и задачи, отобранные из настоящего стандарта или [43], и обеспечить сосредоточение на специальном интересе способом, который пересекается со всеми или некоторыми частями жизненного цикла. Настоящее приложение содержит точку зрения на процесс, которая может быть использована для определения представления процесса.

E.2 Понятие представления процесса

Имеют место случаи, когда необходима ориентация на действиях и задачах, которые выбираются из несоответствующих процессов лишь с тем, чтобы обеспечить видимость существенному замыслу или тематике, которая пересекает процессы, прорабатываемые по жизненному циклу. Пользователям стандартов рекомендуется, каким образом определять эти действия для их использования, даже в том случае, если они не могут определить место отдельного процесса, имеющего отношение к их определенному интересу.

С этой целью было сформулировано понятие представления процесса. Аналогично понятию процесса, описание представления процесса предусматривает установление цели и результатов. В отличие от процесса описание представления процесса не включает действий и задач. Вместо этого описание включает руководство, объясняющее то, как результаты могут быть достигнуты, используя действия и задачи различных процессов согласно настоящему стандарту и [43]. Представления процесса могут быть построены с использованием точки зрения на процесс, образец которой представлен в E.3.

E.3 Точка зрения на процесс

Представление процесса соответствует точке зрения на процесс. Точка зрения на процесс, предоставленная здесь, может использоваться для создания представления процесса.

Точка зрения на процесс определяется:

• ее заинтересованными сторонами, а именно, пользователями стандарта;
• интересами, которые ее структурируют с использованием процессов, необходимых для отражения специального инженерного интереса.

В содержание получающихся представлений процесса следует включать:

• название представления процесса;
• цель представления процесса;
• результаты представления процесса;
• определение и описание процессов, действий и задач, которые реализуют представление процесса и ссылки на источники для этих процессов, действий и задач в других стандартах.

Примечания

1 Требования для документирования точек зрения представлено в ГОСТ Р 57100-2016 (см. 5.4). Настоящее описание — совместимо с указанными требованиями.

2 Примеры представления процесса описаны в ГОСТ Р 57098-2016.

F.1 Введение

Настоящее приложение содержит информацию, связанную с процессами определения архитектуры и определения проекта в настоящем стандарте.

Действия в части архитектуры и проекта в настоящем стандарте разделены на два процесса для отражения различных методов сообщества системной инженерии, относящихся к сложным системам. Например, в производственной линии архитектура может следовать различным проектам для разных систем. В этом случае важно выполнить указываемые два процесса (определения архитектуры и определения проекта) отдельными способами. Кроме того, архитектура часто создается по другим причинам, нежели основы для проектирования. Такими причинами могут быть, например, продвижение технологических инвестиций, приведение в порядок корпоративного портфеля проектов, руководство решением по заявке/без заявки и т.д.

Архитектура системы может быть представлена как ряд структурированных архитектурных сущностей и их отношений, таких, как функции, потоки, взаимодействия, объекты потока ресурсов, элементы информации/данных, физические компоненты, контейнеры, узлы, связи, коммуникационные ресурсы и т.д. Эти архитектурные сущности могут обладать характеристиками, такими как размерности, экологическая стойкость, пригодность, робастность, эффективность функционирования, эффективность по назначению и т.д.

F.2 Точки зрения, представления и модели архитектуры системы

Процесс определения архитектуры использует множество моделей, включая примеры моделей, перечисленные в следующем разделе (Традиционная практика системной инженерии классифицирует некоторые из этих моделей как «логические модели» или «физические модели», но таксономические различия не являются необходимыми для применения настоящего стандарта). Чтобы представить, как архитектура системы соотносится с интересами заинтересованных сторон, используется множество представлений. Представления составляются из моделей (см. ГОСТ Р 57100-2016 в части определений терминов архитектуры) и дополнительных деталей относительно понятий архитектуры и моделей.

F.3 Логические и физические модели

F.3.1 Функциональная модель

Функциональная модель архитектуры — это представление некоторого множества функций, которое определяет преобразования входов в выходы. Функции выполняются системой для достижения целей или выполнения своего назначения. Эти функции определяют, как система будет вести себя при использовании по назначению. Следовательно, каждая системная функция связана с взаимодействием системы и окружающей среды. Чтобы определить функции и потоки входов — выходов, обычно анализируются функциональные, эксплуатационные, нефункциональные требования и ограничения. Если функции связаны с системными элементами, то требуется реализация процесса определения проекта до такой степени, когда каждый системный элемент будет достаточно определен для его построения или закупки. Если намерения по системному элементу должны быть урегулированы позже, то в порядке достижения этой степени достаточности функции, связанные с этим системным элементом, также должны быть урегулированы позже и далее должным образом увязаны с подэлементами. Обычно существует много способов декомпозиции функций, способствующих определению различных вариантов архитектур.

F.3.2 Поведенческая модель

Поведенческая модель архитектуры — это соглашение по функциям и взаимодействиям (внутренним и внешним), которое определяет последовательное выполнение и параллельное, условия для поведенческого изменения и функционирования для удовлетворения эксплуатационных сценариев. Функции ограничивают диапазон доступного поведения. Поведенческая модель может быть описана как множество взаимосвязанных сценариев. Это включает определение поведенческих элементов в жизненном цикле (способы/состояния, передачи, вызывающие события, эксплуатационные сценарии и т.д.).

F.3.3 Временна́я модель

Временна́я модель архитектуры — это модель, которая представляет собой уровни частоты выполнения функций (стратегический или тактический уровень, уровень эксплуатационного контроля, уровень регулирования и т.д.), соответствующие уровням решений, которые обеспечивают людей и программы логикой контроля и управления функционированием системы. Это включает определение временны́х элементов (продолжительности, частоты, времени ответа, переключения, перерывы, условия останова и т.д.) из эксплуатационного замысла и системных требований.

F.3.4 Структурная модель

Структурная модель архитектуры системы представляет свои системные элементы и все необходимые физические взаимодействия между этими системными элементами, а также с внешними сущностями. Такая модель обеспечивает объединение или определение физических взаимодействий между системными элементами на уровне системной иерархии и между иерархическими уровнями, а также с внешними сущностями рассматриваемой системы (в окружающей среде/контексте).

F.3.5 Массовая модель

Массовая модель архитектуры представляет собой пространственное расположение физических объемов системных элементов или их частей в случае, если они распределены между собой в пространстве. Модель может осуществлять регистрацию ожидаемых или фактических массовых свойств, помочь определить массовые свойства, такие как центр тяжести и динамическое поведение в движении. Модель также используется для распределения полной массы системы по ее элементам.

F.3.6 Топологическая модель

Топологическая модель архитектуры представляет территориальное размещение системных элементов друг относительно друга. Например, в модели железных дорог топологическая модель — это диорама, содержащая масштабную композицию для управления поездами. Автомобильная топология описывает, где в транспортном средстве находятся двигатель и ведущие колеса.

F.3.7 Сетевая модель

Сетевая модель определяет расположение узлов и связей, что помогает понять, как ресурсы перетекают от одного узла к другому. Ресурсы в потоках сети могут быть представлены массой, энергией, данными, людьми и т.д. Сетевая модель может использоваться для того, чтобы определить пропускную способность, времена ожидания, объекты скопления и т.д. Иногда сетевая модель используется совместно со стеком протокола, чтобы понять, как слои в сети взаимодействуют по стекам вертикально вверх и вниз.

F.3.8 Учет других моделей

Интересы заинтересованных сторон в жизненном цикле, такие как, например, сопровождение, развитие, списание, потенциальные изменения окружающей среды или управление устареванием и нефункциональными требованиями, учитываются при определении архитектурных характеристик, таких, как модульность, относительная независимость, способность к обновлениям, адаптация к нескольким окружающим средам, уровень эффективности, надежности, робастности, масштабируемости или стойкости к условиям окружающей среды и т.д.

Другие необходимые модели могут включать некоторые из этих характеристик или другие критичные характеристики качества. Например, модель надежности может продвигать функциональный уровень анализа видов и последствий отказов (FMEA или FMECA), чтобы помочь вывести потенциальные архитектурные смягчения для минимизации эксплуатационных рисков (риска потерь вопреки назначению, риска нарушения безопасности или защищенности и др.), связанных с критическими интересами и функциями.

Определения понятий, в которых модели используются для определения архитектуры, могут быть основаны на экспертизе интересов заинтересованных сторон. Модели и получающиеся представления могут использоваться для выражения того, как архитектура обращается к их интересам, и для получения лучшего понимания их фактических потребностей, пожеланий и ожиданий.

G.1 Введение

Система систем (СС) является рассматриваемой системой, элементы которой представляют собой самостоятельные системы. СС использует интегрированное множество систем для решения таких задач, которые ни одна из составных систем не может выполнить самостоятельно. Каждая составляющая система имеет свои собственные руководство, цели и ресурсы, координируясь в пределах СС и адаптируясь для достижения целей СС. В контексте терминологии, описанной в 5.2.3 (как показано на рисунке 3), скомпонованное множество систем, включая оригинальную рассматриваемую систему, обеспечивающие системы и взаимодействующие системы вместе составляют СС. Там, где присутствуют интересы, затрагивающие скомпонованное множество, СС становится рассматриваемой системой, отвечающей некоторым целям бизнеса или назначения, или необходимой для понимания эмерджентных свойств от комбинации систем. Причем эти цели не могут быть достигнуты отдельными составляющими системами.

Настоящее приложение обращается к применению процессов жизненного цикла применительно к такому типу СС. Настоящее приложение описывает общие характеристики и типы СС, а также их использование в жизненном цикле.

G.2 Характеристики и типы системы систем (СС)

СС характеризуется организаторской и эксплуатационной независимостью составляющих систем, которые во многих случаях были разработаны и продолжают поддерживать первоначально определенных пользователей одновременно с пользователями СС. В других контекстах каждая составляющая система — это сама рассматриваемая система. Ее существование часто предшествует появлению СС, в то время как ее характеристики были первоначально спроектированы так, чтобы удовлетворить потребности их изначальных пользователей. В качестве элементов СС рассмотрение составляющих систем расширяется до такой степени, чтобы охватить возросшие потребности СС. Это подразумевает возрастание сложности, особенно когда составляющие системы продолжают развиваться независимо от СС. Составляющие системы обычно сохраняют свои изначальные заинтересованные стороны и механизмы управления, которые ограничивают альтернативы относительно потребностей СС.

СС были охарактеризованы четырьмя типами, основанными на отношениях управления между элементом системы и СС, показанными на рисунке G.1. Самые строгие отношения управления относятся к руководимой СС, где у соответствующей организации имеются полномочия над составляющими системами, несмотря на то, что элементы системы не были первоначально спроектированы для поддержки СС. Несколько менее строгий уровень управления предоставлен для познаваемой СС, где распределенные полномочия между составляющими системами и СС оказывают влияние на применение некоторых из процессов системной инженерии. В объединенной СС, которой недостает полномочий по всей СС, применение системной инженерии зависит от взаимосвязей между составляющими системами. Виртуальные СС в значительной степени самоорганизованы и часто намного больше ограничивают возможности для применения в СС методов системной инженерии.

Рисунок G.1 — Типы системы систем

Главной характеристикой СС являются неожиданные случаи, т.е. непредвиденные эффекты на уровне СС, отнесенные к сложной динамике взаимодействия составляющих систем. В СС составляющие системы преднамеренно рассматриваются в их комбинации с тем, чтобы получить и проанализировать результаты, не возможные к получению от единичных систем. Сложность составляющих систем и факт того, что они, возможно, были разработаны безотносительно к их роли в СС, может привести к новым, неожиданным поведениям. Определение и обращение к непредвиденным эмерджентным результатам — это особенная сложная проблема в инженерии СС.

G.3 Процессы системной инженерии, применяемые к системе систем

G.3.1 Общее

Вышеупомянутые характеристики СС имеют особенности при применении каждого из четырех типов относительно процессов жизненного цикла систем.

G3.2 Процесс соглашения

Процессы соглашения крайне важны для СС, поскольку они устанавливают способы управления при разработке и эксплуатации среди организаций, ответственных за СС и, нередко, за независимые составляющие системы. Составляющие системы, которые приобретаются и управляются различными организациями, часто имеют оригинальные цели, которые, возможно, не могут быть подчинены целям из СС. Исключая случай руководимой СС, организации, ответственные за СС, не могут решать задачи составляющей системы без сотрудничества с ней. В познаваемой или объединенной СС эти задачи сбалансированы в сравнении с задачами составляющей системы, фигурирующей в качестве рассматриваемой системы с ее собственными правами. Для виртуальной СС процессы соглашения могут оказаться неформальными или рассматриваться только в целях анализа.

G.3.3 Процессы организационного обеспечения проекта

В обычной рассматриваемой системе процессы организационного обеспечения проекта устанавливают окружающую среду, в которой осуществляются проекты. Организация устанавливает процессы и модели жизненного цикла, которые будут использоваться в проектах; устанавливает, перенаправляет или отменяет проекты; обеспечивает требуемыми ресурсами, включая человеческие и финансовые ресурсы; вводит и контролирует показатели качества для систем и других производств, которые разрабатываются в проектах для внутренних и внешних заказчиков (см. 6.2).

В СС владельцы составляющих систем обычно сохраняют ответственность за разработку своих систем, и у каждого из них имеются собственные процессы организационного обеспечения проекта. В зависимости от типа СС также применяют свои процессы организационного обеспечения проекта с учетом специфики СС — при планировании, анализе, организации и интеграции возможностей существующих и новых систем в возможности СС.

Следовательно, в СС эти процессы организационного обеспечения проекта реализуются на двух уровнях. Организации, ответственные за составляющие системы, реализуют эти процессы для собственных рассматриваемых систем независимо от СС. Организация, ответственная за СС (или в объединенных СС — задействованная по соглашению с СС), реализует эти процессы для СС так, чтобы учесть то, что относится к полной СС. Например, к процессу управления человеческими ресурсами для инженерии соответствующих систем обращается каждая организация, ответственная за составляющую систему. Организация, ответственная за СС, обращается только к этому аспекту для действий системной инженерии, применяемых через составляющие системы.

Особенно сложная проблема в инженерии СС — это отсутствие выравнивания (соответствия) среди процессов организационного обеспечения проекта, относящихся к составляющим системам, и тех же процессов относительно СС. Процессы для составляющих систем проектируются так, чтобы удовлетворить их собственные результаты и, возможно, не выравниваются с такими же процессами для СС. Например, процесс управления портфелем будет в ответственности составляющей системы в случаях, когда организация, отвечающая за составляющую систему, имеет полный контроль над составляющей системой и другими системами и проектами в ее портфеле, а организация, ответственная за СС, будет нуждаться в некотором своем подходе к управлению портфелем — в подходе, который признает такое положение дел.

В обычной рассматриваемой системе процессы технического управления сосредоточены на управлении ресурсами и активами, распределенными согласно управлению организациями, и на их использовании для выполнения соглашения, в которое организация или организации вступают. Процессы касаются управления проектами, в особенности, планирования в терминах стоимости, временной шкалы, достижений и проверки действий. Процессы призваны гарантировать то, что выполнение соответствует планам и критериям работы, определению и выбору корректирующих действий, которые восстанавливают отставание в продвижении и достижениях. Процессы используются для того, чтобы устанавливать и выполнять технические планы относительно проекта, управлять информацией с помощью технической команды, оценивать техническое продвижение в сравнении с планами относительно системных продуктов или услуг, управлять техническими задачами в направлении завершения и достижения цели в процессе принятия решений (см. 6.3).

Процессы технического управления также реализуемы на уровне СС и соответственно в составляющих системах. Процессы технического управления применяются со специфическим учетом системной инженерии для СС при планировании, анализе, организации и интеграции возможностей существующих и новых систем в возможности СС. Параллельно организации, ответственные за составляющие системы, сохраняют ответственность за системную инженерию и их собственные процессы технического управления.

Организация, ответственная за СС, обращается к процессам технического управления, поскольку они применяются через СС, в то время как аналогичные процессы независимо реализуются также в организациях, ответственных за составляющие системы. В управлении конфигурацией, например, составляющие системы управляют своими собственными конфигурациями, в то время как СС обращаются к управлению конфигурацией, когда это относится к соединению систем в СС. Управление риском осуществляется составляющей системой и основано на оценке риска, применимой к ее выходным результатам, в то время, как управление риском для СС смотрит на риски уже применительно к СС.

Процесс планирования проекта и процесс оценки и контроля проекта являются основными применительно ко всем методам управления (см. 6.3), а основная сложная проблема в инженерии СС — это нехватка управления со стороны организации, ответственной за СС, процессы для составляющих систем (особенно для познаваемых и объединенных СС). Ведомая ее собственными организационными требованиями, каждая из составляющих систем может в графиках разработки или модернизации отличаться от графиков выполнения работ относительно других составляющих систем. Организация, ответственная за СС, должна запланировать интегрированный жизненный цикл, который признает независимые изменения в составляющих системах в дополнение к начатым в СС изменениям в некотором жизненном цикле, в котором СС фигурирует как рассматриваемая система. Часто это влечет за собой определение устойчивых промежуточных форм, которые констатируют развитие СС с инкрементными возможностями, добавленными из составляющих систем.

G.3.5 Технические процессы

Технические процессы сосредоточены на технических действиях по всему жизненному циклу. Они преобразуют потребности заинтересованных сторон сначала в продукты и затем, применяя эти продукты, оказывают жизнеспособные услуги, когда и где это необходимо для достижения удовлетворенности заказчика. Технические процессы применяются на любом уровне в иерархии структуры системы (см. 6.4), чтобы создать и использовать систему, является ли это в форме модели или готового продукта.

Аналогично другим процессам, когда это относится к СС, технические процессы реализуются также и для СС, и для составляющих систем. В некоторых случаях реализация СС осуществляется посредством реализации процессов в составляющих системах, нежели для СС в целом.

Анализ бизнеса или назначения для СС рассматривается через полную окружающую среду бизнеса и назначения СС. Процессы анализа бизнеса или назначения для СС и составляющих систем будут в значительной степени разделены до той степени, до которой составляющая система разрабатывалась к функционированию в таком пространстве. Цель — определить лучшие средства для обеспечения желаемых возможностей.

Процесс определения потребностей и требований заинтересованных сторон будет сосредоточен на высшем уровне СС, но с учетом того, насколько несовместимые потребности заинтересованных сторон для отдельных систем могут привести к ограничениям на СС в целом.

Процесс определения системных требований для СС имеет тенденцию к применению на уровне, который должен удовлетворить потребности заинтересованных сторон и цели назначения. Причем так, чтобы будучи переведенным в системные требования для составляющих систем со стороны СС, рассматриваемой в качестве «заинтересованной стороны», для составляющих систем это были бы новые требования.

Архитектура для СС — это структура для организации и объединения возможностей соединенных существующих и новых систем в возможности СС, оставляя при этом архитектуры составляющих систем их организациям. Поскольку составляющие системы в СС обычно предшествуют самой СС, определение архитектуры СС часто начинается с ее де-факто архитектуры. Архитектурные альтернативы подлежат исследованию с тем, чтобы структурировать интересы заинтересованных сторон и удовлетворить высший уровень системных требований в СС, осознать конкретный эффект от новых требований для составляющих систем и приспособить архитектурные ограничения составляющих систем.

Процесс определения проекта содержит достаточные подробные данные и информацию, необходимые для обеспечения реализации СС. Процесс предусматривает сотрудничество с составляющими системами, осуществляющими свою собственную проектную деятельность, с тем, чтобы определить подход для обращения к требованиям СС с точки зрения их использования в своей системе. Для выполнения контролирующей роли имеет место ответственность организации, отвечающей за составляющую систему и ее реализацию, совместно с организацией, ответственной за СС.

Процессы комплексирования, верификации, передачи, валидации (аттестации) выполняются составляющими системами для изменений, которые эти системы реализуют для поддержки требований, произведенных со стороны СС. Эти процессы также применяются и к СС, когда модернизированные составляющие системы интегрируются в СС и функционирование СС подлежит верификации и валидации. Независимая и асинхронная природа составляющих систем в СС ставит сложные проблемы для эффективной реализации этих процессов, выполняемых в традиционной рассматриваемой системе. Может случиться так, что в эксплуатационной среде может быть выполнен только уровень СС. В этом случае следует учитывать превентивные показатели функционирования во избежание неблагоприятного поведения СС.

Наконец, процессы функционирования, сопровождения, изъятия и списания имеют тенденцию к реализации на уровне составляющих систем, учитывая их эксплуатационную независимость и управление. Для содействия этим процессам возможны взаимодействия на уровне СС.

Библиография

<1> Freely available on www.iso.org website.

<2> To be published.

<3> To be published.