ГОСТ Р 71439-2024. Национальный стандарт Российской Федерации. Системная и программная инженерия. Методы и инструментарии продуктовой линейки программных средств и систем. Общие положения

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

30 сентября 2024 года

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО/МЭК 26580:2021 «Системная и программная инженерия. Методы и инструментарии для подхода к инженерии продуктовой линейки программных средств и систем, ориентированного на характеристики» (ISO/IEC 26580:2021 «Systems and software engineering — Methods and tools for the feature-based approach to software and system product line engineering», NEQ)

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

6 Некоторые положения настоящего стандарта могут являться объектами патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

В общем случае проблематика создания и применения разнородных ПСС остро востребована при решении задач создания, эффективного функционирования и развития сложных систем (см. также [1] - [9]), таких как:

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

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

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

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

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

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

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

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

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

Примечания

1 ПО является одним из видов обеспечения различных автоматизированных систем (АС) наряду с математическим, информационным, лингвистическим, техническим, метрологическим, организационным, методическим и другими видами обеспечения (см. ГОСТ 34.602, ГОСТ Р 59853), информационно-вычислительных систем (ИВС), устройств и систем искусственного интеллекта (СИИ), в том числе киберфизических систем (см. ГОСТ Р 53622, ГОСТ Р 59276, ГОСТ Р 59277).

2 Для ИВС, программно-технического комплекса (ПТК), устройства и СИИ под ПО и программными средствами понимаются также упорядоченная последовательность инструкций (кодов) для вычислительного средства, находящаяся в памяти этого средства и представляющая собой описание алгоритма управления вычислительными средствами, устройства и действий с данными (см. ГОСТ Р 53622, ГОСТ Р 59277).

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

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

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

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

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

ГОСТ 34.602 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

ГОСТ 28806 Качество программных средств. Термины и определения

ГОСТ Р 27.101 Надежность в технике. Надежность выполнения задания и управление непрерывностью деятельности. Термины и определения

ГОСТ Р 27.102 Надежность в технике. Надежность объекта. Термины и определения

ГОСТ Р 51583 Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения

ГОСТ Р 51897 (ISO Guide 73:2009) Менеджмент риска. Термины и определения

ГОСТ Р 51901.1 Менеджмент риска. Анализ риска технологических систем

ГОСТ Р 51904 Программное обеспечение встроенных систем. Общие требования к разработке и документированию

ГОСТ Р 53622 Информационные технологии. Информационно-вычислительные системы. Стадии и этапы жизненного цикла, виды и комплектность документов

ГОСТ Р 53647.1 Менеджмент непрерывности бизнеса. Часть 1. Практическое руководство

ГОСТ Р 54145 Менеджмент рисков. Руководство по применению организационных мер безопасности и оценки рисков. Общая методология

ГОСТ Р 56921/ISO/IEC/IEEE 29119-2:2013 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования

ГОСТ Р 56922/ISO/IEC/IEEE 29119-3:2013 Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

ГОСТ Р 56939 Защита информации. Разработка безопасного программного обеспечения. Общие требования

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

ГОСТ Р 57193 Системная и программная инженерия. Процессы жизненного цикла систем

ГОСТ Р 57272.1 Менеджмент риска применения новых технологий. Часть 1. Общие требования

ГОСТ Р 58412 Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения

ГОСТ Р 58771 Менеджмент риска. Технологии оценки риска

ГОСТ Р 59276 Системы искусственного интеллекта. Способы обеспечения доверия. Общие положения

ГОСТ Р 59277 Системы искусственного интеллекта. Классификация систем искусственного интеллекта

ГОСТ Р 59329 Системная инженерия. Защита информации в процессах приобретения и поставки продукции и услуг для системы

ГОСТ Р 59330 Системная инженерия. Защита информации в процессе управления моделью жизненного цикла системы

ГОСТ Р 59331 Системная инженерия. Защита информации в процессе управления инфраструктурой системы

ГОСТ Р 59332 Системная инженерия. Защита информации в процессе управления портфелем проектов

ГОСТ Р 59333 Системная инженерия. Защита информации в процессе управления человеческими ресурсами системы

ГОСТ Р 59334 Системная инженерия. Защита информации в процессе управления качеством системы

ГОСТ Р 59335 Системная инженерия. Защита информации в процессе управления знаниями о системе

ГОСТ Р 59336 Системная инженерия. Защита информации в процессе планирования проекта

ГОСТ Р 59337 Системная инженерия. Защита информации в процессе оценки и контроля проекта

ГОСТ Р 59338 Системная инженерия. Защита информации в процессе управления решениями

ГОСТ Р 59339 Системная инженерия. Защита информации в процессе управления рисками для системы

ГОСТ Р 59340 Системная инженерия. Защита информации в процессе управления конфигурацией системы

ГОСТ Р 59341 Системная инженерия. Защита информации в процессе управления информацией системы

ГОСТ Р 59342 Системная инженерия. Защита информации в процессе измерений системы

ГОСТ Р 59343 Системная инженерия. Защита информации в процессе гарантии качества для системы

ГОСТ Р 59344 Системная инженерия. Защита информации в процессе анализа бизнеса или назначения системы

ГОСТ Р 59345 Системная инженерия. Защита информации в процессе определения потребностей и требований заинтересованной стороны для системы

ГОСТ Р 59346 Системная инженерия. Защита информации в процессе определения системных требований

ГОСТ Р 59347 Системная инженерия. Защита информации в процессе определения архитектуры системы

ГОСТ Р 59348 Системная инженерия. Защита информации в процессе определения проекта

ГОСТ Р 59349 Системная инженерия. Защита информации в процессе системного анализа

ГОСТ Р 59350 Системная инженерия. Защита информации в процессе реализации системы

ГОСТ Р 59351 Системная инженерия. Защита информации в процессе комплексирования системы

ГОСТ Р 59352 Системная инженерия. Защита информации в процессе верификации системы

ГОСТ Р 59353 Системная инженерия. Защита информации в процессе передачи системы

ГОСТ Р 59354 Системная инженерия. Защита информации в процессе аттестации системы

ГОСТ Р 59355 Системная инженерия. Защита информации в процессе функционирования системы

ГОСТ Р 59356 Системная инженерия. Защита информации в процессе сопровождения системы

ГОСТ Р 59357 Системная инженерия. Защита информации в процессе изъятия и списания системы

ГОСТ Р 59709 Защита информации. Управление компьютерными инцидентами. Термины и определения

ГОСТ Р 59853 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения

ГОСТ Р 59989 Системная инженерия. Системный анализ процесса управления качеством системы

ГОСТ Р 59990 Системная инженерия. Системный анализ процесса оценки и контроля проекта

ГОСТ Р 59991 Системная инженерия. Системный анализ процесса управления рисками для системы

ГОСТ Р 59992 Системная инженерия. Системный анализ процесса управления моделью жизненного цикла системы

ГОСТ Р 59993 Системная инженерия. Системный анализ процесса управления инфраструктурой системы

ГОСТ Р 59994 Системная инженерия. Системный анализ процесса гарантии качества для системы

ГОСТ Р 70921 Системная и программная инженерия. Требования и оценка качества систем и программной продукции (SQuaRE). Концепция требований к качеству

ГОСТ Р 71199 Системы киберфизические. Умный дом. Термины и определения

ГОСТ Р ИСО 9000 Системы менеджмента качества. Основные положения и словарь

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

ГОСТ Р ИСО/МЭК 15026 Информационная технология. Уровни целостности систем и программных средств

ГОСТ Р ИСО/МЭК 15026-1 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь

ГОСТ Р ИСО/МЭК 15026-4 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 4. Гарантии жизненного цикла

ГОСТ Р ИСО/МЭК 16085 Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения

ГОСТ Р ИСО/МЭК 25000 Системная и программная инженерия. Требования и оценка качества систем и программных средств (SQuaRE). Руководство

ГОСТ Р ИСО/МЭК 25010 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов

ГОСТ Р ИСО/МЭК 25020 Системная и программная инженерия. Требования и оценка качества систем и программной продукции (SQuaRE). Основные принципы измерения качества

ГОСТ Р ИСО/МЭК 25023 Системная и программная инженерия. Требования и оценка качества систем и программной продукции (SQuaRE). Измерения качества системы и программной продукции

ГОСТ Р ИСО/МЭК 25040 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки

ГОСТ Р ИСО/МЭК 27001 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования

ГОСТ Р ИСО/МЭК 27002 Информационная технология. Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности

ГОСТ Р ИСО/МЭК 27005 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности

ГОСТ Р МЭК 61069-1 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 1. Терминология и общие концепции

ГОСТ Р МЭК 61069-2 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 2. Методология оценки

ГОСТ Р МЭК 61069-3 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 3. Оценка функциональности системы

ГОСТ Р МЭК 61069-4 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 4. Оценка производительности системы

ГОСТ Р МЭК 61069-5 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 5. Оценка надежности системы

ГОСТ Р МЭК 61069-6 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 6. Оценка эксплуатабельности системы

ГОСТ Р МЭК 61069-7 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 7. Оценка безопасности системы

ГОСТ Р МЭК 61069-8 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 8. Оценка других свойств системы

ГОСТ Р МЭК 61508-4 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения

ГОСТ Р МЭК 61508-5 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 5. Рекомендации по применению методов определения уровней полноты безопасности

ГОСТ Р МЭК 61508-7 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Методы и средства

ГОСТ Р МЭК 62264-1 Интеграция систем управления предприятием. Часть 1. Модели и терминология

ГОСТ Р МЭК 62508 Менеджмент риска. Анализ влияния на надежность человеческого фактора

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

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

В настоящем стандарте применены термины по ГОСТ 27.102, ГОСТ 28806, ГОСТ Р 27.101, ГОСТ Р 27.102, ГОСТ 28806, ГОСТ Р 59853, ГОСТ Р ИСО 9000, ГОСТ Р ИСО/МЭК 15026, ГОСТ Р ИСО/МЭК 15026-1, ГОСТ Р ИСО/МЭК 27001, ГОСТ Р 51897, ГОСТ Р 59709, ГОСТ Р 59991, ГОСТ Р 59994, ГОСТ Р МЭК 61069-1, ГОСТ Р МЭК 61508-4, ГОСТ Р МЭК 62264-1, ГОСТ Р 71199, а также следующие термины с соответствующими определениями: 3.1 автоматизированная система; АС: Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование. Примечания 1 В зависимости от вида деятельности выделяют, например, следующие виды АС: автоматизированные системы управления (АСУ), системы автоматизированного проектирования (САПР), автоматизированные системы научных исследований (АСНИ) и др. 2 В зависимости от вида управляемого объекта (процесса) АСУ подразделяют, например, на АСУ технологическими процессами (АСУТП), АСУ предприятиями (АСУП) и т.д.

[ГОСТ Р 59853-2021, статья 2]

3.2

дефект: Каждое отдельное несоответствие продукции установленным требованиям. ГОСТ 15467-1979, [пункт 38]

3.3

информационно-вычислительная система (программно-технический комплекс): Совокупность данных (баз данных) и программ, функционирующих на вычислительных средствах как единое целое для решения определенных задач. [ГОСТ Р 53622-2009, пункт 3.5]

3.4

искусственный интеллект; ИИ: Способность технической системы имитировать когнитивные функции человека (включая самообучение и поиск решений без заранее заданного алгоритма) и получать при выполнении конкретных практически значимых задач обработки данных результаты, сопоставимые, как минимум, с результатами интеллектуальной деятельности человека. [ГОСТ Р 59276-2020, пункт 3.6]

3.5

киберфизическая система: Информационно-технологическая концепция, подразумевающая интеграцию вычислительных ресурсов в физические процессы. В такой системе датчики, оборудование и информационные системы соединены на протяжении всей цепочки в логику управления для создания стоимости, выходящей за рамки одного предприятия или бизнеса. Эти системы взаимодействуют друг с другом с помощью стандартных интернет-протоколов для прогнозирования, самонастройки и адаптации к изменениям. [ГОСТ Р 59277-2020, пункт 3.29]

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

3.7

ошибка: Недопустимое состояние, которое испытывает система. Примечание — Примером такой ошибки является попытка деления на нуль. [ГОСТ 33707-2016, статья 4.871]

3.8

программное обеспечение автоматизированной системы; программное обеспечение АС: Совокупность программ и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС. [ГОСТ Р 59853-2021, статья 62]

3.9

программное средство в автоматизированной системе; программное средство в АС: Объект, состоящий из программ, процедур, правил, относящихся к функционированию автоматизированной системы, а также сопутствующих им документации и, если предусмотрено, данных. [ГОСТ Р 59853-2021, статья 63]

3.10

программное обеспечение ИВС (программа, программное средство): Упорядоченная последовательность инструкций (кодов) для вычислительного средства, находящаяся в памяти этого средства и представляющая собой описание алгоритма управления вычислительными средствами и действий с данными. [ГОСТ Р 53622-2009, пункт 3.8]

3.11

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

[Адаптировано из ГОСТ Р 59276-2020, статья 3.38]

3.12 программное обеспечение системы; программное обеспечение АС, ИВС, ПТК, устройства, СИИ: Совокупность программ и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС, ИВС, ПТК, устройства, СИИ. 3.13

продукт, продукция: Результат процесса.

[ГОСТ Р 57193-2016, пункт 4.1.29]

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

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

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

3.14 продуктовая линейка: Семейство аналогичных продуктов с различиями в характеристиках. 3.15 система: Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. Примечания 1 Система может рассматриваться как какой-то продукт или как предоставляемые услуги, обеспечивающие этот продукт. 2 На практике интерпретация данного термина зачастую уточняется с помощью ассоциативного существительного, например система самолета. В некоторых случаях слово «система» может заменяться контекстно-зависимым синонимом, например самолет, хотя это может впоследствии затруднить восприятие системных принципов.

[ГОСТ Р 57193-2016, пункт 4.1.44]

3.16

системная инженерия: Междисциплинарный подход, управляющий полным техническим и организаторским усилием, требуемым для преобразования ряда потребностей заинтересованных сторон, ожиданий и ограничений в решение и для поддержки этого решения в течение его жизни. [ГОСТ Р 57193-2016, пункт 4.1.47]

3.17

системный элемент: Представитель совокупности элементов, образующих систему. Пример — Системный элемент может представлять собой технические и программные средства, данные, людей, процессы (например, процессы для обеспечения услуг пользователям), процедуры (например, инструкции оператору), средства, материалы и природные объекты (например, вода, живые организмы, минералы) или любые их сочетания. Примечание — Системный элемент является отдельной частью системы, которая может быть создана для полного выполнения заданных требований. [ГОСТ Р 57193-2016, пункт 4.1.45]

3.18

требование: Требуемая (ожидаемая) количественная или качественная характеристика или свойство объекта, а также связанные ограничения и условия. [ГОСТ Р 59194-2020, пункт 3.1.21]

3.19

система искусственного интеллекта; СИИ: Техническая система, в которой используются технологии искусственного интеллекта, и обладающая искусственным интеллектом. [ГОСТ Р 59276-2020, пункт 3.16]

3.20

технические средства ИВС: Аппаратные и программные средства, используемые для сбора, обработки, хранения, манипуляции и выдачи данных. [Адаптировано из ГОСТ Р 53622-2009, пункт 3.12]

3.21

технологии искусственного интеллекта: Комплекс технологических решений, направленных на создание систем искусственного интеллекта. [ГОСТ Р 59277-2020, пункт 3.44]

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

4 Возможности продуктовой линейки, ориентированной на характеристики

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

Идея разработки продуктовой линейки, ориентированной на характеристики, появилась некоторое время назад как эффективный способ создания портфелей родственных продуктов ПСС с использованием всех преимуществ их сходства и различий, а также управления этими различиями. В настоящем стандарте использование понятия «системная инженерия продуктовой линейки» (СИПЛ) охватывает все виды деятельности в процессах системной и программной инженерии (см. ГОСТ Р 57193), включая планирование конкретных продуктов, разработку, производство, выпуск, развертывание, поддержку в эксплуатации, сопровождение и вывод продуктов из эксплуатации. СИПЛ зародилась в области системной и программной инженерии в 1970-х и 1980-х годах и в значительной степени основывается на концепции многократного использования программных средств, что обеспечивает сокращение сроков разработки, стоимость, повышение качества выходной продукции в продуктовой линейке.

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

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

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

4.2 Совместно используемые активы

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

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

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

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

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

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

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

4.3 Характеристики

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

4.4 Автоматизированные средства разработки

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

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

5 Представление системной инженерии продуктовой линейки

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

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

База активов, изображенная на рисунке 1 в виде большого цилиндра, приобретает несколько особенностей, свойственных для СИПЛ, ориентированной на требуемые характеристики, а именно:

• активы предметной области, иллюстрируемые цилиндром меньшего размера слева, описывают полное множество предметной области. Они явным образом включают в себя формальный каталог характеристик, который играет центральную роль в абстракции и автоматизации этого подхода. Характеристики играют роль общего языка для передачи информации об изменениях в продуктовой линейке. Каталог характеристик выступает в качестве модели изменений. В рамках СИПЛ, ориентированной на требуемые характеристики, для моделирования изменений обычно используются графические описания характеристик;
• в активы предметной области также входят обычные активы для разработки, отмеченные в системной инженерии литерой «V», означающей V-модель (см. рисунок 2), и дополненные точками изменений — точками в активах, которые отмечаются в зависимости от абстрактных изменений характеристик (точки в активах, которые не подвержены изменениям, не требуют такого дополнения и являются частью каждого связанного продукта). Дополнение активов для разработки точками изменений приводит к созданию размеченных наборов совместно используемых активов, которые могут быть автоматически сконфигурированы на основе выбранных характеристик для различных продуктов в линейке;
• активы приложений, показанные на рисунке в виде цилиндра справа, называются экземплярами продукта и явным образом включают в себя формальный портфель спецификаций характеристик, который представляет собой набор отдельных спецификаций — по одному набору для каждого продукта в линейке. Каждый связанный продукт имеет уникальную спецификацию характеристик, в которой конкретные характеристики выбраны из вариантов каталога характеристик;
• в активы для приложений также входят обычные активы для разработки, показанные в виде нескольких литер «V» системной инженерии над текстовым полем «Экземпляры активов продуктов». В экземплярах активов продуктов изменения продуктовой линейки отсутствуют.

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

Поле «Разработка предметной области» вверху на рисунке 1 отражает несколько особенностей, специфичных для СИПЛ, ориентированных на требуемые характеристики:

• разработка требований к предметной области, разработка и проектирование предметной области, верификация и валидация предметной области — все это описания положений классической V-модели в системной инженерии (см. ГОСТ Р 57102) в приложении к размеченным наборам совместно используемых активов (рассматриваемым как система). Связи между элементами на рисунке 1 отражают соответствующие отношения между их V-аналогами во множестве активов предметной области;
• расширения подразумевают добавление точек изменения в активы на протяжении всего их жизненного цикла. Кроме того, СИПЛ, ориентированная на требуемые характеристики, не подразумевает ограничений в отношении методов и инструментариев разработки, применяемых в жизненном цикле продуктов;
• должны быть определены границы предметной области. Область применения продукта определяется в сочетании с разработкой портфеля характеристик (см. 8.4). Спектр задействованных активов определяется в сочетании с разработкой размеченного набора совместно используемых активов (см. 8.5).

Поле «Разработка приложений» снизу на рисунке 1 отражает несколько особенностей, специфичных для СИПЛ, ориентированных на требуемые характеристики:

• разработка требований к приложению, разработка и реализация приложения, а также их верификация и валидация — это описания положений классической V-модели в системной инженерии (см. рисунок 2) в приложении к экземплярам активов продукта. Связи между элементами на рисунке 1 отражают соответствующие отношения между их V-аналогами в каждом экземпляре актива продукта;
• экземпляры активов продукта автоматически создаются конфигуратором продуктовой линейки из размеченных наборов совместно используемых активов и спецификации характеристик. Для активов приложений, полученных из активов предметной области, разработка не требуется;
• акцент в разработке приложений делается на верификации и валидации в правой части литеры «V». Ручные и автоматизированные активы верификации и валидации создаются конфигуратором продуктовой линейки вместе с другими активами продукта для повышения эффективности и точности тестирования. Если в ходе верификации и валидации выявляются проблемы, то устранение дефектов и улучшения выполняются на стороне разработки предметной области. Это показано стрелкой обратной связи от верификации и валидации продукта к разработке предметной области. При этом для проработки обратной связи используются некоторые процессы технического управления. В частности, процесс управления изменениями (см. 8.10) определяет, какие изменения (при их наличии) необходимо внести в каталог характеристик, спецификации характеристик и размеченные наборы совместно используемых активов на основе обратной связи. Затем экземпляры активов продукта воссоздаются и повторно подвергаются верификации и валидации;
• поскольку происходит создание активов продукта, их можно рассматривать как цифровые данные продукта, которые можно использовать, игнорировать, уничтожать и восстанавливать по мере объективной необходимости.

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

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

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

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

Обеспечение качества продуктов в рамках СИПЛ осуществляют с использованием требований ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 15026, ГОСТ Р ИСО/МЭК 15026-4, ГОСТ Р ИСО/МЭК 25000, ГОСТ Р ИСО/МЭК 25010, ГОСТ Р ИСО/МЭК 25020, ГОСТ Р ИСО/МЭК 25023, ГОСТ Р ИСО/МЭК 25040, ГОСТ Р 51583, ГОСТ Р 51901.1, ГОСТ Р 51904, ГОСТ Р 53622, ГОСТ Р 53647.1, ГОСТ Р 54145, ГОСТ Р 56921, ГОСТ Р 56922, ГОСТ Р 56939, ГОСТ Р 57102, ГОСТ Р 57193, ГОСТ Р 57272.1, ГОСТ Р 58412, ГОСТ Р 58771, ГОСТ Р 59276, ГОСТ Р 70921, ГОСТ Р МЭК 61069-2 — ГОСТ Р МЭК 61069-8, ГОСТ Р МЭК 61508-5, ГОСТ Р МЭК 61508-7, ГОСТ Р МЭК 62508 с необходимым учетом специфики.

6 Типовая модель продуктовой линейки программных средств и систем

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

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

6.2 Основные элементы

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

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

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

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

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

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

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

Размеченные наборы совместно используемых активов показаны на рисунке 1 в литере «V» путем разграничения внутренностей этой литеры - . Например, параллелограмм в левом верхнем углу может быть размеченным набором совместно используемых активов системных требований, параллелограмм правее — размеченным набором совместно используемых активов технического проекта системы, а три нижних параллелограмма слева — размеченными наборами совместно используемых активов механического дизайна, электрического дизайна и исходного кода программного обеспечения. Каждый параллелограмм на правой стороне литеры «V» может быть, например, интерпретирован как размеченный набор совместно используемых активов верификации и валидации для своего зеркального отображения на левой стороне литеры «V».

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

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

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

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

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

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

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

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

6.3 Взаимоотношения между основными элементами

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

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

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

6.3.3 В размеченные наборы предметной области входят каталог характеристик и размеченные наборы совместно используемых активов. Оба компонента продуктовой линейки не зависят от какого-либо одного конкретного продукта линейки. Их область применения относится ко всей продуктовой линейке.

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

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

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

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

6.4 Уровни типовой модели

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

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

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

Вместе эти три уровня типовой модели продуктовой линейки дают представление о том, что требуется для реализации преимуществ СИПЛ ПСС.

6.5 Язык характеристик

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

6.6 Поддержка иерархической структуры продуктовых линеек

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

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

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

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

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

6.7 Управление конфигурациями, прослеживаемостью, изменениями, защита информации

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

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

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

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

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

6.7.2 СИПЛ поддерживает полный набор активов в жизненном цикле разработки ПСС (см. литеру «V» на рисунках 1, 2), включая все взаимосвязи и прослеживаемость между активами на различных этапах, таких как формирование требований, проектирование, реализация, верификация и валидация. Помимо обычной прослеживаемости между активами проблема прослеживаемости также относится к отношениям сопоставления между каталогом характеристик и точками изменений во всех размеченных наборах совместно используемых активов. Эта проблема решается с помощью конфигуратора продуктовой линейки (см. 8.7) и процесса управления прослеживаемостью (см. 8.9).

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

Для проработки вопроса прослеживаемости в СИПЛ следует использовать инструментарии, позволяющие:

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

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

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

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

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

СИПЛ должна содержать инструментарии для обеспечения контроля доступа к активам и использовать действенные меры защиты соответствующей информации. Меры защиты информации предназначены для обеспечения конфиденциальности, целостности и доступности защищаемой информации, предотвращения утечки защищаемой информации, несанкционированных и непреднамеренных воздействий на защищаемую информацию. Определение мер по защите информации осуществляют по ГОСТ Р ИСО/МЭК 27001, ГОСТ Р ИСО/МЭК 27002, ГОСТ Р 51583, ГОСТ Р 56939, ГОСТ Р 58412, ГОСТ Р 59329 — ГОСТ Р 59357, ГОСТ Р МЭК 61508-7, [10] - [14] с необходимым учетом специфики и реализуемой стадии жизненного цикла продуктовой линейки и самих продуктов.

6.8 Системный анализ и управление рисками

Системный анализ и управление рисками в рамках СИПЛ осуществляют с использованием количественных показателей, моделей и методов с необходимым учетом специфики системы и требований по ГОСТ Р ИСО/МЭК 15026, ГОСТ Р ИСО/МЭК 15026-4, ГОСТ Р ИСО/МЭК 16085, ГОСТ Р ИСО/МЭК 27005, ГОСТ Р 51901.1, ГОСТ Р 58771, ГОСТ Р 59989 — ГОСТ Р 59994, ГОСТ Р МЭК 61069-2 — ГОСТ Р МЭК 61069-8, ГОСТ Р МЭК 61508-5, ГОСТ Р МЭК 61508-7, ГОСТ Р МЭК 62508.

7 Технологический уровень

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

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

Примечание — В разделе 8 СИПЛ намеренно оставлены открытыми при описании «черных ящиков», чтобы поставщики готовых к коммерческому использованию инструментариев и технологий имели гибкость в выборе собственных вариантов реализации.

7.2 Язык характеристик

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

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

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

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

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

    дальнейшего подвыбора;
  - <a id="p100348"></a>скалярный  выбор:  значение   должно   быть  выбрано  из  диапазона
    значений, например выбор целочисленного значения от 1 до 10;
- <a id="p100349"></a>язык ограничений характеристик в каталоге характеристик для выражения

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

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

    больше единицы, может иметь вид (NumberOfDoors > 1);
  - <a id="p100351"></a>логика   реляционного   программирования   (т.е.   N-арные   булевы

        выражения, состоящие  из  типизированных  переменных  и операторов,
        таких  как   AND,  OR,  NOT,  Greater-than,  Equal-to,  Less-than);
        например,     ограничение     характеристики     в    виде    ((NOT
        AdaptiveCruiseControl)    OR    (Brakes   ==   Electronic))   может
        использоваться для  выражения  того,  что  опционная характеристика
        AdaptiveCruiseControl не выбрана  (NOT)  (адаптивный круиз-контроль
        позволяет   автомобилю  замедляться  и  ускоряться  для  сохранения
        безопасного  расстояния  до  автомобиля впереди)  или  что  выбрана
        характеристика    Brakes  -  Electronic   (электронное   торможение
        позволяет  программному  обеспечению  инициировать  торможение  для

    замедления автомобиля);
  - <a id="p100352"></a>графические отношения в визуальном языке  характеристик;  например,

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

    другой, но не оба);
-   <a id="p100353"></a>язык  формирования  экземпляров  данных  для  представления  выбора

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

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

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

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

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

    проанализировать выбранные из спецификации характеристики и вызвать
    способ со значениями параметров;
  - <a id="p100361"></a>преобразование    содержимого    размеченного    набора   совместно
    используемых  активов  из одной формы в другую в месте расположения
    точки изменений;
- <a id="p100362"></a>иерархическая   структура   декомпозиции   для  создания  одной   или

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

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

обычного текста.

7.3 Каталог характеристик

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

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

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

7.4 Портфель спецификаций характеристик

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

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

7.5 Размеченные наборы совместно используемых активов

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

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

7.6 Экземпляры активов продуктов

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

7.7 Конфигуратор продуктовой линейки

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

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

7.8 Среда разработки для продуктовой линейки

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

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

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

8 Уровень процессов технического управления в организации

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

В разделе 8 приведено описание ресурсов, ролей и процессов, управляющих СИПЛ на уровне процессов технического управления в организации по ГОСТ Р ИСО/МЭК 12207, ГОСТ Р 57193.

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

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

Каждую операцию описывают в контексте следующих атрибутов:

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

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

8.2 Связь с группой процессов технического управления

В рамках СИПЛ могут быть реализованы процессы, связанные:

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

Примечание — Дополнительно см. раздел 9 и [15] - [17].

8.3 Разработка каталога характеристик

8.3.1 Общее

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

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

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

8.3.2 Исходные данные

Исходными данными являются:

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

8.3.3 Задачи

8.3.3.1 Разработка и анализ декомпозиции общего каталога характеристик

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

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

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

8.3.3.2 Разработка и проверка характеристик в модели

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

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

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

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

8.3.3.3 Разработка и анализ ограничений характеристик в модели

Цель этой задачи — выявить любые зависимости и взаимосвязи между различными характеристиками семейства продуктов. Например, эти ограничения могут быть выявлены и выведены из требований с помощью утверждений типа: «Если характеристика X или Y включена, то использование характеристики Z невозможно». Эта задача также включает в себя сбор описательных комментариев, специфичных для конкретной предметной области или приложения, которые объясняют правильность применяемых ограничений.

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

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

8.3.4 Инструментарии

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

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

8.4 Разработка портфеля спецификаций характеристик

8.4.1 Общее

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

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

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

8.4.2 Исходные данные

Исходными данными являются:

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

8.4.3 Задачи

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

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

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

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

8.4.3.2 Проверка выбранных в спецификации характеристик опций

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

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

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

8.4.4 Инструментарии

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

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

8.5 Разработка размеченных наборов совместно используемых активов

8.5.1 Общее

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

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

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

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

8.5.2 Исходные данные

Исходными данными являются:

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

8.5.3 Задачи

8.5.3.1 Разработка размеченного набора совместно используемых активов

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

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

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

8.5.3.2 Вставка точек изменений в размеченные наборы совместно используемых активов

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

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

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

8.5.3.3 Тестирование точек изменений

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

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

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

8.5.4 Инструментарии

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

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

8.6 Автоматизированная конфигурация экземпляров активов продукта

8.6.1 Общее

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

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

8.6.2 Исходные данные

Исходными данными являются:

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

8.6.3 Задача — настроить размеченные наборы совместно используемых активов

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

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

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

8.6.4 Инструментарии

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

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

8.7 Верификация, валидация и выпуск продукции

8.7.1 Общее

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

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

Основными результатами являются:

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

8.7.2 Исходные данные

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

8.7.3 Задачи

8.7.3.1 Верификация и валидация продукта линейки

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

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

8.7.3.2 Упаковка и выпуск связанного продукта

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

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

8.7.3.3 Выявление дефектов и предоставление информации о них

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

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

8.7.4 Инструментарии

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

8.8 Управление конфигурацией

8.8.1 Общее

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

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

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

Стратегия управления для СИПЛ, ориентированной на требуемые характеристики, сосредоточена на общих наборах совместно используемых активов, а не на экземплярах активов продукта. Модификация и расширение созданных экземпляров активов продукта и возможное объединение этих изменений обратно в размеченные наборы совместно используемых активов не отражаются в качестве практических действий. Однако если это необходимо для реализации бизнес-процессов, такие действия должны выполняться в соответствии с практикой разработки приложений (см. [15] - [17]).

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

8.8.2 Исходные данные

Исходными данными являются:

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

8.8.3 Задачи

8.8.3.1 Создание временного базового варианта

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

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

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

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

8.8.3.2 Использование временного базового варианта

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

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

8.8.4 Инструментарии

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

8.9 Управление прослеживаемостью

8.9.1 Общее

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

Ожидаемые результаты:

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

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

8.9.2 Исходные данные

Исходными данными являются:

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

8.9.3 Задачи

8.9.3.1 Вставка ссылок прослеживания

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

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

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

8.9.3.2 Проверка экземпляров активов продукта на корректность связей прослеживания

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

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

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

8.9.4 Инструментарии

Набор инструментариев для этих задач не ограничивается настоящим стандартом.

8.10 Управление изменениями

8.10.1 Общее

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

Основными результатами являются:

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

8.10.2 Исходные данные

Исходными данными являются:

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

8.10.3 Задачи

8.10.3.1 Подача запроса на изменение

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

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

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

8.10.3.2 Вынесение решения по запросу на изменение

Цель этой задачи — присвоить начальное состояние запросу на изменение, например «отклонен», «принят» или «отложен до ... (условие)».

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

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

8.10.3.3 Прослеживание выполнения запроса на изменение

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

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

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

8.10.4 Инструментарии

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

9 Процессы жизненного цикла продуктовой линейки

В общем случае продуктовая линейка является системой, включающей в себя ПСС, в ее жизненном цикле могут быть использованы следующие процессы (см. ГОСТ Р 57193):

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

Решение задач в жизненном цикле продуктовой линейки осуществляют с использованием требований ГОСТ Р ИСО/МЭК 15026, ГОСТ Р ИСО/МЭК 15026-4, ГОСТ Р ИСО/МЭК 16085, ГОСТ Р ИСО/МЭК 27002, ГОСТ Р 51901.1, ГОСТ Р 58771, ГОСТ Р 59329 — ГОСТ Р 59357, ГОСТ Р 59989 — ГОСТ Р 59994, ГОСТ Р МЭК 61069-2 — ГОСТ Р МЭК 61069-8, ГОСТ Р МЭК 61508-5, ГОСТ Р МЭК 61508-7, ГОСТ Р МЭК 62508 (см. также [15] - [17]), с необходимым учетом специфики.

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

[1]	Федеральный закон от 21 июля 1997 г. № 116-ФЗ «О промышленной безопасности опасных производственных объектов»
[2]	Федеральный закон от 21 июля 1997 г. № 117-ФЗ «О безопасности гидротехнических сооружений»
[3]	Федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации»
[4]	Федеральный закон от 9 февраля 2007 г. № 16-ФЗ «О транспортной безопасности»
[5]	Федеральный закон от 22 июля 2008 г. № 123-ФЗ «Технический регламент о требованиях пожарной безопасности»
[6]	Федеральный закон от 30 декабря 2009 г. № 384-ФЗ «Технический регламент о безопасности зданий и сооружений»
[7]	Федеральный закон от 28 декабря 2010 г. № 390-ФЗ «О безопасности»
[8]	Федеральный закон от 21 июля 2011 г. № 256-ФЗ «О безопасности объектов топливно-энергетического комплекса»
[9]	Федеральный закон от 26 июля 2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»
[10]	Специальные требования и рекомендации по технической защите конфиденциальной информации (СТР-К) (утверждены приказом Председателя Гостехкомиссии России от 30 августа 2002 г. № 282)
[11]	Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах (утверждены приказом ФСТЭК России от 11 февраля 2013 г. № 17)
[12]	Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных (утверждены приказом ФСТЭК России от 18 февраля 2013 г. № 21)
[13]	Требования к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды (утверждены приказом ФСТЭК России от 14 марта 2014 г. № 31)
[14]	Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации (утверждены приказом ФСТЭК России от 25 декабря 2017 г. № 239)
[15]	ISO/IEC 26550:2015	Системная и программная инженерия. Типовая модель для разработки и управления продуктовой линейкой (Software and systems engineering — Reference model for product line engineering and management)
[16]	ISO/IEC 26556:2018	Информационные технологии. Системная и программная инженерия. Методы и инструментарии организационного управления продуктовой линейкой (Information technology — Software and systems engineering — Tools and methods for product line organizational management)
[17]	ISO/IEC 26562:2019	Системная и программная инженерия. Методы и инструментарии для управления переходом на новую продуктовую линейку (Software and systems engineering — Methods and tools for product line transition management)

УДК 006.34:004.056:004.056.5:004.056.53:006.354	ОКС 35.080
Ключевые слова: модель, продуктовая линейка, риск, системная инженерия, программные средства и системы

---