Conforme BONACIN(2004) destaca, não são raros os casos de fracasso em projetos de desenvolvimento de sistemas computacionais. Este problema parece ser mais evidente na produção de software do que em outras áreas. Mas porque isto é assim?
Bem, vejamos algumas palavras que usuários, gestores, acionistas e outros utilizam para dar origem a um sistema:
-“Preciso que você construa um programa que seja capaz de prever a tendência de consumo de nossos clientes, projetando as compras com os fornecedores e controle de estoques, integrado com a lista de consumidores inadimplentes e com o ERP da matriz. Ele deve aumentar em mais de três vezes o nosso faturamento. Será que em duas semanas podemos iniciar os testes?”
Embora este seja um diálogo fictício, na maioria das vezes é o que recebe o analista de sistemas / negócios. Inúmeros projetos de software foram construídos com uma especificação não muito mais detalhada do que o diálogo mencionado acima. A velha história do telefone sem fio se repete. Esta informação é passada de equipe a equipe. Detalhes vão se perdendo e no final o sistema é um produto muito diferente daquele que foi solicitado.
A industria de software tem sobrevivido por muitos anos baseada no esforço heróico de alguns profissionais! A grande maioria dos projetos, não são planejados e partem diretamente para o desenvolvimento do código.”Muitos projetos são entregues com um grande atraso, custando muito mais que o inicialmente previsto, sendo não confiáveis, difíceis de manter e/ou não tendo um desempenho satisfatório.”ROUILLER (2003). Há casos de projetos terem uma equipe grande, durarem por anos e serem abandonados após enorme custo e esforço.
Uma realidade muito diferente ocorre na industria automotiva. Um veículo é composto por milhares de peças, que são produzidas por diferentes fornecedores. Todas as peças são intercambiáveis, podendo ser substituídas facilmente por outras.
Mas porque então existe esta diferença tão gritante? Bem vamos considerar alguns prováveis motivos.
A industria mecânica possui uma engenharia apurada que vem sendo desenvolvida há séculos. É raro encontrar um mecânico de usinagem que não entenda uma especificação técnica de uma peça, bem como não saiba medir e apurar os resultados de seu trabalho. As especificações técnicas não permitem interpretações ambíguas. Existem grandes equipes especializadas na engenharia de um motor, sistema de transmissão, estrutura metálica, trem de rodagem, design, ergonomia, conforto e teste de veículos. Projetos de novos veículos levam em média 3 anos para serem desenvolvidos, o que na grande maioria das vezes, envolve apenas a adaptação de projetos anteriores, reaproveitando muitos conceitos.
Além disto, a industria automobilística não se dá ao luxo de customizar seus veículos ao gosto do freguês. Em alguns casos isto pode ser feito, mas não o ocorrerá pela montadora. Se um cliente desejar que seu carro popular 0 Km, com um motor de 65 cv seja substituído por um de 450cv, a montadora não o fará. Mais difícil ainda será customizar itens internos, que seguem um padrão para aquele modelo, podendo receber pequenas variações.
Na engenharia de software, este é um ponto crítico. Geralmente um carro é feito para ser utilizado por uma ou mais pessoas de uma família. Diferentemente, um software é desenvolvido para centenas / milhares de usuários, com cultura, gostos, interesses, objetivos, habilidades e porquê não dizer sonhos diferentes.
BONACIN(2004) destaca o problema de maneira muito enfática. “No desenvolvimento de sistemas para serem utilizados por grupos de pessoas, devem ser considerados não só os aspectos técnicos, mas também aspectos humanos e sociais”. De fato, algumas empresas desejam que seus funcionários utilizem um novo sistema caríssimo que alguém disse ser milagroso. Entretanto os funcionários não o consideram produtivo ou atrativo e com o tempo a solução é abandonada.
No dia-a-dia, é comum observarmos três práticas:
• Um sistema completamente novo que possui um processo de trabalho completamente diferente da empresa alvo, obrigando os funcionários a se adaptarem ao novo processo de trabalho.
• Um sistema altamente flexível que necessitará de uma equipe técnica para parametrização a um elevado custo e ainda sim causará mudanças nos processos de trabalho.
• Desenvolvimento de todo o sistema de acordo com o processo de trabalho atual, gerando elevado custo de desenvolvimento e manutenção.
Pode-se observar o impacto que os projetos de software causam em uma empresa. Embora estes projetos sejam considerados estratégicos e possuam muitos patrocinadores internos e externos o mesmo precisa ser avaliado de uma forma adequada. Como BONACIN(2004) destaca, o software deve ser avaliado pela capacidade de aprimorar o contexto organizacional.
Para VEGA(2004) os principais problemas relacionados aos softwares atuais são:
• Dificuldade na manutenção.
• Dificuldade na extensão de funcionalidades.
• Baixa qualidade.
• Processo de construção precário.
• Dificuldade em integrações.
• Baixo desempenho.
• Necessidade do usuário mutante.
Inúmeras instituições ao redor do mundo têm realizado esforços para aperfeiçoar a disciplina de engenharia de software e seus produtos. O IEEE tem patrocinado a composição e revisão do SWEBOK que é um documento que tem por objetivo servir de referência para a comunidade de engenharia de software. Conforme o próprio documento salienta, este manual não é completo, e exigirá que os interessados conheçam muito mais coisas sobre ciências da computação, gerenciamento de projetos e engenharia de sistemas do que material nele contido. O objetivo deste manual é estabelecer uma normalização daquilo que se pode ser chamado de engenharia de software. SWEBOK(2004)
