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

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

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

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

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

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

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

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