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
1. 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 shutdown 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...
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
(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
(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