UM ESTUDO DE FERRAMENTAS DE
GERENCIAMENTO DE REQUISIÇÃO DE
MUDANÇA

VAGNER CLEMENTINO DOS SANTOS
UM ESTUDO DE FERRAMENTAS DE
GERENCIAMENTO DE REQUISIÇÃO DE
MUDANÇA
Dissertação apresentada ao Programa de
Pós-Graduação em Ciência da Computação
do Instituto de Ciências Exatas da Univer-
sidade Federal de Minas Gerais - Departa-
mento de Ciência da Computação como re-
quisito parcial para a obtenção do grau de
Mestre em Ciência da Computação.
Orientador: Rodolfo Sérgio Ferreira de Resende
Belo Horizonte
Outubro de 2017
c© 2017, Vagner Clementino dos Santos.
Todos os direitos reservados.
Santos, Vagner Clementino dos
S237e Um estudo de ferramentas de gerenciamento de
requisição de mudança / Vagner Clementino dos Santos.
— Belo Horizonte, 2017
xxii, 166 f. : il. ; 29cm
Dissertação (mestrado) — Universidade Federal de
Minas Gerais - Departamento de Ciência da
Computação
Orientador: Rodolfo Sérgio Ferreira de Resende
1. Computação — Teses. 2. Engenharia de Software.
3. Software – Manutenção. I. Orientador. II. Título.
CDU 519.6*32(043)


Dedico este trabalho à Deus, aos meus pais e familiares pela força e exemplo e ao
meu amor Andreza Vieira por nunca me deixar desistir.
vii

Agradecimentos
Agradeço ao meu orientador Rodolfo F. Resende pelos ensinamentos e paciência. A
sua sinceridade e esforço me fez uma pessoa e um mestrando melhor. Obrigado por
não desistir.
Aos professores do DCC/UFMG, em especial aos professores Marco Túlio e Edu-
ardo Figueiredo, que durante as disciplinas do mestrado me fizeram conhecer e gostar
cada vez mais da área de Engenharia de Software.
Aos funcionários da Secretaria do DCC/UFMG pelo suporte e atenção em todos
os momentos. Um agradecimento especial a Sônia Borges que sempre esteve disponível
para apontar os caminhos.
Aos colegas de trabalho da PRODABEL pelo suporte e força durante o mestrado.
Gostaria de agradecer em especial a Dinha e Clara que permitiram que eu cursasse o
mestrado. Um agradecimento ao Marcão (meu padrinho) que ajudou em diversas
etapas desta dissertação.
Ao meu amigo e revisor Tiago Henrique Campos cujas correções e apoio foram
fundamentais para que a dissertação fosse finalizada.
Vocês são os verdadeiros mestres!
ix

“O antigo inimigo cedeu o espaço
Pra um desafio ainda maior
Se manter de pé,
Contra o que vier,
Vencer os medos,
Mostrar ao que veio,
Ter o foco ali,
E sempre seguir
Rumo a vitória!”
(Vitória - Dead Fish)
xi

Resumo
Dentro do ciclo de vida de um produto de software o processo de manutenção tem papel
fundamental. Devido ao seu custo, em alguns casos chegando a 60% do montante inves-
tido [Kaur & Singh, 2015], as atividades relacionadas a manter e evoluir software têm
sua importância considerada tanto pela comunidade científica quanto pela indústria.
As manutenções em software podem ser divididas em Corretiva, Adaptativa, Per-
fectiva e Preventiva [Lientz & Swanson, 1980, IEEE, 1990]. A Manutenção Corretiva
lida com a reparação de falhas encontradas. A Adaptativa tem o seu foco na adequação
do software por conta de mudanças ocorridas no ambiente em que ele está inserido.
A Perfectiva trabalha para detectar e corrigir falhas latentes antes que elas se mani-
festem como tal. A Preventiva se preocupa com atividades que possibilitem aumento
da manutenibilidade do sistema. A ISO 14764 [ISO/IEC, 2006] propõe que exista um
elemento denominado Requisição de Mudança (RM) que corresponde a uma agrega-
ção de características que representam uma solicitação de manutenção de qualquer das
quatro categorias.
Por conta do volume das Requisições de Mudança é necessária a utilização de
ferramentas com o objetivo de gerenciá-las. Esse controle é geralmente realizado por
Sistemas de Controle de Demandas - Issue Tracking Systems, que auxiliam os desen-
volvedores na correção, de forma individual ou colaborativa, de defeitos (bugs), no
desenvolvimento de melhorias ou de novas funcionalidades. Não existe na literatura
uma nomenclatura comum para este tipo de ferramenta. Nesta dissertação utilizamos
o termo Ferramentas de Gerenciamento de Requisições de Mudança (FGRM) ao
referimos a este tipo de software.
Apesar da inegável importância das FGRMs, percebe-se um aparente desacopla-
mento deste tipo de ferramenta com as necessidades das diversas partes interessadas
(stakeholders) na manutenção e evolução de um software. Um sinal deste distan-
ciamento pode ser observado pelas diversas extensões (plugins) propostas na litera-
tura [Rocha et al., 2015, Thung et al., 2014b, Kononenko et al., 2014] e por estudos
que estão propondo melhorias para este tipo de software [Zimmermann et al., 2010,
xiii
Cavalcanti et al., 2014, Zimmermann et al., 2009]. Neste sentido, este trabalho de dis-
sertação se propõe a investigar e contribuir no entendimento de como as FGRMs estão
sendo melhoradas ou estendidas no contexto da transformação do processo de desenvol-
vimento e manutenção de software de um modelo tradicional para outro que incorpora
cada vez mais as práticas propostas pelos agilistas. O intuito é analisar como as FGRM
estão sendo modificadas com base na literatura da área ao mesmo tempo que conside-
ramos o ponto de vista dos profissionais envolvidos com Manutenção de Software.
Neste trabalho de dissertação realizamos um estudo exploratório com o objetivo
de entender as funcionalidade propostas na literatura e aquelas já existentes de modo a
melhorá-las. Foi realizado um Mapeamento Sistemático da Literatura a fim de avaliar
os trabalhos já existentes nesta área; também foi conduzido um estudo exploratório
na documentação de algumas ferramentas deste tipo de modo a caracterizá-las. Para
coletarmos o ponto de vista dos profissionais envolvidos em desenvolvimento e ma-
nutenção de software foi conduzido um Levantamento com questionário (survey) com
o objetivo de apurar como os respondentes avaliam as funcionalidades existentes e as
melhorias que possam ser realizadas neste tipo de software. Com base no conhecimento
adquirido foi proposto um conjunto de melhorias para este tipo de ferramenta que ti-
veram uma boa aceitação quando foram validades com profissionais que desenvolvem
FGRMs. Uma das recomendações propostas foi implementada como Prova de Conceito
e apresentou resultados satisfatórios.
Palavras-chave: Engenharia de Software, Manutenção de Software, Ferramentas de
Gerenciamento de Requisições de Mudança, Melhorias.
xiv
Lista de Figuras
1.1 Tipos de manutenção segundo a norma ISO/IEC 14764. Extraído
de [ISO/IEC, 2006] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Processo de Manutenção de Software adaptado da norma
IEEE 1219 [IEEE, 1999]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Processo de Manutenção de Software adaptado da norma
ISO/IEC 14764 [IEEE, 2006]. . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Modelo conceitual de uma Requisição de Mudança. . . . . . . . . . . . . . 15
2.4 Informações que compõem uma RM . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Um exemplo de uma RM do Projeto Eclipse . . . . . . . . . . . . . . . . . 18
2.6 Diagrama de estados de uma RM. Adaptado de [Tripathy & Naik, 2015] . 19
2.7 Um processo de modificação de uma RM utilizando uma FGRM. Extraído
de [Ihara et al., 2009] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Exemplo de documentação de uma funcionalidade do Bugzilla . . . . . . . 32
2.9 Exemplo de um cartão ordenado para uma funcionalidade da FGRM Bugzilla 33
2.10 Funções desempenhadas pelos participantes . . . . . . . . . . . . . . . . . 34
2.11 Modelo de funcionalidades básicas das FGRMs . . . . . . . . . . . . . . . . 36
3.1 Número de artigos incluídos durante o processo de seleção dos estudos.
Figura baseada em [Petersen et al., 2015] . . . . . . . . . . . . . . . . . . . 46
3.2 Esquema de classificação das melhorias propostas na literatura. Os re-
tângulos representam as dimensões de melhorias e os polígonos de cantos
arredondados representam tópicos de problemas do gerenciamento das RMs. 48
4.1 Ferramenta de coleta de dados da rede Stack Overflow . . . . . . . . . . . 68
4.2 Histórico de relatos de uma RM do projeto Python . . . . . . . . . . . . . 69
4.3 Sentenças utilizadas para seleção das discussões no Stack Overflow . . . . . 69
4.4 Funcionalidades que o participantes sentem falta. . . . . . . . . . . . . . . 74
xv
5.1 Lista de contribuidores do projeto Redmine . . . . . . . . . . . . . . . . . 90
5.2 Avaliação das Sugestões de Melhorias . . . . . . . . . . . . . . . . . . . . . 93
5.3 Avaliação sobre a implementação das sugestões propostas. . . . . . . . . . 95
6.1 Visão geral do funcionamento da extensão IssueQuality . . . . . . . . . . . 102
6.2 Comentário produzido pela extensão IssueQuality com os cabeçalhos e dicas
padrões. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3 Cópia de uma RM do projeto Guava para a sua ramificação. . . . . . . . . 107
6.4 Comentário para a RM do projeto Guava exibida na Figura 6.3 . . . . . . 107
6.5 Frequência de dicas por atributo analisados. . . . . . . . . . . . . . . . . . 108
xvi
Lista de Tabelas
1.1 Exemplos de ferramentas e serviços da Internet que podem ser classificados
como FGRMs. Extraído de [Cavalcanti et al., 2014] . . . . . . . . . . . . . 3
2.1 Ferramentas utilizadas no estudo . . . . . . . . . . . . . . . . . . . . . . . 35
2.2 Documentações utilizadas no processo de coleta de dados. . . . . . . . . . 35
2.3 Frequência de cada categoria de funcionalidade no conjunto de cartões obtidos. 37
3.1 Número de Estudos Recuperados por Base de Dados . . . . . . . . . . . . 46
3.2 Número de estudos primários por ano de publicação. . . . . . . . . . . . . 49
3.3 Lista de artigos de acordo com o esquema de classificação . . . . . . . . . . 50
3.4 Total de artigos por papel na manutenção de software . . . . . . . . . . . . 55
3.5 Lista de artigos de acordo com o papel suportado . . . . . . . . . . . . . . 56
4.1 Fontes de Amostragem utilizadas no estudo . . . . . . . . . . . . . . . . . 66
4.2 Função desempenhada pelos participantes . . . . . . . . . . . . . . . . . . 71
4.3 Localização Geográfica dos Participantes . . . . . . . . . . . . . . . . . . . 72
4.4 Tamanho da equipe dos participantes . . . . . . . . . . . . . . . . . . . . . 72
4.5 Probabilidade de Recomendação da Ferramenta Utilizada . . . . . . . . . . 73
4.6 Classificação das funcionalidades que possam dar suporte ao uso das práticas
dos agilistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.1 Projetos que os participantes contribuem. . . . . . . . . . . . . . . . . . . 92
5.2 Frequência e percentual das respostas sobre a relevância das sugestões de
melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3 Pesos utilizados para ordenar as sugestões propostas. . . . . . . . . . . . . 93
5.4 Ranking das sugestões propostas . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 Frequência e percentual das respostas sobre a dificuldade de implementação
das sugestões de melhoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6 Pesos utilizados no ranqueamento das sugestões de melhorias . . . . . . . . 94
xvii
5.7 Ordenamento das sugestões pelo grau de dificuldade. . . . . . . . . . . . . 96
6.1 Critérios de aceitação e forma de análise utilizados na análise de qualidade
do relato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2 Projetos utilizados no testes de execução da extensão. Os dados apresenta-
dos têm como referência 23/04/2017. . . . . . . . . . . . . . . . . . . . . . 106
6.3 Número de dicas retornadas pela extensão. . . . . . . . . . . . . . . . . . . 108
xviii
Sumário
Agradecimentos ix
Resumo xiii
Lista de Figuras xv
Lista de Tabelas xvii
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Visão Geral da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Contribuições do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 As FGRMs no Contexto da Manutenção de Software 9
2.1 A Manutenção de Software e a Requisição de Mudança . . . . . . . . . 10
2.1.1 Visão Geral da Manutenção de Software . . . . . . . . . . . . . 10
2.1.2 O Processo de Manutenção de Software . . . . . . . . . . . . . . 10
2.1.3 Papéis na Manutenção de Software . . . . . . . . . . . . . . . . 13
2.1.4 Requisição de Mudança . . . . . . . . . . . . . . . . . . . . . . 15
2.2 As Ferramentas de Gerenciamento de Requisições de Mudança (FGRM) 24
2.2.1 Modelo Conceitual do Contexto das FGRMs . . . . . . . . . . . 25
2.2.2 Extensões de Funcionalidades em FGRM . . . . . . . . . . . . . 26
2.3 Funcionalidades das FGRMs . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Objetivo do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . 28
xix
2.3.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.5 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.6 Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 Resumo do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Mapeamento Sistemático da Literatura 43
3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.1 Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2 Pesquisa da Literatura . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.3 Esquemas de Classificação . . . . . . . . . . . . . . . . . . . . . 46
3.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1 Classificação por Dimensões de Melhoria . . . . . . . . . . . . . 49
3.3.2 Suporte aos Papéis desempenhados na Manutenção de Software 54
3.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5 Limitações e Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . 59
3.6 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7 Resumo do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4 Levantamento de Funcionalidades de FGRMs 63
4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2 Objetivo do Levantamento com Profissionais . . . . . . . . . . . . . . . 64
4.3 Desenho e Método da Pesquisa com Profissionais . . . . . . . . . . . . 64
4.3.1 Conceitos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.2 Método de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.1 Perfil dos Participantes . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.2 Nível de Satisfação com as FGRM . . . . . . . . . . . . . . . . . 72
4.4.3 Avaliação das Funcionalidades Existentes . . . . . . . . . . . . . 73
4.4.4 Práticas Ágeis na Manutenção de Software . . . . . . . . . . . . 75
4.5 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.6 Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7 Resumo do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5 Sugestões de Melhorias para as FGRMs 79
5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Sugestões de Melhorias para FGRMs . . . . . . . . . . . . . . . . . . . 80
xx
5.2.1 Suporte à Qualidade do Texto Relatado . . . . . . . . . . . . . 81
5.2.2 Acesso Facilitado ao Código Fonte Incluído nas RMs . . . . . . 82
5.2.3 Ranqueamento pela Reputação do Reportador . . . . . . . . . . 82
5.2.4 Atalhos para filtros e classificação (rankings) das RMs . . . . . 83
5.2.5 Suporte a Processos de Integração Contínua . . . . . . . . . . . 84
5.2.6 Suporte ao Registro do Relato além de Texto Simples . . . . . . 85
5.2.7 Classificação Automática pela Urgência da RM . . . . . . . . . 86
5.2.8 Suporte à tarefas compartilhadas . . . . . . . . . . . . . . . . . 87
5.3 Avaliação das Melhorias Propostas . . . . . . . . . . . . . . . . . . . . 88
5.3.1 Seleção dos Participantes . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2 Desenho do Questionário . . . . . . . . . . . . . . . . . . . . . . 90
5.3.3 Processo de Aplicação . . . . . . . . . . . . . . . . . . . . . . . 91
5.4 Resultados da Avaliação das Sugestões de Melhorias . . . . . . . . . . . 91
5.4.1 Perfil dos Participantes . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.2 Relevância das Sugestões . . . . . . . . . . . . . . . . . . . . . . 92
5.4.3 Implementação das Sugestões . . . . . . . . . . . . . . . . . . . 94
5.5 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.6 Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.7 Resumo do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6 Implementação de uma Extensão para FGRM 99
6.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2 Qualidade do Relato de uma RM . . . . . . . . . . . . . . . . . . . . . 99
6.3 Extensão de Suporte à Qualidade do Relato . . . . . . . . . . . . . . . 100
6.3.1 Desenho da Extensão . . . . . . . . . . . . . . . . . . . . . . . . 101
6.4 Uso da Extensão em Projetos Reais . . . . . . . . . . . . . . . . . . . . 105
6.4.1 Seleção dos Projetos . . . . . . . . . . . . . . . . . . . . . . . . 106
6.4.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.5 Limitações e Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . 109
6.6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7 Conclusão 111
Referências Bibliográficas 115
Apêndice A Lista de Ferramenta de Gerenciamento de Requisição de
mudanças 131
xxi
Apêndice B Formulário Aplicado para Seleção das Ferramentas 133
Apêndice C Modelo da Mensagem Enviada no Levantamento para
Seleção das Ferramentas 143
Apêndice D Formulário dos Cartões Ordenados 145
Apêndice E Sentenças de Busca por Base de Dados 149
Apêndice F Modelo da Mensagem Enviada no Levantamento com
Profissionais 151
Apêndice G Lista de Projetos Avaliação Sugestões de Melhorias 153
Apêndice H Formulário Aplicado para Avaliação das Sugestões de Me-
lhorias 157
Apêndice I Modelo da Mensagem Enviada no Levantamento sobre as
Sugestões de Melhorias das Funcionalidades das FGRMs 165
xxii
Capítulo 1
Introdução
Dentro do ciclo de vida de um produto de software o processo de Manutenção tem papel
fundamental. Devido ao seu alto custo, que pode variar entre 60% e 90% do preço final
do sistema [Kaur & Singh, 2015], as atividades relacionadas com manter e evoluir têm
sua importância considerada tanto pela comunidade científica quanto pela indústria.
Uma vez que o software entra em operação, anomalias são descobertas, mudanças
ocorrem no ambiente de execução e o atendimento a novos requisitos é solicitado.
À frente caracterizamos o que denominamos como “Requisição de Mudança” (RM)
e o nosso interesse em um tipo de ferramenta que denominamos “Ferramentas de
Gerenciamento de Requisições de Mudanças” (FGRM). De uma maneira informal
uma RM representa uma solicitação de manutenção e a FGRM dá apoio às atividades
de gerência destas solicitações. Esta dissertação apresenta o estudo sobre FGRMs feito
no correspondente projeto de mestrado e apresenta contribuições sobre como melhorar
este tipo de software.
A Manutenção, dentre outros aspectos, corresponde ao processo de modificar um
componente ou sistema de software após a sua entrega com o objetivo de corrigir fa-
lhas, melhorar o desempenho ou adaptá-lo devido à mudanças ambientais [IEEE, 1990].
De maneira relacionada, Manutenibilidade é a propriedade de um sistema ou compo-
nente de software em relação ao grau de facilidade que ele pode ser corrigido, melho-
rado ou adaptado [IEEE, 1990]. As manutenções de software, conforme apresenta
a Figura 1.1, podem ser divididas em Corretiva, Adaptativa, Perfectiva e Preven-
tiva [Lientz & Swanson, 1980, IEEE, 1990]. A Manutenção Corretiva lida com a repa-
ração de falhas encontradas. A Adaptativa tem o seu foco na adequação do software por
conta de mudanças ocorridas no ambiente em que ele está inserido. A Perfectiva tra-
balha para detectar e corrigir falhas latentes antes que elas se manifestem como tal. A
Preventiva se preocupa com atividades que possibilitem aumento da manutenibilidade
1
2 Capítulo 1. Introdução
do sistema. A ISO 14764 [ISO/IEC, 2006] propõe que exista um elemento denominado
Requisição de Mudança (RM) que corresponde a uma agregação de características que
representam uma solicitação de manutenção de qualquer das quatro categorias. Nesta
dissertação adotamos a mesma terminologia com o mesmo significado.
Figura 1.1. Tipos de manutenção segundo a norma ISO/IEC 14764. Extraído
de [ISO/IEC, 2006]
Por conta do volume das RMs é importante a utilização de um software para
gerenciá-las. Esse controle é realizado pelas FGRMs que auxiliam a equipe de ma-
nutenção na correção, de forma individual ou colaborativa, de falhas (bugs) ou na
implementação de melhorias. Estas ferramentas podem ser utilizadas por gestores,
analistas de qualidade e usuários do sistema para atividades como gerenciamento de
projetos, comunicação, discussão e revisões de código. A literatura sobre Manutenção
de Software não define uma nomenclatura comum para este tipo de software. Em alguns
estudos são utilizados nomes como Sistema de Rastreio de Defeito - Bug Tracking Sys-
tems, Sistema de Gerenciamento de Requisição - Request Management System, sendo
bastante comum o termo Sistemas de Controle de Demandas - Issue Tracking Systems.
Todavia, de modo geral, o termo se refere às ferramentas utilizadas no gerenciamento
das Requisições de Mudança. Nesta dissertação utilizamos o termo Ferramentas de Ge-
renciamento de Requisições de Mudança (FGRM) ao referirmos a este tipo de software.
A Tabela 1.1 apresenta alguns exemplos de sistemas que podem ser classificados como
FGRMs. Também são listados serviços da Internet que oferecem funcionalidades exis-
tentes nas FGRMs na modalidade de Software como Serviço [Fox & Patterson, 2013].
1.1 Motivação
Diante da presença de software em todos os setores da sociedade existe um interesse
por parte da comunidade científica e da industria no desenvolvimento de processos,
1.1. Motivação 3
Ferramentas Serviços da Internet
Bugzilla https://www.bugzilla.org/ SourceForge https://sourceforge.net/
MantisBT https://www.mantisbt.org/ Lauchpad https://launchpad.net/
Trac https://trac.edgewall.org/ Code Plex https://www.codeplex.com/
Redmine www.redmine.org/ Google Code https://code.google.com/
Jira https://www.atlassian.com/software/jira GitHub https://github.com/
Tabela 1.1. Exemplos de ferramentas e serviços da Internet que podem ser
classificados como FGRMs. Extraído de [Cavalcanti et al., 2014]
técnicas e ferramentas que melhorem a relação custo/benefício de manter um soft-
ware. Dependendo do tamanho do projeto de software é necessário a utilização de uma
FGRM para gerenciar as suas requisições de mudança. Além disso, as diferentes partes
interessadas necessitam de um espaço único onde possam registrar as falhas encontra-
das e as melhorias que necessitam. Neste contexto, verificamos que as FGRMs fazem
parte de projetos de diferentes tipos e tamanhos, em empresas públicas e privadas (por
exemplo NASA e IBM) e de diversos projeto de código aberto (por exemplo Mozilla,
Eclipse, Apache); elas dão suporte a softwares de diferentes plataformas: computadores
de mesa, web ou dispositivos móveis.
A literatura mostra que uma FGRM desempenha um papel além do gerencia-
mento dos pedidos de manutenção de software. Avaliando o controle de demandas
como um processo social, Bertram e outros [Bertram et al., 2010] realizaram um es-
tudo qualitativo sobre FGRMs que eram utilizadas por equipes de pequeno porte. Os
resultados demonstraram que a ferramenta era utilizada não apenas como um banco
de dados de rastreamento de falhas, mas atuava como um ponto central para a co-
municação e coordenação das diversas partes interessadas dentro e fora da equipe de
manutenção. Os clientes, gerentes de projeto, analistas de qualidade e programadores
contribuíam em conjunto para o compartilhamento do conhecimento do projeto através
da FGRM utilizada.
No trabalho de Breu e outros [Breu et al., 2010] o foco foi analisar o papel das
FGRMs no suporte à colaboração entre desenvolvedores e usuários de um software.
Com base nos resultados foi possível verificar que o uso da ferramenta possibilitou que
os usuários desempenhassem um papel além de simplesmente reportar uma falha: a par-
ticipação ativa e permanente foi importante no progresso da solução das falhas que eles
descreveram. Um outro benefício das FGRMs é que as mudanças no software podem
ser rapidamente identificadas e reportadas para os desenvolvedores [Anvik et al., 2005].
Além disso, elas podem ajudar na estimativa do custo do software, na análise do im-
4 Capítulo 1. Introdução
pacto de uma modificação, no planejamento do projeto, na rastreabilidade de uma
falha e na extração de conhecimento [Cavalcanti et al., 2013].
Conforme exposto, as FGRMs desempenham um papel fundamental no contexto
do desenvolvimento e manutenção de software. Entretanto, no escopo de sua utili-
zação diversos desafios se apresentam: duplicação de RMs, pedidos de modificação
abertos inadvertidamente, grande volume de RMs que devem ser atribuídas aos desen-
volvedores, RMs descritas de forma incompleta [Cavalcanti et al., 2014]. Diante destes
problemas e desafios é importante entender como estas ferramentas estão sendo utiliza-
das e o que está sendo proposto na literatura sobre elas, de modo a avaliar e entender as
necessidades dos profissionais envolvidos com Manutenção de Software visando propor
melhorias paras as funcionalidades oferecidas pelas FGRMs.
1.2 Problema
O desenvolvimento e a manutenção de software envolvem diversos tipos de métodos,
técnicas e ferramentas. Em especial no processo de Manutenção, um importante as-
pecto são as diversas RMs que devem ser gerenciadas, cujo controle é realizado pelas
FGRMs. Apesar da inegável importância dessa ferramenta, percebe-se um aparente
desacoplamento de suas funcionalidades com as necessidades das diversas partes interes-
sadas na manutenção e evolução de software. A utilização de “demanda” como conceito
central para as FGRMs parece ser distante das necessidades práticas dos projetos de
software, especialmente no ponto de vista dos desenvolvedores [Baysal et al., 2013].
Um exemplo deste desacoplamento pode ser visto no trabalho proposto por Baysal
e Holme [Baysal & Holmes, 2012] no qual desenvolvedores que utilizam o Bugzilla1
relataram dificuldade em manter uma compreensão do escopo que as RMs atribuídas
para eles possuem. Segundo eles, seria importante que a ferramenta tivesse um suporte
melhorado para o conceito de Percepção Situacional - Situational Awareness. Em
síntese, eles gostariam de estar cientes da situação global do projeto bem como das
atividades que estavam sendo desempenhadas pelo demais desenvolvedores.
Existem outros problemas que são potencializados pela ausência de certas fun-
cionalidades nas FGRMs, por exemplo, a inclusão de RMs cuja descrição do erro ou
da melhoria é de baixa qualidade. Nesta situação os usuários terminam por serem
solicitados a inserir mais informação sobre as quais algumas das vezes não têm co-
nhecimento. Por outro lado, verifica-se uma frustração por parte dos desenvolvedores
1https://www.bugzilla.org
1.3. Objetivos 5
que não conseguem realizar o seu trabalho por conta da ausência da informação que
necessitam [Just et al., 2008].
Corroborando com a necessidade de evolução das FGRMs, o estudo realizado
por Zimmermann e outros [Zimmermann et al., 2009] propõe quatro dimensões de me-
lhorias para este tipo de software. Estas dimensões representam aperfeiçoamentos
centrados em aspectos tais como ferramenta, informação, processo e usuário. Eles são
melhor discutidos no Capítulo 3 onde foram utilizados na classificação de estudos no
Mapeamento Sistemático realizado.
Não encontramos um grande número de trabalhos que avaliam de forma sistemá-
tica as funcionalidades oferecidas pelas FGRMs, ao mesmo tempo que faça relação com
que vem sendo proposto na literatura sobre o assunto. Adicionalmente, os estudos sobre
melhorias das FGRMs não discutem a adoção de algumas das práticas propostas pelos
agilistas na Manutenção de Software [Soltan & Mostafa, 2014, Heeager & Rose, 2015].
É importante que as FGRMs evoluam para se adaptar a esta forma de trabalho. Um
outro fator que corrobora sobre a necessidade de melhorias das FGRMs são as diversas
extensões (plugins) propostas na literatura [Rocha et al., 2015, Thung et al., 2014b,
Kononenko et al., 2014].
1.3 Objetivos
Segundo o nosso entendimento existe um distanciamento entre as necessidades dos
profissionais envolvidos em Manutenção de Software e as funcionalidades oferecidas
pelas FGRMs. Por esta razão, este trabalho de dissertação investiga e contribui no
entendimento de como as FGRMs podem ser melhoradas ou estendidas no contexto
da transformação do processo de desenvolvimento e manutenção de software de um
modelo tradicional para outro que incorpora cada vez mais as práticas propostas pelos
agilistas. O intuito é analisar como as FGRMs estão sendo modificadas com base na
literatura da área em contraste com o ponto de vista dos profissionais envolvidos com
manutenção. Neste sentido, elaboramos um estudo sobre as FGRMs com os seguintes
objetivos:
(i) entender os requisitos e funcionalidades oferecidas por este tipo de ferramenta;
(ii) mapear as melhorias para as FGRMs que estão sendo propostas na literatura;
(iii) verificar como os profissionais avaliam as funcionalidades das ferramentas que têm
contato;
(iv) propor melhorias para as funcionalidades das FGRMs.
6 Capítulo 1. Introdução
1.4 Visão Geral da Dissertação
A fim de alcançarmos os objetivos descritos foi proposto um conjunto de melhorias para
as funcionalidades das FGRMs. As sugestões de aperfeiçoamento são apresentadas no
Capítulo 5 e foram baseadas no (i) mapeamento apresentado no Capítulo 3 e no ( ii)
levantamento com profissionais descrito no Capítulo 4. O Capítulo 5 além de sugerir
melhorias realizou um levantamento (survey) da percepção destas recomendações por
parte de profissionais de desenvolvimento de software.
Mediante o mapeamento sistemático obtivemos e avaliamos uma parte das me-
lhorias para as funcionalidades das FGRMs que estavam sendo propostas na literatura.
A partir do estudo foi possível propor dois esquemas de classificação: por dimensão de
melhoria e suporte ao papel desempenhado na manutenção de software. De maneira
similar, através da caracterização das funcionalidades de algumas FGRMs de código
aberto ou disponíveis comercialmente, identificamos o estado da prática deste tipo de
ferramenta.
Com base nestes dois estudos conduzimos uma pesquisa com profissionais em
que pedimos que avaliassem os requisitos funcionais e não funcionais que poderiam ser
utilizados para aperfeiçoar as FGRMs. O questionário também quis saber a opinião dos
profissionais sobre a relevância das propostas de melhorias existente na literatura em
sua rotina de trabalho. Fundamentado nos estudos descritos foi proposto um conjunto
de melhorias. Como prova de conceito e em função de restrições de tempo escolhemos
implementar apenas uma delas conforme descrito no Capítulo 6.
1.5 Metodologia de Pesquisa
A metodologia de pesquisa utilizada nesta dissertação é baseada em uma abordagem
multi-método [Hesse-Biber, 2010]. Este tipo de desenho combina dois ou mais métodos
quantitativos ou qualitativos em um único estudo. As etapas do trabalho, que compõem
a abordagem multi-método estão listadas a seguir:
(i) Mapeamento Sistemático da Literatura [Petersen et al., 2008]
(ii) Caracterização das funcionalidades das FGRMs
(iii) Levantamento (Survey) com desenvolvedores [Wohlin et al., 2012]
(iv) Proposição e avaliação de um conjunto de melhorias para as FGRMs
(v) Implementação, como Prova de Conceito, de uma extensão para determinada
FGRM
1.6. Contribuições do Estudo 7
1.6 Contribuições do Estudo
Este estudo sistematizou uma parte da literatura sobre melhorias das funcionalidades
das FGRMs ao mesmo tempo que avaliou com base na opinião de profissionais envol-
vidos com desenvolvimento e manutenção de software a relevância de tais alterações.
Além disso, foi proposto um conjunto de recomendações que podem contribuir com
a melhoria das funcionalidades disponibilizadas por este tipo de software. Uma das
recomendações foi implementada demonstrando a aplicabilidade do que foi apresen-
tado. Entendemos que uma FGRM que atenda as necessidades dos desenvolvedores
possa contribuir com o aperfeiçoamento das atividades relacionadas com manutenção
de software e na diminuição de custos. Neste sentido, entendemos que contribuímos
no avanço dos estudos sobre melhorias das FGRMs. Os resultados apresentados nesta
dissertação podem ser utilizados para o desenvolvimento de novas versões para este
tipo de software ou serem aplicados pela equipe de manutenção para otimizar a sua
rotina de trabalho.
1.7 Organização do Trabalho
Este trabalho de dissertação está organizado conforme descrito a seguir. No Capítulo 2
apresentamos e discutimos os principais conceitos utilizados nesta dissertação. Neste
mesmo capítulo é descrito um estudo em que coletamos as funcionalidades de um
conjunto de FGRMs que foram definidas como relevantes na visão de profissionais
consultados mediante um levantamento.
O Capítulo 3 descreve o mapeamento sistemático que trata de trabalhos sobre
melhorias nas funcionalidades das FGRMs. Os estudos foram classificados em 04 di-
mensões de melhorias e pelo papel desempenhado na Manutenção de Software que a
melhoria visa dar suporte. No Capítulo 4 reunimos a opinião de profissionais envolvidos
em Manutenção de Software sobre as funcionalidades oferecidas pelas FGRMs. Estes
profissionais exercem suas atividades em projetos de código aberto e empresas do setor
público e privado. Foi possível identificar que os participantes do levantamento, na
maior parte, estão satisfeitos com a ferramenta que utiliza, contudo, eles se mostram
interessados em novos tipos de funções para este tipo de software.
Tomando como base a literatura sobre melhorias nas FGRMs e os resultados
obtidos nos estudos descritos em capítulos anteriores, apresentamos e discutimos um
conjunto de recomendações para as funcionalidades das FGRMs no Capítulo 5. As
sugestões propostas foram avaliadas por profissionais que contribuem no desenvolvi-
mento deste tipo de ferramenta. Em geral, as recomendações tiveram boa aceitação
8 Capítulo 1. Introdução
com relação à sua necessidade e facilidade de implementação. O Capítulo 6 descreve
a implementação de uma das 8 sugestões propostas. O Capítulo 7 apresenta uma
discussão final e também apresenta algumas possibilidades de trabalhos futuros.
Capítulo 2
As FGRMs no Contexto da
Manutenção de Software
Os sistemas de software têm tendência de evoluir para atender aos requisitos e altera-
ções do ambiente no qual eles se inserem. Em uma série de estudos, Lehman propôs
leis sobre a evolução do software. A Lei da Mudança Contínua (Continuing Change)
afirma que um software em uso deve mudar ou se tornará progressivamente menos
útil [Lehman, 1980]. A Lei da Complexidade Crescente (Increasing complexity) afirma
que as mudanças realizadas em um sistema transforma sua estrutura cada vez mais
complexa. Neste contexto, recursos extras devem ser disponibilizados a fim de preser-
var e simplificar a estrutura do software [Lehman, 1980]. As leis de Lehman têm sido
validadas, especialmente aquelas relacionadas ao tamanho e complexidade do software.
Em um trabalho sobre o tema Yu e Mishra [Yu & Mishra, 2013] examinaram de forma
empírica as Leis de Lehman em relação à evolução da qualidade do software. O estudo
demonstrou que a qualidade declinará a menos que sejam realizadas modificações com
objetivo de melhoria da qualidade do produto.
Partindo da premissa de que mudanças em software são inevitáveis, torna-se
importante uma disciplina com foco no gerenciamento e controle das alterações. Em
geral, dentro do escopo da Engenharia de Software a tarefa fica a cargo da Manutenção
de Software. Nas próximas seções discutimos os conceitos básicos da Manutenção de
Software que foram utilizados nesta dissertação e sua relação com as FGRMs.
9
10 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
2.1 A Manutenção de Software e a Requisição de
Mudança
Nesta seção apresentamos os vários termos e conceitos relacionados à Manutenção de
Software e a relação destes termos com o conceito de Requisição de Mudança. Iniciamos
com uma visão geral da Manutenção de Software.
2.1.1 Visão Geral da Manutenção de Software
No Padrão IEEE 1219 [ISO/IEEE, 1998] a Manutenção de Software é definida como a
modificação de um produto de software após a sua entrega com o objetivo de corrigir
falhas, melhorar o desempenho ou outros atributos com a finalidade de adaptar o
sistema às modificações ambientais.
Posteriormente a IEEE/EIA 12207 - Padrão para o Processo de Ciclo de Vida
do Software [ISO/IEC/IEEE, 2008], retrata a manutenção como um dos principais
processos no ciclo de vida do software. No texto do padrão a disciplina corresponde às
atividades de modificação do código e da documentação associada em decorrência de
uma falha ou necessidade de melhoria no software [Society et al., 2014].
De maneira relacionada, Manutenibilidade é a propriedade de um sistema ou
componente de software em relação ao grau de facilidade que ele pode ser corrigido,
melhorado ou adaptado [IEEE, 1990]. A ISO/IEC 9126 - 01 [ISO/IEC, 2001] define a
Manutenibilidade como um atributo de qualidade do processo de Manutenção.
É possível verificar quemanter e evoluir são aspectos comuns das diferentes defini-
ções para Manutenção de Software. Embora exista o entendimento de que os processos
de manutenção e evolução possuem características distintas [Tripathy & Naik, 2015],
não está nos objetivos desta dissertação discutir e apresentar as diferenças. Neste
sentido, utilizamos os termos de forma intercambiáveis.
2.1.2 O Processo de Manutenção de Software
O Processo de Manutenção de Software é caracterizado pelo conjunto de atividades,
métodos, práticas e transformações utilizadas para desenvolver ou manter um software
e seus artefatos associados [Paulk et al., 1993]. Existe na literatura alguns modelos
para o processo de manutenção de software, especialmente baseados em uma visão
“tradicional”, no sentido de que desenvolvimento e a manutenção de software possuem
uma separação clara. Contudo, no momento do desenvolvimento desta dissertação,
existia uma tendência cada vez maior da adoção das práticas propostas pelos agilistas
2.1. A Manutenção de Software e a Requisição de Mudança 11
na manutenção de software. Segundo o nosso entendimento, essa inclinação surge da
demanda por serviços de manutenção de rápido retorno para o usuário.
2.1.2.1 Manutenção de Software Tradicional
Nesta seção apresentamos e discutimos alguns modelos para o processo de manuten-
ção, que segundo o nosso entendimento, são os principais disponíveis na literatura. No
contexto desta dissertação estes modelos são descritos como tradicionais. Em resumo,
um processo de manutenção de software descreve as atividades e suas respectivas en-
tradas e saídas. Alguns modelos são descritos nos padrões IEEE 1219 [IEEE, 1999] e
ISO/IEC 14764 [IEEE, 2006]. O processo especificado no padrão IEEE 1219 prescreve
que as atividades de manutenção de software devem ser iniciadas após a entrega do pro-
duto de software. O padrão também discute aspectos de planejamento da manutenção.
As atividades que compõem o processo são apresentadas na Figura 2.1.
Figura 2.1. Processo de Manutenção de Software adaptado da norma
IEEE 1219 [IEEE, 1999].
De maneira relacionada, na ISO/IEC 14764 as atividades que compõem o processo
são similares àquelas propostas na IEEE 1219, exceto pelo fato que elas são agregadas
de uma forma diferente. O processo descrito na ISO/IEC 14764 é exibido na Figura 2.2.
12 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
Figura 2.2. Processo de Manutenção de Software adaptado da norma
ISO/IEC 14764 [IEEE, 2006].
As atividades de manutenção propostas na ISO/IEC 14764 são detalhadas nas
tarefas descritas a seguir:
• Implementação do Processo
• Análise do Problema e da Modificação
• Implementação da Modificação
• Revisão ou aceitação da Manutenção
• Migração
• Aposentadoria do Software
2.1. A Manutenção de Software e a Requisição de Mudança 13
É possível notar que algumas atividades realizadas durante a manutenção são
similares a outras presentes no desenvolvimento de software, como por exemplo, aná-
lise de desempenho, codificação, teste e documentação. Outra atividade comum é o
gerenciamento dos requisitos. Nas duas situações recomenda-se aos profissionais res-
ponsáveis por controlar os requisitos atualizar a documentação por conta de alterações
ocorridas no código fonte.
2.1.2.2 Manutenção de Software na Perspectiva dos Agilistas
A maior parte da literatura em Manutenção de Software trata de técnicas e meto-
dologias tradicionais da Engenharia de Software. Todavia, verifica-se a tendência de
que os departamentos dedicados à Manutenção de Software se mostrem interessados
nas metodologias propostas pelos agilistas [Heeager & Rose, 2015]. No momento da
elaboração desta dissertação boa parte dos textos de Engenharia de Software tratam
desenvolvimento e manutenção como atividades com natureza distintas. Todavia, algu-
mas “práticas ágeis” podem ser utilizadas em tarefas de manutenção tais como processo
de trabalho iterativo, um maior envolvimento do cliente, a comunicação face a face e
os testes frequentes.
A adoção das práticas dos agilistas na manutenção de software pode apresentar
algumas dificuldades [Svensson & Host, 2005a]. Dentre elas está a adequação das prá-
ticas da organização com as necessidades da equipe de desenvolvimento. Por outro
lado, a adoção de um modelo de manutenção de software usando práticas da Progra-
mação Extrema (Extreme Programming - XP) apresentou como resultados a melhoria
do aprendizado e produtividade da equipe e aumento no encorajamento e confiança
entre os desenvolvedores [Choudhari & Suman, 2014].
2.1.3 Papéis na Manutenção de Software
As ações realizadas durante a manutenção de um software podem ser desempenhadas
por uma ou mais pessoas. Os nomes e as atividades desenvolvidas por cada um pode
variar, contudo, é possível determinar uma classificação que agregue pontos comuns
entre os diferentes papéis. Nesta dissertação, utilizamos a classificação proposta por
Polo e outros [Polo et al., 1999b] cujo objetivo é definir uma estrutura da equipe de
manutenção através da identificação de papéis responsáveis por cada tarefa. O conjunto
de papéis é o resultado da aplicação da metodologia MANTEMA [Polo et al., 1999a] em
projetos de software bancários espanhóis em que o setor de manutenção foi terceirizado
(outsourcing). Os autores reforçam que apesar da classificação ter sido criada em um
contexto específico, ela pode ser generalizada e utilizada em outras situações.
14 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
Para esta dissertação removemos os papéis que segundo o nosso entendimento
estavam mais vinculados a um contexto de manutenção terceirizada. Além disso, divi-
dimos o papel “equipe de manutenção’ (maintenance team) em Desenvolvedor, Analista
de Qualidade e Atribuidor por percebermos que decompõem a equipe de forma ade-
quada aos processos de manutenção existentes.
Usuário Afetado: Indivíduo que utiliza o software correspondente à Requisição de
Mudanças (RM) que será relatada. O defeito, a melhoria ou evolução no software,
representada pela RM, estão relacionadas com os desejos e necessidades deste papel.
Reportador: Responsável por registrar a RM. Em certas situações este papel é de-
sempenhado tanto pelo usuário do sistema quanto pela equipe de manutenção.
Gerente de Requisição de Mudança (Maintenance-request manager): Respon-
sável por decidir se uma RM será aceita ou rejeitada. Além disso, ele define qual
tipo de manutenção deverá ser aplicada. Posteriormente a RM é encaminhada para o
Escalonador.
Escalonador (Scheduler) : Deve planejar a fila das RMs que foram aceitas, ou seja,
planeja a ordem de atendimento das RMs que tenham sido aprovadas pelo Gerente de
Requisição de Mudança.
Atribuidor: Deve atribuir a solução de RMs aos desenvolvedores, ou seja, considerar
o planejamento de RMs feito pelo Escalonador e determinar os desenvolvedores que
elaborarão as soluções.
Desenvolvedor: Responsável por realizar as ações que irão solucionar a RM.
Analista de Qualidade: Tem por responsabilidade avaliar se uma RM solucionada
por um Desenvolvedor foi resolvida de forma correta e dentro dos padrões de qualidade
exigidos pelo projeto.
Chefe da Manutenção (Head of Maintenance): Este papel é responsável por
definir os padrões e procedimentos que compõem o processo de manutenção que será
utilizado.
2.1. A Manutenção de Software e a Requisição de Mudança 15
Apesar da classificação de papéis derivar de um contexto específico (setor bancário
e empresas com a área de manutenção terceirizada), ela é capaz de acoplar com alguns
tipos de modelos de processo de manutenção existentes na literatura.
Cabe ressaltar que está fora do escopo deste estudo elaborar uma classificação
dos papeis envolvidos na Manutenção de Software em função de supormos que isto
corresponde a um esforço bem extenso. Nossa ação é identificar alguns dos papeis e
quais são eles, sem com isso, nos envolvermos em uma consolidação definitiva.
2.1.4 Requisição de Mudança
2.1.4.1 Conceitos Básicos
Uma Requisição de Mudança (RM) corresponde ao registro da informação sobre o de-
feito, evolução ou melhoria de um sistema [Tripathy & Naik, 2015]. De maneira geral,
uma RM pode ser especializada como o Pedido de Correção de uma falha ou o Pedido
de Melhoria que pode estar relacionado com o aprimoramento de funcionalidades ou
com a melhoria da qualidade do sistema. Esta visão é apresentada na Figura 2.3. Al-
guns autores utilizam os termos relato de defeito ou relato de melhoria como sinônimos
para a RM. Todavia, no escopo desta dissertação, o relato é um atributo da RM que
representa o texto que descreve uma falha ou pedido de melhoria (vide Figura 2.4).
Requisição de Mudanças
Pedido de Correção Pedido de Melhoria
Figura 2.3. Modelo conceitual de uma Requisição de Mudança.
As principais características que compõem uma RM podem ser visualizadas no
modelo exibido na Figura 2.4. Trata-se de uma adaptação do que foi proposto no
trabalho de Singh e Chaturvedi [Singh & Chaturvedi, 2011] que descreve um processo
genérico de como uma RM é relatada.
Os principais elementos envolvidos no modelo estão detalhados a seguir:
Identificador: Sequência de caracteres, geralmente numérica, que permite distinguir
de maneira única uma RM.
16 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
Requisição de Mudança
 identificador
 sumario
 relato
 situacao
 criado Por
 atribuido Para
Anexo Comentario
Figura 2.4. Informações que compõem uma RM
Sumário: Um título ou resumo da RM.
Relato: Descrição detalhada da RM incluindo “o que”, “onde”, “por quê”, “como” e
“quando” a situação relatada ocorreu. A mensagem que aparece durante a ope-
ração do sistema pode ser incluída, bem como a entrada inserida e/ou a saída
esperada.
Situação: A situação atual de uma RM. Representa os diversos estados que uma RM
possui em seu ciclo de vida. Nesta dissertação discutimos brevemente o ciclo de
vida de uma RM na Subseção 2.1.4.2.
Criado Por: Nome da pessoa ou um identificador previamente registrado no sistema
de quem criou a RM.
Atribuído Para: A RM pode ser atribuída a uma pessoa específica caso ela seja
capaz de resolvê-la, caso contrário, a RM será atribuída para alguém que possui o
papel de definir o desenvolvedor mais apto para solucioná-la. Nesta dissertação, o
membro de uma equipe de manutenção com esta função é denominado Atribuidor.
Anexo: Refere-se à informação em formato diferente de texto e que pode ser incluída
na RM. Por exemplo, casos de teste, capturas de tela, e cadeia de registros de
ativação (stack trace).
Comentário: Registra o histórico de discussões realizadas durante o processo de so-
lução da RM1.
1O conceito de solução bem como de outros relacionados ao ciclo de vida de uma RM estão
descritos com maiores detalhes na Seção 2.1.4.2
2.1. A Manutenção de Software e a Requisição de Mudança 17
Conforme pode ser observado na Figura 2.4 os atributos Comentário e Anexo
foram modelados como uma agregação, dando aos mesmos um caráter multivalorado.
Esta escolha foi intencional para salientar que uma RM pode conter diversos anexos ou
comentários. No caso dos comentários esta característica é ainda mais relevante tendo
em vista que eles são realizados durante o processo de solução de uma RM. A partir do
conjunto de comentários é possível coletar informações relevantes para a manutenção
do software e que podem ser utilizadas para solucionar futuras RMs.
Os atributos que compõem uma RM podem variar dependendo de fatores como
a ferramenta utilizada para o gerenciamento, o projeto e a equipe de manutenção.
Esses campos fornecem uma variedade de metadados descritivos tais como importância,
prioridade, gravidade, componente, e produto [Zhang et al., 2016]. Em alguns casos a
RM pode conter um campo de modo a relacioná-la com outra já existente na base de
dados. Este tipo de vínculo é importante para minimizar problemas da gestão das RMs,
como por exemplo, a duplicação discutida na Subseção 2.1.4.3. A Figura 2.5 exibe um
exemplo de uma RM contendo os elementos básicos descritos no modelo proposto na
Figura 2.4.
Em síntese, apesar das diferentes nomenclaturas existentes na literatura (de-
manda, bug, defeito, bilhete, tíquete, requisição de modificação, solicitação de mo-
dificação, relato de problema) uma Requisição de Mudança representa uma descrição,
independente da estrutura, que visa gerar a manutenção ou evolução do software. A
manutenção ou evolução estão relacionados com o reparo de uma falha ou com um
desejo ou necessidade do usuário do software. Nesta dissertação procuramos ficar ade-
rentes ao termo “Requisição de Mudança” e sua sigla RM.
2.1.4.2 Ciclo de Vida de uma Requisição de Mudança
Uma RM descreve os desejos e necessidades dos usuários de como um sistema deve
operar. Quando uma RM é relatada pelo menos dois fatores devem ser levados em
conta [Tripathy & Naik, 2015]:
• Corretude da RM: uma RM deve ser descrita de forma não ambígua tal que seja
fácil revisá-la afim de determinar sua corretude. O “formulário”, que corresponde
aos campos que devem ser preenchidos na RM, é a chave para efetiva intera-
ção entre desenvolvedores e usuários. O formulário, neste sentido, documenta
informações essenciais sobre mudanças no software, hardware e documentação.
• Comunicação clara das RMs para as partes interessadas2: as RMs necessitam ser
2Na Seção 2.1.3 discutimos em maior detalhe as diferentes partes interessadas no contexto da
18 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
Figura 2.5. Um exemplo de uma RM do Projeto Eclipse
claramente comunicadas para as partes interessadas. O resultado de avaliar de
maneira distinta uma RM pode ser contra-produtivo: (i) a equipe que realiza
mudanças no sistema e a equipe que executa testes podem ter visões contraditó-
rias sobre a qualidade do software; (ii) O sistema alterado pode não atender às
necessidades e desejos dos usuários finais.
No caminho entre sua criação e solução uma RM possui diferentes estágios. O
ciclo de vida de uma RM é ilustrado através do diagrama de estados da Figura 2.6.
Nele uma RM inicia como Submetida (Submit) e vai sendo modificada até alcançar o
estado Fechada (Closed), em que é considerada como solucionada. Neste caminho o
manutenção de software.
2.1. A Manutenção de Software e a Requisição de Mudança 19
conjunto de fatores que resultou na necessidade de relatar a RM pode não mais existir.
Neste caso, ela é alterada para o estado Rejeitada (Decline).
Existe um aspecto importante do ciclo de vida de uma RM não abordado na
discussão apresentada por Tripathy e Naik. Em teoria uma RM poderia ter novos
estados: “Reaberta”, quando um usuário ou outro membro da equipe de manutenção
entende que ela não foi solucionada; “Relacionada”, quando uma nova RM é na realidade
uma sucessora ou possui algum tipo de relação com outra RM anteriormente registrada.
Figura 2.6. Diagrama de estados de uma RM. Adaptado
de [Tripathy & Naik, 2015]
A seguir apresentamos as características dos estados do ciclo de vida de uma
RM [Tripathy & Naik, 2015]. Para cada estado pode haver mais de um papel responsá-
vel pelas ações executadas. Também pode ocorrer que uma mesma pessoa desempenhe
diferentes papéis neste processo, conforme discutido na Seção 2.1.3.
Submetida (Submit): Este é o estado inicial de uma RM criada. Geralmente são
os usuários do sistema a fonte primária das RMs nesta situação. Com base no nível de
prioridade, ela é movida de Submetida para Em Revisão. Normalmente cabe ao Gerente
de Requisição de Mudança a responsabilidade da manipulação inicial das RMs. Neste
instante ele se torna o “dono” das mesmas.
Em Revisão (Review): Normalmente, cabe ao Gerente de Requisição de Mudanças
manipular as RMs no estado Em Revisão através das seguintes atividades:
20 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
• Verificar se a RM submetida recentemente é idêntica a outra já existente. Se ela é
identificada como duplicada o estado da mesma é alterado para Rejeitada. Neste
caso, uma breve explicação e algum tipo de ligação para a original são inseridos
nos comentários da RM.
• Aceitar o nível de prioridade atribuído para a RM ou alterá-lo.
• Determinar o nível de severidade da RM: normal ou crítico.
Caso as atividades descritas anteriormente não possam ser realizadas, a RM é
movida para o estado Em análise.
Em Análise (Analysis): Neste estágio uma análise de impacto é conduzida para
entender o que foi solicitado na RM e estimar o tempo necessário para implementá-
la. Caso não seja possível ou desejável atendê-la a situação é alterada para Rejeitada.
Caso contrário, a RM é movida para estado Compromissada (Commit). No estado Em
Análise o responsável pela RM é o Gerente de Requisição de Mudança.
Compromissada (Commit): A RM no estado Compromissada não foi atendida, mas
se encontra no planejamento do projeto de modo a estar em uma próxima versão do
produto. As RMs neste estado são responsabilidade de um Gerente de Requisição
de Mudança. Algumas RMs podem ser incluídas em futuras versões do sistema após
acordo com as demais partes interessadas.
Em Implementação (Implement): No estágio de Em Implementação diferentes ce-
nários podem ocorrer:
• A RM pode ser rejeitada caso sua implementação não seja factível.
• Caso a RM seja possível de implementar, os desenvolvedores realizam a codifi-
cação e os testes. Após o desenvolvimento ser finalizado a RM é movida de Em
Implementação para Em verificação.
Em Verificação (Verification): No estado de verificação as atividades são controla-
das pelo Analista de Qualidade. Dentre os métodos de verificação temos demonstrações,
análises, inspeções e testes.
2.1. A Manutenção de Software e a Requisição de Mudança 21
Fechada (Closed): Após a verificação de que a RM foi atendida, ela é movida de
Em verificação para Fechada. Esta ação é realizada pelo Analista de Qualidade que é o
“proprietário” da RM durante o estado de Em Verificação. Nesta dissertação, quando
referenciamos ao último estágio do ciclo de vida da RM, utilizaremos o termo “Solução
da RM” para representar a situação em que a falha relatada ou a melhoria solicitada é
entendida, por algum membro das partes interessadas, como atendida.
Rejeitada (Decline): Uma RM pode ser rejeitada caso ela seja considerada sem
impacto relevante no sistema, não seja possível tecnicamente realizar o que foi solicitado
na RM ou a equipe de qualidade conclui que as mudanças no software para atender à
RM não podem ser satisfatoriamente verificadas.
O modelo de ciclo de vida discutido por Tripathy e Naik possui foco em orga-
nizações que possuem uma área exclusivamente dedicada à manutenção de software.
Em outros contextos, como por exemplo em projetos de código aberto, o processo de
modificação dos estados de uma RM pode ser diferente. No trabalho de Ihara e ou-
tros [Ihara et al., 2009] foi conduzido um estudo de caso nos projetos Firefox e Apache
e um dos resultados foi o diagrama apresentado na Figura 2.7 que representa o processo
de modificação de uma RM.
Figura 2.7. Um processo de modificação de uma RM utilizando uma FGRM.
Extraído de [Ihara et al., 2009]
Os autores ponderam que apesar de haver diferentes estados e transições em
diferentes projetos, o diagrama é capaz de representar de maneira geral o processo de
transição de uma RM. O processo é composto de três fases diferentes: não tratada
(untreated), modificação (modification) e verificação (verification).
A fase não tratada foca em um subprocesso em que as RMs são relatadas, todavia,
não foram aceitas ou atribuídas a algum membro da equipe. A fase de modificação é um
subprocesso em que as RMs são efetivamente modificadas. Nesta fase uma RM é aceita
e posteriormente atribuída a algum desenvolvedor. Caso o pedido da RM não possa ser
atendido ela é rejeitada. A fase de verificação é o subprocesso em que membros com
a responsabilidade de garantia da qualidade verificam se as RMs modificadas foram
22 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
efetivamente solucionadas. Caso uma RM modificada por um desenvolvedor não seja
verificada, ela poderia não ser reconhecida como fechada (closed).
É possível relacionar o modelo descrito por Tripathy e Naik e aquele proposto
por Ihara e outros. Em ambos é possível identificar fases em que uma RM é relatada,
analisada e verificada. Além disso, os modelos discriminam situações em que o pedido
descrito na RM não é capaz de ser realizado. Nesta dissertação utilizamos de forma
geral o modelo proposto por Ihara e outros.
2.1.4.3 Problemas e Desafios do Gerenciamento das RMs
A seguir discutimos alguns dos problemas e desafios do gerenciamento de RMs discu-
tidos na literatura.
Localização do Problema: A tarefa de encontrar a origem de uma falha de software
em boa parte das vezes é complexa e consome muito tempo. O estudo de Thung e
outros afirma que na faixa de 84 a 93% de problemas em software afetam entre 1 e
2 arquivos de código-fonte [Thung et al., 2012a]. Apesar da pequena quantidade de
arquivos afetados, identificar em quais deles o problema reside (buggy files) é uma
tarefa árdua [Thung et al., 2014b].
Os pesquisadores vêm propondo abordagens baseadas em Recuperação da Infor-
mação para localizar o arquivo que contém uma falha com base no texto do relato
de uma RM. Nesse tipo de abordagem existe a tentativa de encontrar um elo en-
tre o texto do relato e os arquivos que podem estar relacionados com a solução do
problema [Wong et al., 2014].
Dificuldade na Visualização das Informações das RMs: Uma tomada de decisão
deve ser subsidiada por informações corretas. Este fato não é diferente na manu-
tenção e desenvolvimento de software. Pouco se sabe sobre o comportamento evo-
lutivo, o tempo de vida, distribuição e estabilidade dos problemas reportados nas
FGRMs [Hora et al., 2012]. Este problema é reforçado pela forma como as FGRMs
armazenam os dados das RMs. Em geral, essas ferramentas exibem informações sobre
as RMs de forma textual, o que não é apenas complicado para navegar, mas também
dificulta a compreensão dos problemas do software [Dal Sasso & Lanza, 2014]. Por esta
razão estudos estão sendo realizados de modo a propor novas formas de visualização
da informação contida nas RMs [Takama & Kurosawa, 2013, Hora et al., 2012].
Baixa Qualidade do Relato: Durante o processo de solução de uma RM a repro-
dução manual das falhas reportadas é demorada e tediosa. Os desenvolvedores ten-
2.1. A Manutenção de Software e a Requisição de Mudança 23
tam reproduzir problemas usando a informação contida nas RMs que muitas vezes
está incompleta [White et al., 2015]. Em algumas situações, para obter os dados que
necessita, o desenvolvedor deve registrar um comentário para que o responsável do
relato inclua as informações necessárias [Zimmermann et al., 2009]. A melhoria da
qualidade do relato pode implicar na redução do custo do processo de garantia de qua-
lidade bem como aumentar a confiabilidade do software com a redução gradativa de
falhas [Tu & Zhang, 2014].
Identificação de RMs Duplicadas: O processo de identificação de RMs Duplicadas
consiste em avaliar se determinado relato de uma RM trata do mesmo assunto tratado
no relato de outra RM. Quando uma RM é identificada como duplicada ela deveria ser
relacionada com a sua “cópia”. Uma delas é definida como RM Mestre e as demais RMs
Filhas. Geralmente a Mestre é aquela que foi primeiramente incluída no repositório
de erros. Alguns estudos revelam que entre 10% e 30% das RMs podem ser classifica-
das como duplicadas [Anvik et al., 2005, Cavalcanti et al., 2013, Runeson et al., 2007].
Por conta do grande número de RMs repetidas uma das soluções é o Escalonador
analisá-las manualmente com objetivo de evitar que elas cheguem aos desenvolvedo-
res [Anvik et al., 2005]. Em alguns casos esta solução não é viável. O processo de
identificação de RMs duplicadas requer: (i) um prévio conhecimento do conjunto de
relatos existentes anteriormente no projeto; (ii) a busca manual em toda base de da-
dos da FGRM [Banerjee et al., 2012, Lerch & Mezini, 2013, Hindle et al., 2016]. Am-
bas as estratégias consomem tempo e não garantem que falsos positivos não possam
ocorrer [Kaushik & Tahvildari, 2012]. Os falsos positivos podem ainda acarretar na
desconsideração de problemas relevantes.
Atribuição da RM: O processo de atribuição de RMs tem como objetivo encontrar o
desenvolvedor mais capacitado para manipular uma dada RM [Cavalcanti et al., 2014].
Existe a premissa de que a escolha do desenvolvedor apropriado é crucial para obter
em menor tempo a solução da RM [Di Lucca et al., 2002]. Estudos também discutem
que o processo de atribuição deve considerar fatores tais como a carga de trabalho do
desenvolvedor e a prioridade da RM, dentre outros [Aljarah et al., 2011].
Classificação da RM: Independentemente do tipo e tamanho de um projeto é im-
portante determinar qual tipo de manutenção deverá ser realizada para cada RM que
é criada. Geralmente este tipo de classificação é feita com base no texto que cor-
responde ao relato da RM. A diversidade de categorias pode tornar a tarefa com-
plexa pelo fato de que em muitos casos não é fácil determinar os limites entre os
24 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
tipos [Antoniol et al., 2008]. Por exemplo, a uma classificação incorreta de um de-
feito que na verdade trata-se de uma melhoria pode acarretar em atrasos no pro-
jeto [Cavalcanti et al., 2014]. A principal atividade associada é a triagem de RMs que
tem como objetivo revisar uma lista de RMs para determinar aquelas que necessitam
ser acompanhadas ou priorizadas.
Estimativa de Esforço da RM: A gerência de custo e de esforço de um projeto
de manutenção passa pelo controle do esforço necessário para solucionar suas RMs.
Os estudos que discutem o esforço para solução de uma RM utilizam três formas de
estimativa [Cavalcanti et al., 2014]: determinar o tempo para solucionar novas RMs;
definir os artefatos que são impactados por determinada RM (Análise de Impacto);
prever o número de novas RMs que poderão fazer parte do projeto. A literatura
sobre análise de impacto é bastante abrangente e pode envolver o estudo de arte-
fatos tais como documentos de requisitos e arquiteturas de softwares, código fonte,
registros (logs) de teste e assim por diante [Cavalcanti et al., 2014]. Apesar da ine-
rente imprecisão deste tipo de trabalho é importante salientar que a estimativa de
esforço de RMs é importante para a gestão de projetos de manutenção porque ajuda
alocar o recurso disponível de forma mais eficiente [Bhattacharya & Neamtiu, 2011]
e melhorar a previsão do custo necessário para o lançamento de futuras versões do
sistema [Vijayakumar & Bhuvaneswari, 2014].
Recomendação de RMs: Em algumas equipes, um membro experiente geralmente
ensina os recém-chegados o que eles precisam fazer para solucionar uma RM. Todavia,
alocar um membro experiente de uma equipe por um longo tempo para ensinar um no-
vato nem sempre é possível ou desejável. A premissa é que o mentor poderia ser mais
útil fazendo tarefas mais importantes [Malheiros et al., 2012]. Por exemplo, quando
um novo desenvolvedor entra no projeto seria interessante que ele resolvesse as RMs
que tivessem um menor nível de dificuldade. Posteriormente, quando o desenvolvedor
ganhasse mais experiência, poderia aumentar o grau de dificuldade das RMs que ele
deve tratar. Este tipo de situação ocorre com certa frequência em projetos de código
aberto, em que a contribuição de desenvolvedores externos ao projeto é fundamental.
No entanto, encontrar um defeito apropriado ao nível de conhecimento do desenvolve-
dor, bem como a correção apropriada para o mesmo requer uma boa compreensão do
projeto [Wang & Sarma, 2011].
Para facilitar a inclusão de novos desenvolvedores alguns estudos vêm se dedi-
cando ao desenvolvimento de sistemas de recomendação de RMs [Malheiros et al., 2012,
Wang & Sarma, 2011]. Estes sistemas podem ajudar o recém-chegado a solu-
2.2. As Ferramentas de Gerenciamento de Requisições de Mudança
(FGRM) 25
cionar uma RM mediante a apresentação do código fonte potencialmente rele-
vante [Malheiros et al., 2012].
2.2 As Ferramentas de Gerenciamento de
Requisições de Mudança (FGRM)
As RMs são controladas por uma FGRM na forma de um fluxo de trabalho de
modo a identificar, descrever e controlar a sua situação. Em geral, os objetivos
de um projeto em adotar uma FGRM para gerenciar suas RMs são os seguin-
tes [Tripathy & Naik, 2015]:
• Disponibilizar um método comum para a comunicação entre as partes interessa-
das.
• Identificar de forma única e rastrear a situação de cada RM. Esta característica
simplifica o processo de relatar uma RM e fornece um melhor controle sobre as
mudanças.
• Manter uma base de dados sobre todas as mudanças no sistema. Esta informação
pode ser utilizada para monitoramento e métricas de medição.
No momento em que os trabalhos desta dissertação estavam sendo desenvolvidos,
alguns estudos discutiam o fato de que as FGRMs não apenas ajudam as organizações
a gerenciar, atribuir, controlar, resolver e arquivar as RMs [Bertram et al., 2010]. Em
alguns casos, este tipo de ferramenta se tornou o ponto focal para comunicação e
coordenação para diversas partes interessadas, dentro e além da equipe de manutenção.
As FGRMs servem como um repositório central para monitorar o progresso das ações
dos mantenedores associadas a uma RM, para solicitar informações adicionais da pessoa
responsável por redigir a requisição e o ponto de discussão para potenciais soluções de
um defeito (bug) [Zimmermann et al., 2009].
Em projetos de código aberto, as FGRMs são um importante espaço onde a
equipe de desenvolvimento interage com a comunidade. Como consequência é possível
observar o fenômeno da participação dos usuários no processo de solução da RM:
eles não apenas submetem a RM, mas também participam da discussão da solução.
Desta forma, o usuário final ajuda nas decisões sobre a direção futura do produto de
software [Breu et al., 2010].
26 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
2.2.1 Modelo Conceitual do Contexto das FGRMs
As FGRMs têm características as vezes distintas e têm sido usadas em diferentes con-
textos, apesar disso é possível encontrar atributos comuns que permitem a compilação
de um modelo das FGRMs e de seu contexto. A construção de um modelo conceitual
do contexto das FGRM pode ajudar em discussões posteriores. Acreditamos que o
esforço para a criação de um modelo conceitual para FGRMs e seu contexto é bem
extenso. Conforme discutido na Conclusão desta dissertação percebemos que organi-
zar de maneira consistente e abrangente as FGRMs e seu contexto exigiria um esforço
além de nossa disponibilidade e aqui apenas itemizamos alguns conceitos que podem
ser candidatos a estarem presentes em um trabalho mais completo.
Projeto: Em vários contextos um “projeto” corresponde a um “projeto de manutenção
de software”, mas há também contextos que tratam de um “projeto” que não é
claramente especificado. Este pode ser composto pelos atributos Componentes
de Software, Artefatos e Contexto de Desenvolvimento.
• Componente de Software representa um ou mais módulo que fazem parte
do sistema que a FGRM suporta.
• Artefatos são os objetos utilizados ou produzidos no desenvolvimento do
software tais como código fonte, documentação, casos de teste e etc.
• Contexto de Desenvolvimento representa os atributos que interferem no pro-
cesso de desenvolvimento e manutenção de software. Nele está contido o
processo de desenvolvimento (por exemplo métodos ágeis, cascata, iterativo
e etc), as ferramentas utilizadas (compiladores, ferramentas de debug e de
build), dentre outros aspectos.
Repositório de RMs: Trata-se da base de dados onde as RMs são armazenadas e
gerenciadas. Cada item nesta base é uma RM com as características discutidas
na Seção 2.1.4.
Repositório de Usuários Representa a base de dados de usuários da FGRM. Nele
são gerenciados os dados das pessoas envolvidas no projeto e de seus respectivos
direitos de acesso às informações das RMs. Neste caso, esta base inclui tanto a
equipe de manutenção quanto as demais partes interessadas.
Fluxo de Trabalho: O Fluxo de Trabalho representa o conjunto de regras que ge-
renciam o processo de solução das RMs. É a partir dele que são definidos os
diferente estados que uma RM pode assumir desde de quando ela é redigida até
2.2. As Ferramentas de Gerenciamento de Requisições de Mudança
(FGRM) 27
o momento em que se define que foi solucionada. Este processo é realizado pelas
Pessoas envolvidas no Projeto através dos diferentes Papéis desempenhados e
suas respectivas Atividades. Uma discussão mais aprofundada sobre os papéis
desempenhados na manutenção de software está disponível na Subseção 2.1.3.
De maneira relacionada, os diferentes estados de um ciclo de vida de uma RM
estão descritos na Subseção 2.1.4.2.
As FGRMs desempenham um papel que vai além de gerenciar as Requisições
de Mudança. Neste sentido, é importante estudar este tipo de software em busca do
conhecimento de como melhorá-lo de modo a atender as diversas necessidades dos seus
usuários. Contudo, é importante avaliar as novas funcionalidades propostas na litera-
tura. Uma possível forma de melhoria é através do uso de extensões. Na próxima seção
abordamos esta propriedade de algumas FGRMs que permitem a inclusão e modificação
de funcionalidades e comportamentos segundo as necessidades do usuário.
2.2.2 Extensões de Funcionalidades em FGRM
Em determinados domínios de aplicação é interessante desenvolver produtos de soft-
ware com uma arquitetura que permita o sistema se adaptar às mudanças em seu
ambiente. Existe a possibilidade de incluir novas funcionalidades dentro das já exis-
tentes no software. Verificamos que os sistemas que permitem extensões apresentam
os seguintes benefícios:
• Extensibilidade: o software pode ser dinamicamente estendido mediante a inclu-
são de novos módulos de código que correspondem a novas características;
• Desenvolvimento em Paralelo: Quando os componentes não possuem certas de-
pendências eles podem ser desenvolvidos em paralelo por equipes diferentes;
• Simplicidade: uma extensão tipicamente tem uma única funcionalidade, desta
forma, permite um maior foco de quem desenvolve.
Uma extensão de uma FGRM pode portanto ser (i) um código executável que
estende as funcionalidades do módulo executável da ferramenta ou (ii) uma especifi-
cação de como uma ferramenta pode ter funcionalidades adicionais. Nesta dissertação
fazemos uso dos dois significados e normalmente o contexto deixa claro a intenção de
significado.
28 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
2.3 Funcionalidades das FGRMs
2.3.1 Visão Geral
Quando uma empresa ou um projeto de software de código aberto decide adotar uma
FGRM um desafio é analisar o conjunto de funcionalidades das FGRMs que serão
consideradas candidatas. Outras variáveis podem envolver o custo e o suporte pós-
venda da ferramenta. De maneira relacionada, o pesquisador que estuda propostas de
melhorias para as FGRMs pode estar interessado em analisar o conjunto de funções
que permita caracterizar este tipo de software.
O número de FGRMs disponíveis quando esta dissertação foi escrita era de cerca
de 50 ferramentas. A nossa expectativa é que, a partir de um conjunto compartilhado
de funções e comportamentos, sejamos capazes de caracterizar as FGRMs e também
avaliar a contribuição de novas funcionalidades propostas na literatura, conforme será
apresentado no Capítulo 3. Com este objetivo realizamos um estudo exploratório para
coletar as funcionalidades presentes nas FGRMs. Em um estudo exploratório a preo-
cupação é analisar o objeto em sua configuração natural, deixando que as descobertas
surjam da própria observação [Wohlin et al., 2012].
2.3.2 Objetivo do Estudo
O objetivo do estudo descrito nesta Seção é coletar, apresentar e discutir as princi-
pais funcionalidades das FGRMs que dão suporte ao desenvolvimento e manutenção
de software. O ponto de partida é o conjunto de sistemas escolhidos por meio de um
levantamento (survey). Acreditamos que o resultado obtido permite uma melhor com-
preensão deste tipo de software tomando como base o conjunto de funções que eles
oferecem aos seus usuários. Em um segundo momento também será possível propor
novas funcionalidades ou melhorias das existentes tendo em vista a possibilidade de
determinar um conjunto mínimo de comportamentos das FGRMs.
2.3.3 Metodologia
Para determinarmos um conjunto de funcionalidades das FGRMs realizamos um estudo
exploratório dividido nas três etapas listadas a seguir. Nas próximas seções apresenta-
mos os detalhes de cada uma delas.
(i) Seleção das Ferramentas
(ii) Inspeção da Documentação
2.3. Funcionalidades das FGRMs 29
(iii) Agrupamento das Funcionalidades
2.3.3.1 Seleção das Ferramentas
Nesta etapa definimos as ferramentas que seriam utilizadas. A partir de uma pesquisa
na Internet obtivemos cerca de 50 ferramentas3. Devido ao esforço necessário e a
dificuldade de realizar a análise em cada um dos sistemas que compunha o conjunto
inicial, optamos por escolher um subconjunto que fosse mais representativo, tomando
como base a opinião de desenvolvedores que trabalham em projetos de código aberto e
de código proprietário que já tenham utilizado alguma FGRM. A representatividade
no escopo do levantamento corresponde a opinião do profissional sobre notoriedade que
a ferramenta possui dentro do seu domínio de aplicação em comparação com as demais
que lhe foram apresentadas ou com as quais ele já teve contato.
2.3.3.2 Desenho do Levantamento por Questionário
Um levantamento (survey) por questionário é uma abordagem de coleta e análise de
dados em que os participantes respondem a perguntas ou manifestam opinião sobre
algum tipo de item apresentado. Este tipo de estudo permite a generalização das cren-
ças e opiniões de uma população mediante os dados coletados de um subconjunto do
público-alvo (amostra). No trabalho conduzido por Kasunic [Kasunic, 2005] é apre-
sentada uma sequência de etapas a serem seguidas no processo de condução de um
levantamento por questionário. Este passo-a-passo está descrito a seguir e foi utilizado
no levantamento para seleção das FGRMs.
1. Identificar os objetivos da pesquisa
2. Identificar e caracterizar o público-alvo
3. Elaborar o plano de amostragem
4. Elaborar e escrever o questionário
5. Aplicar questionário de teste ou piloto
6. Distribuir o questionário
7. Analisar os resultados e escrever o relatório
3https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
30 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
Para coletar a opinião dos profissionais utilizamos um formulário estruturado
em duas partes: a formação de base do participante (background) e a avaliação das
ferramentas. Na primeira, estávamos interessados em conhecer as características do
respondente. Esta informação é relevante para analisar de forma separada os dois
grupos de profissionais em que o questionário foi aplicado. Na segunda, apresenta-
mos uma lista previamente definida de ferramentas e solicitamos aos participantes
que avaliassem a relevância de cada uma delas através de uma escala do tipo Li-
kert [Robbins & Heiberger, 2011]. As ferramentas que foram apresentadas aos partici-
pantes estão disponíveis no Apêndice A. O formulário também dispunha de um campo
de texto em que era possível registrar outras FGRMs também julgadas relevantes, mas
que não estava na lista que lhe foi apresentada.
Antes da aplicação, o questionário foi validado em um processo de três etapas. Na
primeira parte foi solicitada a avaliação por dois pesquisadores experientes da área de
Engenharia de Software. Após as alterações, uma versão modificada foi enviada para
dois profissionais que trabalham com manutenção de software. O critério utilizado para
seleção dos profissionais foi ter um tempo da ordem ou superior a 10 anos de experiência
em desenvolvimento e manutenção de software. O formulário foi modificado com as
sugestões dos profissionais finalizando assim a segunda etapa de validação. A última
etapa consistiu na realização de um piloto com dez desenvolvedores que trabalham
em um setor manutenção de software de uma empresa pública de informática. Os
programadores responderam o questionário e, adicionalmente, responderam questões
em que era possível dar sugestões de melhoria. A versão final do formulário está
disponível no Apêndice B desta dissertação. Como o público-alvo do questionário
poderia incluir desenvolvedores de diferentes nacionalidades foi criada uma versão em
inglês4.
No caso deste levantamento a população é o conjunto de profissionais que tra-
balham com desenvolvimento e manutenção de software e que tenham uma razoável
experiência de uso com as FGRMs. A caracterização e estratificação desta população
não é simples. Neste sentido, visando diminuir possíveis vieses, replicamos o questio-
nário em dois grupos:
Grupo 01: Profissionais que participam de fóruns e discussões sobre desenvolvimento
e manutenção de software na rede social Stack Overflow.
Grupo 02: Profissionais relacionados a grupos que contribuem em projetos de código
aberto.
4A versão inglês do formulário está disponível em https://archive.org/download/
dissertacao-vagner-clementino-um-estudo/form-avalicao-ferramentas-en.pdf
2.3. Funcionalidades das FGRMs 31
Os participantes foram recrutados através de correio eletrônico. Nós coletamos
os endereços de e-mail que foram definidos com públicos e enviamos um total de 104
mensagens no período de 13/11/2016 a 21/11/2016. O gabarito da mensagem enviada
pode ser visualizado no Apêndice C.
2.3.3.3 Critérios de Seleção das FGRMs
Antes da seleção das FGRMs que seriam utilizadas nesta dissertação, elas foram catego-
rizados como ”ferramentas” e ”serviços da internet”. Para incluir determinado software
em um dos grupos utilizamos a respectiva documentação do software. A primeira cate-
goria representa os softwares que são capazes de serem implantados na infraestrutura
do seu cliente e permite algum grau de personalização de seus componentes, como por
exemplo, o banco de dados a ser utilizado. Na segunda categoria estão os softwares
que oferecem o gerenciamento das RMs mediante uma arquitetura do tipo Software
como Serviço, onde certos tipos de alterações no comportamento do sistema são mais
restritas. Acreditamos que ao escolher ferramentas destes dois tipos poderíamos cobrir
uma maior parte do domínio de aplicação das FGRMs do que se a escolha priorizasse
apenas um tipo. Optamos por escolher 03 ferramentas de cada categoria.
O grupo final de FGRMs foi selecionado pela frequência com que cada grau de
relevância apareceu no levantamento. A pontuação seguiu uma escala que atribuía 1
para uma uma opção mais negativa como “Não conheço a ferramenta” e um peso 5 para
resposta mais positiva como “Muito relevante”. Por exemplo, se uma ferramenta X teve
a opção “Muito relevante” escolhida por três profissionais ela receberia a pontuação final
de 15. Caso uma ferramenta não estivesse na lista, mas foi informada pelo participante
de forma espontânea, ela recebia uma pontuação igual a 5. Após o cálculo da pontuação
de cada ferramenta, ordenamos do maior para o menor valor e escolhemos as três
melhores posicionadas de cada categoria.
2.3.3.4 Inspeção da Documentação
Nesta etapa do trabalho realizamos a leitura do material disponível na Internet para
cada uma das ferramentas selecionadas conforme descrito anteriormente. Para cada
uma das FGRMs optamos por analisar a última versão estável do software a fim de
analisarmos o que havia de mais novo disponível aos usuários. A documentação de al-
gumas ferramentas, em especial aquelas que adotam uma arquitetura cliente/servidor e
necessitam de um certo grau de administração, dividem as funcionalidades do software
entre aquelas com foco no usuário final e administradores de sistema. Nestes casos, op-
tamos por coletar as funcionalidades para os usuários finais das FGRMs tendo em vista
32 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
que aquelas com foco em administradores de sistemas não estão no escopo desta disser-
tação. Os dados obtidos durante o processo de seleção foram incluídos no formulário
disponível no Apêndice D.
Os dados obtidos da leitura da documentação de cada ferramenta foram classifica-
dos por meio da técnica denominada Cartões de Classificação - Sorting Cards. Trata-se
de um processo de elicitação de conhecimento de baixo custo e com foco no usuário que
é utilizado na área de arquitetura da informação para criar modelos mentais e derivar
classificações a partir dos dados utilizados [Just et al., 2008]. Existem três fases dentro
do processo de Cartões de Classificação (i) preparação, na qual os participantes ou o
conteúdo dos cartões são selecionados; (ii) execução, em que os cartões são organizados
em grupos com um título que seja capaz de descrever o grupo; (iii) análise, na qual
os cartões são sistematizados para formar hierarquias mais abstratas e que são usadas
para deduzir resultados.
Figura 2.8. Exemplo de documentação de uma funcionalidade do Bugzilla
Os cartões foram organizados de modo a conter: o nome e a versão da ferramenta
analisada; a URL da documentação utilizada; o nome da funcionalidade coletada, que
consiste de uma descrição breve conforme existente na documentação; descrição deta-
lhada da funcionalidade, cujo objetivo é facilitar o processo de agrupamento que será
descrito na próxima seção. Nas Figura 2.8 e 2.9 é possível visualizar, respectivamente,
a documentação de uma funcionalidade da ferramenta Bugzilla e o cartão produzido5
5O conteúdo integral dos cartões utilizados nesta dissertação estão disponíveis em https://
archive.org/download/dissertacao-vagner-clementino-um-estudo/cartoes-ordenados.csv
2.3. Funcionalidades das FGRMs 33
Figura 2.9. Exemplo de um cartão ordenado para uma funcionalidade da FGRM
Bugzilla
2.3.3.5 Agrupamento das Funcionalidades
Esta etapa tem por objetivo agrupar as funcionalidades que aparecem com nomen-
clatura distintas em diferentes ferramentas, mas que representam o mesmo comporta-
mento. Cabe ressaltar que o agrupamento de algumas funcionalidades pode depender
de uma análise interpretativa do responsável pela atividade. Neste sentido, a fim de
evitar algum tipo de viés, o agrupamento foi realizado em duas etapas:
Análise Individual Nesta etapa o autor e um outro especialista realizam de forma
separada os agrupamentos.
Anaĺise Compartilhada Em um segundo momento tanto o autor quanto o especia-
lista discutem as possíveis divergências até que um consenso seja obtido.
Após o processo de agrupamento foi possível realizar a categorização das funcio-
nalidades das ferramentas. Os resultados do processo de agrupamento são apresentados
e discutidos nas próximas seções.
34 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
2.3.4 Resultados
Nesta seção iniciamos apresentando o perfil dos participantes do levantamento que
selecionou as ferramentas e em seguida exibimos as categorias resultantes do processo
de classificação dos cartões.
2.3.4.1 Perfil dos Participantes
Ao final do levantamento obtivemos um total de 52 respostas. Os profissionais que
participaram são em sua maioria desenvolvedores conforme pode ser verificado na Fi-
gura 2.10. O grupo de respondentes também incluem Engenheiros de Software, Geren-
tes de Equipe e Arquitetos de Software que, junto com os Desenvolvedores, representam
mais de 80% do total. Com relação à experiência verificamos que a maior parte possui
entre 3 e 10 anos (60%). Na segunda posição temos os participantes com 10 - 20 anos
de experiência (17%). Quanto ao tamanho da equipe, verificamos uma prevalência de
equipes com mais de 10 membros, representando 38% das participações. As demais
configurações de tamanho de equipe tiveram a seguinte frequência de respostas: 2 a 5
membros (35%); 6 a 10 membros (19%); 1 membro (8%). Por sua vez, estas equipes es-
tão predominantemente em empresas privadas de software, é o caso de 37 participantes
(74%). Com relação ao local de trabalho verificamos ainda que a segunda posição ficou
para empresas que pertencem ao setor governamental com 11 participantes (22%). O
restante é composto por 01 profissional que se dedica a projetos de software livre (2%)
e 01 estudante (2%).
2.3.4.2 Ferramentas Escolhidas
A partir do levantamento realizado e do processo de seleção descrito na Seção 2.3.3.3
obtivemos as ferramentas apresentas na Tabela 2.1. Conforme pode ser observado
foram escolhidos três softwares que conforme os critérios que adotamos podem ser
classificados como ferramenta ou serviço da Internet6. É importante perceber que o
Github e o Gitlab não estavam na lista inicial, contudo, apareceram no resultado final.
Isso decorre pelo fato de optarmos por atribuir o peso 5 para ferramentas que foram
citadas pelos participantes de maneira espontânea.
A Tabela 2.2 apresenta as ferramentas e o elo de ligação para os respectivos
documentos que foram utilizados. Para aqueles sistemas que apresentam documentação
6A análise completa dos dados sobre a seleção das ferramentas pode ser encontrado
em https://archive.org/download/dissertacao-vagner-clementino-um-estudo/frequencia_
selecao_ferramentas.csv
2.3. Funcionalidades das FGRMs 35
Perfil dos Participantes: Função Desempenhada
De
se
nvo
lve
do
r
En
g. 
de
 So
ftw
ar
e
Ge
ren
te
Arq
. D
e S
oft
wa
re
Te
sta
do
r
An
al.
 de
 Re
qu
isit
os
Es
tag
iár
io
An
al.
 De
 Da
do
s
l
l
l
l
l
l
l
l
21
11
8
5
3 2 1 1
40%
62%
77%
86%
92%
96%
98%
100%
Figura 2.10. Funções desempenhadas pelos participantes
Ferramenta Classificação Versão URL
Bugzilla Ferramenta 5.0.3 https://www.bugzilla.org
Mantis Bug Tracker Ferramenta 1.3.2 https://www.mantisbt.org
Redmine Ferramenta 3.3.1 http://www.redmine.org/
JIRA Software Serviço 7.2.4 https://br.atlassian.com/software/jira
Github Issue System Serviço - https://github.com/
Gitlab Issue Tracking System Serviço - https://gitlab.com/
Tabela 2.1. Ferramentas utilizadas no estudo
36 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
em mais de um idioma optamos por aquela escrita em inglês por entendermos que
poderia ser a mais atualizada.
Nome da Ferramenta URL
Bugzilla https://www.bugzilla.org/features/
Github Issue Tracking System https://github.com/blog/411-github-issue-tracker
Github Issue Tracking System https://github.com/features
Github Issue Tracking System https://guides.github.com/features/issues/
Gitlab Issue Tracking System http://docs.gitlab.com/ce/user/project/labels.html
Gitlab Issue Tracking System https://about.gitlab.com/2016/08/22/announcing-the-gitlab-issue-board/
Gitlab Issue Tracking System https://about.gitlab.com/solutions/issueboard/
Gitlab Issue Tracking System https://docs.gitlab.com/ee/user/project/description_templates.html
Gitlab Issue Tracking System https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html
Gitlab Issue Tracking System https://docs.gitlab.com/ee/workflow/issue_weight.html
Gitlab Issue Tracking System https://docs.gitlab.com/ee/workflow/milestones.html
Gitlab Issue Tracking System https://docs.gitlab.com/ee/workflow/time_tracking.html
JIRA https://br.atlassian.com/software/jira/features
MantisBT https://www.mantisbt.org/wiki/doku.php/mantisbt:features
Redmine http://www.redmine.org/projects/redmine/wiki/Features
Tabela 2.2. Documentações utilizadas no processo de coleta de dados.
2.3.4.3 Espectro de Funcionalidades das FGRMs
Após a inspeção da documentação e validação dos dados obtivemos um total de 123
cartões, sendo eles sistematizados manualmente. Como o nosso objetivo é derivar tópi-
cos a partir de um conjunto inicial de cartões, optamos por realizar uma classificação
aberta. Neste tipo de abordagem, os grupos são estabelecidos durante o processo de
classificação dos cartões em oposição a outra forma de utilização da técnica em que a
sistematização dos cartões ocorre com base em grupos pré-determinados. Ao final do
processo compilamos os tópicos para construir um espectro de funcionalidades para as
FGRMs exibido na Figura 2.11.
A figura foi construída com base nas categorias de funcionalidades exibidas na
Tabela 2.3 em que é possível verificar a frequência que cada uma delas apareceu no
conjunto de cartões coletados.
A partir da Tabela 2.3 é possível verificar que o gerenciamento das RMs formam as
funcionalidades mais frequentes das FGRMs. De uma maneira geral, uma das primeiras
responsabilidades de uma FGRM é gerir a criação, consulta, atualização e destruição
de uma RM. Estas funções podem ser agrupadas em um termo único denominado
Operações de CRUD (acrônimo de Create, Read, Update e Delete na língua Inglesa).
Algumas das categorias apresentadas na Tabela 2.3 estão descritas descritas a seguir.
Operações de CRUD: Nesta categoria estão as funcionalidades que dão suporte à
criação, consulta, atualização e destruição das RMs. Com relação à criação verificamos
2.3. Funcionalidades das FGRMs 37
Figura 2.11. Modelo de funcionalidades básicas das FGRMs
Categoria de Funcionalidades Frequência
Operações de CRUD 24
Visualização e Monitoramento de RMs 22
Segurança da Informação 17
Fluxo de Trabalho 15
Interfaces de Notificação 13
Extensão de Funcionalidades 8
Triagem de RMs 6
Gerenciamento de Artefatos 6
Integração com Sistemas de Controle de Versão 4
Gerenciamento da Informação 4
Internacionalização da Ferramenta 3
Auditoria 1
Tabela 2.3. Frequência de cada categoria de funcionalidade no conjunto de
cartões obtidos.
38 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
que algumas FGRMs permitem a definição de campos personalizáveis para o preenchi-
mento da RM. A ferramenta Bugzilla permite a criação de um campo personalizado
de modo a capturar informações específicas de um projeto. Estes campos podem ainda
ser exibidos com base no valor de outro, para usá-los apenas quando for de interesse.
Esta categoria também agrupa as funcionalidades relacionadas à busca de RMs
e à localização de RMs duplicadas. Durante o processo de criação de uma RM, uma
das ferramentas possui a funcionalidade para detecção automatizada de duplicação de
RMs. Para criar RMs algumas ferramentas possibilitam diferentes interfaces de entrada
de modo que ela possa ser criada através do envio de e-mail, utilizando dispositivos
móveis ou mediante formulários disponíveis via Web.
Verificamos ainda que algumas FGRMs permitem que o relato da RM seja reali-
zado em linguagem com semântica de apresentação como o Markdown7, que permite,
dentre outras opções, a inclusão de código fonte com a sintaxe realçada. Isso possibi-
lita visualizar de forma mais clara partes do código que podem ser incluídas no relato
da RM. Neste mesmo tópico encontramos funcionalidades para recuperação das RMs
utilizando o texto contido no atributo que corresponde ao relato, através de filtros per-
sonalizáveis ou por meio de uma Linguagem de Domínio Específico (Domain-Specific
Language - DSL) baseada em SQL.
Gerenciamento da Informação: Dentro de um projeto de desenvolvimento ou ma-
nutenção de software gerenciar uma RM por vez não é muito eficiente. Neste sentido,
é necessário que as FGRMs permitam o gerenciamento em massa da informação ar-
mazenada. Em geral, o gerenciamento da informação fica a cargo dos Sistemas de
Gerenciamento de Banco da Dados - SGBD, neste sentido, a maior parte das funcio-
nalidades nesta categoria estão focadas em suportar múltiplos SGBDs. Além disso, a
ferramenta Bugzilla oferece funcionalidade para validação de consistências dos dados
armazenados.
Extensão de Funcionalidades: As FGRMs oferecem recursos que permitem que ou-
tras ferramentas possam interagir e manipular a informação que elas armazenam. Nesta
dimensão estão as funcionalidades que possibilitam a manipulação externa dos dados
contidos nas RMs ou mesmo o desenvolvimento de novas funções ou comportamentos
da FGRM mediante o uso de interfaces de programação (APIs) e extensões.
As funcionalidades que compõem este grupo têm por objetivo estender o conjunto
de comportamentos oferecidos através de uma arquitetura de plug-in ou mediante o
suporte de APIs. Algumas ferramentas como o Github permitem realizar as atividades
7https://en.wikipedia.org/wiki/Markdown
2.3. Funcionalidades das FGRMs 39
de gerência de uma RM mediante a utilização de uma API própria. No caso do Bugzilla
e do Mantis é permitido o acesso à informação das RMs através de Webservices.
Integração com Sistemas de Controle de Versão: As FGRMs podem acessar os
repositórios de código de fonte, gerenciados mediante um Sistema de Controle de Versão
(SCV), permitindo que o usuário navegue pelo seu conteúdo, visualize e procure as
alterações realizadas. As ferramentas também possibilitam acesso aos diferentes tipos
de SCV, tais como Git, SVN, Mercurial.
Interfaces de Notificação: Neste tópico estão as funcionalidades oferecidas pelas
FGRMs para notificar as diversas partes interessadas envolvidas em determinada RM.
As FGRMs podem notificar através de e-mail, RSS, Twitter e chats.
Fluxo de trabalho: Nesta categoria estão as funcionalidades que dão suporte às
tarefas do desenvolvimento e manutenção de software. Nela estão incluídos funções
para gerenciamento de tarefas e suporte a múltiplos projetos. Também é possível
personalizar o fluxo de trabalho adotado. Esta personalização é realizada através da
definição de situações próprias que se adéquem às necessidades do projeto de software.
Gerenciamento de Artefatos: O processo de trabalho relacionado com a ma-
nutenção de software pode consumir ou gerar diversos artefatos, tais como do-
cumentos de requisitos, código fonte, registros (logs) de teste e assim por di-
ante [Cavalcanti et al., 2013]. Em alguns contextos, devido ao volume de artefatos
gerados, é importante que a FGRM forneça suporte para armazenamento e recupe-
ração destes ativos correspondentes ao processo de desenvolvimento de software. As
FGRMs possuem funcionalidades que se relacionam com a documentação de software,
geralmente no formato de Wikis. Além disso, algumas ferramentas permitem uma
melhor visualização de anexos da RM, como por exemplo arquivos no formato CSV
(comma-separated values).
Triagem de RMs: Este tópico descreve as funcionalidades relacionadas com a tri-
agem de RMs. As FGRMs dão suporte a esta atividade principalmente através da
categorização das RMs. Todas as ferramentas analisadas permitem algum tipo de
classificação através do uso de etiquetas previamente definidas.
Internacionalização da Ferramenta: Neste tópico estão as características das
FGRMs que ajudam no desenvolvimento ou adaptação da interface para diferentes
40 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
idiomas. As FGRMs possuem tradução para diversos idiomas e também possuem fun-
cionalidades que permitem aos colaboradores criarem novas traduções.
Segurança da Informação: Neste grupo estão as funcionalidades de uma FGRM que
estão diretamente relacionadas com proteção da informação no sentido de preservar
o valor que possui para um indivíduo ou uma organização. Assim as ferramentas
oferecem funcionalidades para suporte à confidencialidade, integridade e autenticidade
da informação armazenada.
Visualização e Monitoramento de RMs: Em diversos contextos, devido ao volume
das RMs, é importante que as partes interessadas na manutenção do software, pos-
sam visualizar e monitorar a situação das RMs que estão sendo analisadas. As FGRMs
oferecem funcionalidades para visualizar a informação das RMs mediante quadros simi-
lares àqueles utilizados nas metodologias ágeis do tipo Kanban ou SCRUM. Existem
funcionalidades que permitem ao usuário visualizar um conjunto específico de RMs.
Nesta mesma categoria estão as funcionalidades para geração de relatórios para auxílio
dos tomadores de decisões.
2.3.5 Discussão
Ao realizarmos a categorização dos cartões certos desafios se apresentaram. Para al-
gumas funcionalidades não há uma separação clara em qual categoria ela poderia ser
encaixada, como por exemplo a possibilidade que algumas FGRMs fornecem de perso-
nalizar os campos que compõem uma RM. Esta função está relacionada com a criação
da RM (Operação de CRUD), contudo, também faz parte da definição do processo de
trabalho próprio de um projeto, o que permitiria categorizá-la como Fluxo de Traba-
lho. Esta mesma situação ocorre com as funcionalidades de deleção de uma RM que
foram classificadas como Operações de CRUD, mas que têm relação com a categoria de
Segurança da Informação já que para realizar tal ação o usuário deve ser identificado
(login realizado no sistema) e estar autorizado para realizar a ação.
A análise das funcionalidades nos permite verificar que o suporte oferecido pelas
FGRMs evoluíram da gerência simples de RMs para colaborar no processo de desenvol-
vimento e manutenção do software. Entretanto, esta evolução não abrange todo tipo
de necessidade. As ferramentas analisadas apresentaram um suporte bem estabelecido
para atividades relativas à gestão da RM, como por exemplo a criação de uma nova
RM. Contudo, são bastante escassas as funções que minimizem os problemas que ocor-
rem quando as RMs são criadas. Por exemplo não foi possível verificar funcionalidades
2.3. Funcionalidades das FGRMs 41
nativas das RMs que ajudem o responsável pelo relato a fornecer as informações que
serão necessárias à solução do que está sendo pedido. Uma outra facilidade ausente
neste tipo de ferramenta é a identificação de possíveis RMs duplicadas.
Com base no resultado obtido foi possível verificar que as FGRMs oferecem fun-
cionalidades que dão suporte a todo o ciclo de vida de uma RM, conforme discutido
na Subseção 2.1.4.2. Todavia, grande parte do esforço fica a cargo do usuário da fer-
ramenta, o que pode resultar em atrasos nas situações em que se têm muitas RMs
para gerenciar. Um exemplo deste problema ocorre no processo de atribuição do de-
senvolvedor responsável por solucionar determinada RM. Esta atividade fica sob a
responsabilidade do Atribuidor, que deve realizar a escolha de forma manual já que as
FGRMs não são capazes de “recomendar” o desenvolvedor mais apto.
Devido à sua importância, seria importante que as FGRMs incorporassem ou-
tros comportamentos que ajudem no processo de desenvolvimento e manutenção de
software, especialmente em temas como busca de duplicados, melhoria da qualidade
do relato e atribuição e classificação automatizadas das RMs. As sugestões de novas
funcionalidades para as FGRMs são discutidas no Capítulo 5.
2.3.6 Ameaças à Validade
Em função da classificação ser uma atividade interpretativa, a classificação das fun-
cionalidades em si mesma é uma limitação desta dissertação. Uma outra ameaça à
validade do trabalho está no processo de seleção das ferramentas. Apesar da escolha
ter sido realizada com suporte de profissionais envolvidos em manutenção de software,
não podemos garantir que o número de respondentes nos permite afirmar que escolhe-
mos as ferramentas mais relevantes dentre aquelas disponíveis. Além disso, a própria
distribuição que compõe os participantes não nos permite generalizar os resultados.
Neste mesmo sentido, a fórmula que foi utilizada para definir as mais relevantes podem
conter um enviesamento sobretudo pela forma que os pesos foram adotados, ou seja,
não há como garantir que o fato de um participante entender que uma determinada
ferramenta é muito relevante (peso igual a 5) mereça ser ponderado cinco vezes mais
que uma outra que não é conhecida (peso igual a 1).
Com relação à técnica de Cartões de Classificação temos dois pontos principais
de ameaças aos resultados. Como a extração dos dados foi realizada de forma manual
pode ter ocorrido algum tipo de equívoco no processo, como por exemplo a não coleta
de algum dado de determinada ferramenta por algum descuido. Todavia, um número
pequeno de ferramentas foi selecionado tendo em vista a limitação da extração manual,
o que pode ter minimizado este tipo de problema. Um segundo ponto encontra-se na
42 Capítulo 2. As FGRMs no Contexto da Manutenção de Software
classificação dos cartões. Apesar do processo ter sido realizado em pares pode ter
ocorrido uma classificação de forma incorreta o que pode acarretar em limitação dos
resultados apresentados. Esta situação pode ocorrer porque para algumas funcionali-
dades não há uma fronteira clara de qual grupo ela poderia pertencer.
2.4 Resumo do Capítulo
Neste capítulo discutimos o relacionamento da disciplina de Manutenção de Software
com as FGRMs. Para tanto apresentamos e discutimos os principais conceitos re-
lacionados e que são utilizados nos demais capítulos desta dissertação. Além disso,
apresentamos uma análise das funcionalidades das FGRMs realizado com o suporte
de um levantamento por questionário. A partir deste levantamento foram obtidas as
principais funções existentes nas FGRMs. O conjunto comum de funcionalidades que
foi encontrado é utilizado na dissertação para discutir a proposição de novas funciona-
lidades ou melhorias das existentes.
Capítulo 3
Mapeamento Sistemático da
Literatura
3.1 Introdução
Neste capítulo apresentamos um Mapeamento Sistemático com o objetivo de iden-
tificar estudos que propõem melhorias das funcionalidades fornecidas pelas FGRMs.
Realizamos a divisão de um conjunto de 64 artigos pela pertinência com as seguin-
tes categorias: (i) dimensões de melhoria, conforme proposto por Zimmermann e ou-
tros [Zimmermann et al., 2009] e (ii) função desempenhada no processo de manutenção
de software, a partir do conjunto de papéis envolvidas com Manutenção que foi apre-
sentado no Capítulo 2.
A principal contribuição deste mapeamento é uma visão do estado da arte das
propostas de melhorias das funcionalidades das FGRMs. Nossa expectativa é que
pesquisadores possam encontrar questões que contribuam para suas investigações e
que profissionais com interesses em FGRMs possam encontrar discussões e referências
neste domínio. Além disso, os desenvolvedores de FGRMs podem incorporar alguns
dos aspectos deste estudo nas funcionalidades oferecidas pelas ferramentas que são
responsáveis.
Este capítulo está organizado conforme descrito a seguir. Na Seção 3.2 descre-
vemos a metodologia adotada através das perguntas direcionadoras, dos critérios para
seleção dos estudos e dos esquemas de classificação utilizados. Na Seção 3.3 apresenta-
mos o resultado do processo de classificar os artigos que fizeram parte do mapeamento.
Uma discussão dos resultados é feita na Seção 3.4. As ameaças à validade e os traba-
lhos relacionados são discutidos nas Seções 3.5 e 3.6, respectivamente. Um resumo do
43
44 Capítulo 3. Mapeamento Sistemático da Literatura
capítulo é realizado na Seção 3.7.
3.2 Metodologia de Pesquisa
Um Mapeamento Sistemático da Literatura, também conhecido como Estudo de Es-
copo (Scoping Studies), tem como objetivo fornecer uma visão geral de determinada
área de pesquisa, estabelecer a existência de evidências de estudos sobre um tema de
interesse e fornecer uma indicação da quantidade de trabalhos na linha de pesquisa sob
análise [Keele, 2007, Wohlin et al., 2012]. Nesta dissertação empregamos as diretrizes
propostas por Petersen e outros [Petersen et al., 2008] em que um conjunto de ques-
tões de pesquisa é utilizado para guiar a busca e seleção dos estudos primários. Em
seguida, foram construídos dois esquemas de classificação com base nos dados extraídos
dos artigos. Por fim, foi realizada uma análise para posicionar os trabalhos em seus
respectivos esquemas.
3.2.1 Questões de Pesquisa
O objetivo deste mapeamento é identificar na literatura a proposição de novas funcio-
nalidades para as FGRMs ou a melhoria daquelas que existiam quanto esta dissertação
foi escrita. Deste modo, foram definidas as seguintes questões de pesquisa:
• Questão 01: Quais as melhorias e novas funcionalidades estão sendo propostas
para as FGRM?
• Questão 02: Para quais papéis envolvidos no processo de manutenção de soft-
ware as melhorias das funcionalidades visam dar suporte?
Na Questão de Pesquisa 01 estamos interessados em entender como a literatura
da área estava propondo melhorias ou novas funcionalidades para as FGRMs. Estas
melhorias deveriam potencialmente estar relacionadas com os problemas do gerencia-
mento das RMs, conforme discutido na Seção 2.1.4.3. O intuito é entender as técnicas
e abordagens adotadas nas soluções propostas. Na Questão de Pesquisa 02 o objetivo
é descobrir como os diferentes tipos de papéis que fazem parte do processo de manu-
tenção de software, e que foram apresentados no Capítulo 2 estavam recebendo suporte
pelos estudos da área.
3.2. Metodologia de Pesquisa 45
3.2.2 Pesquisa da Literatura
Para encontrarmos o conjunto de estudos mais relevantes, bem como eliminarmos aque-
les que não permitiam responder as questões de pesquisas, adotamos os seguintes cri-
térios para inclusão ou exclusão de artigos no mapeamento:
• Critérios de Inclusão
– Artigos publicados em conferências e periódicos (journals)
– Estudos publicados a partir de 20101
– Artigos escritos em língua inglesa
– Artigos disponíveis com texto completo
• Critérios de Exclusão
– Livros e literatura cinza (grey literature [Keele, 2007], por exemplo, relató-
rios técnicos, white papers, trabalhos em progresso e etc.)
– Artigos que não possuíam relação com FGRM
– Estudos duplicados, neste caso foi considerada a versão mais completa do
trabalho
Os estudos primários foram coletados mediante a aplicação de sentenças de
buscas nas bases de pesquisa IEEE Explore, ACM Digital Library, Scopus, e Ins-
pec/Compendex. Elas foram escolhidas por possibilitarem acesso a uma quantidade
similar de estudos relevantes se comparada com uma configuração muito maior de base
de dados [Dybå et al., 2007]. As sentenças de buscas foram produzidas com base na me-
todologia PICO (Population, Intervention, Comparison and Outcomes) [Keele, 2007]
que tem como objetivo dar suporte ao pesquisadores na formulação de termos de busca
tomando como ponto de partida as questões de pesquisa. As sentenças de busca apli-
cadas em cada base de pesquisa estão disponíveis no Apêndice E.
A aplicação de uma busca automatizada gerou um total de 286 artigos2. A Ta-
bela 3.1 exibe o total de estudos recuperados por base de pequisa. Os metadados dos
artigos foram organizados com ajuda da ferramenta JabRef 3, de modo a encontrar pos-
síveis duplicados. Com a ajuda da ferramenta JabRef foi possível remover 81 artigos,
1Foram considerados os artigos publicados até maio/2016, data de realização da pesquisa nas base
de dados.
2A lista inicial de artigos, após a remoção do duplicados, pode ser acessada em https://archive.
org/download/dissertacao-vagner-clementino-um-estudo/artigo-todos-sem-duplicados.
csv
3https://www.jabref.org/
46 Capítulo 3. Mapeamento Sistemático da Literatura
Figura 3.1. Número de artigos incluídos durante o processo de seleção dos
estudos. Figura baseada em [Petersen et al., 2015]
resultando em 205 estudos ao final desta etapa do processo. Finalmente os trabalhos
foram analisados com base na leitura do título e do resumo. Nos casos em que o título
e o resumo não eram capazes de indicar que o artigo atendia aos critérios de inclusão
foi realizada uma leitura completa do texto. A aplicação de todas as etapas descritas
resultou em 64 estudos. A Figura 3.1 resume a seleção dos estudos primários através
da exibição do número de artigos em cada etapa.
Base de Dados Total
ACM Digital Library 109
IEEE Explore 100
Inspec/Compendex 22
Scopus 55
Tabela 3.1. Número de Estudos Recuperados por Base de Dados
3.2. Metodologia de Pesquisa 47
3.2.3 Esquemas de Classificação
O mapeamento foi conduzido utilizando dois esquemas de classificação. O primeiro or-
ganiza os artigos pela pertinência da funcionalidade proposta no estudo com alguma das
dimensões de melhoria proposta por Zimmermann e outros [Zimmermann et al., 2009].
A segunda classificação distribui os estudos pelo relacionamento com o suporte dado
a determinado papel no processo de manutenção de software e que foi adotado nesta
dissertação. Entendemos que estes dois esquemas nos fornecem uma visão de como as
melhorias das funcionalidades foram propostas tanto do ponto de vista de quem desen-
volve quanto das diferentes partes interessadas dos projetos de software. As próximas
subseções discutem com mais detalhe cada esquema.
3.2.3.1 Classificação por Dimensão de Melhoria
Em um estudo sobre o aperfeiçoamento das FGRMs [Zimmermann et al., 2009], os
autores argumentam que ter informações completas nas RMs, tão logo quanto possí-
vel, ajuda os desenvolvedores a resolver com mais rapidez o problema. Neste mesmo
estudo, eles discutem como melhorar as funcionalidades oferecidas pelas FGRMs de
forma integral, ou seja, que atenda aos diversos contextos em que este tipo software
está integrado. Para isso, os autores propõe quatro dimensões de melhoria, conforme
descritas a seguir.
Foco na Informação Estas melhorias focam diretamente na informação fornecida
pelo reportador da RM. Com ajuda da FGRM, o responsável por descrever
uma falha, por exemplo, poderia ser motivado a coletar mais informações sobre
o problema. O sistema poderia verificar a validade e consistência do que foi
repassado pelo Reportador (detalhes sobre este papel pode ser encontrado na
Subseção 2.1.3).
Foco no Processo Melhorias com foco no processo visam dar suporte às atividades
de administração focadas na solução das RMs. Por exemplo, a triagem de RM,
poderia ser automatizada visando acelerar o processo. Um outro exemplo de
melhoria poderia ocorrer no aumento do entendimento do progresso realizado em
cada RM ou mesmo fornecer ao usuário afetado por uma falha uma estimativa
de tempo ou esforço necessário para atendimento.
Foco no Usuário Nesta dimensão estão incluídos tanto os usuários que relatam as
RMs (Reportadores) quanto os desenvolvedores responsáveis por solucioná-las.
Os reportadores podem ser orientados sobre qual informação fornecer e como
48 Capítulo 3. Mapeamento Sistemático da Literatura
Figura 3.2. Esquema de classificação das melhorias propostas na literatura.
Os retângulos representam as dimensões de melhorias e os polígonos de cantos
arredondados representam tópicos de problemas do gerenciamento das RMs.
coletá-la. Os desenvolvedores também podem se beneficiar de um treinamento
sobre qual informação esperar e como esta informação pode ser utilizada para
solucionar determinada RM.
Foco na Ferramenta As melhorias centradas na ferramenta são discutidas com vistas
às funcionalidades das FGRMs. Elas podem reduzir a complexidade da coleta e
fornecimento das informações necessárias para solucionar a RM. Por exemplo, as
FGRMs poderiam ser configuradas para automaticamente identificar a cadeia de
registros de ativação de funções (stack trace) e adicioná-la ao erro reportado. A
ferramenta poderia ainda simplificar o processo de reprodução do erro mediante
a captura automatizada de tela (screenshots).
Para a classificação dos estudos nos esquemas utilizados foi realizado um pro-
cesso baseado no trabalho de Petersen e outros [Petersen et al., 2008]. Os autores
recomendam que nos casos em que o resumo e o título do estudo não sejam capazes de
caracterizá-lo, as seções de introdução e conclusão também devem ser analisadas. Para
as bases de pesquisa de dados em que era informado mais de um conjunto de palavras-
chaves para um mesmo artigo, utilizamos aquelas que foram definidas pelos autores.
Mediante a aplicação do processo descrito foi construído o esquema de classificação
apresentado na Figura 3.2.
3.3. Resultados 49
3.2.3.2 Classificação por Suporte ao Papel da Manutenção de Software
Neste esquema de classificação estamos interessado em avaliar como os estudos dão
suporte aos papéis apresentados na Subseção 2.1.3. A construção da classificação uti-
liza a mesma metodologia descrita na seção anterior e utiliza a versão modificada do
conjunto de papéis propostos por Polo e outros [Polo et al., 1999b] e que está descrita
na Subseção 2.1.3.
3.3 Resultados
Nesta seção apresentamos os estudos divididos para cada um dos esquemas de clas-
sificação utilizados. Iniciamos com uma análise da frequência de publicações e pos-
teriormente apresentamos os resultados para cada uma das dimensões de melhoria.
Seguimos com a análise dos estudos pelo papel ao qual a funcionalidade proposta visa
dar suporte.
Para os artigos recuperados, em 2010, primeiro ano do período analisado, obtive-
mos um total de 05 trabalhos publicados. A maior quantidade de publicação ocorreu
entre os anos de 2012, 2013 e 2014, com, respectivamente, 14, 12 e 13 artigos. No ano
de 2016, último ano do período de referência, encontramos 03 estudos publicados. A
Tabela 3.2 exibe o número de estudos primários identificados entre os anos de 2010 e
2016.
Ano Frequência
2010 5
2011 8
2012 14
2013 12
2014 13
2015 9
2016 3
Tabela 3.2. Número de estudos primários por ano de publicação.
3.3.1 Classificação por Dimensões de Melhoria
Nesta seção apresentamos estudos relacionados com a dimensão denominada “Melhoria
das funcionalidades das FGRMs”. A classificação está estruturada de modo que no
primeiro nível temos as dimensões de melhoria discutidas na Subseção 3.2.3.1. O
50 Capítulo 3. Mapeamento Sistemático da Literatura
segundo nível é composto por tópicos representando os problema relacionados com
o gerenciamento das RMs, conforme discutidos na Subseção 2.1.4.3. A Tabela 3.3
exibe a distribuição dos estudos pela dimensão de melhoria e por sua pertinência com
determinado problema do gerenciamento das RMs.
Dimensão de Melhoria Tópico Estudos Total
Processo Localização de RMs Duplicadas
[Alipour et al., 2013, Banerjee et al., 2012, Hindle et al., 2016, Koopaei & Hamou-Lhadj, 2015]
13[White et al., 2015, Prifti et al., 2011, Song et al., 2010, Sun et al., 2010, Sun et al., 2011]
[Sun et al., 2011, Thung et al., 2014a, Tian et al., 2012, Tomašev et al., 2013, Lerch & Mezini, 2013]
Processo Atribuição de RM
[Banitaan & Alenezi, 2013, Hosseini et al., 2012, Hu et al., 2014, Naguib et al., 2013]
12[Nagwani & Verma, 2012, Shokripour et al., 2012, Tian et al., 2015, Valdivia Garcia & Shihab, 2014]
[Wu et al., 2011, Xuan et al., 2012, Zanetti et al., 2013, Zhang et al., 2014]
Processo Classificação de RM
[Behl et al., 2014, Chawla & Singh, 2015, Gegick et al., 2010, Izquierdo et al., 2015]
10[Kochhar et al., 2014, Nagwani et al., 2013, Netto et al., 2010]
[Somasundaram & Murphy, 2012, Tian et al., 2013, Zhang & Lee, 2011]
Ferramenta Localização do Problema
[Bangcharoensap et al., 2012, Corley et al., 2011, Nguyen et al., 2012]
7[Thung et al., 2014b, Wong et al., 2014]
[Romo & Capiluppi, 2015, Thung et al., 2013]
Informação Suporte ao Registro da RM [Zimmermann et al., 2010, Correa et al., 2013, Moran et al., 2015, Moran, 2015] 7[Tu & Zhang, 2014, White et al., 2015, Kaiser & Passonneau, 2011]
Processo Estima de esforço para solução da RM [Bhattacharya & Neamtiu, 2011, Nagwani & Verma, 2010, Thung et al., 2012b] 5[Vijayakumar & Bhuvaneswari, 2014, Xia et al., 2015]
Ferramenta Visualização de RM [Dal Sassc & Lanza, 2013, Dal Sasso & Lanza, 2014, Hora et al., 2012, Takama & Kurosawa, 2013] 4
Informação Organização da Informação da RM [Mani et al., 2012, Otoom et al., 2016] 2
Usuário Recomendação de RM [Malheiros et al., 2012, Wang & Sarma, 2011] 2
Ferramenta Busca de RM [Liu & Tan, 2014] 1
Ferramenta Monitoramento de RM [Aggarwal et al., 2014] 1
Tabela 3.3. Lista de artigos de acordo com o esquema de classificação
3.3.1.1 Melhorias Propostas na Dimensão Ferramenta
Este ramo do esquema de classificação inclui os estudo que possuem relação com tópicos
como Localização do Problema e Visualização de RMs.
Localização do Problema: Os estudos incluídos neste tópico focam em localizar a
origem do problema no software com base nos dados da RM [Hovemeyer & Pugh, 2004].
Com objetivo de melhorar a eficiência da localização de um problema, a informa-
ção contida nas RMs vem sendo utilizada. As abordagens propostas utilizam a
cadeia de registros de ativação [Wong et al., 2014], a descrição e campos estrutura-
dos das RMs [Thung et al., 2014b] e os históricos de versões do código fonte do sis-
tema [Bangcharoensap et al., 2012, Corley et al., 2011, Romo & Capiluppi, 2015]. Al-
gumas das melhorias propostas foram incluídas em ferramentas que estavam disponíveis
quando esta dissertação foi escrita por meio dos mecanismos de extensão que elas ofe-
recem. A ferramenta BugLocalizer 4, implementada como extensão do Bugzilla, extrai
o texto do sumário e do relato de uma RM e calcula a semelhança entre o texto re-
latado e o código fonte para encontrar os arquivos onde a falha possivelmente está
localizada [Thung et al., 2014b]. A ferramenta BugTrace [Corley et al., 2011] é uma
4https://github.com/smagsmu/buglocalizer
3.3. Resultados 51
extensão do Bugzilla que analisa os patches5 inseridos em RM para determinar um elo
de rastreabilidade entre uma falha e o código fonte.
Visualização de RM: Os artigos neste tópico estão relacionados com melhoria da
visualização da informação contida na RM. Com o objetivo de apresentar diferentes
formas de visualizar os dados de uma RM, novos conceitos estão sendo propostos.
No estudo de Hora e outros [Hora et al., 2012] é apresentado o conceito de Mapas
de Defeitos (BugsMaps) que mostra a RM e uma ligação dela com outros artefatos
de software, por exemplo, o histórico de versões. O conceito de hiperligação entre
documentos é utilizado para permitir a navegação entre os artefatos que podem estar
relacionados com a RM [Dal Sasso & Lanza, 2014].
Verificamos ainda no artigo proposto por Takama e Kuro-
sawa [Takama & Kurosawa, 2013] a aplicação de tecnologias de visualização de
informação empregada para o monitoramento das informações contidas nas RMs.
Uma FGRM atualiza quase toda informação de uma RM como texto, sem maiores
estruturações. A solução proposta pelos autores visa suportar o monitoramento
das RMs apresentando ao usuário da FGRM, seja ele o afetado por uma falha ou
responsável por relatar a requisição ou mesmo um membro da equipe de manutenção, a
situação das RMs mediante animações produzidas com base nas atualizações ocorridas
nas mesmas.
Por conta da natureza das melhorias propostas neste tópico de pesquisa, veri-
ficamos que diversos estudos foram implementados como protótipos. Desta forma, é
possível avaliar as propostas contidas neste tópico através das ferramentas como o
bugMaps6 [Hora et al., 2012] e In* Bug7 [Dal Sasso & Lanza, 2014].
3.3.1.2 Melhorias Propostas na Dimensão Informação
Apresentamos os trabalhos relacionados com a melhoria da qualidade da informação
fornecida na RM. A melhoria pode envolver suporte ao registro da RM antes que
ela seja armazenada na FGRMs; a melhoria também pode envolver a organização da
informação contida no relato para facilitar o entendimento pelos desenvolvedores e
demais profissionais envolvidos na manutenção do software.
5Um patch é um software projetado para atualizar um programa de computador ou seus dados de
suporte, para corrigi-lo ou melhorá-lo.
6http://rmod.lille.inria.fr/web/pier/software/BugMaps
7http://inbug.inf.usi.ch
52 Capítulo 3. Mapeamento Sistemático da Literatura
Suporte ao Registro da RM: Em geral, com base nos estudos identificados neste ma-
peamento, foi possível verificar que os trabalhos relacionado com o suporte ao registro
das RMs definem um atributo de interesse, como por exemplo a inclusão de anexos, e o
seu respectivo limiar. Caso este limiar não seja alcançado alguma ação é tomada, como
por exemplo, a exibição de uma mensagem de alerta para o responsável pela criação da
RM. Uma possível definição do que seria uma descrição com qualidade de um problema
de software foi feita pelo estudo de Zimmermann e outros [Zimmermann et al., 2010]
utilizando uma pesquisa com profissionais envolvidos com manutenção de software.
Em outro estudo os próprios autores definiram as métricas que posteriormente foram
utilizadas para avaliar o relato da RM [Tu & Zhang, 2014].
Nos artigos encontrados verificamos uma outra linha de estudo que tem como
objetivo suportar a reprodução da falha do software. Estes estudos incluem tanto
registrar o conjunto de ações que podem ter resultado na falha [White et al., 2015],
quanto em autocompletar o texto que compõe o relato da RM [Moran et al., 2015].
Um ponto em comum destes dois estudos é que eles foram pensados para o ambiente
de desenvolvimento de aplicações para dispositivos móveis, mais especificamente para
dispositivos baseados no sistema Android8. Uma possível justificativa para o foco
em aplicações móveis pode ser a dificuldade em registrar uma falha neste tipo de
ambiente [White et al., 2015, Moran et al., 2015].
Muitos dos estudos resultaram em ferramentas com a finalidade de realizar uma
prova de conceito sobre como ajudar ao Reportador a fornecer um relato de boa
qualidade [Tu & Zhang, 2014, Zimmermann et al., 2010, Kaiser & Passonneau, 2011,
White et al., 2015, Moran et al., 2015].
Organização da Informação da RM: Em diversas situações o desenvolvedor precisa
examinar manualmente o relato das RMs que podem variar em tamanho e complexi-
dade [Mani et al., 2012]. Neste contexto, o resumo (sumarização) automático do texto
contido em uma RM é uma maneira de reduzir a quantidade de dados que o desenvol-
vedor precisa analisar. A ferramenta denominada AUSUM [Mani et al., 2012] propõe
uma abordagem, utilizando técnicas não supervisionadas de aprendizado de máquina,
para aprender e sumarizar um ou mais relatos relacionados.
3.3.1.3 Melhorias Propostas na Dimensão Processo
Identificação de RMs Duplicadas O processo de identificação de RMs duplicadas
consiste em avaliar se duas ou mais RMs correspondem a uma mesma requisição. A lite-
8https://www.android.com/
3.3. Resultados 53
ratura discute dois tipos de tratamento para o problema [Kaushik & Tahvildari, 2012,
Tian et al., 2012]:
(i) remoção de duplicadas
(ii) identificação de duplicatas
No primeiro tipo, o objetivo é evitar que RMs duplicadas sejam inseridas no re-
positórios de RMs e, desta forma, reduzir o esforço e o tempo extra necessário para
identificá-las posteriormente. Por outro lado, no segundo tipo o objetivo é sugerir
uma lista de possíveis duplicatas durante o processo de registro de uma nova RM.
Um ponto importante é que o segundo tipo se baseia na premissa que registrar um
mesmo problema por mais de uma vez nem sempre é ruim, já que a possível “cópia”
pode fornecer informações adicionais [Bettenburg et al., 2008]. É importante que no-
vas abordagens tentem equilibrar estes dois tipos de tratamento para evitar o tempo
extra para análise de uma RM bem como apoiar os desenvolvedores com informações
adicionais [Lerch & Mezini, 2013, Thung et al., 2014a].
Uma forma de tratar o problema é utilizar modelos de espaços vetoriais para medir
a similaridade entre as RMs [Liu & Tan, 2014, Sun et al., 2010, Thung et al., 2014a,
Tomašev et al., 2013]. Outros trabalhos tentam utilizar técnicas em que os ter-
mos específicos do domínio do projeto de software, contidos no relato das RMs,
são utilizados na determinação da probabilidade que duas requisições sejam dupli-
cadas [Hindle et al., 2016, Alipour et al., 2013]. Em resumo verificamos que o relato
contido na RM é utilizado como fonte de informação para técnicas de Recuperação da
Informação visando determinar a similaridade entre duas RMs.
Atribuição de RM: Os estudos apresentados neste tópico foram classificados pela
pertinência com a automatização do processo de encontrar o desenvolvedor mais apto
para solucionar determinada RM. A principal fonte de informação utilizada nas abor-
dagens propostas é o relato contido na RM, todavia, outros dados são utilizados,
tais como a prioridade [Tian et al., 2015], registros (log) do sistema de controle de
versão [Shokripour et al., 2012, Hu et al., 2014] e itens do contexto do projeto como
por exemplo: o perfil e preferências do desenvolvedor, quantidade de RMs atribuídas
e o tempo estimado de correção [Hosseini et al., 2012]. Em outros trabalhos verifi-
camos que é explorada a característica colaborativa que existe no processo de tria-
gem das RMs. Nestes estudos é desenvolvida uma “rede de colaboração” que possi-
bilita determinar o desenvolvedor mais apto [Zhang et al., 2014, Zanetti et al., 2013,
54 Capítulo 3. Mapeamento Sistemático da Literatura
Wu et al., 2011]. Em geral técnicas de Recuperação da Informação (RI) são utilizadas
pelos estudos que espaço vetorial e ranqueamento de páginas.
Classificação da RM: Os estudos neste tópico visam automatizar o processo de clas-
sificação de uma RM. Este tipo de abordagem faz uso da funcionalidade de atribuição
de rótulos que é comum a grande parte das FGRMs. Em muitos projetos esta atividade
é realizada manualmente pelo Escalonador, Desenvolvedor ou Analista de Qualidade,
o que pode resultar em classificações equivocadas.
Esta classificação pode ser realizada pelo tipo de manutenção (Corretiva, Adap-
tativa, Perfectiva e Preventiva), se a RM trata de questões relativas à segurança do
sistema [Gegick et al., 2010, Behl et al., 2014] ou pelo nível de prioridade que a requi-
sição deve ser analisada [Behl et al., 2014].
Estimativa de Esforço da RM: Identificamos três tipos de estimativas de esforço
relacionadas a uma RM: determinar o tempo para solucionar novas RMs; definir os
artefatos que são impactados pela RM; prever o número de RMs que poderão surgir em
futuras versões do sistema. Nos estudos que tratam da primeira forma de estimativa a
preocupação é o tempo necessário para tratar a mudança solicitada em determinada re-
quisição. A principal complexidade está em produzir uma estimativa precisa em função
das muitas atividades envolvidas e dos diferentes níveis de capacitação do responsável
pela execução das tarefas [Xia et al., 2015]. No segundo grupo temos os artigos que
tentam identificar previamente o conjunto de artefatos que serão impactados pela tarefa
de manutenção [Nagwani & Verma, 2010]. Neste mapeamento o foco foi em estudos
em que as RMs são o ponto de partida para a análise de impacto. O último grupo
de estudos discute técnicas sobre como prever o número de RMs que possivelmente se-
rão incluídas em futuras versões do sistema. A predição do que será registrados inclui
RMs que não existiam em versões anteriores como aquelas que serão reabertas, ou seja,
problemas que não foram solucionados previamente [Xia et al., 2015].
3.3.1.4 Melhorias Propostas na Dimensão Usuário
Recomendação de RM: Os estudos deste tópico dão suporte aos desenvolvedores
com pouca experiência mediante a redução da curva de aprendizagem. Para facili-
tar a inclusão de desenvolvedores menos experientes alguns estudos propõem siste-
mas de recomendação de RMs [Malheiros et al., 2012, Wang & Sarma, 2011]. Estes
sistemas podem ajudar o recém-chegado a solucionar uma RM mediante a apresen-
tação do código fonte potencialmente relevante que o ajudará na solução do pro-
3.3. Resultados 55
blema [Malheiros et al., 2012]. O segundo tipo de abordagem pode ser vista como
ambiente de exploração do repositório de RMs. Esta funcionalidade permite que novos
desenvolvedores pesquisem descrições das requisições que possam ser do seu interesse
bem como dos artefatos relacionados (por exemplo, arquivos relacionados, desenvolve-
dores contribuintes, registros de comunicação) [Wang & Sarma, 2011]. Com base nos
estudos que compõem esta categoria, verificamos que modelos de RI vêm sendo utiliza-
dos para possibilitar a recomendação das RMs, tais como VSM [Wang & Sarma, 2011]
e o modelo estatístico PPM [Malheiros et al., 2012].
3.3.2 Suporte aos Papéis desempenhados na Manutenção de
Software
Nesta subseção são discutidos os estudos que foram considerados relacionados com pa-
peis abordados na Subseção 2.1.3. A Tabela 3.4 exibe o total de artigos por papel que
a funcionalidade proposta visa dar suporte. Como pode ser observado verificamos um
maior número de estudos para os papéis de Escalonador e Desenvolvedor. Na Tabela 3.5
é possível observar os estudos por papel que consideramos que eles podem oferecer su-
porte. Durante a nossa classificação verificou-se que um mesmo estudo poderia dar
suporte a mais de um papel. Por exemplo, o estudo de Zimmermann e outros propõe
uma ferramenta que mede a qualidade do relato das RMs e recomenda quais elemen-
tos devem ser adicionados para melhorar a qualidade [Zimmermann et al., 2010]. Os
possíveis benefícios podem ajudar o Reportador, que pode ter reduzido o tempo para
analisar a RM que ele registrou já que a RM fornece a informação necessária para sua
análise; o Desenvolvedor, que recebe uma RM com mais qualidade nos dados forneci-
dos; o Analista de Qualidade que consegue avaliar se a RM foi atendida tendo em vista
a maior facilidade em entender o que foi solicitado.
Papel Total de Artigos
Escalonador 27
Desenvolvedor 26
Analista de Qualidade 13
Gerente de Requisição de Mudança 11
Atribuidor 9
Reportador 6
Líder da Manutenção 4
Todos 3
Tabela 3.4. Total de artigos por papel na manutenção de software
56 Capítulo 3. Mapeamento Sistemático da Literatura
Papel Suportado Estudos
Escalonador
[Gegick et al., 2010, Izquierdo et al., 2015, Liu & Tan, 2014]
[Nagwani et al., 2013, Behl et al., 2014, Chawla & Singh, 2015]
[Mani et al., 2012, Sun et al., 2011, Somasundaram & Murphy, 2012]
[Bhattacharya & Neamtiu, 2011, Kaiser & Passonneau, 2011, Zhang et al., 2014, Zanetti et al., 2013]
[Valdivia Garcia & Shihab, 2014, Koopaei & Hamou-Lhadj, 2015, Prifti et al., 2011]
[Thung et al., 2014a, Tian et al., 2013, Lerch & Mezini, 2013, Tomašev et al., 2013]
[Tian et al., 2012, Song et al., 2010]
[Aggarwal et al., 2014, Nagwani & Verma, 2010, Tu & Zhang, 2014]
[Otoom et al., 2016, Liu et al., 2013]
Atribuidor
[Hosseini et al., 2012, Tian et al., 2015, Shokripour et al., 2012]
[Naguib et al., 2013, Xuan et al., 2012, Wu et al., 2011]
[Bangcharoensap et al., 2012]
[Nagwani & Verma, 2012, Hu et al., 2014]
Analista de Qualidade
[Izquierdo et al., 2015, Gegick et al., 2010, Aggarwal et al., 2014, Zimmermann et al., 2010]
[Corley et al., 2011, Song et al., 2010, Nguyen et al., 2012, White et al., 2015]
[Thung et al., 2012b, Xia et al., 2015, Tu & Zhang, 2014, Romo & Capiluppi, 2015, White et al., 2015]
Desenvolvedor
[White et al., 2015, Zimmermann et al., 2010, Thung et al., 2014b, Nguyen et al., 2012]
[Wang & Sarma, 2011, Romo & Capiluppi, 2015, Valdivia Garcia & Shihab, 2014, Nagwani & Verma, 2010]
[Koopaei & Hamou-Lhadj, 2015, Prifti et al., 2011, Thung et al., 2012b, White et al., 2015]
[Tomašev et al., 2013, Thung et al., 2013, Banitaan & Alenezi, 2013, Corley et al., 2011]
[Vijayakumar & Bhuvaneswari, 2014, Gegick et al., 2010, Izquierdo et al., 2015, Tian et al., 2012]
[Malheiros et al., 2012, Song et al., 2010, Mani et al., 2012]
[Tu & Zhang, 2014, Aggarwal et al., 2014, Wong et al., 2014]
Gerente de Requisição de Mudança
[Vijayakumar & Bhuvaneswari, 2014, Mani et al., 2012, Hindle et al., 2016]
[Gegick et al., 2010, Sun et al., 2010, Alipour et al., 2013, Zhang & Lee, 2011]
[Nagwani & Verma, 2010, Kochhar et al., 2014, Banerjee et al., 2012, Valdivia Garcia & Shihab, 2014]
Líder da Manutenção [Vijayakumar & Bhuvaneswari, 2014, Tian et al., 2012, Netto et al., 2010, Nagwani & Verma, 2010]
Reportador [Zimmermann et al., 2010, Tu & Zhang, 2014, Vijayakumar & Bhuvaneswari, 2014][Moran, 2015, Thung et al., 2014a, Moran et al., 2015]
Todos [Hora et al., 2012, Takama & Kurosawa, 2013, Dal Sasso & Lanza, 2014]
Tabela 3.5. Lista de artigos de acordo com o papel suportado
Escalonador Esta função planeja a fila de RMs. Para dar suporte a essa atividade
os estudos propõem classificação automatizada [Gegick et al., 2010, Liu & Tan, 2014,
Behl et al., 2014, Chawla & Singh, 2015, Tian et al., 2015]; visualização das RMs ar-
mazenadas no repositórios de RMs [Izquierdo et al., 2015]; agrupamento (clustering)
das requisições [Liu & Tan, 2014]; identificação do tempo necessário para solucionar
a RM (time to fix ) [Hosseini et al., 2012, Bhattacharya & Neamtiu, 2011]; sumariza-
ção da informação contida na RM [Mani et al., 2012]; determinação de RMs duplica-
das [Sun et al., 2011, Kaiser & Passonneau, 2011].
Atribuidor Esta função essencialmente deve atribuir as RMs aos desenvol-
vedores considerando o planejamento do Escalonador. Idealmente deve-se
selecionar o desenvolvedor mais apto [Banitaan & Alenezi, 2013]. Alguns tra-
balhos descrevem técnicas de atribuição automática [Banitaan & Alenezi, 2013,
Shokripour et al., 2012, Somasundaram & Murphy, 2012, Naguib et al., 2013,
Zhang et al., 2014, Zanetti et al., 2013].
3.3. Resultados 57
Desenvolvedor: Apresentamos aqui os trabalhos com foco em aspectos de codifi-
cação, depuração e testes. No suporte ao desenvolvedor identificamos estudos que
propõem a atribuição de RMs a um conjunto de desenvolvedores, em contraposi-
ção da tradicional atribuição a um único desenvolvedor [Banitaan & Alenezi, 2013],
visando minimizar os problemas decorrentes da propriedade de código e pro-
piciar um maior nivelamento de informações entre os membros da equipe.
Não obstante, o maior grupo de estudos nesta categoria está relacionado com
a ajuda ao desenvolvedor na vinculação de determinado problema do soft-
ware à sua efetiva origem, que nesta dissertação foi denominado como Lo-
calização do Problema [Corley et al., 2011, Wong et al., 2014, Thung et al., 2014b,
Nguyen et al., 2012, Thung et al., 2013, Romo & Capiluppi, 2015]. Nesta mesma ca-
tegoria verificamos estudos que dão suporte ao desenvolvedor na classificação da RM
que lhe foi atribuída, em especial aquelas que estão relacionadas às questões de segu-
rança do sistema [Gegick et al., 2010] ou aquelas que impedem a resolução de outras
(blocking-bugs) [Valdivia Garcia & Shihab, 2014].
Analista de Qualidade: Cabe ao Analista de qualidade avaliar se uma RM consi-
derada “solucionada” por um desenvolvedor foi corretamente resolvida. De maneira
similar ao que ocorre nos estudos que estão relacionados com o tópico de classifica-
ção “Desenvolvedor” verificamos uma prevalência dos estudos com foco no apoio para
encontrar o defeito no código fonte a partir do relato da falha durante execução do soft-
ware [Corley et al., 2011, Wong et al., 2014, Thung et al., 2014b, Nguyen et al., 2012,
Thung et al., 2013, Romo & Capiluppi, 2015]. Verificamos ainda estudos que tentam
determinar a probabilidade que determinada RM será reaberta [Xia et al., 2015], o
que pode ajudar ao Analista de Qualidade na priorização das requisições com alta
possibilidade de reabertura.
Gerente de Requisição de Mudança: O papel que representa esta classe está
vinculado ao gerenciamento do processo de manutenção de software, em especial
por decidir se uma RM será aceita ou rejeitada. As melhorias relacionadas à
classificação quanto ao nível de segurança [Gegick et al., 2010, Zhang & Lee, 2011,
Valdivia Garcia & Shihab, 2014], identificação de duplicadas [Hindle et al., 2016,
Sun et al., 2010, Alipour et al., 2013, Banerjee et al., 2012] pode ajudar no desempe-
nho desta atividade.
Reportador: Os estudos que fazem parte desta categoria partem da premissa que me-
lhorar a qualidade da informação fornecida na RM é o ponto de partida para tratar ou-
58 Capítulo 3. Mapeamento Sistemático da Literatura
tros problemas relacionados ao processo de manutenção de software [Moran et al., 2015,
Moran, 2015, Zimmermann et al., 2010]. Neste sentido verificamos trabalhos para au-
tocompletar as informações fornecidas pelo Reportador [Moran et al., 2015], suporte
à reprodução do problema [Moran, 2015]; análise da qualidade da informação forne-
cida [Zimmermann et al., 2010, Tu & Zhang, 2014]. Esta categoria também contempla
um estudo que verifica se o problema relatado já foi registrado [Thung et al., 2014a].
Chefe da Manutenção: O Chefe da Manutenção tem por responsabilidade definir
os padrões e procedimentos que compõem o processo de manutenção que será utili-
zado. Para ajudar neste trabalho alguns estudos propõem melhorar a alocação de
tarefas do processo de resolução das Requisições de Mudanças [Netto et al., 2010].
Outros estudos visam estimar o esforço necessário para solucionar determinada
RM [Vijayakumar & Bhuvaneswari, 2014, Nagwani & Verma, 2010], estes aspectos
têm o potencial de ajudar o Chefe de Manutenção no planejamento de liberações de
novas versões do sistema mantido.
Todos: Esta categoria abarca os estudos para o qual a melhoria proposta possui im-
pacto positivo para todos os papéis envolvidos na manutenção de software. A definição
que o foco da melhoria é geral decorre do que foi dito como objetivo dos autores dos
estudos que fazem parte desta categoria ou ainda por não ser possível determinar uma
atividade específica sendo beneficiada.
Conforme pode ser observado, os estudos estão relacionados principalmente
com a melhoria da visualização das informações contidas nas RMs [Hora et al., 2012,
Takama & Kurosawa, 2013, Dal Sasso & Lanza, 2014]. Os aperfeiçoamentos podem
estar vinculados a questões de usabilidade das ferramentas, como por exemplo a nave-
gabilidade entre as RMs [Dal Sasso & Lanza, 2014].
3.4 Discussão
Ao realizarmos este mapeamento verificamos uma prevalência de estudos na dimensão
Processo especialmente para os tópicos de Localização de RMs Duplicadas, Atribuição
de RMs e Classificação de RMs, respectivamente. A prevalência destes tópicos pode
estar relacionada ao fato de que eles afetam projetos de diferentes tipos e tamanhos.
No caso da Localização de RMs Duplicadas apesar de ser o de maior frequência não é
um problema identificado como o de impacto mais significativo por alguns desenvolve-
dores [Zimmermann et al., 2010].
3.5. Limitações e Ameaças à Validade 59
Dos estudos que fizeram parte do mapeamento um total de 10 foram implemen-
tados como extensões ou protótipos. No nosso entendimento este número poderia ser
maior a fim de permitir avaliações pelos profissionais envolvidos em manutenção de
software. Cabe ressaltar que no escopo de um estudo pode não estar prevista a efe-
tiva implementação da melhoria proposta de modo a ser utilizada efetivamente pelo
seu público-alvo, como por exemplo, a criação ou melhoria de uma funcionalidade em
determinada FGRM. Além disso, não colocamos como objetivo de nossa dissertação
avaliar ou discutir a facilidade que as FGRMs possuem para criar novas funcionalidades
ou melhorias.
Quando analisamos o esquema de Classificação por Papéis, verificamos uma pre-
valência de estudos com foco no papel de Escalonador. Os estudos que fazem parte
desta classe destacam que um considerável conhecimento sobre o projeto é necessário
bem como a capacidade de negociação com os desenvolvedores e demais partes interes-
sadas são importantes para o desempenho do papel. Todavia, tendo em vista o esforço
e tempo gasto por esta tarefa, especialmente quando realizada manualmente, seria im-
portante que as FGRMs automatizassem algumas destas atividades. Um outro ponto
a destacar é que as FGRMs deveriam dar suporte ao Reportador que, na maioria da
vezes, é o primeiro a registrar as informações que serão necessárias à solução da RM.
3.5 Limitações e Ameaças à Validade
Alguns dos procedimentos adotados neste trabalho não acompanharam exatamente as
diretrizes existente na literatura para condução de uma Mapeamento Sistemático. A
seleção dos estudos foi realizada pelo autor sem que outra pessoa fizesse a revisão.
O mapeamento realizado nesta pesquisa utilizou o método de aplicação de sentenças
de busca nas bases de pesquisa selecionadas para coletar os estudos primários. Ou-
tros estudos, além da estratégia descrita, fazem uso de uma técnica conhecida como
bola de neve (snowballing) [Wohlin, 2014] em que as referências dos estudos primários
podem ser usadas para compor o conjunto de artigos do mapeamento. O uso de uma
única estratégia pode levar a perda de artigos relevantes e, portanto, subestimar a
extensão dos resultados encontrados. Em particular, por termos optado por escolher
artigos apenas em língua inglesa também pode ter havido falta de material publicado
em revistas e conferências nacionais. Assim, nossos resultados devem ser considera-
dos apenas com base em artigos em inglês contidos nas bases de pesquisa escolhidas e
publicados nas principais conferências da área de Engenharia de Software.
O fato que o autor foi o único responsável pela análise dos estudos aumenta o
60 Capítulo 3. Mapeamento Sistemático da Literatura
risco de erros. O processo de seleção e validação dos estudos primários pode levar a
problemas de extração e agregação das informações quando há um grande número de
artigos ou os dados são complexos [Keele, 2007].
No tocante às questões deste estudo é possível que as perguntas de pesquisa
definidas possam não abranger completamente o campo de investigação sobre as fun-
cionalidades das FGRMs. No entanto, algumas discussões com membros do projeto e
especialistas em Manutenção de Software foram realizadas para validar as perguntas.
Assim, mesmo que não tenhamos considerado o melhor conjunto de questões, acredita-
mos que foi possível abordar as indagações mais frequentes e abertas no campo, tanto
do ponto de vista do praticante como do investigador.
Como as bases de pesquisa não funcionam com regras de busca compatíveis entre
si, todas as sequências de pesquisa foram adaptadas e calibradas em cada uma delas.
No entanto, não conhecemos todas as regras que as bases de pesquisa utilizam para
indexar um documento. Neste sentido, a forma que as sentenças de busca foram estru-
turadas pode não ser a mais otimizada para pesquisa do maior número de documentos
relevantes.
O nosso estudo considerou publicações até maio de 2016. De lá pra cá veri-
ficamos que assuntos como Identificação de RMs Duplicadas [Aggarwal et al., 2017,
Chaparro, 2017, Sadat et al., 2017] e Classificação da RM [Karim et al., 2017,
Zibran, 2016, Ohira et al., 2016] ainda permanecem entre aqueles com a maior frequên-
cia de publicação.
3.6 Trabalhos Relacionados
No estudo proposto por Kagdi e outros [Kagdi et al., 2012] foi realizada uma revisão
da literatura sobre abordagens para mineração de repositórios de RMs. No contexto
daquele trabalho este tipo de repositório pode ser comparado ao repositório de RMs
empregados nas FGRMs. O resultado foi uma taxonomia baseada em quatro classes: o
tipo de repositório extraído (o que), o propósito (por que), o método proposto (como)
e o método de avaliação (qualidade). No entanto, a sua classificação não fornece um
entendimento extensivo sobre as investigações em repositórios de RMs. De acordo com
seus critérios de exclusão para estudos, eles estavam muito preocupados com artigos
que abordavam mudanças evolutivas de artefatos de software investigando múltiplos
repositórios de RMs. Como consequência, muitos trabalhos que usaram dados de um
único repositório de RM estavam fora do seu escopo.
Por outro lado, o estudo realizado neste capítulo aumentou o escopo da análise
3.7. Resumo do Capítulo 61
sobre as funcionalidades oferecidas pelas FGRMs possibilitando um acréscimo na visão
do estado da arte deste tipo de investigação. Uma outra diferença com o trabalho
de Kagdi [Kagdi et al., 2012] é que sua taxonomia considera as técnicas e métodos
para mineração de repositórios de RMs como o foco principal do seu estudo, por outro
lado este trabalho considera as FGRM, sobre o prisma de suas funcionalidades, como
entidades de primeira classe.
Na pesquisa realizada por Cavalcanti e outros [Cavalcanti et al., 2014] houve a
classificação de estudos sobre repositórios de RMs em desafios e oportunidades. Desa-
fios referem-se a problemas enfrentados no gerenciamento das RMs, enquanto oportu-
nidades referem-se às vantagens proporcionadas pelos dados obtidos das RMs para o
desenvolvimento de software. Além disso os autores utilizam a classificação proposta
por Cerulo e Canfora [Cerulo & Canfora, 2004]. Ela consiste em duas visões sobrepos-
tas: uma taxonomia vertical que classifica os modelos de RI em relação ao seu conjunto
de características básicas; e uma taxonomia horizontal que classifica os objetos de RI
com respeito às suas tarefas, forma e contexto.
Nosso trabalho estende a classificação realizada por Caval-
canti [Cavalcanti et al., 2014] tendo em vista que avalia as funcionalidades das
FGRMs que encaixam no conceito de repositórios de RMs. Ou seja, o foco deles é no
repositório de RMs, seja ele automatizado ou não. Contudo, o nosso objeto de estudo
são as propostas de melhorias para as funcionalidades das FGRMs.
3.7 Resumo do Capítulo
Neste capítulo realizamos um mapeamento sistemático envolvendo 64 estudos divididos
em dois esquemas de classificação: dimensões de melhoria e suporte ao papel exercido
na manutenção de software. Verificamos que tópicos como Localização de RMs Du-
plicadas, Atribuição de RMs e Classificação de RMs estão sendo tratados com maior
frequência na literatura. Da mesma forma, o Escalonador e Desenvolvedor tiveram um
maior número de artigos com funcionalidades que podem dar-lhes suporte. Verificamos
ainda que é reduzido o número de estudos que efetivaram as melhorias propostas em
protótipos de ferramentas. Esta última constatação pode causar um distanciamento
entre o estado da arte e o estado da prática.

Capítulo 4
Levantamento de Funcionalidades
de FGRMs
4.1 Introdução
Neste capítulo apresentamos um levantamento por questionário com o objetivo de
coletar os aspectos mais importantes das funcionalidades oferecidas pelas FGRMs do
ponto de vista dos profissionais que trabalham com desenvolvimento e manutenção de
software. O planejamento e o desenho do estudo seguiram as diretrizes propostas nos
trabalhos de Wohlin [Wohlin et al., 2012] e Kasunic [Kasunic, 2005]. Em especial, para
selecionarmos a população e a amostra de interesse utilizamos o arcabouço (framework)
proposto por De Mello e outros [de Mello et al., 2015, de Mello et al., 2014].
Para este levantamento foi definido que a população de interesse é a comuni-
dade envolvida com o processo de manutenção de software e que faça uso de FGRMs.
Pela abrangência e dificuldade de caracterização da população acabamos por lidar com
uma amostra de conveniência. Contamos com a colaboração de profissionais que estão
envolvidos no projeto de código aberto Python1. Coletamos também a opinião de pro-
fissionais com um conjunto de características que esperamos ser mais abrangente: os
usuários da rede social de desenvolvedores Stack Overflow2. Neste último caso, estamos
interessados nos usuários da rede que tenham participado de discussões sobre assuntos
relacionados à manutenção de software.
A contribuição deste levantamento é que ele permitiu avaliar se os estudos con-
duzidos na literatura que propõem melhorias que podem ser aplicadas para as funci-
onalidades das FGRMs estão em consonância com as necessidades dos profissionais.
1http://bugs.python.org/
2http://stackoverflow.com
63
64 Capítulo 4. Levantamento de Funcionalidades de FGRMs
Neste sentido é possível analisar como está o distanciamento entre o estado da arte e
o da prática.
4.2 Objetivo do Levantamento com Profissionais
Em linhas gerais, o objetivo desta etapa do projeto da dissertação é analisar, através
da percepção e opinião dos profissionais envolvidos em Manutenção de Software, a
situação das funcionalidades atualmente oferecidas pelas FGRMs, bem como sobre a
adoção das práticas propostas pelos agilistas no processo de manutenção de software.
Com intuito de atingir os objetivos propostos foram definidas as seguintes questões de
pesquisa:
Questão 01 Qual a opinião dos profissionais envolvidos em Manutenção de Software
com relação as funcionalidades oferecidas pelas FGRM?
Questão 02 Na visão dos profissionais envolvidos em Manutenção de Software quais
melhorias nas funcionalidades das FGRMs propostas na literatura teriam maior
relevância em suas atividades?
Questão 03 As práticas propostas pelos agilistas estão sendo utilizadas no processo
de Manutenção de Software?
Questão 04 Como as FGRMs podem ajudar as equipes de manutenção na adoção
das práticas propostas pelos agilistas?
O desenho da pesquisa é detalhado na próxima seção onde discutimos a estru-
tura do questionário bem como detalhamos o processo de seleção da amostra que foi
utilizado.
4.3 Desenho e Método da Pesquisa com
Profissionais
4.3.1 Conceitos Básicos
Estudos primários em Engenharia de Software (SE), como os levantamentos por ques-
tionário, são muitas vezes conduzidos em amostras que são mais de conveniência
do que adequadas [Sjøberg et al., 2005, Dybå et al., 2006]. Um desafio na determi-
nação de amostras representativas, especialmente em Engenharia de Software, é a
4.3. Desenho e Método da Pesquisa com Profissionais 65
identificação de fontes relevantes e disponíveis que permitam a criação de amostra-
gem [de Mello et al., 2014]. Uma alternativa é a utilização de fontes disponíveis na
Internet, como rede sociais e projetos de código aberto, que permitem aumentar o
acesso à potenciais participantes [de Mello & Travassos, 2013].
O levantamento descrito neste capítulo consistiu de um estudo exploratório sem
uma hipótese prévia. Idealmente, ele deveria ser respondido por todos os profissio-
nais envolvidos com desenvolvimento e manutenção de software. Como não é possível
alcançar essa população, nos conformamos com a utilização de uma amostra de conve-
niência. Neste tipo de amostragem a seleção de indivíduos é realizada por conta de sua
facilidade de acesso ou proximidade [Marshall, 1996]. Este é um dos riscos à validade
do estudo e é discutido na Seção 4.3.2.1.
Para caracterizar a amostra foi utilizado o estudo de Mello e ou-
tros [de Mello et al., 2014]. Nele os autores apresentam um arcabouço (framework)
conceitual para a determinação de fontes adequadas para amostragens com foco em
estudos na área de Engenharia de Software. Decidimos utilizar alguns aspectos deste
arcabouço para discutir algumas características da nossa amostra. O modelo inclui
termos estatísticos, tais como público-alvo, população, amostragem e unidade de ob-
servação [Thompson, 2012], e discute conceitos como Fonte de Amostragem, Unidade
de Pesquisa, Plano de Pesquisa e Estratégia de Amostragem. No estudo os autores
apresentam alguns atributos, denominado Requisitos Essenciais - Essential Requeri-
ments (ER), que podem ser utilizadas para determinar que uma Fonte de Amostragem
é válida e que estão descritos a seguir.
ER1 Uma Fonte de Amostragem não deve representar intencionalmente um subcon-
junto segregado do público-alvo, ou seja, dado um público-alvo “X”, não seria ade-
quado pesquisar por unidades na fonte intencionalmente desenhada para compor
um subconjunto específico de “X”.
ER2 Uma Fonte de Amostragem não deve apresentar qualquer viés, como incluir na
sua base de dados determinados subconjuntos do público-alvo. Critérios desiguais
para inclusão de Unidades de Pesquisa significam oportunidades desiguais para
oportunidades de amostragem.
ER3 Todas as Unidades de Pesquisa3 das amostras e suas Unidades de Observação4
devem identificados de forma única.
3Uma Unidade de Pesquisa caracteriza como uma ou mais Unidade de Observação podem ser
recuperadas de uma Fonte de Amostragem.
4Unidade de Observação é a entidade que é estudada em determinado experimento.
66 Capítulo 4. Levantamento de Funcionalidades de FGRMs
ER4 Todas as amostragem de determinada Unidade de Pesquisa devem ser acessíveis.
Se houver unidades de pesquisa ocultas, não é possível contextualizar a população.
4.3.2 Método de Pesquisa
No escopo deste levantamento, o público-alvo é o conjunto de profissionais que traba-
lham com desenvolvimento e manutenção de software. Adicionalmente, seria impor-
tante que o participante tivesse um mínimo de experiência de uso de alguma FGRM. A
caracterização e estratificação da população que temos interesse não é simples. Neste
sentido, é difícil dizer que um extrato com uma certa experiência com FGRMs é mais
relevante do que outro ou ainda questões como processo de software ou linguagem de
programação. Salvo melhor juízo, todos os desenvolvedores de código aberto e có-
digo proprietário, que de alguma forma tenham utilizado alguma FGRM, podem ser
relevantes nesta investigação.
4.3.2.1 Fontes de Amostragem
Uma Fonte de Amostragem corresponde a um banco de dados, não necessariamente
automatizado, em que um subconjunto válido da população pode ser recuperado. Ou-
tra característica é permitir a extração aleatória de amostras da população de inte-
resse [de Mello et al., 2014]. Utilizamos nesta dissertação as duas Fontes de Amostra-
gem exibidas na Tabela 4.1. Na primeira fonte, temos a expectativa de encontrar-
mos indivíduos ligados ao desenvolvimento da linguagem Python que correspondam
ou representem profissionais do extrato de código aberto. A segunda fonte, FA02,
corresponde a indivíduos com interesse na rede social Stack Overflow em que é possí-
vel que encontremos um perfil mais abrangente de desenvolvedores e mantenedores de
software5.
Identificador Fonte de Amostragem URL
FA01 Python https://bugs.python.org/
FA02 Stack Overflow https://stackoverflow.com
Tabela 4.1. Fontes de Amostragem utilizadas no estudo
A fonte FA01 foi utilizada por apresentar as seguintes características: (i) pelo
menos 5 anos de existência; (ii) comunidade bem estabelecida, no sentido de um nú-
mero relevante e participativo de contribuidores e usuários; (iii) permite acesso aos
5Não tentamos distinguir se o foco da atividade do usuário do Stack Overflow é desenvolvimento,
manutenção ou outra categoria
4.3. Desenho e Método da Pesquisa com Profissionais 67
dados históricos de suas RMs. Por outro lado, a fonte FA02 foi selecionada devido sua
extensão: envolve mais de 6 milhões de usuários e poderia nos fornecer o acesso a um
perfil abrangente de participantes.6.
O fato de lidarmos com amostras de conveniência pode resultar em limitações
devido a forma subjetiva que a amostra se apresenta. Uma amostra de conveniência
se apresenta quando a randomização não é possível, como no caso de uma população
muito grande ou de difícil caracterização [Boxill et al., 1997]. Os requisitos ER1 e
ER2, apresentados na Seção 4.3 são atendidos no sentido que cada membro vinculado
a uma das FAs têm igual possibilidade de participação no levantamento. O requisito
ER3 foi atendido pela atribuição de um identificador único para cada participante que
foi coletado pelo processo de extração. Considerando que as FAs consideram apenas
usuários com o endereço eletrônico público, o requisito ER4 é atendido no sentido que
os participantes estão de alguma forma acessíveis.
4.3.2.2 Construção das Fontes de Amostragem
Cada Fonte de Amostragem (FA) utilizou uma estratégia distinta para a sua construção.
Para a FA01 utilizamos a lista de RMs disponível na Internet através da FGRM do
projeto7. No caso da FA02 a fonte primária de informação são as discussões realizadas
pelos seus usuários, especialmente aquelas sobre a temática da Manutenção de Software.
Em ambos os casos foram coletados automaticamente os atributos:
• Nome do Participante
• E-mail do Participante
• Data de Ação
• Tipo de Ação
O Tipo de Ação representa aquilo que o participante realizou na lista de discussão
ou na rede social. Exemplos de ação estão no relato ou solução de RM, no caso da
FA01 ou ainda responder a uma pergunta de determinada discussão, no caso da FA02.
O tipo e a data da Ação foram utilizados para avaliar se o indivíduo estaria no conjunto
final de potenciais participantes do estudo. Além daqueles atributos, foram coletadas
outras informações através do questionário de pesquisa, como por exemplo a localização
geográfica, o tempo de experiência, o nome da função desempenhada, as principais
atribuições, dentre outros.
6Disponível em http://stackexchange.com/sites. Acessado em novembro de 2016.
7http://bugs.python.com
68 Capítulo 4. Levantamento de Funcionalidades de FGRMs
No caso do Stack Overflow utilizamos para seleção dos participantes uma métrica
da própria rede social conhecida como reputação8. Trata-se de uma medida aproximada
de quanto a comunidade avalia as contribuições de um usuário. Neste trabalho ela foi
utilizada como um dos critérios de seleção do participante, que incluiu ainda a sua
frequência de participação em discussões sobre Manutenção de Software.
Para extrairmos os dados da rede social Stack Overflow utilizamos a interface de
busca avançada que a plataforma disponibiliza e que permite consultar e analisar os
dados de todos as páginas da rede Stack Exchange9. A interface possibilita a utilização
da linguagem SQL para acesso aos dados. A Figura 4.1 exibe uma tela da interface
utilizada para coleta dos dados.
Figura 4.1. Ferramenta de coleta de dados da rede Stack Overflow
Para a fonte FA01 foi desenvolvido um robô (web crawler) para coletar as infor-
mações dos participantes. A partir de uma lista de RMs previamente selecionada, a
ferramenta coletou os dados dos possíveis participantes a partir do histórico de modi-
ficações de cada RM. A Figura 4.2 apresenta o histórico de registros de uma RM do
projeto Python em que os dados dos participantes podem ser visualizados nos quadros
inseridos. Os dados coletados também foram armazenadas em um banco de dados para
posterior aplicação de critérios de inclusão e exclusão.
4.3.2.3 Seleção dos Participantes
Utilizamos estratégias distintas em cada fonte de amostragem para escolher os potenci-
ais participantes do levantamento. Para a fonte FA01 utilizamos os registros históricos
das RMs ocorridos nos últimos 05 anos. Além disso, foi coletada a frequência que
8http://stackoverflow.com/help/whats-reputation
9http://data.stackexchange.com/stackoverflow
4.3. Desenho e Método da Pesquisa com Profissionais 69
Figura 4.2. Histórico de relatos de uma RM do projeto Python
o participante teve contato com o projeto, como por exemplo abertura, solução ou
comentários em RMs. Um participante seria incluído caso tivesse pelo menos uma
interação no período avaliado.
No caso do Stack Overflow realizamos a busca de discussões com base nas sen-
tenças de busca exibidas na Figura 4.3. Um conjunto similar de sentenças foi utilizado
no mapeamento sistemático descrito no Capítulo 3. De modo a considerar as prefe-
rências de privacidade dos indivíduos que iriam compor as Fontes de Amostragens,
não incluímos os participantes que proíbem a utilização dos seus dados, especialmente
do seu endereço eletrônico. Nesta mesma linha, não incluímos pessoas que utilizam
uma língua diferente do inglês, tendo em vista que apenas existiam versões em inglês
e português para o questionário utilizado no estudo.
Figura 4.3. Sentenças utilizadas para seleção das discussões no Stack Overflow
70 Capítulo 4. Levantamento de Funcionalidades de FGRMs
4.3.2.4 Formulário
O formulário enviado aos participantes foi estruturado em três partes, cada uma cole-
tando um conjunto de informação. Na primeira estávamos interessados na formação do
participante. O segundo conjunto de perguntas tinha por objetivo coletar a percepção
dos participantes sobre as funcionalidades oferecidas pelas FGRMs. Na terceira parte
estão as perguntas sobre as melhorias e proposição de novas funcionalidades para as
FGRMs. Antes de aplicarmos o questionário foi realizado um processo de avaliação
constituído de quatro etapas:
(i) Avaliação por Pesquisadores: Nesta etapa a primeira versão do formulário foi
enviada para dois pesquisadores da área de manutenção de software.
(ii) Avaliação por Profissionais: O formulário resultante da análise anterior foi enca-
minhado a dois profissionais que trabalham com manutenção de software.
(iii) Piloto da Pesquisa: O formulário obtido da fase anterior foi utilizado em um piloto
com dez profissionais envolvidos da manutenção de software de uma empresa
pública de informática.
(iv) Tradução do Formulário: Em cada uma das etapas anteriores o formulário foi
aplicado em português, tendo em vista a falta de fluência em Inglês de alguns
profissionais envolvidos no processo de avaliação, em especial na fase Piloto da
Pesquisa. Neste sentido, a última etapa consistiu na tradução do formulário para
a língua inglesa. Esta etapa foi conduzida com o suporte de um pesquisador
experiente na área de Engenharia de Software.
Após o processo de avaliação do questionário10, enviamos uma mensagem de cor-
reio eletrônico solicitando a colaboração com nosso trabalho de mestrado. O gabarito
(template) da mensagem enviada pode ser visualizado no Apêndice F. Foram envi-
adas um total de 452 mensagens de correio eletrônico no período de 02/01/2017 a
27/01/2017.
4.4 Resultados
Nesta seção apresentamos os resultados obtidos na aplicação do questionário. Após o
envio das mensagens obtivemos 85 participações. É importante salientar que nenhuma
10A versão final do questionário pode ser encontrada em https://archive.org/download/
dissertacao-vagner-clementino-um-estudo/form-melhorias-funcionalidades.pdf
4.4. Resultados 71
das questões do formulário era de preenchimento obrigatório, desta forma, alguns dos
resultados não necessariamente apresentam o total de respostas recebidas. Começamos
com a análise do perfil dos respondentes. Em seguida, avaliamos o nível de satisfação
com as ferramentas que utilizam. Posteriormente verificamos o grau de adoção das
práticas propostas pelos agilistas no processo de desenvolvimento e manutenção de
software.
4.4.1 Perfil dos Participantes
O total para cada função declarada pelos participantes pode ser visualizado na Ta-
bela 4.2. A função com maior frequência é a de desenvolvedor, com cerca de um terço
dos participantes. Todavia, grande parte dos respondentes pode estar envolvida com
tarefas de desenvolvimento e manutenção de software, uma vez que mais de 80% da
amostra é formada por desenvolvedores, engenheiros de software, gerentes e arquitetos.
Função Desempenhada Total
Desenvolvedor 23
Engenheiro de Software 17
Gerente 12
Arquiteto de Software 5
Pesquisador 5
Consultor 4
Estudante 3
Analista de Qualidade 1
Designer 1
Tabela 4.2. Função desempenhada pelos participantes
A distribuição geográfica dos participantes demonstra uma proeminência de pes-
soas da Ásia (32%), Europa (27%) e em seguida das América do Norte (17%) e América
do Sul (12%). A Tabela 4.3 exibe o total de participações por localização geográ-
fica. Esta distribuição pode atenuar possíveis enviesamentos que por ventura algum
nicho geográfico possa apresentar. Todavia, não está no escopo deste estudo discutir
como que as diferenças de localização do participante podem influenciar nos resultados.
Os respondentes trabalham em sua maioria em empresas privadas de software (74%).
Existem também aqueles que participam de projetos de código aberto (6%) e empresa
pública de software (4%). O restante do grupo que respondeu esta questão é composto
por contribuidores de projetos de software livre e estudantes. É importante considerar
que grande parte dos respondentes pertencem à empresas privadas, em que os proces-
sos e ferramentas não podem ser modificados pelo desenvolvedor. Esta característica
72 Capítulo 4. Levantamento de Funcionalidades de FGRMs
pode afetar os resultados, especialmente quando avaliarmos o nível de satisfação das
funcionalidades das FGRMs.
Localização Participações
Asia 28
Europa 23
América do Norte 15
América do Sul 11
Africa 4
América Central 2
Oceania 2
Tabela 4.3. Localização Geográfica dos Participantes
A equipe que o participante faz parte possui em geral mais de dez pessoas (31%).
Em segundo lugar, temos equipes de médio porte, entre seis e dez membros (28%). A
Tabela 4.4 apresenta a frequência de respostas para o tamanho da equipe. Os parti-
cipantes possuem com maior frequência entre três e dez anos de experiência. Existem
ainda 09 participantes que possuem mais de dez anos trabalhando com desenvolvimento
ou manutenção de software. Em síntese, temos um grupo com significativa experiência
o que pode agregar valor aos resultados finais.
Tamanho da Equipe Número de Respostas
Mais do que 10 23
Entre 6 e 10 21
Entre 2 e 5 1
1 (eu mesmo) 13
Tabela 4.4. Tamanho da equipe dos participantes
4.4.2 Nível de Satisfação com as FGRM
A avaliação da ferramenta utilizada pelo participante é importante tendo em vista
que as opiniões dadas podem estar relacionadas com a versão utilizada, podendo os
resultados se mostrarem diferentes se a pesquisa fosse realizada com outras versões
dos sistemas. A maior frequência ocorre para a ferramenta Jira (28%). Na segunda
posição visualizamos o Github (17%) que é um serviço de web para armazenamento
de projetos que usam o controle de versionamento Git e que possui um módulo que
oferece funções existentes nas FGRMs. Uma outra ferramenta bem posicionada foi o
Trello (10%), que é um software de planejamento no estilo Kanban e que segundo os
4.4. Resultados 73
nossos resultados está sendo utilizado para gestão das RMs. Um conjunto de dezenove
ferramentas, correspondendo a um total de 32% das respostas, foram escolhidas uma
única vez, dando um indício da extensão das FGRMs disponíveis.
Verificamos o nível de satisfação dos participantes com as funcionalidades ofereci-
das pelas FGRMs que ele utiliza. Em grande parte os respondentes estão satisfeitos com
as funcionalidades. A resposta com maior frequência foi Nem satisfeito ou insatisfeito,
com cerca de 32 (44%) respostas. Na segunda posição, 21 profissionais (29%) respon-
deram que estão Satisfeitos. A opção Muito satisfeito foi escolhida por 11 (15%) dos
profissionais. As alternativas que podem refletir uma insatisfação sobre as funcionalida-
des (Desapontado ou Muito Desapontado) foram escolhidas por 8 (11%) participantes.
O item desapontado teve 6 respostas e a opção Muito Desapontado foi escolhida por 2
participantes. Se desconsiderarmos aqueles que selecionaram Nem satisfeito ou insatis-
feito, é possível verificar que a maior parte dos respondentes (44%) estão satisfeitos com
as funcionalidades da FGRM que utiliza. Em contrapartida, os participantes insatisfei-
tos representam 11% da amostra. O número de respostas não nos permite generalizar
o resultado, entretanto, ele não segue o que a literatura sobre melhorias em funcionali-
dades das FGRMs em que se discute um possível descontentamento dos usuários deste
tipo de software. Uma possível explicação seria o desconhecimento dos profissionais de
funcionalidades que estão sendo propostas na literatura que podem melhorar as suas
atividades.
No mesmo questionário verificamos se o respondente recomendaria a ferramenta
que utiliza para outro projeto. A probabilidade de recomendação é exibida na Ta-
bela 4.5. De maneira similar ao nível de satisfação grande parte dos participantes
tendem a recomendar a FGRM. Com base neste resultado, podemos deduzir que os
profissionais estão realmente satisfeitos com as funcionalidades da ferramenta que uti-
lizam ao ponto de recomendá-la.
Recomendação da Ferramenta Utilizada Total
Com certeza 22
Provável 32
Pouco Provável 9
Muito Improvável 3
Não Recomendaria 5
Tabela 4.5. Probabilidade de Recomendação da Ferramenta Utilizada
74 Capítulo 4. Levantamento de Funcionalidades de FGRMs
4.4.3 Avaliação das Funcionalidades Existentes
Nesta seção apresentamos a opinião dos profissionais sobre as funcionalidades oferecidas
atualmente pelas FGRMs. O conjunto de funcionalidades apresentado ao participante
é o resultado do estudo descrito na Seção 2.3. No questionário apresentamos ao par-
ticipante uma lista de funcionalidades e pedimos que para cada uma fosse escolhido
um item de uma escala de importância (Nada Importante, Pouco Importante, Impor-
tante, Levemente Importante, Muito Importante). Com base nas respostas, as seguinte
funcionalidades foram consideradas como as mais importantes: Suporte ao Unicode,
Múltiplos Projetos, Integração com Sistemas de Controle de Versão (VCS Integration).
Por outro lado, apresentamos aos profissionais funcionalidades que poderiam ser
integradas à FGRM que ele utiliza. As funcionalidades foram baseadas no Mapeamento
Sistemático descrito no Capítulo 3. A Figura 4.4 apresenta as funcionalidades que os
participantes sentem falta. As funcionalidades foram apresentadas aos profissionais
através de uma lista e foi permitido que eles escolhessem mais de uma opção. As
funções tais como Identificação Automática de RMs Duplicadas, Atribuição Automática
de RM e Análise de Impacto foram de maior escolha.
4.4.4 Práticas Ágeis na Manutenção de Software
Nesta etapa do levantamento com profissionais, estamos interessados em analisar como
as práticas propostas pelos agilistas estão sendo utilizadas no desenvolvimento e em
especial na manutenção de software. Após a apresentação de um cardápio de opções,
obtidas de um livro [Meyer, 2014], os participantes selecionaram como as práticas mais
adotadas: Integração Contínua (17%), Padrões de Programação (16%), Refatoração
(15%), Reunião Diária (daily) (13%) e Propriedade compartilhada de código (10%).
A fim de avaliar como as FGRMs podem ajudar as equipes de manutenção de
software na adoção das práticas propostas pelos agilistas, apresentamos aos participan-
tes do levantamento uma lista de possíveis funcionalidades com este viés. Foi solicitado
a eles que escolhessem a ordem em que estas melhorias seriam implementadas na fer-
ramenta que utilizam, sendo 1 a maior prioridade e 7 a menor. Segundo o nosso
entendimento as funções que tivessem uma maior prioridade para serem implemen-
tadas poderiam ser consideradas mais relevantes para os profissionais. A Tabela 4.6
apresenta a opinião dos profissionais sobre as funcionalidades mais relevantes. Segundo
eles, a priorização automática de RMs urgentes e não esperadas, ajuda o desenvolve-
dor nas reuniões diárias e o suporte a tarefas compartilhadas foram as respostas mais
frequentes.
4.4. Resultados 75
Figura 4.4. Funcionalidades que o participantes sentem falta.
Melhorias Propostas Classificação
Priorização automatizada de RMs urgentes e inesperadas 1
Sugestão automatizada das RMs que farão parte da iteração. 2
Suporte aos desenvolvedores na preparação para reunião diária 3
Suporte à divisão de tarefas de forma compartilhada 4
Facilitar a propriedade compartilhada de código 5
Tabela 4.6. Classificação das funcionalidades que possam dar suporte ao uso
das práticas dos agilistas.
76 Capítulo 4. Levantamento de Funcionalidades de FGRMs
4.5 Discussão
Nível de Satisfação com a Ferramenta Utilizada: Em geral, o nível de satisfação
com as funcionalidades oferecidas pelas FGRMs é alto. Esta medida foi observada na
análise do nível da satisfação dos participantes em que verificamos que cerca de 44%
estão de alguma forma satisfeito com a ferramenta que utilizam. Em contrapartida, os
participantes que mostraram algum tipo de insatisfação representaram 11% da amostra.
Este mesmo sentimento pode ser observado pela alta probabilidade de recomendação
da FGRM utilizada para um novo projeto. Naquela medida verificamos que o mesmo
percentual de participantes pretende recomendar o software que utiliza.
Funcionalidades Faltantes: Apesar dos profissionais estarem satisfeitos com as fun-
cionalidades ofertadas pela FGRM que utilizam, quando foi apresentado um conjunto
de novas funções grande parte deles aprova a inclusão de algumas delas. Por exemplo,
cerca de um terço dos participantes disseram sentir falta de um processo de identi-
ficação automatizada de RMs duplicadas. Este resultado também foi encontrado no
trabalho de Zimmermann e outros [Zimmermann et al., 2010] que ao conduzir um le-
vantamento com questionário em que o problema da duplicação de RMs foi descrito
como um dos problemas que pode ocasionar em atrasos na solução das RMs.
Um ponto interessante é que as funcionalidades que os participantes mais sentiram
falta, também representam a maior quantidade de estudos na literatura. Posto de outra
forma, a automatização da detecção de RMs duplicadas e atribuição de RMs são as
soluções mais demandadas e representam o maior número de trabalhos na literatura.
Este resultado pode sugerir a necessidade de uma maior divulgação do que está sendo
proposto na literatura tendo em vista que os profissionais se mostraram interessados
nestes tipos de funcionalidades.
Suporte às Práticas dos Agilistas: Apesar de ser pouco discutido na literatura, as
FGRMs podem oferecer suporte às praticas propostas pelos agilistas. Os participantes
se mostraram interessados em funções tais como a priorização automática de RMs
urgentes e não esperadas, ajuda na reunião diária e o suporte a tarefas compartilhadas.
Com a crescente adoção das práticas dos agilistas por equipes de desenvolvimento e
manutenção de software seria importante que este tipo de ferramenta incorporasse em
suas funcionalidades tal tendência. Conforme discutido na Seção 2.3 as FGRMs, em
sua maioria, não apresentam funcionalidades que suportem as práticas propostas pelos
agilistas.
4.6. Ameaças à Validade 77
4.6 Ameaças à Validade
Uma ameaça à validade deste trabalho está no número de respondentes da pesquisa.
Apesar do esforço de seleção de uma amostra representativa da população o número de
participantes limita a extrapolação do resultados. O fato de ao final termos uma amos-
tragem de conveniência implica que as generalizações são limitadas. Por outra lado,
utilizamos o arcabouço proposto por de Mello [de Mello et al., 2014] visando minimizar
o enviesamento da amostra.
Não temos garantias que as regras para seleção de participantes resultaram em
um conjunto bem representativo da população. Vale ressaltar que todas as opiniões
coletadas devem levar em conta a ferramenta que o profissional utilizava quando da
aplicação do questionário. Caso este mesmo estudo fosse realizado com outras ver-
sões do mesmo sistema os resultados poderiam ser diferentes. Neste sentido, qualquer
tentativa de generalização deve observar por esta característica do estudo.
4.7 Resumo do Capítulo
Neste capítulo realizamos um levantamento mediante questionário com o objetivo de
entender e analisar a opinião de profissionais de desenvolvimento e manutenção de soft-
ware sobre as funcionalidades oferecidas pelas FGRMs. O questionário foi preenchido
por 85 participantes o que nos permitiu observar que existia um bom nível de aceitação
das funcionalidades no momento da realização do estudo. Em contrapartida, quando
apresentadas melhorias das funcionalidades da ferramenta, muito dos desenvolvedores
se mostraram interessados. As propostas de melhorias foram baseadas nos resultados
obtidos do Mapeamento Sistemático descrito no Capítulo 3. Este fato pode ilustrar
a necessidade de que os estudos propostos na literatura se integrem nas ferramentas,
através de protótipos, por exemplo, de modo a atender as necessidades dos profissio-
nais.

Capítulo 5
Sugestões de Melhorias para as
FGRMs
5.1 Introdução
No levantamento por questionário descrito no Capítulo 4 os profissionais consultados se
mostraram, em geral, satisfeitos com as funcionalidades disponibilizadas pelas FGRMs.
Cerca de 44% dos participantes fizeram uma avaliação positiva da ferramenta que
utilizavam quando consultados, além disso, também cerca de 76% dos participantes
disseram que recomendariam as FGRMs que utilizava para um novo projeto (opções
Provável e Com certeza).
Não obstante, naquela mesma pesquisa, apresentamos uma lista de possíveis novas
funcionalidades para as FGRMs e perguntamos aos participantes quais eles gostariam
que fizessem parte de uma FGRM. O resultado desta pergunta foi que cerca de 85%
se mostraram interessados na inclusão de pelo menos uma das funções propostas nas
FGRMs que utilizavam. A partir da análise deste resultado é possível inferir que o
grupo de desenvolvedores que participaram do levantamento estão satisfeitos com a
ferramenta utilizada, contudo, não conhecem ou não têm acesso ao potencial de funci-
onalidades que este tipo de software pode oferecer. Apesar do número de participações
não nos permitir extrapolar o resultado, entendemos que podemos contribuir com o
estado atual das funcionalidades das FGRMs propondo um conjunto de melhorias.
As sugestões foram construídas utilizando a literatura da área e os levantamen-
tos realizados nesta dissertação, especialmente com base nos Capítulos 3 e 4, na Se-
ção 2.3 e nos estudos que propõem melhorias para as FGRM [Zimmermann et al., 2009,
Zimmermann et al., 2010, Singh & Chaturvedi, 2011]. Estas recomendações podem ser
79
80 Capítulo 5. Sugestões de Melhorias para as FGRMs
utilizadas por pesquisadores interessados em conduzir estudos sobre o avanço da produ-
tividade dos desenvolvedores mediante o uso das FGRMs. Além disso, os responsáveis
pelo desenvolvimento deste tipo de software, podem utilizar algumas das recomenda-
ções para a criação ou aperfeiçoamento das funcionalidades das FGRMs. Na mesma
linha, os profissionais envolvidos com Manutenção de Software podem criar extensões
(plug-in) com base no que foi proposto de modo a aplicar essas melhorias em sua rotina
de trabalho.
Este capítulo está organizado da seguinte forma: a Seção 5.2 apresenta as suges-
tões de melhorias propostas, cada sugestão é seguida de uma breve discussão de como
foi obtida e justificativa de sua consideração; na Seção 5.3 realizamos uma avaliação do
que foi recomendado com base na opinião de profissionais que contribuem para projetos
relacionados ao desenvolvimento de FGRMs; os resultados do processo de avaliação são
apresentados na Seção 5.4; na Seção 5.5 discutimos os resultados obtidos no processo
de avaliação; na Seção 5.6 apresentamos as ameaças à validade; encerramos o capítulo
com um resumo na Seção 5.7.
5.2 Sugestões de Melhorias para FGRMs
As sugestões propostas neste capítulo não estão vinculadas exclusivamente às melhorias
de funcionalidades existentes nas FGRMs. As recomendações podem representar o
desenvolvimento de um novo comportamento ou a melhoria de outros já existentes.
Cabe-nos ressaltar que não houve a intenção de apresentar um conjunto exaustivo de
melhorias.
É possível que algumas das recomendações propostas já estejam implementadas
de maneira parcial ou integral. Infelizmente não tivemos como verificar isso em função
do esforço exigido pelo grande volume de ferramentas disponíveis quando esta disser-
tação foi escrita. Além disso, com base no processo de validação descrito na Seção 5.3
seria possível identificar se alguma das sugestões proposta já existe como funcionali-
dade em determinada FGRM@. Ao longo da elaboração das sugestões verificamos que
não conseguiríamos implementá-las e também não conseguiríamos analisar a complexi-
dade de estratégias de implementação. Entretanto, como prova de conceito, a sugestão
descrita na Seção 5.2.1 foi implementada como extensão da FGRM existente nos re-
positórios da plataforma Github, conforme pode ser visto no Capítulo 6. As sugestões
foram estruturadas como seções deste capítulo, em que apresentamos a justificativa, o
benefício gerado, as limitações e exemplos de utilização.
5.2. Sugestões de Melhorias para FGRMs 81
5.2.1 Suporte à Qualidade do Texto Relatado
Sugestão #01: As FGRMs devem fornecer realimentação (feedback) relaci-
onada à qualidade do texto relatado.
Justificativa: Conforme discutido na Seção 2.1.3 o responsável por reportar uma
RM pode ser tanto um usuário do sistema quanto um membro da equipe de ma-
nutenção. Por esta razão, podemos encontrar reportadores com diferentes níveis de
conhecimento sobre o sistema. Do ponto de vista dos desenvolvedores, um problema
recorrente é a baixa qualidade do texto no relato da RM, tipicamente pela falta da
informação necessária à solução. Alguns estudos mostram que a ausência de infor-
mações, tais como as etapas para reproduzir a falha e a cadeia de registros de ati-
vação, dificultam mais o andamento do projeto do que a ocorrência de RMs dupli-
cadas [Zimmermann et al., 2010, Bettenburg et al., 2007]. Neste sentido, as FGRMs
poderiam fornecer uma funcionalidade capaz de reduzir o número de relatos de baixa
qualidade através, por exemplo, de uma realimentação ao Reportador envolvendo uma
estimativa da qualidade do que foi informado no relato da RM.
Benefício Gerado: Com este tipo de funcionalidade uma FGRM poderia reduzir o
tempo de análise das RMs uma vez que o responsável por criá-la estaria ciente das
informações necessárias à sua solução. Neste caso, o desenvolvedor seria diretamente
beneficiado já que teria a sua disposição um relato mais completo. Não obstante, um
trabalho adicional seria dado aos reportadores que em algumas situações devem rever
as informações incluídas na RM.
Limitações: Alguns estudos sobre a melhoria da qualidade do relato da RM focam
prioritariamente nas requisições que descrevem defeitos do software. Conforme dis-
cutimos na Seção 2.1.4, uma RM pode também estar relacionada com um pedido de
melhoria. Uma dificuldade desta recomendação de funcionalidade é separar de forma
automatizada as duas dimensões das RMs. Da mesma forma, seria importante defi-
nir padrões distintos para analisar a qualidade do relato por conta de suas diferentes
características e necessidades de uma RM.
Exemplo de Utilização: Após o usuário relatar um problema ou pedido de melhoria,
a ferramenta poderia avaliar o texto corresponde ao atributo relato da RM gerada e
apresentar ao responsável realimentação sobre como a informação fornecida poderia ser
melhorada, como por exemplo através da inclusão de um arquivo com o histórico de
82 Capítulo 5. Sugestões de Melhorias para as FGRMs
execução do software (log). Como prova de conceito foi implementada uma extensão
para uma FGRM com estas características no Capítulo 6.
5.2.2 Acesso Facilitado ao Código Fonte Incluído nas RMs
Sugestão #02: As FGRMs devem fornecer busca pelo código fonte contido
no relato, comentários ou anexos das RMs.
Justificativa: As RMs permitem a inclusão de fragmentos de código fonte em seu
relato ou nos comentários em diversas etapas do seu ciclo de vida. O código pode ser
incluído durante a criação das RMs, nas discussões realizadas para a sua solução ou
mesmo quando ela é concluída (fechada). Quando o código corresponde a uma solução
então recebe o nome de patch. Os fragmentos de código podem ser utilizados para
descrever uma falha ou apresentar uma solução candidata. Apesar de sua importância
este tipo de informação não é facilmente recuperada no contexto de uso de uma FGRM.
O estudo de Damevski e outros [Damevski et al., 2016], que analisa o problema da
localização de funcionalidades no código fonte (feature location), ressalta a importância
que a facilidade de acesso ao código fonte pode propiciar na redução do tempo de
conclusão da tarefa de manutenção e no aumento da qualidade das alterações realizadas.
Este é um caso particular de uma sugestão de melhoria que envolve generalizar ou
especializar a interface de busca das FGRMs. Esta interface tem relação com a Sugestão
#06 porque pode ser só texto (Recuperação da Informação) ou pode envolver elementos
não textuais.
Benefício Gerado: Com um fácil acesso ao código fonte um desenvolvedor pode
obter exemplos de solução para RMs similares. Este tipo de funcionalidade pode ser
vantajosa em comparação com a busca estruturada, presente em grande parte das
FGRMs, por permitir a recuperação com base em elementos específicos da linguagem de
programação utilizada pelo software que a FGRM suporta, como por exemplo classes,
funções, constantes e outros.
Exemplo de Utilização: Em certas ocasiões, uma RM em análise pode ter similarida-
des com outras solucionadas anteriormente. A similaridade pode ser devido a afetarem
o mesmo módulo do sistema, por exemplo. Um desenvolvedor poderia realizar uma
busca por código fonte na RM solucionada com o objetivo de encontrar fragmentos de
código que o ajudem no entendimento e solução do pedido atual.
5.2. Sugestões de Melhorias para FGRMs 83
5.2.3 Ranqueamento pela Reputação do Reportador
Sugestão #03: As FGRMs devem permitir um ranqueamento das RMs de
acordo com a reputação do Reportador.
Justificativa: Um problema recorrente em diversos projetos de software é a defini-
ção da ordem que o conjunto de RMs deve ser analisado. Conforme discutido na
Seção 3.3.1.3 alguns estudos vêm se dedicando em classificar as RMs sob determina-
dos critérios. Por outro lado, é possível observar que determinados reportadores têm
por hábito relatar pedidos que possuem um maior grau de relevância no projeto. Por
exemplo, existem certos usuários cujos relatos frequentemente envolvem questões de
segurança do sistema. Neste contexto, seria interessante se as FGRMs aplicassem al-
gum tipo de métrica de relevância aos seus usuários, em especial aos reportadores. Em
um segundo momento, esta mesma medida poderia ser utilizada com a finalidade de
ranquear as RMs. Neste sentido, conforme a conveniência, um desenvolvedor poderia
priorizar as requisições de reportadores com um maior grau de reputação.
Benefício Gerado: Uma das possíveis atividades desempenhadas pelo Escalonador
é organizar a ordem que as RMs devem ser analisadas. Ele pode utilizar diversos cri-
térios no exercício desta atividade, como por exemplo a prioridade do que foi relatado.
Segundo a nossa proposta, o Escalonador pode previamente ordenar uma lista de RMs
pelo grau de reputação de quem as redigiu. A partir disso, ele poderia atribuir primeiro
as RMs de reportadores com maior grau de reputação. Com base nesta estratégia, é
possível que RMs com maior relevância sejam analisadas primeiro. O conceito de rele-
vância pode variar em diferentes projetos. Contudo, uma RM poderia ser classificada
como relevante caso descreva um problema que afete um grande número de usuários
ou represente uma falha de segurança do software. Além disso, deve ser redigida de
forma clara e fornecer as informações necessárias para sua solução.
Exemplo de Utilização: Conforme descrito anteriormente, um Escalonador poderia
ordenar uma lista de RMs pelo grau de reputação do Reportador. Em seguida, o
Atribuidor daria início ao processo de distribuição das RMs analisando primeiro aquelas
mais bem ranqueadas. Caso as elas sejam relevantes o profissional poderia realizar a
atribuição.
84 Capítulo 5. Sugestões de Melhorias para as FGRMs
5.2.4 Atalhos para filtros e classificação (rankings) das RMs
Sugestão #04: As FGRMs devem fornecer atalhos para filtros personalizá-
veis e classificações (rankings).
Justificativa: As RMs atribuídas a determinado desenvolvedor podem estar em di-
ferentes estados. Existem aquelas que não foram analisadas, que estão aguardando
informações adicionais ou que estejam aguardando o Analista de Qualidade, por exem-
plo. Em geral, conforme discutido na Seção 2.3, as FGRMs permitem visualizar a
situação das RMs de um desenvolvedor mediante relatórios pré-definidos. Contudo,
no levantamento mediante questionário, apresentado no Capítulo 4, identificamos que
uma parte dos profissionais solicitou um acesso mais facilitado a este tipo de informa-
ção. Por exemplo, na questão em que deixamos livre ao profissional sugerir uma nova
funcionalidade, obtivemos a seguinte respostas: “The ability to clearly visualize how
many tickets are at the to do, in progress, to validate or done steps.”. Desta forma, su-
gerimos uma alteração nas interfaces das FGRMs de modo a fornecer acesso facilitado
a filtros personalizáveis e outros tipos de classificações.
Benefício Gerado: Com um acesso mais rápido às últimas RMs analisadas o de-
senvolvedor poderia ter uma noção geral do trabalho desenvolvido. Este panorama
poderia ajudá-lo no planejamento de suas atividades diárias.
Exemplo de Utilização: Ao acessar a FGRM o desenvolvedor tem acesso as últimas
n RMs que ele analisou. Além disso, ele poderia criar filtros para acessar outras
informações que julgar importante no desenvolvimento de suas atividades.
5.2.5 Suporte a Processos de Integração Contínua
Sugestão #05: As FGRMs devem fornecer suporte a Processos de Integração
Contínua.
Justificativa: A solução de determinada RM pode levar a resultados não esperados
em outros módulos do sistema mantido. Para tomar conhecimento dos possíveis pro-
blemas recomenda-se a avaliação do impacto da RM. A Análise de Impacto estima o
que será afetado no software e na documentação relacionada caso uma mudança pro-
posta seja feita [Arnold, 1996]. A literatura sobre RMs discute algumas soluções com
o objetivo de realizar a Análise de Impacto. Alguns exemplos de trabalhos nesta linha
são apresentados na Seção 3.3.1.3. Dentro das propostas feitas pelos agilistas uma das
5.2. Sugestões de Melhorias para FGRMs 85
possibilidades de reduzir os efeitos colaterais de uma mudança é periodicamente realizar
a construção (build) do sistema. A Integração Contínua (IC) é a prática de construir
e implantar (deploy) imediatamente após um desenvolvedor compromissar (commit)
o código fonte [Aiello & Sachs, 2010]. Neste sentido, as FGRMs poderiam vincular a
solução de uma RM com a execução do processo de IC. Desta forma, seria possível
associar uma versão do sistema com o conjunto de RMs solucionadas até a sua geração.
Este tipo de integração foi descrita como uma funcionalidade ausente nas FGRMs por
alguns participantes do levantamento por questionário descrito no Capítulo 4.
Benefício Gerado: A integração de uma FGRM com processos de IC traria para as
atividades de manutenção os benefícios desta prática, tais como a redução de riscos e
a facilidade de encontrar e remover falhas [Fowler & Foemmel, 2006]. Além disso, se-
gundo o nosso entendimento, o fato de associar a solução de uma RM com determinada
versão de um sistema, pode minimizar problemas levantados no Mapeamento Sistemá-
tico descrito no Capítulo 3, por exemplo a Localização do Problema (Seção 3.3.1.1) e a
Estimativa de Esforço da RM (Seção 3.3.1.3). Em ambos os casos é possível aproveitar
a facilidade que a IC propicia em fornecer a localização de uma falha que, por exemplo,
pode ter sido causada pela solução de outra RM.
Limitações: Algumas vezes a mudança de situação de uma RM para Fechada pode
não representar a sua efetiva solução. Por exemplo, a falha descrita pode ser definida
como de baixo impacto e desta maneira não ser tratada, ou ainda o conjunto de fatores
que geraram o problema descrito na RM deixa de existir. Nestas situações não faz
sentido que responsável por fechar a RM engatilhe um processo de Integração Contínua.
Exemplo de Utilização: Após um desenvolvedor solucionar determinada RM, mu-
dando a sua situação para Fechada, por exemplo, a FGRM dispara o processo de
compilação do sistema. O resultado da compilação poderia ser exibido em um painel
de controle incluindo o responsável pela mudança mais recente no sistema e as com-
pilações que resultaram em falhas. O painel poderia incluir ainda dados da RM que
engatilhou o processo de compilação como por exemplo o seu número e título.
5.2.6 Suporte ao Registro do Relato além de Texto Simples
Sugestão #06: As FGRMs devem dar suporte além da especificação de texto
simples.
86 Capítulo 5. Sugestões de Melhorias para as FGRMs
Justificativa: Quando uma nova RM é registrada as informações mais relevantes
estão no texto correspondente ao atributo relato. Além do problema da falta de infor-
mação no relato da RM, discutido na Seção 5.2.1, o Reportador enfrenta a dificuldade
de expressar a falha ou o pedido de melhoria do software. A baixa expressividade do
texto do relato pode estar relacionada com o fato que algumas ferramentas analisa-
das utilizam texto simples (vide Seção 2.3). A possibilidade de usar linguagens com
semântica de apresentação, como por exemplo Rich Text Format - RTF1, ou que permi-
tam realce da sintaxe do código, poderia ajudar ao Reportador a expressar com maior
qualidade a falha ou pedido de melhoria.
Benefício Gerado: Em um trabalho sobre a transcrição de materiais de estudo, Voe-
gler e outros [Voegler et al., 2014] mostraram que o uso da linguagem Markdown pode
melhorar a qualidade técnica e a acessibilidade do documento resultante. As FGRMs
poderiam se apropriar destas facilidades com o objetivo de melhorar a legibilidade do
texto contido na RM. É possível que com o uso deste tipo de formato, os reportadores
poderiam, por exemplo, incluir no próprio relato uma parte do código fonte onde eles
supõem que esteja localizada a falha.
Limitações: Em algumas situações os responsáveis por reportar uma RM possuem
diferentes níveis de conhecimento sobre o sistema. Neste sentido, é possível que nem
todos os reportadores consigam fazer uso de todas as facilidades oferecidas por um novo
formato de texto para o relato da RM. Além disso, a utilização de uma linguagem que
exija conhecimento prévio pode inibir o desejo de reportar uma RM.
Exemplo de Utilização: Conforme discutido na Seção 2.3, algumas FGRMs permi-
tem a utilização de linguagens com semântica de apresentação no processo de relato.
No Github, o módulo para a criação de uma RM, (issue no contexto da plataforma),
permite o uso da linguagem Markdown como um dos formatos disponíveis.
5.2.7 Classificação Automática pela Urgência da RM
Sugestão #07: As FGRMs devem fornecer uma classificação automática em
termos da urgência da RM.
Justificativa: Conforme discutido na Seção 5.2.3 a escolha das RMs que serão anali-
sadas é um desafio para as equipes de manutenção. Em determinados contextos, certas
1https://msdn.microsoft.com/en-us/library/aa140280(office.10).aspx
5.2. Sugestões de Melhorias para FGRMs 87
equipes estão adotando práticas propostas pelos agilistas em suas rotinas de manu-
tenção de software [Svensson & Host, 2005b]. Nestes ambientes, um dos problemas
existente é que as iterações (sprint) estão sujeitas a interrupções por demandas urgen-
tes de clientes [Bennett & Rajlich, 2000]. Uma possível solução é a utilização de uma
reserva de tempo (buffer) que não é alocada no planejamento da iteração de modo a
atender eventuais demandas não esperadas [Schwaber & Beedle, 2002]. Para apresen-
tação da solução proposta ainda é necessário definir quais RMs devem ser priorizadas
durante a iteração, o que geralmente é realizado manualmente. As FGRMs poderiam
dar suporte à priorização automática de RMs urgentes.
Benefício Gerado: Ao realizarmos a priorização automática estamos reduzindo o
esforço desempenhado por alguns membros da equipe de manutenção, em especial
pelo Escalonador. No caso em que as RMs forem corretamente classificadas como
urgentes, elas poderão ser solucionadas em um prazo mais curto. Para as equipes que
organizam as suas atividades em iterações (sprints) pode ocorrer a redução de iterações
interrompidas o que pode evitar algum tipo de frustração e desmotivação com relação
ao planejamento e objetivos da iteração.
Limitações: A priorização automática pode ser vista como um problema de Classi-
ficação de RM, conforme discutido na Seção 3.3.1.3. Em geral, são utilizadas técnicas
de Mineração de Dados com o objetivo de classificar uma RM, o que possui diversas
limitações. Neste sentido, o uso de técnicas supervisionadas, ou seja, com suporte de
membros da equipe de manutenção, pode ajudar na melhoria dos resultados.
Exemplo de Utilização: Após uma nova RM ser criada, a FGRM dispara um pro-
cesso para determinar se ela deve ser classificada como urgente conforme critérios pre-
viamente definidos. Caso positivo, a ferramenta realiza a priorização da RM através,
por exemplo, da atribuição automatizada para um desenvolvedor disponível.
5.2.8 Suporte à tarefas compartilhadas
Sugestão #08: As FGRMs devem suportar tarefas compartilhadas, permi-
tindo o trabalho colaborativo.
Justificativa: Dentro do que é proposto pelos agilistas, o compartilhamento de código
é visto como uma boa prática [Meyer, 2014]. Por outro lado, mantenedores tendem
a se tornarem especialistas nos sistemas que são responsáveis [Singer, 1998]. A pro-
priedade compartilhada de tarefas permite que a carga de trabalho seja distribuída
88 Capítulo 5. Sugestões de Melhorias para as FGRMs
de forma mais flexível, permitindo que os desenvolvedores sejam capazes de ajudar
uns aos outros. No contexto das FGRMs, as tarefas compartilhadas poderiam ser re-
presentadas com a “propriedade” de uma RM por dois ou mais desenvolvedores. A
literatura sobre o tema apresenta uma abordagem semelhante em que os autores cons-
truíram uma comunidade de desenvolvedores baseada nos comentários realizados nas
RMs [Banitaan & Alenezi, 2013]. Cada RM criada era atribuída para uma comuni-
dade. Os resultados mostraram que a abordagem atingiu uma precisão razoável de
atribuição de RMs, além de construir um conjunto de desenvolvedores com experiência
em solucionar determinadas RMs.
Benefício Gerado: A atribuição de uma RM a mais de um desenvolvedor flexibiliza
a carga de trabalho e pode aumentar a moral da equipe. Em algumas situações os
desenvolvedores deixam de ser especialistas em determinados sistemas para se torna-
rem generalistas, trabalhando com outros projetos. Esses benefícios são discutidos na
literatura sobre o desenvolvimento e a manutenção que adotam as práticas propostas
pelos agilistas [Dybå & Dingsøyr, 2008, Rudzki et al., 2009].
Limitações: Uma funcionalidade com suporte ao compartilhamento de tarefas tem os
mesmos desafios e problemas do processo de atribuição automatizada de RMs, conforme
discutido na Seção 3.3.1.3. Além disso, a RM deve permitir a divisão atômica de tarefas
de modo que cada atividade fique com um único desenvolvedor o que nem sempre é
possível.
Exemplo de Utilização: Quando uma nova RM é criada um processo automatizado
define dois ou mais desenvolvedores como responsáveis. Posteriormente, a RM pode
ser dividida em tarefas que serão compartilhadas entre os desenvolvedores.
5.3 Avaliação das Melhorias Propostas
Este capítulo apresentou um conjunto de sugestões que foram construídas tomando
como base a literatura da área e os levantamentos desta dissertação. Com o objetivo
de avaliar a relevância e o grau de facilidade de implementação das recomendações
propostas, conduzimos um levantamento mediante questionário com profissionais que
contribuem em projetos de código aberto hospedados no Github que possuem relação
com o desenvolvimento de FGRMs. O processo de seleção dos participantes, o desenho
do questionário e como foi realizada a aplicação estão descritos a seguir.
5.3. Avaliação das Melhorias Propostas 89
5.3.1 Seleção dos Participantes
O público-alvo deste questionário é o conjunto de profissionais que estejam ligados
ao processo de desenvolvimento e manutenção de algum projeto de FGRMs. Esta
escolha se deu em função de envolver a avaliação da relevância das sugestões propostas
e verificar a viabilidade de implementação do que foi recomendado. Tivemos que nos
conformar com uma amostra composta por profissionais que atuam como contribuidores
em projetos de código aberto hospedados no Github. Com cerca de 38 milhões de
repositórios2, o Github é atualmente o maior repositório de código na Internet. Sua
popularidade e a disponibilidade de metadados, acessíveis através de uma API, têm
tornado Github bastante atrativo para a realização de pesquisas na área de Engenharia
de Software.
A seleção dos participantes iniciou com a escolha dos projetos através da interface
de busca avançada oferecida pela plataforma Github. Ela permite recuperar projetos
utilizando critérios tais como data de criação, linguagem utilizada no desenvolvimento
e proprietário do repositório, dentre outros. O fato de utilizarmos apenas o Github
como a única fonte para seleção de participantes implica em certas ameaças à validade
do estudo que são discutidas na Seção 5.6. Os critérios de seleção dos projetos inclui
os seguintes requisitos:
• Os projetos devem representar o desenvolvimento de uma FGRM.
• Os projetos devem ter no mínimo seis meses de desenvolvimento, para evitar
aqueles que não tenham passado por um tempo de manutenção relevante.
• Os projetos devem ter no mínimo 200 revisões (commits) pelos mesmos motivos
da restrição anterior.
• Os projetos obtidos devem estar entre os 50 mais populares que atendam aos
demais critérios e estejam entre os melhores classificados pela ordenação via a
opção “most stars”, que representa o número de usuário do Github que mostraram
apreciação sobre o trabalho desenvolvido no repositório.
Após aplicação destes critérios descritos obtivemos os projetos retratados no
Apêndice G. Com base nos projetos selecionados ficou definido que a amostra a ser
utilizada no levantamento seriam os respectivos contribuidores. Um contribuidor é al-
guém que participa efetivamente do desenvolvimento de um projeto, tendo o privilégio
2Disponível em https://github.com/features. Acesso em junho/2016. Uma definição do con-
ceito de repositório no contexto da plataforma Github é realizada no Capítulo 6
90 Capítulo 5. Sugestões de Melhorias para as FGRMs
de acesso para alterar o código fonte. A solicitação de participação foi realizada por
meio de correio eletrônico. O atributo foi coletado de forma automatizada apenas dos
usuários da plataforma que disponibilizam esta informação como pública, de modo a
preservar a privacidade dos contribuidores. A Figura 5.1 exibe uma página do projeto
com seus respectivos colaboradores.
Figura 5.1. Lista de contribuidores do projeto Redmine
5.3.2 Desenho do Questionário
A fim de coletar a opinião dos participantes foi utilizado um questionário eletrônico.
O formulário foi desenhado com a premissa de ser respondido em um prazo curto, de
preferência entre 5 e 10 minutos. Neste sentido, as perguntas foram organizadas em dois
grupos principais. As questões do primeiro grupo têm por objetivo coletar a opinião
dos profissionais sobre a relevância da recomendação proposta e o grau de dificuldade
em implementá-la. As perguntas foram estruturadas de maneira a permitir respostas
na forma de uma escala de Likert em que o respondente deveria fornecer o seu nível
5.4. Resultados da Avaliação das Sugestões de Melhorias 91
de concordância para as declarações que lhe foram apresentadas. No segundo grupo
estamos interessados na formação dos profissionais. Optamos por definir algumas das
questões como não obrigatórias por entendermos que a impossibilidade ou falta de
interesse em responder determinada pergunta não deveria impedir o participante de
enviar os dados de outras questões respondidas. A versão final do questionário está
Apêndice H.
5.3.3 Processo de Aplicação
O questionário foi encaminhado via correio eletrônico. O endereço foi coletado dire-
tamente do projeto hospedado no Github. O pedido de participação foi enviado para
um total de 121 contribuidores no período de 28/04/2017 a 01/05/2017. A mensagem
enviada pode ser visualizada no Apêndice I.
O processo de envio consistia ainda de uma segunda mensagem de “lembrete” após
dois dias. Esta estratégia foi adotada com base em estudos que discutem os resultados
de que o reenvio pode ser um dos fatores que aumenta a taxa de participação em
levantamentos por questionários realizados através da web [Fan & Yan, 2010].
5.4 Resultados da Avaliação das Sugestões de
Melhorias
Após o envio do formulário aos participantes obtivemos um total de 29 respostas. Como
algumas das questões do formulário não eram de preenchimento obrigatório é possível
encontrar resultados que não totalizem 29 participações. O nível de participação foi
similar ao observado em outros estudo em Engenharia de Software que utilizam o
levantamento por questionário como método de coleta de dados [Fan & Yan, 2010].
Nas próximas seções apresentamos o perfil dos participantes, a relevância das sugestões
propostas e o grau de facilidade de implementação das mesmas.
5.4.1 Perfil dos Participantes
No levantamento realizado incluímos uma questão sobre qual sistema o desenvolve-
dor contribui. A Tabela 5.1 exibe o nome dos projetos que tiveram contribuidores
que preencheram o nosso formulário. Verificamos nas primeiras posições ferramentas
tradicionais como Mantis, Trac e Debbugs. As FGRMs que tiveram menos de duas
participações foram agrupados sob o termo “OUTROS”.
92 Capítulo 5. Sugestões de Melhorias para as FGRMs
Projeto Participantes
DEBBUGS 4
MANTISBT 4
TRAC 4
FOSSIL 3
BUGZILLA 2
REDMINE 2
OUTROS 6
Tabela 5.1. Projetos que os participantes contribuem.
Com relação à função desempenhada mais da metade dos participantes são de-
senvolvedores (53%). O segundo grupo de função com maior frequência são aqueles
ligados ao gerenciamento de equipes (Gerentes de Projetos, Chief Technical Officer e
etc.). Verificamos ainda a participação de Engenheiros e Arquitetos de Software. So-
bre o tempo de experiência, cerca de 13 participantes têm entre dez e vinte anos de
experiência. A maior parte desempenha suas atividades em equipes com 2 a 5 pessoas
ou com mais do 10 membros. Quando questionamos sobre qual o tipo de atividade
desempenhada pelo participante, cerca de 25 deles trabalham com desenvolvimento ou
manutenção de software.
5.4.2 Relevância das Sugestões
As sugestões de melhorias foram apresentadas aos participantes e eles respondiam se
achavam as sugestões pertinentes mediante uma escala do tipo Likert. A Tabela 5.2
apresenta a frequência e o percentual de escolha para cada sugestão de melhoria. A
Figura 5.2 exibe o nível de aceitação das sugestões propostas. Em uma primeira aná-
lise verificamos que a maioria das recomendações tiveram uma avaliação positiva dos
participantes (Concordo ou Concordo Fortemente). A exceção foi para a Sugestão #3
- As FGRMs devem permitir um ranqueamento das RMs de acordo com a reputação
do Reportador que trata da possibilidade de ordenar as RMs a serem analisadas pela
reputação do Reportador. Por outro lado, as Sugestões #6 - As FGRMs devem dar
suporte além da especificação de texto simples e #8 - As FGRMs devem suportar tare-
fas compartilhadas, permitindo o trabalho colaborativo tiveram uma boa aceitação dos
participantes.
Para avaliar quais sugestões tiveram maior aceitação definimos um ranqueamento.
O ordenamento consistiu em aplicar pesos para cada item da escala de Likert conforme
a Tabela 5.3. O valor é obtido multiplicando a frequência de determinado item da
escala pelo seu respectivo peso. A Tabela 5.2 exibe as recomendações ordenadas pelo
5.4. Resultados da Avaliação das Sugestões de Melhorias 93
Sugestão Discordo Fortemente Discordo Não concordo e nem discordo Concordo Concordo Fortemente
Sugestão #1 1 (3,4%) 3 (10,3%) 10 (34,5%) 13 (44,9%) 2 (6,9%)
Sugestão #2 0 (0,0%) 2 (6,9%) 7 (24,1%) 13 (44,9%) 7 (24,1%)
Sugestão #3 3 (10,3%) 9 (31,0%) 13 (44,9%) 2 (6,9%) 2 (6,9%)
Sugestão #4 0 (0,0%) 1 (3,4%) 6 (20,7%) 12 (41,4%) 10 (34,5%)
Sugestão #5 1 (3,4%) 0 (0,0%) 5 (17,2%) 10 (34,5%) 13 (44,9%)
Sugestão #6 0 (0,0%) 1 (3,4%) 2 (6,9%) 6 (20,7%) 20 (69,0%)
Sugestão #7 1 (3,4%) 5 (17,2%) 8 (27,7%) 6 (20,7%) 9 (31,0%)
Sugestão #8 0 (0,0%) 1 (3,4%) 1 (3,4%) 15 (51,7%) 12 (41,4%)
Tabela 5.2. Frequência e percentual das respostas sobre a relevância das suges-
tões de melhorias
Avaliação das Recomendações de Melhorias
Número de Respostas
Recomendação #8
Recomendação #7
Recomendação #6
Recomendação #5
Recomendação #4
Recomendação #3
Recomendação #2
Recomendação #1
20 10 0 10 20 30
Discordo.Fortemente Discordo Nem.concordo.ou.discordo Concordo Concordo.Fortemente
Figura 5.2. Avaliação das Sugestões de Melhorias
nível de aceitação dos participantes, conforme o valor atribuído a cada opção da escala.
É possível visualizar o número de respostas que cada item recebeu.
Item da Escala Peso
Discordo Fortemente -2
Discordo -1
Nem concordo ou discordo 0
Concordo 1
Concordo Fortemente 2
Tabela 5.3. Pesos utilizados para ordenar as sugestões propostas.
Com base na Tabela 5.4 verificamos que recomendações que sobressaíram: uti-
lização nas FGRMs de uma linguagem além do texto simples para redigir uma RM
94 Capítulo 5. Sugestões de Melhorias para as FGRMs
(#3), suporte à tarefas colaborativas (#8) e incorporação de processos de Integração
Contínua (#5). Por outro lado as sugestões de diferenciar as RMs pela reputação do
Reportador (#3) e avaliar a qualidade do relato (#1) não foram avaliadas como as
mais relevantes pelos participantes. É importar notar que as recomendações que fica-
ram nas últimas posições tiveram a opção “Não concordo nem discordo” selecionadas
com maior frequência.
Sugestão Discordo Fortemente Discordo Não concordo e nem discordo Concordo Concordo Fortemente Ranking
Sugestão #6 0 1 2 6 20 45
Sugestão #8 0 1 1 15 12 38
Sugestão #5 1 0 5 10 13 34
Sugestão #4 0 1 6 12 10 31
Sugestão #2 0 2 7 13 7 25
Sugestão #7 1 5 8 6 9 17
Sugestão #1 1 3 10 13 2 12
Sugestão #3 3 9 13 2 2 -9
Tabela 5.4. Ranking das sugestões propostas
5.4.3 Implementação das Sugestões
Neste etapa do estudo estávamos interessados em avaliar o nível de dificuldade para
implementar as sugestões propostas. A frequência e o percentual das respostas para
cada sugestão de melhoria estão disponíveis na Tabela 5.5 e podem ser visualizados na
Figura 5.3
Sugestão Discordo Fortemente Discordo Não concordo e nem discordo Concordo Concordo Fortemente
Sugestão #1 1 (3,4%) 3 (10,3%) 10 (34,5%) 13 (44,9%) 2 (6,9%)
Sugestão #2 0 (0,0%) 2 (6,9%) 7 (24,1%) 13 (44,9%) 7 (24,1%)
Sugestão #3 3 (10,3%) 9 (31,0%) 13 (44,9%) 2 (6,9%) 2 (6,9%)
Sugestão #4 0 (0,0%) 1 (3,4%) 6 (20,7%) 12 (41,4%) 10 (34,5%)
Sugestão #5 1 (3,4%) 0 (0,0%) 5 (17,2%) 10 (34,5%) 13 (44,9%)
Sugestão #6 0 (0,0%) 1 (3,4%) 2 (6,9%) 6 (20,7%) 20 (69,0%)
Sugestão #7 1 (3,4%) 5 (17,2%) 8 (27,7%) 6 (20,7%) 9 (31,0%)
Sugestão #8 0 (0,0%) 1 (3,4%) 1 (3,4%) 15 (51,8%) 12 (41,4%)
Tabela 5.5. Frequência e percentual das respostas sobre a dificuldade de imple-
mentação das sugestões de melhoria
As sugestões foram ordenadas pelo grau de dificuldade de implementação. Uti-
lizamos um mecanismo similar ao descrito na Seção 5.4.2 em que o valor é obtido
multiplicando a frequência de um item da escala por um peso previamente definido.
Os pesos estão apresentados na Tabela 5.6.
Foram consideradas ser de fácil implementação: o suporte do relato de uma RM
além do texto simples (#6), a criação de atalhos e filtros personalizáveis (#4) e o
ranqueamento das RMs pela reputação do Reportador (#3). Segundo os participantes
5.4. Resultados da Avaliação das Sugestões de Melhorias 95
Avaliação da Implementação das Melhorias
Número de Respostas
Recomendação #8
Recomendação #7
Recomendação #6
Recomendação #5
Recomendação #4
Recomendação #3
Recomendação #2
Recomendação #1
20 10 0 10 20
Muito.Difícil Difícil Neuto Fácil Muito.Fácil
Figura 5.3. Avaliação sobre a implementação das sugestões propostas.
Item da Escala Peso
Muito Difícil -2
Difícil -1
Neutro 0
Fácil 1
Muito Fácil 2
Tabela 5.6. Pesos utilizados no ranqueamento das sugestões de melhorias
96 Capítulo 5. Sugestões de Melhorias para as FGRMs
funções como o suporte a tarefas compartilhadas (#8) e análise da qualidade do relato
(#1) foram consideradas de um maior grau de dificuldade de implementação. O fato
interessante é que a Sugestão #3 foi considerada como uma das mais fáceis de imple-
mentar, entretanto, está entre aquelas que tiveram menor aceite entre os participantes.
Este fato pode sugerir que sua possível rejeição não estaria ligada à sua complexidade
de desenvolvimento, mas a fatores como não haver interesse em classificar aqueles que
reportam uma RM. Contudo, para comprovarmos este tipo de hipótese seria neces-
sário conduzir um novo tipo de estudo com os participantes, como por exemplo uma
entrevista em questões deste tipo poderiam ser melhor esclarecidas.
Recomendações Muito Difícil Difícil Neutro Fácil Muito Fácil Ranking
Sugestão #6 0 0 8 16 5 26
Sugestão #4 0 1 8 17 3 22
Sugestão #3 4 3 9 10 3 5
Sugestão #2 2 7 11 8 1 -1
Sugestão #7 3 12 4 7 3 -5
Sugestão #5 2 11 12 3 1 -10
Sugestão #8 0 16 7 6 0 -10
Sugestão #1 8 16 3 2 0 -30
Tabela 5.7. Ordenamento das sugestões pelo grau de dificuldade.
5.5 Discussão
Em geral podemos considerar que as sugestões propostas tiveram uma boa aceitação
dos participantes. Em média 32% dos participantes avaliaram as recomendações “Con-
cordo” ou “Concordo Fortemente”. Além disso, por volta de 22% em média selecionaram
a opção “Nem concordo ou discordo”. Uma questão a ser futuramente investigada é se
as as respostas poderiam ser alteradas para uma visão mais positiva, como por exem-
plo “Concordo” ou “Concordo Fortemente”, caso fossem fornecidos mais detalhes ao
participantes. Com este objetivo um estudo do tipo entrevista poderia ser conduzido.
Com relação às recomendações propostas, verificamos que a utilização de uma
linguagem além do texto simples, como por exemplo o Markdown, foi muito bem aceita.
Este tipo de sugestão tem como principal objetivo aumentar o poder de expressão do
relato, tal como a possibilidade do destaque da sintaxe do código fonte. Conforme
pode ser observado na Seção 2.3 trata-se de uma funcionalidade encontrada em uma
das FGRMs analisadas. Entretanto, o nosso resultado demonstra, com base na amostra
utilizada, que deveria ser estendida para outras ferramentas.
5.6. Ameaças à Validade 97
O suporte a tarefas compartilhadas (sugestão #8) também foi muito bem aceito.
Esta recomendação surgiu das tentativas de implantação das propostas dos agilis-
tas [Svensson & Host, 2005b]. A sugestão defende que uma determinada RM não tenha
um único “dono”, mas que a responsabilidade seja dividida entre dois ou mais mem-
bros da equipe. Esta divisão de tarefas pode resultar na melhoria da distribuição do
conhecimento entre a equipe. A prevalência deste tipo de funcionalidade pode estar
relacionada com o desejo das equipes de manutenção de utilizar algumas das práticas
dos agilistas. Seria necessário um aprofundamento da opinião dos participantes para
confirmamos esta hipótese. Apesar da sua popularidade entre os participantes, esta
sugestão ficou entre aquelas com maior grau de dificuldade de implementação.
Por outro lado, as sugestões que têm algum tipo de relação com a interface das
FGRMs (sugestões #6, #4, e #2) foram consideradas como mais “fáceis” de implemen-
tar com mais frequência. Entretanto, a sugestão sobre a qualidade do relato (#1) ficou
entre aquelas com maior grau de dificuldade. Esta classificação pode ser decorrente do
caráter subjetivo que a qualidade do relato pode ter. Em cada projeto a qualidade do
relato pode ter características distintas o que pode dificultar o seu suporte.
5.6 Ameaças à Validade
Para avaliarmos as sugestões propostas nos conformamos em empregar uma amostra
que se caracteriza como de conveniência, apresentando os vícios desse tipo de amostra-
gem. Apesar da taxa de resposta estar dentro da faixa observada na literatura, o total
de participantes não nos permite extrapolar os resultados para todos os contextos em
que as FGRMs estão inseridas. Adicionalmente, os critérios utilizados para seleção,
como por exemplo, seis meses de desenvolvimento ou ter no mínimo duzentas revisões,
não nos permite afirmar que foram escolhidos os projetos mais representativos para o
nosso público-alvo. A utilização de apenas projetos públicos hospedados no Github
pode ter causado algum tipo de direcionamento, por exemplo, o foco em projetos de
código aberto.
A estrutura das perguntas do formulário pode ter causado impacto na quantidade
de respostas ou na opção escolhida pelos participantes. Esta situação pode ter ocorrido
especialmente quando apresentamos as sugestões. No caso de escrevermos de maneira
extensa a explicação corremos o risco do respondente desistir do item. Por outro lado,
se o texto for escrito de forma “concisa” corremos o risco de ficar vago, o que pode ter
impacto nas respostas. Uma boa opção talvez fosse uma descrição concisa associada
com uma explicação detalhada. A opção por apenas uma descrição concisa pode ter
98 Capítulo 5. Sugestões de Melhorias para as FGRMs
feito a pesquisa ficar superficial.
No espaço destinado a comentários do formulário enviado aos participantes, ve-
rificamos que um deles citou que seria possível que as sugestões propostas podem ter
funcionalidades similares em outras FGRMs. Acreditávamos que a escolha destas 08
sugestões envolveria as principais melhorias para as funcionalidades das FGRMs, mas
existia a possibilidade de alguma sugestão existir de forma parcial ou completa em de-
terminada ferramenta. A condução da avaliação das sugestões melhorias foi realizada
também para identificar este tipo de situação.
5.7 Resumo do Capítulo
O objetivo do levantamento foi avaliar as sugestões de melhorias de funcionalidades
das FGRMs. A avaliação foi realizada com base na opinião de desenvolvedores que
contribuem para projetos de código aberto deste tipo de software. Em geral, as suges-
tões de melhorias foram bem avaliadas. Das 8 sugestões propostas 5 foram avaliadas de
forma positiva (“Concordo” ou “Concordo Fortemente”). Quanto à dificuldade de imple-
mentação, metade delas foi considerada de fácil implementação. No próximo capítulo
discutimos aspectos de implementação da Sugestão #1 na plataforma Github.
Capítulo 6
Implementação de uma Extensão
para FGRM
6.1 Introdução
Neste capítulo complementamos a contribuição do Capítulo 5 com a discussão de as-
pectos de implementação da Sugestão #1-As FGRMs devem fornecer realimentação
(feedback) relacionada à qualidade do texto relatado na plataforma Github. A escolha
da Sugestão #1 e da plataforma Github envolve mais aspectos de conveniência do que
algum tipo de decisão formal.
6.2 Qualidade do Relato de uma RM
É possível considerar que as informações mais relevantes estejam no relato de uma RM,
que é o atributo que representa o texto redigido pelo Reportador. Sabemos que o ato
de relatar uma RM pode ser realizado por um usuário do software ou por um membro
da equipe de desenvolvimento ou manutenção. Por esta razão, podemos encontrar
reportadores com diferentes níveis de conhecimento sobre o sistema. Em determinados
contextos, este tipo de situação pode resultar na baixa qualidade no relato de uma
RM, por exemplo, a falta da informação necessária para sua solução.
A literatura discute que a baixa qualidade do relato prejudicam o andamento
do projeto mais do que RMs duplicadas [Bettenburg et al., 2007]. No estudo reali-
zado por Zimmermann e outros [Zimmermann et al., 2010] foi desenvolvido um levan-
tamento com questionário entre desenvolvedores e usuários de três projetos de código
99
100 Capítulo 6. Implementação de uma Extensão para FGRM
aberto1,2,3. O objetivo era coletar informação de modo a verificar o que produziria um
bom relato. Os resultados demonstraram que, do ponto de vista dos desenvolvedores,
são consideradas informações úteis para estar no relato de uma RM:
• a sequência de ações executadas até o aparecimento da falha, também conhecida
como etapas para reproduzir ;
• a cadeia de registros de ativação (stack traces) que corresponde à descrição das
chamadas de funções ou métodos que ocorreram antes do aparecimento da falha.
No estudo proposto por Zimmermann e outros [Zimmermann et al., 2009] é discu-
tida a importância de que a informação descrita em uma RM seja relevante e completa
a fim de que o problema relatado seja resolvido rapidamente. Contudo, na prática, a
informação apenas chega ao desenvolvedor com a qualidade requerida após diversas in-
terações com o usuário afetado. Com o objetivo de minimizar este problema os autores
propõem um conjunto de diretrizes para a construção de uma extensão capaz de reunir
informações relevantes a partir do usuário além de identificar arquivos que precisam
ser corrigidos para resolver o defeito.
Conforme exposto, a utilização de uma extensão que suporte a melhoria da qua-
lidade do relato pode resultar nas seguintes vantagens: redução no tempo necessário
para análise do que foi solicitado na RM; facilidade na identificação de RMs duplicadas;
melhor disciplina dos reportadores sobre a boa prática de fornecer um relato com maior
qualidade. Estas vantagens têm impacto no custo e qualidade do software produzido.
6.3 Extensão de Suporte à Qualidade do Relato
Considerando as vantagens de analisar a qualidade do relato de uma RM, desenvolve-
mos uma extensão para o módulo de gerenciamento de RMs da plataforma Github4.
De uma maneira geral, a extensão proposta realiza a análise do relato contido em uma
RM e com base nele gera uma realimentação contendo “dicas” com ações que podem
melhorar a qualidade da informação prestada. Nas próximas seções apresentamos com
mais detalhes o desenho e o funcionamento da extensão proposta.
1Apache (http://www.apache.org/)
2Eclipse (https://www.eclipse.org)
3Mozilla (https://www.mozilla.org)
4https://guides.github.com/features/issues/
6.3. Extensão de Suporte à Qualidade do Relato 101
6.3.1 Desenho da Extensão
O objetivo da extensão é analisar de maneira automatizada a qualidade do relato de
uma RM em repositórios do GitHub. No contexto da extensão proposta, o elemento
correspondente ao conceito de uma RM nesta dissertação representa o elemento issue
no âmbito da plataforma Github. Um Repositório é o elemento mais básico do GitHub
e contém os arquivos do projeto (incluindo documentação) e armazena o histórico
de revisões de cada arquivo5. A execução da extensão resulta em um conjunto de
dicas para o responsável por redigir a RM com o intuito de melhorar a qualidade da
informação fornecida no relato, por esta razão recebeu o nome de IssueQuality.
6.3.1.1 Visão Geral
A extensão proposta pode ser vista como um cliente para API do Github6 que possi-
bilita analisar a qualidade da informação fornecida no relato. Uma visão geral sobre o
funcionamento da IssueQuality pode ser visualizada na Figura 6.1. A partir de uma
lista pré-definida de repositórios (1) a extensão solicita, através da API do Github
(2), o conjunto de RMs que estão com a situação “aberta” (etapas 3 e 4). Para cada
uma das RMs recebidas, a ferramenta cria um comentário por meio da API (5) que
é registrado e armazenado no repositório de RMs do Github (etapas 6 e 7). A partir
do comentário gerado o próprio Github se encarrega de notificar (8) o responsável por
relatar a RM (9). A partir desta notificação espera-se que o responsável inclua a in-
formação solicitada através, por exemplo, da criação de um comentário ou a inclusão
de um anexo.
Para gerar o comentário descrito anteriormente, a extensão avalia alguns atribu-
tos do texto que compõe o relato da RM. Os detalhes de como estes atributos são
analisados e o comentário construído quando certos limiares não são atingidos estão
descritos na próxima seção.
6.3.1.2 Análise da Qualidade do Relato
Para cada RM analisada a extensão cria um vetor de características que armazena uma
pontuação para cada atributo do texto que será analisado. A análise dos atributos
utiliza da sintaxe da linguagem de marcação Markdown7, que é o padrão para as RMs
dos repositórios no GitHub.
5https://help.github.com/articles/github-glossary/
6https://api.github.com/
7https://help.github.com/categories/writing-on-github/
102 Capítulo 6. Implementação de uma Extensão para FGRM
Figura 6.1. Visão geral do funcionamento da extensão IssueQuality
Conforme descrito, o resultado da análise feita pela extensão é uma realimenta-
ção na forma de um comentário que é criado na RM. O comentário é composto de
três partes: cabeçalho, corpo e dicas. O cabeçalho apresenta um texto padrão que é
personalizado com o nome do usuário no Github. Ao utilizarmos a sintaxe [Github
login] o próprio Github se encarrega de enviar um e-mail notificando o usuário sobre o
comentário. A Figura 6.2 exibe o cabeçalho padrão incluídos nos comentários.
Figura 6.2. Comentário produzido pela extensão IssueQuality com os cabeçalhos
e dicas padrões.
Ao final do comentário é incluído um conjunto de dicas com objetivo de reforçar os
6.3. Extensão de Suporte à Qualidade do Relato 103
benefícios que a melhoria da qualidade do relato pode ter na solução da RM correspon-
dente, como por exemplo dizendo: “as RMs que são mais fáceis de serem lidas possuem
um tempo de solução menor”. Estas dicas foram obtidas com base na literatura sobre
melhoria da qualidade do relato, especialmente nos trabalhos de Zimmermann e Bet-
tenburg [Bettenburg et al., 2007, Zimmermann et al., 2010]. Na Figura 6.2 é possível
visualizar como algumas dicas são apresentadas.
O corpo é a parte dinâmica do comentário. Ele é construído incluindo fragmentos
de texto quando certos critérios de aceitação não foram atendidos. Por exemplo, caso
não seja detectada a presença de “etapas para reproduzir” no relato de uma RM o se-
guinte fragmento de texto é incluído no corpo do comentário: “Add steps to reproduce”.
Os atributos avaliados e os critérios de aceitação estão descritos na Tabela 6.1.
Atributo Critério de Aceitação
Completude de Palavras-chaves Existência de uma lista representando as etapas executadas até ocorrência do erro.
Arquivos Anexados Pelo menos um arquivo anexado a RM
Fragmentos de Código Existência de pelo menos um fragmento de código no relato da RM.
Completude do Texto As palavras que compõem o relato da RM devem fazer parte de pelo menos duas categorias.
Legibilidade do Texto Dois testes de legibilidade apresentarem valores acima dos limiares.
Tabela 6.1. Critérios de aceitação e forma de análise utilizados na análise de
qualidade do relato.
O corpo do comentário é produzido com análise dos seguintes atributos do relato
da RM: Etapas para Reproduzir, Arquivos Anexados, Fragmentos de Código, Com-
pletude do Texto e Legibilidade do Texto. Estes atributos foram baseados no estudo
realizado por Zimmermann e outros [Zimmermann et al., 2010]. A seguir apresentamos
os detalhes de como cada atributo é avaliado.
Etapas para Reproduzir: Verifica se o reportador incluiu uma lista, na forma de
itens, descrevendo as etapas executadas até a ocorrência da falha. Para detectar este
padrão a extensão aproveita a linguagem Markdown, que é o padrão utilizado para
redigir o relato da RM, e que possui uma sintaxe pré-definida para listas. O pa-
drão é detectado através da utilização de expressões regulares. Pode ocorrer que o
Reportador utilize outro formato para relatar as etapas executadas até a ocorrência
da falha, contudo, o fato da extensão exigir a informação através de uma lista, pode
criar no Reportador uma boa prática. Cabe ressaltar que uma lista com etapas para
reproduzir uma falha foi considerada uma das informações mais relevantes de um re-
lato [Zimmermann et al., 2010].
Arquivos Anexados: Nesta dimensão avaliamos a existência de arquivos anexados
à RM, tais como capturas de telas (screenshots) e cadeia de registros de ativação de
104 Capítulo 6. Implementação de uma Extensão para FGRM
funções (stack trace). A detecção é realizada utilizando expressões regulares que é
a sintaxe padrão para o relato da RM8. Não houve avaliação sobre o conteúdo do
anexo, contudo, conforme descrito na Tabela 6.1, uma mensagem é incluída no corpo
do comentário no caso de nenhum anexo ser detectado. A existência de anexos em
uma RM consta como uma das informações mais relevantes do ponto de vistas dos
desenvolvedores [Zimmermann et al., 2010].
Fragmentos de Código Este atributo de avaliação verifica se fragmentos de código
foram adicionados no relato da RM. O processo de detecção faz uso de expressões
regulares e da sintaxe oferecida pela versão do Markdown utilizado pelo Github9. De
forma similar aos atributos descritos anteriormente, a verificação de fragmentos de
código fonte é binária, ou seja, foi avaliada a existência ou não de trecho de código.
Completude do Texto: Nesta dimensão da avaliação há uma premissa que possa
existir um vocabulário comum no relato de diferentes RMs. Sendo assim, algumas pa-
lavras aparecem com determinada frequência no relato de uma RM, independente do
projeto. Com o objetivo de compreender como as pessoas descrevem problemas de soft-
ware, Ko e outros [Ko et al., 2006] analisaram o título de 200.000 RMs de cinco projetos
de código aberto desenvolvidos na linguagem Java. Nós empregamos esta base de da-
dos10 para construir uma distribuição da frequência de ocorrências de palavras no relato
de uma RM. Em uma primeira etapa, removemos as palavras de parada (stopwords),
reduzimos as vocábulos11 e selecionamos as 100 palavras com maior frequência. Em
seguida, categorizamos as palavras nos seguintes grupos:
• itens de ação (do, work, open)
• relacionado com compilação (build, task)
• relacionado com documentação (support, help, content)
• comportamento esperado ou observável (fail, error, crash)
• relacionado com projeto (management, list)
• relacionado com código fonte (java, code, method)
8https://guides.github.com/features/mastering-markdown/
9https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown
10Disponível para download em http://www.cs.cmu.edu/~marmalade/reports.html.
11Do inglês stemming é o processo de reduzir palavras flexionadas (ou às vezes derivadas) ao seu
tronco (stem), base ou raiz, geralmente uma forma da palavra escrita. Por exemplo um algoritmo de
stemming reduz as palavras “fishing”, “fished” e “fisher” para a raiz “fish”.
6.4. Uso da Extensão em Projetos Reais 105
• elementos da interface do usuário (menu, display, button)
Legibilidade do Texto Por fim a extensão avalia o nível de legibilidade do texto com
base em testes largamente utilizados na literatura [Si & Callan, 2001]. Os testes são
formulados para avaliar a legibilidade do texto, geralmente contando sílabas, palavras
e frases. Neste estudo utilizamos os testes de legibilidade Flesch–Kincaid, Automated
Readability Index - ARI e Dale–Chall Readability Formula. As avaliações foram se-
lecionadas por apresentarem metodologias distintas para determinar a legibilidade do
texto.
O Flesch-Kincaid (FK) é baseado no número de sílabas das palavras que compõem
as sentenças do texto. Existem dois testes, o Flesch Reading Ease e Flesch–Kincaid
Grade Level, que diferem pelo fator de ponderação utilizado. A extensão utilizou o
Flesch Reading Ease que recebe um texto em língua inglesa e retorna um valor inteiro
representando a dificuldade de entendimento. Pontuações mais altas indicam que o
material é mais fácil de ler [Kincaid et al., 1975]. Desta forma, foi considerada como
legibilidade baixa uma pontuação menor do 50. Este valor foi baseado em uma tabela
pré-definida pelo próprio teste [Kincaid et al., 1975].
O ARI considera o número de caracteres de cada palavra. O resultado do teste
é uma representação aproximada do grau de escolaridade no estilo K-12 dos Estados
Unidos necessário para compreender o texto [Senter & Smith, 1967]. De maneira apro-
ximada, o grau 1 corresponde a idades 6-8. O nível de leitura 8 corresponde a jovem de
14 anos. O grau 12, o mais alto no ensino secundário dos EUA, corresponde ao nível
de leitura de 17 anos de idade.
Por outro lado, o teste Dale-Chall é baseado em um conjunto mínimo de pala-
vras. A fórmula usa uma lista de 3000 vocábulos que grupos de estudantes americanos
de quarta série poderiam entender de forma confiável, partindo-se da premissa que
qualquer palavra nessa lista não seja de difícil compreensão [Dale & Chall, 1948]. No
caso dos testes ARI e Dale-Chall a legibilidade será considerada ruim se o valor do
teste for maior ou igual a 13, ou seja, uma pessoa deveria estudar no mínimo 13
anos para “entender”. Esta limiar foi utilizado no trabalho de Zimmermann e ou-
tros [Zimmermann et al., 2010].
6.4 Uso da Extensão em Projetos Reais
A extensão descrita neste Capitulo foi desenvolvida como prova de conceito. Neste
sentido, o desenho e o desenvolvimento tiveram mais foco na viabilidade do que estava
sendo proposto do que melhorar ou sobrepor determinada solução do estado da arte.
106 Capítulo 6. Implementação de uma Extensão para FGRM
Entretanto, com o objetivo de avaliar a extensão em um contexto mais próximo do
cotidiano de desenvolvedores, ela foi executada utilizando os dados de RMs de projetos
código aberto hospedados no Github.
6.4.1 Seleção dos Projetos
Para realizarmos a avaliação a partir de execuções da extensão usamos, por motivos
já explicados, uma amostra de conveniência composta de projetos hospedados na pla-
taforma Github. Para isso utilizamos os mesmos critérios descritos na Seção 5.3.1. As
exceções foi que incluímos a restrição de que o projeto fosse desenvolvido em Java e ava-
liamos os dez primeiros projetos ordenados pelo critério “most stars”. O condicionante
da linguagem Java é por conta de algumas decisões tomadas durante o desenvolvi-
mento da extensão que exigem a utilização da linguagem. Após aplicação dos critérios
descritos obtivemos os projetos apresentados na Tabela 6.2.
Projeto Revisões Ramificações Lançamentos
elasticsearch 27.118 94 174
guava 4.081 84 175
spring-framework 14575 12 106
Tabela 6.2. Projetos utilizados no testes de execução da extensão. Os dados
apresentados têm como referência 23/04/2017.
6.4.1.1 O Processo de Execução
Para avaliarmos a extensão começamos por criar uma ramificação (fork) dos projetos
escolhidos. Este processo é realizado de forma automatizada pelo Github, contudo, não
realiza a cópia das RMs, que no caso deste teste é a informação mais relevante. Para
transpor os dados das RMs foi desenvolvido um processo automatizado que copiava o
título e o relato (corpo da RM) do projeto original para a sua ramificação. Para cada
projeto realizamos a cópia de 100 RMs escolhidas de forma aleatória. A Figura 6.3
exibe uma RM do projeto Guava no lado esquerdo e sua cópia na ramificação criada.
Como pode ser observado título e o relato são idênticos.
Após finalizado o processo de cópia executamos a extensão com as 100 RMs de
cada projeto. Na Figura 6.4 visualizamos o comentário gerado para a RM apresentada
na Figura 6.3. Na próxima seção apresentamos algumas métricas do processo de exe-
cução da extensão nos projetos escolhidos. Como se trata de uma prova de conceito
estes dados podem nos ajudar na avaliação da viabilidade de implantação da extensão
proposta.
6.4. Uso da Extensão em Projetos Reais 107
Figura 6.3. Cópia de uma RM do projeto Guava para a sua ramificação.
Figura 6.4. Comentário para a RM do projeto Guava exibida na Figura 6.3
6.4.2 Resultados
Fizemos algumas medidas de desempenho mas infelizmente não tivemos condições de
elaborar uma estrutura que nos desse medidas repetíveis. Em uma estrutura sujeita
a aspectos não muito bem controlados observamos que o tempo médio para avaliação
de uma RM é de 02 segundos. Em alguns casos o processo é finalizado em menos de
01 segundo. Entretanto, é possível verificar situações em que o tempo para uma gerar
uma realimentação na forma de um comentário é de 30 segundos.
Com a execução utilizando os dados de RMs de projetos reais queríamos verificar
em qual atributo do relato os problemas são mais frequentes. Conforme apresentado na
Tabela 6.1 a extensão avalia os seguintes atributos do relato: Etapas para Reproduzir,
Arquivo Anexado, Fragmentos de Código, Completude de Palavras-Chaves e Legibi-
lidade do Texto. Um comentário é gerado caso o relato não atenda a determinados
108 Capítulo 6. Implementação de uma Extensão para FGRM
critérios para cada atributo analisado. A Figura 6.5 exibe a frequência que um item
foi incluído no comentário para atributo.
299
294
164
134
88Etapas para Reproduzir
Completude de Palavras−Chaves
Legibilidade do texto
Fragmento de Código
Arquivo Anexado
0 50 100 150 200 250 300 350 400
Frequência
Frequência de Dicas por Atributo
Figura 6.5. Frequência de dicas por atributo analisados.
Verificamos na figura que em quase todas as RMs analisadas não foi detectada
a inclusão de arquivos anexados ou de fragmentos de código. É possível observar que
mais da metade do texto relatado apresentou uma legibilidade ruim do ponto de vista
da nossa extensão. A situação menos frequente está relacionada com a inclusão de
“Etapas para Reproduzir”, em que é avaliada a existência de uma lista detalhando os
passos executados até a ocorrência da falha.
Projeto Média (seg) Mediana (seg) Desvio Padrão (seg) Min (seg) Max (seg)
Todos 3,26 3 0,96 1 5
elasticsearch 2,95 3 0,85 1 5
guava 3,16 3 0,88 2 5
spring-framework 3,68 4 1,01 1 5
Tabela 6.3. Número de dicas retornadas pela extensão.
Durante a execução estávamos interessados em avaliar o número de dicas de
melhorias na qualidade do relato que a extensão gerou. Esta informação está exibida
na Tabela 6.3. É possível observar que em média 03 dicas são incluídas em cada RM, ou
seja, três em cada cinco dos itens apresentaram algum tipo de problema. Entretanto,
para que possamos extrapolar qualquer discussão sobre este resultado era necessário
uma avaliação de pessoas envolvidas nos projetos utilizados de modo a detectar falsos
positivos.
6.5. Limitações e Ameaças à Validade 109
6.4.3 Discussão
As execuções que foram realizadas têm como foco avaliar a viabilidade da extensão
proposta. Neste sentido, os resultado obtidos na Seção 6.4 devem ser avaliados sobre
esta ótica. Tomando como base os testes executados, verificamos que, em média, o
tempo que a extensão leva para analisar uma RM, não causa impacto no seu processo
de solução. Contudo, seria importante replicar o mesmo testes de duração em um
ambiente controlado de modo a diminuir algum qualquer tipo de enviesamento.
Com relação aos problemas mais frequentes, é possível que exista uma tendência
dos usuário em não incluir anexos, mas de relatar o problema copiando, por exemplo,
as mensagens contendo a cadeia de registros de ativação no próprio corpo da RM. Não
verificamos estudos que comprovem esta hipótese nem os nossos resultados permitem
comprová-la. Por outro lado, um fator a destacar é que mais da metade das RMs
analisadas apresentaram um texto com baixa legibilidade. Esta situação já foi verificada
em estudos anteriores [Ko et al., 2006, Bettenburg et al., 2007]. Esta métrica depende
menos de uma análise de alguém vinculado ao projeto pelo fato de utilizar índices
existentes e utilizados em diversas áreas para medir legibilidade. Neste sentido pode
ser interessante ao projeto de software instruir os reportadores em fornecer sempre que
possível um relato mais simples e direto.
6.5 Limitações e Ameaças à Validade
O desenvolvimento da extensão possui limitações que ameaçam a sua validade. Ini-
cialmente não é possível determinar se os atributos avaliados são os mais indicados
para medir a qualidade do relato. Eles foram utilizados com base em estudos já re-
alizados [Bettenburg et al., 2007] em que os atributos foram baseados na opinião de
desenvolvedores.
Para que uma dica de melhoria seja disparada é necessário que um ou mais dos
critérios descritos na Tabela 6.1 não sejam atendidos. No caso do atributo “Com-
pletude de Palavras-Chaves” utilizou-se o conjunto de termos do trabalho de Ko e
outros [Ko et al., 2006]. Apesar de ambos os estudos utilizarem projetos desenvolvidos
na linguagem Java não podemos garantir que o conjunto de termos é o mesmo nas RMs
de diferentes projetos.
A legibilidade do texto foi implementada considerando testes descritos na litera-
tura. Em todos os testes existem os limiares que definem o grau de legibilidade de um
texto. Entretanto, não sabemos qual o impacto de utilizarmos estes valores no relato
de uma falha de software, por exemplo. Em geral, os testes de legibilidade são bastante
110 Capítulo 6. Implementação de uma Extensão para FGRM
genéricos, contudo, certas adequações podem ser necessárias para serem utilizados na
análise do relato de uma RM.
A principal limitação deste estudo está na extrapolação dos resultados. O ideal
é que a execução da extensão fosse avaliada por profissionais vinculados aos projetos
utilizados. Esta análise poderia ajudar na detecção de falsos positivos, por exemplo.
6.6 Conclusão
Neste capítulo discutimos alguns dos aspectos envolvidos na implementação de me-
lhorias de funcionalidades de FGRMs. Entendemos que existem vários aspectos que
não foram discutidos, como por exemplo planejamento de capacidade e segurança, mas
acreditamos que foram explicitados alguns aspectos importantes.
Capítulo 7
Conclusão
A contribuição deste trabalho de dissertação está na proposição de melhorias para as
FGRMs tomando como base a literatura da área e a opinião de profissionais envolvi-
dos com Manutenção de Software. As atividades empregadas para manter e evoluir
software são complexas e caras e, portanto, merecem atenção da comunidade científica
e da indústria. Surge então a necessidade do desenvolvimento de técnicas, processos
e ferramentas que reduzam o custo e o esforço envolvidos nas atividades de manuten-
ção e evolução de software. Conforme discutido, as FGRMs desempenham um papel
fundamental que ultrapassa apenas registrar as falhas e os pedidos de melhorias dos
softwares.
Com base no estudo descrito na Seção 2.3 verificamos que as FGRMs dispõem de
funcionalidades para gerenciar a criação, consulta, atualização e destruição de uma RM.
Entretanto, em algumas plataformas, tais como o Github e o Gitlab, não existe uma
clara separação entre o gerenciamento das RMs e o controle de versão do código. Um
possível desdobramento desta dissertação é avaliar o impacto deste tipo de abordagem
no processo de manutenção de software. Este tipo de análise poderia modificar o
desenvolvimento de futuras versões das FGRMs, especialmente para aquelas que estão
acopladas a repositórios de software.
No Capítulo 3, ao revisarmos a literatura sobre melhorias nas FGRMs, apresenta-
mos estudos que discutem diversos aspectos dos problemas e desafios do gerenciamento
das RMs. A maior frequência de trabalhos está relacionada com temas como atribuição
automática e RMs duplicadas. Conforme discutimos, alguns autores afirmam que, do
ponto de vista dos desenvolvedores, a duplicação dos pedidos de manutenção não seria
o principal problema a ser tratado. Em contrapartida, os profissionais estariam mais
interessados em propostas que melhorem a qualidade do relato. Esta situação pode ser
o sinal de um possível desacoplamento entre as necessidades dos desenvolvedores e o
111
112 Capítulo 7. Conclusão
que está sendo proposto na literatura. Apesar da qualidade dos estudos sobre melho-
rias das funções das FGRMs, tais avanços, aparentemente, não são de conhecimento
das equipes de manutenção. Com base nos resultados da amostra do levantamento
realizado no Capítulo 4 percebemos que os profissionais consultados estão satisfeitos
com as funcionalidades oferecidas. Todavia, a nossa visão é que existem muitos outros
comportamentos que poderiam ser acoplados a este tipo de software de modo a me-
lhorar as atividades de manter e evoluir um software. Da mesma forma, as práticas
propostas pelos agilistas vêm sendo adotadas por algumas equipes de manutenção de
software. Um trabalho futuro desta dissertação é aprofundar no estudo da relação en-
tre as práticas dos agilistas e a manutenção de software. Em especial, entender como
as FGRMs poderiam implantar funcionalidades com o objetivo de suportar alguns dos
métodos.
De maneira relacionada, em uma das classificações feitas no Mapeamento con-
duzido, os estudos foram agrupados pelo tipo de papel desempenhado na Manutenção
de Software. Utilizamos uma classificação baseada na que foi proposta por Polo e ou-
tros [Polo et al., 1999b] apresentada em 1999. Em nossas pesquisas na literatura não
foi possível identificar uma discussão mais recente sobre os papéis desempenhados na
Manutenção de Software. Entendemos que seria importante a condução de um novo
trabalho com o objetivo de descrever e avaliar os papéis presentes no processo de man-
ter um software. Este estudo poderia avaliar, por exemplo, como as práticas propostas
pelos agilistas podem ter alterado a estrutura de trabalho das equipes de manutenção.
O nível de satisfação dos profissionais com as funcionalidades das FGRMs pode
ser considerado alto. Esta percepção foi obtida mediante um levantamento por ques-
tionário apresentado no Capítulo 4. Entretanto, o mesmo estudo demonstrou que os
participantes desconhecem o potencial deste tipo de software. Esta situação pode ser
observada pelo fato que, ao apresentarmos propostas de melhorias que eram discutidas
na literatura, o grau de aceitação foi elevado. Isto poderia ser considerado um distan-
ciamento entre o estado da arte e o estado da prática das melhorias para as FGRMs.
Entendemos que esta dissertação contribuiu neste sentido ao apresentar para os pro-
fissionais algumas das melhorias discutidas na literatura. Este conhecimento pode ser
utilizado pelos desenvolvedores para exigir ferramentas que atendam às suas demandas.
Ao mesmo tempo, o nosso trabalho conseguiu coletar, discutir e apresentar algumas
das necessidades dos desenvolvedores. Da mesma forma, pesquisadores podem usar
esta informação para propor estudos propondo melhorias para as FGRMs.
Esta dissertação contribuiu para o estudo das FGRMs com a apresentação de um
conjunto de melhorias no Capítulo 5. Considerando que a maioria delas teve uma boa
aceitação, as recomendações podem ser utilizadas por pesquisadores, pelos responsá-
113
veis por desenvolver e manter projetos de FGRMs e por os profissionais envolvidos com
Manutenção de Software. Um possível trabalho futuro é a avaliação do impacto da im-
plantação destas sugestões. Esta análise poderia ser realizada mediante um Estudo de
Caso. Além disso, seria importante conduzir uma análise qualitativa da relevância das
sugestões propostas. Um estudo com base em entrevistas poderia melhorar o entendi-
mento da opinião dos profissionais e esclarecer como tratar situações onde os critérios
definidos nas sugestões de melhorias não possam ser atendidos. Neste eventual estudo
seria importante realizar uma avaliação mais aprofundada sobre questões que surgiram
durante a avaliação das sugestões de melhorias e que não puderam ser esclarecidas,
como por exemplo, o ranqueamento pela reputação do Reportador.
Na elaboração do modelo conceitual do contexto das FGRMs, que pudesse dar
suporte as discussões realizadas nesta dissertação, verificamos que o tratamento da
ambiguidade e inconsistência, entre os diversos artigos que tratam do assunto, exigia
maior esforço do que foi possível investir. Neste sentido, entendemos que seria impor-
tante a realização de um estudo com o objetivo de melhorar a organização dos conceitos
da área de Manutenção de Software, em especial sobre as RMs e FGRMs.
No Capítulo 6 implementamos uma das sugestões como uma extensão para o
módulo de gerenciamento de RMs issues da plataforma Github. Por ser tratar de
uma Prova de Conceito, não foi realizada uma avaliação com membros dos projetos
selecionados. Por esta razão não é possível generalizar os resultados. Um trabalho
futuro é conduzir um estudo em uma configuração em que seja possível avaliar a opinião
de alguém envolvido no projeto estudado. Entendemos que seria importante conduzir
um estudo com os mesmos objetivos desta dissertação, entretanto, coletando a opinião
daqueles que reportam as RMs.
Conforme apresentado na Seção 2.3 as FGRMs disponibilizam diversos métodos
para o registro de uma RM: envio de e-mail, formulários que podem ser disponibi-
lizados em sítios da Web e etc. Entretanto, a maneira mais comum é o formulário
disponibilizado pelas FGRMs, conforme exibido na Figura 2.5. Segundo o nosso en-
tendimento, o processo de criação de RMs poderia ser melhorado com a utilização de
uma interface que estimule e possibilite o Reportador fornecer as informações necessá-
rias à análise da RM. Uma possível abordagem é a utilização pelas FGRMs de uma
interface de criação de RMs através de um chatbot [Mauldin, 1994, Huang et al., 2007].
Esta maneira interativa de criação de uma RM, dentre outros aspectos, pode ajudar
no fornecimento das informações necessárias para a correspondente solução.
Os dados obtidos e os artefatos utilizados nesta dissertação (ques-
tionários dos levantamentos, cartões de classificação, planilha e etc) es-
tão disponíveis no endereço eletrônico https://archive.org/details/
114 Capítulo 7. Conclusão
dissertacao-vagner-clementino-um-estudo.
Referências Bibliográficas
[Aggarwal et al., 2014] Aggarwal, A.; Waghmare, G. & Sureka, A. (2014). Mining
issue tracking systems using topic models for trend analysis, corpus exploration,
and understanding evolution. Em Proceedings of the 3rd International Workshop on
Realizing Artificial Intelligence Synergies in Software Engineering, RAISE 2014, pp.
52--58, New York, NY, USA. ACM.
[Aggarwal et al., 2017] Aggarwal, K.; Timbers, F.; Rutgers, T.; Hindle, A.; Stroulia,
E. & Greiner, R. (2017). Detecting duplicate bug reports with Software Engineering
domain knowledge. Journal of Software: Evolution and Process, 29(3).
[Aiello & Sachs, 2010] Aiello, B. & Sachs, L. (2010). Configuration Management Best
Practices: Practical Methods that Work in the Real World (Adobe Reader). Pearson
Education.
[Alipour et al., 2013] Alipour, A.; Hindle, A. & Stroulia, E. (2013). A contextual
approach towards more accurate duplicate bug report detection. Em Proceedings of
the 10th Working Conference on Mining Software Repositories, pp. 183--192. IEEE
Press.
[Aljarah et al., 2011] Aljarah, I.; Banitaan, S.; Abufardeh, S.; Jin, W. & Salem, S.
(2011). Selecting discriminating terms for bug assignment: a formal analysis. Em
Proceedings of the 7th International Conference on Predictive Models in Software
Engineering, p. 12. ACM.
[Antoniol et al., 2008] Antoniol, G.; Ayari, K.; Di Penta, M.; Khomh, F. & Guéhéneuc,
Y.-G. (2008). Is it a bug or an enhancement?: a text-based approach to classify
change requests. Em Proceedings of the 2008 conference of the Center for Advanced
Studies on collaborative research: meeting of minds, p. 23. ACM.
115
116 Referências Bibliográficas
[Anvik et al., 2005] Anvik, J.; Hiew, L. & Murphy, G. C. (2005). Coping with an
open bug repository. Em Proceedings of the 2005 OOPSLA workshop on Eclipse
technology eXchange, pp. 35--39. ACM.
[Arnold, 1996] Arnold, R. S. (1996). Software change impact analysis. IEEE Computer
Society Press.
[Banerjee et al., 2012] Banerjee, S.; Cukic, B. & Adjeroh, D. (2012). Automated du-
plicate bug report classification using subsequence matching. Em High-Assurance
Systems Engineering (HASE), 2012 IEEE 14th International Symposium on, pp.
74--81. IEEE.
[Bangcharoensap et al., 2012] Bangcharoensap, P.; Ihara, A.; Kamei, Y. & Matsu-
moto, K.-i. (2012). Locating source code to be fixed based on initial bug reports-a
case study on the eclipse project. Em Empirical Software Engineering in Practice
(IWESEP), 2012 Fourth International Workshop on, pp. 10--15. IEEE.
[Banitaan & Alenezi, 2013] Banitaan, S. & Alenezi, M. (2013). Decoba: Utilizing de-
velopers communities in bug assignment. Em Machine Learning and Applications
(ICMLA), 2013 12th International Conference on, volume 2, pp. 66--71. IEEE.
[Baysal & Holmes, 2012] Baysal, O. & Holmes, R. (2012). A Qualitative Study of
Mozillas Process Management Practices. David R. Cheriton School of Computer
Science, University of Waterloo, Waterloo, Canada, Tech. Rep. CS-2012-10.
[Baysal et al., 2013] Baysal, O.; Holmes, R. & Godfrey, M. W. (2013). Situational
awareness: Personalizing issue tracking systems. Em Proceedings of the 2013 Inter-
national Conference on Software Engineering, ICSE ’13, pp. 1185--1188, Piscataway,
NJ, USA. IEEE Press.
[Behl et al., 2014] Behl, D.; Handa, S. & Arora, A. (2014). A bug mining tool to
identify and analyze security bugs using naive Bayes and TF-IDF. Em Optimization,
Reliabilty, and Information Technology (ICROIT), 2014 International Conference
on, pp. 294--299. IEEE.
[Bennett & Rajlich, 2000] Bennett, K. H. & Rajlich, V. T. (2000). Software mainte-
nance and evolution: a roadmap. Em Proceedings of the Conference on the Future
of Software Engineering, pp. 73--87. ACM.
[Bertram et al., 2010] Bertram, D.; Voida, A.; Greenberg, S. & Walker, R. (2010).
Communication, collaboration, and bugs: The social nature of issue tracking in
Referências Bibliográficas 117
small, collocated teams. Em Proceedings of the 2010 ACM Conference on Computer
Supported Cooperative Work, CSCW ’10, pp. 291--300, New York, NY, USA. ACM.
[Bettenburg et al., 2007] Bettenburg, N.; Just, S.; Schröter, A.; Weiß, C.; Premraj, R.
& Zimmermann, T. (2007). Quality of bug reports in Eclipse. Em Proceedings of
the 2007 OOPSLA workshop on eclipse technology eXchange, pp. 21--25. ACM.
[Bettenburg et al., 2008] Bettenburg, N.; Premraj, R.; Zimmermann, T. & Kim, S.
(2008). Duplicate bug reports considered harmful. . . really? Em Software Mainte-
nance, 2008. ICSM 2008. IEEE international conference on, pp. 337--345. IEEE.
[Bhattacharya & Neamtiu, 2011] Bhattacharya, P. & Neamtiu, I. (2011). Bug-fix time
prediction models: can we do better? Em Proceedings of the 8th Working Conference
on Mining Software Repositories, pp. 207--210. ACM.
[Boxill et al., 1997] Boxill, I.; Chambers, C. M. & Wint, E. (1997). Introduction to
social research: With applications to the Caribbean. University of The West Indies
Press.
[Breu et al., 2010] Breu, S.; Premraj, R.; Sillito, J. & Zimmermann, T. (2010). Infor-
mation needs in bug reports: improving cooperation between developers and users.
Em Proceedings of the 2010 ACM conference on Computer supported cooperative
work, pp. 301--310. ACM.
[Cavalcanti et al., 2014] Cavalcanti, Y. C.; Mota Silveira Neto, P. A.; Machado, I.
d. C.; Vale, T. F.; Almeida, E. S. & Meira, S. R. d. L. (2014). Challenges and
opportunities for software change request repositories: a systematic mapping study.
Journal of Software: Evolution and Process, 26(7):620--653.
[Cavalcanti et al., 2013] Cavalcanti, Y. C.; Neto, P. A. d. M. S.; Lucrédio, D.; Vale,
T.; de Almeida, E. S. & de Lemos Meira, S. R. (2013). The bug report duplication
problem: an exploratory study. Software Quality Journal, 21(1):39--66.
[Cerulo & Canfora, 2004] Cerulo, L. & Canfora, G. (2004). A taxonomy of information
retrieval models and tools. CIT. Journal of computing and information technology,
12(3):175--194.
[Chaparro, 2017] Chaparro, O. (2017). Improving bug reporting, duplicate detection,
and localization. Em Proceedings of the 39th International Conference on Software
Engineering Companion, pp. 421--424. IEEE Press.
118 Referências Bibliográficas
[Chawla & Singh, 2015] Chawla, I. & Singh, S. K. (2015). An automated approach
for bug categorization using fuzzy logic. Em Proceedings of the 8th India Software
Engineering Conference, pp. 90--99. ACM.
[Choudhari & Suman, 2014] Choudhari, J. & Suman, U. (2014). Extended Iterative
Maintenance Life Cycle Using eXtreme Programming. SIGSOFT Softw. Eng. Notes,
39(1):1--12. ISSN 0163-5948.
[Corley et al., 2011] Corley, C. S.; Kraft, N. A.; Etzkorn, L. H. & Lukins, S. K. (2011).
Recovering traceability links between source code and fixed bugs via patch analysis.
Em Proceedings of the 6th International Workshop on Traceability in Emerging Forms
of Software Engineering, pp. 31--37. ACM.
[Correa et al., 2013] Correa, D.; Lal, S.; Saini, A. & Sureka, A. (2013). Samekana: A
browser extension for including relevant web links in issue tracking system discus-
sion forum. Em 2013 20th Asia-Pacific Software Engineering Conference (APSEC),
volume 1, pp. 25--33. IEEE.
[Dal Sassc & Lanza, 2013] Dal Sassc, T. & Lanza, M. (2013). A closer look at bugs.
Em Software Visualization (VISSOFT), 2013 First IEEE Working Conference on,
pp. 1--4. IEEE.
[Dal Sasso & Lanza, 2014] Dal Sasso, T. & Lanza, M. (2014). In∗ bug: Visual analy-
tics of bug repositories. Em Software Maintenance, Reengineering and Reverse En-
gineering (CSMR-WCRE), 2014 Software Evolution Week-IEEE Conference on, pp.
415--419. IEEE.
[Dale & Chall, 1948] Dale, E. & Chall, J. S. (1948). A formula for predicting readabi-
lity: Instructions. Educational research bulletin, pp. 37--54.
[Damevski et al., 2016] Damevski, K.; Shepherd, D. & Pollock, L. (2016). A field study
of how developers locate features in source code. Empirical Software Engineering,
21(2):724--747.
[de Mello et al., 2014] de Mello, R. M.; da Silva, P. C.; Runeson, P. & Travassos, G. H.
(2014). Towards a framework to support large scale sampling in Software Engine-
ering surveys. Em Proceedings of the 8th ACM/IEEE International Symposium on
Empirical Software Engineering and Measurement, p. 48. ACM.
[de Mello et al., 2015] de Mello, R. M.; Da Silva, P. C. & Travassos, G. H. (2015).
Investigating probabilistic sampling approaches for large-scale surveys in Software
Engineering. Journal of Software Engineering Research and Development, 3(1):8.
Referências Bibliográficas 119
[de Mello & Travassos, 2013] de Mello, R. M. & Travassos, G. H. (2013). Would so-
ciable software engineers observe better? Em Empirical Software Engineering and
Measurement, 2013 ACM/IEEE International Symposium on, pp. 279--282. IEEE.
[Di Lucca et al., 2002] Di Lucca, G. A.; Di Penta, M. & Gradara, S. (2002). An ap-
proach to classify software maintenance requests. Em Software Maintenance, 2002.
Proceedings. International Conference on, pp. 93--102. IEEE.
[Dybå & Dingsøyr, 2008] Dybå, T. & Dingsøyr, T. (2008). Empirical studies of agile
software development: A systematic review. Information and software technology,
50(9):833--859.
[Dybå et al., 2007] Dybå, T.; Dingsøyr, T. & Hanssen, G. K. (2007). Applying syste-
matic reviews to diverse study types: An experience report. Em ESEM, volume 7,
pp. 225--234.
[Dybå et al., 2006] Dybå, T.; Kampenes, V. B. & Sjøberg, D. I. (2006). A systematic
review of statistical power in Software Engineering experiments. Information and
Software Technology, 48(8):745--755.
[Fan & Yan, 2010] Fan, W. & Yan, Z. (2010). Factors affecting response rates of the
web survey: A systematic review. Computers in human behavior, 26(2):132--139.
[Fowler & Foemmel, 2006] Fowler, M. & Foemmel, M. (2006). Continuous integration.
Thought-Works) http://www.thoughtworks.com/ContinuousIntegration.pdf, p. 122.
[Fox & Patterson, 2013] Fox, A. & Patterson, D. (2013). Engineering Software as a
Service: An Agile Approach Using Cloud Computing. Strawberry Canyon LLC. ISBN
9780984881246.
[Gegick et al., 2010] Gegick, M.; Rotella, P. & Xie, T. (2010). Identifying security bug
reports via text mining: An industrial case study. Em 2010 7th IEEE Working
Conference on Mining Software Repositories (MSR 2010), pp. 11--20. IEEE.
[Heeager & Rose, 2015] Heeager, L. T. & Rose, J. (2015). Optimising Agile develop-
ment practices for the maintenance operation: nine heuristics. Empirical Software
Engineering, 20(6):1762--1784. ISSN 15737616.
[Hesse-Biber, 2010] Hesse-Biber, S. N. (2010). Mixed methods research: Merging theory
with practice. Guilford Press.
120 Referências Bibliográficas
[Hindle et al., 2016] Hindle, A.; Alipour, A. & Stroulia, E. (2016). A contextual appro-
ach towards more accurate duplicate bug report detection and ranking. Empirical
Software Engineering, 21(2):368--410.
[Hora et al., 2012] Hora, A.; Anquetil, N.; Ducasse, S.; Bhatti, M.; Couto, C.; Valente,
M. T. & Martins, J. (2012). Bug maps: A tool for the visual exploration and analysis
of bugs. Em Software Maintenance and Reengineering (CSMR), 2012 16th European
Conference on, pp. 523--526. IEEE.
[Hosseini et al., 2012] Hosseini, H.; Nguyen, R. & Godfrey, M. W. (2012). A market-
based bug allocation mechanism using predictive bug lifetimes. Em Software Mainte-
nance and Reengineering (CSMR), 2012 16th European Conference on, pp. 149--158.
IEEE.
[Hovemeyer & Pugh, 2004] Hovemeyer, D. & Pugh, W. (2004). Finding bugs is easy.
SIGPLAN Not., 39(12):92--106. ISSN 0362-1340.
[Hu et al., 2014] Hu, H.; Zhang, H.; Xuan, J. & Sun, W. (2014). Effective bug triage
based on historical bug-fix information. Em 2014 IEEE 25th International Sympo-
sium on Software Reliability Engineering, pp. 122--132. IEEE.
[Huang et al., 2007] Huang, J.; Zhou, M. & Yang, D. (2007). Extracting chatbot kno-
wledge from online discussion forums. Em IJCAI, volume 7, pp. 423--428.
[IEEE, 1990] IEEE (1990). IEEE Standard Glossary of Software Engineering Termi-
nology. IEEE Std 610.12-1990, pp. 1–84.
[IEEE, 1999] IEEE (1999). IEEE Standard for Software Maintenance, IEEE Std 1219-
1998, volume 2. IEEE Press.
[IEEE, 2006] IEEE (2006). Norma ISO/IEC 14764:2006 (E) IEEE Std 14764-2006
Revision of IEEE Std 1219-1998). IEEE std. IEEE. ISBN 9780738149608.
[Ihara et al., 2009] Ihara, A.; Ohira, M. & Matsumoto, K.-i. (2009). An analysis
method for improving a bug modification process in open source software develop-
ment. Em Proceedings of the joint international and annual ERCIM workshops on
Principles of software evolution (IWPSE) and software evolution (Evol) workshops,
pp. 135--144. ACM.
[ISO/IEC, 2001] ISO/IEC (2001). ISO/IEC 9126. Software Engineering – Product
quality. ISO/IEC.
Referências Bibliográficas 121
[ISO/IEC, 2006] ISO/IEC (2006). International Standard - ISO/IEC 14764 IEEE Std
14764-2006 Software Engineering 2013; Software Life Cycle Processes 2013; Main-
tenance. ISO/IEC 14764:2006 (E) IEEE Std 14764-2006 Revision of IEEE Std
1219-1998), pp. 01–46.
[ISO/IEC/IEEE, 2008] ISO/IEC/IEEE (2008). ISO/IEC/IEEE Standard for Systems
and Software Engineering - Software Life Cycle Processes.
[ISO/IEEE, 1998] ISO/IEEE (1998). IEEE Standard for Software Maintenance.
[Izquierdo et al., 2015] Izquierdo, J. L. C.; Cosentino, V.; Rolandi, B.; Bergel, A. &
Cabot, J. (2015). Gila: Github label analyzer. Em 2015 IEEE 22nd International
Conference on Software Analysis, Evolution, and Reengineering (SANER), pp. 479-
-483. IEEE.
[Just et al., 2008] Just, S.; Premraj, R. & Zimmermann, T. (2008). Towards the next
generation of bug tracking systems. Em 2008 IEEE Symposium on Visual Languages
and Human-Centric Computing, pp. 82--85. IEEE.
[Kagdi et al., 2012] Kagdi, H.; Gethers, M.; Poshyvanyk, D. & Hammad, M. (2012).
Assigning change requests to software developers. Journal of Software: Evolution
and Process, 24(1):3--33.
[Kaiser & Passonneau, 2011] Kaiser, L. W. B. X. G. & Passonneau, R. (2011). Bug-
miner: Software reliability analysis via data mining of bug reports. Em Proceedings
of the 25th International Conference on Software Engineering and Knowledge Engi-
neering, volume 12, pp. 09--0500.
[Karim et al., 2017] Karim, M. R.; Ihara, A.; Yang, X.; Iida, H. & Matsumoto, K.
(2017). Understanding key features of high-impact bug reports. Em Empirical
Software Engineering in Practice (IWESEP), 2017 8th International Workshop on,
pp. 53--58. IEEE.
[Kasunic, 2005] Kasunic, M. (2005). Designing an effective survey. Relatório técnico,
DTIC Document.
[Kaur & Singh, 2015] Kaur, U. & Singh, G. (2015). A review on software maintenance
issues and how to reduce maintenance efforts. International Journal of Computer
Applications, 118(1).
[Kaushik & Tahvildari, 2012] Kaushik, N. & Tahvildari, L. (2012). A comparative
study of the performance of IR models on duplicate bug detection. Em Software
122 Referências Bibliográficas
Maintenance and Reengineering (CSMR), 2012 16th European Conference on, pp.
159--168. IEEE.
[Keele, 2007] Keele, S. (2007). Guidelines for performing systematic literature reviews
in Software Engineering. Em Technical report, Ver. 2.3 EBSE Technical Report.
EBSE.
[Kincaid et al., 1975] Kincaid, J. P.; Fishburne Jr, R. P.; Rogers, R. L. & Chissom,
B. S. (1975). Derivation of new readability formulas (Automated Readability Index,
Fog Count and Flesch Reading Ease formula) for Navy enlisted personnel. Relatório
técnico, DTIC Document.
[Ko et al., 2006] Ko, A. J.; Myers, B. A. & Chau, D. H. (2006). A linguistic analysis of
how people describe software problems. Em Visual Languages and Human-Centric
Computing, 2006. VL/HCC 2006. IEEE Symposium on, pp. 127--134. IEEE.
[Kochhar et al., 2014] Kochhar, P. S.; Thung, F. & Lo, D. (2014). Automatic fine-
grained issue report reclassification. Em Engineering of Complex Computer Systems
(ICECCS), 2014 19th International Conference on, pp. 126--135. IEEE.
[Kononenko et al., 2014] Kononenko, O.; Baysal, O.; Holmes, R. & Godfrey, M. W.
(2014). Dashboards: Enhancing developer situational awareness. Em Companion
Proceedings of the 36th International Conference on Software Engineering, ICSE
Companion 2014, pp. 552--555, New York, NY, USA. ACM.
[Koopaei & Hamou-Lhadj, 2015] Koopaei, N. E. & Hamou-Lhadj, A. (2015). Crashau-
tomata: an approach for the detection of duplicate crash reports based on genera-
lizable automata. Em Proceedings of the 25th Annual International Conference on
Computer Science and Software Engineering, pp. 201--210. IBM Corp.
[Lehman, 1980] Lehman, M. M. (1980). On understanding laws, evolution, and conser-
vation in the large-program life cycle. Journal of Systems and Software, 1:213--221.
[Lerch & Mezini, 2013] Lerch, J. & Mezini, M. (2013). Finding duplicates of your yet
unwritten bug report. Em Software Maintenance and Reengineering (CSMR), 2013
17th European Conference on, pp. 69--78. IEEE.
[Lientz & Swanson, 1980] Lientz, B. P. & Swanson, E. B. (1980). Software Mainte-
nance Management. Addison-Wesley Longman Publishing Co., Inc., Boston, MA,
USA. ISBN 0201042053.
Referências Bibliográficas 123
[Liu & Tan, 2014] Liu, K. & Tan, H. B. K. (2014). Faceted bug report search with
topic model. Em Computer Software and Applications Conference (COMPSAC),
2014 IEEE 38th Annual, pp. 123--128. IEEE.
[Liu et al., 2013] Liu, K.; Tan, H. B. K. & Zhang, H. (2013). Has this bug been
reported? Em Reverse Engineering (WCRE), 2013 20th Working Conference on,
pp. 82–91.
[Malheiros et al., 2012] Malheiros, Y.; Moraes, A.; Trindade, C. & Meira, S. (2012).
A source code recommender system to support newcomers. Em 2012 IEEE 36th
Annual Computer Software and Applications Conference (COMPSAC), pp. 19--24.
IEEE.
[Mani et al., 2012] Mani, S.; Catherine, R.; Sinha, V. S. & Dubey, A. (2012). Ausum:
approach for unsupervised bug report summarization. Em Proceedings of the ACM
SIGSOFT 20th International Symposium on the Foundations of Software Enginee-
ring, p. 11. ACM.
[Marshall, 1996] Marshall, M. N. (1996). Sampling for qualitative research. Family
practice, 13(6):522--526.
[Mauldin, 1994] Mauldin, M. L. (1994). Chatterbots, tinymuds, and the Turing test:
Entering the loebner prize competition. Em AAAI, volume 94, pp. 16--21.
[Meyer, 2014] Meyer, B. (2014). Agile. The Good, the Hype and the Ugly. Switzerland:
Springer International Publishing.
[Moran, 2015] Moran, K. (2015). Enhancing Android application bug reporting. Em
Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering,
pp. 1045--1047. ACM.
[Moran et al., 2015] Moran, K.; Linares-Vásquez, M.; Bernal-Cárdenas, C. & Poshy-
vanyk, D. (2015). Auto-completing bug reports for Android applications. Em Proce-
edings of the 2015 10th Joint Meeting on Foundations of Software Engineering, pp.
673--686. ACM.
[Naguib et al., 2013] Naguib, H.; Narayan, N.; Brügge, B. & Helal, D. (2013). Bug
report assignee recommendation using activity profiles. Em Mining Software Repo-
sitories (MSR), 2013 10th IEEE Working Conference on, pp. 22--30. IEEE.
[Nagwani et al., 2013] Nagwani, N.; Verma, S. & Mehta, K. K. (2013). Generating
taxonomic terms for software bug classification by utilizing topic models based on
124 Referências Bibliográficas
Latent Dirichlet Allocation. Em ICT and Knowledge Engineering (ICT&KE), 2013
11th International Conference on, pp. 1--5. IEEE.
[Nagwani & Verma, 2010] Nagwani, N. K. & Verma, S. (2010). Predictive data mining
model for software bug estimation using average weighted similarity. Em Advance
Computing Conference (IACC), 2010 IEEE 2nd International, pp. 373--378. IEEE.
[Nagwani & Verma, 2012] Nagwani, N. K. & Verma, S. (2012). Predicting expert de-
velopers for newly reported bugs using frequent terms similarities of bug attributes.
Em 2011 Ninth International Conference on ICT and Knowledge Engineering, pp.
113--117. IEEE.
[Netto et al., 2010] Netto, F.; Barros, M. O. & Alvim, A. C. (2010). An automa-
ted approach for scheduling bug fix tasks. Em Software Engineering (SBES), 2010
Brazilian Symposium on, pp. 80--89. IEEE.
[Nguyen et al., 2012] Nguyen, A. T.; Nguyen, T. T.; Nguyen, H. A. & Nguyen, T. N.
(2012). Multi-layered approach for recovering links between bug reports and fixes.
Em Proceedings of the ACM SIGSOFT 20th International Symposium on the Foun-
dations of Software Engineering, FSE ’12, pp. 63:1--63:11, New York, NY, USA.
ACM.
[Ohira et al., 2016] Ohira, M.; Yoshiyuki, H. & Yamatani, Y. (2016). A case study
on the misclassification of software performance issues in an issue tracking system.
Em Computer and Information Science (ICIS), 2016 IEEE/ACIS 15th International
Conference on, pp. 1--6. IEEE.
[Otoom et al., 2016] Otoom, A. F.; Al-Shdaifat, D.; Hammad, M. & Abdallah, E. E.
(2016). Severity prediction of software bugs. Em 2016 7th International Conference
on Information and Communication Systems (ICICS), pp. 92--95. IEEE.
[Paulk et al., 1993] Paulk, M. C.; Curtis, B.; Chrissis, M. B. & Weber, C. V. (1993).
Capability Maturity Model, Version 1.1. IEEE Softw., 10(4):18--27. ISSN 0740-7459.
[Petersen et al., 2008] Petersen, K.; Feldt, R.; Mujtaba, S. & Mattsson, M. (2008).
Systematic mapping studies in Software Engineering. EASE’08 Proceedings of the
12th international conference on Evaluation and Assessment in Software Enginee-
ring, pp. 68--77. ISSN 02181940.
[Petersen et al., 2015] Petersen, K.; Vakkalanka, S. & Kuzniarz, L. (2015). Guidelines
for conducting systematic mapping studies in Software Engineering: An update.
Information and Software Technology, 64:1--18. ISSN 09505849.
Referências Bibliográficas 125
[Polo et al., 1999a] Polo, M.; Piattini, M.; Ruiz, F. & Calero, C. (1999a). MANTEMA:
a complete rigorous methodology for supporting maintenance based on the ISO/IEC
12207 standard. Em Software Maintenance and Reengineering, 1999. Proceedings of
the Third European Conference on, pp. 178–181.
[Polo et al., 1999b] Polo, M.; Piattini, M.; Ruiz, F. & Calero, C. (1999b). Roles in the
maintenance process. ACM SIGSOFT Software Engineering Notes, 24(4):84--86.
ISSN 01635948.
[Prifti et al., 2011] Prifti, T.; Banerjee, S. & Cukic, B. (2011). Detecting bug duplicate
reports through local references. Em Proceedings of the 7th International Conference
on Predictive Models in Software Engineering, p. 8. ACM.
[Robbins & Heiberger, 2011] Robbins, N. B. & Heiberger, R. M. (2011). Plotting Li-
kert and other rating scales. Em Proceedings of the 2011 Joint Statistical Meeting,
pp. 1058--1066.
[Rocha et al., 2015] Rocha, H.; Oliveira, G.; Marques-Neto, H. & Valente, M. T.
(2015). NextBug: a Bugzilla extension for recommending similar bugs. Journal
of Software Engineering Research and Development, 3(1).
[Romo & Capiluppi, 2015] Romo, B. A. & Capiluppi, A. (2015). Towards an auto-
mation of the traceability of bugs from development logs: A study based on open
source software. Em Proceedings of the 19th International Conference on Evaluation
and Assessment in Software Engineering, EASE ’15, pp. 33:1--33:6, New York, NY,
USA. ACM.
[Rudzki et al., 2009] Rudzki, J.; Hammouda, I. & Mikkola, T. (2009). Agile experien-
ces in a software service company. Em Software Engineering and Advanced Applica-
tions, 2009. SEAA’09. 35th Euromicro Conference on, pp. 224--228. IEEE.
[Runeson et al., 2007] Runeson, P.; Alexandersson, M. & Nyholm, O. (2007). Detec-
tion of duplicate defect reports using natural language processing. Em Proceedings of
the 29th International Conference on Software Engineering, ICSE ’07, pp. 499--510,
Washington, DC, USA. IEEE Computer Society.
[Sadat et al., 2017] Sadat, M.; Bener, A. B. & Miranskyy, A. V. (2017). Rediscovery
datasets: connecting duplicate reports. Em Proceedings of the 14th International
Conference on Mining Software Repositories, pp. 527--530. IEEE Press.
126 Referências Bibliográficas
[Schwaber & Beedle, 2002] Schwaber, K. & Beedle, M. (2002). Agile software develop-
ment with Scrum, volume 1. Prentice Hall Upper Saddle River.
[Senter & Smith, 1967] Senter, R. & Smith, E. A. (1967). Automated readability index.
Relatório técnico, DTIC Document.
[Shokripour et al., 2012] Shokripour, R.; Kasirun, Z. M.; Zamani, S. & Anvik, J.
(2012). Automatic bug assignment using information extraction methods. Em Ad-
vanced Computer Science Applications and Technologies (ACSAT), 2012 Internati-
onal Conference on, pp. 144--149. IEEE.
[Si & Callan, 2001] Si, L. & Callan, J. (2001). A statistical model for scientific reada-
bility. Em Proceedings of the Tenth International Conference on Information and
Knowledge Management, CIKM ’01, pp. 574--576, New York, NY, USA. ACM.
[Singer, 1998] Singer, J. (1998). Practices of software maintenance. Em Software Main-
tenance, 1998. Proceedings., International Conference on, pp. 139--145. IEEE.
[Singh & Chaturvedi, 2011] Singh, V. & Chaturvedi, K. K. (2011). Bug tracking and
reliability assessment system (BTRAS). International Journal of Software Enginee-
ring and Its Applications, 5(4):1--14.
[Sjøberg et al., 2005] Sjøberg, D. I.; Hannay, J. E.; Hansen, O.; Kampenes, V. B.;
Karahasanovic, A.; Liborg, N.-K. & Rekdal, A. C. (2005). A survey of controlled
experiments in Software Engineering. IEEE Transactions on Software Engineering,
31(9):733--753.
[Society et al., 2014] Society, I. C.; Bourque, P. & Fairley, R. E. (2014). Guide to
the Software Engineering Body of Knowledge (SWEBOK(R)): Version 3.0. IEEE
Computer Society Press, Los Alamitos, CA, USA, 3rd edição. ISBN 0769551661,
9780769551661.
[Soltan & Mostafa, 2014] Soltan, H. & Mostafa, S. (2014). Leanness and agility within
maintenance process. Em International Journal of Engineering Research and Tech-
nology, volume 3, pp. 553–555.
[Somasundaram & Murphy, 2012] Somasundaram, K. & Murphy, G. C. (2012). Auto-
matic categorization of bug reports using Latent Dirichlet Allocation. Em Procee-
dings of the 5th India software Engineering Conference, pp. 125--130. ACM.
Referências Bibliográficas 127
[Song et al., 2010] Song, Y.; Wang, X.; Xie, T.; Zhang, L. & Mei, H. (2010). Jdf:
detecting duplicate bug reports in jazz. Em Proceedings of the 32nd ACM/IEEE
International Conference on Software Engineering-Volume 2, pp. 315--316. ACM.
[Sun et al., 2011] Sun, C.; Lo, D.; Khoo, S.-C. & Jiang, J. (2011). Towards more accu-
rate retrieval of duplicate bug reports. Em Proceedings of the 2011 26th IEEE/ACM
International Conference on Automated Software Engineering, pp. 253--262. IEEE
Computer Society.
[Sun et al., 2010] Sun, C.; Lo, D.; Wang, X.; Jiang, J. & Khoo, S.-C. (2010). A discri-
minative model approach for accurate duplicate bug report retrieval. Em Proceedings
of the 32nd ACM/IEEE International Conference on Software Engineering-Volume
1, pp. 45--54. ACM.
[Svensson & Host, 2005a] Svensson, H. & Host, M. (2005a). Introducing an agile pro-
cess in a software maintenance and evolution organization. Em Ninth European
Conference on Software Maintenance and Reengineering, pp. 256–264. ISSN 1534-
5351.
[Svensson & Host, 2005b] Svensson, H. & Host, M. (2005b). Introducing an agile pro-
cess in a software maintenance and evolution organization. Em Software Maintenance
and Reengineering, 2005. CSMR 2005. Ninth European Conference on, pp. 256--264.
IEEE.
[Takama & Kurosawa, 2013] Takama, Y. & Kurosawa, T. (2013). Application of mo-
nitoring support visualization to bug tracking systems. Em Industrial Electronics
(ISIE), 2013 IEEE International Symposium on, pp. 1--5. IEEE.
[Thompson, 2012] Thompson, S. (2012). Sampling. CourseSmart. Wiley. ISBN
9781118162941.
[Thung et al., 2014a] Thung, F.; Kochhar, P. S. & Lo, D. (2014a). Dupfinder: in-
tegrated tool support for duplicate bug report detection. Em Proceedings of the
29th ACM/IEEE international conference on Automated software engineering, pp.
871--874. ACM.
[Thung et al., 2014b] Thung, F.; Le, T.-D. B.; Kochhar, P. S. & Lo, D. (2014b). Bu-
glocalizer: Integrated tool support for bug localization. Em Proceedings of the 22Nd
ACM SIGSOFT International Symposium on Foundations of Software Engineering,
FSE 2014, pp. 767--770, New York, NY, USA. ACM.
128 Referências Bibliográficas
[Thung et al., 2013] Thung, F.; Lo, D. & Jiang, L. (2013). Automatic recovery of
root causes from bug-fixing changes. Em 2013 20th Working Conference on Reverse
Engineering (WCRE), pp. 92--101. IEEE.
[Thung et al., 2012a] Thung, F.; Lo, D.; Jiang, L. et al. (2012a). Are faults localizable?
Em Mining Software Repositories (MSR), 2012 9th IEEE Working Conference on,
pp. 74--77. IEEE.
[Thung et al., 2012b] Thung, F.; Lo, D.; Jiang, L.; Rahman, F.; Devanbu, P. T. et al.
(2012b). When would this bug get reported? Em Software Maintenance (ICSM),
2012 28th IEEE International Conference on, pp. 420--429. IEEE.
[Tian et al., 2013] Tian, Y.; Lo, D. & Sun, C. (2013). Drone: Predicting priority of
reported bugs by multi-factor analysis. Em 2013 IEEE International Conference on
Software Maintenance, pp. 200–209. ISSN 1063-6773.
[Tian et al., 2015] Tian, Y.; Lo, D.; Xia, X. & Sun, C. (2015). Automated prediction
of bug report priority using multi-factor analysis. Empirical Software Engineering,
20(5):1354--1383.
[Tian et al., 2012] Tian, Y.; Sun, C. & Lo, D. (2012). Improved duplicate bug report
identification. Em Software Maintenance and Reengineering (CSMR), 2012 16th
European Conference on, pp. 385--390. IEEE.
[Tomašev et al., 2013] Tomašev, N.; Leban, G. & Mladenić, D. (2013). Exploiting hubs
for self-adaptive secondary re-ranking in bug report duplicate detection. Em Infor-
mation Technology Interfaces (ITI), Proceedings of the ITI 2013 35th International
Conference on, pp. 131--136. IEEE.
[Tripathy & Naik, 2015] Tripathy, P. & Naik, K. (2015). Software Evolution and Main-
tenance. Wiley. ISBN 9780470603413.
[Tu & Zhang, 2014] Tu, F. & Zhang, F. (2014). Measuring the quality of issue trac-
king data. Em Proceedings of the 6th Asia-Pacific Symposium on Internetware on
Internetware, pp. 76--79. ACM.
[Valdivia Garcia & Shihab, 2014] Valdivia Garcia, H. & Shihab, E. (2014). Characte-
rizing and predicting blocking bugs in open source projects. Em Proceedings of the
11th working conference on mining software repositories, pp. 72--81. ACM.
Referências Bibliográficas 129
[Vijayakumar & Bhuvaneswari, 2014] Vijayakumar, K. & Bhuvaneswari, V. (2014).
How much effort needed to fix the bug? a data mining approach for effort esti-
mation and analysing of bug report attributes in firefox. Em Intelligent Computing
Applications (ICICA), 2014 International Conference on, pp. 335--339. IEEE.
[Voegler et al., 2014] Voegler, J.; Bornschein, J. & Weber, G. (2014). Markdown–
a simple syntax for transcription of accessible study materials. Em International
Conference on Computers for Handicapped Persons, pp. 545--548. Springer.
[Wang & Sarma, 2011] Wang, J. & Sarma, A. (2011). Which bug should i fix: helping
new developers onboard a new project. Em Proceedings of the 4th International
Workshop on Cooperative and Human Aspects of Software Engineering, pp. 76--79.
ACM.
[White et al., 2015] White, M.; Linares-Vásquez, M.; Johnson, P.; Bernal-Cárdenas,
C. & Poshyvanyk, D. (2015). Generating reproducible and replayable bug reports
from Android application crashes. Em 2015 IEEE 23rd International Conference on
Program Comprehension, pp. 48--59. IEEE.
[Wohlin, 2014] Wohlin, C. (2014). Guidelines for snowballing in systematic literature
studies and a replication in Software Engineering. Em Proceedings of the 18th in-
ternational conference on evaluation and assessment in Software Engineering, p. 38.
ACM.
[Wohlin et al., 2012] Wohlin, C.; Runeson, P.; Höst, M.; Ohlsson, M. C.; Regnell, B.
& Wesslén, A. (2012). Experimentation in Software Engineering. Springer Science
& Business Media.
[Wong et al., 2014] Wong, C.-P.; Xiong, Y.; Zhang, H.; Hao, D.; Zhang, L. & Mei,
H. (2014). Boosting bug-report-oriented fault localization with segmentation and
stack-trace analysis. Em ICSME, pp. 181--190. Citeseer.
[Wu et al., 2011] Wu, W.; Zhang, W.; Yang, Y. & Wang, Q. (2011). Drex: Developer
recommendation with k-nearest-neighbor search and expertise ranking. Em 2011
18th Asia-Pacific Software Engineering Conference, pp. 389--396. IEEE.
[Xia et al., 2015] Xia, X.; Lo, D.; Shihab, E.; Wang, X. & Zhou, B. (2015). Automa-
tic, high accuracy prediction of reopened bugs. Automated Software Engineering,
22(1):75--109.
130 Referências Bibliográficas
[Xuan et al., 2012] Xuan, J.; Jiang, H.; Ren, Z. & Zou, W. (2012). Developer prio-
ritization in bug repositories. Em 2012 34th International Conference on Software
Engineering (ICSE), pp. 25--35. IEEE.
[Yu & Mishra, 2013] Yu, L. & Mishra, A. (2013). An empirical study of Lehman’s Law
on software quality evolution. Int J Software Informatics, 7(3):469--481.
[Zanetti et al., 2013] Zanetti, M. S.; Scholtes, I.; Tessone, C. J. & Schweitzer, F. (2013).
Categorizing bugs with social networks: a case study on four open source software
communities. Em Proceedings of the 2013 International Conference on Software
Engineering, pp. 1032--1041. IEEE Press.
[Zhang et al., 2016] Zhang, T.; Jiang, H.; Luo, X. & Chan, A. T. (2016). A literature
review of research in bug resolution: Tasks, challenges and future directions. The
Computer Journal, 59(5):741--773.
[Zhang & Lee, 2011] Zhang, T. & Lee, B. (2011). A bug rule based technique with
feedback for classifying bug reports. Em Computer and Information Technology
(CIT), 2011 IEEE 11th International Conference on, pp. 336--343. IEEE.
[Zhang et al., 2014] Zhang, W.; Han, G. & Wang, Q. (2014). Butter: An approach
to bug triage with topic modeling and heterogeneous network analysis. Em Cloud
Computing and Big Data (CCBD), 2014 International Conference on, pp. 62--69.
IEEE.
[Zibran, 2016] Zibran, M. F. (2016). On the effectiveness of labeled latent dirichlet
allocation in automatic bug-report categorization. Em Proceedings of the 38th In-
ternational Conference on Software Engineering Companion, pp. 713--715. ACM.
[Zimmermann et al., 2010] Zimmermann, T.; Premraj, R.; Bettenburg, N.; Just, S.;
Schroter, A. &Weiss, C. (2010). What makes a good bug report? IEEE Transactions
on Software Engineering, 36(5):618--643.
[Zimmermann et al., 2009] Zimmermann, T.; Premraj, R.; Sillito, J. & Breu, S. (2009).
Improving bug tracking systems. Em Software Engineering - Companion Volume,
2009. ICSE-Companion 2009. 31st International Conference on, pp. 247–250.
Apêndice A
Lista de Ferramenta de
Gerenciamento de Requisição de
mudanças
131
Nome Licença Lançamento
Apache Bloodhound Apache License 2012
Assembla Tickets Proprietary, hosted. Available for f 2008
Axosoft Proprietary, Saas 2002
BMC Remedy Action Request System Proprietary 1992
Bontq Proprietary, hosted. 2010
Brimir AGPL 2013
Bugzilla MPL 1998
Debbugs GPL 1994
FogBugz Saas 2000
Fossil SCM BSD 2006
FusionForge GPLv2 2009
Gestionnaire libre de parc informatique GPLv2 2003
GNATS GPL 1992
Google Code Hosting Proprietary, hosted; available for 2004
HP Quality Center Proprietary 1995
IBM Rational ClearQuest Proprietary 1998
IBM Rational Team Concert Proprietary 2008
JIRA Proprietary. Free community licen 2002
Kayako SupportSuite Proprietary, some parts GPL 2001
Launchpad AGPL 2004
Liberum Help Desk GPL 2000
MantisBT GPL 2000
Microsoft Dynamics CRM Proprietary, Commercial 2003
org-mode GPL 2003
Open-source Ticket Request System AGPL 2002
Pivotal Tracker Proprietary, free version for public 2008
Plain Ticket Proprietary, online, hosted. 2011
Planbox Proprietary, free version 2009
QuickBase Proprietary 2000
Redmine GPLv2 2006
Request Tracker GPLv2 1999
Roundup MIT license (ZPL v 2.0 for the tem 2001
StarTeam Proprietary 2011
Supportworks Proprietary 1994
SysAid Proprietary 2002
Targetprocess Proprietary 2005
Team Foundation Server Proprietary, Commercial 2005
Twproject Proprietary, some parts LGPL 2003
TechExcel's DevTrack Proprietary 1997
TestTrack Proprietary 1996
The Bug Genie Mozilla Public License 1.1 2003
Trac Bug Tracking System New BSD 2006
TrackerSuite.Net Proprietary 2006
Tuleap GPLv2 2011
Usersnap Bug Tracking System Proprietary 2013
Web Help Desk Proprietary 1999
Wrike Project management software Proprietary, hosted 2006
YouTrack Proprietary, stand-alone and hosted 2009
Zoho BugTracker Proprietary 2011
Apêndice B
Formulário Aplicado para Seleção
das Ferramentas
133
Ferramentas de Gerenciamento de Requisição
de Mudança: avaliando as mais representativas
*Obrigatório
As manutenções em software podem ser classificadas
em corretiva, adaptativa, perfectiva e preventiva
[Lientz & Swanson, 1980]. A ISO 14764 propõe que
exista um elemento comum denominado Requisição
de Mudança que representa as características
comuns a todas aqueles tipos de manutenção. Por
conta do seu volume, as Requisições de Mudanças
precisam ser gerenciadas por um sistema de
informação ao qual denominamos Ferramentas de
Gerenciamento de Requisição de Mudança (FGRM). A
Figura 01 exibe alguns exemplos de ferramentas que
podem ser classificadas como FGRM. Esta pesquisa
tem por objetivo caracterizar algumas ferramentas do
tipo FGRM. Ao final, dentre outras informações,
queremos saber quais ferramentas são consideradas
mais completas, adequadas, funcionais ou usáveis.
Caso seja do seu interesse podemos compartilhar
com você estes resultados! Em caso de dúvidas favor
enviar um e-mail para vagnercs@dcc.ufmg.br ou
acesse minha página pessoal
http://homepages.dcc.ufmg.br/~vagnercs/
Figura 01: Exemplos de Ferramentas de
Gerenciamento de Requisição de Mudança
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
1 de 8 01-02-2017 21:44
Background
Informe o horário que você começou a responder *
Exemplo: 08h30
1. 
Dentro do contexto de sua organização, qual é o nome de sua função atual? *2. 
Faça um breve relato de suas principais atribuições. *3. 
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
2 de 8 01-02-2017 21:44
Considerando a sua atual ocupação, as suas atividade estão mais vinculadas
com: *
Marcar apenas uma oval.
desenvolvimento de novos softwares
manutenção e evolução de software já existentes
sou estudante
Outro:
4. 
Você possui quanto tempo de experiência em desenvolvimento/manutenção
de software? *
Marcar apenas uma oval.
Menos de 03 anos
3 - 10 anos
10 - 20 anos
20 ou mais anos
Estudante
Outro:
5. 
Como você classifica o seu local de trabalho? *
Marcar apenas uma oval.
Empresa pública de software
Empresa privada de sotware
Projeto de código aberto
Estudante
Outro:
6. 
Qual é o tamanho de sua equipe? *
Marcar apenas uma oval.
1 (apenas eu)
2 - 5
6 - 10
Mais do que 10
7. 
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
3 de 8 01-02-2017 21:44
Com qual frequência você está envolvido nas seguintes atividades? *
Marcar apenas uma oval por linha.
Nunca
Uma
vez
por
mês
Algumas
vezes
no mês
Semanalmente
Algumas
vezes
na
semana
Algumas
vezes no
dia /
diariamente
Registrar
Requisição de
Mudança em
uma FGRM
Decidir se uma
Requisição de
Mudança será
aceita ou
rejeitada e qual
tipo de
manutenção
deverá ser
aplicada.
Planejar a fila de
Requisições de
Mudança (RM)
aceitas e atribuir
atribuição das
RM’s para o
desenvolver
mais apto.
Realizar as
ações que irão
solucionar a
Requisição de
Mudança.
Avaliar se uma
Requisição de
Mudança foi
solucionada
corretamente.
Definir os
padrões e
procedimentos
que compõe o
processo de
manutenção que
será utilizado.
8. 
Relevância das Ferramentas
Nesta pesquisa será apresentado um conjunto de ferramentas onde queremos saber 
qual a relevância de cada uma delas dentro do domínio  das FGRM. Neste sentido, 
não estamos interessado em avaliar se uma determinada ferramenta é melhor do que 
outra, mas em determinar a notoriedade de uma FGRM em comparação com as que 
foram listadas. Caso uma ferramenta não esteja na lista a seguir, utilize a opção 
"Outro" para informá-la.
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
4 de 8 01-02-2017 21:44
Informe o nome da FGRM que você utiliza atualmente *9. 
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
5 de 8 01-02-2017 21:44
Para cada uma das ferramentas listada a seguir pedimos que avalie a sua
relevância dentro do domínio de aplicação das FGRM *
Marcar apenas uma oval por linha.
Não
conheço a
ferramenta
Nada
relevante
Pouco
relevante Relevante
Muito
relevante
Apache
Bloodhound
Assembla Tickets
Axosoft
BMC Remedy
Action Request
System
Bontq
Brimir
Bugzilla
Debbugs
FogBugz
Fossil SCM
FusionForge
Gestionnaire libre
de parc
informatique
GNATS GNU
Google Code
Hosting
HP Quality
Center
IBM Rational
ClearQuest
IBM Rational
Team Concert
JIRA Software
Kayako
SupportSuite
Launchpad
Liberum Help
Desk
Mantis Bug
Tracker
Microsoft
Dynamics CRM
org-mode
Open-source
Ticket Request
System
Pivotal Tracker
Plain Ticket
Planbox
QuickBase
Redmine
Request Tracker
Roundup Issue
Tracker
10. 
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
6 de 8 01-02-2017 21:44
StarTeam
Supportworks
SysAid
Targetprocess
Team Foundation
Server
Twproject
TechExcel's
DevTrack
TestTrack
The Bug Genie
Trac Bug
Tracking System
TrackerSuite.Net
Tuleap
Usersnap Bug
Tracking System
Web Help Desk
Wrike Project
management
software
YouTrack
Zoho BugTracker
CA Service Desk
SourceSafe
Não
conheço a
ferramenta
Nada
relevante
Pouco
relevante Relevante
Muito
relevante
Você gostaria de receber o resultado desta pesquisa *
Marcar apenas uma oval.
Sim
Não
11. 
Você gostaria de participar de outra pesquisa sobre esse mesmo tema? *
Marcar apenas uma oval.
Sim
Não
12. 
Informe o horário que você terminou de responder *
Exemplo: 08h30
13. 
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
7 de 8 01-02-2017 21:44
Powered by
Deseja incluir informações adicionais ou fazer sugestões sobre esta
pesquisa?
14. 
Ferramentas de Gerenciamento de Requisição ... https://docs.google.com/forms/d/1mBW5cJds2R...
8 de 8 01-02-2017 21:44

Apêndice C
Modelo da Mensagem Enviada no
Levantamento para Seleção das
Ferramentas
143

Apêndice D
Formulário dos Cartões Ordenados
145
Cartões Ordenados - Ferramentas de
Gerenciamento de Requisições de Mudança
*Obrigatório
Nome da Ferramenta *
Marcar apenas uma oval.
Bugzilla
Mantis Bug Tracker
JIRA Software
Redmine
Github Issue Tracking System
Gitlab Issue Tracking System
1. 
URL Documentação *2. 
Nome da Funcionalidade *3. 
Descrição da Funcionalidade *4. 
Cartões Ordenados - Ferramentas de Gerencia... https://docs.google.com/forms/d/1MOARl_15L...
1 de 2 01-02-2017 22:59
Powered by
Observações Adicionais5. 
Cartões Ordenados - Ferramentas de Gerencia... https://docs.google.com/forms/d/1MOARl_15L...
2 de 2 01-02-2017 22:59

Apêndice E
Sentenças de Busca por Base de
Dados
149
Base de Dados Setença de Busca
ACM Digital Library
("issue tracking" OR "bug tracking" OR "issue-tracking" OR "bug-tracking"  OR "bug repository" OR "issue repository") AND 
("issue report" OR "bug report" OR "bug priorization" OR "bug fix" OR "bug assigment" OR "bug reassigment" OR "bug triage"    
OR "duplicate bug" OR "reopened bug" OR "bug impact" OR "bug localization" OR "bug prediction"  OR "bug risk" OR "bug 
severity" OR "bug classification") AND ("extension" OR "plugin" OR "add-on" OR "tool" OR "improving" OR "personalization")
IEEE Explore
("Document Title":"issue tracking") OR
("Document Title":"bug tracking") OR
("Document Title":"issue-tracking") OR
("Document Title":"bug-tracking") OR
("Document Title":"bug repository") OR
("Document Title":"issue repository") AND
("Document Title":"issue report" OR
 "Document Title":"bug report"  OR
 "Document Title":"bug priorization" OR
"Document Title":"bug fix" OR
"Document Title":"bug assigment" OR
"Document Title":"bug reassigment" OR
"Document Title":"bug triage" OR
"Document Title":"duplicate bug" OR
"Document Title":"reopened bug" OR
"Document Title":"bug impact" OR
"Document Title":"bug localization" OR
"Document Title":"bug prediction" OR
"Document Title":"bug risk" OR
"Document Title":"bug severity" OR
"Document Title":"bug classification"
 ) AND ("Document Title":"extension" OR
"Document Title":"plugin" OR
"Document Title":"add-on" OR
"Document Title":"tool" OR
"Document Title":"improving" OR
"Document Title":"personalization")
Inspec/Compendex
((("issue tracking" OR "bug tracking" OR "issue-tracking" OR "bug-tracking" OR "bug repository" OR "issue repository") WN 
KY) AND (("issue report" OR "bug report" OR "bug priorization" OR "bug fix" OR "bug assigment" OR "bug reassigment" OR 
"bug triage" OR "duplicate bug" OR "reopened bug" OR "bug impact" OR "bug localization") WN KY)) AND (("extension" OR 
"plugin" OR "add-on" OR "tool" OR "improving" OR "personalization") WN KY))
OR
((("issue tracking" OR "bug tracking" OR "issue-tracking" OR "bug-tracking" OR "bug repository" OR "issue repository") WN 
KY) AND (("bug prediction"  OR "bug risk" OR "bug severity" OR "bug classification") WN KY)) AND (("extension" OR "plugin" 
OR "add-on" OR "tool" OR "improving" OR "personalization") WN KY))
Scopus
( TITLE-ABS-KEY ( ( "issue tracking"  OR  "bug tracking"  OR  "issue-tracking"  OR  "bug-tracking"  OR  "bug repository"  OR  
"issue repository" ) ) )  AND  ( TITLE-ABS-KEY ( "issue report"  OR  "bug report"  OR  "bug priorization"  OR  "bug fix"  OR  
"bug assigment"  OR  "bug reassigment"  OR  "bug triage"  OR  "duplicate bug"  OR  "reopened bug"  OR  "bug impact"  OR  
"bug localization"  OR  "bug prediction"  OR  "bug risk"  OR  "bug severity" ) )  AND  ( TITLE-ABS-KEY ( "extension"  OR  
"plugin"  OR  "add-on"  OR  "tool"  OR  "improving"  OR  "personalization" ) )
Apêndice F
Modelo da Mensagem Enviada no
Levantamento com Profissionais
151

Apêndice G
Lista de Projetos Avaliação
Sugestões de Melhorias
153
Projeto  URL
BLOODHOUND https://github.com/apache/bloodhound
BUGS https://github.com/veritech/bugs
BUGTRACKINGSYSTEM https://github.com/sunilbooks/bugtrackingsystem
BUGTRAX https://github.com/peithvergil/bugtrax
BUGTRCKR https://github.com/sn0opy/bugtrckr
BUGZILLA https://github.com/bugzilla/bugzilla
DEBBUGS https://github.com/dondelelcaro/debbugs
FAVEO-HELPDESK https://github.com/ladybirdweb/faveo-helpdesk
FIXPHASE https://github.com/abdulazizalaa/fixphase
FLYSPRAY https://github.com/flyspray/flyspray
FUSIONFORGE https://github.com/fusionforge/fusionforge
GNATS https://github.com/pld-linux/gnats
KATANABUGTRACKING https://github.com/grievoushead/katanabugtracking
MANTISBT https://github.com/mantisbt/mantisbt
NBT https://github.com/mycelium/nbt
OHBUGZ https://github.com/kadnan/ohbugz
POTRACHENO https://github.com/dallaylaen/potracheno
PRAELATUS https://github.com/praelatus/praelatus
QUICKRADAR https://github.com/amyworrall/quickradar
REDMINE https://github.com/redmine/redmine
SIMPLEBUGS https://github.com/repox/simplebugs
https://github.com/grievoushead/katanabugtracking

Apêndice H
Formulário Aplicado para Avaliação
das Sugestões de Melhorias
157
Towards Change Request Management
Systems New Features
In the context of Software Maintenance, a Change Request - CR is the common 
element to corrective, adaptive, perfective, or preventive software problem types. 
Because of its volume, CRs need to be managed by tools. We use the term Change 
Request Management Systems (CRMS) to refer to the set or group of these tools. This 
class of systems serves as a central repository for monitoring the progress of bug 
reports, requesting additional information from reporters, and discussing potential 
solutions for fixing the bug. 
The CRMSs are very efficient and effective, but the literature in Software Engineering 
presents studies that discuss their improvement needs. Based on the hypothesis that 
CRMSs need improvements, we conducted a study to evaluate a collection of CRMSs 
new features recommendations and to understand the level of difficulty to develop 
these features.
This form was developed so that most of the answers are optional. We provide a field 
where you can enter your email so that it can be removed from our list of participants. 
We don´t want to be considered spammers. Please let us know if you want to receive a 
copy of the results. 
For questions please email to vagnercs@dcc.ufmg.br or access my homepage on 
http://homepages.dcc.ufmg.br/~vagnercs. Thank you for your contribution. I hope not 
only to complete my master's degree but also to contribute to the evolution of Software 
Engineering.
*Obrigatório
Some examples of Change Request Management
Systems
Please choose a project you are contributing the most.
Marcar apenas uma oval.
bugzilla
mantisbt
redmine
Outro:
1. 
For each recommendation listed below, choose your level of agreement with
the following statement: "I would like this feature in my project." *
Marcar apenas uma oval por linha.
Strongly
disagree Disagree
Neither
agree or
disagree
Agree Stronglyagree
#1 - The CRMSs
should support
some type of
automatic feedback
related on the
quality of reported
text.
#2 - The CRMSs
should enable
source code search
contained in your
report, comments or
attachments.
#3 - The CRMSs
should allow
Change Requests
ranking according to
the reporters
reputation.
#4 - The CRMSs
should provide
shortcuts for filtering
and ranking, for
example the latest
CRs accessed by a
developer.
#5 - The CRMSs
should support
Continuous
Integration
processes.
#6- The CRMSs
should give support
beyond plain text
specifications, for
example Markdown.
#7 - The CRMSs
should provide
automatic
classification of CRs
in terms of urgency.
#8 - The CRMSs
should support
shared task,
allowing
collaborative work.
2. 
For each recommendation listed below, choose your level of difficulty to
develop it? *
Marcar apenas uma oval por linha.
Very
difficult Difficult Neutral Easy
Very
easy
#1 - The CRMSs should
support some type of
automatic feedback related
on the quality of reported text.
#2 - The CRMSs should
enable source code search
contained in your report,
comments or attachments.
#3 - The CRMSs should allow
Change Requests ranking
according to the reporters
reputation.
#4 - The CRMSs should
provide shortcuts for filtering
and ranking, for example the
latest CRs accessed by a
developer.
#5 - The CRMSs should
support Continuous
Integration processes.
#6- The CRMSs should give
support beyond plain text
specifications, for example
Markdown.
#7 - The CRMSs should
provide automatic
classification of CRs in turns
urgency and unexpecteness
CRs.
#8 - The CRMSs should
support shared task, allowing
collaborative work.
3. 
What is your current location?
Marcar apenas uma oval.
Africa
Central America
Latin America
North America
Asia
Europe
Oceania
4. 
In your organization context, what is
your job title?
5. 
Considering your current occupation, please identify the activities that you
are more engaged with:
Marcar apenas uma oval.
development of new software
maintenance and evolution of software
I am a student
Outro:
6. 
For how long have you been working in development or maintenance of
software?
Marcar apenas uma oval.
Less than 03 years
3 - 10 years
10 - 20 years
More than 20 years
7. 
What is the current size of your team?
Marcar apenas uma oval.
1 (myself only)
2 - 5
6 - 10
More than 10
8. 
Would you like to receive the results of this research?
Marcar apenas uma oval.
Yes
No
9. 
Would you like to participate in other research about the theme?
Marcar apenas uma oval.
Yes
No
10. 
Enter your e-mail if you want to delete
it from our list of participants.
11. 
Powered by
Would you like to include additional information or suggestions about this
research?
12. 

Apêndice I
Modelo da Mensagem Enviada no
Levantamento sobre as Sugestões
de Melhorias das Funcionalidades
das FGRMs
165