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

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

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