UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE CONFIGURAÇÃO DO MPS.BR UTILIZANDO FERRAMENTAS DE SOFTWARE LIVRE

Transcrição

1 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

2 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO Ewelton Yoshio Chiba Yoshidome Maurício Ronny de Almeida Souza UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE CONFIGURAÇÃO DO MPS.BR UTILIZANDO FERRAMENTAS DE SOFTWARE LIVRE Data da defesa: / / Conceito: Banca Examinadora Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA Orientador Prof. Dra. Carla Alessandra Lima Reis Faculdade de Computação/UFPA Membro Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA Membro Belém 2009

3 Aos amigos e familiares que deram o suporte necessário ao longo dessa jornada.

4 AGRADECIMENTOS Agradeço a minha família, por ter acreditado em meus estudos e em minha capacidade, também por ter me ajudado e apoiado em minhas decisões todo o tempo. Dedico este trabalho, também, aos meus amigos (Maurício, Carlos Rafael, Vitor, Wallace, Eder) por terem acompanhado a minha estada em Belém e minha vida acadêmica. Um agradecimento ao pessoal que estão em Macapá, aos meus amigos (Carla e Diego) e a uma pessoa muito importante para mim, minha querida Larissa, os quais me incentivaram a não procrastinar o desenvolvimento deste trabalho. Agradeço ao pessoal do grupo do projeto SPIDER. E finalmente, mas não menos importante, agradeço ao meu orientador, Sandro Bezerra, por tornar o desenvolvimento deste trabalho de conclusão de curso possível. Ewelton Yoshio Chiba Yoshidome Em primeiro lugar à minha querida mãe por cuidar de mim com tanto empenho, e por todo o apoio, carinho e dedicação que sempre me ofereceu. À minha madrinha e minha avó que foram minhas mães também. Aos meus familiares, pela motivação ao longo de todos esses anos. À minha amada namorada e melhor amiga, Ariane pelo companheirismo e confiança incondicional depositada em mim, e à sua família, Sebastião, Julieta e Talita, por me acolherem de forma tão afetuosa. Aos meus amigos de colégio Luiz, Carlos, Rosana, Amanda, Jefferson, Júlio, Vanessa, Patty e Nandara, por manterem nossa amizade sempre viva. Aos amigos da vida, Monique (dona), Carol e Victor (Jimmy), provando que amizades são feitas das formas mais inusitadas. Aos meus inseparáveis amigos de universidade Yoshio, Vitor e Wallace, por toda a paciência e diversão. Aos amigos do projeto SPIDER, que tanto contribuíram para a confecção deste trabalho. Aos professores do curso de Bacharelado em Ciência da Computação, pelo profissionalismo e lembranças deixadas. E agradecimentos merecidos ao professor e orientador Sandro, pela paciência no MSN e seu exímio trabalho como professor, motivando e ensinando sempre. Maurício Ronny de Almeida Souza

5 É na mudança que encontramos um objetivo. Heráclito

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

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

8 SUMÁRIO 1 Introdução Qualidade de Software Contexto (problemas, justificativa, motivação) Objetivos Objetivo Geral Objetivos Específicos Metodologia Estrutura do Trabalho MPS.BR: Uma Visão Geral Histórico do MPS.BR Definição e Composição do MPS.BR Guias do MPS.BR Níveis de Maturidade do MPS.BR Considerações Finais Processo de Gerência de Configuração (GCO) Gerência de Configuração Atividades da Gerência de Configuração Gerência de Configuração no MPS.BR Resultados Esperados Considerações Finais Proposta de Apoio Sistematizado Projeto SPIDER Ferramentas de Software Livre para Apoio do Processo de Gerência de Configuração Controle de versão Controle de Mudanças... 35

9 4.3 Ferramentas Analisadas para a Metodologia Proposta Mapeamento das Ferramentas aos Resultados Esperados (pontos fracos e fortes) GCO 1: Subversion e Trac / CVS e Mantis GCO 2: Trac, Mantis, Spider-CL GCO 3: CVS, Subversion GCO 4: Subversion, Trac e CVS GCO 5: Mantis, Trac GCO 6: Mantis, Trac, Subversion e CVS GCO 7: Spider-CL, Mantis, CVS, Trac e Subversion Sugestões de Melhoria do Ferramental de Apoio Considerações Finais Metodologia Para a Implementação do Processo de Gerência de Configuração Descrição do Cenário Definindo e estabelecendo um sistema de gerência de configuração Identificando itens de configuração Manipulando e controlando a evolução dos itens de configuração Gerenciando Mudanças Definindo políticas de acesso e segurança Realizando Auditoria de Configuração Considerações Finais Conclusão Resultados Obtidos e Trabalhos Futuros Lições Aprendidas Referências Bibliográficas... 82

10 LISTA DE FIGURAS Figura Componentes do modelo MPS [Softex, 2009] Figura Estrutura dos Níveis de Maturidade do MPS.BR [Softex, 2009] Figura 4.1 Mapeamento dos Resultados Esperados com as Ferramentas de GCO Figura 5.1 Visualização do repositório através da árvore de diretórios Figura 5.2 Criação de um projeto no Mantis Figura 5.3 Tela para importação de atributos a partir do Template do Projeto Figura 5.4 Visualização do repositório através do TortoiseSVN Figura 5.5 Criação de um ambiente Trac para um projeto Figura 5.6 Visualização de Projetos Disponíveis no Trac Figura 5.7 Exemplo de Estrutura de Plano de Gerência de Configuração na Ferramenta Trac Figura 5.8 Checklist criado e aplicado através do Spider-CL Figura 5.9 Exemplo de Identificação de Itens de Configuração no Plano de Gerencia de Configuração Figura 5.10 Check-in no CVS (commit) Figura 5.11 Check-in no Subversion (commit) Figura 5.12 Criação de Baseline no Subversion (Tags) Figura 5.13 Criação de Baseline no Subversion (Tags) Figura 5.14 Histórico de Alterações do CVS Figura 5.15 Tela de log do CVS (a partir do Web log) Figura 5.16 Histórico de Alterações do Subversion Figura 5.17 Visualização dos Itens e suas Revisões em uma Baseline no Subversion Figura 5.18 Criação de issue na ferramenta Mantis Figura 5.19 Criação de ticket na ferramenta Trac

11 Figura Visualização de issues (View Issues) Figura Histórico de mudanças de issues Figura 5.22 Visualização de Tickets no Trac (Ticket View) Figura 5.23 Exibição dos Milestones do projeto no Trac (Roadmap) Figura Histórico de mudanças do ticket 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 73 Figura 5.27 Exemplo de checklist para auditoria de configuração Figura 5.28 Página Auditorias de Configuração Figura 5.29 Página de uma Auditoria de Configuração específica

12 Lista de Tabelas Tabela Processos e Atributos de Processo por Nível de Maturidade [Softex, 2009]... 21

13 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 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 SUITE 1 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 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 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 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 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 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 [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 [ISO/IEC, 2008], ISO/IEC [ISO/IEC, 2003] e CMMI-DEV (Capability Maturity Model Integration for Development) [SEI, 2006].

18 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 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 [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 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 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 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 (e emendas 1 e 2) e ISO/IEC , 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 Estrutura dos Níveis de Maturidade do MPS.BR [Softex, 2009]

21 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 Processos e Atributos de Processo por Nível de Maturidade [Softex, 2009] Onde tem-se atributos para avaliação da capacidade, os seguintes: AP O processo é executado; AP O processo é gerenciado;

22 22 AP Os produtos de trabalho do processo são gerenciados; AP O processo é definido; AP O processo está implementado; AP O processo é medido; AP O processo é controlado; AP O processo é objeto de inovações; AP 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 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 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 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 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 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 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 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, encontramse 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 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 30 planos, metodologia para verificar se a baseline está correta, ou seja, avalia se ela cumpre o seu propósito, todas as versões dos IC estão de acordo com o previsto. No entanto, a auditoria física verifica a completitude da baseline, avaliando se todos os IC estão presentes [Softex, 2009a]. 3.4 Considerações Finais O capítulo 3 apresentou uma visão geral do processo de Gerência de Configuração de Software, atividade guarda-chuva responsável pela consistência e disponibilidade dos produtos de trabalho de um projeto de software. Foi visto o papel do processo no contexto do modelo MPS.BR, tópicos que servem de base para o próximo capítulo, Proposta de Apoio Sistematizado, onde será iniciada a análise de implementação do processo de GCO utilizando ferramentas livres.

31 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 SUITE 2 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 32

33 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 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] Concurrent Version System - CVS O CVS (disponível em é 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]) Git Git (disponível em é 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 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 Mercurial Mercurial (disponível em é uma ferramenta multiplataforma 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 V Subversion O Subversion, ou SVN, (disponível em é 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 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 e está disponível sob licença GNU GPL 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] Bugzilla Bugzilla (disponível em é 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 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 ; gerenciamento profiles; campos customizáveis Mantis O Mantis (disponível em é 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 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 Redmine O Redmine (disponível em é 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 Scarab O Scarab (disponível em é 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 Trac O Trac (disponível em é 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 é , possuindo integração nativa com o subversion, mas capaz de se integrar com outros sistemas de controle de versão.

37 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 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 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 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 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 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 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 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 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 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 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 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 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 GCO 7: Spider-CL, Mantis, CVS, Trac e Subversion Auditorias devem ser feitas com base em critérios objetivos para verificação do andamento do processo de gerencia de configuração e do estado das baselines em relação ao que fora planejado. Para efetuar as auditorias de configuração, será utilizada a ferramenta de apoio Spider- CL para geração e armazenamento dos checklists que serão utilizados para guiar as auditorias. Para verificar se os procedimentos e padrões planejados estão sendo seguidos, serão utilizados os históricos e relatórios das ferramentas Mantis e CVS, ou Trac e Subversion, como referência. As ferramentas apóiam a implementação total deste resultado esperado. 4.5 Sugestões de Melhoria do Ferramental de Apoio Como foi mencionado na seção anterior, os resultados esperados GCO 1, GCO 2 e GCO 7 poder ser satisfeitos com o apoio do conjunto Mantis e CVS com uma oportunidade de melhoria. Para que estes resultados esperados sejam contemplados, é necessária a integração com o sistema DokuWiki para integrar uma wiki ao Mantis. A partir dessa instalação, será possível criar uma instância de uma página da wiki onde haverá o plano de gerência de configuração. Apesar do conjunto Trac e Subversion fornecer o apoio suficiente para que sejam totalmente implementados os resultados esperados, conforme analisado, ainda é interessante a possibilidade de definir relações entre problemas identificados, no contexto do resultado esperado GCO 5, o que pode ser alcançado através da instalação do plugin MasterTickets. 4.6 Considerações Finais O capítulo 4 apresentou o Projeto SPIDER, e seus propósitos de definir metodologias de apoio a implementação dos níveis de maturidade G e F do MPS.BR, exclusivamente através de ferramentas de software livre, para diminuição do tempo e complexidade das implementações, além da redução de custo para as organizações. Aqui foram mostrados os dados coletados sobre as ferramentas disponíveis, hoje, para apoio da gestão de configuração de software e o mapeamento de dois conjuntos de ferramentas que serviram como base para definição de uma metodologia sistêmica para a implementação do processo de Gerência de Configuração do MPS.BR, a ser descrita no Capítulo 5.

45 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 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 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 ), 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 47 O conjunto B é composto pelas ferramentas SVN (versão1.6.5),, Trac (versão ) 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 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 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 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 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 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 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 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 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 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) 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 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 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 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 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 57 Figura 5.11 Check-in no Subversion (commit) 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 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 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 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 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 60 Figura 5.13 Criação de Baseline no Subversion (Tags) 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 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 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 62 projeto, juntamente com todas as versões existentes de cada item de configuração, como visto na Figura 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 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 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 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 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 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 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 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 Primeiramente, toda solicitação de mudança que for gerada, uma issue referente será instanciada, cada issue possuirá:

66 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 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 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 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 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 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 70 Figura Visualização de issues (View Issues) Figura 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 A lista é útil para informar o andamento das várias solicitações de mudança registradas.

71 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 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 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 Figura Histórico de mudanças do ticket 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 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 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).