ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

СИСТЕМНАЯ ИНЖЕНЕРИЯ

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

ISO/IEC 15288:2002

System engineering - System life cycle processes

(IDT)

 

 

Москва

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

2006

 

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1 ПОДГОТОВЛЕН Подкомитетом «Системная и программная инженерия» Технического комитета по стандартизации ТК 22 «Информационные технологии» (с участием 3 ЦНИИ Минобороны России, Российской академии ракетных и артиллерийских наук, Международного центра по информатике и электронике, МИРЭА, ЦНИИ РТК) на основе собственного аутентичного перевода стандарта, указанного в пункте 4

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15288:2002 «Системная инженерия. Процессы жизненного цикла систем» (ISO/IEC 15288:2002 «System engineering - System life cycle processes»).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (подраздел 3.5)

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

СОДЕРЖАНИЕ

Информационная технология

СИСТЕМНАЯ ИНЖЕНЕРИЯ

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

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

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

1.1 Назначение

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

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

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

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

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

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

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

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

1.3 Ограничения

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

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

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

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

2.1 Предполагаемое использование

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

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

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

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

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

2.3 Адаптированное соответствие

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

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

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

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

Изменение № 1-2002 к ИСО/МЭК 12207:1995 Информационная технология. Процессы жизненного цикла программных средств¹⁾.

¹) Взаимосвязь между ИСО/МЭК 15288 и Изменением № 1 к ИСО/МЭК 12207 приведена в приложении С.

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

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

4.1 приобретающая сторона (acquirer): Правообладатель, который приобретает или получает продукт или услугу от поставщика.

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

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

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

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

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

Примечания

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

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

4.6 предприятие (enterprise): Часть организации, отвечающая за приобретение и поставку продукции и (или) услуг в соответствии с соглашениями.

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

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

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

4.9 оператор (operator): Лицо или организация, которые вносят вклад в реализацию функциональных возможностей системы и применяют знания, умение и процедуры при выполнении определенной функции.

Примечания

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

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

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

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

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

Примечания

1 Адаптация определения, приведенного в [3] и [20].

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

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

Примечания

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

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

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

Примечания

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

2 Стадии могут перекрывать друг друга.

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

4.24 верификация (verification): Подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены [3].

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

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

5.1 Введение

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

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

процессы соглашения;

процессы предприятия;

процессы проекта;

технические процессы.

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

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

5.2.1 Введение

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

Процессы соглашения состоят из:

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

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

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

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

5.2.2.1 Цель процесса приобретения

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

5.2.2.2 Результаты процесса приобретения

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

a) определяется стратегия приобретения;

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

c) устанавливается связь с поставщиком;

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

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

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

g) осуществляется оплата или другие согласованные расчеты.

5.2.2.3 Деятельность в процессе приобретения

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

a) утверждать план приобретения.

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

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

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

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

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

d) выбирать поставщика.

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

e) заключать соглашение с поставщиком.

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

f) оценивать выполнение соглашения.

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

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

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

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

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

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

5.2.3.1 Цель процесса поставки

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

5.2.3.2 Результаты процесса поставки

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

a) определяется приобретающая сторона продукта или услуги;

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

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

d) обеспечивается связь с приобретающей стороной;

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

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

g) производится оплата или осуществляются другие согласованные взаиморасчеты.

5.2.3.3 Деятельность в процессе поставки

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

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

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

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

c) готовить предложение по удовлетворению ходатайства;

d) заключать соглашение с приобретающей стороной.

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

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

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

f) оценивать выполнение соглашения.

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

g) поставлять продукт или услугу в соответствии с критериями соглашения;

h) принимать и подтверждать получение оплаты или выполнение других согласованных способов расчета;

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

5.3 Процессы предприятия

5.3.1 Введение

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

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

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

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

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

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

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

5.3.2 Процесс управления средой предприятия

5.3.2.1 Цель процесса управления средой предприятия

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

5.3.2.2 Результаты процесса управления средой предприятия

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

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

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

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

5.3.2.3 Деятельность в процессе управления средой предприятия

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

a) устанавливать планы действий для каждой области деятельности.

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

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

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

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

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

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

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

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

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

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

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

5.3.3.1 Цель процесса управления инвестициями

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

5.3.3.2 Результаты процесса управления инвестициями

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

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

b) определяются и распределяются ресурсы и денежные средства;

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

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

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

5.3.3.3 Деятельность в процессе управления инвестициями

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

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

Примечание - Следует расставлять приоритеты для проектов, которые должны быть начаты, и устанавливать критерии для определения выполнимости этих проектов;

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

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

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

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

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

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

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

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

1) проекты продвигаются в направлении достижения поставленных целей;

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

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

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

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

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

5.3.4 Процесс управления процессами жизненного цикла системы

5.3.4.1 Цель процесса управления процессами жизненного цикла системы

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

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

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

В результате эффективного управления процессами жизненного цикла системы:

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

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

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

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

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

5.3.4.3 Деятельность в процессе управления процессами жизненного цикла системы

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

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

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

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

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

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

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

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

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

5.3.5.1 Цель процесса управления ресурсами

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

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

5.3.5.2 Результаты процесса управления ресурсами

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

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

b) поддерживается или улучшается квалификация персонала;

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

5.3.5.3 Деятельность в процессе управления ресурсами

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

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

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

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

c) проявлять заботу о персонале, занятом в осуществлении текущих проектов.

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

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

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

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

2) из-за занятости персонала работой над несколькими проектами одновременно.

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

5.3.6.1 Цель процесса управления качеством

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

5.3.6.2 Результаты процесса управления качеством

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

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

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

c) определяется ответственность и полномочия для управления качеством;

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

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

5.3.6.3 Деятельность в процессе управления качеством

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

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

Примечание - Модель процесса для требований к системе управления качеством приведена в [4] и [5];

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

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

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

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

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

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

f) непрерывно контролировать состояние усовершенствования качества продукции и услуг.

5.4 Процессы проекта

5.4.1 Введение

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

Процессы проекта состоят из следующих процессов:

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

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

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

d) процесс принятия решений;

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

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

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

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

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

5.4.2.1 Цель процесса планирования проекта

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

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

5.4.2.2 Результаты процесса планирования проекта

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

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

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

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

d) определяются показатели для характеристик проекта;

е) штат проекта ориентируется в соответствии с планами проекта.

5.4.2.3 Деятельность в процессе планирования проекта

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

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

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

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

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

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

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

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

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

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

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

f) определять расходы на проект и планировать бюджет.

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

g) устанавливать структуру полномочий и ответственности за выполнение работ в рамках проекта.

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

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

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

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

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

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

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

Примечание - К этому действию относится определение источников проектных данных, их получателей и назначение соответствующих сроков;

l) составлять планы по обеспечению качества проекта.

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

5.4.3 Процесс оценки проекта

5.4.3.1 Цель процесса оценки проекта

Цель процесса оценки проекта заключается в определении статуса проекта.

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

5.4.3.2 Результаты процесса оценки проекта

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

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

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

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

d) анализируются отклонения от планируемых значений показателей рабочих характеристик проекта;

e) заинтересованные стороны информируются о статусе проекта.

5.4.3.3 Деятельность в процессе оценки проекта

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

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

b) обеспечивать гарантии качества в соответствии с проектными планами;

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

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

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

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

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

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

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

g) отслеживать критические процессы и новые технологии.

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

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

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

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

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

5.4.4.1 Цель процесса контроля проекта

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

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

5.4.4.2 Результаты процесса контроля проекта

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

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

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

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

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

5.4.4.3 Деятельность в процессе контроля проекта

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

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

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

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

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

d) инициировать действия по разрешению проблем для коррекции несоответствий.

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

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

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

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

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

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

5.4.5 Процесс принятия решений

5.4.5.1 Цель процесса принятия решений

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

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

5.4.5.2 Результаты процесса принятия решений

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

a) определяется стратегия принятия решений;

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

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

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

5.4.5.3 Деятельность в процессе принятия решений

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

a) определять стратегию принятия решений.

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

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

c) устанавливать обстоятельства и необходимость принятия решений.

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

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

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

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

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

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

5.4.6.1 Цель процесса управления рисками

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

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

5.4.6.2 Результаты процесса управления рисками

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

a) определяются и классифицируются риски;

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

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

d) определяется и объявляется статус риска;

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

5.4.6.3 Деятельность процесса управления рисками

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

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

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

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

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

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

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

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

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

f) определять стратегии реакции на риски.

Примечание - К этому действию относятся:

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

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

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

4) удержание риска в границах приемлемого ущерба;

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

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

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

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

j) вести учет рисков в течение всего жизненного цикла.

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

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

5.4.7.1 Цель процесса управления конфигурацией

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

5.4.7.2 Результаты процесса управления конфигурацией

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

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

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

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

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

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

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

5.4.7.3 Деятельность в процессе управления конфигурацией

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

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

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

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

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

c) поддерживать информацию о конфигурации на приемлемом уровне целостности и защищенности.

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

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

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

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

5.4.8.1 Цель процесса управления информацией

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

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

5.4.8.2 Результаты процесса управления информацией

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

a) определяется информация, подлежащая управлению;

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

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

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

e) информация является «свежей», полной и достоверной;

f) информация становится доступной для уполномоченных сторон.

5.4.8.3 Деятельность в процессе управления информацией

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

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

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

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

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

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

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

e) получать идентифицированные элементы информации.

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

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

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

g) определять действия по сопровождению информации.

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

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

Примечание - Информация предоставляется назначенным сторонам в приемлемой форме;

i) предоставлять официальную документацию в соответствии с требованиями.

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

j) архивировать заданную информацию в соответствии с целями аудита и сохранения знаний.

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

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

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

5.5.1 Введение

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

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

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

а) процесс определения требований правообладателей;

b) процесс анализа требований;

c) процесс проектирования архитектуры;

d) процесс реализации элементов системы;

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

f) процесс верификации;

g) процесс передачи;

h) процесс валидации;

i) процесс функционирования;

j) процесс технического обслуживания;

k) процесс изъятия и списания.

5.5.2 Процесс определения требований правообладателей

5.5.2.1 Цель процесса определения требований правообладателей

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

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

5.5.2.2 Результаты процесса определения требований правообладателей

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

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

b) определяются ограничения для системных решений;

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

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

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

f) формируется основа для ведения переговоров и заключения соглашения о поставке продукции или услуг.

5.5.2.3 Деятельность в процессе определения требований правообладателей

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

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

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

b) выявлять требования правообладателей.

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

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

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

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

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

е) определять взаимодействие между пользователями и системой.

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

1) физических, умственных способностей и способностей к обучению;

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

3) нормальных, необычных и чрезвычайных ситуаций;

4) набора, обучения и развития операторов и пользователей;

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

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

g) анализировать полную совокупность выявленных требований.

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

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

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

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

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

j) устанавливать совместно с правообладателями корректность выражения их требований.

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

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

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

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

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

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

5.5.3.1 Цель процесса анализа требований

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

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

5.5.3.2 Результаты процесса анализа требований

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

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

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

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

d) определяется основа для верификации системных требований.

5.5.3.3 Деятельность в процессе анализа требований

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

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

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

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

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

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

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

d) определять технические показатели и показатели качества при использовании, позволяющие оценивать технические достижения.

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

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

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

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

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

g) демонстрировать связь между системными требованиями и требованиями правообладателей.

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

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

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

5.5.4.1 Цель процесса проектирования архитектуры

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

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

5.5.4.2 Результаты процесса проектирования архитектуры

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

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

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

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

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

e) определяется основа для верификации системных элементов;

f) устанавливается основа комплексирования системных элементов.

5.5.4.3 Деятельность в процессе проектирования архитектуры

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

a) определять приемлемые проекты логической архитектуры.

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

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

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

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

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

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

1) ограниченные возможности человека;

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

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

Руководство по человеко-ориентированным процессам проектирования для интерактивных систем представлено в [13];

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

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

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

Примечание - К данному действию относятся:

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

2) гарантии того, что ограничения обеспечивающих систем приняты в расчет в данном проекте;

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

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

Примечание - Определение проводится с той степенью детализации и контроля, которая соответствует созданию, использованию и обеспечению целостности системы. При этом сторонами, ответственными за взаимодействие с внешними элементами, осуществляется документирование интерфейсов. Интерфейсы типа «человек-система» и «человек-человек» также определяются и контролируются. Определения интерфейсов должны соответствовать конкретному производственному сектору или международным стандартам, в которых они присутствуют, например, [10] - для интерфейса «человек-компьютер» или [2] - для семиуровневой модели взаимодействия открытых систем при передаче данных;

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

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

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

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

j) поддерживать взаимосвязь и взаимозависимость между архитектурой и системными требованиями.

5.5.5 Процесс реализации элементов системы

5.5.5.1 Цель процесса реализации элементов системы

Цель процесса реализации элементов системы состоит в создании заданных (специфицированных) элементов системы.

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

5.5.5.2 Результаты процесса реализации элементов системы

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

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

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

c) изготавливается системный элемент;

d) системный элемент упаковывается и хранится в соответствии с соглашением о его поставке.

5.5.5.3 Деятельность в процессе реализации элементов системы

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

a) разрабатывать стратегию реализации элементов системы.

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

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

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

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

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

1) Производство технических средств

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

2) Создание программных средств

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

3) Обучение операторов

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

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

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

e) упаковывать элемент системы и хранить его в соответствующем виде.

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

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

5.5.6.1 Цель процесса комплексирования

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

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

5.5.6.2 Результаты процесса комплексирования

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

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

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

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

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

5.5.6.3 Деятельность в процессе комплексирования

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

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

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

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

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

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

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

d) получать системные элементы согласно графикам.

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

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

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

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

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

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

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

5.5.7.1 Цель процесса верификации

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

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

5.5.7.2 Результаты процесса верификации

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

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

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

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

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

5.5.7.3 Деятельность в процессе верификации

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

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

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

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

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

c) идентифицировать и сообщать о потенциальных ограничениях на проектные решения.

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

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

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

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

f) формировать доступные верификационные данные о системе.

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

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

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

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

5.5.8.1 Цель процесса передачи

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

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

5.5.8.2 Результаты процесса передачи

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

a) определяется стратегия передачи;

b) система приводится в рабочее состояние на месте ее применения;

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

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

е) регистрируются отчеты о корректирующих действиях;

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

5.5.8.3 Деятельность в процессе передачи

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

a) определять стратегию передачи.

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

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

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

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

Примечание - Может появиться необходимость в том, чтобы предусмотреть хранение системы до момента поставки;

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

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

e) продемонстрировать, что система установлена надлежащим образом.

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

f) активизировать систему;

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

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

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

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

5.5.9 Процесс валидации

5.5.9.1 Цель процесса валидации

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

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

5.5.9.2 Результаты процесса валидации

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

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

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

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

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

5.5.9.3 Деятельность в процессе валидации

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

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

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

b) подготавливать план валидации.

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

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

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

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

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

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

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

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

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

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

5.5.10.1 Цель процесса функционирования

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

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

5.5.10.2 Результаты процесса функционирования

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

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

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

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

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

5.5.10.3 Деятельность в процессе функционирования

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

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

Примечание - Это действие определяет:

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

2) стратегию подбора персонала и графики работы операторов;

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

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

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

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

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

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

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

Примечание - В их число входят источники питания для технических средств и снабжение продовольствием операторов;

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

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

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

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

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

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

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

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

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

5.5.11 Процесс обслуживания

5.5.11.1 Цель процесса обслуживания

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

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

5.5.11.2 Результаты процесса обслуживания

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

а) разрабатывается стратегия обслуживания;

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

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

d) осуществляется поддержка услуг, удовлетворяющих требования правообладателей;

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

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

5.5.11.3 Деятельность в процессе обслуживания

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

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

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

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

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

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

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

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

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

Примечание - Ограничения могут являться следствием необходимости:

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

2) повторного использования существующих запасов заменяемых системных элементов и согласования с ограничениями на повторную поставку;

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

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

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

e) осуществлять процедуры исправления случайных неисправностей и (или) плановых замен системных элементов.

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

f) инициировать корректирующие действия по устранению ранее необнаруженных конструкционных ошибок.

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

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

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

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

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

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

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

5.5.12.1 Цель процесса изъятия и списания

Цель процесса изъятия и списания состоит в прекращении существования системного объекта.

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

5.5.12.2 Результаты процесса изъятия и списания

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

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

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

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

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

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

5.5.12.3 Деятельность в процессе изъятия и списания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1 Введение

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

6.2 Модели жизненного цикла

Должна быть создана модель жизненного цикла, состоящая из стадий.

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

6.3 Стадии жизненного цикла

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

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

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

Процесс адаптации

А.1 Введение

В данном приложении сформулированы требования для адаптации настоящего стандарта.

А.2 Процесс адаптации

А.2.1 Цель процесса адаптации

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

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

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

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

А.2.2 Результаты процесса адаптации

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

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

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

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

А.2.3 Деятельность в процессе адаптации

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

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

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

2) коммерческие или эксплуатационные риски, касающиеся заинтересованных сторон;

3) новизну, размеры и сложность;

4) дату начала и продолжительность применения;

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

6) вновь возникающие технологические возможности;

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

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

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

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

1) правообладатели системы;

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

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

d) решения по адаптации принимаются в соответствии с процессом принятия решений;

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

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

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

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

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

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

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

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

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

Стадии жизненного цикла

В.1 Введение

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

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

a) стадия замысла;

b) стадия разработки;

c) стадия производства;

d) стадия применения;

e) стадия поддержки применения;

f) стадия прекращения применения и списания.

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

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

В.2.1 Краткий обзор

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

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

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

В.2.2 Цель стадии замысла

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

В.2.3 Результаты стадии замысла

Результаты выполнения стадии замысла перечислены ниже:

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

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

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

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

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

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

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

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

j) удовлетворение критерием завершения данной стадии;

k) санкционирование перехода на стадию разработки.

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

В.3.1 Краткий обзор

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

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

В.3.2 Цель стадии разработки

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

В.3.3 Результаты стадии разработки

Результатами стадии разработки являются:

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

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

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

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

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

f) техническая информация, в том числе:

1) диаграммы, чертежи и модели технических средств;

2) проектная программная документация;

3) спецификации интерфейсов;

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

5) рабочие инструкции;

6) руководства по тренингу операторов;

7) процедуры обслуживания;

8) особенности изъятия и списания;

g) прототип или непосредственно рассматриваемая система в окончательном виде;

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

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

j) планы и критерии завершения стадии производства;

k) идентифицированные текущие риски и определенные действия по их уменьшению;

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

m) санкционирование перехода на стадию производства.

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

В.4.1 Краткий обзор

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

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

Данная стадия может пересекаться со стадиями разработки, применения по назначению и поддержки в процессе применения.

В.4.2 Цель стадии производства

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

В.4.3 Результаты стадии производства

Результаты стадии производства перечислены ниже:

a) оцениваются возможности производства;

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

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

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

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

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

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

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

i) удовлетворяется критерий завершения стадии производства; j) санкционируется переход на стадию применения.

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

В.5.1 Краткий обзор

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

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

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

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

В.5.2 Цель стадии применения

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

В.5.3 Результаты стадии применения

Результаты стадии применения перечислены ниже:

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

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

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

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

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

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

g) фиксируется удовлетворение критерия завершения данной стадии;

h) санкционируется переход на стадию изъятия и списания.

В.6 Стадия поддержки применения

В.6.1 Краткий обзор

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

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

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

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

В.6.2 Цель стадии поддержки применения

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

В.6.3 Результаты стадии поддержки применения

Результаты стадии поддержки применения перечислены ниже:

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

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

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

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

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

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

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

h) устанавливается соответствие критерию завершения стадии.

В.7 Стадия изъятия и списания

В.7.1 Краткий обзор

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

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

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

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

В.7.2 Цель стадии изъятия и списания

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

В.7.3 Результаты стадии изъятия и списания

Результаты стадии изъятия и списания перечислены ниже:

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

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

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

d) удаляются отходы;

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

f) обеспечивается архивирование элементов;

g) проводится перемещение, перевод или увольнение операторов;

h) констатируется удовлетворение критерия завершения стадии изъятия и списания.

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

Взаимосвязь между ИСО/МЭК 15288 и Изменением № 1 к ИСО/МЭК 12207

С.1 Представление в виде диаграммы

Рисунок С.1 - Взаимосвязь между ИСО/МЭК 15288 и Изменением № 1 к ИСО/МЭК 12207

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

С.2 Представление в виде таблицы

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

Графы 2, 3 и 4 таблицы С.1 служат для определения того, какой из документов в большей степени отражает специфику процесса:

a) наличие символав графе 2 означает, что предпочтение отдано процессам, представленным в ИСО/МЭК 15288;

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

c) наличие символа  в графе 4 свидетельствует о том, что предпочтение отдано процессам, представленным в Изменении № 1 к ИСО/МЭК 12207.

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

a) в ИСО/МЭК 15288 деятельность по усовершенствованию распределяется между несколькими процессами, тогда как в Изменении № 1 к ИСО/МЭК 12207 такая деятельность осуществляется в ходе процесса усовершенствования;

b) в Изменении № 1 к ИСО/МЭК 12207 мероприятия по управлению рисками распределяются между несколькими процессами, тогда как в ИСО/МЭК 15288 они включаются в процесс управления рисками.

Таблица С.1 - Взаимосвязь между ИСО/МЭК 15288 и Изменением № 1 к ИСО/МЭК 12207

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

Концепции

D.1 Системные концепции

D.1.1 Введение

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

D.1.2 Системы

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

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

На рисунке D.1 представлено множество примеров восприятия системы самолета и его эксплуатационной среды. На рисунке проиллюстрированы следующие аспекты:

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

Рисунок D.1 - Стандартное представление системы самолета в среде его использования

b) иерархическое восприятие физической структуры системы;

c) объект любого уровня иерархической структуры может рассматриваться как система;

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

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

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

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

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

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

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

D.1.3 Структура системы

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

Рисунок D.2 - Взаимосвязь между системой и системными элементами

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

Рисунок D.3 - Структура рассматриваемой системы

D.1.4 Иерархия систем и проектов

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

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

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

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

D.1.5 Обеспечивающие системы

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

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

Рисунок D.4 - Иерархия систем и проектов

Рисунок D.5 - Рассматриваемая система, среда функционирования и обеспечивающие системы

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

D.2 Концепции жизненного цикла системы

D.2.1 Модель жизненного цикла

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

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

D.2.2 Стадии жизненного цикла

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

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

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

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

Таблица D.1 - Пример стадий, их целей и основных схем решений

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

D.2.3 Стадии рассматриваемой системы и обеспечивающих ее систем

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

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

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

Рисунок D.6 - Взаимодействие системы со стандартными обеспечивающими системами

D.3 Концепции процесса

D.3.1 Процессы жизненного цикла

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

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

D.3.2 Ответственность и соглашения внутри и между организациями

D.3.2.1 Ответственность за процесс

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

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

D.3.2.2 Процессы заключения соглашения

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

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

D.3.2.3 Процессы предприятия

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

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

D.3.2.4 Процессы проекта

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

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

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

D.3.2.5 Технические процессы

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

D.3.3 Применение процессов

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

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

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

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

Рисунок D.8 - Процессы жизненного цикла системы

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

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

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

[1]	ИСО 6385:1981	Эргономические принципы в проектировании рабочих систем
	(ISO 6385:1981)	(Ergonomic principles in the design of work systems)
[2]	ИСО/МЭК 7498-1:1994	Информационная технология. Взаимодействие открытых систем. Базовая эталонная модель: Базовая модель
	(ISO/IEC 7498-1:1994)	(Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model)
[3]	ИСО 9000:2000	Системы менеджмента качества. Основные положения и словарь
	(ISO 9000:2000)	(Quality management systems - Fundamentals and vocabulary)
[4]	ИСО 9001:2000	Системы менеджмента качества. Требования
	(ISO 9001:2000)	(Quality management systems - Requirements)
[5]	ИСО 9004:2000	Системы менеджмента качества. Руководство по выполнению усовершенствований
	(ISO 9004:2000)	(Quality management systems - Guidelines for performance improvements)
[6]	ИСО/МЭК 9126-1:2001	Программная инженерия. Качество программного продукта. Часть 1. Модель качества
	(ISO/IEC 9126-1:2001)	(Software engineering - Product quality - Part 1: Quality model)
[7]	ИСО/МЭК ТО 9126-2	Программная инженерия. Качество программного продукта. Часть 2. Внешние показатели
	(ISO/IEC TR 9126-2)	(Software engineering - Product quality - Part 2: External metrics)
[8]	ИСО/МЭК TO 9126-3	Программная инженерия. Качество программного продукта. Часть 3. Внутренние показатели
	(ISO TR 9126-3)	(Software engineering - Product quality - Part 3: Internal metrics)
[9]	ИСО/МЭК ТО 9126-4	Информационная технология. Качество программного продукта. Часть 4. Показатели качества при использовании
	(ISO TR 9126-4)	(Software engineering - Product quality - Part 4: Quality in use metrics)
[10]	ИСО 9241-2	Эргономические требования для работ в офисе с визуальными дисплейными терминалами задач. Часть 2. Руководство по требованиям к задачам
	(ISO 9241-2)	(Ergonomic requirements for office work with visual display terminals (VDTs) - Part 2: Guidance on task requirements)
[11]	ИСО 10007	Менеджмент качества. Руководство по менеджменту конфигурации
	(ISO 10007)	(Quality management - Guidelines for configuration management)
[12]	ИСО 10075	Эргономические принципы относительно умственной загрузки. Основные термины и определения
	(ISO 10075)	(Ergonomic principles related to mental workload - General terms and definitions)
[13]	ИСО 13407	Человеко-ориентированные процессы проектирования для интерактивных систем
	(ISO 13407)	(Human-centered design processes for interactive systems)
[14]	ИСО 14001:1996	Системы управления среды. Спецификация с руководством по использованию
	(ISO 14001:1996)	(Environmental management systems - Specification with guidance for use)
[15]	ИСО/МЭК 15026:1998	Информационная технология. Уровни целостности систем и программных средств
	(ISO/IEC 15026:1998)	(Information technology - System and software integrity levels)
[16]	ИСО/МЭК TO 15271	Информационная технология. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)
	(ISO/IECTR 15271)	(Information Technology - Guide for ISO/IEC 12207 (Software Life Cycle Processes)
[17]	ИСО/МЭК TO 15504 (все части)	Информационная технология. Оценка программного процесса
	(ISO/IEC TR 15504) (all parts)	(Information Technology - Software process assessment)
[18]	ИСО TO 18529	Эргономика. Эргономика взаимодействия человек-система. Описания процесса человекоориентированного жизненного цикла
	(ISO TR 18529)	(Ergonomics - Ergonomics of human-system interaction - Human-centered lifecycle process descriptions)
[19]	МЭК 61508	Функциональная безопасность электрических /электронных/ программируемых электронных систем, связанных с безопасностью
	(IEC 61508)	(Functional safety of electrical /electronic/ programmable electronic safety-related systems)
[20]	PMBOK:2000	Руководство для органа знаний по управлению проектами
		(A Guide to the Project Management Body of Knowledge (PMBOK Guide):2000 Project Management Institute, Inc, Newtown Square, PA 19073-3299 USA)
[21]1)	ИСО/МЭК 15939:2001	Информационная технология. Программная инженерия. Процесс измерения программных средств
	(ISO/IEC 15939:2001)	(Information Technology - Software engineering - Software measurement process)

¹⁾ Ссылка на данный стандарт отсутствует в оригинале и добавлена в библиографию при переводе.