[completo] TCC MauricioEwelton - spider.ufpa.brspider.ufpa.br/publicacoes/tcc/tcc_eweltonmauricio_2009.pdf · universidade federal do parÁ instituto de ciÊncias exatas e naturais

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



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.


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.


“É 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


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


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


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].


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”.


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).


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.

Documents

[completo] TCC MauricioEwelton - spider.ufpa.brspider.ufpa.br/publicacoes/tcc/tcc_eweltonmauricio_2009.pdf · universidade federal do parÁ instituto de ciÊncias exatas e naturais