Engenharia de Software Professora Lucélia

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.

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.

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).

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).

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.

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.

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 Significant mechanical and software problems have plagued the automated baggage handling system. In tests of the system, bags were misloaded, were misrouted, or fell out of telecarts, causing the system to jam. Video cameras were installed at several known trouble spots to document problems, such as the following: The baggage system continued to unload bags even though they were jammed on the conveyor belt. This problem occurred because the photo eye at this location could not detect the pile of bags on the belt and hence could not signal the system to stop. The baggage system loaded bags into telecarts that were already full. Hence, some bags fell onto the tracks, again causing the telecarts to jam. This problem occurred because the system had lost track of which telecarts were loaded or unloaded during a previous jam. When the system came back on-line, it failed to show that the telecarts were loaded. The timing between the conveyor belts and the moving telecarts was not properly synchronized, causing bags to fall between the conveyor belt and the telecarts. The bags became wedged under the telecarts. This occurred because telecarts were bumping into each other near the load point.

Denver International Airport Significant mechanical and software problems have plagued the automated baggage handling system. In tests of the system, bags were misloaded, were misrouted, or fell out of telecarts, causing the system to jam. Video cameras were installed at several known trouble spots to document problems, such as the following: The baggage system continued to unload bags even though they were jammed on the conveyor belt. This problem occurred because the photo eye at this location could not detect the pile of bags on the belt and hence could not signal the system to stop. The baggage system loaded bags into telecarts that were already full. Hence, some bags fell onto the tracks, again causing the telecarts to jam. This problem occurred because the system had lost track of which telecarts were loaded or unloaded during a previous jam. When the system came back on-line, it failed to show that the telecarts were loaded. The timing between the conveyor belts and the moving telecarts was not properly synchronized, causing bags to fall between the conveyor belt and the telecarts. The bags became wedged under the telecarts. This occurred because telecarts were bumping into each other near the load point. 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.

Ariane 5

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.

Vôo inaugural em 4/junho/1996

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

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 a program segment for converting a floating point number to asigned 16 bit integer was executed with an input data value outside the range representable by a signed 16 bit integer. This run time error (out of range, overflow), which arose in both the active and the backup computers at about the same time, was detected and both computers shut themselves down. This resulted in the total loss of attitude control. The Ariane 5 turned uncontrollably and aerodynamic forces broke the vehicle apart. This breakup was detected by an on-board monitor which ignited the explosive charges to destroy the vehicle in the air. Ironia: o resultado desta conversão não era mais necessário após a decolagem...

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. a program segment for converting a floating point number to asigned 16 bit integer was executed with an input data value outside the range representable by a signed 16 bit integer. This run time error (out of range, overflow), which arose in both the active and the backup computers at about the same time, was detected and both computers shut themselves down. This resulted in the total loss of attitude control. The Ariane 5 turned uncontrollably and aerodynamic forces broke the vehicle apart. This breakup was detected by an on-board monitor which ignited the explosive charges to destroy the vehicle in the air. Ironia: o resultado desta conversão não era mais necessário após a decolagem...

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)}

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

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

Professora: Lucélia Oliveira (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

Professora: Lucélia Oliveira (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

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.

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

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?

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.

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.

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”).

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.

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.

Quanto mais tarde a detecção de um erro, mais cara é a sua correçã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

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

Sugestão para detecção de erros(continuação) O processo de revisão, realizado por colegas que mutuamente examinam e comentam o código e o projeto que eles criam, revela quatro dos cinco defeitos restantes (Fagan, 1986) Então, a qualidade do software pode aumentar consideravelmente somente com a revisão e dos trabalhos pelos colegas. Professora: Lucélia Oliveira

Qual tem sido o grau de sucesso dos sistemas atuais? 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