O custo da não qualidade
Autor: Andressa Flávia | Publicado: 2008-04-27T19:11:00-03:00

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, mas não idealizar um cálculo do custo que foi poupado. Percebendo-se essa inviabilidade, o propósito é 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 25O 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 5O 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      IntelEm 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)                  MotorolaA 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