Embed Size (px)
Citation preview
Eficácia de Práticas de Verificação na Evolução de Projetos de Software Livre
Rodrigo Rocha G. e Souza <[email protected]>
Orientadora:Christina von Flach Garcia Chavez
Laboratório de Engenharia de Software (LES)Universidade Federal da Bahia (UFBA)
23 de março de 2012 1
sexta-feira, 23 de março de 12
Sumário
• ...
2
sexta-feira, 23 de março de 12
Revisão
Práticas. Defeitos.
3
sexta-feira, 23 de março de 12
Práticas
4
sexta-feira, 23 de março de 12
Defeitos
5
sexta-feira, 23 de março de 12
Terminologia
• Defeito = bug
• Correção = fix
• Correção parcial
6
sexta-feira, 23 de março de 12
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)
7
sexta-feira, 23 de março de 12
http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use8
sexta-feira, 23 de março de 12
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
9
sexta-feira, 23 de março de 12
Projeto
O quê? Pra quê? Como? Desafios.
10
sexta-feira, 23 de março de 12
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.
ex.: verificação independente, formação de times de QA, estabelecimento de uma fase de verificação no ciclo de releases...
11
sexta-feira, 23 de março de 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)
12
sexta-feira, 23 de março de 12
Como?
• 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
13
sexta-feira, 23 de março de 12
Resultados Parciais
14
sexta-feira, 23 de março de 12
1. Verificação independente (quatro olhos) de uma correção
contribui para evitar a reabertura do bug
correspondente?
15
sexta-feira, 23 de março de 12
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)
16
sexta-feira, 23 de março de 12
0
15,00
30,00
45,00
60,00
reaberto ok
Eclipse Platform
2 olhos 4 olhos
Teste exato de Fisher:p = 0.44 (não significativo)
Resultado inconclusivo para o projeto Eclipse
17
sexta-feira, 23 de março de 12
• Explicação possível: os desenvolvedores sabem identificar quais bugs devem ser verificados por outro desenvolvedores.
18
sexta-feira, 23 de março de 12
2. Será que há ruído nos dados de bugs? Como
aproveitar os dados para minerar práticas de
verificação?
19
sexta-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?
sexta-feira, 23 de março de 12
verificações em massa
há ruídos nos dados?
21
sexta-feira, 23 de março de 12
fase de verificação
quando é feita a verificação?
22
sexta-feira, 23 de março de 12
quem faz a verificação?
23
sexta-feira, 23 de março de 12
como é feita a verificação?
24
sexta-feira, 23 de março de 12
3. Será que determinadas práticas de verificação são
mais eficazes do que outras?(em andamento)
25
sexta-feira, 23 de março de 12
• 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
26
sexta-feira, 23 de março de 12
4. Experimento na disciplina “Desenvolvimento de
Projetos FLOSS”(em andamento)
27
sexta-feira, 23 de março de 12
• 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).
28
sexta-feira, 23 de março de 12
• 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?
29
sexta-feira, 23 de março de 12
Trabalhos Futuros
30
sexta-feira, 23 de março de 12
• 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
31
sexta-feira, 23 de março de 12
sexta-feira, 23 de março de 12
