Atividade:
| ||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Depois que a baseline de um item de configuração é criada e ele é inserido no sistema de gerenciamento de configuração, todas as solicitações de mudanças no item devem passar pelo processo oficial de gerenciamento de solicitação de mudança. | |
| Papel: Gerente de Controle de Mudança | |
| Mentores de Ferramentas: | |
| Mais Informações:
|
|
| Detalhamentos do Fluxo de Trabalho: |
O Comitê de Controle de Mudança (ou Configuração) (CCB) é o comitê que supervisiona o processo de mudança. Ele é formado por representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. Em um projeto de pequeno porte, uma única pessoa (por exemplo, o gerente de projeto ou arquiteto de software) pode desempenhar esse papel. No Rational Unified Process (RUP), isso é mostrado pelo papel Gerente de Controle de Mudança.
A função desta reunião é rever as Solicitações de Mudança Enviadas. Uma revisão inicial do conteúdo da CR é feita na reunião para determinar se a solicitação é válida. Se for, será decidido se a mudança está dentro ou fora do escopo dos releases atuais, de acordo com prioridade, programação, 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 do release 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 Gerente de Teste, o Gerente de Desenvolvimento e um membro do Departamento de Marketing. A presença de outros participantes poderá ser requisitada se os membros a considerarem necessária.
O Formulário de Solicitação de Mudança é um artefato enviado formalmente que é usado para rastrear todas as solicitações (incluindo novos recursos, solicitações de melhoria, defeitos, mudança 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 a Solicitação de Mudança, 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 Solicitação de Mudança é fornecido em Artefato: Solicitações de Mudança.
A função desta atividade é rever as Solicitações de Mudança Enviadas. Este estado é o resultado de 1) um novo envio de CR, 2) atualização de uma CR existente ou 3) consideração de uma CR Adiada para um novo ciclo do release. 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 da CR é feita na Reunião de Revisão do CCB para determinar se a solicitação é válida. Se for, será decidido se a mudança está dentro ou fora do escopo dos releases atuais, de acordo com prioridade, programação, recursos, nível de esforço, risco, gravidade e outros critérios relevantes definidos pelo grupo.
Se a CR for considerada válida, mas "fora do escopo" dos releases atuais, ela será colocada no estado Adiado e será executada e reconsiderada para releases futuros. Um release-alvo pode ser atribuído para indicar o período em que a CR poderá ser Enviada e entrar novamente na fila de Revisão do CCB.
Se uma CR for considerada duplicata de outra CR que já tenha sido enviada, ela deverá ser atribuída ao Administrador da Revisão do CCB ou ao membro de equipe responsável por resolver essa questão. Quando a CR é colocada no estado Duplicada, o número da CR duplicada é registrado (na guia Attachments do ClearQuest). O solicitante deve, primeiramente, consultar o banco de dados de CRs e verificar se há solicitações duplicadas. Dessa forma, não será necessário seguir diversos passos do processo de revisão, o que economiza tempo. O solicitante das CRs duplicadas deve ser incluído na lista de notificação da CR original para obter notificações futuras sobre a resolução.
Às vezes, uma CR é considerada inválida na Reunião de Revisão do CCB ou pelo membro da equipe responsável, ou o solicitante deve fornecer mais informações. Se já houver alguma atribuição (Aberta), a CR será removida da fila de resolução e revisada 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. Nesse caso, o estado da CR passará para o estado Mais Informações. A CR será revisada novamente na Reunião de Revisão do CCB, levando em consideração quaisquer novas informações. Se a CR for confirmada como inválida, ela será Fechada pelo CCB e o solicitante será notificado.
Quando uma CR é considerada como "dentro do escopo" do release atual, ela é atribuída ao estado Aberta e fica aguardando uma resolução. Ela foi incluída na fila de resolução antes de um marco-alvo. Ela fica na "fila de atribuições". Os membros da reunião são os únicos que têm autorização para abrir uma CR que esteja na fila de resolução. Se for encontrada uma CR de prioridade dois ou superior, ela deverá ser imediatamente observada pelo Gerente 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 a CR imediatamente na fila de resolução.
Uma CR Aberta passa a ser responsabilidade do Gerente de Projeto, que deverá atribuir tarefas de acordo com o tipo de CR e, em seguida, atualizar a programação, se necessário.
Os estados comuns pelos quais uma Solicitação de Mudança pode passar estão especificados em Conceitos: Gerenciamento de Solicitações de Mudança)
|
Rational Unified Process
|
