Plano de Gerenciamento e Configuração

Conforme método de identificação estabelecido no Plano de Gerenciamento e Configuração: “Para cada versão entregue do projeto deverá ser criada uma tag no CVS (atualmente através da ferramenta Subversion) no formato X.Y.Z onde X, Y, Z são números definidos da seguinte forma:

X é o número da versão principal e não evolui a não ser que a funcionalidade do sistema seja profundamente alterada ou comporte uma parte totalmente nova.
Y é o número da versão menor e corresponde às evoluções menos importantes.
Z é facultativo e designado para uma pequena evolução de ordem meramente técnica (geralmente correção de bug)”. Entenda-se que o Z é facultativo o incremento de seu valor, porém, por uma questão de padronização no formato da numeração, em todos os projetos, o valor de Z deve ser, obrigatoriamente, inserido mesmo que seu valor seja 0 (zero).

Aconselha-se que a versão inicial do sistemas (ou projeto) seja inicialmente estabelecida no formato 1.0.0 (portanto não utilizando o formato 0.0.0, 0.1.0 ou 0.0.1) e, considerando definição descrita anteriormente, para o padrão X.Y.Z, X deve evoluir quando funcionalidades significativas foram incluídas ou quando houveram mudanças no sistema com impacto que justifique uma mudança no valor de X ou, ainda, X deve ser incrementado quando houver questões de incompatibilidade com versões anteriores, indicando que o sistema possui uma nova configuração que seja plenamente perceptível pelos usuários. O valor de Y deve ser alterado quando pequenas funcionalidades (ou uma funcionalidade única) foram incluídas que não justifique a mudança de X, ou seja, sem mudanças com grandes impactos em estruturas existentes. Quando alterações decorrentes de erros encontrados nos sistemas, provenientes de procedimentos de testes e utilização do sistema pelo usuário final, que não especifique a inclusão de uma nova funcionalidade no sistema, aconselha-se que o valor de Z seja alterado. É possível que um conjunto de erros corrigidos sejam associados a uma única mudança do valor de Z.

Versão x Release

Segundo Ian Sommerville (Engenharia de Software, 6ª Edição): “As novas versões de um sistema devem ser sempre criadas pela equipe de Configuração e Mudança, e não pelos desenvolvedores de sistema, mesmo quando não se destinem a liberação externa. Isso facilita manter a consistência da configuração ... “.

E, ainda, segundo Sommerville: “Um release de sistema é uma versão que é distribuída para os clientes. Cada release de sistema deve incluir nova funcionalidade ou se destinar a uma diferente plataforma de hardware. Há sempre muito mais versões de um sistema do que releases, uma vez que as versões são criadas dentro de uma organização para o desenvolvimento interno ou testes, e nunca são liberadas para clientes.”

A principal funcionalidade do Plano de Gerenciamento e Configuração é o controle de liberação de versões e releases, para isto, existe dois itens que devem ser mantidos durante o ciclo de vida do sistema (ou projeto), um deles trata da liberação de uma nova versão (Histórico de Versão), conforme indicado pela primeira tabela, e o outro trata da liberação de um novo release (Histórico de Release), conforme indicado pela segunda tabela.

Histórico de Versão

Número da Versão	Data da Liberação	Data da Implantação
X.Y.Z	dd/MM/yyyy	dd/MM/yyyy

Breve descrição da Versão
texto descritivo

Itens de verificação da Versão
texto descritivo

Responsável pela Liberação:	nome responsável

Histórico de Release

Número do Release	Data da Liberação	Data da Implantação
X.Y.Z	dd/MM/yyyy	dd/MM/yyyy

Breve descrição do Release (Histórico de Modificações)
texto descritivo

Responsável pela Liberação:	nome responsável

Solicitação de Mudança

O documento Solicitação de Mudança é o controle definido pelo Processo de Engenharia de Software para prover um gerenciamento das modificações no sistema.

Como, provavelmente, diversos documentos de Solicitação de Mudança serão gerados, um número de ordem (indicado por: nº solicitação) foi definido para identificar cada documento gerado dentro do projeto de desenvolvimento de sistema.

A versão do documento é definida pelo Processo de Engenharia de Software, portanto, quando houver modificação significativa no layout (ou itens) do documento uma nova versão será disponibilizada.

A modificação de um artefato do processo (indicando uma nova versão) somente será efetuado pela Seção de Engenharia de Sistemas. O número de versão de um artefato não tem relação com o número de versão do Processo de Engenharia de Software e nem com o número de versão do projeto onde o documento estiver sendo utilizado (verificar exemplo abaixo).
Plugin insertion failed: Could not find plugin NomePlugin insertion failed: Could not find plugin Nome
Solicitação de Mudança Plugin insertion failed: Could not find plugin no.Plugin insertion failed: Could not find plugin no.
Gerenciamento de Configuração e Mudança

No documento Solicitação de Mudança (no item Solução) existe o controle indicando em qual versão do sistema a modificação proposta pela Solicitação de Mudança foi executada, conforme indicado pela abaixo.

Data da Solução:	dd/MM/yyyy	Versão:	X.Y.Z

Detalhes da Solução:	texto descritivo

Controle de Versão de Documentos

Para controle do Histórico de Mudança de documentos (artefatos) do Processo (conforme exmplo abaixo) deve-se adotar procedimentos similares ao adotado para o versionamento do Projeto, ou seja, mantem-se o padrão X.Y.Z, onde:

X : deve ser iniciado com o número 1 (um) evitando, assim, os formatos 0.0.0, 0.1.0 ou 0.0.1 e alterado quando houver mudanças na estrutura do documento, em um conjunto de itens pré-existentes ou, principalmente, com a inclusão de itens inexistentes na versão inicial do documento, portanto, quando houver mudança significativa na estrutura do documento.
Y: deve ser alterado quando novos itens forem inicialmente completados (item existente na versão inicial do documento) em um documento já existente.
Z: deve ser alterado quando houver mudança no texto de algum item pré-existente, ou seja, mudanças com pouco impacto estrutural no documento.

Histórico de Modificações

Data	Versão	Estado	Autor
dd/MM/yyyy	X.Y.Z	estado	autor

Considerando exemplo apresentado pela Figura 6, a versão inicial do documento (considerando modelo pré-definido) iniciou com a versão 1.0.0, como houve alterações em textos pré-existente a versão foi atualizada para 1.0.1 (alteração em Z) e, por último, como um novo item foi incluído (inexistente na versão inicial do documento) alterando, desta maneira, a estrutura do documento, a versão foi atualizada para 2.0.0 (modificação em X e consequentemente em Y e Z (ambos zerados)).

Histórico de Modificações

Data	Versão	Estado	Autor
30/11/06	1.0.0	Especificação Inicial	Luis Dias Pereira
30/11/06	1.0.1	Revisão Técnica	Marcos Sakamoto
30/11/06	2.0.0	Inclusão do item Controle de Versão de Documentos	Luis Dias Pereira

Caso houvesse a especificação inicial de um item pré-existente (considerando estrutura pré-definida pelo modelo do artefato) para um documento já versionado (o item já existia no documento, porém, não havia sido completado) a modificação da versão do documentos seria feita em Y (e conseqüentemente em Z que seria novamente inicializado em 0 (zero)).

Conclusão

A Gerência de Configuração e Mudança é uma das disciplinas do Processo de Engenharia de Software que estabelece as atividades necessárias para uma evolução controlada do projeto de sistema computacional (considerando as versões e releases disponibilizados). Aconselha-se que o Líder de Projeto em conjunto com o Analista de Implantação estabeleçam as políticas necessárias para a geração de uma nova versão ou de um novo release.
É importante lembrar que o ato de disponibilizar uma nova versão do sistema, além de uma prática evolutiva de implementação, garante um recurso de retorno (backup) caso modificações não adequadas seja inseridas no projeto. Portanto, considera-se uma boa prática o ato de gerar versões do projeto de maneira sistematizada e periodicamente. É aconselhável que, pelo menos, ao final de uma iteração uma versão do projeto seja disponibilizada.