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.

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

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

4. Prover acesso por tópicos a base de conhecimento da engenharia de software (material de referência e matriz em cada AC).

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

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.

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

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.

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

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

Receita Federal dos Estados Unidos

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

(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

(continuação)

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.

• 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

Importância do Planejamento

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.

• 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

Quanto mais tarde a detecção de um erro, mais cara é a sua correção!

• 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

• 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

Sugestão para detecção de erros(continuação)

• 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

Qual tem sido o grau de sucesso dos sistemas atuais?