UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação

Transcrição

1 UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Ferramenta para análise de utilização de Sistemas de Gerenciamento de Bugs em projetos de software livre Ronaldo Francisco Maia São Carlos - SP

2

3 Ferramenta para análise de utilização de Sistemas de Gerenciamento de Bugs em projetos de software livre Ronaldo Francisco Maia Orientadora: Prof a Dr a Renata Pontin de Mattos Fortes Monografia final de conclusão de curso apresentada ao Instituto de Ciências Matemáticas e de Computação ICMC-USP para obtenção do título de Bacharel em Ciência da Computação. Área de Concentração: Engenharia de Software USP - São Carlos Outubro de 2009

4

5 Resumo Ferramentas de software livre estão se tornando cada vez mais presentes no dia-a-dia das pessoas. Para desmistificar o processo envolvido no desenvolvimento de tais ferramentas, o projeto QualiPSo foi criado com o objetivo de realizar uma avaliação desse processo. No estudo realizado neste trabalho, evidenciou-se a importância dos Sistemas de Gerenciamento de Bugs (SGB) para a qualidade e sucesso do desenvolvimento dos projetos; como esses SGB estão inseridos nesse processo e sua utilização pelos usuários. Foi realizado também um estudo sobre as métricas levantadas no projeto QualiPSO, além de métricas existentes na literatura, servindo como ponto de partida para a reescrita da ferramenta Bicho, buscando auxiliar a avaliação de processos de software que utilizam SGB.

6

7 Sumário Lista de Figuras III Lista de Tabelas V 1 Introdução Objetivos do Trabalho Organização da Monografia Revisão Bibliográfica Métodos Ágeis Extreme Programming (XP) SCRUM Crystal Feature Driven Development Métodos Ágeis vs. Software Livre Desenvolvimento Orientado a Bugs Anatomia de um Bug Ciclo de Vida de um Bug Atividades de Garantia de Qualidade Ferramentas SGB Avaliação de Processos de Software O Modelo de Avaliação de Qualidade proposto no Qualipso Análise das Métricas

8 2.6 Considerações Finais Estado Atual do Projeto O Projeto Bicho Mudanças Aplicadas Frontends e Backends Interação Entre as Classes Configuração da ferramenta Avaliação Preliminar Data Warehouse Backend Interface Web Resultados Obtidos Conclusões e Trabalhos Futuros 35 5 Comentários Sobre o Curso 37 Referências Bibliográficas 39

9 Lista de Figuras 2.1 Capturas de telas apresentando campos de bugs do Bugzilla e Sourceforge Workflow para os bugs no Bugzilla e Trac (traduzidos a partir da documentação dos próprios SGB) Máquina de estados de um dos parsers da ferramenta Bicho Nova arquitetura da ferramenta Bicho Objetos do domínio Interação entre as classes Bicho, Frontend e Backend Exemplo de configuração da ferramenta Bicho Evolução dos estados dos bugs, por mês Evolução da atividade dos usuários, por mês

10

11 Lista de Tabelas 2.1 Características gerais de métodos de desenvolvimento ágeis, adaptado de (ABRAHAMSSON et al., 2002) Resumo dos dados de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009) Medidas extraídas de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009) Medidas extraídas do SGB do projeto stoq

12

13 1 1 Introdução Processo de Software é um conceito que tem sido investigado há mais de duas décadas por pesquisadores e profissionais envolvidos com desenvolvimento de software. Sommerville (2003) considera processo de software como um conjunto de atividades bem definidas que devem ser realizadas no decorrer do ciclo de desenvolvimento de um software. Essas atividades incluem, por exemplo, o planejamento, o levantamento de requisitos, o desenvolvimento, os testes do software desenvolvido, entre outras. Complementarmente são disponibilizadas diversas ferramentas, que buscam atingir um mesmo objetivo: o de facilitar e/ou melhorar o processo envolvido, de maneira a estimular que os erros humanos sejam reduzidos e que a automatização de certas tarefas auxiliem a produtividade e qualidade do produto em desenvolvimento. Entre as diversas ferramentas de apoio à melhoria do processo, estão os chamados bug trackers, ou Sistemas de Gerenciamento de Bugs (SGB), que auxiliam no gerenciamento de defeitos encontrados e no acompanhamento das melhorias necessárias no software que está sendo desenvolvido (DELUGACH, 2007). Os SGB são muito utilizados em processos de software cujos responsáveis se preocupam com a qualidade do produto desenvolvido, pois oferecem meios que possibilitam a discussão, registro e rastreamento dos problemas encontrados, visando aprimoramento e produtividade na comunicação das pessoas que podem participar no desenvolvimento do projeto de software. Dessa forma, os SGB apoiam as diversas fases do processo de software. Os SGB têm um papel importante no processo de desenvolvimento de projetos de software livre pois proporcionam um canal de comunicação entre desenvolvedores que, muitas vezes, não se encontram em um mesmo local, além de oferecerem à comunidade de usuários um histórico com o progresso do desenvolvimento e de planejamentos futuros (ANVIK; HIEW; MURPHY, 2006; BLEEK; FINCK, 2004). O desenvolvimento deste trabalho está inserido no contexto de um projeto maior, o projeto QualiPSo (Quality Platform for Open Source Softwares) 1, que envolve diversas empresas e instituições espalhadas pela Europa, China e Brasil, e cuja motivação é a desmistificação de ferramentas de software livre, principalmente no que se refere à 1

14 2 confiabilidade e qualidade do processo envolvido no desenvolvimento de tais ferramentas (QUALIPSO, 2009). Assim, um modelo de processo de software livre tem sido definido: OMM - The QualiPSo Open Maturity Model, bem como um conjunto de indicativos que possam ser obtidos por meio de métricas e verificações, para avaliar a aderência de um determinado processo ao OMM. 1.1 Objetivos do Trabalho O principal objetivo deste projeto é investigar SGB de apoio a processos de software livre, visando evidenciar dados de uso dessas ferramentas que possam demonstrar informações sobre qualidade de processo por meio de métricas estudadas na literatura. Para tanto, foram estabelecidos os seguintes objetivos específicos: Analisar a ferramenta existente Bicho para acompanhamento de SGB, uma vez que ela já estava em desenvolvimento por membros do projeto Qualipso; Estudar as métricas levantadas no desenvolvimento do projeto QualiPSo e na literatura, e como as mesmas podem ser extraídas de diversos SGB; Desenvolver a nova versão da ferramenta Bicho para auxiliar na coleta dessas métricas. 1.2 Organização da Monografia Como um tema importante desta pesquisa é sobre processo de software, no Capítulo 2, são apresentados os métodos ágeis, que foram estudados, visando identificar como eles se comparam ao processo de software livre. Uma vez que SGBs são as ferramentas objeto de estudo deste trabalho, são também descritos nesse capítulo os SGBs estudados na bibliografia, a forma como eles são utilizados nos diversos projetos de software, e quais elementos eles possuem em comum. Finalmente, no Capítulo 2, são apresentadas também as métricas envolvendo SGB e os dados coletados de quatro projetos de software, os quais são discutidos de modo a demonstrar as indicações qualitativas de processo, que podem ser obtidas desses dados. No Capítulo 3, que apresenta o estado atual de desenvolvimento deste projeto, é feita também uma avaliação sobre a ferramenta de análise de SGB denominada Bicho (que foi proposta no âmbito do projeto QualiPSo) e sobre o trabalho desenvolvido neste projeto de graduação, que foi realizado visando a análise das métricas levantadas no projeto QualiPSo, e como essas podem ser coletadas.

15 3 Finalmente, no Capítulo 4 são apresentadas as considerações finais do projeto desenvolvido e no Capítulo 5 são reportados os comentários do aluno sobre o curso de graduação.

16 4

17 5 2 Revisão Bibliográfica No contexto de processo de software, a literatura apresenta diversos métodos de desenvolvimento de software, que descrevem as atividades definidas e as características de como a adoção dos métodos se distingue dos demais. Os processos de software livre têm muitas semelhanças com os métodos ágeis, assim, neste capítulo são apresentados uma breve introdução aos métodos ágeis e como o processo de software livre pode ser considerado um método ágil. A seguir é discutido o estudo realizado sobre os conceitos relacionados aos SGB, bem como a relação desses com o processo de desenvolvimento em projetos de software livre. Além disso, as características principais de SGB existentes são discutidas e ao final, é apresentado como uma avaliação de processos de software pode ser realizada utilizando dados de SGB e o modelo de avaliação proposto no projeto Qualipso. 2.1 Métodos Ágeis Os Métodos Ágeis surgiram como uma alternativa para contornar os diversos problemas existentes nos métodos tradicionais de desenvolvimento de software, nos quais o trabalho começa com a documentação completa dos requisitos, seguida do projeto, implementação e manutenção (COHEN; LINDVALL; COSTA, 2004). Entre esses problemas destaca-se, por exemplo, a possibilidade dos usuários mudarem de idéia após um longo período de levantamento de requisitos, em um momento em que a alteração implica em um custo muito alto para o projeto. O termo Métodos Ágeis surgiu no início de 2001, com a formação de uma aliança envolvendo 17 grupos de especialistas em métodos de desenvolvimento interativos e incrementais (COHEN; LINDVALL; COSTA, 2004), mas Larman e Basili (2003) mostram que a aplicação dessas técnicas data de meados dos anos 50. Dessa aliança, surgiu o Agile Manifest que diz (BECK et al., 2001): Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Por meio deste trabalho, passamos

18 6 a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação Colaboração com o cliente mais que negociação de contratos Respostas a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos elementos descritos à direita na lista acima, valorizamos mais os elementos à esquerda. Abrahamsson et al. (2002) resume os métodos ágeis como tendo as seguintes características: Incremental: os lançamentos ocorrem em ciclos rápidos de desenvolvimento. Cooperativo: o cliente e os desenvolvedores trabalhando em próximos e em conjunto, constantemente. Direto: o método é fácil de aprender e modificar, bem documentado. Adaptativo: por ser fácil de realizar mudanças de última hora. Cohen, Lindvall e Costa (2004) afirmam que enquanto as técnicas ágeis têm práticas e ênfases diferentes, elas compartilham características comuns, incluindo desenvolvimento iterativo, com foco na interação, comunicação e redução de artefatos intermediários: O desenvolvimento em iterações permite ao time de desenvolvedores se adaptar rapidamente a mudanças nos requisitos. Trabalhar em um lugar próximo, e com foco na comunicação significa que os times podem tomar decisões e agir imediatamente, não precisando esperar correspondências. A redução da produção de artefatos intermediários, que não agregam valor ao produto final, leva a possibilidade de mais recursos serem aplicados ao desenvolvimento. A seguir são apresentados brevemente alguns métodos ágeis existentes, bem como são descritas suas características Extreme Programming (XP) O XP é um dos métodos ágeis mais populares e documentados (COHEN; LINDVALL; COSTA, 2004), e é uma combinação de idéias e práticas adquiridas de métodos previamente existentes (ABRAHAMSSON et al., 2002). As 12 praticas do método XP, conforme descritas por Beck (1999) são:

19 7 I Planejamento: os clientes decidem o escopo e tempo do lançamento baseados em estimativas fornecidas pelos programadores, que desenvolvem somente as funcionalidades exigidas na iteração. II Lançamentos pequenos: o sistema entra em produção em poucos meses, antes de resolver o problema como um todo. Os novos lançamentos são feitos frequentemente, diária ou mensalmente. III Metáfora: a forma do sistema é definida por uma metáfora, ou um conjunto de metáforas, compartilhadas entre cliente e programadores. IV Projeto simples: a qualquer momento, o projeto contém todos os testes, não contém código duplicado, e possui a menor quantidade possível de classes e métodos. V Testes: os desenvolvedores escrevem testes a todo momento. Esses testes são reunidos e todos devem ser satisfeitos com sucesso. Os clientes escrevem testes funcionais para os casos de uso (stories) da iteração. VI Refatoração: o projeto do sistema evolui através de transformações no projeto atual, desde que os testes não falhem. VII Programação em pares: todo o código é escrito pelos desenvolvedores organizados em pares, compartilhando um mesmo computador. VIII Integração contínua: o código novo deve ser integrado ao sistema em poucas horas. Quando integrado, o sistema deve ser reconstruído, e os testes devem continuar a ser satisfeitos. IX Autoria coletiva: qualquer programador pode melhorar o código em qualquer parte do projeto, ao encontrar uma oportunidade. X Cliente presente: o cliente está presente junto à equipe o tempo todo. XI Semanas de 40 horas: ninguém pode realizar horas extras por duas semanas consecutivas. Quaisquer horas extras são um sinal de problemas que devem ser resolvidos. XII Área de trabalho coletiva: a equipe trabalha em uma sala ampla, com cubículos espalhados ao redor, e a programação em pares é realizada em um computador no centro SCRUM Junto com o XP, o Scrum é um dos métodos ágeis mais populares (COHEN; LIND- VALL; COSTA, 2004). Schwaber (1995) descreveu que o Scrum pressupõe que processos

20 8 de desenvolvimento são imprevisíveis e complicados. Dessa forma o método é definido como um conjunto de atividades que incluem ferramentas e técnicas conhecidas com o melhor que uma equipe de desenvolvimento pode planejar para construir sistemas. O método Scrum inclui 3 fases (SCHWABER, 1995): Pré-jogo: esta fase inicial é composta pelas seguintes atividades: Planejamento - nessa fase é realizada a definição de um novo lançamento com base em um backlog, além da estimativa do tempo necessário e do custo. Se um novo sistema está sendo desenvolvido, essa fase consiste na conceitualização e análise. Se um sistema existente está sendo melhorado, essa fase consiste em uma análise limitada. Arquitetura - definição de como os itens do backlog serão implementados, incluindo as modificações na arquitetura e um projeto em auto nivel. Jogo: esta é a principal fase do processo Scrum. Nela são realizados os Sprints de desenvolvimento, nos quais novas funcionalidades são desenvolvidas, respeitando as variáveis tempo, requisitos, qualidade e custo. A combinação dessas variáveis define o fim desta fase. Pós-jogo: esta fase representa o final do método. Nela ocorre o fechamento, que consiste na preparação para o lançamento, incluindo documentação, testes e o lançamento propriamente dito. 1995): Além disso, o método Scrum apresenta as seguintes características (SCHWABER, Objetivos flexíveis : o conteúdo do produto final é ditado pelo ambiente. Agenda flexível : o produto final pode ser necessário antes ou depois do que planejado. Equipes pequenos : cada equipe não tem mais do que 6 membros e existem várias equipes em um mesmo projeto. Revisões frequentes : o progresso de uma equipe é revisto conforme a complexidade e risco exigirem assim o exigirem. Colaboração : a colaboração dentro e entre as equipes é esperada durante todo o projeto. Orientada a objetos : cada equipe trabalha em um conjunto de objetos relacionados, com interfaces e comportamentos claros.

21 Crystal Desenvolvido por Alistair Cockburn, no início dos anos 90, o método foi proposto como uma solução àquilo que acreditava ser um dos maiores obstáculos ao desenvolvimento de software: a comunicação (COHEN; LINDVALL; COSTA, 2004). Crystal é na verdade uma família de métodos classificados por cor, devendo ser escolhidos de acordo com o tamanho do projeto (ABRAHAMSSON et al., 2002). Todos os métodos pertencentes à família começam com um conjunto básico de papéis, técnicas e notações, e conforme a criticidade do projeto aumenta, o rigor do método acompanha. O processo usa ciclos de desenvolvimento incremental com um período máximo de quatro meses. É dada enfase a comunicação e cooperação, e leva em consideração o talento e capacidade dos desenvolvedores envolvidos. A metodologia não restringe as práticas e ferramentas que podem ser usadas, podendo também ser empregadas práticas de outros métodos ágeis como o XP ou Scrum Feature Driven Development A abordagem Feature Driven Development (FDD) não cobre todo o processo de desenvolvimento, mas da ênfase às fases de projeto e construção. Assim como o Crystal, o método foi projetado para ser empregado junto à outras atividades, mesmo que de outros métodos (ABRAHAMSSON et al., 2002). No FDD o processo começa com o desenvolvimento de um modelo, a partir do qual um conjunto de funcionalidades é identificado e depois organizado em pacotes. Esses pacotes são então distribuídos entre os desenvolvedores e as funcionalidades são planejadas com mais detalhes, implementadas, testadas e integradas Métodos Ágeis vs. Software Livre A Tabela 2.1 apresenta um resumo das principais características dos métodos ágeis apresentados. Embora possua algumas características distintas como a distribuição geográfica dos desenvolvedores e o tamanho das equipes, podemos observar que em processos de software livre, várias das idéias propostas pelos métodos ágeis são praticadas, tais como: lançamentos rápidos e frequentes, trabalho conjunto entre desenvolvedores e clientes (que muitas vezes também são desenvolvedores) e requisitos em constante elaboração, a medida que o software evolui (WARSTA; ABRAHAMSSON, 2003). Levando em consideração as características dos métodos ágeis, atribuídas por Abra-

22 10 Características Método Principais Especiais XP Desenvolvimento dirigido pelo cliente, times pequenos, builds diários. Scrum Times de desenvolvimento independentes, pequenos e autoorganizados, ciclos de lançamento de 30 dias. Crystal Família de métodos, cada um com os mesmos princípios. Técnicas, papéis, ferramentas e padrões variam. FDD Processo com cinco passos, desenvolvimento baseado em componentes (funcionalidades) orientados a objetos, iterações curtas (de horas a duas semanas) Refatoração - redesenho constante do sistema, para melhorar a performance e respostas a mudanças. Obriga uma mudança de paradigma do definido e repetível para a visão de desenvolvimento do Scrum Habilidade de selecionar o método mais apropriado baseado no tamanho do projeto e criticidade. Simplicidade do método, desenha e implementa o sistema por funcionalidades, modelagem de objetos. Tabela 2.1: Características gerais de métodos de desenvolvimento ágeis, adaptado de (ABRAHAMSSON et al., 2002). hamsson et al. (2002), podemos observar que o modelo de desenvolvimento de software livre também satisfaz as mesmas propriedades, que são (WARSTA; ABRAHAMSSON, 2003): Incremental: conforme notado por Raymond (1999), ter lançamentos rápidos e frequentes é uma das características de projetos de software livre. Cooperativo: a colaboração é a principal idéia por trás do software livre e é muito incentivada, mesmo que não seja por meio de código. Testes, documentação, traduções e divulgação também são formas de cooperação. Direto: embora não seja bem documentado, o modelo de desenvolvimento é de fácil aplicação e modificação. Adaptativo: os produtos de software livre possuem requisitos que estão em constante mudança, sempre se adaptando às necessidades dos seus usuários. Portanto o processo de software permite uma fácil adaptação a essas mudanças. Dessa forma, com base nas propriedades apresentadas, concluímos que processos de software livre pode ser considerados um tipo de método ágil. A seguir, é apresentado um modelo de processo mais detalhado de software livre, principalmente no que diz respeito ao gerenciamento de bugs ou requisitos.

23 Desenvolvimento Orientado a Bugs Reis e Fortes (2002) descrevem o processo utilizado nos projetos da Mozilla Foundation 1 como um Desenvolvimento Orientado a Bugs, no qual cada mudança realizada na base de código é feita como uma solução para um bug. Esses bugs não necessariamente representam um defeito, mas também podem ser planejamentos de melhorias no software ou pedidos de novas funcionalidades por seus usuários. Dessa forma, o ciclo de desenvolvimento de qualquer projeto de software pode ser iniciado com o controle de bugs. Já Halloran e Scherlis (2002) apresentam diversas ferramentas de software livre e evidenciam que praticamente todas usam algum tipo de SGB acessível ao público em geral. Além disso, descrevem brevemente o processo envolvido em relação aos bugs: Usuários relatam a existência de defeitos ou pedidos de melhorias, e cada um desses relatos se torna uma espécie de lista de discussões focada somente nesse ponto. Algumas dessas discussões são resolvidas rapidamente (como inválidas, por exemplo) e outras podem durar semanas ou até mais tempo, e podem envolver dezenas de mensagens. As ferramentas de gerenciamento de bugs fornecem o veículo para contribuições de código-fonte de programadores sem privilégios de alterações no repositório do projeto. Além disso, a ferramenta de gerenciamento de bugs tem um papel na gerência do projeto, permitindo, por exemplo, que problemas específicos (como desempenho, funcionalidade, reparos de problemas) sejam relacionados a um Planejamento para Lançamento Estável, oferecendo assim um ponto de partida para um lançamento futuro. Nesse contexto, este projeto, aliado às metas do Qualipso, também considera que as ferramentas SGB são essenciais para se apresentar um desenvolvimento eficiente e de software com qualidade Anatomia 2 de um Bug Cada ferramenta de SGB distinta possui uma definição diferente das informações que compõem um bug. Em geral, observa-se que essas informações podem ser pré-definidas pela própria ferramenta, ou ser atributos personalizados com valores específicos ao processo do projeto que os usa Os termos anatomia e ciclo de vida, comumente utilizados nos artigos que tratam desse assunto, tem origem provável na documentação do Bugzilla e fazem uma analogia à biologia dos insetos.

24 12 Alguns desses atributos possuem informações sobre a classificação do bug como prioridade e severidade, se é um defeito ou uma melhoria, a qual componente esse bug se aplica, entre outros. Há alguns valores que não mudam com o tempo, como o autor do relato e a data de abertura, e outros que podem ter mudanças mais freqüentes, como as pessoas envolvidas ou o estado atual do bug (ANVIK; HIEW; MURPHY, 2006). Embora muitas vezes diferentes, podemos observar que algumas dessas informações são recorrentes aos diversos SGB. A Figura 2.1 ilustra alguns desses campos nos SGB Bugzilla e Sourceforge. (a) Bugzilla (b) Sourceforge Figura 2.1: Capturas de telas apresentando campos de bugs do Bugzilla e Sourceforge A seguir, são descritas as informações básicas que os SGB apresentam em comum, mesmo que de diferentes formas (ANVIK; HIEW; MURPHY, 2006), (DELUGACH, 2007), (BUGZILLA, 2009), (TRAC, 2009): Descrição e Detalhes: os bugs sempre têm uma descrição simples e breve que ajuda a identificá-los rapidamente em uma lista, além de uma descrição mais detalhada de como reproduzir o problema, no caso de um defeito, ou melhorias desejadas, no caso de um pedido de funcionalidade nova. Estado e Resolução: o estado reflete a situação atual do bug e pode ter os seus valores resumidos em dois estados mais abrangentes: aberto ou fechado. Enquanto o bug estiver no estado aberto, ele pode ser considerado novo, ainda não ter sido confirmado como um bug de fato ou já estar atribuído para algum desenvolvedor, entre outros. Já no caso de um bug no estado fechado, ele pode ter sido

25 13 resolvido (com uma alteração efetiva no código), marcado como um bug duplicado de outro, ou sequer ser um problema de fato, o que o torna inválido. Relator: pessoa (usuário ou desenvolvedor) que reportou bug (problema ou requisição de uma melhoria). Responsável: desenvolvedor que irá trabalhar em uma solução para o bug. Anexos: arquivos anexos geralmente contêm informações não textuais como uma captura de tala de um problema ou um patch (solução) para o bug. Comentários: campos de texto livre no qual cada usuário pode expressar sua opinião em uma discussão ou adicionar informações que complementem a descrição. Revisões sobre soluções propostas geralmente acontecem na forma de comentários no próprio bug. Com base nessas informações, as ferramentas SGB se diferenciam conforme se especializam para atender diferentes necessidades de projeto. O Bugzilla, por exemplo, oferece um controle mais detalhado para o tempo gasto no desenvolvimento dos bugs, permite criar uma relação de dependência entre os bugs, e definir um lançamento alvo, para quando um bug deverá estar corrigido. (BUGZILLA, 2009) Ciclo de Vida de um Bug Desde sua criação até a resolução e fechamento, um bug passa por diversas fases, dependendo do processo adotado pelos desenvolvedores do projeto. Em geral, essas fases correspondem aos diversos conjuntos de estados pelos quais os bugs podem ser qualificados. Anvik, Hiew e Murphy (2006) relatam um exemplo desse ciclo de vida para um bug do projeto Eclipse 3 : Quando um bug é submetido ao repositório do Eclipse, o seu estado é ajustado para novo. Assim que um desenvolvedor foi designado ou assumiu a responsabilidade pelo bug o estado muda para atribuído. Quando um bug é fechado seu estado passa então para resolvido. Ele pode ainda ser marcado como verificado ou ser fechado para sempre ( fechado ). Um bug pode ser resolvido de diversas maneiras e essa informação é armazenada no campo resolução. Se a solução resultou em uma mudança na base de código o bug é resolvido como corrigido. Quando o desenvolvedor determina que já existe um relato equivalente para o bug, o mesmo é marcado como duplicado. Se 3

26 14 o desenvolvedor não conseguiu reproduzir o bug, como descrito, ele marca a resolução como funciona para mim. Se o bug descreve um problema que não será resolvido, ou sequer é um problema, a resolução será não será resolvido ou inválida, respectivamente. Um bug previamente resolvido pode ser reaberto em um outro momento, e terá o seu estado ajustado para reaberto. Assim como os campos definidos em um bug podem variar de ferramenta para ferramenta, o mesmo ocorre com as fases de sua vida. A Figura 2.2 mostra o fluxo dos estados nos SGB Bugzilla 4 e Trac 5. (a) Bugzilla (b) Trac Figura 2.2: Workflow para os bugs no Bugzilla e Trac (traduzidos a partir da documentação dos próprios SGB) É possível observar que na mudança entre os estados possíveis, certas atividades podem estar presentes, como: A confirmação de um bug ainda não confirmado, na passagem do estado Não Confirmado para o estado Novo 4 Adaptado de 5 Adaptado de

27 15 O processo de revisão ao qual os patches são submetidos antes de serem aplicados ao código, entre os estados Atribuído e Resolvido. A verificação da solução por parte da equipe de garantia de qualidade após o bug ter sido resolvido, o que pode levar ao estado Verificado se a equipe estiver satisfeita, ou ao estado Reaberto, caso algum problema ainda persita. Essas atividades de garantia de qualidade são apresentadas com mais detalhes a seguir Atividades de Garantia de Qualidade Conforme um bug avança em seu ciclo de vida, pode-se observar que atividades auxiliares estão envolvidas nesse processo. As principais atividades são a triagem pela qual os novos bugs passam, o processo de revisão e aprovação para as soluções propostas e a garantia de qualidade que é realizada após a aplicação da solução. Essas atividades são descritas a seguir. Triagem Uma das vantagens da natureza aberta de SGB em projetos de software livre é a possibilidade de que uma quantidade maior de bugs seja identificada e reportada pelos usuários. Em contrapartida, ela vem acompanhada de uma desvantagem : cada bug que é reportado deve passar por uma triagem a fim de assegurar que ele é realmente válido e atribuí-lo a um desenvolvedor apropriado (ANVIK; HIEW; MURPHY, 2006). Considerada uma atividade relacionada com a Garantia de Qualidade 6, a triagem envolve um trabalho nos bugs reportados, com tentativas de reprodução, podendo invalidálos quando as descrições fornecidas não são suficientes ou o problema é, na verdade, um comportamento esperado. Uma melhor distribuição dos novos bugs entre os desenvolvedores disponíveis também é uma das responsabilidades da triagem (REIS; FORTES, 2002). Anvik, Hiew e Murphy (2005) mostram que um dos desafios de se ter um SGB aberto é a quantidade de bugs que são reportados diariamente: o Firefox 7, por exemplo, recebe uma média diária de 8 bugs perto de um lançamento, com o máximo de 37 em um dia. Já o Eclipse tem uma média de 48 bugs por dia chegando a ter 192 perto de um lançamento. Dos bugs do Eclipse, 39% não contribuem para a melhora do produto, enquanto no Firefox esse número chega a 56%. 6 Do inglês, Quality Assurance 7

28 16 Revisão de código Em sua investigação sobre o processo envolvido na Mozilla Foundation, Reis e Fortes (2002) descrevem o processo de revisão e aprovação pelas quais as mudanças no código passam antes da integração como uma das características mais importantes: O processo de revisão funciona da seguinte maneira: o desenvolvedor trabalhando no código gera um patch, que consiste em um arquivo de texto descrevendo linha por linha as diferenças entre a versão local do desenvolvedor e a ultima versão do código do repositório. Esse patch é então anexado ao bug no Bugzilla e um pedido de revisão é feito. O revisor, que pode ser o dono do módulo ou alguém familiar com o código, irá então ler as mudanças de uma maneira crítica e aprovar ou sugerir novas alterações. Essa revisão é feita em comentários no próprio bug e podem descrever mudanças necessárias, questões sobre partes não esclarecidas ou recomendações sobre outros aspectos do patch (impactos no desempenho, dependências ou problemas relacionados). Validação das Mudanças Além da triagem já descrita, outra responsabilidade da Garantia de Qualidade é a realização de testes para assegurar que a solução aplicada realmente soluciona o problema descrito, e que novos problemas não foram introduzidos. Esses testes não são necessariamente realizados pela própria equipe de desenvolvedores, e podem ser realizados também por voluntários, smoke testers ou testes funcionais automáticos (REIS; FORTES, 2002). O termo Smoke tests descreve o processo de validação das mudanças no código antes desses serem integrados efetivamente no código do produto. Depois da revisão de código, smoke testing é o método mais rentável para identificar e corrigir defeitos no software (MICROSOFT, 2009). Conforme evidenciado na literatura, existe um consenso de que os SGB exercem um papel importante no processo de desenvolvimento de projetos de software livre, sendo muitas vezes a principal ferramenta utilizada na gerência de tais projetos. 2.3 Ferramentas SGB Para apoiar o processo de gerência de bugs, as ferramentas existentes possuem características similares. A partir de um estudo das ferramentas disponíveis, pode-se classificálas em dois tipos: as presentes em forges como o SourceForge e Google Code e as stan-

29 17 dalones, em que o usuário (ou projeto) interessado deve ter uma instalação própria para poder utilizá-lo. Como exemplos de forges temos o já citado SourceForge, além do Launchpad 8 e Google Code 9. Para os standalones, fora o popular Bugzilla, Mantis 10 e Trac 11 são outros SGB usados por projetos de software livre. Koru e Tian (2004) afirmam que em projetos de software livre de pequena escala, os desenvolvedores geralmente tomam nota dos defeitos encontrados em arquivos de histórico ou planilhas, ou os arrumam sem manter nenhum controle. Já Krishnamurthy (2002), em seu estudo sobre os 100 projetos mais maduros disponíveis no Sourceforge, chegou à conclusão de que a maioria dos programas de software livre é desenvolvida por um pequeno grupo de indivíduos. Pode-se concluir que projetos de pequeno porte geralmente utilizam algum tipo de forge pela simplicidade e facilidades oferecidas. Esses forges costumam oferecer diversas funcionalidades necessárias ou úteis ao processo de desenvolvimento, como ferramentas para controle de versões, documentação, listas de discussões, entre outras. Koru e Tian (2004) ainda descrevem que projetos de médio a grande porte, ou aqueles que envolvem mais do que apenas alguns desenvolvedores por um período curto de tempo, necessitam de um controle mais organizado sobre os defeitos, e que a maioria dos projetos de grande porte de que têm conhecimento usam ferramentas standalones, como o Bugzilla. Os SGB standalones são mais atrativos para projetos de maior porte ou mesmo empresas com desenvolvimento de software proprietário. Uma das desvantagens no uso de forges para esses projetos é a dependência de ferramentas que estão fora de seu controle e podem deixar de funcionar ou não estar disponíveis em algum momento crítico. Outro atrativo é a possibilidade de adaptar a ferramenta a necessidades específicas do projeto, como algum workflow diferenciado, ou restrições maiores a certos tipos de usuários, o que dificilmente é possível em ferramentas mais genéricas como os forges. 2.4 Avaliação de Processos de Software Com o decorrer do processo de desenvolvimento e o uso das ferramentas de apoio (entre elas os SGB), dados importantes sobre o processo são gerados e podem ser usados para realizar uma avaliação sobre o mesmo. Esses dados podem ser utilizados individualmente ou até mesmo combinados, para uma melhor aferição sobre como as ferramentas envolvidas

30 18 se relacionam. Bachmann e Bernstein (2009) afirmam, no entanto, que pouca informação sobre a qualidade desses dados está disponível, embora sejam muito utilizados em pesquisas. Essa qualidade é definida como a porcentagem dos dados disponíveis que realmente possuem informações relevantes para realizar a avaliação. A seguir são apresentadas as medidas características de processo envolvendo SGB e controle de versão, levantadas por Bachmann e Bernstein (2009): M-I Mudanças de estado por bug: as mudanças de estado em bugs são uma boa indicação para o grau de colaboração e a existência de um processo definido para a manipulação de bugs. M-II Comentários por bug: o número de comentários é um bom indicador para a atividade da comunidade, mas também pode ser um sinal de uma má descrição do bug. Bugs com vários comentários devem, portanto, ser analisados cuidadosamente. M-III Anexos por bug: os arquivos anexos podem ser muito úteis para um desenvolvedor resolver um problema, logo, anexos são um bom sinal de qualidade do relato. M-IV Média de bugs abertos por usuário: quanto maior a quantidade de bugs abertos por um usuário, melhor é a qualidade dos bugs, devido ao aprendizado que o usuário obtém a cada novo bug, como qual informação é relevante para os desenvolvedores solucionarem o problema. Melhores descrições do problema levam a uma resolução mais eficiente, logo, quanto maior esse valor, mais rápido os bugs podem ser resolvidos. M-V Relação de usuários que alteram estados de bugs por desenvolvedor: essa relação mostra o quão aberto é o acesso ao SGB. No caso ideal, o desenvolvedor que resolve um bug é o mesmo que o marca como resolvido, e mais tarde, alguém valida a solução e finalmente, alguém marca como fechado. Nesse caso, um máximo de três pessoas diferentes modificariam o estado do bug. M-VI Relação de usuários que reportam bugs por desenvolvedor: quanto maior a comunidade, maior é a quantidade de usuários que abrem bugs. Um valor mais alto não necessariamente é um mau indicador, mas quanto menor esse número, maiores as chances do desenvolvedor dar retorno para bugs descritos de uma forma incompleta. M-VII Média de bugs por desenvolvedor: Quanto mais bugs um desenvolvedor se envolver, maior sua experiência e desenvolvedores experientes são de grande valor para um projeto. Portanto esse valor também é um indicador da experiência na comunidade de desenvolvedores.

31 19 M-VIII Média de bugs resolvidos por desenvolvedor: de forma similar, quanto mais bugs um desenvolvedor já resolveu, maior é sua experiência dentro de um projeto. Em um estudo de Wang, Guo e Shi (2007) sobre a evolução de sistemas de software livre, foi definido um conjunto de métricas relacionadas a SGB muito similar às métricas citadas. A Tabela 2.2 apresenta um resumo dos dados presentes nos SGB de projetos de software livre, enquanto a Tabela 2.3 mostra os valores para algumas das métricas definidas. (BACHMANN; BERNSTEIN, 2009) Apache Eclipse Gnome OpenOffice Período considerado 18/03/ /04/ /10/ /02/ /05/ /09/ /03/ /02/2008 Total de Bugs Bugs resolvidos Bugs duplicados Relatores Alteradores de estado Comentários Desenvolvedores Tabela 2.2: Resumo dos dados de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009) Apache Eclipse Gnome OpenOffice Taxa de bugs resolvidos 28,80% 52,16% 26,40% 38,93% Taxa de bugs duplicados 12,39% 13,03% 33,56% 16,12% Taxa de bugs inválidos 34,46% 12,76% 4,32% 19,46% Mudanças de estado por bug 1,77 1,83 1,35 2,93 Comentários por bug 3,58 4,32 2,95 6,53 Alteradores de estado por desenvolvedor 12,27 27,94 7,54 29,10 Relatores por desenvolvedor 46,80 100,73 105,50 161,53 Bugs por desenvolvedor 66, ,33 285,50 728,17 Bugs resolvidos por desenvolvedor 19,19 600,58 75,38 283,49 Tabela 2.3: Medidas extraídas de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009)

32 20 Esses dados nos permitem entender melhor o processo que há por trás de cada projeto de software livre, no entanto, deve-se sempre levar em consideração as características individuais de cada projeto como a quantidade de desenvolvedores, o público alvo e a quantidade de usuários, idade do projeto, tamanho da base de código, entre outras. Nos dados apresentados, podemos destacar, por exemplo, os valores altos para a relação de bugs por desenvolvedor (M-VII) e de usuários que reportam bugs por desenvolvedor (M-VI). Além de evidenciarem o elevado número de usuários, esses valores altos são indícios de que o processo está sendo prejudicado, seja pela baixa qualidade dos bugs reportados e o tempo gasto pelos desenvolvedores para tentar identificar esses problemas mal descritos, ou pela dificuldade em identificar bugs duplicados, entre outros. Outro dado interessante é o número de mudanças de estado (M-I). Em um processo bem definido, espera-se que um bug passe por várias fases desde sua criação até a finalização, conforme descrito na Seção 2.2. Esse valor não necessariamente deve ser grande, mas deve estar próximo do número de mudanças de estado pelo qual se espera que um bug passe. Por exemplo, no caso de um processo onde um bug, após aberto, deve ser designado a um desenvolvedor e após a resolução ele deve ser verificado, espera-se que o valor de M-I esteja próximo de 3. Conclui-se assim que os SGB são uma boa fonte de informação acerca do processo de desenvolvimento empregado em sistemas de software livre, porém, por cada projeto ter características singulares, deve-se levar em consideração as propriedades de cada um, tanto do processo utilizado quanto do produto sendo desenvolvido. 2.5 O Modelo de Avaliação de Qualidade proposto no Qualipso Conforme o movimento Open Source evolui e produtos de software livre ganham popularidade, espera-se que os requisitos de qualidade sobre esses produtos aumentem, e isso traz a necessidade de se estabelecer o que é qualidade em processos de desenvolvimento de software livre. Produtos comerciais geralmente exibem certificados de qualidade ou alegam aderência à padrões bem estabelecidos, como o ISO9001. No entanto, para projetos de software livre, pode não ser fácil de se obter tal certificação, pois elas exigem documentação detalhada, organização de responsabilidades claramente definidas, entre outros requisitos. A satisfação desses requisitos se torna difícil uma vez que projetos de software livre são desenvolvidos por pessoas espalhadas geograficamente e sem uma infra-estrutura ou ambiente formal definido.

33 21 Com base nisso, o projeto Qualipso desenvolveu, baseado no modelo CMMI 12, um modelo de avaliação denominado Qualipso OpenSource Maturity Model (OMM). Esse modelo é o resultado da comparação dos elementos de confiança (TrustWorthy Elements - TWE) de processos de desenvolvimento de software livre e dos TWE encontrados no CMMI, e da seleção dos elementos que são necessários ou que estão faltando nos dois modelos. Utilizando o método Goal, Question, Metric (GQM) (BASILI; CALDIERA; ROM- BACH, 1994), foram definidas métricas para avaliar os diversos elementos de confiança definidos no OMM. A seguir são apresentadas as métricas relacionadas aos sistemas de apoio utilizados em processos de software, e que de certa forma permitem uma coleta automática por meio de ferramentas especializadas. Essas métricas podem ser indicadores importantes da qualidade em processos de software livre, porém é necessário um estudo mais profundo para avaliar a viabilidade de coleta dessas informações Análise das Métricas Em (WITTMANN et al., 2008) foi feito um levantamento de várias métricas de processo de software baseado nos elementos de confiança definidos no OMM. A seguir, essas métricas são classificadas pela área de aplicação e, ao mesmo tempo, são propostas algumas medidas equivalentes (ou complementares) que podem ser extraídas de SGB. Código Fonte Essas são medidas que podem ser obtidas realizando uma análise do código fonte ou do histórico de mudanças do repositório. M1 Número de autores de mudanças distintos. Da mesma forma que temos os autores em sistemas de controle de versões, temos os bug reporters em SGB. Poderiamos ainda fazer essa medida usando os criadores de patches, o que pode ser uma informação mais valiosa que os próprios commiters, uma vez que em projetos de maior porte, são poucos os usuários que têm permissão para aplicar as modificações. M2 Percentual de atividade (número de alterações em um certo período). Podemos medir o percentual de atividade em SGB também, analisando a quantidade de bugs abertos, comentários inseridos ou patches anexados aos bugs. 12 Capability Maturity Model Integration

34 22 M3 Número de alterações normalizado (usando o número de contribuições dos maiores contribuidores). Da mesma forma que em M2, podemos usar as atividades dos usuários nos SGB. M4 Autoria dos módulos (Número de módulos escrito por cada usuário) M5 Liderança de código (Percentagem do número de módulos escrito por autor) M6 Número de desenvolvedores ativos que se tornam Core developers (Taxa de evolução, medida como o número de contribuições) M7 Taxa de usuários e desenvolvedores (evolução ao longo do tempo) Novamente, podemos evidenciar esses dados em SGB. Usuários são aqueles que somente reportam bugs ou inserem comentários, já os desenvolvedores costumam mais marcar os bugs como resolvidos e anexar patches M8 Taxa de linhas órfãs, que são as linhas de código que não foi possível definir a autoria. (evolução ao longo do tempo) M9 Freqüência de lançamentos (evolução ao longo do tempo). Dependendo das características, esta é uma informação que pode estar presente em SGB. M10 Número de mudanças introduzidas a cada lançamento (evolução ao longo do tempo). Caso o SGB ofereça um controle de lançamentos, como marcos alvos, podemos considerar o número de mudanças introduzidas como o número de bugs resolvidos. Mesmo que a ferramenta não ofereça esse controle, podemos obter essa informação levando em consideração o período de desenvolvimento de cada lançamento. M18 Número de licenças distintas incorporadas (evolução) M19 Número de arquivos e módulos sem licença (evolução) M20 Número de idiomas suportados (evolução) Documentação A documentação pode estar presente em várias formas, como arquivos de texto no próprio repositório de código fonte ou ferramentas de edição colaborativa (wikis), que estão de tornando cada vez mais comuns em projetos de software livre. M11 Número de documentos guia.

35 23 M12 Número de documentos com recomendações de desenvolvimento M13 Presença de documentação de planejamento M14 Presença de árvore de autoria. M15 Presença de FAQ e guia de usuários M16 Presença de diretrizes sobre o workflow do projeto Gerenciamento de Bugs Essas são as métricas que podem ser obtidas diretamente de SGB. Elas serão o alvo da ferramenta desenvolvida neste projeto de graduação. M23 Número de pedidos de modificações submetidos pelos testes automáticos (evolução). M24 Número de pedidos de melhorias submetidos por usuários/desenvolvedores (evolução). M25 Número de bugs enviados ao projeto (evolução). M26 Número de bugs abertos. M27 Número de bugs sem um target. M28 Número de bugs não atribuídos. M29 Percentagem de bugs resolvidos (por período de tempo). M30 Número de bugs enviados. M31 Percentagem de bugs de regressão (sobre o total de bugs). M32 Percentagem de bugs de erros (sobre o total de bugs). Listas de Discussão As listas de discussões oferecem para os usuário um meio de comunicação para que dúvidas sejam tiradas e problemas discutidos. Conforme descrito por Halloran e Scherlis (2002) os bugs se tornam uma espécie de mini-lista, onde somente as questões relativas ao bug são consideradas. M33 Número de cadastros nas listas. Da mesma forma que temos os cadastros nas listas, temos os usuários cadastrados no SGB.

36 24 M34 Número de escritores para as listas. Enquanto os bugs são mini listas, podemos medir o número de usuários que comentam em bugs. M35 Número de cadastrados que se tornaram desenvolvedores. Essa é outro valor que pode ser aferido com mais precisão usando os dados presentes em SGB: é possível determinar o momento em que um usuário deixou de contribuir apenas com comentários e novos bugs, e passou a propor soluções na forma de patches. M36 Contribuidores mais ativos nas listas. Novamente, podemos verificar quais são os usuários mais ativos nos SGB. 2.6 Considerações Finais Neste capítulo vimos como processos de software livre se comparam com os métodos ágeis, e podem inclusive ser considerados como tal. Vimos também a importância dos SGB para os projetos de software livre, a forma como essas ferramentas estão inseridas no processo envolvido nos projetos e quais são as informações gerenciadas pelos SGB. Além disso, foram apresentadas métricas existentes na literatura e levantadas no projeto Qualipso, que evidenciam a qualidade do processo de software, ao mesmo tempo que foram comentadas maneiras de se extrair valores equivalentes (ou complementares) para tais métricas. No capítulo a seguir, será descrita a ferramenta desenvolvida neste projeto para auxiliar na coleta das métricas estudadas e que foram consideradas como requisitos para a avaliação da qualidade do processo de software, coletados de SGB.

37 25 3 Estado Atual do Projeto Neste capítulo é descrita a ferramenta denominada Bicho, o seu estado no início do projeto, as alterações que foram implementadas e uma interface web criada para visualização dos dados coletados. Entre os motivos que levaram à escolha dessa ferramenta para o desenvolvimento desse projeto de graduação estão: A sua inclusão no planejamento do projeto Qualipso como resultado de uma de suas fases (PETRINJA et al., 2008). A linguagem de programação do projeto ser Python e a familiaridade deste autor com a mesma. Após o desenvolvimento das alterações, foi possível coletar dados reais de projetos de software livre atuais. Uma interface web foi implementada para exemplificar uma possível aplicação de visualização desses dados. 3.1 O Projeto Bicho Desenvolvido pelo GSyC/LibreSoft, um grupo de pesquisa da Universidad Rey Juan Carlos, Espanha, o projeto Bicho é uma ferramenta de linha de comando usada para analisar SGB. Em sua execução, a ferramenta cria um banco de dados contendo três tabelas com cópias das informações presentes no SGB sob análise (GSYC/LIBRESOFT, 2009): Bugs, com detalhes sobre cada bug; Comments, com informações sobre cada comentário nos bugs; Attachments, com informações sobre cada arquivo anexo aos bugs.

38 26 Com o inicio do desenvolvimento em agosto de 2007, tendo última atividade registrada em fevereiro de 2009 e com três versões lançadas nesse período, a ferramenta possuía quase 3000 linhas de código Python e apresentava as seguintes funcionalidades: Possibilidade de configuração via parâmetros na linha de comando ou arquivo de configuração; Parser para os bug trackers Bugzilla e Sourceforge; Armazenamento em banco de dados com o esquema dos dados descrito acima. O parser para os bugs do Sourceforge, por exemplo, foi implementado usando uma máquina de estados finitos de difícil leitura e interpretação, o que tornava a manutenção do código uma tarefa árdua. Após uma re-estruturação ocorrida recentemente nas páginas do Sourceforge, esse parser deixou de funcionar corretamente e uma tentativa de corrigir o código levaria muito tempo. A Figura 3.1, presente na documentação da ferramenta, mostra o diagrama de estados implementado nesse parser. É possível observar que os estados enumerados consistem nas 19 possíveis condições dos estados que o programa deve prever e todas as respectivas transições, rotuladas com os tokens html que permitem a transição. Assim, fica evidenciada a complexidade do código implementado nesse parser. O projeto apresentava também uma ligação muito forte entre o frontend (parte responsável pela busca dos dados nos SGB) e o backend (parte responsável pelo armazenamento da saída no banco de dados), o que também dificultava a adição de novas funcionalidades como outros SGB ou um esquema diferente de banco de dados. 3.2 Mudanças Aplicadas O trabalho inicial deste projeto de graduação na ferramenta Bicho foi o de tentar minimizar os problemas citados na seção anterior, começando por uma refatoração do código com o objetivo de satisfazer o máximo possível as indicações do PEP-8 2. O PEP- 8 (Python Enhancement Proposals ou Propostas de Melhoras para o Python) contém uma série de convenções sobre o estilo de código para os programas e bibliotecas escritas em Python, como: identação, uso dos espaços em branco, tamanho máximo das linhas e linhas em branco, além de algumas recomendações sobre a forma de programar. Ao mesmo tempo em que a refatoração do estilo era feita, o projeto foi sendo re-escrito, removendo partes de código desnecessários ou melhorando a forma como algumas soluções 2

39 27 Figura 3.1: Máquina de estados de um dos parsers da ferramenta Bicho. 1 foram implementadas. Ao final de todas as alterações, o projeto passou a apresentar pouco mais de 1600 linhas de código Python. Nas subseções a seguir são descritos os principais componentes da nova arquitetura da ferramenta, a interação entre esses componentes e a configuração da ferramenta. A nova arquitetura é ilustrada pela Figura 3.2. Figura 3.2: Nova arquitetura da ferramenta Bicho