Главная » UML » Технологический процесс управления конфигурацией и изменениями

0

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

Цель

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

Проектная команда должна отслеживать развитие продукта, собирать запросы на внесение изменений (change request — CR) и управлять этими запросами (при этом не важно, откуда поступают запросы) с дальнейшим последовательным внесением изменений в набор артефактов.

 

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

Куб ССМ

Управление конфигурацией и изменениями (configuration and change management — ССМ) включает три независимые функции. Проиллюстрировать это можно с помощь так называемого "куба ССМ" (рис. 13.1).

•   Грань управления состоянием и измерениями относится к управляющей структуре проекта.

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

-       состояния, прогресса, общих тенденций и качества продукта;

-       расходов;

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

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

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

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

Рис. 13.2. Структура продукта и рабочие среды

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

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

 

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

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

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

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

Управление запросами на внесение изменений

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

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

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

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

Управление состоянием и измерениями

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

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

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

м   Общий прогресс проекта относительно изменений

•       Число изменений, сделанных в различных состояниях

•       "Возраст" запросов на внесение изменений — как долго они находятся в опреде
ленном состоянии

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

•       По серьезности и приоритету

•       По затронутым уровням или подсистемам

•       По командам разработчиков

•       По основным причинам

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

Исполнители и артефакты

Как все сказанное выше описывается в Rational Unified Process через исполнителей, артефакты, виды деятельности и технологические процессы? Рассмотрим рис. 13.5, на котором представлены исполнители и артефакты технологического процесса управления конфигурацией и изменениями. Итак, рассмотрим основные исполнители данного технологического процесса.

184              Часть П. Технологические процессы

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

•       Управляющий контролем над изменениями. Наблюдает за процессом контроля над
изменениями. Эту роль обычно исполняет орган контроля над изменениями
(Change Control Board— CCB), который должен состоять из представителей
всех заинтересованных сторон, включая заказчиков, разработчиков и пользова
телей. В небольшом проекте эту роль может играть одно лицо, например руко
водитель проекта или архитектор программного обеспечения.  Управляющий
контролем над изменениями
также отвечает за определение процесса управление
запросами на внесение изменений,
который должен быть задокументирован в плане
управления конфигурацией.

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

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

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

•       Любой исполнитель, который может предлагать запрос на внесение изменений.

•       Архитектор,   воздействующий  на  структуру  продукта  через  реализационное
представление.

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

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

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

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

•    Запросы на внесение изменений

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

 

развития запроса изменяется его состояние; кроме того, к нем)’ добавляется предыстория (в частности, решения группы ССВ).

Рассматриваемый процесс также включает следующие артефакты.

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

•       Метрики и  отчеты о состоянии,  извлекаемые  из  среды  поддержки данного
технологического процесса и позднее включаемые в отчеты оценки состояния.

Технологический процесс

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

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

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

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

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

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

Изменение и предоставление конфигурационных объектов

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

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

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

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

 

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

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

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

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

Управление запросами на внесение изменений

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

Инструментальная поддержка

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

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

•       ClearCase помогает при управлении конфигурацией.

•       ClearQuest облегчает управление запросами на внесение изменений и управле
ние состоянием и измерениями.

Кроме того, для этих средств Rational Unified Process предлагает инструментальные наставники.

 

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

Унифицированное управление изменениями (Unified Change Management — UCM) -это подход корпорации Rational Software к управлению разработкой программной системы (от определения требований до финального выпуска). UCM охватывает весь цикл разработки, определяет, как управлять изменениями требований, моделей проектирования, документации, компонентов, контрольных задач и исходного кода.

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

Резюме

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

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

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

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

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

 

По теме:

  • Комментарии