Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2011 seminario rodrigo 2011

338 views

Published on

  • Be the first to comment

  • Be the first to like this

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

×