2011 seminario rodrigo 2011

288 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
288
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

2011 seminario rodrigo 2011

  1. 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. 2. Sumário • Revisão • Projeto • Resultados Parciais • Trabalhos Futurosquarta-feira, 14 de dezembro de 11
  3. 3. Revisão Práticas. Defeitos.quarta-feira, 14 de dezembro de 11
  4. 4. Práticasquarta-feira, 14 de dezembro de 11
  5. 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. 123quarta-feira, 14 de dezembro de 11
  6. 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ávelquarta-feira, 14 de dezembro de 11
  7. 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. 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. 9. Defeitosquarta-feira, 14 de dezembro de 11
  10. 10. Terminologia • Defeito = bug • Correção = fix • Correção parcialquarta-feira, 14 de dezembro de 11
  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. 12. http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Usequarta-feira, 14 de dezembro de 11
  13. 13. Projeto O quê? Pra quê? Como? Desafios.quarta-feira, 14 de dezembro de 11
  14. 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. 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. 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. 17. Desafios • Busca de projetos interessantes com dados disponíveis • Qualidade dos dados (commits, bug reports) • Falta de controle sobre as variáveisquarta-feira, 14 de dezembro de 11
  18. 18. Resultados Parciaisquarta-feira, 14 de dezembro de 11
  19. 19. Avaliação independente de uma correção contribui para evitar a reabertura do bug correspondente?quarta-feira, 14 de dezembro de 11
  20. 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. 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. 22. Classificação de Bugs • ... • RESOLVED (by fixer) • VERIFIED (by verifier) verifier = fixer? • ... { S → 2 olhos N → 4 olhos { S → reaberto • REOPEN? N → okquarta-feira, 14 de dezembro de 11
  23. 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. 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. 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. 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. 27. Trabalhos Futurosquarta-feira, 14 de dezembro de 11
  28. 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árioquarta-feira, 14 de dezembro de 11
  29. 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. 30. Trabalhos Futuros • Estudar outras práticas. Ex.: refactoring.quarta-feira, 14 de dezembro de 11
  31. 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 repositoriesquarta-feira, 14 de dezembro de 11

×