Básico 3 - Novas Demandas por Software
A disciplina de Engenharia de Software surgiu como uma ajuda para muitos dos problemas enfrentados pelas equipes de desenvolvimento, mas está longe de ser a cura milagrosa que muitos esperavam. A demanda por software nunca foi tão grande quanto agora, e alguns motivos para isso já são conhecidos:
- A redução dos custos dos computadores e peças de hardware favoreceram todas as classes sociais e ajudaram a reduzir os índices de exclusão digital. Embora ainda existam fortes desigualdades e extrema pobreza no planeta, os computadores estão mais acessíveis do que nunca;
- Os microcomputadores (incluindo palmtops, celulares e outros aparelhos móveis) passaram a ser utilizados por inúmeras áreas de atuação humana e tornaram-se ferramentas imprescindíveis para o sucesso de cada uma delas. Alguns exemplos são as áreas de educação, indústria, finanças, saúde, esportes e diversão, que estão cada vez mais dependentes de soluções tecnológicas;
- A integração promovida pela Internet abriu grandes possibilidades de negócio e parcerias entre as empresas. Além disso, soluções pessoais para o uso do computador também precisam de especial atenção.
O efeito de todos esses fatores sobre a produção de software exige uma quantidade de profissionais qualificados que ainda estamos longe de adquirir. De fato, podemos observar que o desenvolvimento de software depende diretamente dessa disponibilidade de mão-de-obra, a qual só pode ser obtida com anos de treinamento e estudos nessa área. Por outro lado, as universidades precisariam de muito tempo para preparar o alto número de profissionais desejados pelo mercado, isso considerando que a demanda por software não vai continuar crescendo ainda mais rápido.
Afinal, será que não existiriam soluções alternativas para esse problema? Se não podemos contar com soluções mágicas na Engenharia de Software, precisamos articular um raciocínio que nos leve a uma solução viável. Segundo Barnes e Bollinger [Barnes+1991], existem três caminhos para lidarmos com recursos escassos: automação, um melhor planejamento e reuso. O primeiro caminho é o mais difícil. Apenas tarefas formalizadas podem ser automatizadas, o que requer um entendimento profundo da tarefa. Infelizmente, no desenvolvimento de software, um projeto não costuma ser igual a outro. Além disso, a formalização de tarefas tende a ser muito difícil, e, algumas vezes, chega a ser praticamente impossível automatizá-las completamente.
Dessa forma, só nos resta um melhor planejamento e reuso. Ambos são similares no sentido em que eles podem ser apoiados por uma organização e unidos da mesma forma que outras áreas da indústria fizeram com a invenção da linha de produção. Assim como montamos hardware a partir de peças e placas de circuitos pré-fabricados, por que não transportar esse ponto de vista para a construção de software?
Referências
[Barnes+1991] Bruce Barnes e Terry Bollinger. Making reuse cost effective. IEEE Software. Janeiro, 1991. 8(1):13-24.