Um certo professor da Universidade de Michigan, em um congresso de Software na Suíça, certa vez, utilizou a terminologia "Aflição Crônica" para representar a crise da indústria de software dos últimos trinta anos, e explicou: nós não atingimos o nível chamado crise de software. E complementou: crise é o limite máximo para a solução de um problema. Já aflição crônica, é algo que causa sofrimento e dura um longo período de tempo [1].

Como forma de reforçar a colocação acima, nada melhor que informações colhidas de uma recente pesquisa americana realizada pelo instituto Standish Group [2], utilizando uma amostra de 365 companhias entrevistadas, representando 8.380 aplicações, visando identificar:

• Âmbito das falhas de projetos de software;
• Os fatores principais que causam falhas nos projetos de software;
• Os ingredientes chave que podem reduzir falhas de projeto.

• Os EUA gastam US$ 250 bilhões por ano em desenvolvimento de aplicação de tecnologia da informação em aproximadamente 175 mil projetos.
• 31% de todos os projetos são cancelados antes do seu término, representando um desperdício da ordem de US$ 81 bilhões.
• 53% de todos os projetos chegam ao final tendo custado 189% do valor estimado, representando US$ 59 bilhões em custo adicional, atrasam em até 222% da estimativa original além de serem entregues com apenas 61% das características originalmente especificadas.
• 16% são entregues no prazo e dentro do orçamento.

Além destes dados estatísticos, talvez o aspecto mais importante da pesquisa tenha sido o levantamento dos fatores principais que tornam um projeto crítico, ou seja, aqueles projetos que extrapolam prazo, custo e que são entregues com a funcionalidade prejudicada. De acordo com os entrevistados, as razões principais que levam a problemas de projeto são identificadas na tabela abaixo:

Parece que a nossa inabilidade para trabalhar mais efetivamente com usuários e entender melhor as suas necessidades (requisitos) tem sido a causa principal das falhas de software. Esta deficiência, aliada à desordem de muitos ambientes de desenvolvimento, que muitas vezes buscam a melhoria da qualidade de seus produtos, mas não investem em processos básicos, como por exemplo, a documentação dos seus sistemas é que produz esta situação de caos.

Não temos mais para onde correr. Os negócios estão cada vez mais ágeis e precisam de respostas ainda mais velozes. Os modelos de qualidade CMM e SPICE, que apareceram em meados desta década pareciam a nossa tábua de salvação. Davam um caminho a seguir, como forma de obtermos a tão sonhada melhoria da qualidade. Enfoque no processo e não no produto. Fantástico!!!!

E aí, o que aconteceu? Nos trouxe algum benefício, mas não o que esperávamos, porque esses modelos nos dizem o que é preciso fazer para termos qualidade no produto desenvolvido, mas não nos conta como fazer. Eles não são a panacéia que vai resolver todos os nossos problemas.

Precisamos colocar o nosso trem em movimento. No início, a velocidade de locomoção é tão lenta, que parece que não vai engrenar. Mas depois de um certo tempo, não sabemos mais como é que fazemos para pará-lo.

Parece-me que o ingrediente principal para o nosso trem engrenar seja a disciplina. Precisamos de um processo consistente para seguir e disciplina para realizá-lo.

Para terminar este artigo gostaria de deixar uma pergunta: "O que o Desenvolvimento de Software e o Guaraná Antártica têm em comum?"

Se você respondeu, nada, eu acho que você acertou. Mas, e se a pergunta for: "O que o Desenvolvedor de Software e o Gênio da propaganda do Guaraná Antártica têm em comum?"

Se você não lembra da propaganda, vou refrescar a sua memória.

A menina abre a lata do refrigerante, um gênio sai da lata, e o diálogo segue mais ou menos assim:

A moça espantada exclama:

• Gênio?!

O gênio diz:

• Vamos mocinha, pode pedir o que quiser.

Ela pensa em (Tom Cruise, Arnold Schwarzenegger, Richard Gere,...) e pede:

• Eu quero um homem mais velho, que me entenda e perdoe todos os meus defeitos.

O gênio mais que depressa:

• Salta homem mais velho, experiente e que perdoa tudo...

Buumm (fumaça)

Ela decepcionada, murmura:

• Padre Lauro?!!! 

• Valeu em... ("gênio burro")

Escolhi esta metáfora, para fazer a todos nós, desenvolvedores de software, pensarmos se não estamos sendo o Gênio da estória para nossos usuários. Será que não estamos entregando o padre Lauro para eles???

Até o próximo volume!!!

REFERÊNCIAS BIBLIOGRÁFICAS

[1] PRESSMAN, Roger S. Software engineering: a pratictioner’s approach. 3. ed. New York: McGraw-Hill, 1995.

[2] STANDISH GROUP. Chaos. Pesquisa sobre o desenvolvimento de software e o panorama caótico da indústria de software dos dias de hoje. Disponível na Internet. www.standishgroup.com/chaos.html