Задача: Проверка запросов изменений
В этой задаче рассмотрен способ обработки запросов изменений.
Дисциплины: Управление конфигурацией и изменениями
Назначение
  • В результате выполнения этой задачи принимается или отклоняется запрос изменения (CR). Если запрос изменения принят, оценивается приоритет и трудозатраты, а также определяется приблизительное расписание обработки. Кроме того, проверяется принадлежность запроса области действия текущего выпуска.
Взаимосвязи
Шаги
Планирование собрания совета управления изменениями

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

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

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

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

Проверка отправленных запросов изменений

Данная задача посвящена проверке отправленных запросов изменений. Она выполняется в результате 1) отправки нового запроса изменения, 2) обновления существующего запроса изменения или 3) рассмотрения отложенного запроса изменения. Запросы изменений заносятся в очередь проверки советом управления изменениями. Обратите внимание, что это действие не предусматривает назначение ответственного сотрудника.

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

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

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

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

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

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

Типичная последовательность состояний запроса изменения приведена в разделе Управление запросами изменений.



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