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:
Contextualizaçã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.
Objetivos 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.
Termos 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.
Software Configuration Configuração é o estado do conjunto de itens que formam o sistema em um determinado momento . 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).
Baseline 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).
Software Configuration Item 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.
Object Manufacturing 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.
Gerência de mudanças 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.
Versionamento 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 : 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.