Конфигурационное управление (Software Configuration Management).

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

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

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

При электронном проектировании средствами систем CAE/CAD/CAM должны использоваться и электронные средства управления конфигурацией, отвечающие, в частности, требованиям стандарта ИСО 10303-203.

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

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

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

Эта технология предполагает выполнение следующих операций (по ИСО 10007):

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

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

· учет статуса конфигурации;

· проверку (аудит) конфигурации.

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

В некоторых PDM были предусмотрены следующие статусы для версий документов: рабочий – версия c таким статусом находится в работе, ее можно модифицировать; принятый – именно версия с этим статусом является основой для взаимодействия частей проекта, она служит для обмена данными между объектами, ее модификации осуществляются через рабочий статус; архивный – статус, присваиваемый предыдущим сохраняемым версиям; порождаемый – статус зарезервирован для вновь создаваемых объектов, например при синтезе проектных решений. Разработчик сам изменяет статус объектов.

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

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

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

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

Концепция изделия (КИ, Product Concept – PC): понятие, описывающее класс подобных изделий, которые предприятие предлагает заказчикам. КИ – идея изделия, отвечающая заданному набору технических требований (Specification), требованиям заказчиков («Облик изделия» или «Лицо изделия»). С точки зрения заказчика концепция изделия представляет обозначение формализованного набора требований (Specification), отражающих потребности заказчика. С точки зрения производителя концепция изделия – это обозначение семейства модификаций изделия, поставляемых на рынок.

В стандарте ИСО 10303, спецификации SPS и модели NPDM понятию объект управления конфигурацией (Объект конфигурации (ОК) – Configuration Item – CI) соответствует любое техническое или программное средство (или их комбинация), выполняющее конечную функцию (или некоторую функцию конечного изделия), выделенное для целей управления конфигурацией и обладающее определенным набором свойств (характеристик). Один объект конфигурации может входить в другой и, в свою очередь, включать в себя другие объекты конфигурации. Конфигурация в целом и составляющие ее ОК могут быть соответствующим образом документированы и утверждены. ОК обычно обозначают уникальным буквенно-цифровым идентификатором (кодом), который используется также в качестве неизменяемой части для серийных номеров и уникальной идентификации отдельных компонентов (блоков) этого ОК.

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

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

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

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

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

· формализацию требований;

· структурирование требований;

· проверку требований на выполнимость и непротиворечивость;

· управление изменениями в требованиях.

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что же такое SCM? Наиболее простое и в то же время достаточно полное определение того, что такое конфигурационное управление, содержится в документации к PVCS.

“Конфигурационное управление, - считает фирма Intersolv (разработчик PVCS), - это организация изменений и управления изменением компонентов в процессе разработки программного обеспечения”.

Это некоторая сквозная деятельность (активность, “вспомогательный процесс” в терминологии стандарта ISO 12207-1), выполняемая в течение всего производственного процесса. Определение не учитывает конфигурационного управления на этапе поддержки информационной системы, но оно вполне достаточно для выявления характерных черт SCM.

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

Проблема автоматизации конфигурационного управления

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

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

Стандарт IEEE Std-828 и заменивший его IEEE Std-1042;

Стандарт ANSI, основанный на IEEE Std-828.

Стандарт ISO 12207, основанный на IEEE Std-828.

На основании упомянутых (или иных - например, корпоративных) стандартов для каждого проекта разрабатываются документы, содержащие в себе методику конфигурационного управления. Эти стандарты и методики учитывают сложный характер современной групповой разработки программных проектов. В SCMP (SoftWare Configuration Management Plan) детально расписываются все действия, обязанности и ответственность участников проекта по отношению к SCM.

Действующие в России стандарты (19-я и 34-я серии ГОСТов) не содержат предписаний, касающихся конфигурационного управления, хотя советская программная инженерия выработала оригинальные подходы - достаточно упомянуть сборочное программирование, представляющее собой систему как проектирования, так и конфигурационного управления. В отсутствие национальных стандартов должны применяться стандарты международные, в частности, по отношению к конфигурационному управлению документом прямого действия является ISO 12207-2.

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

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

Это разделение процесса разработки на “действия” (терминология ISO 12207-1), соответствующее этапам жизненного цикла, дополняется распределением задач по отдельным исполнителям и группам. Разнообразие действий, задач и исполнителей образует среду современной организации разработки.

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

Ниже мы будем рассматривать почти исключительно PVCS. Средства PVCS очень широко распространены и фактически стали стандартом в области конфигурационного управления. Мне даже приходилось слышать, как SourceSafe (средство версионного хранения фирмы Microsoft) называли PVCS’ом.

ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПО И КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ

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

Куда вносятся изменения?

Кто вносит изменения?

Какова процедура внесения изменений?

Как процедура внесения изменений связана с объектом изменения, этапом разработки, лицом, вносящим изменения?

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

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

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

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

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

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

Сопровождение (на этом этапе изменения как таковые не вносятся [внесение изменений здесь можно рассматривать как кратковременный откат к предшествующим этапам], основной рассматриваемый объект - выпускаемые версии).

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

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

Изменения. На каждом этапе жизненного цикла могут возникать запросы на изменения. Обычно считается, что эти запросы не формализуются в отношении тех объектов, которые массово изменяются на этом этапе (за одним исключением, которое будет описано в разделе “Метрики и управление проектом”). Так, изменения в исходном коде на этапе кодирования будут вноситься непосредственно. Если же на этапе кодирования возникнет запрос на изменение в дизайне, то этот запрос оформляется принятой процедурой регистрации и прохождения изменения.

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

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

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

Георгий Серяков

(Окончание следует)

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

"The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits."

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

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

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

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

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

• Все артефакты, создаваемые при разработке продукта, имеют свой уникальный идентификатор в системе, позволяя тем самым идентифицировать конфигурационные элементы.
• Этапы разработки программного продукта неразрывно связаны с версиями продукта, к которым привязываются все артефакты: пожелания, требования, тестовая и пользовательская документация, тесты, файлы и т.д.
• , управление требованиями, тестовой и пользовательской документацией позволяют создавать весь необходимый набор артефактов для заданной версии продукта, то есть определять конфигурацию для заданного baseline.
• Автоматическое создание связей между пожеланиями, задачами, требованиями, тестовой и пользовательской документацией, позволяет организовать согласованную конфигурацию программного продукта и выполнять аудит с целью выявления рассогласований. DEVPROM автоматически отслеживает неактуальные связи и предлагает выполнить согласование (приведение в соответствие) артефактов между собой.
• Все изменения в системе протоколируются, что позволяет контролировать любые изменения в конфигурации, выполненные участниками проекта.
• Формирование заметок к релизу (release notes) для определенной версии продукта, включающих в себя список реализованных доработок и исправленных ошибок.

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

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

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

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

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

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

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

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

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

Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия 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, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.

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

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

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

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

08.08.2013 Никита Налютин

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

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

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

При объединении объектов конфигурации образуется их конфигурация - любая структурированная совокупность объектов разработки программной системы, представленных в виде CI, или совокупность процессов и технологических цепочек проекта по разработке программной системы, описания которых также могут быть представлены в виде CI. Процесс управления конфигурациями в различных отраслях регламентируется международными и национальными стандартами: ГОСТ Р 51904, DO-178, AS9100, AS9006, ISO10007, ISO/IEC TR 15846, ISO/IEC 15408, IEEE 1042 и пр. При разработке высококритичных систем применение процесса управления конфигурациями строго обязательно - цена исправления дефектов в таких системах может быть очень высока.

Стандарт ГОСТ Р 51904 был принят Госстандартом России в 2002 году и регламентирует требования к разработке и документированию встроенных систем. В нем процесс управления конфигурациями отнесен к группе интегральных процессов, необходимых для обеспечения качества выполнения процессов разработки и их выходных данных. Интегральные процессы выполняются одновременно с процессами разработки и обеспечивают непрерывную поддержку разработки. Основные цели процесса управления конфигурациями согласно ГОСТ 51904 состоят в том, чтобы обеспечить:

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

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

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

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

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

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

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

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

По своей сути ГОСТ Р 51904, область применения которого - любые встроенные системы, базируется на международном стандарте DO-178, используемом при разработке авиационных систем. Системы, разработанные в соответствии с этим стандартом, могут быть сертифицированы согласно требованиям летной годности.

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

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

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

Существуют также стандарты AS 9100/AS9006, специально адаптирующие требования системы менеджмента качества ISO к авиационной отрасли.

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

Никита Налютин ([email protected]) - менеджер по обеспечению качества, компания Experian (Москва).