2011 seminario rodrigo 2011
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

2011 seminario rodrigo 2011

on

  • 318 views

 

Statistics

Views

Total Views
318
Views on SlideShare
318
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

2011 seminario rodrigo 2011 Presentation Transcript

  • 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 Futurosquarta-feira, 14 de dezembro de 11
  • 3. Revisão Práticas. Defeitos.quarta-feira, 14 de dezembro de 11
  • 4. Práticasquarta-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. 123quarta-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ávelquarta-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. Defeitosquarta-feira, 14 de dezembro de 11
  • 10. Terminologia • Defeito = bug • Correção = fix • Correção parcialquarta-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_Usequarta-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áveisquarta-feira, 14 de dezembro de 11
  • 18. Resultados Parciaisquarta-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 → okquarta-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 Futurosquarta-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árioquarta-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 repositoriesquarta-feira, 14 de dezembro de 11