O Custo da Não Qualidade

06:35 , , , 14 Comments

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/

14 comentários:

  1. Anônimo9 de maio de 2007 às 11:19

    Você falou dos custos da não qualidade. Fiquei curioso pra saber o quanto se deveria ter investido para garantir que eles não ocorressem.

    Ao meu ver nenhum processo de testes existente hoje garante sistemas 100% livres de erros.

    Então sinto que faltou uma análise de quanto um processo de testes encarece um sistema e em quanto ele diminui o risco de um erro aparecer quando o sistema estiver em produção...

    ResponderExcluir
  2. Fernando Palma9 de maio de 2007 às 11:58

    Ok, Ivan!

    Em meu ultimo artigo fiz uma demonstração de como pode ser adotado um bom processo de testes com o mínimo de investimento possível (apenas um profissional de testes). Deste ponto em diante, quanto mais especialistas, ferramentas e quantidade de testes existirem, menor será o risco de haver falhas. E você está certo, por mais que um sistema seja testado, ele nunca estará completamente livre de erros, os testes apenas diminuem o máximo possível essa possibilidade.

    Depende ao bom senso para determinar a medida necessária. Mas, se existir menos do que o mínimo que propus lá (artigo II), será quase certo que haverá problemas.

    O objetivo deste artigo foi demonstrar que não seguir boas prática resulta fatalmente em prejuízos, independente do custo necessário para segui-las. Já a estrutura de testes que será escolhida pela empresa, deve passar por uma avaliação custo x benefício como você mencionou, englobando principalmente o porte e finalidade do sistema. Mas repito, boas práticas não devem passar por avaliação custo x benefício, devem ser seguidas.

    Realmente, pode ser uma boa proposta fazer um levantamento de custos envolvidos com equipes de testes de tamanhos diferentes e avaliar a recompensa para cada caso (uma espécie de exemplos). Vou guardar sua sugestão!

    Obrigado pela visita e comentário!

    ResponderExcluir
  3. Anônimo9 de maio de 2007 às 15:29

    Você pode confirmar o inicio (anos) das técnicas de testes de Sfw ?

    ResponderExcluir
  4. Unknown9 de maio de 2007 às 18:12

    Este modelo de custos esta baseado no ciclo de vida de engenharia faseada.

    No ciclo de vida da engenharia simultanea onde vc faz Especificação, Design, Codificação, Homologação e Implantação de incrementos de produto que representem 4% do projeto total, vc vai ter tipo de grafico totalmente diferente.

    A Toyota e outras empresas fazem as pessoas responsaveis pelo trabalho os responsaveis pela qualidade tambem.

    Custa muito caro fazer errado, testar e depois concertar. Sai muito mais barato criar os testes, e criar o produto que passe nos testes necesarios, esta inversão do processo faz toda a diferença.

    Abraços,
    Juan.

    ResponderExcluir
  5. Fernando Palma10 de maio de 2007 às 04:49

    Anônimo,

    Testes existem desde que o desenvolvimento de software existe, mas até 1957 os testes de software eram considerados uma parte do debugging. A partir daí, começou a ganhar mais valor como um conceito a parte.

    Em 1979 foi escrito o Clássico The Art of Software Testing que acrescentou muito ao conceito de Testes, e a partir de 1980 teve início à boa pratica dos testadores participarem do projeto desde o inicio.

    Você pode encontrar um histórico mais detalhado no Livro de Alexandre Bartie, ou neste link:

    http://www.cs.cmu.edu/~luluo/Courses/17939Report.pdf

    Até mais e agradeço sua visita!

    Fernando Palma

    ResponderExcluir
  6. Anônimo10 de maio de 2007 às 05:14

    Arigo bem interessante. Ficou claro pra mima importancia de testar cedo.

    Abraço,
    Henrique Oliveira.

    ResponderExcluir
  7. Unknown10 de maio de 2007 às 06:26

    Este comentário foi removido por um administrador do blog.

    ResponderExcluir
  8. Fernando Palma10 de maio de 2007 às 06:32

    Juan,

    Concordo com você, o fato de que fazer e corrigir depois custa mais caro. O objetivo do artigo foi mostrar isso. A boa prática de testes de software é caracterizada justamente por validar e verificar a especificação antes de construir. Ou seja, considerar a fase de testes desde a especificação e não como uma fase separada. Isso é possível possibilitando a interação dos profissionais de Qualidade com os de análise e produção desde o inicio do projeto, em paralelo (veja o artigo II). Acho que essas características se aproximam dos conceitos de Engenharia Simultânea, sim? Me corrija se eu estiver enganado.

    Em breve, irei apresentar um conceito de Programação Orientada a Testes, onde os testes de código são escritos antes e o programador deve desenvolver baseado neles. Acho que tem haver com que mencionou. Mas em desenvolvimento de software, deve existir profissionais separados para produzir, escrever e arquitetar testes. A criatividade para criar regras de sistemas é diferente da criatividade de criar testes. São profissionais com perfis diferentes.

    O espaço está aberto caso queira trazer mais exemplos da metodologia de engenharia simultânea, principalmente na área de tecnologia. Assim, eu posso melhorar o conhecimento nos conceitos e fazemos novos comparativos com o processo de testes.

    Agradeço a visita e aguardo seu retorno!

    Até mais,
    Fernando Palma.

    ResponderExcluir
  9. Fernando Palma10 de maio de 2007 às 06:33

    Obs: comentário excluido por erros de digitação.

    ResponderExcluir
  10. Marcelo Cantalice Dias16 de maio de 2007 às 17:02

    Fernandão,
    É bom para mim ler o seu blog, pois apesar de não ser bem a minha àrea eu tenho que estar sempre antenado!
    Abração

    ResponderExcluir
  11. Klatuu o embuçado18 de junho de 2007 às 08:29

    Interessante este blog, fora do comum.

    ResponderExcluir
  12. Guido Potier23 de outubro de 2007 às 08:45

    Caro Fernando...
    Como oportunidade de melhoria em seu blog, poderia haver um rss feed... o que achas?

    ResponderExcluir
  13. Unknown1 de julho de 2008 às 09:38

    Cara,

    Tb sou fa de testes. Acredito que podem agregar valor ao produto e evitar prejuizos para a empresa e o cliente.

    Passei um e-mail tocando no assunto das ferramentas de apoio a contrução automizada de testes e documentação.

    Espero um retorno.

    Leandro Brito
    FIB

    ResponderExcluir
  14. Denis30 de dezembro de 2009 às 10:15

    Parabéns pelo seu blog! Como podemos ver por este artigo, a fase de testes é uma fase importante que muitas vezes não recebe a atenção que deveria. E é bastante gratificante encontrar um blog especializado no assunto.

    Mais uma vez, parabéns pelo blog!

    ResponderExcluir

Assinar: Postar comentários (Atom)