Software e Engenharia de
Software
ENGENHARIA DE SOFTWARE - PRESSMAN
Renata Pontin de Mattos Fortes – ICMC/USP
Software
1- INSTRUÇÕES
que quando executadas produzem a função e o
desempenho desejados
2 - ESTRUTURAS DE DADOS
que possibilitam que os programas manipulem
adequadamente a informação
3 - DOCUMENTOS
que descrevem a operação e o uso dos
programas
2
Características do Software
1- desenvolvido ou projetado por engenharia,
não manufaturado no sentido clássico
2- não se desgasta mas se deteriora
3- a maioria é feita sob medida em vez de ser
montada a partir de componentes existentes
3
Curva de falhas para o hardware
índice
de
falhas
“desgaste”
“mortalidade
infantil”
tempo
4
Curva de falhas do software
mudança
índice de
falhas
curva real
curva idealizada
tempo
5
Aplicações do software
BÁSICO coleção de programas escritos para dar
apoio a outros programas
DE TEMPO REAL software que monitora, analisa e
controla eventos do mundo real
COMERCIAL sistemas de operações comerciais e
tomadas de decisões administrativas
CIENTÍFICO E DE ENGENHARIA caracterizado
por algoritmos de processamento de números
6
Aplicações do software
EMBUTIDO usado para controlar produtos e sistemas
para os mercados industriais e de consumo
DE COMPUTADOR PESSOAL envolve
processamento de textos, planilhas eletrônicas,
diversões, etc.
DE INTELIGÊNCIA ARTIFICIAL faz uso de algoritmos
não numéricos para resolver problemas que não
sejam favoráveis à computação ou à análise direta
7
Evolução do software
(1950 - 1965)
 O hardware sofreu contínuas mudanças
 O software era uma arte "secundária" para
a qual havia poucos métodos sistemáticos
 O hardware era de propósito geral
 O software era específico para cada
aplicação
 Não havia documentação
8
Evolução do software
(1965 - 1975)
 Multiprogramação e sistemas multiusuários
 Técnicas interativas
 Sistemas de tempo real
 1a. geração de SGBD’s
 Produto de sofwtare - software houses
 Bibliotecas de Software
 Cresce nro. de sistemas baseado em computador
 Manutenção quase impossível
..... CRISE DE SOFTWARE
9
Evolução do software
(1975 - hoje)
 Sistemas distribuídos
 Redes locais e globais
 Uso generalizado de
microprocessadores - produtos
inteligentes
 Hardware de baixo custo
 Impacto de consumo
10
Evolução do software
(Quarta era do software de computador)
 Tecnologias orientadas o objetos
 Sistemas especialistas e software de
inteligência artificial usados na prática
 Software de rede neural artificial
 Computação Paralela
11
crise de software
Refere-se a um conjunto de problemas
encontrados no desenvolvimento de software:
1- As estimativas de prazo e de custo freqüentemente
são imprecisas
“Não dedicamos tempo para coletar dados sobre o
processo de desenvolvimento de software”
“Sem nenhuma indicação sólida de produtividade, não
podemos avaliar com precisão a eficácia de novas
ferramentas, métodos ou padrões”
12
crise de software
2- A produtividade das pessoas da área de
software não tem acompanhado a demanda por
seus serviços
“Os projetos de desenvolvimento de software
normalmente são efetuados apenas com um vago
indício das exigências do cliente”
13
crise de software
3- A qualidade de software às vezes é menos que
adequada
Só recentemente começam a surgir conceitos
quantitativos sólidos de garantia de qualidade de
software
4- O software existente é muito difícil de manter
A tarefa de manutenção devora o orçamento destinado
ao software
A facilidade de manutenção não foi enfatizada como um
critério importante
14
crise de software

estimativas de prazo e de custo 

produtividade das pessoas 

qualidade de software 

software difícil de manter 
15
Causas dos problemas associados
à crise de software
1- PRÓPRIO CARÁTER DO SOFTWARE
O software é um elemento de sistema lógico e
não físico. Conseqüentemente o sucesso é
medido pela qualidade de uma única
entidade e não pela qualidade de muitas
entidades manufaturadas
O software não se desgasta, mas se
deteriora
16
Causas dos problemas associados
à crise de software
2- FALHAS DAS PESSOAS RESPONSÁVEIS
PELO DESENVOLVIMENTO DE SOFTWARE
Gerentes sem nenhum background em software
Os profissionais da área de software têm
recebido pouco treinamento formal em novas
técnicas para o desenvolvimento de software
Resistência a mudanças.
17
Causas dos problemas associados à
crise de software
3- M ITOS DO SOFTWARE
Propagaram desinformação e confusão
administrativos
cliente
profissional
18
Mitos do software (ADMINISTRATIVOS)
Mito: Já temos um manual repleto de padrões e
procedimentos para a construção de software.
Isso não oferecerá ao meu pessoal tudo o que
eles precisam saber?
Realidade: Será que o manual é usado?
Os profissionais sabem que ele existe?
Ele reflete a prática moderna de
desenvolvimento de software? Ele é completo?
19
Mitos do software (ADMINISTRATIVOS)
Mito: Meu pessoal tem ferramentas de
desenvolvimento de software de última
geração; afinal lhes compramos os mais
novos computadores.
Realidade: É preciso muito mais do que os
mais recentes computadores para se fazer
um desenvolvimento de software de alta
qualidade.
20
Mitos do software (ADMINISTRATIVOS)
Mito: Se nós estamos atrasados nos prazos,
podemos adicionar mais programadores e
tirar o atraso.
Realidade: O desenvolvimento de software não
é um processo mecânico igual à
manufatura. Acrescentar pessoas em um
projeto torna-o ainda mais atrasado.
Pessoas podem ser acrescentadas, mas
somente de uma forma planejada.
21
Mitos do software (CLIENTE)
Mito: Uma declaração geral dos objetivos é
suficiente para se começar a escrever programas
- podemos preencher os detalhes mais tarde.
Realidade: Uma definição inicial ruim é a principal
causa de fracassos dos esforços de
desenvolvimento de software. É fundamental
uma descrição formal e detalhada do domínio
da informação, função, desempenho, interfaces,
restrições de projeto e critérios de validação.22
Mitos do software
(CLIENTE)
Mito: Os requisitos de projeto modificam-se
continuamente, mas as mudanças podem ser
facilmente acomodadas, porque o software é
flexível.
Realidade: Uma mudança, quando solicitada
tardiamente num projeto, pode ser maior do
que a ordem de magnitude mais
dispendiosa da mesma mudança solicitada
nas fases iniciais.
23
magnitude das mudanças
F AS E S
D E F IN IÇ Ã O
C U S T O D E M AN U T E N Ç ÃO
1 x
D E S E N V O L V IM E N T O
1 .5 - 6 x
M AN U T E N Ç Ã O
60 - 100x
24
Mitos do software (PROFISSIONAL)
Mito: Assim que escrevermos o programa e
o colocarmos em funcionamento nosso
trabalho estará completo.
Realidade: Os dados da indústria indicam
que entre 50 e 70% de todo esforço gasto
num programa serão despendidos depois
que ele for entregue pela primeira vez ao
cliente.
25
Mitos do software
(PROFISSIONAL)
Mito: Enquanto não tiver o programa
"funcionando", eu não terei realmente
nenhuma maneira de avaliar sua qualidade.
Realidade: Um programa funcionando é
somente uma parte de uma Configuração
de Software que inclui todos os itens de
informação produzidos durante a
construção e manutenção do software.
26
abrange um conjunto de três elementos fundamentais:
Métodos, Ferramentas e
Procedimentos
MÉTODOS: proporcionam os detalhes de como
fazer para construir o software
27
Engenharia de Software
 Planejamento e estimativa de projeto
 Análise de requisitos de software e de
sistemas
 Projeto da estrutura de dados
 Algoritmo de processamento
 Codificação
 Teste
 Manutenção
28
Engenharia de Software
FERRAMENTAS: dão suporte automatizado aos
métodos.

Existem atualmente ferramentas para sustentar
cada um dos métodos

Quando as ferramentas são integradas é
estabelecido um sistema de suporte ao
desenvolvimento de software chamado CASE Computer Aided Software Engineering
29
Engenharia de Software
PROCEDIMENTOS: constituem o elo de ligação
entre os métodos e ferramentas
 Seqüência em que os métodos serão aplicados
 Produtos que se exige que sejam entregues
 Controles que ajudam assegurar a qualidade e
coordenar as alterações
 Marcos de referência que possibilitam
administrar o progresso do software.
30
ENGENHARIA DE SOFTWARE
Conjunto de etapas que envolve MÉTODOS,
FERRAMENTAS e PROCEDIMENTOS.
 Essas etapas são conhecidas como
componentes de CICLOS DE VIDA DE
SOFTWARE
 Alguns ciclos de vida mais conhecidos são:
Ciclo de Vida Clássico, Prototipação, Modelo
Espiral e Técnicas de 4a Geração
31
Para escolha de um Ciclo de Vida de software:

natureza do projeto e da aplicação

métodos e ferramentas a serem usados

controles e produtos que precisam ser
entregues
32
Ciclo de Vida Clássico (Cascata)
 modelo
mais antigo e o mais
amplamente usado da engenharia de
software
 modelado
em função do ciclo da
engenharia convencional
 requer
uma abordagem sistemática,
seqüencial ao desenvolvimento de
software
33
Cascata
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
34
Atividades do Ciclo de Vida Clássico
1- ANÁLISE E ENGENHARIA DE
SISTEMAS
 envolve a coleta de requisitos em nível do
sistema, com uma pequena quantidade de
projeto e análise de alto nível
 esta visão é essencial quando o software
deve fazer interface com outros elementos
(hardware, pessoas e banco de dados)
35
Atividades do Ciclo de Vida Clássico
2- ANÁLISE DE REQUISITOS DE SOFTWARE
 o processo de coleta dos requisitos é intensificado
e concentrado especificamente no software
 deve-se compreender o domínio da informação,
a função, desempenho e interfaces exigidos
 os requisitos (para o sistema e para o software)
são documentados e revistos com o cliente
36
Atividades do Ciclo de Vida Clássico
3- PROJETO
 tradução dos requisitos do software para um
conjunto de representações que podem ser avaliadas
quanto à qualidade, antes que a codificação se inicie
 se concentra em 4 atributos do programa:
 Estrutura de Dados,
 Arquitetura de Software,
 Detalhes Procedimentais e
 Caracterização de Interfaces
37
Atividades do Ciclo de Vida Clássico
4- CODIFICAÇÃO
 tradução das representações do projeto para
uma linguagem “artificial” resultando em
instruções executáveis pelo computador
38
Atividades do Ciclo de Vida Clássico
5- TESTES
Concentra-se:
 nos aspectos lógicos internos do software,
garantindo que todas as instruções tenham sido
testadas
 nos aspectos funcionais externos, para descobrir
erros e garantir que a entrada definida produza
resultados que concordem com os esperados.
39
Atividades do Ciclo de Vida Clássico
6- MANUTENÇÃO
 provavelmente o software deverá sofrer
mudanças depois que for entregue ao cliente
 causas das mudanças: erros, adaptação do
software para acomodar mudanças em seu
ambiente externo e exigência do cliente para
acréscimos funcionais e de desempenho
40
Problemas com o Ciclo de Vida Clássico
projetos reais raramente seguem
o fluxo seqüencial que o modelo
propõe

logo no início é difícil
estabelecer explicitamente todos
os requisitos. No começo dos
projetos sempre existe uma
incerteza natural

o
cliente deve ter paciência.
41
 Embora o Ciclo de Vida Clássico
tenha fragilidades, ele é
significativamente melhor do que
uma abordagem casual ao
desenvolvimento de software
42
Prototipação

processo que possibilita que o desenvolvedor crie
um modelo do software que deve ser construído.

idealmente, o modelo (protótipo) serve como um
mecanismo para identificar os requisitos de
software.

apropriado para quando o cliente definiu um
conjunto de objetivos gerais para o software,
mas não identificou requisitos de entrada,
processamento e saída com detalhes.
43
Prototipação
início
fim
obtenção
dos
requisitos
construção
produto
projeto
rápido
construção
protótipo
refinamento
protótipo
avaliação
protótipo
44
Atividades da Prototipação
1- OBTENÇÃO DOS REQUISITOS: desenvolvedor
e cliente definem os objetivos gerais do
software, identificam quais requisitos são
conhecidos e as áreas que necessitam de
definições adicionais.
2- PROJETO RÁPIDO: representação dos
aspectos do software que são visíveis ao usuário
(abordagens de entrada e formatos de saída)
45
Atividades da Prototipação
3- CONSTRUÇÃO PROTÓTIPO:
implementação do projeto rápido
4- AVALIAÇÃO DO PROTÓTIPO: cliente e
desenvolvedor avaliam o protótipo
46
Atividades da Prototipação
5- REFINAMENTO DOS REQUISITOS: cliente e
desenvolvedor refinam os requisitos do software
a ser desenvolvido. Ocorre neste ponto um
processo de iteração que pode conduzir a atividade 1
até que as necessidades do cliente sejam satisfeitas e
o desenvolvedor compreenda o que precisa ser feito.
6- CONSTRUÇÃO PRODUTO: identificados os
requisitos, o protótipo deve ser descartado e a
versão de produção deve ser construída
considerando os critérios de qualidade.
47
Problemas com a Prototipação
cliente não sabe que o software que ele vê não
considerou, durante o desenvolvimento, a qualidade
global e a manutenibilidade a longo prazo. Não aceita
bem a idéia que a versão final do software vai ser construída e
"força" a utilização do protótipo como produto final
desenvolvedor freqüentemente faz uma
implementação comprometida (utilizando o que está
disponível) com o objetivo de produzir rapidamente
um protótipo. Depois de um tempo ele familiariza com essas
escolhas, e esquece que elas não são apropriadas para o produto
final.
48
ainda que possam ocorrer problemas, a
prototipação é um ciclo de vida eficiente.
a chave é definir-se as regras do jogo logo no
começo.
o cliente e o desenvolvedor devem ambos
concordar que o protótipo seja construído para
servir como um mecanismo a fim de definir os
requisitos.
49
Ciclo de Vida em Espiral
– engloba as melhores características do ciclo de vida
Clássico e da Prototipação, adicionando um novo
elemento: a Análise de Risco
– segue a abordagem de passos sistemáticos do Ciclo de
Vida Clássico incorporando-os numa estrutura iterativa
que reflete mais realisticamente o mundo real
– usa a Prototipação, em qualquer etapa da evolução do
produto, como mecanismo de redução de riscos
50
Espiral
planejamento
análise dos
riscos
decisão de continuar ou não
avaliação
do cliente
na direção de um
sistema concluído
engenharia
51
Atividades do Ciclo de Vida em Espiral
1- PLANEJAMENTO: determinação dos objetivos,
alternativas e restrições
2- ANÁLISE DE RISCO: análise das alternativas e
identificação / resolução dos riscos
3- CONSTRUÇÃO: desenvolvimento do produto no
nível seguinte
4- AVALIAÇÃO DO CLIENTE: avaliação do produto e
planejamento das novas fases
52
Comentários sobre o Ciclo de Vida em Espiral
 é, atualmente, a abordagem mais realística para o
desenvolvimento de software em grande escala.
 usa uma abordagem que capacita o desenvolvedor
e o cliente a entender e reagir aos riscos em cada
etapa evolutiva.
 pode ser difícil convencer os clientes que uma
abordagem "evolutiva" é controlável
 exige considerável experiência na determinação
de riscos e depende dessa experiência para ter
53
sucesso
Comentários sobre o Ciclo de Vida em Espiral
 o modelo é relativamente novo e não tem
sido amplamente usado. Demorará muitos
anos até que a eficácia desse modelo possa
ser determinada com certeza absoluta.
54
Técnicas de 4a Geração
Concentra-se na capacidade de se especificar o
software a uma máquina em um nível que esteja
próximo à linguagem natural.
Engloba um conjunto de ferramentas de software
que possibilitam que:
 o sistema seja especificado em uma
linguagem de alto nível e
o código fonte seja gerado automaticamente a
partir dessas especificações
55
4a Geração
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementação
usando 4GL
Testes
56
Ferramentas do ambiente de
desenvolvimento de software de 4a Geração
O ambiente de desenvolvimento de software que sustenta
o ciclo de vida de 4a geração inclui as ferramentas:
 linguagens não procedimentais para consulta de banco
de dados
 geração de relatórios
 manipulação de dados
 interação e definição de telas
 geração de códigos
 capacidade gráfica de alto nível
 capacidade de planilhas eletrônicas
57
Atividades das Técnicas de 4a Geração
1- OBTENÇÃO DOS REQUISITOS: o cliente
descreve os requisitos os quais são traduzidos
para um protótipo operacional
o
cliente pode estar inseguro quanto aos requisitos
o
cliente pode ser incapaz de especificar as informações
de um modo que uma ferramenta 4GL possa consumir
 as
4GLs atuais não são sofisticadas suficientemente
para acomodar a verdadeira "linguagem natural"
58
Atividades das Técnicas de 4a Geração
2- ESTRATÉGIA DE "PROJETO": para pequenas
aplicações é possível mover-se do passo de
Obtenção dos Requisitos para o passo de
Implementação usando uma linguagem de
quarta geração
Para grandes projetos é necessário desenvolver uma
estratégia de projeto. De outro modo ocorrerão os mesmos
problemas encontrados quando se usa abordagem
convencional (baixa qualidade)
59
Atividades das Técnicas de 4a Geração
3- IMPLEMENTAÇÃO USANDO 4GL: os resultados
desejados são representados de modo que haja
geração automática de código . Deve existir uma
estrutura de dados com informações relevantes e
que seja acessível pela 4GL
4- TESTE: o desenvolvedor deve efetuar testes e
desenvolver uma documentação significativa. O
software desenvolvido deve ser construído de
maneira que a manutenção possa ser efetuada
prontamente.
60
Comentários sobre as Técnicas de 4a Geração
PROPONENTES: redução dramática no tempo de
desenvolvimento do software (aumento de
produtividade)
OPONENTES: as 4GL atuais não são mais fáceis
de usar do que as linguagens de programação
 o código fonte produzido é ineficiente
 a manutenibilidade de sistemas usando técnicas 4G
ainda é questionável
61
Mudança na natureza de
desenvolvimento de software
demanda
global
demanda por
software
aplicação de
técnicas de 4a
Geração
métodos
convencionais
1970
1980
1990
2000
62
Combinação dos Métodos de Ciclo de Vida
obtenção dos requisitos
preliminares
análise dos
requisitos
protomodelagem
projeto
protomodelagem
no. interação
técnicas
4G
codificação
protomodelagem
no. interação
modelo espiral
técnicas
4G
modelo espiral
no. interação
testes
sistema completo
manutenção
63
Engenharia de Software uma visão genérica
O processo de desenvolvimento de software
contém 3 fases genéricas, independentes
do modelo de engenharia de software
escolhido:
 DEFINIÇÃO,
 DESENVOLVIMENTO e
 MANUTENÇÃO.
64
Engenharia de Software uma visão genérica
FASE DE DEFINIÇÃO: “o que” será desenvolvido.

Análise do Sistema:

Planejamento do Projeto de Software:

Análise de Requisitos:
define o papel de cada elemento num
sistema baseado em computador, atribuindo em última análise, o
papel que o software desempenhará.
assim que o
escopo do software é estabelecido, os riscos são analisados, os
recursos são alocados, os custos são estimados e, tarefas e
programação de trabalho definidas.
o escopo definido para o software
proporciona uma direção, mas uma definição detalhada do
domínio da informação e da função do software é necessária antes
que o trabalho inicie.
65
Engenharia de Software uma visão genérica
DESENVOLVIMENTO: “como” o software vai ser desenvolvido.
 Projeto de Software: traduz os requisitos do software num
conjunto de representações (algumas gráficas, outras tabulares ou
baseadas em linguagem) que descrevem a estrutura de dados, a
arquitetura do software, os procedimentos algoritmicos e as
características de interface.
Codificação:

as representações do projeto devem ser convertidas
numa linguagem artificial (a linguagem pode ser uma linguagem de
programação convencional ou uma linguagem não procedimental) que
resulte em instruções que possam ser executadas pelo computador.

Realização de Testes do Software: logo que o software é
implementado numa forma executável por máquina, ele deve ser testado
para que se possa descobrir defeitos de função, lógica e
implementação.
66
Engenharia de Software uma visão genérica
FASE DE MANUTENÇÃO: concentra-se nas
“mudanças” que ocorrerão depois que o
software for liberado para uso operacional
 Correção
 Adaptação
 Melhoramento Funcional
67
Engenharia de Software uma visão genérica
Correção: mesmo com as melhores atividades de
garantia de qualidade de software, é provável que o
cliente descubra defeitos no software. A manutenção
corretiva muda o software para corrigir defeitos.
Adaptação: com o passar do tempo, o ambiente
original (por exemplo a CPU, o sistema operacional e
periféricos) para o qual o software foi desenvolvido
provavelmente mudará. A manutenção adaptativa
muda o software para acomodar mudanças em seu
ambiente.
68
Engenharia de Software uma visão genérica
Melhoramento Funcional: a medida que o
software é usado, o cliente/usuário
reconhecerá funções adicionais que
oferecerão benefícios. A manutenção
perfectiva estende o software para além
de suas exigências funcionais originais.
69
Engenharia de Software uma visão genérica
ATIVIDADES DE PROTEÇÃO as fases e etapas correlatas
descritas são complementadas por uma série de atividades de
proteção.
Revisões: efetuadas para garantir que a qualidade seja
mantida à medida que cada etapa é concluída.
Documentação: é desenvolvida e controlada para garantir
que informações completas sobre o software estejam
disponíveis para uso posterior.
Controle das Mudanças: é instituído de forma que as
mudanças possam ser aprovadas e acompanhadas.
70
Conclusão
ENGENHARIA DE SOFTWARE
pode ser vista como uma abordagem
de desenvolvimento de software
elaborada com disciplina e métodos
bem definidos.
.....“a construção por múltiplas
pessoas de um software de
múltiplas versões” [Parnas 1987]
71