Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Gerência de Configuração
Definições Iniciais, Ferramentas e Processo
Alberto Boller Filho
alberto.boller@gmail.com
Formado em Tecnólogo Análise de Sistemas pelo
Centro Universitário Instituto Metodista Bennet.
Possui mais de 30 anos de experiência em infor-
mática. Possui especialização em administração
de redes Linux Conectiva, segurança de redes
Linux Conectiva, administração de redes Windo-
ws NT e Windows Server 2003, programação de
aplicações cliente servidor avançada em Delphi,
programação RPGII, programação COBOL, System
Administrator NOTES, Application Development
NOTES. Atualmente é Gerente de informática na
clínica de diagnóstico por imagens “CEPEM “ Cen-
tro de Estudos e Pesquisa da Mulher”.
Rodrigo Oliveira Spínola
rodrigo@sqlmagazine.com.br
Doutorando e Mestre em Engenharia de Software
pela COPPE/UFRJ (avaliada como a melhor pós-
graduação em computação do país). Criador do
projeto e editor chefe da revista Engenharia de
Software Magazine. Autor de diversos artigos
científicos sobre Engenharia de Software publica-
dos em revistas e conferências renomadas, dentro
e fora do país. Experiência de participação em
diversos projetos de consultoria para diferentes
empresas tendo atuado com gerência de projetos,
requisitos e testes de software. Implementador
certificado do MPS.BR, tendo também experiência
atuando junto a empresas certificadas CMMI.
14 Engenharia de Software Magazine - Gerência de Configuração
Marcelo Nascimento Costa
mnc@kalisoftware.com
Mestre em Engenharia de Sistemas e Computação
pela COPPE/UFRJ (avaliada como a melhor pós-
graduação em computação do país). Bacharel em
Ciência da Computação pela UFPA. Professor dos
cursos de graduação em computação e adminis-
tração do Instituto Metodista Bennett. Autor de
diversos artigos científicos sobre Engenharia de
Software publicados em revistas e conferências
renomadas, dentro e fora do país.
Marcos Kalinowski
mk@kalisoftware.com
Doutorando e Mestre em Engenharia de Software
pela COPPE/UFRJ (avaliada como a melhor pós-
graduação em computação do país), com ênfase
em Validação, Verificação e Testes de Software e
Melhoria de Processos. Bacharel em Ciência da
Computação pela UFRJ. Professor do curso de pós-
graduação e-IS Expert da UFRJ e Coordenador do
curso de Engenharia da Computação da UVA RJ.
C
om um mercado cada vez mais
exigente, as empresas que fabri-
cam 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
De que se trata o artigo?
Neste artigo serão mostrados inicialmente aspectos
relevantes da gerência de configuração. Na segun-
da parte do artigo, será apresentada a aplicação da
gerência de configuração dentro dos principais mo-
delos 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 mate-
rial de apoio para aqueles que desejam implementar
gerência de configuração em uma organização de-
senvolvedora de software, usando como ferramen-
tas 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.
software voltadas para o controle tem
sido elaboradas uma vez que um pro-
jeto 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 en-
tidades 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 pes-
soal, 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 bi-
bliográfica sobre GCS, sua aplicação dentro dos modelos
de maturidade CMMI e MPS e uma solução especifica uti-
lizando 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.
Gerência de Configuração
Ao longo do ciclo de vida de um software, diversas modifi-
caçõ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.
PROJETO
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 au-
menta à medida que alterações são efetuadas sem uma analise
antes da sua execução, sem o registro formal antes da sua imple-
mentaçã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 diver-
sos 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 ativida-
de 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 impor-
tâ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 Integra-
tion (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:
Edição 24 - Engenharia de Software Magazine 15
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.
Configuração de Software
Diversos elementos são gerados como produto de um pro-
cesso de software. Estes elementos podem ser:
Programas de computador (tanto na forma de código fonte
como executável);
 Documentos que podem descrever programas, procedi-
mentos 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 in-
formaçã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 Con-
figuration 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 ras-
treamento. 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 con-
ceito 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.
Repositório
Segundo Forte (1989 apud Pressman, 2006, p. 604), o repo-
sitório é o conjunto de mecanismos e estruturas que per-
mite a uma equipe de software gerir modificação de modo
16 Engenharia de Software Magazine - Gerência de Configuração
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 mo-
dificaçõ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.
Figura 1. Classes e instâncias de um item de configuração
Um repositório tem que ser capaz de manter ICS’s relaciona-
dos a diversas versões do software e ainda fornecer mecanis-
mos 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.
Identificação de ICSÊs
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 item de configuração com um determinado
marco no projeto (milestone). Um baseline pode ser visto como
um conjunto de itens de configuração identificados e liberados
para uso, independente de suas versões.
É importante identificar e agrupar estes ICS’s dentro dos
baselines apropriados pois desta forma, cria-se uma estrutura
que facilita o rastreamento de mudanças à estes ICS’s.
Em cada fase do processo de desenvolvimento, um conjunto
bem definido de itens de configuração deve ser estabelecido.
Tal conjunto representa um estágio do desenvolvimento, o qual
é passível de modificações apenas mediante um mecanismo
formal de alterações. A este conjunto é dado o nome de base-
lines, ou configurações base do sistema.
Em princípio, baselines poderiam ser estabelecidas em qual-
quer ponto do desenvolvimento. Entretanto, a grande vanta-
gem do conceito está em se fazer coincidir o estabelecimento de
baselines com os finais de fase do ciclo de vida do produto.
O desenvolvimento com configurações base pode, então, ser
resumido nos seguintes pontos:
 Caracterização do ciclo de vida, identificando-se as fases
pelas quais o desenvolvimento do software irá passar;
Definição do conjunto de baselines, estabelecendo-se quais
serão os ICS’s que a irão compor;
Estabelecer o marco o qual a baseline irá representar. Uma
nova baseline é estabelecida no final de cada fase do ciclo de
vida do software;
PROJETO
Durante cada fase, a modificação de uma configuração-base
somente pode ser feita de forma controlada, mediante um
processo bem definido;
Ao ser estabelecida, cada baseline incorpora integralmente
a anterior.
 O estabelecimento de cada baseline somente é realizado
após ser aprovada por procedimentos de consistência interna,
verificação e validação;
Na Figura 2 vemos uma representação de baselines adaptada
de Molinari (2007, p 56).
Figura 2. Entendendo um baseline
Controle de Versão
Segundo Pressman (2006, p. 608), controle de versões
combina procedimentos e ferramentas para gerir diferentes
versões de objetos de configuração que são criados durante
o processo de software. Um sistema de controle de versão
implementa ou está diretamente integrado com quatro ca-
pacidades principais:
 Um banco de dados de projeto (repositório) que guarda
todos os objetos de configuração relevantes;
Uma capacidade de gestão de versão que guarda todas as
versões de um objeto de configuração;
Uma facilidade de construir que permite ao engenheiro de
software coletar todos os objetos de configuração relevantes
e construir uma versão especifica do software;
Capacidade de acompanhamento de tópicos (também cha-
mado de acompanhamento de bugs).
Segundo Molinari (2007, p. 168), alguns colocam que a prin-
cipal missão de um sistema de controle de versões é permitir
a edição colaborativa e o compartilhamento de dados, outros
dizem que o sistema de controle de versões rastreia e controla
todos os artefatos do projeto e desse modo consegue coorde-
nar o trabalho paralelo de desenvolvedores.
Ainda segundo Molinari (2007, p.168), independente do que
cada um pensa sobre controle de versões, algumas das suas
características perceptíveis são:
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 de maneira simultânea;
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.
Edição 24 - Engenharia de Software Magazine 17
 O sistema de controle de versões é o responsável por manter
as diversas versões dos ICS’s e faz isso através de um esquema
de arquivos e diretórios presentes no repositório, registrando
não só as alterações realizadas em cada arquivo mas também
na estrutura do diretório em si.
O repositório evolui, junto com o projeto guardando as múlti-
plas versões que o compõe organizadas em forma de revisões.
As revisões são as situações estáticas de todos os arquivos do
projeto em um determinado instante de tempo.
Em empresas de grande porte, onde existem vários profissio-
nais trabalhando concorrentemente nos mesmos arquivos, faz-se
necessário uma política para ordenar e integrar estas alterações,
a fim de evitar a perda de um trabalho ocasionada quando uma
pessoa sobrescreve o trabalho de outra.
Os sistemas de controle de versão implementam esta política,
assegurando que os desenvolvedores não trabalhem diretamen-
te nos arquivos do repositório, mas sim em cópias de trabalho
destes arquivos em suas próprias máquinas. Isto permite que
um desenvolvedor faça seu trabalho de forma independente e
sem interferir no trabalho de outro. Após terminado o trabalho,
o arquivo deve ser colocado novamente no repositório e para que
alterações não sejam inadvertidamente sobrepostas, o sistema
de controle de versões pode fazer uso das seguintes políticas
de versionamento:
Trava-Modifica-Destrava: Apenas uma pessoa por vez detém
o direito de alterar um determinado arquivo. O sistema trava o
arquivo quando uma pessoa retira uma cópia para manutenção
e só libera a cópia para edição à outra pessoa, quando a primeira
publica sua nova versão. Esta política é limitada e pode causar
problemas administrativos e forçar a serialização do trabalho,
entretanto, é a solução indicada para organizações que neces-
sitam de um alto grau de formalização.
Copia-Modifica-Resolve: Não utiliza travamento de arquivos.
Nesta política, cada desenvolvedor trabalha de forma indepen-
dente em sua cópia de trabalho, e ao final, as alterações são
mescladas no repositório, formando a versão final. Esta política
pode parecer caótica, mas na prática funciona bem, devido ao
baixo índice de conflitos. Os conflitos são causados na maioria
das vezes, por falta de comunicação entre os desenvolvedores.
Branch
Branching (ou ramificação em português) é uma parte funda-
mental do controle de versões. O conceito de branching reside
em se iniciar uma nova linha de desenvolvimento em paralelo
à uma principal já existente.
Esta técnica é extremamente útil em situações onde temos
que fazer grandes alterações em objetos de configuração e que
provavelmente levarão muito tempo, sem contudo afetar a linha
principal de manutenção do sistema. Nesta situação, cria-se uma
segunda cópia do objeto em questão e trabalha-se em paralelo
à linha principal. Ao longo do tempo, as manutenções feitas na
linha principal poderão ser incorporadas na ramificação para
que defeitos encontrados na cópia original possam ser conser-
tados também na ramificação. A Figura 3 demonstra como é a
técnica de branching ao longo do tempo.
18 Engenharia de Software Magazine - Gerência de Configuração
Figura 3. Branch de desenvolvimento
Merge
Em projetos onde existe um grande número de pessoas en-
volvidas, é comum que elas possuam uma cópia de trabalho da
linha principal de desenvolvimento. Neste contexto, o conceito
de merge é também uma parte fundamental do controle de
versões. O Merge faz a fusão de dois arquivos que estão sendo
alterados simultaneamente por desenvolvedores diferentes
garantindo que a versão final contenha todas as alterações.
Quando isso não é possível, mantém apenas a última versão
guardada e emite uma mensagem de “arquivo fora de data”
para que as diferenças sejam resolvidas com intervenção
humana. Em alterações demoradas, onde normalmente é
utilizada a técnica de branch, é recomendável que se façam
merges, periodicamente entre a linha principal e a ramificação,
para que no final não fique inviável fazer o merge devido ao
grande número de conflitos gerados entre as diferenças das
diversas versões.
Tags
Um outro tipo de controle de versão são as tags. Tags são
como fotografias de um projeto, em um determinado instante
do tempo. São rótulos associados a um conjunto de arquivos
usados para denominar um projeto ou uma nova versão, e que
rotulam estes arquivos. As tags nas versões de um conjunto
de itens de configuração, existente em diversos sistemas de
controle de versões, pode ser utilizado para implementar o
conceito de baseline.
Controle de Modificação
Mudanças são inevitáveis. Todo produto de software sofre
mudanças durante o seu ciclo de vida, seja por erro de cons-
trução, ou por necessidade de mudanças solicitadas pelos
clientes. Em projetos de grande porte, fazer modificações sem
um esquema formal de controle pode levar ao caos. Alguns
dos problemas que podem ser causados em projetos devido a
mudanças não controladas são:
Aumento do custo do projeto;
Atrasos em entregas planejadas;
Impacto em outros objetos de configuração;
Degradação da qualidade do software;
Retrabalho.
Controle de modificações podem incluir procedimentos
humanos e também o uso de ferramentas automatizadas, e

seu objetivo é controlar estas mudanças e manter informações
sobre os pedidos de mudança, nos produtos e as implementa-
ções realizadas em função destas mudanças.
Informações do tipo quem, quando, por que e o que foi mu-
dado, em um item de configuração, são guardadas para que
seja possível haver uma rastreabilidade entre suas versões
anteriores e posteriores.
O processo de controle de mudanças começa quando o clien-
te emite um pedido de comunicação. Este pedido passa pela
análise de uma Comissão de Controle de Modificações (do
inglês Change Control Board – CCB), que é responsável pela
sua aprovação ou não. É gerada então uma ordem de modifi-
cação de engenharia (Engineering Change Order – ECO) pra as
modificações aprovadas. O ICS é retirado do repositório para
uma área de trabalho exclusiva do profissional, que irá executar
as mudanças. As mudanças são executadas, as atividades de
SQA são aplicadas, e os ICS’s modificados são introduzidos
no repositório com os mecanismos adequados de controle
de versão. Controles para acesso aos ICS’s pelos engenheiros
e controles de sincronização de modificações paralelas por
pessoas diferentes são usados nesta etapa.
A Figura 4 esboça o processo formal de controle de modifi-
cações segundo Pressman (2006, p 610).
Figura 4. Processo de controle de modificações (Pressman, 2006)
Auditoria de Configuração
Além dos controles de identificação, versão e modificação
vistos anteriormente, precisamos implementar algum mecanis-
mo que nos garanta que as modificações foram feitas de forma
adequada. Este mecanismo envolve dois aspectos:
PROJETO
Revisões técnicas formais;
Auditoria de configuração de software.
A revisão técnica tem como foco a correção técnica do ICS
que foi modificado a partir de uma requisição. Revisores
avaliam o ICS para determinar se o mesmo é consistente.
Revisões técnicas formais normalmente são feitas para todas
as modificações, exceto as mais triviais.
A auditoria de configuração de software tem como objetivo
complementar a revisão técnica formal e trata dos seguintes
aspectos:
Verifica se a modificação técnica especificada foi realizada e
se foi incorporada alguma modificação adicional;
Verifica se uma revisão técnica formal foi feita para avaliar
a correção técnica;
Verifica se o processo de software foi seguido;
Verifica se constam anotados no ICS modificado, dados de
rastreabilidade tais como data da modificação, autor, nº de
requisição etc.;
Verifica se os procedimentos de GCS para registrar e relatar
a modificação, foram seguidos;
Verifica se todos os ICS’s relacionados foram atualizados de
forma adequada.
Quando a GCS é uma atividade formal, a auditoria de confi-
guração é conduzida pelo grupo responsável pela garantia de
qualidade. A auditoria também tem como objetivo garantir que
os ICS’s corretos foram incorporados em um build específico e
que sua documentação está consistente com a nova versão.
Relatórios de Estado
Os relatórios de estado é uma tarefa de GCS que tem por
objetivo responder às seguintes questões:
O que aconteceu ?
Quem fez ?
Quando aconteceu ?
O que mais será afetado ?
O relatório de estado reúne informações de todos os estágios
da GCS. Atividades como identificação de ICS’s, aprovação de
modificações, resultado das auditorias de configuração são
registradas no relatório de estado. O relatório de estado deve
ser colocado em um banco de dados de maneira que todas
as pessoas envolvidas na manutenção de software tenham
acesso as informações ali contidas. O principal objetivo de
um relatório de estado é manter a gerência e os profissionais
informados das modificações sofridas por um software, de-
vendo ser gerado regularmente.
Ferramentas de Apoio à GCS
Existem diversas ferramentas disponíveis no mercado para
apoiar a Gerência de Configuração de Sistemas. As funciona-
lidades, documentação, o suporte disponível e popularidade
variam bastante. As ferramentas comerciais apresentam
maior número de funcionalidades mas tem um alto custo. As
Edição 24 - Engenharia de Software Magazine 19
ferramentas open source além de baixo custo, também apre-
sentam vantagens como qualidade e segurança. A Tabela 1
apresenta algumas ferramentas e suas aplicações.
Tipo de ferramenta Nome
Controle de Versão CVS
SubVersion
Controle de mudança Mantis
Bugzilla
Integração (Build) Scons
Tabela 1. &ERRAMENTASPARA'#3
CVS
O CVS, ou Concurrent Version System (Sistema de Versões
Concorrentes), é um sistema de controle de versão open source,
que permite que se trabalhe com diversas versões de arquivos
organizados em um diretório e localizados local ou remota-
mente, mantendo-se suas versões antigas e os logs de quem e
quando manipulou os arquivos.
É especialmente útil para se controlar versões de um software
durante seu desenvolvimento, ou para composição colaborativa
de um documento.
O CVS utiliza uma arquitetura cliente-servidor: um servidor
armazena as versões atuais do projeto e seu histórico, e os clien-
tes se conectam a esse servidor para obter uma cópia completa
do projeto, trabalhar nessa cópia e então devolver suas modifica-
ções. Tipicamente, cliente e servidor devem estar conectados por
uma rede local de computadores, ou pela internet, mas o cliente
e o servidor podem estar na mesma máquina se a configuração
do CVS for feita de maneira a dar acesso a versões e histórico
do projeto apenas a usuários locais.
O CVS possui limitações tais como:
 Os arquivos em um repositório CVS não podem ser re-
nomeados, eles devem ser explicitamente removidos e re-
adicionados;
O protocolo do CVS não permite que os diretórios sejam mo-
vidos ou renomeados. Cada arquivo do subdiretório em questão
deve ser individualmente removido e re-adicionado;
 Não permite “lock” (permite que dois usuários alterem o
mesmo arquivo ao mesmo tempo) e em alguns casos pode ser
mais custoso resolver o conflito do que evitar que ele ocorra.
Subversion
Subversion (também conhecido por SVN, o nome da sua ferra-
menta de linha de comando) é um sistema de controle de versão
open source projetado especificamente para ser um substituto
moderno do CVS, que se considera ter algumas limitações.
O Subversion é bem conhecido na comunidade que utiliza
código aberto e é utilizado em diversos projetos incluindo
Apache Software Foundation, KDE, Free Pascal, FreeBSD, GCC
Python, Django, Ruby, Mono, SourceForge.net, ExtJS e Tigris.org.
O Google Code também faz a hospedagem de seus projetos de
código aberto utilizando o Subversion.
O Subversion também é adotado no mundo corporativo.
Em 2007, a Forrest Research reportou que o Subversion foi
20 Engenharia de Software Magazine - Gerência de Configuração
reconhecido como sendo líder isolado na categoria Standalone
Software Configuration Manager (SSCM) tendo uma forte
atuação na categoria Software Configuration and Change
Management (SCCM).
O Subversion começou a ser escrito no ano 2000 como um
esforço para criar um sistema de controle de versão o qual
operasse de forma parecida com o CVS porém sem os seus
problemas, e suprindo as facilidades não existentes no CVS. No
ano de 2001, o Subversion já estava suficientemente desenvol-
vido para ser capaz de hospedar seu próprio código fonte.
Algumas de suas facilidades são:
Operações de “Commit” são atômicas. Interrupções nestas
operações não causam inconsistências no repositório;
Mudanças de nomes, cópias, e movimentações de arquivos
são guardadas como histórico de revisões;
Mudanças de nomes em diretórios são guardados também
como versões. Árvores de diretórios inteiras podem ser movi-
das ou copiadas com rapidez e tem estas operações guardadas
no histórico de revisões;
Servidor Apache HTTP como servidor de rede;
Operações de Branch e Tag são menos custosas, independente
do tamanho do arquivo. O Subversion não faz distinção entre
Tag, Branch e um diretório;
Permite operações de “lock” para arquivos que não podem
ser fundidos (sofrer operação de “merge”).
Mantis
Mantis é um sistema de controle de mudança open source,
baseado em Web, bastante popular. Foi escrito em linguagem
PHP e trabalha com banco de dados MySQL, MS SQL e Pos-
tgreSQL e um webserver. Pode ser instalado em Windows,
Linux, Mac OS, OS/2 e outros e funciona na maioria dos web
browsers como um cliente.
Algumas de suas características são:
É um software livre (licença GPL);
Fácil de instalar;
Fácil de avaliar;
É baseado em Web;
Suporta qualquer plataforma que roda PHP;
Suporta múltiplos projetos por instancia;
Suporte para Projetos, Sub-projetos e categorias;
Suporte a diferentes níveis de acesso de usuário por projetos;
Suporta log de mudanças;
Possui diversos relatórios e gráficos;
Usuários podem monitorar as solicitações;
Envio de notificações por e-mail;
Permite histórico de mudanças;
Integração com SVN e CVS.
Bugzzila
Bugzilla é uma ferramenta baseada em Web e e-mail, que dá
suporte ao desenvolvimento do projeto Mozilla, rastreando
defeitos de software, e servindo também como plataforma
para solicitações e controle de mudanças. Como projeto de
software livre, é mantido por voluntários, sendo utilizado

por diversos outros projetos e empresas. Algumas de suas
características são:
Capacidade de pesquisa avançada;
 Notificações por e-mail controladas pelas preferências de
usuários;
Lista de defeitos em diversos formatos;
Relatórios periódicos (diários, semanais etc.) enviados por
e-mail;
Controle de tempo de execução de uma solicitação;
Sistema de atribuição de tarefas;
 Diversas versões de localização (incluindo Português
– Brasil).
SCons
SCons é uma ferramenta de construção de software open
source escrita em Python. O SCons provê uma ponte entre
plataformas e é o substituto para o utilitário clássico Make com
funcionalidades similares ao autoconf/automake, e possui com-
piladores integrados. Algumas de suas características são:
Seus arquivos de configuração são scripts Python;
Analise automática de dependências, nativa para C, C++ e
Fortran, extensível para outras linguagens;
Suporte nativo para adquirir arquivos fonte do CVS;
Suporte nativo ao MS Visual Studio .NET
 Detecção de mudanças de construção usando assinaturas
baseadas em MD5.
Gerência de configuração nos modelos de maturidade
A partir dos anos 90, iniciou-se um movimento no sentido de
solucionar problemas que afetavam a industria de software.
Problemas como descumprimento de prazos, estouro de or-
çamentos, falta de funcionalidades requeridas pelos clientes e
outros, afetavam de maneira drástica a qualidade dos produtos
de software produzidos nesta época.
A maioria destes problemas originavam-se do fato da cons-
trução de software ser conduzida utilizando-se processos
improvisados e pouco ou nada controlados. Sendo assim,
vários órgãos e associações começaram a criar modelos que
orientassem o desenvolvimento destes produtos.
Embora hoje existam diversos modelos de maturidade
voltados para o desenvolvimento de software objetivando
aumentar a produtividade da construção e a sua qualidade,
todos incluem a utilização de práticas de GCS que variam de
acordo com cada modelo.
Neste artigo será apresentado os pontos em comum da apli-
cação da GCS nos modelos CMMI, e MPS.BR.
GCS aplicada no CMMI
O CMMI (Capability Maturity Model Integration) tem como
objetivo prover um modelo de maturidade para desenvolvi-
mento de produtos e serviços de uma maneira geral. Ele aponta
práticas que cobrem o ciclo de vida dos produtos desde a sua
concepção até a entrega e manutenção. A versão 1.0 foi publi-
cado em 2000 em substituição ao CMM (Capability Maturity
Model) Versão 1.1, criado pela SEI (Software Engineering
PROJETO
Institute) na Carnegie Mellon University a pedido do Depar-
tamento de defesa dos EUA que necessitava de um modelo
para avaliar os seus fornecedores de software. A versão 1.1
foi publicada em 2002 e a atual, versão 1.2 , foi publicada em
agosto de 2006.
A missão inicial da equipe que produziu o CMMI era com-
binar três modelos:
Capability Maturity Model for Software (SW-CMM) v. 2.0
draft C
Systems Engineering Capability Model (SECM)
Integrated Product Development Capability Maturity Model
(IPD-CMM) v. 0.98
O CMMI permite abordar a avaliação e o melhoramento de
processos utilizando dois tipos de representação: contínua e
por estágio.
A representação contínua permite a uma organização sele-
cionar áreas de processo e melhorar os processos relacionados
a ela. Nesta representação, são utilizados níveis de capacidade
para caracterizar os melhoramentos relativos a uma área de
processo individual.
A representação por estágios usa um conjunto pré-definido
de áreas de processo para definir uma via de melhoramento
para uma organização. Esta via de melhoramento é carac-
terizada por níveis de maturidade. Cada nível fornece um
conjunto de áreas de processo que caracterizam diferentes
comportamentos organizacionais.
A Figura 5 mostra uma visão geral por estágio dos níveis de
maturidade e as áreas de processo envolvidas. Podemos notar
na figura que a Gestão de Configuração de Software é uma
área de processo do nível 2 do modelo de maturidade.
Segundo o CMMI-DEV (2006, p.114), o propósito da Gestão
de Configuração de software (GCS) é estabelecer e manter a
integridade dos produtos de trabalho, usando identificação da
configuração, controle de configuração, status da configuração
contábil e auditoria de configuração.
As metas e práticas especificas da gestão de configuração
definidas na CMMI são:
SG 1. Estabelecer baselines.
SP 1.1 Identificar itens de configuração
SP 1.2 Estabelecer um Sistema de Gestão de Configuração
SP 1.3 Criar ou liberar baselines
SG 2. Rastrear e controlar mudanças
SP 2.1 Rastrear requisição de mudanças
SP 2.2 Controlar itens de configuração
SG 3. Estabelecer integridade
SP 3.1 Estabelecer registros de Gerencia da Configuração
SP 3.2 Realizar auditorias de configuração
GCS aplicada no MPS
O programa MPS.BR (Melhoria de Processo do Software
Brasileiro) foi criado em 2003 pela SOFTEX (Associação para
Promoção da Excelência do Software Brasileiro). O MPS.BR
tem o apoio do Ministério de Ciência e Tecnologia (MCT)
da Financiadora de Estudos e Projetos (FINEP) e do Banco
Edição 24 - Engenharia de Software Magazine 21
 Figura 5. Visão por nível de maturidade X Áreas de processo
Interamericano de Desenvolvimento (BID). Sua estrutura está
dividida em duas áreas de apoio:
• Fórum de Credenciamento Controle (FCC) cujas atribui-
ções são:
I. Emitir parecer que subsidie decisão da SOFTEX sobre o
credenciamento de Instituições Implementadoras (II) e Ins-
tituições Avaliadoras (IA);
II. Monitorar os resultados das Instituições Implementa-
doras (II) e Instituições Avaliadoras (IA), emitindo parecer
propondo à SOFTEX o seu descredenciamento no caso de
comprometimento da credibilidade do modelo MPS.
• Equipe Técnica do Modelo (ETM) cuja atribuição é apoiar a
SOFTEX sobre os aspectos técnicos relacionados ao Modelo
de Referência (MR-MPS) e Métodos de Avaliação (MA-MPS)
para:
I. Criação e aprimoramento contínuo do MR-MPS, MA-MPS
e seus guias específicos;
II. Capacitação de pessoas por meio de cursos, provas e
workshops.
22 Engenharia de Software Magazine - Gerência de Configuração
Este modelo surgiu pelo fato de muitas empresas ao busca-
rem certificação CMM/CMMI se depararem com os custos
elevados de implementação/avaliação, inviabilizando as
certificações para pequenas empresas.
Uma das metas do programa MPS.BR é definir e aprimorar
um modelo de melhoria e avaliação de processo de software
visando preferencialmente às micro, pequenas e médias em-
presas, de forma a atender as suas necessidades de negócio
e ser reconhecido nacional e internacionalmente como um
modelo aplicável à indústria de software.
A base técnica para a construção e aprimoramento deste
modelo de melhoria e avaliação de processo de software é
composta pelas normas ISO/IEC 12207:2008 [ISO/IEC, 2008a]
e ISO/IEC 15504-2 [ISO/IEC, 2003]. O MPR.BR se propõe ser
compatível com o modelo CMM/CMMI para software.
Na Figura 6 temos uma visão geral dos principais compo-
nentes MPS.BR.
O Modelo de Referência, MR-MPS, define níveis de ma-
turidade que são uma combinação entre processos e sua

capacidade. Para cada nível de maturidade são estabelecidos
processos que caracterizam estágios de melhoria da imple-
mentação de processos na organização. O MR-MPS define sete
níveis de maturidade:
A (Em Otimização);
B (Gerenciado Quantitativamente);
C (Definido);
D (Largamente Definido);
E (Parcialmente Definido);
F (Gerenciado);
G (Parcialmente Gerenciado).
Figura 6. Visão geral dos componentes do MPS.BR
O primeiro nível da escala é o “G” e o último o “A”. A
Tabela 2 mostra os processos exigidos para cada nível de
maturidade.
Segundo definição do MPS.BR Guia de Implementação (2009,
p. 16), o propósito do processo de Gerência de Configuração
é estabelecer e manter a integridade de todos os produtos de
trabalho de um processo ou projeto e disponibilizá-los a todos
os envolvidos. A GCS é encarada pelo MPS.BR como sendo
um processo do nível de maturidade “F” e portanto deve ter
resultados esperados. Os resultados esperados da GCS são:
GCO1 - Um Sistema de Gerência de Configuração é esta-
belecido e Mantido;
GCO2 - Os itens de configuração são identificados com base
em critérios estabelecidos;
 GCO3 - Os itens de configuração sujeitos a um controle
formal são colocados sob baseline;
GCO4 - A situação dos itens de configuração e das baselines
é registrada ao longo do tempo e disponibilizada;
 GCO5 - Modificações em itens de configuração são
controladas;
GCO 6 - O armazenamento, o manuseio e a liberação de itens
de configuração e baselines são controlados consistentes;
GCO7 - Auditorias de configuração são realizadas objeti-
vamente para assegurar que as baselines e os itens de confi-
guração estejam íntegros, completos e consistentes.
Nesta parte do artigo foi mostrado onde a Gerência de confi-
guração de Software se encaixa nos dois dos principais modelos
de maturidade de software usados por em presas brasileiras. Na
próxima seção do artigo será apresentado um estudo de caso
de aplicação de GCS em uma empresa de desenvolvimento de
PROJETO
software utilizando-se das ferramentas Mantis para controle de
modificações e Subversion para controle de versões.
Nivel Processos
A
B Gerência de Projetos – GPR (evolução)
C Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
D Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
E Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
F Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
G Gerência de Requisitos – GRE
Gerência de Projetos – GPR
Tabela 2. Níveis de Maturidade do MR-MPS
Estudo de caso de uma implementação de GCS com
Mantis e Subversion
A partir de agora será apresentado um estudo de caso de
implementação de práticas de GCS com as ferramentas Mantis
e Subversion em uma empresa de construção de software de
pequeno porte. A esta empresa, daremos o nome fictício de
“Casa do Software”.
Cenário
A empresa “Casa do Software” é uma empresa de pequeno porte
e conta com trinta e cinco colaboradores. A empresa desenvolve
softwares voltados para áreas comerciais de outras empresas
utilizados por vendedores em seus notebooks nas visitas a seus
clientes. A empresa não possui uma política de GCS implementa-
da. Existe apenas uma rotina periódica de back-ups que fica sob
responsabilidade do pessoal de suporte de infra-estrutura.
As solicitações de modificações são feitas pelos clientes
através de reuniões realizadas com o gerente de projetos e
desenvolvedores. A única documentação existente sobre as
solicitações são as atas das reuniões, não havendo documen-
tação de acompanhamento da manutenção e aprovação formal
das mesmas por parte da gerência de projetos. Existe mais
de uma versão do mesmo sistema, como conseqüência de
alterações feitas especificamente para determinados clientes,
o que complica ainda mais a manutenção dos produtos de
software. Como a empresa está em franca expansão, fica clara
a necessidade de se implementar práticas de GCS que possam
Edição 24 - Engenharia de Software Magazine 23
contribuir para melhorar a qualidade de software da mesma, Nas seções seguintes mostraremos um PGC para esta em-
além disso, as práticas de GCS adotadas deverão estar em presa com base em pesquisa nos trabalhos de Borges (2006),
conformidade com o MPS-BR. Barbosa (2007), Neto(2005).
Como nesta empresa não existe a prática de GCS, será ne-
cessário a realização de treinamentos para que os diversos
colaboradores envolvidos no processo de implementação de
tais práticas e também aqueles que irão fazer uso dela possam
compreender o novo processo e utilizá-lo conforme definido
no Plano de Gerência de Configuração.
Como projeto piloto, foi selecionado o SISVEN (Sistema de
Vendas). O SISVEN é um sistema feito em Java destinado a
tirar pedidos de vendas, fazer prospecção de clientes e roda
em notebooks utilizados por vendedores que visitam clientes
em todo o país.

Plano para implementação da GCS na empresa

Devido ao tamanho da empresa e da pouca experiência do
pessoal envolvido, será implantada a GCS sob a perspectiva
de desenvolvimento, a qual abrange os sistemas de Controle
Figura 7. &LUXODO0LANODE)MPLEMENTA¥ÎODA'#3NAEMPRESA
de Modificações, Controle de Versões e Gerenciamento da
Construção. Histórico das Revisões
Embora a implementação seja feita sob esta perspectiva, as As tabelas apresentadas nas Tabelas 3 e 4 deverão ser altera-
funções da perspectiva gerencial podem ser implementadas das sempre que alguma modificação for feita no PGC.
por estes três sistemas acrescendo-se procedimentos manuais.
Neste artigo apresentaremos uma solução baseada em Mantis Data Versão Descrição Autor
para o “Controle de modificações”, e Subversion para o “Con- 05/07/2009 1.0 Criação da primeira versão Alberto Boller
trole de Versões”. O “Gerenciamento de construção” feito por
um sistema automatizado não será tratado neste trabalho. Na
Figura 7 podemos ver o fluxo do Plano para implementação da
GCS na empresa.

Criação da Equipe de Gerência de Configuração (EGC) Tabela 3. (ISTØRICODAS2EVISÜES

A Equipe de Gerência de Configuração (EGC) será composta
por um gerente de configuração, um gerente de projetos e por Data Versão Nome Cargo
uma pessoa de infra-estrutura. 05/07/2009 1.0 Alberto Boller Filho Gerente de Projetos
A responsabilidade deste grupo é procurar melhorar de for-
ma constante as atividades de GCS definidas para a empresa,
seja mudando processos ou incluindo novas ferramentas.

Criação do Comitê de Controle de Configuração (CCC) Tabela 4 . Aprovações

O Comitê de Controle de Configuração (CCC) será com-
posto pelo gerente de projetos e o Gerente de Qualidade. A
responsabilidade do CCC será avaliar se uma determinada
modificação deve ser implementada, rejeitada ou posterga-
da, baseando-se em análises de impacto que tal modificação
irá causar.
Criação do Plano de Gerência de Configuração (PGC)
O Plano de Gerência de Configuração (PGC) define formal-
mente os padrões e práticas adotadas pela empresa no que
tange à GCS. Neste documento estão descritos os procedi-
mentos a serem seguidos, as ferramentas a serem utilizadas,
os ICS’s que deverão estar sob controle da GCS, sua forma de
identificação e todas as diretrizes que qualquer sistema deverá
seguir dentro da empresa.
Histórico das Revisões
Aprovações
Identificação dos ICS’s
Os itens de configuração, os níveis de controle exigidos e
os identificadores para cada um encontram-se descritos na
Tabela 5. Outros itens também poderiam ser controlados
mas para exemplificar este estudo de caso, os itens constan-
tes nesta tabela são suficientes.
Regras para nomeação dos itens de configuração
Com exceção do Plano de Gerencia de Configuração,
Fontes e Executáveis, o nome dos artefatos deverá seguir
a seguinte regra:

24 Engenharia de Software Magazine - Gerência de Configuração

 PROJETO

<SISVEN>-<identificador_do_artefato>-<xxx> Armazenamento dos ICS’s

Todos os ICS’s especificados na Tabela 5 serão armaze-
Onde <xxx> é um número sequencial começando em 001. nados em um repositório do Subvesion em um servidor de
arquivos que poderá ser acessado via Internet ou através
Descrição Identificador Nível de Controle da rede local. A estrutura do diretório do repositório para
Casos de uso UC Versão e mudança armazenamento do sistema SISVEN pode ser visto na
Diagrama de Classes DC Versão e Mudança Figura 8.
Documento de Requisitos DR Versão e Mudança
Plano de Testes PTES Versão e Mudança
Plano de Gerencia de Configuração - Versão e Mudança
Código Fonte - Versão e Mudança
Release - Versão e Mudança

Tabela 5. )TENSDE#ONFIGURA¥ÎO

Regras para versionamento

As regras de versionamento serão aplicadas apenas nas
identificações de tags e branches, uma vez que o Subver-
sion controla as versões de itens de configuração a cada
operação de commit.
O padrão de versionamento utilizará a regra descrita a
seguir:
<XX>.<YY>
onde:
XX é um número decimal que representa a versão;
YY é um número decimal que representa a modificação.
O primeiro numero de versão deverá ser 01.00. A cada mo-
dificação, o valor YY deve ser incrementado de uma unidade
e retorna para 00 assim que uma nova versão é gerada.
Identificação de Tags
Sempre que uma nova baseline for criada, esta deverá ser
identificada por uma tag seguindo as seguintes regras:
Baseline de Documentos
DOC-V-<versão>
Baseline de Código Fonte
FONTE-V-<versão>
Baseline de Releases
RELEASE-V-<versão>
Onde <versão> segue as regras descritas no item anterior.
Identificação de Branches
Sempre que houver necessidade de criação de um branch, sua
identificação deverá obedecer aos seguintes padrões:
Branch de Documentos
DOC-MANUT-<número_da_solicitação_de_modificação>
Branch de Código Fonte
FONTE-MANUT-< número_da_solicitação_de_modificação>
Branch de Releases
RELEASE-MANUT-< número_da_solicitação_de_modificação>
O <número_da_solicitação_de_modificação> será aquele atri-
buído pelo campo ticket do Mantis conforme veremos adiante.
Figura 8. Estrutura de diretório do repositório
Gerenciamento de Baselines
Sempre que uma modificação for concluída, seja em algum
documento ou código fonte e o gerente de projetos tiver
inspecionado os testes e aprovado, o desenvolvedor poderá
solicitar ao gerente de configuração a criação de uma base-
line. As baselines ficarão armazenadas na subpasta “tag”
da estrutura de diretório do repositório.
Os branches deverão ser criados pelo gerente de configu-
ração apenas quando a modificação exigida pela solicitação
de mudança levar um tempo para sua conclusão superior
a três semanas, caso contrário será feita na mainline cuja
subpasta da estrutura de diretório chama-se “trunk” (ver
Figura 8).
Apenas o gerente de configuração terá autoridade para
criar branches e tags e deverá fazê-lo mediante a solicitação
formal do gerente de projeto que deverá enviar um e-mail
especificando o que e para quem deve ser criado.
Estabelecimento de um sistema de GCS
Conforme descrito no MPS.BR Guia de Implementação
(SOFTEX, 2009, p. 20), para que a Gerência de Configu-
ração ocorra de forma sistemática, é necessário que seja
estabelecido um sistema de Gerência de Configuração. Esse
sistema pode ser decomposto em três subsistemas: sistema
de controle de versões, sistema de controle de modificações
e sistema de gerenciamento de construção.
Para o subsistema de controle de modificações, utiliza-
remos a ferramenta Mantis. A escolha desta ferramenta
está apoiada no fato de ser open source (o que diminui os
custos), por ter integração direta com o Subversion (o que
permite dar visibilidade ao processo), e ser uma aplicação.

Edição 24 - Engenharia de Software Magazine 25

A Figura 9 ilustra o fluxo básico de controle de modificações produto TortoiseSVN que faz a mesma coisa só que de forma
que será seguido quando uma solicitação de modificação interativa e visual facilitando o trabalho.
for feita pelo usuário.

Figura 10. Tela de login do Mantis

Figura 9.&LUXODO#ONTROLEDEMODIFICA¥ÜESDAEMPRESAh#ASADO3OFTWAREv Figura 11. Visão inicial dos status de solicitações de mudanças

Nas Figuras 10 a 14 podemos visualizar como o Mantis

trata o controle de uma solicitação de modificações. Na
Figura 10 observamos que existe um controle de acesso
às solicitações a nível de tipo de usuário que pode ser um
relator, desenvolvedor, gerente administrador etc, cada qual
com suas restrições de acesso.
Na Figura 11 temos uma visão (a nível de usuário) das diver-
sas solicitações e seus status. Nas Figuras 12 a 14 aparece em
detalhes todos os tramites pelos quais passou uma solicitação
de mudanças, permitindo manter informado o usuário solici-
tante e todos os outros envolvidos no processo de GCS.
Para o subsistema de controle de versões, será utilizado o
Subversion. A escolha desta ferramenta também está baseada
no fato de ser open source, ter integração com o Mantis e com Figura 12. 6ISÎODETALHADADEUMASOLICITA¥ÎODEMUDAN¥A)NFORMA¥ÜES
o Eclipse. O Subversion possui uma parte server que roda em gerais)
um servidor e que fica responsável por fazer as operações de
check-in, check-out, controle de lock, merge, controle de acesso Na Figura 15 é apresentado um fluxo básico de utilização
e outras. O Subversion possui também uma parte client, que do Subversion.
roda na máquina do desenvolvedor e que tem a função de Nas Figuras 16 a 23 são apresentados exemplos das funções
solicitar à parte server as funções necessárias. Como a parte descritas na Figura 15 usando-se o TortoiseSVN.
client do Subversion é executada em linha de comando, e por As Figuras 16 e 17 mostram que o desenvolvedor deve fazer
esta razão ser pouco amigável, iremos utilizar como client o uma cópia dos ICS’s do repositório para seu disco local a fim

26 Engenharia de Software Magazine - Gerência de Configuração

 PROJETO

de poder fazer as modificações necessárias utilizando-se da

operação de check-out. A Figura 18 mostra que novos itens de
configuração são adicionados à cópia local do repositório atra-
vés de operação de add. A Figura 19 mostra uma operação de
update para atualizar a cópia local do repositório. As Figuras 20
à 22 mostram uma atualização da mainline através de uma
operação de commit. Vale observar neste ultimo caso que esta
operação é controlada com autenticação de usuário e senha.
Por fim, a Figura 23 mostra um log com todas as operações
executadas neste repositório ao longo do tempo.
Através das figuras vistas pode-se concluir que o Subversion
Figura 16. &AZENDOCHECK OUT
controla de forma adequada o armazenamento e manuseio de
ICS’s, fornecendo dados para sua auditoria.

Figura 17. Resultado da operação de check-out

Figura 13. Visão detalhada de uma solicitação de mudanças (Anotações)

Figura 18. Adicionando novos programas ao repositório local

Figura 14. 6ISÎODETALHADADEUMASOLICITA¥ÎODEMUDAN¥A(ISTØRICO

do caso)

Figura 15. &LUXOBÉSICODEUTILIZA¥ÎODOSUBVERSION Figura 19. &AZENDOUMAOPERA¥ÎODEUPDATEPARAATUALIZARACØPIALOCAL

Edição 24 - Engenharia de Software Magazine 27

Figura 20. )NICIANDOUMAOPERA¥ÎODECOMMIT
Figura 21. Operação de commit (autenticação de usuário autorizado)
Figura 22. Resultado da operação de commit
Resultados esperados do MPS.BR alcançados na solução
adotada
Conforme descrito anteriormente, a solução adotada deve-
rá estar em conformidade com o modelo MPS-BR.
Segundo o MPS.BR Guia Geral (SOFTEX, 2009, p.23) o
processo de Gerencia de Configuração encontra-se no nível
“F” do MR-MPS e deve atingir sete resultados esperados.
A Tabela 6 mostra os resultados esperados e os itens deste
trabalho onde estão contemplados.
28 Engenharia de Software Magazine - Gerência de Configuração
Figura 23. Log das operações realizadas no repositório
Instalação do Mantis
A versão do Mantis para Windows pode ser baixada a
partir do site “http://www.mantisbt.org/download.php”.
A sua versão estável mais recente é a MantisBT 1.1.8. Os se-
guintes softwares são requeridos e devem ser instalados:
PHP 4.3.0 and higher
MySQL database 4.1.1 and higher (MS SQL and DB2 are
also supported).
Web server (Apache, IIS, etc.)
Como forma de facilitar a instalação dos softwares acima,
pode ser instalado a última versão do XAMPP que traz
todos os requisitos para rodar o Mantis. O XAMPP pode
ser baixado a partir do site www.baixaki.com.br.
Caso seja instalado o XAMPP, o diretório de instalação do
Mantis deve estar localizado na pasta “htdocs” existente
no diretório de instalação do XAMPP.
O Mantis é simples de instalar. Basicamente é só seguir
as instruções de instalação que irão surgir na tela.
Configuração do Mantis
Após instalado o Mantis é necessário configurar o arquivo
“config.inc.php” com os parâmetros corretos para emissão
de e-mails. A configuração utilizada neste trabalho está
apresentada na Figura 24. Os campos “user”, “domínio” e
“password” que aparecem no texto devem ser substituídos
pelos correspondentes de cada caso.
A configuração listada na Figura 24 já inclui os parâ-
metros necessários para integração com o Subversion. O
significado de cada parâmetro pode ser obtido no manual
do Mantis no endereço “http://manual.mantisbt.org/
index.php”.
Vale observar que para que o envio de e-mails a cada novo
status de uma solicitação de modificação ocorra, é neces-
sário a instalação do PHPMailer, que pode ser encontrado
no site “http://phpmailer.sourceforge.net”. A instalação do
PHPMailer é simples, bastando para tanto copiar os arqui-
vos “class.smtp.php” e “class.phpmailer.php” para o diretó-
rio destinado aos arquivos de include. No caso do XAMPP o
diretório é “<diretório_de_instalação_do_XAMPP>\ php\
 PROJETO

Resultado esperado Seção

GCO 1. Um Sistema de Gerência de Configuração é estabelecido e mantido Estabelecimento de um sistema de GCS
GCO 2. Os itens de configuração são identificados com base em critérios estabelecidos Identificação dos ICS’s
Regras para nomeação dos itens de configuração
Regras para versionamento
Identificação de Tags
Identificação de Branches
GCO 3. Os itens de configuração sujeitos a um controle formal são colocados sob baseline Armazenamento dos ICS’s
Gerenciamento de Baselines
Estabelecimento de um sistema de GCS
GCO 4. A situação dos itens de configuração e das baselines é registrada ao longo do tempo e Gerenciamento de Baselines
disponibilizada; Estabelecimento de um sistema de GCS

GCO 5. Modificações em itens de configuração são controladas; Estabelecimento de um sistema de GCS

GCO 6. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são Estabelecimento de um sistema de GCS
controlados

GCO 7. Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os Estabelecimento de um sistema de GCS
itens de configuração estejam íntegros, completos e consistentes

Tabela 6. 2ESULTADOSESPERADOSNONÓVEL&DO-03"2

PEAR”. A instalação está descrita no arquivo “readme” que

traz também um exemplo simples.

Instalação do Subversion
A instalação do Subversion é mais simples do que a do
Mantis. O arquivo de instalação pode ser obtido no ende-
reço http://www.collab.net/downloads/subversion/. O
único software requerido é o Apache version: 2.2.11 que
já estará instalado caso o XAMPP tenha sido instalado
primeiro. Vale ressaltar que neste endereço existem dois
arquivos de instalação que devem ser baixados:
 CollabNet Subversion Server and Client v1.6.3 (for
Windows)
CollabNet Subversion Command-Line Client v1.6.3 (for
Windows)

O primeiro é obrigatório para o funcionamento das ope-

rações. Para o segundo arquivo, poderá ser usada a alter-
nativa do software “TortoiseSVN” que é mais amigável e
tem integração direta com o Windows Explorer. O arquivo
para instalação do TortoiseSVN pode ser encontrado no
site “www.baixaki.com.br”. Não é necessário configuração
adicional no software para o seu funcionamento, porém,
para cada repositório deverá ser configurado os perfis Figura 24. Arquivo config.inc.php
de acesso no arquivo “svnserve.conf”. Para detalhes de
integração do Subversion com o Mantis, consulte o site terminologias e algumas ferramentas voltadas para dar
http://alt-tag.com/blog/archives/2006/11/integrating- apoio à GCS.
mantis-and-subversion/. Na sequencia, mostramos uma solução de boa qualidade e
baixo custo que atende as exigências dos modelos de maturi-
Consideraçõs Finais dade e que pode ser facilmente implementada em empresas
Neste artigo, vimos inicialmente os conceitos gerais de de pequeno porte a fim de instalar as práticas de Gerência de
Gerencia de Configuração de software, suas principais Configuração de Software. A solução foi mostrada através de

Edição 24 - Engenharia de Software Magazine 29

um estudo de caso em uma empresa fictícia, e fez uso das fer- Dê seu feedback sobre esta edição! eu
Feedback

s
ramentas Mantis e Subversion para o controle de solicitação

Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
de modificações e controle de versões respectivamente.
Para isso, precisamos saber o que você, leitor, acha da revista!
Foram apresentados ainda aspectos de instalação das ferra-

s
ta
edição
Dê seu voto sobre este artigo, através do link:
mentas e sua customização.
www.devmedia.com.br/esmag/feedback

Referências Links

Barbosa, Valeria Plano de Gerência de Configuração de Software: Sistema de
Controle de Custos 11/09/2007 disponível em http://conexao.googlecode.com/files/
SYSCOPlanoGerenciaConfiguracao.pdf
Ben Collins-Sussman, de et al Version Control with Subversion: for Subversion 1.6 (Compiled
from r3445) 2008 disponível em <http:subversion.tigris.org/>
Borges, Vanessa R. Implantação de Práticas de Gerência de Configuração em uma Fábrica de
Software: Um estudo de caso (Graduação em Ciência da Computação) Universidade Federal de
Lavras, Minas Gerais, 2006
Forte, G.,“Rally Round the Repository”, CASE Outlook, Dez 1989, p. 5-27
MOLINARI, Leonardo. Gerência de configuração: Técnicas e práticas no desenvolvimento do
software. Florianópolis : Visual Books, 2007. 208p.
Neto, Euclides Plano de Gerência de configuração de software: Projeto VENSSO – Venda
de Serviços de Software 27/05/2005 disponível em <http://vensso.sourceforge.net/doc/
VENSSO_SCM_20050527.pdf>
Collabnet “CollabNet Subversion Downloads”
http://www.collab.net/downloads/subversion/
Comunidade de Software & Inovação Empresarial “As Ferramentas de SCM e o Suporte
do CMM”
http://paginas.ispgaya.pt/~msantos/es_artigos_tecnicos_1/60_FerramentasSCM_e_
suporteCMM.pdf
DevMedia “Gerência de Configuração – Parte 1”
http://www.devmedia.com.br/articles/viewcomp.asp?comp=9378
EAI Community “Establishing a Configuration Management Baseline”
http://it.toolbox.com/blogs/enterprise-solutions/establishing-a-configuration-management-
baseline-13910
Enciclopédia Livre, (2007) “Gerência de Configuração de Software”
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software
Gerência de Configuração “Gerência de Configuração”
http://www.cin.ufpe.br/~gfn/qualidade/gc.html

PRESSMAN, Roger S. Engenharia de software. 6ª. ed. São Paulo : McGraw-Hill, 2006. xxxi, 720p.
SEI, Software Engineering Institute. CMMI for Development, Version 1.2: CMMI DEV V 1.2.
Carnegie Mellon University, EUA, 2006 573p.
SOFTEX MPS.BR - Melhoria de Processo do Software Brasileiro, Guia de Implementação – Parte 2:
Nível F, Rio de Janeiro, 2009 53p
Mantis “Mantis Bug Tracker”
http://www.mantisbt.org/
Pronus Engenharia de Software “O que é Gerência de Configuração”
http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuracao.php
Regularize “Gerência de Configuração de Software”
http://cartilha.regularize.com.br/list/18/cartilha/post/80/gerencia-de-configuracao-de-software.html

SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral Rio de Janeiro, 2009 57p Tigris.org “Subversion”
http://subversion.tigris.org/

30 Engenharia de Software Magazine - Gerência de Configuração