Inappropriate Software Changes: Rejection and Rework (Tese de Doutorado)

Minha defesa de doutorado na UFBA.

Vídeo: https://youtu.be/RLSbIsS4Ojs
Mais informações: http://rodrigorgs.github.io/phd-thesis/

--

Data: 17/7/2015, 10 horas
Local: Sala 12, Instituto de Matematica - UFBA

Banca Examinadora:

Prof. Dr. Dalton Serey Guerrero, UFCG
Prof. Dr. Marco Aurélio Gerosa, IME-USP
Prof. Dr. Cláudio Nogueira Sant'Anna, UFBA
Prof. Dr. Roberto Almeida Bittencourt, UEFS (co-orientador)
Profa. Dra. Christina von Flach Garcia Chavez, UFBA (orientadora)

Transcript

1. Inappropriate Software Changes: Rejection and Rework Inappropriate Software Changes: Rejection and Rework Programa Multiinstitucional de Pós-Graduação em Ciência da Computação – PMCC Tese de Doutorado 17 de julho de 2015, 10h, sala 12, IM-UFBA Rodrigo Rocha Gomes e Souza
2. rejeição
 da mudança código-fonte revisão testes retrabalho 㿂 defeitos na
 versão final mudança
 inadequada Problema 2 㿂
3. 3 – retrabalho + produtividade programador
4. 4 retrabalho gerente
5. 5 retrabalho causas retrabalho efeitos pesquisador
6. 6 An et al., 2014 AN, L.; KHOMH, F.; ADAMS, B. Supplementary bug fixes vs. re-opened bugs. In: 14th IEEE International Working Conference on Source Code Analysis and Manipulation, SCAM 2014, Victoria, BC, Canada, September 28-29, 2014. [S.l.: s.n.], 2014. p. 205– 214. detectar rejeição de mudanças tíquetes commits
7. 7 rejeição
 da mudança retrabalho 㿂 defeitos na
 versão final mudança
 inadequada processo A processo B aprimorar
 a detecção quantificar e entender comparar 2) Quantificar o retrabalho desencadeado por mudanças inadequadas 3) Validar hipóteses sobre rejeição de mudanças e retrabalho 4) Avaliar o impacto de mudanças no processo de desenvolvimento sobre o retrabalho Objetivos 1) Propor e comparar técnicas para detectar rejeição de mudanças
8. Dados 8 Mozilla Core Firefox Thunderbird
9. 9 Conceitos (com foco na Mozilla)
10. 10 reversão precoce reversão tardia fecha tíquete reabertura reversão revisão negativa (commit suplementar) cria tíquete cria mudança e solicita revisão build automatizado testes manuais faz commit
11. 11 Até 03/2011 Releases tradicionais Escopo fixo Mais de um ano Desde 03/2011 Releases rápidas Tempo fixo 6 semanas Ciclos de Release
12. 12 Problema Fulano Sicrano central
13. 13 integr. central reverte Mozilla Core Firefox Thunderbird (desde 2011) Solução: repositórios de integração Fulano Sicrano merge xerife
14. 14 Trabalhos Relacionados
15. 15 11% das
 revisões de código
 são negativas Jeong et al., 2009 JEONG, G. et al. Improving code review by predicting reviewers and acceptance of patches. [S.l.], 2009. Technical report.
16. 16 22–33% dos tíquetes
 estão associados a
 commits suplementares Park et al., 2012 PARK, J. et al. An empirical study of supplementary bug fixes. In: 9th IEEE Working Conference on Mining Software Repositories. [S.l.: s.n.], 2012. p. 40– 49. ISSN 2160-1852.
17. 17 1–12% dos tíquetes
 são reabertos Almossawi, 2012
 Jongyindee et al., 2011 JONGYINDEE, A. et al. Good or bad committers? a case study of committers’ cautious- ness and the consequences on the bug fixing process in the Eclipse project. In: Proc. of the 2011 Joint Conf. of the 21st International Workshop on Softw. Measurement and the 6th International Conf. on Softw. Process and Product Measurement. Washington, DC, USA: IEEE Computer Society, 2011. p. 116–125. ISBN 978-0-7695-4565-3. ALMOSSAWI, A. Investigating the architectural drivers of defects in open-source software systems: an empirical study of defects and reopened defects in GNOME. Disserta ̧c ̃ao (Mestrado) — Massachusetts Institute of Technology, 2012.
18. 18 Tíquetes reabertos 
 possuem um tempo de vida
 50–100% mais longo (em média) Shihab et al., 2010
 Park et al., 2012 PARK, J. et al. An empirical study of supplementary bug fixes. In: 9th IEEE Working Conference on Mining Software Repositories. [S.l.: s.n.], 2012. p. 40– 49. ISSN 2160-1852. SHIHAB, E. et al. Predicting re-opened bugs: A case study on the eclipse project. In: Proceedings of the 2010 17th Working Conference on Reverse Engineering. Washington, DC, USA: IEEE Computer Society, 2010. (WCRE ’10), p. 249–258. ISBN 978-0-7695- 4123-5.
19. 19 Shihab et al., 2010 REABERTURA predição Zimmermann et al., 2012 causa SHIHAB, E. et al. Predicting re-opened bugs: A case study on the eclipse project. In: Proceedings of the 2010 17th Working Conference on Reverse Engineering. Washington, DC, USA: IEEE Computer Society, 2010. (WCRE ’10), p. 249–258. ISBN 978-0-7695- 4123-5. ZIMMERMANN, T. et al. Characterizing and predicting which bugs get reopened. In: Proceedings of the 2012 International Conference on Software Engineering. Piscataway, NJ, USA: IEEE Press, 2012. (ICSE 2012), p. 1074–1083. ISBN 978-1-4673-1067-3.
20. 20 Cada estudo, um tipo de rejeição Nenhum estudo analisa reversões
21. 21 Dados e Métodos
22. 22 rejeição
 da mudança retrabalho 㿂 defeitos na
 versão final mudança
 inadequada processo A processo B aprimorar
 a detecção quantificar e entender comparar
23. 23 Mozilla Core Firefox Thunderbird Bugzilla Mozilla-Central Comm-Central Dados
24. Junho
 2009 Março
 2011 Objetivo 4 24 Junho
 2011 Setembro
 2013 Releases
 Rápidas (19 versões) Objetivos 1–4 Releases
 Tradicionais (2 versões)
25. 25 Somente tíquetes: - fechados - com pelo menos um commit
26. 0.1 S/N Métodos
27. criação do tíquete solicitação da revisão commit fecham.
 tíquete revisão
 negativa reversão reabertura do tíquete submissão
 rejeição solicitação da revisão commit fecham.
 tíquete submissão
 suplementar original
28. commit fecham.
 tíquete reversão reversão
 precoce commit fecham.
 tíquete reversão reversão
 tardia
29. 29 Detecção de Eventos criação do tíquete solicitação da revisão fecham.
 tíquete reabertura do tíquete revisão
 negativa
30. 30 Detecção de Eventos changeset: 104004:0a93ae68184e user: Lucas Rocha <lucasr@mozilla.com> date: … summary: Bug 787078 - Backout 43dd8252f52d changeset: 103905:43dd8252f52d user: Lucas Rocha <lucasr@mozilla.com> date: … summary: Bug 787078 - Load Reader UI on pageshow… commit reversão
31. 31 Métricas: Contagem tíquetes associados a algum tipo de rejeição 0.1
32. criação do tíquete solicitação da revisão commit fecham.
 tíquete revisão
 negativa reversão reabertura do tíquete submissão
 original rejeição solicitação da revisão commit fecham.
 tíquete submissão
 suplementar Métricas: Tempo (latente)
33. 33 Resultados e Discussão
34. 34 Objetivo 1 1) Propor e comparar técnicas para detectar rejeição de mudanças
35. 35 commits suplementares reversões reaberturas Mozilla Core 97%
36. 36 commits suplementares reversões reaberturas Mozilla Core 36% Part 1: … Part 2: …
37. 37 commits suplementares tardios reversões
 tardias reaberturas 75%
38. 38 commits suplementares tardios reversões
 tardias reaberturas 25% Vamos abrir outro tíquete Você fechou na hora errada Ooops! não representam rejeição de mudança: 75%
39. 39 Reversões Thunderbird
40. 40 Objetivo 2 2) Quantificar o retrabalho desencadeado por mudanças inadequadas
41. 41 revisão negativa 11.7% reversão 8.4% reabertura 4.7% 20.9% 6.7% precoce 1.7% tardia rejeição Firefox
42. 42 Mozilla Core 5 rejeições por dia Firefox 1 rejeição por dia Thunderbird Uma rejeição a cada 5 dias
43. 43 Rejeição é um evento comum, cotidiano
44. 44 Mozilla Core Firefox Thunderbird +140% +74% +132% tíquete tíquete tíquete tíquete tíquete tíquete tíquete tíquete +26% +15% +25% tíquetes com rejeição vs. sem rejeição tempo de vida Pensar no que falar na segunda coluna.
45. 45 Objetivo 3 3) Validar hipóteses sobre rejeição de mudanças e retrabalho
46. 46 Mozilla Core Firefox Thunderbird +77% 17 dias 30 dias 28 dias +30% 37 dias 22 dias +68% 37 dias maior tempo para submissão hipótese:
47. 47 mudança difícil maior tempo para submissão ?
48. 48 defeitos na
 versão final mudança
 inadequada Mozilla Core Firefox Thunderbird < 2.5% < 1.6% < 7.4% > 12 semanas x%
49. 49 㿂 mudança
 inadequada +26% 7% - qualidade - produtividade
50. 50 Nosso processo de desenvolvimento dá uma margem de segurança muito grande para detectar regressões bem antes de o código de fato chegar nas mãos dos usuários. “ ”
51. 51 0.14–0.24 correlação (fraca) tempo
 latente submissão
 suplementar solicitação da revisão revisão
 negativa solicitação da revisão criação do tíquete 㿂
52. 52 Objetivo 4 4) Avaliar o impacto das mudanças no processo da Mozilla no retrabalho
53. 53 2011 Releases tradicionais Releases rápidas Xerifes Envia mudanças para o repositório central Envia mudanças para o repositório de integração
54. 54 Firefox revisões negativas reaberturas 19.2% 6.2% reversões 11.7% 10.0% 4.7% 8.4%
55. 55 Firefox 6.2% 8.4% reversões mais código, mais produtos testes automatizados melhores xerifes, repositórios de integração por quê?
56. 56 Se você quebra o repositório de vez em quando: “OK” Se você nunca quebra o repositório: “Você está rodando testes demais” Sobre os repositórios de integração
57. 57 Firefox reversões precoces 2.0% 4.6% reversões tardias 1.7% 6.7% repo. de integração
58. 58 O tempo gasto testando mudanças antes de submetê-las diminuiu, assim como o tempo desperdiçado com repositório [central] quebrado. “ ”
59. 59 Conclusão
60. 60 rejeição
 da mudança retrabalho 㿂 mudança
 inadequada comum defeitos na
 versão final incomum +25% Recapitulando commits suplementares reversões reabertura (imprecisos)
61. 61 reversões: mais frequentes mais cedo :) programadores gastam menos tempo com testes
62. 62 Trabalhos Futuros comparar o código de mudanças: adequadas vs inadequadas
63. 63 Trabalhos Futuros descobrir módulos mais frágeis para priorizar testes
64. 64 Trabalhos Futuros estudar o impacto de outras variáveis de processo e de design na rejeição de mudanças débito técnico 㱺 + rejeição? violações arquiteturais 㱺 + rejeição?
65. 65 Para Saber Mais http://rodrigorgs.github.io/publications/ artigos slides vídeos dados e scripts Co-located with