- O documento discute a eficácia de práticas de verificação na evolução de projetos de software livre, como verificação independente e formação de times de qualidade. - Fornece resultados preliminares de um estudo sobre como a verificação independente afeta a taxa de reabertura de bugs no projeto Eclipse. - Aponta desafios como ruído nos dados de verificação e planeja experimentos controlados com alunos para avaliar práticas de verificação.

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 1
sexta-feira, 23 de março de 12

2. Sumário
• ...
2
sexta-feira, 23 de março de 12

3. Revisão
Práticas. Defeitos.
3
sexta-feira, 23 de março de 12

4. Práticas
4
sexta-feira, 23 de março de 12

5. Defeitos
5
sexta-feira, 23 de março de 12

6. Terminologia
• Defeito = bug
• Correção = fix
• Correção parcial
6
sexta-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)
7
sexta-feira, 23 de março de 12

8. http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use
8
sexta-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
9
sexta-feira, 23 de março de 12

10. Projeto
O quê? Pra quê? Como? Desafios.
10
sexta-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...
11
sexta-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)
12
sexta-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.
13
sexta-feira, 23 de março de 12

14. Resultados Parciais
14
sexta-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?
15
sexta-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)
16
sexta-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
17
sexta-feira, 23 de março de 12

18. • 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

19. 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?
20
sexta-feira, 23 de março de 12

21. há ruídos nos dados?
verificações em massa
21
sexta-feira, 23 de março de 12

22. quando é feita a verificação?
fase de verificação
22
sexta-feira, 23 de março de 12

23. quem faz a verificação?
23
sexta-feira, 23 de março de 12

24. como é feita a verificação?
24
sexta-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)
25
sexta-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
26
sexta-feira, 23 de março de 12

27. 4. Experimento na disciplina
“Desenvolvimento de
Projetos FLOSS”
(em andamento)
27
sexta-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).
28
sexta-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?
29
sexta-feira, 23 de março de 12

30. Trabalhos Futuros
30
sexta-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.
31
sexta-feira, 23 de março de 12

32. sexta-feira, 23 de março de 12