2011 seminario rodrigo 2011

Download 2011 seminario rodrigo 2011

Post on 24-May-2015

122 views

Category:

Documents

7 download

Embed Size (px)

TRANSCRIPT

<ul><li> 1. Impacto de Prticas de Desenvolvimento na Ocorrnciade Defeitos em Software Rodrigo Rocha G. e Souza Orientadora: Christina von Flach Garcia Chavez Laboratrio de Engenharia de Software (LES) Universidade Federal da Bahia (UFBA)Seminrio. 14 de dezembro de 2011.quarta-feira, 14 de dezembro de 11</li></ul> <p> 2. Sumrio Reviso Projeto Resultados Parciais Trabalhos Futurosquarta-feira, 14 de dezembro de 11 3. Reviso Prticas. Defeitos.quarta-feira, 14 de dezembro de 11 4. Prticasquarta-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 programao em pares pequenas verses jogo do planejamento convenes decodicao desenvolvimento dirigidopor testes posse coletiva de cdigo time coeso (equipe inclui design simplesequipe) metfora refatorao ritmo sustentvelquarta-feira, 14 de dezembro de 11 7. Posse coletiva Collectivetoo many cooks? quality: enougheyeballs orownership vs. Bird2010: high ownership and few minor contributors less defects (mostly in commercial projects) Rahman2011: implicated code* more often associated with a single developers contribution. Experience in the modied les is more important than general experience. (context: FOSS) * Code that was changed in a bug x. Maruping2008: collective ownership improves software quality (in low expertise teams)quarta-feira, 14 de dezembro de 11 8. Convenes deCodicao Coding conventions vs. quality: Butler2010: low quality identiers 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 Correo = x Correo parcialquarta-feira, 14 de dezembro de 11 11. Repositrios de Bugs Lista de bugs conhecidos de um sistema Reportados por usurios e desenvolvedores Desenvolvedores reportam o progresso dacorreo de bugs, pedem mais informaes,comentam as correes enviadas... (dados doprocesso)quarta-feira, 14 de dezembro de 11 12. http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Usequarta-feira, 14 de dezembro de 11 13. ProjetoO qu? Pra qu? Como? Desaos.quarta-feira, 14 de dezembro de 11 14. O qu? Investigar o impacto de determinadas boas prticas de desenvolvimento de software sobre a a ocorrncia de defeitos no software produzido. ex.: reviso de cdigo, convenes de codicao, refactoring...quarta-feira, 14 de dezembro de 11 15. Pra qu? Fornecer evidncias que ajudem a priorizar aadoo de prticas mais efetivas emdiferentes contextos. Enriquecer modelos de previso de defeitos ao incorporardados do processo de desenvolvimento.quarta-feira, 14 de dezembro de 11 16. Como? Identicao automtica de prticas a partirde repositrios de software. Estudos observacionais retrospectivosusando dados de repositrios de software. Anlise quantitativa (estatstica, minerao de dados/processos) Anlise qualitativa, exploratria (codicao de texto)quarta-feira, 14 de dezembro de 11 17. Desaos Busca de projetos interessantes com dadosdisponveis Qualidade dos dados (commits, bug reports) Falta de controle sobre as variveisquarta-feira, 14 de dezembro de 11 18. Resultados Parciaisquarta-feira, 14 de dezembro de 11 19. Avaliao independente de uma correo contribui paraevitar 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. (princpio dos 4 olhos)quarta-feira, 14 de dezembro de 11 21. Dados Repositrio de bugs do Eclipse/Platform(MySQL) Outubro de 2001 a Junho de 2010 Seleo: apenas bugs vericados at 2009.quarta-feira, 14 de dezembro de 11 22. Classicao de Bugs ... RESOLVED (by xer) VERIFIED (by verier) verier = xer? ...{S 2 olhosN 4 olhos {S reaberto REOPEN? N okquarta-feira, 14 de dezembro de 11 23. Hiptese Bugs vericados por outra pessoa (4 olhos)esto menos sujeitos a serem reabertos(depois da vericao). (A proporo de 2 olhos maior nos bugs reabertos do que nos bugs ok)quarta-feira, 14 de dezembro de 11 24. ResultadoEclipse Platform 60,00 45,00 30,002 olhos4 olhos 15,000 Teste exato de Fisher:reabertook p = 0.44 (nosignicativo)quarta-feira, 14 de dezembro de 11 25. Outros dados Foram analisados 34 subprojetos do Eclipsee 39 subprojetos do Netbeans No foram encontradas evidncias de queavaliao independente de uma correo (4olhos) evita reabertura do bugcorrespondente.quarta-feira, 14 de dezembro de 11 26. Anlise Qualitativa Uma anlise qualitativa de 4 subprojetos (Eclipse/Platform,Eclipse/EMF, Netbeans/versioncontrol, Netbeans/proler) mostrouque o status VERIFIED pode signicar vrias coisas. o usurio que reportou o problema executou uma verso modicada do sistema e no enfrentou o erro reportado. a soluo est disponvel em um build publicado no site. o bug muito antigo e foi vericado 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 acurcia das informaes Entender por que correes so rejeitadas (i.e., que tipo de vericao realizada) Diferenciar entre pre- e post-release bugs Post-release bugs so mais graves, pois aparecem para o usurioquarta-feira, 14 de dezembro de 11 29. Trabalhos futuros Criar diagrama de causas para o princpiodos 4 olhos e reabertura de bugs Ex.: ser que o princpio dos 4 olhos s aplicado em bugs difceis? outras variveis: experincia do desenvolvedor, rigor no processo, produtividade...quarta-feira, 14 de dezembro de 11 30. Trabalhos Futuros Estudar outras prticas. Ex.: refactoring.quarta-feira, 14 de dezembro de 11 31. Algumas Referncias Bird2010 - An Analysis of the Effect of Code Ownership on Software Quality acrossWindows, Eclipse, and Firefox Rahman2011 - Ownership, Experience and Defects- A ne-grained study ofAuthorship Maruping2008 - Role of collective ownership and coding standards in coordinatingexpertise in software project teams-annotated Butler2010 - Exploring the Inuence of Identier Names on Code Quality_ anempirical study Cook1998 - Discovering models of software processes from event-based data-annotated Poncin2011 - Process mining software repositoriesquarta-feira, 14 de dezembro de 11</p>