GESTÃO DE CONFIGURAÇÃO

GERENCIA DE CONFIGURAÇÃO

O processo de Gerência de Configuração define as atividades para a aplicação de procedimentos administrativos e técnicos por todo o ciclo de vida, destinado a:

• Controlar as modificações e liberações dos itens;

• Registrar e apresentar a situação dos itens e dos pedidos de modificação;

• Garantir a conclusão, consistência e correção dos itens;

• Controlar o armazenamento, manipulação e distribuição dos itens de software;

• Identificar e definir os itens de software em um sistema e estabelecer suas linhas básicas (baseline*).

*Versão formalmente aprovada de um item de configuração, independente de mídia, formalmente definida e fixada em um determinado momento durante o ciclo de vida do item de configuração.

NOTA - O termo “item de software” pode ser empregado para outros produtos de software ou entidades.

Lista das atividades.

1) Implementação do processo;

2) Identificação da configuração;

3) Controle da configuração;

4) Relato da situação da configuração;

5) Avaliação da configuração;

6) Gerência de liberação e distribuição.

1 Implementação do processo.

1.1 Um plano de gerência de configuração deve ser desenvolvido. O plano deve descrever: as atividades da gerência de configuração; procedimentos e cronograma para executar estas atividades; as organizações responsáveis pela execução destas atividades; e seu relacionamento com outras organizações, como por exemplo a de desenvolvimento ou manutenção de software. O plano deve ser documentado e implementado.

NOTA - O plano pode ser parte do plano de gerência de configuração do sistema.

2 Identificação da configuração.

2.1 Uma sistemática para o projeto deve ser estabelecida para a identificação dos itens de software e suas versões a serem controladas. Para cada item de software e suas versões deve ser identificado o seguinte: a documentação que estabelece a linha básica (baseline); as referências de versão e outros detalhes de identificação.

3 Controle da configuração.

3.1 Deve ser executado o seguinte: identificação e registro dos pedidos de alteração; análise e avaliação das alterações; aprovação ou rejeição do pedido; e implementação, verificação e liberação do item de software modificado. Devem existir registros de auditoria, de tal forma que, para cada modificação, a sua razão e a sua autorização possam ser rastreadas. Deve ser realizado controle e auditoria de todos os acessos aos itens de software controlados que tratam de funções críticas de proteção ou segurança.

4 Relato da situação da configuração.

4.1 Devem ser preparados registros de gerenciamento e relatórios de situação que mostrem a situação e o histórico dos itens de software controlados, incluindo a linha básica (baseline). Os relatórios de situação deveriam incluir o número de alterações em um projeto, as últimas versões do item de software, identificadores de liberação, a quantidade de liberações e as comparações entre elas.

5 Avaliação da configuração.

5.1 Deve ser determinado e garantido o seguinte: a completeza funcional dos itens de software em relação aos seus requisitos e a completeza física dos itens de software (ou seja, se seu projeto e código refletem uma descrição técnica atualizada).

6 Gerência de liberação e distribuição.

6.1 A liberação e a distribuição de produtos de software e documentação devem ser formalmente controladas. Cópias matrizes do código e da documentação devem ser mantidas durante a vida do produto de software. O código e a documentação que contenham funções críticas de proteção ou segurança devem ser manipulados, armazenados, empacotados e distribuídos de acordo com as políticas das organizações envolvidas.

ESTUDO DE CASO CEPEL

A Implantação de Gerência de Configuração no CEPEL

Para avaliar o processo proposto, esta seção apresenta e discute sua utilização na implantação de controle de versões no CEPEL.

O CEPEL é uma instituição que compõe o Sistema Eletrobrás e possui mais de 30 anos em pesquisa e desenvolvimento relacionados à geração, transmissão e distribuição de energia elétrica.

O CEPEL possui vários projetos de software em desenvolvimento. Parte dos projetos não estava sob controle de versões. Na maioria das vezes, este controle era realizado pelo desenvolvedor, que normalmente organizava as versões anteriores sob a forma de diretórios em sistemas de arquivos, fazendo backup em mídias. Os projetos que já utilizavam um sistema de controle de versões (SCV) não o faziam de maneira uniforme. Alguns problemas foram identificados e relatados por diversos usuários, como, por exemplo, bases corrompidas e dificuldade da administração do controle de acesso. Esses problemas motivaram a criação de um projeto de parceria entre o CEPEL e a Universidade Federal do Rio de Janeiro (UFRJ) com o objetivo de implantar

...