Finalidade
  • A finalidade desta atividade é determinar se o CR (Controle de Mudanças) deve ser aceito ou sinalizado como rejeitado. No caso de CRs aceitos, esta atividade avalia a prioridade, o esforço, o planejamento e outros aspectos para determinar se a alteração está no escopo da liberação atual.
Função:  Gerenciador de Controle de Mudanças  
Freqüência:  Uma vez que um item de configuração tenha uma baseline e tenha entrado no sistema de gerenciamento de configuração, todos os pedidos de mudanças feitos para ele deverão passar pelo processo oficial de gerenciamento de controle de mudanças. 
Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   

Detalhes de Workflow:   

Planejar Reunião de Revisão do CCB Para o início da página

O CCB (Conselho de Controle de Mudanças (ou Configuração)) é o conselho que supervisiona o processo de alteração que consiste em representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. Em um projeto de pequeno porte, uma única pessoa, como o coordenador de projeto ou arquiteto de software, pode desempenhar essa função. No Rational Unified Process, isso é mostrado pela função de Gerenciador do Controle de Mudanças.

A função desta reunião é revisar os Controles de Mudanças Enviados. Uma revisão inicial do conteúdo do CR é feita na reunião para determinar se o pedido é válido. Se for, será decidido se a mudança está dentro ou fora do escopo das liberações atuais, de acordo com prioridade, planejamento, recursos, nível de esforço, risco, gravidade e outros critérios relevantes definidos pelo grupo. Geralmente, essa reunião ocorre uma vez por semana. Se o volume de CR aumentar significativamente ou quando o ciclo da liberação estiver perto de terminar, essa reunião poderá ocorrer diariamente. Os membros que normalmente participam da Reunião de Revisão do CCB são o Gerenciador de Teste, o Gerenciador de Desenvolvimento e um membro do Departamento de Marketing. É possível que participantes adicionais sejam requisitados pelos membros, caso os julguem "necessários".

Recuperar Controles de Mudanças para Revisão Para o início da página

O Formulário de Controle de Mudanças é um artefato formalmente enviado que é utilizado para controlar todos os pedidos (incluindo novos recursos, pedidos de melhoria, defeitos, alteração de requisitos, etc.) junto com as informações de status relacionadas durante todo o ciclo de vida do projeto. Todo o histórico de mudanças será mantido com o CR, o que inclui todas as mudanças de estado, datas e motivos da mudança. Essas informações ficam disponíveis para revisões repetidas e para fechamento final. Um exemplo de Formulário de Controle de Mudanças é fornecido em Artefato: Controles de Mudanças.

Revisar Controles de Mudanças Enviados Para o início da página

A função desta atividade é revisar os Controles de Mudanças Enviados. Este estado é o resultado de 1) envio de um novo CR, 2) atualização de um CR existente ou 3) consideração de um CR Adiado para um novo ciclo da liberação. A CR é colocada na fila de Revisão do CCB. Não ocorre atribuição de propriedade como resultado desta ação.

Uma revisão inicial do conteúdo do CR é feita na Reunião de Revisão do CCB para determinar se o pedido é válido. Se for, será decidido se a mudança está dentro ou fora do escopo das liberações atuais, de acordo com prioridade, planejamento, recursos, nível de esforço, risco, gravidade e outros critérios relevantes definidos pelo grupo.

Se o CR for considerado válido, mas "fora do escopo" para a(s) liberação(ões) atual(is), ele será colocado no estado Adiado e será suspenso e reconsiderado para liberações futuras. Uma liberação de destino pode ser designada para indicar o período em que o CR poderá ser Enviado e entrar novamente na fila de Revisão do CCB.

Se um CR for considerado duplicata de outro CR que já tenha sido enviado, ele deverá ser designado ao Administrador da Revisão do CCB ou ao membro de equipe responsável por resolver essa questão. Quando o CR for colocado no estado Duplicado, o número do CR duplicado será registrado (na guia Attachments do ClearQuest). O solicitante deve, primeiramente, consultar o banco de dados de CRs e verificar se há CRs duplicados. Dessa forma, não será necessário seguir diversos passos do processo de revisão, o que economiza tempo. Os solicitantes de CRs duplicados devem ser incluídos na lista de notificação do CR original para obter notificações futuras sobre a resolução.

Às vezes, um CR é considerado inválido na Reunião de Revisão do CCB ou pelo membro da equipe responsável, ou o solicitante deve fornecer informações adicionais. Se já tiver sido designado (Aberto), o CR será removido da fila de resolução e será revisado novamente. Uma autoridade designada do CCB fica responsável pela confirmação. Não é exigida nenhuma ação do solicitante, a menos que haja necessidade e, nesse caso, o estado do CR será alterado para Informações Adicionais. A CR será revisada novamente na Reunião de Revisão do CCB, levando em consideração quaisquer novas informações. Se o CR for confirmado como inválido, ele será Fechado pelo CCB e o solicitante será notificado.

Quando um CR for considerado como "no escopo" para a liberação atual, ele será designado a um estado Aberto e ficará aguardando resolução. Ela foi incluída na fila de resolução antes de um marco-alvo. Ele é definido como estando na "fila de designação". Os membros da reunião são os únicos que têm autorização para abrir um CR que esteja na fila de resolução. Se for localizado um CR de prioridade dois ou superior, ele deverá ser imediatamente observado pelo Gerenciador de QE ou de Projeto. Nesse momento, eles podem optar por convocar uma Reunião de Revisão do CCB de emergência ou apenas abrir o CR imediatamente na fila de resolução.

Um CR Aberto passa a ser responsabilidade do Coordenador de Projeto que deverá Designar Trabalho com base no tipo de CR e atualizar o planejamento, se apropriado.

Os estados típicos pelos quais um Controle de Mudanças pode passar são mostrados em Conceitos: Gerenciamento do Controle de Mudanças)



Rational Unified Process   2003.06.15