Um procedimento típico para manipular Controles de Mudanças é mostrado no seguinte diagrama de atividades. (Clique em qualquer local no diagrama para obter uma descrição completa do Conceito: Gerenciamento de Controles de Mudanças)

Amostras de Tarefas para Gerenciar CRs 

Preencher o Formulário de Controle de Mudanças

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.) . Ele deve incluir informações de status 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 Produto de Trabalho: Controles de Mudanças.

O diagrama de estados a seguir mostra estados comuns pelos quais um Controle de Mudanças pode passar. (Clique em qualquer local no diagrama para obter uma descrição completa do Conceito: Gerenciamento de Controles de Mudanças)

Amostras de Estados e Transições para um CR

Analisar o Controle de Mudanças

Depois que um Controle de Mudanças é enviado, ele é analisado para garantir que seja realmente válido e possa ser avaliado quanto à validade pela equipe técnica e de gerenciamento apropriada. É necessário revisar os Controles de Mudanças em diversos níveis da equipe de desenvolvimento. Em geral, o chefe da equipe revisará e aprovará os Controle de Mudanças enviados por membros da sua equipe. No entanto, se o escopo de uma mudança ultrapassar as responsabilidades da equipe, ela será escalada para o nível de revisão seguinte. Se o impacto da mudança atingir diversas equipes de desenvolvimento distintas, ela será revisada pelo Conselho de Controle de Mudanças. No Rational Unified Process, a função de Gerenciador de Controle de Mudanças é utilizada para representar a função do CCB (Conselho de Controle de Mudanças).

Ocasionalmente, um problema de funcionamento do sistema relatado pode ser decorrente mais do uso, do que do fato de estar vinculado ao sistema de implementação. Também pode acontecer de o problema já ter sido relatado e estar sendo identificado.

O resultado da etapa de análise é aceitar o Controle de Mudanças ou rejeitá-lo com base no fato de ser inválido, duplicado ou 'fora do escopo', de acordo com a visão ou o mandado do projeto atual.

Avaliar o Custo do Controle de Mudanças

No caso das mudanças válidas, o passo seguinte é avaliar a mudança e estabelecer o seu custo, com base no impacto que possui sobre todo o sistema e na facilidade com que pode ser implementada.

As informações do passo de estabelecimento de custo são fornecidas ao CCB para avaliação. O CCB revisa o Controle de Mudanças e o impacto correspondente do ponto de vista estratégico, organizacional e técnico. Ele deverá decidir se o Controle de Mudanças pode ser justificada economicamente.

Aplicar o Controle de Mudanças

Depois que um Controle de Mudanças é aprovado, ele pode ser aplicado ao software. O software revisado passará por verificações de garantia de qualidade para assegurar que as mudanças tenham sido efetuadas de acordo com as práticas adotadas pelo projeto e não prejudiquem outras partes do software existente.

Após a realização das mudanças, a nova versão do software será verificada em uma construção de teste do produto, incorporada e verificada em uma versão de 'liberação' de todo o software.

Manter o Histórico de Mudanças

À medida que são efetuadas mudanças no software, é importante manter um registro de todas elas.

Uma forma eficaz de manter um histórico de mudanças é estabelecê-lo no início de cada componente de software e nos controles de mudanças.

O exemplo a seguir mostra o tipo de dados de mudança a ser mantido em um cabeçalho de componente:

Histórico de Modificações

Versão Modificador Data Mudança Motivo

1.1 Bruce Bogtrotter 01.05.98 Intervalos de Teste CR#232

1.2 Maria Mussolini 02.06.98 Requisitos CR#454

O CCB se reúne com freqüência e conforme necessário.

As suas tarefas básicas são declarar baselines de produtos, revisar mudanças na baseline, bem como aprovar, rejeitar ou adiar a implementação dessas mudanças.

Selecionar Membros

A finalidade desta etapa é configurar um CCB que consista nas 'pessoas certas', com autoridade real entre seus pares e conhecimento suficiente para evitar propostas de mudanças imprudentes ou dispendiosas. O CCB precisa incluir representantes de todas as organizações ou investidores afetados, como:

• Usuários
• Desenvolvedores
• Grupo de Teste
• Gerenciamento de Projeto

Designar a Comissão do CCB

O presidente do CCB deve fazer parte da empresa de Gerenciamento do Projeto. A comissão deverá ter a capacidade de resolver conflitos na equipe de forma clara e aplicar as decisões da equipe ao projeto.

Sempre que possível, as decisões do CCB deverão ser tomadas por meio de consenso. A dinâmica do grupo reflete a natureza cooperativa do projeto de desenvolvimento. A função do presidente é cultivar essa visão cooperativa e executar ações unilaterais, se necessário.

Marcar uma Reunião para Avaliar Propostas de Mudanças

O CCB deverá se reunir com freqüência e conforme necessário para assegurar que as Propostas de Mudança sejam revisadas e organizadas de forma oportuna. A equipe de desenvolvimento deverá ver esse grupo como uma entidade confiável para a resolução de problemas que poderiam travar o progresso do projeto.

A entrada para essa etapa é a lista de produtos de trabalho a ser desenvolvida durante o andamento do projeto.

Os membros da equipe precisam revisar produtos de trabalho relacionados ao produto para decidir se eles atendem ou não aos padrões de qualidade definidos do projeto, de forma que eles passem para a etapa seguinte de desenvolvimento. Se um produto for reprovado na revisão, ele será submetido a retrabalho, mudança e nova revisão.

Para que uma revisão seja 'eficaz', o produto deverá ser avaliado pelas pessoas certas que compreendem o escopo e o impacto de uma alteração ou melhoria proposta. Além disso, as revisões precisam ser de 'custo efetivo' para que o tempo da equipe dos principais implementadores e integradores não esteja sendo gasto na geração de defeitos de 'baixo impacto'.

Os membros da equipe que precisam estar envolvidos em uma revisão são representantes do lado do produtor, do destinatário e do gerenciamento do 'produto'. O objetivo disso é garantir que todos os investidores com um interesse particular na qualidade do produto possam decidir se ele está pronto para passar para o nível seguinte de desenvolvimento.

No ambiente de equipe, o projeto geral é dividido em atividades. As atividades são alocadas a indivíduos responsáveis para implementação e integração. Por exemplo, todo o sistema é dividido em subsistemas e, depois, em pacotes individuais. Os membros de equipe responsáveis pela implementação de um pacote precisam se certificar de que suas mudanças sejam revisadas pelos seus pares no subsistema e por qualquer outra pessoa em outros subsistemas que possa ser atingida pelas mudanças.

O princípio da notificação de revisão e mudança é a comunicação com os pares, chefes de equipe e receptores das mudanças propostas, e a oportunidade de eles revisarem as propostas e fazerem comentários sobre elas.

É fornecida orientação adicional sobre esse assunto em Conceito: Gerenciamento de Controles de Mudanças.