Gerência de Configuração de Software

Neste artigo são apresentados os principais conceitos de gerência de configuração de software e onde esses se encaixam no processo de desenvolvimento de software. Também são apresentadas descrições das principais tarefas de gerência de configuração de software, tais como definição e implementação do processo, identificação da configuração, controle da configuração, relato da situação da configuração, avaliação da configuração e controle de subcontratados e fornecedores.

Para que exista um maior controle no processo de desenvolvimento, e não haja inconsistências nos itens considerados importantes para o projeto, é necessário que sejam estabelecidas normas para controlar a criação e alteração dos itens de configuração.

Durante o desenvolvimento de software, uma grande quantidade de informações é produzida, tais como: especificações, planos de projeto, arquivos de código fonte, casos e planos de testes, manuais, arquivos de dados, entre outros. Cada um desses documentos produzidos poderá ser considerado um item de configuração de software. A configuração de software é composta pelos itens de configuração produzidos durante o processo de engenharia de software, ou seja, no processo de desenvolvimento disciplinado de sistemas (Pressman, 2005).

Os itens de configuração podem sofrer alterações ao longo do ciclo de vida do software, gerando novas versões, e até mesmo a criação de novos itens. Para que exista um maior controle no processo de desenvolvimento, e não haja inconsistências nos itens considerados importantes para o projeto, é necessário que sejam estabelecidas normas para controlar a criação e alteração dos itens de configuração. A essas normas dá-se o nome de gerência de configuração de software (Tichy, 1994).

A gerência de configuração vem sendo estudada desde os anos sessenta (Berlack, 1992). Inicialmente, era aplicado da mesma forma para software e hardware, sendo que no final dos anos setenta já havia padrões de gerência de configuração específicos para software.

A gerência de configuração de software é um processo abrangente, ao mesmo tempo técnica e gerencial, que se aplica a todas as atividades de engenharia de software, e pode ser visto como um dos principais elementos que compõem o sistema de garantia de qualidade de uma empresa de informática (Leblang, 1988). O processo visa identificar e definir os itens considerados relevantes ao projeto, controlar as modificações dos itens, registrar e reportar a situação dos itens e das requisições das alterações, garantir a integridade e consistência dos itens e controlar o armazenamento, manipulação, liberação e entrega dos itens (ISO/IEC 12207, 1995).

Saiba mais: Cursos de Engenharia de Software

Os ganhos em tempo e qualidade pela aplicação da gerência de configuração são comprovados e mensuráveis. Esses ganhos podem ser reconhecidos constatando-se que o uso de gerência de configuração de software facilita a comunicação entre as equipes de desenvolvedores relatando a situação do software a cada momento, assim como as alterações que foram efetuadas. Isso traz como conseqüência a redução no esforço necessário para efetuar alterações e a redução no número de erros. O resultado final é melhor cumprimento dos cronogramas, redução nos custos e melhora na qualidade do software (Berlack, 1992).

Algumas normas e modelos internacionais como a ISO/IEC 12207, ISO/IEC 15504 e o CMMI citam a gerência de configuração de software como requisito para que uma empresa inicie a melhoria de qualidade do processo de desenvolvimento de software. Dessa forma a gerência de configuração de software vem ocupando cada vez mais espaço no escopo de desenvolvimento de software (Berczuk, 2003).

A implantação da Gerência de Configuração não costuma ser fácil (Micallef, 1996). Isso ocorre pela grande diversidade de normas, padrões e modelos que não seguem um mesmo padrão na definição das atividades. O custo de implantação também costuma ser bastante alto, impossibilitando que instituições com menos recursos realizem a gerência de configuração de software (Berczuk, 2003).

Além disso, devido ao aumento de interesse pela implantação da gerência de configuração de software, existem atualmente no mercado várias ferramentas que se propõem a auxiliar a execução de práticas e processos de gerência de configuração (Lampen, 1988). No entanto, a maioria dessas ferramentas cobre apenas uma parte das atividades necessárias para implantação da gerência de configuração, confundindo muitas vezes o usuário leigo que vê nessas ferramentas a solução para todos os seus problemas de gerência de configuração.

Neste contexto, neste artigo são apresentados os principais conceitos de gerência de configuração de software e onde esses se encaixam no processo de desenvolvimento de software.

Também são apresentadas descrições das principais tarefas de gerência de configuração de software, tais como definição e implementação do processo, identificação da configuração, controle da configuração, relato da situação da configuração, avaliação da configuração e controle de subcontratados e fornecedores.

Conceitos Fundamentais

O desenvolvimento de um software pode ser organizado de várias formas. A cada uma dessas formas de organização dá-se o nome de um paradigma de ciclo de vida. Os paradigmas mais estudados são o clássico, a prototipação, o modelo espiral, as técnicas de quarta geração e os modelos evolutivos tais como RUP e XP (Pressman, 2005).

Um processo de desenvolvimento de software, independente do paradigma de ciclo de vida adotado, inclui as fases de engenharia de sistemas, análise de requisitos, projeto de software, codificação, testes e manutenção (Pressman, 2005). Na Tabela 1 é apresentada uma breve descrição de cada uma dessas fases.

Tabela 1. Fases do Desenvolvimento de Software.

Durante o processo de desenvolvimento de um software, uma grande quantidade de itens de informação é produzida. Alguns desses itens são selecionados de acordo com sua relevância e necessidade de controle tanto de versão quanto de mudança. Esses itens selecionados são chamados itens de configuração de software e o conjunto dos mesmos compõe a configuração de software (Mahler, 1994).

A criação e as alterações de cada item de configuração de software devem ser acompanhadas e controladas pelo gerente do projeto. Para isso, é necessário o estabelecimento de pontos bem definidos dentro do processo de desenvolvimento do software: as Linhas de Referência (baselines). Esses pontos podem ocorrer ao final de cada uma das fases do processo de desenvolvimento de software, ou de algum outro modo definido pela gerência.

Nos pontos estabelecidos pelas linhas de referência, os itens de configuração devem ser identificados, analisados, corrigidos, aprovados e armazenados como uma configuração de software. Os itens aprovados são armazenados em um local sob controle de acesso, denominado repositório dos itens de configuração. Esses itens só poderão ser alterados após uma solicitação de mudança formalmente aprovada pelo gerente de configuração. Essa é uma forma de prover controle sobre a situação de cada um dos itens de configuração, evitando inconsistências.

O método utilizado para trabalhar com itens de configuração que já estão no repositório é chamado de Check In/Check Out (Bersoff, 1979), ou seja, conferência na entrada e conferência na saída. Quando for desejada uma alteração em algum item de configuração do repositório, uma cópia do item é colocada numa área de trabalho do desenvolvedor (“check out”). A partir desse momento, nenhum outro desenvolvedor poderá alterar o mesmo item: a isso dá-se o nome de controle de concorrência. Dentro de sua área, o desenvolvedor tem total liberdade de trabalho. Após o final das alterações no item de configuração, ele será revisado e recolocado no repositório (“check in”). Nesse momento, uma nova baseline poderá ser estabelecida, de modo que uma nova configuração, contendo o item alterado, seja formada e armazenada no repositório (Figura 1).

Depois do armazenamento e da definição da baseline, o acesso é liberado, permitindo que outros desenvolvedores possam acessar e também executar alterações sobre esse item de configuração.

Tarefas de Gerência de Configuração de Software

As tarefas de gerência de configuração de software, que respondem às questões apresentadas na Tabela 2 são descritas a seguir.

Tabela 2. Tarefas de gerência de configuração de software

Tarefa 1 - Definição e Implementação do Processo

O processo de gerência de configuração de software deve ser estabelecido de acordo com uma política organizacional definida. Para cada projeto de desenvolvimento de software é preciso elaborar um plano de gerência de configuração, respeitando o processo de gerência de configuração da organização (IEEE Std 828, 1998). Quaisquer desvios do processo devem estar documentados no plano de gerência de configuração.

Deve ser designado um grupo para ser responsável pelo controle da configuração do projeto. Os membros do grupo de gerência de configuração devem ser treinados nos objetivos, procedimentos, e métodos para desenvolver as atividades de gerência de configuração de software.

Também é preciso prover e adequar recursos para que seja possível realizar as atividades de gerência de configuração, tais como a disponibilização de ferramentas para dar suporte às atividades de gerência de configuração. Para isso deve ser designado um gerente com responsabilidades específicas de gerência de configuração de software.

Tarefa 2 - Identificação da Configuração

O primeiro passo para a identificação é selecionar os itens a serem gerenciados. Como exemplo, é apresentado abaixo uma série de itens sugeridos por Pressman (Pressman, 2005):

1. Especificação do Sistema
2. Plano de Projeto de Software
3. Especificação de Requisitos do Software
4. Manual Preliminar do Usuário
5. Especificação do Projeto
1. Descrição do Projeto de Dados
2. Descrição do Projeto Arquitetural
3. Descrições do Projeto Modular
4. Descrições do Projeto de Interface
5. Descrições de Objetos (se forem usadas técnicas orientadas a objetos)
6. Listagem do código-fonte
7. Planos, Procedimentos, Casos de Testes e Resultados Registrados
8. Manuais Operacionais e de Instalação
9. Programa Executável e Módulos Interligados
10. Descrição do Banco de Dados
1. Esquema e estrutura de arquivo
2. Conteúdo inicial
11. Manual do Usuário
12. Documentos de Manutenção
1. Relatórios de problemas de software
2. Solicitações de manutenção
3. Pedidos de mudança
13. Padrões e procedimentos para engenharia de software
14. Ferramentas de produção de software (editores, compiladores, CASE, etc.)

É importante que seja efetuada uma seleção dos itens relevantes, porque uma super-documentação torna a gerência de configuração muito onerosa (Tuscany, 1987). Geralmente, devem sofrer gerência de configuração os itens mais usados no ciclo de vida, os mais genéricos, os mais importantes para a segurança, os itens projetados para reuso e os que podem ser modificados por vários desenvolvedores ao mesmo tempo (Bersoff, 1984). Somente os itens selecionados serão controlados, sendo que os outros itens poderão ser alterados livremente.

Saiba mais: Introdução ao Gerenciamento de Qualidade

Após a seleção, deve-se descrever como esses itens se relacionam. Consideram-se cinco classes de relacionamento: equivalência (ex: BD em disco rígido e em CD), dependência (ex: a descrição do projeto modular é dependente da especificação do projeto), derivação (ex: código objeto é derivado do código fonte), sucessão (ex: a versão 1.2 é sucessora da versão 1.1) e variante (ex: versão para DOS ou para UNIX). A identificação desses relacionamentos é muito importante para a manutenção, pois permite que se localize rapidamente os itens afetados por cada alteração.

Depois de escolhidos os itens e estabelecidos os relacionamentos, deve-se criar um esquema de identificação dos itens com a atribuição de nomes únicos a cada um dos componentes, de forma que seja possível reconhecer a evolução de cada uma das versões dos componentes e a hierarquia existente entre componentes, a partir de seus nomes (Bersoff, 1979).

Um exemplo simples para um pequeno programa cuja sigla é “PROG” é apresentado na Tabela 3. O esquema de identificação utiliza a combinação de nome do projeto, tipo de item, nome do item e versão.

Após o estabelecimento do esquema de identificação, devem ser planejadas as baselines dentro do ciclo de vida do projeto. Geralmente, cria-se uma linha de referência ao final de cada fase do ciclo de vida do projeto e, periodicamente, depois de cada manutenção. Deve-se especificar quais itens serão revisados e armazenados em cada uma das linhas de referência planejadas. O último passo da identificação é descrever a maneira como os itens serão arquivados e recuperados do repositório.

Tabela 3. Identificação dos itens de configuração

Tarefa 3 - Controle da Configuração

Dois controles básicos são instituídos no processo de gerência de configuração de software: Controle de Mudanças e Controle de Versões.

a) Controle de Mudanças

Durante o processo de desenvolvimento de software, mudanças descontroladas podem levar rapidamente ao caos (Pressman, 2005). Assim, deve ser instituído na organização um processo que combine procedimentos humanos e ferramentas automatizadas para proporcionar um mecanismo de controle das mudanças. Esse processo deve ser implementado depois que uma linha de referência for fixada - antes disso somente um controle de mudanças informal precisa ser aplicado (Bersoff, 1979; Bersoff, 1984; Pressman, 2005). A Figura 2 (Pacheco, 1997) ilustra um processo de controle de mudanças que pode ser implementado para os itens que já passaram por uma linha de referência.

De acordo com esse processo de controle de mudanças, quando um pedido de mudança é solicitado, primeiramente ele deve ser analisado, gerando um relatório de mudanças. Esse relatório é encaminhado para avaliação; se aprovado, o relatório de mudança segue para o gerente de configuração. O Gerente de configuração controla o acesso aos itens no repositório, liberando-os para a equipe de desenvolvimento para que a mudança seja efetuada, e recebendo os itens, quando atualiza o repositório. Caso o pedido de mudança não seja aprovado, o relatório e o pedido são arquivados e é dado um retorno ao solicitante.

Esse controle possibilita que as mudanças sejam efetuadas, comunicadas e incorporadas de um modo disciplinado. Entretanto, para que esse controle ocorra de forma satisfatória, qualquer mudança que ocorra nos itens de configuração de software, após o estabelecimento de uma linha de referência, deve seguir efetivamente sempre o mesmo caminho (Bersoff, 1979).

No processo de controle de mudanças, as alterações aprovadas são efetuadas de maneira sincronizada. O objetivo dessa sincronização é evitar que duas pessoas efetuem, ao mesmo tempo, mudanças incompatíveis em um mesmo item, criando inconsistências (Bersoff, 1984). O método mais utilizado para evitar inconsistências é controlar o acesso ao repositório, de forma que, quando um desenvolvedor retira um item para alterações, ele bloqueia o acesso de escrita no item para os outros desenvolvedores (Mackay, 1995).

Os procedimentos de controle das mudanças asseguram que as mudanças em um software sejam feitas de modo controlado, permitindo-se prever o efeito das mesmas em todo o sistema (Leblang, 1997). Procedimentos formais de organização e de controle das mudanças no sistema permitem que os pedidos de alteração possam ser considerados em conjunto com outros pedidos (Honda, 1988). Desse modo, os pedidos similares podem ser agrupados, e os pedidos incompatíveis entre si ou com os objetivos do sistema identificados. Também podem ser atribuídas prioridades aos pedidos e, de acordo com essas prioridades, pode-se gerar um cronograma (Rigby, 2003).

b) Controle de Versões

Um item, ao ser desenvolvido, evolui até que atinja um estado em que atenda aos propósitos para o qual foi criado. Isso implica em diversas alterações, gerando uma versão do item a cada estado (Munch, 1996). Para estabelecer o controle sobre as diversas versões, todas as versões devem ser armazenadas e identificadas. Isso, geralmente, é feito com o auxílio de uma ferramenta.

A versão do item pode ser incluída no esquema de identificação ou ser acessível a partir de uma tabela à parte. É conveniente que o esquema de identificação das versões dos itens seja feito em forma de árvore, pois ao mesmo tempo em que mantém um histórico das versões dos itens, permite identificação única e ramificações a partir de qualquer versão (Figura 3 (Pacheco, 1997)).

Quando um item existe simultaneamente em duas ou mais formas diferentes que atendam a requisitos similares, temos variantes do item, representados por ramificações na árvore. Um exemplo seria o de duas sub-rotinas para retornar a data do sistema operacional: uma para Unix e outra para DOS (versões 2.1.1 e 2.2.1 na Figura 3).

Para minimizar o espaço de armazenamento das versões utiliza-se o conceito de delta, ou seja, são armazenadas uma versão completa e as diferenças entre as versões (Brown, 1991; Humphrey, 1989). Há duas variações desse conceito: delta negativo e delta positivo. Com o delta negativo, armazena-se integralmente a versão mais recente e as diferenças (deltas) existentes até então. Com o delta positivo, armazena-se a versão mais antiga e, para montar as versões mais recentes, processam-se as diferenças (deltas) armazenadas (Clemm, 1999).

Os sistemas atuais de gerência de versões utilizam o conceito de delta negativo no tronco, por ser mais comum a utilização de versões mais recentes do item de configuração (Berczuk, 2003). A Figura 3 representa um caso em que se utiliza delta negativo. A única versão armazenada integralmente é a 4. As outras versões são construídas, quando solicitadas, a partir da 4 e das diferenças armazenadas. Utilizam-se deltas negativos no tronco da árvore, que representa o caminho principal de evolução do item. As ramificações representam as variantes dos itens e são obtidas pela utilização de delta positivo.

Tarefa 4 - Relato da Situação da Configuração

O objetivo dessa tarefa de gerência de configuração é relatar a todas as pessoas envolvidas no desenvolvimento e na manutenção do software as seguintes informações sobre as alterações na configuração de software:

• O que aconteceu?
• Quem o fez?
• Quando aconteceu?
• O que mais será afetado?

Para isso, deve ser criado um banco de dados sobre as ocorrências na gerência de configuração. Esse banco de dados deve estar disponível aos desenvolvedores com acesso através de palavras-chave. Além disso, deve ser gerado regularmente um relatório de situação para informar as alterações mais importantes. O acesso rápido às informações sobre a configuração agiliza o processo de desenvolvimento e melhora a comunicação entre as pessoas, o que é uma maneira de eliminar muitos problemas relativos à modificação do mesmo item de informação, com intenções diferentes e conflitantes.

Saiba mais: Como formar Times de alta performance

Tarefa 5 - Auditoria da Configuração

A identificação e controle das alterações ajudam a manter ordem, mas para assegurar que a alteração foi implementada apropriadamente, há necessidade de auditorias na configuração do software.

Existem dois tipos de auditoria de configuração de software que são pré-requisitos para o estabelecimento das baselines no ciclo desenvolvimento de software: a Auditoria Funcional e a Auditoria Física.

A auditoria funcional preocupa-se com aspectos internos dos arquivos, compreendendo uma verificação técnica formal na configuração de software, que deve ser realizada ao ser fixada uma baseline. Esta verificação é uma atividade de controle de qualidade que tenta descobrir omissões ou erros na configuração, que degradam os padrões de construção do software (Capretz, 1994; Pressman, 2005).

A auditoria física é um processo administrativo que ocorre no final de cada fase do ciclo de vida do software e consiste em verificar se a configuração que será baselined, ou seja, fará parte de uma baseline, está composta da versão mais recente dos itens de configuração, determinados para a fase do ciclo de vida específica (Bersoff, 1979; Bersoff, 1984) e se os procedimentos e padrões foram devidamente aplicados.

Tarefa 6 - Controle de Subcontratados e Fornecedores

As atividades de controle de subcontratados e fornecedores coordenam a forma como os itens que foram desenvolvidos por solicitação a outras empresas ou foram adquiridos já prontos são testados e incorporados ao repositório do projeto.

Para itens subcontratados o plano deve descrever:

• Os requisitos de gerência de configuração de software a serem satisfeitos pelo subcontratado;
• Como será feito o monitoramento sobre o subcontratado;
• Como o código, documentação e dados externos serão testados, aceitos e adicionados ao projeto;
• Como serão tratadas as questões de propriedade do código produzido, como direitos autorais e royalties.

Para itens adquiridos prontos o plano deve descrever:

• Como serão recebidos, testados e colocados sob controle de gerência de configuração;
• Como as mudanças no software do fornecedor serão tratadas;
• Se e como o fornecedor participará no processo de gerência de mudança do projeto.

Itens de configuração poderão ser adquiridos de fornecedores, subcontratados, clientes, outros projetos ou outras fontes.

Conclusões

Neste artigo foram apresentados conceitos gerais e as principais tarefas de gerência de configuração de software. Um estudo detalhado das necessidades específicas de cada ambiente de desenvolvimento de software, no que diz respeito à gerência de configuração de software, é necessário para que seja possível a execução das tarefas de forma mais adequada a cada situação.