Estratégia de Gerência de Configuração

Objetivo

Este documento descreve todas as atividades de gerenciamento de controle de configuração e mudança que serão executadas durante o ciclo de vida dos projetos da STI do TJES.

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

Baseline Conjunto de um ou mais itens de configuração identificados e liberados para uso independente de suas versões
Branches Pasta do repositório onde devem ser armazenados os ramos que não são do tipo baseline
CCM Comitê de Controle de Mudanças
GCO Gerência de Configuração
SVN / CVS / GitLab / GitHub Ferramentas para controle de versão
Tags Pasta do repositório onde devem ser armazenados os rótulos e os ramos do tipo baseline
Trunk Pasta do repositório onde devem ser armazenados o ramo principal do projeto

Identificação dos Itens de Configuração

Os itens de configuração dos projetos devem ser selecionados com base nos seguintes critérios:

  • Produtos que servem para controle do projeto;
  • Produtos que possam ser utilizados por mais de um grupo/pessoa;
  • Produtos que são insumos para fases seguintes do processo de desenvolvimento;
  • Produtos que serão entregues ao cliente.

Os itens de configuração podem estar em dois níveis de controle diferentes:

  • Versionável: O item de configuração terá suas versões controladas, sem a necessidade de uma solicitação formal para mudanças;
  • Formal: A partir do momento em que for inserido em uma baseline, o item de configuração só poderá ser alterado através de uma solicitação formal de mudança aprovada.

Os itens de configuração dos projetos que estarão sujeitos à Gerência de Configuração estão listados na tabela abaixo.

Item de Configuração Nível de Controle Baseline Repositório de Armazenamento
Formulário de Solicitação de Demandas Formal Requisitos O repositório de Solicitações de Demandas está versionado no SVN. O acesso ao repositório pode ser feito através deste link.
Especificação Funcional Formal Requisitos
Plano de Testes Versionável Requisitos
Especificação Técnica Formal Construção e Testes
Código Formal Construção e Testes
Relatório de Testes Versionável Construção e Testes

[to-do: Incluir no fluxo de desenvolvimento, tarefas de criação das baselines de Requisitos, e Construção e Testes]

Regras Comuns de Nomenclatura

Regras comuns para padrão de nomenclatura de todos os tipos de item de configuração:

  • Devem ser usados undescore ou hifem para separar palavras;
  • Não devem ser usados caracteres especiais nas palavras, como acento, cedilha, til, etc.
  • Não devem ser usados espaços no nome do arquivo;
  • Nos documentos de projeto, utilizar o código do projeto iniciando a nomenclatura

Versões dos Documentos

Os códigos das versões dos documentos devem seguir o padrão X.Y, sendo que X é um número sequencial iniciado em 1 e Y é um número sequencial iniciado em 0.

Para cada mudança, uma nova versão do documento deve ser criada. O código da versão e descrição da mudança devem ser registrados na tabela de controle de versão de cada documento.

Caso a mudança tenha grande impacto no documento, deve ser incrementado de 1 (um) o valor X da versão e atribuído o valor 0 (zero) para o valor Y. Mudanças de grande impacto são aquelas que modificam significativamente o conteúdo de um documento, como os marcos de um cronograma, o escopo do plano do projeto ou os casos de uso de uma especificação de requisitos. Nestes casos, deve-se obter um novo comprometimento dos envolvidos com a nova versão do documento.

Caso a mudança não tenha grande impacto no documento, deve ser apenas incrementado de 1 (um) o valor Y da versão. Mudanças sem grande impacto são aquelas que modificam apenas o formato de um documento, como a fonte do texto, cabeçalho ou rodapé. Nestes casos, não é necessário obter um novo comprometimento dos envolvidos com a nova versão do documento.

Nomenclatura do tipo Baseline de Projeto

As baselines de projeto devem seguir o seguinte padrão de nomenclatura:

Modelo: <Código da Demanda>_<Nome da Fase (Requisitos ou Construção e Testes)>_RC<Número Sequencial da Baseline Candidata>

Exemplos:

DEMANDA123_Requisitos_RC01

DEMANDA123_Requisitos_RC02

DEMANDA123_ConstrucaoTestes_RC01

DEMANDA123_ConstrucaoTestes_RC02

Nomenclatura para Rótulos de Produtos (Build)

Os rótulos do projeto (baselines aprovadas) devem seguir o seguinte padrão de nomenclatura:

Modelo: <Nome do Sistema>_<Número da Versão>

  • O Número da Versão deve seguir o formato V_X_Y_Z, onde
    • X – Representa o número da versão do produto. Inicia em 1 (um) e incrementa para grande evoluções.
    • Y – Representa liberações intermediárias. Inicia em 1 (um) e incrementa para evoluções e customizações.
    • Z – Representa correções. Inicia em 1 (um) e incrementa para cada correção realizada

Exemplos:

PJE_V_2_1_5

Ações de Gerenciamento de Configuração

As ações possíveis de serem executadas no contexto de gerenciamento de configuração são as seguintes:

  • Pull / Update: [to-do: completar conforme os ambientes de gestão de configuração de cada produto / time]
  • Push / Commit: [to-do: completar conforme os ambientes de gestão de configuração de cada produto / time]
  • Merge: [to-do: completar conforme os ambientes de gestão de configuração de cada produto / time]
  • Tag / Label: [to-do: completar conforme os ambientes de gestão de configuração de cada produto / time]

Controle de Ocorrências

Todo problema encontrado durante a execução do projeto deve ser cadastrado na ferramenta JIRA. Após esse cadastro o Gerente do Projeto deve analisar a problema e identificar o tipo de ocorrência, que pode ser: Defeito, Melhoria e Solicitação de Mudança. Uma ocorrência só pode ser identificada como defeito, caso não afete nenhum item de configuração pertencente à baseline. Se afetar algum item de baseline, deve ser identificada como Solicitação de Mudança.

Processamento de Controle de Mudanças

Toda mudança de um item de baseline deve ser controlada, através de solicitação, análise de impacto, verificação e aprovação.

O controle de mudanças pode ser executado por qualquer membro da equipe responsável por um item de configuração, durante a execução do projeto ou na fase de operação.

As solicitações de mudança são realizadas através da ferramenta JIRA como uma ocorrência. O gerente de projeto analisa a ocorrência e identifica se é uma solicitação de mudança ou uma dúvida. Caso a ocorrência seja identificada como solicitação de mudança, o gerente do projeto deve realizar a análise de impacto que deverá ser descrita na tarefa como um comentário, listando os itens de configuração de baseline afetados para serem verificados e alterados, conforme pertinente.

A partir da análise de impacto, o gerente de projeto deve criar tarefas pendentes à tarefa original para correção dos itens afetados, explicitando a liberação do(s) item(s) de baseline para alteração.

Mudança de um item de baseline configura uma solicitação de mudança, no entanto, de acordo com os critérios abaixo, não deve ser configurada como solicitação de mudança:

  • Mudança de nomenclatura de um artefato seja por nome fora do padrão ou incorreto;
  • Movimentação de um artefato para outra pasta;
  • Atualização de índice, cabeçalho, rodapé, folha de rosto de um artefato.

Auditorias de Configuração

As auditorias de gerência de configuração devem ser realizadas com o intuito de garantir que as configurações estejam completas e consistentes, devem ser realizadas verificações nos itens de configuração e baselines estabelecidas, como definido neste plano. As auditorias de gerência de configuração devem ser realizadas imediatamente após a criação das baselines.

Finalizada a auditoria, o auditor de configuração deve gerar um Relatório de Auditoria de Configuração com o resumo dos itens com falhas e o as Não Conformidades (NCs) encontradas devem ser registradas no JIRA. Após feito isso o gerente de configuração envia um e-mail com o número das NCs referentes as não conformidades encontradas na auditoria.

Após a liberação de uma baseline, o gerente do projeto, altera o nome da Release Candidate, sendo assim ela passa a ser a baseline final e o auditor de configuração verifica se a nomenclatura está de acordo com o definido nesta estratégia.

As não-conformidades devem ser resolvidas no prazo de 2 (dois) dias úteis. Não-conformidades não resolvidas nesse prazo devem ser escaladas para o nível hierárquico superior com novo prazo de resolução de 2 (dias) úteis.