Crise do software
A crise do software foi um termo utilizado nos anos 1970, quando a engenharia de software era praticamente inexistente. O termo expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados.
História
[editar | editar código]A noção da crise do software emergiu no final dos anos 60. O termo "crise do software" foi cunhado por alguns participante da primeira Conferência de Engenharia de Software da OTAN em 1968 em Garmisch, Alemanha.[1][2] Edsger Dijkstra, na apresentação feita em 1972 na Association for Computing Machinery ao ser laureado com o Prêmio Turing, intitulada The Humble Programmer (EWD340) e publicada no periódico Communications of the ACM faz menção ao mesmo problema.[3]
The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
– Edsger Dijkstra , ''The Humble Programmer (EWD340) , Communications of the ACM
Causas
[editar | editar código]As causas da crise do software estão ligadas a complexidade do processo de software e a relativa imaturidade da engenharia de software como profissão. A crise se manifesta de várias formas:
- Projetos estourando o orçamento;
- Projetos estourando o prazo;
- Software de baixa qualidade;
- Software muitas vezes não satisfaz os requisitos;
- Projetos ingerenciáveis e código difícil de manter;
A maior parte dos projetos continuam com estes problemas ainda na atualidade, assim pode se dizer que a crise continua vigente ainda na atualidade.[4]
Soluções
[editar | editar código]As soluções para a crise de software:
- Análise econômica de sistemas de informação;
- O uso de melhores técnicas, métodos e ferramentas;
- Interesse do governo em treinamentos e educação[carece de fontes];
- A mudança de paradigma sobre o que é desenvolver software e como deveria ser feito;
Ver também
[editar | editar código]Referências
- ↑ «NATO Software Engineering Conference 1968». Consultado em 26 de abril de 2017
- ↑ «Report on a conference sponsored by the NATO SCIENCE COMMITTEE Garmisch, Germany, 7th to 11th October 1968» (PDF). Consultado em 26 de abril de 2017
- ↑ «E.W.Dijkstra Archive: The Humble Programmer (EWD 340)». Consultado em 26 de abril de 2017
- ↑ «Chaos Manifesto: The Laws of CHAOS and the CHAOS 100 Best PM Practices» (PDF). 2011. Consultado em 11 de junho de 2015. Arquivado do original (PDF) em 1 de maio de 2015.
Ligações externas
[editar | editar código]- Edsger Dijkstra: The Humble Programmer (arquivo PDF, 473kB)
- Brian Randell: The NATO Software Engineering Conferences
- Markus Bautsch: Cycles of Software Crises em: ENISA Quarterly on Secure Software (PDF file; 1,86MB)
- Hoare 1996, "How Did Software Get So Reliable Without Proof?"