Что такое менеджмент конфигурации
Цикл статей по основам Software Configuration Management
Пролог
Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной 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 (читается: «сиэм»).
Схема 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, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.
Итак, каковы задачи управления конфигурацией?
Для начала — достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.
Что такое менеджмент конфигурации
ГОСТ Р ИСО 10007-2007
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
РУКОВОДЯЩИЕ УКАЗАНИЯ ПО УПРАВЛЕНИЮ КОНФИГУРАЦИЕЙ
Organization management.
Guidelines for configuration management
Дата введения 2008-06-01
Сведения о стандарте
1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (ОАО «НИЦ КД») и Техническим комитетом по стандартизации ТК 10 «Перспективные производственные технологии, менеджмент и оценка рисков» на основе собственного аутентичного перевода стандарта, указанного в пункте 4
2 ВНЕСЕН Управлением развития, информационного обеспечения и аккредитации Федерального агентства по техническому регулированию и метрологии
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (подраздел 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении В
Целью настоящего стандарта является улучшение понимания процесса управления конфигурацией.
Конфигурация продукции должна быть документально оформлена, что обеспечивает идентификацию и прослеживаемость статуса выполнения физических и функциональных требований к продукции и доступ к точным данным на всех стадиях жизненного цикла.
Управление конфигурацией зависит от размера организации, а также от характера и сложности продукции.
Управление конфигурацией может использоваться для выполнения требований идентификации и прослеживаемости продукции, указанных в ИСО 9001:2000 «Системы менеджмента качества. Требования».
1 Область применения
Настоящий стандарт является руководством по применению управления конфигурацией. Стандарт предназначен для использования на всех стадиях жизненного цикла продукции от концепции до утилизации.
До описания процессов управления конфигурацией, которые включают в себя планирование управления конфигурацией, идентификацию конфигурации, управление изменениями, учет статуса конфигурации и аудит конфигурации, должны быть распределены ответственность и полномочия.
Стандарт не предназначен для целей сертификации и использования в контрактах.
2 Нормативные ссылки
В настоящем стандарте использована нормативная ссылка на следующий стандарт:
ИСО 9000:2005 Системы менеджмента качества. Основные положения и словарь
3 Термины и определения
В настоящем стандарте применены термины и определения по ИСО 9000, а также следующие термины с соответствующими определениями:
3.1 управление изменениями (change control): Действия по управлению продукцией после формального одобрения данных о конфигурации продукции (см. 3.9).
3.2 разрешение на отклонение (concession): Разрешение на использование или выпуск продукции, которая не соответствует установленным требованиям.
1 Разрешение на отклонение обычно распространяется на поставку продукции с несоответствующими характеристиками и с установленными согласованными ограничениями по времени или количеству данной продукции
[см. определение 3.6.11 ИСО 9000:2005].
2 Разрешение на отклонение не затрагивает базовой конфигурации (см. 3.4) и включает в себя разрешение на производство продукции, не соответствующей установленным требованиям.
3 Некоторые организации используют термины «отказ от требований» или «отклонения» вместо «разрешение на отклонение».
3.3 конфигурация (configuration): Взаимосвязанные функциональные и физические характеристики продукции, установленные в данных о конфигурации продукции (см. 3.9).
3.4 базовая конфигурация (baseline configuration): Утвержденные данные о конфигурации продукции (3.9), в которых установлены взаимосвязанные функциональные и физические характеристики продукции, относящиеся к указанному моменту времени, и используемые в качестве эталона на всех стадиях жизненного цикла продукции.
3.5 элемент конфигурации (configuration item): Объект конфигурации (см. 3.3), выполняющий законченную функцию.
3.6 управление конфигурацией (configuration management): Скоординированные действия, направленные на формирование и контроль конфигурации.
3.7 отчетность о статусе конфигурации (configuration status accounting): Записи и отчеты в установленной форме данных о конфигурации продукции (см. 3.9), о статусе предложенных изменений и состоянии выполнения одобренных изменений.
3.8 ответственный исполнитель (dispositioning authority): Лицо или группа лиц, обладающих необходимыми полномочиями, на которых возложена ответственность о принятии решения о конфигурации (см. 3.3).
1 Ответственных исполнителей также называют «комиссией по управлению конфигурацией».
2 Соответствующие заинтересованные стороны внутри и вне организации должны быть представлены в качестве ответственных исполнителей.
3.9 данные о конфигурации продукции* (product configuration information): Требования к проектированию, производству, верификации, эксплуатации и обслуживанию продукции.
* Данные приводят в документации о конфигурации продукции.
4 Ответственность по управлению конфигурацией
4.1 Ответственность и полномочия
Организация должна идентифицировать и описать ответственность и полномочия, связанные с выполнением и верификацией процесса управления конфигурацией. Необходимо учитывать следующее:
— сложность и характер продукции;
— требования к продукции на различных стадиях жизненного цикла;
— границы между различными видами деятельности, непосредственно включенными в процесс управления конфигурацией;
— другие заинтересованные стороны внутри и вне организации;
— идентификацию ответственных исполнителей по верификации действий по внедрению процесса управления конфигурацией;
— идентификацию ответственных исполнителей.
4.2 Ответственный исполнитель
До одобрения изменений ответственный исполнитель в рамках своих полномочий должен верифицировать следующее:
— необходимость предложенного изменения и приемлемость его последствий;
— выполнение должным образом документирования и классификации изменения;
— достаточность запланированных действий по введению изменения в документы, аппаратные средства и/или программное обеспечение.
5 Процесс управления конфигурацией
5.1 Общие положения
Для увеличения эффективности процесса важно, чтобы действия по управлению конфигурацией были скоординированы.
Процесс управления конфигурацией должен быть ориентирован на требования потребителя к продукции и должен учитывать конкретные условия производства. Процесс управления конфигурацией должен быть детально указан в плане управления конфигурацией. В плане управления конфигурацией следует указывать все процедуры, определенные в проекте, и степень их применения на всех стадиях жизненного цикла продукции.
5.2 Планирование управления конфигурацией
Планирование управления конфигурацией является основой процесса управления конфигурацией. Эффективное планирование позволяет координировать деятельность по управлению конфигурацией в конкретных ситуациях на всех стадиях жизненного цикла продукции. Выходом процесса планирования управления конфигурацией продукции является план управления конфигурацией.
План управления конфигурацией для конкретной продукции должен:
— быть документально оформленным и утвержденным;
— идентифицировать используемые процедуры управления конфигурацией;
— включать в себя ссылки на соответствующие применяемые процессы в организации (при необходимости);
— содержать актуализированное описание ответственности и полномочий ответственных лиц для поддержания в рабочем состоянии процесса управления конфигурацией на всех стадиях жизненного цикла продукции.
План управления конфигурацией может быть отдельным документом или частью другого документа, или состоять из нескольких документов.
В некоторых ситуациях организации необходимо, чтобы поставщик предоставил свой план управления конфигурацией. Организация может сохранять такие планы как отдельные документы или включать их в собственный план управления конфигурацией.
В приложении А представлены примеры структуры и содержания плана управления конфигурацией.
5.3 Идентификация конфигурации
5.3.1 Структура продукции и выбор элементов конфигурации
Выбранные элементы конфигурации и их взаимосвязи должны описывать структуру продукции.
Элементы конфигурации должны быть идентифицированы с использованием установленных критериев. Элементы конфигурации должны быть выбраны таким образом, чтобы функциональными и физическими характеристиками можно было управлять автономно для достижения полного выполнения конечной функции элемента.
При выборе критерия необходимо учитывать:
— установленные законодательные и обязательные требования;
— критичность элементов конфигурации по отношению к риску и безопасности;
— применение новых или модифицированных технологий, проектирования или разработки;
Что такое менеджмент конфигурации
ГОСТ Р ИСО 10007-2019
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
РУКОВОДЯЩИЕ УКАЗАНИЯ ПО МЕНЕДЖМЕНТУ КОНФИГУРАЦИИ
Quality management. Guidelines for configuration management
Дата введения 2020-10-01
Предисловие
1 ПОДГОТОВЛЕН Ассоциацией по сертификации «Русский Регистр» (Ассоциация «Русский Регистр») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 076 «Системы менеджмента»
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
Введение
Целью настоящего стандарта является улучшение общего понимания предмета, продвижение использования менеджмента конфигурации и оказание поддержки организациям, применяющим менеджмент конфигурации для улучшения их показателей деятельности.
Настоящий стандарт содержит ответственности и полномочия перед описанием процесса менеджмента конфигурации, который включает планирование, менеджмент конфигурации, идентификацию конфигурации, управление изменениями, учет статуса конфигурации и аудит конфигурации.
Менеджмент конфигурации подразумевает документальное оформление конфигурации продукции или услуги. Это обеспечивает идентификацию и прослеживаемость, статус выполнения физических и функциональных требований и доступ к точным данным на всех стадиях жизненного цикла.
Внедрение менеджмента конфигурации зависит от размера организации, сложности и характера продукции или услуги, а также отражает потребности на определенных стадиях жизненного цикла.
Менеджмент конфигурации может использоваться для выполнения требований идентификации и прослеживаемости продукции и услуг, указанных в ИСО 9001:2015 (8.5.2).
1 Область применения
Настоящий стандарт является руководством по применению менеджмента конфигурации в рамках организации. Настоящий стандарт применим для поддержания продукции и услуг от концепции до утилизации.
2 Нормативные ссылки
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) идентификацию ответственных исполнителей по верификации действий по внедрению;
f) идентификацию ответственных исполнителей.
4.2 Ответственный исполнитель
До одобрения изменений ответственному исполнителю следует верифицировать следующее:
a) необходимость предложенного изменения и приемлемость его последствий;
b) выполнение должным образом документирования и классификации изменения;
c) достаточность запланированных действий по внедрению изменения в документированную информацию, аппаратные средства и/или программное обеспечение.
5 Процесс менеджмента конфигурации
5.1 Общие положения
Организации следует разработать, внедрить и поддерживать в рабочем состоянии процесс менеджмента конфигурации. Для улучшения эффективности процесса организации следует координировать деятельность по менеджменту конфигурации.
Процесс менеджмента конфигурации следует ориентировать на требования к продукции или услуге (включая требования потребителей или соответствующих заинтересованных сторон), а также на применение законодательных и нормативных требований, учитывая при этом среду выполнения процесса. Процесс менеджмента конфигурации следует детально указать в плане менеджмента конфигурации. В плане следует описать всю документированную информацию в конкретном проекте и степень ее применения на всех стадиях жизненного цикла продукции или услуги.
5.2 Планирование менеджмента конфигурации
Планирование менеджмента конфигурации является основой процесса менеджмента конфигурации. Эффективное планирование позволяет координировать деятельность по менеджменту конфигурации в конкретной среде на всех стадиях жизненного цикла продукции или услуги. Выходом процесса планирования менеджмента конфигурации является план менеджмента конфигурации.
Необходимо, чтобы план менеджмента конфигурации для конкретной продукции или услуги:
a) был документально оформлен и утвержден;
c) идентифицировал используемую документированную информацию по менеджменту конфигурации;
d) включал в себя ссылки на соответствующую документированную информацию организации, при возможности;
e) описывал необходимые ресурсы и все ответственности и полномочия (включая индивидуальную ответственность) для менеджмента конфигурации на всех стадиях жизненного цикла продукции или услуги.
План менеджмента конфигурации может быть отдельным документом или частью другого документа либо состоять из нескольких документов.
В некоторых ситуациях план менеджмента конфигурации предоставляется внешним поставщиком. Организация может сохранять такие планы как отдельные документы или включать их в собственный план управления конфигурацией.
В приложении А приведены пример структуры и содержание плана менеджмента конфигурации.
5.3 Идентификация конфигурации
5.3.1 Структура продукции или услуги и выбор элементов конфигурации
Структуру продукции или услуги следует описывать выбранными элементами конфигурации и их взаимосвязей.
Элементы конфигурации следует идентифицировать с использованием установленных критериев. Элементы конфигурации следует выбирать таким образом, чтобы функциональными и физическими характеристиками можно было управлять автономно для достижения полного выполнения конечной функции элемента.
При выборе критерия следует учитывать:
a) жизненный цикл конфигурации;
b) применение законодательных и нормативных требований;
c) критичность с точки зрения рисков и безопасности;
d) применение новых или модифицированных технологий, проектирования или разработки;
e) взаимосвязи с другими элементами конфигурации;
f) условия приобретения;
g) сопровождение и обслуживание.
Следует выбирать определенное количество элементов конфигурации для обеспечения оптимального управления продукцией или услугой. Выбор элементов конфигурации следует начинать на самых ранних стадиях жизненного цикла продукции или услуги. Элементы конфигурации следует анализировать по мере модернизации продукции или услуги.
5.3.2 Данные о конфигурации
Данные о конфигурации включают в себя как описание, так и эксплуатационные данные. Как правило, данные о конфигурации включают в себя требования, спецификации, проектную документацию, перечень составных частей, модели данных, спецификации на испытания, руководства (по вводу в эксплуатацию, техническому обслуживанию и эксплуатации), а также специальные требования, касающиеся вывода и должны быть уместными и прослеживаемыми. Следует разработать систему уникального наименования и идентификационного номера и обеспечить надлежащее управление как элементами конфигурации, так и связанными с ними данными. При этом следует учитывать существующие в организации системы наименования и нумерации и информацию об управлении изменениями, такую как статус пересмотра.
5.3.3 Базовая конфигурация
Базовую конфигурацию следует устанавливать каждый раз, когда это необходимо в процессе жизненного цикла продукции или услуги при определении рекомендаций к дальнейшей деятельности или при выполнении специальных требований к анализу.
Уровень детализации, с которой продукция или услуга определена в базовой конфигурации, зависит от требуемой степени управления.