1. CAR - Causal Analysis and Resolution
(Análise de causas e resolução de defeitos)
Disciplina: Qualidade de Software
Aluno: Jander Cerqueira
Professor: Alexandre Lenz
3. INTRODUÇÃO
• Processo de apoio de nível 5 de maturidade;
• O objetivo da análise causal é identificar causas de defeitos
e problemas, e adotar práticas para prevenir a sua
ocorrência no futuro;
• Esta análise permite o estabelecimento de tendências na
produção de defeitos e problemas que são examinados
desde suas raízes;
• A técnica de análise e resolução de causas pode ser
aplicada para a melhoria de áreas não necessariamente
problemáticas.
7. SG 1- DETERMINAR CAUSAS DE DEFEITOS
• SP 1.1 - Selecionar defeitos e dados associados
• Sub prática 1 – Recolher dados relevantes sobre defeitos ou
problemas associados;
• Exemplos de defeitos:
• Defeitos descritos pelos usuários;
• Defeitos encontrados em revisões ad-hoc;
• Defeitos encontrados em testes;
• Exemplos de problemas associados:
• Problemas de gerenciamento de projeto requerendo ações corretivas ;
• Problemas na capacidade do processo;
• Problemas de duração do processo;
8. SG 1- DETERMINAR CAUSAS DE DEFEITOS
• SP 1.1 - Selecionar defeitos e dados associados
• Sub prática 2 – Definir quais defeitos e problemas vão ser
analisados;
Considerar o impacto dos defeitos, sua frequência de
ocorrência, a similaridade entre defeitos, o custo de sua
análise, o tempo e os recursos necessários, aspectos de
segurança, etc.
Exemplos de técnicas:
• Análise de Paretto;
• Histogramas;
• Análise da capacidade do processo;
9. SG 1- DETERMINAR CAUSAS DE DEFEITOS
• SP 1.2 - Analisar causas
O objetivo desta análise é de desenvolver soluções para
os problemas identificados e produzir propostas de ações para
a sua implementação.
• Quando realizar esta análise:
• Quando um processo estável não responde aos requisitos de qualidade
e desempenho;
• Quando um produto de trabalho exibe um desvio inesperado em
relação a seus requisitos;
10. SG 1- DETERMINAR CAUSAS DE DEFEITOS
• SP 1.2 - Analisar causas
• Sub prática 1 – Analisar causas com os responsáveis pela
execução dos processos.
Isto ocorre em encontros com quem conhece o defeito
ou o problema em estudo;
• Sub prática 2 – Analisar cada defeito selecionado para
determinar sua causa-raiz.
Técnicas:
• Diagrama de Causa e Efeito (espinha de peixe)
• Listas de verificação
11. SG 1- DETERMINAR CAUSAS DE DEFEITOS
• SP 1.2 - Analisar causas
• Sub prática 3 – Agrupar os defeitos e outros problemas
selecionados baseados em suas causas-raiz.
• Exemplos:
• Treinamento inadequado;
• Problemas de comunicação;
• Falta de consideração com os detalhes das tarefas;
• Enganos em procedimentos;
• Deficiência do processo;
12. SG 1- DETERMINAR CAUSAS DE DEFEITOS
• SP 1.2 - Analisar causas
• Sub prática 4 – Propor e documentar ações que devem ser realizadas
para prevenir novas ocorrências de defeitos ou problemas similares.
• Exemplos de ações:
• Questionar o processo;
• Fornecer treinamento;
• Automatizar parte do processo com ferramentas;
• Reorganizar os métodos
• Melhorar os canais de comunicação;
• Adicionar atividades de prevenção de erros e problemas;
• Documentos de uma proposta de ação:
• Origem da proposta;
• Descrição do defeito ou problema;
• Descrição da causa do defeito ou problema
• Categoria do defeito ou problema
• Fase na qual o problema foi introduzido
• Fase na qual o problema foi identificado;
• Descrição das ações propostas;
13. SG 2 – ATACAR AS CAUSAS DOS DEFEITOS
• SP 2.1 Implementar propostas de ações
• Sub prática 1 – Analisar as ações propostas e definir as
prioridades.
• Critérios:
• Impacto esperado na qualidade;
• Custos de implementação do plano de ações preventivas;
• Consequência da não resolução do defeito ou problema;
• Sub prática 2 – Selecionar as propostas de ações que serão
implementadas;
14. SG 2 – ATACAR AS CAUSAS DOS DEFEITOS
• SP 2.1 Implementar propostas de ações
• Sub prática 3 – Detalhar as atividades que implementem as
ações propostas;
Detalhamento:
• Pessoa responsável pela implementação;
• Descrição das áreas afetadas;
• Pessoas que deve ser informadas;
• Justificativa para as decisões-chave;
• Descrição da implementação das ações;
• Tempo e custo para identificar e corrigir o defeito;
• Custo estimado da não correção do defeito;
15. SG 2 – ATACAR AS CAUSAS DOS DEFEITOS
• SP 2.1 Implementar propostas de ações
• Sub prática 4 – Identificar e remover defeitos similares que
possam existir em outros processos e produtos de trabalho;
• Sub prática 5 – Identificar e documentar propostas de
melhoria para o conjunto de processos da organização;
16. SG 2 – ATACAR AS CAUSAS DOS DEFEITOS
• SP 2.2 - Avaliar o efeito das mudanças
• O efeito das alterações deve ser alvo de verificação e de
coleta de evidências que mostrem que as alterações do
processo corrigiram o problema e melhoraram o seu
desempenho;
• Sub prática 1 - Medir a alteração no desempenho do
processo definido para o projeto.
Verificar se a alteração teve impacto positivo e medir o
nível deste impacto.
17. SG 2 – ATACAR AS CAUSAS DOS DEFEITOS
• SP 2.2 - Avaliar o efeito das mudanças
• Sub prática 2 - Medir a capacidade do processo definida para
o projeto.
• Verificar se a alteração influenciou a capacidade do processo
em responder aos requisitos de qualidade e de desempenho.
• Ex. Verificar se o projeto alcança os valores mínimos
permitidos para a densidade de defeitos na documentação.
Medida derivada de verificações ad-hoc antes e depois da
modificação;
18. SG 2 – ATACAR AS CAUSAS DOS DEFEITOS
• SP 2.3 Registrar os dados
• Registrar os dados de modo a que outros projetos e
organizações possam realizar as mesmas alterações e obter
resultados similares;
• Registros:
• Dados sobre os defeitos e outros problemas que foram analisados;
• Justificativas das decisões tomadas;
• Ações propostas nas reuniões de análise de causas;
• Atividades detalhando as ações propostas;
• Custo das atividades de análises e da resolução de defeitos;
• Medidas das alterações do desempenho do processo definido para o
projeto depois das alterações;
19. CONCLUSÃO
• Concluímos que a utilização do CAR é essencial
para solução dos problemas, já que não é
necessário apenas encontrar os problemas e sim
as causas, que geralmente não são óbvias. E
sempre realizar documentações para as
utilizações futuras.