Identificação e visualização de rastros entre artefatos no GitHub

(1)

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA

DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Identificação e Visualização de Rastros

entre Artefatos no GitHub

Gabriel Sebastian von Conta

Natal-RN Novembro, 2018

(2)

Gabriel Sebastian von Conta

Identificação e Visualização de Rastros entre

Artefatos no GitHub

Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de bacharel em Ciência da Computação.

Orientador

Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Coorientador

Profa. Dra. Roberta de Souza Coelho

Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – DIMAp

Natal-RN Novembro, 2018

(3)

Conta, Gabriel Sebastian von.

Identificação e visualização de rastros entre artefatos no GitHub / Gabriel Sebastian von Conta. - 2018.

58f.: il.

Monografia (Bacharelado em Ciência da Computação)

-Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Departamento de Informática e Matemática Aplicada, Curso de Ciência da Computação. Natal, 2018. Orientadora: Marcia Jacyntha Nunes Rodrigues Lucena. Coorientadora: Roberta de Souza Coelho.

1. Computação - Monografia. 2. Rastreabilidade - Monografia. 3. Coleta de dados Monografia. 4. Visualização de links -Monografia. I. Lucena, Marcia Jacyntha Nunes Rodrigues. II. Coelho, Roberta de Souza. III. Título.

RN/UF/CCET CDU 004

Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET

(4)

Monografia de Graduação sob o título Identificação e Visualização de Rastros entre Artefatos no GitHub apresentada por Gabriel Sebastian von Conta e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:

__________________________________________ Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Orientador(a)

Departamento de Informática e Matemática Aplicada UFRN

__________________________________________ Profa. Dra. Roberta de Souza Coelho

Co-orientador(a)

_________________________________________ Profa. Dra. Lyrene Fernandes da Silva

(5)

Ao meu pai Manfred pelo amor e carinho.

(6)

Agradecimentos

Agradeço primeiramente às professoras Roberta e Márcia por me orientarem e acreditarem na minha capacidade e na qualidade do trabalho. Todos os conselhos foram sempre preciosos.

Obrigado a minha família pelo apoio emocional e o incentivo sempre a fazer o meu melhor. Em especial agradecimentos à minha mãe, Sônia, por sempre estar disponível e me incentivar a fazer o que eu gosto.

Minha gratidão à todos os colegas do laboratório LETS que me presentearam com sua atenção e companhia, provendo muitas trocas de idéias que enriqueceram meu conhecimento e aqueceram meu coração.

Obrigado à todos os amigos que estiveram presentes, tornando a minha experiência na universidade e na vida mais divertida e interessante. Por fim, minha gratidão e carinho à Valquíria, que sempre me apoiou e incentivou de todas as formas, sendo uma pessoa maravilhosa e uma companheira fiel.

(7)

Even if you're on the right track, you'll get run over if you just sit there.

(8)

Identificação e Visualização de Rastros entre

Artefatos no GitHub

Autor: Gabriel Sebastian von Conta Orientador(a): Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena Co-orientador(a): Profa. Dra. Roberta de Souza Coelho

R

ESUMO

O GitHub é um repositório de projetos de código aberto e uma das ferramentas mais utilizadas para gerenciamento e organização de projetos, contendo diversos sistemas, desde projetos de alunos até sistemas de informação de governos. Todos esses projetos contém informações vitais para o seu desenvolvimento e manutenção, como requisitos, testes e bugs. Apresentar essa informação de forma clara e inteligível ainda é um desafio. Buscamos neste trabalho apresentar uma solução para esse desafio, através de uma abordagem que produza uma visualização dos dados, suas características e relacionamentos. A partir dos dados disponibilizados pelo GitHub é feita a coleta dos dados. Uma vez com esses dados em mãos, utilizamos a plataforma de banco de dados em grafos, Neo4j, para criar uma visualização dos relacionamentos entre os dados e suas características. Com essa visualização disponível, esperamos tornar o processo de tomada de decisão e gerência de projetos mais fácil e intuitiva. A proposta é validada em um projeto de código aberto, usando requisitos delimitados para a abordagem como forma de medir sua eficiência.

Palavras-chave: Rastreabilidade, Coleta de dados, Visualização de links, Neo4j, GitHub.

(9)

Identification and visualization of links between

requirements and artefacts on GitHub

Author: Gabriel Sebastian von Conta Advisor: Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena Co-Advisor: Profa. Dra. Roberta de Souza Coelho

A

BSTRACT

GitHub is a repository of open code projects and one of the most utilized tool for organizing and maintaining projects, having a large number of diverse projects, from students projects to governmental information systems. All of those containing vital information for the development and maintenance, such as requirements, tests and bugs. Showing this info in a clear and intelligible way is still a challenge. In this paper we present a solution for this challenge, using an approach that produces a data visualization, its characteristics and relations. Starting from the data available through GitHub we collect and structure the desired info. With this info at hand, we use the graph oriented database platform Neo4j to create a visualization of the data characteristics and relations. With the created visualization we expect to provide the decision and management process of the projects easier and more intuitive. The approach is then validated through an open code project, using requirements as a measurement tool for efficiency.

(10)

Lista de Figuras

Pré, Inter e Pós-rastreabilidade p.15

Rastreabilidade vertical e horizontal p.16

Matriz de Rastreabilidade p.17

Grafo de Rastreabilidade p.18

Estrutura de grafo na plataforma Neo4j p.21

Exemplo de grafo produzido pelo Neo4j p.22

Diagrama de Atividades do Workflow do Trabalho p.28

Issues do projeto barra.govbr p.31

Organization do projeto barra.govbr p.32

Pull requests do projeto barra.govbr p.33

Nó repositório do projeto barra.govbr p.34

Usuários contribuidores do projeto barra.govbr p.34

Diagrama de Cenário de Uso p.38

Execução do código para coleta de dados p.40 Arquivos gerados e trecho do arquivo de dados referente às issues p.41 Criação dos nós e relacionamentos e trecho do código cypher p.41 Representação em grafo do projeto barra.govbr p.42 Visão do projeto barra.govbr no site do GitHub p.43

Issues com estado aberto p.44

Issues abertas do projeto barra.govbr na visão do GitHub p.45 Artefatos criados pelo usuário caduvieira p.46

Consulta com tempo delimitado p.47

Uso do GitHub Visualizer aplicado ao projeto Barra.govbr p.49

(11)

Lista de Tabelas

Requisitos exibidos em Trindade (2018) e seus status p.25 Campos selecionados a fim de atender requisitos levantados p.30

(12)

Sumário

1 Introdução 10 1.1 Apresentação do Problema 11 1.2 Objetivo geral 11 1.3 Metodologia 12 1.4 Organização do trabalho 13

2 Fundamentação Teórica e Tecnologias utilizadas 14

2.1 Rastreabilidade 14

2.2 GitHub 20

2.3 Neo4j 20

3 Abordagem Proposta 23

3.1 Foco e Público da abordagem 23

3.2 Desenvolvimento da abordagem 24

3.2.1 Requisitos e Modelagem 25

3.2.2 Construção da abordagem proposta 29

3.3 Desenvolvimento, Dificuldades e Aprendizados 36

4 Cenário de Uso 40

4.1 Descrição do Projeto 41

4.2 Descrição da execução da abordagem 42

5 Trabalhos relacionados 51 5.1 GitHub Visualizer 51 5.2 Gource 53 6 Considerações Finais 55 6.1 Limitações e Ameaças 55 6.2 Trabalhos futuros 56 7 Referências 57

(13)

10

1 Introdução

Para facilitar e acelerar o processo de produção de código, métodos ágeis vem ocupando cada vez mais o ambiente de produção. Ancorado pelo manifesto ágil, um dos seus pontos centrais é a produção de software em funcionamento mais valorizado que documentação abrangente.

Segundo Trindade (2015) o foco em interações entre pessoas no lugar de ferramentas e processos leva a um grande desafio quando pensamos na construção de uma documentação formal e, consequentemente, na engenharia de requisitos(ER). Apesar de ainda termos um volume de documentação gerada, elas não são suficientes para prover rastreabilidade, uma atividade importante da ER.

Procurando ainda acelerar o desenvolvimento de Sistemas e prover uma forma de armazená-lo temos sites de versionamento de código, onde são armazenados todo tipo de projeto em enormes quantidades. Alguns desses sites que podem ser citados são Bitbucket, Gitlab e, o maior deles, GitHub. O GitHub contém mais de 96 milhões de repositórios, como por exemplo o sistema operacional Linux.

Junto com esse enorme volume de projetos, temos também um grande volume de dados. Dentro de um único repositório existem diversos dados e ferramentas que auxiliam no desenvolvimento do código, mas essas informações estão dispersas pelo sistema do GitHub ou não possuem visibilidade, dificultando tomadas de decisão para fins de gerenciamento do projeto.

(14)

11 Esse trabalho se propõe então, usando como base noções de rastreabilidade junto com as tecnologias disponibilizadas pelo GitHub (através de sua API), prover uma visualização do repositório, tendo como base a pesquisa e requisitos levantados por Trindade (2018).

1.1 Apresentação do Problema

Dado o alto volume de dados do GitHub, a forma como esses dados estão apresentados no site e a conjuntura de metodologias ágeis utilizada normalmente no desenvolvimento de software torna-se complexa a realização de rastreabilidade, apesar de suas diversas vantagens.

Seja pela visualização dos artefatos e seus relacionamentos estar comprometida ou pelo alto custo de documentação e manutenção para proporcionar rastreabilidade dos requisitos, não é comum a visualização dos relacionamentos entre os dados.

1.2 Objetivo geral

O objetivo deste trabalho é investigar os potenciais rastros entre artefatos que podem ser identificados a partir de informações disponíveis no GitHub. Esses rastros podem ser de utilidade para gerentes de projetos como identificados no trabalho de Trindade (2018).

Para alcançar este objetivo geral temos os seguintes objetivos específicos: (i) investigar os potenciais rastros existentes entre artefatos do GitHub; (ii) definir uma abordagem que proporcione a identificação de artefatos e seus relacionamentos; (iii) providenciar uma visualização para

(15)

12 esses artefatos; (iv) atender aos requisitos levantados diretamente com gerentes, retirados do trabalho de Trindade (2018), exibidos no capítulo 3; e, por fim, (v) essa abordagem deve realizar consulta a partir de qualquer repositório do GitHub.

1.3 Metodologia

O trabalho se iniciou com a leitura do material referente à rastreabilidade e suas aplicações (Pohl, 2010) em conjunto com o primeiro levantamento feito por Trindade, 2015. Escolheu-se então o GitHub como ponto de coleta de dados devido ao seu grande número de repositórios e extensa utilização. Paralelamente, ocorreu a leitura de material referente ao Neo4j e sua linguagem própria (cypher), a fim de criar a visualização dos dados coletados.

Definiu-se então python como a linguagem a ser utilizada devido às suas diversas bibliotecas para mineração de dados. Inicialmente foi usada uma biblioteca especial do python para git, Gitpython, mais tarde abandonada em favor da própria api do GitHub, uma vez que a biblioteca Gitpython era mais adequada para operações no próprio git, enquanto que a API dedicava-se à consultas, o que era o objetivo desejado.

Inicialmente produziu-se um código para retirada de informação de commits e produção de grafo representando cada commit e seus relacionamentos. Validado o grafo, extraiu-se todos os dados presentes no GitHub, a partir da documentação de sua API e foi realizada a seleção do que seria utilizado. Gerou-se um novo código python, agora realizando a consulta

(16)

13 ao que foi selecionado e criou-se um script cypher para a criação do grafo, chegando ao estado atual da abordagem.

1.4 Organização do trabalho

O trabalho está organizado como segue: o Capítulo 2 reúne tanto a teoria referente a rastreabilidade, como descrições das tecnologias utilizadas, GitHub e Neo4j, detalhando suas características e o motivo de suas escolhas.

O capítulo 3 descreve o desenvolvimento da abordagem, detalhando cada passo a passo desde a análise dos requisitos até a criação de consultas de exibição, encerrando-se com dificuldades e soluções encontradas. O capítulo 4 se trata de um exemplo da abordagem utilizada em um repositório do GitHub. O capítulo 5 trata de trabalhos relacionados, descrevendo duas outras ferramentas de visualização do GitHub que foram encontradas e o capítulo 6 contém as considerações finais do trabalho, assim como possíveis trabalhos futuros.

(17)

14

2 Fundamentação Teórica e Tecnologias

utilizadas

Nesta seção trataremos primeiramente de rastreabilidade, sua definição, vantagens trazidas e seus custos, passando em seguida a como ela pode ser representada. Uma vez apresentados seus detalhes, serão escolhidos e delimitados que tipos de rastreabilidade serão apresentadas na abordagem.

Em seguida será discorrido o sistema de versionamento de código GitHub, de onde os dados serão acessados e agrupados de forma a identificar os traços de rastreabilidade entre os artefatos presentes na plataforma.

Por fim trataremos do Neo4j, um sistema de banco de dados orientado a grafos, utilizado para receber os dados tratados do GitHub, associá-los a nós e arestas, de forma a tornar possível a visualização dos traços de rastreabilidade presentes.

2.1 Rastreabilidade

Conforme discutido em Gotel et al. (2012) a rastreabilidade de um requisito é "a possibilidade de acompanhá-lo através do ciclo de vida do sistema". Rastreabilidade ainda pode ser definida como "a capacidade de linkar um requisito aos artefatos do sistema que o satisfazem". De acordo com Genvigir (2009) a rastreabilidade falha ao não executar uma das seguintes habilidades: foward e backward , onde foward é a capacidade de

(18)

15 rastrear um requisito em direção a seus refinamentos e backward a

capacidade de rastrear um refinamento até sua origem. Outra classificação de rastreabilidade bastante presente na literatura(Gotel e Finkelstein, 1994) se baseia em dois pontos, sendo eles:

1) Rastreabilidade Pré, Inter e Pós-especificação (Figura 1):

a) Pré-especificação: Relacionamento entre artefatos que formam a base para o documento de requisitos e o próprio requisito.

b) Pós-especificação: Relacionamento entre artefatos posteriores a especificação, como atividades de desenvolvimento (código, artefatos) e o próprio requisito.

c) Inter-especificação: Relacionamentos entre os requisitos, mostrando suas dependências.

Figura 1: Pré, Inter e Pós-rastreabilidade. Fonte: (Trindade, 2018)

(19)

16 2) Rastreabilidade Vertical e Horizontal (Figura 2)

a) Vertical: Ocorre entre requisitos e artefatos produzidos pelo processo de desenvolvimento durante o ciclo de vida do projeto. b) Horizontal: Traz informações das diferentes versões ou variações

dos requisitos ou outros artefatos em uma fase do ciclo de vida.

(20)

17

Tendo em vista o modelo ágil usado no desenvolvimento dos projetos, assim como a fonte dos trabalhos aqui utilizados, boa parte dos trabalhos pode usufruir apenas de rastreabilidade backwards , uma vez que os requisitos seriam identificados a partir dos artefatos, já que requisitos não são explicitamente documentados na maior parte dos casos; rastreabilidade pós-especificação, uma vez que temos acesso, primariamente, a atividades de desenvolvimento e essas atividades serão ligadas aos requisitos; e rastreabilidade vertical, presente no ciclo de vida do projeto.

Segundo (Pohl, 2010) a rastreabilidade pode ser apresentada de duas formas: Matrizes de rastreabilidade (Figura 3) e Grafos de rastreabilidade(Figura 4). Matrizes de rastreabilidade são definidas por linhas representando artefatos de origem e colunas representando artefatos de chegada. Se existir alguma relação entre esses artefatos a célula correspondente na matriz é demarcada. Várias relações podem ser representadas ao se usar palavras nas células, ao invés de uma simples marcação, porém em casos com múltiplos artefatos que não possuem relações a matrix pode se tornar grande, contendo um grande número de células vazias.

(21)

18

Figura 3. Matriz de Rastreabilidade. Fonte:

https://thinkthyme.com/project-management/what-is-a-traceability-matrix

Grafos de rastreabilidade tem seus artefatos demarcados por nós e possíveis relacionamentos entre esses nós marcados por arestas. Informações quanto às relações são descritas sobre as arestas. Essa visualização permite melhor orientar os requisitos e suas relações espacialmente, sendo a escolhida para nossa abordagem.

Figura 4: Grafo de Rastreabilidade. Fonte: Pohl, 2010

(22)

19

A rastreabilidade nos proporciona diversas vantagens, entre elas: análise de impacto de mudanças, identificação de propriedades desnecessárias do sistema, correção de defeitos, validação, reusabilidade, determinação de responsabilidade e previsão de custos e prazos. Apesar disso, criar e prover manutenção para a rastreabilidade de um projeto é tido como custoso e limitador, por vezes afetando o trabalho e produtividade do desenvolvedor, uma vez que se utiliza tempo e recurso na rastreabilidade e não no próprio sistema.

Dessa forma, abordagens que permitam a automatização de rastreabilidade em projetos seriam excelentes para o desenvolvimento de software, assim como sua manutenção, ajudando a prover tal rastreabilidade. Abordagens nessa direção já foram feitas em diversos campos, conforme veremos mais à frente nos trabalhos relacionados, porém ainda existem melhorias a serem feitas.

Levando em consideração o ambiente de desenvolvimento no qual nos encontramos (GitHub) e o contexto ágil, a documentação e o detalhamento de requisitos por vezes sequer é obtível. Uma vez que não podemos realizar uma identificação de artefatos presentes no sistema (como commits, issues, pull requests) a um determinado requisito do sistema ou seja, a definição padrão de rastreabilidade de requisitos não seria aplicável à abordagem aqui descrita.

Dessa forma, precisamos expandir o conceito de rastreabilidade de requisitos para abarcar uma maior gama de informações referente ao projeto. Definimos então a Rastreabilidade de Artefatos(RA), permitindo que

(23)

20 apliquemos técnicas e definições de rastreabilidade aos projetos encontrados no GitHub.

2.2 GitHub

O GitHub é um site para versionamento e desenvolvimento de código 1 colaborativo baseado sistema de controle de versão git, onde estão hospedados mais de 96 milhões de projetos de todo cunho: Desde trabalhos escolares até sistemas de código aberto, como o Linux.

A informação de código fica armazenada na forma de commits realizados pelo usuário, que informam quais arquivos foram adicionados ou alterados e como essa alteração ocorreu. Outros artefatos presentes no GitHub são erros ou problemas encontrados no projeto( issues ), diferentes versões de um projeto( branches ), informações de colaboração dos usuários associados ao projeto( users ), entre outros, totalizando mais de 2000 campos, segundo o levantamento feito no trabalho. Além disso, toda informação armazenada no GitHub pode ser acessada através de sua robusta API na forma de requisições, permitindo assim coletar e re-estruturar essa informação conforme for julgado necessário.

A escolha pelo GitHub foi realizada levando em consideração o número de projetos, sua popularidade e o poder de acesso concedido pela API. A forma de escolha e representação desses campos será discutida no próximo capítulo, ao detalharmos nossa abordagem no Capítulo 3.

2.3 Neo4j

(24)

21 O Neo4j é um banco de dados orientado a grafos desenvolvido 2 pela empresa Neo4j inc. Ele permite a construção de um banco de dados na forma de grafo, assim como a visualização de tal banco e diferentes consultas. A representação em grafos é composta por elementos, no caso de nossa abordagem, artefatos e ligações entre eles, representando seus relacionamentos, conforme mostrado na Figura 5.

Figura 5: Estrutura de grafo na plataforma Neo4j. Fonte:

https://Neo4j.com/developer/graph-database /

Seu código é open-source, escrito em Java e Scala, disponível no GitHub e no formato de uma aplicação desktop. Algumas particularidades do banco de dados são sua linguagem própria( Cypher ) similar ao SQL, mas otimizada para grafos. Essa linguagem é usada tanto na criação dos grafos a partir dos dados quanto na sua consulta, e um exemplo de grafo é exibido na Figura 6.

Outro ponto especial da ferramenta é sua flexibilidade na criação e

(25)

22 apresentação do modelo em grafo, permitindo a adição e alteração rápida de artefatos e relacionamentos. Graças a sua estrutura, o Neo4j cabe perfeitamente no desejado, provendo às informações coletadas na API do GitHub uma visualização dos artefatos e suas relações, além de permitir uma definição rápida e simples dos relacionamentos entre os artefatos definidos ao utilizar a abordagem de grafo no banco de dados estabelecido.

Figura 6: Exemplo de grafo produzido pelo Neo4j. Fonte:

https://Neo4j.com/graphgist/graph-of-the-free-agent-players-of-major-lea gue-baseball-2016

(26)

23

3 Abordagem Proposta

A abordagem criada realiza operações de consulta à API do GitHub, a fim de coletar dados sobre artefatos desejados e, a partir desses dados coletados, insere-os na infraestrutura provida pelo Neo4j de forma a evidenciar conexões entre os diversos artefatos disponibilizados pelo GitHub. Esses dados coletados são exibidos em formato de grafo utilizando-se do Neo4j. A consulta à API foi realizada utilizando-se python e produzindo os dados desejados na forma de um arquivo csv. Esse arquivo csv é então alimentado na ferramenta Neo4j. Todas as versões e tecnologias utilizadas estão presentes no Anexo A.

É a partir da interface disponibilizada pelo Neo4j que se torna possível navegar pelos diferentes artefatos e suas conexões, realizar consultas específicas, como por exemplo usuário com maior número de comentário em issues resolvidas ou data com maior número de commits. Buscamos a partir dessa abordagem facilitar a identificação de informações e suas conexões frente ao que é disponibilizado dentro do GitHub.

3.1 Foco e Público da abordagem

O foco da abordagem é o gerenciamento de projetos, a fim de identificar relações entre os artefatos gerados com a finalidade de facilitar a tomada de decisões e rápida resposta a problemas encontrados durante o desenvolvimento, assim como as diversas vantagens discutidas anteriormente com a adição de rastreabilidade ao projeto.

(27)

24 Assim, a abordagem tem como público principal gerentes de projeto, responsáveis por tomadas de decisão e o desenvolvimento do sistema. Em um nível menor, a abordagem também pode ser útil para desenvolvedores que busquem informação a respeito do sistema.

3.2 Desenvolvimento da abordagem

Para a coleta de dados, escolhemos a linguagem python, devido ao seu amplo número de bibliotecas, entre elas uma biblioteca para tratar da comunicação com o GitHub. Essa biblioteca mais tarde foi trocada por uma outra para consulta direta à api, uma vez que muitas das features disponibilizadas pela primeira não eram utilizadas e sua documentação não era clara, tendo poucos exemplos encontrados que nos auxiliassem a esclarecer quaisquer dúvidas.

A partir de então fizemos uma primeira versão de consulta à informação, utilizando commits como exemplo. Deles selecionamos seu código único(sha), o texto do commit(message), seu autor(author) e data de realização(date). Essa seleção produz então um arquivo .csv, alimentado no Neo4j para criação de um banco de dados que possui nós do tipo commit. A ligação entre esses nós foi feita através de um outro campo que apontava, dentro de cada commit, para outro commit através do código único(sha). Após analisar esse campo(parents) percebemos que ele apenas apontava para o commit anterior em ordem cronológica. Com a definição dos nós pudemos então criar o grafo para análise.

Uma vez que atestamos o funcionamento tanto da seleção de dados da API quanto sua criação no banco de dados do Neo4j, partimos para a seleção

(28)

25 de quais campos poderíamos utilizar. Essa seleção foi feita tomando-se todos os campos da API e análise e discussão.

3.2.1 Requisitos e Modelagem

Para a modelagem da abordagem utilizamos os pontos presentes no trabalho de (Trindade, 2018) para identificar requisitos desejados na ferramenta. Esses pontos são oriundos de entrevistas feitas com gerentes de projetos a fim de detectar suas necessidades e são apresentadas na Tabela 1.

(29)

26 A abordagem aqui proposta pode atingir plenamente os requisitos R6 , R8 , R9 e R10 , assim como propostos. Os requisitos, R2 , R3 , R5 foram contemplados em parte, limitados pelo detalhe de consulta, podendo não trazer a informação completa e, por fim, dentro da abordagem aqui discutida, os requisitos R1 , R4 e R7 não puderam ser atendidos.

R1 - Análise de impactos (entre os artefatos), que vão ser ocasionados pela alteração solicitada.

Essa visualização não é possível dentro da abordagem aqui realizada, uma vez que não ocorre a ligação direta entre um artefato e uma alteração realizada, pois os artefatos são relacionados através do usuário que o criou e alterações possuem nós próprios.

R2 - Histórico de alterações feitas em um artefato, com datas, motivos e versão do artefato.

Certos artefatos presentes no GitHub incluem data de criação, última mudança ou fechamento, como issues e commits. Apesar disso não é possível estruturar um histórico completo com esse conjunto limitado de funções, apenas detalhar sua última modificação e prover um link para a página do artefato, que possui maiores detalhes.

R3 - Stakeholder responsável por uma mudança no artefato.

Toda ação dentro de um repositório do GitHub está associada a um usuário. Dessa forma, qualquer que seja o artefato consultado, é possível associar um usuário a ele. Algumas consultas podem possuir informações reduzidas(Contendo apenas o login do usuário), caso o usuário não faça mais parte do repositório ou sua conta tenha sido deletada do site.

(30)

27 R4 - Análise dos stakeholders, que precisam ser informados de uma alteração solicitada.

Tal consulta não pôde ser atendida, uma vez que não é possível identificar diretamente stakeholders envolvidos em uma determinada alteração, a fim de informá-los da necessidade de uma alteração.

R5 - Análise de dependências entre artefatos produzidos.

Dentro dos artefatos selecionados a partir da API do GitHub, é possível identificar dependências entre todos eles. Essas dependências podem ser mais claras, como um link entre uma issue e um commit, ou indiretas, como qual usuário é responsável por um commit que ocasionou a issue. Para evidenciar essas dependências, utilizamos de múltiplas consultas ao banco de dados no Neo4j.

R6 - Análise das situações dos artefatos.

Varia de acordo com o artefato, por exemplo, artefatos "issues" possuem diferentes situações "open", "closed", etc. Artefatos como commits, não.

R7 - Avaliar cobertura de testes nos requisitos e código fonte.

Não é possível avaliar com a abordagem, uma vez que ela não identifica código de testes e quais métodos são cobertos por ele seja através de uma análise sintática ou outro método qualquer.

R8 - Análise do trabalho desenvolvido por um integrante da equipe.

É possível avaliar em conjunto com o site do GitHub, que possui um menu identificando quantidade de commits e código gerado no decorrer do tempo (presente na abordagem através de um link). Dentro do próprio site, na

(31)

28 página do projeto, essa informação se encontra na aba "insights". Além disso, a abordagem permite a identificação de outros elementos visuais que não são código como issues, pull requests e branches.

R9 - Análise de esforço de cada integrante da equipe por tempo.

É possível avaliar em conjunto com o site do GitHub, conforme dito acima. Essa avaliação por tempo é possível apenas no referente a quantidade de código produzida.

R10 - O que foi produzido em um dado período de tempo, com seus relacionamentos, tempo e responsáveis.

É possível realizar essa consulta, especificando a data como um parâmetro no código do Neo4j, ao realizar a consulta.

(32)

29

3.2.2 Construção da abordagem proposta

A sequência de passos para elaborar a abordagem está apresentada na Figura 7.

Figura 7: Diagrama de Atividades do Workflow do Trabalho

Para a criação da abordagem proposta, iniciamos analisando os requisitos levantados por Trindade (2018) através de entrevistas realizadas com gerentes e especialistas da área, a fim de identificar quais deles poderiam ser atendidos, tendo como base os dados disponibilizados pela API do GitHub (Passo 0). Esses requisitos estão enumerados no tópico anterior e foram a base para o passo seguinte.

Partimos então para a seleção dos elementos do GitHub (Passo 01), de acordo com os manuais de sua API . Criou-se uma lista de todos elementos 3

(33)

30 disponíveis para seleção, com mais de 2500 campos diferentes, havendo então uma redução dos elementos selecionados, caindo para cerca de 100 campos selecionados. Essa seleção se deu através do levantamento de todos os campos de informação disponibilizados pela API do GitHub em um glossário e a seleção minuciosa de cada um deles através de reuniões4 semanais, onde foi decidido quais artefatos são selecionados, quais atributos esses artefatos têm e quais relacionamentos estão presentes entre os artefatos.

Boa parte dos elementos que não foram selecionados diziam respeito à

features do sistemas não utilizadas, ou irrelevantes para o trabalho, como o uso de emoticons em comentários de commits, ou unidades de dados do GitHub, conhecidas como blobs . A lista de campos escolhidos e sua justificativa está presente na Tabela 2.

4

https://docs.google.com/document/d/1JRRtmavnM4hxNUch1YRHxEZ7EtsA9_Muw4bqt8c PFKE/edit?usp=sharing

(34)

31

Tabela 2: Campos selecionados a fim de atender requisitos levantados

Issues representam problemas ou eventualidades encontradas no projeto, como erros, bugs ou questões quanto à execução do programa e estão representadas na Figura 8. Junto às issues temos os subcampos Milestones, agrupando issues como uma finalidade ou objetivo a ser alcançado; comments, comentários associados a issues e labels, que categorizam issues em diferentes grupos.

Em função dos requisitos previamente levantados, issues atendem aos requisitos R2 através da página html associada, contendo um histórico da issue; R3 , pois estão sempre associadas a um usuário; R5 , devido a suas

(35)

32 associações a outros artefatos, R6 com um campo definindo se estão abertas, fechadas ou indisponíveis e R10 , através de sua data de criação.

Figura 8: Issues do projeto barra.govbr

Organizations representam grupos de usuários, responsáveis por repositórios, conforme apresentado na Figura 9. No GitHub, um repositório pode ser de uma organização ou de um único usuário. Organizações são subdivididas em teams , que tem acesso de leitura e escrita sobre um repositório. Informações sobre uma organização provê um insight sobre a estrutura dos usuários que gerenciam o código do projeto. Em função dos requisitos levantados, organizations provê informações a respeito dos integrantes do projeto, atendendo aos requisitos R3 e R8 .

(36)

33

Figura 9: Organization do projeto barra.govbr

Pull Request (Figura 10) permitem descrever mudanças adicionadas ao código em um branch específico do código. Além disso, ao se criar uma pull request é criada uma página para discussão da mudança, permitindo a adição de milestones que estão associadas a um pull request. Com relação aos requisitos levantados anteriormente, pull requests atendem aos requisitos R2 , possuindo uma página com histórico de mudanças e discussão a respeito do pull request; R3 , contendo informação do usuário que criou tal pull request; R6 , uma vez que pull requests possuem dois estados: aberto ou fechado; R8 , uma vez que acrescem ao trabalho realizado por um integrante da equipe; R9 e R10 , por poderem ser delimitadas pela data de criação e encerramento do pull request.

(37)

34

Figura 10: Pull requests do projeto barra.govbr

Repositories (Figura 11) contém toda informação referente ao repositório. Daqui extraímos detalhes sobre alterações de código na forma de commits, branches, que representam diferentes versões do projeto, collaborators, representando usuários que colaboram com os projetos e statistics, representando a contribuição de cada usuário ao código. Dessa forma, repository busca atender aos requisitos R2 , pelo commits atrelados ao repositório, R3 pelo usuário associado a um commit, R5 pelas relações entre commits, branches e usuários, R8 , R9 e R10 através da relação entre usuários e a criação de commits e branches. Temos ainda a presença de

deployments representando updates realizados diretamente onde o projeto está operante e hospedado e releases , que provêem o código operante diretamente aos usuários.

(38)

35 Figura 11: Nó repositório do projeto barra.govbr

User (Figura 12)representa cada usuário cadastrado no GitHub, com um login único que o identifica e permite associar a um usuário a criação qualquer artefato. Essencial para abarcar os requisitos envolvendo membros de desenvolvimento do projeto, como R8 , R9 e R10 .

Figura 12: Usuários contribuidores do projeto barra.govbr

(39)

36

Para cada um dos campos mencionados acima, foram selecionados um conjunto de atributos a fim de identificar e relacionar elementos uns com os outros, assim como outras informações julgadas úteis, como data de criação, texto descritivo e login de usuário, por exemplo.

Em seguida, definimos como cada informação recolhida de cada campo seria identificada no Neo4j. Para cada um dos casos acima, foram criados nós, com seus campos selecionados funcionando como atributos e conexões (arestas) entre nós, usando da linguagem própria do Neo4j, cypher . Uma vez definidos como nós, adicionamos para cada artefato os atributos selecionados aos nós e criamos a partir de atributos comuns entre nós, relações na forma de arestas.

3.3 Desenvolvimento, Dificuldades e Aprendizados

No decorrer do desenvolvimento da abordagem foram encontradas várias dificuldades. Abaixo encontra-se uma lista dessas dificuldades, organizada pela ordem na qual elas foram encontradas e solucionadas.

1. Leitura do arquivo JSON. Leitura detalhada da estrutura do arquivo, que é diferente quando se trata de repositórios, commits ou issues. Essa leitura foi realizada comparando o arquivo à estrutura de um dicionário, em python, onde temos vários pares: uma chave e um valor determinado.

2. Codificação e Decodificação de Caracteres. Como os projetos analisados eram projetos de código brasileiros, a decodificação unicode

(40)

37 presente no python não conseguia processar certos caracteres, como á,ã,ç, entre outros, gerando erros de compilação. Solucionamos tal problema ao definir a decodificação como utf-8, sobre-escrevendo a decodificação padrão, unicode.

3. Acessar todos os commits presentes em um repositório. Dado o esquema de paginação presente na resposta à consulta da API do GitHub, apenas um certo número de resultados é exibido por página de requisição. Dessa forma precisamos encontrar uma forma de percorrer todas as páginas que contenham os commits de um projeto. Isso foi solucionado usando os parâmetros 'page' e 'per_page' para navegar pelos resultados e aumentar a quantidade de resultados por página, respectivamente.

4. Escolha dos parâmetros disponibilizados pela api do GIT. Dado os dados disponibilizados pela api do GitHub, tivemos dificuldades em identificar quais campos seriam selecionados para nosso projeto e como as relações entre os artefatos encontrados seriam definidas. A solução para essa questão foi através da leitura de um glossário feito a partir de um refinamento da api.

(41)

38 5. Definição dos repositórios escolhidos. Os repositórios foram escolhidos a partir de repositórios do governo brasileiro (inserindo os termos 'gov br' criados a partir da data '2014-01-01') com resultado de 182 repositórios com falsos positivos, como repositórios do governo britânico, por conter 'British Goverment'. Removemos esses falsos positivos ao definir a tag 'gov br' presente no nome do próprio repositório, removendo assim o encontro da tag na descrição do repositório.

6. Limite a taxa de consultas a api. O GitHub permite apenas um limite de 60 consultas por hora a sua API, incrementamos esse limite através de uma autenticação utilizando tokens associados a cada requisição feita, preferível a autenticação por senha, que torna o usuário vulnerável e não permite descartar o método de autenticação, como o token.

7. Codificação do readme. A resposta da API do GitHub ao consultar o arquivo readme não produz o texto presente no readme, ao invés disso disponibilizando uma string codificada. Acessamos o conteúdo textual do readme utilizando uma outra chave presente, 'download_url' .

8. Arquivos vazios. Certos arquivos presentes da coleção de Tags para identificação encontram-se vazios. Definimos uma lista de erros de acesso e associamos a cada repositório, de modo a distinguir caso houvesse realmente um erro ou se aquele repositório não possuísse commit, tag ou readme

9. Acesso restrito a algumas informações. Por vezes, desejamos acessar certos repositórios para verificar a estrutura de certa resposta da api, mas tal resposta é protegida por autenticação do dono do repositório. Um exemplo disso é a lista dos colaboradores do repositório. Podemos

(42)

39 acessar diretamente adicionando o token de autenticação diretamente após o link de acesso. (?access_token=valor_token) Alternativas são o acesso com login e senha.(?client_id=xxxx&client_secret=yyyy)

10. Execução do Script Cypher automaticamente. A fim de evitar o repetitivo processo de criação de nós, aprendemos que é possível executar todo o script utilizando o comando 'cat rede.cypher | bin/cypher-shell -u Neo4j -p admin' no terminal.

(43)

40

4 Cenário de Uso

Uma vez definida a estrutura da abordagem e sua codificação, o cenário de uso fica definido como na Figura 13. Os passos são descritos em detalhes após a Figura.

Figura 13: Diagrama de Cenário de Uso

Inicia-se a execução da abordagem (Passo 0) com a definição de um 5 token de acesso, provido pelo GitHub, a fim de obter-se autorização ao acesso de informação do repositório e usuário ou organização que o

(44)

41 possuem. Caso não se execute este passo, certas informações privadas do repositório não podem ser acessadas, como por exemplo, usuários colaboradores do repositório.

Executa-se então a consulta à API do GitHub, uma vez autorizado, onde serão recolhidas as informações definidas no tópico anterior(Passo 1). Faz-se necessário então a execução de outro código, dessa vez na linguagem

cypher , própria do Neo4j a fim de termos o carregamento da informação contida em cada arquivo csv(Passo 2) como um nó com atributos na base de dados orientada a grafos. Uma vez definido os vértices do grafo e seus atributos, definimos as relações entre esses vértices, baseando-se em atributos comuns. Essas relações serão as arestas no grafo(Passo 3).

Tem-se então todo o grafo montado com as informações. Pode-se agora realizar uma consulta por certos elementos ou exibir todos os dados carregados(Passo 4). Considerando o tamanho de certos projetos e a incapacidade da abordagem de exibir grafos com elevado número de vértices devido a restrições de memória, recomenda-se a execução de consultas.

4.1 Descrição do Projeto

O projeto inicialmente escolhido como exemplo foi um projeto governamental brasileiro, com marcação por estrelas (indicando interesse) de mais de 10 usuários, com alterações no código no espaço de um mês da análise, demonstrando que o projeto estava ativo.

Assim, selecionamos o projeto da conta govbr, intitulado barra.govbr. O projeto trata-se da barra dinâmica visual do governo brasileiro, integrando

(45)

42 e padronizando sites do Governo Federal . O projeto conta com 396 commits, 6 24 issues, 6 colaboradores e não utiliza algumas features do GitHub, como releases e projects.

4.2 Descrição da execução da abordagem

Primeiramente executamos o código python para extração de informação através do uso da API do GitHub, produzindo os arquivos csv referente a cada nó definido. Conforme definimos na seção 3.3, a execução da abordagem se inicia com a execução do código, definindo o repositório a ser acessado e um token de acesso para a operação. Caso o token não seja definido, utilizamos um token padrão. Nesse caso, é possível que certas informações referentes ao repositório de caráter privado não possam ser acessadas, tal como usuários contribuidores, como exibido na Figura 14.

Figura 14: Execução do código para coleta de dados

Com estes passos executados, geramos os arquivos necessários para a criação dos nós e relacionamentos presentes no grafo (Figura 15),

(46)

43 necessitando agora carregá-los no Neo4j, conforme os passos 2 e 3 (Figura 16). Isso ocorre com a execução de um script cypher próprio do Neo4j. A Figura abaixo mostra a execução deste passo.

Figura 15: Arquivos gerados e trecho do arquivo de dados referente às issues

Figura 16: Criação dos nós e relacionamentos e trecho do código cypher

Por fim, resta apenas delimitar as consultas através de comandos no terminal do Neo4j, executado diretamente do Browser. Esse passo é extremamente importante em caso de um projeto de maior tamanho, a fim de prover melhor legibilidade ao usuário.

(47)

44

Figura 17: Representação em grafo do projeto barra.govbr

Uma vez gerada a visualização, é possível manipular e movimentar os nós, selecionar um nó para acessar seus atributos, mudar o tamanho dos nós e utilizar opções de zoom in e zoom out. Na Figura 17, por exemplo, podemos perceber a relação entre artefatos, usuários que os produziram

(48)

45 (através das arestas), suas ligações e situação do artefato (Através dos atributos dos nós).

Com relação ao passo 4, foram definidas diferentes consultas a serem realizadas. Essas consultas são definidas utilizando a linguagem cypher , própria do Neo4j. A primeira, representada na Figura 17, é definida como " match (n) return n " , buscando todos os nós e relacionamentos criados e exibindo todos simultaneamente. Em comparação, a visão original provida pelo github não expressa diretamente o tamanho do projeto, exibindo-o como uma lista (Figura 18).

Figura 18: Visão do projeto barra.govbr no site do GitHub

(49)

46 barra.govbr, essa consulta tende a ser menos legível conforme o tamanho dos projetos e o número de artefatos neles aumentam, uma vez que o grafo se torna mais denso e complexo, além do maior consumo de memória para um grande número de nós (a conFiguração inicial do neo4j limita esse número em mil unidades).

Procurando prover um grafo detalhado referente ao requisito R6 , podemos criar uma consulta a fim de restringir artefatos com determinado status, executando a consulta " match (n:issues),(r) where n.state = 'open' return (n)-[]-(r) " como é o caso de issues, como mostrado na Figura 19.

Figura 19: Issues com estado aberto

Já a visão presente no site do GitHub de issues em estado aberto se mantém como lista (Figura 20), mas não torna evidente os atributos de cada

(50)

47 issue, para isso torna-se necessário selecionar uma issue em específico e abrir sua página.

Figura 20: Issues abertas do projeto barra.govbr na visão do GitHub

Afim de se atender aos requisitos R8 e R9 podemos escolher um único usuário a fim de visualizar os artefatos criados por ele, através da consulta " match (n:Users_contributors),(m) where n.login='caduvieira' return (n)-[]-(m)" (Figura 21) .

No caso do próprio GitHub tal visualização não é possível. No lugar dela, podemos ver um gráfico específico do número de commits feitos por tempo ou selecionar o usuário e obter informações dos repositórios que ele faz parte. Essa visualização pode ser obtida seguindo a página html presente

(51)

48 como atributo do nó repositório.

Figura 21: Artefatos criados pelo usuário caduvieira

Outra consulta realizada busca atender ao requisito R10 , representada na Figura 22, e é descrita como " match (n),(m) where exists(n.created_at) or exists(n.author_date) and n.created_at<= ('2016-01-29T00:00:00Z') and (n.created_at >= '2015-01-29T00:00:00Z') or n.author_date<= ('2016-01-29T00:00:00Z') and (n.author_date >= '2015-01-29T00:00:00Z') return (n)-[]-(m)" .

(52)

49 de tempo. O GitHub não possui uma visão para artefatos dessa forma, ou seja, não é possível delimitar todos os artefatos produzidos em uma janela de tempo. No exemplo apresentado na Figura 22, retiramos os artefatos criados entre 2015 e 2016:

Figura 22: Consulta com tempo delimitado

(53)

50 produzidos pelo GitHub, assim como a estruturação do projeto de uma forma alternativa a visão em listagens oferecida pelo próprio GitHub.

Assim, um gerente ou líder de equipe terá uma alternativa de visualização, geral ou específica, dos atributos produzidos. Por fim, com essa automatização do processo de rastreabilidade, podemos reduzir os custos de documentação, ao mesmo tempo que provemos essas visualizações.

(54)

51

5 Trabalhos relacionados

Neste capítulo dedicamo-nos a explorar ferramentas ou abordagens que também procurem prover uma visualização aos dados presentes no GitHub. Realizamos então uma comparação com a abordagem aqui presente e ressaltamos seus pontos fortes e fracos com relação a abordagem aqui apresentada. Não conseguimos localizar uma outra ferramenta ou abordagem que também levasse em consideração a noção de rastreabilidade explicitamente e procurasse prover uma visualização dos links e artefatos presentes, simultaneamente.

Boa parte das ferramentas dedica-se unicamente a prover uma interface gráfica de usuário para representar dados do GitHub, mas não evidencia a relação entre diversos artefatos do projeto ou não procura criar uma visualização do relacionamento entre eles, optando ao invés disso, por prover informação sobre commits ou branches do projeto.

Selecionamos dois projetos mais próximos ao que procuramos realizar no trabalho, ambos representando dados do GitHub em formato de grafo, para sua seleção definimos projetos que utilizassem dados do GitHub, providenciassem uma visualização deles em formato de grafo.

5.1 GitHub Visualizer

GitHub visualizer (Figura 23) é uma aplicação web que permite a seleção de um usuário e um repositório e a representação dos commits desse

(55)

52 projeto e os usuários que a realizaram, criando uma animação demonstrando a evolução do projeto. Essa apresentação ocorre em três passos: a seleção de um usuário, a seleção de um repositório e a definição de parâmetros para visualização dinâmica.

São utilizadas a API do GitHub e a biblioteca D3, uma biblioteca do JavaScript para manipulação de documentos baseada em dados, além de Canvas e SVG, para visualização dinâmica em HTML5 e produção de gráficos interativos.

Figura 23: Uso do GitHub Visualizer aplicado ao projeto Barra.govbr. Fonte:

(56)

53

Com relação à abordagem aqui apresentada, o GitHub Visualizer demonstra características interessantes, como a animação da construção do projeto no decorrer do tempo, o que não é possível no nosso caso, em que apresentamos imagens do projeto em um dado momento. Outro ponto positivo é a identificação dos arquivos atualizados e adicionados, além das linguagens de programação presentes nos mesmos.

Apesar disso, essa é a única visualização presente na ferramenta, ignorando outros artefatos interessantes que podem prover informações do projeto, como issues e pull requests.

5.2 Gource

Gource (Figura 24) é um programa que permite a visualização7 do desenvolvimento de um sistema através de uma árvore de diretórios animada. Nele diretórios aparecem como galhos e arquivos como folhas. Desenvolvedores são identificados ao contribuírem no projeto e os arquivos contribuídos são destacados.

(57)

54

Figura 24: Primórdio do desenvolvimento do sistema operacional Linux.

Fonte: Gource

Comparativamente à abordagem aqui apresentada, ela possui vantagens e desvantagens similares a ferramenta anteriormente apresentada. Animações e identificação de arquivos tornam a visualização mais fluida, ao tratar-se do desenvolvimento do projeto, mas ignora outros artefatos presentes no GitHub, como issues e pull requests, perdendo detalhes do projeto que trazem informação diversa.

(58)

55

6 Considerações Finais

O trabalho de Trindade (2018) mostrou que a rastreabilidade em projetos ágeis é um desafio crescente. Isto motivou o presente trabalho cujo objetivo foi investigar potenciais rastros entre artefatos disponíveis em projetos do GitHub. Escolhemos o GitHub como foco deste trabalho por possuir diversos projetos e respectivos artefatos identificáveis e analisáveis. Inicialmente realizamos a seleção e discussão de quais artefatos do projeto seriam realmente úteis para um gerente de projeto - tomando como base o trabalho de Trindade (2018). Tendo realizado esse passo, investigamos então a visualização dos dados e como seus relacionamentos se dariam, levando em consideração os dados obtidos, utilizando um banco de dados em Grafo (i.e., Neo4j).

Definimos então uma abordagem que foi então comparada as duas alternativas, GitHub Visualizer e Gource, onde foi possível notar a maior riqueza de dados e informação na abordagem aqui apresentada, no lugar da alternativa animada e dedicada a arquivos presentes em ambas as outras alternativas.

6.1 Limitações e Ameaças

A abordagem aqui apresentada é limitada tanto pelas tecnologias escolhidas, quanto pela estrutura do projeto(Como dados incompletos ou não utilizados como esperado). Quanto ao GitHub, não é possível acessar todos os dados de um projeto sem a utilização de um token do administrador e a obtenção desse token não é intuitiva ao utilizador. Além disso muitas das

(59)

56 usadas erroneamente pelo usuário, levando a produção de dados confusos ou incompletos, como se deu no caso do projeto barra.govbr, em que contas deletadas do GitHub mas que contribuíram no projeto geraram artefatos sem relacionamentos.

Quanto ao Neo4j para projetos de maior tamanho, nossa abordagem é limitada tanto pelo custo em memória para a criação do alto número de nós, assim como a reduzida visibilidade, uma vez que os nós e suas interações começam a se sobrepor e formar uma imagem confusa.

Ao se tratar das ameaças temos alterações na API do GitHub, que já conta com um protótipo próprio para visualização, além outras alterações possíveis, que não puderam ser acompanhadas uma vez que o trabalho foi baseado no glossário feito e analisado, que não se mantém atualizado com a API.

6.2 Trabalhos futuros

Trabalhos futuros que merecem atenção incluem: (i) a validação da abordagem frente a gerentes de projeto - durante a validação da abordagem poderemos refinar as consultas utilizadas, podendo trazer assim mais informações úteis ao gerentes que utilizem a abordagem; (ii) avaliação da escalabilidade da abordagem aplicando a mesma projetos de maiores proporções; (iii) a criação de uma interface para o usuário e (iv) automatização do processo, de forma que não seja mais necessária a execução de cada passo tratado no cenário de uso, mas sim um único processo automático.

(60)

57

7 Referências

ANTONINO, P., et al. A Non-invasive Approach to Trace Architecture Design, Requirements Specification and Agile Artifacts . 2014 23rd Australian Software Engineering Conference, IEEE, 2014, p. 220–29.

GENVIGIR, E. C. (2009). Um modelo para rastreabilidade de requisitos de software baseado em generalização de elos e atributos. Instituto Nacional de Pesquisas Espaciais.

GOTEL, O. C.; FINKELSTEIN, C. W. (1994, April). An analysis of the requirements traceability problem . In Requirements Engineering, 1994., Proceedings of the First International Conference on (pp. 94-101). IEEE.

GOTEL, O. et al. Glossary of traceability terms (v1. 0) . Software and Systems Traceability, Springer, 2012, p. 413.

KALLIAMVAKOU, E. The Promises and Perils of Mining GitHub. Proceedings of the 11th Working Conference on Mining Software Repositories , p. 92-101,2014.

(61)

58 KANNENBERG, A.; SAIEDIAN, H. Why Software Requirements Traceabiity Remains a Challenge. CrossTalk The Journal of Defense Software Engineering , 2009.

POHL, Klaus. Requirements engineering: fundamentals, principles, and techniques . Heidelberg ; New York: Springer,p. 606-625, 2010,

TRINDADE, G.; LUCENA, M. Rastreabilidade de Requisitos em Metodologias Ágeis: um Estudo Exploratório. XII Brazilian Symposium on Information Systems , Florianópolis, SC, 2016.

TRINDADE, G. Requisitos para Ferramenta de Gerenciamento de Requisitos em Desenvolvimento Ágil a partir de um Estudo Exploratório. Tese (Graduação) - Universidade Federal do Rio Grande do Norte, 2015.

TRINDADE, G. Visualização da Rastreabilidade em Projetos Ágeis através de Dados contidos em Ferramentas de Apoio à Gerência de Projetos . Tese (Mestrado) - Universidade Federal do Rio Grande do Norte, 2018.

(62)

59

ANEXO A – Tecnologias e versão utilizada

Tecnologias necessárias: Python 2.7.12 8

Biblioteca Requests 9

Neo4j Community Edition 10

8_{https://www.python.org/downloads/release/python-2712/} 9_{http://docs.python-requests.org/en/master/user/install/#install} 10 https://neo4j.com/download-thanks/?edition=community&release=3.0.7&flavour=winstall6 4&_ga=1.216361168.738332568.1479756499