Projeto <nome do projeto>

<sigla ou nome do projeto>

Plano de Gerência da Configuração

 Projeto <nome do projeto>

1. Introdução
[O Plano de Gerência da Configuração estabelece e mantem a integridade dos artefatos do
projeto <nome do projeto>, permitindo o acompanhamento destes itens durante todo o ciclo de
vida do projeto, preservando o histórico de evolução do sistema e auxiliando a gerenciar as
mudanças e o estado dos itens de configuração e rastrear modificações nos itens de configuração
ao longo do tempo.]

1.1. Propósito
[Este documento descreve a organização, nomenclatura e regras para o versionamento de
artefatos do projeto <nome do projeto>.]

1.2. Escopo
[Este documento descreve a infra-estrutura utilizada durante o desenvolvimento do projeto
<nome do projeto>.]

1.3. Convenções, Termos e Abreviações

[Este tópico explica o conceito de alguns termos importantes que são mencionados no
decorrer deste documento. Estes termos são descritos na tabela a seguir, e são
apresentados por ordem alfabética.]

Termo/Abreviatura Descrição
<nome/sigla> <descrição>

1.4. Referências (opcional)

[Aqui são referenciados todos os documentos mencionados neste plano. Esses documentos
devem ser identificados por um título, número de edição, data e editora da publicação.]
 Projeto <nome do projeto>

2. Política de Configuração

2.1. Identificação de Itens de Configuração

[Aqui são descritos todos os itens sujeitos à gerência de configuração.
Os itens de configuração podem estar em dois níveis de controle diferentes, ou seja,
versionados ou em baseline. Um item de configuração pode ser entendido como sendo um
artefato do projeto que será passível de gerência de configuração. Dizer que um item está
versionado significa que um sistema de controle de versões foi adotado para controlar
todas as alterações realizadas sob um determinado item, onde a cada alteração uma nova
versão é criada, ou para obter um controle de concorrência, uma vez que dois ou mais
integrantes da equipe podem estar modificando um mesmo item ao mesmo tempo. Em um
determinado momento, este item pode fazer parte de uma baseline, que é um
agrupamento de vários itens versionados representando uma configuração específica do
sistema. Uma baseline pode ser gerada ao final de cada etapa do ciclo de vida
(planejamento, análise de requisitos, etc) e/ou a cada release. Para fazer parte de uma
baseline, cada item deve ser formalmente revisado e aprovado e qualquer modificação
neste item deve passar por um controle formal automatizado através de uma ferramenta de
controle de modificações. A modificação deve ser solicitada, e então o Comitê de Gerência
de Configuração (CCC) – Gerente de Projeto, Gerente de Configuração, etc - poderá julgar
a relevância de tal modificação, aprovando ou rejeitando o pedido.

Identificação
<Nome do item>

[O Anexo A no final deste documento traz uma lista com os possíveis itens de
configuração.]
 Projeto <nome do projeto>

2.1.1. Nomenclatura para Itens de Configuração

[Aqui é definido como os itens de configuração serão identificados através da
padronização para os nomes de cada item.
Sugere-se o padrão <projeto>-<tipo-artefato>-<categoria>-<número>-<nome>,
onde <tipo-artefato> é a sigla do artefato correspondente ao item de configuração.
O Anexo A apresenta as siglas para cada item de configuração.
Exemplo: SIGAEDU-CDU-INFRA-003-Manter Matrícula.

2.2. Definição e Identificação de Baselines (Releases)

[Deve ser definido em que momento uma baseline será estabelecida. Essa informação
deve estar especificada no Plano de Projeto. Geralmente baselines são estabelecidas ao
final da iteração de uma fase do ciclo de vida do projeto. Para identificar baselines, sugere-
se o padrão:
<projeto>-<nome>-<versão>
Exemplo: SIGAEDU_RegistroAcademico_2.1.1.]

2.2.1. Versionamento de Baselines

[As baselines devem ser versionadas de acordo com o padrão X.Y.Z, onde:
a) X é um valor decimal que corresponde a versão principal;
b) Y é um valor decimal que corresponde a versão de implementação de novas
funcionalidades;
c) Z é um valor decimal que corresponde a consertos de bugs.
Exemplo: Uma determinada baseline está na versão 2.3.6. Caso seja gerado um
pedido de manutenção referente ao conserto de um bug que foi identificado, então
após a correção deste bug uma nova versão será criada, modificando o dígito
referente ao valor de Z, neste caso, 2.3.7. Caso uma nova funcionalidade seja
implementada, será criada uma versão 2.4.0, neste caso modificando o dígito
referente ao valor de Y. Se uma funcionalidade muito significativa for acrescentada
será criada a versão 3.0.0, alterando nesse caso o valor de X (geralmente a versão
principal é modificada para efeitos de marketing).]
 Projeto <nome do projeto>

3. Controle da Configuração

3.1. Procedimentos de Mudança

[Deve ser identificada e descrita a ferramenta de controle de modificações utilizada e como
um pedido de manutenção é criado.
As modificações realizadas em um item de configuração, quando passam a fazer parte de
uma baseline, só podem ser realizadas de acordo com as políticas do sistema de controle
de modificações adotado. Enquanto um item estiver no ambiente de desenvolvimento
como cópia local, as modificações podem ser feitas livremente, porém para efetivar a
modificação (devolver o item ao repositório) deve ser feito um pedido formal ao CCC e será
aprovada mediante verificação, conforme descrito no item 2.1.
Quando um pedido de modificação é aprovado, pode ser criado um ramo (branch)
referente àquela configuração (baseline) que sofrerá modificação. Este ramo pode ser
alterado livremente, porém ao terminar de implementar as modificações necessárias o
Gerente de Projeto será notificado para então verificar e validar tais modificações e então
autoriza os responsáveis pela manutenção a integrar o ramo ao conteúdo da raiz (trunk).
Ramos podem ser criados para desenvolvimento e para correção de bugs sobre uma
versão já entregue ao cliente, ou seja, uma release.
O Anexo B apresenta um diagrama com o fluxo de um pedido de manutenção.]

3.2. Ciclo de Vida das Solicitações de Mudanças

[Devem ser descritos os possíveis estados de um pedido de manutenção.]
Estado Descrição
Sob avaliação O pedido de manutenção foi feito e será avaliado pelo Comitê de Gerência da
Configuração
Novo O pedido de manutenção foi aprovado pelo Comitê de Gerência da Configuração
Atribuído O pedido de manutenção foi atribuído a um desenvolvedor
Resolvido O pedido de manutenção foi implementado
Reaberto O pedido de manutenção não foi corretamente implementado e é reaberto pelo Comitê
de Gerência da Configuração
Fechado O pedido de manutenção é fechado (fim do ciclo de vida do pedido de manutenção)
[O Anexo C apresenta um diagrama de estados do ciclo de vida de um pedido de
 Projeto <nome do projeto>

manutenção.]

4. Relato de Status da Configuração

[Devem ser identificados e definidos os relatórios para gerenciar a configuração.]

Relatório* Descrição
<nome> <descrição>

[*Possíveis relatórios:

–Relatório de Status da Configuração;

–Relatório de Auditoria da Configuração;

–Relatório de Auditoria de Baseline;

–Release Notes (Notas de Liberação).]

 Projeto <nome do projeto>

5. Auditoria da Configuração
[Devem ser definidas as auditorias de configuração que serão realizadas no projeto a fim de
verificar a completude de uma baseline em relação aos requisitos estabelecidos.]

Responsável Objetivo Observações

<nome> <objetivo geral da auditoria> <observações importantes>
 Projeto <nome do projeto>

6. Infra-estrutura
[Deve ser descrita toda a estrutura do ambiente, ou seja, a estrutura hierárquica de diretórios,
hardware e software utilizados e qualquer informação relacionada ao ambiente.]

6.1. Estrutura de Diretórios

Local Descrição Restrições de Acesso

<diretório> <descrição sobre o diretório> <quem possui que tipo de acesso:
leitura(R) e escrita(W)>

6.2. Hardware

Quantidade Recurso Modelo/Configuração

<quantidade> <recurso (impressora, notebook, etc)> <modelo ou configuração do recurso
utilizado>

6.3. Software

Ferramenta Versão Descrição

<nome> <versão> <descrição da ferramenta>
 Projeto <nome do projeto>

Anexo A
Lista de Itens de Configuração

Identificação
Casos de Testes
Código fonte
Documento de Arquitetura
Documento de Avaliação de Testes
Documento de Regras de Negócio
Documento de Especificação de Casos de Uso
Documento de Inspeção/Revisão pela Qualidade
Documento de Requisitos
Documento de Visão
EAP
Glossário
Manuais de Implantação
Manuais de Usuário
Matriz de Responsabilidades
Matrizes de Rastreabilidade
Modelo de Dados
Modelos de Analise e Projeto
Planilha de Gestão de Ações Corretivas
Planilha de Recursos
Plano de Comunicação
Plano de Gerência de Configuração e Ambiente
Plano de Medição
 Projeto <nome do projeto>

Plano de Riscos
Plano de Testes
Plano e Relatório de Implantação
Registro de Métricas
Relatório de Auditória de Baseline
Relatório de Métricas
Termo de Abertura, incluindo Cronograma

Anexo B
Fluxo de um Pedido de Manutenção
Projeto <nome do projeto>
Projeto <nome do projeto>
Projeto <nome do projeto>
 Projeto <nome do projeto>

Anexo C
Ciclo de Vida (estados) de um Pedido de Manutenção
Projeto <nome do projeto>