Национальный стандарт РФ ГОСТ Р ИСО/МЭК 15288-2005 "Информационная технология. Системная инженерия. Процессы жизненного цикла систем" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 29 декабря 2005 г. N 476-ст) (документ не действует)

Национальный стандарт РФ ГОСТ Р ИСО/МЭК 15288-2005
"Информационная технология. Системная инженерия. Процессы жизненного цикла систем"
(утв. приказом Федерального агентства по техническому регулированию и метрологии от 29 декабря 2005 г. N 476-ст)

Information technology. System engineering. System life cycle processes

Дата введения - 1 января 2007 г.

Введен впервые

ГАРАНТ:

Приказом Росстандарта от 31 октября 2016 г. N 1538-ст взамен настоящего ГОСТа с 1 ноября 2017 г. введен в действие ГОСТ Р 57193-2016 "Системная и программная инженерия. Процессы жизненного цикла систем" для добровольного применения в РФ

См. ГОСТ Р ИСО/МЭК 12207-99 "Информационная технология. Процессы жизненного цикла программных средств"

Предисловие

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

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

1.1 Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Деятельность в процессе управления средой предприятия

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

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

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

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) процесс принятия решений;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Результаты процесса проектирования архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Деятельность в процессе валидации

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

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

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

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 Стадии жизненного цикла

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

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

______________________________

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

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

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

[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 (ISO/IEC 9126-1:2001)	Программная инженерия. Качество программного продукта. Часть 1. Модель качества (Software engineering - Product quality - Part 1: Quality model)
[7]	ИСО/МЭК ТО 9126-2 (ISO/IEC TR 9126-2)	Программная инженерия. Качество программного продукта. Часть 2. Внешние показатели (Software engineering - Product quality - Part 2: External metrics)
[8]	ИСО/МЭК ТО 9126-3 (ISO TR 9126-3)	Программная инженерия. Качество программного продукта. Часть 3. Внутренние показатели (Software engineering - Product quality - Part 3: Internal metrics)
[9]	ИСО/МЭК ТО 9126-4 (ISO TR 9126-4)	Информационная технология. Качество программного продукта. Часть 4. Показатели качества при использовании (Software engineering - Product quality - Part 4: Quality in use metrics)
[10]	ИСО 9241-2 (ISO 9241-2)	Эргономические требования для работ в офисе с визуальными дисплейными терминалами задач. Часть 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]	ИСО/МЭК ТО 15271 (ISO/IEC TR 15271)	Информационная технология. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств) (Information Technology - Guide for ISO/IEC 12207 (Software Life Cycle Processes)
[17]	ИСО/МЭК ТО 15504 (все части)	Информационная технология. Оценка программного процесса
	(ISO/IEC TR 15504) (all parts)	(Information Technology - Software process assessment)
[18]	ИСО ТО 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]*	ИСО/МЭК 15939:2001 (ISO/IEC 15939:2001)	Информационная технология. Программная инженерия. Процесс измерения программных средств (Information Technology - Software engineering - Software measurement process)

______________________________

* Ссылка на данный стандарт отсутствует в оригинале и добавлена в библиографию при переводе.