Задача: Реализация процесса управления изменениями
В этой задаче приведены инструкции по организации процесса управления изменениями.
Дисциплины: Управление конфигурацией и изменениями
Назначение

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

Взаимосвязи
Шаги
Организуйте процесс управления изменениями
Цель:  Процедуры управления изменениями позволяют оценивать и реализовывать изменения по единым принципам.  
Шаги
Памятки по инструментам
Дополнительная информация: Концепция: Управление запросами изменений 

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

Примеры задач по управлению запросами изменений Начало страницы

Концепции: Управление запросами изменений Взаимодействие между лицом, подавшим запрос изменения, комитетом CCB, ответственным специалистом и испытателем.

Заполнить форму Запрос изменения Начало страницы

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

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

Примеры состояний запросов изменений и переходы между состояниями Начало страницы

Концепции: Управление запросами изменений Процесс работы с новым запросом изменения. Возможные типы состояния включают: подан, отложен, открыт, отклонен, выполняется, реализован, проверен.

Проанализировать запрос изменения Начало страницы

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

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

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

Оценить стоимость запроса изменения Начало страницы

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

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

Реализовать запрос изменения Начало страницы

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

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

Внести запись в хронологию изменений Начало страницы

После обновления программного обеспечения необходимо сделать запись обо всех изменениях.

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

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

Хронология изменений

Версия Исполнитель Дата Изменение Причина

1.1 Брюс Богтроттер 01.05.98 Диапазон тестирования Причина #232

1.2 Мария Муссолини 02.06.98 Требования Причина #454

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

Комитет CCB проводит регулярные и, при необходимости, незапланированные встречи.

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

Выбрать участников Начало страницы

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

  • Пользователи
  • Разработчики
  • Группа тестирования
  • Группа управления проектом

Назначить руководителя CCB Начало страницы

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

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

Организовать встречи для оценки запросов изменений Начало страницы

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

Создать протоколы уведомления о проверках изменений
Цель Цель ведения протоколов уведомления о проверках изменений - сообщение соответствующим специалистам о получении очередных запросов изменений.
Выберите специалистов, которые будут проверять различные рабочие продукты.  
Памятки по инструментам:  Работа с уведомлениями об изменениях и проверках с помощью Rational ClearQuest

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

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

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

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

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

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

Более подробная информация по этой теме приведена в разделе Концепция: Управление запросами изменений.


 

Дополнительные сведения