O documento discute inspeções em projetos de software, apresentando: 1) a motivação para inspeções devido aos altos custos de qualidade na indústria; 2) os tipos de revisões e o processo de inspeção; 3) estudos de caso que mostraram reduções significativas de defeitos e custos com inspeções; 4) uma reflexão sobre se a organização ultrapassou o ponto de inflexão entre custos de desenvolvimento e qualidade.
4. Situação atual da indústria
CHAOS Report (Standish Group)
The rise and fall of the Chaos report figures - J.L. Eveleens and C. Verhoef
4
5. Situação atual da indústria
Panorama atual da indústria [Yang et al., 2008]:
– 59% a 76% dos projetos apresentam esforço superior
ao estimado, sendo o erro de 18% a 41%.
– 35% a 80% apresentam estouro do prazo, sendo o
estouro de 22% a 25%.
5
7. Custo de remoção de defeitos
Baziuk Boehm
Fase
(1995) (1976)
Requisitos 1X 0,2Y
Desenho 0,5Y
Codificação 1,2Y
Testes de Unidade
Testes de integração
Testes de sistema 90X 5Y
Testes de instalação 90X-440X 15Y
Testes de aceitação 440X
Operação 440-880X (2900X)
8. Prévia do Momento de reflexão
Nosso processo de desenvolvimento é caro?
Ultrapassamos o ponto de inflexão?
Ctotal = Cdesenvolvimento + Cqualidade
Cqualidade = Cprevenção + Capreciações + Cfalha_interna +
Cfalha_externa
8
10. Revisões versus Testes
Revisões são muito mais eficazes que testes:
– Encontram o defeito mais cedo
• Mais barato
– Identificam diretamente o defeito
• Testes identificam apenas o sintoma. Depois é necessário
descobrir a causa.
10
11. IEEE Std 1028-1997, IEEE Standard for Software Reviews
Revisão:
– Processo ou reunião na qual um artefato é
apresentado para a equipe, usuários clientes e/ou
gerentes para ser aprovado ou comentado.
Tipos de revisão
– Revisões Gerenciais
– Revisões Técnicas
– Inspeções
– Revisões de apresentação
– Auditorias
11
12. Classificação proposta por Wiegers [Wiegers, 2002]
Peer
Revisão de Deskcheck,
Inspeção apresentação Passaround
Revisão Progra- Ad hoc
técnica mação
em pares
Mais formal Menos formal
12
13. Atividades em cada tipo de revisão [Wiegers, 2002]
Tipo de revisão Planejamento Preparação Reunião Correção Verificação
Inspeção x x x x x
Revisão técnica x x x x Opc.
Revisão de apresentação x x x
Programação em pares x Contínuo x x
Peer Deskcheck,
x Opc. x
Passaround
Ad Hoc x x
13
14. Tipos de revisão x Recomendações de uso [Wiegers, 2002]
Revisão Revisão de Programação Peer
Objetivo Inspeção Passaround
técnica apresentação em pares Deskcheck
Encontrar defeitos x x x x x x
Verificar conformidade com
x x x x
especificações
Verificar conformidade com
x x x
padrões
Verificar completeza e correção
x x
do artefato
Avaliar compreensão e
x x x x
manutenibilidade
Coletar dados para melhoria de
x x
processos
Medir qualidade do artefato x
Educar a equipe sobre o produto x x x x
Alcançar consenso sobre uma
x x x
abordagem
Garantir a correção dos defeitos x x x
Explorar abordagens alternativas x
14
15. Outra opinião [Gilb & Graham, 1993]
Usar
– Revisões de apresentação
• Treinar
– Revisões técnicas
• Chegar a um consenso
– Inspeções
• Aumentar a qualidade do artefato e do processo
Inspecionar antes ou depois dos outros procedimentos?
– Depende da maturidade do artefato
– Não adianta encontrar defeitos sobre algo que não
tem consenso
– E não adianta tentar alcançar consenso sobre algo
de baixa qualidade
15
17. Os papéis da inspeção e suas responsabilidades
Líder da inspeção
– Planejamento e preparação
– Assegurar que o processo seja seguido
Relator
– Registrar defeitos, ações e decisões
– Coletar dados da qualidade
– Pode ser exercido pelo Líder
Leitor
– Apresenta o artefato sendo revisado, uma parte de cada vez,
ressaltando os pontos importantes.
– Não deve ser o autor
17
18. Os papéis da inspeção e suas responsabilidades
Autor
– Corrigir os defeitos
– Tirar eventuais dúvidas durante as reuniões
Inspetor(es)
– Identificar e descrever os defeitos e inconformidades do artefato
18
19. As etapas da inspeção
1. Planejamento
– O autor comunica a conclusão de um artefato
– O gerente designa um líder, que escolhe os inspetores e
estima o número de encontros necessários e agenda as
reuniões
– O moderador fornece o material para revisão: artefato, listas de
conferência, objetivos e material de suporte
2. Reunião de visão geral (opcional)
– Apresentação informal do artefato, pelo autor, sem entrar em
detalhes
3. Preparação
– Os inspetores avaliam o material e coletam uma lista de
problemas, defeitos, sugestões
– Utilização de listas de conferência e tabelas de classificação
dos defeitos
19
20. As etapas da inspeção
4. Reuniões de inspeção
– O leitor apresenta o material para os inspetores, em pequenas
partes de cada vez.
– Após a apresentação de cada parte, os inspetores apontam os
problemas, defeitos, inconformidades e sugestões, que são
registrados pelo Relator
– Ao final das reuniões, o grupo deve dar um laudo para a
inspeção
– O líder deve produzir um relatório sumarizando os dados
quantitativos
5. Retrabalho
– Correção dos defeitos
– Resolução dos problemas
20
21. As etapas da inspeção
6. Conferência
– O Líder assegura a verificação da correção dos defeitos e
correto endereçamento dos problemas.
7. Análise causal
– Os dados quantitativos são analisados para prevenção de
defeitos:
• Análise de Paretto
• Análise de Causa e efeito (Diagrama de Ishikawa)
21
22. Revisões técnicas x Inspeções
Principais diferenças entre Revisão técnica e Inspeção:
– O Papel do Leitor
– A etapa de prevenção de defeitos
– Granularidade da apresentação
22
24. O trabalho de Fagan [Fagan, 1976] na IBM
Desenvolvimento do processo de inspeção para
especificações de teste, desenho detalhado e código
fonte
Aumento de produtividade:
– I1 = 12%, I1 + I2 = 123%
– I3 se mostrou mais caro que a economia do
retrabalho
24
25. O trabalho de Fagan na IBM
Comparado com a metodologia anterior, onde no lugar
das inspeções eram usadas revisões de apresentação:
– Redução de 38% nos defeitos de desenho e código
25
26. O estudo de Boehm na indústria da Tailândia
Comparou-se Inspeções formais (IF) a Programação em
pares (PP), tanto com alunos de graduação quanto na
indústria Tailandesa.
– Na graduação:
• PP teve Tempo total de desenvolvimento 24% menor, com
qualidade equivalente
– Na indústria (projetos mais complexos)
• PP teve Tempo total de desenvolvimento 4% maior, mas
teve 39% a menos de defeitos graves
26
27. Comparação entre formas de organizar a inspeção
Porter e outros [Porter et.al., 1997] fizeram
experimentos durante 18 meses com inspeções e
concluíram:
– Tamanho da equipe:
• Não há diferença entre 2 ou 4 inspetores
• 2 ou 4 inspetores são mais eficazes que 1
– 2 sessões de inspeção não são mais eficazes que 1
só. Não vale o overhead
– Reparar defeitos entre as sessões não traz efeito
sobre na densidade de defeitos, mas aumenta muito
o tempo total de inspeção
– A preparação individual levantou apenas 13% de
defeitos funcionais, indicando que os inspetores
estavam focando em aspectos pouco importantes
27
28. Outros relatos apresentados em [Wiegers, 2002]
HP mediu o ROI em 1000% do seu programa de
inspeção.
AT&T reduziu o custo de encontrar defeitos, usando
inspeções, por um fator de 10. Também houve um
aumento de 4x na qualidade do produto e 14% de
aumento de produtividade.
IBM relatou que cada hora investida em inspeções
economizou 20 horas de testes e 82 horas de
retrabalho.
Na Imperial Chemical Industries, o custo de manter 400
produtos que foram inspecionados é 10% do custo de
manter outro portfólio de 400 produtos que não
passaram por inspeção.
28
29. E claro: um modelo de maturidade! [Kollanus, 2009]
29
30. Qual é a melhor técnica?
Parece não haver resposta definitiva.
Um método de revisão pode ser mais apropriado que
outro em uma determinada situação, mas não
necessariamente em todas.
Cada organização deve medir o benefício de cada
método, através de experimentos
30
32. Momento de reflexão
Nosso processo de desenvolvimento é caro?
Ultrapassamos o ponto de inflexão?
Ctotal = Cdesenvolvimento + Cqualidade
Cqualidade = Cprevenção + Capreciações + Cfalha_interna +
Cfalha_externa
32
33. O custo da qualidade no Synergia
Levantamento “preliminar”
Dados incluem especificação e desenvolvimento de um
grande projeto, mas o escopo da especificação é maior.
Tipo de investimento Detalhes % do Projeto
Especificação e execução de testes 8,30%
Apreciações Revisões 6,30%
Revisões de requisitos com usuários 6,80%
Custo defeito interno Retrabalho Interno 13,90%
Investimento em usabilidade 6,50%
Prevenção
Treinamentos 6,90%
Tipo Total % 48,70%
Correção e verificação de defeitos
39,3%
código-fonte
Correção e verificação de defeitos
50,9%
encontrados nas revisões
Outros retrabalhos 9,8%
33
34. A Qualidade do produto entregue
Distribuição do esforço de um grande projeto,
atualmente em manutenção
Densidade de defeitos encontrados em produção:
– Aproximadamente: 0,05 defeitos/PF (0,02 defeitos graves/PF)
• Índice de empresas CMMI nível 5, segundo a SPR.
34
35. Algumas questões para refletir
O custo da qualidade está alto?
Estamos fazendo os tipos certos de apreciações em
cada artefato?
Os defeitos encontrados nas revisões são os que
deveríamos procurar?
O esforço das revisões deveria ser menor que o
investimento em testes?
O esforço de correção e verificação de defeitos deveria
ser aproximadamente igual ao de correção e verificação
das revisões?
O tipo de teste de unidade é o adequado?
Todo cliente demanda a qualidade que estamos
oferecendo?
35
38. Algumas Referências
[Fagan, 1976] – Design and code inspections to reduce errors in
program development - Michael E. Fagan - IBM Systems Journal,
15(3), 182–211
[Gilb & Graham, 1993] – Software Inspection – Tom Gilb, Dorothy
Graham – Addison-Wesley – 1993
[Kollanus, 2009] - Experiences from using ICMM in inspection
process assessment - Sami Kollanus - Software Qual J (2009)
[Phongpaibul & Boehm, 2006] - An Empirical Comparison Between
Pair Development and Software Inspection in Thailand - Monvorath
Phongpaibul, Barry Boehm - ISESE'06
[Porter et.al., 1997] - An Experiment to Assess the Cost-Benefits of
Code Inspections in Large Scale Software Development - Adam A.
Porter, Carol A. Toman, and Lawrence G. Votta - IEEE Transactions
On Software Engineering, Vol. 23, no. 6, June 1997
[Wiegers, 2002] – Peer Reviews in Software, A Practical Guide –
Karl E. Wiegers – Addison-Wesley Information Technology Series –
2002 38