Projeto
Gerência de Configuração
Definições Iniciais, Ferramentas e Processo
De que se trata o artigo:
Neste artigo serão mostrados inicialmente aspectos relevantes da gerência de configuração. Na segunda parte do artigo, será apresentada a aplicação da gerência de configuração dentro dos principais modelos de maturidade e as vantagens de se utilizar tais ferramentas, através de um estudo de caso de implementação em uma empresa hipotética.
Para que serve:
Este trabalho tem como intuito servir como um material de apoio para aqueles que desejam implementar gerência de configuração em uma organização desenvolvedora de software, usando como ferramentas de controle de mudanças e controle de versões, o Mantis e o Subversion respectivamente.
Em que situação o tema é útil:
Para qualquer empresa de desenvolvimento de software que tenham interesse em aumentar o controle e confiabilidade nos artefatos gerados pela equipe de desenvolvimento ao longo de um processo de desenvolvimento de software.
Com um mercado cada vez mais exigente, as empresas que fabricam software tem revisto seus processos de construção com o intuito de aumentar a qualidade de seus produtos e também sua produtividade. Diversas metodologias de desenvolvimento de software voltadas para o controle tem sido elaboradas uma vez que um projeto de software, ao longo do seu ciclo de vida, tem uma grande quantidade de itens de informação tais como documentos, código-fonte, dados, manuais e outros, produzidos e até modificados, pelos mais diversos motivos.
Para que a qualidade do software seja garantida, em função destas modificações, é necessário que se faça uso da Gerência de Configuração de Software (GCS). A Gerência de Configuração de Software tem como objetivo gerenciar e controlar a evolução de um software através do controle formal de versão e solicitação de mudanças. É uma forma sistemática e organizada de controlar as modificações de um software tornando possível manter sua integridade ao longo do tempo. A quantidade de itens que podem estar sob controle da GCS e os níveis de controle exigidos sobre estes itens irá variar de empresa para empresa ou mesmo de projeto para projeto. Sendo assim, o uso desta prática em conformidade com modelos de maturidade mantidos por entidades que possuam credibilidade nacional e internacional, e também o uso de ferramentas adequadas que garantam a qualidade deste processo, é fundamental para que uma empresa obtenha êxito e reconhecimento.
Para empresas de grande porte, isto não chega a ser um grande problema pois normalmente se dispõem de capital e pessoal qualificado para manter tais práticas. Entretanto, quando voltamos a olhar para as pequenas empresas, o cenário é exatamente o oposto. As dificuldades e o custo envolvidos para se adotar um modelo de gestão, treinar pessoal, adquirir ferramentas que apóiem a pratica de GCS, e ainda obter certificação em um determinado nível de modelo de maturidade, de uma entidade reconhecida, pode levar uma pequena empresa a desistir rapidamente da adoção de um processo de GCS com qualidade, e como conseqüência, perder em competitividade para outras empresas. Este artigo foi feito com o foco voltado para estas empresas.
Neste contexto, o objetivo deste artigo é mostrar uma solução especifica, de boa qualidade e baixo custo, que atenda as exigências dos modelos de maturidade e que possa ser utilizada para implementar a Gerência de Configuração de Software em pequenas empresas.
Sob esta perspectiva, será apresentada uma revisão bibliográfica sobre GCS, sua aplicação dentro dos modelos de maturidade CMMI e MPS e uma solução especifica utilizando as ferramentas Mantis e Subversion, através de um estudo de caso de uma empresa fictícia de pequeno porte que atenda as exigências do modelo de maturidade MPS, e que possa servir como alternativa para empresas reais que estejam buscando a implementação do processo de GCS. Serão apresentados também os aspectos de instalação e configuração das ferramentas, a fim de facilitar àqueles que forem utilizá-las.
Ao longo do ciclo de vida de um software, diversas modificações podem ocorrer em seu projeto original. Os motivos e origens destas modificações podem ser os mais variados possíveis e podem ocorrer em qualquer época.
A primeira lei da engenharia de sistemas diz:
“Independente de onde você está no ciclo de vida de um sistema, o sistema vai se modificar e o desejo de modificá-lo vai persistir ao longo de todo o ciclo de vida”. Bersoff (1980 apud Pressman, 2006, p. 600)
Produtos de software normalmente envolvem quantidades significativas de artefatos que são manuseados por diversas pessoas envolvidas em seu projeto.
Assim sendo, a possibilidade de introdução de defeitos aumenta à medida que alterações são efetuadas sem uma analise antes da sua execução, sem o registro formal antes da sua implementação, sem a comunicação às pessoas que necessitam saber delas ou ainda sem um controle que vise melhorar a qualidade e reduzir os erros.
Existem quatro fontes fundamentais de modificações de software:
· Novas condições de negócio e/ou mercado, modificam regras de negócio;
· Novas necessidades do cliente exigem modificações de funcionalidades;
· Reorganização e/ou crescimento/diminuição do negócio;
· Restrições de orçamento ou cronograma, causando redefinição do sistema;
Conceitos e Terminologias
A Gerência de Configuração de Software (GCS) ou Software Configuration Management (SCM) é uma atividade abrangente que ocorre ao longo de todo o ciclo de vida de um software e que gerencia e controla sua evolução, através do controle de versões e solicitações de mudanças, permitindo que os diversos envolvidos na sua criação e manutenção tenham acesso ao histórico destas modificações, fornecendo-lhes subsídios para o entendimento do sistema na sua forma atual, e também nas suas formas anteriores.
As atividades de GCS incluem:
· Identificar modificações;
· Controlar modificações;
· Garantir a implementação adequada das modificações;
· Relatar as modificações a outros que possam ter interesse.
Segundo Pressman (2006, p. 599), diferentemente da atividade de suporte de software, que ocorre depois que o software foi entregue ao cliente, a GCS é um conjunto de atividades de acompanhamento e controle que começam quando o projeto de engenharia de software tem início e só terminam quando o software é retirado de operação.
A Gerência de Configuração de Software tem especial importância na garantia da qualidade do software e no apoio a gestão de projetos, sendo imprescindível sua aplicação nas empresas que desejam obter a certificação do Capability Maturity Model Integration (CMMI) nível 2 ou na obtenção da certificação do modelo para Melhoria de Processo do Software Brasileiro (MPS-BR) nível F.
Segundo Pressman (2006 p. 606), o processo de gestão de configuração de software define uma série de tarefas que têm quatro objetivos principais:
· Identificar todos os itens de configuração;
· Gerir modificações em um ou mais destes itens;
· Facilitar a construção de diferentes versões de um mesmo produto;
· Garantir que a qualidade do software seja mantida a medida que a configuração evolui ao longo do tempo.
Para podermos entender como estas tarefas são executadas, devemos conhecer alguns conceitos que são fundamentais para a aplicação de GCS.
Diversos elementos são gerados como produto de um processo de software. Estes elementos podem ser:
· Programas de computador (tanto na forma de código fonte como executável);
· Documentos que podem descrever programas, procedimentos regras de negócio etc. (Documentação técnica e de usuário final);
· Estrutura de dados que podem estar contidos em programas ou externos a ele;
A este conjunto de elementos, que compreende toda a informação produzida no processo de software, chamamos de “Configuração de Software”.
Itens de Configuração de Software – ICS
Segundo Molinari (2007 p. 44), um item de configuração é o menor item de controle num processo de GCS.
Um item de configuração de Software (ICS) ou Software Configuration Item (SCI) é cada elemento criado durante o processo de engenharia de software, ou que para este processo seja necessário. Pode ser um arquivo, uma aplicação corporativa, uma parte de um documento, uma seqüência de casos de teste, um hardware ou um componente de programa. Além dos ICS´s gerados no processo de engenharia de software, também poderão ser considerados como ICS’s ferramentas de software como editores, compiladores, navegadores e outras ferramentas que forem necessárias à correta geração do software.
Os ICS’s são identificados de maneira única e podem estar relacionados a outros ICS’s e sua evolução é passível de rastreamento. O controle da Gerência de Configuração será feito sobre estes itens e serão mantidas todas as informações a seu respeito. Diversas versões de um mesmo ICS podem existir como produto das modificações efetuadas no dia-a-dia.
Molinari (2007 p. 44) faz uma analogia interessante ao conceito de classes em orientação a objetos (OO) quando diz que o item está para uma “classe” em OO assim como as versões deste item estão para as “instâncias” da classe em questão conforme mostrado na Figura 1.
Figura 1. Classes e instâncias de um item de configuração
Segundo Forte (1989 apud Pressman, 2006, p. 604), o repositório é o conjunto de mecanismos e estruturas que permite a uma equipe de software gerir modificação de modo efetivo. Fornece as funções óbvias de um sistema de gestão de banco de dados, mas, além disso executa ou propicia as seguintes funções:
· Integridade de dados – Valida entradas no repositório, garante consistência entre os ICS’s relacionados, executa modificações em cascata quando uma modificação em um objeto exige modificações em objetos a ele relacionados;
· Compartilhamento de informações – Fornece mecanismo para compartilhar a informação entre vários desenvolvedores e ferramentas, controla o acesso aos ICS’s por diferentes usuários através de política de bloqueio e desbloqueio de modo que as modificações não sejam sobrepostas umas as outras;
· Integração de ferramenta – Provê uma estrutura de dados que permite acesso à várias ferramentas de engenharia de software;
· Integração de dados – Fornece funções de banco de dados que permitem que várias tarefas de GCS sejam executadas em um ou mais ICS’s;
· Imposição de metodologia – Define um modelo entidade relacionamento que implica um modelo de processo especifico de engenharia de software. O relacionamento entre objetos definem um conjunto de passos a ser seguido para construir o conteúdo do repositório;
· Padronização de documentação – Normalização para a criação de documentos de engenharia de software.
Um repositório tem que ser capaz de manter ICS’s relacionados a diversas versões do software e ainda fornecer mecanismos para montar esses ICS’s em uma configuração especifica da versão, garantindo assim a gestão efetiva das entregas do produto e permitindo aos desenvolvedores voltar a versões anteriores. Precisa ser capaz de controlar variados tipos de ICS’s incluindo textos, gráficos, mapas de bits e outros mais complexos.
Além disso, o repositório deve ser capaz de guardar informações sobre baselines e pistas de auditoria com informações sobre quando, por que, e por quem as modificações foram feitas.
Estas informações são chamadas de metadados, e são definidas em um metamodelo que determina como as informações são armazenadas no repositório, como ter acesso a elas, como podem ser vistas pelos engenheiros de software, e como manter a sua integridade e segurança.
Além de manter as informações sobre os ICS’s, o repositório deve ser capaz de armazená-los fisicamente em um esquema de bibliotecas.
Os ICS’s são retirados e inseridos nos repositórios, através das seguintes operações:
· LOCK: Garante que apenas um usuário detém o acesso para alterar um determinado ICS. Apesar de resolver o problema de atualização simultânea, o lock serializa o trabalho dos desenvolvedores.
· CHECK-OUT: Recupera a última versão de um item de configuração guardado no repositório, copiando-o para a área de trabalho do desenvolvedor.
· CHECK-IN: Insere ou atualiza um item de configuração no repositório, incrementando a versão do ICS, e fazendo o registro das informações de mudança.
A identificação dos ICs é uma área de extrema importância dentro da Gerência de Configuração de Software. Sem uma identificação correta de um item, é impossível gerenciar este processo.
Cada ICS deve ser identificado através de características distintas que o caracterizam unicamente. Estas características podem ser um nome, uma descrição, uma lista de recursos etc. É necessário que cada organização defina suas convenções de identificação.
Baseline
Um baseline pode ser descrito como a situação de uma coleção de ICS’s similares em um momento especifico do ciclo de vida de um software que foram aprovados e armazenados em uma biblioteca controlada. Pode ser descrito também como a conexão de um ...
