Gestão de Configurações em Software Factory

VANESSA RODRIGUES BORGES
IMPLANTAO DE PRTICAS DE GERNCIA DE CONFIGURAO EM UMA

FBRICA DE SOFTWARE: UM ESTUDO DE CASO
Monografia de graduao apresentada ao

Departamento de Cincia da Computao da
Universidade Federal de Lavras como parte das
exigncias do Curso de Cincia da Computao
para obteno do ttulo de Bacharel em Cincia da
Computao.
LAVRAS
MINAS GERAIS BRASIL
2006


Universidade Federal de Lavras como parte das
Computao.
rea de concentrao:
Engenharia e Qualidade de Software
Orientador:
Prof. Andr Luiz Zambalde
LAVRAS
MINAS GERAIS BRASIL
2006
Ficha Catalogrfica preparada pela Diviso de Processo Tcnico da Biblioteca
Central da UFLA
Borges, Vanessa Rodrigues
Implantao de Prticas de Gerncia de Configurao em uma Fbrica de

Software: Um Estudo de Caso / Vanessa Rodrigues Borges Minas Gerais, 2006.
Monografia de Graduao Universidade Federal de Lavras. Departamento de

Cincia da Computao.
1. Engenharia e Qualidade de Software. 2. Melhoria do Processo de Software. 3.

Gerncia de Configurao de Software. 1. BORGES, V. R.. II. Universidade Federal de
Lavras. III. Ttulo.


Universidade Federal de lavras como parte das
Computao.
Aprovada em 18 de setembro de 2006.
______________________________________
Prof. Guilherme Bastos Alvarenga
______________________________________
Prof. Reginaldo Ferreira de Souza
______________________________________
Prof. Andr Luiz Zambalde
(Orientador)
LAVRAS
MINAS GERAIS - BRASIL
Dedico esse trabalho aos meus pais, Humberto e Ida, e s minhas irms, Ludmila e
Jacqueline que fizeram desse sonho uma realidade! Agradeo todo apoio, educao,
empenho, amor, carinho e dedicao que sempre recebi de vocs!
Agradecimentos
Agradeo a Deus por toda fora, luz, sade!

Aos meus professores, que foram peas imprescindveis para a minha formao!
Ao Alessandro pelas figuras e co-orientao nesse trabalho. Pelo apoio, dedicao e
carinho que sero para a vida inteira!
Ao Leandro e Breno pelos n trabalhos feitos juntos e noites sem dormir!
s farras feitas em Lavras!
ngela e o Deivson pelos quebra-galho essenciais minha graduao!
Repblica Kara Karamba Kara Kara , por tornar Lavras meu Lar Doce Lar!
Casa das 7 Mulheres pelo tempo de hospedagem!
Gerao Sade pelas farras Bom Sucessenses!
Gabi por ser a minha eterna princesinha e meu remdio contra o estresse e tristeza!
Joana, Keka, Nina e Pati por toda amizade!
s minhas irms por tudo!
famlia SW que despertou em mim, a paixo por minha profisso!
Ao professor Andr Luiz Zambalde pela orientao e conselhos!
E a todos que de alguma forma fizeram parte da minha vida e contriburam positiva e
negativamente para o meu crescimento pessoal e profissional!
A todos: Muito obrigada!
RESUMO
O principal objetivo deste trabalho descrever e discutir a implantao de prticas de

Gerncia de Configurao de Software de uma empresa de pequeno porte. A empresa
participante da pesquisa, uma fbrica de software, buscou implantar atividades
relacionadas Gerncia de Configurao em funo de problemas relacionados falta de
controle sobre o desenvolvimento, comunicao precria entre os colaboradores, excesso
de no conformidades nos softwares produzidos e grande quantidade de retrabalho
decorrente de perdas de cdigo-fonte e requisitos j documentados e implementados. A fim
de facilitar o desenvolvimento deste trabalho levou-se em considerao o perfil da
empresa, ou seja, empresa de pequeno porte e de recursos moderados (humano, tempo e
capital). Foram definidas atividades dentro do processo de desenvolvimento que dessem
suporte s prticas de identificao, controle, contabilizao da situao e auditoria da
configurao. Apesar da imaturidade no processo de gerncia de configurao de software
e da resistncia causada pela cultura organizacional, a adoo das prticas definidas
apontou para uma melhora na qualidade do processo e do produto da organizao,
diminuio de retrabalho, maior produtividade e uso racional de recursos.
Palavras-Chave: Engenharia de Software, Qualidade de Software, Melhoria do Processo
de Software, Gerncia de Configurao de Software.
IMPLANTATION OF CONFIGURATION MANAGEMENT PRACTICES IN A

SOFTWARE FACTORY: A CASE STUDY
ABSTRACT
The main objective of this work is to describe and to argue the implantation of
Configuration Management practices in a software development process of a small
business company. The software factory of the participant company of the research
searched to implant activities related to the Software Configuration Management in
function of the control lack on the development, of the precarious communication between
the collaborators, of the excess of non conformity in softwares produced and of the great
amount of re-work decurrently of losses of code-source and requirements already
documented and implemented. In order to facilitate the development of this work the
profile of the company was taken in consideration, that is, small business company, young,
moderate resources (human, time and capital). Activities had been defined within the
development process that gave support to the identification practices, control, and situation
accounting and configuration audit. Although the process immaturity of software
configuration management and the resistance caused for the organizational culture, the
adoption of the practices defined pointed to an improvement in the organization process
and product quality, reduction of re-work, greater productivity and rational use of
resources.
Key-Words: Software Engineering, Software Quality, Software Process Improvement,
Software Configuration Management.
vi
SUMRIO
LISTA DE FIGURAS............................................................................................... ix
LISTA DE TABELAS ............................................................................................... x
LISTA DE ABREVIATURAS E SIGLAS ............................................................... xi
1. INTRODUO.................................................................................................. 1
1.1. Contextualizao e Motivaes................................................................. 1
1.2. Objetivos e Justificativas........................................................................... 2
1.3. Organizao do Trabalho ......................................................................... 3
2. REFERENCIAL TERICO ............................................................................. 4
2.1. Engenharia e Qualidade de Software ...................................................... 4
2.2. Melhoria do Processo de Software ........................................................... 6
2.3. Fbrica de Software................................................................................. 12
2.4. Gerncia de Configurao de Software (GCS) ..................................... 14
2.4.1. Funes da Gerncia de Configurao................................................................... 18

2.4.2. Ferramentas de Apoio ............................................................................................ 22
2.5. Consideraes Finais do Captulo .......................................................... 24
3. METODOLOGIA ............................................................................................ 25
3.1. Tipo de Pesquisa ...................................................................................... 25
3.2. Procedimentos Metodolgicos ................................................................ 26
4. RESULTADOS E DISCUSSO .................................................................. 28
4.1. Caracterizao da Empresa.................................................................... 28
4.2. Diagnstico das Prticas de Gerncia de Configurao Atuais .......... 28
4.3. Planejamento da Implantao das Prticas de GCS na Empresa ...... 32
4.3.1. Auditoria da Implantao....................................................................................... 32

4.3.2. Elaborao do Plano de Implantao ..................................................................... 33
vii
4.3.3. Execuo do Plano de Implantao........................................................................ 33
4.3.4. Institucionalizao das Prticas de GCS ................................................................ 37
4.3.5. Avaliao da Implantao ...................................................................................... 38
4.4. Implantao das Prticas de GCS.......................................................... 38
4.4.1. Plano de Gerncia de Configurao....................................................................... 39

4.4.2. Plano de Ambiente ................................................................................................. 39
4.4.3. Identificao da Configurao ............................................................................... 39
4.4.4. Controle da Configurao ...................................................................................... 40
4.4.5. Contabilizao da Situao da Configurao......................................................... 45
4.4.6. Auditoria da Configurao..................................................................................... 45
4.5. Avaliao da Implantao das Prticas de GCS................................... 46
5. CONCLUSES............................................................................................... 47
6. REFERENCIAL BIBLIOGRFICO ............................................................. 49
Apndice A Glossrio de Gerncia de Configurao ............................ 52
Apndice B Plano de Gerncia de Configurao .................................... 58
Apndice C Plano de Ambiente.................................................................... 63
viii
LISTA DE FIGURAS
Figura 2.1 - O Processo de Software e seus Componentes................................................................................ 7
Figura 2.2 - O Processo de Software ............................................................................................................... 11
Figura 4.1 - Poltica "trava-modifica-destrava" ............................................................................................... 30
Figura 4.2 - Cpia dos arquivos do repositrio para o local de trabalho ......................................................... 30
Figura 4.3 - Etapas da Implantao das Prticas de GCS ................................................................................ 32
Figura 4.4 - Poltica "copia-modifica-resolve" ................................................................................................ 36
Figura 4.5 - Prticas de Gerncia de Configurao ......................................................................................... 38
Figura 4.6 - Fluxo Sinttico de Gerncia de Configurao ............................................................................. 41
Figura 4.7 - Fluxo de Operao do Subversion ............................................................................................... 42
Figura 4.8 - Fluxo de Controle de Mudanas Formal...................................................................................... 43
Figura 4.9 - Fluxo de bugs adotado para a Ferramenta Mantis ....................................................................... 44
Figura 4.10 - Fluxo de requisitos adotado para a Ferramenta Mantis ............................................................. 44
Figura A.1 - Pginas 1 e 2 do Glossrio de Gerncia de Configurao........................................................... 52
Figura A.5 - Pginas 9 e 10 do Glossrio de Gerncia de Configurao......................................................... 54
Figura A.6 - Pginas 11 e 12 do Glossrio de Gerncia de Configurao....................................................... 54
Figura A.7 - Pginas 13 e 14 do Glossrio de Gerncia de Configurao....................................................... 55
Figura A.8 - Pginas 15 e 16 do Glossrio de Configurao........................................................................... 55
Figura A.9 - Pginas 17 e 18 do Glossrio de Configurao........................................................................... 56
Figura A.10 - Pginas 19 e 20 do Glossrio de Configurao......................................................................... 56
Figura A.11 - Pgina 21 do Glossrio de Configurao .................................................................................. 57
Figura B.1 - Pginas 1 e 2 do Plano de Gerncia de Configurao ................................................................. 58
Figura B.3 - Pginas de 5 e 6 do Plano de Gerncia de Configurao ............................................................ 59
Figura B.5 - Pginas 9 e 10 do Plano de Gerncia de Configurao ............................................................... 60
Figura B.6 - Pginas 11 e 12 do Plano de Gerncia de Configurao ............................................................. 60
Figura B.10 - Pgina 19 do Plano de Gerncia de Configurao .................................................................... 62
Figura C.1 - Pginas 1 e 2 do Plano de Ambiente ........................................................................................... 63
ix
LISTA DE TABELAS
Tabela 2.1 - Caractersticas do processo............................................................................................................ 9
x
LISTA DE ABREVIATURAS E SIGLAS
ABNT Associao Brasileira de Normas Tcnicas

CASE - Computer-Aided Software Engineering Engenharia de Software Apoiada por
Computador
CMG Configuration Management Group Grupo de Gerncia de Configurao
CMMI-SE/SW - Capability Maturity Model Integration Modelo de Capacidade da
Maturidade Integrado
ES - Engenharia de Software
EUA Estados Unidos da Amrica
GC - Gerncia de Configurao
GCS - Gerncia de Configurao de Software
HP - Hewlett-Packard Development Company
IEEE - Institute of Electrical and Eletronic Engineers Instituto de Engenheiros Eltricos
e Eletrnicos
IBM - International Business Machines Corporation
IC Item de configurao
ISO/IEC - International Organization for Standardization / International Electrotechnical
Commission - Organizao Internacional para Padronizao / Comisso Internacional
Eletrnica.
MG - Minas Gerais
MPS.BR - Melhoria de Processo do Software Brasileiro
NBR Norma Brasileira
SDO - Software Development Organization Organizao Desenvolvedora de Software
SEI - Software Engineering Institute - Instituto de Engenharia de Software.
SEPG - Software Engineering Process Group Grupo de Engenharia de Processo de
Software
SW-CMM - Capability Maturity Model Modelo de Capacidade da Maturidade
TI - Tecnologia da Informao
UFLA - Universidade Federal de Lavras
xi
1. INTRODUO
A preocupao com a melhoria do processo de desenvolvimento de software vem
sendo impulsionada por exigncias do mercado por mais qualidade e produtividade. Muitas
empresas tm revisto seus processos, procurando se capacitar no mercado cada vez mais
competitivo.
Neste primeiro captulo apresentada uma breve introduo sobre o trabalho
proposto, juntamente com as motivaes para a realizao do mesmo, os objetivos e as
justificativas.
1.1. Contextualizao e Motivaes

Com o aumento da complexidade no desenvolvimento de sistemas e a existncia
cada vez maior de uma competitividade no mercado na rea de tecnologia da informao,
tornou-se crescente a necessidade de criao de produtos mais confiveis e de boa
qualidade.
Nos ltimos anos, identifica-se uma forte tendncia busca contnua pela
qualidade, principalmente porque o resultado de mtodos que objetivam a melhora dessa
qualidade pde ser traduzido como lucro para as empresas (diminuio de retrabalho,
maior produtividade e uso racional de recursos).
A fim de atender a essa tendncia e exigncias do mercado, diversas metodologias
de desenvolvimento de software relacionadas ao controle foram elaboradas, visto que, ao
longo do ciclo de vida de um projeto de software uma grande quantidade de itens de
informao produzida, tais como: documentos, cdigo-fonte, dados e manuais. Muitos
desses itens provavelmente iro sofrer algumas modificaes durante o projeto devido a
diversas causas, como mudanas nos requisitos ou correo de defeitos.
Para evitar a perda do controle do projeto em conseqncia das mudanas preciso
que essas sejam devidamente controladas e gerenciadas.
A Gerncia de Configurao de Software (GCS) uma disciplina, dentro da
Engenharia de Software, que tem como objetivo gerenciar e controlar a evoluo de um
software atravs, basicamente, de controle formal de verso e solicitao de mudanas. Em
outras palavras, a prtica de lidar com modificaes de forma sistemtica, permitindo que
os sistemas tenham sua integridade mantida com o passar do tempo.
A falta da Gerncia de Configurao de Software pode ocasionar problemas como:
perda de cdigo-fonte, bibliotecas que inesperadamente param de funcionar,
impossibilidade de determinar o que aconteceu com um programa ou parte dele, programa
em execuo e o seu cdigo-fonte em verses diferentes ou, at mesmo, quem, por que e
quando foram efetuadas modificaes.
Bersoff (1984) garante que a Gerncia de Configurao nasceu como resposta aos
erros cometidos durante os anos 70, quando computadores comearam a ser utilizados de
maneira geral para a soluo dos mais diversos e complexos problemas e para os quais o
gerenciamento tradicional mostrou-se inadequado. Principalmente, quando se descobriu
que a complexidade de gerenciamento de um sistema no variava de maneira linear com o
nmero de linhas de cdigo, mas de maneira exponencial.
Como observa Babich (1986), ela uma disciplina til para a gerncia do projeto,
pois lhe permite executar tarefas complexas de uma maneira mais organizada, o que
proporciona aumento de produtividade e reduo de erros. Do ponto de vista da atividade
de teste, o uso da gerncia de configurao como elemento de melhoria de qualidade ainda
uma questo em aberto. Mas ela profundamente importante no que tange aos benefcios
trazidos por ela, pois o tipo e quantidade de informao advindos da atividade de teste que
podem ser manipuladas com o uso dessa disciplina, possibilitam maior eficincia nas
atividades de evoluo, depurao e manuteno do software.
Hoje, independente do porte da empresa de desenvolvimento de software, tem-se
que a GCS imprescindvel para maximizar a produtividade, minimizar os erros e diminuir
o retrabalho.
1.2. Objetivos e Justificativas

O objetivo deste trabalho propor o uso da gerncia de configurao nas atividades
de uma empresa desenvolvedora de software, neste trabalho tratada pelo nome fictcio
Beta, com o intuito de minimizar o esforo alocado, o retrabalho e aumentar a
produtividade durante toda a evoluo do software por ela desenvolvido.
Nessa perspectiva, a finalidade apresentar um plano de gerncia de configurao
para a organizao, criar um manual de instrues para todos os envolvidos no processo de
desenvolvimento de software, elaborar um plano de ambiente, organizar a equipe e a infra-
estrutura dentro da empresa e, por fim, implantar as prticas no processo da organizao.
Com a implantao dessas prticas, espera-se que seja institucionalizada a
metodologia de gerenciamento dos itens de configurao nos projetos da organizao, que
2
se tenha um satisfatrio controle de verses e de mudanas, bem como, que se obtenha um
aumento na qualidade dos seus produtos desenvolvidos e reduo do retrabalho.
A empresa participante como ambiente de execuo e estudo de caso para a
realizao deste trabalho de desenvolvimento de software, uma Software Development
Organization (SDO), de pequeno porte, localizada na cidade de Lavras MG.
Apesar de existir nesta empresa Beta um processo de desenvolvimento de
software definido, esse possui carncias no que se refere Gerncia de Configurao de
Software. Para a empresa, a implantao das prticas de GCS motivada pela busca da
qualidade nos projetos sob sua orientao como ponto de diferenciao de seus produtos
num mercado aberto e competitivo. Esse trabalho ser o incio da formalizao e
institucionalizao do processo de gerncia de configurao no desenvolvimento de
software dentro da organizao.
A empresa estudo de caso submeteu-se, recentemente, implantao de melhorias
em seu processo visando uma certificao formal nvel G no modelo MPS.BR - Melhoria
de Processo do Software Brasileiro. Nesse contexto, o trabalho se justifica, uma vez que, a
organizao j possui uma cultura institucionalizada de busca por qualidade. Na empresa
se tem como bom investimento implantao de novas prticas em seu processo de
desenvolvimento que auxiliaro o aumento e a garantia da qualidade de seus produtos e
processo.
1.3. Organizao do Trabalho

Os captulos subseqentes deste trabalho esto assim organizados: no Captulo 2,
so discutidos os conceitos de engenharia e qualidade de software; melhoria no processo
de software; fbrica de software, alm de gerncia de configurao. A metodologia
utilizada para a concepo deste trabalho mostrada no Captulo 3. No captulo 4, so
apresentados os resultados e discusses sobre o estudo realizado. Por fim, o Captulo 5
aborda as concluses deste trabalho. Nos Anexos de A at C, so exibidos modelos de
documentos utilizados para apoiar a atividade e a implantao das prticas de Gerncia de
Configurao de Software.
3
2. REFERENCIAL TERICO
O presente captulo tem por objetivo facilitar a compreenso do trabalho proposto
abordando os temas relacionados ao mesmo. So introduzidos conceitos gerais de
engenharia e qualidade de software, melhoria no processo de software, fbrica de software
e gerncia de configurao de software; fornecendo, assim, embasamento para um melhor
entendimento deste trabalho.
2.1. Engenharia e Qualidade de Software

Segundo Bauer apud Pressman (2002), "Engenharia de Software (ES) a criao e
a utilizao de slidos princpios de engenharia a fim de obter software de maneira
econmica, que seja confivel e que trabalhe eficientemente em mquinas reais". O prprio
significado de engenharia j traz os conceitos de criao, construo, anlise,
desenvolvimento e manuteno.
Sommerville (2003) diz que a Engenharia de Software uma disciplina da
engenharia que se ocupa de todos os aspectos da produo de software, desde os estgios
iniciais de especificao do sistema at a manuteno desse sistema, depois que ele entrou
em operao. Destacam-se dois fragmentos nesta definio: disciplina da engenharia, o
que diz respeito aplicao de teorias, mtodos e ferramentas apropriadas em momentos
apropriadas, de modo seletivo; e sempre procura descobrir solues para os problemas,
mesmo quando no existem teorias aplicveis e mtodos de apoio; e todos os aspectos da
produo de software, o que elucida que a engenharia de software no se encarrega
somente dos processos de desenvolvimento, mas tambm do gerenciamento de projetos de
software e desenvolvimento de ferramentas, mtodos e teorias que dem apoio produo
de software.
Essa disciplina surgiu em meados dos anos 70 numa tentativa de contornar a crise
do software e dar um tratamento de engenharia (mais sistemtico e controlado) ao
desenvolvimento de sistemas de software complexos. Um sistema de software complexo se
caracteriza por um conjunto de componentes abstratos de software (estruturas de dados e
algoritmos) encapsulados na forma de procedimentos, funes, mdulos, objetos ou
agentes e interconectados entre si, compondo a arquitetura do software, que devero ser
executados em sistemas computacionais.
A Engenharia de Software uma rea de conhecimento voltada para a
especificao, desenvolvimento e manuteno de sistemas de software aplicando
tecnologias e prticas de cincia da computao, gerncia de projetos, gerncia de
configurao e outras disciplinas, objetivando organizao, produtividade e qualidade.
Empresas desenvolvedoras de software passaram a empregar os conceitos de
Engenharia de Software, sobretudo para orientar suas reas de desenvolvimento, muitas
delas organizadas sob a forma de Fbrica de Software. O conceitos sobre fbrica de
softwares sero apresentados na seo 2.3 deste trabalho.
A engenharia de sistemas uma rea mais ampla por tratar de todos os aspectos de
sistemas baseados em computadores, incluindo hardware e engenharia de processos alm
do software.
Segundo o IEEE (2001) so definidos no SWEBOK as seguintes reas de
conhecimento da Engenharia de Software: requisitos de software; projeto (design) de
software; construo de software; teste de software; manuteno de software; gerncia de
configurao de software; gerncia de engenharia de software; ferramentas e mtodos de
engenharia de software e qualidade de software.
A Gerncia de Configurao de Software (GCS) alm de ser uma das reas de
conhecimento da ES o foco deste trabalho e ser apresentada de forma mais detalhada na
seo 2.4 desse trabalho.
A ES est envolvida com todos os aspectos da produo de software de qualidade a
um custo aceitvel. Esses termos levam busca de um processo de desenvolvimento que
considere a componente Qualidade.
Atingir um alto nvel de qualidade de produto ou servio o objetivo da maioria
das organizaes. Atualmente, no mais aceitvel entregar produtos com baixa qualidade
e reparar os problemas e as deficincias depois que os produtos foram entregues ao cliente,
conforme diz Sommerville (2003).
A definio de qualidade relativa. O que qualidade para uma pessoa pode ser
falta de qualidade para outra. A idia de qualidade aparentemente intuitiva; contudo,
quando examinado mais longamente, o conceito se revela complexo. Definir um conceito
de qualidade para estabelecer objetivos , assim, uma tarefa menos trivial do que aparenta
a princpio. A noo de qualidade de software pode ser descrita por um grupo de fatores,
requisitos ou atributos, tais como: confiabilidade, eficincia, facilidade de uso,
modularidade e legibilidade.
Em Engenharia de Software, a qualidade normalmente tratada de forma
diferenciada quanto a produtos e a processos de desenvolvimento de software.
5
Segundo a norma ISO/IEC 9126 (1991) - International Organization for
Standardization/International Electrotechnical Commission, relacionada a produtos,
qualidade "Um conjunto de atributos que tm impacto na capacidade do software de
manter o seu nvel de desempenho dentro de condies estabelecidas por um dado perodo
de tempo.
Pressman (2002) diz que qualidade a conformidade a requisitos funcionais e de
desempenho explicitamente declarados, a padres de desenvolvimento claramente
documentados e a caractersticas implcitas que so esperadas de todo software
profissionalmente desenvolvido.
As duas vertentes qualidade de produto e qualidade de processo so
complementares e interdependentes. Espera-se que a qualidade do processo de fabricao
tenha um impacto positivo sobre o software obtido. Entretanto, tal objetivo ser atingido se
houver uma compreenso clara de que os processos devem fornecer todos os mecanismos
necessrios para especificar o produto e controlar a fabricao.
Atentas a essas exigncias e buscando alcanar um alto padro de qualidade dos
seus produtos, as organizaes de software vm utilizando o conceito da engenharia de
software na construo dos mesmos.
Em geral, a disciplina de Engenharia de Software adota uma abordagem sistemtica
e organizada para a realizao do trabalho, uma vez que essa , com freqncia, a maneira
mais eficaz de produzir software de alta qualidade.
Sendo assim, para alcanar a qualidade, a Engenharia de Software utiliza-se de
melhoria de processos, implementada atravs de modelos abstratos ou formais que
permitem aos engenheiros especificar, projetar, implementar e manter sistemas de
software, avaliando e garantindo suas qualidades. Alm disto, a Engenharia de Software
deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento.
A implantao de um sistema de qualidade no desenvolvimento de software
permite um aumento de produtividade, uma melhoria da qualidade do produto final e um
aumento da satisfao dos clientes e da prpria empresa.
2.2. Melhoria do Processo de Software

Hoje em dia, a qualidade do processo mais importante do que a qualidade final do
produto e existem normas e padres tanto para produtos quanto para processos.
6
O conceito de processo na indstria de manufaturas quase intuitivo e pode ser
visto como as diversas operaes pelas quais um produto passa at ficar pronto.
Segundo o IEEE (Institute of Electrical and Eletronic Engineers), de forma mais
geral, processo uma seqncia de passos realizados para um determinado propsito.
Para software, o conceito de processo pode ser definido segundo Paulk et al. (1995)
como um conjunto de atividades, mtodos, prticas e tecnologias que as pessoas utilizam
para desenvolver e manter o software e seus produtos relacionados. A Figura 2.1 ilustra
esta definio.
Figura 2.1 - O Processo de Software e seus Componentes

Fonte: Pessoa (2003)
Pressman (2002) trata a engenharia de software como uma tecnologia em

camadas. Toda iniciativa de engenharia de software deve ser apoiada por um
compromisso com a qualidade. Acima da camada da qualidade encontram-se os processos,
acima destes os mtodos e acima destes as ferramentas. O processo de software o
conjunto de atividades e resultados associados que levam produo de software.
7
Ao longo da histria da engenharia de software foram sendo criadas ferramentas
computadorizadas para apoiar o desenvolvimento, vrios modelos de processos de
software foram concebidos.
Existem algumas atividades fundamentais, que se pode dizer comuns em todos os
processos de software, so elas: especificao, projeto e implementao; validao e
evoluo do software.
A especificao de software, tambm conhecida como engenharia de requisitos,
destina-se a estabelecer quais funes so requeridas pelo sistema e as restries sobre a
operao e o desenvolvimento do sistema.
A implementao converte a especificao produzida na atividade anterior em um
sistema executvel. Esta atividade, geralmente, envolve o projeto e a programao do
software. O projeto a descrio da estrutura do software, dos dados que fazem parte do
sistema e das interfaces entre os componentes do sistema.
A atividade de validao, tambm chamada de verificao e validao, atesta que o
sistema est de acordo com suas especificaes e que atende s expectativas. Esta atividade
inclui revises e inspees em cada estgio do processo de software.
A ltima atividade fundamental, a evoluo de software, trata da demanda real por
modificaes no software, o que cada vez mais comum visto que as necessidades dos
usurios so mutveis.
Segundo Sommerville (2003), durante os ltimos anos, ampliou-se o interesse por
parte das organizaes que desenvolvem software pela melhoria de seus processos. A
melhoria do processo significa compreender os processos existentes e modific-los, a fim
de melhorar a qualidade do produto e/ou reduzir os custos e o tempo de desenvolvimento.
A maior parte da literatura relacionada a esse assunto tem se concentrado em aprimorar os
processos para melhorar a qualidade do produto e, em particular, para reduzir o nmero de
defeitos nos softwares fornecidos. Uma vez que esse objetivo alcanado, a reduo dos
custos e do tempo pode se tornar a principal meta da melhoria.
A melhoria do processo de software envolve aspectos tcnicos, gerenciais e
culturais, tais como:
Alinhamento das aes de melhoria ao contexto, estratgia e objetivos de
negcio da organizao;
8
Escolha de um modelo (ou conjunto de modelos) de processo como
referncia para orientao do trabalho (por exemplo, a ISO/IEC 15504 e o
CMMI-SE/SW - Capability Maturity Model Integration);
Estabelecimento de um programa de melhoria para gerenciar as aes a
serem realizadas, conhecimento do estado atual das prticas da organizao;
Acompanhamento, medio e institucionalizao da melhoria.
Tudo isto por meio da definio, utilizao e melhoria contnua dos processos
envolvidos na aquisio, fornecimento, desenvolvimento, operao, manuteno e suporte
de sistemas de software.
Para tanto abordagens e experincias para a melhoria de processo de software
baseadas em modelos tm sido utilizadas com sucesso pelas organizaes de software. Os
modelos mais utilizados tm sido o SW-CMM - Capability Maturity Model, ISO/IEC
12207, ISO/IEC 15504 e CMMI-SE/SW.
Sommerville (2003) diz que melhorar o processo de software de uma organizao
no significa simplesmente adotar mtodos ou ferramentas especficas ou algum modelo de
processo que tenha sido utilizado em outro lugar, pois os processos de software so
inerentemente complexos e envolvem um nmero muito grande de atividades. Assim como
os produtos, os processos tambm tm atributos ou caractersticas (ver Tabela 2.1).
Tabela 2.1 - Caractersticas do processo
Caracterstica do processo Descrio
Facilidade de compreenso At que ponto o processo est explicitamente definido e
com que facilidade se pode compreender a definio do
processo?
Visibilidade As atividades de processo culminam em resultados ntidos,

de modo que o progresso do processo seja externamente
visvel?
Facilidade de suporte At que ponto as atividades do processo podem ser apoiadas

por ferramentas CASE - Computer-Aided Software
Engineering?
Aceitabilidade O processo definido aceitvel e utilizvel pelos

engenheiros responsveis pela produo do produto de
software?
9
Confiabilidade O processo est projetado de tal maneira que seus erros
sejam evitados ou identificados antes que resultem em erros
no produto?
Robustez O processo pode continuar, mesmo que surjam problemas

inesperados?
Facilidade de manuteno O processo pode evoluir para refletir os requisitos mutveis

da organizao ou melhorias de processo identificadas?
Rapidez Com que rapidez pode ser concludo o processo de entrega

de um sistema, a partir de uma determinada especificao?
Fonte: Sommerville (2003)
Para que alcanar a melhoria do processo, necessrio que se promova a execuo

das seguintes atividades denominadas de estgios:
Anlise de processo: examina os processos existentes e produz um modelo
especfico para documentar e compreender o processo;
Identificao de melhoria: ocupa-se de utilizar os resultados coletados da
fase de anlise de processo para identificar gargalos relativos qualidade,
ao prazo e ao custo, em que os fatores de processo influenciam
adversamente a qualidade do produto. A melhoria de processo deve enfocar
as eliminaes desses gargalos, propondo novos procedimentos, mtodos e
ferramentas para corrigir os problemas;
Introduo de mudana de processo: implantam-se novos procedimentos,
mtodos, ferramentas e integra-os com outras atividades de processo.
importante dar tempo suficiente para introduzir as mudanas e garantir que
elas sejam compatveis com outras atividades de processo e com os
procedimentos e padres organizacionais;
Treinamento em mudanas de processo: essa fase muito importante, pois
sem ela no possvel obter os plenos benefcios das mudanas de processo.
Quando as mudanas de processo so impostas sem treinamento adequado,
10
os efeitos dessa mudana resultam na deteriorao e no na melhoria da
qualidade do produto;
Ajuste de mudanas: As mudanas de processo propostas nunca sero
inteiramente eficazes assim que forem introduzidas. H a necessidade de
uma fase de ajuste, em que problemas menores sejam descobertos e
modificaes no processo sejam propostas e introduzidas.
O sucesso da melhoria de processo depende do cumprimento organizacional com as
metas estabelecidas, da disponibilidade de recursos e do apoio e participao de todos os
colaboradores da organizao.
Os diversos modelos identificam processos fundamentais para a engenharia de
software e, em todos eles, tem-se a gerncia de configurao como sendo um desses. A
gerncia de configurao essencial para a avaliao do software desenvolvido.
Uma das atividades consideradas por Pressman (2002) como atividade guarda-
chuva aplicada ao longo de todo o processo de software a gerncia de configurao de
software, conforme ilustrado na Figura 2.2.
Figura 2.2 - O Processo de Software

Fonte: Adaptado de Pressman (2002)
Entretanto, gerenciar a configurao de um software no uma atividade trivial, e
exige conhecimentos, habilidades e infra-estrutura especficos.
11
2.3. Fbrica de Software
Nos ltimos anos pde-se perceber uma movimentao crescente no mercado de
desenvolvimento de sistemas em direo ao modelo denominado fbrica de software.
O termo Fbrica de Software surgiu no mercado, como uma soluo para alcanar
maior produtividade e menor custo na produo de sistemas de software. Esta afinidade
com o mercado possivelmente o principal fator que concorre para a baixa quantidade de
materiais acadmicos abordando o tema. O que existe na verdade so iniciativas, partindo
de empresas de diferentes portes, para pr em prtica os conceitos de produo
provenientes de fbricas industriais. Sendo assim, uma das principais caractersticas deste
modelo a adoo de tcnicas utilizadas na engenharia industrial de produo em srie,
para a criao de um ambiente produtivo de desenvolvimento de software com qualidade e
baixo custo.
Conforme Siy et al. (2001), uma fbrica de software uma organizao que prov
servios de desenvolvimento de sistemas com alta qualidade, a baixo custo e de forma
rpida, utilizando um processo de desenvolvimento de software bem definido e tecnologia
de ponta, alm de algumas formas de feedback1 para reconhecer e lidar com oportunidades
de melhoria do processo.
De acordo com Aaen (1997), h mais de trinta anos a idia de fbrica de software
vem sendo continuamente moldada. As primeiras fbricas surgiram no final da dcada de
60 e, ainda hoje, o termo fbrica possui uma interpretao controversa quando o
desenvolvimento de software comparado produo em massa de produtos industriais.
importante frisar que, esta comparao com produo industrial de massa, deve
ser realizada com ressalvas, principalmente pelo fato de um produto de software ser nico,
ou seja, cada nova demanda de produo da fbrica possuir caractersticas especficas, o
que descaracteriza o conceito de produo em massa que se tem para os produtos
industriais. Apesar das controvrsias e das diferentes vises com relao ao termo, em sua
forma mais trivial, todas as definies possuem pontos em comum. As diferenas surgem
ao se detalhar os conceitos e nos aproximando dos aspectos estratgicos, funcionais e
operacionais, quando ento se percebe uma srie de diferentes opes para se estruturar
uma fbrica de software.
1
Feedback, nesse contexto, significa retroinformao, ou seja, comentrios e informaes sobre algo que j
foi feito com o objetivo de avaliao
12
O termo Fbrica de Software deve ser interpretado como uma organizao
projetada de maneira particular e sistematizada, composta por pessoas envolvidas em um
esforo comum, onde as tarefas so organizadas e a padronizao utilizada com o
objetivo de auxiliar na coordenao e formalizao do processo, segundo Aaen (1997).
Apesar de ser um modelo antigo, surgido no incio da dcada de 60, fbrica de
software nunca foi um modelo adotado intensivamente pelo mercado, onde as principais
iniciativas partiam de grandes corporaes como HP - Hewlett-Packard Development
Company, IBM - International Business Machines Corporation e Unisys, associaes entre
institutos de pesquisa ou projetos governamentais. Durante os ltimos trinta anos,
existiram vrias iniciativas para criao de fbricas de software em diferentes partes do
mundo, cada uma delas adotando diferentes estratgias para organizao e execuo de
suas atividades, enquanto algumas tinham o foco na adoo de processos, outras
priorizavam a adoo de ferramentas de automao.
Com a constante evoluo da engenharia de software e das tecnologias envolvidas
no desenvolvimento de sistemas, as fbricas sero cada vez mais efetivas dentro de seu
objetivo de produzir softwares de qualidade, em pouco tempo e por um baixo custo espera-
se, portanto, um crescimento ainda maior na adoo deste modelo para o desenvolvimento
de sistemas.
Atravs das novas facilidades tornaram possveis tambm que empresas de mdio e
at de pequeno porte, pudessem montar suas fbricas de software para prestar servios de
desenvolvimento de sistemas crescente terceirizao do mercado, resultando numa
proliferao deste novo modelo de fbrica pelo mundo.
Neste contexto, as fbricas de software podem constituir ncleos de
desenvolvimento dentro de grandes empresas ou serem empresas independentes. Alm
disso, o escopo do processo dentro do ciclo de desenvolvimento de software varia
conforme a fbrica. Existem fbricas de software que prestam servios desde a anlise de
sistemas e outras que trabalham a partir da fase de implementao.
Desta forma, as fbricas de software podem se tornar estruturas complementares
organizao do cliente, ampliando de forma eficaz e qualificada a capacidade de
atendimento demanda de servios de software.
Fbricas localizadas na ndia exportam muitos servios de programao de
aplicaes para os EUA Estados Unidos da Amrica e pases da Europa, cujos mercados
de tecnologia da informao so os maiores do mundo. Entretanto, grandes investimentos
13
na criao de fbricas de software vm sendo realizados no Brasil, China e Rssia,
conforme Computerworld (2006).
Ainda em Computerworld (2006), so listadas cinco razes para esse crescimento
das fbricas de software no Brasil:
1. O Brasil se tornou uma opo interessante para exportao de programao
devido desvalorizao cambial em relao aos EUA e ao baixo custo de
homem/hora;
2. Grande parte dos trabalhos de fbrica de software decorrente de reviso de
processos ou projetos de integrao como, por exemplo, servios de
customizao de produtos produzidos por multinacionais para o mercado
brasileiro;
3. As arquiteturas de sistemas so projetadas fragmentadas em camadas, o que
possibilita o desenvolvimento remoto de partes desses fragmentos;
4. O crescimento de fbricas que possuem conhecimentos de negcios e
prestam servios de anlise de sistemas, e no apenas implementao;
5. A tendncia existente de terceirizao de servios por parte de empresas que
se concentram em suas atividades principais e transferem para parceiros as
atividades que no esto diretamente ligadas ao seu negcio principal.
O conceito de fbrica de software est baseado na idia de ter uma linha de
produo de sistemas (software) a partir de requisitos levantados por um cliente da
fbrica. Essa produo deve ser realizada de preferncia sem a necessidade de
comunicao dos profissionais da linha de produo (desenvolvedores) com os usurios,
analistas e projetistas e de acordo com um escopo, cronogramas e padres pr-
estabelecidos de qualidade e de projeto.
Para que a fbrica funcione com sucesso e os resultados atendam s expectativas do
cliente fundamental a adoo de um processo que considere todo o ciclo de
desenvolvimento, assim como auxilie no gerenciamento (planejamento e controle) de todas
as atividades e recursos envolvidos nos projetos. Dessa forma possvel medir e controlar
a produtividade da equipe envolvida.
2.4. Gerncia de Configurao de Software (GCS)

A Gerncia de Configurao (GC) surgiu nos anos 50 devido necessidade da
indstria aeroespacial norte-americana controlar as modificaes na documentao
14
referente produo de avies de guerra e naves espaciais, segundo Leon (2000), Estublier
et al. (2002), Hass (2003). Posteriormente, nos anos 60 e 70, a GC passou a abranger
artefatos de software, indo alm dos artefatos de hardware j estabelecidos e
desencadeando o surgimento da Gerncia de Configurao de Software (GCS), como pode
ser visto em Christensen et al.(2002).
Apesar do surgimento da GCS nos anos 70, o seu foco era muito restrito s
aplicaes militares e aeroespaciais, e somente no final dos anos 80, com o surgimento do
padro IEEE Std 1042 (IEEE, 1987), e em meados dos anos 90, com o surgimento da
norma ISO 10007 (ISO, 1995), a GCS foi finalmente assimilada no processo de
desenvolvimento de software de organizaes no militares, segundo Leon (2000).
Segundo Bersoff (1984), a Gerncia de Configurao de Software (GCS) nasceu
como resposta aos erros cometidos durante os anos 70, quando computadores comearam a
ser utilizados de maneira geral para a soluo dos mais diversos e complexos problemas
para os quais o gerenciamento tradicional mostrou-se inadequado. Principalmente, quando
se descobriu que a complexidade de gerenciamento de um sistema no variava de maneira
linear com o nmero de linhas de cdigo, mas de maneira exponencial.
Como toda nova rea de pesquisa, existem diversas definies para GCS.
Babich (1986) define a arte de coordenar o desenvolvimento de software para
minimizar ... confuso chamada de gerncia de configurao. A gerncia de configurao
a arte de identificar, organizar e controlar modificaes no software que est sendo
construdo por uma equipe de programao. O objetivo maximizar a produtividade pela
minimizao dos erros.
Estublier (2000) diz que GC a disciplina que permite evoluir produtos de software
de forma controlada, e, desta forma, contribui na satisfao de restries de qualidade e de
tempo.
Contudo, a definio mais aceita e utilizada, atualmente, caracteriza a GCS como
uma disciplina que aplica procedimentos tcnicos e administrativos para identificar e
documentar as caractersticas fsicas e funcionais de itens de configurao, controlar as
alteraes nessas caractersticas, armazenar e relatar o processamento das modificaes e
verificar a compatibilidade com os requisitos especificados e garantir que foi feito o que
deveria ter sido feito. (IEEE, 1990).
Desta forma, a GCS no se prope a definir quando e como devem ser executadas
as modificaes nos artefatos de software, papel este reservado ao prprio processo de
15
desenvolvimento de software. A sua atuao ocorre como processo auxiliar de controle e
acompanhamento dessas atividades.
Como observa Babich (1986), ela uma disciplina til para a gerncia do projeto,
pois lhe permite executar tarefas complexas de uma maneira mais organizada, o que
proporciona aumento de produtividade e reduo de erros.
No processo de produo de software, um objeto em desenvolvimento no tem um
comportamento esttico, ele evolui com o tempo. Chama-se de verso ao estado particular
de um objeto e, por configurao, entende-se a relao entre as verses de um objeto
composto, ou seja, configurao uma instncia do sistema composta da unio de uma
verso especfica de cada objeto componente, segundo Victorelli (1990).
De acordo com Capretz (2002), a Gerncia de Configurao de Software no
fornece um mtodo de projeto, nem um modelo de ciclo de vida, nem, tampouco, define
como a qualidade dos itens deve ser julgada; ela fornece um fundamento slido para todas
as outras atividades de engenharia de software. Pode-se defini-la como uma disciplina para
gerenciamento efetivo da produo de software. Cabe a ela identificar a configurao de
um sistema em relao ao tempo com a finalidade de, sistematicamente, controlar as
mudanas desta configurao, manter sua integridade e, desta forma, possibilitar seu
rastreamento atravs do ciclo de vida do sistema, segundo Babich (1986).
Inicialmente, a preocupao da GC estava voltada basicamente para a equipe de
programao, o que no ocorre mais hoje.
A gerncia de configurao atualmente abrange todas as pessoas envolvidas com o
projeto de software, sejam elas analistas de requisitos, implementadores, testadores,
gestores da qualidade, dentre outros.
Uma concepo errnea, mas bastante freqente em algumas organizaes, consiste
em julgar que a gerncia de configurao garantida pelo simples fato da empresa utilizar
uma ferramenta de controle de verses. Na realidade, a GCS envolve todo um conjunto de
regras e procedimentos, que so apenas parcialmente automatizveis.
Em relao confuso, de acordo com Babich (1986), ela surge quando as
modificaes no so analisadas antes de serem feitas, no so registradas antes de serem
implementadas, no so relatadas queles que tm necessidade de saber delas ou no so
controladas no sentido de melhorar a qualidade e reduzir os erros.
As modificaes em um produto de software so inevitveis durante seu ciclo de
vida. Elas podem ocorrer pelo surgimento de novas necessidades dos clientes, que exigem
16
modificaes nos dados produzidos por sistemas de informao ou at mesmo por
restries de oramento ou cronograma, que causam redefinies no sistema ou produto.
Como as mudanas nos produtos de software so intrnsecas, se no forem bem
controladas, podem levar perda de controle do produto e, como conseqncia,
comprometer sua integridade e qualidade.
Para entender melhor a definio de GCS e, tambm, suas atividades, so
necessrias algumas definies sobre o tema.
Villas Boas (2003) assume que configurao so caractersticas fsicas e funcionais
de um produto, conforme definidas na documentao tcnica obtidas no produto. E diz
ainda, que documentos de configurao so documentos (em qualquer tipo de mdia) que
definem os requisitos, projeto, construo/produo e verificao para um item de
configurao.
Durante o processo de desenvolvimento de um produto, produzida uma grande
quantidade de itens de informao que podem ser alterados durante o processo, a esses
itens d-se o nome de item de configurao (IC). Segundo Villas Boas (2003), IC o
conjunto de materiais e equipamentos, informaes, materiais processados, servios ou
qualquer de suas partes distintas, que designado para a gerncia de configurao e tratado
como entidade nica no processo de GCS. todo e qualquer ente passvel de manipulao,
ou seja, que possa ser univocamente identificado e gerenciado. So normalmente
considerados ICs, documentos, modelos e cdigo (seja fonte, executvel, etc.).
Para que cada item de configurao possa ser efetivamente gerenciado necessrio
o estabelecimento de pontos bem definidos dentro do processo de desenvolvimento: as
baselines, que tambm so chamadas na literatura como linhas de referncia ou linhas de
base ou configurao-base.
Segundo Villas Boas (2003), baseline uma especificao ou produto que tenha
sido formalmente revisto e acordado e que, a partir de ento, serve como base para
desenvolvimento futuro, podendo ser alterado apenas com o uso de um procedimento
formal de alterao.
Esses pontos podem ocorrer ao final de cada uma das fases do processo de
desenvolvimento ou de algum outro modo definido pela gerncia. Nos pontos
estabelecidos pelas baselines, os itens de configurao devem ser identificados, analisados,
corrigidos, aprovados e armazenados em um local sob controle de acesso denominado
repositrio dos itens de configurao.
17
Quando um projeto de software no utiliza gerncia de configurao podem ocorrer
problemas como: perda de cdigo-fonte, indisponibilidade e/ou dificuldade na
determinao de verses de software a serem mantidas, impossibilidade de se gerenciar as
bibliotecas de software necessrias ao funcionamento de um sistema, falta de sincronismo
entre as atividades realizadas, dentre outros.
A inadequao no ambiente de produo para a implantao do produto, a ausncia
de controle sobre alteraes efetuadas em documentos de apoio e no prprio cdigo-fonte e
de informaes sobre a composio de uma determinada verso de sistema so outros
problemas freqentes ocasionados pela falta de GCS.
Segundo Pressman (2002), importante salientar que gerncia de configurao de
software um conjunto de atividades de acompanhamento e controle que comea quando o
projeto de engenharia de software tem incio e s termina quando o software retirado de
operao. Por este motivo considerada uma atividade guarda-chuva, visto que pode
estar sendo executada durante todo o projeto, pois mudanas podem ocorrer a qualquer
momento.
Dentre os benefcios que podem ser obtidos com a implementao adequada de
GCS destacam-se: o controle efetivo e sistematizado do que produzido, a gerao de
registro documental sobre o andamento evolutivo dos sistemas e suas alteraes, facilidade
de distribuio e nivelamento do conhecimento absorvido ao longo de todo o
desenvolvimento realizado, tornando possvel a rastreabilidade dos componentes que se
encontram sob controle.
2.4.1. Funes da Gerncia de Configurao

Conforme IEEE (1990), norma NBR ISO 10007 da ABNT (1996), Bersoff (1984) e
outros autores, a GCS dividida em quatro funes: identificao da configurao (que
itens constituem uma configurao), controle da configurao (que passos no processo de
alterao afetam uma configurao), auditoria da configurao (quais so as diferenas
entre as verses) e contabilizao da situao de configurao (que modificaes foram
feitas por determinado programador).
2.4.1.1. Identificao da Configurao

Esta atividade consiste em nomear de maneira nica os componentes de uma
configurao. Estes componentes bsicos so os itens de configurao. Um IC pode ser
18
tanto um trecho de cdigo quanto um documento, e deve ficar a cargo do projeto de
controle de configurao definir quais sero os ICs do projeto que sero controlados.
A forma de nomeao dos ICs completamente livre, mas deve ser padronizada
dentro do projeto. Pode-se aproveitar a estrutura do produto (quando ela for hierrquica) ou
uma outra forma qualquer. Para a indicao numrica, pode-se adotar, por exemplo, o uso
de dois numerais, sendo o primeiro a indicao da configurao e o segundo a indicao da
verso do IC. No entanto, hoje em dia esta informao fornecida automaticamente pelas
ferramentas de controle.
O padro da ABNT/ISO para Gerncia de Configurao, conforme visto em ABNT
(1996), prev as seguintes funes dentro dessa atividade:
1. Seleo dos itens de configurao: Os ICs devem ser escolhidos pelo processo
de decomposio.
2. Determinao da estrutura da configurao: Esta estrutura deve descrever a
posio de cada IC que compe o projeto. O uso de uma estrutura hierrquica
recomendvel.
3. Documentao dos itens de configurao: Todas as caractersticas fsicas e
funcionais de um item (interfaces, alteraes, desvios e concesses) devem ser descritas
em documentos bem identificados.
4. Sistema de numerao: Um sistema de identificao deve ser escolhido para
garantir unicidade na identificao dos ICs.
5. Estabelecimento de configuraes bsicas: Configuraes bsicas (baselines)
devem ser estabelecidas atravs de um acordo formal em determinados pontos do ciclo de
vida do projeto e utilizadas como ponto de partida para o controle formal da configurao.
Estes pontos podem ser as mudanas de fase no ciclo de vida, bem como, marcos
estabelecidos no cronograma do projeto ou at mesmo necessidades emergenciais.
2.4.1.2. Controle de Configurao

A funo de controle de configurao designada para o acompanhamento da
evoluo dos ICs selecionados e descritos pela funo de identificao.
Segundo Bersof (1984), o conceito de baseline um dos fundamentos da Gerncia
de Configurao. A gerao de uma baseline o momento no qual acordado que um ou
mais IC est em conformidade com os requisitos do projeto e deve ser protegido contra
alteraes no autorizadas. Aps o estabelecimento de uma configurao-base (baseline),
19
toda e qualquer alterao sobre os itens dessa configurao deve ser formalmente
controlada.
A baseline uma referncia para desenvolvimento futuro, permite a verificao e
recuperao das informaes, representa um marco definido no ciclo de desenvolvimento
do projeto e uma referncia para auditar o projeto.
O impacto da alterao, os requisitos do cliente e a configurao-base afetada
influenciam o grau de formalidade do processo de alterao e podem servir de base para
qualquer sistema de classificao utilizado para a classificao/categorizao de alteraes.
As seguintes atividades devem ser documentadas em detalhes no processo de
controle: documentao e justificao da alterao, avaliao das conseqncias da
alterao, aprovao/recusa dos pedidos de alterao, implementao e verificao das
alteraes, desvios e concesses.
A fim de proteger a integridade da configurao e fornecer a base para o controle
de alterao, essencial que os ICs sejam mantidos em um ambiente que: satisfaa as
condies ambientais necessrias (por exemplo, para hardware, software, dados,
documentos, diagramas.); proteja-os de alteraes no autorizadas e destruio acidental;
fornea mecanismos para recuperao; permita recuperao controlada de todos os dados
armazenados; proporcione consistncia entre a configurao construda e a especificada.
Dois controles bsicos so institudos no processo de gerncia de configurao:
controle de verso e controle de mudana.
Um item, ao ser desenvolvido, evolui at que atinja um estado que atenda os
propsitos para o qual foi criado. Isso implica em diversas alteraes, gerando uma verso
(reviso) do item a cada estado. Para estabelecer o controle sobre as diversas verses, todas
devem ser armazenadas e identificadas e, hoje, diversas ferramentas apiam essa atividade.
A importncia do controle de mudanas pode ser facilmente visualizada durante o
processo de desenvolvimento, onde mudanas descontroladas podem levar rapidamente ao
caos. Assim, deve-se instituir na organizao um processo que combine procedimentos
humanos e ferramentas automatizadas para proporcionar um mecanismo de controle de
mudanas eficaz.
Algumas das ferramentas de apoio s atividades de controle de verso e de
mudanas so apresentadas na seo 2.4.2 deste trabalho.
20
2.4.1.3. Contabilizao da Satisfao de Configurao
A contabilizao da situao da configurao consiste no registro e relato formais
das informaes necessrias para gerenciar a configurao de maneira efetiva. As
informaes englobam a listagem da identificao da configurao aprovada, o status das
mudanas propostas configurao e o status de implementao das mudanas aprovadas.
chamada, tambm, de contabilizao do status da configurao, relato da configurao,
entre outros.
De forma geral, a obteno de informaes sobre o status da configurao deve
comear assim que os ICs so gerados. Estas informaes devem permitir o rastreamento
de todas as alteraes efetuadas sobre os ICs. Desta maneira, pode-se saber quem efetuou
uma alterao, quando ela foi executada e o que foi feito, por exemplo.
2.4.1.4. Auditoria da Configurao

SEI (2002) define a auditoria da configurao como a auditoria conduzida para
verificar se um item de configurao est em conformidade com um padro ou requisito
especificados.
Segundo Bryan (1982) e o prprio IEEE (1993), auditoria o processo de examinar
um produto, sendo que esse processo executado por um grupo independente do grupo
que o produziu. Bryan tambm sustenta que quanto mais crtico o projeto em termos de
tamanho, custo ou cronograma, maior a necessidade de se ter um processo eficiente de
auditoria.
Pode-se dizer que auditoria o preo da qualidade no projeto, no sentido de que
atravs dela assegurado ao usurio que o produto (no caso o software) est de acordo
com os requisitos de desempenho e operacionais, ao cliente que ser entregue no prazo
especificado e dentro dos limites oramentrios e, por fim, ao fornecedor que seu produto
evoluiu de uma maneira rastrevel (e, portanto, manutenvel) e de acordo com as
expectativas do usurio final.
A auditoria de configurao deve ser executada antes que uma baseline seja
definida, para certificar que o produto est de acordo com os requisitos (de especificao e
contratuais) e tambm para garantir que est precisamente descrito em seus documentos
tcnicos.
Toda alterao tambm precisa ser auditada para garantir a integridade do produto
que est sendo produzido. Ou seja, ela utilizada para tornar visvel ao gerenciamento o
status do software ao longo do ciclo de vida do projeto e tambm para revelar se os
21
requisitos iniciais esto sendo satisfeitos e se a passagem de uma configurao a outra no
descaracteriza o produto.
Duas atividades so executadas neste processo: verificao e validao.
A verificao a atividade que assegura a coerncia entre as configuraes, ou seja,
toda configurao candidata a se tornar uma nova configurao-base deve ser verificada
com relao configurao-base anterior.
A validao a atividade que determina a coerncia entre as vrias configuraes-
base e a especificao de requisitos, ou seja, ela garante que cada configurao-base, em
cada estgio do ciclo de vida, est de acordo com os requisitos especificados.
2.4.2. Ferramentas de Apoio

Segundo Dias (2006), do ponto de vista das ferramentas existentes, a GCS
apoiada pelas mesmas nas atividades: Controle de Verso, Controle de Mudana e
Integrao Contnua.
O controle de verso a espinha dorsal de toda a gerncia de configurao,
apoiando as atividades de controle de mudana e integrao contnua. O sistema de
controle de verso rastreia e controla todos os artefatos do projeto (cdigo-fonte, arquivos
de configurao, documentao, etc.) e desse modo consegue coordenar o trabalho paralelo
de desenvolvedores.
Essas ferramentas oferecem servios como: identificao, armazenamento e
gerenciamento dos itens de configurao e de suas verses durante todo o ciclo de vida do
software; histrico de todas as alteraes efetuadas nos itens de configurao; criao de
rtulos e ramificaes no projeto; recuperao de uma configurao em um determinado
momento desejado do tempo.
O controle de verso de software uma prtica de engenharia de software
comprovadamente eficaz. Por isso, faz parte das exigncias para melhorias do processo de
desenvolvimento de certificaes tais como CMMI-SE/SW e MPS.BR.
O controle de mudanas fornece um servio complementar ao oferecido pelo
sistema de controle de verso. O foco desse tipo de ferramenta nos procedimentos pelos
quais as mudanas de um ou mais itens de configurao so propostas, avaliadas, aceitas e
aplicadas. Oferece servios para identificar, rastrear, analisar e controlar as mudanas nos
itens de configurao.
22
Para as necessidades da GCS, bastaria um controle de construo de software que
cuidasse da identificao, empacotamento e preparao de uma baseline para a entrega a
um cliente externo ou interno, tornando-a uma release2 ou uma build3, respectivamente.
A idia de utilizar uma integrao contnua, entretanto, vai um pouco mais alm. O
objetivo garantir que as mudanas no projeto so construdas, testadas e relatadas to
logo quanto possvel depois de serem introduzidas.
Em projetos de software, a construo do software feita pela recuperao da
configurao correta no sistema de controle de verso e a construo dos arquivos
executveis e de instalao do produto. Este processo executado geralmente aps cada
mudana publicada no sistema de controle de verso ou em intervalos de tempo pr-
definidos.
Geralmente, so combinadas duas ferramentas separadas: uma que faz a construo
do software e outra que monitora alteraes no controle de verso e dispara a primeira para
a construo.
Existem diversas ferramentas disponveis para apoiar atividades de GCS, como:
para controle de verso, Subversion, CVS, ClearCase, StarTeam; para controle de
mudana, Trac, Mantis, Bugzilla, Jira, FogBugz e para integrao mtua, Scons, Bitten,
Ant, AntHill Pro, FinalBuilder.
A quantidade de funcionalidades, a maturidade, a documentao e o suporte
disponveis, e a popularidade de cada ferramenta variam bastante. Embora as ferramentas
comerciais geralmente apresentem mais funcionalidades e um maior grau de integrao, o
custo de licenciamento muitas vezes torna o seu uso proibitivo principalmente para micro e
pequenas empresas de software.
As ferramentas open source4, por outro lado, possuem diversas vantagens alm do
custo mais baixo de aquisio tais como qualidade, segurana, independncia de
fornecedor, possibilidade de adequao a necessidades especficas, estabilidade e suporte
tcnico. Essas caractersticas tornam a escolha por ferramentas open source uma soluo
extremamente interessante no s para micro e pequenas empresas.
2
Release, que tambm chamada de liberao, o nome dado a uma verso disponibilizada para um
propsito especfico. Por exemplo, release para testes, liberao para entrega ao cliente.
3
Build a construo do sistema a partir dos itens fonte para uma configurao alvo.
4
Ferramenta open source, ou em portugus, cdigo aberto, um tipo de ferramenta cujo cdigo-fonte
pblico.
23
2.5. Consideraes Finais do Captulo
Neste captulo foram apresentados conceitos relacionados Engenharia e
Qualidade de Software, Melhoria do Processo de Software, Fbrica de Software e Gerncia
de Configurao de Software.
Depois de elaborado o estudo sobre as funes e as ferramentas de apoio gerncia
de configurao de software, foi possvel definir as que seriam utilizadas na implantao
no processo de desenvolvimento da empresa Beta.
24
3. METODOLOGIA
apresentada neste captulo a metodologia que foi aplicada no desenvolvimento
deste projeto e a descrio de como o estudo de caso foi realizado.
3.1. Tipo de Pesquisa

O mtodo de pesquisa utilizado neste trabalho foi a pesquisa-ao, de natureza
tecnolgica, com objetivos de carter exploratrio, utilizando procedimentos de estudo de
caso fundamentada em referncias bibliogrfica e documental (Jung, 2004).
A pesquisa-ao quando os pesquisadores e participantes representativos da
situao ou do problema esto envolvidos de modo cooperativo ou participativo.
Uma pesquisa que utiliza conhecimentos bsicos, tecnologias existentes,
conhecimentos tecnolgicos, e que tenha como objeto um novo produto ou processo
caracterizada como tecnolgica.
Pesquisa de carter exploratrio visa o aprimoramento de idias ou a descoberta de
intuies, ou seja, fornecer ao pesquisador um maior conhecimento sobre o tema ou
problema de pesquisa em questo. Este tipo de pesquisa proporciona maior familiaridade
com o problema, tornando-o mais explcito.
Segundo Jung (2004), normalmente, a pesquisa exploratria no exige grandes
teorizaes e, sim, a experimentao para coleta de dados que serviro de base para a
formulao de modelos inovadores ou explicativos.
Quanto aos procedimentos o tipo de pesquisa adotado foi o estudo de caso realizado
em campo, ou seja, a pesquisa foi realizada dentro da fbrica de software da empresa
Beta.
O estudo de caso um estudo aprofundado e exaustivo de um ou de poucos objetos,
de maneira a permitir o seu conhecimento amplo e detalhado. adequado para explorar
situaes da vida real, descrever a situao do contexto em que est sendo feita
determinada investigao e explicar as variveis causais de determinado fenmeno em
situaes muito complexas.
Atravs do estudo de caso foi possvel explicar e descrever um objeto dentro do
contexto local e real e correlacion-lo ao que existe na literatura sobre o tema, nesse
trabalho o objeto de estudo o processo de gerncia de configurao na organizao
Beta.
O embasamento terico da pesquisa imprescindvel e nesse trabalho as referncias
adquiridas foram atravs de estudo e referencial bibliogrfico e documental.
Conforme Jung (2004), a pesquisa bibliogrfica tem por finalidade principal formar
uma consistente base mental a partir daquilo que existente, e oportunizar uma ampla
aquisio de conhecimentos para o entendimento substancial do assunto, viabilizando ao
pesquisador ousar ao propor novos argumentos que justifiquem as descobertas.
Ainda de acordo Jung (2004), assim como a pesquisa bibliogrfica, a documental
visa formular uma base consistente de conhecimentos ao pesquisador, fornecendo a estas
fontes subsidirias para importantes aplicaes referenciais. A diferena existente entre
uma e outra consiste no tipo e estado de tratamento do material textual. As informaes
existentes em documentos so muitas vezes de carter indito e, por isto, esta fonte
indispensvel ao processo de pesquisa e pode representar um diferencial na formulao dos
argumentos.
Os documentos analisados na empresa Beta foram o seu processo de
desenvolvimento de software, seus templates, polticas e manuais.
3.2. Procedimentos Metodolgicos

O trabalho iniciou-se com o interesse pessoal da autora em aprofundar seus
conhecimentos em Engenharia de Software, mais especificamente na disciplina Gerncia
de Configurao e tornou-se possvel com o apoio da empresa Beta, estudo de caso.
A pesquisa foi realizada no perodo de abril a agosto de 2006, no ambiente de
desenvolvimento da fbrica de software da empresa Beta.
A primeira etapa foi definir o tema da pesquisa a ser realizada, bem como, o
problema a ser investigado.
Em seguida, foi realizada uma reviso bibliogrfica sobre os aspectos da engenharia
e qualidade de software, melhoria do processo de software, fbrica de software e gerncia
de configurao de software, a fim de se obter maior conhecimento sobre os temas
abordados.
Na seqncia, buscou-se conhecer a empresa, atravs de um diagnstico da situao
atual da empresa no que se refere gerncia de configurao, que foi realizado pela
pesquisadora desse trabalho no ambiente de desenvolvimento da organizao Beta.
A partir desse diagnstico, foi planejada a implantao e definidas as atividades
relacionadas s prticas de gerncia de configurao que seriam incorporadas ao processo
26
de desenvolvimento de software da organizao. Tambm foram selecionados projetos
pilotos para a implantao de tais prticas possibilitando, assim, uma avaliao da
implantao.
As prticas de gerncia de configurao implantadas no processo de
desenvolvimento foram adaptadas realidade da empresa estudada, levando em
considerao o fato se tratar de uma empresa de pequeno porte, jovem e com poucos
recursos humano e financeiro para o desenvolvimento desse trabalho.
No processo de execuo da implantao foram institucionalizadas as prticas
atravs de treinamentos realizados com todos os colaboradores da empresa,
principalmente, os envolvidos nos projetos pilotos.
Aps a implantao nos projetos pilotos, ocorreu um processo de avaliao da
implantao onde foram identificadas inconsistncias, melhorias s prticas de GCS
definidas.
Ao final, o consenso da adoo das prticas de GCS em todos os projetos da fbrica
de software da empresa Beta foi estabelecido.
27
4. RESULTADOS E DISCUSSO
Neste captulo apresenta-se o estudo de caso realizado na empresa desenvolvedora
de software Beta e as principais atividades que foram executadas para a implantao de
prticas de gerncia de configurao no processo de desenvolvimento da empresa.
4.1. Caracterizao da Empresa

A empresa utilizada como estudo de caso, est situada na cidade de Lavras MG.
uma empresa da rea de Tecnologia da Informao (TI) que tem como principais reas
de atuao:
Fbrica de Software: atua no mercado de TI, desenvolvendo solues eficientes,
que trazem grandes transformaes, gerando retornos financeiros e operacionais
aos seus clientes;
Ensino a Distncia: oferece suporte tcnico e operacional para cursos
ministrados a distncia (ambiente virtual de ensino a distncia).
A empresa conta atualmente em seu quadro de funcionrios com 30 (trinta)
colaboradores, sendo 14 (quatorze) profissionais graduados em Cincia da Computao e
16 (dezesseis) estagirios do curso de Cincia da Computao da Universidade Federal de
Lavras UFLA.
Apesar de ser uma empresa jovem apenas 4 (quatro) anos e formada por
profissionais recm-formados e estagirios, o comprometimento com a qualidade de seus
produtos sempre foi tomada como uma premissa dentro da organizao.
4.2. Diagnstico das Prticas de Gerncia de

Configurao Atuais
Com o intuito de planejar as atividades de gerncia de configurao de software e
saber o estado atual da empresa, com relao s prticas desta disciplina, foi feito um
diagnstico na empresa. Esse diagnstico foi realizado com a participao dos
colaboradores que possuam vises tcnicas, gerenciais e administrativas dos projetos
executados pela empresa.
O diagnstico foi executado atravs de entrevista com os colaboradores, anlise do
processo definido da empresa, bem como, participao ativa da pesquisadora em projetos
da empresa, onde se evidenciou toda a situao da empresa no contexto da GCS.
Apesar de a empresa possuir um processo de desenvolvimento de software
definido, esse no tratava a gerncia de configurao formalmente. No existia
institucionalizao do uso das prticas de gerncia de configurao, como tambm no
havia documentao especfica a ser aplicada ao processo de desenvolvimento do produto
da empresa.
As funes da gerncia de configurao no estavam presentes nem mesmo
informalmente no processo da empresa. No existiam atividades que fizessem a
identificao da configurao, o controle da configurao, a contabilizao da situao da
configurao e a auditoria da configurao. Nem mesmo, parte dessas atividades eram
realizadas.
A nica iniciativa que existia na empresa era a utilizao da ferramenta FreeVCS
para o controle de verso. Porm, na prtica, essa ferramenta auxiliava apenas o controle
de concorrncia entre os desenvolvedores, cuja poltica trava-modifca-destrava (ver
Figura 4.1) e a cpia da verso mais atual de cada um dos arquivos que se encontravam no
repositrio para a local de trabalho dos desenvolvedores (ver Figura 4.2).
29
Figura 4.1 - Poltica "trava-modifica-destrava"
Fonte: Dias (2006)
Figura 4.2 - Cpia dos arquivos do repositrio para o local de trabalho

Fonte: Dias (2006)
A imaturidade com relao disciplina GCS era notria na empresa, pois muitos
colaboradores ligados diretamente ao desenvolvimento de software nem mesmo conheciam
30
termos e conceitos importantes dessa disciplina como: baseline, branch5, tag6, release,
contabilizao da situao, entre outros. O fato de serem termos em ingls poderia levar
errnea concluso de que as pessoas no conheciam tais termos por serem estrangeiros;
porm quando apresentados os seus mais diversos sinnimos, como: linha de base,
ramificao, rtulo, liberao esses tambm no eram conhecidos.
As especificaes dos recursos de hardware e software a serem utilizados por um
projeto no eram documentadas, eram informaes que as pessoas no possuam dentro da
organizao. Por exemplo, no existia documento que informasse em um projeto
desenvolvido (ou a ser desenvolvido) quais eram as configuraes necessrias para as
mquinas da equipe do projeto (processador, memria), software a serem utilizados pela
equipe de desenvolvimento (sistema operacional, servidor web, sistema gerenciador de
banco de dados), polticas de backup.
A empresa no possua um responsvel pela GCS, nem tampouco, alguma pessoa
que possua um conhecimento mais aprofundado nas funes e atividades da GCS. A
empresa ainda no estava ciente da necessidade e suma importncia de se institucionalizar
as prticas de GCS no processo de desenvolvimento dentro da organizao e definir
responsveis para desempenhar as atividades de GCS.
No havia, no histrico da organizao, tentativa de implantao de prticas de
GCS, nem mesmo, projetos que aplicavam essas prticas de forma isolada; porm a
necessidade dessa implantao apresentava-se cada vez mais nos projetos onde diversos
problemas ocorriam pela falta de GCS.
Problemas que aconteciam comumente durante o desenvolvimento dos projetos da
empresa eram: perda de cdigo-fonte; impossibilidade de determinar o que aconteceu com
um programa, ou parte dele; e, tambm, de determinar quem, por que e quando foram
efetuadas modificaes; desaparecimento de requisitos documentados e implementados;
programa em execuo e seu cdigo-fonte em diferentes verses.
Esses foram os principais pontos fracos da organizao no que se refere GCS,
porm foram levantados pontos fortes tambm.
Atravs do diagnstico foi possvel perceber que como pontos fortes a organizao
possua o fato de ter se submetido implantao de melhorias do processo de
5
Branch, tambm conhecida como ramo ou ramificao, uma verso que no segue a linha principal de
desenvolvimento.
6
Tag, tambm chamada de rtulo ou etiqueta, o mecanismo usado para identificar uma configurao.
31
desenvolvimento recentemente e, com isso, existir uma conscientizao da necessidade de
melhorias contnuas e buscar alternativas de se contornar os seus pontos francos.
Os colaboradores sentiam que mudanas deveriam acontecer para evitar diversos
problemas, porm no sabiam que a implantao de prticas de GCS remediaria boa parte
destes problemas.
Com o diagnstico, a organizao percebeu que se implantadas e seguidas essas
novas prticas poderiam minimizar um nmero muito grande de problemas que ocorriam
durante o desenvolvimento, bem como, produzir softwares com mais qualidade.
A empresa motivou-se a buscar a identificao e o detalhamento dessas prticas,
para que as mesmas fossem adotadas de fato. Achou-se conveniente que a implantao
ocorresse de maneira mais suave, evitando alteraes bruscas na cultura da organizao.
4.3. Planejamento da Implantao das Prticas de

GCS na Empresa
A implantao das prticas de GCS no processo de desenvolvimento de software da
empresa foi planejada e separada por 5 (cinco) etapas que so apresentadas na Figura 4.3:
Figura 4.3 - Etapas da Implantao das Prticas de GCS

Fonte: Elaborado pela autora
4.3.1. Auditoria da Implantao

Para a implantao das prticas de gerncia de configurao de software foram
realizadas auditorias durante toda a execuo deste projeto. Dentro de cada uma das etapas,
as atividades foram submetidas auditoria. Pensou-se inicialmente em realizar a auditoria
somente na transio de cada uma das etapas, porm essa proposta mostrou-se invivel. A
32
complexidade e o alto impacto de algumas atividades dentro de algumas etapas deveriam
ser acompanhadas com um pouco mais de cuidado para no afetassem de forma negativa
os projetos e a organizao como um todo.
Na empresa Beta existe um grupo chamado SEPG (Software Engineering Process
Group) que responsvel pela definio, manuteno e melhoria do processo de software
da organizao. A execuo da auditoria da implantao ficou sob sua responsabilidade.
Essa escolha fundamentou-se no fato desse grupo ter total conhecimento do processo
definido na empresa; ter um compromisso com a busca contnua de melhorias e qualidade;
o mesmo j possuir experincia em auditorias de outras naturezas, entre outros.
A funo da auditoria se resumiu em acompanhar cada uma das etapas e verificar
se as atividades propostas dentro das mesmas estavam sendo executadas corretamente e no
tempo estimado. Caso isso no estivesse acontecendo, analisavam-se as causas, os
impactos e propunham-se solues alternativas para contornar os problemas.
4.3.2. Elaborao do Plano de Implantao

A partir dos resultados encontrados no diagnstico e visando uma melhor conduo
das atividades relacionadas ao projeto, foi elaborado um plano de ao denominado Plano
de Implantao.
O Plano de Implantao um plano de ao que identifica os objetivos do projeto,
quais os impactos do mesmo sobre a organizao, o mtodo de trabalho que ser utilizado,
as aes especficas e os recursos necessrios para a implantao das prticas de GCS no
processo de desenvolvimento de software.
Assim, nessa etapa de implantao, foi elaborada a documentao de aes que
deveriam ser executadas dentro do propsito de implantar as prticas de GCS na
organizao atendendo principalmente o que foi detectado no diagnstico realizado.
4.3.3. Execuo do Plano de Implantao

As atividades relacionadas implantao das prticas de gerncia de configurao
foram descritas no template7 denominado Plano de Gerncia de Configurao. Nesse
plano apresentado como e quando as atividades sero efetuadas, quem sero os
responsveis por elas e quais recursos sero necessrios. O plano de gerncia de
7
Template um modelo de documento definido como padro e que utilizado no processo de
desenvolvimento de software.
33
configurao foi desenvolvido de acordo com as peculiaridades da empresa e tambm as
atividades que compem a GCS, segundo NBR ISO 10007, ABNT (2006).
Foi recomendado que o plano de gerncia de configurao adotasse padres que
tinham maior compatibilidade com o projeto para o qual o plano estivesse sendo escrito, ou
seja, que sempre fosse adaptado para a realidade do projeto, levando-se em considerao
tecnologia, escopo do projeto, enfim, s necessidades do mesmo. No Apndice A deste
trabalho, apresentado o Plano de Gerncia de Configurao.
Foram apresentadas as responsabilidades na execuo das prticas para os diversos
papis dos colaboradores dentro da organizao. Criou-se um grupo de gerncia de
configurao (CMG Configuration Management Group) na empresa, que seria o
responsvel por aplicar melhorias constantes nas diversas atividades definidas no processo
de GCS. Esse grupo foi formado por um gerente de configurao, um membro do grupo
SEPG, o gerente do projeto e um membro da equipe de infra-estrutura da empresa,
podendo ter mais de um colaborador na mesma rea, porm no menos que esta estrutura
de quatro integrantes e das reas descritas.
Como a empresa no possua condies para alocar uma grande quantidade de
colaboradores para integrarem o CMG, nem mesmo, condies de permitir que os
integrantes se dedicassem exclusivamente ao grupo, decidiu-se que as funes
desempenhadas pelo grupo seriam realizadas paralelamente s suas demais funes dentro
da organizao.
Houve a elaborao do Plano de Ambiente, cujo objetivo definir formalmente os
recursos de hardware e software a serem utilizados por um projeto. Por exemplo, todo
projeto desenvolvido (ou a ser desenvolvido) possuir um documento ao qual sero
encontradas informao como: quais foram as configuraes necessrias para as mquinas
da equipe do projeto (processador, memria), softwares e suas verses utilizados pela
equipe de desenvolvimento (sistema operacional, servidor web, sistema gerenciador de
banco de dados), polticas de backup. O Plano de Ambiente encontra-se no Apndice B.
Foi desenvolvido um Glossrio de Gerncia de Configurao para que todos os
envolvidos no desenvolvimento passassem a conhecer os conceitos acerca das novas
prticas implantadas no processo de desenvolvimento do software, uma vez que, o
diagnstico apontou como fato o desconhecimento da disciplina GCS e dos conceitos a ela
vinculados. Termos da lngua estrangeira foram apresentados, neste glossrio, tambm
com sua traduo para o portugus para facilitar a familiarizao com os conceitos
34
contidos nas prticas de GCS. O Glossrio de Gerncia de Configurao apresentado no
Apndice C.
Decidiu-se migrar da ferramenta FreeVCS para o Subversion para a realizao de
do controle de verso dos itens de configurao. O pouco suporte oferecido pelo FreeVCS
s funes de GCS, motivou essa migrao. A escolha do Subversion baseou-se em
diversos fatores, como: ser uma ferramenta open source; oferecer suporte a funes
importantes para o controle da verso como branch, tag; utilizar a poltica copia-
modifica-resolve (ver Figura 4.2) para o controle de concorrncia e ainda permitir o
travamento de arquivos que no podem ser mesclados com facilidade (merge8);
armazenamento atravs de versionamento de diferenas9 (delta) no repositrio, reduzindo o
espao requerido em disco; entre outros.
8
Merge, nesse contexto, significa mesclar os arquivos modificados simultaneamente.
9
Versionamento de diferenas, tambm chamado de versionamento delta, a forma pela qual os ICs so
armazenados no repositrio. Nesse caso, o repositrio armazena apenas as modificaes sofridas pelo IC, ou
seja, no salva tudo novamente, apenas o que foi alterado.
35
Figura 4.4 - Poltica "copia-modifica-resolve"
Fonte: Dias (2006)
Foi realizada uma adaptao dos fluxos de bugs10 e requisitos do processo de teste
para que os mesmos auxiliassem e atendessem s prticas relacionadas ao controle de
mudanas. Os fluxos foram desenhados baseados na utilizao da ferramenta Mantis.
Essa ferramenta j utilizada na organizao para o processo de relatos de erros e
inconsistncias encontradas e para atribuio de atividades como a implementao de
requisitos para os desenvolvedores.
Com isso, viabilizou-se o uso tambm dessa ferramenta para se aplicar o controle
de mudanas, assim, a execuo dessa atividade tornou-se menos complicada e mais
atrativa para os envolvidos, uma vez que foram adicionadas atividades s que os
colaboradores j desempenhavam.
Aps reunies com os membros do SEPG, as prticas de GCS foram definidas, os
templates gerados, planos e documentos, a ferramenta Subversion foi adotada e melhorias
foram aplicadas baseando-se nos procedimentos j existentes na empresa.
10
Um bug, nesse contexto, qualquer falha encontrada no software que o impede de funcionar como
esperado.
36
4.3.4. Institucionalizao das Prticas de GCS
Para a institucionalizao das prticas implantadas no processo de desenvolvimento
da empresa foi realizado treinamento com todos os colaboradores envolvidos no processo
de desenvolvimento de software, onde foi exposto: em qual momento do desenvolvimento
as novas prticas seriam aplicadas; a utilidade de cada um dos documentos, templates e
planos e como esses deveriam ser utilizados e, principalmente, a importncia de se adotar
essas prticas definidas.
Tambm foram apresentadas palestras a fim de familiarizar cada vez mais os
colaboradores com novas atividades por eles desempenhadas e, tambm, incentiv-los a
utilizar o que foi definido da forma desejada.
Os temas dessas palestras foram: Introduo Gerncia de Configurao de
Software, onde foram introduzidos os conceitos iniciais (apresentao formal do
Glossrio de Gerncia de Configurao), as principais atividades dentro da disciplina GCS
e o fluxo sinttico da gerncia de configurao; Utilizao do Subversion, apresentando
as principais funes da ferramenta e o fluxo de operao desta ferramenta; Utilizao e
preenchimento dos Templates Planos, Documentos e Outros Artefatos, exposio de
todos os artefatos relacionados s prticas de GCS mostrando em cada um desses artefatos
os seus objetivos, suas sees e subsees, simulando o preenchimento dos mesmos tanto e
conscientizando sobre a importncia do correto preenchimento tanto para o projeto como
para a organizao.
Foram selecionados dois projetos pilotos da organizao para a implantao das
prticas de GCS: Sistema de Administrao Escolar e Sistema Integrado de Venda de
Imveis. O primeiro um sistema de administrao de escolas de ensinos fundamental e
mdio; conta com cadastros de alunos, professores, turmas alm de lanar alunos em uma
srie, disciplinas para um professor, notas e faltas de um aluno e, tambm, gerar boletim,
histrico escolar, entre outros. O segundo trata-se de um sistema que automatiza a venda
de imveis e formando por cinco mdulos: contbil, financeiro, administrativo, comercial
e relatrios, englobando em seus mdulos funcionalidades como cadastros desde o
loteamento at a forma de pagamento das vendas de lotes, gerao de boletos bancrios,
controle financeiro dos diversos setores da empresa, alm de emitir relatrios de lotes
venda, contas em atraso, projetos dos loteamentos, entre outros.
37
Nesses projetos foi possvel verificar o uso das prticas, bem como, suas
inconsistncias, erros existentes e procedimentos desnecessrios que somente estavam
burocratizando o processo de desenvolvimento.
4.3.5. Avaliao da Implantao

Ao final da implantao das prticas de gerncia de configurao de software foi
realizada uma avaliao, levando em conta todos os envolvidos neste projeto e os
resultados desta avaliao so apresentados ao final da seo 4.5 deste trabalho.
4.4. Implantao das Prticas de GCS

Aps a realizao de todas as atividades citadas acima e uma auto-avaliao, as
prticas de GCS inseridas ao novo processo de desenvolvimento de software da empresa
mostraram-se como uma forma vivel e aplicvel, no somente aos dois projetos pilotos,
mas a todos os outros projetos da organizao.
As prticas de gerncia de configurao definidas foram: desenvolvimento do plano
de gerncia de configurao, definio do plano de ambiente, identificao da
configurao, controle da configurao, contabilizao da situao da configurao e
auditoria da configurao, conforme ilustra a figura 4.5.
Figura 4.5 - Prticas de Gerncia de Configurao

38
Para cada uma das macro-atividades das prticas de GCS foram definidas outras
atividades para que fossem gerados os produtos de trabalho que, nesse contexto, so os
artefatos que devem ser produzidos ao longo do processo de gerncia de configurao de
software.
As prximas subsees descrevem as prticas que foram definidas para serem
aplicadas ao longo do processo de desenvolvimento da empresa Beta.
4.4.1. Plano de Gerncia de Configurao

O propsito do Plano de Gerncia de Configurao definir formalmente as
ferramentas a serem utilizadas e os procedimentos a serem seguidos durante a evoluo do
software em desenvolvimento.
Os leitores alvo deste documento so os novos membros da equipe de um projeto.
Tambm, pode ser utilizado por membros experientes quando houver a necessidade da
aplicao de algum procedimento para gerncia de configurao.
Um plano de gerncia de configurao elaborado contendo as diretrizes que todo
projeto dentro da empresa deve seguir, alm das suas diretrizes especficas.
4.4.2. Plano de Ambiente

O Plano de Ambiente define os recursos de hardware e software a serem utilizados
por um projeto. Por exemplo, todo projeto desenvolvido (ou a ser desenvolvido) possuir
um documento ao qual sero encontradas informao como: quais foram as configuraes
necessrias para as mquinas da equipe do projeto (processador, memria), softwares e
suas verses utilizados pela equipe de desenvolvimento (sistema operacional, servidor
web, sistema gerenciador de banco de dados), polticas de backup.
Este plano tem como alvo novos membros do time de um projeto. Tambm, pode
ser usado por membros experientes quando houver a necessidade de realizar alguma
mudana no ambiente.
4.4.3. Identificao da Configurao

Nessa atividade so definidas as seguintes funes: seleo dos itens de
configurao; determinao da estrutura da configurao; documentao dos itens de
configurao; sistema de numerao; estabelecimento de baselines.
39
Sendo assim, inicialmente so selecionados os itens de configurao a serem
gerenciados. importante que sejam selecionados itens relevantes, porque uma
superdocumentao onera muito a gerncia de configurao. Geralmente, os itens mais
usados no ciclo de vida, os mais genricos, os mais importantes para a segurana, os
projetados para reutilizao e os que podem ser modificados ao mesmo tempo, sofrem
gerenciamento de configurao. Somente os itens selecionados sero controlados, sendo
que os outros itens podero ser alterados livremente.
Aps a seleo, determina-se a estrutura da configurao, ou seja, descreve-se
como esses itens se relacionam. A identificao dos relacionamentos muito importante
para a manuteno, pois permite que se localizem rapidamente os itens afetados
decorrentes de cada alterao.
Depois de escolhidos os itens e estabelecidos os relacionamentos, so descritas
todas as caractersticas fsicas e funcionais de um item (interfaces, alteraes, desvios e
concesses) em documentos bem identificados.
Depois definido um esquema de identificao dos itens, com a atribuio de
nomes exclusivos (garantindo a sua unicidade) a cada um dos componentes, para que seja
possvel reconhecer a evoluo da cada uma das verses dos componentes e a hierarquia
existente entre eles a partir de seus nomes. Um esquema de identificao simples utiliza a
combinao de nome do projeto, tipo de item, nome do item e verso.
Aps o estabelecimento do esquema de identificao, so planejadas as baselines
dentro do ciclo de vida do projeto. Geralmente, cria-se uma linha de referncia ao final de
cada fase do ciclo de vida do projeto e, periodicamente, depois de cada manuteno. So
especificados quais itens sero revisados e armazenados em cada uma das baselines
planejadas.
A ltima etapa da identificao descrita a maneira como os itens sero arquivados
e recuperados do repositrio.
4.4.4. Controle da Configurao

Dois controles bsicos so institudos no processo de gerncia de configurao:
controle de verso e controle de mudana.
4.4.4.1. Controle de Verso

Um item, ao ser desenvolvido, evolui at que atinja um estado que atenda os
propsitos para o qual foi criado. Isso implica diversas alteraes, gerando uma verso
40
(reviso) do item a cada estado. Para estabelecer o controle sobre as diversas verses, todas
devem ser armazenadas e identificadas e para tal processo foi adotada a ferramenta
Subversion.
O Subversion uma ferramenta open source e suas principais funes pertinentes
ao controle de verses podem ser resumidas em: recuperao de verses anteriores;
auditoria das modificaes realizadas: quem, quando, o qu; automatizao do
rastreamento de arquivos; estabelecimento de meios para obter a situao de um projeto
em determinado ponto do tempo; permite o desenvolvimento paralelo; resolve conflitos
entre desenvolvedores.
O Subversion armazena em seu repositrio as modificaes realizadas num arquivo
ao longo do tempo; cada modificao identificada por um nmero chamado de reviso.
Toda reviso armazena as modificaes realizadas, quem realizou essas modificaes,
quando foram realizadas, entre outras informaes. Qualquer reviso poder ser rastreada
para fins de consulta, comparao ou unio com outras revises.
Conta, ainda, com um mecanismo capaz de controlar os acessos simultneos e as
modificaes paralelas, garantindo a integridade das modificaes e a atomicidade das
operaes.
A Figura 4.6 apresenta o fluxo sinttico de gerncia de configurao e a Figura 4.7
mostra o fluxo de operao do Subversion, ambas apresentaro de forma resumida o
funcionamento do controle de verso.
Figura 4.6 - Fluxo Sinttico de Gerncia de Configurao

41
Figura 4.7 - Fluxo de Operao do Subversion
Todas as atividades envolvidas no processo de controle de verso foram

apresentadas aos colaboradores atravs dos treinamentos realizados.
4.4.4.2. Controle de Mudanas

Durante o processo de desenvolvimento, mudanas descontroladas podem levar
rapidamente ao caos. Assim, foi institudo na organizao um processo que combine
procedimentos humanos e ferramentas automatizadas para proporcionar um mecanismo de
controle de mudanas.
Esse processo deve ser implementado depois que uma baseline for estabelecida;
antes disso, somente um controle de mudanas informal11 precisa ser aplicado, ou seja, at
que um item de configurao faa parte de uma baseline, o mesmo no precisar passar por
controle de mudanas formal.
11
O termo informal, nesse contexto, refere-se a qualquer mudana que no necessite da aprovao e
procedimentos realizados pelo gerente de configurao da organizao.
42
A Figura 4.8 apresenta o fluxo de controle de mudanas formal a ser aplicado para
os itens que compem uma baseline.
Figura 4.8 - Fluxo de Controle de Mudanas Formal

Para o controle de mudanas dos itens que no compem ainda uma baseline, ou
seja, controle de mudanas informal decidiu-se utilizar a ferramenta Mantis. Com isso,
toda e qualquer modificao realizada no desenvolvimento, antes do estabelecimento de
uma baseline, poderia ser verificada e monitorada.
Houve uma adaptao dos fluxos do processo de teste da empresa para o controle
de mudana informal. No fluxo de bugs so tratadas as modificaes referentes a erros
detectados (no conformidades) e no fluxo de requisitos, desenvolvimento de novos
requisitos.
Na Figura 4.9 e na Figura 4.10 so apresentados o fluxo de bugs adaptado e o fluxo
de requisitos adaptado, respectivamente.
43
Figura 4.9 - Fluxo de bugs adotado para a Ferramenta Mantis
Fonte: Empresa Beta
Figura 4.10 - Fluxo de requisitos adotado para a Ferramenta Mantis

Fonte: Empresa Beta
44
A estruturao do uso das ferramentas Subversion e Mantis foi definida visando
facilitar e auxiliar o processo de contabilizao da situao da configurao e, tambm, a
auditoria da configurao.
Todas as atividades envolvidas no processo de controle de mudanas foram
apresentadas aos colaboradores atravs dos treinamentos realizados.
4.4.5. Contabilizao da Situao da Configurao

O objetivo dessa atividade relatar a todas as pessoas envolvidas no
desenvolvimento e na manuteno do produto as seguintes informaes sobre as alteraes
na configurao do produto: O que aconteceu?; Quem o fez?; Quando aconteceu?
e O que mais ser afetado?.
As ferramentas Subversion e Mantis foram adotadas para registrar, armazenar e
permitir a busca por essas informaes. Na primeira so disponibilizadas a todos os
colaboradores que possuem acesso ao projeto informaes como: quem modificou um
item, quando, a qual solicitao est vinculada a modificao, entre outros. Na segunda so
encontradas informaes de o que foi alterado, o porqu da alterao, o que mais ser
afetado, quantas modificaes sofreu um determinado item de configurao entre outros;
essas informaes visualizadas atravs de permisses de acesso
O acesso rpido s informaes sobre a gerncia de configurao agiliza o processo
de desenvolvimento e melhora a comunicao entre as pessoas, o que uma maneira de
eliminar muitos problemas relativos modificao do mesmo item de informao com
intenes diferentes e conflitantes.
4.4.6. Auditoria da Configurao

A auditoria de configurao executada antes que uma baseline seja definida e tem
como finalidade certificar que o produto est de acordo com os requisitos (de especificao
e contratuais) e, tambm, garantir que est precisamente descrito em seus documentos
tcnicos.
As alteraes tambm so auditadas para garantir a integridade do produto que est
sendo produzido. Ou seja, ela auxilia a visualizao da situao da configurao durante
todo o desenvolvimento e revela se os requisitos iniciais esto sendo satisfeitos e se a
passagem de uma configurao a outra no descaracteriza o produto.
45
A auditoria ser realizada por um grupo independente do grupo que produziu a
configurao. Tanto a atividade de verificao como de validao ser realizada pela
equipe de teste e a gerente de configurao da organizao.
4.5. Avaliao da Implantao das Prticas de GCS

Aps a implantao das prticas descritas acima, constatou-se fatores positivos e
negativos de toda a execuo deste projeto.
Como pontos positivos podem ser citados:
Diminuio de perda de cdigo-fonte, de requisitos j documentados e
implementados, evitando o retrabalho;
Aumento da produtividade;
Aumento da memria organizacional da empresa, pois agora tudo era
armazenado e controlado;
Maior controle sobre o desenvolvimento, tornou-se possvel identificar quais
mudanas ocorreram, quem e quando as realizou;
Existncia de documentao sobre a evoluo do sistema;
Desenvolvimento dependente do processo e, no de pessoas;
Diminuio dos custos do processo de desenvolvimento;
Maior confiabilidade nos prazos estabelecidos;
Melhor comunicao entre a equipe de desenvolvimento;
Maior compatibilidade de verses.
Os pontos negativos encontrados foram:
Resistncia ao uso de novas ferramentas e procedimentos no processo de
desenvolvimento;
Dificuldade de conscientizao de todos os colaboradores.
46
5. CONCLUSES
A preocupao com a melhoria do processo de desenvolvimento de software vem
sendo impulsionada por exigncias do mercado por mais qualidade e produtividade. Muitas
empresas tm revisto seus processos e procurado se capacitar no mercado cada vez mais
competitivo.
Os estudos realizados sobre Engenharia e Qualidade de Software, Melhoria do
Processo de Software e Gerncia de Configurao de Software revelaram que em processo
de desenvolvimento de software de suma importncia o controle e gerenciamento das
mudanas a que so submetidos os itens de configurao.
O elevado nmero de problemas encontrados na empresa como: perda de cdigo-
fonte, requisitos j documentados e requisitos implementados, falta de controle sobre o
desenvolvimento, constantes retrabalhos; indicaram que a empresa de software descrita no
estudo de caso necessitava de aplicar ao seu processo de desenvolvimento prticas de
Gerncia de Configurao de Software.
A definio das prticas a serem adotadas levou em considerao principalmente o
perfil da empresa, ou seja, empresa de pequeno porte, jovem, de recursos moderados
(humano, tempo e capital). Sendo assim, foram adotadas ferramentas open source para o
suporte ao controle de verso e mudanas, atividades relacionadas GCS foram atribudas
aos prprios lderes de projeto. O pouco tempo para a execuo deste projeto tambm foi
fator determinante para o pouco treinamento oferecido.
A implantao das prticas proporcionou melhorias no processo; permitiu um
controle sobre o desenvolvimento; diminuio das perdas de cdigo; uniformidade do
trabalho; mudana na cultura organizacional; aumento da memria organizacional da
empresa; maior organizao dos processos e projetos; melhor adequao dos prazos
estipulados para os projetos e melhoria nas relaes entre os clientes e a empresa.
As principais dificuldades verificadas para a implantao das prticas de gerncia
de configurao foram: as deficincias na alocao de recursos para a execuo deste
projeto; a cultura organizacional, a falta de consenso em relao ao estabelecimento das
melhores prticas a serem implantadas, falta de conhecimento mais amplo de gerncia de
configurao dos colaboradores da empresa.
Contudo, os treinamentos realizados para a implantao das prticas juntamente
com a escolha dos projetos pilotos viabilizaram este trabalho. As prticas ajudaram
tambm, atravs dos seus planos, templates, processos, nova ferramenta adotada, a reduzir
falhas na comunicao entre os colaboradores da empresa e aumentar a produtividades.
Percebeu-se que uma implantao pode utilizar um processo j existente
adicionando-se apenas algumas atividades a esse processo, ou seja, implantao pode
representar apenas adaptaes ao invs de criaes de processos que comecem do zero.
As vantagens da implantao na empresa Beta foram muito superiores s
desvantagens, o que permitiu a concluso desse trabalho com xito. Porm, no se pode
acreditar que esse o melhor processo a ser adotado, deve-se buscar melhorias contnuas a
fim de se ter produtos e processos com a alta qualidade.
Toda modificao requer um perodo de adaptao, um treinamento adequado,
comprometimento dos envolvidos; caso isso no exista pode ser definido o insucesso do
projeto. Vale ressaltar que toda implantao, ao final, deve ser submetida a uma avaliao,
pois assim se tem base para projetos futuros e se realiza um levantamento de melhorias a
serem aplicadas.
As prticas de GCS mostraram-se um importante elemento para a melhoria da
qualidade dos produtos, principalmente devido ao perfil da organizao, que emprega
profissionais que muitas vezes nunca tiveram uma experincia prtica com
desenvolvimento de software para o mercado. Os colaboradores da empresa se
familiarizaram com os conceitos e atividades relacionadas disciplina da engenharia de
software gerncia de configurao fundamental ao processo de desenvolvimento de
software.
Como trabalho futuro, pretende-se implantar melhorias nas prticas j
institucionalizadas de gerncia de configurao e buscar continuamente qualidade no
processo e nos produtos da empresa.
48
6. REFERENCIAL BIBLIOGRFICO
ABNT, Gesto da Qualidade - Diretrizes para a Gesto da Configurao. NBR ISO
10007. ABNT, 1996.
Aaen, I., Bottcher, P., Mathiassen, L., The Software Factory: Contributions and
Illusions, In the Proceedings of the Twentieth Information Systems Research Seminar,
Scandinavia, Oslo, 1997.
Asklund, U., Bendix, L. A Study of Configuration Management in Open Source
Software. In: IEE Proceedings - Software, v. 149, pp. 40-46, 2002.
Babich, W.A. Software Configuration Management - Coordination For Team
Productivity. Addison-Wesley, 1986.
Bersoff, E.H. Elements Of Software Configuration Management. IEEE Transactions on
Software Engineering, v. 10, n. 1, p. 79-87, 1984.
Bryan, W. L., Siegel, S. G., Whiteleather, G. L. Auditing Through The Software Life
Cycle: A Primer. Computer, v. 15, n. 3, p. 57-67, 1982.
Capretz, M.A.M. A Software Maintenance Method Based On The Software
Configuration Management Discipline. Tese de Doutorado. University of Durham,
Inglaterra, 1992.
Castor, E. M. Fbrica de Software: Passado, Presente e Futuro. Ps-Graduao Lato
Sensu em Tecnologia da Informao - UNIBRATEC - Unio dos Institutos Brasileiros
de Tecnologia, 2004.
Christensen, M. J., Thayer, R. H. The Project Manager's Guide to Software
Engineering's Best Practices. 1 ed., IEEE Computer Society Press and John Wiley &
Sons, 2002.
Computerworld (2006), Crescimento das Fbricas de Software no Brasil. Disponvel
em, http://computerworld.uol.com.br/mercado/2005/09/13/idgnoticia.2006-05-
15.329843166/IDGNoticia_view. Acessado no dia 20 de maio de 2006.
Dias, A.F. O que Gerncia de Configurao?, Disponvel em
http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuraca
o.php?pagNum=0. Acessado dia 18 de maro de 2006.
Estublier, J. Software Configuration Management: a Roadmap. In: Proceedings of 22nd
International Conference on Software Engineering, The Future of Software
Engineering, pp. 279-289, Limerick, Ireland, 2000.
Estublier, J., Leblang, D., Clemm G., et al. Impact of the Research Community On the
Field of Software Configuration Management. In: Software Engineering Notes
(ACM), v. 27, pp. 31-39, Orlando, Florida, 2002.
Gil, A. C. Como Elaborar Projetos de Pesquisa. 3. ed. So Paulo: Atlas, 1991. 159 p.
Hass, A. M. J. Configuration Management Principles and Practices, Boston, MA,
Pearson Education, Inc, 2003.
Herbsleb, James D.; Mockus, Audris; Finholt, Thomas A.;Grinter, Rebecca E. Distance,
Dependencies, and Delay in a Global Collaboration. Conference On Computer
Supported Cooperative Work, Philadelphia, Pennsylvania. Proceedings... New York:
ACM Press, 2000. p. 319-328.
IEEE. IEEE Standards Collection - Software Engineering. 1993.
IEEE, Std 610.12 - IEEE Standard Glossary of Software Engineering Terminology.
1990.
IEEE, Std 1042 - IEEE Guide to Software Configuration Management. 1987.
IEEE. SWEBOK - Guide to the software engineering body of knowledge: trial version
(version 1.00) / executive editors, Alain Abran, James W. Moore; editors, Pierre
Bourque, Robert Dupuis, Leonard L. Tripp. 2001.
ISO. ISO - International organization for Standardization / International
Electrotechanical Commission. Information Technology - Software Product
evaluation Quality characteristics and guidelines for use. - ISO/IEC 9126, Genve
1991.
ISO. ISO 10007, Quality Management - Guidelines for Configuration Management.
1995.
Jung, C. Metodologia Para Pesquisa & Desenvolvimento Aplicada a Novas
Tecnologias, Produtos e Processos. Rio de Janeiro: Axcel Books, 2004. 162 p.
Leon, A. A Guide to Software Configuration Management, Norwood, MA, Artech
House Publishers, 2000.
Paulk, M.C.; Weber, C.V.; Curtis, B.; Chrissis, M.B.; et al. The Capability Maturity
Model: Guidelines for Improving the Software Process. Estados Unidos: Addison-
Wesley, 1995.
Pessoa, M. S. de P. Introduo ao CMM Modelo de Maturidade da Capacidade de
Processo de Software Lavras: UFLA/FAEPE, 2003.
50
Pressman, Roger S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002.
843p.
SEI, Software Engineering Institute. Capability Maturity Model Integration
(CMMISM), Version 1.1. CMMISM for Software Engineering (CMMI-SW, V1.1),
Staged Representation. Pittsburgh, PA, EUA: Carnegie Mellon University 2002.
Siy, H, P., Mockus, A., Herbsleb, J, D., Krishnan, M., Tucker, G, T., Making The
Software Factory Work: Lessons from a decade of experience, In the Seventh
International Symposium on Software Metrics, London, England, 2001.
Sommerville, I. Engenharia de Software. 6 ed. So Paulo, Addison Wesley, 2003.
Victorelli, E.Z. Controle de Verses e Configuraes em Ambientes de
Desenvolvimento de Software. Dissertao de Mestrado. DCC/IMECC/UNICAMP,
1990.
Villas Boas, A. L. C. Gesto de Configurao para Teste de Software, Dissertao de
mestrado apresentada na Faculdade de Engenharia Eltrica e de Computao da
Universidade Estadual de Campinas. Campinas, SP: [s.n.], 2003.
51
Apndice A Glossrio de Gerncia de
Configurao
Figura A.1 - Pginas 1 e 2 do Glossrio de Gerncia de Configurao



53

54
Figura A.8 - Pginas 15 e 16 do Glossrio de Configurao

55

56
Figura A.11 - Pgina 21 do Glossrio de Configurao
57
Apndice B Plano de Gerncia de
Configurao
Figura B.1 - Pginas 1 e 2 do Plano de Gerncia de Configurao


Figura B.3 - Pginas de 5 e 6 do Plano de Gerncia de Configurao

59

60

61
Figura B.10 - Pgina 19 do Plano de Gerncia de Configurao

62
Apndice C Plano de Ambiente
Figura C.1 - Pginas 1 e 2 do Plano de Ambiente



64

Gestão de Configurações em Software Factory

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gestão de Configurações em Software Factory

Enviado por

Direitos autorais:

Formatos disponíveis

VANESSA RODRIGUES BORGES

IMPLANTAO DE PRTICAS DE GERNCIA DE CONFIGURAO EM UMA

Monografia de graduao apresentada ao

IMPLANTAO DE PRTICAS DE GERNCIA DE CONFIGURAO EM UMA

Monografia de graduao apresentada ao

Borges, Vanessa Rodrigues

Implantao de Prticas de Gerncia de Configurao em uma Fbrica de

Monografia de Graduao Universidade Federal de Lavras. Departamento de

1. Engenharia e Qualidade de Software. 2. Melhoria do Processo de Software. 3.

IMPLANTAO DE PRTICAS DE GERNCIA DE CONFIGURAO EM UMA

Monografia de graduao apresentada ao

Aprovada em 18 de setembro de 2006.

Agradeo a Deus por toda fora, luz, sade!

O principal objetivo deste trabalho descrever e discutir a implantao de prticas de

IMPLANTATION OF CONFIGURATION MANAGEMENT PRACTICES IN A

LISTA DE TABELAS ............................................................................................... x

LISTA DE ABREVIATURAS E SIGLAS ............................................................... xi

1.1. Contextualizao e Motivaes................................................................. 1

1.2. Objetivos e Justificativas........................................................................... 2

1.3. Organizao do Trabalho ......................................................................... 3

2. REFERENCIAL TERICO ............................................................................. 4

2.1. Engenharia e Qualidade de Software ...................................................... 4

2.2. Melhoria do Processo de Software ........................................................... 6

2.3. Fbrica de Software................................................................................. 12

2.4. Gerncia de Configurao de Software (GCS) ..................................... 14

2.4.1. Funes da Gerncia de Configurao................................................................... 18

3.1. Tipo de Pesquisa ...................................................................................... 25

3.2. Procedimentos Metodolgicos ................................................................ 26

4. RESULTADOS E DISCUSSO .................................................................. 28

4.1. Caracterizao da Empresa.................................................................... 28

4.2. Diagnstico das Prticas de Gerncia de Configurao Atuais .......... 28

4.3. Planejamento da Implantao das Prticas de GCS na Empresa ...... 32

4.3.1. Auditoria da Implantao....................................................................................... 32

4.4.1. Plano de Gerncia de Configurao....................................................................... 39

6. REFERENCIAL BIBLIOGRFICO ............................................................. 49

Apndice A Glossrio de Gerncia de Configurao ............................ 52

Apndice B Plano de Gerncia de Configurao .................................... 58

Apndice C Plano de Ambiente.................................................................... 63

ABNT Associao Brasileira de Normas Tcnicas

1.1. Contextualizao e Motivaes

1.2. Objetivos e Justificativas

1.3. Organizao do Trabalho

2.1. Engenharia e Qualidade de Software

2.2. Melhoria do Processo de Software

Figura 2.1 - O Processo de Software e seus Componentes

Pressman (2002) trata a engenharia de software como uma tecnologia em

Visibilidade As atividades de processo culminam em resultados ntidos,

Facilidade de suporte At que ponto as atividades do processo podem ser apoiadas

Aceitabilidade O processo definido aceitvel e utilizvel pelos

Robustez O processo pode continuar, mesmo que surjam problemas

Facilidade de manuteno O processo pode evoluir para refletir os requisitos mutveis

Rapidez Com que rapidez pode ser concludo o processo de entrega

Fonte: Sommerville (2003)

Para que alcanar a melhoria do processo, necessrio que se promova a execuo

Figura 2.2 - O Processo de Software

2.4. Gerncia de Configurao de Software (GCS)

2.4.1. Funes da Gerncia de Configurao

2.4.1.1. Identificao da Configurao

2.4.1.2. Controle de Configurao

2.4.1.4. Auditoria da Configurao

2.4.2. Ferramentas de Apoio

3.1. Tipo de Pesquisa

3.2. Procedimentos Metodolgicos