Artefato:  Solicitação de Mudança

Solicitação de Mudança	As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs). As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.
Papel:	Gerente de Controle de Mudança é responsável pelas Solicitações de Mudanças.
Mais informações:	Conceitos: Gerenciamento de Solicitações de Mudança Detalhamento do Fluxo de Trabalho: Gerenciar Solicitações de Mudança
Finalidade Breve Resumo Ocorrência Responsabilidade Adaptação

Entrada para Atividades: Identificar Solicitações dos Principais Envolvidos Gerenciar Dependências Revisar Requisitos Definir Detalhes do Teste Programar e Atribuir Trabalho Combinar Missão Identificar Motivadores de Teste Corrigir um Defeito Determinar Resultados do Teste Verificar Mudanças no Build Revisar Solicitação de Mudança Confirmar Duplicar ou Recusar CR Avaliar e Defender Qualidade Avaliar e Aprimorar Esforço de Teste Atualizar Solicitação de Mudança

Saída de Atividades: Implementar Teste Implementar Conjunto de Testes Analisar Falha de Teste Iniciar Caso de Desenvolvimento Avaliar Iteração Resolver Exceções e Problemas Gerenciar Teste de Aceitação Gerenciar Teste Beta Obter Confirmação de Testabilidade Design de Banco de Dados Revisar a Arquitetura Revisar o Design Definir Abordagem do Teste Definir Configurações do Ambiente de Teste Identificar Mecanismos de Testabilidade Definir Elementos de Testabilidade Enviar Solicitação de Mudança Verificar Instalação e Configuração das Ferramentas Determinar Resultados do Teste Verificar Mudanças no Build Revisar Solicitação de Mudança Confirmar Duplicar ou Recusar CR Avaliar e Defender Qualidade Avaliar e Aprimorar Esforço de Teste Atualizar Solicitação de Mudança

Finalidade

A necessidade de mudança parece ser inerente aos sistemas de software existentes e em desenvolvimento. O Gerente de Controle de Mudança é responsável pela definição dos procedimentos de Gerenciamento de Solicitações de Mudança e pela manutenção de CRs, garantindo que as mudanças em um sistema sejam efetuadas de maneira controlada, para que seu efeito no sistema possa ser previsto. As CRs podem ser usadas para documentar e controlar todos os tipos de solicitações de mudanças no sistema, inclusive defeitos e solicitações de melhoria.

As solicitações de melhoria são usadas pelo Analista de Sistemas para determinar futuros recursos a serem incluídos no produto. Serão usadas como base durante a coleta de Solicitações dos Principais Envolvidos para que se possa Compreender as Necessidades dos Investidores.

Um defeito é uma anomalia ou falha em um produto de trabalho liberado. Alguns exemplos são omissões e imperfeições localizadas durante as fases iniciais do ciclo de vida e sintomas (falhas) de erros contidos em softwares maduros o suficiente para teste e operação. Os defeitos também podem incluir desvios das expectativas ou qualquer questão que precise ser controlada e resolvida.

A finalidade de um defeito é comunicar os detalhes da questão, permitindo a ação corretiva, a solução e o acompanhamento. As seguintes pessoas usam as CRs:

• O Analista de Sistemas usa as CRs identificadas como Solicitações de Melhoria para determinar novos recursos do produto.
• O Gerente de Projetos usa CRs para atribuir trabalho.
• Os Testadores usam CRs para identificar e descrever os defeitos localizados no teste.
• O Implementador usa CRs para analisar o defeito e localizar os erros ou causas das CRs.
• O Designer de Teste usa CRs a fim de planejar o teste para verificar as CRs solucionadas e analisar um conjunto de defeitos para medir a qualidade do software e do processo.

Breve Resumo

Os seguintes atributos são úteis para tomar uma decisão sobre qualquer CR enviada:

Tamanho

• Que volume de trabalho existente precisará ser alterado?
• Que volume de trabalho extra precisará ser adicionado?

Alternativas

• Existe alguma?

Complexidade

• A mudança proposta é fácil de ser efetuada?
• Quais são as possíveis ramificações provenientes dessa mudança?

Gravidade

• Qual é o impacto da não implementação desta solicitação?
  • Há alguma perda de trabalho ou de dados envolvida?
  • Esta é uma solicitação de melhoria?
  • É um problema secundário?

Cronograma

• Quando a mudança é necessária?
• Ela é viável?

Impacto

• Quais as conseqüências de efetuar a mudança?
• Quais as conseqüências de não efetuar a mudança?

Custo

• Qual é a economia proveniente desta mudança?

Relacionamento com Outras Mudanças

• Outras mudanças substituirão ou invalidarão esta ou isso depende de outras mudanças?

Teste

• Há algum requisito especial de teste?

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

1. Identificação

• Projeto:

• Número da Solicitação de Mudança:

• Tipo de Solicitação de Mudança: (Problema ou Melhoria)

• Cargo:

• Data de Envio:

• Originador:

• Prioridade da Solicitação de Mudança:

2. Problema Atual

• Descrição do problema atual:

• Falha Crítica:

• Dano:

• Melhoria:

• Novo Requisito:

• Condições sob as quais o problema foi observado:

• Ambiente Atual: Hardware

• Sistema Operacional

• Compilador

• Origem do problema atual:

• Impacto do problema atual no Custo ou na Economia:

3. Mudança Proposta (Originador)

• Descrição da mudança proposta:

• Custo estimado para implementar a mudança proposta:

4. Mudança Proposta (Equipe de Revisão de Mudanças)

• Ação:

• Aprovada:

• Desaprovada:

• Adiada:

• Descrição da mudança proposta:

• Itens de Configuração Afetados:

• Categoria:

• Correção de Erros:

• Melhoria:

• Novo Recurso:

• Outros:

5. Resolução:

• Custo estimado para implementar a mudança proposta:

• Implementador:

• Tempo real para implementar a mudança:

• Análise:

• Implementação:

• Teste:

• Documentação:

• Número de Linhas de Código Afetadas:

6. Avaliação

• Métodos de Teste:

• Inspeção

• Análise

• Demonstração

• Teste:

• Plataformas de Teste:

• Casos de Teste:

7. Disposição da Equipe de Revisão de Mudanças

• Mudanças Aprovadas e Aceitas:

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.

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

Responsabilidade

Qualquer pessoa da equipe de projeto deve ser capaz de efetuar uma CR. No entanto, a CR precisa ser revisada e aprovada pelo supervisor da pessoa que a efetuou. A arbitragem final sobre uma Solicitação de Mudança é realizada por uma Equipe de Revisão ou um Comitê de Controle de Mudança (CCB).

O Gerente de Controle de Mudança é responsável pela integridade do defeito, garantindo que:

• Sejam exatas todas as informações que identificam e descrevem o defeito e indicam como ele foi descoberto.
• O defeito seja exclusivo ou que não seja outra ocorrência de um defeito já identificado.

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.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process