A identificação de configurações é uma parte essencial do gerenciamento de configurações e é definida pelo IEEE como "um elemento do gerenciamento de configurações que consiste em selecionar os itens de configuração para um sistema e registrar suas características físicas e funcionais na documentação técnica". Em termos de gerenciamento de configuração de software, a identificação da configuração significa ser capaz de localizar e identificar a versão correta de qualquer produto de trabalho de projeto rápida e facilmente. O impacto negativo de um sistema de identificação de configuração ineficaz é avaliado em termos de perda de tempo e qualidade.

As etiquetas identificam versões específicas de produtos de trabalho. O conjunto de produtos de trabalho que constitui uma versão de um subsistema é, coletiva e individualmente, identificável por uma determinada versão e etiqueta. As etiquetas são, portanto, úteis na reutilização ou referência a conjuntos originais de produtos de trabalho com controle de versão.

A seguir, é sugerida uma convenção de identificação de produtos de trabalho em nível produto que pode ser utilizada para identificar caminhos e produtos de trabalho na Estrutura de Diretórios do Produto.

<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<SYSTEM> Identifica o sistema

<A> Significa o acrônimo de três letras (TLA!). Ele é utilizado para os vários tipos de produtos de trabalho utilizados na criação do sistema. Por exemplo,

PLN	Planos de Projeto
REQ	Arquivos de Requisitos
USC	Casos de Uso
MOD	Arquivos de Modelo
SRC	Arquivos de Código Fonte
INT	Interface Públicas
TST	Scripts de Testes e Resultados
DOC	Documentação (Usuário, Notas sobre o Release)
BIN	Executáveis

<SUBSYSTEM> Identifica cada subsistema

<A> Significa o acrônimo de três letras para os vários tipos de produtos de trabalho utilizados na criação do subsistema. De acordo com a tabela acima.

R|A|B	Significa release, alfa ou beta
<X>	Inteiro, significa um release principal (por exemplo, 1)
<Y>	Inteiro (opcional), significa um release secundário
<Z>	Inteiro (opcional), significa uma liberação alternativa (correções, portas etc.)
BL	Significa nível base (um release interno)
#	Inteiro, para releases internos

A seguir são apresentados alguns exemplos:

T2K_R1.0	Release 1 do sistema Thorn 2000
T2K_GUI_R2.0.BL5	Release interno do sistema da GUI destinado à entrega no release 2
T2K_B1.1	Release 1.1 beta do sistema Thorn 2000
T2K_R2.0.BL16	Baseline de sistema interna #16 do Thorn 2000 destinada à criação do release 2
T2K_R1.0.5	Release de manutenção do Thorn 2000

Uma baseline fornece um ponto estável e uma captura instantânea dos produtos de trabalho do projeto. Conceito: Criação de Baseline descreve em que ponto no ciclo de vida do projeto as baselines precisam ser criadas. Este passo fornece orientação adicional sobre a prática.

As baselines identificam conjuntos fixos de controles de versão de diretórios e de arquivos, e são criadas em marcos de projeto específicos. Elas podem ser criadas para um subsistema ou para todo o sistema. As baselines devem ser identificadas de acordo com o esquema descrito na etapa de processo anterior (Definir a Convenção de Identificação de Produtos de Trabalho).

Uma diferença que precisa ser especificada no momento da criação de uma baseline é se você estará criando:

• Uma 'Baseline de Subsistema' com TODAS as versões de arquivos e de diretórios que foram modificadas no subsistema ou subsistemas.

• Uma 'Baseline de Sistema' com uma ÚNICA versão de todos os arquivos e diretórios em todos os subsistemas.

Geralmente, facilitaria o gerenciamento da liberação criar Baselines de Sistema nos marcos de projeto principais e secundários, e Baselines de Subsistema quando necessário ou em uma freqüência maior. Como regra geral, será interessante criar uma baseline se, no máximo, 30% dos elementos de um subsistema tiverem sido alterados.

O propósito dessa etapa é assegurar que o software do projeto e os ativos relacionados (documentos principais) sejam submetidos ao backup, catalogados e transferidos a sites de armazenamento designados. Os arquivos mostram o seu valor quando é necessária alguma reutilização ou quando acontecem desastres. Os arquivos precisam ser criados regularmente e nos marcos principais e secundários.

As diretrizes de identificação descritas anteriormente na etapa 'Definir a Convenção de Identificação de Produtos de Trabalho' do processo podem ser utilizadas durante a criação de etiquetas de arquivamento. No entanto, informações adicionais sobre o local onde a mídia real será armazenada podem ser necessárias. Por exemplo:

Todas as informações relacionadas devem ser mantidas em um banco de dados para facilitar a liberação e a reutilização.

A Elaboração de Relatórios de Status de Configuração , se utilizada, descreve as várias origens para criação de Relatórios de Status de Configuração.

Selecionar Relatórios com Base em Controles de Mudanças

Aqui, você deve selecionar relatórios que possam ser derivados dos Controles de Mudanças enviados ao projeto. Existem vários Controles de Mudanças úteis baseados em relatórios.

Na categoria 'duração', a elaboração de relatórios pode ser solicitada em termos do número de Controles de Mudanças em períodos semanais ou mensais com base nos seguintes critérios:

• Submetido
• Designado
• Resolvido
• Prioridade

A listagem de problemas por estado pode ajudar a determinar se o projeto está ou não perto de terminar. Por exemplo, se a maior parte dos problemas foi resolvida, isso significa que a conclusão do projeto está mais próxima do que se os problemas estivessem no estado enviado.

Na categoria 'distribuição', a geração de relatórios pode ser solicitada para responder aos seguintes tipos de perguntas:

• Quem está detectando, qual tipo de defeito e em que ponto do projeto?
• A quem os problemas estão sendo atribuídos?
• Quantos problemas estão em aberto para um determinado engenheiro?
• Qual é o nível de gravidade dos defeitos que estão sendo detectados?
• Em que ponto do processo os problemas estão sendo gerados (causa original)?
• Quando os problemas serão solucionados?
• Quantos defeitos existem?
• Qual é o nível de gravidade desses defeitos?

Essas métricas podem ajudar a analisar a carga de trabalho, quem está trabalhando nos problemas mais críticos e com que rapidez os problemas estão sendo solucionados.

Na categoria 'tendência', os relatórios podem ser solicitados para responder aos seguintes tipos de perguntas:

• Quantos defeitos estão em aberto neste dia, nesta semana ou neste mês?
• Quantos defeitos foram corrigidos neste dia, nesta semana ou neste mês?

Esses dados são úteis durante a avaliação de taxas de reparo e podem fornecer indicações da eficiência do pessoal da engenharia.

Definir a Freqüência de Elaboração de Relatórios

Assegure-se de que os relatórios são recebidos na freqüência correta a fim de que uma contribuição significativa seja fornecida para a tomada de decisões. Os relatórios podem ser solicitados na seguinte freqüência

• Diariamente - é improvável que os relatórios sejam requeridos nesta freqüência
• Semanalmente - Relatórios de Tendência, de Distribuição e de Contagem, Relatórios de Construção
• Mensalmente - Relatórios de Tendência, de Distribuição e de Contagem, Relatórios de Construção
• Por Iteração - Relatórios de Tendência, de Distribuição e de Contagem, Relatórios de Construção, Descrições de Versão
• Por Fase - Relatórios de Tendência, de Distribuição e de Contagem, Auditorias, Relatórios de Construção, Descrições de Versão
• No Final do Projeto - Relatórios de Tendência, de Distribuição e de Contagem, Auditorias, Relatórios de Construção, Descrições de Versão