Prevendo Defeitos de Software II: Previsão dos Números de Defeitos
Prever o número de defeitos de software em campo não é uma arte de “bola de cristal” mas uma técnica que se baseia no histórico de defeitos ocorridos até a liberação.
A técnica que apresentamos neste tutorial é de fácil aplicação, permitindo a criação de cenários “what-if”, mostrando as situações de melhor/pior caso, desta forma orientando a tomada de decisões e o acompanhamento.
Jorge Moreira de Souza
Doutor em Informática (81) pelo Instituto Nacional Politécnico de Toulouse, França, Mestre (75) e Bacharel (71) em Engenharia Elétrica na PUC-RIO.
As principais áreas de interesse são Engenharia de Tráfego e Análise de Confiabilidade de Sistemas. Trabalha atualmente na FITec onde desenvolve trabalhos de análise/avaliação e revisões de projeto.
Participou com membro da Comissão do I Concurso Teleco de Trabalhos de Conclusão de Curso (TCC), realizado em 2005, e do II Concurso Teleco de Trabalhos de Conclusão de Curso (TCC), realizado em 2006.
Email: jmdsouza@fitec.org.br Categoria: Banda Larga
Nível: Introdutório Enfoque: Técnico
PDS II: Introdução
No tutorial anterior abordamos a avaliação da qualidade do software, ou seja, a análise crítica do histórico de defeitos até o momento da liberação. Relembrando, por defeito entendemos a detecção de uma operação do sistema que não está conforme a especificação e que necessita de uma correção do software para ser sanado.
Mostramos o que é o gráfico de controle e como é usado no controle da “fabricação” de software para garantir que a taxa de defeitos, detectada ao longo do processo de desenvolvimento, esteja dentro de limites especificados. Abordamos também o que é crescimento de confiabilidade e apresentamos um modelo que será usado no presente tutorial.
Ainda relembrando, “os modelos são ditos de crescimento de confiabilidade porque supõem que o processo de detecção e correção de falhas é perfeito e consequentemente o sistema tende a crescer em confiabilidade ao longo do tempo. Na prática isso não acontece e períodos de crescimento (diminuição da taxa de defeitos) e decrescimento (aumento da taxa de defeitos) de confiabilidade se sucedem ao longo do desenvolvimento ou de operação em campo”.
Em muitos projetos de software, o sistema não apresenta crescimento de confiabilidade no momento da liberação (release). A decisão gerencial desejável seria análise do processo de detecção/correção de defeitos visando obter o crescimento de confiabilidade antes da liberação (a avaliação da qualidade contribuiria para a análise). Devido às pressões de mercado essa decisão geralmente não é possível e, desde de que não haja defeitos “impeditivos”, a versão é liberada.
A liberação de uma versão na qual o número de defeitos é crescente implica num maior esforço de manutenção. Dado que essa versão vai para o cliente o “time to fix” é muito importante e ele depende do planejamento do esforço necessário. Tendo em vista o número de defeitos podemos ter em mente as seguintes questões:
Qual a previsão do número de defeitos após a liberação de modo a se dimensionar o esforço necessário à manutenção?
Quanto tempo leverá para a versão liberada exibir crescimento de confiabilidade?
Neste tutorial mostraremos uma maneira de tratar as questões acima. Existem outras questões pendentes, como a da probabilidade de ocorrências críticas após a liberação, que podem ser analisadas mas que não são objeto deste tutorial.
PDS II: Construindo os possíveis cenários
De maneira geral, no momento de liberação podemos identificar quatro cenários possíveis: Cenário 1, ideal: o software apresenta um crescimento consistente de confiabilidade.
Cenário 2, quase ideal: o software apresenta uma taxa de defeito crescente mas a avaliação é que trata-se um efeito temporário e que a tendência após a liberação será de crescimento de confiabilidade.
Cenário 3, crítico: o software apresenta uma taxa de defeito decrescente e a avaliação é que trata-se um efeito temporário e que a tendência, após a liberação, será de decrescimento de confiabilidade durante um certo período.
Cenário 4, crítico: o software apresenta uma taxa de defeito crescente e a avaliação é que trata-se um efeito consistente e que a tendência após a liberação será de decrescimento de confiabilidade durante um certo período.
Não temos dados reais para mostrar os diversos cenários. Vamos ilustrar apenas os cenários 1 e 4. Exemplo do cenário 1
Trata-se de um sistema de telecomunicaçãoes de grande porte que foi testado durante 225 dias. Ao longo desse tempo o sistema exibiu crescimento consistente de confiabilidade até a entrada de um novo módulo (após 169 dias de teste) que alterou o perfil de crescimento durante 23 dias.
Após esse período o sistema volta a crescer em confiabilidade. A previsão abaixo foi feita usando-se os dados dos últimos 90 dias de teste de modo a capturar a tendência mais recente. O objetivo foi prever o número de defeitos durante o teste de aceitação com duração de 52 dias.
A figura 1 mostra o número acumulado de defeitos detectados e o resultado do modelo de previsão. O cenário 1 permite a aplicação direta dos modelos de crescimento de confiabilidade para efetuar a previsão. Usamos o modelo S-Shaped apresentado no tutorial anterior.
O resultado é muito bom permitindo ao desenvolvedor prever as expectativas de defeitos e discuti-las com o cliente antes da execução dos testes de aceitação.
Figura 1: Exemplo do cenário 1. Exemplo do cenário 4
Para o exemplo do cenário 4 vamos usar o arquivo de defeitos detectados da versão 3.8 do OpenBSD, que é a versão atual [3]. Ela foi liberada em 01/11/2005. A análise de tendência dos defeitos detectados mostra que após 26/09/2005 o número de defeitos detectados aumenta.
Veja a figura 2, a tendência ao aumento do número de defeitos é mostrada pela média móvel calculada sobre 10 dias.
Figura 2: OpenBSD R 3.8 – Defeitos detectados até a liberação.
Para efetuar a previsão de defeitos após a liberação não podemos aplicar diretamente os modelos de crescimento de confiabilidade porque o histórico de defeitos detectados não apresenta crescimento de confiabilidade.
A figura 3 mostra o resultado da previsão caso tentemos esse caminho usando o modelo S-Shaped.
Figura 3: OpenBSD R 3.8 – Previsão aplicado diretamente o modelo S-Shaped.
Para resolver esse problema propomos o uso de um índice previsor, que chamaremos apenas de previsor (predictor) que explicaremos a seguir.
PDS II: O que é um previsor?
Um previsor é qualquer métrica que possa ser derivada do produto. No nosso caso queremos um previsor para estimação do número de defeitos. Na referência [4], também com o objetivo de estimar o número de defeitos, são analisados previsores como: linhas com comentários, número de classes, troca de e-mails na correção de defeitos, etc. No nosso caso propomos como previsor a taxa de defeitos.
Como estimar o previsor? Lembre-se que vamos usar o previsor nos cenários 2-4, quando avaliamos ou suspeitamos que o sistema não terá crescimento de confiabilidade após a liberação. Nesse caso a taxa de defeitos para o período_depois da liberação (que pode ser de um, dois meses) será baseada no previsor e não no modelo de crescimento de confiabilidade.
O previsor é estimado usando os defeitos detectados num período imediatamente antes da liberação, que chamaremos período_antes. De outra forma, o método proposto prevê o número de defeitos para o período_depois da liberação baseado na história recente da taxa de defeitos avaliada no período_antes. Estimação do previsor
Previsor = Número de defeitos detectados no período_antes / Período_antes
O tamanho do período_antes é estimado de modo a representar a tendência esperada para o período_depois. A análise de tendência usando a média móvel pode nos ajudar a estimar o período_antes.
A justificativa desse método é que se a versão liberada não exibe crescimento de confiabilidade antes dificilmente a exibirá depois. Assim a taxa de defeitos no período_depois é estimada usando-se o previsor. O modelo de crescimento de confiabilidade é então aplicado ao conjunto de defeitos antes da liberação (medido) mais o período_depois (estimado pelo previsor). Relembrando, esse método baseado no previsor será usado apenas nos cenários 2-4.
PDS II: Usando o previsor
Vamos usar os dados do OpenBSD R 3.8 que, como já vimos, na liberação não apresenta crescimento de confiabilidade (cenário 4) e, para o previsor, um período_antes igual a 15 dias.
Como pode ser verificado na figura 2 a taxa de defeitos apresenta certa estabilidade nesse período com média igual a 0.93, que será o valor usado para o previsor.
Para a previsão os desenvolvedores e testadores podem ter dúvidas sobre o período_depois, que é o período estimado para que o sistema cresça em confiabilidade. Nesse caso a melhor solução é criar cenários tipo “what-if”.
Vimos (figura 3) que supor o período_depois igual a zero dá resultados otimistas. Mas se a período_depois for de um mes?, e se for de dois meses?.
A figura 4 mostra as duas previsões. Usamos os defeitos coletados até 01/04/2006.
Figura 4: Análise “what-if” do OpenBSD R 3.8 com dados até 01/04/2006.
A duas previsões começam a divergir a partir de 01/12/2005 e fica claro que a previsão período_depois igual a 2 meses é a mais apropriada. Ou seja, um mes após a liberação fica clara a previsão apropriada: 2 meses
Figura 5: Crescimento de confiabilidade: defeitos detectados até 01/01/2006.
Figura 7: Previsão usando o modelo de confiabilidade e defeitos até 01/01/2006.
Notamos, para esse exemplo real, que a precisão é muito boa e pode orientar precisamente o planejamento da manutenção, os contratos de manutenção e outras decisões que dependam do número de defeitos.
PDS II: Considerações Finais
A liberação de uma versão para o cliente tem implicações na manutenção como o planejamento da equipe de suporte, o tempo de correção do defeito, a capacidade em cumprir as claúsulas do contrato de manutenção, etc.
Tudo isso depende do comportamento do número de defeitos após a liberação. Ter um método acurado de previsão de defeitos é um dos fatores de sucesso junto ao cliente.
Prever o número de defeitos não é uma arte de “bola de cristal” mas uma técnica que se baseia no histórico de defeitos ocorridos até a liberação.
A técnica que apresentamos neste tutorial não dá uma única resposta certeira e precisa mas permite a criação de cenários “what-if” mostrando as situações de melhor/pior caso que orientam as decisões e permitem o acompanhamento.
Referências
[1] Moreira de Souza J., Prevendo Defeitos de Software I: Avaliação da qualidade, www.teleco.com.br [2] De Herdt, K., Mendiratta, V. B., Moreira de Souza, J., and Zimmerman, G. H., “What Can We Learn from Software Failure Data,” Proceedings International Symposium on Software Reliability Engineering, Chicago, Illinois, November 2005.
[3] www.openbsd.org
[4] Li P., Hersbleb J., Shaw M., “Finding Predictors of Field Defects for Open Source Software Systems in Commonly Available Data Sources: a Case Study of OpenBSD, 11th Int SW Metrics Symp (METRICS 2005), Italy, Sept. 2005.
PDS II: Teste seu Entendimento
1. Podemos aplicar diretamente o modelo de crescimento de confiabilidade para previsão: Quando o histórico de defeitos apresenta crescimento de confiabilidade.
Independentemente da tendência observada no histórico de defeitos. Sempre que se tratar de defeitos de software.
No momento da liberação.
2. Quando o histórico de defeitos não apresenta crescimento de confiabilidade? Não é possível prever.
É possível prever mas a margem de erro é bem grande. Não tem sentido prever.
Uma solução proposta é definir previsores que se correlacionem com o histórico observado. 3. Um previsor é?
Uma métrica relacionada ao produto.
Um índice relacionado ao processo de desenvolvimento. Um índice baseado no sentimento dos desenvolvedores. Uma métrica relacionado com o número de defeitos. 4. Um cenário de previsão do tipo “what-if”:
Representa uma determinada situação.
Estima as situações de pior/melhor caso pela variação de parâmetros. Define precisamente o cenário a ser analisado.
Permite representar o comportamento real do sistema.
