Estimando Defeitos Residuais em Software
 J. Antão B. Moura - UFCG/CCT/DSC – antao@dsc.ufcg.edu.br

“Good Enough Software” (GES) desponta como um decisor pragmático para liberação de versões de um software. Um produtor de software que  adota  GES decide liberar uma versão  para uso mesmo que  esta ainda contenha alguns defeitos (“bugs”)  e desde que ela já possa ser “útil” para seus usuários. A expectativa é de ir consertando os bugs em versões futuras à medida em que também se incrementa (possivelmente) a funcionalidade do software. Claro que dependendo das condições e exigências do mercado e clientes, pode não ser fácil ou mesmo possível, adotar GES. O atrativo do GES é que o produtor pode reduzir o prazo-de-entrega da versão, trazendo algum retorno financeiro mais rapidamente.

Os defeitos residuais não podem ser críticos (por exemplo, destruir o sistema de arquivos) nem em número excessivo. Um grande número de defeitos causaria falhas freqüentes do software, exasperando o usuário. É de importância pois, conhecer o número de defeitos no software para que se decida (ou não) pela sua liberação para uso.

Conhecer precisamente o número de defeitos em um Software relativamente extenso e complexo não é trivial e talvez, nem possível. A não-detecção de defeitos após uma bateria de testes em um software extenso não deve ser motivo de euforia. Normalmente significa apenas que os defeitos existem e não foram descobertos!  Alguns bugs só aparecem após muito tempo de uso por uma grande população de usuários, uma vez que testes exaustivos (nos testes alfa e beta) muitas vezes não podem ser feitos. Isto porque o total de combinação de seqüências de comandos e situações (“estados”) do ambiente de execução do software pode ser elevadíssimo.

Assim, como “estimar” o número de defeitos?  A resposta é necessária para a adoção de GES com risco “razoável” (afinal a reputação e o futuro do produtor podem ser comprometidos seriamente caso os usuários não tolerem a freqüência de falhas). Infelizmente, a literatura de Engenharia de Software não traz muitas informações sobre previsão de defeitos. Felizmente, existem alguns procedimentos relativamente simples que podem ser adotados para reduzir a prática de decisões “no escuro” ou na “base do chute”. Dois dos mais simples destes procedimentos são discutidos aqui.

Independentemente do procedimento adotado, a providência de registrar o histórico de defeitos nos vários sistemas ou produtos que desenvolve é a única maneira para o produtor   “calibrar” ou validar as estimativas que fará. Esta providência é raramente tomada, mas você não irá muito longe se não passar a executá-la imediata e continuadamente. Só com o histórico da “distribuição de defeitos” e do “ nível de satisfação de usuário” você poderá aumentar a confiabilidade de suas estimativas e a conseqüente decisão de liberação de versões. O primeiro procedimento ajudará a ilustrar a aplicação deste histórico.

Procedimento 1 – Uso do Histórico de Qualidade de Desenvolvimento

“Bom Soft” versão 1.1 com 10.000 linhas de código (= 10 KLOC ou seja, 10 Kilo Lines Of Code) apresentou 40 defeitos detectados nos testes alfa e beta e que foram removidos antes da liberação; e, outros 10 defeitos reportados pelos usuários (para o departamento de suporte técnico). A distribuição final de defeitos neste caso foi de 50 defeitos em 10 KLOC ou 5,0 defeitos/KLOC. O índice de remoção de defeitos antes da liberação foi de 40/50 (ou 80%). Os usuários reclamaram enfaticamente, mas foram acalmados pelo suporte após algum esforço. Na versão 1.2 a distribuição foi de 6,0 defeitos/KLOC; consertados todos os defeitos anteriores (foram acrescentados 5 KLOC e introduzido um total final de 30 novos defeitos), com índice de remoção antes de liberação de 70%. Desta vez, os usuários quase que se rebelavam, ameaçando ações judiciais por perdas e danos. A situação foi crítica, mas contornada eventualmente. Neste ponto, sabe-se que a qualidade do desenvolvimento deste produtor está “na faixa de 5,0 - 6,0 defeitos/KLOC” e que o produto pode se queimar no mercado ou com o cliente contratante se o índice de remoção de defeito antes da liberação não for no mínimo, 70%. Agora, deve-se decidir a liberação de “Bom Soft v1.3”, à qual foram acrescentadas 20 KLOC e os testes detectaram 80 defeitos (o que dá uma distribuição de 4 defeitos/KLOC). A não ser que haja muita confiança na melhoria de qualidade do desenvolvimento, recomendam-se extrema cautela e providência de revisão de código (mais testes, por exemplo) uma vez que a taxa de remoção antes de liberação é esperada ficar abaixo de 70% ( entre 50a 65%). Neste caso, uma aparentemente menor distribuição de defeitos detectados nos testes é motivo de apreensão e não de euforia...

Procedimento 2 – “Agrupamento de Defeitos”

O segundo procedimento foi apresentado por Steve McConnell, da Construx Sofware Builders de Washington, EUA na revista IEEE Software de maio/junho 1997. Intitulado de “Agrupamentos de Defeitos” (“Defect Pooling”), o procedimento consiste basicamente em agrupar os defeitos sendo descobertos em dois conjuntos: A e B. Aqui, o importante é ter independência entre os dois agrupamentos - o conjunto A é montado por uma equipe que testa todo o produto e  o conjunto B, por outra equipe separada que também testa todo o produto. Alternativamente, uma única equipe de testes poderia construir o conjunto A com os defeitos econtrados nos dias de datas pares e o conjunto B com os defeitos em datas ìmpares. Fechados os conjuntos A e B (no final dos testes), conte o número de defeitos:
                                            - no conjunto A (DA);
                                            - no conjuntoB (DB); e, 
                                            - que estão simultaneamente no conjunto A e no B (DAxDB)

Aplicando Teoria dos Conjuntos (vide figura), o número total de defeito distintos em ambos os conjuntos é D(A+B):

  D(A+B) = DA + DB - D(Ax B)

                                             A+B

                       A                        B                         

                                 AxB                    

O número total estimado de defeitos (durante testes e após liberação do produto) pode ser aproximado por:

Dtotal = ( DA x DB ) / D(AxB)         	

Voltando ao exemplo de “Bom Soft v 1.3” e supondo que DA= 50, DB = 45 e DAxB = 15, o número de defeito distintos é 50 + 45 - 15 = 80 ( o número já fornecido). Contudo, o número total de defeitos estimado pela última fórmula é ( 50x 45 ) / 15 = 150. Ou seja, espera-se ainda detectar 70 defeitos, o que levaria a um índice de remoção antes de liberação um pouco acima de 50%. É melhor talvez, não liberar esta versão na sua forma atual.

Note a importância de se coletar o histórico neste caso (último exemplo) para verificar a “precisão” da estimativa e ajustar a credibilidade que o produtor passará a ter na estimativa gerada.

Os leitores interessados em um terceiro procedimento (um pouco mais complexo e trabalhado), bem como na combinação de procedimentos, podem examinar o artigo de McConnell com mais vagar.

Para concluir e se você desejar uma referência para o seu produtor (ou equipe de desenvolvimento), o índice típico de remoção de defeitos antes de liberação no EUA é de 85%. Os melhores produtores estão no patamar de 95-97%. Dos defeitos após liberação, 30% são detectados após 1 ano de uso do produto e os restantes até o 4º ano de uso. Estas estatísticas são do Capers Jones, guru americano na área de Engenharia de Software.