ГОСТ Р 57102-2016

     
ГОСТ Р 57102-2016/
ISO/lEC TR 24748-2:2011

     

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

Информационные технологии. Системная и программная инженерия

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

Часть 2

Руководство по применению ИСО/МЭК 15288

Information technology. Systems and software engineering. Life cycle management. Part 2. Guide to the application of ISO/IEC 15288

ОКС 35.080

Дата введения 2017-09-01

     

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному документу ISO/IEC TR 24748-2:2011* "Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288 (Процессы жизненного цикла системы)" (ISO/IEC TR 24748-2:2011 "Systems and software engineering - Life cycle management - Part 2: Guide to the application of ISO/IEC 15288 (System life cycle processes)", IDT).

________________

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

ИСО/МЭК 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 к заданной системе эта система становится рассматриваемой системой. У рассматриваемой системы есть жизненный цикл, состоящий из множества стадий, через которые система проходит в период своей жизни. Обозначим стадии как s, s, ..., s. Примером типовых стадий являются:

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

- s - разработка;

- s - производство;

- s - применение;

- s - поддержка;

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

Примечания

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 (приложение А).

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

ИСО/МЭК 24748-1 (подраздел 9.1) представляет собой обширное детальное сравнение между старыми и новыми версиями ИСО/МЭК 15288, так же как и сравнения между старыми и новыми версиями ИСО/МЭК 12207 и между ИСО/МЭК 15288 и ИСО/МЭК 12207. По существу:

- структура процессов в ИСО/МЭК 15288 была изменена согласно структуре процессов в ИСО/МЭК 12207 путем декомпозиции действий процессов в более детальные задачи;

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

     
Рисунок 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) определенные функциональные требования и требования по выполнению, атрибутам и характеристикам, которые ясно означают то, что система и соответствующие ей услуги должны быть реализованы, на что должны быть похожи или что должны содержать, включая взаимодействия с другими системами, пользователями и окружающей средой. Они могут быть в форме ряда формальных требований или в виде спецификаций;

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

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

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

f) другую соответствующую информацию, такую как:

1) ограничения по стоимости и графикам,

2) контрольные точки в разработке,

3) графики оплаты,

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) с дальнейшими пояснениями в приложении А.

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

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

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

Подтверждение соответствия ИСО/МЭК 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 (приложение А) описывает приспосабливание и определяет основные виды деятельности, выполняемые при приспосабливании ИСО/МЭК 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 Рассмотрение и методики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 14 - Применение процесса с целью соответствия условиям соглашения

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

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

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

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

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

5.4.3.1 Общее

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

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

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

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

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

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

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

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

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) объекты, которые инкапсулируют разделение и схематичное представление технических требований и характеризуются услугами (поведениями, функциями и операциями), предоставленными атрибутами (значениями, характеристиками и данными);

k) ряд алгоритмов контекстных диаграмм;

I) диаграмма IDEF0 [IDEF0 (определение интеграции 0) - моделирование функции обозначено, чтобы представить решения, действия и деятельность существующей или предполагаемой организации или системы (см. дополнительную информацию - IEEE Std. 1320.1].

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

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

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

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

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) требованиям из выходных результатов процесса анализа требований, которые не были распределены по модели логического архитектурного проекта. Это могло произойти, когда техническое требование после анализа требований не нашло распределения согласно модели логического архитектурного проектирования.

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

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

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

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

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

Кроме того, на любом уровне системный элемент может быть определен как имеющий специальный стандарт, который может быть использован для реализации системы. Это проиллюстрировано на рисунке 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 - Реализация обеспечивающих систем

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

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

5.4.4.1 Обзор

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

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

Модель жизненного цикла системы, проиллюстрированная на рисунке 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, различными способами, чтобы удовлетворить потребности разнообразных областей бизнеса и сбалансировать стратегию реагирования на риски. Часто используются последовательные, инкрементные или эволюционные подходы. Эти подходы обсуждены в положениях ниже. Альтернативно может быть разработана приемлемая комбинация этих подходов.

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

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

b) природа и сложность системы;

c) устойчивость системных требований;

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, для определения и реализации структуры системы.

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

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

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

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

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

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

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

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

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) при необходимости: основание для утверждения дальнейшего производства системы.

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

Примечания для применения процессов ИСО/МЭК 15288

А.1 Общее

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

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

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

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

Таблица А.1 - Процесс приобретения (пункт 6.1.1)

Таблица А.2 - Процесс поставки (6.1.2)

А.3 Процессы организационного обеспечения проекта (подраздел 6.2)

Таблица А.3 - Процесс управления моделью жизненного цикла (6.2.1)

Таблица А.4 - Процесс управления инфраструктурой (6.2.2)

Таблица А.5 - Процесс управления портфелем (6.2.3)

Таблица А.6 - Процесс управления человеческими ресурсами (6.2.4)

Таблица А.7 - Процесс управления качеством (6.2.5)

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

Таблица А.8 - Процесс планирования проекта (6.3.1)

Таблица А.9 - Процесс оценки и контроля проекта (6.3.2)

Таблица А.10 - Процесс управления решениями (6.3.3)

Таблица А.11 - Процесс управления рисками (6.3.4)

Таблица А.12 - Процесс управления конфигурацией (6.3.5)

Таблица А.13 - Процесс управления информацией (6.3.6)

Таблица А.14 - Процесс измерений (пункт 6.3.7)

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

Таблица А.15 - Процесс определения требований заинтересованных сторон (правообладателей) (пункт 6.4.1)

Таблица А.16 - Процесс анализа системных требований (6.4.2)

Таблица А.17 - Процесс проектирования архитектуры (пункт 6.4.3)

Таблица А.18 - Процесс реализации (6.4.4)

Таблица А.19 - Процесс комплексирования (6.4.5)

Таблица А.20 - Процесс верификации (6.4.6)

Таблица А.21 - Процесс передачи (6.4.7)

Таблица А.22 - Процесс валидации (аттестации) (6.4.8)

___________________

* Буквенная нумерация соответствует оригиналу. - Примечание изготовителя базы данных.

Таблица А.23 - Процесс функционирования (6.4.9)

Таблица А.24 - Процесс обслуживания (сопровождения) (6.4.10)

Таблица А.25 - Процесс изъятия и списания (6.4.11)

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