<Nome do Projeto>

Plano de Gerenciamento de Configuração

 

Versão <1.0>

 

 

[Observação: O template a seguir é fornecido para uso com o Rational Unified Process (RUP).  O texto em azul exibido entre colchetes e em itálico (style=InfoBlue) foi incluído para orientar o autor e deve ser excluído antes da publicação do documento. Qualquer parágrafo inserido após esse estilo será definido automaticamente como normal (estilo=BodyText).]


Histórico da Revisão

Data

Versão

Descrição

Autor

<dd/mmm/aa>

<x.x>

<detalhes>

<nome>

 

 

 

 

 

 

 

 

 

 

 

 

 


Índice Analítico

1. Introdução         

1.1 Finalidade     

1.2 Escopo     

1.3 Definições, Acrônimos e Abreviações     

1.4 Referências     

1.5 Visão Geral     

2. Gerenciamento de Configuração de Software

2.1 Organização, Responsabilidades e Interfaces     

2.2 Ferramentas, Ambiente e Infra-estrutura     

3. O Programa de Gerenciamento de Configuração         

3.1 Identificação da Configuração     

3.1.1 Métodos de Identificação           

3.1.2 Baselines do Projeto           

3.2 Controle de Configuração e Mudança     

3.2.1 Processamento e Aprovação de Solicitações de Mudança           

3.2.2 Comitê de Controle de Mudança (CCB)           

3.3 Estimativa do Status de Configuração     

3.3.1 Processo de Armazenamento de Mídia e Liberação do Projeto           

3.3.2 Relatórios e Auditorias           

4. Marcos

5. Treinamento e Recursos     

6. Controle de Software de Subcontratados e Fornecedores


Plano de Gerenciamento de Configuração

1.                  Introdução

[A introdução do Plano de Gerenciamento de Configuração  oferece uma visão geral de todo o documento. Ela inclui a finalidade, o escopo, as definições, os acrônimos, as abreviações, as referências e uma visão geral deste Plano de Gerenciamento de Configuração.]

1.1               Finalidade

[Especifique a finalidade deste Plano de Gerenciamento de Configuração.]

1.2               Escopo

[Uma breve descrição do escopo deste Plano de Gerenciamento de Configuração; o modelo ao qual ele está associado e tudo o que é afetado ou influenciado por este documento.]

1.3               Definições, Acrônimos e Abreviações

[Esta subseção apresenta as definições de todos os termos, acrônimos e abreviações necessários para a correta interpretação do Plano de Gerenciamento de Configuração.  Essas informações podem ser fornecidas mediante referência ao Glossário do projeto.]

1.4               Referências

[Esta subseção apresenta uma lista completa de todos os documentos mencionados no Plano de Gerenciamento de Configuração. Identifique os documentos por título, número de relatório (se aplicável), data e organização responsável pela publicação. Especifique as fontes a partir das quais as referências podem ser obtidas. Essas informações podem ser fornecidas por um anexo ou outro documento.]

1.5               Visão Geral

[Esta subseção descreve o conteúdo restante do Plano de Gerenciamento de Configuração e explica como o documento está organizado.]

2.                  Gerenciamento de Configuração de Software

2.1               Organização, Responsabilidades e Interfaces

[Descreva quem será o responsável pela execução das diversas atividades de Gerenciamento de Configuração (CM) descritas na Disciplina Processo de CM.]

2.2               Ferramentas, Ambiente e Infra-estrutura

[Descreva o ambiente de computação e as ferramentas de software a serem utilizadas para desempenhar as funções de CM em todo o ciclo de vida do projeto ou produto.

Descreva as ferramentas e os procedimentos necessários utilizados para o controle de versão dos itens de configuração gerados no ciclo de vida do projeto ou produto.

As questões envolvidas na configuração do ambiente de CM incluem:

·         tamanho previsto dos dados do produto

·         distribuição da equipe do produto

·         localização física dos servidores e clientes]

3.                  O Programa de Gerenciamento de Configuração

3.1               Identificação da Configuração

3.1.1          Métodos de Identificação

[Descreva como os artefatos do projeto ou produto devem ser nomeados, marcados e numerados. O esquema de identificação deve abranger o hardware, o software do sistema, os produtos de terceiros (COTS) e todos os artefatos de desenvolvimento de aplicativos listados na estrutura de diretórios do produto; por exemplo, planos, modelos, componentes, software de teste, resultados e dados, executáveis e assim por diante.]

3.1.2          Baselines do Projeto

[As baselines funcionam como um padrão oficial no qual os trabalhos subseqüentes são baseados. Somente mudanças autorizadas podem ser efetuadas nas baselines.

Descreva em que pontos do ciclo de vida do projeto ou produto as baselines devem ser estabelecidas. As baselines mais comuns devem ser definidas ao final de cada uma das fases de Iniciação, Elaboração, Construção e Transição. Elas também podem ser geradas no final de iterações ocorridas dentro das várias fases ou com freqüência ainda maior.

Descreva quem autoriza uma baseline e o que ela contém.]

3.2               Controle de Configuração e Mudança

3.2.1          Processamento e Aprovação de Solicitações de Mudança

[Descreva o processo pelo qual os problemas e as mudanças são submetidos, revisados e dispostos.]

3.2.2          Comitê de Controle de Mudança (CCB)

[Descreva a participação e os procedimentos para processar solicitações e aprovações de mudança a serem seguidos pelo CCB.]

3.3               Estimativa do Status de Configuração

3.3.1          Processo de Armazenamento de Mídia e Liberação do Projeto

[Descreva as políticas de retenção e os planos de backup, erros irreversíveis e recuperação. Descreva também como a mídia deve ser mantida - on-line, off-line, tipo de mídia e formato.

O processo de liberação deve descrever o conteúdo do release, a quem ele se destina e se há quaisquer problemas conhecidos e instruções de instalação.]

3.3.2          Relatórios e Auditorias

[Descreva o conteúdo, o formato e a finalidade dos relatórios e auditorias de configuração solicitados.

Os relatórios são usados para avaliar a "qualidade do produto" em qualquer fase do ciclo de vida do projeto ou produto. Os relatórios sobre defeitos com base em solicitações de mudança podem fornecer alguns indicadores de qualidade proveitosos e, dessa forma, alertar a administração e os desenvolvedores para determinadas áreas prioritárias do desenvolvimento. Geralmente os defeitos são classificados por prioridade (alta, média e baixa) e podem ser reportados com base nos seguintes aspectos:

·         Vencimento (Relatórios Baseados em Períodos): Há quanto tempo defeitos de diversos tipos estão pendentes? Qual é o "tempo de retardo" de quando são encontrados defeitos no ciclo de vida em comparação com o tempo necessário para corrigi-los?

·         Distribuição (Relatórios Baseados em Contagens): Existem quantos defeitos nas diversas categorias por proprietário, prioridade ou estado de correção?

·         Tendência (Relatórios Relacionados a Períodos e Contagens): Qual é o número acumulado de defeitos encontrados e corrigidos no decorrer do tempo? Qual é a classificação dos defeitos detectados e corrigidos? Qual é a "lacuna de qualidade" em termos de defeitos pendentes versus defeitos corrigidos? Qual é a média de tempo de correção de um defeito?]

4.                  Marcos

[Identifique os marcos internos e de cliente relacionados ao esforço de CM do projeto ou produto. Esta seção deve incluir detalhes sobre quando o Plano CM deve ser atualizado.]

5.                  Treinamento e Recursos

[Descreva as ferramentas de software, o pessoal e o treinamento necessários para implementar as atividades de CM especificadas.]

6.                  Controle de Software de Subcontratados e Fornecedores

[Descreva de que forma o software desenvolvido fora do ambiente do projeto será incorporado.]