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.

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

281 views

Published on

  • Você gostaria de conhecer uma Oportunidade de Negócio na internet onde você TERÁ seu PRÓPRIO NEGÓCIO ONLINE (Website, Produtos e Área de Gerenciamento) que possibilitará a você faturar sempre 100% de Lucro por cada venda realizada e o melhor, pagamentos direto em sua conta? http://www.paginalucrativa.com.br/?id=4346
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Você gostaria de conhecer uma Oportunidade de Negócio na internet onde você TERÁ seu PRÓPRIO NEGÓCIO ONLINE (Website, Produtos e Área de Gerenciamento) que possibilitará a você faturar sempre 100% de Lucro por cada venda realizada e o melhor, pagamentos direto em sua conta? http://www.paginalucrativa.com.br/?id=4346
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

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

  1. 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. 2. Sumário • ... 2sexta-feira, 23 de março de 12
  3. 3. Revisão Práticas. Defeitos. 3sexta-feira, 23 de março de 12
  4. 4. Práticas 4sexta-feira, 23 de março de 12
  5. 5. Defeitos 5sexta-feira, 23 de março de 12
  6. 6. Terminologia • Defeito = bug • Correção = fix • Correção parcial 6sexta-feira, 23 de março de 12
  7. 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. 8. http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use 8sexta-feira, 23 de março de 12
  9. 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. 10. Projeto O quê? Pra quê? Como? Desafios. 10sexta-feira, 23 de março de 12
  11. 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. 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. 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. 14. Resultados Parciais 14sexta-feira, 23 de março de 12
  15. 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. 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. 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. 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. 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. 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. 21. há ruídos nos dados? verificações em massa 21sexta-feira, 23 de março de 12
  22. 22. quando é feita a verificação? fase de verificação 22sexta-feira, 23 de março de 12
  23. 23. quem faz a verificação? 23sexta-feira, 23 de março de 12
  24. 24. como é feita a verificação? 24sexta-feira, 23 de março de 12
  25. 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. 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. 27. 4. Experimento na disciplina “Desenvolvimento de Projetos FLOSS” (em andamento) 27sexta-feira, 23 de março de 12
  28. 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. 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. 30. Trabalhos Futuros 30sexta-feira, 23 de março de 12
  31. 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. 32. sexta-feira, 23 de março de 12

×