ГОСТ Р 56923-2016 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

ГОСТ Р 56923-2016/
ISO/IEC TR 24748-3:2011

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

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

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Управление жизненным циклом

Часть 3

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

(Процессы жизненного цикла программных средств)

Information technologies. Systems and software engineering. Life cycle management. Part 3. Guide to the application of ISO/IEC 12207 (Software life cycle processes)

ОКС 35.080

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

Предисловие

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

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

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

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

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

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

Введение

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

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

- часть 2. Руководство по применению ИСО/МЭК 15288 (процессы жизненного цикла систем);

- часть 3. Руководство по применению ИСО/МЭК 12207 (процессы жизненного цикла программных средств).

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

- ИСО/МЭК 15288 (ИСО/МЭК 15288 Информационная технология. Системная инженерия. Процессы жизненного цикла систем);

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

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

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

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

Настоящий стандарт уточняет факторы, которые должны быть рассмотрены при применении ИСО/МЭК 12207, и делает это в контексте различных способов применения ИСО/МЭК 12207. Руководство не предназначено для объяснения требований ИСО/МЭК 12207. Прежде, чем знакомиться с настоящим стандартом, читатели должны понимать отношения между системой и программными средствами, владеть понятиями "рассматриваемой системы" и структуры системы. Эти понятия описаны в ИСО/МЭК 24748-1.

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

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

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

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

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

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

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

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

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

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

3.2 Структура

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

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

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

- разделов приложения А, обеспечивающего требования приспособления ИСО/МЭК 12207;

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

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

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

- приложение D описывает соответствие процессов ИСО/МЭК 15288 и ИСО/МЭК 12207;

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

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

- приложение G оказывает поддержку пользователям IEEE и описывает связь стандарта ИСО/МЭК 12207 со стандартами IEEE.

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

3.3 Контекст

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

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

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

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

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

Пример:

Примером типовых стадий являются:

s1: Концепция

s2: Разработка

s3: Эксплуатация

s4: Сопровождение.

Примечание - Стадии описаны в ИСО/МЭК 12207 (пункт 5.1.12) и ИСО/МЭК 24748-1 (3.2, разделах 4 и 5).

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

Примечания

1 Роль и использование обеспечивающих систем описаны в 4.6.3.

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

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

Примечания

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

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

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

Примечания

1 Связанные проектные понятия описаны в 4.6.

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

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

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

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

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

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

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

3.4 Сравнение с предыдущими версиями

ИСО/МЭК 12207 был издан 1 августа 1995 и был первым Международным стандартом, который обеспечил исчерпывающий набор процессов жизненного цикла, деятельности и задач как для программных средств, являющихся частью большей системы, так и для автономных программных продуктов и услуг. За этим международным стандартом последовал в ноябре 2002 стандарт ИСО/МЭК 15288, который обратился к процессам жизненного цикла систем. Повсеместность программных средств означала, что они и процессы проекта нельзя рассмотреть отдельно от систем, они должны быть рассмотрены как неотъемлемая часть процессов проекта и системы в целом. Дополнения к ИСО/МЭК 12207 в 2002 г. и 2004 г. добавили цели и результаты процессов и установленную эталонную модель процесса в соответствии с требованиями ИСО/МЭК 15504-2.

ИСО/МЭК 12207 объединяет ИСО/МЭК 12207 с его двумя дополнениями и обеспечивает лучшее определение процесса для поддержки содержательности и улучшения его применимости.

Примечание

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

2 Рисунок 18 ИСО/МЭК 24748-1 показывает изменения структуры процесса после обновления 2008 г.

3 Рисунок 20 ИСО/МЭК 24748-1 предоставляет информацию относительно источника условий в гармонизированном множестве разделов по процессам в ИСО/МЭК 12207.

4 Рисунок 21 ИСО/МЭК 24748-1 обеспечивает связь между множеством разделов по процессам в ИСО/МЭК 12207 и ИСО/МЭК 12207.

5 Рисунок 22 ИСО/МЭК 24748-1 обеспечивает обратную связь между множеством разделов по процессам в ИСО/МЭК 12207 и ИСО/МЭК 12207.

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

4.1 Обзор

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

Примечание

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

2 Далее по тексту положения, относящиеся к ИСО/МЭК 12207, излагаются применительно к ИСО/МЭК 12207.

4.2 Понятия программных средств

4.2.1 Понятия системы и программных средств

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

Примечание

1 Системные понятия введены в ИСО/МЭК 15288 (5.1). Дополнительные обсуждения, такие как системы и структура системы, предоставлены в ИСО/МЭК 24748-1 (3.1).

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

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

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

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

Примечание - Отношения между системами и программными средствами введены в ИСО/МЭК 12207 (пункт 5.1.2).

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

Рисунок 2 - Место программных средств в системе

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

Рисунок 3 - Компьютеризированная система в организации

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

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

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

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

4.4.1 Общее

4.4.1.1 Введение

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

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

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

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

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

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

Примечания

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

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

3 ИСО/МЭК 24774 обеспечивает руководящие принципы для описания процессов.

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

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

4.4.1.2 Входы

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

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

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

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

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

4.4.1.3 Выходы

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

4.4.1.4 Управление

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

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

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

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

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

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

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

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

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

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

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

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

4.4.2.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

2 Организации и стороны обсуждены в 4.5.

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

4.4.3.1 Общее

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

Группы процесса в контексте системы:

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

- процессы организационного обеспечения проекта;

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

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

Группы специальных процессов программных средств:

- процессы реализации программных средств;

- процессы поддержки программных средств;

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

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

Примечание - Категории процесса жизненного цикла объединены в ИСО/МЭК 12207 (подпункт 5.2.1). Суть процессов представлена в подпункте 5.2.2. Всесторонние обсуждения даны в разделах 6 и 7.

4.4.3.2 Категории процесса в контексте системы

Процессы в контексте системы представлены на рисунке 5.

Рисунок 5 - Процессы в контексте системы

Процессы в контексте системы

Рисунок 5 - Процессы в контексте системы

Примечание - Суть процессов контекста системы представлена в ИСО/МЭК 12207 (подпункт 5.2.2.1). Всестороннее обсуждение дано в разделе 6.

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

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

Рисунок 6 - Роль процессов в контексте системы

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

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

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

4.4.3.3 Категории специальных процессов программных средств

Специальные процессы программных средств представлены на рисунке 8.

Примечание - Суть специальных процессов программных средств представлена в ИСО/МЭК 12207 (подпункт 5.2.2.2). Всестороннее обсуждение представлено в разделе 7.

Рисунок 8 - Специальные процессы программных средств

Специальные процессы программных средств

Рисунок 8 - Специальные процессы программных средств

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

Рисунок 9 - Роль специальных процессов программных средств

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

4.4.4.1 Общее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.5.1 Общее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.6.1 Общее

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

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

Примечания

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

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

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

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

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

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

Примечание - Стандарт IEEE 1490 Принятие стандарта Института PMI: Руководство органам знаний по управлению проектами (Adoption of PMI Standard: A Guide to the Project Management Body of Knowledge) предоставляет больше информации о проектах и руководстве проектом.

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

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

Рисунок 12 - Роли соглашения

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

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

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

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

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

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

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

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

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

1) стоимость и ограничения по плану;

2) "контрольные точки" реализации;

3) сроки оплаты;

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

5) ответственности верификации и аттестации (аттестации);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.7.1 Общее

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

Примечания

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

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

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

Примечание - Требования ИСО/МЭК 12207 содержатся в разделах 6 и 7, и приложении А.

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

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

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

Примечание - Соответствия стандарту отражено в ИСО/МЭК 12207 (подпункт 5.1.4).

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

4.7.2 Адаптация

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

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

b) обоснование процесса: многие из процессов ИСО/МЭК 12207 описаны как "специализации" процессов в ГОСТ Р ИСО/МЭК 15288. Как основание для соответствия предоставляется явное разрешение для использования процесса уровня системы, а не процесса уровня программных средств;

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

5.1 Обзор

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

Примечание - Применение ИСО/МЭК 12207 введено в разделе 5.

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

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

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

5.2.1 Обзор

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

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

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

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

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

а) запланируйте применение;

b) если возможно, садаптируйте ИСО/МЭК 12207;

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

d) формализуйте подход;

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

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

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

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

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

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

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

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

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

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

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

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

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

а) запланируйте применение;

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

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

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

Применение ИСО/МЭК 12207 должно рассматриваться как определенный проект и планироваться как проект.

Примерами положений при планировании проекта применения являются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.4 Формализуйте подход

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

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

5.2.5 Утвердите подход

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

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

5.3.1 Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- установление эталона, относительно которого могут быть разработаны программы усовершенствования, например аудит согласно ИСО/МЭК 12207.

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

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

5.3.5 Использования внутри организации

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

Рисунок 16 - Три типа использования ИСО/МЭК 12207-2008

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

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

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

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

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

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

5.4.1 Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

c) реализация и прохождение контрольных точек;

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

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

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

Примечание - IEEE 1062-1998 обеспечивает дополнительное руководство относительно процесса приобретения, включая выбор поставщика.

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

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

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

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

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

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

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

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

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

5.4.3.1 Общее

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

- процесс функционирования программного средства;

- процесс сопровождения программного средства;

- процесс прекращения применения программного средства.

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

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

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

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

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

Примечание - См. 5.4.4 для применения процессов реализации программного средства к проекту.

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

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

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

5.4.3.2.1 Общее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3.2.4.1 Общее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I) диаграмма IDEF0.

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

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

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

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

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

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

5.4.3.2.4.3.1 Общее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3.3.1 Общее

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

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

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

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

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

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

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

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

5.4.3.3.4 Процесс квалификационного тестирования системы

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

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

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

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

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

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

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

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

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

5.4.3.3.5 Процесс инсталляции программных средств

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

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

5.4.3.3.6 Процесс поддержки приемки программных средств

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3.4.1 Общее

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

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

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

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

5.4.3.4.3 Процесс сопровождения

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

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

5.4.3.4.4 Процесс прекращения применения

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

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

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

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

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

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

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

5.4.4 Применение процессов реализации программных средств к проекту

5.4.4.1 Обзор

Рисунок 21 обеспечивает модель для применения процессов реализации программного средства по ИСО/МЭК 12207.

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

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

5.4.4.2.1 Общее

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

5.4.4.2.2 Процесс анализа требований программных средств

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

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

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

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

5.4.4.2.4 Процесс детального проектирования программных средств

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

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

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

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

Рекурсивное применение первых трех процессов на рисунке 21 повторяется в пределах структуры системы до тех пор, пока процесс конструирования программных средств окажется неприменимым для элемента программных средств и пока все элементы программных средств не будут построены.

5.4.4.3 Соответствующие процессы реализации программного средства

5.4.4.3.1 Общее

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

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

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

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

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

5.4.4.3.3 Процесс комплексирования программных средств

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

5.4.4.3.4 Процесс квалификационного тестирования программных средств

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

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

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

5.4.5.1 Обзор

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

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

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

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

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

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

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

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

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

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

5.4.5.2.1 Подходы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.5.2.2.1 Общее

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

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

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

5.4.5.2.2.2 Применимые системы

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

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

5.4.5.2.2.3 Риски

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

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

b) из команд могут уйти знающие работники;

c) может измениться персонал, принимающий решения в организации;

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

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

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

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

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

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

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

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

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

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

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

5.4.5.2.3.1 Общее

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

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

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

5.4.5.2.3.2 Применимые системы

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

5.4.5.2.3.3 Риски

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.5.2.4.1 Общее

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

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

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

5.4.5.2.4.2 Применимые системы

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

5.4.5.2.4.3 Риски

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.5.3.1 Общее

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

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

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

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

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

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

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

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

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

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

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

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

5.4.5.3.2 Технические ревизии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели физического аудита представлены ниже:

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

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

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

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

5) обеспечить основания для одобрения дальнейшего производства системы, если применимость имеет место.

Приложение А (справочное). Примечания для применения процессов ИСО/МЭК 12207

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

А.1 Общее

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

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

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

Примечание - IEEE/EIA 12207.2-1997 использовался как один из источников для следующих положений.

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

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Чтобы должным образом выполнить действия и задачи процесса приобретения, следует реализовать соответствующим образом применяемые процессы организационного обеспечения проекта, процессы проекта, технические процессы, процессы реализации и процессы поддержки программных средств	6.1.1.3 6.2, 6.3, 6.4	6.1.1.3 6.2, 6.3, 6.4 7.1, 7.2
b) Обычно в любой ситуации приобретения есть несколько подходов или способов сделать что-либо. Желателен подход или путь, который лучше всего ведет к достижению целей приобретения при ограничениях. Для использования учитываются: 1) Возможности сбыта; 2) Деловая политика; 3) Окружающая среда организации; 4) Готовность финансовых ресурсов; 5) Человеческие факторы; 6) Стратегия усовершенствования; 7) Интеграция и интероперабельность; 8) Логистика (поддерживаемость); 9) Устаревание; 10) Эксплуатационная окружающая среда; 11) Производительность; 12) Техногенная безопасность; 13) Безопасность; 14) Конкурентоспособность; 15) Цели заинтересованной стороны; 16) Жизнеспособность; 17) Ограничения рынка по времени; 18) Потенциальные риски для приобретения и поставки	6.1.1.3 а) 1)	6.1.1.3.1
с) Для определения замысла с помощью системы, программных продуктов или услуг, которые будут приобретены, должны быть использованы все воздействующие дисциплины. Эксплуатационный замысел должен изменяться/обновляться периодически для отражения текущих потребностей Эксплуатационный замысел должен быть направлен на полный жизненной цикл (приобретение, поставку, реализацию, функционирование, сопровождение) системы, программного продукта или услуг. Описание эксплуатационного замысла может быть использовано для: 1) получения согласия между приобретающей стороной, поставщиком, конструктором (исполнителем), сопровождающей стороной и пользователями на эксплуатационный замысел и замысел сопровождения предлагаемой системы; 2) помощи пользователям для понимания и адаптации к необходимым эксплуатационным изменениям и изменениям в сопровождении как результат модификаций при реинжениринге, дополнении новых способностей или иных модификациях		6.1.1.3.1.1
d) Требования системы должны быть написаны на соответствующем уровне, основанном на уровне знания об эксплуатационном замысле и системе, которая будет приобретена. Требования к системе развиваются, поскольку знание получаются всеми вовлеченными сторонами. Многие методы доступны для использования в определении требований системы (например, исследование замысла, прототипирование)		6.1.1.3.1.2
е) Определение безопасности системы и требования к безопасности должны также включать то, что не должна делать система		6.1.1.3.1.2
f) В системах, содержащих программные средства с требованиями безопасности, может быть уместным применить стандарт IEEE Std 1228, Стандарт IEEE для планов безопасности программных средств. Учет программных средств при сертификации бортовых систем и оборудования (IEEE Standard for Software Safety Plans. RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification), ссылка на него также может оказаться полезной		6.1.1.3.1.2
g) В системах, содержащих программные средства с высокими требованиями зависимости, может быть уместно применить стандарт IEEE Std 982.1, Стандарт IEEE Словарь показателей зависимости в программных аспектах (IEEE Standard Dictionary of Measures of the Softw* areaspects of Dependability), чтобы сформулировать измеримые требования зависимости		6.1.1.3.1.2
___________________ * Текст документа соответствует оригиналу. - .
h) Приобретающая сторона должна гарантировать, что получающиеся требования системы обеспечивают соответствующую гибкость для проектирования, модификаций или расширения поставляемых систем. Например, в соответствующих ситуациях требования системы могут включать подход "открытых систем". Альтернативно требования системы могут вызывать к использованию области применения специальной архитектуры или содержательные связи со специальной архитектурой или с архитектурой других программных систем в эксплуатационной окружающей среде		6.1.1.3.1.4
i) Рассматривая опции 6.1.1.3.1.6, приобретающая сторона должна запрашивать входы от потенциальных поставщиков		6.1.1.3.1.6
j) План приобретения готовится с использованием процесса планирования проекта	6.1.1.3 а) 6.3.1	6.1.1.3.1.8 6.3.1
k) План приобретения должен определить проектный процесс приобретения и должен описать отношения проектного процесса приобретения к организационному процессу приобретения		6.1.1.3.1.8
l) Для d) 6.1.1.3.1.8 поставщик ответственен за координацию контракта с субподрядчиком(ами). Если проект использует многофункциональные команды, приобретающая сторона и субподрядчик(и) могут также быть участниками команды		6.1.1.3.1.8
m) Приобретающая сторона должна установить и задокументировать в плане приобретения программу измерения программных средств. Программа должна использоваться, чтобы эффективно запланировать и отследить действия программных средств и задачи через жизненный цикл, нацеленность в управлении стоимостью, сроками, качеством и техническими рисками и объединить программные измерения с существующим управлением программными средствами и установленными для проекта дисциплинами		6.1.1.3.1.8
n) Так как приемка продукции или услуг обычно освобождает поставщика от ответственности по контракту, приобретающая сторона должна тщательно рассмотреть приемную стратегию и условия. Факторы для рассмотрения включают в себя: 1) степень, требования, и местоположение выполненного конструктором (исполнителем) квалификационного тестирования; 2) поддержку выполняемому приобретающей стороной функциональному тестированию; 3) установление соответствующей концепции сопровождения, включая запасные детали, поддерживающее оборудование и т.д.; 4) временную поддержку поставщика/конструктора (исполнителя); 5) успешную инсталляцию программных средств и передачу сопровождения; 6) обучение; 7) гарантии. Должны быть определены период договорной ответственности, а также обязательства поставщика после приемки приобретающей стороной		6.1.1.3.1.9
о) Приобретающая сторона должна определить уровень своего участия в течение выполнения проекта поставщиком, чтобы обеспечить необходимую программную продукцию или услугу		6.1.1.3.1.10
р) Приобретающая сторона может запрашивать в запросе на предложение доступ к проектным планам и данные планирования, предлагаемые процессы, стандарты и методы. Для доступа можно запрашивать: 1) оценки и ссылки во время выбора поставщика и во время реализации/сопровождения/функционирования; 2) поддержку после передачи в случае необходимости. В течение исходного выбора и контрактных переговоров следует провести ревизию приобретающей стороной планов и других специально определенных процедур, методов и рабочих продуктов, когда это приемлемо для проектных характеристик. В некоторых случаях ревизия может иметь место после заключения контракта		6.1.1.3.1.10
q) Приобретающая сторона может задать в запросе на предложение использование ИСО/МЭК 12207 и других критериев как основание для оценки процессов поставки и плана(ов) и сделать известными критерии оценки Если в качестве базовых определены более, чем один стандарт, должен быть установлен ясный порядок приоритетности, чтобы предотвратить противоречивые интерпретации		6.1.1.3.1.10
r) Приобретающая сторона должна использовать процесс проекта запроса на предложение, чтобы выявить входы от поставщиков, уточнить требования и договорные моменты		6.1.1.3.1.10
s) В запросе на предложение приобретающая сторона должна запросить описание структуры для определения показателей программных средств. Основы измерения программных средств должны определить гибкий процесс измерения, который непосредственно поддерживает процесс жизненного цикла программных средств и соответствующие задачи и действия на предмет того, как это реализовано для проекта. Процесс измерения должен быть основан на выборе и анализе соответствующих показателей программных средств, чтобы обратиться к определенным проектным источникам программных средств, ограничениям и целям, как определено приобретающей стороной и поставщиком. Данные измерения программного средства должны быть доступны приобретающей стороне и поставщику как части соглашения приобретающей стороны с поставщиком, предпочтительно автоматизированными методами доступа к данным		6.1.1.3.1.10 6.3.7
t) Приобретающая сторона должна включить в запрос на предложение определение потребности в независимой аттестации и верификации, совместных ревизиях, аудитах и процессе, который будет использоваться для обеспечения приобретающей стороны необходимой информацией от процессов реализации/сопровождения/функционирования		6.1.1.3.1.10
u) Также организация-исполнитель, как обозначено в этом пункте, обращается в соответствующих пределах к организации приобретающей стороны или поставщика, а не к эксплуатирующей организации (например, по управлению конфигурацией, обеспечению качества)		6.1.1.3.1.11
v) Приобретающая сторона должна рассмотреть установленные стандарты документации и предложенное поставщиком применение согласно проектной специфике и определить, удовлетворяет ли предложенная документация потребностям приобретающей стороны. Если приобретающая сторона нуждается в дополнительной или иной документации, чем предлагается в предложении поставщика, все задействованные стороны должны прийти к соглашению относительно документации во время контрактных переговоров или установить основы соглашения по последующему вознаграждению		6.1.1.3.1.11
w) Цель адаптации стандарта приобретающей стороной - определить область действий, которые будут охвачены в соответствии с контрактом. Структура процесса ИСО/МЭК 12207 может быть очень полезной в достижении эффективного взаимодействия между приобретающей стороной и поставщиком относительно действий, которые будут выполнены в ожидаемой работе		6.1.1.3.1.11
х) Во время исходного выбора и контрактных переговоров должен быть осуществлен обзор приобретающей стороной планов и других специально идентифицированных процедур, методов и рабочих продуктов, когда это приемлемо для проектных характеристик. В некоторых случаях дальнейшие уточнения и ревизии могут иметь место после заключения контракта		6.1.1.3.1.11
у) Приобретающая сторона должна только приобрести данные жизненного цикла, которые она ожидает для использования в течение договорного периода или позже. Информационные объекты, описанные в ИСО/МЭК 15289, должны быть приспособлены к их компонентному уровню, чтобы избежать разработки и приобретения бесполезных данных. У подлежащих поставке данных должны быть содержание, местоположение, формат, медиа-отображение и упаковка, которые являются приемлемыми для организации или проекта, где они разработаны и зарегистрированы. Приобретающая сторона должна убедиться, что поставленные данные отвечают намеченным потребностям		6.1.1.3.1.11
z) Сроки ревизий программного средства должны поддержать системный уровень и контрольные точки ревизий. Контрольные точки контракта должны быть основаны на ясно определенном входе и выходных критериях		6.1.1.3.1.12 7.2.6, 7.2.7
аа) Типичные документы ходатайства включают в себя: запрос на приобретение (например запрос на предложение, запрос о цене, запрос об информации, запрос о ссылке), меморандум о намерении, оферта или директива	6.1.1.3 b)	6.1.1.3.2
bb) Критерии оценки могут включать в себя согласованность с национальными стандартами, международными стандартами, включая ИСО/МЭК 12207, и зрелость процессов		6.1.1.3.3.1 6.1.1.3.1.13
cc) Иные факторы для рассмотрения включают способность/зрелость, экспертизу области приложения, прошлую работу, финансовую стабильность, обязательство по непрерывному усовершенствованию, местоположение и укомплектованность персоналом		6.1.1.3.3.2
dd) Когда возможно для формальной ситуации контракта с привлечением внешних поставщиков, потенциальные поставщики должны быть вовлечены в определение документа запроса на приобретение, чтобы обеспечить оптимально возможное соответствие потребностей заинтересованных сторон с системными требованиями	6.1.1.3 с)	6.1.1.3.4
ее) В некоторых случаях требования в п.6.1.1.3.4.1 могут быть неприемлемыми или трудно реализуемыми. Нижеследующее предоставлено как средство достижения намерений данного пункта. Адаптация приобретающей стороны должна быть применена только для определения области работ, подлежащих выполнению. Вместо того чтобы разрабатывать уникальную адаптацию к проекту, приобретающая сторона должна запросить предложения, основанные на организационных процессах поставщиков и оценить предложенные процессы поставщиков		6.1.1.3.4.1
ff) Приобретающая сторона должна идентифицировать для поставщика период хранения записей, прямо или косвенно относящихся к другим правовым требованиям		6.1.1.3.4.2
gg) Требования приобретения должны также быть обращены к компромиссам между стоимостью, сроками, работой, безопасностью, уровнем качества продукции и т.д.		6.1.1.3.4.2
hh) приобретающая сторона должна установить с поставщиком способы управления и осуществления изменений и в контрактных требованиях, и в требованиях к поставляемой системе или услуге		6.1.1.3.4.2
ii) Приобретающая сторона должна определить требования и предпочтения и провести переговоры с поставщиком, чтобы определить: 1) какую информацию нужно поставить приобретающей стороне; 2) какая информация должна быть доступной для приобретающей стороны; 3) какая информация требует одобрения от приобретающей стороны, когда создается впервые или последовательно модифицируется; 4) требования любого формата и содержания для информации; 5) когда информация должна быть произведена		6.1.1.3.4.2
jj) Исследования воздействия изменений к контракту должны включать в себя все потенциальные существенные риски		6.1.1.3.4.3
kk) Изменения к контракту не должны использоваться как метод, вызывающий изменения в организационных процессах поставщика		6.1.1.3.4.3
II) Уровень формальности контроля должен быть ясно установлен на уровне, соответствующем области и контексту соглашения, включая взаимные обязанности, частоту и способ контроля и способы оценки приемлемого выполнения соглашения. Соответствующие процессы включают поддержку приемки программного средства, ревизию, аудит программного средства и процессы решения проблем в программных средствах	6.1.1.3 d)	6.1.1.3.5 6.4.8 7.2.6 7.2.7 7.2.8
mm) У приобретающей стороны должна быть возможность исследовать процессы поставщика/конструктора (исполнителя)/сопровождающей стороны/оператора на возможности реализации, модификации или иной поддержки системы/программных средств, чтобы гарантировать рентабельность расходов ресурсов и высокое качество продукции, которое удовлетворяет пользовательские потребности в пределах проектной стоимости и плановых ограничений		6.1.1.3.5.1
nn) Приобретающая сторона и поставщик должны участвовать в совместных ревизиях. Требования/обязанности всех сторон, вовлеченных в совместное управление и совместные технические ревизии, должны быть задокументированы		6.1.1.3.5.1
оо) Чтобы контролировать действия поставщика, могут использоваться один или более методов. Эти методы включают в себя измерения программных средств, интегрированные команды, локальный или удаленный доступ к цифровым данным и совместные ревизии		6.1.1.3.5.1
рр) Приобретающая сторона может использовать данные из программы измерения программных средств поставщика как входные данные к ее собственной программе измерения программных средств для контроля поставщика		6.1.1.3.5.1
qq) Должны быть установлены вспомогательные меры, чтобы гарантировать, что и приобретающая сторона, и поставщик сотрудничают для обеспечения необходимой информации и работают для решения проблем и адекватной реакции на риски		6.1.1.3.5.2
rr) Устанавливают, кто уполномочен принять каждый выпущенный продукт или услугу и на каком основании, включая применимые процессы квалификации, верификации и валидации (аттестации)	6.1.1.3 е) 6.4.6 6.4.8	6.1.1.3.6 6.4.6 6.4.8 7.1.7 7.2.3 7.2.4 7.2.5
ss) Приобретающая сторона, включая пользователя, должна учесть подготовку к приемному тестированию. В зависимости от планов поддержки жизненного цикла относительно системы/программных средств приобретающая сторона должна также включить в подготовку к приемному тестированию организации, обеспечивающие эксплуатацию и сопровождение		6.1.1.3.6.1
tt) результаты других процессов (например, квалификационного тестирования, верификации, аттестации) могут использоваться как часть приемки и комплектации		6.1.1.3.6.1
uu) В зависимости от природы разработанного продукта приобретающая сторона может принять только программный продукт, программный продукт и связанные с ним компьютерные аппаратные средства или всю систему, которая включает встроенные программные средства		6.1.1.3.6.2
vv) Как определено в 6.1.1.3.6, приобретающая сторона определяет стратегию приемки. Приобретающая сторона может выбрать выполнение отдельного приемочного тестирования и анализа с поддержкой конструктора (исполнителя), задать работу конструктору (исполнителю) для выполнения всего тестирования с проведением основной приемки путем адекватного анализа испытательных результатов конструктора (исполнителя) или использовать некоторые вариации с вышеперечисленным		6.1.1.3.6.2

Примечание - Стандарт IEEE Std 1062 обеспечивает дополнительное руководство относительно процесса приобретения, включая выбор поставщика.

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Чтобы должным образом выполнить действия и задачи процесса поставки, следует реализовать соответствующим образом применимые процессы организационного обеспечения проекта, процессы проекта, технические процессы, процесс реализации и процесс поддержки программных средств	6.1.2.3 6.2, 6.3, 6.4	6.1.2.3 6.2, 6.3, 6.4 7.1, 7.2
b) Ходатайство от внутренней или внешней бизнес-единицы (которая может находиться внутри проекта) является обычным явлением. Нет необходимости в том, чтобы ходатайство было формальным	6.1.2.3 а)	6.1.2.3.1
с) Бизнес-единицы проводят изучение рыночной конъюнктуры на альтернативной основе, чтобы установить возможности, доступные в пределах специфического делового сектора	6.1.2.3 а)	6.1.2.3.1
d) Используя процесс планирования проекта, готовится план поставки	6.3.1	6.3.1
е) Обычно в любой ситуации поставки есть несколько подходов или способов сделать что-либо. Желателен подход или способ, который наилучшим образом и в полной мере достигает целей организации и поставки при задаваемых ограничениях. Должны учитываться: 1) применяемое законодательство и регулирования, которые относятся к поставщику; 2) бизнес-цели единицы; 3) конкурентоспособность; 4) окружающая среда организации, политика и процедуры; 5) готовность ресурсов; 6) соответствующие риски менеджмента, технические и ресурсные риски	6.1.2.3 b)	6.1.2.3.2
f) Предпочтительно, чтобы проектная реализация по ИСО/МЭК 12207 была ориентирована применительно к требованиям организации в части соответствия ИСО/МЭК 12207		6.1.2.3.2.1
g) Поставщик должен получить входы от конструктора (исполнителя), оператора, сопровождающей стороны, выбранной поддержки и подходящих организационных объектов, чтобы помочь в подготовке предложения		6.1.2.3.2.2 6.1.2.3.2.3
h) Предложение - это способ для поставщика предложить определенные процессы организации поставщика или рекомендовать рассмотрение контракта (например, тип контракта, учет жизненного цикла, контрольные точки)		6.1.2.3.2.2 6.1.2.3.2.3
i) Когда это возможно для формальной контрактной ситуации, привлекающей первичных и поддерживающих поставщиков, потенциальные поставщики должны быть вовлечены в определение тендерного ответа и в переговоры по соглашению поставки непосредственно или косвенно или и тем, и другим способом для того, чтобы обеспечить оптимально возможное соответствие способностей с системными требованиями	6.1.2.3 b) 6.1.2.3 с)	6.1.2.3.3
j) Выбранная модель жизненного цикла программных средств должна быть согласована совместно с приобретающей стороной и поставщиком. Должна быть построена модель жизненного цикла программных средств с действиями и задачами поставки, реализации, функционирования, сопровождения и применимой поддержки и организационных процессов, даже если будет выполняться лишь только один из вышеупомянутых первичных процессов		6.1.2.3.4.2
k) То, что выбранные и одобренные модели жизненного цикла организации существуют и доступны для использования проектами - это, как правило, является проектным предположением. Организация, согласно ИСО/МЭК 12207 (подраздел 6.2), определяет и регистрирует свои деловые требования и определяет модель жизненного цикла для использования, чтобы поддержать бизнес. Какой-либо проект, который выбирает, какую модель жизненного цикла использовать, базируются на потребностях проекта(ов). В конкретном проекте, основанном на его проектном плане, действия и задачи в жизненном цикле наносятся на карту. Нанесение на карту действий и задач технических процессов и процессов реализации программного средства должно сопровождаться соответствующими процессами поддержки программных средств. Эти нанесения на карты требуются для каждой итерации или прохождения через инкрементные и эволюционные модели. Другие проектные действия также должны быть нанесены на карту, свойственную выбранной модели жизненного цикла		6.1.2.3.4.2
I) В предложении на приобретение поставщик должен установить основы формирования показателей и измерения программных средств. Основы измерения должны непосредственно поддерживать проектный процесс жизненного цикла программных средств, связанные задачи и действия. Это должно обеспечить полную структуру для идентификации и определения приоритетности программных проблем, отбора соответствующих показателей для оперирования с идентифицированными проблемами, интеграции требований измерения с инженерией и процессами управления, анализа и отчетности о результатах измерения и предпринятия соответствующих действий. Основы измерения должны быть реализованы для поддержки информации поставщика и приобретающей стороны через весь жизненный цикл проекта и обращены к анализу выполнимости проектных планов и прослеживанию проектной работы согласно планам		6.1.2.3.4.3
m) В разработке и документировании плана(ов) управления проектом поставщик должен получить применимую поддержку от конструктора (исполнителя), оператора, сопровождающей стороны, выбранных поддерживающих и организационных объектов, базирующуюся на организационных процессах по ИСО/МЭК 12207		6.1.2.3.4.5
n) Поставщик должен перечислить области и уровни участия приобретающей стороны в процессе поставки, как определено в контракте (например, в ревизиях проектных планов, тестировании). Эта информация должна быть добавлена к соответствующим разделам плана управления проектом		6.1.2.3.4.5 i) 6.1.2.3.4.5 j)
о) Основы измерения программных средств, установленные в 6.1.2.3.4.3, должны использоваться для сбора данных		6.1.2.3.4.5 n)
р) Процессы поставщика для проекта должны быть определены относительно организационных процессов поставщика и проводимой политики		6.1.2.3.4.5
q) Поставщик должен сделать запись о стратегии и подходе к передаче в плане(ах) управления проектом		6.1.2.3.4.5
r) План(ы) управления проектом должен (должны) обновляться/изменяться по мере необходимости, отражать изменения в требованиях, политике и процедурах		6.1.2.3.4.6
s) Приобретающие стороны нужно держать в курсе обновлений план(ов)		6.1.2.3.4.6
t) Каждый из перечисленных процессов - это реализации соответствующих процессов организации		6.1.2.3.4.7
u) Уровень формальности контроля должен быть ясно установлен на уровне, соответствующем области и контексту соглашения, включая взаимные обязанности, частоту и способы контроля и оценки приемлемого выполнения соглашения. Соответствующие процессы - это поддержка приемки программного средства, ревизии программного средства, аудит программного средства и процессы решения проблем в программных средствах	6.1.2.3 d)	6.1.2.3.4.8 6.4.8 7.2.6 7.2.7 7.2.8
v) Управление риском должно быть включено в предпринимаемые действия		6.1.2.3.4.8 а) 6.3.4
w) Поставщик должен использовать процесс решения проблем в программных средствах (7.2.8)		6.1.2.3.4.8 а) 7.2.8
х) Основы измерения программных средств, установленные в 6.1.2.3.4.3, должны использоваться для сбора данных		6.1.2.3.4.8
у) Контракт с субподрядчиком должен определять только те задачи, которые субподрядчик должен выполнить, и только те требования из главного контракта, которые применимы к работе, выполняемой субподрядчиком		6.1.2.3.4.9
z) Когда поставщик передает требования субподрядчику(ам), подрядчик поставки принимает на себя роль приобретающей стороны, а субподрядчик принимает роль поставщика. Получающиеся отношения приобретающей стороны-поставщика отличны от существующих высокоуровневых отношений приобретающей стороны-поставщика. Это иллюстрирует принцип, что "приобретающая сторона" и "поставщик" обращаются к ролям, которые могут быть приняты разными сторонами, применяющими ИСО/МЭК 12207 и что определенная сторона может принять несколько различных ролей		6.1.2.3.4.9
аа) Приобретающая сторона или поставщик могут использовать независимую верификацию и валидацию (НВВ) или агентов для тестирования. Эти агенты могут оценить работу поставщиков и субподрядчика(ов). Чтобы гарантировать что ресурсы НВВ и агента используются наиболее эффективно, для этих агентов важно получить надлежащее обучение и опыт в процессах, инструментариях и методах, используемых оцениваемой организацией		6.1.2.3.4.10
bb) Поставщик должен скоординировать контрактные действия по ревизиям, интерфейсам и взаимодействию с организацией приобретающей стороны, как определено в плане(ах) управления проектом		6.1.2.3.4.12
cc) Если проект использует многофункциональные команды (например, в пределах организации поставщика или между поставщиком и субподрядчиком(ами)), участие приобретающей стороны должно быть ясно определено и понятно всем участникам команды. Например, приобретающая сторона может быть пассивным наблюдателем всех действий команды, случайным посетителем, активным участником или председателем и утверждающим уполномоченным лицом для всех решений команды		6.1.2.3.4.13 6.1.2.3.4.14 6.1.2.3.4.15 6.1.2.3.4.16
dd) Устанавливают, кто уполномочен принять каждый поставляемый продукт или услугу и на какой основе, включая применяемые процессы квалификации, верификации и валидации (аттестации)	6.1.2.3 е) 6.4.6 6.4.8	6.1.2.3.5 6.4.6 6.4.8 7.1.7 7.2.3 7.2.4 7.2.5
ее) Поставщик должен сделать записи о стратегии и подходе к передаче в плане управления проектом		6.1.2.3.5 6.1.2.3.6

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

Таблица А.3 - Процесс менеджмента модели жизненного цикла (6.2.1)


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

Таблица А.4 - Процесс менеджмента инфраструктуры (6.2.2)


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

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


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

Таблица А.6 - Процесс менеджмента людских ресурсов (6.2.4)


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

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Этот процесс совместим с установлением подходов менеджмента качества, которые приводят к соответствию со стандартом ИСО 9001	6.2.5	6.2.5
b) Этот процесс обеспечивает достаточный уровень уверенности, что система и атрибуты качества услуг каждого проекта соответствующим образом определены, и действия эффективно управляемы для удовлетворения требованиям заказчика и других сторон, заинтересованных в организационном успехе	6.2.5.3 а) 6.2.5.3 b)	6.2.5.3.1
с) Чтобы обеспечить гарантию, что рабочие продукты и процессы выполняют предопределенные условия и планы, используется процесс обеспечения гарантии качества программных средств		7.2.3
d) Чтобы помочь с обеспечением качества, могут использоваться процессы верификации, валидации (аттестации) и аудита	6.4.6 6.4.8	7.2.4 7.2.5 7.2.7

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

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Процесс планирования проекта определяет необходимые планы по поддержке других процессов. Например, 1) принятие решения по инвестициям; 2) подготовка обоснованного ответа на ходатайство; 3) определение, перейти на следующий этап или же продолжать работу для удовлетворения требований специальных организационных критериев входа/выхода на стадии; 4) руководство работой, требуемой для удовлетворения требованиям установленного соглашения; 5) повторное планирование работы	6.2.3.3 а) 6.1.2.3 b) 2) 6.3.1.3 b) 6) 6.2.3.3 с) 6.3.1.3 b) 6.3.1.3 с) 6.3.1.3 а) 1) 6.3.1.3 b) 2)	6.2.3.3.1 6.1.2.3.2 6.3.1.3.2 6.2.3.3.3 6.2.3.3.2 6.3.1.3.1 6.3.1.3.2
b) Планы ограничены организационными целями и задачами и потребностями заинтересованных сторон	6.3.1.3 b)	6.3.1.3.2
с) Планы включают область применения, задачи, методы, инструментарии, показатели, риски и ресурсы для применимой реализации системного элемента или системы, процессов комплексирования, верификации, передачи и аттестации, так, чтобы каждый резервный вариант мог использоваться эффективно	6.3.1.3 6.2.4 6.3.4 6.4.7	6.3.1.3 6.2.4 6.3.4 6.4.7 7.1.1 7.1.6 7.2.4 7.2.5
d) Перепланирование обычно начинается: 1) когда требуется в соответствии с соглашением; 2) когда из выходных результатов другого процесса выявлены существенные изменения или отклонения, или 3) перед реализацией следующей стадии инженерного или организационного представления, связанного с выбранной моделью жизненного цикла системы	6.3.1.3 а) 6.3.2	6.3.1.3.1 6.3.2
е) Резервные варианты используются в плане, когда там известны риски или возможности (например существенные изменения в бюджете, сроках, требованиях или технологии или в пригодности ресурса), которые могут заставить перенаправить проект или усилия по работе	6.3.1.3 а) 1)	6.3.1.3.1 6.3.4
f) Чтобы соответствовать проекту или сложности работы, неопределенности и ресурсам, включая финансирование, планы должны быть садаптированы относительно уровня и формальностей	6.3.1.3 а) 6.3.1.3 b)	6.3.1.3.1 6.3.1.3.2
g) Часто устанавливаются организационная структура проекта из структуры системы и специфика несистемной структуры согласно действиям в процессах проекта. Соответствующие действия процесса проекта, учитывающие специфику несистемной структуры, включают проектное планирование, оценку и контроль, управление рисками, управление принятием решения, управление конфигурацией, управление информацией и измерениями	6.3.1.3 а) 4) 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6	6.3.1.3.1 6.3.1.3.2 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6
h) Начальная организационная структура проекта должна быть основана на структуре системы и процессах жизненного цикла системы. Организационная структура проекта обычно развертывается, чтобы определить задачи и рабочие пакеты, связанные со специфической системой параллельно с техническим определением структуры, в которой существует система	6.3.1.3 а) 4)	6.3.1.3.1 6.3.1.3.2
i) Нижеследующие объекты 1)-4) должны быть полезными для того, чтобы определить проектные сроки, требования к укомплектованности и ресурсам:	6.3.1.3 b) 6.2.4	6.3.1.3.2 6.2.4
1) Ключевые события, необходимые для удовлетворения техническим требованиям (например техническая ревизия, ревизия готовности производства, верификация, ревизия решения по модификации)	6.3.1.3 b)	6.3.1.3.2
2) Первичные задачи, связанные с выполнением входных и выходных критериев каждого ключевого случая (например - задачи по определению требований заинтересованной стороны, завершению комплектования технических или управленческих ревизий, проведению тестирования)	6.3.1.3 b)	6.3.1.3.2
3) Задачи поддержки, которые обеспечивают штат, выполняющий первичные задачи для удовлетворения их целей, например: - по приобретению ресурсов, оборудования и услуг; - по приобретению соответственно квалифицированного персонала для того, чтобы он выполнял первичные задачи; - по организации командировки	6.3.1.3 b) 6.2.4	6.3.1.3.2 6.3.1.3.3 6.2.4
4) Задачи управления, требуемые для направления, контроля, ревизий и одобрения первичных задач и задач поддержки (например, тех, которые служат руководством для технической ревизии, рассматривают и одобряют документы для передачи заказчику, посещают ревизии менеджмента и решают, сделать ли обновление технологии, технологическую вставку или удалить систему)	6.3.1.3 с)	6.3.1.3.2
j) После санкционированного одобрения проектные сроки считаются субъектом базовой линии для изменения управления в соответствии с организационной политикой и процедурами	6.3.1.3 b) 1) 6.3.1.3 b) 2)	6.3.1.3.2
k) После санкционированного одобрения запланированный бюджет обычно считают субъектом базовой линии в соответствии с деловой политикой и процедурами	6.3.1.3 b) 3)	6.3.1.3.2
I) Планы могут быть индивидуальными документами в коллективном документе или собранными в электронных СМИ для доступа соответствующими участниками. План - это начальный результат процесса, который позволяет процессу быть эффективно выполненным. План должен быть сделан с использованием соответствующих действий процесса планирования проекта	6.3.1.3 b) 6)	6.3.1.3.2

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Существуют формализованные методы по управлению стоимостью и сроками. Примеры включают: 1) Проектирование по стоимости (используется для установления требований стоимости эквивалентных другим требованиям функционирования системы); 2) Планирование, основанное на событиях, устанавливает события (например контрольные точки), существенные действия и задачи, связанные с событием, и критерии, в соответствии с которыми определено завершение действий или задач; 3) Освоенный объем (используется для определения бюджетной стоимости выполняемой работы и осуществления сравнения планируемой стоимости с реальной стоимостью работы, чтобы определить оценки завершенных вариантов по стоимости и срокам)	6.3.2.3 а)	6.3.2.3.3
b) Соответствующие исследования и оценки проводятся для: 1) определения продолжающейся содержательности и уместности проектных планов (менеджмента и технического); 2) определения проектного технического прогресса, используя определенные технические показатели, основанные на предполагаемом достижении и полноте контрольных точек; 3) определения эффективности технических ролей и структуры проектной команды, использующей, где возможно, объективные показатели, такие, как технические достижения и эффективность использования ресурсов; 4) определения адекватности технических компетенций и мастерства участников команды для удовлетворения техническим ролям и выполнения технических задач; 5) определения эффективности и ценности поддерживающего обучения; 6) определения адекватности и пригодности производственной инфраструктуры и услуг в определенные периоды для подтверждения того, что удовлетворены внутриорганизационные обязательства; 7) определения качества и прогресса в проектировании системы и услугах обеспечивающей системы; 8) определения технических различий с проектными оценками и идентификации различий в спецификациях стоимости, готовности и выполнения; 9) оценки эффективности технического сбора, обработки и распространения данных; 10) определения технических изменений между ожидаемыми результатами и результатами оценки для обнаружения тенденций и идентификации первопричин; 11) определения качества собранных технических данных, ценности полученной информации, своевременности ее представления, полноты, достоверности, конфиденциальности (если требуется) и ее выгоды для получателей	6.3.2.3 а)	6.3.2.3.1 6.3.2.3.3
с) Процесс оценки проекта должен использоваться для выбора, оценки и сбора показателей системы и процесса, чтобы обеспечить информацией для поддержки менеджмента проекта. Соответственно, это включает определение: 1) развития проекта; 2) информации для реакции на риски; 3) значимых финансируемых и нефинансируемых работ; 4) информации по эффективности и рискам для того, чтобы осуществлять анализ компромиссных решений и обеспечивать рекомендации по действиям и результативным управляющим воздействиям	6.3.2.3 а)	6.3.2.3.1 6.3.2.3.3
d) Использование процесса оценки проекта помогает принятию управленческого решения, предоставляя информацию, которая является результатом контроля и анализа проектной работы, чтобы определить: 1) развитие и достижения в сравнении с планами (производительностью работы) и техническими требованиями (качество продукции); 2) приверженность методам и процедурам; 3) готовность перейти к следующей стадии организационного представления (через прохождение решений или анализ контрольных точек) или к следующему уровню структуры системы; 4) эффективность, риски и возможности, связанные с альтернативами, доступными для лиц, принимающих решения; 5) результаты коммерческого анализа для выбора рекомендуемого курса акций и воздействия стоимости, сроков, работ и рисков	6.3.2.3 а)	6.3.2.3.1 6.3.2.3.3
е) Показатели продукции позволяют оценивать прогресс и достижения в сравнении с техническими требованиями к системе и другим рабочим продуктам	6.3.2.3 а) 1) 6.3.2.3 а) 4) 6.3.2.3 а) 6)	6.3.2.3.3.1
f) Чтобы оценить удовлетворенность заинтересованных сторон и довести до приобретателей улучшающуюся ценность проектных продуктов и услуг, используются системные показатели (называемые показателями продукции). Эти показатели также служат индикаторами того, что процесс проекта развивается в направлении приемлемого решения. Примером входных системных показателей является мастерство привлекаемого проектного персонала. Примеры выходных показателей включают жалобы заказчиков, отчеты об эксплуатационных отказах и технические показатели работы (ТПР). Технические показатели работы - это показатели, используемые, чтобы оценить развитие проекта, соответствие требованиям к работе и технические риски для критических параметров работы. Выбор технических показателей работы должен быть ограничен по критическим пороговым значениям или по параметрам (если пороговые значения отсутствуют), которые, помещают в проект по стоимости, срокам или рискам. ТПР обеспечивают раннее определение адекватности проекта в терминах удовлетворения требованиям по выбранным критическим техническим параметрам. ТПР включают показатели проектного выполнения, такие, например, как кривые роста с порогами приемлемого уровня. Работа системного элемента или системы прослеживается через жизненный цикл по показателям в сравнении проектируемых и требуемых значений. Ранние оценки значений показателей работы в жизненном цикле основаны на моделировании и имитации. По мере переходов в жизненном цикле фактические данные заменяют оценочные и повышают тем самым точность информации. По мере развития эти измерения проектных решений позволяют оценить действия в процессах раньше, нежели ждать до тестирования системы, чтобы получить реальные значения показателей	6.3.2.3 а) 5) 6.3.2.3 а) 6)	6.3.2.3.3.2
g) Запланированные сроки и фактические или оцененные трудозатраты должны быть собраны, количественно оценены и сравнены с бюджетной базовой линией и текущими прогнозами	6.3.2.3 а) 5) 6.3.2.3 а) 8)	6.3.2.3.3
h) Выходные результаты оценки производительности (развития по планам) предоставляют собой статусную информацию, предназначенную для обеспечения эффективного использования ресурсов, оценки развития в сравнении с планами, определения различий по стоимости и срокам от запланированных проектных базовых линий, более ранней идентификации и решений проблем производительности	6.3.2.3 а) 2) 6.3.2.3 а) 6)	6.3.2.3.3
i) Когда изменения являются существенными или не могут быть исправлены повторным выполнением задач процесса, приведшим к неудовлетворительным выходным результатам, процесс планирования проекта начинается повторно с тем, чтобы запланировать и реализовать соответствующие корректирующие действия		6.3.2.3 а) 4) 6.3.2.3 а) 5) 6.3.2.3 а) 6)
j) Показатели идентифицируются и используются, чтобы оценить эффективность планируемой работы. Примерные показатели включают в себя освоенный объем (показатель стоимость/сроки), число инженерных изменений, процент строк законченного кода, процент переделок, время простоя, изменения тарифа и текучесть персонала. Критерии выбора показателей процесса основаны на том, насколько хорошо улучшения в выполнении проекта отвечают потенциальной удовлетворенности заказчика относительно стоимости, сроков и риска		6.3.2.3 а) 5)
k) Показатели определяются и используются, а данные собираются, чтобы выполнить оценку удовлетворенности заказчика	6.3.2.3 а) 5)	6.3.2.3.3
I) Технические ревизии, аудиты и инспекции проводятся в сравнении с техническими планами в соответствии с определенными сроками, чтобы продемонстрировать соответствие действий и результатов относительно запланированной технической работы	6.3.2.3 а) 6)	7.2.3 7.2.6 7.2.7
m) Типичные цели ревизии включают определение: 1) зрелости системы и то, насколько хорошо решение удовлетворяет требованиям; 2) прослеживаемости требований, обоснованность предположений и рациональность решения; 3) идентификации нерешенных проблем и тех проблем, которые не определены во время проектной работы; 4) соответствующих рисков, необходимых ресурсов и адекватности подготовки к проведению следующей стадии жизненного цикла системы	6.3.2.3 а) 6)	7.2.6
n) Ревизии уровня рассматриваемой системы могут быть сделаны в объединении с контрольными точками в организационном представлении, прохождениями решения или ревизией качества	6.3.2.3 а) 6)
о) Несоответствие подлежащих доставке рабочих продуктов, услуг и процессов должно быть зарегистрировано. Для исправления условий соответствия должны быть рекомендованы надлежащие меры	6.3.2.3 а) 7) 6.3.2.3 а) 8) 6.3.2.3 а) 9)	6.3.2.3.1
р) Использование процесса управления проектом помогает охвату и управлению результатами со стороны менеджмента проекта и технической работы, включая перенаправление той работы на преодоление трудностей, реакции на изменяющиеся обстоятельства или исправление случающихся отклонений	6.3.2.3 b)	6.3.2.3.2
q) Управление требованиями осуществляется параллельно с действиями по управлению стоимостью, сроками, качеством, конфигурацией, интерфейсом, риском и изменениями, которые отслеживают соответствие соглашения проекта и технических требований	6.3.2.3 b)	6.3.2.3.2

Таблица А.10 - Процесс менеджмента решений (6.3.3)


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Типы анализов компромиссных решений, осуществляемых обычно во время выполнения процессов жизненного цикла, включают в себя: 1) формальный анализ - формально проводимый, с результатами, анализируемыми при технических ревизиях. Специфические формальные анализы компромиссных решений обычно определяются в соглашении; 2) неформальный анализ - следует той же самой методологии формального анализа, но требует меньшего количества документации и имеет меньшее значение для приобретающей стороны; 3) субъективный анализ - выбор рекомендуемых опций, основанный на суждении аналитика или проектировщика после менее строгого анализа, чем формальный анализ компромиссных решений и для которого последствия не столь важны. Используется тогда, когда одна опция явно превосходит другие или отсутствует время для более формального подхода. Большинство выполняемых анализов компромиссных решений имеет субъективный тип	6.3.3.3 а) 6.3.3.3 b)	6.3.3.3.1 6.3.3.3.2
b) Анализы компромиссных решений проводятся в течение реализации проекта и технических процессов, чтобы разрешить противоречия (такие как, например, противоречивые требования) и выбрать рекомендуемое решение из ряда определенных альтернатив (таких, как дополнительные действия, предпринятые для разрешения риска, решения для противоречивых требований, альтернативных логических или физических решений архитектурного проектирования). Результаты от анализа включают рекомендуемые опции, рассмотрения реализации, воздействия, связанные с каждой опцией, основы рекомендаций и сделанных предположений	6.3.3.3 а) 2) 6.3.3.3 b) 1) 6.3.3.3 с)	6.3.3.3.1.3 6.3.3.3.2.1 6.3.3.3.3

Таблица А.11 - Процесс менеджмента рисков (6.3.4)


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

Таблица А.12 - Процесс менеджмента конфигурации (6.3.5)


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

Таблица А.13 - Процесс менеджмента информации (6.3.6)


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

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


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

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

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Требования заинтересованной стороны составляют первичные неформальные входы для решений установленных проблем (замысел новой системы или модифицированная система, основанная на недостатках, отказах и других отклонениях, обнаруженных во время использования)	6.4.1.3	6.4.1.3
b) Заинтересованная сторона может быть внутренней к организации (например другой проект, маркетинговая организация, вышестоящая производственная команда, собственная производственная команда, пользователь, оператор, исполнительный менеджер, руководитель), или внешней к организации (например закупочное агентство, головной подрядчик, другая организация, заказчик, пользователь, оператор, собственник, покупатель)	6.4.1.3 а)	6.4.1.3.1
с) Пользователь - это особый случай заинтересованной стороны-приобретателя. Это тот, кто оперирует программными средствами или кто устанавливает программные средства, чтобы сформировать высокоуровневую систему (например компьютер или микрочип) в структуре системы	6.4.1.3 а)	6.4.1.3.1
d) Другие заинтересованные стороны также могут относиться к "иным правообладателям" или иным сторонам, отличным от приобретателей и заинтересованным в выходных результатах работы по инженерии или реинженирингу. Требования другой заинтересованной стороны, не обязательно обеспечиваемые приобретающей стороной в соглашении, включают: 1) организационные и проектные требования, такие, как те, что имеют дело с рынками систем и организационными процессами; 2) экологические, местные, национальные и международные регламенты и законы;	6.4.1.3 а)	6.4.1.3.1
3) функциональные требования поддержки для реализации системы и комплексирования, производства, испытаний, функционирования и логистики (развертывание, обучение, сопровождение и прекращение применения)
е) Требование обычно составляется из того, что должно быть сделано (функция) и как хорошо оно должно быть сделано. Функция - это обычно предложение того, кто производит действие (существительное), самим действием (глагол) и объектом действия (существительное). Например, механизм (кто производит действие) открывает (действие) дверь (объект действия) в течение 10 с. Требование может также быть нефункциональным, то есть, ограничением проекта, например, таким как, например, цвет	6.4.1.3 b) 6.4.1.3 с)	6.4.1.3.2
f) Этот процесс включает действия и задачи, выполняемые с помощью или для поставщика в охватывании и выражении требований, которые будут выполняться, и целей, которые будут преследоваться в поставке программных средств и соответствующих услуг	6.4.1.3 b) 1)	6.4.1.3.2.2
g) Стоимость может быть требованием, заявленным как фиксированные расходы (независимая переменная) или максимальная стоимость (ограничение)	6.4.1.3 b) 1)	6.4.1.3.2.2
h) Этот процесс вовлекает гарантии того, что оказываются идентифицированными опасения нисходящего жизненного цикла системы, такие как, например, производство, испытания, функционирование и логистика (развертывание, обучение, сопровождение, прекращение применения), затрагивая функциональные возможности системы	6.4.1.3 b) 2)	6.4.1.3.2.3
i) Положения контекста использования - это отобранная информации о физических, технических, социальных и культурных элементах, окружающих систему, и анализ того, как они воздействуют (или будут воздействовать), а также как программные средства используются. Положения контекста использования - это полезная коллекция поддержки информации при подготовке требований пользователя программных средств и эксплуатационных требований. Они дают представление о том, как и где программные средства будут использоваться проектировщиками программных средств в рассмотрении альтернатив проекта. Это - документы ссылки для проектирования действий по аттестации системы. Контекст использования - самый детальный источник информации о пользователях программных средств и производственных условиях. Используются как первичное руководство при выборе пользователей для испытаний и тестирования (см. ИСО 9241-11 для получения дополнительной информации об определении и анализе контекста использования)	6.4.1.3 b) 2) 6.4.3 6.4.8	6.4.1.3.2.3 6.4.3 6.4.8
j) Обычно невозможно удовлетворить все требования правообладателей (приобретающей стороны и других заинтересованных сторон) для специфической системы с различными заинтересованными сторонами, у которых могут быть противоречивые требования относительно друг друга. Эти противоречия должны быть идентифицированы и разрешены во время работы этого процесса или как только противоречия идентифицированы во время действий или во время одного из технических процессов. Для разрешения противоречий должны использоваться оценка эффективности, анализ компромиссных решений и действия по анализу рисков	6.4.1.3 с)	6.4.1.3.4 7.2.8
k) Для каждой системы из структуры системы должны быть явно определены показатели эффективности. Показатель эффективности - это "эксплуатационный" показатель успешности, который близко связан с достижением эксплуатационных целей в намеченной эксплуатационной окружающей среде при соблюдении указанного множества условий. Например, насколько хорошо решение позволяет достичь намеченной цели. Показатели эффективности, которые заявлены с точки зрения пользователя/заказчика, являются ключевыми индикаторами заказчику по достижению целей для функционирования, пригодности и доступности на протяжении жизненного цикла	6.4.1.3 с) 1) 6.4.1.3 с) 2) 6.4.1.3 с) 3)	6.4.1.3.3.1 6.4.1.3.4.1 6.4.1.3.4.2
I) Требования заинтересованной стороны - это основание для аттестации реализованной или скомплексированной системы, которая разработана с использованием технических процессов	6.4.1.3 с) 2) 6.4.1.3 с) 3) 6.4.1.3 с) 4) 6.4.1.3 с) 5)	6.4.1.3.4.1 6.4.1.3.4.2 6.4.1.3.4.3 6.4.1.3.5.1
m) Прослеживаемость требований инициирована в этом пункте для того, чтобы отследить требования и изменения к требованиям от начальных входов заинтересованной стороны через архитектурный проект	6.4.1.3 с) 6)	6.4.1.3.5.2

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Чтобы полностью понять, что требуется от намеченного продукта, деятельность анализа системных требований должна включать выявление таковых от пользовательского сообщества		6.4.2.3.1.1
b) Если система состоит из подсистем, то действия и задачи процесса анализа системных требований должны выполняться итеративно с действиями и задачами процесса проектирования архитектуры системы для определения системных требований, проектирования системы и определения подсистем, требований для этих подсистем, проектирования подсистем и определения их компонентов и т.д.		6.4.2.3.1.1 6.4.3
с) Каждое требование должно быть задано таким способом, который позволяет определить объективный тест для этого требования		6.4.2.3.1.1
d) Конструктор (исполнитель) должен проанализировать требования приобретения относительно компьютерного использования ресурса аппаратных средств (например, максимальное допустимое использование возможностей процессора, памяти, устройств ввода/вывода, вспомогательной возможности устройств хранения, возможностей коммуникационного/сетевого оборудования). Если нет никаких требований приобретения, касающихся компьютерного использования ресурсов аппаратных средств, или они являются очень общими, конструктор (исполнитель) должен установить соответствующие требования использования как часть действий по системным требованиям. Установление требований использования должно быть действиями, итеративно повторяемыми с действиями по проектированию		6.4.2.3.1.1
е) Определение требований безопасности системы должны также включать то, что система не должна делать		6.4.2.3.1.1
f) У каждого показателя эффективности есть соответствующее множество показателей функционирования. Показатели функционирования - это показатели, которые характеризуют физические или функциональные атрибуты, касающиеся функционирования системы. Эти "системные" технические индикаторы работы измеряются или оцениваются при специальном тестировании и/или в эксплуатационных условиях окружающей среды. Эти атрибуты рассматриваются как важные для гарантий способности системы к достижению эксплуатационных целей. Показатели функционирования используются для оценки того, удовлетворяет ли система проекту или требованиям функционирования. Они необходимы для анализа показателя эффективности, в интересах которого эти показатели функционирования были произведены. Показатели функционирования получаются с точки зрения поставщика решения и отражают, насколько хорошо поставляемая система функционирует в сравнении с требованиями уровня системы, например в аспектах функционирования системы или применения ее способностей. Показатели функционирования часто наносят на карту ключевых требований функционирования в системной спецификации. Они выражаются в терминах отчетливо оцениваемых свойств функционирования, таких как скорость, полезный груз, диапазон или частота. Это требует тщательного определения показателей функционирования во время процесса анализа системных требований и во время логического архитектурного проектирования, а также эффективного отслеживания требований для гарантий того, что показатели функционирования фактически определены и включены в проект системы	6.4.2.3 а) 4)	6.4.2.3.1
g) Требования для выполнения оценки предназначены для задания работы конструктору (исполнителю), определения реализуемости создаваемого архитектурного проекта системы, основанного на требованиях, выполнимости функционирования и сопровождения такой системы. Это может оказаться необходимым для выполнения отобранных аспектов проекта, таких, как прототипирование или моделирование в интересах определения того, выполнима ли разработка продукции, удовлетворяющей заданным требованиям		6.4.2.3.2.1 d) 6.4.2.3.2.1 е)
h) Каждое техническое требование подлежит аттестации для гарантии того, что оно отражает следующие свойства качества: 1) способность к сохранению конкурентоспособности - позволяет сохранить конкурентоспособные позиции и только как ограничение сказывается на конкурентоспособности, оправдывая выгоды, получаемые с помощью требований; 2) ясность - сформулированное требование готово к пониманию без анализа значения слов или используемых терминов; 3) корректность - сформулированное требование не содержит фактической ошибки; 4) выполнимость - требование может быть удовлетворено в пределах - естественных физических ограничений; - современного состояния науки и техники относительно приложения к проекту; - всех других абсолютных ограничений, относящихся к проекту; 5) целенаправленность - требование выражено в терминах того, "что" и "почему" или формы, приспособления и функции, но не в терминах того, как разрабатывать продукты или материалы, которые будут использоваться. Исключением к этому являются детальные требования, которые востребованы для проведения детального проектирования продукта; 6) реализуемость - сформулированное требование содержит информацию, необходимую, для реализации требования быть реализованным; 7) модифицируемость - необходимые изменения к требованию могут быть сделаны полностью и содержательно; 8) отсутствие неопределенности - позволяет только одну интерпретацию для значения требования. Например, не определены словами или сроками такие положения, как "чрезмерный", "существенный" и "сопротивляющийся", которые не могу быть измерены; 9) однозначность - сформулированное требование не может быть осмысленно выражено как два или более требований, имеющих различия по факторам, действиям, объектам или инструментариям; 10) тестируемость - существование конечного и объективного процесса для верификации того, что требование было выполнено; 11) верифицируемость - может быть проверено на уровне структуры системы, в которой это установлено; 12) абстракция - корректные уровни абстракции для организационного представления стадии и зрелости системы	6.4.2.3 b) 1)	6.4.2.3.2
i) Технические сформулированные требования в парах и множествах подлежат аттестации для гарантий того, что они отражают следующие свойства качества: 1) отсутствие избыточности - каждое требование задается только один раз; 2) связность - все термины в пределах требования соответственно связаны с другими требованиями и со словами, терминами и определениями так, чтобы индивидуальные требования соответствовали должным образом другим требованиям как множество; 3) непротиворечивость - требование не находится в противоречии с другими требованиями или в пределах самого себя	6.4.2.3 b) 1)	6.4.2.3.2
j) Чтобы помочь гарантировать выполнимость требований, поставщик должен учесть: 1) существующие системные элементы, такие как коммерческие, готовые к использованию, которые могут помочь уменьшить время реализации и стоимость, но и могут увеличить сложность; 2) введение новой технологии, которая может обеспечить конкурентное превосходство; 3) возможные физические решения; 4) новые интерфейсы, которые могут быть введены	6.4.2.3 b) 1)	6.4.2.3.2
k) Чтобы создать решения по архитектурному проекту рассматриваемой системы, получающееся множество технических требований подлежит аттестации на предмет необходимости и достаточности. Это включает как приемлемые: 1) нисходящую прослеживаемость аттестованного множества требований заинтересованных сторон ко множеству определенных технических требований; 2) восходящую прослеживаемость индивидуальных технических сформулированных требований, производных от множества определенных технических требований, снизу вверх к аттестованным множествам требований заинтересованных сторон; 3) подтверждение того, что предположения и произведенные требования достоверны и совместимы с системой и связанными услугами в инженерии или реинжениринге; 4) разрешение выявленных неохваченных аспектов, различий и противоречий, включая: - подтверждение того, что были предприняты соответствующие действия, когда множество определенных технических требований оказывается непрослеживаемым снизу вверх к утвержденному множеству требований заинтересованных сторон; - определение, были ли требования или ограничения введены без источников и желательны ли они соответствующим заинтересованным сторонам; - подтверждение того, что пропущенные требования добавлены приемлемым образом ко множеству определенных технических требований, когда соответствующие потребности заинтересованной стороны не были отражены во множестве определенных технических требований; - доказательство того, что была сделана повторная аттестация множества технических требований, когда изменения необходимы к одному из аттестованных множеств потребностей заинтересованной стороны и что соответствующие действия и задачи заинтересованной стороны, нуждающиеся в процессах определения и анализа требований, были выполнены вновь соответствующим образом	6.4.2.3 b) 3)	6.4.2.3.2

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Проектирование архитектуры касается разработки удовлетворительных и выполнимых системных решений для множества полученных технических требований, поддержания целостности замысла через реализацию, гарантируя, что построенная система соответствует спецификациям при верификации и требованиям применения заинтересованными сторонами при аттестации и обеспечивает конфигурационную целостность системного замысла в течение стадий эксплуатации и поддержки. Завершенный архитектурный проект должен использоваться в течение жизненного цикла системы для прогнозирования и отслеживания пригодности к использованию и оценки изменений в системе	6.4.3.3	6.4.3.3
b) ИСО/МЭК 12207 содержит несколько требований для целей или руководства по проектированию архитектуры системы, признавая, что эта область технологии и практики подвергается быстрому развитию. Следующие рекомендации могут быть полезными в выборе методов и множества целей:		6.4.3.3.1.1
1) Во многих случаях уместно рассмотреть архитектуру системы как механизм для того, чтобы облегчить связь между приобретающей стороной, конструктором (исполнителем), поставщиком и другими ключевыми заинтересованными сторонами относительно разъяснения требований и их воздействия на структуру системы. Хотя такое использование не является требованием стандарта, оно действительно способствует выполнению критериев оценки, перечисленных в 6.4.3.3.2.1		6.4.3.3.1.1 6.4.3.3.2.1
2) ИСО/МЭК 12207 не требует использования любого специфического архитектурного метода, например, функциональной декомпозиции. Выбор должен быть основан на характеристиках усилий по реализации. В некоторых случаях уместно рассмотреть программные архитектурные усилия как расширение системы архитектурных усилий, продолжающееся на более детальном уровне с большим вниманием к программно-специфическим вопросам		6.4.3.3.1.1
3) ИСО/МЭК 12207 не требует никакого специфического результата от архитектурного усилия, кроме определения объектов и распределения требований. Часто это является приемлемым (и поддерживаемым по критериям оценки) для использования архитектуры как средства в отношении формулировки и регистрации решений проекта всей системы (то есть, решений о системном замысле выполнения и особенностях интерфейса и других решений, затрагивающих выбор и проектирование системных объектов). Результаты таких решений могут быть зарегистрированы в форме проекта всей системы. Результаты решений относительно определения объектов и прослеживаемости требований могут быть зарегистрированы в форме архитектурного проекта и соответствующих ссылок		6.4.3.3.1.1
4) Во многих случаях проектирование архитектуры должно быть расценено как итеративная деятельность. Заключительное определение всех объектов и распределение всех требований могут быть закончены во время итераций, кроме первой		6.4.3.3.1.1
5) Проектирование архитектуры системы высшего уровня (то есть, первый уровень деления) может включать подсистемы. Проектирование архитектуры системы может включить альтернативные представления архитектуры		6.4.3.3.1.1
с) Требования по выполнению оценок предназначены для задания работы конструктору (исполнителю), чтобы определить осуществимость создания системного архитектурного проекта, основанного на требованиях, выполнимости функционирования и сопровождаемости такой системы. Может оказаться необходимым выполнить отобранные аспекты анализа требований программных средств для определения, выполнима ли разработка продукта(ов), отвечающего заданным требованиям		6.4.3.3.2.1 d) 6.4.3.3.2.1 е)
d) Конструктор (исполнитель) должен рассмотреть, являются ли запланированные и потенциальные компьютерные ресурсы (процессоры и т.д.) адекватными для удовлетворения требований		6.4.3.3.2.1 d)
е) Требования для обеспечивающих систем происходят от: 1) пользователя или заказчика или заданных требований и от других системных потребностей заинтересованных сторон; 2) полученных технических требований для систем и производного применения процесса проектирования архитектуры системы. Таким образом, инициирование реализации обеспечивающей системы или ее приобретения (какая-то функция границы проектируемой системы) зависит от завершения решения архитектурного проекта для создаваемой системы или системы, являющейся результатом реинжениринга, а также от применяемой стадии жизненного цикла системы и связанной деятельности по инженерному или организационному представлению	6.4.3.3 а)	6.4.3.3.1
f) Логическое проектирование архитектуры включает в себя изучение различных логических декомпозиций и иных представлений требований. Для различных представлений отсутствует какое-либо множество форматов или форм. Выбранный формат или форма - это то, что лучшим образом определяет в качестве приемлемых функциональные, поведенческие потоки или потоки данных или структуру данных, и что позволяет осуществить лучшее задание для потенциальных физических элементов, ручных операций или обеспечивающих систем для генерации альтернативных решений физического проектирования архитектуры	6.4.3.3 а)	6.4.3.3.1
g) Определенные технические требования размещаются согласно создаваемому представлению логического проекта архитектуры. От различных представлений получается множество технических требований, которые используются для проектирования архитектуры. Уже после того, как это распределение закончено, могут оказаться незадействованными некоторые технические требования. Их назначают непосредственно на альтернативные решения физического проекта архитектуры	6.4.3.3 а)	6.4.3.3.1
h) В распределении требований логического представления и полученных технических требований относительно того, обеспечивают ли они требования, которые могут быть выполнены лучшим образом, учитывают следующее: 1) выполнение с помощью обеспечивающих систем, связанных с реализацией и интеграцией, производством, тестированием, операциями, поддержкой или прекращением применения; 2) выполнение вручную или с помощью оборудования, материалов или данных; 3) выполнение аппаратными средствами, программными средствами и микропрограммными физическими элементами (новыми или существующими)	6.4.3.3 а)	6.4.3.3.1
i) Процесс определения требований правообладателей, процесс анализа требований системы и процесс архитектурного проектирования системы повторяются для каждого последовательного более низкого уровня в структуре системы, пока заданные требования для всех системных элементов не будут определены или пока заданный системный элемент сможет быть построен, применен повторно или закуплен. Если требуется дальнейшая реализация для системного элемента, она может быть осуществлена с использованием соответствующего стандарта реализации системного элемента, такого, как ИСО/МЭК 12207	6.4.3.3 b) 6.4.3.3 с) 6.4.1 6.4.2	6.4.3.3.2 6.4.1 6.4.2
j) Если во время проектирования архитектуры определено, что требования не могут быть удовлетворены из-за нерешенных проблем, связанных с воздействующими факторами решения (см. ожидаемые результаты проектирования архитектуры), или из-за неприемлемых стоимости, сроков, выполнения или рисков для приемлемых альтернатив, то может оказаться необходимым повторить процесс определения требований правообладателей, процесс анализа требований системы и процесс архитектурного проектирования системы	6.4.3.3 b) 6.4.3.3 с) 6.4.1 6.4.2	6.4.3.3.2 6.4.1 6.4.2
k) При определении предпочтительных физических решений для архитектурного проекта исследования каждой альтернативы выполняются с учетом следующего: 1) физических интерфейсов (человека, формы, приспособления, функции, потока данных и интероперабельности): - между идентифицированными физическими элементами решения физического проекта; - с другими системными элементами структуры системы; - с обеспечивающими системами; - с внешними системами. 2) изменяемости и чувствительности к изменяемости каждого определенного критического параметра функционирования; 3) технологических потребностей, необходимых для того, чтобы сделать альтернативное решение эффективным, а связанные с введением новых или передовых технологий риски - отвечающими заданным техническим требованиям и альтернативным менее рискованным технологиям, на которые можно было бы заменить технологии с более высоким риском; 4) пригодности коммерческих конечных продуктов (таких как программные средства многократного использования). Если продукты приемлемы не в полной мере, определяется стоимость и риски для модификации коммерческого системного элемента, чтобы удовлетворить требования интерфейса и проекта; 5) эффектов от рассмотрений проекта, чтобы сопровождать или создать альтернативу физического решения, конкурентоспособную с потенциальными или существующими продуктами конкурентов; 6) дальнейших проектных усилий, которые могут оказаться необходимыми для обеспечения резервируемости и поддержки от неизбежной деградации в результате последствий возможных отказов, для анализа эффектов и критичности отказов, имеющих недопустимый уровень или высокую степень критичности; 7) степени, с которой полученные технические требования к функционированию удовлетворяются с помощью каждого из альтернативных физических решений; 8) степени, с которой атрибуты безопасности, производительности, тестируемости, легкости развертывания, инсталлируемости, работоспособности, поддерживаемости, сопровождаемости, обучаемости и прекращения применения приспособлены к тому, чтобы быть запроектированными; 9) потребностей, требований и ограничений для обеспечивающих систем; 10) способности к развитию или реинженирингу, включая новые технологии, к улучшению функционирования, увеличению функциональности или к иным рентабельным или конкурентоспособным усовершенствованиям, когда система находится в производстве или на рынке; 11) ограничений, которые могут ухудшить способности рассматриваемой системы или системного элемента и связанных услуг для развития (путем обновления технологии или технологической вставки); 12) преимуществ и недостатков в реализации системного элемента или выполнении комплексирования в пределах организации или доведении до установленного поставщика; 13) преимуществ и недостатков в использовании стандартизированных системных элементов, протоколов, интерфейсов и т.д.; 14) проблем интеграции, которые могут включать: - потенциальные опасности другим системам, операторам или окружающей среде; - требования встроенного теста и теста для изоляции ошибки; - легкость доступа, готовность к дизассемблированию, использование общих инструментариев, преимущества модульности, стандартизации и меньшей потребности в когнитивных навыках; - динамические или статические противоречия, несогласованности и несвойственные функциональные возможности комплексируемых элементов, которые составляют решение	6.4.3.3 b) 6.4.3.3 с)	6.4.3.3.2
I) При поиске решения архитектурного проекта, которое вовлекает людей и человеческие ограничения, например, такие, как движение глаз, необходимо учесть информационные нормы и эргономику. Кроме того, должны быть проанализированы человеческие факторы удобства и простоты использования. Эти факторы затрагивают человеческие взаимодействия с другими системами и интерфейсами пользователя к системе в течение жизни системы	6.4.3.3 b) 2)	6.4.3.3.2
m) Во время проектирования архитектуры для разработки и коммуникаций в проектных решениях могут использоваться целевые модели, поведенческие модели, математические модели и управленческие модели. Определенный тип модели зависит от применимой стадии организационного представления, ее цели или требований соглашения	6.4.3.3 b) 6.4.3.3 с)	6.4.3.3.2
n) Для того, чтобы разработать решение для обеспечивающей системы, также используются процесс определения требований правообладателей, процесс анализа требований и процесс проектирования архитектуры - но после того, как требования для такой реализации идентифицированы и определены в результате применения процесса определения требований рассматриваемой системы или разрабатываемого системного элемента. Реализация обеспечивающей системы или приобретение обеспечивающей системы применимы для каждой рассматриваемой системы и системного элемента из структуры системы	6.4.1 6.4.2 6.4.3	6.4.1 6.4.2 6.4.3
o) Спецификации (специальные требования), произведенные в соответствии с физическим проектированием архитектуры, могут определять работу системы, не говоря, как эта работа должна быть выполнена. Это называют спецификацией функционирования (хотя "ориентированной на функционирование" был бы более точным термином). Если результат проектирования архитектуры содержит большое количество деталей, включая определенные способы, которыми должно быть обеспечено функционирование, это называют детальным проектом. Какой вид в итоге получается, зависит в общем случае от следующего шага в разработке или от того, как результаты будут использоваться. Если следующий шаг - это разработка более низкого системного уровня, и желательно, чтобы у поставщика была гибкость в инновационном обеспечении приемлемого решения, используются спецификации функционирования. Спецификации функционирования используются, когда уместно заявить требования в терминах: 1) необходимых результатов, не определяя метод для достижения необходимых результатов; 2) функции (что должно быть достигнуто) и функционирования (как хорошо каждая функция должна быть выполнена); 3) окружающей среды, в которой рассматриваемая система или системный элемент должны выполнять функции; 4) интерфейса и характеристик взаимозаменяемости; 5) средств для верификации соответствия	6.4.3.3 с) 1)	6.4.3.3.1
р) Начальные спецификации или спецификации "проекта, чтобы...", производимые вышеупомянутыми действиями, обеспечивают входные требования приобретающей стороны для начала реализации следующего, более низкого уровня систем или любого иного. Эти инициируемые спецификации завершаются после процесса определения требований правообладателей, процесса анализа требований и процесса проектирования архитектуры, примененных к каждому из более низких уровней системных элементов. Спецификации описывают необходимые характеристики систем из структуры системы и включают требования к функциям и функционированию, требования к интерфейсам, окружающую среду, в которой системы обязаны выполнять свои функции, физические характеристики и атрибуты, основы для оценки систем путем тестирования при верификации и аттестации, методы для проверки требований соответствия, использования по предназначению и требований к обеспечивающим системам	6.4.3.3 с) 1) 6.4.1 6.4.2	6.4.3.3.1 6.4.1 6.4.2
q) Процесс определения требований правообладателей, процесс анализа требований и процесс проектирования архитектуры применяются к последующим, более низким уровням до системных элементов до тех пор, когда получающееся решение для архитектурного проекта сможет быть реализуемым, закупленным или разработанным в дальнейшем	6.4.3.3 с) 1) 6.4.1 6.4.2	6.4.3.3.1 6.4.1 6.4.2
r) Процесс реализации, процесс комплексирования, процесс верификации, процесс передачи и процесс аттестации используются для реализации систем в пределах структуры системы сверху вниз	6.4.3.3 с) 1) 6.4.4 6.4.5 6.4.6 6.4.7 6.4.8	6.4.3.3.1 6.4.4 6.4.5 6.4.6 6.4.7 6.4.8 7.1.1 7.1.6 7.2.4 7.2.5
s) Детальные спецификации используются тогда, когда приемлемым является установление требований проекта в терминах одного или более из следующего: 1) как должно быть выполнено требование; 2) как должна быть построена система	6.4.3.3 с) 1)	6.4.3.3.1
t) Получающиеся множества решений архитектурного проекта и связанных технических требований должны быть оценены с тем, чтобы показать, насколько они применимы и что у каждого множества сформулированных требований для физического решения есть приемлемое качество, включая: 1) подтверждение того, что предназначенные функции системы и соответствующие услуги (выраженные в соответствии с произведенными техническими требованиями и техническими требованиями, распределенными непосредственно по физическому решению) реализованы правильно; 2) подтверждение того, что ограничения к системе и соответствующим услугам, включая интерфейсы, удовлетворены; 3) устранение выявленных упущений, отклонений и противоречий, включая: - перезадание производных технических требований для обеспечения приемлемого качества; - подтверждение того, что соответствующее действие было предпринято тогда, когда заданные требования оказались непрослеживаемыми снизу вверх ко множеству полученных технических требований согласно решению архитектурного проекта и техническим требованиям, распределенным согласно решению непосредственно по физическим объектам; - определение, были ли указанные требования введены без указания источников, были ли они предназначены для включения и желательны ли они соответствующим заинтересованным сторонам; - подтверждение того, что упущенные требования добавлены к решению архитектурного проекта, когда технические требования были неадекватно определены или отражены в выбранном решении; - определение и регистрацию действий, предпринятых для того, чтобы устранить определенные требования при отсутствии их источников, установить корректное множество производных технических требований или пересмотреть множество аттестованных технических требований; - доказательство того, что была выполнена повторная верификация заданных требований, когда изменения ко множеству аттестованных технических требований были необходимы, и что соответствующие действия и задачи процесса анализа требований системы и процесса проектирования архитектуры системы были выполнены вновь соответствующим образом; - доказательство того, что была выполнена повторная аттестация множества технических требований, когда изменения к одному из аттестованных множеств потребностей заинтересованной стороны были необходимы, и что соответствующие действия и задачи процессов анализа системных требований и процесс проектирования архитектуры системы были выполнены вновь соответствующим образом; - доказательство, что тесты повторной верификации были выполнены, когда прослеживались тестовые отклонения выходных результатов и аномалии, приведшие к плохим результатам верификации или к неадекватной окружающей среде верификации	6.4.3.3 с)	6.4.3.3.1 6.4.3.3.2
u) Описание базовой линии решения архитектурного проекта используется для управления конфигурацией рассматриваемой системы или системного элемента	6.4.3.3 с)	6.4.3.3.1
v) Это может оказаться необходимым для выполнения реинжениринга решений архитектурного проекта систем или для рассматриваемой системы более высокого уровня в структуре системы, чем тот, который создавался или модифицировался на основе реинжениринга	6.4.3.3 с)	6.4.3.3.1
w) Результаты "Проектирования архитектуры" могут быть охвачены в описании архитектуры, как определено ИСО/МЭК 42010. В этом случае "Заинтересованные стороны и вопросы", как определено ИСО/МЭК 42010, будут, возможно, определены во время процесса определений требований правообладателей и процесса определения требований системы. Представление решения для физического проектирования архитектуры, описанного в настоящем стандарте, будет, возможно, представлено как "Проектное представление" или "Функциональное представление", связанное с функциональной точкой зрения, которая совместима с требованиями ИСО/МЭК 12207. Использующая организация может установить другие архитектурные представления, ИСО/МЭК 12207 не должен интерпретироваться как мандат единственной архитектурной точки зрения и представления	6.4.3	6.4.3

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) См. также табл.А.26 - Процесс реализации программного средства (п.7.1.1)	6.4.4	7.1.1
b) Любой системный элемент может быть смоделирован, основываясь на зрелости его определения, а также на применимой стадии организационного представления, контрольных точках или прохождении решения и связанных с этим выходных критериев	6.4.4.3 а)	7.1.1.3.1
с) Системный элемент - или единичный продукт или композиция продуктов в зависимости от его уровня в структуре системы и его способности быть закупленным или реализованным	6.4.4.3 b)	7.1.1.3.1
d) Системные элементы, состоящие исключительно из программных элементов, могут быть 1) закуплены у поставщика или продавца, 2) закодированы внутри организации или 3) повторно использованы	6.4.4.3 b)	7.1.1.3.1
е) Аспекты, учитываемые при формировании стратегии реализации, включают: 1) производит ли реализация новый системный элемент или системный элемент, который воспроизведен согласно существующему проекту и данным реализации, является адаптацией существующего системного элемента; 2) стандартные методы, которые управляют соответствующей технологией реализации, технической дисциплиной или сектором продукта; 3) безопасность, факторы частной жизни и собственности, экологические факторы; 4) местоположение и окружающую среду реализации; 5) мастерство и навыки специалистов по реализации, их пригодность и устойчивость; 6) характеристики операторов; 7) период, за который требуются повторные случаи реализации	6.4.4.3 а)	7.1.1.3.1
f) Реализованные системные элементы верифицируются с использованием соответствующего процесса до поставки приобретающей стороне. Валидация (аттестация) может быть выполнена перед поставкой или до завершения процесса комплексирования системы, основанного на требованиях соглашения	6.4.4.3 b) 6.4.6 6.4.8	7.1.1.3.1 7.2.4 7.2.5
g) Конфигурация "как построено" должна быть зарегистрирована и сопровождаема всюду по жизненному циклу системы	6.4.4.3 b)	7.1.1.3.1

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) До комплексирования системы низшего уровня в желаемую сложную систему убеждаются, что каждая составная система была соответствующим образом аттестована поставщиком или внутри организации	6.4.5.3 b)	7.1.6.3.1
b) Аттестационные результаты испытаний системы, документация и процедуры, как принято, должны быть рассмотрены до выполняемого комплексирования	6.4.5.3 b)	6.4.5.3.2 7.1.6.3.1
c) Конструктор (исполнитель) должен определить подходящее время в процессе реализации, чтобы начать или обновить планирование для квалификационного тестирования системы. Конструктор (исполнитель) может разработать и задокументировать детали квалификационного тестирования как часть процесса комплексирования системы или часть одного из процессов реализации программного средства. Важно убедиться, что все задействованные стороны понимают: d) какая тестовая документация должна быть подготовлена; e) когда предварительная и обновляемая информация подлежит использованию; f) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление информации		6.4.5.3.1.1 6.4.5.3.2.1
g) Конструктор (исполнитель) должен использовать процедуры предварительного тестирования для аппаратных и программных средств, требуемых как часть подготовки к испытаниям		6.4.5.3.1.1 6.4.5.3.2.1
h) Если приобретающая сторона планирует засвидетельствовать квалификационное тестирование, конструктор (исполнитель) должен провести репетицию всех случаев квалификационного тестирования и процедур, чтобы гарантировать, что документация тестирования корректна и система функционирует согласно ожиданиям		6.4.5.3.1.1 6.4.5.3.2.1

Таблица А.20 - Процесс квалификационного тестирования системы (6.4.6)


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

Таблица А.21 - Процесс инсталляции программных средств (6.4.7)


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

Таблица А.22 - Процесс поддержки приемки программных средств (6.4.8)


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Использование имитации и моделирования может быть полезным для изучения работы системы в эксплуатационной окружающей среде, а также для того, чтобы сэкономить затраты, когда непосредственные испытания являются непрактичными	6.4.8.3 а)
b) Главный заказчик для рассматриваемой системы проводит аттестацию поставленных продуктов, используя процесс аттестации в сравнении с требованиями приобретающей стороны (часто по текущим продуктам, которые могут быть включены или могли быть не включены в продукцию). Это может принять форму приемочных испытаний или начального эксплуатационного теста и оценки	6.4.8.3 а) 6.4.8.3 b)
с) Необходимо позаботиться о получении гарантий того, что требования, полученные для устранения отклонений, не находятся в противоречии с множеством входов или аттестованных требований заинтересованных сторон или требований соглашения без координации таковых изменений с соответствующими заинтересованными сторонами	6.4.8.3 b)
d) Отклонения, влекущие несоответствия, включают некорректное проведение аттестационных испытаний, некорректный испытательный проект, несовершенный системный проект, несоответствие объекта испытаний "как построено" описаниям проектных решений (спецификациям, требованиям интерфейса, и т.д.) и некорректные, устаревшие или недавно появившиеся требования заинтересованных сторон. Разрешение ошибочных ситуаций проводится на уровне решения, совместимого с корректирующими действиями, эффективными по затратам, включая повторную аттестацию после исправления дефектов или организационных действий по улучшению качества	6.4.8.3 b)
е) Если это применимо, поставка программной продукции включает: - поставку программных средств с исходными текстами и в исполнимых кодах, включая пакетные файлы, командные или иные файлы, необходимые для восстановления исполняемых программ; - описание требований упаковки; - процедуры компиляции/сборки для того, чтобы создать программные средства в исполнимых кодах; - процедуры модификации программных средств; - для программных средств "как построено" - использование аппаратных средств измерения; - описание версии программных средств.		6.4.8.3.1.2

Таблица А.23 - Процесс функционирования программных средств (6.4.9)


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

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


Положение	ИСО/МЭК 15288	ИСО/МЭК 12207
а) Процесс сопровождения программного средства включает любой элемент поддержки логистики, в т.ч. обучение персонала сопровождения, штатного управления конфигурацией, управления поставкой, функции поставки, как определено соглашением или другими директивами, а также упаковку, ручную обработку и отгрузку	6.4.10.3 а)	6.4.10.3.1
b) У каждой стадии жизненного цикла программных средств есть функция сопровождения для выполнения задач и достижения цели той стадии. Поэтому процесс сопровождения применим к любой стадии и может иметь различную стратегию и план относительно поддержания программных и обеспечивающих систем, применимых к конкретной стадии	6.4.10.3 а)	6.4.10.3.1
с) Должна поддерживаться соответствующая документация, описывающая действия сопровождения и выходные результаты	6.4.10.3 а)	6.4.10.3.1 6.4.10.3.3
d) Если есть полное множество актуальной информации, связанной с программными средствами (например, требования, документация проекта, тестирования, функционирования, сопровождения), сопровождающая сторона должна определить, какая документация должна обновляться с каждым действием сопровождения. Однако, на многих проектах связанная с программными средствами информация неполна или информация является устаревшей. В таких случаях сопровождающая сторона должна определить 1) сколько должно быть создано новой информации, представляющей собой часть действия сопровождения; 2) какая существующая информация должна быть актуализирована как часть действия сопровождения. Множество информации, созданной или обновленной как часть деятельности сопровождения, зависит от области приложения, масштабов и критичности действий сопровождения, готовых ресурсов в окружающей среде сопровождения, ресурсов, доступных для приобретающей стороны, финансирующей деятельность сопровождения, воздействий сопровождения на другие заинтересованные стороны, а также от других факторов		6.4.10.3.3.1
е) Использование и определение термина "программная единица (блок)" могут изменяться от проекта к проекту. Для сопровождающей стороны важно понять понятия проекта программных средств и терминологию, используемую на сопровождаемом продукте и определить, какие модули и какие версии программных средств должны быть изменены. Определение термина "программная единица (блок)", которое будет использоваться, должно быть дано поддерживающей организацией с учетом определения конструктора (исполнителя)		6.4.10.3.3.1
f) Не все программные средства и требования системы должны быть повторно проверены с каждой модификацией программных средств. Область повторного тестирования, которое должно произойти, чтобы гарантировать, "что исходные, немодифицированные требования не были затронуты", может измениться, базируясь на масштабах действия изменения, критичности затронутых частей или функций системы, безотлагательности для обновления, стратегии выпуска относительно пользовательской окружающей среды, а также от других факторов		6.4.10.3.3.2
g) Нужно тщательно рассмотреть модификацию программных продуктов многократного использования (например, коммерческих, ранее разработанных программных средств). Модификация может привести к продавцу или поставщику продукта, снижающего поддержку или требующего определенных договорных и финансовых усилий для будущей поддержки. Дополнительная информация относительно программных средств многократного использования может быть найдена в приложении В		6.4.10.3.3.2
h) Поддержка старой системы должна быть описана в планах замещения, включая уровень поддержки		6.4.10.3.5.3 а)
i) Если обучение пользователей функционирующей системы обеспечивает отдельная учебная окружающая среда, то обновления в функционирующей системе должны вызывать соответствующие обновления и для учебной системы		6.4.10.3.5.4

Таблица А.25 - Процесс прекращения применения программных средств (6.4.11)


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

А.6 Процессы реализации программных средств (Подраздел 7.1)

Таблица А.26 - Процесс реализации программных средств (7.1.1)


Положение	ИСО/МЭК 12207
а) См. также таблицу 18 - Процесс реализации (6.4.4)	6.4.4.3
b) Если нет предложений от приобретающей стороны или поставщика, конструктор (исполнитель) должен установить соответствующую модель(и) жизненного цикла прежде, чем переходить к процессу реализации программных средств. Содержание процесса реализации программных средств и распределение по модели жизненного цикла должны включать действия и задачи для осуществления процесса, когда они могут быть проведены и ответственных лиц за выполнение действий и задач. Дополнительное руководство по использованию моделей жизненного цикла программных средств может быть найдено в стандарте IEEE Std 1074, IEEE стандарт для разработки процесса жизненного цикла программных средств (Standard for Developing a Software Project Life Cycle Process)	7.1.1.3.1.1
с) Реализация процесса управления документацией - это запись информации в любых СМИ и может включать подготовку печатных документов. Обоснование для ключевых решений, принятых в проведении реализации программных средств/системы, должно быть задокументировано. Обоснование должно включать рассмотренные компромиссы, методы анализа и критерии, использованные при принятии решений. Значение "ключевых решений" и подхода для того, чтобы обеспечить обоснование, должны быть описаны в планах. Разработка и документирование информации - это неотъемлемая часть процесса реализации программных средств. Процесс управления документацией обращается к представлению и управлению этой информацией. Руководство по формату и содержанию разрабатываемой информации предоставлено в ИСО/МЭК 15289	7.1.1.3.1.2 а) 7.2.1
d) Конструктор (исполнитель) должен учитывать различные состояния, в которых определяются объекты, продукты, или иные сущности, проходящие как часть управления конфигурацией (например, авторский надзор, конструкторское проектное управление, управление приобретающей стороны). Эти состояния можно определить тогда, когда могут использоваться другие процессы. (Например, только управление конфигурацией для продуктов на проектном уровне или более высоком уровне может быть перечислено в записях статусного учета конфигурации и использовано в процессе решения проблем в программных средствах для официального отчета и отслеживания любых проблем). Конструктор (исполнитель) должен также зарегистрировать уполномоченных лиц или группы для разрешения изменений и их выполнения на каждом уровне, если это приемлемо. Конструктор (исполнитель) должен зарегистрировать шаги, которые будут следовать для запрашивания авторизации на изменения, для заявок на изменения процесса, изменения последовательности, распределения изменений и запоминания прошлых версий. Изменения, которые воздействуют на объект, продукт или иную сущность уже при управлении приобретающей стороны, должны быть предложены приобретающей стороне в соответствии с контрактом по установленными формам и процедурам. Базовая линия может использоваться во время процесса реализации программных средств как форма управления объектом конфигурации	7.1.1.3.1.2 b) 7.2.2
е) Выбор конструктором (исполнителем) стандартов, методов, инструментариев и компьютерных языков может включать выбор собственных стандартных практик конструктора (исполнителя), в т.ч. практику повторного использования программных средств	7.1.1.3.1.3 7.3
f) Конструктор (исполнитель) может сослаться на определенные стандарты, методы, инструментарии, практики и языки программирования в планах относительно осуществления своих действий	7.1.1.3.1.4
g) Планирование реализации описывает подход (методы/процедуры/инструментарии) к применимым действиям и задачам процесса реализации программных средств, охватывает все применимые разделы относительно реализации, идентифицирует применимые риски/неопределенность относительно этих действий и задач и описывает планы относительно разрешения проблем с рисками/неопределенностью	7.1.1.3.1.4
h) Планирование реализации программного средства должно быть основано на модели его жизненного цикла (см. 7.1.1.3.1.1)	7.1.1.3.1.4
i) Планы, которые будут приняты, могут быть планами руководства проектом и/или планами реализации программных средств	7.1.1.3.1.4
j) Конструктор (исполнитель) должен предоставить вниманию поставщика (и приобретающей стороне) те объекты, для которых доставка не предусмотрена, но для которых поставляемые продукты могут быть востребованы во время функционирования и сопровождения, чтобы позволить поставщику и приобретающей стороне договариваться об использовании или доставке поставляемых продуктов	7.1.1.3.1.5

Таблица А.27 - Процесс анализа требований программных средств (7.1.2)


Положение	ИСО/МЭК 12207
а) См. также таблицу 16 - Процесс анализа системных требований (подпункт 6.4.2)	6.4.2.3
b) ИСО/МЭК 25030 определяет шесть качественных характеристик для использования: функциональность, надежность, применимость, эффективность, сопровождаемость и мобильность	7.1.2.3.1.1
с) Все объекты должны быть установлены таким образом, чтобы для них могли быть определены объективные критерии	7.1.2.3.1.1
d) Руководство относительно планов безопасности программных средств может быть найдено в стандарте IEEE 1228, IEEE стандарт для планов безопасности программных средств	7.1.2.3.1.1
е) Требования к выполнению оценок предназначены для задания работы конструктору (исполнителю) в интересах определения выполнимости архитектурного проекта программного объекта, основанного на требованиях и выполнимости функционирования и сопровождения системы, содержащей такой программный объект. Это может оказаться необходимым для выполнения выборочных аспектов проекта, например, таких, как прототипирование или моделирование, и определения, выполнима ли разработка продукции, отвечающей задаваемым требованиям	7.1.2.3.1.2 е) 7.1.2.3.1.2 f)
f) Проведение ревизий включает в себя планирование и принятие участия в технических и управленческих ревизиях. Стандарт 1028 может быть полезным в осуществлении этого требования	7.1.2.3.1.3

Таблица А.28 - Процесс проектирования архитектуры программных средств (7.1.3)


Положение	ИСО/МЭК 12207
а) См. также таблицу 17 - Процесс проектирования архитектуры системы (6.4.3)	6.4.3.3
b) Во многих случаях уместно рассмотреть архитектуру программных средств как механизм для того, чтобы облегчить связь среди проектировщиков системы, проектировщиков программных средств и других ключевых заинтересованных сторон относительно разъяснения требований и их воздействия на структуру программных средств	7.1.3.3.1.1
с) Архитектурная деятельность касается создания строгой полной структуры для программных средств. Во время этой деятельности внимание должно быть обращено на структурные механизмы архитектуры системы. Например, проектирование архитектуры должно произвести общие механизмы для того, чтобы управлять неизменяемыми объектами, обеспечивая пользовательский интерфейс и управляющее хранение	7.1.3.3.1.1
d) Часто является приемлемым (и поддерживаемым критериями оценки) использовать архитектуру как средство для формулировки и регистрации решений проекта программных средств (т.е. решений о поведенческом проекте программных средств и других решений, затрагивающих выбор и проект компонентов программных средств). Результаты таких решений могут быть зарегистрированы в форме проекта программного объекта. Результаты решений относительно определения компонентов программных средств и прослеживаемости требований могут быть зарегистрированы в форме проектирования архитектуры и ссылок прослеживаемости	7.1.3.3.1.1
е) Конструкторское описание архитектуры программных средств включает описание замысла выполнения с участием программных компонентов	7.1.3.3.1.1
f) Для каждого объекта программных средств отсутствует какой-либо универсальный вид соглашения о том, сколько деталей проекта должно быть зарегистрировано и рассмотрено как "структура высшего уровня". Поэтому конструкторские стандарты, методы и инструментарии, описанные в планах реализации, должны ясно излагать подход к созданию программных архитектурных и детальных проектов. В частности, планы должны обращаться: 1) к используемым стандартам, методам и инструментариям; 2) к терминологии и графическим способам описания различных модулей; 3) к уровню деталей, связанных с архитектурным и детальным проектом; 4) к подходу для ревизий проектной информации участниками проектирования. Чтобы избежать неверных представлений различными проектными заинтересованными сторонами, важно, чтобы эти связанные с проектом проблемы были решены, задокументированы и ясно понимаемы	7.1.3.3.1.1
g) Термин "программный компонент" в ИСО/МЭК 12207 представляет собой сущность (объект), которая уточняется на более низких уровнях, содержит программные единицы (блоки) и протестирована как часть программного комплекса. План(ы) реализации должен ясно установить подход к созданию программных средств структуры высшего уровня, архитектурный и детальный проекты, кодирование программных средств, а также все уровни тестирования программных средств. В частности, планы должны обращаться: 1) к используемым стандартам, методам и инструментариям; 2) к терминологии и графическим способам описания различных модулей; 3) к уровню деталей, связанных с архитектурным и детальным проектом; 4) к отношению программного архитектурного проекта с детальным проектом; 5) к подходу для ревизий проектной информации участниками проектирования; 6) к подходу к тестированию при программном комплексировании. Чтобы избежать неверных представлений различными проектными заинтересованными сторонами, важно, чтобы эти связанные с проектом проблемы были решены, задокументированы и ясно понимаемы	7.1.3.3.1.1
h) Архитектура программных средств должна быть совместимой с архитектурой системы	7.1.3.3.1.1
i) Конструкторское описание проекта интерфейса должно включать описание характеристик интерфейса программных объектов, внешних сущностей и программных компонентов	7.1.3.3.1.2
j) Конструктор (исполнитель) часто планирует и готовит пользовательскую документацию, поскольку во многих системах используется взаимодействие между людьми. Конструктор (исполнитель) должен общаться с пользователем относительно всех проблем, которые воздействуют на пользователя (например, требования, проект, тест, пользовательские проблемы документации). Предварительные версии пользовательской документации могут быть подготовлены как часть деятельности проектирования архитектуры программных средств и обновлены во время последующих действий. Важно гарантировать, чтобы все задействованные стороны понимали: 1) каким образом входы от пользователей должны быть собраны и объединены в процессе реализации программных средств; 2) какая пользовательская документация должна быть подготовлена; 3) когда должна быть готова предварительная и обновленная информация; 4) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление информации. Вопросы приемки пользовательской документации должны быть отражены в соглашении приобретающей стороны с поставщиком	7.1.3.3.1.3 7.1.3.3.1.4
k) В процессе реализации программного средства конструктор (исполнитель) должен определить подходящее время для начала планирования комплексирования программных средств и тестирования. Конструктор (исполнитель) может определить и задокументировать требования предварительных испытаний и сроки для комплексирования программных средств как часть деятельности проектирования архитектуры или задокументировать тестовую информацию во время процесса реализации программных средств. Важно гарантировать, чтобы все задействованные стороны понимали: 1) какая испытательная документация должна быть подготовлена; 2) когда должна быть готова предварительная и обновленная информация; 3) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление информации	7.1.3.3.1.5
I) Оценивая и документируя результаты этих оценок, конструктор (исполнитель) должен объяснить осуществимость архитектуры, чтобы реализовать требования и удовлетворить пользовательские потребности	7.1.3.3.1.6
m) Проведение ревизий включает планирование и принятие участия в совместных технических и управленческих ревизиях. Стандарт IEEE Std 1028 Стандарт IEEE для ревизий и аудитов программных средств (IEEE Standard for Software Reviews and Audits) может быть полезным в осуществлении этого требования	7.1.3.3.1.7 7.2.6

Таблица А.29 - Процесс детального проектирования программных средств (7.1.4)


Положение	ИСО/МЭК 12207
а) Конструкторское детальное описание проекта должно включать описание каждой программной единицы (блока) программного объекта	7.1.4.3.1.1
b) Стандарты поставщика, методы, и инструментарии, описанные в плане(ах) реализации, должны ясно излагать подход к созданию детального проекта, кодированию программных средств и тестированию программных средств всех уровней. В частности, план(ы) должен (должны) обращаться: 1) к используемым стандартам, методам и инструментариям; 2) к терминологии и графическим способам описания различных проектных элементов; 3) к уровню деталей, связанных с детальным проектом; 4) к отношению детального проекта с отдельно компилируемой программной сущностью (объектом) и к отдельно выполнимой программной сущности (объекту); 5) к подходу для ревизий проектной информации участниками проектирования; 6) к подходу для тестирования единиц (блоков).	7.1.4.3.1.1
Чтобы избежать неверных представлений различными проектными заинтересованными сторонами, важно, чтобы эти связанные с проектом проблемы были решены, задокументированы и ясно понимаемы
с) Конструктор (исполнитель) должен описать каждую программную единицу (блок), используемый для доступа к базе данных или манипуляций, и должен описать элементы данных и объединения элементов данных базы данных	7.1.4.3.1.2 7.1.4.3.1.3
d) Конструктор (исполнитель) должен определить подходящее время в процессе реализации программного средства, чтобы начать планировать тестирование программных единиц (блоков). Конструктор (исполнитель) может определить и задокументировать требования и сроки для тестирования программных единиц (блоков) как часть деятельности детального проектирования программных средств или создать и задокументировать тестовую информацию во время процесса реализации программных средств. Важно гарантировать, чтобы все задействованные стороны понимали: 1) какая должна быть подготовлена документация для тестирования; 2) когда информация должна быть готова; 3) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление информации	7.1.4.3.1.4 7.1.4.3.1.5
е) В процессе реализации программного средства конструктор (исполнитель) должен определить подходящее время, чтобы начать или обновить планирование по комплексированию программных средств и тестированию. Конструктор (исполнитель) может определить и задокументировать требования и сроки для тестирования программных единиц (блоков). Конструктор (исполнитель) может обновить тестовые требования и сроки для комплексирования программных средств как часть деятельности детального проектирования программных средств или обновить тестовую информацию во время процесса реализации программных средств. Важно, чтобы все задействованные стороны ясно понимали: 1) какая должна быть подготовлена документация для тестирования; 2) когда должна быть готова предварительная и обновленная информация; 3) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление информации	7.1.4.3.1.6
f) Проведение ревизий включает планирование и принятие участия в совместных технических и управленческих ревизиях. Стандарт IEEE 1028 стандарт IEEE для ревизий и аудитов программных средств (IEEE Standard for Software Reviews and Audits) может быть полезным в осуществлении этого требования	7.1.4.3.1.8 7.2.6

Таблица А.30 - Процесс конструирования программных средств (7.1.5)


Положение	ИСО/МЭК 12207
а) Единицы (блоки) программного средства могут быть определены различными способами. Определение(я), которое будет использоваться, должно однозначно пониматься реализующей организацией	7.1.5.3.1.1
b) Реализация базы данных может включать действия базы данных, например, такие, как подготовка данных и заполнение базы данных или других данных с их значениями	7.1.5.3.1.1
c) Конструктор (исполнитель) должен определить подходящее время в процессе реализации программного средства, чтобы начать или обновить планирование комплексирования программных средств и тестирования. Конструктор (исполнитель) может обновить требования и сроки для комплексирования программных средств как часть деятельности процесса конструирования программных средств или обновить тестовую информацию во время процесса реализации программных средств. Важно гарантировать, чтобы все задействованные стороны понимали: d) какая должна быть подготовлена документация для тестирования; e) когда должна быть готова предварительная и обновленная информация; f) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление информации	7.1.5.3.1.2 7.1.5.3.1.3 7.1.5.3.1.4
g) Требование для оценки приемлемости методов и стандартов кодирования предназначено для постановки задач конструктору (исполнителю) по оценке соответствующего использования методов и стандартов кодирования	7.1.5.3.1.5

Таблица А.31 - Процесс комплексирования программных средств (7.1.6)


Положение	ИСО/МЭК 12207
а) См. также таблицу 19 - Процесс комплексирования системы (подпункт 6.4.5).	6.4.5.3
b) План комплексирования должен включать, если применимо, описание испытательной окружающей среды, обоснование и процедуры регистрации и анализа данных. План должен также включать любую интеграцию и испытательную информацию, которая была развита или обновлена во время других процессов реализации программного средства	7.1.6.3.1.1
с) Конструктор (исполнитель) должен идентифицировать программные средства или требования системы, к которым обращается каждый испытательный случай, и должен гарантировать, что все требования программных средств включены как часть квалификационного тестирования	7.1.6.3.1.2
d) В ИСО/МЭК 12207 тест состоит из одного или более тестовых случаев	7.1.6.3.1.2 7.1.6.3.1.4
е) Конструктор (исполнитель) должен определить подходящее время в процессе реализации, чтобы начать или обновить планирование квалификационного тестирования программных средств. Конструктор (исполнитель) может разработать и документировать детали квалификационных испытаний как часть деятельности по комплексированию программных средств или во время другой части. Процесса реализации программного средства. Важно гарантировать, чтобы все задействованные стороны понимали: 1) какая испытательная документация должна быть подготовлена; 2) когда предварительная и обновленная информация должна быть готовой; 3) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление информации	7.1.6.3.1.4
f) Конструктор (исполнитель) должен включить процедуры предварительных испытаний для аппаратных средств и программных средств, требуемых как часть подготовки к испытаниям	7.1.6.3.1.2 7.1.6.3.1.4
g) Если приобретающая сторона планирует засвидетельствовать квалификационное тестирование, конструктор (исполнитель) должен провести репетицию всех испытательных случаев и процедур, чтобы гарантировать, что испытательная документация правильна, и программные средства функционируют, как ожидается	7.1.6.3.1.4
h) Проведение ревизий включает планирование и принятие участия в совместных технических и управленческих ревизиях. Стандарт IEEE 1028, IEEE Standard for Software Reviews and Audits может быть полезным в осуществлении этого требования	7.1.6.3.1.6 7.2.6

Таблица А.32 - Процесс квалификационного тестирования программных средств (7.1.7)


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

А.7 Процессы поддержки программных средств (7.2)

Таблица А.33 - Процесс менеджмента программной документации (7.2.1)


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

Таблица А.34 - Процесс менеджмента конфигурации программных средств (7.2.2)


Положение	ИСО/МЭК 12207
а) См. также таблицу 12 - Процесс менеджмента конфигурации (6.3.5)	6.3.5.3
b) План менеджмента конфигурации может также быть частью приобретения, поставки, реализации, функционирования, плана(ов) сопровождения или любого другого соответствующего плана	7.2.2.3.1.1
с) Дополнительное руководство по управлению конфигурацией может быть найдено в ИСО 10007	7.2.2.3.1.1
d) Схема идентификации конфигурации должна охватить указатели для идентификации сущностей (объектов), которые будут помещены под управление конфигурацией, и должна позволить назначать уникальный идентификатор на каждый программный объект. Указатели должны охватить продукты программных средств, которые будут разрабатываться или использоваться, и должны охватить элементы программной инженерной окружающей среды. Схема идентификации должна быть на уровне управления сущностью, например, компьютерными файлами, электронными СМИ, документами, программными единицами (блоками), объектами аппаратных и программных средств. Схема идентификации должна включать статус версии/пересмотра/выпуска каждой сущности	7.2.2.3.2.1
е) Основное содержание требований в этом объекте - те объекты, продукты или сущности, непосредственно связанные с программными средствами для проекта, т.е. планирование и техническая информация в компьютерных файлах, электронных СМИ, и документах, описывающих программные средства, и компьютерные файлы и электронные СМИ, непосредственно содержащие программные средства. В то время как другими объектами, продуктами или сущностями, такими как отчеты или документы, связанные с управлением и оценкой тех продуктов, нужно управлять на некоторых уровнях. Это не является намерением ИСО/МЭК 12207 требовать, чтобы все такие объекты, продукты или сущности управлялись с той же самой степенью строгости	7.2.2.3.3.1
f) Процедуры менеджмента конфигурации должны охватывать уровни управления, через которые каждый идентифицированный объект, продукт, или сущность обязаны проходить (например, авторский надзор, управление проектного уровня, управление приобретающей стороны), людей или группы, уполномоченные разрешать и делать изменения на каждом уровне, и сопровождаемые шаги с запросами на разрешение изменений, запросами на изменения процесса, с непосредственными изменениями, распределением изменений и сохранением прошлых версий. Изменения, воздействующие на объект, продукт или сущность уже при управлении приобретающей стороной, должны быть предложены приобретающей стороне в соответствии с установленными контрактом формами и процедурами	7.2.2.3.3.1
g) Записи должны быть подготовлены и поддержаны для сущностей (объектов), которые находятся под определенным уровнем управления конфигурацией (например, проектным уровнем или более высоким уровнем управления конфигурацией). Эти записи должны сопровождаться в течение срока действия, определенного в контракте, или для соответствия организационной политике	7.2.2.3.4.1
h) Управление выпуском и требования поставки обращаются к стороне, которая выпускает программную продукцию	7.2.2.3.6.1

Таблица А.35 - Процесс обеспечения гарантии качества программных средств (7.2.3)


Положение	ИСО/МЭК 12207
а) Процесс обеспечения гарантии качества программных средств должен быть ответственным за то, чтобы проводить продолжающиеся оценки приобретения, поставки, реализации, сопровождения, функционирования программных средств и действия по поддержке процесса и получающихся программных продуктов, как применимые, к 1) гарантиям того, что каждый процесс, деятельность, и задача, требуемые в соответствии с контрактом или описанные в планах, выполняются в соответствии с контрактом и этими планами; 2) гарантиям того, что каждый программный продукт, требуемый соответствующим процессом или условиями контракта, существует и подвергся оценкам программной продукции, тестированию и решению проблем, как то требуется	7.2.3.3.1.1
b) Организации, которые поддерживают систему менеджмента качества, основанную на ISO 9001, должны идентифицировать системные элементы, которые имеют отношение непосредственно с требованиями этого объекта и других объектов процесса поддержки и определяют, как идентифицированные элементы выполняют эти требования	7.2.3.3.1.2
с) Процесс обеспечения гарантии качества программных средств должен быть скоординирован с соответствующими процессами для гарантий того, что 1) согласно оценкам не существуют никаких ненужных или вредоносных дублирований; 2) запланированные оценки являются взаимовыгодными и реалистичными; 3) противоречивые отчеты из связанных процессов разрешены до каких-либо предложений к процессу решения проблем в программных средствах	7.2.3.3.1.2
d) Процесс обеспечения гарантии качества программных средств может использовать результаты процесса валидации программного средства, процесса верификации программного средства и других процессов и действий, чтобы удовлетворить функцию обеспечения качества	7.2.3.3.1.2
е) Идентификация действий и задач, выполняемых связанными процессами, сообщения которых состоят в том, чтобы использоваться для процесса обеспечения гарантии качества программных средств, предназначена, чтобы облегчить координацию между обеспечением качества и теми связанными процессами	7.2.3.3.1.3 е)
f) Три главных требования существуют в 7.2.3.3.1.6 с возможно различными сторонами, ответственными за разные части: 1) организационная свобода, ресурсы и полномочия для разрешения объективных количественных оценок; 2) ответственность начать и эффектно решать проблемы; 3) ответственность за верификацию решений проблем. Ответственные за процесс или продукт являются ответственными за решение проблем, обнаруженных в тех процессах или продуктах. Стороны, выполняющие процесс обеспечения гарантии качества программных средств, ответственны за гарантии того, что проблема верифицирована и решена	7.2.3.3.1.6
g) Программные продукты, которые полностью удовлетворяют договорным требованиям, могут расцениваться как приемлемые для принятия приобретающей стороной	7.2.3.3.2.3
h) Процесс обеспечения гарантии качества программных средств должен быть выполнен для гарантирования того, что все продукты, определенные в контракте, существуют, подверглись оценкам в соответствии с планами действий и решения задач по обеспечению качества, и удовлетворяют критериям приемки по контракту	7.2.3.3.2.3
i) Гарантии для продукции могут использовать результаты верификации, валидации (аттестации) и других процессов, чтобы обеспечить решение задач гарантии продукции	7.2.3.3.2.3
j) Применение ИСО 9001 должно быть частью полноценной деловой деятельности организации. Приобретающая сторона не должна определять использование ИСО 9001 как часть контракта. Для "дополнительных действий по менеджменту качества" следует обращаться к ИСО 9001 по действиям менеджмента качества, что намеренно не отражено в ИСО/МЭК 12207	7.2.3.3.4.1

Таблица А.36 - Процесс верификации программных средств (7.2.4)


Положение	ИСО/МЭК 12207
Нет руководства	-

Таблица А.37 - Процесс валидации программных средств (7.2.5)


Положение	ИСО/МЭК 12207
Нет руководства	-

Таблица А.38 - Процесс ревизии программных средств (7.2.6)


Положение	ИСО/МЭК 12207
а) Вопросы риска должны быть включены в ревизии	7.2.6.3.1.3
b) В дополнение к контрактным требуемым ревизиям поставщик, включая конструктора (исполнителя), сопровождающую сторону или оператора, как применимые, может предложить дополнительные совместные ревизии управления. Поставщик и другие применяющие стороны должны запланировать и принять участие в дополнительных ревизиях (анализах) в местоположении и в сроки, предлагаемые поставщиком и согласуемые приобретающей стороной. Эти ревизии должны быть посещаемы специалистами с полномочиями для принятия решений по стоимости и срокам и могут иметь следующие цели: 1) держать менеджмент в курсе проектного статуса, выбранного направления, достигнутых технических соглашений и полного статуса разработанных программных продуктов; 2) решить в совместных технических ревизиях проблемы, которые не могли быть решены; 3) приходить при проведении объединенных технических ревизий к согласованным стратегиям уменьшения краткосрочных и долгосрочных рисков, которые не могли быть разрешены; 4) определить и разрешить при проведении объединенных технических ревизий проблемы менеджмент-уровня и пути снижения рисков; 5) получить обязательства и одобрения приобретающей стороны, необходимые для своевременного выполнения проекта	7.2.6.3.2
с) Поставщик, включая конструктора (исполнителя) и/или сопровождающую сторону и/или оператора, если применимо, должны запланировать и принять участие в объединенных технических ревизиях в местоположении и в сроки, предлагаемые поставщиком и согласуемые приобретающей стороной. Эти ревизии должны быть посещаемы специалистами с техническим знанием программных продуктов, которые будут проводить ревизии. Дисциплины процесса поддержки (например, обеспечения качества, управления конфигурацией, верификация, аттестация) должны обеспечить вход процесса или использоваться в совместных ревизиях. Ревизии в большей степени должны сосредоточиваться на незавершенных и заключительных продуктах программных средств, нежели на материалах, произведенных специально для ревизии. У ревизий могут быть следующие цели: 1) проанализировать развивающиеся продукты программных средств, которые удовлетворяют критериям завершенности; проанализировать и продемонстрировать предложенные технические решения; проникнуть в суть и получить обратную связь в предпринимаемых технических усилиях; покрыть и разрешить технические проблемы; 2) проанализировать статус проекта и покрыть краткосрочные и долгосрочные риски, связанные с техническими, стоимостными и временными проблемами; 3) прийти к согласованным стратегиям уменьшения идентифицированных рисков в пределах полномочий сложившегося представления; 4) идентифицировать риски и связанные с ними проблемы для их разрешения в совместных управлениях ревизиями; 5) убедиться в продолжающейся связи между техническим персоналом приобретающей стороны и поставщика	7.2.6.3.3

Таблица А.39 - Процесс аудита программных средств (7.2.7)


Положение	ИСО/МЭК 12207
Нет руководства	-

Таблица А.40 - Процесс решения проблем в программных средствах (7.2.8)


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

А.8 Процессы повторного применения программных средств (7.3)

Таблица А.41 - Процесс проектирования доменов (7.3.1)


Положение	ИСО/МЭК 12207
Нет руководства	-

Таблица А.42 - Процесс менеджмента повторного применения активов (7.3.2)


Положение	ИСО/МЭК 12207
Нет руководства	-

Таблица А.43 - Процесс менеджмента повторного применения программ (7.3.3)


Положение	ИСО/МЭК 12207
Нет руководства	-

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

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

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

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

В.2 Оценка повторно применяемых программных продуктов

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

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

b) способность обеспечить требуемую безопасность и защиту частной жизни;

c) надежность/зрелость, что свидетельствуется установленной репутацией;

d) тестируемость;

e) интероперабельность с другими системными и внешнесистемными элементами;

f) проблемы распространения, включая:

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

2) лицензионную или иную оплату, применимую к каждой копии;

g) сопровождаемость, включая:

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

2) осуществимость тех изменений;

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

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

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

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

7) доступные гарантии;

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

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

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


[1]	IEC 61160:2005, Анализ проекта (Design Review)
[2]	IEEE Std 730-2002, Стандарт IEEE для планов по обеспечению качества программных средств (IEEE Standard for Software Quality Assurance Plans)
[3]	IEEE Std 829-2008, Стандарт IEEE для документации по программным и системным тестам (IEEE Standard for Software and System Test Documentation)
[4]	IEEE Std 983-1986, Стандарт IEEE Руководство для планирования обеспечения качества программных средств (IEEE Guide for Software Quality Assurance Planning)
[5]	IEEE Std 1008-1987, Стандарт IEEE для тестирования программных блоков (IEEE Standard for Software Unit Testing)
[6]	IEEE Std 1012-2004, Стандарт IEEE для верификации и валидации программных средств (IEEE Standard for Software Verification and Validation)
[7]	IEEE Std 1016-1998, Стандарт IEEE Рекомендуемая практика для описания программного проекта (IEEE Recommended Practice for Software Design Descriptions)
[8]	IEEE Std 1028-2008, Стандарт IEEE для ревизий и аудитов программных средств (IEEE Standard for Software Reviews and Audits)
[9]	IEEE Std 1042-1987, Руководство IEEE по менеджменту конфигурации программных средств (IEEE Guide to Software Configuration Management)
[10]	IEEE Std 1044-2009, Стандарт IEEE Классификация по программным аномалиям (IEEE Standard Classification for Software Anomalies)
[11]	IEEE Std 1062-1998, Рекомендуемая практика для приобретения программных средств (IEEE Recommended Practice for Software Acquisition)
[12]	IEEE Std 1074-2006, Стандарт IEEE для разработки процесса жизненного цикла программных средств (IEEE Standard for Developing a Software Project Life Cycle Process)
[13]	IEEE Std 1298-1992, Стандарт IEEE Система менеджмента качества программных средств (IEEE Standard Software Quality Management System)
[14]	IEEE Std 1320.1-1998, Стандарт для языка функционального моделирования - Синтаксис и семантика для IDEF0 (IEEE Standard for functional modelling language - Syntax and semantics for IDEF0)
[15]	IEEE Std 1490-2003, Руководство IEEE: Принятие стандарта Института PMI: Руководство органам знаний по управлению проектами (IEEE Guide: Adoption of PMI Standard - A Guide to the Project Management Body of Knowledge)
[16]	IEEE Std 1517-1999, Стандарт IEEE для информационных технологий - Процессы жизненного цикла программных средств - Процессы повторного использования (IEEE Standard for Information Technology - Software Life Cycle Processes - Reuse Processes)
[17]	IEEE/EIA 12207.0-1996, Промышленная реализация MC ИСО/МЭК 12207:1995 Стандарт ИТ. Процессы жизненного цикла программных средств (Industry Implementation of International Standard ISO/IEC 12207:1995, (ISO/IEC 12207) Standard for Information Technology - Software life cycle processes)
[18]	IEEE/EIA 12207.1-1997, Промышленная реализация MC ИСО/МЭК 12207:1995 Стандарт ИТ. Процессы жизненного цикла программных средств - Данные жизненного цикла (Industry Implementation of International Standard ISO/IEC 12207:1995, (ISO/IEC 12207) Standard for Information Technology - Software life cycle processes - Life cycle data)
[19]	IEEE/EIA 12207.2-1997, Промышленная реализация MC ИСО/МЭК 12207:1995 Стандарт ИТ. Процессы жизненного цикла программных средств - Рассмотрения реализации (Industry Implementation of International Standard ISO/IEC 12207:1995, (ISO/IEC 12207) Standard for Information Technology - Software life cycle processes - Implementation considerations)
[20]	ISO 9000:2005, Системы менеджмента качества. Основные положения и словарь (Quality management systems - Fundamentals and vocabulary)
[21]	ISO/IEC 14764:2006, Программная инженерия. Процессы жизненного цикла программных средств. Сопровождение (Software Engineering - Software Life Cycle Processes - Maintenance)
[22]	ISO/IEC 15288:2008, Системная и программная инженерия. Процессы жизненного цикла систем (Systems and software engineering - System life cycle processes)
[23]	ISO/IEC 15289:2006, Системная и программная инженерия. Содержание информационных продуктов для процессов жизненного цикла программных средств и систем (документация) (Systems and software engineering - Content of systems and software life cycle process information products (Documentation))
[24]	ISO/IEC 15504-1:2004, ГОСТ P ИСО/МЭК 15504-1 Информационная технология. Оценка процессов. Часть 1. Концепция и словарь (Information technology - Process assessment - Part 1: Concepts and vocabulary)
[25]	ISO/IEC 15504-2:2003, ГОСТ P ИСО/МЭК 15504-2 Информационная технология. Оценка процессов. Часть 2. Проведение оценки (Information technology - Process assessment - Part 2: Performing an assessment)
[26]	ISO/IEC 16085:2006, Системная и программная инженерия. Менеджмент жизненного цикла. Менеджмент рисков (Systems and software engineering - Life cycle process - Risk management)
[27]	ISO/IEC/IEEE 16326:2009, Системная и программная инженерия. Процессы жизненного цикла. Управление проектом (Systems and software engineering - Life cycle processes - Project management)
[28]	ISO/IEC TR 19759:2005, Программная инженерия. Руководство к своду знаний по программной инженерии (Software Engineering - Guide to the Software Engineering Body of Knowledge (SWEBOK))
[29]	ISO/IEC 20000 (all parts), Информационная технология. Менеджмент услуг (Information technology - Service management)
[30]	ISO/IEC TR 24774:2007, Системная и программная инженерия. Менеджмент жизненного цикла. Руководящие указания по определению процессов (Software and systems engineering - Life cycle management - Guidelines for process description)
[31]	ISO/IEC 26702:2007, Системная инженерия. Применение и менеджмент процесса системной инженерии (Systems engineering - Application and management of the systems engineering process)
[32]	ISO/IEC 42010:2007, Системная и программная инженерия. Рекомендуемая практика по описанию архитектуры программных систем. Разработка (Systems and software engineering - Recommended practice for architectural description of software-intensive systems)
[33]	ISO/IEC 90003:2004, Программная инженерия. Руководство по применению ИСО 9001:2000 к компьютерным программным средствам (Software engineering - Guidelines for the application of ISO 9001:2000 to computer software)


УДК 004.4.006.39:006.354		ОКС 35.080
Ключевые слова: программные средства, процессы жизненного цикла, оценивание, критерии, характеристики, модели и стадии жизненного цикла, эталонная модель процессов, менеджмент, риски, конфигурации, архитектура, проектирование, тестирование, верификация, валидация, повторное применение, адаптация

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2016