Prova de Conceito: Aplicação de DPPI a um Projeto Real 73 

para realizar análise causal de defeitos na atividade de especificação funcional de um projeto Web real de larga escala. O escopo deste projeto, chamado SIGIC, foi desenvolver um novo sistema de informação para gerenciar as atividades da Fundação COPPETEC. Assim, o projeto envolveu diversos departamentos desta Fundação, tais como: recursos humanos, financeiro, protocolo, entre outros.

O sistema a ser desenvolvido foi modularizado e implementado utilizando um ciclo de vida iterativo e incremental. Baseado neste ciclo de vida, um processo de desenvolvimento foi definido, em que inspeções de software eram realizadas nas especificações funcionais de cada um dos módulos (Kalinowski et al., 2007), utilizando o framework ISPIS (Kalinowski e Travassos, 2004).

Ao todo, mais de 10 iterações foram realizadas e mais de 200 casos de uso foram especificados, implementados e entregues ao cliente, ao longo de um período de desenvolvimento de mais de três anos. No final do projeto, todos os dados das inspeções estavam disponíveis, incluindo detalhes de mais de 1000 defeitos encontrados e removidos das especificações funcionais antes da efetiva implementação.

Neste contexto, DPPI foi aplicada retroativamente à atividade de especificação funcional do quarto módulo desenvolvido, referente ao protocolo de solicitações de projetos vinculados, chamado MPTV.

Os detalhes de como cada uma das atividades de DPPI (exceto a atividade de melhoria, que não pode ser realizada, uma vez que a aplicação foi retroativa) pôde ser realizada são descritos a seguir.

5.2.1 Realizando a Análise da Atividade de Desenvolvimento

Para entender o cenário atual e as mudanças nas taxas de defeitos comparando o módulo MPTV com os módulos anteriores (MSL, MGU e MPT), conforme definido em DPPI, um gráfico U foi plotado, utilizando a ferramenta MiniTab (MiniTab, 2011), para defeitos por hora de inspeção e defeitos por unidade de tamanho (neste caso pontos de caso de uso). Este gráfico está ilustrado na Figura 5.1.

Figura 5.1. Gráfico U para Defeitos por Hora de Inspeção e Defeitos por Unidade de Tamanho (Pontos de Caso de Uso).

Neste gráfico foi possível notar que o número de defeitos revelados por hora de inspeção no MPTV foi mais alto do que a média, enquanto o número de defeitos por ponto de caso de uso foi próximo da média. O gráfico U mostra um cenário de estabilidade (nenhum de seus limites de controle foi ultrapassado).

Como a especificação funcional é a primeira atividade do desenvolvimento, a métrica PIQ (Phase Input Quality – percentual de defeitos proveniente de fases

anteriores) tem valor 0 e a métrica POQ (Phase Output Quality – percentual de defeitos propagando desta atividade para as demais), que é diagnóstica em relação ao processo como um todo, não pôde ser calculada, uma vez que dados de defeitos de outras atividades não estavam disponíveis. Mais detalhes sobre as métricas PIQ e POQ podem ser obtidos no capítulo 3.

Dado este cenário, o objetivo quantitativo de melhoria estabelecido foi reduzir a taxa de defeitos por unidade de tamanho de 0,39 (a atual) para 0,31 (a melhor taxa obtida até então).

5.2.2 Realizando a Preparação para Análise Causal

Esta atividade envolve aplicar o gráfico de Pareto para selecionar amostras e encontrar erros sistemáticos nestas amostras. O gráfico de Pareto elaborado para a análise dos defeitos do módulo MPTV (gerado utilizando a ferramenta MiniTab) está ilustrado na Figura 5.2.

O projeto considerou as categorias de defeitos descritas em (Shull, 1998). É possível observar que a maioria dos defeitos é do tipo fato incorreto e que a soma de fatos incorretos e omissões representa em torno de 60% do total de defeitos encontrados. Com o apoio do gráfico, os 12 defeitos do tipo fato incorreto (de um total de 34 defeitos) foram selecionados como amostra para identificar os erros sistemáticos.

Figura 5.2. Gráfico de Pareto para os Defeitos do Módulo MPTV.

A partir da análise da descrição dos defeitos os seguintes dois erros sistemáticos puderam ser encontrados: “Escrever regras de negócio inválidas” (referente a 4 dos 12 defeitos) e “Ligar descrições de casos de uso de forma incorreta” (referente aos outros 8 dos 12 defeitos).

Para deixar mais claro o significado destes erros sistemáticos, um exemplo de defeito que foi atribuído ao erro sistemático “Escrever regras de negócio inválidas” é “UC01 - O funcionário do setor de protocolo não pode alterar o projeto/fundo selecionado pelo coordenador! Baseado em quê ele faria essa alteração? Assim, formulário só deveria ter campo read-only”. Um exemplo de defeito atribuído ao erro sistemático “Ligar descrições de casos de uso de forma incorreta” é “UC03 - O fluxo A7 deveria retornar para o passo 2 ao invés do 3”.

5.2.3 Realizando a Reunião de Análise Causal

Antes de descrever como a atividade de reunião de análise causal foi realizada, alguns detalhes serão fornecidos sobre como o modelo causal pôde ser construído retroativamente.

Construção Retroativa da Rede Bayesiana. Como nenhuma sessão anterior

de análise causal havia sido realizada no projeto SIGIC, o modelo causal Bayesiano teve que ser construído retroativamente com base nos dados de defeitos dos módulos anteriores, para que pudesse ser usado para a sessão do MPTV.

Para isto, primeiramente uma reunião foi conduzida com a equipe responsável pela análise e gerência no projeto SIGIC (um total de 4 participantes do projeto) para realizar um brainstorm sobre possíveis causas para defeitos de especificação funcional, baseado nas categorias de causa (método, pessoas, ferramentas, entradas e organização) sugeridas nas diretrizes. O resultado deste brainstorm pode ser visto na Figura 5.3 (os termos foram mantidos em inglês, porque a rede foi alimentada desta forma, para obter consistência com as demais figuras apresentados no restante do capítulo).

Após este brainstorm, descrições dos 163 defeitos de especificação funcional que haviam sido encontrados em módulos desenvolvidos antes do MPTV foram analisadas com o apoio dos autores destes módulos, de membros do grupo de processos (SEPG) e de inspetores responsáveis por encontrar estes defeitos. Durante este processo, cada um dos defeitos foi associado a uma das causas do brainstorm. Outras causas poderiam ter sido adicionadas, mas para os 163 defeitos analisados isto não foi necessário.

Ao final deste processo, cada defeito continha as seguintes informações: o módulo, o tamanho deste módulo, o esforço de inspeção, a categoria do defeito, a severidade do defeito, a causa e a categoria de causa (estes últimos dois representam os dados novos adicionados). Estas eram as variáveis aleatórias candidatas a fazer parte da rede Bayesiana. Conforme descrito no capítulo anterior, as relações causais de nosso interesse puderam ser facilmente modeladas utilizando três destas variáveis, com a causa e a categoria da causa ambas afetando a categoria do defeito (veja Figura 4.8). Isto definiu a estrutura de nossa rede Bayesiana. Tendo definido a estrutura, os valores e as probabilidades puderam ser obtidos utilizando os dados dos defeitos como casos de aprendizado.

É importante ressaltar que, neste caso, a rede Bayesiana foi construída de forma retroativa, uma vez que nenhuma sessão anterior de análise causal havia sido conduzida ao longo do projeto utilizando DPPI. Caso contrário, os casos de aprendizado poderiam ter sido obtidos a partir dos resultados das sessões anteriores (realizadas em módulos anteriores do mesmo projeto ou em módulos de projetos similares) e a rede Bayesiana poderia ter sido construída dinamicamente, sem a necessidade de classificar os dados dos defeitos um a um. Mais detalhes sobre a construção dinâmica da rede podem ser obtidos no capítulo 4.

Conduzindo a Reunião de Análise Causal. No início da atividade de reunião

de análise causal o diagrama de causa e efeito probabilístico deveria estar disponível para as categorias de defeitos associadas aos erros sistemáticos sendo analisados. Note que, seguindo a abordagem DPPI, um erro sistemático sempre estará associado a defeitos da mesma categoria.

Este diagrama pode ser construído transcrevendo a inferência Bayesiana para a categoria de defeito em questão. A inferência Bayesiana mostra as probabilidades com que cada causa levou a uma determinada categoria de defeitos, considerando os dados de módulos passados (ou de projetos similares) do mesmo contexto organizacional.

A inferência diagnóstica Bayesiana e o diagrama de causa e efeito probabilístico correspondente para fatos incorretos em especificações funcionais do

projeto SIGIC estão ilustrados na Figura 5.4. Esta figura mostra que, neste projeto, as causas para fatos incorretos usualmente são “Falta de Conhecimento do Domínio” (25%), “Tamanho e Complexidade do Domínio do Problema” (18,7%), “Descuido” (15,6%) e “Ferramental limitado para Rastreabilidade” (12,5%).

Figura 5.4. Inferência Bayesiana e o Diagrama de Causa e Efeito Probabilístico Correspondente.

De fato, na reunião de análise causal do modulo MPTV as causas identificadas para o erro sistemático “Escrever regras de negócio inválidas” foram “Falta de Conhecimento do Domínio” e “Tamanho e Complexidade do Domínio do Problema” e a causa identificada para o erro sistemático “Ligar descrições de casos de uso de forma incorreta” foi “Descuido”. Estas causas correspondem às três causas do diagrama de causa e efeito probabilístico com maior probabilidade e foram identificadas através da leitura das descrições dos defeitos envolvendo o autor, inspetores e membros do SEPG. Com base nesta experiência, aparentemente, o diagrama de causa e efeito probabilístico pode se mostrar útil, embora uma investigação adicional desta utilidade seja necessária (capítulo 6).

As ações propostas para tratar as causas “Falta de Conhecimento do Domínio” e “Tamanho e Complexidade do Domínio do Problema” foram: (i) estudar o domínio e o sistema pré-existente e (ii) modificar o template de especificação funcional, criando uma sessão separada para as regras de negócio, listando separadamente da

Para a causa “Descuido” a ação foi publicar exemplos relevantes de defeitos da categoria “Fato Incorreto” relacionados a descuidos e apresentá-los à equipe de especificação funcional.

De acordo com DPPI, neste momento a rede Bayesiana seria retroalimentada com 16 novos casos de aprendizado, 4 tuplas contendo o tipo de defeito fato incorreto e associando-o à causa “Falta de Conhecimento do Domínio”, 4 tuplas contendo o tipo de defeito fato incorreto e associando-o à causa “Tamanho e Complexidade do Domínio do Problema” e 8 tuplas contendo o tipo de defeito fato incorreto e associando-o à categoria “Descuido”. Como somente fatos incorretos foram analisados nesta sessão de análise causal, nenhum aprendizado adicional foi obtido a respeito das demais categorias de defeitos. Esta retroalimentação é sistemática e pode ser facilmente automatizada.

A próxima atividade de DPPI seria a melhoria da atividade de desenvolvimento. Entretanto, conforme mencionado anteriormente, esta atividade não foi realizada, uma vez que a prova de conceito foi realizada retroativamente e o próximo módulo já havia sido especificado. Por este mesmo motivo, resultados quantitativos da aplicação de DPPI (que seriam observados nos gráficos U da análise da atividade de desenvolvimento para o próximo módulo) não puderam ser obtidos.

5.2.4 Considerações Finais da Prova de Conceito

A aplicação manual e retroativa de DPPI à um projeto de desenvolvimento real permitiu a obtenção de insights adicionais a respeito de sua viabilidade de aplicação e dos requisitos para apoio ferramental.

As inspeções realizadas no contexto do projeto ocorreram com o apoio da ferramenta ISPIS (Kalinowski e Travassos, 2004), que facilitou a condução de um processo de inspeção bem definido que apresentou resultados estáveis e permitiu o registro dos dados de defeitos. Entretanto, a condução das inspeções está fora do escopo de DPPI e elas poderiam também ter sido realizadas de forma manual.

Durante a aplicação de DPPI descrita na prova de conceito as ferramentas MiniTab e Netica foram utilizadas. A ferramenta MiniTab foi utilizada para gerar os gráficos de controle U e o gráfico de Pareto. Ela foi escolhida por atender às necessidades de geração destes gráficos. A geração manual destes gráficos iria requerer muito esforço. Entretanto é importante ressaltar que existem outras ferramentas estatísticas que poderiam ser utilizadas para a geração destes gráficos. A ferramenta Netica, por sua vez, foi utilizada para gerar a rede Bayesiana a partir dos casos de aprendizado e para realizar a inferência Bayesiana. Novamente existem outras ferramentas que atendem a este propósito e que poderiam ser utilizadas.

Conforme mencionado anteriormente, DPPI trata todas as práticas específicas da área de processos CAR do CMMI. Entretanto, mesmo com a aplicação sendo moderada pelo criador da abordagem, seguir as atividades de DPPI e manter toda a documentação relacionada (taxas de defeitos, objetivos de melhoria, principais categorias de defeito identificadas, erros sistemáticos, causas identificadas e propostas de ação) utilizando somente templates (como o disponível no Anexo D) sem um apoio ferramental se mostrou uma tarefa complexa durante a experiência de aplicar DPPI ao módulo MPTV.

Adicionalmente, a geração manual e retroativa dos casos de aprendizado para alimentar a rede Bayesiana exigiu grande esforço (além de ser uma tarefa sujeita a erros). Ao todo foram gastas mais de 80 horas da equipe com sessões de brainstorm para identificar as possíveis causas e classificar a base de defeitos para obter os casos de aprendizado (defeitos associados às suas causas). Este esforço seria proporcional ao tamanho da base de defeitos e pode não ser aceitável em aplicações industriais. Entretanto, a abordagem prevê a geração dinâmica destes casos com os próprios resultados de cada uma das sessões de análise causal, que, se automatizada, não exigiria esforço adicional.

De maneira geral, a experiência de aplicar DPPI a um projeto Web real de larga escala mostrou sua viabilidade de aplicação em projetos reais, desde que apoio adequado seja fornecido para sua institucionalização e a retroalimentação da rede Bayesiana seja automatizada.

Assim, requisitos para que um framework computacional para apoiar a realização de DPPI pudesse ser construído foram identificados, de modo que este

framework forneça um passo a passo para a realização das atividades previstas na

abordagem, mantendo toda a documentação necessária como simples conseqüência de sua utilização. Adicionalmente, o framework construído estabelece e mantém os casos de aprendizado e realiza o aprendizado e a inferência bayesiana sem esforço adicional, utilizando os próprios resultados de cada sessão de análise causal, automatizando desta forma o ciclo de retroalimentação da abordagem DPPI (Figura 4.4). Os requisitos para o framework foram definidos a partir da abordagem DPPI e de seu template (Anexo D). Sua construção se deu contexto de um projeto final do curso de Engenharia da Computação da UFRJ (Paes, 2010). Um resumo de seus requisitos, de seu projeto e de suas principais funcionalidades encontra-se no Anexo E.