Your SlideShare is downloading. ×
2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina

101
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
101
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Eficácia de Práticas de Verificação na Evolução de Projetos de Software Livre 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)23 de março de 2012 1sexta-feira, 23 de março de 12
  • 2. Sumário • ... 2sexta-feira, 23 de março de 12
  • 3. Revisão Práticas. Defeitos. 3sexta-feira, 23 de março de 12
  • 4. Práticas 4sexta-feira, 23 de março de 12
  • 5. Defeitos 5sexta-feira, 23 de março de 12
  • 6. Terminologia • Defeito = bug • Correção = fix • Correção parcial 6sexta-feira, 23 de março de 12
  • 7. 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) 7sexta-feira, 23 de março de 12
  • 8. http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use 8sexta-feira, 23 de março de 12
  • 9. Reabertura de Bugs • Depois de considerado corrigido, percebe-se que o bug ainda se manifesta. • Problemas • Bugs reabertos demoram 2x mais para serem corrigidos • Bugs incorretamente considerados como corrigidos vão se manifestar nas releases 9sexta-feira, 23 de março de 12
  • 10. Projeto O quê? Pra quê? Como? Desafios. 10sexta-feira, 23 de março de 12
  • 11. O quê? Avaliar a eficácia de determinadas práticas de verificação aplicadas no contexto de correção de defeitos em projetos de software livre. Outra metrica é qto tempo ate o fix definitivo, e como isso varia de acordo com a pratica usada. ex.: verificação independente, formação de times de QA, estabelecimento de uma fase de verificação no ciclo de releases... 11sexta-feira, 23 de março de 12
  • 12. Pra quê? • Fornecer evidências que ajudem a priorizar a adoção de práticas mais efetivas • Enriquecer modelos de previsão de defeitos ao incorporar dados do processo de desenvolvimento. • Facilitar a avaliação de qualidade de processos empregados em projetos de software livre. (ver QualiPSo) 12sexta-feira, 23 de março de 12
  • 13. Como? Abram Hindle. Software process recovery. Ana Carla de Medeiros. Eindhoven. • 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) • Experimento controlado com alunos no contexto de um curso acadêmico Estudo piloto com Christina, Terceiro etc. 13sexta-feira, 23 de março de 12
  • 14. Resultados Parciais 14sexta-feira, 23 de março de 12
  • 15. 1.Verificação independente (quatro olhos) de uma correção contribui para evitar a reabertura do bug correspondente? 15sexta-feira, 23 de março de 12
  • 16. 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) 16sexta-feira, 23 de março de 12
  • 17. Resultado inconclusivo para o projeto Eclipse Eclipse Platform 60,00 2 olhos 4 olhos 45,00 30,00 Teste exato de Fisher: p = 0.44 (não 15,00 significativo) 0 reaberto ok 17sexta-feira, 23 de março de 12
  • 18. • Explicação possível: os desenvolvedores sabem identificar quais bugs devem ser verificados por outro desenvolvedores. 18sexta-feira, 23 de março de 12
  • 19. 2. Será que há ruído nos dados de bugs? Como aproveitar os dados para minerar práticas de verificação? 19sexta-feira, 23 de março de 12
  • 20. há ruídos nos dados? quando é feita a verificação? quem faz a verificação? como é feita a verificação? 20sexta-feira, 23 de março de 12
  • 21. há ruídos nos dados? verificações em massa 21sexta-feira, 23 de março de 12
  • 22. quando é feita a verificação? fase de verificação 22sexta-feira, 23 de março de 12
  • 23. quem faz a verificação? 23sexta-feira, 23 de março de 12
  • 24. como é feita a verificação? 24sexta-feira, 23 de março de 12
  • 25. 3. Será que determinadas práticas de verificação são mais eficazes do que outras? (em andamento) 25sexta-feira, 23 de março de 12
  • 26. • A chance de o bug ser reaberto após a verificação é menor quando... • ... a verificação é feita pelo time de QA? inconclusivo • ... a verificação é feita durante a fase de verificação? sim (em 2/4 dos projetos) • ... uma determinada técnica de verificação é empregada (testes, inspeção etc.)? sim, no caso de inspeção de código 26sexta-feira, 23 de março de 12
  • 27. 4. Experimento na disciplina “Desenvolvimento de Projetos FLOSS” (em andamento) 27sexta-feira, 23 de março de 12
  • 28. • Em fase de planejamento • Alunos em equipes de 3 ou 4 contribuirão com patches para projetos de software livre a sua escolha. • Em algumas equipes, cada patch será revisado por outro membro da equipe antes de submeter ao projeto (verificação interna). 28sexta-feira, 23 de março de 12
  • 29. • Coisas pra olhar: • que critérios um verificador interno tende a negligenciar quando comparado a um verificador do projeto? • a verificação interna ajuda a acelerar a inclusão do patch no projeto? 29sexta-feira, 23 de março de 12
  • 30. Trabalhos Futuros 30sexta-feira, 23 de março de 12
  • 31. • Investigar outras práticas de verificação • Construir diagrama causal de reabertura de bugs e usá-lo para realizar análises mais rigorosas. • Analisar outros projetos (tenho dados de +3) • Talvez incorporar à análise dados de repositórios de código Diego trabalhando com bug reports na Google. 31sexta-feira, 23 de março de 12
  • 32. sexta-feira, 23 de março de 12

×