- O documento apresenta uma revisão sobre o impacto de práticas de desenvolvimento de software na ocorrência de defeitos.
- É descrito um projeto que investiga esta relação por meio de estudos em repositórios de software.
- Foram apresentados resultados parciais sobre a avaliação independente de correções de defeitos.
Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)
2011 seminario rodrigo 2011
1. Impacto de Práticas de
Desenvolvimento na Ocorrência
de Defeitos em Software
Rodrigo Rocha G. e Souza <rodrigorgs@gmail.com>
Orientadora:
Christina von Flach Garcia Chavez
Laboratório de Engenharia de Software (LES)
Universidade Federal da Bahia (UFBA)
Seminário. 14 de dezembro de 2011.
quarta-feira, 14 de dezembro de 11
2. Sumário
• Revisão
• Projeto
• Resultados Parciais
• Trabalhos Futuros
quarta-feira, 14 de dezembro de 11
3. Revisão
Práticas. Defeitos.
quarta-feira, 14 de dezembro de 11
5. Software Dev. Practices
“Practices are contained, repeatable, and
transferable techniques used to improve some
aspect of the performance of a software
organization that is pertinent to the creation
of its products.”
Jorge Aranda (2010) - A Theory of Shared Understanding for
Software Organizations [PhD Thesis], p. 123
quarta-feira, 14 de dezembro de 11
6. Exemplo: XP
• programação em pares • pequenas versões
• jogo do planejamento • convenções de
codificação
• desenvolvimento dirigido
por testes • posse coletiva de código
• time coeso (equipe inclui • design simples
equipe)
• metáfora
• refatoração
• ritmo sustentável
quarta-feira, 14 de dezembro de 11
7. Posse coletiva
• Collectivetoo many cooks? quality: enough
eyeballs or
ownership vs.
• Bird2010: high ownership and few minor contributors
less defects (mostly in commercial projects)
• Rahman2011: “implicated” code* more often associated
with a single developer’s contribution. Experience in the
modified files is more important than general
experience. (context: FOSS)
* Code that was changed in a bug fix.
• Maruping2008: collective ownership improves software
quality (in low expertise teams)
quarta-feira, 14 de dezembro de 11
8. Convenções de
Codificação
• Coding conventions vs. quality:
• Butler2010: low quality identifiers low quality code
(Findbugs)
• Maruping2008: coding conventions improve software
quality (survey with employees)
quarta-feira, 14 de dezembro de 11
10. Terminologia
• Defeito = bug
• Correção = fix
• Correção parcial
quarta-feira, 14 de dezembro de 11
11. Repositórios de Bugs
• Lista de bugs conhecidos de um sistema
• Reportados por usuários e desenvolvedores
• Desenvolvedores reportam o progresso da
correção de bugs, pedem mais informações,
comentam as correções enviadas... (dados do
processo)
quarta-feira, 14 de dezembro de 11
13. Projeto
O quê? Pra quê? Como? Desafios.
quarta-feira, 14 de dezembro de 11
14. O quê?
Investigar o impacto de determinadas boas
práticas de desenvolvimento de software
sobre a a ocorrência de defeitos no
software produzido.
ex.: revisão de código, convenções de
codificação, refactoring...
quarta-feira, 14 de dezembro de 11
15. Pra quê?
• Fornecer evidências que ajudem a priorizar a
adoção de práticas mais efetivas em
diferentes contextos.
• Enriquecer modelos de previsão de defeitos ao incorporar
dados do processo de desenvolvimento.
quarta-feira, 14 de dezembro de 11
16. Como?
• Identificação automática de práticas a partir
de repositórios de software.
• Estudos observacionais retrospectivos
usando dados de repositórios de software.
• Análise quantitativa (estatística, mineração
de dados/processos)
• Análise qualitativa, exploratória
(codificação de texto)
quarta-feira, 14 de dezembro de 11
17. Desafios
• Busca de projetos interessantes com dados
disponíveis
• Qualidade dos dados (commits, bug reports)
• Falta de controle sobre as variáveis
quarta-feira, 14 de dezembro de 11
19. Avaliação independente de
uma correção contribui para
evitar a reabertura do bug
correspondente?
quarta-feira, 14 de dezembro de 11
20. “It is important that the
verifier be a different
person than the fixer
because the fixer is too
close to the code and thus
may not be as diligent at
testing the corner cases.”
(princípio dos 4 olhos)
quarta-feira, 14 de dezembro de 11
21. Dados
• Repositório de bugs do Eclipse/Platform
(MySQL) — Outubro de 2001 a Junho de 2010
• Seleção: apenas bugs verificados até 2009.
quarta-feira, 14 de dezembro de 11
22. Classificação de Bugs
• ...
• RESOLVED (by fixer)
• VERIFIED (by verifier) verifier = fixer?
• ...
{
S → 2 olhos
N → 4 olhos
{
S → reaberto
• REOPEN? N → ok
quarta-feira, 14 de dezembro de 11
23. Hipótese
• Bugs verificados por outra pessoa (4 olhos)
estão menos sujeitos a serem reabertos
(depois da verificação).
• (A proporção de 2 olhos é maior nos bugs
reabertos do que nos bugs ok)
quarta-feira, 14 de dezembro de 11
24. Resultado
Eclipse Platform
60,00
45,00
30,00 2 olhos
4 olhos
15,00
0
Teste exato de Fisher: reaberto ok
p = 0.44 (não
significativo)
quarta-feira, 14 de dezembro de 11
25. Outros dados
• Foram analisados 34 subprojetos do Eclipse
e 39 subprojetos do Netbeans
• Não foram encontradas evidências de que
avaliação independente de uma correção (4
olhos) evita reabertura do bug
correspondente.
quarta-feira, 14 de dezembro de 11
26. Análise Qualitativa
• Uma análise qualitativa de 4 subprojetos (Eclipse/Platform,
Eclipse/EMF, Netbeans/versioncontrol, Netbeans/profiler) mostrou
que o status VERIFIED pode significar várias coisas.
• o usuário que reportou o problema executou uma
versão modificada do sistema e não enfrentou o erro
reportado.
• a solução está disponível em um build publicado no
site.
• o bug é muito antigo e foi “verificado” em massa junto
com outros bugs antigos.
quarta-feira, 14 de dezembro de 11
28. Trabalhos futuros
• Inspecionar de amostras de bugs
• Estimar acurácia das informações
• Entender por que correções são rejeitadas
(i.e., que tipo de verificação é realizada)
• Diferenciar entre pre- e post-release bugs
• Post-release bugs são mais graves, pois
aparecem para o usuário
quarta-feira, 14 de dezembro de 11
29. Trabalhos futuros
• Criar diagrama de causas para o princípio
dos 4 olhos e reabertura de bugs
• Ex.: será que o princípio dos 4 olhos só é
aplicado em bugs difíceis?
• outras variáveis: experiência do
desenvolvedor, rigor no processo,
produtividade...
quarta-feira, 14 de dezembro de 11
30. Trabalhos Futuros
• Estudar outras práticas. Ex.: refactoring.
quarta-feira, 14 de dezembro de 11
31. Algumas Referências
• Bird2010 - An Analysis of the Effect of Code Ownership on Software Quality across
Windows, Eclipse, and Firefox
• Rahman2011 - Ownership, Experience and Defects- A fine-grained study of
Authorship
• Maruping2008 - Role of collective ownership and coding standards in coordinating
expertise in software project teams-annotated
• Butler2010 - Exploring the Influence of Identifier Names on Code Quality_ an
empirical study
• Cook1998 - Discovering models of software processes from event-based data-
annotated
• Poncin2011 - Process mining software repositories
quarta-feira, 14 de dezembro de 11