Artigo Engenharia de Software 17 - Predição de Defeitos em Software

Verificação & Validação

Predição de Defeitos em Software

A produção de um software de qualidade depende de muitos fatores envolvidos no seu processo de desenvolvimento. Uma das maneiras de contribuir com a qualidade de um produto é incluir atividades de testes de software bem direcionadas e conduzidas durante a sua construção. O processo de testes tem como uma de suas etapas a identificação dos defeitos existentes no produto em análise. Antecipar a localização de defeitos, antes mesmo que ocorram, pode contribuir para o direcionamento das atividades de testes, de maneira que a equipe envolvida nessas atividades possa direcionar seus esforços para áreas do software que apresentam maior propensão a apresentar problemas. Iniciativas neste sentido são muito difundidas na indústria, apresentando diversos casos práticos em empresas como: Microsoft, Ericsson e IBM.

O que é Predição de Defeitos em Software?

Predição de defeitos é a tentativa de antecipar a localização de defeitos em uma aplicação através do uso de técnicas específicas. Em muitos casos, trata-se da criação de modelos, que analisam dados históricos de um projeto para, a partir daí, tentar adivinhar como se comportarão versões futuras de seu código.

Predizer a localização de defeitos em módulos da aplicação aumenta as chances que as atividades de testes têm de encontrá-los. Dessa maneira, ações corretivas podem ser tomadas o quanto antes no desenvolvimento do produto.

As atividades de testes de software podem ser responsáveis por uma parcela considerável dos custos totais de um projeto. Tosun, em seu artigo Ensemble of software defect predictors: a case study, publicado em 2008, relata uma redução de aproximadamente 29% (vinte e nove por cento) no esforço de testes quando as atividades são direcionadas através da predição de defeitos.

Assim, através da aplicação de tais técnicas, pode-se prever em uma aplicação, por exemplo:

·          Se determinado módulo está ou não propenso ao aparecimento de defeitos. Um módulo pode ser representado por um pacote, um arquivo, uma classe, ou um método, a depender da granularidade escolhida para análise. Neste caso, diz-se que um módulo classificado como SIM está propenso ao aparecimento de defeitos, assim como um módulo classificado como NÃO, não está propenso ao aparecimento de defeitos;

·          Quantidade de defeitos em um módulo. Em módulos onde é esperado o aparecimento de defeitos, pode-se querer estimar a quantidade desses defeitos em cada módulo;

·          Densidade de defeitos na aplicação. A densidade de defeitos pode ser representada pela quantidade de defeitos por linha de código;

·      Quais módulos apresentam a maior quantidade de defeitos na aplicação. Com nessa informação, o time de testes pode priorizar seus esforços em módulos com propensão a maior quantidade de defeitos.

Benefícios da Predição de Defeitos

Diversos são os benefícios reportados na academia e na indústria pela aplicação de técnicas de predição de defeitos, como por exemplo, a geração de informação para:

·         Suporte ao planejamento e execução de testes;

·         Identificação de pontos de melhoria no código desenvolvido, através do diagnóstico de trechos de código complexos que podem ser simplificados;

·         Redução da taxa de inserção de defeitos na manutenção e evolução do software;

·         Planejamento do esforço de desenvolvimento de iterações futuras do projeto.

Para que uma equipe possa se beneficiar da aplicação de técnicas de predição, esta deve definir quais informações coletar em um projeto já no inicio do seu desenvolvimento. A seção seguinte explica que tipo de métricas podem ser coletadas em um projeto.

Métricas para Predição de Defeitos

Algumas métricas de projeto devem ser coletadas, de maneira manual ou automática. Em seguida, essas métricas devem ser analisadas, caso a caso, visando à identificação da sua relação com o aparecimento de defeitos em versões futuras do código. Diversos tipos de métricas podem ser utilizadas, de diferentes categorias, por exemplo: métricas de métodos, de classes, de componentes ou processo.

As métricas de projeto podem ser básicas ou derivadas. Cibele Feitosa explica a diferença entre esses dois tipos de métricas em um trabalho publicado em 2004, chamado Definição de Um Processo de Medição e Análise com Base nos Requisitos do CMMI. Segundo Cibele, uma métrica básica é “independente de outras medidas”. Já a métrica derivada pode ser definida como “função de duas ou mais medições básicas ou derivadas”.

Como exemplo de métricas básicas, podemos mencionar as seguintes métricas retiradas do artigo Use of relative code churn measures to predict system defect density, publicado por Naggapan, em 2005:

·         LOC – quantidade de linhas de código;

·         Quantidade de modificações feitas em um arquivo;

·         Quantidade de arquivos que foram modificados.

Como exemplo de métricas derivadas, podemos citar as métricas abaixo, retiradas do mesmo artigo:

·         LOC modificado / LOC Total – quantidade de linhas de código que foram modificadas em relação à quantidade total de linhas de código existentes na aplicação;

·         Arquivos modificados / Total de arquivos – quantidade de arquivos que foram modificados em relação à quantidade total de arquivos existentes na aplicação.

Uma busca em bases eletrônicas por artigos que abordassem o tema predição de defeitos foi realizada pela autora deste artigo com o objetivo de identificar que métricas de projeto geralmente são utilizadas para servir de entrada para a criação de modelos de predição.

Como resultado desta pesquisa, a Tabela 1 exibe as métricas que tiveram uma quantidade maior de ocorrências dentre os 66 (sessenta e seis) artigos selecionados pelo estudo (Pontes, 2009). A coluna ocorrências indica a quantidade de vezes que a métrica apareceu em relação à quantidade total de artigos analisados.

É importante ressaltar que 1134 (mil cento e trinta e quatro) artigos foram encontrados pelas palavras-chave de pesquisa utilizadas na busca. Em seguida foram definidos critérios de inclusão e exclusão desses artigos nesta revisão da literatura, de maneira que somente artigos recentes, e que abordassem diretamente o tema, fossem incluídos para extração de suas informações.