Руководство по управлению конфигурацией

Текст ГОСТ Р 59193-2020 Управление конфигурацией. Основные положения

ГОСТ Р 59193-2020

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

УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ

Основные положения

Configuration management. General provisions

ОКС 01.040.01

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

Предисловие

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 482 «Поддержка жизненного цикла экспортируемой продукции военного и продукции двойного назначения»

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

4 ВВЕДЕН ВПЕРВЫЕ

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

Введение

Цель настоящего стандарта — показать связи процедур управления конфигурацией по ГОСТ Р ИСО 10007 с существующими процессами разработки, производства и эксплуатации изделия, а также с процессами управления жизненным циклом (ЖЦ) изделия, описанными в ГОСТ Р 56135.

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

Для решения задач УК сложного изделия выполняют декомпозицию исходного объекта анализа на отдельные управляемые объекты — объекты конфигурации.

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

Для каждого объекта конфигурации разрабатывается комплект документации конфигурации, который после утверждения представляет «утвержденную конфигурацию» данного объекта. Примером комплекта документации конфигурации является, например, полный комплект конструкторской документации по Единой системе конструкторской документации.

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

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

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

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

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

ГОСТ 2.053 Единая система конструкторской документации. Электронная структура изделия. Общие положения

ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.103 Единая система конструкторской документации. Стадии разработки

ГОСТ 2.201 Единая система конструкторской документации. Обозначение изделий и конструкторских документов

ГОСТ 2.503 Единая система конструкторской документации. Правила внесения изменений

ГОСТ 2.603 Единая система конструкторской документации. Внесение изменений в эксплуатационную и ремонтную документацию

ГОСТ 3.1102 Единая система технологической документации. Стадии разработки и виды документов. Общие положения

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

ГОСТ Р 2.601 Единая система конструкторской документации. Эксплуатационные документы

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

ГОСТ Р 54089 Интегрированная логистическая поддержка. Электронное дело изделия. Основные положения и общие требования

ГОСТ Р 56135 Управление жизненным циклом продукции военного назначения. Общие положения

ГОСТ Р 56136 Управление жизненным циклом продукции военного назначения. Термины и определения

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

ГОСТ Р 58301 Управление данными об изделии. Электронный макет изделия. Общие положения

ГОСТ Р 58675 Автоматизированная система управления данными об изделии. Общие требования

ГОСТ Р ИСО 10007-2019 Менеджмент качества. Руководящие указания по менеджменту конфигурации

ГОСТ Р 59194-2020 Управление требованиями. Основные положения

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

3 Термины, определения и сокращения

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

В настоящем стандарте применены термины по ГОСТ Р 56136, а также следующие термины с соответствующими определениями:

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

________________

В контексте данного стандарта термин «объект» используется как синоним термина «объект конфигурации».

Примечание — Валидация, как правило, выполняется при завершении разработки объекта и передаче результатов заказчику (головному разработчику для СЧ).

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

3.1.3 документация (данные) конфигурации: Комплект документов и/или данных, в которых содержится описание конфигурации объекта.

________________

Здесь и далее знаком «*» отмечены термины, для которых в приложении А приведены аналогичные термины и определения из ГОСТ Р ИСО 10007.

3.1.4

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

Примечания

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

2 Число изделий может измеряться в штуках (экземплярах).

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

[ГОСТ 2.101-2016, статья 3.1]

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

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

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

Примечания

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

2 Разные варианты объекта (модификации, исполнения и т.п.) соответствуют разным конфигурациям.

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

Примечания

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

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

3.1.9

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

[ГОСТ Р 59194-2020, статья 3.1.17]

3.1.10

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

[ГОСТ Р 59194-2020, статья 3.1.18]

3.1.11

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

[ГОСТ 2.053-2013, статья 3.1.1]

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

________________

Управление конфигурацией, согласно ГОСТ Р 57193-2016 (пункт 6.3.5), относится к процессам технического управления в ЖЦ системы.

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

3.2 Сокращения

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

АС УДИ

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

ДД

— доказательный документ;

ЖЦ

— жизненный цикл изделия;

КР

— контрольный рубеж;

МОС

— метод оценки соответствия;

ОКнф

— объект конфигурации;

СЧ

— составная часть;

УК

— управление конфигурацией;

ЭМИ

— электронный макет изделия.

4 Основные положения

4.1 Управление конфигурацией является одним из процессов управления ЖЦ изделия в соответствии с ГОСТ Р 56135. УК осуществляют в отношении ОКнф, выделяемых для этих целей на стадиях (этапах) ЖЦ.

4.2 Управление конфигурацией включает следующие процедуры (виды деятельности):

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

— идентификация конфигурации;

— аудит конфигурации;

— управление изменениями конфигурации;

— учет статуса конфигурации.

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

— формализацию состава и структуры ОКнф;

— определение контролируемых характеристик ОКнф;

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

— утверждение документации конфигурации.

4.2.2 Аудит конфигурации — деятельность по формальной проверке конфигурации, включающая:

— аудит документации конфигурации;

— аудит изготовленного экземпляра ОКнф.

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

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

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

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

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

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

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

Примечание — Основные сведения о структуре и содержании плана УК приведены в ГОСТ Р ИСО 10007-2019 (приложение А), который рекомендуется применять с учетом требований настоящего стандарта.

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

4.6 Документация конфигурации в зависимости от вида ОКнф и задач, решаемых на стадии (этапе) ЖЦ, может включать:

— техническое задание, спецификацию требований и другие документы и/или данные с требованиями в соответствии с ГОСТ Р 59194;

— проектные конструкторские документы по ГОСТ 2.102 и/или данные в АС УДИ (в том числе функциональный ЭМИ по ГОСТ Р 58301);

— рабочие конструкторские документы по ГОСТ 2.102 и/или данные в АС УДИ (в том числе конструкторский ЭМИ по ГОСТ Р 58301);

— эксплуатационные документы по ГОСТ 2.601 и/или данные в АС УДИ (в том числе эксплуатационный ЭМИ по ГОСТ Р 58301);

— технологические документы по ГОСТ 3.1102 и/или данные в АС УДИ (в том числе технологический ЭМИ по ГОСТ Р 58301);

— программные документы по ГОСТ 19.101 и/или данные в специализированных информационных системах;

— технические документы (планы, стратегии, программы и т.п.);

— другие виды документов и данных при необходимости.

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

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

________________

Количество и наименования видов утвержденных конфигураций даны для примера в соответствии с [1]*. Применяемые в организации виды и наименования утвержденных конфигураций могут отличаться — см. 4.9.

* См. раздел Библиография. — .

— утвержденная требуемая конфигурация;

— утвержденная проектная конфигурация;

— утвержденная рабочая конфигурация;

— утвержденная производственная конфигурация.

Общие требования к формированию и утверждению конфигурации приведены в разделе 5.

Рисунок 1 — Пример утвержденных конфигураций для разрабатываемого объекта

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

4.8.1 Утвержденная требуемая конфигурация — это комплект утвержденной документации конфигурации, необходимый для достижения соглашения между заказчиком и поставщиком объекта (или между головным разработчиком и разработчиком СЧ изделия). Утвержденная конфигурация включает спецификацию исходных требований к объекту в соответствии с ГОСТ Р 59194.

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

4.8.2 Утвержденная проектная конфигурация — это комплект утвержденной документации конфигурации, содержащий принятые по объекту технические решения и необходимый для установления требований к разработчикам СЧ изделия (в том числе к внутренним подразделениям головного разработчика, разрабатываемым крупные функциональные СЧ). Утвержденная проектная конфигурация включает спецификацию проектных требований к ОКнф и требования к его СЧ в соответствии с ГОСТ Р 59194.

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

Проектную конфигурацию утверждают на этапе разработки эскизного проекта и уточняют на этапе разработки технического проекта.

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

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

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

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

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

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

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

4.10 Аудиты конфигурации каждого вида и аудиты экземпляров выполняют на КР, устанавливаемых в модели ЖЦ изделия по ГОСТ Р 56135. Результаты аудита конфигурации являются одним из критериев для принятия решения о переходе к следующей стадии (этапу) ЖЦ объекта. Общие требования к аудиту конфигурации приведены в разделе 6.

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

Общие требования к управлению изменениями конфигурации приведены в разделе 7.

5 Идентификация конфигурации

5.1 Идентификация конфигурации включает решение следующих задач:

— уникальное обозначение объектов и их конфигураций;

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

— уникальное обозначение документации конфигурации;

— формирование утвержденной конфигурации;

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

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

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

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

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

5.3 Конфигурация специфицированного ОКнф (в том числе финального изделия) включает описание его структуры.

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

Проектная конфигурация включает функциональную структуру изделия.

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

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

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

5.5 Все документы и/или информационные наборы, составляющие документацию конфигурации объекта, должны быть связаны с соответствующим ОКнф или элементами его структуры.

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

5.6 Для каждого ОКнф анализируют проверяемые на КР требования, а также установленные для них МОС и виды ДД в соответствии с ГОСТ Р 59194. ДД и другие документы и данные, необходимые для описания и подтверждения характеристик ОКнф, включают в состав документации конфигурации.

Примечание — Создание документации конфигурации происходит в ходе разработки объекта. В ходе верификации и валидации объекта разрабатывают необходимые ДД.

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

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

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

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

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

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

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

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

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

Примечание — Как правило, принципы идентификации экземпляров финальных изделий устанавливает изготовитель изделия. Для идентификации экземпляров СЧ могут использоваться разные технологии автоматизированной идентификации: использование штриховых кодов, радиочастотной идентификации (RFID-меток) и т.п.

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

6.1 Аудит конфигурации проводят:

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

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

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

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

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

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

6.4.1 Исходными данными для аудита документации конфигурации являются:

— документация конфигурации, на основании которой проведена верификация ОКнф.

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

— ДД, созданные в результате верификации;

— разрешения на отклонение (отступление) от требований;

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

6.4.2 Аудит документации конфигурации включает:

— проверку наличия и правильности размещения в АС УДИ (или другом установленном хранилище) каждого документа или информационного набора в требуемой форме представления;

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

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

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

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

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

6.4.3 После проведения аудита документации формируют утвержденную конфигурацию в соответствии с 5.9.

6.4.4 При внесении изменений в утвержденную конфигурацию проводят аудит всех изменений конфигурации.

6.5 Аудит конфигурации экземпляра проводят в ходе или после изготовления проверяемого объекта. Аудит конфигурации экземпляров сложных технических изделий проводят в процессе их изготовления (сборки) для исключения необходимости последующего демонтажа СЧ для доступа к проверяемым объектам.

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

6.5.2 В ходе аудита экземпляра проверяют:

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

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

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

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

6.5.3 Аудит экземпляра сложного изделия может проводиться постепенно путем проверки экземпляров его основных ОКнф (или наборов ОКнф).

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

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

7 Управление изменениями конфигурации

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

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

7.2 Изменение конфигурации инициируют в отношении утвержденной конфигурации определенного вида (см. 4.8). Изменение утвержденной конфигурации включает:

— изменение версий документов или данных в утвержденной конфигурации;

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

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

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

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

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

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

— выявление экземпляров объекта, требующих доработки.

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

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

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

— проведение комплексного анализа и оценки вариантов изменения, а также выявление необходимости изменения всех подчиненных конфигураций, вариантов изделия, в которых применяется изменяемый объект, и уже изготовленных экземпляров; принятие решения о проведении изменения (как правило, поддерживается документом «предложение об изменении» в соответствии с ГОСТ 2.503 или аналогичным);

— открытие (присвоение изменению обозначения в автоматизированной системе) и классификация изменения;

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

— аудит измененной конфигурации (см. раздел 6);

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

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

К изменениям первого класса относят изменения, влияющие:

— на выполнение требований уполномоченных государственных органов;

— контрактную документацию, утвержденную разработчиком и поставщиком;

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

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

— утвержденные внешние интерфейсы изделия (ОКнф).

К изменениям второго класса относят все изменения, не относящиеся к изменениям первого класса.

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

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

После проведения изменения второго класса имеющиеся ДД по умолчанию распространяются и на новую конфигурацию.

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

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

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

— путем оперативного внесения изменений в утвержденную конфигурацию с оформлением разрешения на отступление (для конструкторской документации оформляется «предварительное извещение об изменении» в соответствии с ГОСТ 2.503);

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

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

8 Учет статуса конфигурации

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

___________________

* Текст документа соответствует оригиналу. — .

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

8.3 Задачами данной деятельности являются:

— анализ полноты информации, связанной с ОКнф;

— контроль статусов документации конфигурации;

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

— анализ и контроль процедур оформления отступлений и отклонений;

— проверка устранения замечаний, установленных на предшествующем КР ЖЦ изделия;

— регистрация результатов аудита конфигурации;

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

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

8.5 Типовыми отчетами являются:

— перечень устраненных замечаний, установленных по результату прохождения предшествующего КР ЖЦ изделия;

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

— перечень утвержденных конфигураций и ОКнф;

— отчеты о количестве и статусе изменений и разрешений на отклонение и отступление;

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

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

Таблица соответствия терминов настоящего стандарта и ГОСТ Р ИСО 10007

Таблица А.1 — Соответствие терминов настоящего стандарта и ГОСТ Р ИСО 10007

Термин из подраздела 3.1 настоящего стандарта

Аналогичный термин из ГОСТ Р ИСО 10007

Определение термина из ГОСТ Р ИСО 10007

3.1.3 документация (данные) конфигурации

3.5 данные о конфигурации (configuration information)

Требования к проектированию, реализации, верификации, эксплуатации и обслуживанию продукции или услуг

3.1.7 конфигурация

3.1 конфигурация (configuration)

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

3.1.8 объект конфигурации

3.3 элемент конфигурации (configuration item)

Объект конфигурации, выполняющий законченную функцию

3.1.13 утвержденная конфигурация

3.2 базовая конфигурация (configuration baseline)

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

Библиография

[1]

EIA-649-B*

Стандарт управления конфигурацией (Configuration management standard. TechAmerica Standard, 2011)

________________

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

УДК 005: 629.7:006.354

ОКС 01.040.01

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

Электронный текст документа

и сверен по:

, 2020

Источник
Содержание

Спрятать

  1. Что такое управление конфигурацией программного обеспечения (SCM)?
  2. Какова цель управления конфигурацией программного обеспечения?
  3. Этапы плана управления конфигурацией программного обеспечения
    1. №1. Идентификация и планирование
    2. № 2. Базовый план и контроль версий
    3. №3. Изменить управление
    4. № 4. Учет состояния конфигурации
    5. № 6. Аудиты и оценки
  4. Кто принимает участие в процессе управления конфигурацией программного обеспечения?
    1. №1. Менеджер конфигурации
    2. # 2. Руководитель проекта
    3. #3. Разработчики программного обеспечения
    4. № 4. Аудитор
  5. Лучшее программное обеспечение и инструменты для управления конфигурацией
    1. №1. Гит
    2. № 2. Докер
    3. №3. Терраформ
    4. № 4. Шеф-повар, Марионетка, Ansible, Соляной стек
  6. Каковы преимущества развертывания инструментов и управления конфигурацией программного обеспечения?
    1. Есть ли что-то негативное в использовании инструмента управления конфигурацией программного обеспечения?
  7. Что такое управление конфигурацией в SDLC?
  8. Какое применение имеет конфигурация CE?
  9. Заключение
  10. Часто задаваемые вопросы об управлении конфигурацией программного обеспечения
  11. Каковы 4 основные функции управления конфигурацией программного обеспечения?
  12. Что такое элементы конфигурации программного обеспечения?
  13. Что такое стратегия управления конфигурацией?
    1. Статьи по теме
    2. Рекомендации

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

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

Какова цель управления конфигурацией программного обеспечения?

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

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

Этапы плана управления конфигурацией программного обеспечения

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

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

№1. Идентификация и планирование

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

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

На этом этапе к конкретным мероприятиям относятся:

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

№ 2. Базовый план и контроль версий

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

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

Этот этап включает в себя следующие мероприятия:

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

№3. Изменить управление

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

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

Эта процедура влечет за собой:

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

№ 4. Учет состояния конфигурации

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

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

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

№ 6. Аудиты и оценки

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

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

Действия этого шага включают:

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

Кто принимает участие в процессе управления конфигурацией программного обеспечения?

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

№1. Менеджер конфигурации

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

# 2. Руководитель проекта

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

#3. Разработчики программного обеспечения

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

№ 4. Аудитор

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

№1. Гит

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

№ 2. Докер

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

№3. Терраформ

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

№ 4. Шеф-повар, Марионетка, Ansible, Соляной стек

Среды автоматизации ИТ включают Ansible, Salt Stack, Chef и Puppet. Эти платформы автоматизируют многие типичные процессы системного администратора. Каждая структура использует набор файлов данных конфигурации, обычно YAML или XML, которые анализируются исполняемым файлом.

Файлы данных конфигурации описывают шаги, которые необходимо предпринять для настройки системы. Затем программа выполняет действия. Язык исполняемого файла зависит от системы: Chef написан на Ruby, а Ansible и Salt Stack — на Python. Этот метод аналогичен запуску специальных сценариев оболочки, но он обеспечивает более структурированный и усовершенствованный опыт работы с экосистемами соответствующих платформ. Эти инструменты обеспечат автоматизацию, необходимую для достижения CI/CD.

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

  1. Тревоги и отчеты: Если есть какие-либо отклонения от согласованного базового уровня, компетентный инструмент SCM отправит предупреждения и отчеты. Эти данные будут передаваться практически в режиме реального времени, что позволит руководству быстро реагировать, если что-то пойдет не так.
  2. Отслеживать изменения: Инструменты SCM автоматически отслеживают изменения в серверах или приложениях, а также разрешают ввод таких данных человеком. Выходные данные сценария мониторинга также можно использовать для аудита изменений.
  3. Сравнение конфигураций: Лучшие инструменты управления конфигурацией программного обеспечения позволят вам обнаружить различия между конфигурациями.
  4. Ошибки: Ошибки и проблемы обнаруживаются быстро, что позволяет инженерам принять меры до того, как проблема усугубится.
  5. Отслеживание запасов: Большинство инструментов SCM будут включать механизм отслеживания аппаратных и программных активов, что избавит от необходимости вести рукописную инвентаризацию.
  6. Управление исправлениями: Инструменты SCM могут помочь вам отслеживать все тонкости, связанные с управлением исправлениями, по мере того, как вы поставляете обновленное программное обеспечение.

Есть ли что-то негативное в использовании инструмента управления конфигурацией программного обеспечения?

Прежде чем внедрять инструмент SCM, обратите внимание на следующие моменты:

  1. Истощение ресурсов: У вас должны быть ресурсы для поддержки процесса от начала до конца.
  2. Ограничения знаний: Все участники должны хорошо разбираться в используемых инструментах управления программным обеспечением.
  3. Недостаток малого и среднего бизнеса: Масштаб того, что требуется для эффективного использования этих инструментов, может быть сложным для небольшой организации.
  4. Аппаратные требования: Для успешной работы процедуры необходимо быстрое и точно настроенное оборудование.

Какова основная цель управления конфигурацией программного обеспечения?

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

Что такое управление конфигурацией в SDLC?

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

Какое применение имеет конфигурация CE?

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

Заключение

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

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

Каковы 4 основные функции управления конфигурацией программного обеспечения?

Выявление, контроль, аудит и учет состояния

Что такое элементы конфигурации программного обеспечения?

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

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

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

Статьи по теме

  • Системы и инструменты управления конфигурацией в 202 году3
  • ОБЗОРЫ ЛУЧШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ УПРАВЛЕНИЯ ЦЕПОЧКАМИ ПОСТАВОК В 202 ГОДУ3
  • Управление цепочками поставок: что такое SCM и почему это важно?
  • Управление стоимостью проекта: как создать план управления стоимостью

Рекомендации

  • Guru99
  • Atlassian
  • Программное обеспечениеТестированиеПомощь
Источник

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

Введение

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

«У нас есть CMDB, конечно, мы занимаемся управлением конфигурацией»

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

Управление конфигурацией — это клей, который объединяет ИТ-услугу и Заказчика.

Управление конфигурацией — Основы

Управление конфигурацией является одной из наиболее важных корпоративных способностей в операционной модели ИТ. Не имеет значения, примеряете вы в ITIL 4, v3 или v2! Важность понимания сервисной топологии коленной кости, связанной с бедренной костью, нельзя недооценивать.

Устремление к услуге

Несмотря на то, что сейчас в облачном/гибком/цифровом мире ИТ очень ориентированы на продукты, ИТ — это все еще услуга, а ИТ-департамент — все еще поставщик услуг.

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

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

Преимущества

К преимуществам единого стандартного процесса управления конфигурациями относятся:

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

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

Поддержка бизнес-процессов

Бизнес-процессы — это часто упускаемый из виду элемент управления конфигурацией. Пренебрежение бизнес-процессами еще больше развивает разделение на “нас и их” между ИТ и бизнесом.

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

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

  • Как узнать, что вы предоставили бизнесу качественные услуги?
  • Соответствует ли ваша ИТ-инфраструктура бизнесу?

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

Подумайте об арбузном SLA! Зеленый снаружи, но красный внутри. Действительно ли заказчик доволен?

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

  • Когда услуга становится достаточно хорошей и откуда вы знаете, что предоставляете то, что нужно бизнесу?
  • Как обосновываются улучшения услуг и может ли быть действительно сотрудничество в подходах между бизнесом и ИТ?
  • Нужен ли подход, основанный на здравом смысле, для достижения организационных целей и задач, и какую роль во всем этом играют стандарты и лучшая практика?

Триггеры изменений

Есть некоторые общие драйверы, которые влияют на изменения в ИТ.

  1. Затраты — соотношение затрат и качества ИТ постоянно подвергается все более пристальному вниманию, особенно в условиях глобальной рецессии, с которой мы столкнемся в 2023 году и далее. За последние 10 лет затраты на ИТ продолжали расти быстрее, чем инвестиции в аппаратное и программное обеспечение, и во многом это связано с переходом в облако, которое перемещает маятник ИТ-расходов от финансовых моделей CapEx к OpEx.
  2. Эффективность — ИТ постоянно нужно идти в ногу с бизнесом и обеспечивать экономию эффективности для него или самих ИТ.
  3. Реакция на значительные события в бизнесе — это может быть крупномасштабный сбой, который оказал финансовое или репутационное воздействие, большой аудит вендора программного обеспечения, который привел к огромному CPO (Compulsory Purchase Order) или, возможно, даже IPO (Initial Public Offering) компании, что привело к тому, что привело к необходимости выглядеть инвестиционно привлекательной для аналитиков рынка.

Важность проектирования

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

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

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

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

Переход от CMDB к CMS

Прежде чем мы поговорим о причинах, давайте рассмотрим, что это такое…

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

CMS — набор инструментов и баз данных (т.е. CMDB), которые используются для управления данными о конфигурации поставщика ИТ-услуг. CMS также включает в себя информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах; и может содержать данные о Сотрудниках, Поставщиках, Местоположениях, Бизнес-единицах, Заказчиках и Пользователях.

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

Другими словами, CMDB — это только база данных, а CMS включает в себя инструменты и базы данных для управления данными. CMS поддерживает одну или несколько CMDB, и CMS используется всеми ИТ-подразделениями.

Концепция CMS основывается на концепции CMDB.

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

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

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

Важность услуг

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

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

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

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

Существует два подхода: сверху вниз и снизу вверх.

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

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

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

CMDB предлагает значительные преимущества.

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

Управление конфигурацией — что дальше?

Ключевые моменты, которые нужно помнить

  • Вы внедряете способность управление конфигурацией, а не просто CMDB.
  • Не просто заполняйте ее, подумайте о том, что вам нужно.
  • Получите базовый уровень. Оценить, кто что, как и почему собирает, затем посмотрите, насколько оно точно.
  • Начните с чего-то одного – горизонтального или вертикального. Это означает, что либо начните с бизнес-услуги и работайте вниз по топологии услуг, либо начните с типа или класса КЕ и найдите ее в своем портфеле услуг. Здесь нет правильного или неправильного маршрута, все зависит от того, как вы подготовлены и что вы можете сделать.
  • Это способность, а значит, люди, процессы и инструменты. Не стоит просто заполнять базу данных (CMDB) всякой всячиной и ожидать, что она сделает это за вас.
  • Сначала создайте управление услугами — свяжите его с управлением изменениями, чтобы КЕ обновлялись по мере прохождения жизненного цикла КЕ. Встраивайте политики в такие места, как управление инцидентами, чтобы при замене КЕ CMS управления конфигурацией обновлялся для отражения новой топологии услуги и состояния КЕ.
  • Не полагайтесь на обнаружение чтобы выяснить, что изменилось! Обнаружение должно помочь в проверке и аудите КЕ.
  • Интегрируйте, интегрируйте и еще раз интегрируйте! Другие способности настолько сильны, насколько сильна CMS, которая их поддерживает. Как мы влияем на оценку изменений? Откуда мы узнаем, что восстанавливать и в каком порядке в случае катастрофы? Как управление событиями соотносит затронутые услуги с нестабильными КЕ? Варианты использования бесконечны.

Готовы?

  • Дважды отмерь, один раз отрежь — одному нашему клиенту потребовалось более 18 месяцев с командой из 8 человек, чтобы спроектировать, построить, запустить и довести до совершенства возможности управления конфигурацией, отвечающие его целям.
  • Итеративный процесс лучше всего. Постепенная выгода лучше, чем отложенное совершенство.
  • Если информация никому не нужна, не отслеживайте ее. Меньше — значит больше!
  • Убедитесь, что у вас есть владелец процесса и команда для его выполнения.
  • Назначьте владельцев для каждого типа конфигурации, которые будут отвечать за поддержание их в актуальном состоянии.

Оригинал статьи можно найти здесь

Источник

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Менеджмент качества

РУКОВОДЯЩИЕ УКАЗАНИЯ ПО МЕНЕДЖМЕНТУ КОНФИГУРАЦИИ

(ISO 10007:2017, ЮТ)

Издание официальное

Москва

Стандартинформ

2019

Предисловие

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

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 076 «Системы менеджмента»

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

4    Настоящий стандарт идентичен международному стандарту ИСО 10007:2017 «Менеджмент качества. Руководящие указания по менеджменту конфигурации» (ISO 10007:2017 «Quality management — Guidelines tor configuration management». IDT).

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

5    ВЗАМЕН ГОСТ Р ИСО 10007-2007

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

© ISO, 2017 — Все права сохраняются ©Стандартинформ, оформление. 2019

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

и

b) определение содержания и форм для отчетов по учету статуса конфигурации А.7 Аудит конфигурации

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

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

b)    используемую документированную информацию по аудиту конфигурации.

c)    ответственности и полномочия соответствующих внутренних и внешних заинтересованных сторон;

d)    определение формы отчетов об аудитах конфигурации

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

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА 1

Обозначение ссылочного международного стандарта

Степень

соответствия

Обозначение и наименование соответствующего национального стандарта

ISO 9000 2015

ЮТ

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

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

— ЮТ — идентичный стандарт

Библиография

(1)    ISO 9001:2015, Quality management systems — Requirements

(2)    ISO 9004, Managing for the sustained success of an organization — A quality management approach

(3)    I SO 10006, Quality management systems — Guidelines for quality management in projects

УДК 362:621.001:658.382.3:006.354    ОКС    3.180

Ключевые слова: конфигурация, элемент конфигурации, менеджмент конфигурации, процесс менеджмента конфигурации, план менеджмента конфигурации

Редактор Я С Зим и лова Технический редактор В Н. Прусакова Корректор И А Королева Компьютерная верстка Л А Круговой

Сдано 8 набор 21.08 2019 Подписано а печать 05 09 2019 Формат бО’вД1/^ Гарнитура Ариап Уел печ л. 1.86 Уч-изд л. 1.70. Тираж 60 экз. За к 653 Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ». 117418 Москва, Нахи?ж>вс*ий пр-т.д 31. к. 2.

www goslinfo ru info@gostmto ru

Содержание

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

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

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

4    Ответственность по менеджменту конфигурации…………………………………….2

4.1    Ответственности и полномочия………………………………………………2

4.2    Ответственный исполнитель………………………………………………..2

5    Процесс менеджмента конфигурации…………………………………………….2

5.1    Общие положения……………………………………………………….2

5.2    Планирование менеджмента конфигурации…………………………………….2

5.3    Идентификация конфигурации………………………………………………3

5.4    Управление изменениями………………………………………………….3

5.5    Учет статуса конфигурации…………………………………………………5

Приложение А (справочное) Структура и содержание плана менеджмента конфигурации………..6

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

Библиография

национальным стандартам…………………………………………8

9

Введение

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

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

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

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

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

Менеджмент конфигурации может использоваться для выполнения требований идентификации и прослеживаемости продукции и услуг, указанных в ИСО 9001:2015 (8.5.2).

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

Менеджмент качества РУКОВОДЯЩИЕ УКАЗАНИЯ ПО МЕНЕДЖМЕНТУ КОНФИГУРАЦИИ

Quality management Guidelines for configuration management

Дата введения — 2020—10—01

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

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

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

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

ISO 9000:2015, Quality management systems — Requirements (Системы менеджмента качества. Основные положения и словарь)

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

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

—    онлайн-платформа ИСО, которая доступна по ссылке https://www.iso.org/obp;

—    электропедия МЭК, которая доступна по ссылке http://www.electropedia.org/.

3.1    конфигурация (configuration): Взаимосвязанные функциональные и физические характеристики продукции или услуги, установленные в данных о конфигурации (3.5).

3.2    базовая конфигурация (configuration baseline): Утвержденные данные о конфигурации (3.5), в которых установлены характеристики продукции или услуги, относящиеся к указанному моменту времени и используемые в качестве эталона для деятельности на всех стадиях жизненного цикла продукции или услуги.

3.3    элемент конфигурации (configuration item): Объект конфигурации (3.1), выполняющий законченную функцию.

3.4    учет статуса конфигурации (configuration status accounting): Записи и отчеты в установленной форме данных о конфигурации (3.5), о статусе предложенных изменений и состоянии внедрения одобренных изменений.

3.5    данные о конфигурации (configuration information): Требования к проектированию, реализации, верификации, эксплуатации и обслуживанию продукции или услуг.

Издание официальное

4    Ответственность по менеджменту конфигурации

4.1    Ответственности и полномочия

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

a)    сложность и характер продукции или услуги;

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

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

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

e)    идентификацию ответственных исполнителей по верификации действий по внедрению;

0 идентификацию ответственных исполнителей.

4.2    Ответственный исполнитель

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

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

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

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

5    Процесс менеджмента конфигурации

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

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

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

5.2    Планирование менеджмента конфигурации

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

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

a)    был документально оформлен и утвержден;

b)    был управляемым;

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

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

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

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

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

В приложение А приведены пример структуры и содержание плана менеджмента конфигурации.

5.3 Идентификация конфигурации

5.3.1    Структура продукции или услуги и выбор элементов конфигурации

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

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

При выборе критерия следует учитывать:

a)    жизненный цикл конфигурации;

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

c)    критичность с точки зрения рисков и безопасности;

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

e)    взаимосвязи с другими элементами конфигурации;

f)    условия приобретения;

д) сопровождение и обслуживание.

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

5.3.2    Данные о конфигурации

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

5.3.3    Базовая конфигурация

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

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

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

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

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

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

a)    описание обоснования и документированную информацию об изменении:

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

c)    оценку последствий изменения;

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

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

Примечание — Некоторые организации используют такие термины, как «отказ» или «отступление», вместо термина «отклонение»

5.4.2    Инициирование, идентификация и документирование необходимости изменений

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

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

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

b)    описание предложенного изменения;

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

d)    заинтересованную сторону, представившую предложение, и дату его подготовки;

e)    обоснование изменения;

О категорию изменения.

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

5.4.3    Оценка изменения

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

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

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

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

d)    потенциальное воздействие неутверждения предлагаемого изменения.

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

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

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

c)    взаимосвязь между элементами конфигурации:

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

e)    инвентаризацию и закупки:

О деятельность, связанную с поставками;

д) требования по обслуживанию потребителей.

5.4.4    Распределение обязанностей за изменения

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

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

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

5.4.5    Внедрение и верификация изменения

Внедрение одобренного изменения, как правило, включает в себя:

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

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

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

5.5 Учет статуса конфигурации

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

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

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

5.5.2    Документированная информация

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

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

b)    конфигурации продукции или услуги (такие как номер частей, статус проекта продукции или конструкции);

c)    статусе выпуска новых данных о конфигурации;

d)    процедуре внесения изменений.

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

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

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

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

c)    обеспечивающей средства аварийного восстановления;

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

e)    допускающей восстановление.

5.5.3    Отчеты

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

Как правило, отчеты включают в себя:

a)    перечень данных о конфигурации, включенных в определенную базовую конфигурацию;

b)    перечень элементов конфигурации и их базовой конфигурации;

c)    подробное описание текущего статуса пересмотра и истории изменений:

d)    статус отчетов об изменениях и разрешениях на отклонение;

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

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

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

Как правило, выделяют два типа аудита конфигурации:

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

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

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

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

Структура и содержание плана менеджмента конфигурации

А.1 Общие положения

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

А.2 Введение

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

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

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

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

d)    описание инструментов менеджмента конфигурации;

e)    соответствующую документированную информацию (например, планы менеджмента конфигурации от поставщиков),

f)    список необходимых документов и их взаимосвязь

А.З Политики

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

a)    политика в отношении практик менеджмента конфигурации и соответствующей деятельности по управлению;

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

c)    квалификация и подготовка;

d)    критерии выбора элементов конфигурации,

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

f)    терминология

А.4 Идентификация конфигурации

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

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

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

c)    метод идентификации статуса пересмотра.

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

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

0 документированную информацию, определяющую процессы выпуска (включая все соответствующие процедуры) для данных о конфигурации

А.5 Управление изменениями

В плане управления конфигурацией следует подробно описывать

a)    отношения ответственных исполнителей (см 4 2) организации с ответственными исполнителями других заинтересованных сторон,

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

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

А.6 Учет статуса конфигурации

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

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

Источник

Время на прочтение
5 мин

Количество просмотров 21K

Пролог

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

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

Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.

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

Итак, поехали.

Что такое CM и зачем он нужен

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

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

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

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

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

В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).

image
Схема 1. Элементы, их версии и срезы-конфигурации.

CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.

Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.

Так в чем же заключается такая ценность CM?

Направления ответственности CM

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

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

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

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

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

Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» — (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.

Итак, каковы задачи управления конфигурацией?

Это:

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

Кому интересно прочитать ещё немного теории и проникнуться терминами и формальными описаниями области ответственности – вам к стандартам CMM/CMMI (см. ссылки в конце), там это рассматривается много и плодотворно. Правда, не всегда понятно и почти всегда – сухо и скучно.

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

Ссылки для расширения кругозора:

  1. en.wikipedia.org/wiki/Software_configuration_management Software Configuration Management на Википедии.
  2. www2.computer.org/portal/web/swebok Software Engineering Book of Knowledge.
  3. www.sei.cmu.edu/cmmi SEI CMMI Website.
  4. www.cmcrossroads.com CM Crossroads the Configuration Management Community.

Продолжение следует.

UPD: по просьбам трудящихся, ссылка на вторую часть: habrahabr.ru/blogs/pm/67839

Источник

Понравилась статья? Поделить с друзьями:
  • Ротокан как полоскать инструкция по применению
  • Добрушская бумажная фабрика руководство
  • Марни кинрис формула ф руководство по флирту для мужчин 2021
  • Взаимодействие руководства с подразделениями в организации
  • Что такое sony playstation 3 руководство