- 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.

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

4. Práticas
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

9. Defeitos
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

12. http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use
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

18. Resultados Parciais
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

27. Trabalhos Futuros
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