obs. : artigo escrito em maio de 2007
O Custo da Não Qualidade
Por: Fernando Palma
Maio, 2007
___________________________________________________
Entre o fim da década de cinqüenta e inicio de sessenta, começava a ser criado o conceito de testes de software. Finalmente, o exercício de testar começara a ser designado como um processo separado e não mais como uma simples revisão de código dos programadores como acontecia até então. Esta mudança provocou melhoras na qualidade dos sistemas que acataram a nova metodologia, mas não significou grande redução de custos para os projetos até então. Não significou porque essa prática isolada não era suficiente, ela dependia de outra que teve origem por volta da década de oitenta: a de testar o software desde o inicio. Hoje, está claro que a eficiência dos testes resulta na qualidade do sistema, na mesma proporção que, a boa distribuição deles resulta em menores custos. Embora pareça simples, existem muitos modelos de fabricas trabalhando como nos primórdios, e continuam sem entender o porquê dos prejuízos financeiros em seus projetos.
Assim que é implantado um processo de testes eficiente dentro de uma empresa, como avaliar o ganho que foi gerado? É possível perceber o bom desempenho, assim como realizar um cálculo do custo que foi poupado (ROI). O propósito deste artigo, entretanto, é que seja feito exatamente contrário: uma breve avaliação dos custos gerados por não testar o software de maneira eficaz e distribuída. Os exemplos a seguir são breves estudos de caso que introduzem esta análise:
Acidente: Therac 25
O Therac 25 era uma maquina controlada por um software, utilizada para o tratamento de câncer por radioterapia. Na época, foi uma grande evolução, pois gerenciava as dosagens adequadas a seus pacientes, poupando o trabalho mecânico.
A máquina operou durante seis meses e era considerada livre de defeitos, até dar-se o início a uma sucessão de falhas. Infelizmente, a descoberta foi tardia e irreparável. Devido a uma overdose causada pelo software, ocorreram quatro mortes (duas imediatas) e um total de quinze acidentes ocorridos em locais diferentes. Os episódios ocorreram entre 1985 e 1987, muitos pacientes estão com ferimentos permanentes até hoje.
O caso é considerado um dos mais graves em toda a história envolvendo falhas de computadores, justamente porque o prejuízo causado pelos erros foi incalculável: vidas humanas.
Muitas falhas foram indicadas como razão do ocorrido, após uma perícia do software. Entre elas destacam-se: a falta de gerenciamento da qualidade, documentação não apresentava explicação para os códigos de erros gerados e ausência de técnicas de testes, em construção, para simular usos imprevistos.
Mais informações: http://pt.wikipedia.org/wiki/Therac-25
Acidente : Ariane 5
O Arine 5 é um foguete espacial utilizado para levar satelites até suas orbitas, além de transportar outros tipos de cargas. Para seu lançamento, o veículo utiliza uma serie de softwares, entre eles, sistemas de referncia inercial e o software de controle.
Em Junho de 1996, a aeronave se auto destruiu um minuto após seu lançamento. As condições de tempo estavam favoráveis, mas houve um desvio na tragetória, seguido pela explosão do foguete. O prejuízo foi de qautrocentos milhões de dólares.
Uma comissão liderada pelo matemático francês Jacques-Louis Lions realizou uma investigação para apurar a origem do problema. Como resultado, foi encontrada uma cadeia de falhas iniciais que incidiram em uma anomalia no software controlador, exatamente no instante que este executava a conversão de dados de um número de 64 bits em ponto flutuante para um inteiro de 16 bits.
O código não estava protegido contra o tipo de exceção que foi levantada.
Mais informações: http://www.sbmac.org.br/bol/bol-2/artigos/ariane5.html
Intel
Em 1994, ouve um erro de vírgula flutuante no Pentium. A correção custou à empresa 475 milhões de dólares.
O erro teria um custo insignificante se descoberto na fase de especificação.
(Computer Science, Springer Verlag – 1995)
Motorola
A empresa PrimeCo Personal Comunications cancelou um contrato de 500 milhões de dólares com a Motorola por causa de falhas.
(Wall Street Journal – 24/02/98)
Diversos outros casos poderiam ser utilizados para ilustrar, como um erro de software que paralisou as linhas as telefônicas de quase toda a costa leste dos EUA, sondas espaciais da NASA perdidas no espaço, colapsos em sistemas de matrículas, sistemas governamentais. Mas, para resumir, nada melhor do que uma estatística demonstrada no livro de Alexandre Bartie, 2002, Garantia da Qualidade de Software, envolvendo estudos americanos:
-->Mais de 30% dos Projetos são cancelados antes de serem finalizados.
-->Mais de 70% dos Projetos falham nas entregas das funcionalidades esperadas.
-->Os custos extrapolam mais de 180% os valores originalmente previstos
-->Os prazos excedem em 200% os cronogramas originais
Obs: Trecho retirado da página 06, Elsevier Editora Ltda, 2002
Depois deste breve histórico de bugs e os dados estatísticos, fica fácil compreender a imagem a seguir, que representa um gráfico bastante conhecido entre profissionais de Qualidade:
O Custo médio de um erro (em dolar)
(para ampliar, basta clicar sob a imagem)
A ilustração acompanha o custo de um defeito, demonstrando que ele cresce em uma proporção média de dez vezes a cada etapa de desenvolvimento. Sendo assim, um erro encontrado em especificação custa dez centavos de dólar para ser corrigido. Já para o caso do mesmo erro ser esquecido e detectado em fase de implantação, o custo aproximar-se-ia de cem dólares.
Os computadores e softwares tendem a tornarem-se mais complexos, em uma velocidade exponencialmente crescente. A segurança e qualidade somente serão possíveis, caso o ritmo dos critérios de avaliação, de auditorias e testes acompanhem esta evolução. Mesmo para os pequenos sistemas, existe uma infinidade de cenários e caminhos nas regras de negócio. O fatal de tanta complexidade, ao contrário do que se imagina, está nos pequenos detalhes dos softwares. Os bugs dos caminhos improváveis, quase invisíveis. Justamente os defeitos pequenos e esquecidos, são os mais traiçoeiros e causadores de prejuízos. Mas isso já é assunto para o próximo artigo.
Fernando Palma
Referências:
Bartie Alexandre, Garantia da Qualidade de Software, São Paulo: Elsevier Editora Ltda, 2002.
paginas.fe.up.pt/~jpf/teach/TQS0506
www.lac.inpe.br/~vijay/download/ELAC2007/Vijay_Testes_De_Software_E_Avaliacao_De_Desempenho_PARTE_II.pdf
http://pt.wikipedia.org/
.png)
0 comentários: