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

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

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

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

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

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

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

После подачи запроса изменения специалисты из технических и руководящих групп анализируют его на предмет обоснованности. Запросы изменений необходимо рассматривать на нескольких уровнях группы разработки. Руководитель группы часто проверяет и утверждает запросы изменений, поданные участниками его группы. Однако если специфика изменения выходит за рамки деятельности группы разработки, оно передается для проведения проверки следующего уровня. Если изменение затрагивает несколько групп разработки, оно рассматривается комитетом контроля за изменениями. В 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 проводит регулярные и, при необходимости, внеплановые встречи, чтобы во время обрабатывать запросы изменений. Группа разработки обращается в комитет для разрешения спорных моментов, которые могут отрицательно сказаться на ходе проекта.

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

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

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

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

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

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

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