ГОСТ Р ИСО/МЭК 26555-2016. Национальный стандарт Российской Федерации. Системная и программная инженерия. Инструменты и методы технического менеджмента линейки продуктов

Федеральное агентство по техническому регулированию и метрологии · № ГОСТ Р ИСО/МЭК 26555-2016Действующий акт

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

Примечание

Документ введен в действие с 1 июня 2017 года.

Утвержден и введен в действие
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 18 мая 2016 г. № 336-ст

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

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

ИНСТРУМЕНТЫ И МЕТОДЫ ТЕХНИЧЕСКОГО МЕНЕДЖМЕНТА ЛИНЕЙКИ ПРОДУКТОВ

Systems and software engineering. Tools and methods for product line technical management

ISO/IEC 26555:2013 Systems and software engineering — Tools and methods for product line technical management (IDT)

ГОСТ Р ИСО/МЭК 26555-2016

ОКС 35.080

Дата введения
1 июня 2017 года

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 26555:2013 «Системная и программная инженерия. Инструменты и методы для технического менеджмента линейки продуктов» (ISO/IEC 26555:2013 «Software and systems engineering — Tools and methods for product line technical management»).

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

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

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

Введение

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

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

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

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

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

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

ИСО/МЭК 26550 устанавливает требования к управлению, а также ключевым характеристикам линейки продуктов. ИСО/МЭК 26550 входит в серию международных стандартов (ИСО/МЭК 26551 — ИСО/МЭК 26556), а также рассматривает структуру модели:

процессы и возможности методов и инструментов определения границ линейки продуктов, требований к разработке домена и требований к разработке приложений определены в ИСО/МЭК 26551 «Системная и программная инженерия. Инструменты и методы разработки требований к линейке продуктов»;
процессы и возможности методов и инструментов для проектирования домена и проектирования приложений определены в ИСО/МЭК 26552 «Системная и программная инженерия. Инструменты и методы проектирования архитектуры линейки продуктов»;
процессы и возможности методов и инструментов для реализации домена и реализации приложений определены в ИСО/МЭК 26553 «Системная и программная инженерия. Инструменты и методы реализации линейки продуктов»;
процессы и возможности методов и инструментов для верификации и валидации домена, для верификации и валидации приложений определены в ИСО/МЭК 26554 «Системная и программная инженерия. Инструменты и методы верификации и валидации линейки продуктов»;
процессы и возможности методов и инструментов для технического менеджмента определены в ИСО/МЭК 26555 «Системная и программная инженерия. Инструменты и методы технического менеджмента линейки продуктов»;
процессы и возможности методов и инструментов для организационного управления определены в ИСО/МЭК 26556 «Системная и программная инженерия. Инструменты и методы организационного менеджмента линейки продуктов».

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

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

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

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

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

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

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

ИСО/МЭК 12207:2008, Системная и программная инженерия — Процессы жизненного цикла программного обеспечения (ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes)

ИСО/МЭК 15288:2008, Системная и программная инженерия — Процессы жизненного цикла систем (ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes)

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

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

3.1 процесс разработки приложения (application engineering process): Набор процессов, предназначенных для разработки продукта из линейки продуктов.

3.2 связанный процесс (attached process): Процесс, определяющий использование в приложении каждого актива.

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

3.3 время связывания (binding time): Момент времени разрешения вариабельности.

3.4 внешняя вариабельность (external variability): Изменяемость, видимая потребителям.

3.5 процесс разработки домена (domain engineering process): Набор процессов, необходимых для разработки актива домена.

3.6 внутренняя вариабельность (internal variability): Изменяемость, определенная с точки зрения разработчика, но не видимая потребителями.

3.7 связывание вариабельности (variability binding): Действие определения варианта в точке вариации, определенной в модели вариабельности.

3.8 документация по вариабельности (variability documentation): Подробное описание моделей вариабельности для использования в продуктах из линейки продуктов.

3.9 вариабельность в пространстве (variability in space): Вариация, происходящая в один и тот же момент времени различным образом.

3.10 вариабельность во времени (variability in time): Вариация, происходящая в разное время.

3.11 механизм вариабельности (variability mechanism): Механизм управления вариантами в линейке продуктов для поддержки сборки активов домена.

3.12 прослеживаемость вариабельности (variability traceability): Способ прослеживания связей, установленных для модели вариабельности как для активов домена, так и для ресурсов приложений в случаях, если варианты связаны.

4. Эталонные модели технического менеджмента линейки продуктов

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

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

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

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

┌─────────────────────────┐┌────────────────────────────┐┌──────────────────────┐
│  Менеджмент процессов   ││ Менеджмент вариабельности  ││  Менеджмент активов  │
│┌───────────────────────┐││┌──────────────────────────┐││┌────────────────────┐│
<pre class="legal-pre">││ Процессы обеспечения  ││││    Менеджмент модели     ││││                    ││
││ применяемых процессов ││││      вариабельности      ││││Идентификация актива││
││ для линеек продуктов  ││││                          ││││                    ││</pre>
│└───────────────────────┘││└──────────────────────────┘││└────────────────────┘│
│┌───────────────────────┐││┌──────────────────────────┐││┌────────────────────┐│
<pre class="legal-pre">││ Определение процессов ││││  Управление связыванием  ││││  Реализация базы   ││
││   разработки домена   ││││      вариабельности      ││││      активов       ││</pre>
│└───────────────────────┘││└──────────────────────────┘││└────────────────────┘│
│┌───────────────────────┐││┌──────────────────────────┐││┌────────────────────┐│
<pre class="legal-pre">││ Определение процессов ││││ Менеджмент документации  ││││Верификация активов ││
││ разработки приложения ││││      вариабельности      ││││                    ││</pre>
│└───────────────────────┘││└──────────────────────────┘││└────────────────────┘│
│┌───────────────────────┐││┌──────────────────────────┐││┌────────────────────┐│
<pre class="legal-pre">││Мониторинг и управление││││                          ││││                    ││
││применяемыми процессами││││Трассировка вариабельности││││  Развитие активов  ││
││ для линеек продуктов  ││││                          ││││                    ││</pre>
│└───────────────────────┘││└──────────────────────────┘││└────────────────────┘│
<pre class="legal-pre">│┌───────────────────────┐││┌──────────────────────────┐││                      │
││   Совершенствование   ││││  Управление и развитие   │││                      │
││ применяемых процессов ││││      вариабельности      │││                      │
││ для линеек продуктов  ││││                          │││                      │
│└───────────────────────┘││└──────────────────────────┘││                      │</pre>
└─────────────────────────┘└────────────────────────────┘└──────────────────────┘
┌───────────────────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│                     ┌────────────────────────┐ ┌─────────────────────────┐    │
│ Процессы поддержки  │ Технический менеджмент │ │ Менеджмент конфигурации │    │
│    менеджмента      │   качества для ЛППС    │ │        для ЛППС         │    │
│                     └────────────────────────┘ └─────────────────────────┘    │</pre>
│┌────────────────────────┐ ┌──────────────────────┐ ┌─────────────────────────┐│
<pre class="legal-pre">││ Технический менеджмент │ │  Менеджмент решений  │ │ Менеджмент инструментов ││
││    рисков для ЛППС     │ │       для ЛППС       │ │        для ЛППС         ││</pre>
│└────────────────────────┘ └──────────────────────┘ └─────────────────────────┘│
└───────────────────────────────────────────────────────────────────────────────┘

Рисунок 1 — Технический менеджмент линейки продуктов

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

Категория	Аспект
Менеджмент повторного использования	Разработка приложений, активы, разработка домена, управление продуктом, платформа, возможность многократного использования
Менеджмент вариабельности	Связывание, вариабельность
Менеджмент сложности	Совместные работы, конфигурация, доменная архитектура, поддержка передовых технологий, структура, прослеживаемость
Менеджмент качества	Измерение и отслеживание, верификация и валидация

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

5. Управление процессами

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

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

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

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

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

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

Входы:

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

Выходы:

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

Задачи:

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

5.1.1 Создать группу управления процессами

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

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

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

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

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

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

5.1.2 Согласовать ресурсы для определения и совершенствования процессов

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

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

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

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

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

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

5.1.3 Руководить определением и совершенствованием процессов

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

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

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

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

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

5.1.4 Подготовить управление процессами и их совершенствованием

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

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

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

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

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

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

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

5.2. Определение процессов разработки домена

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

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

Входы:

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

Результаты:

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

Задачи:

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

5.2.1 Определить процессы разработки домена

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

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

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

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

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

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

5.2.2 Проверить процессы разработки домена

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

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

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

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

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

5.2.3 Развернуть процессы разработки домена

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

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

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

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

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

5.3. Определение процессов разработки приложения

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

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

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

Входы:

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

Результаты:

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

Задачи:

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

5.3.1 Определить процессы разработки приложений

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

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

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

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

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

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

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

5.3.2 Проверить соответствие процессов разработки приложений процессам разработки домена

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

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

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

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

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

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

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

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

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

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

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

5.4. Применение процесса мониторинга и управления для линеек продуктов

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

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

Входы:

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

Результаты:

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

Задачи:

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

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

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

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

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

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

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

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

5.4.2 Определить критерии качества работы процесса

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

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

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

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

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

5.4.3 Измерить производительность процесса и управлять ею

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

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

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

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

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

5.4.4 Координировать процессы улучшения многократного использования

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

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

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

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

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

5.5. Применение совершенствования процессов для линеек продуктов

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

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

Входы:

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

Результаты:

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

Задачи:

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

5.5.1 Оценить процессы

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

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

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

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

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

5.5.2 Оценить влияние изменений процессов

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

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

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

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

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

5.5.3 Планировать совершенствование процесса

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

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

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

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

совместно применять план совершенствования процессов вместе с заинтересованными сторонами;
создавать отчеты о состоянии реализации плана;
обновлять планы.

5.5.4 Реализовать совершенствование процесса

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

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

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

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

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

5.5.5 Оценить совершенствование процесса

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

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

определение метрик;
измерение результатов;
анализ результатов измерения;
интеграцию накопленного опыта в линейки продуктов.

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

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

6. Менеджмент вариабельности

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

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

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

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

Менеджмент вариабельности обеспечивает следующее:

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

6.1. Менеджмент модели вариабельности

Цель менеджмента модели вариабельности

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

Входы:

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

Результаты:

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

Задачи:

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

6.1.1 Установить политику моделирования вариабельности

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

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

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

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

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

Инструментарий для моделирования вариабельности должен обеспечивать следующие возможности:

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

6.1.2 Собрать информацию по вариабельности

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

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

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

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

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

6.1.3 Проверить модели вариабельности

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

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

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

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

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

6.1.4 Совместно использовать и поддерживать модели вариабельности

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

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

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

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

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

6.2. Менеджмент документации вариабельности

Цель менеджмента документации вариабельности

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

Входы:

модели вариабельности;
информация, относящаяся к вариабельности.

Результаты:

модели вариабельности документированы.

Задачи:

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

6.2.1 Установите правила документирования вариабельности

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

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

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

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

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

6.2.2 Соберите аннотации моделей вариабельности

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

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

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

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

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

6.2.3 Проверить документацию по вариабельности

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

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

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

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

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

6.3. Управление связыванием вариабельности

Цель управления связыванием вариабельности

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

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

Входы:

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

Результаты:

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

Задачи:

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

6.3.1 Установить правила связывания

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

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

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

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

применять правила связывания совместно с соответствующими заинтересованными сторонами.

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

Назначение задачи: руководить анализом альтернатив времени связывания.

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

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

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

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

6.3.3 Руководить принятием решения о времени связывания

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

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

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

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

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

6.3.4 Поддерживать информацию о связывании

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

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

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

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

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

6.4. Трассировка вариабельности

Цель трассировки вариабельности

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

Входы:

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

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

Результаты:

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

Задачи:

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

6.4.1 Установить правила менеджмента прослеживаемости моделей вариабельности

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

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

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

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

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

6.4.2 Определить связи между моделью вариабельности и активами домена

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

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

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

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

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

6.4.3 Управлять изменениями конкретных связей трассировки

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

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

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

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

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

6.5. Управление и развитие вариабельности

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

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

Входы:

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

Результаты:

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

Задачи:

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

6.5.1 Идентифицировать и проанализировать необходимость развития вариантов

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

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

анализ запросов на изменение вариантов из запросов на развитие вариабельности;
анализ влияния изменений вариантов (с использованием механизма вариабельности);
формирование списка необходимых изменений.

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

отображение взаимосвязей вариабельности в явном виде;
выделение затронутых изменениями элементов моделей.

6.5.2 Добавить или удалить варианты

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

Методология должна обеспечивать при добавлении или удалении следующие возможности:

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

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

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

6.5.3 Добавить или удалить зависимости и ограничения

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

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

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

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

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

6.5.4 Изменить время связывания

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

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

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

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

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

6.5.5 Поддерживать затронутые прослеживаемости

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

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

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

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

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

6.5.6 Обеспечить обратную связь по вариабельности и процессу развития вариабельности

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

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

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

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

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

7. Управление активами

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

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

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

7.1. Идентификация актива

Цель идентификации активов

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

Входы:

все артефакты, произведенные в ходе разработки домена/приложений;

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

Результаты:

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

Задачи:

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

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

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

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

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

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

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

7.1.2 Определить кандидатуры активов

Цель этой задачи заключается в поиске и извлечении кандидатов актива из базы активов домена/приложений.

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

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

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

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

7.1.3 Оценить затраты, необходимые для создания, повторного использования и обновления активов домена

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

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

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

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

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

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

7.1.4 Определить активы

Кандидатов актива оценивают в соответствии с критериями оценки, а для определения активов принимают четко обоснованные решения.

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

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

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

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

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

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

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

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

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

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

7.2. Реализация базы активов

Цель реализации базы активов

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

Входы:

артефакты домена;
артефакты приложения.

Результаты:

создана система поиска актива;
создана база активов.

Задачи:

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

7.2.1 Создать механизм поиска (или извлечения) активов

Механизм поиска активов тесно связан с системой конфигурации актива.

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

определение классификации активов;
выбор атрибутов для извлечения активов. Атрибуты выбираются из числа внутренних или внешних атрибутов активов;
определение представления выбранных атрибутов для поиска.

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

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

7.2.2 Определить и реализовать для активов метод CRUD

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

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

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

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

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

7.2.3 Создать базу активов

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

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

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

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

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

7.2.4 Оценить базу активов

Базу активов анализируют и проверяют для подтверждения надлежащего использования конфигурации активов, механизма поиска и процессов CRUD.

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

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

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

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

7.3. Верификация активов

Цель верификации активов

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

Входы:

активы;
конфигурация активов.

Результаты:

получены результаты верификации конфигурации активов;
созданы базисы активов.

Задачи:

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

7.3.1 Проанализировать отобранные активы

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

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

определение критериев оценки активов;
оценка правильности отбора активов согласно критериям.

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

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

7.3.2 Проанализировать конфигурации активов

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

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

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

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

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

7.3.3 Создать и подготовить к использованию базисы активов

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

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

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

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

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

7.4. Развитие актива (включая менеджмент изменений)

Цель развития активов

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

Входы:

база активов;
запросы на изменения активов.

Результаты:

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

Задачи:

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

7.4.1 Управлять изменениями актива

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

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

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

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

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

7.4.2 Поддерживать прослеживаемость активов

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

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

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

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

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

7.4.3 Управлять обратной связью

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

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

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

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

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

7.4.4 Преобразовывать ранее созданные активы в реконструированную форму для размещения в базе активов

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

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

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

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

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

7.4.5 Удаление активов из базы активов

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

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

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

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

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

8. Процессы поддержки управления

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

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

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

8.1. Технический менеджмент качества для ЛППС

Цель технического менеджмента качества для ЛППС

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

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

Входы:

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

артефакты разработки линеек продуктов (активы, продукты, артефакты приложения).

Результаты:

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

Задачи:

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

8.1.1 Создать техническую политику менеджмента качества

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

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

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

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

совместное применение процесса технической политики менеджмента качества.

8.1.2 Определить и поддерживать критерии обеспечения качества

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

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

отбор процессов, артефактов домена/приложений или приложений для объективной оценки;
определение критериев оценки для двух направлений процессов разработки: разработки домена и разработки приложений.

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

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

8.1.3 Оценить качество согласно критериям

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

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

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

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

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

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

8.1.4 Информировать и обеспечить совместное использование информации о разрешении проблем несоответствия

Цель этой задачи заключается в подтверждении разрешения проблем качества.

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

Методология должна обеспечивать при информировании и обеспечении разрешения проблем несоответствия следующие возможности:

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

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

предоставление среды совместной работы для доменных инженеров, инженеров приложений, менеджмента и обеспечения качества;
отслеживание состояния проблем несоответствия.

8.2. Менеджмент конфигурации для ЛППС

Цель менеджмента конфигурации для ЛППС

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

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

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

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

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

Входы:

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

Результаты:

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

Задачи:

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

8.2.1 Идентифицировать конфигурации продуктов линейки

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

Разделение концепций «общий/переменный» и «время/пространство» упрощает менеджмент конфигурации в линейке продуктов.

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

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

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

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

8.2.2 Создать дерево конфигурации для линейки продуктов

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

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

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

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

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

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

8.2.3 Управлять конфигурациями вариабельности в пространстве

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

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

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

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

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

8.3. Менеджмент решения для ЛППС

Цель менеджмента решения для ЛППС

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

Входы:

потребность в решении;
среда принятия решения;
историческая информация по решению.

Результаты:

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

Задачи:

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

8.3.1 Установить политику менеджмента решения

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

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

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

Примечание - Пример универсальной процедуры решения:

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

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

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

8.3.2 Адаптировать процедуру принятия решения

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

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

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

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

предоставление шаблона адаптации.

8.3.3 Руководить принятием решения

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

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

документирование обоснования решения;
оценка результативности решения.

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

обеспечение поддержки принятия решений с несколькими критериями;
предоставление шаблонов для документирования.

8.3.4 Извлечь уроки из результата принятия решения

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

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

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

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

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

8.4. Технический менеджмент рисков для ЛППС

Цель технического менеджмента рисков для ЛППС

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

Входы:

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

Результаты:

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

Задачи:

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

8.4.1 Идентифицировать технические риски

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

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

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

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

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

8.4.2 Оценить технические риски

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

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

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

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

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

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

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

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

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

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

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

8.4.4 Активировать действия по плану смягчения отрицательных последствий

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

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

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

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

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

8.5. Менеджмент инструментария для ЛППС

Цель менеджмента инструментария для ЛППС

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

Примечание - Выбор и оценка инструментария CASE описаны в ИСО/МЭК 14102.

Входы:

запросы на инструментальную поддержку.

Результаты:

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

Задачи:

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

8.5.1 Определить потребности в инструментальной поддержке

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

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

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

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

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

8.5.2 Выбрать и адаптировать инструменты

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

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

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

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

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

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

8.5.3 Установить и поддерживать инструменты

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

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

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

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

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

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

ТЕХНИЧЕСКИЙ МЕНЕДЖМЕНТ И УРОВНИ ТЕХНИЧЕСКОЙ ГОТОВНОСТИ (TRL)

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

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

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

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

Однако проект системы высокоскоростных железных дорог, разработанный в первый год, должен «заморозить» много интерфейсов, даже если высокоскоростные поезда не разработаны в деталях — необходимо определить условия электропитания, обмена информацией, физические размеры, ожидаемую скорость и т.д. Таким образом системные архитекторы должны учесть некоторые предполагаемые технологические возможности. Уровень технической готовности — это способ указать, насколько зрелыми являются предполагаемые технологии, а также путь снижения риска их использования. Значение уровня технической готовности может изменяться от низкого уровня (перспектива) до высокого (уверенность).

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

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

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

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

ВЗАИМОСВЯЗЬ С ПРОЦЕССАМИ ПО ИСО/МЭК 12207

Категория и процесс по ИСО/МЭК 12207		Соответствующие процесс и подпроцесс по настоящему стандарту
Соглашение	1 Приобретение
Соглашение	2 Поставка
Процессы организационного обеспечения проекта	3 Менеджмент модели жизненного цикла	1 Менеджмент процессов	Процессы обеспечения применяемых процессов для линеек продуктов	S1
			Определение процессов разработки домена	N
			Определение процессов разработки приложения	N
			Процесс мониторинга и управления	S1
			Совершенствование процесса	S1
	4 Менеджмент инфраструктуры		Процессы обеспечения применяемых процессов для линеек продуктов	S1
	5 Менеджмент портфеля проекта
	6 Менеджмент людских ресурсов		Процессы обеспечения применяемых процессов для линеек продуктов	S1
	7 Менеджмент качества	4 Управление поддержкой	Технический менеджмент качества	S1
Проект	8 Планирование проекта	4 Управление поддержкой	Техническое планирование и управление	N
	9 Оценка проекта и процесс управления	4 Управление поддержкой	Техническое планирование и управление	S1
	10 Менеджмент решения	4 Управление поддержкой	Менеджмент решения	S0
	11 Менеджмент рисков	4 Управление поддержкой	Технический менеджмент риска	N
	12 Менеджмент конфигурации	4 Управление поддержкой	Менеджмент конфигурации	S2
	13 Информационный менеджмент
	14 Измерение	4 Управление поддержкой	Процесс мониторинга и управления	S2
Технический	15 Определение требований заинтересованной стороны
	16 Анализ системных требований
	17 Архитектурный проект системы
	18 Реализация
	19 Системная интеграция
	20 Квалификационное тестирование системы
	21 Установка программного обеспечения
	22 Поддержка приемки программного обеспечения
	23 Функционирование программного обеспечения
	24 Поддержка программного обеспечения
	25 Прекращение применения программного обеспечения
Реализация ПО	26 Реализация программного обеспечения
	27 Анализ требований к программному обеспечению
	28 Архитектурный проект программного обеспечения
	29 Детальное проектирование программного обеспечения
	30 Конструирование программного обеспечения
	31 Комплексирование программного обеспечения
	32 Квалификационное тестирование программного обеспечения
Поддержка ПО	33 Менеджмент документации ПО			S0
	34 Менеджмент конфигурации ПО	4 Управление поддержкой	Менеджмент конфигурации	S2
	35 Обеспечение гарантии качества ПО	4 Управление поддержкой	Технический менеджмент качества	S2
	36 Верификация ПО			S0
	37 Валидация ПО			S0
	38 Ревизия ПО			S0
	39 Аудит ПО			S0
	40 Решение проблем ПО			S0
Повторное использование программного обеспечения	41 Проектирование домена
	42 Менеджмент повторного применения программ	Технический менеджмент		S3
	43 Менеджмент повторного применения актива	3 Менеджмент актива	Реализация базы активов	S3
			Идентификация активов	N
			Аннотация активов	N
			Верификация активов	N
			Развитие актива	N
		2 Менеджмент вариабельности	Менеджмент модели вариабельности	N
			Управление связанностью вариабельности	N
			Менеджмент документации вариабельности	N
			Трассировка вариабельности	N
			Управление и развитие вариабельности	N
		4 Управление поддержкой	Менеджмент инструмента	N

Условные обозначения:

'N' обозначает 'Недавно добавленный подпроцесс';
'S' обозначает 'Добавленный подпроцесс';

S0: концептуально то же, что и в ИСО/МЭК 12207;

S1: немного дополнено;
S2: значительно дополнено;
S3: существенно дополнено.

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

КОНЦЕПЦИЯ
ПРОЦЕССА, МЕТОДА, ИНСТРУМЕНТА И АСПЕКТА

8.5. Менеджмент инструментария для ЛППС

Рисунок C.1 — Концепция процесса, метода,
инструмента и аспекта

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

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ
НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO/IEC 12207:2008	IDT	ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»
ISO/IEC 15288:2008	-	<*>
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичные стандарты.

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

[1]	Международный стандарт ИСО/МЭК 15940:2006 (ISO/IEC 15940:2006)	Информационные технологии. Службы средств поддержки программных разработок (Information technology. Software engineering environment services)
[2]	Международный стандарт ИСО/МЭК 14102:2008 (ISO/IEC 14102:2008)	Информационные технологии. Руководство по оценке и выбора инструментов CASE (Information technology. Guideline for the evaluation and selection of CASE)
[3]	Международный стандарт ИСО/МЭК 25000:2005 (ISO/IEC 25000:2005)	Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Руководство по SQuaRE (Software engineering. Software product Quality Requirements and Evaluation (SQuaRE). Guide to SQuaRE)
[4]	Международный стандарт ИСО/МЭК TR 19759 (ISO/IEC TR 19759)	Программная инженерия. Руководство по своду знаний по программной инженерии (SWEBOK) (Software Engineering. Guide to the Software Engineering Body of Knowledge (SWEBOK)
[5]	Международный стандарт ИСО/МЭК TR 24748:2010 (ISO/IEC TR 24748:2010)	Системная и программная инженерия. Управление жизненным циклом (Systems and software engineering. Life cycle management)
[6]	Международный стандарт ИСО/МЭК 16085:2006 (ISO/IEC 16085:2006)	Системная и программная инженерия. Процессы жизненного цикла. Менеджмент рисков (Systems and software engineering. Life cycle processes. Risk management)
[7]	Международный стандарт ИСО/МЭК 15939:2007 (ISO/IEC 15939:2007)	Системная и программная инженерия. Процесс измерения (Systems and software engineering. Measurement process)
[8]	Международный стандарт ИСО 26550 (ISO 26550)	Системная и программная инженерия. Эталонная модель разработки и управления линейкой продуктов (Software and Systems Engineering. Reference model for product line engineering and management)
[9]	Klaus Pohl, Günter Böckle , Frank J. van der Linden	Software Product Line Engineering: Foundations, Principles and Techniques. Springer 2005
[10]	Linda M. Northrop, Paul C. Clements	A Framework for Software Product Line Practice, Version 5.0. Software Engineering Institute, Carnegie Mellon University, July 2007