ГОСТ Р 57102-2016/ISO/IEC TR 24748-2:2011. Национальный стандарт Российской Федерации. Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288

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

Утвержден и введен в действие Приказом Федерального агентства

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

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

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

Для самостоятельного использования каждый из стандартов ИСО/МЭК 12207 и ИСО/МЭК 15288 имели свои руководства по применению (ИСО/МЭК ТО 15271 и ИСО/МЭК ТО 19760 соответственно). Однако оба стандарта были переизданы в 2008 году после существенной доработки по согласованию их терминологии и структуры. Как следствие, два опубликованных руководства по применению более не относятся к соответствующим им стандартам и не могут отвечать в должной мере своему назначению.

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

Настоящий стандарт поддерживает использование ИСО/МЭК 15288 и заменяет ИСО/МЭК ТО 19760. В содержательной части настоящего стандарта и дополняющем его ИСО/МЭК 24748-3, заменяющем ИСО/МЭК ТО 15271, продолжается работа над указанными стандартами. У обоих стандартов терминология и структура в руководствах идентичны там, где это возможно, и содержание выстраивается в соответствии с содержанием ИСО/МЭК 15288 и ИСО/МЭК 12207. Следовательно, пользователям ИСО/МЭК 15288 и ИСО/МЭК 12207 будет полезно иметь документы, одновременно учитывающие все аспекты соответствующих продуктов или услуг на протяжении их жизненного цикла.

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

Настоящий стандарт является руководством для применения ИСО/МЭК 15288. Он применим к системе, жизненному циклу, процессу, организационным аспектам, проекту и понятиям адаптации, преимущественно путем ссылки на ИСО/МЭК 24748-1 и ИСО/МЭК 15288. Это служит руководством при применении ИСО/МЭК 15288 в зависимости от аспектов стратегии, планирования и применения в организациях и проектах.

В терминологии, структуре и содержании настоящий стандарт гармонизирован с ИСО/МЭК 24748-1 и ИСО/МЭК 24748-3.

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

В целях настоящего документа применены термины и определения, приведенные в ИСО/МЭК 12207, ИСО/МЭК 15288 и ИСО/МЭК 24748-1.

3 Обзор ИСО/МЭК 15288

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

ИСО/МЭК 15288 можно использовать самостоятельно или совместно с другими стандартами, такими как ИСО/МЭК 12207. Он предлагает эталонную модель, поддерживающую оценку возможностей процессов в соответствии с ИСО/МЭК 15504-2.

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

3.2 Структура ИСО/МЭК 15288

ИСО/МЭК 15288 содержит требования двух разделов:

• раздела 6, содержащего требования для жизненного цикла систем;
• приложения A, содержащего требования по приспособлению ИСО/МЭК 15288.

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

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

- приложение C дает описание конструкций процессов, используемых в ИСО/МЭК 15288;

• приложение D содержит пример процессного подхода в приложении к специализации «инженерия». Пример предназначен для иллюстрации того, как проект может интегрировать процессы, действия и задачи по ИСО/МЭК 15288 для достижения специфических характеристик программной продукции;
• приложение E описывает соответствие процессов по ИСО/МЭК 15288 и ИСО/МЭК 12207;
• приложение F оказывает поддержку пользователям IEEE и описывает связь ИСО/МЭК 15288 со стандартами IEEE.

Для понимания основных используемых понятий пользователям ИСО/МЭК 15288 следует руководствоваться разделом 5.

3.3 Контекст ИСО/МЭК 15288

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

Контекст ИСО/МЭК 15288 проиллюстрирован на рисунке 1.

Рисунок 1 — Контекст ИСО/МЭК 15288

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

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

- s₁ - концепция;

- s2 — разработка;

- s3 — производство;

- s4 — применение;

• s5 — поддержка;
• s6 — изъятие и списание.

Примечания

1 Стадии описаны в ИСО/МЭК 15288 (пункт 5.2.2), в ИСО/МЭК 24748-1 (раздел 4 и подраздел 3.2).

2 Управление продвижением от одной стадии к другой и инженерные действия, связанные с обеспечением соответствующих рабочих продуктов и информацией для принятия решений, описаны в ИСО/МЭК 24748-1 (раздел 5).

Для необходимой поддержки рассматриваемой системы в ее жизненном цикле применяется некоторое количество обеспечивающих систем. Каждая стадия жизненного цикла может потребовать одной или более обеспечивающих систем. Также могут оказаться необходимыми обеспечивающие системы, которые используются для рассматриваемой системы на стадиях применения, поддержки, изъятия и списания. Важно отметить, что у обеспечивающей системы есть свой собственный жизненный цикл. Если для этой системы применяется ИСО/МЭК 15288, тогда она становится рассматриваемой системой.

Примечания

1 Роль и использование обеспечивающих систем описаны в настоящем стандарте (4.7 и 5.4.3.5).

2 Соответствующий материал по обеспечивающим системам см. в ИСО/МЭК 15288 (пункт 5.1.4) и в ИСО/МЭК 24748-1 (пункт 3.1.5).

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

Примечания

1 Соответствующий материал по структуре системы см. в ИСО/МЭК 15288 (пункт 5.1.3) и в ИСО/МЭК 24748-1 (пункт 3.1.4).

2 Представления с точки зрения иерархии проекта даны в настоящем стандарте (4.6.4).

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

Примечания

1 Связанные проектные понятия описаны в настоящем стандарте (4.6).

2 Понятия жизненного цикла системы описаны в ИСО/МЭК 24748-1 (подраздел 3.2).

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

Примечание — Совпадение (пересечение) интересов описано в настоящем стандарте (см. 4.6.3).

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

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

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

Примечание — Это может быть выполнено путем адаптации жизненного цикла, как описано в ИСО/МЭК TR 24748-1 (разделы 6 и 7) или путем приспосабливания согласно описанию в ИСО/МЭК 15288 (приложение A).

3.4 Сравнение с предыдущими версиями ИСО/МЭК 15288

ИСО/МЭК 15288:2002		ИСО/МЭК 15288:2008
Пункт	Процесс	Пункт	Процесс	Изменения
5	Процессы жизненного цикла систем	6	Процессы жизненного цикла систем
5.1	Введение			Удалено
5.2	Процессы соглашения	6.1	Процессы соглашения	Нумерация
5.2.1	Введение	6.1	Процессы соглашения	Объединены в 6.1; удален отдельный пункт
5.2.2	Процесс приобретения	6.1.1	Процесс приобретения	Нумерация
5.2.3	Процесс поставки	6.1.2	Процесс поставки	Нумерация
5.3	Процессы предприятия	6.2	Процессы организационного обеспечения	Тема и название пересмотрены; нумерация
5.3.1	Введение	6.2	Процессы организационного обеспечения	Объединены в 6.2; удален отдельный пункт
5.3.2	Процесс управления средой предприятия	6.2.2	Процесс управления инфраструктурой	Тема и название пересмотрены; нумерация
5.3.3	Процесс управления инвестициями	6.2.3	Процесс управления портфелем	Тема и название пересмотрены; нумерация
5.3.4	Процесс управления процессами жизненного цикла системы	6.2.1	Процесс управления моделью жизненного цикла	Название пересмотрено; нумерация
5.3.5	Процесс управления ресурсами	6.2.2	Процесс управления инфраструктурой	Человеческие ресурсы отделены от других ресурсов; нумерация
		6.2.4	Процесс управления человеческими ресурсами
5.3.6	Процесс управления качеством	6.2.5	Процесс управления качеством	Нумерация
5.4	Процессы проекта	6.3	Процессы проекта	Нумерация
5.4.1	Введение	6.3	Процессы проекта	Объединены в 6.3; удален отдельный пункт
5.4.2	Процесс планирования проекта	6.3.1	Процесс планирования проекта	Нумерация
5.4.3	Процесс оценки проекта	6.3.2	Процесс оценки и контроля проекта	Процессы объединены; нумерация
5.4.4	Процесс контроля проекта
5.4.5	Процесс принятия решений	6.3.3	Процесс управления решениями	Нумерация
5.4.6	Процесс управления рисками	6.3.4	Процесс управления рисками	Нумерация
5.4.7	Процесс управления конфигурацией	6.3.5	Процесс управления конфигурацией	Нумерация
5.4.8	Процесс управления информацией	6.3.6	Процесс управления информацией	Нумерация
		6.3.7	Процесс измерений	Добавлено
5.5	Технические процессы	6.4	Технические процессы	Нумерация
5.5.1	Введение	6.4	Технические процессы	Объединены в 6.4; удален отдельный пункт
5.5.2	Процесс определения требований заинтересованных сторон (требований правообладателей)	6.4.1	Процесс определения требований заинтересованных сторон (требований правообладателей)	Нумерация
5.5.3	Процесс анализа требований	6.4.2	Процесс анализа требований	Нумерация
5.5.4	Процесс проектирования архитектуры	6.4.3	Процесс проектирования архитектуры	Нумерация
5.5.5	Процесс реализации элементов системы	6.4.4	Процесс реализации элементов системы	Нумерация
5.5.6	Процесс комплексирования	6.4.5	Процесс комплексирования	Нумерация
5.5.7	Процесс верификации	6.4.6	Процесс верификации	Нумерация
5.5.8	Процесс передачи	6.4.7	Процесс передачи	Нумерация
5.5.9	Процесс валидации (аттестации)	6.4.8	Процесс валидации (аттестации)	Нумерация
5.5.10	Процесс функционирования	6.4.9	Процесс функционирования	Нумерация
5.5.11	Процесс обслуживания (сопровождения)	6.4.10	Процесс обслуживания (сопровождения)	Нумерация
5.5.12	Процесс изъятия и списания	6.4.11	Процесс изъятия и списания	Нумерация
Annex A	Процесс адаптации	Приложение A	Процесс приспосабливания	Название пересмотрено

Рисунок 2 — Отображение множества процессов по разделам между старой и новой версиями ИСО/МЭК 15288

4 Понятия применения

4.1 Обзор

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

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

4.2 Понятия системы

Применение ИСО/МЭК 15288 предполагает осознание основных понятий системы. Для систем, являющихся комбинацией продуктов и услуг, понятия системы представлены в ИСО/МЭК 15288 (подраздел 5.1). Дополнительное изложение — в ИСО/МЭК 24748-1 (подраздел 3.2).

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

Применение ИСО/МЭК 15288 предполагает осознание основных понятий жизненного цикла.

Примечание — Понятия жизненного цикла содержатся в ИСО/МЭК 15288 (подраздел 5.2). Дополнительное изложение находится в ИСО/МЭК 24748-1 (подраздел 3.2).

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

4.4.1 Общее

4.4.1.1 Введение

Применение ИСО/МЭК 15288 предполагает осознание основных понятий процесса.

Примечание — Понятия процесса введены в ИСО/МЭК 15288 (подраздел 5.3). Дополнительное изложение находится в ИСО/МЭК 24748-1 (подраздел 3.3).

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

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

Задача выражается в форме требования, самодекларации, рекомендации или приемлемого действия. С этой целью в ИСО/МЭК 15288 (подраздел 2.3, примечание 3) использованы определенные вспомогательные глаголы, чтобы подчеркивать различия между формами задач:

- требования ИСО/МЭК 15288 выражаются с использованием глагола «должен»;

- рекомендации — глаголом «следует»;

- разрешения — глаголом «может».

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

Примечания

1 Понятия процесса введены в ИСО/МЭК 15288 (подраздел 5.3), ИСО/МЭК 12207 (пункты 5.1.9 и 5.1.10) и ИСО/МЭК 24748-1 (подраздел 3.3).

2 Критерии для процессов изложены в ИСО/МЭК 12207 (пункт 5.1.8), а декомпозиция процессов в ИСО/МЭК 15288 (пункт 5.1.11) не содержит этих материалов.

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

Рисунок 3 — Пример входов и выходов процесса

4.4.1.2 Входы

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

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

b) данные, такие как измерения и отчеты по испытаниям;

c) материалы, которые или реализованы в выходных результатах, или использованы в производстве выходных результатов;

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

4.4.1.3 Выходы

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

4.4.1.4 Управление

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

a) проектное соглашение;

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

c) применимые стадию или стадии жизненного цикла системы;

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

4.4.1.5 Обеспечивающие механизмы

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

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

b) другие ресурсы, востребованные процессом, такие как услуги, оборудование и фонды;

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

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

4.4.2 Принципы процесса

4.4.2.1 Введение

ИСО/МЭК 15288 устанавливает архитектуру высшего уровня для жизненного цикла систем от замысла до изъятия и списания. Архитектура построена с множеством процессов и взаимосвязей в среде этих процессов. Процессы основаны на двух изначальных принципах: модульности и ответственности.

4.4.2.2 Модульность

Процессы являются модульными. В рамках модульности процессы:

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

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

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

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

b) каждый процесс привязан к архитектуре;

c) если процесс A привлечен процессом B и только B, то A принадлежит B;

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

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

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

4.4.2.3 Ответственность

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

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

Примечания

1 ИСО/МЭК 24748-1 (пункт 3.3.2) содержит дополнительную информацию об ответственности в процессах.

2 Организации и стороны представлены в подразделе 4.6.

4.4.3 Категории процесса по ИСО/МЭК 15288

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

Рисунок 4 — Роль процессов ИСО/МЭК 15288

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

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

Рисунок 5 — Использование процессов соглашения

4.4.4 Рекурсивное/итеративное применение процессов

4.4.4.1 Общее

Две формы применения процессов являются существенными и полезными для выполнения требований ИСО/МЭК 15288 — это рекурсивное и итеративное применения.

4.4.4.2 Рекурсивное применение процессов

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

Рисунок 6 — Рекурсивное применение процессов

4.4.4.3 Итеративное применение процессов

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

Рисунок 7 — Итеративное применение процессов

4.4.4.4 Методы и инструментарии

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

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

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

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

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

d) следует учитывать обеспечивающие системы, а также администрирование.

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

4.5.1 Общее

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

Определенная часть организации (даже такая малая, как единственный сотрудник) или определенная группа организаций могут быть расценены как организация, если она несет ответственность, наделена полномочиями и у нее установлены определенные отношения. В ИСО/МЭК 15288 термины «организация» и «сторона» тесно связаны. Когда организация в целом или какая-то ее часть заключает контракт, она выступает его стороной. Если организации являются отдельными органами, то стороны могут быть представителями той же самой организации или отдельных организаций.

Примечание — Организации и стороны представлены в ИСО/МЭК 12207 (пункт 5.1.3). Применение организационного и проектного уровней рассмотрено в ИСО/МЭК 12207 (пункт 5.1.4).

4.5.2 Ответственность

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

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

Организация (или сторона) получает свое определение из процесса, который она в настоящее время осуществляет. Например, ее называют приобретающей стороной, когда она выполняет процесс приобретения. В ИСО/МЭК 15288 стороны соглашения называют приобретающей стороной и поставщиком.

Термины, используемые ИСО/МЭК 15288, не имеют своего изначального смыслового значения. Но, обращаясь к организации или стороне, ответственной за выполнение процесса, рекомендуются следующие названия: «приобретающая сторона», «поставщик», «конструктор» («исполнитель», «разработчик»), «сопровождающая сторона», «оператор».

Процессы и организации (или стороны) связаны только функционально. ИСО/МЭК 15288 не навязывает, а лишь подразумевает структуру для организации (или стороны).

Примечание — ИСО/МЭК 24748-1 (пункт 3.3.2) содержит дополнительную информацию об ответственности за процесс в организациях.

4.5.3 Организационные отношения

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

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

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

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

d) обеспечение инфраструктурной поддержки;

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

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

4.5.4 Организационная структура проекта

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

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

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

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

4.6.1 Общее

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

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

Примечания

1 ИСО/МЭК 24748-1 (пункт 3.1.4) предоставляет детализацию относительно структуры в системах и проектах.

2 ИСО/МЭК 24748-1 (пункт 3.1.5) предоставляет детализацию относительно обеспечивающих систем.

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

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

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

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

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

4.6.2 Проектные отношения

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

Рисунок 8 — Роли соглашения

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

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

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

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

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

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

5. ответственность при верификации и валидации (аттестации),

6. условия приемки и инструкции по передаче (например, для упаковки, обращения, поставки и инсталляции),

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

Примечание — Возможная модель отражена в 5.4.2 для применения процессов ИСО/МЭК 15288 и достижения соглашения.

4.6.3 Отношения с обеспечивающими системами

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

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

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

Рисунок 9 — Совпадение интересов в проекте в определенный период времени

4.6.4 Иерархия проекта

Для иерархического представления проекта основные отношения на рисунке 9, иллюстрирующие период совпадения интересов в проекте, могут быть объединены с иерархическим представлением системной структуры, проиллюстрированным на рисунке 2 ИСО/МЭК 24748-1, и структуры рассматриваемой системы на рисунке 3 ИСО/МЭК 24748-1. Систему, за которую проект ответственен, в настоящем стандарте называют рассматриваемой системой. Каждый подчиненный проект или подпроект рассмотрен как проект сам по себе. Тогда может быть сформирована результирующая иерархия проектов. Эта иерархия проиллюстрирована на рисунке 4 ИСО/МЭК 24748-1 и изображена более детально на рисунке 10.

Рисунок 10 — Иерархия проектов

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

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

4.7 Понятия адаптации

4.7.1 Общее

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

Примечания

1 Понятия процесса приспосабливания (удаления соответствующих материалов) введены в ИСО/МЭК 15288 (пункт 5.3.4) с дальнейшими пояснениями в приложении A.

2 ИСО/МЭК 24748-1 (раздел 6) содержит дополнительную информацию по адаптации модели жизненного цикла (приспосабливанию или добавлению материалов), а по адаптации процессов — в пункте 9.4.3.

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

Примечание — Требования ИСО/МЭК 15288 изложены в разделе 6 и приложении A.

Подтверждение соответствия ИСО/МЭК 15288 возможно следующими способами:

a) как условие своей деятельности организация объявляет публично множество процессов, действий и задач ИСО/МЭК 15288, которым поставщики организации должны соответствовать;

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

Примечание — Соответствия стандарту отражены в ИСО/МЭК 15288 (раздел 2).

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

4.7.2 Адаптация

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

a) выбор процессов: требования соответствия ИСО/МЭК 15288 формируются для декларируемого множества процессов. Ни организация, ни конкретный проект не обязаны использовать каждый из процессов. Они могут выбрать процессы, относящиеся к их потребностям, и объявить это подмножество как основание для соответствия;

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

c) использование результатов: согласно разделу соответствия ИСО/МЭК 15288, «соответствие достигается путем демонстрации того, что все требования заявленного множества процессов были удовлетворены, что подтверждается путем использования полученных результатов». Факт того, что полученные результаты использованы как свидетельства соответствия, обеспечивает тот альтернативный выбор действий и задач, которые могут быть выполнены, если достигаются полученные результаты заявленного множества процессов;

d) использование примечаний: ИСО/МЭК 15288 использует примечания или другие формы руководства по обеспечению, которые не требуются для соответствия и не являются нормативными требованиями. Выполнение выбранных примечаний будет приемлемым в специальных ситуациях;

e) приспосабливание процессов: разрешено приспосабливание процессов. Приспосабливание определено как удаление отобранных результатов, действий или задач.

4.7.3 Адаптация жизненного цикла

Адаптация жизненного цикла подробно изложена в разделе 6 ИСО/МЭК 24748-1.

4.7.4 Адаптация для областей применения, дисциплин и специализаций

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

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

Примечание — Использование модели жизненного цикла и адаптация к областям, дисциплинам и специализациям отражено в разделе 7 ИСО/МЭК 24748-1.

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

Приспосабливание не является требованием соответствия ИСО/МЭК 15288. Приспосабливание не разрешается, если имеет место требование «полного соответствия». Если сформулировано требование «приспособленного соответствия», то приспосабливание должно быть выполнено так, как предписано в ИСО/МЭК 15288.

Примечания

1 Приспосабливание представлено в ИСО/МЭК 15288 (подраздел 2.3).

2 ИСО/МЭК 15288 (приложение A) описывает приспосабливание и определяет основные виды деятельности, выполняемые при приспосабливании ИСО/МЭК 15288.

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

5 Применение ИСО/МЭК 15288

5.1 Обзор

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

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

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

5.2 Стратегия применения

5.2.1 Обзор

ИСО/МЭК 15288 может быть применен по различным причинам:

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

Безотносительно причин для применения ИСО/МЭК 15288 в предлагаемой стратегии применения рекомендовано предусматривать следующие действия:

a) планирование применения;

b) если приемлемо, адаптация ИСО/МЭК 15288;

c) руководство пилотным(и) проектом(ами);

d) формализация подхода;

e) утверждение подхода.

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

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

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

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

b) потребности в подготовке кадров;

c) изменения ответственности, включая потребность в новых соглашениях;

d) воздействия на инструментарии и базы данных;

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

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

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

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

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

a) планирование применения;

b) если приемлемо, адаптация ИСО/МЭК 15288 (с учетом степени риска работы);

c) руководство проектом(ами).

5.2.2 Планирование применения

Применение ИСО/МЭК 15288 следует рассматривать как определенный проект с соответствующим планированием.

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

a) определение области проекта. Возможные варианты включают:

• одиночный проект — или внутренний для организации, или как часть двухстороннего контракта,
• сосредоточение на некоторых основных процессах или даже на единственном процессе, где ожидается некоторая польза для организации. Этот подход можно использовать, если ранее были обнаружены слабости, поэтому следует ориентироваться на полное применение ИСО/МЭК 15288 с определенного момента в будущем,
• адаптацию ИСО/МЭК 15288 через диапазон проектов, возможно, с постадийным введением. В этом случае организация, предположительно, не имеет или может насчитывать малое количество определенных процессов и тогда следует ориентироваться на стандартизацию на основе ИСО/МЭК 15288,
• адаптацию ИСО/МЭК 15288 через все проекты и в пределах всех частей организации. Маловероятно, что любая организация, кроме очень малых, примет этот подход. Это может быть использовано для нового филиала существующей организации, которая ранее положила ИСО/МЭК 15288 в основу практики своей работы;

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

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

d) определение ресурсов, доступных для применения по ИСО/МЭК 15288, таких как время, деньги, люди и оборудование;

e) создание и документирование планов управления проектом для применения ИСО/МЭК 15288.

5.2.3 Руководство пилотным(и) проектом(ами)

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

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

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

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

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

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

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

5.2.4 Формализация подхода

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

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

5.2.5 Утверждение подхода

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

5.3 Применение в организациях

5.3.1 Обзор

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

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

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

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

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

Рисунок 11 — Отношения с существующими документами

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

5.3.2 Рассмотрение и методики

5.3.3 Прикладные возможности

Причины для применения ИСО/МЭК 15288 в пределах организации (внутри организации) могут включать такие ситуации, как:

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

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

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

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

5.3.4 Обязательство управления

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

5.3.5 Использование ИСО/МЭК 15288 в пределах организации

Возможны три варианта основного использования ИСО/МЭК 15288 в пределах организации. Эти использования проиллюстрированы на рисунке 12 и описаны ниже.

Рисунок 12 — Три типа использования 15288

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

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

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

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

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

5.4 Применение к проектам

5.4.1 Обзор

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

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

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

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

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

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

5.4.2 Применение процессов соглашения на проект

5.4.2.1 Применение процесса приобретения

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

Рисунок 13 — Применение процесса к форме формального соглашения

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

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

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

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

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

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

a) требования к системе и услуге;

b) ожидаемые поставки;

c) разработка плана-графика и прохождение контрольных точек;

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

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

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

5.4.2.2 Применение процесса поставки

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

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

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

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

5.4.3 Применение технических процессов к проекту

5.4.3.1 Общее

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

Рисунок 15 — Применение технических процессов к инженерии рассматриваемой системы

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

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

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

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

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

Каждый процесс этой модели описан ниже. Дополнительные примечания, призванные помочь использованию этих процессов, приведены в приложении A.

5.4.3.2 Соответствующие технические процессы для определения системы

5.4.3.2.1 Общее

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

5.4.3.2.2 Процесс определения требований заинтересованных сторон (требований правообладателей)

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

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

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

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

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

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

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

5.4.3.2.3 Процесс анализа требований

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

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

5.4.3.2.4 Процесс проектирования архитектуры

5.4.3.2.4.1 Общее

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

5.4.3.2.4.2 Логическое определение архитектуры

Вначале следует преобразовать множество технических требований в более детализированное множество таких технических требований, которые получаются с помощью ряда логических моделей архитектурного проектирования [ИСО/МЭК 15288, подпункт 6.4.3.3 a)]. Это может быть достигнуто выполнением задачи логического проектирования из процесса проектирования архитектуры путем разделения на части и формирования взаимодействий. Логические модели архитектурного проектирования могут проявляться в одной или нескольких формах, как это описано ниже:

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

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

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

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

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

f) диаграмма контроля, которая указывает контролируемые факторы функции и результирующего функционирования;

g) системные состояния и режимы;

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

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

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

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

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

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

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

5.4.3.2.4.3 Физическое проектирование архитектуры

5.4.3.2.4.3.1 Общее

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

5.4.3.2.4.3.2 Результаты физического проектирования архитектуры

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

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

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

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

5.4.3.2.4.3.3 Прослеживаемость физических результатов проектирования архитектуры

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

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

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

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

5.4.3.2.4.4 Определение структуры системы

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

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

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

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

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

5.4.3.3 Соответствующие технические процессы для реализации системы

5.4.3.3.1 Общее

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

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

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

5.4.3.3.2 Процесс реализации

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

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

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

5.4.3.3.4 Процесс верификации

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

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

a) экспертиза (например, экспертиза чертежей);

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

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

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

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

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

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

5.4.3.3.5 Процесс передачи

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

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

5.4.3.3.6 Процесс аттестации (валидации)

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

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

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

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

Для того чтобы выполнить процесс аттестации, существует несколько подходов, таких как:

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

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

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

d) как определено в соглашении.

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

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

5.4.3.4 Соответствующие технические процессы для использования системы

5.4.3.4.1 Общее

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

5.4.3.4.2 Процесс функционирования

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

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

5.4.3.4.3 Процесс обслуживания (сопровождения)

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

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

5.4.3.4.4 Процесс изъятия и списания

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

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

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

Примеры:

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

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

5.4.3.5 Определение и реализация обеспечивающей системы

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

Нижеследующие положения поясняют примеры применения рисунка 16 к пригодности оборудования и инструментариев, необходимых для реализации системного элемента или для интеграции системных элементов низшего уровня либо систем. Если такое оборудование и инструментарии уже существуют, процессы, показанные на рисунке 15, не должны использоваться. Вместо этого в качестве приемлемых следует приобретать или намечать к применению существующие обеспечивающие системы. Однако если оборудование или инструментарии должны разрабатываться, то процессы, показанные на рисунке 15, следует использовать способом, описанным в 5.5.5.2 и 5.5.5.3. Требования приобретающей стороны для каждой обеспечивающей системы вытекают из требований, сформулированных во время применения процесса определения требований правообладателей, процесса анализа требований и процесса проектирования архитектуры применительно к системе, которая должна быть реализована. Такие требования могут включать допустимые пределы приемлемости, типы материалов и их обработки, такие как обрезка, размалывание и штамповка. Дополнительно замысел функционирования (или стратегию) для реализации следует делать доступным так же, как и любые ограничения в реализации, чтобы подключать специальные методы, планируемые к использованию. На рисунке 16 предлагается вариант, когда у обеспечивающей системы, определенной и реализованной как рассматриваемая система, использующая процессы, показанные на рисунке 15, также было бы собственное множество обеспечивающих систем для оказания соответствующей поддержки жизненного цикла.

Рисунок 16 — Реализация обеспечивающих систем

5.4.4 Применение процессов в модели жизненного цикла

5.4.4.1 Обзор

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

Для того чтобы определить, какие процессы выбрать и применять на какой-то стадии жизненного цикла системы, руководитель руководствуется целью и результатами для каждой из стадий (ИСО/МЭК 24748-1, раздел 4). Выбор соответствующих процессов позволяет развивать систему через управление ее жизненным циклом. Модель жизненного цикла системы на рисунке 17 можно рассматривать как иллюстрацию упорядоченного прохождения, связанного с системой, развивающейся от одной стадии жизни к другой. И организационные, и инженерные представления на рисунке 17 могут быть полезными в обеспечении возможности этого прохождения.

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

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

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

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

5.4.4.2 Организационное представление

5.4.4.2.1 Подходы

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

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

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

b) следует ли внедрять новую системную технологию (с изменением функционирования);

c) следует ли вывести систему из эксплуатации.

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

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

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

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

c) одобрять ли предложение, отвечая на запрос.

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

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

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

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

Выбор, реализация и использование организацией одного из этих подходов зависят от нескольких факторов, таких как:

d) технологические возможности;

e) потребность в различных возможностях системы в различное время;

f) готовность (доступность) ресурсов.

5.4.4.2.2 Последовательный подход

5.4.4.2.2.1 Общее

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

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

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

5.4.4.2.2.2 Применяемые системы

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

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

5.4.4.2.2.3 Риски

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

a) за долгие годы реализации возможно изменение требований, связанных с системой;

b) уход квалифицированных работников;

c) смена руководства;

d) смена персонала заказчика в организации приобретающей стороны;

e) смена поставщиков системных элементов и связанных услуг или изменение технологий;

f) могут иметь место технические риски;

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

5.4.4.2.2.4 Возможности

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

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

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

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

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

5.4.4.2.3 Инкрементный подход

5.4.4.2.3.1 Общее

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

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

Применение ИСО/МЭК 15288, как это проиллюстрировано на рисунках 13, 15 и 16, выполняется для реализации каждой версии. Функционирование и поддержка каждой версии осуществляются параллельно с реализацией, эксплуатацией и поддержкой последовательных версий. Ранние версии системы, а также их поддержка могут быть постепенно сокращены, поскольку усовершенствованные версии приобретаются и используются клиентской базой или к ранним версиям применима модификация определенного блока, а также могут быть включены новые возможности из поздней версии.

5.4.4.2.3.2 Применяемые системы

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

5.4.4.2.3.3 Риски

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

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

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

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

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

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

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

g) заказчик может изменить требования в процессе разработки версий.

5.4.4.2.3.4 Возможности

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

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

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

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

5.4.4.2.4 Эволюционный подход

5.4.4.2.4.1 Общее

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

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

ИСО/МЭК 15288, как проиллюстрировано на рисунках 13, 15 и 17, применим для реализации каждой версии. В этом случае реализация новых версий может быть последовательной или параллельной с частичным перекрыванием. Как с версиями, разработанными с использованием инкрементного подхода, различные версии могут быть управляемы и поддерживаемы параллельно. При этом особое внимание должно быть уделено сопровождению управления конфигурацией каждой версии так, чтобы функционирование, обучение и процедуры поддержки были приемлемыми для используемой версии.

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

5.4.4.2.4.2 Применяемые системы

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

5.4.4.2.4.3 Риски

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

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

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

c) может иметь место неясность, связанная с определением будущих требований;

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

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

f) неприемлемость раннего использования прототипа продукта в производстве.

5.4.4.2.4.4 Возможности

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

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

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

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

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

e) использование преимуществ появляющихся технологий.

5.4.4.3 Инженерное представление

5.4.4.3.1 Общее

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

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

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

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

Рисунок 18 — V-модель в инженерии

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

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

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

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

V-модель инженерии используется на каждой из стадий жизненного цикла системы как приемлемая для определения входов стадии или выходных критериев либо удовлетворения контрольной точке организационного представления или требованиям прохождения решения. Такое использование проиллюстрировано на рисунке 19 путем замены «инженерных действий» идентифицированных блоков, приведенных на рисунке 17, V-моделью на рисунке 18. Есть точки вдоль жизненного цикла системы, когда все функции уже определены и могут быть охвачены в управляемом множестве конфигурационных документов, которые часто называют функциональной базовой линией. Подобная точка возникает, когда все функции размещены по аппаратным и программным средствам, процессам, процедурам, услугам, людям или естественно происходящим сущностям (объектам) и может быть осуществлено аналогичное размещение базовой линии. В то же время могут быть установлены другие такие базовые линии. Обычно далее делается лишь третья базовая линия, причем после того, как сделана первая продукционная инсталляция системы. Это называют базовой линией продукции, где продукция может в одинаковой степени относиться и к услуге согласно определению системы по ИСО/МЭК 15288.

Рисунок 19 — Инженерное представление с V-моделью

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

5.4.4.3.2 Технические анализы

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

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

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

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

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

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

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

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

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

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

5. риски идентифицированы и планы реакции на них выполнимы и обоснованы как эффективные;

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

1. спецификации и чертежи определены как приемлемые для понимания решения проекта соответственно через реализацию или комплексирование,

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

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

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

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

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

5.4.4.3.3 Аудиты конфигурации

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

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

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

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

Целями физического аудита являются:

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

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

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

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

5. при необходимости: основание для утверждения дальнейшего производства системы.

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

ПРИМЕЧАНИЯ ДЛЯ ПРИМЕНЕНИЯ ПРОЦЕССОВ ИСО/МЭК 15288

A.1 Общее

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

В ИСО/МЭК 15288 выделены два существенных элемента каждого процесса — это цель и множество выходных результатов. Формулировка цели обеспечивает полное обоснование рациональности использования процесса. Выходы (выходные результаты) — это ожидаемые обозримые результаты выполнения действий процесса. Получаемые выходные результаты каждого процесса по ИСО/МЭК 15288 обеспечивают выгоду, которая мотивирует выбор и выполнение того или иного процесса. Нижеследующие примечания предназначены для помощи в применении действий процессов для получения результатов. Перекрестная ссылка с одним или более объектами, приведенными в ИСО/МЭК 15288, помогает при использовании стандарта.

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

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

Таблица A.1

Положения	ИСО/МЭК 15288
a) Чтобы должным образом выполнить действия и задачи процесса приобретения, следует, если это допустимо, реализовать соответствующим образом применяемые процессы организационного обеспечения проекта, процессы проекта и технические процессы	6.1.1.3 6.2, 6.3, 6.4
b) Обычно в любой ситуации приобретения есть несколько подходов, или способов, предпринять что-либо. Предпочтительным является подход, или путь, который лучше всего ведет к достижению целей приобретения при ограничениях. Для использования учитываются: 1) возможности сбыта; 2) бизнес-политика; 3) окружающая среда организации; 4) готовность финансовых ресурсов; 5) человеческие факторы; 6) стратегия совершенствования; 7) интеграция и интероперабельность; 8) логистика; 9) устаревание; 10) эксплуатационная среда; 11) производительность; 12) техногенная безопасность; 13) защищенность; 14) конкурентоспособность; 15) цели заинтересованных сторон; 16) жизнеспособность; 17) ограничения рынка по времени; 18) потенциальные риски для приобретения и поставки	6.1.1.3 a) 1)
c) План приобретения разрабатывают с использованием процесса планирования проекта	6.1.1.3 a) 6.3.1
d) Типичные документы ходатайства включают: запрос на приобретение (например, запрос на предложение, запрос о цене, запрос об информации, запрос о ссылке), соглашение о намерении, оферта или директива	6.1.1.3 b)
e) Чтобы обеспечить оптимальность между потребностями заинтересованных сторон и системными требованиями, необходимо вовлечение потенциальных поставщиков в определение запроса на приобретение всегда, когда это возможно для формальной ситуации контракта с привлечением внешних поставщиков	6.1.1.3 c)
f) Следует четко установить формальность контроля на уровне, соответствующем области и контексту соглашения, включая взаимные обязанности, частоту и способы контроля и оценки приемлемого выполнения соглашения	6.1.1.3 d)
g) Устанавливается, кто уполномочен принять каждый поставляемый продукт или услугу и на каком основании, включая применяемые процессы верификации и валидации (аттестации)	6.1.1.3 e) 6.4.6 6.4.8

Таблица A.2

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

Положения	ИСО/МЭК 15288
a) Чтобы должным образом выполнить действия и задачи процесса поставки, следует, если это допустимо, реализовать соответствующим образом применяемые процессы организационного обеспечения проекта, процессы проекта и технические процессы	6.1.2.3 6.2, 6.3, 6.4
b) Ходатайство от внутренней или внешней бизнес-единицы (которая может находиться внутри проекта) является обычным явлением. Нет необходимости в том, чтобы ходатайство было формальным	6.1.2.3 a)
c) Бизнес-единицы проводят изучение рыночной конъюнктуры на альтернативной основе, чтобы установить возможности, доступные в пределах специфического сектора в бизнесе	6.1.2.3 a)
d) Используя процесс планирования проекта, разрабатывают план поставки	6.3.1
e) Обычно в любой ситуации поставки есть несколько подходов, или способов, предпринять что-либо. Предпочтителен подход, или способ, который наилучшим образом и в полной мере достигает целей организации и поставки при задаваемых ограничениях. Следует учитывать: 1) применяемое законодательство и правила регулирования, которые соотнесены с поставщиком; 2) бизнес-цели единицы; 3) конкурентоспособность; 4) окружающую среду организации, политику и процедуры; 5) готовность ресурсов; 6) соответствующие риски в управлении, технические и ресурсные риски	6.1.2.3 b)
f) Чтобы обеспечить оптимальность между предоставляемыми возможностями и системными требованиями, необходимо, чтобы непосредственно или косвенно или и тем, и другим способом потенциальные поставщики были вовлечены в определение тендерного ответа и в переговоры по соглашению о поставке всегда, когда это возможно для формальной ситуации контракта с первичными и поддерживающими поставщиками	6.1.2.3 b) 6.1.2.3 c)
g) Следует четко установить формальность контроля на уровне, соответствующем области и контексту соглашения о поставке, включая взаимные обязанности, частоту и способы контроля и оценки приемлемого выполнения соглашения	6.1.2.3 d)
h) Устанавливается, кто уполномочен принять каждый поставляемый продукт или услугу и на каком основании, включая применяемые процессы верификации и валидации (аттестации)	6.1.2.3 e)

Положения	ИСО/МЭК 15288
a) Возможно, в отобранных процессах для применения в пределах стадии жизненного цикла системы некоторые из процессов по ИСО/МЭК 15288 окажутся неприменимыми для организации. В этом случае такие процессы ожидаемо не будут включены в стандарты организации, политику и процедуры или другие директивные средства массовой информации (СМИ). В тех случаях, когда организация желает, чтобы определенные действия процесса были частью директивных материалов, эти отобранные действия могут быть включены как часть определения других процессов или же весь процесс может быть подчинен уровню определенных действий другого процесса	6.2.1.3 a) 6.2.1.3 b)
b) Могут быть сформированы новые процессы проекта или действия одного из процессов жизненного цикла системы могут быть подняты до уровня процесса	6.2.1.3 a) 6.2.1.3 b)
c) Стандартизация процессов жизненного цикла в пределах бизнес-единицы может измениться. Однако там, где это оказывается выгодным, организации обычно поощряют все проекты и функциональные бизнес-единицы к использованию общих методов и стандартов	6.2.1.3 b)
d) Определение стандартизованных процессов включает соответствующие методы и инструментарии, которые будут реализованы в проектах в соответствии с организационной политикой и процедурами и инвестиционными решениями	6.2.1.3 b) 6.2.1.3 c)
e) Соответствующие процедуры восстановления целостности обычно устанавливаются для всех баз данных и процессов организационного обеспечения проекта	6.2.1.3 b)

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

Таблица A.5

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

Положения	ИСО/МЭК 15288
a) Процесс управления портфелем проектов устанавливает окружающую среду для организаций, в которых выполняются множественные продолжающиеся проекты, чтобы предусмотреть применимые стратегические и тактические планы, модели жизненного цикла программных средств и систем, политику, процедуры и стандарты. Кроме того, процесс устанавливает ограничения для технологий, производственных линий и управления проектом, помогает и обеспечивает способы коммуникации, с помощью которых проекты взаимодействуют друг с другом и с организацией	6.2.3 6.2.3 a)
b) На регулярной основе следует оценивать политику и процедуры, которые поддерживают и направляют проекты, реализуют обслуживание и производство организационных продуктов, услуг или и того, и другого. Изменения к политике и процедурам оцениваются в обеспечение того, что реализуется непрерывное усовершенствование организационной зрелости для удовлетворения стратегических и тактических целей	6.2.3 b)
c) Уровень целостности для различных созданных в проектах программных средств может потребовать отдельных множеств политик и процедур	6.2.3 b)
d) Обычно устанавливаются приемлемые цели управления, чтобы обеспечить пригодность достоверной информации для направления и предоставления возможностей проектам, включая статус проекта, стандартизированные автоматизированные инструментарии, организационные продукты, доступные для повторного применения, статус появляющихся технологий и соответствующих угроз и возможностей сбыта, а также информационных баз данных, в которых хранятся собираемые данные и документы	6.2.3 a) 6.2.3 b)
e) Важно установить, использовать и непрерывно уточнять показатели для данной области, показывающие, насколько хорошо проекты (индивидуально и в совокупности) достигают поставленных целей и целей организации с использованием выделенных ресурсов	6.2.3.3 b) 6.2.3.3 c)

Таблица A.6

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

Положения	ИСО/МЭК 15288
a) Этот организационный процесс предусматривает установление услуг с использованием человеческих ресурсов, которые позволяют организациям достигать своих целей и решать задачи в пределах правовых, финансовых и иных ограничений и требований соглашения	6.2.4
b) Услуги человеческих ресурсов включают (но не следует этим ограничиваться): 1) приобретение ресурса;	6.2.4 a) 6.2.4 b)
2) оценку навыков (мастерства); 3) развитие навыков (мастерства); 4) измерение уровня навыков (мастерства); 5) эффективное применение навыков (мастерства) сообразно организационным потребностям; 6) прямую и косвенную компенсацию; 7) обретение знаний, накопление и повторное применение	6.2.4 c) 6.2.4 d)
c) Инфраструктура и профессиональная структура занятости персонала в проектах, индивидуально и в совокупности, должны быть проанализированы на предмет соответствия организационным стратегическим и тактическим целям	6.2.4 a) 6.2.4 b) 6.2.4 c)

Таблица A.7

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

Положения	ИСО/МЭК 15288
a) Этот процесс совместим с установлением подходов управления качеством, которые приводят к соответствию с ИСО 9001	6.2.5
b) Этот процесс обеспечивает достаточный уровень уверенности, что система и атрибуты качества для каждого проекта соответствующим образом определены и действия эффективно управляемы для удовлетворения требованиям заказчика и других сторон, заинтересованных в организационном успехе	6.2.5 a) 6.2.5 b)

A.4 Процессы проекта (подраздел 6.3)

Таблица A.8

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

Положения	ИСО/МЭК 15288
a) Процесс планирования проекта определяет необходимые планы по поддержке других процессов. Например, для того чтобы:
1) принять решение по инвестициям	6.2.3.3 a)
2) подготовить обоснованный ответ на ходатайство	6.1.2.3 b) 2) и 6.3.1.3 b) 6)
3) определить, перейти ли на следующий этап или же продолжить работу для удовлетворения требований специальных организационных критериев входа/выхода на стадии	6.2.3.3 c)
4) руководить работой, требуемой для удовлетворения требованиям установленного соглашения	6.3.1.3 b) и c)
5) перепланировать работу	6.3.1.3 a) 1) и b) 2)
b) Планы ограничены организационными целями и задачами и потребностями заинтересованных сторон	6.3.1.3 a)
c) Планы включают область применения, задачи, методы, инструментарии, показатели, риски и ресурсы для применимой реализации системного элемента или системы, процессов комплексирования, верификации, передачи и валидации так, чтобы каждый резервный вариант мог быть эффективно использован	6.3.1.3
d) Перепланирование обычно начинается: 1) когда это требуется в соответствии с соглашением; 2) когда из выходных результатов другого процесса выявлены существенные изменения или отклонения; или 3) перед реализацией следующей стадии инженерного или организационного представления, связанного с выбранной организацией моделью жизненного цикла системы	6.3.1.3 a) 6.3.2
e) Резервные варианты используются в плане, когда известны риски или возможности (например, существенные изменения в бюджете, графиках, требованиях или технологии или в пригодности ресурса), которые могут заставить перенаправить проект или усилия по работе	6.3.1.3 a) 1)
f) Чтобы приспособиться к проекту или сложности работы, неопределенности и ресурсам, включая финансирование, планы следует садаптировать относительно уровня проекта и формальностей	6.3.1.3 a) 6.3.1.3 b)
g) Обычно устанавливается структура разделения работ из структуры системы и специфика несистемной структуры, связанные с действиями процесса проекта. Соответствующие действия процесса проекта, учитывающие специфику несистемной структуры, включают проектное планирование, оценку и контроль, управление рисками, решениями, конфигурацией, информацией и измерениями	6.3.1.3 a) 4) 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6
h) Начальную структуру разделения работ следует основывать на структуре системы и процессах жизненного цикла системы. Структура разделения работ обычно разрабатывается для того, чтобы определить задачи и пакеты работ, связанные со спецификой системы, параллельно с техническим определением структуры, в которой существует система	6.3.1.3 a) 4) 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6
i) Нижеследующие объекты 1) — 4) должны быть полезны для определения проектных графиков, требований к персоналу и ресурсам:	6.3.1.3 a) 4)
1) основные события, необходимые для соблюдения технических требований (например, технический анализ, анализ готовности производства, верификация, анализ решения по модификации)	6.3.1.3 b)
2) основные задачи, связанные с выполнением входных и выходных критериев каждого основного события (например, задачи по определению требований заинтересованной стороны, подготовке инженерных чертежей, завершению отчетности технического или управленческого анализа, проведению испытаний)	6.3.1.3 b)
3) задачи поддержки, которые позволяют персоналу, выполняющему основные задачи, достичь целей, например: - по приобретению ресурсов, оборудованию и основных средств; - приобретению соответствующего квалифицированного персонала для выполнения основных задач; - организации командировок	6.3.1.3 b)
4) задачи управления, требуемые для направления, контроля, анализов и утверждения основных задач и задач поддержки (например, тех, которые служат руководством для технического анализа, рассматривают и формируют документы для передачи заказчику, способствуют проведению анализа управления и решают, осуществить ли обновление технологии, сделать ли технологическую вставку или удалить систему)	6.3.1.3 c)
j) После санкционированного утверждения проектные графики считаются субъектом базовой линии для изменения управления в соответствии с организационной политикой и процедурами	6.3.1.3 b) 1) и 2)
k) После санкционированного утверждения запланированный бюджет обычно считают субъектом базовой линии в соответствии с деловой политикой и процедурами	6.3.1.3 b) 3)
l) Планы могут быть индивидуальными документами в коллективном документе или собранными в электронных СМИ для доступа соответствующими участниками. План — это начальный результат процесса, который позволяет процессу быть эффективно выполненным. План следует делать с использованием соответствующих действий процесса планирования проекта	6.3.1.3 b) 6)
m) Инженерный план объясняет, что должно быть сделано, как это будет сделано, кто будет это делать и где это будет сделано, а также сколько ресурсов необходимо задействовать для выполнения каждого из технических процессов. Инженерный план объясняет вышеупомянутые установленные ограничения по ресурсам и штату и требования в пределах допустимых рисков с тем, чтобы покрыть затраты, соблюсти графики, обеспечить выполнение процессов	6.3.1.3 c) 1)
n) Инженерный план применим для каждой стадии организационного представления и для каждого проекта (для системной инженерии или реинженерии) с использованием V-модели инженерии	6.3.1.3 c) 1)
o) Инженерный план также известен как план управления системной инженерии (SEMP) или как комплексный план управления (IMP)	6.3.1.3 c) 1)
p) Чтобы гарантировать включение и комплектование необходимой информации в инженерный план, следует использовать в качестве контрольного списка перечень, представленный ниже: 1) общая проблема, требующая решения; 2) польза для приобретающей стороны (организационная перспектива); 3) прикладной контекст общей проблемы, требующей решения; 4) границы общей проблемы, требующей решения, обозначающие, что может контролироваться разработчиком (внутри) и что влияет на разработку и подвержено влиянию разработки, но не контролируется разработчиком (снаружи); 5) требуемые входы и выходы, включая зависимости от обеспечивающих систем; 6) воздействующие факторы и ограничения; 7) системные проблемы относительно надежности, готовности, ремонтопригодности, защищенности, безопасности, качества информации, факторов, воздействующих на здоровье, жизнеспособности, электромагнитной совместимости, управления радиочастотами и человеческих факторов; 8) процессы проекта, действия и задачи, которые будут выполнены; 9) как каждый применяемый технический процесс будет выполняться и как каждый процесс стыкуется (потоки данных входов и выходов и их упорядочивание) с другими техническими, проектными, организационными процессами и процессом соглашения; 10) ресурсы, методы и инструментарии, запланированные для выполнения действий и задач каждого применяемого процесса; 11) как требуемые ресурсы и инструментарии будут приобретаться и использоваться; 12) структура организации, которая будет использована для гарантии эффективной работы в команде; 13) как проект будет укомплектовываться штатами и управляться; 14) основные показатели по качеству продуктов и то, каким образом будет определяться соответствие данным показателям; 15) основные промежуточные события и каким образом такое завершение события будет определено; 16) когда, где и кем действия и события будут завершены; 17) имеющие место технические риски и то, каким образом ими будут управлять;	6.3.1.3 c) 1)
18) потенциальные возможности и то, каким образом эти возможности будут определены и отслежены; 19) критерий завершения действий процесса; 20) входные и выходные критерии повторного выполнения каждого процесса; 21) каким образом будет определено завершение

Таблица A.9

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

Положения	ИСО/МЭК 15288
a) Существуют формализованные методы по управлению стоимостью и расписанием. Примеры включают: 1) «Проектирование по стоимости» (используется для установления требований стоимости, эквивалентных другим требованиям функционирования системы); 2) планирование, основанное на событиях, устанавливает события (например, контрольные точки), существенные действия и задачи, связанные с событиями, и критерии, в соответствии с которыми определено завершение действий или задач; 3) оценки по освоенному объему (используется для определения бюджетной стоимости выполняемой работы и осуществления сравнения планируемой стоимости с реальной стоимостью работы, чтобы определить оценки завершенных вариантов по стоимости и срокам)	6.3.2.3 a)
b) Соответствующие исследования и оценки проводятся: 1) для определения содержательности и соответствия проектных планов (управленческого и технического); 2) определения технического продвижения проекта, используя определенные технические показатели, основанные на предполагаемом достижении и завершенности в контрольных точках; 3) определения эффективности технических ролей и структуры проектной команды, использующей, где это возможно, объективные показатели, такие как технические достижения и эффективность использования ресурсов; 4) определения адекватности технических компетенций и навыков (мастерства) участников команды для удовлетворения техническим ролям и выполнения технических задач; 5) определения эффективности и ценности поддерживающего обучения; 6) определения адекватности и пригодности производственной инфраструктуры и услуг в определенные периоды для подтверждения того, что удовлетворены внутриорганизационные обязательства; 7) определения качества и продвижения в проектировании системы и услугах обеспечивающей системы; 8) определения технических различий с проектными оценками и выявления различий по сравнению с заданиями по стоимости, готовности и выполнению; 9) оценки эффективности технологий сбора, обработки и доведения данных; 10) определения технических отклонений между ожидаемыми результатами и результатами оценки для обнаружения тенденций и определения их первопричин; 11) определения качества собранных технических данных, значимости полученной информации, своевременности ее представления, полноты, достоверности, конфиденциальности (если требуется) и пользы для получателей от этой информации	6.3.2.3 a)
c) Процесс оценки и контроля проекта выполняется для выбора, оценки и сбора показателей системы и процесса, чтобы обеспечить информацией для поддержки управления проектом. Соответственно это предусматривает определение: 1) продвижения проекта; 2) информации для реакции на риски; 3) значимых финансируемых и нефинансируемых работ; 4) информации по эффективности и рискам для того, чтобы осуществлять анализ компромиссных решений и обеспечивать подготовку рекомендаций по действиям и результирующему влиянию	6.3.2.3 a)
d) Использование процесса оценки и контроля проекта помогает принятию управленческого решения, предоставляя информацию, которая является результатом контроля и анализа проектной работы, чтобы определить: 1) продвижение проекта и достижения в сравнении с планами (производительность работы) и техническими требованиями (качество продукции); 2) приверженность методам и процедурам; 3) готовность перейти к следующей стадии организационного представления (через прохождение решений или анализ контрольных точек) или к следующему уровню структуры системы; 4) эффективность, риски и возможности, связанные с альтернативами, доступными для лиц, принимающих решения; 5) результаты анализа компромиссов для выбора рекомендуемого направления действий и влияния стоимости, графиков выполнения работ и рисков	6.3.2.3 a)
e) Системные показатели продукции позволяют оценивать продвижение проекта и достижения в сравнении с техническими требованиями к системе и другим рабочим продуктам	6.3.2.3 a) 1) 6.3.2.3 a) 4) 6.3.2.3 a) 6)
f) Чтобы оценить удовлетворенность заинтересованных сторон и довести до приобретающих сторон улучшающуюся ценность продуктов и услуг проекта, используются системные показатели (называемые показателями продукции). Эти показатели также служат индикаторами того, что процесс проекта развивается в направлении приемлемого решения. Примерами системных показателей входа являются качество материалов и навыки (мастерство) привлекаемого проектного персонала. Примеры показателей выхода включают: жалобы заказчиков, отчеты об эксплуатационных отказах и технические показатели работы (ТПР). Технические показатели работы — это показатели, используемые, чтобы оценить продвижение проекта, соответствие требованиям к работе и технические риски для критичных параметров работы. ТПР получены из показателей функционирования (см. примечание 4 к приложению C.18), сосредотачиваясь на критичных технических параметрах определенных архитектурных элементов системы, если для них применяются процессы проектирования и реализации. Выбор технических показателей работы должен быть ограничен критичным пороговым значением или по параметрам, которые, если они отсутствуют, оценивают проектными рисками по стоимости, срокам и эксплуатации. ТПР обеспечивают раннее определение адекватности проекта в терминах удовлетворения требованиям по выбранным критичным техническим параметрам. ТПР включают показатели проектного выполнения, такие как кривые роста с порогами приемлемого уровня. Работа системного элемента или системы прослеживается через жизненный цикл по показателям в сравнении проектных и требуемых значений. Ранние оценки значений показателей работы в жизненном цикле основаны на моделировании и имитации. По мере переходов в жизненном цикле фактические данные заменяют оценочные и повышают тем самым точность информации. По мере развития эти измерения проектных решений позволяют оценить действия в процессах раньше, чем можно ожидать от тестирования системы, чтобы получить реальные значения показателей	6.3.2.3 a) 5) и 6)
g) Запланированные графики и фактические или оцененные трудозатраты, затраты на материалы и обслуживание следует собирать, количественно оценивать и сравнивать с бюджетной базовой линией и текущими прогнозами	6.3.2.3 a) 5) и 8)
h) Выходные результаты оценки производительности (продвижения по планам) предоставляют статусную информацию, предназначенную для обеспечения эффективного использования ресурсов, оценки продвижения в сравнении с планами, определения различий по стоимости и срокам от запланированных базовых линий проекта, более раннего определения и решений проблем производительности	6.3.2.3 a) 2) и 6)
i) Если изменения являются существенными или не могут быть исправлены повторным выполнением задач процесса, приведшим к неудовлетворительным выходным результатам, процесс планирования проекта начинается повторно с тем, чтобы запланировать и реализовать соответствующие корректирующие действия	6.3.2.3 a) 4) 5) и 6)
j) Чтобы оценить эффективность запланированной работы, определяются и используются показатели. Примерные показатели включают: освоенный объем (показатель стоимость/графики), количество отходов, число инженерных изменений, процент законченных чертежей, число ошибок на чертежах, процент строк законченного кода, процент переделок, время простоя (например, незавершенные работы), изменения тарифа и текучесть персонала. Критерии выбора показателей процесса основаны на том, насколько хорошо улучшения в выполнении проекта отвечают потенциальной удовлетворенности заказчика относительно стоимости, сроков и риска
k) Чтобы выполнить оценку удовлетворенности заказчика, определяются и используются показатели, для их оценки собираются данные	6.3.2.3 a) 5)
l) Технические анализы, аудиты и инспекции проводятся в сравнении с техническими планами в соответствии с определенными сроками, чтобы продемонстрировать соответствие действий и результатов относительно запланированной технической работы	6.3.2.3 a) 6)
m) Типичные цели технического анализа включают определение: 1) зрелости системы и того, насколько хорошо решение удовлетворяет требованиям; 2) прослеживаемости требований, обоснованности предположений и рациональности решений; 3) нерешенных проблем и тех проблем, которые не определены во время проектной работы; 4) соответствующих рисков, необходимых ресурсов и адекватности подготовки к проведению следующей стадии жизненного цикла системы	6.3.2.3 a) 6)
n) Анализы уровня рассматриваемой системы могут быть проведены в объединении с контрольными точками в организационном представлении или анализом качества	6.3.2.3 a) 6)
o) Несоответствие подлежащих доставке рабочих продуктов, услуг и процессов должно быть зарегистрировано. Для исправления условий несоответствия должны быть рекомендованы надлежащие меры	6.3.2.3 a) 7) — 9)
p) Использование процесса оценки и контроля проекта помогает охвату и управлению результатами со стороны руководства проектом и техническими работами, включая перенаправление усилий на преодоление трудностей, реакцию на изменяющиеся обстоятельства или исправление случающихся отклонений	6.3.2.3 b)
q) Управление требованиями осуществляется параллельно с действиями по управлению стоимостью, сроками, качеством, конфигурацией, взаимодействиями, рисками и изменениями, которые отслеживают соответствие требованиям соглашения проекта и технических требований	6.3.2.3 b)

Таблица A.10

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

Положения	ИСО/МЭК 15288
a) Типы анализов компромиссных решений, осуществляемых обычно во время выполнения процессов жизненного цикла, включают: 1) Формальный анализ — это анализ, проводимый по формализованным положениям, включая результаты технических анализов. Специфические формальные анализы компромиссных решений обычно определяются в соглашении. 2) Неформальный анализ — следует той же самой методологии формального анализа, но требует меньшего количества документации и имеет меньшее значение для приобретающей стороны. 3) Субъективный анализ — выбор рекомендуемых опций, основанный на суждении аналитика или проектировщика после менее строгого анализа, чем формальный анализ компромиссных решений, для которого последствия не столь важны. Используется тогда, когда одна опция явно превосходит другие или отсутствует время для более формального подхода. Большинство выполняемых анализов компромиссных решений имеет субъективный тип	6.3.3.3 a) и b)
b) Анализы компромиссных решений проводят в течение реализации проекта и технических процессов, чтобы разрешить противоречия (такие, как противоречивые требования) и выбрать рекомендуемое решение из ряда определенных альтернатив (таких, как дополнительные действия, предпринятые для реакции на риски, разрешения противоречивых требований, альтернативные логические или физические решения архитектурного проектирования). Результаты анализа включают рекомендуемые опции, соображения реализации, воздействия, связанные с каждой опцией, основы рекомендаций и сделанных предположений	6.3.3.3 a) 2), b) 1) и c)

Положения	ИСО/МЭК 15288
a) Управление рисками не следует рассматривать как избыточную деятельность, если даже она выступает как дополнительная деятельность к заданной работе или лежит вне ответственности проекта	6.3.4.1
b) Управление рисками — это общая процедура для того, чтобы отреагировать на риски. Риски считаются разрешенными, когда возможные последствия оцениваются как допустимые. «Допустимый» означает, что проект жизнеспособен с наихудшими возможными результатами. Управление рисками предусматривает: 1) планирование риска, в том числе подготовку плана управления рисками; 2) оценку риска, которую используют для определения риска, включая идентификацию источников и оценку потенциальных эффектов неопределенности; 3) управление рисками, которое используется, чтобы отреагировать на риски, и включает планы действий для реакции на риски, мониторинг статусов рисков, планы действий для реализации резолюций по рискам для тех случаев, когда действия инициируются и исправляются отклонения от проектных планов	6.3.4.3 a)
c) Управление рисками имеет два измерения понимания — прошлое и будущее. Прошлое измерение риска основано на прошлом опыте и включает показатели по сопоставительному анализу и изученные уроки, сравнивая фактические результаты с ожидаемыми, распределяя доступные ресурсы по требованиям относительно определения и выполнения работы и реализации плана производства продукции. Измерение для оценки будущего основано на преобразовании проектного видения в цели и задачи, используемые для того, чтобы обосновать планы, в соответствии с которыми определяются риски и возможности, неясности доступной информации и ресурсов, а также раскрываются неопределенности во время работы	6.3.4.3 a)
d) Управление рисками предусматривает: 1) идентификацию риска с определением источников угроз и связанных интересов, опасений, сомнений, неопределенностей и предположений; 2) анализ, основанный на установленных критериях, чтобы оценить вероятность реализации угроз в будущем с учетом последствий и проранжировать риски; 3) планирование альтернативных стратегий разрешения рисков, определение плана специального противодействия рискам для выбранного подхода и установление инициирующих событий (или пороговых значений) для того, чтобы предпринять действия, связанные с реакцией на риски; 4) прослеживание, чтобы подключить мониторинг статуса риска и сравнение пороговых значений риска с использованием инициирующих событий для обеспечения раннего обнаружения и отчета о статусе, основанном на показателях риска; 5) реакцию на риски с соответствующей идентификацией инициирующих событий, реализацией плана действий, отчетных результатов и продолжением запланированных действий до тех пор, пока риск не станет доступен для контроля	6.3.4.3 a)
e) Инструментарии для управления рисками предусматривают средства: 1) для идентификации риска — таксономия риска, исследования, опросы, изученные уроки, контрольные карты, диаграммы сходства, диаграммы взаимосвязи и структура системы или взаимодействия организационной структуры проекта; 2) анализа риска — модели воздействия, вероятностные модели, диаграмма Ганта, распределение воздействия, связи рисков, структура системы или взаимодействия структуры распределения работ и таблицы серии стандартов ИСО для оценки риска; 3) планирования альтернативной стратегии противодействия рискам — таблицы серии стандартов ИСО для оценки риска, изученные уроки, риски при использовании, гарантии и страхование; 4) прослеживания риска — технические показатели работы, освоенный объем, показатели и перечень предостережений по рискам; 5) реакции на риски — модели воздействия, перечень предостережений по рискам, шаблон риска и матрица управления рисками	6.3.4.3 a)
f) подходы к успешному управлению рисками предусматривают: 1) правильных людей. Люди высказывают проблемы, интересы и неопределенности. При этом существенным является определение желательного участия, возможностей и мотивации; 2) правильный процесс. Процесс преобразует неопределенность в допустимые риски через действия по управлению рисками, включая выполнение и достижение определенности; 3) правильную инфраструктуру. Организационная культура определяет, как проекты используют управление рисками. Инфраструктура обычно определяется через приемлемую политику и стандарты и включает идентификацию и распределение ресурсов (штат, графики, бюджет), требования (договорные, из стандартов) и ожидаемые результаты (стоимость, польза, выгода); 4) правильную информацию. Важно, чтобы информация использовалась для прогнозирования и оценки рисков и статус рисков был правилен, надежен и своевременен; 5) правильную реализацию. Важно запланировать управление рисками и использовать соответствующие методологии для выполнения процесса управления рисками на определенном проекте	6.3.4.3 a)
g) Есть три категории риска для рассмотрения: 1) риски для проекта — организационные, эксплуатационные или договорные опасения, включая ограничения ресурсов, внешние взаимодействия, отношения поставщиков, договорные ограничения, нехватку организационной поддержки и безразличность поставщика; 2) риски для процесса — планирование, укомплектованность персоналом, прослеживание, обеспечение качества и управление конфигурацией; 3) риски для продукции — реализация технического процесса, характеристик рабочих продуктов, стабильность требований, выполнение проекта, сложность и требования испытаний	6.3.4.3 b) и c)
h) Альтернативные подходы к реакции на риски включают: 1) принятие (адаптация); 2) избегание (исключают); 3) защиту (избыточность); 4) сокращение (смягчение — культура управления рисками — выполнение правильных процессов); 5) предотвращение (деятельность команды — использование объединенных команд); 6) прогнозирование (количественные показатели управления рисками, ранжирование, упреждающий подход); 7) возможности (взгляд на положительные результаты, а не только на отрицательные, всеобщая ответственность, сокращение затрат, выполнение лучше, чем запланировано); 8) исследования (больше информации); 9) резервирование (обеспечение непредвиденного); 10) передачу (другому человеку или организации)	6.3.4.3 d) и e)
i) Показатели необходимы, чтобы периодически оценивать эффективность всеобъемлющих усилий по управлению рисками (вместо того, чтобы смотреть на статус индивидуальных рисков). Эта периодическая оценка должна быть сделана с руководством проекта и другими главными заинтересованными сторонами в проекте или в организации	6.3.4.3 f)

Положения	ИСО/МЭК 15288
a) Определяя, чем управлять и до какой степени различные объекты должны быть управляемыми, следует признавать природу организации, ее назначение, ожидания заказчика, юридические и иные ограничения	6.3.5.3
b) Оценки риска должны быть включены в часть управления изменениями процесса управления конфигурацией	6.3.5.3 a) 2) 6.3.4
c) В разработке подхода к управлению конфигурацией использование поддерживающих инструментариев следует рассматривать на ранней стадии	6.3.5.3 b)

Положения

ИСО/МЭК 15288

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

6.3.6.3

Таблица A.14

Процесс измерений (пункт 6.3.7)

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

A.5 Технические процессы (подраздел 6.4)

Таблица A.15

Положения	ИСО/МЭК 15288
a) Требования заинтересованных сторон составляют начальные неформальные входы для решений установленных проблем (замысел новой системы или модификация существующей системы с ее недостатками, отказами и другими отклонениями, обнаруженными во время использования)	6.4.1.3
b) Заинтересованная сторона может быть внутренней для организации (например, другой проект, маркетинговая организация, вышестоящая производственная команда, собственная производственная команда, пользователь, оператор, исполнительный менеджер, руководитель) и внешней для организации (например, закупочное агентство, главный подрядчик, другая организация, заказчик, пользователь, оператор, собственник, покупатель)	6.4.1.3 a)
c) Пользователь — это особый случай заинтересованной стороны-приобретателя. Это тот, кто оперирует системой (например, компьютером) или кто устанавливает систему (к примеру, программное обеспечение), чтобы сформировать высокоуровневую систему (например, компьютер или микрочип) в структуре системы	6.4.1.3 a)
d) Другие заинтересованные стороны также могут относиться к «другим правообладателям» или иным сторонам, отличным от приобретателей и заинтересованным в выходных результатах работы по системной инженерии или реинжинирингу. Требования другой заинтересованной стороны, не обязательно обеспечиваемые приобретающей стороной в соглашении, включают: 1) организационные и проектные требования, связанные с рынками систем и организационными процессами; 2) экологические, местные, национальные и международные регламенты и законы; 3) функциональные требования поддержки для реализации системы и комплексирования, производства, испытаний, функционирования и логистики (развертывание, обучение, сопровождение и прекращение применения)	6.4.1.3 a)
e) Требование, как правило, подразумевает, что должно быть сделано (функция) и насколько хорошо оно должно быть сделано. Функция, как правило, — это утверждение с актором (тем, кто производит действие) (существительное), самим действием (глагол) и объектом действия (существительное). Например, «механизм (кто производит действие) открывает (действие) дверь (объект действия) в течение 10 с». Требование может также быть нефункциональным, то есть ограничением проекта, таким как вес или цвет	6.4.1.3 b) и c)
f) Этот процесс включает действия и задачи, выполняемые с помощью или для поставщика в изложении требований, которые будут выполняться, и целей, которые будут преследоваться при поставке систем и оказании соответствующих услуг	6.4.1.3 b) 1)
g) Стоимость может быть требованием, заявленным как фиксированные расходы (независимая переменная) или как максимальная стоимость (ограничение)	6.4.1.3 b) 1)
h) Этот процесс предусматривает гарантии определения требований для нисходящих интересов в жизненном цикле системы (производства, испытаний, функционирования и логистики развертывания, обучения, обслуживания (сопровождения), прекращения применения), затрагивающих функциональность системы	6.4.1.3 b) 2)
i) Положения контекста использования [как описано в ИСО/МЭК 15288 (см. примечание к действию 5.2.3.d)] — это отобранная информация о физических, технических, социальных и культурных элементах, окружающих систему, и анализ того, как они воздействуют (или будут воздействовать) и как используется система. Положения контекста использования — это полезный набор для поддержки информации при подготовке требований пользователей системы и эксплуатационных требований. Для проектировщиков системы в рассмотрении альтернатив проекта они дают представление о том, как и где система будет использоваться. Это — документы, ссылки для проектирования действий по валидации (аттестации) системы. Контекст использования — самый детальный источник информации о пользователях системы и их рабочих условиях. Используется как первичное руководство при выборе пользователей для испытаний и тестирования (для получения дополнительной информации об определении и анализе контекста использования см. ИСО 9241-11)	6.4.1.3 b) 2) 6.4.3 6.4.8
j) Обычно невозможно удовлетворить все требования правообладателей (приобретающей стороны и других заинтересованных сторон) для специфической системы с различными заинтересованными сторонами, у которых могут быть противоречивые требования относительно друг друга. Эти противоречия следует определить и разрешить во время работы данного процесса или при возможности осуществления каких-либо определенных действий, или при выполнении других технических процессов. Для разрешения противоречий следует руководствоваться оценкой эффективности, анализом компромиссных решений и действиями по анализу рисков	6.4.1.3 c)
k) Для каждой системы из структуры системы следует явно определить показатели эффективности. Показатель эффективности — это «эксплуатационный» показатель успешности, который напрямую связан с достижением эксплуатационных целей в намеченной эксплуатационной среде при соблюдении указанного множества условий, например насколько хорошо решение позволяет достичь намеченной цели. Показатели эффективности, которые заявлены с точки зрения пользователя/заказчика, являются для него основными показателями достижения целей функционирования, пригодности и доступности на протяжении жизненного цикла	6.4.1.3 c) 1) — 3)
l) Требования заинтересованных сторон — это основание для валидации (аттестации) реализованной или скомплексированной системы, которая разработана с использованием технических процессов	6.4.1.3 c) 2) — 5)
m) Прослеживаемость требований инициируется для того, чтобы отследить требования и изменения к требованиям от начальных входов заинтересованных сторон через архитектурный проект	6.4.1.3 c) 6)

Положения	ИСО/МЭК 15288
a) У каждого показателя эффективности есть соответствующее множество показателей функционирования. Показатели функционирования — это показатели, которые характеризуют физические или функциональные атрибуты, касающиеся функционирования системы. Эти «системные» технические показатели работы измеряются или оцениваются при специальном тестировании и/или в эксплуатационных условиях окружающей среды. Они являются определяющими для гарантии способности системы к достижению эксплуатационных целей. Показатели функционирования используются для оценки того, удовлетворяет ли система проектным или эксплуатационным требованиям. Они необходимы для анализа показателя эффективности, в интересах которого эти показатели функционирования были введены. Показатели функционирования характеризуют точку зрения поставщика решения и отражают, насколько хорошо поставляемая система функционирует в сравнении с требованиями уровня системы, например в аспектах ее функционирования или применения ее возможностей. Показатели функционирования часто вносят в состав основных требований к функционированию в системной спецификации. Они выражаются в терминах отчетливо измеримых свойств функционирования, таких как скорость, полезный груз, диапазон или частота. Требуется тщательное определение показателей функционирования в периоды анализа требований и логического архитектурного проектирования, а также эффективное отслеживание требований для гарантий того, что показатели функционирования фактически определены и включены в проект системы	6.4.2.3 a) 4)
b) Каждое техническое требование подлежит аттестации для гарантии того, что оно отражает следующие свойства качества: 1) способность к сохранению конкурентоспособности позволяет сохранить конкурентоспособные позиции и только как ограничение сказывается на конкурентоспособности, оправдывая выгоды, получаемые с помощью требований; 2) ясность — сформулированное требование готово к пониманию без анализа значения слов или используемых терминов; 3) корректность — сформулированное требование не содержит фактической ошибки; 4) выполнимость — требование может быть удовлетворено в пределах: - естественных физических ограничений; - современного состояния науки и техники относительно их приложения к проекту; - всех других абсолютных ограничений, относящихся к проекту; 5) целенаправленность — требование выражено в терминах того, «что» и «почему», или в виде формы, приспособления и функции, но не в терминах того, как разрабатывать продукты или материалы, которые будут использоваться. Исключением к этому являются требования, которые востребованы для проведения детального проектирования продукта, 6) реализуемость — сформулированное требование содержит необходимую информацию для его реализации; 7) модифицируемость — необходимые изменения к требованию могут быть сделаны полностью и частично; 8) избавление от двусмысленности — однозначность интерпретации для значения требования. Например, не определенную словами или сроками, такие как «чрезмерный», «существенный» и «сопротивляющийся», которые не могут быть измерены; 9) однозначность — сформулированное требование не может быть выражено как два или более требований, имеющих различия по факторам, действиям, объектам или инструментариям, 10) тестируемость (возможность проверки в период испытаний) — существование конечного и объективного процесса для верификации того, что требование было выполнено; 11) верифицируемость — требование может быть проверено на уровне структуры системы, в которой это установлено;	6.4.2.3 b) 1)
12) абстракция — корректный уровень абстракции для организационного представления стадии и зрелости системы
c) Технические сформулированные требования в парах и множествах подлежат валидации (аттестации) для гарантий того, что они отражают следующие свойства качества: 1) отсутствие избыточности — каждое требование задается только в один раз, 2) связность — все термины в пределах требования соответственно связаны с другими требованиями и со словами, терминами и определениями так, чтобы индивидуальные требования соответствовали должным образом другими требованиям как множество; 3) непротиворечивость — требование не вступает в противоречие с другими требованиями или не противоречит само себе	6.4.2.3 b) 1)
d) Чтобы помочь гарантировать выполнимость требований, поставщик должен учесть: 1) существующие системные элементы, например коммерческие, готовые к использованию, которые могут сократить время реализации и повлиять на стоимость, но и могут усложнить требования; 2) введение новой технологии, которая может обеспечить конкурентное превосходство; 3) возможные физические решения; 4) новые взаимодействия, которые могут быть введены	6.4.2.3 b) 1)
e) Чтобы создать решения по архитектурному проекту рассматриваемой системы, получающееся множество технических требований подлежит валидации (аттестации) на предмет необходимости и достаточности. Это предусматривает как приемлемые: 1) нисходящую прослеживаемость аттестованного множества требований заинтересованных сторон ко множеству определенных технических требований; 2) восходящую прослеживаемость индивидуальных технических сформулированных требований, производных от множества определенных технических требований, снизу вверх к аттестованным множествам требований заинтересованных сторон, 3) подтверждение того, что предположения и произведенные требования достоверны и совместимы с системой и соответствующими услугами в системной инженерии или реинжиниринге; 4) разрешение выявленных неохваченных аспектов, различий и противоречий, включая: i) подтверждение того, что были предприняты соответствующие действия, когда множество определенных технических требований оказывается непрослеживаемым снизу вверх к утвержденному множеству требований заинтересованных сторон; ii) определение того, были ли введены требования или ограничения без источников и желательны ли они соответствующим заинтересованным сторонам; iii) подтверждение того, что дополнительные требования добавлены приемлемым образом ко множеству определенных технических требований, когда соответствующие потребности заинтересованной стороны не были отражены должным образом; iv) доказательство того, что была сделана повторная аттестация множества технических требований, если изменения необходимы одному из аттестованных множеств потребностей заинтересованной стороны, и что соответствующие действия и задачи заинтересованной стороны, нуждающейся в процессах определения и анализа требований, были вновь выполнены соответствующим образом	6.4.2.3 b) 3)

Таблица A.17

Положения	ИСО/МЭК 15288
a) Проектирование архитектуры касается разработки приемлемых и выполнимых системных решений для множества полученных технических требований, поддержания целостности замысла через разработку с гарантией того, что построенная система соответствует спецификациям при верификации и применимым требованиям заинтересованных сторон при аттестации, обеспечивая конфигурационную целостность системного замысла на стадиях эксплуатации и поддержки. Завершенный архитектурный проект следует использовать в течение жизненного цикла системы для прогнозирования, отслеживания пригодности к использованию и для оценки изменений в системе	6.4.3
b) Требования для обеспечивающих систем исходят: 1) от пользователя или заказчика либо являются заданными требованиями и другими системными потребностями заинтересованных сторон; 2) полученных технических требований для систем и применения процесса проектирования архитектуры. Таким образом, инициирование разработки обеспечивающей системы или ее приобретения (функция границы проектируемой системы) зависит от завершения решения архитектурного проекта для создаваемой системы или системы, являющейся результатом реинжиниринга, а также от применяемой стадии жизненного цикла системы и соответствующей деятельности по инженерному или организационному представлению	6.4.3.3 a)
c) Логическое проектирование архитектуры включает в себя изучение различных логических декомпозиций и иных представлений о требованиях. Для различных представлений отсутствует какое-либо множество форматов или форм. Выбранный формат или форма — это то, что наилучшим образом определяет функциональные, поведенческие потоки, или потоки данных, или приемлемую структуру данных и что позволяет рациональным образом использовать потенциальные физические элементы, ручные операции или обеспечивающие системы для создания альтернативных решений физического проектирования архитектуры	6.4.3.3 a)
d) Определенные технические требования размещаются согласно создаваемому представлению логического проекта архитектуры. На основе различных представлений предъявляется множество технических требований, которые используются для проектирования архитектуры. Уже после того, как это размещение завершено, могут оказаться незадействованными некоторые технические требования. Они касаются альтернативных решений физического проекта архитектуры	6.4.3.3 a)
e) В размещении требований логического представления и полученных технических требований относительно того, обеспечивают ли они требования, которые могут быть выполнены лучшим образом, учитывают следующее: 1) выполнение с помощью обеспечивающих систем, связанных с реализацией и интеграцией, производством, испытаниями, операциями, поддержкой или прекращением применения; 2) выполнение вручную или с помощью оборудования, материалов или данных; 3) выполнение аппаратными средствами, программными средствами и микропрограммными физическими элементами (новыми или существующими)	6.4.3.3 a)
f) Процесс определения требований заинтересованных сторон (требований правообладателей), процесс анализа требований системы и процесс проектирования архитектуры системы повторяются для каждого последовательного более низкого уровня в структуре системы, пока не будут определены заданные требования для всех системных элементов или заданный системный элемент не будет построен, применен повторно или закуплен. Если для системного элемента требуется дальнейшая разработка, она может быть осуществлена с использованием соответствующего стандарта разработки системного элемента, например ИСО/МЭК 12207 для программных средств	6.4.3.3 b) 6.4.3.3 c) 6.4.1 6.4.2
g) Если при проектировании архитектуры определено, что требования не могут быть удовлетворены из-за нерешенных проблем, связанных с воздействующими факторами (см. ожидаемые результаты проектирования архитектуры), или из-за неприемлемых стоимости, сроков выполнения или рисков для приемлемых альтернатив, то может оказаться необходимым повторить процесс определения требований заинтересованных сторон (требований правообладателей), процесс анализа требований и процесс проектирования архитектуры системы	6.4.3.3 b) 6.4.3.3 c) 6.4.1 6.4.2
h) При определении предпочтительных физических решений для архитектурного проекта исследования каждой альтернативы выполняются с учетом следующего: 1) физического взаимодействия (человека, формы, приспособления, функции, потока данных и интероперабельности): i) между идентифицированными физическими элементами из принятого решения физического проекта, ii) с другими системными элементами из структуры системы, iii) с обеспечивающими системами, iv) с внешними системами; 2) разбросов и чувствительности к разбросам каждого определенного критического параметра функционирования; 3) технологических потребностей, необходимых для того, чтобы сделать альтернативное решение эффективным; рисков, связанных с введением новых или передовых технологий, чтобы удовлетворять заданным техническим требованиям, и альтернативных, менее рискованных технологий, которые могут стать заменой технологий с более высоким риском; 4) пригодности коммерческих конечных продуктов (таких как неразвиваемые аппаратные средства или программные средства многократного использования). Если продукты приемлемы не в полной мере, определяется стоимость и риски для модификации коммерческого системного элемента, чтобы удовлетворить проектные требования и требования по взаимодействию; 5) эффектов от учета проекта для обслуживания (сопровождения) или создания конкурентоспособной альтернативы физического решения по отношению к потенциальным или существующим продуктам конкурентов; 6) дальнейших проектных усилий, которые могут оказаться необходимыми для обеспечения резервируемости и поддержки во избежание деградации в результате последствий возможных отказов, для анализа эффектов и критичности отказов, имеющих недопустимый уровень или высокую степень критичности; 7) степени, до которой полученные технические требования к функционированию удовлетворяются с помощью каждого из альтернативных физических решений;	6.4.3.3 b) 6.4.3.3 c)
8) степени, до которой атрибуты безопасности, производительности, тестируемости, легкости развертывания, инсталлируемости, работоспособности, поддерживаемости, сопровождаемости, обучаемости, изъятия и списания были приспособлены к требованиям проекта; 9) потребностей, требований и ограничений для обеспечивающих систем; 10) возможностей к развитию или реинжинирингу, включая новые технологии, к улучшению функционирования, увеличению функциональности или к иным рентабельным или конкурентоспособным усовершенствованиям, когда система находится в производстве или на рынке; 11) ограничений, которые могут ухудшить возможности рассматриваемой системы или системного элемента и связанных услуг для развития (путем обновления технологии или технологической вставки); 12) преимуществ и недостатков в реализации системного элемента или при выполнении комплексирования в пределах организации или доведении до поставщика; 13) преимуществ и недостатков в использовании стандартизованных системных элементов, протоколов, взаимодействий и т.д.; 14) проблем интеграции, таких как: i) потенциальные опасности, угрожающие другим системам, операторам или окружающей среде, ii) требования встроенного теста и теста для изоляции ошибки, iii) легкость доступа, готовность к дизассемблированию, использованию общих инструментариев, частично учитываемый эффект, преимущества модульности, стандартизации и меньшей потребности в когнитивных навыках, iv) динамические или статические противоречия, несоответствия и несвойственная функциональность комплексируемых элементов, которые составляют решение
i) При поиске решения архитектурного проекта, которое вовлекает людей и человеческие ограничения, такие как пределы физического пространства, климатические пределы, движение глаз, использование силы или пальца, следует учитывать информационные эргономические нормы. Кроме того, следует анализировать человеческие факторы удобства и простоты использования. Эти факторы влияют на взаимодействие пользователя с другими системами и взаимодействия пользователя с системой в течение ее функционирования	6.4.3.3 b) 2)
j) Во время проектирования архитектуры для разработки и взаимодействия проектных решений используются масштабируемые, целевые, поведенческие, математические и управленческие модели. Определенный тип модели зависит от применяемой стадии организационного представления, ее цели или требований соглашения	6.4.3.3 b) 6.4.3.3 c)
k) Процесс определения требований заинтересованных сторон (требований правообладателей), процесс анализа требований и процесс проектирования архитектуры также используются, чтобы разработать решение для обеспечивающей системы, но только после того, как определены требования для такой разработки, получаемые в результате определения рассматриваемой системы или разрабатываемого системного элемента. Разработка обеспечивающей системы или приобретение обеспечивающих систем применимы для каждой рассматриваемой системы и системного элемента из структуры системы	6.4.1 6.4.2 6.4.3
l) Спецификации (специальные требования), произведенные в соответствии с физическим проектированием архитектуры, могут определять работу системы без указания того, как эта работа должна быть выполнена. Это называют спецификацией функционирования (хотя термин «ориентированной на функционирование» точный). Если результат проектирования архитектуры содержит большое количество деталей, включая определенные способы, которыми должно быть обеспечено функционирование, то его называют детальным проектом. Какой вид в итоге получается, зависит от следующего шага в разработке или от того, как результаты будут использованы. Если следующий шаг — это разработка системы более низкого уровня, и желательно, чтобы у поставщика была гибкость в инновационном обеспечении приемлемого решения, то используются спецификации функционирования. Спецификации функционирования используются, когда уместно заявить требования в терминах: 1) необходимых результатов, не определяя метод для их достижения; 2) функции (что должно быть достигнуто) и функционирования (в какой мере каждая функция должна быть выполнена); 3) окружающей среды, в которой рассматриваемая система или системный элемент должны выполнять функции; 4) взаимодействия и характеристик взаимозаменяемости; 5) средств для верификации соответствия	6.4.3.3.1
m) Начальные спецификации или спецификации «проекта, чтобы...», производимые вышеупомянутыми способами, обеспечивают входные требования приобретающей стороны для начала разработки следующего или иного, более низкого, уровня системы. Эти инициируемые спецификации завершаются после того, как процесс определения требований заинтересованных сторон (требований правообладателей), процесс анализа требований и процесс проектирования архитектуры будут применены к каждому из системных элементов более низких уровней. Спецификации описывают необходимые характеристики систем из структуры системы и включают требования к функциям и функционированию, требования к взаимодействиям, а также окружающую среду, в которой системы обязаны выполнять свои функции, физические характеристики и атрибуты, основы для оценки систем путем испытаний при верификации и валидации (аттестации), методы для проверки требований соответствия, использования по назначению и требований к обеспечивающим системам	6.4.3.3 c) 1)
n) Процесс определения требований заинтересованных сторон (требований правообладателей), процесс анализа требований и процесс проектирования архитектуры применяются к последующему системному элементу уровнем ниже до тех пор, пока получающееся решение для архитектурного проекта не сможет быть сформировано, закуплено или разработано в дальнейшем, например с использованием ИСО/МЭК 12207 для реализации программных средств	6.4.3.3 c) 1)
o) Процессы реализации, комплексирования, верификации, передачи и валидации (аттестации) используют для реализации систем в пределах структуры системы снизу вверх	6.4.3.3 c) 1)
p) Детальные спецификации следует использовать тогда, когда приемлемым является установление требований проекта в терминах одного или более, исходя из следующего: 1) как должно быть выполнено требование; 2) как должна быть построена система	6.4.3.3 c) 1)
q) Получающиеся множества решений архитектурного проекта и связанных технических требований должны быть оценены с тем, чтобы показать степень их применимости и наличие у каждого множества сформулированных требований для физического решения приемлемого качества, включая: 1) подтверждение того, что предназначенные функции системы и соответствующие услуги (выраженные в соответствии с произведенными техническими требованиями и техническими требованиями, распределенными непосредственно по физическому решению) реализованы правильно; 2) подтверждение того, что ограничения к системе и соответствующим услугам, включая взаимодействия, удовлетворены; 3) подтверждение устранения выявленных упущений, отклонений и противоречий, в том числе: i) повторное задание производных технических требований для обеспечения приемлемого качества; ii) подтверждение того, что соответствующее действие было предпринято тогда, когда заданные требования оказались непрослеживаемыми по восходящей ко множеству производных технических требований по решению архитектурного проекта и техническим требованиям, распределенным согласно решению непосредственно по физическим объектам; iii) определение того, были ли указанные требования введены без указания источников, предназначены для включения и желательны ли они соответствующим заинтересованным сторонам; iv) подтверждение того, что упущенные требования добавлены к решению архитектурного проекта, когда производные технические требования были неадекватно определены или отражены в выбранном решении; v) регистрация действий, предпринятых с целью устранения определенных требований при отсутствии их источников, установки корректного множества производных технических требований или пересмотра множества аттестованных технических требований;	6.4.3.3 c)
vi) доказательство того, что была выполнена повторная верификация заданных требований, когда изменения ко множеству аттестованных технических требований были необходимы, и что соответствующие действия и задачи процесса анализа требований системы и процесса проектирования архитектуры системы были выполнены вновь соответствующим образом; vii) доказательство того, что испытания повторной верификации были еще раз выполнены, когда прослеживались тестовые отклонения выходных результатов и аномалии, приведшие к плохим результатам верификации или к неадекватной окружающей среде верификации
r) Описание базовой линии решения архитектурного проекта использовано для управления конфигурацией рассматриваемой системы или системного элемента	6.4.3.3 c)
s) Может оказаться необходимым реинжиниринг решений архитектурного проекта для систем или для рассматриваемой системы более высокого уровня в структуре системы, в отличие от того, к которому применяется системная инженерия или реинжиниринг	6.4.3.3 c)
t) Результаты «проектирования архитектуры» могут быть использованы в описании архитектуры, как это определено ИСО/МЭК 42010. В этом случае «заинтересованные стороны и интересы», как определено ИСО/МЭК 42010, будут, возможно, определены во время процесса определения требований заинтересованных сторон (требований правообладателей) и процесса определения системных требований. Представление решения для физического проектирования архитектуры, описанного здесь, будет, возможно, представлено как «проектное представление» или «функциональное представление», связанное с функциональной точкой зрения, которая совместима с требованиями ИСО/МЭК 15288. Организация может установить другие архитектурные представления, ИСО/МЭК 15288 не должен интерпретироваться как мандат для единственной архитектурной точки зрения и представления	6.4.3

Положения	ИСО/МЭК 15288
a) Любой системный элемент может быть смоделирован, основываясь на зрелости его определения, а также на применяемой стадии организационного представления, контрольных точках или прохождениях решений и связанных с этим выходных критериев	6.4.4.3 a)
b) Системный элемент — это или единичный продукт, или композиция продуктов в зависимости от их уровня в структуре системы и возможности быть приобретенными или реализованными	6.4.4.3 b)
c) Системные элементы, состоящие исключительно из аппаратных элементов, могут быть: 1) закуплены готовыми к использованию у поставщика или продавца, 2) изготовлены внутри организации, или 3) собственного производства, поставляемые как коммерческий продукт, готовый к использованию	6.4.4.3 b)
d) Системные элементы, состоящие исключительно из программных элементов, могут быть: 1) закуплены у поставщика или продавца, 2) закодированы внутри организации, или 3) повторно используемыми	6.4.4.3 b)
e) Системные элементы, которые являются составными объектами аппаратных и программных средств, но существуют в качестве готовых элементов, могут быть приобретены у поставщика или быть повторно используемыми	6.4.4.3 b)
f) Аспекты, учитываемые при формировании стратегии реализации, включают: 1) информацию о том, производится ли при реализации новый системный элемент, или он воспроизводится согласно существующему проекту и исходным данным для реализации, или он является адаптацией существующего системного элемента; 2) стандартные методы, которые используются соответствующей технологией реализации, технической дисциплиной или секторальным продуктом; 3) вопросы безопасности, защищенности, частной жизни и собственности, экологические факторы; 4) местоположение и окружающую среду реализации; 5) навыки (мастерство) специалистов, их готовность и устойчивость; 6) материалы, выбранные для изготовления, расходные материалы и побочные продукты; 7) характеристики операторов; 8) период, после которого требуется повторная реализация	6.4.4.3 a)
g) Реализованные системные элементы верифицируются с использованием соответствующего процесса до момента поставки приобретающей стороне. Валидация (аттестация) может быть выполнена перед поставкой или до завершения процесса комплексирования, основанного на требованиях соглашения	6.4.4.3 b)
h) Конфигурацию «как построено» следует зарегистрировать и сопровождать на всем протяжении жизненного цикла системы	6.4.4.3 b)

Положения	ИСО/МЭК 15288
a) До комплексирования систем низшего уровня в более сложную систему убеждаются в том, что каждая составная система соответствующим образом аттестована поставщиком или внутри организации	6.4.5.3 b)
b) Аттестационные результаты испытаний системы, документация и процедуры в случае применимости следует проанализировать до выполнения комплексирования	6.4.5.3 b)

Таблица A.20

Процесс верификации (6.4.6)

Положения

ИСО/МЭК 15288

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

6.4.6.3 b)

Положения	ИСО/МЭК 15288
a) Поддержка требований пользователя или требований к подготовке операторов обеспечивается организацией, ответственной за выполнение действий процесса управления ресурсами в части обучения. Для обучения следует разработать обеспечивающую систему, включающую необходимые учебные модули, документы, пособия и материалы	6.4.7.3 a)
c) Может оказаться необходимым продолжить функционирование некоторых систем во время их замены, инсталляции, сертификации новой системы и профессиональной подготовки операторов к ней 6.4.7.3 b)
	Таблица A.22

Положения	ИСО/МЭК 15288
a) Для изучения работы системы в эксплуатационной среде, а также для того, чтобы сэкономить затраты, когда непосредственные испытания являются деструктивными или непрактичными, может оказаться полезным использование имитации и моделирования	6.4.8.3 a)
c) Для того чтобы получить надлежащую систему для валидации (аттестации), может потребоваться реинжиниринг системы поставщиком. Это может создать необходимость в реинжиниринге систем более низкого уровня, составляющих аттестуемую систему 6.4.8.3 a)
и b)	b) Заказчик в отношении рассматриваемой системы проводит аттестацию поставленных продуктов, используя процесс аттестации в сравнении с требованиями приобретающей стороны (часто по текущим продуктам, которые могут быть включены или могли быть не включены в продукцию). Это может принять форму приемочных испытаний или начальных эксплуатационных испытаний и количественной оценки 6.4.8.3 a) и b)
d) Необходимо позаботиться о получении гарантий того, что требования, полученные для устранения отклонений, не находились в противоречии с множеством входов или аттестованных требований заинтересованных сторон или требований соглашения без координации таковых изменений с соответствующими заинтересованными сторонами	6.4.8.3 b)
e) Отклонения, влекущие несоответствия, могут оказаться следствием некорректного проведения аттестационных испытаний, некорректного испытательного проекта, несовершенного системного проекта, несоответствия объекта испытаний «как построено» описаниям проектных решений (чертежам, схемам, спецификациям, требованиям взаимодействия и т.д.) и некорректных, устаревших или недавно появившихся требований заинтересованных сторон. Разрешение ошибочных ситуаций проводится на уровне решения, совместимого с корректирующими действиями, эффективными по затратам, включая повторную аттестацию после исправления дефектов или организационных действий по улучшению качества	6.4.8.3 b)
	Таблица A.23

Положения	ИСО/МЭК 15288
a) Процесс функционирования используется на любой стадии жизненного цикла при эксплуатации системы и применимых обеспечивающих систем для достижения функциональных целей соответствующей стадии	6.4.9.3 a)
b) У каждой стадии жизненного цикла есть эксплуатационная функция для достижения целей и выполнения задач стадии. Поэтому процесс функционирования применим к любой стадии и может иметь различную стратегию и план относительно действий системы и обеспечивающих систем	6.4.9.3 a)
c) Во время стадий замысла и стадий разработки в жизненном цикле план функционирования (эксплуатации) может выступать как один из планов проекта или системной инженерии	6.4.9.3 a)

Положения	ИСО/МЭК 15288
a) Процесс обслуживания (сопровождения) включает любой элемент поддержки логистики, в том числе обучение персонала, штатное управление конфигурацией, эксплуатация хранилищ и основных средств обслуживания (сопровождения), управление поставкой, функции поставки, как определено в соглашении или других директивах, а также упаковку, ручную обработку и отгрузку	6.4.10.3 a)
b) У каждой стадии жизненного цикла системы есть функция обслуживания (сопровождения) для выполнения задач и достижения цели этой стадии. Поэтому процесс обслуживания (сопровождения) применим к любой стадии и может иметь различную стратегию и план относительно поддержания систем и обеспечивающих систем, применимых к конкретной стадии	6.4.10.3 a)
c) Принимая во внимание корректирующие действия во время обслуживания (сопровождения), отказавшие объекты следует изолировать сверху вниз по направлению к возможному уровню отказа в системе. В решении следует планировать и корректировать ситуации путем исправления или замены неисправляемой системы, пополнения используемых или восстановления устаревших либо вышедших из строя запасных частей. После решения по устранению отказа может быть выдано свидетельство о корректном функционировании	6.4.10.3 a)
d) Следует поддерживать соответствующую документацию, описывающую действия обслуживания (сопровождения) и выходные результаты	6.4.10.3 b)

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

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

[1]	IEC 61160:2005	Анализ проекта (Design Review)
[2]	IEEE Std 1028-2008	IEEE для ревизий и аудитов программных средств (IEEE Standard for Software Reviews and Audits)
[3]	IEEE Std 1044-2009	IEEE Классификация по программным аномалиям (IEEE Standard Classification for Software Anomalies) (Software engineering. Software product Quality Requirements and Evaluation (SQuaRE). Guide to SQuaRE)
[4]	IEEE Std 1320.1	Стандарт для языка функционального моделирования. Синтаксис и семантика для IDEF0 (IEEE Standard for functional modelling language — Syntax and semantics for IDEF0)
[5]	ISO/IEC 12207:2008	Системная и программная инженерия. Процессы жизненного цикла программных средств (Systems and software engineering — Software life cycle processes)
[6]	ISO/IEC 15288:2008	Системная и программная инженерия. Процессы жизненного цикла систем (Systems and software engineering — System life cycle processes)
[7]	ISO/TR 18529:2000	Ergonomics — Ergonomics of human-system interaction — Human-centred lifecycle process descriptions
[8]	ISO 9000:2005	Системы управления качества. Основные положения и словарь (Quality management systems — Fundamentals and vocabulary)

---