[completo] tcc mauricioewelton -...
Post on 31-Dec-2018
218 Views
Preview:
TRANSCRIPT
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO
Ewelton Yoshio Chiba Yoshidome
Maurício Ronny de Almeida Souza
UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE CONFIGURAÇÃO DO MPS.BR
UTILIZANDO FERRAMENTAS DE SOFTWARE LIVRE
Trabalho de Conclusão de Curso para obtenção do grau de Bacharel em Ciência da Computação
Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira
Belém 2009
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO
Ewelton Yoshio Chiba Yoshidome
Maurício Ronny de Almeida Souza
UMA PROPOSTA DE APOIO SISTEMATIZADO À
GERÊNCIA DE CONFIGURAÇÃO DO MPS.BR UTILIZANDO FERRAMENTAS DE SOFTWARE LIVRE
Data da defesa: ____/____/____
Conceito: ____________
Banca Examinadora
Prof. Dr. Sandro Ronaldo Bezerra Oliveira
Faculdade de Computação/UFPA – Orientador
Prof. Dra. Carla Alessandra Lima Reis Faculdade de Computação/UFPA – Membro
Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA – Membro
Belém 2009
Aos amigos e familiares que deram o suporte necessário ao longo dessa jornada.
AGRADECIMENTOS
Agradeço a minha família, por ter acreditado em meus estudos e em minha
capacidade, também por ter me ajudado e apoiado em minhas decisões todo o
tempo. Dedico este trabalho, também, aos meus amigos (Maurício, Carlos Rafael,
Vitor, Wallace, Eder) por terem acompanhado a minha estada em Belém e minha
vida acadêmica. Um agradecimento ao pessoal que estão em Macapá, aos meus
amigos (Carla e Diego) e a uma pessoa muito importante para mim, minha querida
Larissa, os quais me incentivaram a não procrastinar o desenvolvimento deste
trabalho. Agradeço ao pessoal do grupo do projeto SPIDER. E finalmente, mas não
menos importante, agradeço ao meu orientador, Sandro Bezerra, por tornar o
desenvolvimento deste trabalho de conclusão de curso possível.
Ewelton Yoshio Chiba Yoshidome
Em primeiro lugar à minha querida mãe por cuidar de mim com tanto empenho,
e por todo o apoio, carinho e dedicação que sempre me ofereceu. À minha madrinha
e minha avó que foram minhas mães também. Aos meus familiares, pela motivação
ao longo de todos esses anos. À minha amada namorada e melhor amiga, Ariane
pelo companheirismo e confiança incondicional depositada em mim, e à sua família,
Sebastião, Julieta e Talita, por me acolherem de forma tão afetuosa. Aos meus
amigos de colégio Luiz, Carlos, Rosana, Amanda, Jefferson, Júlio, Vanessa, Patty e
Nandara, por manterem nossa amizade sempre viva. Aos amigos da vida, Monique
(dona), Carol e Victor (Jimmy), provando que amizades são feitas das formas mais
inusitadas. Aos meus inseparáveis amigos de universidade Yoshio, Vitor e Wallace,
por toda a paciência e diversão. Aos amigos do projeto SPIDER, que tanto
contribuíram para a confecção deste trabalho. Aos professores do curso de
Bacharelado em Ciência da Computação, pelo profissionalismo e lembranças
deixadas. E agradecimentos merecidos ao professor e orientador Sandro, pela
paciência no MSN e seu exímio trabalho como professor, motivando e ensinando
sempre.
Maurício Ronny de Almeida Souza
“É na mudança que encontramos um objetivo.”
Heráclito
RESUMO
Na Engenharia de Software, existe uma área chamada Qualidade de Software,
onde o foco está em garantir a satisfação do cliente, através de definição e
institucionalização do processo de software. Neste contexto, este trabalho tem como
objetivo analisar o MPS.BR e verificar a aderência de um conjunto de ferramentas
de software livres de apoio ao processo de Gerência de Configuração com as
recomendações do modelo, e em seguida, sugerir uma proposta de sistematização
do processo de Gerência de Configuração no nível de maturidade F a partir do uso
das mesmas ferramentas. Finalmente, desenvolver uma metodologia para o uso das
ferramentas propostas para contemplar todos os resultados esperados do processo
de Gerência de Configuração do MPS.BR.
PALAVRAS-CHAVE: Melhoria do Processo, Qualidade do Software, Gerência de
Configuração, MPS.BR, Ferramentas de Software.
ABSTRACT
In Software Engineering, there is a subject called Software Quality, where the
focus is on ensuring customer satisfaction, through the definition and
institutionalization of the software process. In this context, this work aims to analyze
the MPS.BR and verify adherence to a set of free software tools for Configuration
Management, and then suggest an approach to systematize the Configuration
Management process in the F maturity level. Finally, developing a methodology for
using the tools proposed to satisfy all expected results of the MPS.BR’s
Configuration Management process.
KEYWORDS: Process Improvement, Software Quality, Configuration Management, MPS.BR, Software Tools.
SUMÁRIO
1 Introdução ..................................................................................................................................... 13
1.1 Qualidade de Software .......................................................................................................... 13
1.2 Contexto (problemas, justificativa, motivação) .................................................................... 13
1.3 Objetivos ............................................................................................................................... 15
1.3.1 Objetivo Geral ............................................................................................................... 15
1.3.2 Objetivos Específicos ..................................................................................................... 15
1.4 Metodologia .......................................................................................................................... 15
1.5 Estrutura do Trabalho ........................................................................................................... 16
2 MPS.BR: Uma Visão Geral ............................................................................................................. 17
2.1 Histórico do MPS.BR .............................................................................................................. 17
2.2 Definição e Composição do MPS.BR ..................................................................................... 18
2.3 Guias do MPS.BR ................................................................................................................... 19
2.4 Níveis de Maturidade do MPS.BR ......................................................................................... 19
2.5 Considerações Finais ............................................................................................................. 22
3 Processo de Gerência de Configuração (GCO) .............................................................................. 23
3.1 Gerência de Configuração ..................................................................................................... 23
3.1.1 Atividades da Gerência de Configuração ...................................................................... 24
3.2 Gerência de Configuração no MPS.BR .................................................................................. 26
3.3 Resultados Esperados ........................................................................................................... 26
3.4 Considerações Finais ............................................................................................................. 30
4 Proposta de Apoio Sistematizado ................................................................................................. 31
4.1 Projeto SPIDER ...................................................................................................................... 31
4.2 Ferramentas de Software Livre para Apoio do Processo de Gerência de Configuração. ..... 32
4.2.1 Controle de versão ........................................................................................................ 33
4.2.2 Controle de Mudanças .................................................................................................. 35
4.3 Ferramentas Analisadas para a Metodologia Proposta ........................................................ 37
4.4 Mapeamento das Ferramentas aos Resultados Esperados (pontos fracos e fortes) ........... 39
4.4.1 GCO 1: Subversion e Trac / CVS e Mantis ..................................................................... 40
4.4.2 GCO 2: Trac, Mantis, Spider-CL ..................................................................................... 40
4.4.3 GCO 3: CVS, Subversion ................................................................................................. 41
4.4.4 GCO 4: Subversion, Trac e CVS ...................................................................................... 41
4.4.5 GCO 5: Mantis, Trac ....................................................................................................... 42
4.4.6 GCO 6: Mantis, Trac, Subversion e CVS ......................................................................... 43
4.4.7 GCO 7: Spider-CL, Mantis, CVS, Trac e Subversion ........................................................ 44
4.5 Sugestões de Melhoria do Ferramental de Apoio................................................................. 44
4.6 Considerações Finais ............................................................................................................. 44
5 Metodologia Para a Implementação do Processo de Gerência de Configuração ......................... 46
5.1 Descrição do Cenário............................................................................................................. 46
5.1.1 Definindo e estabelecendo um sistema de gerência de configuração ......................... 47
5.1.2 Identificando itens de configuração .............................................................................. 52
5.1.3 Manipulando e controlando a evolução dos itens de configuração ............................. 54
5.1.4 Gerenciando Mudanças ................................................................................................ 64
5.1.5 Definindo políticas de acesso e segurança .................................................................... 72
5.1.6 Realizando Auditoria de Configuração .......................................................................... 74
5.2 Considerações Finais ............................................................................................................. 78
6 Conclusão ...................................................................................................................................... 79
6.1 Resultados Obtidos e Trabalhos Futuros .............................................................................. 79
6.2 Lições Aprendidas ................................................................................................................. 80
Referências Bibliográficas ..................................................................................................................... 82
LISTA DE FIGURAS
Figura 2.1 - Componentes do modelo MPS [Softex, 2009] ....................................... 18
Figura 2.2 - Estrutura dos Níveis de Maturidade do MPS.BR [Softex, 2009] ............ 20
Figura 4.1 – Mapeamento dos Resultados Esperados com as Ferramentas de GCO. .................................................................................................................................. 39
Figura 5.1 – Visualização do repositório através da árvore de diretórios .................. 48
Figura 5.2 – Criação de um projeto no Mantis ........................................................... 48
Figura 5.3 – Tela para importação de atributos a partir do Template do Projeto ...... 49
Figura 5.4 – Visualização do repositório através do TortoiseSVN ............................. 49
Figura 5.5 – Criação de um ambiente Trac para um projeto ..................................... 50
Figura 5.6 – Visualização de Projetos Disponíveis no Trac ...................................... 50
Figura 5.7 – Exemplo de Estrutura de Plano de Gerência de Configuração na Ferramenta Trac. ....................................................................................................... 52
Figura 5.8 – Checklist criado e aplicado através do Spider-CL ................................. 53
Figura 5.9 – Exemplo de Identificação de Itens de Configuração no Plano de Gerencia de Configuração......................................................................................... 54
Figura 5.10 – Check-in no CVS (commit). ................................................................. 56
Figura 5.11 – Check-in no Subversion (commit). ...................................................... 57
Figura 5.12 – Criação de Baseline no Subversion (Tags). ........................................ 58
Figura 5.13 – Criação de Baseline no Subversion (Tags). ........................................ 60
Figura 5.14 – Histórico de Alterações do CVS. ......................................................... 61
Figura 5.15 – Tela de log do CVS (a partir do Web log) ............................................ 62
Figura 5.16 – Histórico de Alterações do Subversion. ............................................... 63
Figura 5.17 – Visualização dos Itens e suas Revisões em uma Baseline no Subversion. ............................................................................................................... 64
Figura 5.18 – Criação de issue na ferramenta Mantis. .............................................. 67
Figura 5.19 – Criação de ticket na ferramenta Trac. ................................................. 68
Figura 5.20- Visualização de issues (View Issues) ................................................... 70
Figura 5.21- Histórico de mudanças de issues.......................................................... 70
Figura 5.22 – Visualização de Tickets no Trac (Ticket View). ................................... 71
Figura 5.23 – Exibição dos Milestones do projeto no Trac (Roadmap). .................... 71
Figura 5.24- Histórico de mudanças do ticket. .......................................................... 72
Figura 5.25 – Atuação do SSL Server (sserver) durante operação de acesso ao repositório CVS. ........................................................................................................ 73
Figura 5.26 – Arquivo de permissões de leitura e escrita do repositório Subversion 73
Figura 5.27 – Exemplo de checklist para auditoria de configuração ......................... 75
Figura 5.28 – Página “Auditorias de Configuração” ................................................... 76
Figura 5.29 – Página de uma Auditoria de Configuração específica. ........................ 77
Lista de Tabelas
Tabela 2.1 - Processos e Atributos de Processo por Nível de Maturidade [Softex, 2009] ......................................................................................................................... 21
13
1 INTRODUÇÃO
Este capítulo apresenta uma visão geral do trabalho, descrevendo o seu contexto
(problemas, justificativa e motivação), objetivos e a estrutura do trabalho, com uma breve
descrição de seus capítulos para melhor entendimento do leitor.
1.1 Qualidade de Software
As mudanças que estão ocorrendo nos ambientes de negócios têm motivado as
empresas a modificar suas estruturas organizacionais e seus processos produtivos, saindo da
visão tradicional baseada em áreas funcionais em direção a redes de processos centrados no
cliente [Softex, 2009]. A competitividade depende, cada vez mais, do estabelecimento de
conexões nestas redes, criando elos essenciais nas cadeias produtivas. A demanda por
qualidade tornou-se um fator decisivo na concorrência entre organizações desenvolvedoras de
software, principalmente quando se fala em exportação. Na indústria de software, e em outros
setores, a qualidade torna-se um elemento crítico para o sucesso, visando manter a
competitividade, e isto implica tanto na melhoria da qualidade dos produtos de software e
serviços correlatos, como dos processos de produção e distribuição de software [Softex, 2009]
Tendo em vista este cenário, a qualidade de software busca formas para melhorar os
métodos de produção de software de uma organização. A qualidade de software é uma área da
Engenharia de Software que está diretamente relacionada em alcançar a satisfação do cliente,
ou seja, produzir um software com o mínimo de erros, no prazo estimado, executando da
forma esperada pelo cliente. Alcançar a qualidade de software não é uma tarefa trivial e está
fortemente ligada a um processo de software de qualidade.
1.2 Contexto (problemas, justificativa, motivação)
O modelo de Melhoria do Processo de Software Brasileiro (MPS.BR) [Softex, 2009],
surgiu em 2003 através de parcerias entre o Governo, a Sociedade para Promoção da
Excelência do Software Brasileiro (SOFTEX) e universidades, com intuito de solucionar o
problema de como melhorar radicalmente os processos de software no Brasil, levando em
consideração a configuração do mercado nacional, constituído principalmente por micro,
pequenas e médias empresas [Softex, 2009]. A idéia por trás do MPS.BR não é propor
soluções novas no que tange a Modelos e Normas de Qualidade para o Processo de Software,
mas sim, alinhar uma estratégia acessível para a realidade das empresas brasileiras que seja
14
compatível com os demais modelos de qualidade reconhecidos internacionalmente [Weber,
2004].
Objetivando agilizar o processo de implementação do MPS.BR e diminuição dos custos
para adequação das organizações ao modelo de qualidade, nasce em 2009 o projeto SPIDER -
Uma Proposta de Solução Sistêmica de um SUITE1 de Ferramentas de Software Livre de
apoio à implementação do modelo MPS.BR [Oliveira, 2008]. O projeto SPIDER tem como
um dos focos principais, apresentar um levantamento das ferramentas de software livre com
características adequadas para possibilitar a criação de produtos de trabalhos que evidenciem
a implementação do programa da qualidade organizacional, inicialmente nos níveis de
maturidade G (parcialmente gerenciado) e F (gerenciado) do modelo MPS.BR [Oliveira,
2008].
O presente trabalho é fruto das pesquisas do projeto SPIDER sobre o processo de
Gerência de Configuração (GCO), apresentando uma metodologia para utilização de
ferramentas de software livre para o acompanhamento e sistematização das práticas deste
processo no contexto do modelo MPS.BR. O objetivo principal deste trabalho é descrever
uma metodologia para uso de serviços e funcionalidades disponibilizados por ferramentas
livres, de forma a sistematizar o controle das modificações sobre os produtos de trabalho ao
longo de projetos, conforme os resultados esperados propostos pelos guias do MPS.BR.
A relevância deste trabalho reside na busca por aumentar a eficiência das
implementações do processo de Gerência de Configuração em unidades organizacionais,
diminuindo custo e tempo, além de propor um conjunto de boas práticas para gerência de
configuração baseado no apoio ferramental.
1 Amplo conjunto modular de tecnologias integradas, facilitando a aceleração de fluxo de dados unificados para enfrentar alguns dos desafios de integração mais sérios da organização. [Oliveira,
2008]
15
1.3 Objetivos
Nesta seção será apresentado o principal objetivo do projeto (objetivo geral), juntamente
com metas (objetivos específicos) que deverão ser alcançados no decorrer do projeto para se
concluir o objetivo.
1.3.1 Objetivo Geral
Propor soluções sistêmicas para apoiar o processo de Gerência de Configuração do
MPS.BR através de ferramentas livres.
1.3.2 Objetivos Específicos
• Estudo do MPS.BR;
• Estudo do processo de gerência de configuração;
• Analisar ferramentas livres para apoio a gerência de configuração;
• Mapear os resultados esperados do processo de Gerência de Configuração do
MPS.BR com cada ferramenta;
• Definir metodologia e políticas de uso para implementação de cada resultado
esperado do processo de Gerência de Configuração do MPS.BR, através de
funcionalidades e serviços das ferramentas livres;
1.4 Metodologia
O desenvolvimento deste trabalho ocorreu através das etapas: estudo do modelo
MPS.BR; estudo do processo de Gerência de Configuração; levantamento de ferramentas
livres para apoio à Gerência de Configuração; mapeamento dos resultados esperados do
processo de GCO com as funcionalidades e serviços das ferramentas; elaboração de
metodologia de uso das ferramentas.
As etapas citadas foram realizadas através da análise da documentação do MPS.BR,
referencias bibliográficas e reuniões semanais com o grupo de pesquisa do projeto SPIDER,
para discussão dos conhecimentos obtidos e apresentação de resultados. A análise das
ferramentas foi feita através de testes em ambiente local e disponibilização de ambientes
configurados para teste por outros membros do grupo de pesquisa. A definição da
16
metodologia foi estabelecida a partir das constatações obtidas pelo uso das ferramentas
comparadas com o referencial teórico e sugestões de implementação dos resultados esperados
de Gerência de Configuração definidos pelo guia de implementação do modelo [Softex,
2009a].
1.5 Estrutura do Trabalho
Além deste capítulo introdutório, o trabalho está estruturado em mais 5 capítulos,
organizados da seguinte maneira: o capítulo 2, “MPS.BR: Uma Visão Geral”, introduz o
programa de melhoria de processo MPS.BR, apontando seus objetivos e características, além
de definir conceitos importantes para o desenvolvimento do trabalho; o capítulo 3, “Processo
de Gerência de Configuração (GCO)”, apresenta o processo de gerência de configuração,
principalmente com foco no contexto do MPS.BR; o capítulo 4, “Proposta de Apoio
Sistematizado”, faz uma análise de ferramentas disponíveis para apoio ao processo de
gerência de configuração; no capítulo 5, “Metodologia Para a Implementação do Processo de
Gerência de Configuração”, é definida uma metodologia de uso de ferramentas livres
selecionadas para apoiar o processo de gerência de configuração; finalmente, o capítulo 6, faz
um resumo geral do trabalho, apontando os resultados obtidos, lições aprendidas e trabalhos
futuros.
17
2 MPS.BR: UMA VISÃO GERAL Este capítulo apresentará o programa Melhoria do Processo de Software Brasileiro
(MPS.BR), objeto de estudo desta monografia, apresentando seu histórico, características,
componentes e organização. Será abordado o processo de institucionalização e avaliação do
modelo nas empresas brasileiras, citando as entidades envolvidas neste processo e os
requisitos para avançar através dos níveis de maturidade.
2.1 Histórico do MPS.BR
O Brasil é um país com uma forte tradição em produção de software, porém o cenário
brasileiro é composto por empresas de micro, pequeno e médio porte. Este cenário é
incompatível com os altos custos para a devida aderência e avaliação/certificação de normas
de qualidade internacional, tais como o CMMI [SEI, 2006] e normas ISO/IEC 15504
[ISO/IEC, 2003]. De acordo com dados do Ministério da Ciência e Tecnologia
(MCT/SEITEC), até 2003, no Brasil, não havia nenhuma empresa de software avaliada no
nível cinco do CMMI, mas existia uma enorme preferência na adoção da ISO 9000 (que não
se trata de uma norma específica ao desenvolvimento de software), reflexo da dificuldade das
empresas nacionais acompanharem os custos de implementação desses modelos.
A partir desse cenário, em dezembro de 2003, foi criado o programa de Melhoria de
Processo de Software Brasileiro (MPS.BR) [Weber, 2004], o qual é um programa, de longo
prazo coordenados pela Associação para Promoção da Excelência do Software Brasileiro
(SOFTEX), contando com o apoio do Ministério da Ciência e Tecnologia (MCT),
Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e
Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID), com o
objetivo de proporcionar melhorias nos processos de software em organizações brasileiras a
um custo mais acessível, tendo vista, principalmente, micro, pequenas e médias empresas
[Softex, 2009].
O MPS.BR não foi criado com o objetivo de definir um modelo novo, surgiu apenas
para adaptar os modelos internacionais já existentes para a realidade das empresas brasileiras
[Weber, 2004], que passam a poder ter um modelo de maturidade compatível com as demais
normas já estabelecidos internacionalmente: ISO/IEC 12207 [ISO/IEC, 2008], ISO/IEC
15504 [ISO/IEC, 2003] e CMMI-DEV (Capability Maturity Model Integration for
Development) [SEI, 2006].
18
2.2 Definição e Composição do MPS.BR
O MPS.BR utiliza conceitos de níveis de maturidade e capacidade de processo, dentro
desse contexto, o modelo é dividido em três componentes que agrupam guias utilizados para
efetuar sua implementação e avaliação. Os três componentes são: o Modelo de Referência
(MR-MPS), o Método de Avaliação (MA-MPS) e o Modelo de Negócio (MN-MPS). A figura
2.1 ilustra os três componentes que fazem parte do MPS.BR [Softex, 2009].
Figura 2.1 - Componentes do modelo MPS [Softex, 2009]
O MR-MPS é utilizado para fazer a implementação do modelo de qualidade, no qual
possui as definições de arquitetura, terminologia e responsabilidades inerentes ao processo
que as unidades organizacionais devem atender para estar em conformidade com o MPS.BR.
O modelo MR-MPS está em conformidade com o modelo de referência de processo da norma
ISO/IEC 12207 [ISO/IEC, 2008].
A avaliação nas organizações é feita verificando a aderência ao modelo de referência
para cada processo pertinente ao nível de maturidade implementado, conforme procedimentos
do Método de Avaliação (MA-MPS), citados no Guia de Avaliação. Para avaliar o nível de
implementação do modelo em uma empresa é verificada a consistência dos artefatos gerados
para cada processo; entrevistas são realizadas com a equipe da organização para averiguar se
o processo está sendo seguido corretamente.
O Modelo de Negócio (MN-MPS) descreve as regras de negócio para efetuar a
implementação e avaliação do modelo de qualidade. Para a implementação, a organização
interessada entra em contato com uma Instituição Implementadora (II), organização
credenciada para a implementação do modelo MPS, e assina um contrato. Para a avaliação, a
19
empresa interessada entra em contato com a SOFTEX o qual indicará algumas Instituições
Avaliadoras (IA), instituição devidamente habilitada para condução de avaliações do
MPS.BR, após a escolha de uma das IA, um contrato é assinado.
2.3 Guias do MPS.BR
O modelo MPS.BR está descrito por meio de guias, que são documentos de apoio sob
responsabilidade da Equipe Técnica do Modelo (ETM). Os guias e suas funções são [Softex,
2009]:
• Guia Geral: descreve de forma geral o MPS.BR e detalha o Modelo de Referência
(MR-MPS), seus componente e as definições comuns necessárias para seu
entendimento e aplicação;
• Guia de Aquisição: descreve o processo de aquisição de software e serviços
correlatos. Existe um guia separado por tratar-se de um processo que só tem
avaliação obrigatória para o caso de organizações que adquiriram produtos de
software, que devem se apoiar no MR-MPS;
• Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os
requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras
(IA);
• Guia de Implementação: dividido em dez documentos, descrevendo como
implementar cada nível do MR-MPS, inclusive sugerindo práticas para atingir
resultados esperados.
A versão mais atual do Guia Geral, utilizada como referência para este trabalho, é o
Guia Geral 2009, lançada em Junho de 2009.
2.4 Níveis de Maturidade do MPS.BR
O MPS.BR tem sua implementação segmentada em níveis de maturidade, que ilustram
uma escada evolutiva para a melhoria do processo, onde cada degrau possui requisitos
cumulativos baseados em processos e capacidade de processos. Segundo Weber [2004], os
níveis de maturidade estabelecem uma forma de prever o desempenho futuro de uma
organização com relação a uma ou mais disciplinas, e estes níveis caracterizam estágios para a
implementação do processo da organização.
20
O modelo propõe sete níveis de maturidade, seqüenciais e cumulativos, que vão do
“Nível G” (inicial) ao “Nível A” (mais maduro), que definem patamares evolutivos para o
processo da organização. Os sete níveis definidos são:
• Nível G: Parcialmente Gerenciado;
• Nível F: Gerenciado;
• Nível E: Parcialmente Definido;
• Nível D: Largamente Definido;
• Nível C: Definido;
• Nível B: Gerenciado Quantitativamente;
• Nível A: Em Otimização.
O documento Guia Geral do MPS.BR explica a decisão por adotar sete níveis de
maturidade: “A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e
avaliação adequada às micros, pequenas e médias empresas. A possibilidade de se realizar
avaliações considerando mais níveis também permite uma visibilidade dos resultados de
melhoria de processos em prazos mais curtos.” [Softex, 2009].
Cada nível é composto por processos e capacidades de processo, definidos em
conformidade com as normas ISO/IEC 12207 (e emendas 1 e 2) e ISO/IEC 15504-5, para os
quais a organização deve direcionar a atenção de forma a melhorar seu processo. Atingir um
nível de maturidade, no MPS.BR, significa atender aos propósitos e resultados esperados dos
processos e atributos de processo referentes àquele nível [Softex, 2009]. A estrutura dos
níveis de maturidade é melhor entendida através da Figura 2.2.
Figura 2.2 - Estrutura dos Níveis de Maturidade do MPS.BR [Softex, 2009]
21
A dimensão de Capacidade reflete o nível de refinamento e institucionalização com o
qual um processo é executado na organização, enquanto a dimensão de processos indica o que
a organização deveria executar a fim de alcançar qualidade na produção, fornecimento,
aquisição e operação de Software [Weber, 2004]. A distribuição dos requisitos de Processo e
Capacidade entre os níveis do MPS.BR pode ser visualizada na Figura 2.3.
Tabela 2.1 - Processos e Atributos de Processo por Nível de
Maturidade [Softex, 2009]
Onde tem-se atributos para avaliação da capacidade, os seguintes:
• AP 1.1 - O processo é executado;
• AP 2.1 - O processo é gerenciado;
22
• AP 2.2 - Os produtos de trabalho do processo são gerenciados;
• AP 3.1 - O processo é definido;
• AP 3.2 - O processo está implementado;
• AP 4.1 - O processo é medido;
• AP 4.2 - O processo é controlado;
• AP 5.1 - O processo é objeto de inovações;
• AP 5.2 - O processo é otimizado continuamente.
2.5 Considerações Finais
Este capítulo apresentou o MPS.BR, trazendo um primeiro entendimento sobre seu
histórico, estrutura, componentes e organização em níveis de maturidade. Esta introdução ao
modelo é importante para dar continuidade a este trabalho que discutirá, no próximo capítulo,
sobre o processo de Gerência de Configuração, presente no Nível F do MPS.BR, utilizando os
conceitos vistos de processos, níveis de maturidade e resultados esperados.
23
3 PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO (GCO)
Este capítulo aborda conceitos referentes ao processo de Gerência de Configuração,
primeiramente no aspecto geral, para em seguida apresentar o propósito do processo no
contexto do MPS.BR. Ainda neste capítulo, são discutidos os resultados esperados do
processo de gerencia de configuração, presente no nível F do modelo.
3.1 Gerência de Configuração
Ao longo de projetos de desenvolvimento de software, a ocorrência de mudanças é
frequente, a qualquer momento, e a falta de uma gerência eficiente sobre estas mudanças pode
trazer problemas como re-trabalho, atraso no cronograma, ou em casos mais graves, perdas de
informação. Para que não ocorram maiores problemas decorrentes de mudanças sobre
produtos de trabalho, é necessário que estas sejam (1) registradas, (2) analisadas, (3)
reportadas para os interessados e (4) acompanhadas conforme medidas forem tomadas para
satisfazê-las. Esse controle sobre mudanças é a tarefa da área de processo chamada “Gerência
de Configuração”.
Gerência de Modificação ou Gerência de Configuração de Software (Software
Configuration Management – SCM) é uma atividade de apoio que se desenvolve ao longo de
todo o processo de software, comportando as ações de identificar e controlar mudanças,
garantir que as modificações sejam implementadas de forma adequada e comunicar as
modificações a todos os interessados [Pressman, 2006].
O papel principal da gerência de configuração é garantir que a produtividade não seja
prejudicada por erros, problemas ou mudanças, segundo Babich (1986), que define “a arte de
coordenar o desenvolvimento de software para minimizar... confusão é chamada de gerência
de configuração. A gerência de configuração é a arte de identificar, organizar e controlar
modificações no software que está sendo construído por uma equipe de programação. O
objetivo é maximizar a produtividade pela minimização dos erros.”
O termo “configuração”, no contexto da engenharia de software, representa uma
coleção de versões específicas de itens de configuração, combinados de acordo com
procedimentos específicos de construção para atender a um determinado objetivo [Dias,
2009]. Os itens de configuração (IC) são elementos, tratados como entidades individuais do
24
ponto de vista da gerência de configuração, que constituem o software e que estão sujeitos a
mudanças ao longo do seu desenvolvimento.
A IEEE (1990) define a Gerência de configuração de Software como a disciplina
responsável por aplicar procedimentos técnicos e administrativos para identificar e
documentar as características físicas e funcionais de IC, controlar suas alterações, armazenar e
relatar o processamento das modificações e verificar a compatibilidade com os requisitos
especificados, garantindo que tenha sido feito o que deveria ter sido feito.
3.1.1 Atividades da Gerência de Configuração
É importante notar, que o papel da SCM é acompanhar ações relacionadas a
modificações e não proibi-las de acontecer. Mudanças ocorrem ao longo de projetos de
software pelos mais variados motivos, como mudança de requisitos e mudanças na estratégia
da instituição. A gestão de configuração propõe meios de tratar essas mudanças de forma
organizada e eficaz.
O processo de Gerência de Configuração é responsável pelas seguintes tarefas
[Pressman, 2006]:
• Identificar todos os itens que definem coletivamente a configuração de software;
• Gerir modificações em um ou mais desses itens;
• Facilitar a construção de diferentes versões de uma aplicação; e
• Garantir que a qualidade do software seja mantida à medida que a configuração
evolui ao longo do tempo.
Sendo assim, a Gerência de Configuração de Software é usualmente dividida, conforme
IEEE (1987), em cinco funções: (1) identificação da configuração, (2) controle da
configuração, (3) contabilização da situação da configuração, (4) avaliação e revisão da
configuração, e (5) gerenciamento de liberação e entrega.
A função de identificação da configuração compreende: seleção dos itens passivos a
gerência de configuração (itens de configuração); definição de nomenclatura (inclusive
esquema de numeração para versões) apropriada para os itens de configuração identificados,
de forma que cada um tenha um identificador único; descrição dos itens de configuração (esta
25
descrição inclui uma lista de dados identificando o tipo do item, projeto, informações sobre
modificações e/ou versão [Presman, 2006]).
O controle de configuração fica encarregado de acompanhar a evolução dos itens de
configuração identificados na fase de identificação de configuração. Neste momento é
introduzido um importante conceito em gestão de configuração: Baselines ou configurações
básicas. Baselines são conjuntos de itens de configuração formalmente aprovados, agrupados em
determinados pontos do ciclo de vida de desenvolvimento e manutenção, para atender
propósitos específicos e que servem de base para etapas posteriores do projeto [IEEE, 1990].
Ainda no contexto do controle de configuração, pode-se identificar duas tarefas: (1) o
controle de versão e (2) o controle de mudança. O controle de versão objetiva identificar e
acompanhar o desenvolvimento de diferentes versões ou releases de um sistema
[Sommerville, 2003], ou seja as várias etapas pelas quais um item de configuração passa
desde sua criação até alcançar um estado em que contemple os propósitos para o qual foi
criado. A tarefa de controle de versão está intimamente relacionada com certas capacidades
fundamentais [Pressman, 2006]: um banco de dados de projeto (repositório) que armazena os
dados relevantes do projeto; uma estrutura com capacidade de gestão de versão, que armazene
todas as versões dos itens de configuração do projeto; facilidade de construir, possibilitando
coletar todos os objetos de uma configuração para contrução de uma versão específica do
software.
O controle de mudança estabelece atividades para conduzir uma modificação desde sua
solicitação até a verificação de sua implementação. É importante para definir um ciclo de vida
das modificações nos itens de configuração de forma organizada e sujeita a análises para
verificar a viabilidade e impactos na mesma. O controle de mudança é importante para manter
todos os interessados a par de quaisquer modificações em itens de configuração.
Em SOFTEX (2009), a função de contabilização da situação da configuração é
explicada: “A função de contabilização da situação da configuração visa: (1) armazenar as
informações geradas pelas demais funções; e (2) permitir que essas informações possam ser
acessadas em função de necessidades específicas. Essas necessidades específicas abrangem o
uso de medições para a melhoria do processo, a estimativa de custos futuros e a geração de
relatórios gerenciais.”
26
A auditoria de configuração é realizada no contexto da função de avaliação e revisão da
configuração, onde são realizadas as auditorias física (certificação de que as baselines geradas
estão completas, de acordo com o que havia sido planejado) e funcional (via revisão dos
planos, dados, metodologia e resultados dos testes, assegurando que ela cumpra corretamente
o que foi especificado) [Softex, 2009].
A função de gerenciamento de liberação e entrega garante a produção de itens de
configuração derivados a partir de itens de configuração fonte (construção), liberação (onde as
versões a serem disponibilizadas, de cada item de configuração, são identificadas) e entrega,
com a implantação do produto no ambiente de produção.
3.2 Gerência de Configuração no MPS.BR
O processo de gerência de configuração (GCO) do MPS.BR, faz parte dos processos do
nível de maturidade F (gerenciado), com o propósito de estabelecer e manter a integridade de
todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os
envolvidos [Softex, 2009a]. Este propósito é atingido ao passo em que processos formais de
controle de modificação são aplicados sobre baselines do projeto, mantendo a integridade dos
produtos de trabalho e posteriormente submetendo-os ao processo de liberação [Softex,
2009a].
Um fato importante no processo GCO, é que este está ligado a todos os demais
processos do MR-MPS por meio do atributo de processo RAP 13, que estabelece: “os
produtos de trabalho são colocados em níveis apropriados de controle” [Softex, 2009]. É
competência do GCO estabelecer quais produtos de trabalho estarão sujeitos a quais níveis de
controle, de acordo com sua criticidade.
3.3 Resultados Esperados
Segundo a versão mais atual do guia geral, o processo de gerência de configuração
(GCO) possui sete resultados esperados, são eles [Softex, 2009]:
• GCO 1: Um sistema de gerência de configuração é estabelecido e mantido;
• GCO 2: Os itens de configuração são identificados com base em critérios
estabelecidos;
27
• GCO 3: Os itens de configuração sujeitos a um controle formal são colocados sob
baseline;
• GCO 4: A situação dos itens de configuração e das baselines é registrada ao longo do
tempo e disponibilizada;
• GCO 5: Modificações em itens de configuração são controladas;
• GCO 6: O armazenamento, o manuseio e a liberação de itens de configuração e
baselines são controlados;
• GCO 7: Auditorias de configuração são realizadas objetivamente para assegurar que
as baselines e os itens de configuração estejam íntegros, completos e consistentes.
O primeiro resultado esperado, GCO1, exige que um sistema de gerência de
configuração seja implantado na organização. Para que seja implantado esse sistema é
necessário a implementação de três subsistemas: (1) controle de versão, (2) controle de
modificação e (3) gerenciamento de construção [Softex, 2009a].
O controle de versão é responsável em sistematizar os versionamentos dos produtos de
trabalho de forma segura e controlada, assegurando que versões anteriores possam ser
resgatadas. No que diz respeito à segurança, pode-se definir políticas de controle de acesso,
enquanto que políticas de controle de concorrência podem ser implementados para garantir
uma maior organização e controle nos produtos de trabalho [Softex, 2009a].
O controle de modificação gerencia a evolução de problemas identificados nos
produtos de trabalho desde sua solicitação até a sua conclusão. Por fim, a função do
gerenciamento de construção é transformar itens de configuração fonte em produtos para o
usuário final, um exemplo disso é tornar código fonte em um executável [Softex, 2009a].
Um ponto importante o qual deve ser observado na implantação de um sistema de
gerência de configuração é a possibilidade de implementação pela organização sem o auxílio
de ferramentas automatizadas [Softex, 2009a]. Porém, o auxílio de uma ferramenta torna-se
indispensável, pois existem operações difíceis de gerenciar apenas com documentação, como
regaste de históricos e versões anteriores, evoluções de versões paralelas de um dado projeto,
controle sobre o ciclo de vida de solicitações de mudanças, mapeamento entre itens de
configuração e baselines.
28
O segundo resultado esperado, GCO2, necessita que a organização estabeleça critérios
para definir o que será um item de configuração (IC). Esses critérios, geralmente, encontram-
se no Plano de Gerência de Configuração [Softex, 2009a].
Com os critérios definidos, a identificação de IC envolve (1) avaliar os produtos de
trabalho de acordo com os critérios estabelecidos que definem os itens de configuração; (2)
atribuir identificadores únicos aos itens selecionados, isto é, estabelecer um padrão de
nomenclatura para os itens de configuração; e (3) listar os itens de configuração detalhando
suas características (atributos como nome, conteúdo, responsáveis, autores, localização no
repositório, nível de controle desejado).
No GCO3, pede-se que em cada ponto do ciclo de vida de um software (geralmente os
marcos) seja selecionado um grupo itens de configuração definidos pelo GCO2, e a partir
deles gerar uma baseline. Para definir uma baseline é necessário um controle formal em sobre
cada item de configuração selecionado, além disso, os critérios para a aprovação desta estarão
contidos dentro do Plano de Gerência de Configuração [Softex, 2009a].
O Guia de Implementação [Softex, 2009a] sugere que pode ser utilizado o mecanismo
de criação de rótulos (tags), presente em ferramentas de controle de versões, sobre uma
configuração de versões de IC, o qual é suficiente para implementar o conceito de baselines.
Conforme os itens de configuração evoluem ao longo do projeto e baselines são
definidas, surge a necessidade de identificar, diferenciar e recuperar o conteúdo de itens de
configuração em diferentes etapas do projeto, ou seja, é necessário assegurar que todos os
interessados tenham acesso e conhecimento sobre o histórico e situação específica de itens de
configuração ou baselines ao longo do tempo. As ferramentas de controle de versão
armazenam o histórico das alterações realizadas sobre os itens do repositório, e é através desta
funcionalidade das ferramentas que pode-se alcançar o GCO 4 [Softex, 2009a].
Os históricos das ferramentas de controle de versão devem fornecer informações
suficientes para um mapeamento preciso dos componentes de uma determinada baseline,
apresentando a versão específica de cada item de configuração e permitindo a recuperação
desta configuração. Com essas informações é possível fazer comparações entre releases,
contabilizando o que foi feito ao longo do projeto. Aliado ao sistema de controle de
mudanças, é possível um controle ainda maior sobre o andamento do projeto.
29
O GCO5 é referente à gestão do ciclo de vida de uma solicitação de mudança, o qual
será acompanhado desde a sua solicitação até a conclusão. Porém, antes de uma solicitação de
mudança ser efetivamente realizada, é necessário ser avaliada a viabilidade e os impactos que
a mudança causarão no projeto a partir de um processo formal utilizando critérios
estabelecidos na organização, esses critérios devem estar contidos no Plano de Gerência de
Configuração [Softex, 2009a].
Segundo o guia de implementação, para que haja um bom controle nas modificações,
seria interessante: designar um responsável para efetuar a mudança; registrar todas as
mudanças realizadas com suas justificativas; revisões para que as mudanças não causem
efeitos indesejáveis; obter uma autorização antes de implementar a modificação a uma nova
versão; disponibilizar as interessados e autorizados [Softex, 2009a].
No sexto resultado esperado, GCO6, espera-se que a organização armazene todos os
itens de configuração seguindo as especificações definidas no Plano de Gerência de
Configuração. Além disso, deverá ser definido o método de acesso concorrente aos IC do
repositório e o sistema de autenticação para acessá-los, levando em conta também a definição
de meios de acesso através de canais seguros.
Ainda no GCO6, é necessário estabelecer a liberação de baselines para os interessados,
gerando versões de baseline para produção e produtos de trabalho fechados. As baselines de
produção são utilizadas pela equipe de desenvolvimento para evolução do produto de forma
incremental. Os produtos de trabalho fechados são as baselines que serão enviadas para o
cliente, essa versão só será liberada depois da aprovação do processo de auditoria [Softex,
2009a].
Por fim, o último resultado esperado, GCO7, refere-se às auditorias de gerência de
configuração, que irá avaliar se todos os procedimentos previstos no Plano de Gerência de
Configuração estão sendo seguidos, além de verificar a consistência, completitude e
integridade dos IC e baselines. As datas das auditorias são definidas previamente no Plano de
Gerência de Configuração e são auditadas por alguém que não está diretamente ligado ao
projeto, sendo possível o auxílio de um checklist para aumentar a objetividade da auditoria
[Softex, 2009a].
Outra auditoria importante é referente à baseline, no qual são efetuados dois tipos de
auditorias: a funcional e a física. Na auditoria funcional são revisados documentos de teste,
30
planos, metodologia para verificar se a baseline está correta, ou seja, avalia se ela cumpre o
seu propósito, todas as versões dos IC estão de acordo com o previsto. No entanto, a auditoria
física verifica a completitude da baseline, avaliando se todos os IC estão presentes [Softex,
2009a].
3.4 Considerações Finais
O capítulo 3 apresentou uma visão geral do processo de Gerência de Configuração de
Software, atividade guarda-chuva responsável pela consistência e disponibilidade dos
produtos de trabalho de um projeto de software. Foi visto o papel do processo no contexto do
modelo MPS.BR, tópicos que servem de base para o próximo capítulo, “Proposta de Apoio
Sistematizado”, onde será iniciada a análise de implementação do processo de GCO
utilizando ferramentas livres.
31
2
4 PROPOSTA DE APOIO SISTEMATIZADO
Este capítulo inicia o principal estudo deste trabalho: a definição de uma proposta de apoio
sistematizada ao processo de Gerência de Configuração do MPS.BR, utilizando apenas
ferramentas de software livre, e uma ferramenta desenvolvida no contexto do projeto SPIDER, da
Universidade Federal do Pará (UFPA): a Spider-CL. Neste capítulo a metodologia será apenas
introduzida, tendo ênfase em apresentar o projeto SPIDER, as ferramentas escolhidas para uso na
metodologia e como estas podem ser utilizadas para suprir as necessidades dos resultados
esperados do processo de GCO do MPS.BR.
4.1 Projeto SPIDER
O projeto de pesquisa intitulado “SPIDER: Uma Proposta de Solução Sistêmica de um
SUITE2 de Ferramentas de Software Livre de apoio à implementação do modelo MPS.BR”
nasceu em 2009, no Instituto de Ciências Exatas e Naturais (ICEN) da Universidade Federal
do Pará (UFPA), em parceria com o Centro de Informática (CIN) da Universidade Federal do
Pernambuco (UFPE) e com o Departamento de Estatística e Informática (DEINFO) da
Universidade Federal Rural de Pernambuco (UFRPE) [Oliveira, 2008].
O objetivo do projeto é apresentar alternativas viáveis para auxiliar a implementação
dos processos do MPS.BR, através do apoio de ferramentas livres, agilizando o processo de
implementação do modelo de qualidade e reduzindo custos para as organizações, que não
necessitam fazer aquisição de ferramentas proprietárias, além de terem a liberdade de
customizarem as ferramentas de acordo com suas necessidades.
Neste contexto, o projeto SPIDER tem, como uma das principais metas, realizar um
levantamento de ferramentas de software livres que possibilitem a criação de produtos de
trabalho (artefatos que evidenciam a implementação do programa de qualidade
organizacional) derivados dos resultados esperados descritos nos objetivos dos processos,
2 SUITE Conjunto de ferramentas com um propósito comum. Neste caso, um conjunto de ferramentas livres
para apoiar a implementação sistematizada do modelo MPS
32
inicialmente, dos níveis de maturidade G (parcialmente gerenciado) e F (gerenciado) do
MPS.BR [Oliveira, 2008].
A partir deste levantamento, pretende-se definir um SUITE de ferramentas, com a
intenção de fazer uso integrado das funções/operações disponibilizadas pelas ferramentas,
realizando a implantação dos processos do modelo MPS.BR, em aderência ao fluxo de
dependência proposto por este modelo de qualidade de processo [Oliveira, 2008].
Dentro do projeto SPIDER, foram definidos subprojetos referentes a (1) levantamento
de ferramentas e definição de metodologias de apoio sistematizado para atender aos
resultados esperados de cada processo dos níveis de maturidade F e G do MPS.BR, e (2)
propostas de integração para os processos dos referidos níveis [Spider, 2009]. Este trabalho
surge do subprojeto homônimo a esta monografia.
4.2 Ferramentas de Software Livre para Apoio do Processo de Gerência
de Configuração.
A área de gerência de configuração é rica quanto à disponibilidade de ferramentas para
apoiar suas funções. Para este trabalho, foram pesquisadas ferramentas de software livre para
controle de versão e controle de mudanças, analisando seu atendimento aos resultados
esperados do MPS.BR.
Ferramentas de controle de versão são responsáveis por armazenar as diversas versões
dos itens de configuração e assegurar que as modificações sobre esses itens ocorram de forma
segura e controlada. Logo, é pertinente a este grupo de ferramentas definir políticas de
controle de acesso (autenticação, autorização e auditoria) e controle de concorrência (políticas
para viabilizar o trabalho cooperativo) [Softex, 2009a]. Os serviços pertinentes a este grupo
de ferramentas são: armazenamento, identificação, disponibilização e gerenciamento dos itens
de configuração; prover histórico e possibilitar rastreio das modificações feitas sobre os itens
de configuração; criação de ramificações e rótulos para configurações específicas dos itens de
configuração; e recuperação de configurações específicas ou baselines do projeto.
O controle de mudanças é instaurado através de ferramentas que controlam o ciclo de
vida das solicitações de modificações ao longo do projeto, desde seu pedido até a
incorporação em uma baseline [Softex, 2009a]. Oferece serviços para identificar, rastrear,
analisar e acompanhar as mudanças. Este tipo de sistema é importante para dar visibilidade ao
33
processo de Gerência de Configuração ao ponto que pode guiar auditorias e apresentar
diferença entre baselines através de histórico de solicitações e implementações de mudanças.
A seguir, são listadas as ferramentas pesquisadas durante a elaboração deste trabalho,
com uma breve descrição, apontando principais características, fornecedores, versões e suas
licenças.
4.2.1 Controle de versão
No grupo de ferramentas de controle de versão, foram pesquisadas as ferramentas CVS
[CVS, 2009], Git [Git, 2009], Subversion [Subversion, 2009] e Mercurial [Mercurial, 2009].
4.2.1.1 Concurrent Version System - CVS
O CVS (disponível em http://nongnu.org/cvs/) é um sistema de controle de versões,
usado para se registrar o histórico de modificações de arquivos. Inicialmente criado por Dick
Grune em 1986 como um conjunto de scripts para facilitar o uso do RCS, o CVS começou a
ser reescrito na linguagem C em1989 por Brian Berliner. Hoje o CVS é um software livre, de
uso gratuito e mantido pela Free Software Foundation [FSF, 2009], sob licença GNU General
Public License v2.
A utilização do CVS é feita através de linha de comando, ou através de uma das várias
opções de clientes gráficos (TortoiseCVS [TortoiseCVS, 2009], por exemplo), e IDE’s
(Integrated Development Environment – Ambiente de Desenvolvimento Integrado) que
fornecem integração com a ferramenta (como o caso da IDE Eclipse [Eclipse, 2009]).
4.2.1.2 Git
Git (disponível em http://git-scm.com/) é um software livre (liberado sob a licença
GPL) para controle de versão distribuído. Git foi inicialmente criado por Linus Torvalds,
inspirado por dois outros sistemas de versionamento (BitKeeper e Monotone), para o
desenvolvimento do kernel Linux. O objetivo do Git é atender requisitos como:
desenvolvimento distribuído, manipulação de grandes conjuntos de arquivos, operações de
junção (merge) complexas, e rapidez.
Cada diretório de trabalho Git é um repositório com todos os históricos e habilidade
total de controle das revisões, não dependente de acesso a uma rede ou a um servidor central.
34
Vários projetos de software usam Git para controle de versão, exemplos notáveis como
Kernel do Linux, Servidor X.org, Qt (toolkit) e a ferramenta de trabalho web Ruby on Rails.
4.2.1.3 Mercurial
Mercurial (disponível em http://selenic.com/mercurial) é uma ferramenta multi-
plataforma de controle de versão distribuído para desenvolvedores de software. O projeto
surgiu em abril de 2005, e o sistema é implementado principalmente em Python, porém o
utilitário binário diff foi escrito na linguagem de programação C. Mercurial foi inicialmente
escrito para operar sobre Linux, mas foi portado para Windows, Mac OS X, e a maioria dos
outros sistemas UNIX. Mercurial é principalmente um programa de linha de comando. Todas
operações do Mercurial são chamadas através de palavras-chave de opções para o programa
controlador hg, uma referência para o símbolo químico do elemento Mercúrio.
Suas principais características incluem a alta performance e escalabilidade,
descentralidade, ser totalmente distribuído colaborativamente, ter um suporte robusto tanto
para arquivos de texto quanto binários e capacidades avançadas de branching (ramificação) e
merging,(junção) mantendo-se simples.
A versão mais atual disponível é a 1.3.1, e o Mercurial é distribuído sob licença GNU
General Public License V2.
4.2.1.4 Subversion
O Subversion, ou SVN, (disponível em http://subversion.tigris.org/) é uma ferramenta
de controle de versão, projeto da CollabNet. Além do controle de versão do conteúdo dos
arquivos, também permite controle de mudanças sobre diretórios, cópias, renomeações e
meta-dados. Algumas das principais funcionalidades do Subversion estão listadas a seguir:
• controle de versões de arquivos texto e binário: utiliza um algoritmo para
diferenciação binário que funciona de modo idêntico para arquivos textos e
binários;
• ramificações de projetos: possui mecanismos para criação de ramos em projetos,
permitindo desenvolvimentos paralelos;
• acesso ao repositório: pode ser acessado através de protocolos de rede ou disco
local. Sua localização sempre é determinada através de uma URL.
35
O SVN não conta com interface gráfica, porém clientes gráficos de terceiros fornecem
essa funcionalidade, a exemplo de clientes como o TortoiseSVN [TortoiseSVN, 2009] e
RapidSVN [RapidSVN, 2009], e conta com clientes e plugins para integração com alguns
IDE’s como o Subeclipse (plugins para eclipse), AnkhSVN [AnkhSVN, 2009] e VisualSVN
[VisualSVN, 2009] (ambos para Visual Studio).
A ferramenta se encontra na versão 1.6.6 e está disponível sob licença GNU GPL.
4.2.2 Controle de Mudanças
Entre as ferramentas de controle de mudança, foram pesquisadas as ferramentas
Bugzilla [Bugzilla, 2009], Mantis [Mantis, 2009], Redmine [Redmine, 2009], Scarab [Scarab,
2009] e Trac [Trac, 2009].
4.2.2.1 Bugzilla
Bugzilla (disponível em http://www.bugzilla.org/) é um Defect Tracking System
(Sistema de Rastreio de Defeitos) feito para gerenciar o ciclo de vida de solicitações de
modificações geradas no decorrer de um projeto. O Bugzilla é uma ferramenta livre open
source utilizada pela equipe Mozilla para desenvolvimento de seus projetos, incluindo o
próprio Bugzilla. Atualmente, a versão mais estável da ferramenta é a versão 3.4.2.
Esta ferramenta de bugtracking possui características como: uma estrutura de banco de
dados otimizado, proporcionando um melhoramento na performance e escalabilidade;
segurança; sistema de permissão de acesso de fácil compreensão; integração com
funcionalidades de email; gerenciamento profiles; campos customizáveis.
4.2.2.2 Mantis
O Mantis (disponível em http://www.mantisbt.org/) é uma ferramenta de bugtracking,
sob licença GPL, desenvolvido para auxiliar o controle de modificações, no contexto do
processo de Gerência de Configuração, através do gerenciamento das issues. Issues são
relatos de problemas identificados nos produtos de trabalho, que terão sua evolução
acompanhada desde a solicitação da mudança até seu desfecho.
Por ser um software executado em browser, ele independe de sistema operacional e sua
base de dados pode ser estruturada em MySQL, MS SQL e PostgreSQL. A sua versão mais
recente e estável é a versão 1.1.8, mas atualmente está sendo desenvolvida a versão 1.2.0rc2.
36
Entre as principais funcionalidades desta ferramenta são identificados: criação de issues;
gerenciamento do ciclo de vida dos issues; registro do histórico dos issues; e controle de
workflow da ferramenta. Outros aspectos marcantes são: a possibilidade de customização;
interface amigável, proporcionando fácil utilização; e a facilidade de extensão através de
plugins.
4.2.2.3 Redmine
O Redmine (disponível em http://www.redmine.org) é outra ferramenta de bugtracking,
open source sob licença GPL, implementado na linguagem de programação Ruby utilizando o
framework Rail. A sua versão estável é 0.8.5, lançada em 13 de setembro de 2009, mas
atualmente encontra-se em desenvolvimento a versão 0.9.
Entre as funcionalidades desta ferramenta é possível identificar: possui suporte a
múltiplos projetos e subprojetos; possui um calendário e Gráfico de Gantt; campos
customizáveis; integração com repositórios de vários sistemas de controle de versão; permite
definir as próprias regras de permissão de acesso; cada projeto possui sua wiki e fórum.
4.2.2.4 Scarab
O Scarab (disponível em http://scarab.tigris.org/) é uma ferramenta open source de
controle de mudanças altamente customizável. A sua versão mais atual encontra-se na versão
0.21, sendo o release mais estável.
Características do Scarab são: suporte a muitos idiomas; possibilidade de
exportar/importar para outras ferramentas de controle de mudanças a partir de uma interface
XML; fácil customização; possibilidade de incluir dependências entre solicitações de
mudanças.
4.2.2.5 Trac
O Trac (disponível em http://trac.edgewall.org/) é uma ferramenta utilizada para auxiliar
no processo de desenvolvimento de softwares com o objetivo de gerenciar bugs, sua estrutura
é baseada em wiki e executada em browser. Este aplicativo open source é implementado em
python e sua versão mais estável é 0.11.5, possuindo integração nativa com o subversion, mas
capaz de se integrar com outros sistemas de controle de versão.
37
Por ser baseado em wiki, o Trac permite fazer formatações nas descrições de
solicitações de mudanças e commit de mensagens, também é possível criar referências para
bugs, arquivos, tarefas, páginas wiki através de links. Outra funcionalidade presente na
ferramenta é a capacidade de verificar o andamento de projetos através da funcionalidade
Roadmap, ou o percurso do projeto através de milestones (marcos).
4.3 Ferramentas Analisadas para a Metodologia Proposta
Para este trabalho, foram selecionadas dois conjuntos de ferramentas para a aplicação da
metodologia a ser desenvolvida: conjunto Mantis e CVS; e o conjunto Trac e Subversion.
Como critério para a escolha, foi levado em conta a popularidade das ferramentas CVS e
SVN, e a verificação de que as ferramentas Mantis e Trac são comumente usadas em conjunto
com os respectivos pares. Além disso, a metodologia a ser definida é adaptável a várias
ferramentas que contemplem pré-requisitos a serem listados, e dentre as ferramentas listadas
anteriormente, foram selecionadas estas ferramentas para demonstrar como a metodologia
pode ser empregada utilizando ferramentas com diferentes funcionalidades, mas que possuem
o mesmo propósito.
A escolha das ferramentas em pares foi realizada para alinhar o atendimento dos
resultados esperados do processo de Gerência de Configuração, com um par de ferramentas
de controle de versão integrado com uma ferramenta de controle de mudança. A exemplo do
caso da dupla Trac e Subversion, o Trac possui integração nativa com repositórios criados
pelo Subversion.
As ferramentas Trac, Mantis, Subversion e CVS, além de atenderem aos requisitos
necessários para utilização da metodologia desenvolvida neste trabalho, também caracterizam
ferramentas largamente difundidas na comunidade de software livre e são constantemente
empregadas por organizações desenvolvedoras de software.
Outro ponto importante é o uso do Tortoise, um cliente de interface gráfica sob licença
GPL para as ferramentas CVS (TortoiseCVS) e Subversion (TortoiseSVN) o qual permite
uma interação nas funcionalidades diretamente pelas janelas do Windows Explorer. Vale
esclarecer que a metodologia utilizada neste trabalho não depende do uso desta interface e
nem oferece funcionalidade a mais que as ferramentas CVS e SVN. O Tortoise foi utilizado
apenas para facilitar a apresentação das funcionalidades das ferramentas de controle de versão
ao longo deste trabalho.
38
Além das ferramentas citadas, outra ferramenta empregada na metodologia proposta,
como uma ferramenta auxiliar, é a Spider-CL. A Spider-CL [Barros, 2009] é uma ferramenta
desenvolvida no projeto SPIDER, com propósito de criar checklists compostos por critérios
objetivos para utilização em diversos contextos, provendo mecanismos para a aplicação destes
checklists, mantendo histórico e registrando seus resultados.
Checklists são bastante utilizados para avaliações e inspeções objetivas de produtos de
trabalhos diversos em organizações. Um checklist é uma lista de atributos ou qualidades que
devem ser avaliados em um determinado produto de trabalho, onde cada um desses atributos
possui uma lista de possíveis valores dos quais apenas um pode ser marcado. Um checklist
nada mais é do que uma relação organizada de critérios objetivos [Barros, 2009].
A Spider-CL é uma ferramenta web, que pode ser executada através de servidor
Tomcat, sendo acessível de qualquer navegador web, e seu banco de dados é estruturado em
MySQL. Conta com serviço de controle de acesso através de cadastro de usuários e provê a
sistematização do processo de definição e aplicação de checklists para avaliação, inspeção ou
revisão através de critérios objetivos. A interface da Spider-CL foi desenvolvida utilizando
componentes gráficos convencionais como caixas de textos, tabelas, listas e botões, para
permitir fácil utilização [Barros, 2009].
A ferramenta Spider-CL é marcada pelas seguintes características:
• É uma ferramenta gratuita;
• É portável, sendo desenvolvida como uma aplicação para o servidor Tomcat. A
ferramenta pode ser executada em qualquer servidor capaz de executar o Tomcat
6.0 e o MySQL 5.1;
• Possui uma interface de fácil utilização;
• Pode ser utilizada para o desenvolvimento de qualquer tipo de checklist objetivo;
• Possui controle de acesso e mantém registro de todas as utilizações de cada
checklist;
• Exporta os checklists preenchidos e seus resultados para o formato PDF.
39
No contexto da metodologia a ser proposta neste trabalho, os checklists gerados pela
ferramenta Spider-CL serão utilizados para definição de critérios objetivos, necessários para a
implementação de alguns resultados esperados.
4.4 Mapeamento das Ferramentas aos Resultados Esperados (pontos
fracos e fortes)
Foi feito um mapeamento entre as funcionalidades disponíveis pelas ferramentas
Mantis, Trac, Subversion, CVS, e Spider-CL e o atendimento aos requisitos do processo de
Gerência de Configuração do MPS.BR, a fim de analisar o nível de atendimento destas em
relação ao modelo, para a possível definição de mudanças ou ações corretivas para adequar
seu uso ao requisitos propostos pelo modelo. O mapeamento resultou nos seguintes dados
exibidos na Figura 4.1.
Figura 4.1 – Mapeamento dos Resultados Esperados com as
Ferramentas de GCO.
Os detalhes do mapeamento são descritos a seguir, divididos por resultados esperados,
apresentando as funcionalidades de ferramenta necessárias para a implementação de cada
resultado pela execução da metodologia proposta, e quais as funcionalidades oferecidas por
cada conjunto de ferramentas analisado.
É importante observar, que a legenda da Figura 4.1 indica o nível de aderência da
ferramenta aos objetivos dos resultados esperados, no sentido de fornecer insumos para que o
40
resultado esperado seja alcançado no nível de implementação indicado (Totalmente
Implementado, Totalmente Implementado com Oportunidade de Melhoria, Parcialmente
Implementado ou Não Implementado). Além disso, é interessante destacar que os casos em
que o nível de implementação foi classificado como “Totalmente Implementado com
Oportunidade de Melhoria” foram situações resolvidas com a utilização de alguns plugins,
conforme será descrito ao longo da metodologia.
4.4.1 GCO 1: Subversion e Trac / CVS e Mantis
O atendimento do primeiro resultado esperado de GCO envolve definir e manter um
sistema de gerência de configuração. Do ponto de vista ferramental isto é resolvido ao
planejar e institucionalizar o uso de ferramentas de controle de versão e controle de mudança.
Utilizando as ferramentas Subversion e Trac, a primeira ferramenta é devidamente
configurada e tem seu(s) repositório(s) definido(s), sob o qual realizará o controle de versão.
A segunda ferramenta, responsável pelo controle de mudanças, tem seu ambiente instanciado,
e as suas páginas wiki integradas podem ser usadas para a definição de um plano de gerência
de configuração. Este par de ferramentas implementa totalmente o GCO 1.
Para atender o primeiro resultado esperado utilizando o outro conjunto de ferramentas,
será necessário o uso das ferramentas CVS e Mantis, os quais implementam um sistema de
controle de versão (com definição de repositório) e um sistema de controle de modificação,
respectivamente. Além de possuir esses dois sistemas, é necessário que exista um plano de
gerência de configuração o qual não é contemplado em nenhuma das ferramentas. Este grupo
de ferramentas fornece insumos para implementar totalmente o resultado esperado, apenas
atentando para a integração com o sistema de páginas wiki (o Dokuwiki), como oportunidade
de melhoria..
4.4.2 GCO 2: Trac, Mantis, Spider-CL
Este resultado esperado requer mecanismos para identificar itens de configuração,
segundo critérios objetivos, definindo identificadores únicos para cada um. Uma abordagem
sistematizada através de ferramentas requer um meio de definir os critérios objetivos para a
identificação e registrar os itens identificados de acordo com estes critérios, além de cadastrar
em algum lugar um formato padrão para a nomenclatura dos itens de configuração
identificados.
41
A definição de critérios objetivos pode ser feita através da ferramenta Spider-CL, que
possui todas as funcionalidades para definição e aplicação de checklists objetivos. Esta
ferramenta deve ser usada em conjunto com a wiki da ferramenta Trac para o registro dos
itens de configuração e definição de regras de nomenclatura para os itens de configuração. A
união Spider-CL e Trac, implementa totalmente o GCO 2.
A ferramenta Spider-CL em conjunto com a ferramenta Mantis, fornece insumos para
que seja implementado totalmente o resultado, porém nota-se a oportunidade de melhoria de
integrar a ferramenta a um sistema wiki, para publicação do plano e dos resultados do
checklist, o que foi resolvido com a integração a DokuWiki
4.4.3 GCO 3: CVS, Subversion
A implementação do conceito de baselines através de ferramentas de controle de versão
é possível através de funcionalidades de tags (rótulos), presente na grande maioria dos
sistemas deste tipo.
Para satisfazer o terceiro resultado esperado, será utilizada a funcionalidade de tags
(etiqueta) das ferramentas de controle de versão CVS e Subversion. A tag será utilizada para
indicar que uma dada versão de um produto é uma baseline. Esta funcionalidade, nada mais é
do que o registro de um “instantâneo” de uma determinada configuração do repositório, que
pode ser recuperada a qualquer momento, reduzindo o risco de ser perdida.
4.4.4 GCO 4: Subversion, Trac e CVS
A implementação sistematizada do resultado esperado GCO 4, é implementável por
ferramentas de controle de versão, onde é possível acompanhar a evolução de baselines e seus
itens de configuração através de suas funcionalidades de alteração de repositório e registro de
históricos.
Entre as funcionalidades do CVS para apoiar a implementação deste resultado esperado,
tem-se a funcionalidade Log em conjunto com os comentários das operações de commit
(envio ao repositório), esta funcionalidade permite visualizar, o histórico da evolução de um
dado item de configuração, exibindo cada versão dos itens de configuração com os
comentários e os itens de configuração pertencentes a cada baseline. Outra funcionalidade
presente na ferramenta para satisfazer o GCO 4, é a operação de diff, o qual permite verificar
diferenças entre duas versões de itens de configuração.
42
De modo semelhante, a ferramenta Subversion fornece soluções para implementar
totalmente o GCO 4, através de funcionalidades de acompanhamento das alterações dos itens
do repositório. O Subversion conta com funcionalidade de Log que lista todas as alterações
realizadas sobre tags (as baselines) ou mesmo diretórios, e todos os seus respectivos itens,
permitindo um mapeamento preciso entre as baselines e as versões de cada item pertencentes.
O Subversion também permite a comparação entre diferentes versões de itens do seu
repositório. A integração do Trac aos repositórios do SVN permite a visualização do mesmo
também por navegador, através da sua funcionalidade Repository Browser que permite a
visualização de qualquer revisão dos itens do repositório. Alterações no repositório são
acompanhadas pelo Trac através do Timeline, onde todas as mudanças ocorridas são
armazenadas de forma semelhante ao histórico do SVN.
4.4.5 GCO 5: Mantis, Trac
A implementação sistêmica do GCO 5, implica na utilização de ferramentas de controle
de mudança, utilizando seus recursos para tratar e acompanhar as mudanças solicitadas ao
longo de um projeto, fornecendo apoio para que os responsáveis selecionados pela
organização tomem decisões sobre a resolução de solicitações de mudanças, e realizem as
autorizações necessárias.
Toda modificação em um item de configuração deve ser registrada, avaliada e aprovada,
para que isso ocorra, a ferramenta Mantis irá gerenciar o ciclo de vida de cada solicitação de
modificação a partir do conceito de issue. Para manter um controle efetivo na evolução dos
issues, a ferramenta disponibiliza de um sistema de histórico, onde estará contida a
modificação efetuada, a data e seu autor. Outra funcionalidade presente no Mantis é a
possibilidade de incluir relacionamentos entre issues, esta funcionalidade não é obrigatória
para este resultado esperado, mas é importante para melhor visibilidade das dependências
entre as solicitações de modificação e possíveis impactos. A ferramenta Mantis fornece apoio
para implementar totalmente este resultado esperado.
A ferramenta Trac dispõe de recursos semelhantes ao Mantis, porém seus registros de
mudanças são feitos através do seu sistema de Tickets. Os tickets do Trac possuem ciclo de
vida, baseados em estados, que servem para o controle e acompanhamento das mudanças
registradas, além de disponibilizar de várias formas de apresentar por relatórios estes tickets e
promover o acompanhamento dos mesmos. O Trac ainda conta com uma funcionalidade de
43
milestones, para associar as mudanças aos pontos de controle do projeto, facilitando os
processos de auditoria. A ferramenta Trac não possui mecanismo nativo para relacionamento
entre os problemas identificados (tickets), implementando o resultado esperado totalmente,
porém com uma oportunidade de melhoria.
4.4.6 GCO 6: Mantis, Trac, Subversion e CVS
Alcançar o resultado esperado GCO 6 requer a utilização apropriada do sistema de
gerência de configuração, mantendo controle sobre quem acessa e altera o repositório. Para
isto, é necessário a garantia da segurança das informações e controlar o acesso às
informações, tanto do ponto de vista de políticas de permissões de acesso, quanto em relação
ao acesso concorrente às informações, certificando que as informações sob domínio do
processo de Gerência de Configuração estejam disponíveis aos responsáveis de forma
adequada.
Um dos requisitos necessários para contemplar o sexto resultado esperado é a questão
de segurança, a qual todas as ferramentas analisadas conseguem satisfazer utilizando
protocolos de autenticação de usuários como o SSL (Secure Socket Layers) ou SSH (Secure
Shell), por exemplo. Outra questão importante neste resultado esperado é o acesso
concorrente aos dados do repositório, o qual pode ser satisfeito com o uso dos métodos
“Copy-Modify-Merge” ou “Lock-Modify-Unlock” presentes na ferramenta de controle de
versão. No método Copy-Modify-Merge permite que toda a equipe de desenvolvimento acesse
os dados do repositório e modifique independentemente, e ao final, todos podem submeter
suas modificações e efetuar a operação de merge, em caso de conflito, para mesclar as
diferentes mudanças de forma consistente. O método Lock-Modify-Unlock, diferentemente do
método anterior, permite que apenas um usuário acesse um determinado dado do repositório,
e esse dado será disponível ao resto da equipe de projeto apenas quando a modificação for
submetida.
Ainda neste contexto, as ferramentas propostas possuem políticas de permissões de
acesso, definindo níveis de acesso e manipulação diferentes para diferentes papéis de
usuários. As ferramentas analisadas fornecem mecanismos para contemplar totalmente este
resultado através de seu apoio.
44
4.4.7 GCO 7: Spider-CL, Mantis, CVS, Trac e Subversion
Auditorias devem ser feitas com base em critérios objetivos para verificação do
andamento do processo de gerencia de configuração e do estado das baselines em relação ao
que fora planejado.
Para efetuar as auditorias de configuração, será utilizada a ferramenta de apoio Spider-
CL para geração e armazenamento dos checklists que serão utilizados para guiar as auditorias.
Para verificar se os procedimentos e padrões planejados estão sendo seguidos, serão utilizados
os históricos e relatórios das ferramentas Mantis e CVS, ou Trac e Subversion, como
referência. As ferramentas apóiam a implementação total deste resultado esperado.
4.5 Sugestões de Melhoria do Ferramental de Apoio
Como foi mencionado na seção anterior, os resultados esperados GCO 1, GCO 2 e GCO
7 poder ser satisfeitos com o apoio do conjunto Mantis e CVS com uma oportunidade de
melhoria. Para que estes resultados esperados sejam contemplados, é necessária a integração
com o sistema DokuWiki para integrar uma wiki ao Mantis. A partir dessa instalação, será
possível criar uma instância de uma página da wiki onde haverá o plano de gerência de
configuração.
Apesar do conjunto Trac e Subversion fornecer o apoio suficiente para que sejam
totalmente implementados os resultados esperados, conforme analisado, ainda é interessante a
possibilidade de definir relações entre problemas identificados, no contexto do resultado
esperado GCO 5, o que pode ser alcançado através da instalação do plugin “MasterTickets”.
4.6 Considerações Finais
O capítulo 4 apresentou o Projeto SPIDER, e seus propósitos de definir metodologias de
apoio a implementação dos níveis de maturidade G e F do MPS.BR, exclusivamente através
de ferramentas de software livre, para diminuição do tempo e complexidade das
implementações, além da redução de custo para as organizações. Aqui foram mostrados os
dados coletados sobre as ferramentas disponíveis, hoje, para apoio da gestão de configuração
de software e o mapeamento de dois conjuntos de ferramentas que serviram como base para
definição de uma metodologia sistêmica para a implementação do processo de Gerência de
Configuração do MPS.BR, a ser descrita no Capítulo 5.
45
A partir da análise feita neste capítulo sobre as ferramentas definidas no projeto
SPIDER para apoiar o processo de GCO, foi definido um protótipo para cada conjunto de
ferramentas analisados, a fim de integrar a implementação dos resultados esperados através da
metodologia a ser definida a seguir, exemplificando-a do ponto de vista de dois conjuntos de
ferramentas com funcionalidades ligeiramente distintas.
46
5 METODOLOGIA PARA A IMPLEMENTAÇÃO DO PROCESSO DE GERÊNCIA DE
CONFIGURAÇÃO
Este capítulo descreverá a metodologia proposta para implementação sistematizada do
processo de gerência de configuração do MPS.BR, através do uso de ferramentas livres. A
metodologia será exemplificada através da utilização de dois conjuntos de ferramentas a
serem descritos, e mostrará as evidências geradas em cada ferramenta, para cada resultado
esperado.
A proposta deste trabalho não é, em momento algum, propor a descrição de um
processo para organizações, mas sim apresentar uma metodologia de uso de ferramentas que
será base para a criação de um manual de uso das ferramentas e sugerir boas práticas para
promover maior agilidade na implantação do processo de gerência de configuração em
organizações, sem que haja qualquer imposição que cause mudança de cultura que não
objetive a implementação dos resultados esperados do processo segundo o MPS.BR.
Questões referentes à instalação, configuração e uso da ferramenta que não estiverem
bem detalhadas neste capítulo, podem ser vistas com maior clareza no Manual de
Implementação do Processo de Gerência de Configuração, disponível em www.ufpa.br/spider.
5.1 Descrição do Cenário
A metodologia a ser proposta neste capítulo será exemplificada através da utilização de
dois conjuntos de ferramentas, e para melhor compreensão, serão denominados conjuntos de
ferramentas A e B.
O conjunto de ferramentas A é composto pelos sistemas CVS (versão 2.5.03), Mantis
(versão 1.1.8) e Spider-CL 1.0. Em conjunto com a ferramenta CVS, é utilizado o
TortoiseCVS, cliente gráfico para o sistema de controle de versão, a fim de facilitar a
apresentação das informações, porém todas as funcionalidades apresentadas através do
TortoiseCVS podem ser executadas pelo próprio CVS através de linha de comando. Também
foi feita a integração com o DokuWiki, conforme mencionado nas sugestões de melhoria para
as ferramentas (ver seção 4.5)
47
O conjunto B é composto pelas ferramentas SVN (versão1.6.5), , Trac (versão 0.11.5) e
Spider-CL 1.0. Semelhantemente ao CVS, será utilizado o cliente gráfico TortoiseSVN para
melhor visualização de algumas funcionalidades do Subversion. Na ferramenta Trac, foi
utilizado o plugin MasterTickets, para possibilitar a criação de relacionamento entre tickets.
É importante configurar, em ambos os conjuntos de ferramentas, sistemas de
autenticação de usuário aliado a protocolos de segurança de acesso como SSL (Secure Socket
Layer) ou SSH (Secure Shell). No caso dos sistemas utilizados durante a produção deste
trabalho, as ferramentas Trac e Subversion e Mantis foram disponibilizadas através do sistema
web server Apache, utilizando recursos de SSL, para a segurança do acesso; a ferramenta
Spider-CL foi mantida em servidor Tomcat; e a ferramenta CVS utilizou o software CVSNT
o qual executará o servidor CVS.
A metodologia de uso das ferramentas descrita nesta seção está dividida em etapas,
facilitando a busca de informações. Como citado anteriormente neste trabalho, a metodologia
não está associada unicamente às ferramentas que compõe o grupo A e grupo B, por isso
sempre será descrita primeiramente com uma visão geral, sem ligação com qualquer
ferramenta específica, e em seguida será exemplificada através dos dois grupos de
ferramentas definidos, para a ilustração de como esta metodologia pode ser adaptada para
ferramentas com diferentes funcionalidades.
5.1.1 Definindo e estabelecendo um sistema de gerência de configuração
Considerando um ambiente onde estejam devidamente instaladas e configuradas
ferramentas que atendam aos requisitos discutidos no capítulo anterior, a metodologia começa
com o estabelecimento do sistema de gerência de configuração, ou seja, definir o meio de
armazenamento, procedimentos e ferramentas para o registro e acesso aos produtos de
trabalho e suas solicitações de mudanças.
Primeiramente, deve ser estabelecido o repositório para o projeto, de acordo com
estratégias definidas pela organização, através de ferramenta de controle de versão. Neste
momento também é estabelecido o banco de dados de solicitações de mudanças, isto é, os
projetos são instanciados nas ferramentas de controle de mudança, para o devido controle
sistematizado.
48
Utilizando o conjunto de ferramentas A, um repositório é criado para o projeto através
da ferramenta CVS, possibilitando o controle de versão, e o projeto deve ser instanciado na
ferramenta Mantis, possibilitando o controle de mudança. No que se diz respeito ao controle
de versão, ao se instanciar um repositório, será criada uma pasta CVSROOT o qual conterá
todos os arquivos de configuração do CVS, como visto na Figura 5.1. Os projetos submetidos
ao repositório serão salvos juntamente com a pasta de configuração da ferramenta.
Figura 5.1 – Visualização do repositório através da árvore de diretórios
Ao instanciar um repositório na ferramenta de controle de versão, será criado um
projeto com o mesmo nome na ferramenta Mantis, no qual se deve atribuir: uma descrição do
projeto, o seu estado (desenvolvimento, obsoleto, release) e permissão de visualização
(público se todos podem visualizar o andamento do projeto ou privado no qual apenas os
envolvidos podem visualizar), como visto na Figura 5.2.
Figura 5.2 – Criação de um projeto no Mantis
Uma boa prática no uso da ferramenta Mantis é a criação de um Projeto Template
através do menu “Manager”, na opção “Manage Projects”, o qual poderá servir como base
para exportar todos os conjuntos de tags, versões, categorias, campos customizados para um
novo projeto, como visualizado na Figura 5.3.
49
Figura 5.3 – Tela para importação de atributos a partir do Template do
Projeto
No conjunto de ferramentas B, o repositório do projeto deve ser criado na ferramenta
Subversion com a estrutura trunk, branches e tags, onde: a pasta trunk é onde será
armazenada a principal linha evolutiva dos itens de configuração; em branches, serão
armazenados os ramos do projeto; e pasta tags é onde serão guardadas as baselines do projeto,
como visto na Figura 5.4.
Figura 5.4 – Visualização do repositório através do TortoiseSVN
Deve ser instanciado um ambiente Trac para o projeto, e durante a criação do projeto,
deve ser definido: nome do projeto; conexão com um banco de dados; tipo de repositório
50
(SVN, neste caso); e caminho para o repositório; como visto na Figura 5.5. Com isto será
criado o sistema de controle de mudança já integrado ao sistema de controle de versão. O
projeto criado agora aparecerá entre os projetos disponíveis do Trac (Available Projects,
figura 5.6).
Figura 5.5 – Criação de um ambiente Trac para um projeto
Figura 5.6 – Visualização de Projetos Disponíveis no Trac
Com os sistemas de controle de versão e de mudança devidamente estabelecidos para o
projeto, deve ser iniciado um plano de gerencia de configuração, para a descrição dos
procedimentos referentes à gerência de configuração através destas ferramentas. O plano é
definido, nesta metodologia, através de paginas wiki integradas às ferramentas de controle de
51
mudança, e nele deve ser descrito: os responsáveis ou envolvidos; a identificação dos itens de
configuração; planejamento de baseline; estrutura do repositório; ferramentas utilizadas no
processo de gerência de configuração e suas metodologias e políticas de uso; descrição do
processo de gerencia de configuração; e planejamento das auditorias de configuração.
No conjunto de ferramentas A, cada projeto instanciado no Mantis, terá páginas wiki
associadas, devido a integração com o DokuWiki, e nestas páginas serão definidos um plano
de gerência de configuração que será exclusivo para cada projeto.
Nenhuma imagem foi gerada para exemplificar o Plano de Gerência de Configuração no
Dokuwiki por ser idêntico ao plano gerado na ferramenta Trac, na Figura 5.7 a seguir.
No conjunto de ferramentas B, o plano de gerência de configuração deve criado em
uma pagina wiki do Trac, como visto na Figura 5.7. O plano na TracWiki permite o anexo de
arquivos, imagens, estabelecimento de links diretamente aos diretórios do repositório (devido
a integração com o repositório). Após criado o plano, deve ser colocado um link na página
inicial do Trac, ou em outra seção desejada, para a devida disponibilização.
52
Figura 5.7 – Exemplo de Estrutura de Plano de Gerência de
Configuração na Ferramenta Trac.
Até este ponto a metodologia permite atender o resultado esperado GCO 1 (um sistema
de gerência de configuração é estabelecido e mantido), onde tem-se um sistema baseado em
controle de versão e controle de mudança. Podem-se considerar como indicadores indiretos a
constatação da instalação das ferramentas, e como indicadores diretos alguma evidência
mostrando que de fato o sistema de gerência de configuração foi estabelecido para o projeto a
ser avaliado.
5.1.2 Identificando itens de configuração
Tendo um sistema definido, é necessário definir os itens de configuração. Critérios
objetivos devem ser elaborados para condução da identificação dos itens de configuração, o
53
que pode ser obtido através da utilização da ferramenta Spider-CL. No Spider-CL, os critérios
serão definidos e integram checklists que podem ser aplicados e registrados através da própria
ferramenta. Os resultados obtidos devem ser anexados aos planos de gerência de
configuração, encontrados nas paginas wiki das ferramentas de controle de mudança, como
visto na Figura 5.8.
Figura 5.8 – Checklist criado e aplicado através do Spider-CL
54
Os itens de configuração definidos com base nos critérios objetivos devem ser listados
no plano de gerência de configuração e devem ter informações sobre atributos como o nome,
responsáveis, localização e conteúdo. A regra de padronização da nomenclatura dos itens de
configuração definida pelas organizações também deve ser inclusa no plano de gerencia de
configuração, juntamente com regras de versionamento, como visto na Figura 5.9.
Figura 5.9 – Exemplo de Identificação de Itens de Configuração no
Plano de Gerencia de Configuração.
A identificação dos itens de configuração de acordo com critérios objetivos,
implementa o GCO 2, tendo o checklist pronto e a seção relativa à identificação dos ICs no
plano de configuração como indicadores (indiretos se não preenchidos, e diretos se o checklist
tiver sido aplicado aos itens do projeto e estes se encontrarem identificados no plano).
5.1.3 Manipulando e controlando a evolução dos itens de configuração
Os itens de configuração identificados são os artefatos ou produtos de trabalho que
serão passivos de gerência de configuração, logo, são os arquivos que deverão ser
armazenados no repositório e a partir de então, serem gerenciados quanto a sua versão e
mudanças. O processo de registro e remoção de produtos de trabalhos do repositório é feito
55
através de mecanismos de check-in e check-out, dos sistemas de controle de versão. Check-in
refere-se ao ato de publicar alterações feitas em um produto de trabalho, enviando-as ao
repositório para torná-las acessíveis a todos. Check-out é o ato de criação de uma cópia local
de trabalho de um determinado item, a partir do repositório, ou seja, é a leitura de um item do
repositório [Sussman, 2009].
Cada item armazenado nos sistemas de controle de versão passa a contar com um
número de versão, ou revisão, automaticamente, e toda vez que sofra alguma alteração e seja
submetido (operação de check-in) ao repositório, este numero é incrementado, permitindo que
a equipe possa identificar e acessar os itens mais atuais do projeto. Além de controlar o
número de revisão dos itens de configuração, toda a ação que envolva alteração no repositório
registra: o usuário que fez a ação; o tipo de ação realizada (alteração, criação, remoção de
elemento do repositório); data e hora; e permite a adição de um comentário pelo usuário.
Esses elementos constituem um histórico dos itens de configuração, armazenado na
ferramenta.
Os comentários adicionados durante operações de check-in são um elemento muito
importante desta metodologia. Comentários padronizados devem ser institucionalizados
dentro das organizações, de modo a prover uma leitura mais precisa do histórico do
repositório. Detalhes importantes a serem colocados nos comentários são: Caráter da
modificação; alguma explicação mais precisa sobre a modificação (qual seção de um
documento foi alterada, por exemplo); e o motivo da alteração. Também é interessante
colocar uma referência ao sistema de controle de mudança, o que será discutido mais a frente.
Para efetuar a operação de check-in no conjunto de ferramentas A, será utilizada a
funcionalidade cvs commit, a qual fará o incremento da revisão de um item de configuração,
como visto na Figura 5.10. O formato de revisão da ferramenta CVS é 1.X, onde “X” será
incrementado toda vez que uma operação de check-in for efetuada e “X” iniciando de um (ou
seja, 1.1). Para recuperar o projeto do repositório (check-out), será utilizada a funcionalidade
cvs checkout. A ferramenta permite que a recuperação dos dados seja feita de várias
maneiras, por padrão, o check-out será feito em cima da versão mais recente presente no
repositório, mas a recuperação pode ser feita a partir de uma data ou por uma tag, caso se
queira trabalhar com uma determinada baseline. Outra funcionalidade importante presente na
ferramenta é o cvs update, no qual fará com que a cópia de um projeto local seja atualizada
com a versão mais recente do repositório.
56
Figura 5.10 – Check-in no CVS (commit).
No conjunto de ferramentas B, os itens de configuração são submetidos ao repositório
através da funcionalidade svn commit, como visto na Figura 5.11. Os interessados acessam o
repositório e fazem suas cópias de trabalho da configuração do sistema sobre as quais irão
trabalhar (isto é, checkout de uma revisão do repositório ou de uma revisão de um item de
configuração específico) ou atualizam suas cópias de trabalho através da funcionalidade svn
update; conforme alterações forem feitas e os produtos de trabalho forem evoluindo, estas
devem ser submetidas ao repositório através da funcionalidade svn commit novamente, e no
momento da submissão, deve ser definido um comentário apropriado, conforme o padrão
definido pela organização, de forma a facilitar o rastreio de modificações através do histórico,
posteriormente.
O Subversion controla o número de revisão dos itens de configuração, conforme estes
são modificados, o Subversion incrementa o número de revisão dos produtos de trabalho
enviados e de seus respectivos diretórios aos quais pertencem.
57
Figura 5.11 – Check-in no Subversion (commit).
5.1.3.1 Gerando Baselines
Em algum momento do projeto, haverá necessidade de eleger configurações ao estado e
baselines, e estas devem ser planejadas, ou seja, devem ser definidos no plano de gerência de
configuração o padrão de identificação das baselines, quando serão geradas, critérios de
validação e questões relacionadas às auditorias sobre essas baselines.
As baselines devem ser geradas através da criação de um rótulo (tag) sobre a
configuração que se deseja definir como linha base, funcionalidade das ferramentas de
controle de versão. Deve ser atribuído um nome compatível com o padrão de nomenclatura
definido para as baselines. Recomenda-se usar nomes que contenham as informações:
[Nome do projeto][tipo de baseline][versão][data no formato AAAAMMDD]
58
Quando uma baseline for gerada, esta deve também ser cadastrada nas ferramentas de
controle de mudança como “versões” do projeto, de forma que as solicitações de mudanças
registradas estejam relacionadas às baselines apropriadas.
A definição de baselines é parte do escopo do GCO 3 e é necessário evidenciar tanto o
planejamento quanto a criação dessas baselines. A metodologia utilizada também será
utilizada para o armazenamento e registro dos releases do sistema (controle necessário para o
GCO 6), , utilizando classificação adequada no campo “tipo de baseline” do identificador da
tag, e o devido registro da versão nos sistemas de controle de mudança, descrevendo qual a
baseline de origem da liberação (se aplicável).
No conjunto de ferramentas A, o processo de criação de baselines será feito utilizando
o CVS, no qual, após ser decidida a configuração da versão que se tornará uma baseline e
devidamente aprovada em uma auditoria, a funcionalidade cvs tag será utilizada para
submeter o projeto ao repositório, como visto na Figura 5.12. A tag estará associada a esta
versão do projeto e a todos os itens de configuração presentes na mesma. Quando for
necessário recuperar a baseline, será utilizada a funcionalide cvs checkout, contendo como
parâmetro o identificador da baseline desejada. É muito importante que a nomenclatura do
identificador de baseline esteja definida no Plano de Gerência de Configuração e possua um
padrão, para facilitar nos mapeamentos e recuperação. Um exemplo de nomenclatura de
baseline pode ser: projeto_release_x_y-aaaa_mm_dd
Figura 5.12 – Criação de Baseline no Subversion (Tags).
59
Depois que a baseline foi criada no CVS, esta será registrada no Mantis utilizando a
funcionalidade de versão, o qual poderá ser acessado na página de configuração de um
projeto, dentro em Manage Projects. Após criar uma versão, ao clicar em seu nome, poderá
ser adicionado um comentário para descrevê-lo.
O processo de criação de uma baseline no conjunto de ferramentas B, é feito através
da ferramenta SVN, onde uma vez definida a configuração que será promovida a baseline,
esta deverá ser colocada na cópia local de trabalho e então submetê-la ao repositório através
da funcionalidade de tags do SVN (svn copy ou a funcionalidade branches/tag do
TortoiseSVN), como visto na Figura 5.13. Como já mencionado no Capítulo 4, as tags criadas
no SVN são colocadas em diretórios diferentes, então no momento de criação da baseline,
esta deverá ser criada na pasta tags, com nome compatível ao que foi definido como padrão
de nomenclatura, por exemplo:
projeto#release_x.y#aaaammdd
Após criada a baseline, esta deverá ser registrada no Trac como uma versão do sistema,
através da opção “versions” no menu “Admin”. Para recuperar uma baseline, é feito o
procedimento semelhante ao checkout de uma configuração qualquer, apenas mudando o
caminho desejado para o diretório onde se encontra a baseline, dentro do diretório “tags”.
60
Figura 5.13 – Criação de Baseline no Subversion (Tags).
5.1.3.2 Acompanhando e registrando a situação dos itens de configuração e
baselines ao longo do tempo
Conforme os itens de configuração evoluam ao longo do projeto e baselines forem
definidas, surge a necessidade de identificar, diferenciar e recuperar o conteúdo de itens de
configuração em diferentes etapas do projeto, ou seja, é necessário assegurar que todos os
interessados tenham acesso e conhecimento sobre o histórico e situação específica de itens de
configuração ou baselines ao longo do tempo. Conforme citado anteriormente, as ferramentas
de controle de versão armazenam um histórico das alterações realizadas sobre os itens do
repositório, e, é através desta funcionalidade das ferramentas, que se pode alcançar o GCO 4.
Os históricos das ferramentas de controle de versão devem fornecer informações
suficientes para um mapeamento preciso dos componentes de uma determinada baseline,
apresentando a versão específica de cada item de configuração e permitindo a recuperação
desta configuração. Com essas informações é possível fazer comparações entre releases,
61
contabilizando o que foi feito ao longo do projeto. Aliado ao sistema de controle de
mudanças, é possível um controle ainda maior sobre o andamento do projeto.
Para implementar o quarto resultado esperado (GCO 4), no conjunto de ferramentas
A, será utilizado a ferramenta CVS. Para verificar a diferenciação entre versões de itens de
configuração, o uso da funcionalidade History do TortoiseCVS é utilizado, no qual será
exibida uma árvore de evolução para um determinado item de configuração contendo todas as
suas versões, também será exibido um rótulo ligando a uma determinada versão do IC se a
mesma estiver associado à uma baseline, como visto na Figura 5.14. Ao selecionar uma das
versões, será exibida a data de submissão, o autor e o comentário onde estará descrito a
modificação que foi realizada. A tela de History será utilizado para fazer o acompanhamento
do histórico dos itens de configuração.
Figura 5.14 – Histórico de Alterações do CVS.
Para efetuar o mapeamento dos itens de configuração com a baseline, a função de Web
log do TortoiseCVS será utilizado, o qual exibirá todos os itens de configuração presentes no
62
projeto, juntamente com todas as versões existentes de cada item de configuração, como visto
na Figura 5.15. Para mapeá-los com as baselines, existe um campo denominado symbolic
names em cada IC, neste campo haverá uma lista de baselines sendo associada com a versão
do item de configuração correspondente. As funcionalidades History e Web Log são
parecidas, porém, a funcionalidade History permite visualizar apenas em um item de
configuração, enquanto que a funcionalidade Web Log permite visualizar um conjunto de IC
(uma pasta ou todo o projeto) ao mesmo tempo, por esse motivo, a funcionalidade Web log
também será utilizada para efetuar o acompanhamento do histórico de todo o projeto.
Figura 5.15 – Tela de log do CVS (a partir do Web log)
63
Como foi mencionado, a interface TortoiseCVS está sendo utilizada apenas para facilitar
a explicação da metodologia, devido a isso, as funcinalidades History e Web Log não são
funcionalidades da ferramenta CVS, mas sim exibições gráficas da funcionalidade cvs log.
No conjunto de ferramentas B, o GCO 4, é obtido através da interpretação das
informações dos relatórios fornecidos pela funcionalidade svn log, que funciona como uma
máquina do tempo do repositório, informando todas as alterações feitas, listando para cada
alteração: autor, data (ano, mês, dia e hora), número de revisão e o comentário da operação de
commit, como visto na Figura 5.16. Mais detalhes podem ser obtidos através de variações do
comando svn log, como a adição de opções para listar apenas mudanças de uma revisão em
específico ou detalhamento de mudanças envolvendo criação, exclusão ou movimentação de
arquivos.
No caso de utilização de um cliente gráfico, as informações podem aparecer de forma
mais clara. O TortoiseSVN, oferece uma interface para visualização de histórico mais clara,
mas suas informações são todas advindas do próprio svn log.
Figura 5.16 – Histórico de Alterações do Subversion.
É importante em dados momentos do projeto realizar a comparação entre configurações,
baselines ou até mesmo em itens de configuração, para a verificação de sua evolução. O SVN
64
permite também a visualização de mudanças no próprio corpo do arquivo, através da
funcionalidade svn diff, que permite visualização das linhas alteradas em um dado arquivo de
uma revisão para outra, como visto na Figura 5.17. Para realizar o mapeamento entre
configurações/baselines e a versão de seus itens, é possível utilizar a funcionalidade svn list,
que lista todos os itens de uma dada revisão.
Figura 5.17 – Visualização dos Itens e suas Revisões em uma Baseline
no Subversion.
5.1.4 Gerenciando Mudanças
Além de definir e controlar os itens de configuração e baselines, deve ser mantido um
sistema capaz de gerenciar as solicitações de modificações sobre os itens de configuração dos
projetos. O controle de modificação consiste em gerenciar o ciclo de vida de uma mudança
desde sua solicitação até a sua conclusão, com o objetivo de auxiliar na análise do impacto
que a mudança causará, além de permitir a sua notificação às pessoas que serão afetadas. A
execução das ações de registro de solicitações de mudanças e o seu devido acompanhamento
implementam o GCO 5.
5.1.4.1 Registrando solicitações de mudanças e problemas
Cada ferramenta de controle de mudança possui um mecanismo de registro de
problemas, geralmente chamado de issue, e através desse mecanismo, os problemas são
registrados e acompanhados através de um ciclo de vida baseado em estados. Deve ser
65
registrado no plano de gerência de configuração o ciclo de vida e os critérios para a aprovação
das solicitações de mudança. A resolução dos problemas e mudanças é acompanhada
alimentando os issues com informações das ações tomadas, alterando os estados dos issues
conforme sua evolução e atribuindo-os a responsáveis.
Cada problema encontrado ou necessidade de mudança deve ser registrado através de
um issue. No preenchimento do formulário da issue, deve-se registrar:
• Nome: identificador claro e facilmente relacionável ao problema ou mudança
em questão. É uma boa prática criar uma padronização para os nomes de issues,
tornando mais fácil a interpretação dos issues apenas pelo nome;
• Descrição da solicitação de modificação: onde é relatado o caráter da mudança,
quais os itens de configuração relacionados, a origem do problema e demais
informações que facilitem a solução da modificação;
• Tipo: classificar o issue de acordo com os possíveis tipos definidos pela
organização. Geralmente, os tipos padrões são “Problema”, “Tarefa” e
“Melhoria”;
• Categoria: qual a área de origem da solicitação de mudança, sejam áreas de
processo ou componente do sistema;
• Versão: especificar a qual versão do sistema que a mudança diz respeito.
Estes campos são os principais, geralmente encontrados na maioria das ferramentas de
bugtracking ou controle de modificação, porém, de acordo com a necessidade da organização,
novos campos podem ser adicionados, e dependendo da ferramenta, outros campos podem ser
oferecidos como data de entrega, configuração do sistema, a qual marco do projeto a mudança
está relacionado, entre outros.
Para efetuar o registro das solicitações de mudança no conjunto de ferramentas A,
será utilizada a funcionalidade Report Issue do Mantis, como visto na Figura 5.18.
Primeiramente, toda solicitação de mudança que for gerada, uma issue referente será
instanciada, cada issue possuirá:
66
• Category: campo referente ao processo do produto de trabalho que originou a
solicitação de mudança;
• Reproducibility: conterá a frequência que o problema ocorre, exemplos de
atributos para este campo podem ser sempre, às vezes, nunca ou variado. Mas
fica a cargo da organização a escolha desses atributos que devem estar contidos
no Plano de Gerência de Configuração;
• Severity: refere-se à gravidade do problema, ou seja, o quanto o problema afeta
no projeto;
• Priority: refere-se à urgência que o problema deve ser resolvido. Este campo
trabalha em conjunto com o campo Severity, pois um problema crítico ao
projeto, geralmente possui alta prioridade;
• Summary: local onde será definido o nome da issue, ou seja, o identificador do
problema;
• Description: área onde conterá a descrição detalhada do problema;
• Additional Information: campo opcional no qual poderá ser descrito uma
possível solução do problema ou experiências de ocorrência do mesmo
problema.
67
Figura 5.18 – Criação de issue na ferramenta Mantis.
No conjunto de ferramentas B, problemas devem ser identificados com a criação de
tickets no Trac (Create New Ticket, Figura 5.19). Para cada ticket deve ser cadastrado: um
nome (summary) de acordo com o padrão definido pela organização; um autor (reporter), que
é preenchido automaticamente com o usuário acessando atualmente o sistema; uma descrição
do problema/solicitação de mudança (description) respeitando o padrão estabelecido; um tipo
que pode ser problema/defeito (defect), melhoria (enhancement) ou uma tarefa (task); a
prioridade de resolução do problema que varia de trivial a blocker; no caso de documentação,
a área de processo da qual o problema advêm (campo category); a versão sobre a qual o
problema ocorre (campo version, definido durante a criação de baselines); e deve ser
apontado um responsável, se houver, para a resolução do problema.
O campo “milestone” (marcos), deve ser preenchido após cada ponto de controle do
projeto. Cada milestone representará um ponto de controle do projeto, e, durante o cadastro,
devem ser registrados os assuntos discutidos na reunião. Todos os tickets criados referentes a
problemas apontados durante àquela reunião, devem ter o campo milestone preenchido com o
referido marco.
68
Caso um ticket impeça a resolução de outro, ou seja, um ticket esteja “bloqueando”
outro, deve ser preenchido o campo “Blocking” com o número do ticket que está sofrendo o
bloqueio. De forma análoga, tickets que são bloqueados podem ter o campo “Blocked by”
preenchido com o número do ticket que o está bloqueando.
Figura 5.19 – Criação de ticket na ferramenta Trac.
5.1.4.2 Acompanhando as mudanças
O controle das modificações é obtido a partir do acompanhamento da evolução dos
issues em harmonia com as alterações feitas sobre os itens de configuração, onde cada ação
tomada e alteração feita deve ser registrada no issue, atualizando-o para que sempre esteja em
sincronia com a implementação da modificação. As modificações devem ser acompanhadas
até serem fechadas, ou seja, até que atinjam um estado final, seja uma solicitação recusada ou
um solicitação completamente implementada. O controle pode ser feito através dos históricos
69
do sistema de controle de mudança, que armazena todas as mudanças feitas nas solicitações
de modificação, fornecendo uma visão abrangente das ações tomadas para a conclusão das
modificações.
A funcionalidade View Issues do conjunto de ferramentas A será utilizada para manter
o controle do ciclo de vida das solicitações de mudanças, nela serão listados todos os
problemas exibindo os seus Ids, categorias, severidades, estado, data da última atualização e o
nome do problema, como visto na Figura 5.20. Ao selecionar uma issue, será possível
visualizá-la de forma mais detalhada, tendo acesso a sua descrição, as issues que possuem
relação ao problema selecionado e ao seu histórico de mudanças.
Toda vez que uma issue é atualizada será exibida uma tela onde será possível alterar
além dos campos preenchidos ao se registrar uma nova issue, os campos:
• Assigned to: este campo encaminhará o problema a algum integrante do projeto
para sua resolução;
• Status: este campo indicará em que estado a solicitação de modificação se
encontra, ou seja, indicará se uma determinada issue está resolvida, confirmada
a ocorrência do problema, designada para alguém corrigir ou fechada. Fica a
cargo de cada organização a definição dos status das issues que devem estar
contidos no Plano de Gerência de Configuração.
• Resolution: indica como uma issue foi finalizada, ou seja, verifica se uma dada
issue foi corrigida, suspensa, duplicada ou impossível de corrigir. Além indicar
se a issue está ativa (caso não tenha sido finalizada) ou se foi reativada.
• Add note: este campo será utilizado para preencher com um comentário toda vez
que a issue for atualizada, descrevendo o motivo e a resolução, caso a issue
tenha sido finalizada;
• Issue History: este campo será utilizado para o acompanhamento da evolução da
issue, no qual será registrada toda atualização feita sobre a issue, cadastrando a
data da atualização e seu autor, os campos foram modificados e a mudança que
foi realizada, como vista na Figura 5.21.
70
Figura 5.20- Visualização de issues (View Issues)
Figura 5.21- Histórico de mudanças de issues.
O acompanhamento das mudanças que estão ocorrendo no projeto, utilizando o
conjunto B de ferramentas, é possível através do sistema de visualização de tickets (view
tickets), onde o usuário pode obter uma lista dos tickets do projeto ordenados e filtrados
conforme desejar, de acordo com buscas SQL, como visto na Figura 5.22. A lista é útil para
informar o andamento das várias solicitações de mudança registradas.
71
Figura 5.22 – Visualização de Tickets no Trac (Ticket View).
Também é possível fazer o acompanhamento do andamento dos milestones, ou seja,
verificar o estado de resolução das solicitações de mudança registrada em um dado marco ou
ponto de controle. Isto pode ser obtido acessando a funcionalidade “Roadmap”, que listará
todos os milestones cadastrados com uma barra de estado que representa a porcentagem de
quantos tickets foram resolvidos, como visto na Figura 5.23. Acessando um milestone, será
apresentada a lista de issues específicas àquele marco.
Figura 5.23 – Exibição dos Milestones do projeto no Trac (Roadmap).
72
Durante a resolução de um problema registrado por ticket, este deverá sempre ser
atualizado para que seja possível acompanhar a resolução através do ticket. Para tanto, deve
ser utilizado o ciclo de vida do ticket aliado ao sistema de comentários, de modo que sempre
que uma ação for tomada para resolver um ticket, deve ser adicionado um comentário (campo
comment) descrevendo o que foi feito, e o fluxo do ticket deve ser atualizado através dos
campos “action”, onde são registradas as mudanças de estado, redirecionamento e aceitação
de tickets.
Todas as alterações realizadas sobre o ticket são armazenadas sob forma de histórico. O
histórico de mudanças lista as ações tomadas com os seus comentários, os usuários
responsáveis pelas mudanças e as datas de ocorrência, como visto na Figura 5.24.
Figura 5.24- Histórico de mudanças do ticket.
5.1.5 Definindo políticas de acesso e segurança
É importante definir como tratar o acesso concorrente aos dados do repositório, para
evitar problemas de perda de informação ou retrabalho. Para isto as ferramentas de controle
de versão utilizam as metodologias copy-modify-merge e lock-modify-unlock (definidas no
Capítulo 4). Também é possível ramificar o projeto, isto é criar ramos (branches), utilizando
variações das funcionalidades de criação de rótulos, já explicadas anteriormente.
Além disso, as informações devem ser disponibilizadas através de um canal de
comunicação seguro, para tanto, deve ser configurado algum protocolo de segurança e
autenticação para o acesso ao repositório de forma controlada, estabelecendo políticas de
permissão de acesso, definindo usuários com poder de leitura e escrita. Nas ferramentas
73
utilizadas nesta metodologia foi configurado o protocolo SSL (Secure Socket Layer), em
conjunto com a configuração de seus sistemas de autenticação de usuário com definição de
políticas de permissão de acesso, leitura e escrita, como visto na Figura 5.25 e 5.26. Para
detalhes de como configurar as ferramentas ver o Manual de Implementação do Processo de
Gerência de Configuração.
Figura 5.25 – Atuação do SSL Server (sserver) durante operação de
acesso ao repositório CVS.
Figura 5.26 – Arquivo de permissões de leitura e escrita do repositório
Subversion
A implementação de políticas de segurança, e o controle do armazenamento, manuseio e
acesso aos itens de configuração, estabelecidos pelo uso apropriado do sistema de gerência de
configuração e seus mecanismos de checkin e checkout, contemplam o resultado esperado
GCO 6 (O armazenamento, o manuseio e a liberação de itens de configuração e baselines são
controlados).
74
5.1.6 Realizando Auditoria de Configuração
Os passos descritos até aqui constituíram o escopo do processo de gerência de
configuração, porém ainda é necessário que este processo seja auditado, ou seja, que seja
verificado se a gerência de configuração foi realizada de maneira apropriada. É necessária a
geração de um roteiro para a realização desta auditoria, implementado através de um checklist
na ferramenta Spider-CL, contendo os critérios para condução de uma auditoria de
configuração. A auditoria de configuração tem o principal objetivo de garantir que as
baselines e os itens de configuração estejam íntegros, completos e consistentes.
Utilizando a Spider-CL, será gerado um checklist objetivo contendo critérios para a
execução da auditoria de configuração, tanto funcional quanto física. O checklist deve ser
dividido de forma a deixar claro estas duas categorias de auditoria, como visto a Figura 5.27.
O checklist gerado deve ser aplicado pela ferramenta Spider-CL, utilizando os históricos
de mudanças das ferramentas de controle de versão e modificação e os relatórios das
ferramentas de bugtracking/controle de modificação como insumos para a verificação dos
itens do checklist.
75
Figura 5.27 – Exemplo de checklist para auditoria de configuração
76
Para apresentar e manter os resultados de auditorias ao longo do projeto, deve ser criada
uma página wiki apenas com este objetivo, onde serão listadas todas as auditorias feitas com
informações de data de execução e auditor. Cada uma das auditorias listadas deve possuir um
link para uma página wiki própria daquela auditoria, com informações sobre o andamento da
auditoria, resultados, plano de ação (para o caso de inconsistências identificadas) e o próprio
checklist publicado, como visto nas Figuras 5.28 e 5.29.
Figura 5.28 – Página “Auditorias de Configuração”
77
Figura 5.29 – Página de uma Auditoria de Configuração específica.
Problemas identificados durante a auditoria devem ser registrados e resolvidos (com
base no plano de ação) de acordo com a metodologia proposta para o GCO 5.
A implementação deste resultado esperado é realizado de forma idêntica nos dois
conjuntos de ferramentas, através de criação de páginas wiki para abrigar as auditorias
realizadas e seus resultados, por este motivo não foi feita a descrição específica para cada
grupo de ferramenta.
Evidências de execução da auditoria são os indicadores para a implementação do
resultado esperado GCO 7 (Auditorias de configuração são realizadas objetivamente para
78
assegurar que as baselines e os itens de configuração estejam íntegros, completos e
consistentes).
5.2 Considerações Finais
Neste capítulo, foi definida a metodologia de implementação do processo de GCO do
MPS.BR, utilizando recursos facilmente encontrados em conjuntos de ferramentas livres. A
metodologia foi apresentada em paralelo com sua utilização em dois conjuntos de ferramentas
diferentes, ilustrando como ela pode ser facilmente adaptada para os recursos disponíveis
pelas ferramentas que se deseja utilizar, desde que as ferramentas em questão contemplem
alguns requisitos.
A viabilidade de implementar o processo GCO através de ferramentas livres, traz
opções para as organizações que desejam ser avaliadas pelo modelo MPS, permitindo que
adotem estratégias mais práticas ou mais condizentes com suas culturas de trabalho, e a
metodologia descrita fornece um guia para nortear a implementação do processo de gerência
de configuração através do conjunto de ferramentas disponíveis ou selecionados pela
organização sob orientação de uma Instituição Implementadora.
Também é importante destacar que a implementação do processo de gerência de
configuração está vinculada a outros processos que fornecem insumos e são apoiadas a ele.
No projeto SPIDER outros subprojetos descrevem metodologias para implementação dos
demais processos do nível F do MPS.BR, e um dos tópicos de estudo do projeto são propostas
de integração dessas metodologias [Oliveira, 2008].
79
6 CONCLUSÃO
Ao longo do ano de 2009, os estudos sobre o MPS.BR e o processo de Gerência de
Configuração no grupo de pesquisa SPIDER, culminaram neste trabalho de conclusão de
curso, onde foi consolidado todo o conhecimento produzido no projeto. Visualizamos, no
Capítulo 2 a definição do programa MPS.BR e como este modelo de qualidade vem trazer
benefícios para o cenário empresarial brasileiro no ramo de desenvolvimento de software,
com uma solução de baixo custo para adequar as empresas nacionais a um modelo que é
compatível com as principais normas definidas internacionalmente. Em seguida, foi estudado
o processo de Gerência de Configuração, no Capítulo 3, importante para a gerência dos
produtos de trabalho da organização, controlando, comunicando e disponibilizando as
mudanças sobre estes produtos. Foi visto como o processo de Gerência de Configuração se
encaixa no contexto do MPS.BR, analisando seu propósito e resultados esperados.
Após toda a definição da base teórica do trabalho, foi discutido o apoio ferramental ao
processo de Gerência de Configuração, no Capítulo 4, onde foram apresentadas as principais
ferramentas livres disponíveis atualmente, e foi feito um mapeamento dos resultados
esperados do processo GCO com algumas dessas ferramentas (CVS, SVN, Mantis, Trac,
Spider-CL) observando quais funcionalidades destas ferramentas podem ser usadas para
alcançar os resultados esperados do processo, e propondo algumas melhorias para as mesmas.
Finalmente, no capítulo 5, foi definida uma metodologia de utilização de ferramentas
livres para a implementação sistematizada do processo de Gerência de Configuração no
MPS.BR, onde foram definidas políticas de uso para ferramentas, exemplificando-as através
das ferramentas mapeadas anteriormente. Foi visto que a utilização de ferramentas livres é
capaz de implementar o processo de GCO, através das funcionalidades que estão
normalmente disponíveis por ferramentas de controle de versão e controle de mudança, ou
apenas algumas customizações podem ser feitas de modo a adaptar ferramentas a
metodologia, conforme foi mostrado com as ferramentas utilizadas neste trabalho.
6.1 Resultados Obtidos e Trabalhos Futuros
Ao longo do desenvolvimento do trabalho, foi possível obter um conhecimento
aprofundado sobre o programa MPS.BR, principalmente no nível de maturidade F. Também
80
houve um estudo extensivo sobre a Gerência de Configuração, para poder entender seus
propósitos e obrigações, além do aprendizado sobre ferramental de apoio ao processo.
Os estudos realizados permitiram o desenvolvimento de uma metodologia de uso de
ferramentas livres, que deu origem a um manual de implementação do processo de Gerência
de Configuração utilizando ferramentas livres, onde a metodologia é explicada e
exemplificada através das ferramentas SVN, CVS, Mantis, Trac e Spider-CL.
A metodologia definida serviu de base para o estudo da implementação de outros
resultados esperados que envolva registros e acompanhamentos de mudanças em outros
processos do modelo, e foi incorporada às metodologias desenvolvidas para outros processos
do MPS.BR, no âmbito do projeto SPIDER. Isto pode ser constatado através do artigo “Uma
Análise Avaliativa de Ferramentas de Software Livre no Contexto da Implementação do
Processo de Gerência de Requisitos do MPS.BR” submetido ao 13º Workshop de Engenharia
de Requisitos (WER’10).
Entre os trabalhos futuros, considera-se a análise da metodologia implantada dentro do
ambiente de desenvolvimento do projeto Portal da Amazônia, na Biblioteca Central
Clodoaldo Beckmann da UFPA, a ser tomada e analisada como estudo de caso. A escrita de
artigos com os resultados obtidos também configura objetivos futuros. Além disso, o teste da
metodologia em outras ferramentas e uma proposta de integração de ferramentas de Gerência
de Configuração ao suíte de ferramentas gerado pelo projeto SPIDER são metas a serem
alcançadas. Outro plano futuro é a submissão deste subprojeto ao Programa Brasileiro de
Qualidade e Produtividade (PBQP).
6.2 Lições Aprendidas
A confecção deste trabalho permitiu a percepção de que a aderência a um modelo de
qualidade não significa necessariamente o aumento da burocracia ou mudança total de cultura
em uma organização. Como visto, o modelo MPS em momento algum dita um solução única
para a implementação de resultados esperados, mas deixa a cargo da organização decidir uma
estratégia que melhor se adapte ao seu modo de trabalho, contanto que resulte nos objetivos
especificados. Foi aprendido também, que a utilização de ferramentas de maneira indevida
pode ter um resultado oposto ao desejado, tornando um processo mais lento e burocrático, por
isso é importante saber quando e como usar ferramentas para sistematizar processos de forma
eficiente.
81
Este trabalho também foi importante para o conhecimento das opções de carreira através
do modelo MPS.BR e vantagens que o modelo traz às empresas. Uma empresa que adota o
modelo, passa a contar com processos mais organizados e menos propícios a falhas e
retrabalho, sendo mais produtiva. Desta forma a aderência a modelos de qualidade traz
benefícios às empresas que tornam seu processo de desenvolvimento mais eficiente, menos
custoso e consequentemente chegam a um produto final mais próximo ao que o cliente deseja,
e traz benefícios aos clientes que passam a ficar mais satisfeitos com os produtos entregues e
mais confiantes na responsabilidade das empresas contratadas.
Pôde-se aprender, também, o quão importante é o processo de gerência de configuração
na empresa, pois é este processo que manterá todas as produções (artefatos) organizadas
dentro de uma empresa, não cuidando meramente de realizar backups no repositório, mas sim
por manter a integridade dos produtos de trabalho, disponibilizar aos interessados e realizar o
acompanhamento das mudanças sobre estes produtos. Por esses motivos o processo de
gerência de configuração faz parte de um dos níveis de maturidade iniciais (nível F).
Em consequência das lições anteriores, foi possível adquirir uma visão crítico-analítica
capaz de efetuar uma consultoria para o aprimoramento do processo de Gerência de
Configuração dentro de um ambiente real de Engenharia de Software no Projeto Portal da
Amazônia. Dentro desse projeto, uma metodologia foi criada para atender aos resultados
esperados de Gerência de Configuração do modelo MPS.BR, sendo aderente ao PSI –
Processo de Software Informam [Lemos, 2006], processo utilizado no desenvolvimento do
portal.
82
Referências Bibliográficas
[AnkhSVN, 2009] AnkhSVN – The Open Source Subversion Plugin For Visual Studio. Disponível
em: < http://ankhsvn.open.collab.net/>. Acesso em: 25 de março de 2009.
[Babich, 1986] Babich, W.A. Software Configuration Management - Coordination For Team
Productivity. Addison-Wesley, 1986.
[Barros, 2009] BARROS, Renan S., Manual do Usuário – SPIDER CL – Versão 1.2, Julho, 2009.
[Bugzilla, 2009] Bugzilla. Disponível em: <http://www.bugzilla.org/>. Acesso em: 23 de março
de 2009.
[CVS, 2009] Concurrent Version System. Disponível em: < http://www.nongnu.org/cvs/>.
Acesso em: 24 de março de 2009.
[Dias, 2009] Dias, A.F. O que é Gerência de Configuração?, Disponível em
<http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerenci
a_configuracao.php?pagNum=0.> Acesso em 13 de Outubro de 2009.
[Eclipse, 2009] Eclipse.org. Disponível em: <http://www.eclipse.org/>. Acesso em: 25 de
março de 2009.
[FSF, 2009] Free Software Foundation. Disponível em: < http://www.fsf.org/>. Acesso
em: 20 de outubro de 2009.
[Git, 2009] Git – Fast Version Control. Disponível em http://git-scm.com/. Acesso em: 22
de março de 2009.
[IEEE, 1987] Institute of Electrical and Electronics Engineers, Std 1042 - IEEE Guide to
Software Configuration Management, 1987.
[IEEE, 1990] Institute of Electrical and Electronics Engineers, Std 610.12 - IEEE
Standard Glossary of Software Engineering Terminology, 1990
[ISO/IEC, 2003] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL
ELECTROTECHNICAL COMISSION. ISO/IEC 15504-2: INFORMATION TECHNOLOGY -
PROCESS ASSESSMENT – PART 2 - PERFORMING AN ASSESSMENT, GENEVE: ISO, 2003.
[ISO/IEC, 2008] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL
ELECTROTECHNICAL COMISSION. ISO/IEC 12207 SYSTEMS AND SOFTWARE
ENGINEERING– SOFTWARE LIFE CYCLE PROCESSES, GENEVE: ISO, 2008
[Lemos, 2006] Lemos, A. de M., Junior, A. C. P., Guerreiro, C. M., Barbosa, E. C., Pereira, L. P.,
Gonçalves, M. K., Portal da Amazônia: Concentrando informações regionais
com ferramentas livres, In: XX Semana Paraense de Informática e
Telecomunicações, Belém-PA, 2006.
[Mantis, 2009] Mantis Bug Tracker. Disponível em: <http://www.mantisbt.org/>. Acesso em:
22 de março de 2009.
[Mercurial, 2009] Mercurial SCM. Disponível em: < http://mercurial.selenic.com/>. Acesso em:
24 de março.
[Oliveira, 2008] Oliveira, S. R. B., SPIDER: Uma Proposta de um SUITE de Ferramentas de
Software Livre de Apoio à Implementação do MPS.BR, Projeto Submetido e
Aprovado pelo Instituto de Ciências Exatas e Naturais da UFPA, Belém-PA,
2008.
[Pressman, 2006] PRESSMAN, Roger S. Engenharia de software. Tradução José Carlos Barbosa
dos Santos. Rio de Janeiro: McGraw-Hill, 2006. 1056 p.
[RapidSVN, 2009] RapidSVN. Disponível em: < http://rapidsvn.tigris.org/>. Acesso em: 20 de
março de 2009.
[Redmine, 2009] Redmine. Disponível em: <http://www.redmine.org/>. Acesso em: 15 de
outubro de 2009.
[Scarab, 2009] Scarab.tigris.org. Disponível em: <http://scarab.tigris.org/> . Acesso em: 25
de março de 2009.
[SEI, 2006] SEI. SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-
DEV), Version 1.2, Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University, 2006.
[Softex, 2009] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO – SOFTEX. MPS.BR – Guia Geral:2009, maio 2009. Disponível
em www.softex.br.
[Softex, 2009a] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 2:
Fundamentação para Implementação do Nível F do MR-MPS:2009, maio
2009. Disponível em: www.softex.br.
[Sommerville, 2003] Sommerville, I. Engenharia de Software. 6 ª ed. São Paulo, Addison Wesley,
2003.
[Spider, 2009] Projeto SPIDER. ww.ufpa.br/spider, último acesso em outubro/2009.
[Subversion, 2009] Subversion. Disponível em: <http://subversion.tigris.org/>. Acesso em: 20 de
março de 2009.
[Sussman, 2009] Sussman, Ben Collins et al. Version Control with Subversion: For Subversion
1.6: (Compiled from r3649), e-Book. O'Reilly Media, 2009.
[TortoiseCVS, 2009] TortoiseCVS. Disponível em:<http://www.tortoisecvs.org/>. Acesso em: 24 de
março de 2009.
[TortoiseSVN, 2009] TortoiseSVN. Disponível em:<http://www.tortoisesvn.org/>. Acesso em: 20
de março de 2009.
[Trac, 2009] Trac - Integrated SCM & project management. Disponível em: <http://trac.edgewall.org/>. Acesso em: 20 de março de 2009.
[VisualSVN, 2009] VisualSVN – Subversion-Based Source Control for Windows. Disponível em:
<http://www.visualsvn.com/>. Acesso em: 20 de março de 2009.
[Weber. 2004] WEBER, Kival C. et al, Modelo de Referência para Melhoria de Processo de
Software: uma abordagem brasileira, Confer6encia Latinoamericana de
Informática – CLEI, Arequipa-Peru, 2004.
top related