Visão Geral da Abordagem DPPI 52 

DPPI representa uma abordagem prática para prevenção de defeitos provenientes de inspeções de software. Quando comparada ao processo tradicional de prevenção de defeitos, descrito em (Jones, 1985), a principal inovação é a integração de conhecimento obtido em sucessivas reuniões de análise causal para prover um maior entendimento a respeito das relações de causa e efeito dos defeitos da organização. Isto trata uma das oportunidades de pesquisa identificadas nas revisões sistemáticas e destacada em (Kalinowski et al., 2008a). O primeiro esforço no sentido de tratar esta oportunidade se deu na concepção inicial da abordagem, descrita em (Kalinowski et al., 2008b), que posteriormente evoluiu para se tornar DPPI (Kalinowski et al., 2010). Até a presente data, de acordo com os resultados da revisão sistemática conduzida, nenhuma outra abordagem considera esta possibilidade de integração.

Tal integração permite estabelecer e manter modelos causais para a organização. Estes modelos podem então ser utilizados para apoiar o raciocínio diagnóstico, facilitando a identificação das principais causas dos defeitos sob análise em uma nova reunião de análise causal. Com estes modelos é possível, por exemplo, apoiar o entendimento, com base no aprendizado obtido de projetos similares da organização, sobre quais causas normalmente contribuem para um determinado tipo de defeitos.

Além desta inovação, DPPI segue as diretrizes para implementar análise causal em organizações de software, descritas em (Kalinowski et al., 2008a) e atualizadas no Capítulo 3 desta tese. O uso das diretrizes permitiu detalhar as atividades de prevenção de defeitos em tarefas mais específicas, fornecendo detalhes adicionais sobre as técnicas a serem utilizadas para realizar estas tarefas eficientemente.

Ainda com base nas diretrizes, DPPI integra a prevenção de defeitos na estratégia de medição e controle das atividades de engenharia do software para as quais a prevenção de defeitos está sendo realizada, permitindo observar se as melhorias implementadas para estas atividades efetivamente trouxeram benefícios.

Isto é feito ao utilizar as métricas definidas nas diretrizes para medir e controlar o desempenho destas atividades.

Adicionalmente, DPPI trata todas as práticas específicas da área de processos CAR (Causal Analysis and Resolution) do modelo CMMI, descrito em (SEI, 2006a). Desta forma, seguir a abordagem DPPI resulta em aderência a estas práticas em relação à análise causal de defeitos de software provenientes de inspeções. Entretanto, a área de processos CAR do CMMI pode também ser utilizada como referência de práticas para realizar a análise causal de outros problemas, que estão fora do escopo de DPPI.

Como DPPI visa a realização de análise causal para obter a melhoria contínua do desempenho e da capacidade das atividades de engenharia do software, conforme sugerido nas diretrizes, ela foi projetada para ocorrer de forma integrada ao processo de desenvolvimento, sempre imediatamente após as inspeções dos artefatos produzidos por estas atividades. Ou seja, DPPI deve ser aplicada mesmo quando o desempenho da atividade estiver dentro do esperado (ou estável). Nesta ocasião, a aplicação contínua permitirá a identificação de causas comuns para o desempenho do processo (Florac e Carleton, 1999) que poderão subsidiar a implementação de ações que tragam melhorias efetivas para o desempenho.

Assim, o momento de aplicação de DPPI dentro de um processo de desenvolvimento de software é após as inspeções dos artefatos produzidos pelas principais atividades de engenharia do software. É importante observar que o processo de inspeção, conforme definido por Fagan (1976) envolve a correção dos defeitos. Assim, quando DPPI é iniciada os defeitos encontrados nos artefatos da atividade de desenvolvimento já foram corrigidos. A Figura 4.1 ilustra os momentos de aplicação de DPPI considerando um processo iterativo e incremental. Nesta figura DPPI foi aplicada duas vezes, após a inspeção da especificação funcional produzida na atividade de levantamento e especificação de requisitos, visando melhorar esta atividade para os próximos módulos e após a inspeção da especificação técnica produzida na atividade de projeto do produto, visando melhorar esta atividade para os próximos módulos.

Na Figura 4.1 é possível ainda observar que DPPI tem a lista de defeitos e o modelo causal da atividade como entrada. O modelo causal visa apoiar a identificação das causas dos defeitos e será atualizado a cada aplicação de DPPI. Maiores detalhes sobre o modelo casual e esta atualização serão fornecidos mais adiante.

Figura 4.1. Momentos de Aplicação de DPPI em um Processo Iterativo Incremental. Este contexto de utilização impõe algumas premissas para a aplicação de DPPI. Estas premissas são:

 A existência de um processo definido para o projeto (ou ao menos para as atividades de engenharia do software em que DPPI será aplicada), conforme sugerido nas diretrizes.

 A realização de inspeções de software durante as quais dados sobre os defeitos são armazenados. Os dados a serem armazenados (além da descrição dos defeitos) são os indicados pelas diretrizes como as informações básicas de consenso para a realização de análise causal de defeitos: a atividade em que o defeito foi introduzido, a atividade em que o defeito foi detectado, a natureza e o tipo de defeito.

 DPPI precisa ser utilizada para melhorar atividades de engenharia do software para incrementos (módulos) do mesmo projeto ou de projetos similares. Assim, caso seja utilizada entre diferentes projetos, estes devem compartilhar o mesmo esquema de classificação de defeitos, seguir processos similares, ser relacionados a domínios de complexidade similar, utilizar equipes com experiência similar e utilizar o mesmo tipo de tecnologia. Basicamente, neste caso, as premissas de similaridade entre os projetos são as mesmas que para o agrupamento de projetos para controle

estatístico de processos (Florac e Carleton, 1999). A definição destes critérios de similaridade está fora do escopo desta tese.

 As causas identificadas para os defeitos de cada uma das atividades de engenharia do software em reuniões de análise causal anteriores (considerando projetos similares) precisam ser registradas com um nome, a categoria da causa e o tipo de defeito relacionado. Esta informação será utilizada como retroalimentação, permitindo a montagem do modelo causal. A abordagem DPPI envolve quatro atividades: (i) Análise da Atividade de Desenvolvimento; (ii) Preparação para Análise Causal; (iii) Reunião de Análise Causal; e (iv) Melhoria da Atividade de Desenvolvimento. A Figura 4.2 fornece uma visão das tarefas e dos papéis envolvidos na execução destas atividades. É importante ressaltar que a atividade de engenharia do software a ser melhorada e a inspeção estão fora do escopo de DPPI.

Figura 4.2. Visão Geral da Abordagem DPPI.

Esta figura também destaca a proposta de manter, para cada atividade de engenharia do software, um modelo causal com informações a respeito das relações de causa e efeito dos defeitos da organização. Em DPPI tais modelos causais devem ser estabelecidos e mantidos ao alimentar redes Bayesianas.

Uma rede Bayesiana é um grafo direcionado e acíclico onde os nós correspondem a variáveis aleatórias (Vars = {X1,..., Xn}) de interesse e estas tem parâmetros de distribuição de probabilidades associadas que quantificam o efeito dos pais4 em um determinado nó (P(Xi|Pa(Xi)), onde Pa(Xi) denota os pais do nó Xi). A rede Bayesiana especifica uma distribuição de probabilidades conjunta sobre variáveis aleatórias, dada pela expressão da Figura 4.3. Assim, segundo Russel e Norvig (2004), uma rede Bayesiana pode fornecer uma descrição completa de um domínio, onde toda entrada na disbribuição de probabilidade conjunta total pode ser calculada a partir das informações armazenadas na rede.

Figura 4.3. Distribuição de Probabilidades Conjunta sobre Variáveis Aleatórias de uma Rede Bayesiana.

Pearl (2000) afirma que modelos causais probabilísticos podem ser elaborados utilizando redes Bayesianas caso exemplos concretos de relações causais5 entre variáveis aleatórias possam ser obtidos para alimentar a rede. Assim, a estrutura e os parâmetros de distribuição de probabilidade podem ser aprendidos a partir destes exemplos. Após a alimentação destas redes elas podem ser utilizadas tanto para inferência preditiva quanto para inferência diagnóstica (Russel e Norvig, 2004).

No caso de DPPI, os exemplos de relações causais para alimentar a rede Bayesiana são os próprios resultados de cada uma das reuniões de análise causal (consenso da equipe a respeito das principais causas dos defeitos analisados). Posteriormente a inferência diagnóstica desta rede deve ser utilizada para apoiar as próximas reuniões de análise causal, fechando explicitamente um ciclo de retroalimentação a respeito das causas de defeitos de software da organização. A Figura 4.4 ilustra esse ciclo de retroalimentação.

4 _{Os pais de um determinado nó em um grafo direcionado são os nós que possuem} arestas direcionadas para este nó.

5 _{De acordo com Babbie (1986), três condições precisam ser atendidas para} demonstrar um relacionamento causal:

 Condição 1: Precisa haver uma correlação entre a causa e o efeito;  Condição 2: A causa precisa preceder o efeito;

Figura 4.4. Ciclo de Retroalimentação da Abordagem DPPI – Os Modelos Causais para as Atividades de Desenvolvimento são Construídos com os Próprios

Resultados das Reuniões de Análise Causal.

Redes Bayesianas têm sido utilizadas ao longo dos anos para apoiar outras atividades de engenharia de software, como gerência de riscos (Hearty et al., 2005), predição de defeitos (Fenton, 1999) (Gras, 2004) (Fenton et al., 2007) e controle da qualidade (Krause et al., 2002). Nestas abordagens as redes bayesianas são alimentadas com base em dados históricos sobre os defeitos e/ou com base na opinião de especialistas e posteriormente utilizadas para predição e controle.

Adicionalmente, fora do contexto de engenharia de software, na experiência descrita em (Han et al., 2008), redes Bayesianas construídas com base na opinião de especialistas, aplicadas ao domínio de máquinas para produção de chips, apoiaram o diagnóstico correto de causas de sintomas destas máquinas.

A proposta de DPPI de atualizar as redes bayesianas dinamicamente com relações causais concretas, identificadas nas reuniões de análise causal de defeitos de software, e utilizar a inferência diagnóstica da rede para apoiar a identificação de causas de defeitos nas próximas reuniões de análise causal representa uma proposta nova e anteriormente não explorada.

Tendo fornecido esta visão geral da abordagem DPPI, nas próximas seções as quatro atividades de DPPI e de suas tarefas são descritas em mais detalhes. Quando conveniente, exemplos com base em projetos reais foram fornecidos para facilitar a compreensão da abordagem. Uma prova de conceito, aplicando as atividades abordagem em um projeto real, fornecendo todo o contexto deste projeto será descrita detalhadamente no capítulo seguinte.