Gerenciamento de Mudanças e Solicitações (CRs) em Projetos

Solicitação de Mudança (CR)

Um artefato formalmente submetido que é usado para rastrear todas as solicitações dos envolvidos (inclusive novas características, solicitações de melhoria, conserto de 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 para as mudanças. Essas informações ficam disponíveis para revisões repetidas e para fechamento final.

Comitê de Controle de Mudança (CCB)

O comitê que supervisiona o processo de mudanças. Consiste em representantes de todas as partes interessadas, inclusive clientes, desenvolvedores e usuários. Em projetos pequenos, um único membro da equipe, como o gerente de projeto ou o arquiteto de software, pode desempenhar esse papel. No Rational Unified Process, esse papel cabe ao Gerente de Controle de Mudança.

Reunião de Revisão do CCB

A função dessa reunião é revisar as Solicitações de Mudança enviadas. Uma revisão inicial do conteúdo da Solicitação de Mudança é 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 lançamentos 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 Solicitações de Mudança aumentar significativamente ou quando o ciclo do lançamento está perto do fim, a reunião pode ser mais frequente, até mesmo diária. 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.

Formulário de Envio de Solicitação de Mudança

Este formulário é exibido quando uma Solicitação de Mudança é enviada pela primeira vez. Somente os campos necessários deverão ser preenchidos pelo solicitante, como exibido no formulário.

Formulário Combinado de Solicitação de Mudança

Este formulário é exibido durante a revisão de uma Solicitação de Mudança que já foi enviada. Ele contém todos os campos necessários para descrever a Solicitação de Mudança.

Solicitação dos Envolvidos

Este artefato contém qualquer tipo de solicitação dos principais envolvidos (cliente, usuário final, pessoal de marketing, etc.) em relação ao sistema que será desenvolvido. Ele também pode conter referências a qualquer tipo de fonte externa com a qual o sistema deve estar de acordo. Fontes das solicitações: Solicitação de proposta, Declaração da missão, Declaração do problema, Regras do negócio, Leis e regulamentações, etc.

Notificação de Revisão de Mudança

A finalidade dos protocolos para notificação de revisão de mudança é assegurar que os membros apropriados da equipe sejam notificados quando Solicitações de Mudança forem enviadas. Defina quem deverá revisar diversos artefatos.

Fluxo de Trabalho

• Estabelecer políticas para o gerenciamento de configuração do projeto.
• Estabelecer políticas e processos para controlar as mudanças feitas no produto.
• Documentar essas informações no Plano de Gerenciamento de Configuração (incluído no Plano de Desenvolvimento de Software).

Ocorrência

As práticas de Gerenciamento de Mudanças normalmente são institucionalizadas ou estabelecidas no início do ciclo de vida do projeto. Desse modo, as CRs, que integram o processo de mudança, podem surgir a qualquer momento durante o curso do projeto.

Principal Origem dos Defeitos

A principal origem de defeitos consiste nos resultados da execução dos testes — integração, sistema e desempenho. No entanto, os defeitos podem aparecer em qualquer ponto do ciclo de vida de desenvolvimento do software e abrangem a identificação de documentação, casos de teste ou casos de uso ausentes ou incompletos.

Adaptação

Os campos e os dados reais necessários para identificar, descrever e controlar defeitos com precisão são variados e dependem do sistema de controle de mudanças, das diretrizes e dos padrões implementados.

Processo de Solicitação de Mudança

Preencher o Formulário de Solicitação de Mudança

Este é o primeiro passo no processo de solicitação de mudança.

Analisar a Solicitação de Mudança

Depois que uma Solicitação de Mudança é enviada, ela é analisada para garantir que seja realmente válida e possa ser avaliada quanto à validade pela equipe técnica e de gerenciamento apropriada. É necessário revisar as Solicitações de Mudança em diversos níveis da equipe de desenvolvimento. Em geral, o chefe da equipe revisará e aprovará as Solicitações de Mudança enviadas por membros da sua equipe.

Avaliar o Custo da Solicitação de Mudança

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 a Solicitação de Mudança e o impacto correspondente do ponto de vista estratégico, organizacional e técnico. Esse comitê deverá decidir se a Solicitação de Mudança pode ser justificada economicamente.

Aplicar a Solicitação de Mudança

Depois que uma Solicitação de Mudança é aprovada, ela pode ser aplicada 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 implementação das mudanças, a nova versão do software será verificada em uma compilação de teste do produto, incorporada a uma versão de lançamento de todo o software e testada nessa versão.

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 nas solicitações de mudança.

Exemplo: 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

Gerente de Controle de Mudança

• O papel do gerente de controle de mudança supervisiona o processo de controle de mudanças. Normalmente, este papel é desempenhado por um Comitê de Controle de Configuração (ou Mudança) (CCB), formado por representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. Em projetos pequenos, um único membro da equipe, como o gerente de projeto ou o arquiteto de software, pode desempenhar esse papel. Ele também é responsável por definir o Processo de Gerenciamento de Solicitações de Mudança.
• O gerente de controle de mudança deve conhecer os princípios de gerenciamento de configuração. Ele deve ser qualificado para estimar os impactos no custo e no cronograma gerados pelas solicitações de mudança. Ele deve ter boa habilidade de comunicação para negociar mudanças no escopo e determinar como e quem deve lidar com cada solicitação de mudança.
• Deve garantir que sejam exatas todas as informações que identificam e descrevem o defeito e indicam como ele foi descoberto.
• Deve garantir que o defeito seja exclusivo e não seja outra ocorrência de um defeito já identificado.