Aula 123

Engenharia de
Software
Profª Joslaine Cristina Jeske de Freitas
Roteiro
 Ementa
 Objetivos
 Agenda de aulas
 Avaliações
 Visão Geral da Engenharia de Software

Ementa
 Plano de curso
2011-1
Ementa
 Visão geral da engenharia de software, suas
subáreas, objetivos, desafios e propostas
correntes.
 Dificuldades essenciais e acidentais da
Engenharia de Software.
 Caracterização de software (produto).
Ementa
 Processos do Ciclo de
 Vida do software.
 Gerência de projetos de software.
Ementa
 Garantia da Qualidade de software.
 Gerência de configuração de software.
 Paradigmas de Desenvolvimento e
Manutenção de software.
Ementa
 Teste de software.
 Ferramentas de apoio à Engenharia de
Software (CASE).
 Considerações práticas: métodos e técnicas
para Engenharia de Software.
Roteiro
 Ementa
 Objetivos
 Agenda de aulas
 Avaliações

Objetivos
 Plano de curso
2011-1
Objetivos
 Capacitar o aluno a lidar adequadamente
com os conceitos da Engenharia de
Software e da Análise de Sistemas.
Roteiro
 Ementa
 Objetivos
 Agenda de aulas
 Avaliações

Agenda de Aulas
 Plano de curso
2011-1
Agenda de Aulas
 Horário:
◦ Segunda-feira: 15:30 as 18:00 ( de 15 em 15
dias)
◦ Quarta-feira: 9:30 as 11:10
◦
 ou
◦
◦ Segunda-feira: 15:30 as 18:00 ( de 15 em 15
dias)
◦ Quarta-feira: 9:30 as 11:10
◦ Quinta-feira: 15:30 as 17:10
◦

◦
Roteiro
 Ementa
 Objetivos
 Agenda de aulas
 Avaliações

Avaliações
 Plano de curso
2011-1
Avaliações
 3 provas e 1 seminário.
 Sendo a média final obtida pela média
aritmética simples das 4 notas
Provas
 Datas a serem discutidas
 O conteúdo das provas não é cumulativo
 Provas serão individuais e sem consulta
Seminário
 Instruções
Roteiro
 Ementa
 Objetivos
 Agenda de aulas
 Avaliações

Roteiro
 Ementa
 Objetivos
 Agenda de aulas
 Avaliações
 Seminários

Visão geral da
engenharia de
software
 Pfleeger
cap. 1
Introdução
 Software no dia a dia – facilita nossa tarefa.
 Exemplos: - torradeira, microondas,
fornecimento de energia elétrica, bancos –
pagamento eletrônico.
 O software está presente em todos os
aspectos de nossa vida.
 Boas práticas de engenharia de software
devem assegurar que o software tenha
uma contribuição positiva em nossas
vidas.

Engenharia de Software 22
O que é engenharia de
software
 Utilizar conhecimento sobre computadores e
computação par ajudar a resolver
problemas.

Resolvendo problemas
 A maioria dos problemas é grande e,
algumas vezes, difícil de se resolver. Sendo
assim, devemos começar a investigação
analisando o problema, isto é, dividindo-o
em partes que sejamos capazes de
entender e manipular.

Processo de análise
Problema
Subproblema Subproblema 2 Subproblema4

1 Subproblema
3
O processo de síntese
Solução 1 Solução 2 Solução 4
Solução 3
SOLUÇÃO
Resolvendo problemas
 Método ou técnica: é um procedimento
formal para produzir algum resultado.
Ferramenta: é um instrumento ou sistema
automatizado utilizado para realizar uma
tarefa da melhor maneira.
Procedimento: é como uma receita – a
combinação de ferramentas e técnicas que
em harmonia produzem um resultado
específico.
Paradigma: ele representa uma abordagem
ou filosofia em particular para a construção
de software.
Qual o papel do
engenheiro de software?
 Trata o computador como uma ferramenta
na solução de problemas.
 Trabalha com as funções do computador
como parte de uma solução geral, não com
a estrutura ou a teoria da computação em
si.

Qual tem sido nosso grau
de sucesso?
 Produtos de software não estão isentos de
problemas. Freqüentemente os sistemas
funcionam, mas não exatamente como se
esperava.
Existe uma enorme diferença entre um erro em
um projeto feito para uma disciplina na
universidade do erro em um grande sistema de
software.
Alguns defeitos simplesmente causam
aborrecimentos, outros custam bastante tempo
e dinheiro. Outros podem ameaçar a vida de
pessoas.

Terminologia para
descrever bugs
Defeito: ocorre quando uma pessoa comete um
engano, chamado de erro, na realização de
alguma atividade relacionada a um software.
Falha: é uma divergência entre o
comportamento requerido para o sistema e o
comportamento real.
Portanto, um defeito é uma visão interna do
sistema, observada pelo ponto de vista dos
desenvolvedores, enquanto uma falha é vista a
partir de um referencial externo ao sistema.
Nem todo defeito corresponde a uma falha.

O que é um bom
software?
 Perspectivas de Garvin sobre qualidade
 Visão transcendental: algo que podemos
reconhecer, mas não definir.
 Visão do usuário: conveniência para
propósito pretendido
 Visão do fabricante: conformidade com
especificação
 Visão do produto: relação com as
características inerentes ao produto
 Visão do mercado: dependência de
quanto os consumidores estão dispostos a
pagar

Qualidade do produto
Construção de modelos.
Exemplo do primeiro modelo de qualidade
( McCall)
 Correção
 Confiabilidade
 Eficiência
 Integridade
 Usabildiade
 Manutenibilidade
 Testabilidade
 Flexibilidade
 Portabilidade
 Reutilizabilidade
 Interoperabilidade

Qualidade do processo
 Modelar o processo de desenvolvimento
permite examinar o processo e aprimorar o
produto.
◦ CMM
◦ ISO 9000
◦ SPICE

Quem faz a engenharia de
software?
 Cliente: é a empresa, organização ou
pessoa que está pagando para o sistema
de software ser desenvolvido.
 Desenvolvedor é a empresa, organização
ou pessoa que está construindo o sistema
de software para o cliente.
 Usuário é pessoa, ou pessoas que
realmente utilizarão o sistema.

Uma abordagem de
sistemas
 Elementos de um sistema
 Atividades e objetos:
◦ Atividade: é algo que acontece em um
sistema. Geralmente descrita como um
evento iniciado por um gatilho.
◦ Objetos ou entidades: são os elementos
envolvidos nas atividades.
 Relações e fronteiras do sistema.
 Sistemas inter-relacionado

Uma abordagem de
engenharia
 Identificar e analisar os  Análise e definição
requisitos
 Produzir e documentar dos requisitos
todo o projeto Projeto do sistema
 Detalhar as
especificações Projeto do
 Identificar e projetar os programa
componentes Escrever os
 Construir cada
componente programas
 Testar cada componente Testes das unidades
 Integrar os componentes
 Fazer as modificações
Teste de integração
finais Teste do sistema
 Manutenção contínua Entrega do sistema
 Manutenção
Construindo uma casa


Construindo um sistema

Fatores-chave que mudaram a prática
da engenharia de software
(Wasserman)
 Aspecto crítico do tempo para entrega do
produto ao mercado, no caso de produtos
comerciais
Mudanças na economia da computação
(redução dos custos de hardware e aumento
nos custos de desenvolvimento e
manutenção)
Disponibilidade poderosa da computação em
desktops
Aumento das redes locais e remotas
Disponibilidade e adoção da tecnologia
orientada a objetos
Uso de interfaces gráficas
Imprevisibilidade do modelo de
desenvolvimento de software cascata
Disciplina de engenharia
de software de Wasserman
 Abstração
 Métodos e notações de análise e projeto
 Protótipo da interface com o usuário
 Arquitetura de software
 Processo de software
 Reuso
 Medição
 Ferramentas e ambientes integrados

Abstração
 É a descrição de um problema com um nível

de generalização que nos permite
concentrar nos principais aspectos do
problema, sem nos perdermos nos
detalhes.
Métodos e notações de
análise e projeto
 Métodos e notações nos oferecem mais do
que um meio de comunicação. Eles nos
permitem construir modelos e avaliar a
completeza e a consistência.
Protótipo da interface com
o usuário
 A criação de um protótipo significa construir
uma pequena versão de um sistema,
geralmente com funcionalidade limitada
que pode ser utilizada para
◦ Ajudar o usuário ou cliente a definir os principais
requisitos de um sistema
◦ Demonstrar a viabilidade do projeto ou de uma
abordagem.
Arquitetura de software
 A arquitetura de sistemas descreve o
sistema em termos de um conjunto de
unidades arquitetônicas e um mapa de
como essas unidades se relacionam entre
si.
 Modos de dividir o sistema em unidades:
◦ Decomposição modular
◦ Decomposição orientada a dados
◦ Decomposição orientada a eventos
◦ Projeto de fora para dentro
◦ Projeto orientado a objetos.
◦
Processo de software
 A organização e disciplina com que as
atividades são realizadas contribuem para
a qualidade do software e para a rapidez
de seu desenvolvimento.
Reuso
 As vezes é mais fácil construir um pequeno
componente do que procurar por um em um
repositório de compoennetes reutilizáveis
É necessário tempo extra para se construi um
componente geral o bastante para ser utilizado por
outros desenvolvedores no futuro
É difícil documentar o grau de segurança e teste de
qualidade que foi feito de modo que outro usuário
em potencial possa se sentir tranqüilo sobre a
qualidade do componente
Não fica muito claro quem é o responsável por sua
atualização ou no caso de um componente
reutilizável apresentar falha.
Muitas vezes existe um conflito entre generalidade e
especificidade
Medição
 A medição quantifica onde e o que podemos
aprimorar, descrevemos nossas ações e
suas conseqüências em uma linguagem
matemática, o que nos permite avaliar
nosso progresso.
Ferramentas e ambientes
integrados
 Integração da plataforma
 Integração da apresentação
 Integração do processo
 Integração de dados
 Integração de controle
Falhas Famosas de
Software
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
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
 Erros no sistema automático de transporte de

bagagens (misloaded, misrouted, jammed):
 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.
 Garantiria 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? (I)
 Fato: o veículo detonou suas cargas
explosivas de autodestruição e explodiu no
ar. Por quê?
 Porque ele estava se quebrando devido às
forças aerodinâmicas. Mas por que?
 O foguete tinha perdido o controle de
direção (altitude). Causa disso?
 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.
Ironia...
 O resultado desta conversão não era mais
necessário após a decolagem...
Exercícios
 Descreva 2 casos de problemas causados
por erros em software que você conhece.
 Descreva 2 produtos (que não seja um
computador) onde o software faz a
diferença.
Atividades
 Responder as questões do capítulo 1 do livro
Engenharia de Software – Shari Pfleeger.




Aula 123

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Aula 123

Transféré par

Droits d'auteur :

Formats disponibles

Engenharia de

Subproblema Subproblema 2 Subproblema4

 É a descrição de um problema com um nível

 Custo do projeto: US$ 4.9 bilhões

 Erros no sistema automático de transporte de

Vous aimerez peut-être aussi