Gerência de configuração de software – Wikipédia, a enciclopédia livre

Este artigo ou secção contém uma lista de referências no fim do texto, mas as suas fontes não são claras porque não são citadas no corpo do artigo, o que compromete a confiabilidade das informações. Ajude a melhorar este artigo inserindo citações no corpo do artigo. (Dezembro de 2015)

Gerência de configuração de software, gerência de configuração ou ainda gestão de configuração de software é uma área da engenharia de software responsável por fornecer o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria das configurações. Roger Pressman, em seu livro Software Engineering: A Practitioner's Approach, especifica que a gerência de configuração de software (GCS) é o:

A história da gerência de configuração de software surge em meados da década de 1970, quando os microprocessadores se tornaram populares e o software deixou de ser considerado parte integrante do hardware para se tornar um produto independente. Nesta época, os sistemas se tornaram cada vez maiores e sofisticados, ficando claro que seriam necessárias metodologias próprias, diferentes das usadas no desenvolvimento de hardware, para controlar o desenvolvimento desses sistemas.

O Departamento de Defesa (DoD) dos EUA foi um dos pioneiros nessa área, criando o padrão DoD-STD-2167 que abordava o desenvolvimento de software. A abordagem do DoD para controlar isto consistia da adoção de uma linguagem padronizada -- Ada—e de práticas padrão para desenvolvimento de software e gerência de configuração.

Outras organizações estavam por sua vez adotando práticas e métodos de gerência de configuração de software, algumas das quais envolvidas também com o desenvolvimento de sistemas para o DoD e outros órgãos do governo Americano. Isto levou o próprio DoD a adotar algumas práticas comerciais e eventualmente uni-las com seus padrões, gerando assim o padrão IEEE/IEA 12207. Um outro padrão a respeito é o IEEE 828-1983.

No início do desenvolvimento, a GCS permite à equipe de desenvolvimento identificar as unidades que compõem o sistema de acordo com as funcionalidades que elas deverão desempenhar, e as interfaces entre estas unidades, documentando assim a interação entre elas. O controle contínuo da evolução destas funcionalidades e interfaces permite que a integração entre estas unidades tenha sucesso continuado, com as mudanças devidamente gerenciadas e documentadas. Por fim, a auditoria das funcionalidades identificadas, documentadas e controladas garante a confiabilidade do sistema.

A terminologia específica da GCS, como também sua história, tem dado origem a controvérsias, de freqüentes variações. Ferramentas vendidas como também acadêmicas tiraram vantagem disto para deliberadamente mudar a terminologia ou procedimentos para reduzir a possibilidade dos clientes para mudanças, algumas vezes tentando desta maneira redefinir o estabelecimento de acrônimos.

Em particular, o vendedor conhecido como Atria (depois Rational Software), agora uma parte da IBM, usava SCM como padrão para Software Configuration Management (em português: "Gerência de Configuração de Software") enquanto o Gartner Group usa o termo SCCM ou Software Change and Configuration Management (em português: "Gerência de Mudanças e Configuração de Software").

Entretanto, os conceitos básicos da GCS descritos abaixo são bem aceitos, divergindo de um autor ou fornecedor para o outro meramente nos termos utilizados.

Configuração é o estado do conjunto de itens que formam o sistema em um determinado momento [1]. Este sistema pode ser composto de todo tipo de elementos, como peças de hardware, artefatos eletrônicos ou não (i.e. documentos em papel), etc. A configuração de software trata apenas dos elementos que se encontram em formato eletrônico e fazem parte dessa configuração. Isso inclui todos os arquivos fontes, todos os documentos eletrônicos, as ferramentas de software utilizadas para construir ou mesmo ler estes arquivos, o sistema operacional utilizado, as bibliotecas de software, etc.

Essa configuração varia com o tempo, pois novos arquivos são incluídos, e arquivos existentes são alterados ou removidos. O objetivo da gerência de configuração como um todo é organizar todos estes elementos de forma a saber em qual estado o sistema se encontrava nos momentos chave do desenvolvimento (por exemplo, quando o sistema foi entregue ao cliente, quando o sistema passou por uma mudança de versão, quando o sistema foi enviado para auditoria, etc). A gerência de configuração como um todo trata dos elementos, incluindo hardware, necessários para a manutenção apropriada do sistema. A gerência de configuração de software trata especificamente dos elementos necessários à construção de sistemas de software, e em geral, controla apenas os elementos em formato computadorizado.

Em sistemas de controle de versão as configurações específicas são geralmente identificadas pelo uso de tags ou labels (etiquetas ou rótulos, em inglês).

Linha-base ou baseline é um conceito de gerenciamento de configuração de software que nos ajuda a controlar as mudanças, sem impedir seriamente as mudanças justificáveis. Segundo PRESSMAN no contexto de engenharia de software, definimos uma linha-base como um marco de referência no desenvolvimento de um software, que é caracterizado pela entrega de um ou mais itens de configuração (em inglês, Software Configuration Items - SCIs) e pela aprovação desses SCIs, obtida por meio de uma revisão técnica formal.

Exemplos de linhas-base:

• Versão 1.0
• Versão de correção de erros 1.1
• Versão personalizada do sistema para o governo americano

Em Sistemas de controle de versão uma linha-base é geralmente identificada pelo uso de branches (ramos, em inglês).

Durante o desenvolvimento de software, uma grande quantidade de informações é produzida e cada um desses documentos produzidos que precisam sofrer controle de versões e de mudanças é chamado de item de configuração de software O Item de configuração é um elemento unitário que será gerenciado: um arquivo de código fonte, um documento de texto, um projeto de uma placa eletrônica, uma planta feita em papel, um CD-ROM de instalação de um sistema operacional, etc. A configuração de um sistema é basicamente a lista de todos os itens de configuração necessários para reproduzir um determinado estado de um sistema. Em geral números de versão são associados aos itens de configuração de forma a podermos identificar também a evolução destes itens.

Exemplos de itens de configuração podem ser:

• Item A: CD de instalação do sistema operacional, versão 1.0
• Item B: Documento de ajuda do sistema em formato eletrônico, versão 2.0
• Item C: Processador de texto usado para imprimir o documento de ajuda, versão 5.0

e assim por diante.

Segundo Pressman os seguintes SCIs tornam-se alvos das técnicas de GCS e formam um conjunto de linhas básicas (baselines):

1. Especificação do Sistema.

2. Plano de Projeto do Software.

3. a) Especificação dos Requisitos de Software; b) Protótipo executável ou "em papel".

4. Manual Preliminar do Usuário.

5. Especificação de Projeto: a) Descrição do projeto de dados; b) Descrições do projeto arquitetural; c) Descrições do projeto modular; d) Descrições do projeto de interfaces; e) Descrições de objetos (no caso do uso da metodologia OO).

6. Listagem do código-fonte.

7. Teste de Software/Sistema: a) Plano e Procedimentos de Testes; b) Casos de teste e resultados registrados.

8. Manuais Operacionais e de Instalação.

9. Programa Executável: a) Módulos; b) Módulos interligados.

10. Descrição do Banco de Dados: a) Esquema e estrutura de arquivo; b) Conteúdo inicial.

11. Manual Feito de Acordo com o Usuário.

12. Documentos de Manutenção: a) Relatórios de problemas de software; b) Solicitações de manutenção; c) Pedidos de mudança de engenharia.

13. Padrões e procedimentos para engenharia de software.

Definimos SCI, no mecanismo de identificação de gerenciamento de configurações, como sendo a sua entidade mais elementar.

Segundo PRESSMAN dois tipos de objetos podem ser identificados:

• Objeto básico: uma "unidade de texto" que foi criada pelo engenheiro de software durante a análise, o projeto, a codificação ou o teste.
• Objeto composto: coleção de objetos básicos e outros objetos compostos.

Cada objeto tem um conjunto distinto de características que o identifica unicamente: um nome, uma descrição, uma lista de recursos e uma realização.

• Nome: cadeia de caracteres que identifica o objeto claramente.
• Descrição: é uma lista de itens de dados que identifica: - O tipo de SCI (ex.: documento, programa, dados) que é representado pelo objeto; - Um identificador do projeto; - Informações sobre mudanças e/ou versão
• Recursos: entidades fornecidas, processadas, consultadas ou, por outro lado, exigidas pelo objeto.

Para um objeto básico, a realização é um indicador para a "unidade texto" e para o objeto composto a realização é nula.

A gerência de mudanças é uma parte geralmente negligenciada da Gerência de configuração. Como ela não tem resultados imediatos para os desenvolvedores e engenheiros de software envolvidos no projeto, estes acabam por não perceber sua importância. Gerência de mudanças entretanto é uma parte importante da Gerência de configuração, pois é a atividade que permite se saber o motivo de uma configuração ter sido mudada para outra configuração. Esta atividade também pode ser parcialmente automatizada, e diversos sistemas de controle de versão já são integrados com sistemas de gerência de mudanças. A gerência de mudanças tem por objetivo mapear, para cada mudança efetuada no sistema, qual foi o motivo que gerou esta mudança. É comum vermos em sistemas de software arquivos que listam as melhorias e mudanças entre duas versões. Estes arquivos são resultado da gerência de mudanças, identificando o que mudou entre uma versão e outra.

Exemplos

• mudança da versão 1.0 para 1.1 inclui:
  • correção do problema 355
  • correção do problema 356
  • correção do problema 358
  • nova funcionalidade de impressão de relatórios
• pendências para a versão 1.2:
  • correção das mudanças 357 e 359.
  • impressão de relatórios coloridos.

Ocorrem muitos problemas durante o desenvolvimento de software que são causados por falta de controle sobre os arquivos do projeto.

Vamos a uma avaliação [2]:

• Você já perdeu alguma versão anterior do arquivo do projeto?
• Já teve problemas em manter diferentes versões do sistema rodando ao mesmo tempo?
• Alguém já sobrescreveu o seu código por acidente e você acabou perdendo seu arquivo?
• Você tem dificuldades em saber quais as alterações que foram efetuadas e quando foram feitas e quem fez?

Se você respondeu que sim para as perguntas acima, então você precisa de um sistema para controle de versão para o seu projeto. Controle de versão deve ser utilizado em todo o andamento do projeto de desenvolvimento de software.

O controle de versão rastreia e controla todos os artefatos do projeto (código-fonte, arquivos de configuração, documentação etc.) e assim consegue coordenar o trabalho paralelo de desenvolvedores através das seguintes funcionalidades:

• Mantém e disponibiliza cada versão já produzida de cada item do projeto
• Possui mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existência de diferentes versões ao mesmo tempo (concorrência)
• Estabelece uma política de sincronização de mudanças que evita a sobreposição de mudanças
• Fornece um histórico completo de alterações sobre cada item do projeto

Controle de versão resolve diversos problemas básicos de desenvolvimento tais como uso de diferentes versões de código, sincronização do trabalho paralelo de desenvolvedores no mesmo projeto, recuperação de versões anteriores e registro do histórico de alterações.

A finalidade do controle de versão é dar um controle maior sobre tudo que você altera no seu projeto de software. Ele permite que você tenha um histórico de tudo o que você mudar no seu projeto. Se você modificou aquela rotina para otimizar uma consulta, se você inseriu uma nova função e retirou outra, se você modificou a imagem que era exibida em determinada página html, tudo fica guardado neste histórico. Para que isso? Para o caso de sua alteração causar algum problema! Se deu você nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez tudo correto, basta um simples comando e você recupera o estado anterior.

Todos os arquivos e diretórios que compõem o projeto ficam sob a responsabilidade do sistema de controle de versão num local denominado de repositório, lugar onde se guarda, arquiva, coleciona alguma coisa. É o local onde você vai guardar o seu projeto. Na prática, é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seu pendrive. O repositório registra cada alteração realizada em cada arquivo e diretório controlado. À medida que o projeto evolui, o repositório passa a guardar múltiplas versões dos arquivos que compõem o projeto. Essas múltiplas versões são organizadas em revisões. Uma revisão funciona como um clone de todos os arquivos do projeto em um determinado momento do tempo. Os clone antigos são mantidos e podem ser recuperados e analisados a qualquer momento. Para economizar espaço, apenas as diferenças entre as revisões costumam ser armazenadas no repositório. Quando se deseja recuperar determinado arquivo, as diferenças são analisadas e o arquivo é remontado de acordo com a revisão desejada. Mesmo que não haja alteração em um arquivo entre uma revisão e outra, o número da revisão do arquivo acompanha o número da revisão global, de modo a manter sempre um grupo coeso e coerente de arquivos.

Alguns projetos precisam de variações específicas, conforme as necessidades específicas de cada cliente, ou criação de um ramo para experimentações no projeto, sem comprometer a linha principal de desenvolvimento. O sistema de controle de versão oferece funcionalidades que facilitam a coordenação de ramos diferentes de desenvolvimento em um mesmo projeto. As alterações feitas em um ramo muitas vezes precisam ser mescladas em outro ramo. Essa operação é bastante delicada e é facilitada em muito com o sistema de controle de versão, que permite bastante controle e automação no processo. Mesmo em caso de uma fusão malsucedida, o sistema de controle de versão permite voltar ao estado anterior, o que traz bastante segurança aos desenvolvedores.

Como os desenvolvedores trabalham em paralelo e concorrentemente nos mesmos arquivos do projeto, é necessária uma política para ordenar e integrar todas essas alterações, de modo a evitar que um desenvolvedor sobrescreva as alterações de outro desenvolvedor.

O controle de versão além de rastrear e controlar alterações, também coordena a edição colaborativa e o compartilhamento de dados entre os vários desenvolvedores de uma equipe.

Cópia de trabalho

Os desenvolvedores não trabalham diretamente nos arquivos do repositório. Cada desenvolvedor possui uma cópia de trabalho que espelha os arquivos do repositório para trabalhar com liberdade enquanto termina suas tarefas, isolado dos outros desenvolvedores.

Política TRAVA-MODIFICA-DESTRAVA

Nessa política, o sistema de controle de versão permite que apenas um desenvolvedor por vez altere um determinado arquivo do projeto. Ela é restritiva e frequentemente atrapalha o trabalho dos usuários. O travamento pode causar alguns problemas administrativos e forçar a uma serialização desnecessária.

Política COPIA-MODIFICA-RESOLVE

Nessa política, não existe travamento de arquivos. Cada desenvolvedor trabalha livremente em qualquer arquivo da sua cópia de trabalho. Ao final, as alterações de cada desenvolvedor são mescladas no repositório formando a versão final. A solução "copia-modifica-resolve" parece um pouco estranha e bagunçada a princípio, mas funciona bem na prática. Conflitos são raros e são causados basicamente pela falta de comunicação entre desenvolvedores. Na grande maioria dos casos, as alterações não se sobrepõe e são mescladas automaticamente pelo sistema de controle de versão.

É o conjunto de todas as alterações que ocorreram no sistema para atender um determinado fim, ou num determinado período de tempo. Fazendo um mapeamento dos itens que foram mudados para uma dada versão do sistema com os motivos das mudanças. Um exemplo de conjunto de mudanças:

Mudanças da versão 1.0 para a versão 1.1

• Item A mudou da revisão 1.0 para a revisão 1.1
• Item B mudou da revisão 4.5 para a revisão 5.0
• Item C foi eliminado
• Item D foi acrescentado na revisão 5.5
• Item E mudou de nome para item F.

Como o repositório registra todas as alterações que foram efetuadas, o sistema de controle de versão pode informar com facilidade quais as alterações que foram realizadas entre uma revisão e outra, quando isso ocorreu e quem fez as alterações. Essas informações permitem um controle maior sobre mudanças no projeto.

Uma auditoria de configuração física (PCA) identifica os componentes de um produto que serão implantados do Repositório do Projeto. Os passos são:

• Identificar a baseline a ser implantada (geralmente é apenas um nome e/ou número, mas também pode ser uma lista completa de todos os componentes e suas respectivas versões).
• Confirmar que todos os artefatos necessários, conforme especificado pelo Caso de Desenvolvimento, estão presentes na baseline. Liste os artefatos ausentes em Descobertas da Auditoria de Configuração.

Algumas organizações usam uma Auditoria de Configuração Física para confirmar a consistência do design e/ou documentação do usuário com o código. O Rational Unified Process recomenda que a verificação dessa consistência seja executada como parte da atividade de revisão no decorrer do processo de desenvolvimento. No último estágio, as auditorias devem se limitar a verificar os produtos liberados necessários que estão presentes, sem se preocupar em revisar o conteúdo.

Uma Auditoria de Configuração Funcional (FCA) confirma que uma baseline atende aos requisitos estabelecidos para ela. Os passos para a execução dessa auditoria são:

• Preparar um relatório que liste cada requisito estabelecido para a baseline, seu procedimento de teste correspondente e o resultado de teste (aprovado/reprovado) da baseline.
• Confirmar que cada requisito passou por um ou mais testes e que o resultado de todos esses testes foi 'aprovado'. Em Descobertas da Auditoria de Configuração, liste quaisquer requisitos que não tenham passado por procedimentos de teste e os requisitos que estão com teste incompleto ou que foram reprovados.
• Gerar uma lista das CRs estabelecidas para essa baseline. Confirme que cada CR foi fechada. Em Descobertas da Auditoria de Configuração, liste quaisquer CRs que não estão fechadas.

Se houver alguma discrepância, ela será capturada em Descobertas da Auditoria de Configuração conforme descrito anteriormente. Além disso, os seguintes passos deverão ser executados:

• Identificar ações corretivas. Talvez, isso requeira a entrevista de vários membros da equipe do projeto para que a origem da discrepância e as ações apropriadas sejam identificadas.
• Para artefatos ausentes, a ação apropriada é geralmente controlar a configuração do artefato ou criar uma CR ou tarefa que produzirá o artefato ausente.
• No caso de requisitos não testados ou reprovados no teste, o requisito pode ser estabelecido para uma baseline posterior ou negociado para ser removido do conjunto de requisitos.
• Para CRs em aberto, a CR pode ser simplesmente fechada, testada ou adiada para uma baseline posterior.
• Para cada ação corretiva, atribua uma responsabilidade e determine uma data de conclusão.

A finalidade da política de gerência de configuração de software consiste em definir a maneira como as atividades de gerência de configuração de software serão executadas, o momento adequado, os responsáveis em executá-las e os conceitos envolvidos no processo. Entre as definições que devem contar nas políticas de Gerência de configuração de software podemos citar:

• Ferramentas para automatização do controle de revisões (sistema de controle de versão) caso seja usada.
  • Caso não seja usada ferramenta, deve se definir o procedimento manual para o controle de revisões.
  • Caso existam elementos que não estejam em formato eletrônico (ferramentas de hardware por exemplo), os procedimentos de controle de revisões para estes elementos deve também ser definido.
• Ferramentas para o controle de mudanças
  • Caso não seja usada ferramenta, deve também ser definido o procedimento manual.
• Controle de acesso às ferramentas de controle de revisão e controle de mudanças
• Nível de integração entre as ferramentas caso sejam ferramentas distintas
  • Alguns fabricantes fornecem ferramentas que já desempenham os papeis de controle de revisão e controle de mudanças num único sistema, enquanto outros fabricantes as fornecem em separado.
• Periodicidade e granularidade do controle de revisões
  • Recomenda-se um controle diário para elementos em formato eletrônico. A granularidade em geral depende do tipo de item e da ferramenta utilizada.
• Papéis a serem desempenhados pelos membros da equipe dentro do contexto de gerência de configuração de software.
• Frequência e forma de realização das auditorias de configuração.
  • Em geral apenas a primeira auditoria de configuração de uma linha-base precisa de intervenção humana, sendo que as auditorias subsequentes apenas verificam se houve quebra da integridade dos arquivos auditados.

    Referências

• BROWN, William J. et ali (1999). Antipatterns and Patterns in Software Configuration Management. Nova Iorque: Wiley computer publishing. 0-471-32929-0 
• MIKKELSEN, Tim, PHERIGO, Suzanne (1997). Practical Software Configuration Management. The Latenight Developer's Handbook. Upper Saddle River, NJ, EUA: Prentice Hall PTR. 0-13-240854-6  !CS1 manut: Nomes múltiplos: lista de autores (link)
• MOLINARI, Leonardo (2007). Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software. Florianópolis: Visual Books. 85-7502-210-5 
• PRESSMAN, Roger S. (1995). Engenharia de Software. São Paulo: Pearson Makron Books. 85-346-0237-9 

• Sistema de controle de versão
• Engenharia de software

• O que é Gerência de Configuração de Software

• Portal das tecnologias de informação