Artefato:
|
![]() |
Controle de Mudanças são utilizados para documentar e controlar pedidos de alteração no produto. Isso fornece um registro de decisões e, com um processo de avaliação apropriado, assegura que o impacto de alteração do pedido seja considerado. |
---|---|
Função: | Gerenciador de Controle de Mudanças |
Opcionalidade/Ocorrência: | Obrigatório. Ocorre sempre que necessário. |
Gabaritos e Relatórios: |
|
Exemplos: |
|
Representação em UML: | Não aplicável. |
Informações Adicionais: |
Entrada de Atividades: | Saída das Atividades: |
A necessidade de alteração é inerente no desenvolvimento de um sistema de software por ele desenvolver-se durante sua criação inicial e por ser utilizado e mantido subseqüentemente na operação de rotina em um ambiente ativo. Controle de Mudanças também são conhecidos por vários nomes, como CRs, defeitos, erros, incidentes, pedidos de melhoria. A captura e o gerenciamento apropriados desses pedidos asseguram que as mudanças em um sistema sejam feitas de maneira controlada para que seu efeito no sistema possa ser previsto. Alguns tipos de importação de Controle de Mudanças incluem:
Pedidos de Melhoria são utilizados por vários investidores para solicitar recursos futuros que desejarem incluir no produto. Representam um tipo de Pedido de Investidor que captura e articula uma compreensão das necessidades dos investidores.
Defeitos são relatórios de anomalias ou falhas em um produto de trabalho entregue. Alguns exemplos incluem omissões e imperfeições localizadas durante as fases iniciais do ciclo de vida ou sintomas de erros (falhas) que precisam ser isolados e corrigidos no software. Também é possível que estejam incluídas variações do que se pode esperar razoavelmente do comportamento do software (como problemas de uso).
A finalidade de um defeito é comunicar os detalhes da questão, permitindo a ação corretiva, a solução e o acompanhamento. As pessoas a seguir utilizam os CRs:
Projeto:
Número do Controle de Mudanças:
Tipo de Controle de Mudanças: (Problema ou Melhoria)
Cargo:
Data de Envio:
Originador:
Prioridade do Controle de Mudanças:
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:
Descrição da mudança proposta:
Custo estimado para implementar a mudança proposta:
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:
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:
Métodos de Teste:
Inspeção
Análise
Demonstração
Teste:
Plataformas de Teste:
Casos de Teste:
Mudanças Aprovadas e Aceitas:
Os seguintes atributos são úteis para tomar uma decisão sobre qualquer CR enviada:
Tamanho da alteração
- 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 deste pedido?
- Há alguma perda de trabalho ou de dados envolvida?
- Este é um pedido 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 teste especial que precisará ser conduzido para verificar se a alteração foi bem-sucedida?
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, os CRs, que integram o processo de alteração, 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.
Qualquer pessoa da equipe de projeto deve ser capaz de efetuar um Controle de Mudanças. No entanto, isso precisa ser revisto e aprovado para o trabalho de resolução associado de maneira apropriada para o contexto do projeto de software. Em grandes equipes ou culturas mais formais, a aprovação é feita geralmente pelo supervisor da pessoa que está efetuando o Controle de Mudanças. Em muitos casos, a arbitragem final sobre um Controle de Mudanças é realizada por uma Equipe de Revisão, como um CCB (Conselho de Controle de Mudanças).
A função de Gerenciador de Controle de Mudanças é responsável pela integridade do Controle de Mudanças, assegurando que:
Enquanto a função de Gerenciador de Controle de Mudanças é geralmente responsável pelo gerenciamento desses pedidos, no caso de Pedidos de Melhoria, o Gerenciador de Controle de Mudanças colabora normalmente com as funções de Analista de Sistemas e de Arquiteto para avaliar a alteração.
Os campos e os dados reais necessários para identificar, descrever e controlar defeitos com precisão são variados e dependem da implementação dos padrões, das diretrizes e do sistema de controle de mudanças.
Geralmente é mais eficiente armazenar controles de mudanças em um banco de dados ou em um sistema de gerenciamento de controle de mudanças para que os controles de mudanças possam ser gerenciados com maior facilidade (por exemplo, classificando por prioridade, controlando a designação e o status de conclusão, etc.). Em um projeto pequeno, uma planilha pode ser suficiente.
Em um projeto pequeno, é possível gerenciar os defeitos como uma lista simples (por exemplo, utilizando a planilha de sua preferência) com uma coluna separada para cada atributo que precisar ser controlado para o controle de mudanças. Esse gerenciamento é possível apenas em sistemas de pequeno porte - quando o número de pessoas envolvidas e a quantidade de defeitos forem maiores, será necessário utilizar um sistema de controle de defeitos mais flexível.
Rational Unified Process
|