Revisão e Nivelamento

 O que é Engenharia de Software? “A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software. Em outras palavras, é a aplicação de Engenharia a Software” (IEEE) “A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software. Em outras palavras, é a aplicação de Engenharia a Software” (IEEE)

 Conferência da OTAN (NATO) 1968 e 1969: Fonte: / 1968: Alemanha1969: Itália

Fonte:

 1955: ◦ 1ª empresa de software independente ( CUC - Computer Usage Corporation ) ◦ Fundada por dois ex-funcionários da IBM;  Até o início da década de 1960, os computadores e softwares ◦ estavam confinados a ambientes governamentais e acadêmicos; ◦ tinham um propósito muito específico, geralmente científico; ◦ eram criados por especialistas, para especialistas; ◦ tinham o foco voltado principalmente para o hardware.

Potencial do Hardware Custo do Hardware Expectativas e Demanda da Sociedade Complexidade do Software Computadores de Propósito Geral Inexperiência dos Programadores

Fonte:

60s

 Muitos softwares não entregues;  Alguns entregues: ◦ Além do prazo; ◦ Acima do custo; ◦ Com baixa qualidade;  Pouquíssimos atendiam as expectativas;

Fonte: Information and decision support systems as a challenge for new democracies Nikitas A. Assimakopoulos. Em: Diffusion of new technologies in the post-communist world

Sucesso16%27%26%28%34%29%35%32% Falhou53%33%46%49%51%53%46%44% Cancelado31%40%28%23%15%18%19%24% Tabela adaptada de Falhou: foi entregue com menos requisitos, fora do prazo e com custo acima do estimado; Cancelado: cancelado antes de finalizado, ou entregue, mas nunca utilizado. CHAOS Report (Standish Group) Contras: o relatório não leva em consideração a satisfação dos clientes, riscos e medidas de qualidades.

Adaptado de: caos-report2009_2.jpg Cancelado FalhouSucesso

Fonte:

 Os principais fatores que contribuíram para o cancelamento dos projetos foram: ◦ Requisitos Incompletos: 13.1% ◦ Falta de envolvimento do usuário: 12.4% ◦ Falta de recursos: 10.6% ◦ Expectativas não realistas 9.9% ◦ Falta de apoio executivo: 9.3% ◦ Mudanças de requisitos: 8.7% ◦ Falta de planejamento: 8.1% ◦ Não precisa mais daquilo: 7.5% ◦ Falta de gestão da TI: 6.2% ◦ Analfabetismo tecnológico: 4.3% ◦ Outros: 9.9% Fonte: CHAOS Report (2009); Retirado de:

 Os principais fatores que contribuíram para a falha dos projetos foram: ◦ Falta de insumos do usuário: 12.8% ◦ Requisitos & Especificações incompletas: 12.3% ◦ Mudanças nos requisitos & especificações: 11.8% ◦ Falta de apoio executivo: 7.5% ◦ Ambiente tecnológico incompleto: 7.0% ◦ Falta de recursos: 6.4% ◦ Expectativas irrealistas: 5.9% ◦ Objetivos nebulosos: 5.3% ◦ Ciclos (tempo) irrealistas: 4.3% ◦ Novas tecnologias: 3.7% ◦ Outras: 23% Fonte: CHAOS Report (2009); Retirado de:

 Os principais fatores que ajudaram no sucesso dos projetos foram: ◦ Envolvimento do usuário: 15.9% ◦ Apoio executivo: 13.9% ◦ Declaração de requisitos clara e limpa: 13% ◦ Planejamento apropriado: 9.6% ◦ Expectativas realistas: 8.2% ◦ Milestones pequenos: 7.7% ◦ Equipe competente: 7.2% ◦ Propriedade: 5.3% ◦ Visão e objetivos claros: 2.9% ◦ Trabalho duro e equipe focada: 2.4% ◦ Outros: 13.9% Fonte: CHAOS Report (2009); Retirado de:

 Em primeiro lugar, devemos saber onde queremos chegar.

 Que os softwares ◦ cumpram o custo estabelecido; ◦ sejam entregues dentro do prazo previsto; ◦ resolvam os problemas que motivaram sua criação; ◦ tenham alta qualidade (o que é isso)?

 O software que satisfaz os requisitos solicitados pelo usuário. Deve ser fácil de manter, ter bom desempenho, ser confiável e fácil de usar.  Alguns atributos de qualidade: ◦ Manutenibilidade: o software deve ser escrito de modo que possa evoluir para atender às necessidades de mudança dos clientes; ◦ Eficiência: o software não deve desperdiçar os recursos do sistema; ◦ Usabilidade: o software deve ser fácil de usar pelos usuários para os quais ele foi projetado; ◦ Confiabilidade: deve ser seguro, não deve causar danos no caso de falhas;

 Em seguida, devemos conhecer um pouco mais sobre: ◦ O que aprendemos nas últimas décadas;  Os erros que cometemos (para não repeti-los);  Os acertos (para procurar repeti-los). ◦ Conceitos de Engenharia de Software.

 IEEE STD , IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990 IEEE STD  Relatórios das Conferências NATO.  The Computer Boys.  Information and decision support systems as a challenge for new democracies Nikitas A. Assimakopoulos. Em: Diffusion of new technologies in the post-communist world &ots=Hj27NVm3ZX&dq=%22software%20crisis%22%20abandoned%2 019%25%20never%20used%2047%25&hl=pt- BR&pg=PP1#v=onepage&q=%22software%20crisis%22%20abandone d%2019%25%20never%20used%2047%25&f=false

 dowsLiveWriter/ChaosReport2009novasinformae svelhosprobl_10E/caos-report2009_2.jpg dowsLiveWriter/ChaosReport2009novasinformae svelhosprobl_10E/caos-report2009_2.jpg  profissionais-qualificados-em-ti-repete- cenario-da-era-industrial profissionais-qualificados-em-ti-repete- cenario-da-era-industrial  Engenharia de Software no IME (Marco Aurélio Gerosa) ◦  Engenharia de Software no INPE (Prado) ◦