Uso das Diretrizes para Realizar Análise Causal de Defeitos de Acordo

Nesta seção será apresentado como as diretrizes podem ser utilizadas para conduzir a análise causal de defeitos de acordo com as boas práticas recomendadas pelos modelos de maturidade CMMI (SEI, 2006a) e MPS (SOFTEX, 2009). A discussão será focada em um destes modelos, o CMMI, que possui uma área de processos dedicada à análise causal, denominada Causal Analysis and Resolution

(CAR), no nível de maturidade 5.

A condução de análise causal de defeitos realizando as práticas específicas da área de processos CAR do CMMI implica no atendimento também de alguns dos resultados dos atributos de processo 5.1 e 5.2 do modelo MPS. Adicionalmente, implica no atendimento de alguns dos resultados de um dos processos complementares da ISO 12207, Melhoria de Processos Quantitativa (Quantitative

Process Improvement), definido na ISO 15504 (ISO/IEC, 2008b). Os resultados

atendidos do MPS e da ISO são os referentes à identificação e implementação de oportunidades de melhoria relacionadas a causas comuns de variação do desempenho do processo. De fato, a aplicação de análise causal de defeitos a um processo de engenharia representa uma das principais formas de identificar e tratar causas comuns de variação do desempenho deste processo, e, consequentemente, de permitir a melhoria quantitativa do desempenho deste processo (Card, 2005)

É importante deixar claro que o escopo desta tese é a análise causal de defeitos de software, enquanto o escopo da área de processos CAR do CMMI envolve a análise causal de defeitos de software e de outros problemas que podem ocorrer ao longo do desenvolvimento (como atrasos no cronograma, custos fora do controle, entre outros). Assim, nesta seção estaremos tratando especificamente de utilizar as diretrizes para realizar análise causal de defeitos de software de acordo com os modelos de maturidade. Para a implementação completa da área de processos CAR seria necessário apoiar também a análise causal de outros problemas que podem surgir durante o desenvolvimento. Desta forma, as informações aqui apresentadas complementam as contidas no modelo CMMI (SEI, 2006a) e no guia de implementação do nível A do MPS (SOFTEX, 2009), fornecendo detalhes adicionais sobre como lidar com os defeitos de software.

As subseções seguintes descrevem como cada uma das práticas específicas da área de processos CAR pode ser efetivamente realizada, para a análise causal de defeitos de software, com base nas diretrizes.

3.9.1 SP 1.1 Selecionar Dados de Defeitos para Análise.

De acordo com a tradução do CMMI (SEI, 2006b), esta prática envolve “Selecionar defeitos e outros problemas para análise”. Assim, esta prática é apoiada diretamente pelas respostas às perguntas “Como Categorizar os Defeitos?” e “Que Abordagem deve ser Seguida?”.

O registro, identificação e classificação são abordados na resposta à primeira pergunta, onde esquemas de classificação de defeitos são discutidos. A seleção para análise, por sua vez, pode ser realizada utilizando gráficos de Pareto, conforme sugerido na resposta à pergunta “Que Abordagem deve ser Seguida?”.

3.9.2 SP 1.2 Analisar Causas

De acordo com a tradução do CMMI (SEI, 2006b), esta prática envolve “Realizar a análise de causas de defeitos e de outros problemas selecionados e propor ações para tratá-las”. Assim, esta prática é apoiada pela resposta à pergunta “Que Abordagem deve ser Seguida?”.

A resposta a esta pergunta sugere o uso de diagramas de causa e efeito para que a equipe, composta por responsáveis pela introdução dos defeitos, responsáveis por sua detecção e membros do grupo de processos da organização, identifique as causas principais para o erro sistemático (um mesmo erro que levou a diversos defeitos do mesmo tipo) em questão.

3.9.3 SP 2.1 Implementar Propostas de Ação

De acordo com a tradução do CMMI (SEI, 2006b), esta prática envolve “Implementar propostas de ação selecionadas que foram desenvolvidas durante análise de causa”. Novamente o resultado é apoiado pela resposta à pergunta “Que Abordagem deve ser Seguida?”

A resposta a esta pergunta sugere o uso de um processo aderente ao de prevenção de defeitos (Jones, 1985). Na reunião de análise causal deste processo, uma vez que as causas principais foram encontradas, propostas de ação são desenvolvidas pela equipe para tratar estas causas. Estas ações devem ser priorizadas para que possam ser gerenciadas até sua conclusão (Card, 2005). O processo de prevenção de defeitos compreende ainda uma atividade específica para a implementação das ações de melhoria identificadas.

3.9.4 SP 2.2 Avaliar Efeitos de Mudanças

De acordo com a tradução do CMMI (SEI, 2006b), esta prática envolve “Avaliar os efeitos das mudanças no desempenho do processo”. Uma maneira interessante de implementar este resultado é através da integração da análise causal de defeitos com o controle estatístico de processos, tratado na resposta à pergunta “Como Análise Causal de Defeitos pode ser Integrada com Controle Estatístico de Processos?”.

Assim, objetivos quantitativos de melhoria do processo de engenharia em que os defeitos foram revelados devem ser estabelecidos e acompanhados através do controle estatístico das métricas relacionadas a defeitos sugeridas na resposta à pergunta “Que Métricas devem ser Coletadas?”. As diretrizes sugerem o uso de gráficos U como ponto de partida para o controle estatístico das métricas relacionadas a defeitos (Hong et al., 1999) (Jalote e Saxena, 2002) (Card, 2005).

3.9.5 SP 2.3 Registrar Dados

De acordo com a tradução do CMMI (SEI, 2006b), esta prática envolve “Registrar dados de análise e resolução de causas para uso no projeto e na organização”.

A resposta à pergunta “Que Abordagem deve ser Seguida?” indica o processo de prevenção de defeitos como uma possibilidade de abordagem a seguir, este processo já menciona uma base de experiências alimentada através da documentação da reunião de análise causal e da implementação das ações. A importância de documentar os resultados da reunião de análise causal é também destacada por Card

sistemáticos identificados e analisados, as causas principais encontradas para estes erros e as ações propostas para tratar estas causas (Leszak et al., 2002) (Card, 2005). Em relação à implementação das ações, a documentação é referente ao gerenciamento desta implementação, envolvendo custo, esforço e tempo da implementação de cada uma das ações. O resultado das ações pode ser acompanhado conforme descrito na seção anterior e também deve ser documentado.