Impacto de Práticas de Desenvolvimento na Ocorrência
de Defeitos em Software
Rodrigo Rocha G. e Souza <[email protected]>
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
Sumário
• Revisão
• Projeto
• Resultados Parciais
• Trabalhos Futuros
quarta-feira, 14 de dezembro de 11
Revisão
Práticas. Defeitos.
quarta-feira, 14 de dezembro de 11
Práticas
quarta-feira, 14 de dezembro de 11
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
Exemplo: XP• programação em pares
• jogo do planejamento
• desenvolvimento dirigido por testes
• time coeso (equipe inclui equipe)
• refatoração
• pequenas versões
• convenções de codificação
• posse coletiva de código
• design simples
• metáfora
• ritmo sustentável
quarta-feira, 14 de dezembro de 11
Posse coletiva
• Collective ownership vs. quality: enough eyeballs or too many cooks?
• 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
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
Defeitos
quarta-feira, 14 de dezembro de 11
Terminologia
• Defeito = bug
• Correção = fix
• Correção parcial
quarta-feira, 14 de dezembro de 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
http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Usequarta-feira, 14 de dezembro de 11
Projeto
O quê? Pra quê? Como? Desafios.
quarta-feira, 14 de dezembro de 11
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
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
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
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
Resultados Parciais
quarta-feira, 14 de dezembro de 11
Avaliação independente de uma correção contribui para evitar a reabertura do bug
correspondente?
quarta-feira, 14 de dezembro de 11
“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
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
Classificação de Bugs
• ...
• RESOLVED (by fixer)
• VERIFIED (by verifier)
• ...
• REOPEN?
verifier = fixer? S → 2 olhosN → 4 olhos{
S → reabertoN → ok{
quarta-feira, 14 de dezembro de 11
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
Resultado
0
15,00
30,00
45,00
60,00
reaberto ok
Eclipse Platform
2 olhos4 olhos
Teste exato de Fisher:p = 0.44 (não significativo)
quarta-feira, 14 de dezembro de 11
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
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
Trabalhos Futuros
quarta-feira, 14 de dezembro de 11
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
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
Trabalhos Futuros
• Estudar outras práticas. Ex.: refactoring.
quarta-feira, 14 de dezembro de 11
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