12. Crise de Software (cont.) 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. 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.
13. Crise de Software (cont.) Os problemas que originaram essa crise tinham relacionamento directo com a forma de trabalho das equipes. Eram problemas que não se limitavam a "sistemas que não funcionam correctamente", mas envolviam também dúvidas sobre como desenvolver e manter um volume crescente de software e ainda estar preparado para as futuras demandas. Essencialmente, eram sintomas provenientes do pouco entendimento dos requisitos por parte dos desenvolvedores, somados às técnicas e medidas pobres aplicadas sobre o processo e o produto, além dos poucos critérios de qualidade estabelecidos até então.
14. Crise de Software (cont.) Todos esses factores exigiram respostas e métodos que foram sendo aprimorados e documentados, dando início à área de Engenharia de Software. A busca por eficiência e competência revelou oportunidades, desafios e perigos que guiaram as tecnologias e apontaram novos rumos para as pesquisas.
15. Manifestação da crise Projectos estourando o orçamento; Projectos estourando o prazo; Software de baixa qualidade; Software muitas vezes não atingiam os requisitos; Projectos ingerenciaveis e o código difícil de manter; Má qualidade das teorias, metodologias e ferramentas de desenvolvimento utilizadas; Complexidade dos sistemas, dificuldade de formalização.
16. Soluções para a crise Análise Económica de Sistemas de Informações; O uso de melhores técnicas, métodos e ferramentas; Mais treinamento e educação: Actualmente não se investe o suficiente; A mudança de paradigma sobre o que é desenvolver software e como deveria ser feito; Trabalho em equipa; Combinar métodos para as fases do desenvolvimento; Ferramentas para automatizar esses mesmos métodos; Técnicas para assegurar a qualidade.
17. Crise de Software: Problemas Software inadequado; Cronogramas e custos imprecisos; Inexistência de dados históricos acerca do processo de desenvolvimento; Comunicação deficiente; Carência de conceitos quantitativos; Difícil manutenção.
18. A Crise de Software e a Idade Média Origens da Crise de Software, pode-se comparar com a história das outras indústrias. Por exemplo, antes da revolução industrial, os sapatos eram feitos de forma muito individual. Nesses tempos mais remotos, os sapateiros faziam cada par de sapatos de forma única para cada cliente, desde a obtenção da matéria prima até o produto final. As semelhanças com a indústria de software começam logo aí. Primeiro, porque as técnicas de desenvolvimento de software ainda não estão totalmente maduras e consolidadas. Afinal, a variedade de técnicas que surgiram nas últimas décadas é enorme, abrangendo ideias. Em segundo lugar, existe uma tendência muito forte em desenvolver software sem aproveitar o material produzido no passado. E para piorar, além de entregá-lo quase sempre mal documentado, a maior parte do conhecimento envolvido na sua construção permanece apenas na cabeça dos desenvolvedores.
19. Tipos de erros Sistemas desenvolvidos correctamente a partir de especificações erradas ou incompletas; Corte deliberado do escopo do projecto, em razão do estouro do prazo ou da verba do projecto; Sistemas desenvolvidos incorrectamente a partir de especificações corretas.
20. O impactocustos e prazos Grande mais de 50% de aumento em custos/prazos Moderado de 11 a 50% de aumento em custos/prazos Pequeno de 0 a 10% de aumento em custos/prazos
21. Causas de erros A- 44% Definição inicial falha B- 36% Novas aplicações desconhecidas dos usuário C-23% Projecto tão longo que os requisitos mudaram durante o desenvolvimento D- 22% Falhas/dificuldades em administrar a expectativa dos usuários E- 19% Dificuldade em envolver os usuários nos estágios iniciais do projecto F- 19% Dificuldade em empregar técnicas de prototípico ou desenvolvimento conjunto
22. Técnicas para superar A- 63% Projectar aplicações conjuntamente usuários e desenvolvedores B- 25% Usar prototípico para obter definição de requisitos C- 23% Buscar requisitos D- 23% Usar ferramentas de controle e gerência de projectos E- 16% Dizer “NÃO” às solicitações de alteração dos requisitos, depois de iniciado o projecto
23. Dificuldades Saber quais os requisitos; Ferramentas e linguagem; Tempo e custos; Prever falhas; Cuidar da manutenção e versões.
![Crise de Software Primeira Era -» 50-65 ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)