Engenharia de Software

1. Engenharia de Software Professora Lucélia

2. IEEE Computer Society • Aproximadamente 100.000 membros. • Organização de suporte aos profissionais da computação, provendo informação técnica, serviços a comunidade e personalizados. • Fundada em 1946. • A maior das 39 sociedades do IEEE. • Dedicada ao avanço teórico, prático e aplicação de computadores e tecnologia da informação. • Aproximadamente 40% dos membros vive e trabalha fora dos EUA, fomentando a comunicação internacional, a cooperação e a troca de informação. • Tem um escritório central de serviços em Tokyo, Japão; um escritório de publicação em Los Alamitos, California; e a sede em Washington.

3. The Guide to the SWEBOK • Não é o conhecimento em si, mas uma síntese e uma referência ao material disponível em diversas publicações que se complementam para formar o corpo de conhecimento. • Descreve que parte do conhecimento é geralmente aceita pela comunidade profissional. • Organiza o conhecimento. • Provê acesso por tópicos ao conhecimento. • Patrocinado por empresas como: Rational (IBM), SAP, Boeing, entre outras.

4. Objetivos • Promover uma visão consistente da engenharia de software em todo o mundo (500 revisores de 42 países na fase Stoneman, versão Trial, e 120 revisores de 21 países na fase Ironman, versão 2004). • Definir as fronteiras de atuação da engenharia de software e as áreas de interseção com outras disciplinas como: engenharia da computação, ciência da computação, gestão de negócios, matemática, gerenciamento de projetos, gestão da qualidade, ergonomia (acessibilidade e usabilidade) e engenharia de sistemas (SWEBOK, capítulo 12).

5. Objetivos (Continuação) • Caracterizar o conteúdo da disciplina engenharia de software, subdividindo-o hierarquicamente em áreas de conhecimento (o Apêndice A descreve como as AC devem ser organizadas). • Prover acesso por tópicos a base de conhecimento da engenharia de software (material de referência e matriz em cada AC). • Fornecer um alicerce para desenvolvimento do currículo, certificação individual e licenciamento de material (conhecimento geralmente aceito: aplica-se a maioria dos projetos e das equipes pelo consenso e pela efetividade).

6. Uma Crise no horizonte • A industria de Software tem tido uma “crise” que a acompanha há quase 30 anos. • Problemas não se limitam ao software que não funciona adequadamente, mas abrange: • desenvolvimento, testes, manutenção, suprimento, etc.

7. Therac-25 • Equipamento de Radioterapia. • Entre 1985 e 1987 se envolveu em 6 acidentes, causando mortes por overdoses de radiação. • Software foi adaptado de uma antecessora, Therac-6: • falhas por falta de testes integrados • falta de documentação • página 382 do Pfleeger.

8. Denver International Airport • Custo do projeto: US$ 4.9 bilhões • 100 mil passageiros por dia • 1.200 vôos • 53 milhas quadradas • 94 portões de embarque e desembarque • 6 pistas de pouso / decolagem

9. Denver International Airport • Problemas: • Erros no sistema automático de transporte de bagagens: • Atraso na abertura do aeroporto com custo total estimado em US$360 Milhões • 86 milhões para consertar o sistema.

10. Ariane 5

11. Ariane 5 • Projeto da Agência Espacial Européia que custou: • 10 anos. • US$ 8 Bilhões. • Capacidade 6 toneladas. • Garante supremacia européia no espaço.

12. Vôo inaugural em 4/junho/1996

13. Resultado • Explosão 40 segundos após a decolagem. • Destruição do foguete e carga avaliada em US$ 500 milhões.

14. O que aconteceu? • Fato: o veículo detonou suas cargas explosivas de autodestruição e explodiu no ar. Por que? • Porque ele estava se quebrando devido às forças aerodinâmicas. Mas por que? • O foguete tinha perdido o controle de direção (atitude). O que causou isso? • Os computadores principal e back-up deram shut-down ao mesmo tempo

15. O que aconteceu? (II) • Por que o Shut-down? Ocorrera um run time error (out of range, overflow , ou outro) e ambos computadores se desligaram. De onde veio este erro? • Um programa que convertia um valor em ponto flutuante para um inteiro de 16 bits recebeu como entrada um valor que estava fora da faixa permitida.

16. Especificamente: O que faltou? strict precondition 1: { Set."x"=FLPT and Set."y"=INT16 and -32768 <= x <= +32767 } program code: y := int(x); postcondition: {Set."x"=FLPT and Set."y"=INT16 and y=int(x)}

17. Ironia... • O resultado desta conversão não era mais necessário após a decolagem...

18. Receita Federal dos Estados Unidos No começo da década de 80, a Receita Federal dos Estados Unidos (IRS) contratou a empresa Sperry Corporation para construir um sistema automatizado de processamento de formulários de impostos federais. De acordo com o jornal americano Washington Post, “o sistema se mostrou inadequado à carga de trabalho, custou cerca de duas vezes o esperado e deve ser logo substituído” (Sawyer, 1985) Professora: Lucélia Oliveira

19. (continuação) Em 1985, foi necessário adicionar US$ 90 milhões aos US$ 103 milhões que já haviam sido pagos pelos equipamentos da Sperry. Além disso o problema acarretou o atraso das restituições da IRS aos contribuintes, o que forçou a IRS a pagar US$ 40,2 milhões em juros e US$ 23 milhões em horas extras para os funcionários que tentaram compensar o estrago. Professora: Lucélia Oliveira

20. (continuação) Em 1996, a situação não havia melhorado. O jornal americano Los Angeles Times publicou, em 29 de março daquele ano, que ainda não havia nenhum plano para a modernização dos computadores da IRS, somente um relatório com 6.000 páginas. O congressista americano Jim Lighfoot chamou o projeto de “um fiasco de quatro bilhões de dólares que está afundando por falta de planejamento ” Professora: Lucélia Oliveira

21. Quais são os problemas? • A sofisticação do software ultrapassou nossa capacidade de construção. • Nossa capacidade de construir programas não acompanha a demanda por novos programas. • Nossa capacidade de manter programas é ameaçada por projetos ruins.

22. Importância do Planejamento • Em 1994, uma pesquisa realizada pelo The Standish Group demonstrava que nos Estados Unidos apenas cerca de 19% do total de projetos de software iniciados eram terminados com sucesso. • 52,2% dos projetos eram concluídos com atrasos e acima dos orçamentos. • 31,1% eram cancelados. Professora: Lucélia Oliveira

23. Perguntas que a Engenharia de Software quer responder: • Porque demora tanto para concluir um projeto (não cumprimos prazos)? • Porque custa tanto (uma ordem de magnitude a mais)? • Porque não descobrimos os erros antes de entregar o software ao cliente? • Porque temos dificuldade de medir o progresso enquanto o software está sendo desenvolvido?

24. Causas óbvias • Não dedicamos tempo para coletar dados sobre o desenvolvimento do software - resulta em estimativas “a olho”. • Comunicação entre o cliente e o desenvolvedor é muito fraca. • Falta de testes sistemáticos e completos.

25. Causas menos óbvias • O Software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico. • Profissionais recebem pouco treinamento formal. • Falta investimento (em ES). • Falta métodos e automação.

26. Mitos do Software - Administrativos • Um manual oferece tudo que se precisa saber. • Computadores de última geração solucionam problemas de desenvolvimento. • Se estamos atrasados, basta adicionar programadores e tirar o atraso (chamado “conceito de hordas de mongois”).

27. Mitos do Software - do Cliente • Uma declaração geral é suficiente para começar a escrever programas. • Mudanças podem ser facilmente acomodadas em um projeto.

28. Mitos do Software - do Profissional • Um programa está terminado ao funcionar. • Quanto mais cedo escrever o código, mais rápido terminarei o programa. • Só posso avaliar a qualidade de um programa em funcionamento. • A única coisa a ser entregue em um projeto é o programa funcionando.

29. Quantomaistarde a detecção de um erro, maiscara é a suacorreção! • Segundo Pfleeger, o custo para a correção de um erro cometido em um projeto durante a etapa inicial da análise é um décimo do custo para corrigir um erro semelhante depois que o sistema foi entregue ao cliente. • Metade dos custos de correção de defeitos encontrados durante a fase de testes e manutenção vem de erros cometidos no início de vida do sistema. Professora: Lucélia Oliveira

30. Sugestão para detecção de erros • Muitos estudantes estão acostumados a desenvolver e testar o seu próprio software; • Seus testes podem ser menos efetivos do que pensam; • Fagan, estudou o modo como os defeitos têm sido detectados: ele descobriu que executar um programa com dados de teste revela somente cerca de um quinto dos defeitos cometidos durante o desenvolvimento do sistema. Professora: Lucélia Oliveira

31. Sugestãoparadetecção de erros(continuação) • O processo de revisão, realizadoporcolegasquemutuamenteexaminam e comentam o código e o projetoqueelescriam, revelaquatro dos cincodefeitosrestantes (Fagan, 1986) • Então, a qualidade do software podeaumentarconsideravelmentesomente com a revisão e dos trabalhospeloscolegas. Professora: Lucélia Oliveira

32. Qual tem sido o grau de sucesso dos sistemasatuais? • Pense como era a vida das pessoas antes dos processadores de texto, das planilhas eletrônicas, do correio eletrônico, da telefonia sofisticada. • Os produtos de softwares têm apoiado avanços na medicina, na agricultura, nos transportes, etc… • Além de nos permitir realizar as coisas nunca feitas antes, como microcirurgias, educação, multimídia e robótica. Professora: Lucélia Oliveira