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

(утв. и введен в действие Приказом Росстандарта от 18.05.2016 № 334-ст)

Утвержден и введен в действие Приказом Федерального

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

ЧАСТЬ 3

Information technologies. Systems and software engineering.

of ISO/IEC 12207 (Software life cycle processes)

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

Дата введения

Предисловие

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 мая 2016 г. № 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)»)

Введение

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

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

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

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

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

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

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

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

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

3.3 Контекст

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

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

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

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

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

Пример:

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

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.

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

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

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

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

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

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

Примечание — Это может быть выполнено путем адаптации жизненного цикла, как это описано в ИСО/МЭК 24748-1 (разделы 6 и 7), и приспосабливания согласно описанию в приложении A ИСО/МЭК 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 Входы

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

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

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 Обеспечивающие механизмы

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

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

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

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

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

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

4.4.2.1 Введение

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

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

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

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

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

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

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

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

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

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

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 — Процессы в контексте системы

Примечание — Суть процессов контекста системы представлена в ИСО/МЭК 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 — Специальные процессы программных средств

Три группы специальных процессов программных средств по ИСО/МЭК 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) с дальнейшими пояснениями в приложении A.

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

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

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

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

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

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

5.1 Обзор

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

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

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

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

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

5.2.1 Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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 — Применение процесса к форме формального соглашения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) ряд алгоритмов, произошедших из контекстных диаграмм;

l) диаграмма 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 продолжается, пока все системные элементы структуры системы не будут определены, и никакие дополнительные системы или системные элементы не должны более быть разработаны. Системные элементы могут произойти на любом уровне «x» структуры системы. На каждом уровне, когда никакое дальнейшее развитие не является необходимым для системы в структуре системы, должно быть выполнено следующее множество процессов для реализации. Это пример рекурсивного применения технических процессов, чтобы улучшить определение высшего уровня для рассматриваемой системы путем определения систем более низкого уровня и системных элементов. Высший уровень для одной организации может быть системой, которая будет закуплена потребителем на коммерческом рынке, например такой системой, как автомобиль. Высший уровень для другой организации может быть системой в пределах структуры системы, например, такой системой, как двигатель, который будет собран в автомобиль другой организацией.

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

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

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

5.4.3.3.1 Общее

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

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

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

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

5.4.4.1 Обзор

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

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

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

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

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

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

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

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

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

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

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 Общее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРИМЕЧАНИЯ ДЛЯ ПРИМЕНЕНИЯ ПРОЦЕССОВ ИСО/МЭК 12207

A.1 Общее

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

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

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

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

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

Таблица A.1

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

Таблица A.2

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

Процесс менеджмента модели жизненного цикла (6.2.1)

Таблица A.4

Процесс менеджмента инфраструктуры (6.2.2)

Процесс менеджмента портфеля проектов (6.2.3)

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

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

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

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

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

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

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

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

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

e) интероперабельность с другими системными и внешнесистемными элементами;

f) проблемы распространения, включая:

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

2. лицензионную или иную оплату, применимую к каждой копии;

g) сопровождаемость, включая:

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

2. осуществимость тех изменений;

3. пригодность и качество документации и исходных файлов;

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

5. воздействие на систему, если текущая версия не поддерживается;

6. использование приобретающей стороной права собственности на программный продукт;

7. доступные гарантии;

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

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

БИБЛИОГРАФИЯ