INTRODUO

O desenvolvimento de softwares envolve vrias etapas fundamentais para criao de um

produto final com qualidade e dentro dos requisitos esperados pelo cliente.

Durante esse processo construtivo, o software sofre vrias modificaes em seu escopo
inicial, podendo gerar vrias releases, e dependendo da profundidade das alteraes nos
artefatos, uma nova verso do produto poder ser disponibilizada ao cliente.

Dentro desse cenrio de vrias alteraes, a gerncia de configurao surge como uma
ferramenta que possibilita manter a integridade do software de acordo com suas
especificaes durante seu desenvolvimento e ciclo de vida do software.

A complexidade envolvida no controle de dessas alteraes, traduz a necessidade de ter

um apoio sistematizado de ferramentas de colaborao de equipes e controle de verso.

A ausncia desse tipo de ferramenta para projetos de software, no torna o produto final
ineficiente, contudo agrega mais valor, confiana, segurana, qualidade e facilidade
colaborativa entre os envolvidos no projeto.

Objetivos Gerais
Melhorar a capacidade da equipe de desenvolvimento de software e seus processos de
controle de verses e releases durante e depois da entrega do produto final.

Objetivos Especficos

1. Criar um processo de gerncia de configurao

2. Controlar a release e verses de software
3. Acrescentar maior qualidade ao produto de software
4. Separar os servidores de teste e produo

CAPTULO I Gerncia de Configurao

1 Conceitos Fundamentais

A gesto de configurao de software um conjunto de atividades que foram desenvolvidas

para gerenciar alteraes de todo o ciclo de vida de um software (Pressman, 2011).
As origens dessas alteraes so variadas, bem como as prprias alteraes. De acordo
com Pressman (2011, p.515) h quatro fontes fundamentais de alteraes:

Novos negcios ou condies de mercado ditam mudanas nos requisitos do produto

ou regras comerciais.
Novas necessidades dos interessados demandam modificaes dos dados produzidos
pelos sistemas de informao, funcionalidade fornecida pelos produtos ou servios
fornecidos por um sistema baseado em computador.
Reorganizao ou crescimento/enxugamento causam alteraes em prioridades de
projeto ou estrutura de equipe de engenharia de software.
Restries oramentrias ou de cronogramas causam a redefinio do sistema ou
produto.

Essas alteraes podem surgir durante qualquer fase do projeto, mesmo que o produto j
esteja em produo, a necessidade de novas modificaes e atualizaes corriqueira.
Diante desse cenrio as metodologias de desenvolvimento de software devem estar prontas
para lidar com essa realidade no mercado.

A mudana inevitvel em todos os grandes projetos de software. Os requisitos do

sistema mudam ao mesmo tempo em que o negcio que adquiriu o sistema responde a
presses externas e mudam as prioridades de gerenciamento. Com a disponibilidade de
novas tecnologias, emergem novos projetos e possibilidades de implementao
(Sommerville, 2011).

O gerenciamento de configuraes de um produto de sistema de software envolve quatro

atividades afins (tabela 1):

Tabela 1 Atividades de Gerenciamento de Configurao

Fonte: Sommerville (2011, p.476)

1.1 Gerenciamento de Mudanas

O processo de mudana em muitos projetos constante e determinam o sucesso ou
fracasso do produto final esperado. As necessidades e requisitos organizacionais se alteram
durante a vida til de um sistema, bugs precisam ser reparados e os sistemas necessitam
se adaptar s mudanas em seu ambiente (Sommerville, 2011).

Essa capacidade de absorver vrias mudanas nos seus artefatos durante a fase de
levantamento de requisitos, desenvolvimento e produo obriga as organizaes a
apoiarem o mecanismo de controle e proteo do produto do software. Esse processo
necessrio devido o custos elevados que essa mudana pode gerar e qual seu impacto nos
componentes associados direta ou indiretamente.

Pensando na importncia desse controle Sommerville (2011, p.479) propem um modelo

bsico de formulrio de solicitao de mudana (tabela 2):

Tabela 2 Formulrio bsico de solicitao de mudana Formulrio de Solicitao de

Mudanas
Fonte: Sommerville (2011, p.479)
1.2 Gerenciamento de Verses

O gerenciamento de verses (VM, do ingls version management) o processo de

acompanhamento de diferentes verses de componentes de software ou itens de
configurao e os sistemas em que esses componentes so usados (Sommerville, 2011).

Adotando um modelo de gesto de verses as organizaes garantem que as mudanas

realizadas nos artefatos para vrios desenvolvedores no sofra interferncia uma das
outras, sendo tratadas como codelines e baseline.

1.2.1 Codelines

uma sequncia de verses de cdigo-fonte com verses posteriores na sequncia

derivadas de verses anteriores. Normalmente, as codelines so aplicadas para
componentes de sistemas, havendo, assim, diferentes verses de cada componente.

1.2.2 Baselines

Uma baseline uma definio de um sistema especfico. A baseline, portanto, especifica a

verso de cada componente includa no sistema, mais uma especificao das bibliotecas
usadas, arquivos de configurao etc.

As baselines podem ser especificadas usando-se uma linguagem de que lhe permite definir
quais componentes esto includos em uma verso de um determinado sistema. possvel
especificar explicitamente a verso de um componente especfico (X.1.2, por exemplo) ou,
simplesmente, especificar o identificador de componente (X). Se voc usar o identificador,
isso significa que a verso mais recente do componente deve ser usada na baseline.

1.2.3 Controlando Verses

Esses mecanismos de identificao apoiam a gerncia de configurao durante todas as
reas de desenvolvimento do software e liberao para usurio final, pois muitas das vezes
preciso recriar uma verso especfica de um sistema completo.

Para auxiliar nessa tarefa importante que as reas apoiem em ferramentas capazes de
identificar, armazenar e controlar o acesso a diferentes verses de componentes.

Normalmente as ferramentas de gerenciamento de verses fornecem uma variedade de

recursos, vide (tabela 3):

Tabela 3 5 recursos bsicos de ferramenta de controle de verses

Fonte: Sommerville (2011, p.482)

1.3 Construo de sistemas

A construo de sistemas o processo da criao de um sistema completo, executvel
por meio da construo e ligao dos componentes de sistema, bibliotecas externas,
arquivos de configurao etc. As ferramentas de construo de sistemas e as ferramentas
de gerenciamento de verses devem se comunicar na medida em que o processo de
construo envolve a realizao de check-out de verses de componentes do repositrio
pelo sistema de gerenciamento de verses (Sommerville, 2011).

A complexidade envolvida na construo de sistemas e o relacionamento com os

componentes geram potencialmente erros e falhas no seu desenvolvimento. Para
construo segura e dentro de padres de qualidade esperados devem-se observar trs
diferentes aspectos de sistemas disponveis:

1. Sistema de desenvolvimento: Abranger ferramentas como compiladores, editores de

cdigos-fontes, revisores de erros etc. Usando essas ferramentas os desenvolvedores
devem realizar o check-out que esto trabalhando em um repositrio privado sem
interferncia da produo, observando o cumprimento das diretrizes de controle de
verses.
2. Servidor de construo: Utilizado para criao de verses definitivas do produto,
integrado com o controle de verses, onde cada desenvolvedor realiza o check-in no
sistema de gerenciamento de verses antes dos sistemas serem construdos.
3. Ambiente alvo: a plataforma que o software ser executado, podendo o produto ser
do mesmo tipo do ambiente de desenvolvimento ou produo. Em ambos os casos os
testes devem ser realizados em ambientes diferentes para evitar incompatibilidade da
verso.
Quanto mais informaes reunidas sobre o software e seu ambiente operacional, menores
sero as possibilidades de problemas com as verses disponibilizadas aos usurios finais.
Para auxiliar nesse processo as ferramentas automatizadas de construo proporciona
maior agilidade na entrega final do produto.

Analisando as ferramentas de construo, algumas caractersticas bsicas so

fundamentais:

Gerao de script de construo

Integrao de sistema de gerenciamento de verses
Recompilao mnima
Criao de sistemas executveis
Automao de testes
Emisso de relatrios
Gerao de documentao

Essa viso permite controlar as inmeras verses geradas pelos desenvolvedores no

projeto e aderncias s polticas de qualidade esperadas no desenvolvimento de software.

Os mtodos geis tm uma viso que a construo de sistema frequentes devem ser
feitas com testes automatizados, conhecidos como testes fumaa, capazes de descobrir
os problemas de software. Essa constante atualizao e gesto de verses abre caminho
para integrao continua dos componentes e capacidade para resoluo dos problemas
causados pelas interaes entre diferentes desenvolvedores sejam detectados e
reparados o mais rpido possvel.

1.4 Gerenciamento de releases

Um release de sistema uma verso de um sistema de software distribuda aos clientes.
Para softwares de mercado de massa, normalmente possvel identificar dois tipos de
releases, chamados releases principais, que fornecem nova e significativa funcionalidade,
e releases menores, que reparam bugs e corrigem problemas de clientes que foram
relatados (Sommerville, 2011).

Dessa forma o gerenciamento de releases um processo complexo, e requer uma

documentao de controle para garantir que ela possa ser recriada no futuro em
decorrncia de problemas. muito comum em grandes sistemas haver vrias ou inmeras
releases sendo usadas ao mesmo tempo pelos usurios, e a gerencia de configurao tem
o papel de identificar qual release cada cliente est utilizando.

Para documentar um release, devem-se gravar as verses especficas dos componentes

de cdigo-fonte que foram usadas para criar o cdigo executvel. Manter cpias dos
arquivos de cdigo-fonte executveis correspondentes e todos os dados e arquivos de
configurao. Gravar as verses do sistema operacional, bibliotecas, compiladores e
outras ferramentas usadas para construir o software. Estas podem ser necessrias para
construir exatamente o mesmo sistema em uma data posterior. Isso pode significar que
voc precisa armazenar cpias de plataforma de software e as ferramentas usadas para
criar o sistema no sistema de gerenciamento de verses junto com o cdigo-fonte do
sistema-alvo (Sommerville, 2011).

Esse processo fundamental para garantir a segurana e qualidade do produto do

software e sobre tudo a confiana e disponibilidade do software para o usurio quando
necessrio. A adoo desse processo muitas vezes requer um investimento tcnico,
logstico, marketing e operacional para alcanar uma fatia do mercado.

Muitas barreiras podem surgir durante o planejamento e lanamento de uma nova release
aos consumidores, Sommerville (2011, p.489) destaca 5 fatores que influenciam o
planejamento de release de sistema:

1. Qualidade tcnica do sistema Caso sejam relatados defeitos graves de sistema,

que afetem a maneira como muitos clientes o usam, pode ser necessrio emitir um
release de reparao de defeitos. Pequenos defeitos de sistema podem ser reparados
mediante a emisso de patches (normalmente distribudos pela Internet) que podem
ser aplicados no release atual do sistema.
2. Mudana de plataforma Talvez voc precise criar um novo release de uma
aplicao de software quando uma nova verso da plataforma do sistema operacional
for lanada.
3. Concorrncia Para software de mercado de massa, um novo release de sistema
pode ser necessrio porque um produto concorrente introduziu novos recursos e a
fatia de mercado pode ser perdida caso estes no sejam fornecidos aos clientes
existentes.
4. Requisitos de marketing O departamento de marketing de uma organizao pode
ter feito um compromisso para releases estarem disponveis em uma determinada
data.
5. Propostas de mudana de cliente Para sistemas customizados, os clientes podem
ter feito e pago por um conjunto especfico de propostas de mudanas de sistema e
eles esperam um release de sistema assim que estas sejam implementadas.

Todos esses cuidados so fundamentais no lanamento de novas releases e ajudam na

transparncia da organizao, bem como na qualidade final do produto do software.
Contudo em inmeras vezes os usurios no querem instalar uma nova release do
produto, pois esto felizes com o sistema existente, fazendo com que as empresas
detentoras dos softwares mantenha disponvel a release em seu repositrio de segurana
e tambm para o cliente.

CAPTULO II Proposta de Gerncia de Configurao

1 Estruturao do ambiente
Para iniciar o processo de gerncia de configurao na empresa necessria uma
estabilizao do parque tecnolgico (computadores, servidores, softwares etc.), permitindo
identificar os possveis impedimentos iniciais na implantao do processo.

Dentro da proposta fundamental identificar as competncias dos colaboradores

envolvidos diretamente no ciclo de desenvolvimento de software na organizao, para criar
um ambiente capaz de suportar mudanas profundas nas rotinas a serem implantadas na
empresa, (foto 1):
Fonte: Elaborado pelo autor

Diante dessa avaliao bsica poderemos reverter inicialmente erros e falhas na

capacidade de infraestrutura da empresa e melhorar as competncias nas ferramentas
necessrias ao desenvolvimento de software.

2 Ambiente atual de desenvolvimento

A empresa tem dois ambientes, um de desenvolvimento e outro de produo, no h um
controle de versionamento do cdigo fonte e nem ambiente especfico de testes antes da
implantao em produo, (figura 2):
Figura 2 Ambiente atual de desenvolvimento

Fonte: Elaborado pelo autor

3 Tratamento de incidentes
Os incidentes so direcionados diretamente equipe de desenvolvimento, que far os
ajustes na ltima verso estvel do sistema, sem nenhuma preocupao no controle de
verses, padres de qualidade e segurana esperados nessa alterao requerida.

Aps realizados os ajustes necessrios a nova verso testada pelos prprios

desenvolvedores, que na sequencia disponibiliza para rea de produo. Havendo o
surgimento de falhas ou erros apontados pelos usurios o software volta para equipe de
desenvolvimento at soluo do problema, (figura 3):
O modelo utilizado pela empresa no satisfatrio, pois os incidentes so direcionados
diretamente aos desenvolvedores, que no so os especialistas indicados para realizar
uma anlise preliminar no questionamento de possveis anomalias com os requisitos.

3 Proposta de gerncia de configurao

A proposta inicial implantar uma rea responsvel pela elicitao dos requisitos e
possveis testes preliminares antes de se reconhecer o incidente como um problema.
Tambm h a necessidade de um versionamento do cdigo fonte a ser alterado de forma
que se mantenha um histrico das alteraes pelas quais o software passou e a
possibilidade de se recuperar uma verso anterior caso seja necessrio.
Deve-se criar um ambiente para homologao onde as alteraes realizadas possam ser
testadas sem interferncia dos outros ambientes e um servidor de construo, onde se
replicam todas as configuraes e caractersticas encontradas em produo (figura 4):
Seguindo o processo proposto a empresa melhora significativamente seu processo de
desenvolvimento de software agregando caractersticas fundamentais de gerenciamento
de configurao, incorporando maior segurana, controle, qualidade e estabilidade no ciclo
de desenvolvimento de software.
Diante das quatro atividades de gerenciamento de configurao, (gerenciamento de
mudanas, verses, construo do sistema e releases) a proposta proporciona
direcionamento da equipe de desenvolvimento, seja utilizando as metodologias tradicionais
ou geis.

CAPTULO III Concluso

A gerncia de configurao em muitos projetos de softwares esquecida por falta de um
processo detalhado e equilibrado dos fluxos de tarefas e caminhos que se deve percorrer
at a entrega do produto.

Com adoo do modelo proposto a organizao capaz de cumprir com as quatro

atividades de gerncia de configurao descritas por Sommerville nesse estudo. Alm de
mapear e reestruturar a infraestrutura de hardware e software caso seja necessrio, antes
mesmo de iniciar uma mudana profunda nos processos de desenvolvimento de software.

Outro ponto de destaque desse estudo capacidade da empresa em enxergar as

competncias dos indivduos diretamente envolvidos no projeto, criando um ambiente
altamente competitivo, pela aplicao de treinamentos e restruturao caso seja
necessrio do quadro efetivo de colaboradores.

Tendo ambientes diferentes de desenvolvimento, teste e construo os desenvolvedores e

usurios tero maior produtividades na execuo das tarefas, e menor incidncia de erros
e falhas no funcionamento esperado do software, histrico de verses, releases e garantia
de no interferncia dos ambientes durante e depois o lanamento do produto final.

CAPTULO IV Referncias
Sommerville, Ian. Engenharia de Software 9. ed. So Paulo, SP: Pearson Prentice Hall,
2011.
Pressman, Roger. Engenharia de Software: Uma abordagem professional 7. ed. Porto
Alegre, RS: AMGH, 2011.

Artigo Redigido pelos Alunos da Ps-Graduao do Curso de Engenharia de

Software da UNINOVE
Trabalho de Concluso do Mdulo de Gerncia da Configurao apresentado
Universidade Nove de Julho como parte dos requisitos para obteno do Ttulo de
Especialista em Engenharia de Software.

ANTONIO MAGNO DE SOUSA RODRIGUES ARAUJO

ALIELY SAMPAIO
EMERSON HONORATO
LEANDRO PEREIRA
WRIQUE DE JESUS FRANCA