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

5

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

6

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

5.1

Введение

Удалено

5.2

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

6.1

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

Нумерация

5.2.1

Введение

6.1

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

Объединены в 6.1; удален отдельный пункт

5.2.2

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

6.1.1

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

Нумерация

5.2.3

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

6.1.2

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

Нумерация

5.3

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

6.2

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

Тема и название пересмотрены; нумерация

5.3.1

Введение

6.2

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

Объединены в 6.2; удален отдельный пункт

5.3.2

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

6.2.2

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

Тема и название пересмотрены; нумерация

5.3.3

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

6.2.3

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

Тема и название пересмотрены; нумерация

5.3.4

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

6.2.1

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

Название пересмотрено; нумерация

5.3.5

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

6.2.2

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

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

6.2.4

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

5.3.6

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

6.2.5

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

Нумерация

5.4

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

6.3

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

Нумерация

5.4.1

Введение

6.3

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

Объединены в 6.3; удален отдельный пункт

5.4.2

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

6.3.1

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

Нумерация

5.4.3

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

6.3.2

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

Процессы объединены; нумерация

5.4.4

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

5.4.5

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

6.3.3

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

Нумерация

5.4.6

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

6.3.4

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

Нумерация

5.4.7

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

6.3.5

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

Нумерация

5.4.8

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

6.3.6

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

Нумерация

6.3.7

Процесс измерений

Добавлено

5.5

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

6.4

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

Нумерация

5.5.1

Введение

6.4

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

Объединены в 6.4; удален отдельный пункт

5.5.2

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

6.4.1

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

Нумерация

5.5.3

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

6.4.2

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

Нумерация

5.5.4

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

6.4.3

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

Нумерация

5.5.5

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

6.4.4

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

Нумерация

5.5.6

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

6.4.5

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

Нумерация

5.5.7

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

6.4.6

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

Нумерация

5.5.8

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

6.4.7

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

Нумерация

5.5.9

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

6.4.8

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

Нумерация

5.5.10

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

6.4.9

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

Нумерация

5.5.11

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

6.4.10

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

Нумерация

5.5.12

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

6.4.11

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

Нумерация

Annex A

Процесс адаптации

Приложение A

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

Название пересмотрено

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

6.1.1.3

6.2, 6.3, 6.4

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

1) возможности сбыта;

2) бизнес-политика;

3) окружающая среда организации;

4) готовность финансовых ресурсов;

5) человеческие факторы;

6) стратегия совершенствования;

7) интеграция и интероперабельность;

8) логистика;

9) устаревание;

10) эксплуатационная среда;

11) производительность;

12) техногенная безопасность;

13) защищенность;

14) конкурентоспособность;

15) цели заинтересованных сторон;

16) жизнеспособность;

17) ограничения рынка по времени;

18) потенциальные риски для приобретения и поставки

6.1.1.3 a) 1)

c) План приобретения разрабатывают с использованием процесса планирования проекта

6.1.1.3 a)

6.3.1

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

6.1.1.3 b)

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

6.1.1.3 c)

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

6.1.1.3 d)

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

6.1.1.3 e)

6.4.6

6.4.8

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

6.1.2.3

6.2, 6.3, 6.4

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

6.1.2.3 a)

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

6.1.2.3 a)

d) Используя процесс планирования проекта, разрабатывают план поставки

6.3.1

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

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

2) бизнес-цели единицы;

3) конкурентоспособность;

4) окружающую среду организации, политику и процедуры;

5) готовность ресурсов;

6) соответствующие риски в управлении, технические и ресурсные риски

6.1.2.3 b)

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

6.1.2.3 b)

6.1.2.3 c)

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

6.1.2.3 d)

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

6.1.2.3 e)

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

6.2.1.3 a)

6.2.1.3 b)

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

6.2.1.3 a)

6.2.1.3 b)

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

6.2.1.3 b)

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

6.2.1.3 b)

6.2.1.3 c)

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

6.2.1.3 b)

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

6.2.2.3 a)

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

6.2.2.3 b)

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

6.2.3

6.2.3 a)

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

6.2.3 b)

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

6.2.3 b)

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

6.2.3 a)

6.2.3 b)

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

6.2.3.3 b)

6.2.3.3 c)

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

6.2.4

b) Услуги человеческих ресурсов включают (но не следует этим ограничиваться):

1) приобретение ресурса;

6.2.4 a)

6.2.4 b)

2) оценку навыков (мастерства);

3) развитие навыков (мастерства);

4) измерение уровня навыков (мастерства);

5) эффективное применение навыков (мастерства) сообразно организационным потребностям;

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

7) обретение знаний, накопление и повторное применение

6.2.4 c)

6.2.4 d)

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

6.2.4 a)

6.2.4 b)

6.2.4 c)

a) Этот процесс совместим с установлением подходов управления качеством, которые приводят к соответствию с ИСО 9001

6.2.5

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

6.2.5 a)

6.2.5 b)

4) руководить работой, требуемой для удовлетворения требованиям установленного соглашения

6.3.1.3 b) и c)

5) перепланировать работу

6.3.1.3 a) 1) и b) 2)

b) Планы ограничены организационными целями и задачами и потребностями заинтересованных сторон

6.3.1.3 a)

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

6.3.1.3

d) Перепланирование обычно начинается:

1) когда это требуется в соответствии с соглашением;

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

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

6.3.1.3 a)

6.3.2

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

6.3.1.3 a) 1)

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

6.3.1.3 a)

6.3.1.3 b)

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

6.3.1.3 a) 4)

6.3.2

6.3.3

6.3.4

6.3.5

6.3.6

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

6.3.1.3 a) 4)

6.3.2

6.3.3

6.3.4

6.3.5

6.3.6

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

6.3.1.3 b) 1) и 2)

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

6.3.1.3 b) 3)

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

6.3.1.3 b) 6)

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

6.3.1.3 c) 1)

n) Инженерный план применим для каждой стадии организационного представления и для каждого проекта (для системной инженерии или реинженерии) с использованием V-модели инженерии

6.3.1.3 c) 1)

o) Инженерный план также известен как план управления системной инженерии (SEMP) или как комплексный план управления (IMP)

6.3.1.3 c) 1)

a) Существуют формализованные методы по управлению стоимостью и расписанием. Примеры включают:

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

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

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

6.3.2.3 a)

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

1) для определения содержательности и соответствия проектных планов (управленческого и технического);

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

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

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

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

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

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

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

9) оценки эффективности технологий сбора, обработки и доведения данных;

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

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

6.3.2.3 a)

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

1) продвижения проекта;

2) информации для реакции на риски;

3) значимых финансируемых и нефинансируемых работ;

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

6.3.2.3 a)

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

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

2) приверженность методам и процедурам;

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

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

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

6.3.2.3 a)

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

6.3.2.3 a) 1)

6.3.2.3 a) 4)

6.3.2.3 a) 6)

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

6.3.2.3 a) 5) и 6)

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

6.3.2.3 a) 5)

и 8)

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

6.3.2.3 a) 2)

и 6)

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

6.3.2.3 a) 4) 5) и 6)

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

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

6.3.2.3 a) 5)

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

6.3.2.3 a) 6)

m) Типичные цели технического анализа включают определение:

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

2) прослеживаемости требований, обоснованности предположений и рациональности решений;

3) нерешенных проблем и тех проблем, которые не определены во время проектной работы;

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

6.3.2.3 a) 6)

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

6.3.2.3 a) 6)

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

6.3.2.3 a) 7) - 9)

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

6.3.2.3 b)

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

6.3.2.3 b)

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

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

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

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

6.3.3.3 a)

и b)

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

6.3.3.3 a) 2),

b) 1) и c)

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

6.3.4.1

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

6.3.4.3 a)

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

6.3.4.3 a)

d) Управление рисками предусматривает:

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

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

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

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

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

6.3.4.3 a)

e) Инструментарии для управления рисками предусматривают средства:

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

2) анализа риска - модели воздействия, вероятностные модели, диаграмма Ганта, распределение воздействия, связи рисков, структура системы или взаимодействия структуры распределения работ и таблицы серии стандартов ИСО для оценки риска;

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

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

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

6.3.4.3 a)

f) подходы к успешному управлению рисками предусматривают:

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

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

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

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

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

6.3.4.3 a)

g) Есть три категории риска для рассмотрения:

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

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

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

6.3.4.3 b)

и c)

h) Альтернативные подходы к реакции на риски включают:

1) принятие (адаптация);

2) избегание (исключают);

3) защиту (избыточность);

4) сокращение (смягчение - культура управления рисками - выполнение правильных процессов);

5) предотвращение (деятельность команды - использование объединенных команд);

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

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

8) исследования (больше информации);

9) резервирование (обеспечение непредвиденного);

10) передачу (другому человеку или организации)

6.3.4.3 d)

и e)

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

6.3.4.3 f)

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

6.3.5.3

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

6.3.5.3 a) 2)

6.3.4

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

6.3.5.3 b)

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

6.3.6.3

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

6.3.7.3 a)

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

6.3.7.3 b)

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

6.3.7.3 c)

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

6.4.1.3

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

6.4.1.3 a)

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

6.4.1.3 a)

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

1) организационные и проектные требования, связанные с рынками систем и организационными процессами;

2) экологические, местные, национальные и международные регламенты и законы;

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

6.4.1.3 a)

Требование может также быть нефункциональным, то есть ограничением проекта, таким как вес или цвет

6.4.1.3 b)

и c)

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

6.4.1.3 b) 1)

g) Стоимость может быть требованием, заявленным как фиксированные расходы (независимая переменная) или как максимальная стоимость (ограничение)

6.4.1.3 b) 1)

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

6.4.1.3 b) 2)

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

6.4.1.3 b) 2)

6.4.3

6.4.8

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

6.4.1.3 c)

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

6.4.1.3 c) 1) - 3)

l) Требования заинтересованных сторон - это основание для валидации (аттестации) реализованной или скомплексированной системы, которая разработана с использованием технических процессов

6.4.1.3 c) 2) - 5)

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

6.4.1.3 c) 6)

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

6.4.2.3 a) 4)

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

1) отсутствие избыточности - каждое требование задается только в один раз,

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

3) непротиворечивость - требование не вступает в противоречие с другими требованиями или не противоречит само себе

6.4.2.3 b) 1)

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

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

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

3) возможные физические решения;

4) новые взаимодействия, которые могут быть введены

6.4.2.3 b) 1)

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

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

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

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

4) разрешение выявленных неохваченных аспектов, различий и противоречий, включая:

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

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

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

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

6.4.2.3 b) 3)

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

6.4.3

b) Требования для обеспечивающих систем исходят:

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

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

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

6.4.3.3 a)

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

6.4.3.3 a)

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

6.4.3.3 a)

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

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

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

3) выполнение аппаратными средствами, программными средствами и микропрограммными физическими элементами (новыми или существующими)

6.4.3.3 a)

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

6.4.3.3 b)

6.4.3.3 c)

6.4.1

6.4.2

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

6.4.3.3 b)

6.4.3.3 c)

6.4.1

6.4.2

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

6.4.3.3 b) 2)

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

6.4.3.3 b)

6.4.3.3 c)

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

6.4.1

6.4.2

6.4.3

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

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

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

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

4) взаимодействия и характеристик взаимозаменяемости;

5) средств для верификации соответствия

6.4.3.3.1

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

6.4.3.3 c) 1)

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

6.4.3.3 c) 1)

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

6.4.3.3 c) 1)

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

1) как должно быть выполнено требование;

2) как должна быть построена система

6.4.3.3 c) 1)

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

6.4.3.3 c)

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

6.4.3.3 c)

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

6.4.3

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

6.4.4.3 a)

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

6.4.4.3 b)

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

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

2) изготовлены внутри организации, или

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

6.4.4.3 b)

d) Системные элементы, состоящие исключительно из программных элементов, могут быть:

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

2) закодированы внутри организации, или

3) повторно используемыми

6.4.4.3 b)

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

6.4.4.3 b)

f) Аспекты, учитываемые при формировании стратегии реализации, включают:

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

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

3) вопросы безопасности, защищенности, частной жизни и собственности, экологические факторы;

4) местоположение и окружающую среду реализации;

5) навыки (мастерство) специалистов, их готовность и устойчивость;

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

7) характеристики операторов;

8) период, после которого требуется повторная реализация

6.4.4.3 a)

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

6.4.4.3 b)

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

6.4.4.3 b)

a) До комплексирования систем низшего уровня в более сложную систему убеждаются в том, что каждая составная система соответствующим образом аттестована поставщиком или внутри организации

6.4.5.3 b)

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

6.4.5.3 b)

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

6.4.6.3 b)

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

6.4.7.3 a)

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

6.4.8.3 a)

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

6.4.8.3 a) и b)

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

6.4.8.3 b)

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

6.4.8.3 b)

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

6.4.9.3 a)

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

6.4.9.3 a)

c) Во время стадий замысла и стадий разработки в жизненном цикле план функционирования (эксплуатации) может выступать как один из планов проекта или системной инженерии

6.4.9.3 a)

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

6.4.10.3 a)

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

6.4.10.3 a)

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

6.4.10.3 a)

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

6.4.10.3 b)

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

6.4.11.3 a)

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

6.4.11.3 a)