Processos de software
Atividades para especificar,
projetar, implementar e testar
sistemas de software
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
1
Processos de software
Uma Visão Genérica: 3 Fases



Definição - “o que”
• Engenharia do Sistema
• Planejamento do Projeto
• Análise de Requisitos
Desenvolvimento - “como”
• Projeto
• Geração do Código
• Teste
Manutenção
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
2
Processos de software
• Um processo de software é um método
para desenvolver ou produzir software.
• A pesquisa em processo de software lida
com métodos e tecnologias estimativas,
suporte e melhoria das atividades de
desenvolvimento de software.
• Define quem faz o que, quando e
como.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
3
Processos de software
O processo é o instrumento capaz
de responder a qualquer momento:
•
•
•
•
•
Profa. Maria Auxiliadora
O que é feito?
 Produto
Como é feito?
 Passos
Por quem é feito?  Agente
O que usa?
 Insumos
O que Produz?
 Resultados
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
4
Modelo de Processo de Software
Processo  deve incorporar uma estratégia
de desenvolvimento
definição do
problema
estado atual
desenvolvimento técnico
integração da
solução
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
5
Modelagem
• Modelagem é uma técnica de
engenharia aprovada e bem aceita
– modelos de arquitetura de casas e
de grandes prédios
– modelos matemáticos a fim de
analisar os efeitos de ventos e
tremores de terra --> causas
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
6
Modelos
Modelagem na Engenharia Civil
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
7
O que é um MODELO?
• Um modelo é uma simplificação da
realidade.
– Planos de detalhes, podem ser
estruturais (organização do
sistema) ou comportamentais
(dinâmica do sistema)
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
8
Modelos
• Modelos são construídos para permitir um
melhor entendimento sobre o sistema que
está sendo construído.
– especificar a estrutura e
comportamento
– guia para construção do sistema
–documentam as decisões tomadas
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
9
Objetivos da Modelagem
• Auxiliar no processo de produção 
produtos de alta qualidade, produzidos
mais rapidamente e a um custo cada vez
menor.
• Atributos: abstração, visibilidade,
especificação, construção, confiabilidade,
manutenibilidade, segurança,
documentação.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
10
Modelos de processo de software
• Abstração
– Melhor entendimento e maior
compreensão
• Visualização
– Visualização antecipada antes da
implementação
– Visões complementares do software
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
11
Modelos de processo de software
• Especificação
– Descrição precisa do que deve ser feito
• Construção
– Geração automática com ferramentas
baseadas em modelos
• Documentação
– Comunicação entre equipes na
diferentes fases do ciclo de vida
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
12
Objetivos da Modelagem
• Possibilitam:
– Ao gerente: controlar o processo de
desenvolvimento de sistemas de
software.
– Ao desenvolvedor: obter a base para
produzir, de maneira eficiente, software
que satisfaça os requisitos préestabelecidos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
13
Modelos de processo de software
• Um conjunto de atividades fundamentais
exigida para desenvolver um sistema de
software
–Especificação.
–Projeto e implementação.
–Validação.
–Evolução.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
14
Modelo X Processo
• Um modelo é algo teórico, um
conjunto de possíveis ações.
• O processo deve determinar ações
práticas a serem realizadas pela
equipe como prazos definidos e
métricas para se avaliar como elas
estão sendo realizadas
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
15
Modelo X Processo
Modelo + Planejamento =
Processo
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
16
Processo de software
Estudo de
viabilidade
Levantamento
e análise de
requisitos
Especificação
de requisitos
Relatório
de viabilidade
Validação
de requisitos
Modelos
de sistemas
Requisitos do
usuário e do sistema
Documentação
de requisitos
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
17
Processo de software
• Processo de Engenharia de Requisitos
– Estudo de viabilidade
• Econômica – relação custo/benefício;
• Técnica – tecnologia e capacitação;
• Jurídica – aspectos legais.
– Levantamento e análise de requisitos
• Entrevista, observação, reuniões
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
18
Processo de software
– Especificação de requisitos
• Documento contendo os requisitos
do usuário e do sistema – funcionais
e não-funcionais
– Validação de requisitos
• Avaliação do documento de
requisitos –consistência e
integralidade.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
19
Modelos de processo de software
• Exemplos de modelos de processo:
–Workflow - sucessão de atividades
–Fluxo de Dados - fluxo de informação
–Papel/ação – representa os papéis das
pessoas e as atividades pelas quais elas
são responsáveis.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
20
Modelos de processo de software –
(paradigmas)
Uma estratégia de
desenvolvimento que englobe
processos, métodos e
ferramentas, e as fases de
desenvolvimento...
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
21
Modelos de processo de software –
(paradigmas)
• Modelo Sequencial Linear (ciclo de vida
clássico)
• Modelos Evolucionários
- Prototipação
- Incremental
- Espiral
- Métodos Ágeis
• Modelo de Métodos Formais
• Técnicas de 4a Geração
• Orientado a reuso
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
22
Modelo Sequencial Linear
(ciclo de vida clássico)
• Método sistemático e sequencial
• O resultado de uma fase se constitui
na entrada da outra.
• Cada fase é estruturada como um
conjunto de atividades que podem
ser executadas por pessoas
diferentes.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
23
Modelo Sequencial Linear
(ciclo de vida clássico)
Engenharia de
Sistemas
Análise / projeto de
sistema e de software
Implementação
e teste
Integração e
teste
Operação e
manutenção
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
24
Modelo Sequencial Linear
(ciclo de vida clássico)
• ENGENHARIA DE SISTEMAS
• envolve a coleta de requisitos em
nível do sistema, pequena quantidade
de projeto e análise de alto nível
• definir quais os requisitos do
produto de software, sem especificar
como esses requisitos serão obtidos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
25
Modelo Sequencial Linear
(ciclo de vida clássico)
• ENGENHARIA DE SISTEMAS
• deve-se analisar os requisitos, recursos e
restrições para:
• apresentar soluções;
• estudar a viabilidade;
• planejar e gerenciar o
desenvolvimento a partir de estimativas
e análise de riscos que se utilizam de
métricas.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
26
Modelo Sequencial Linear
(ciclo de vida clássico)
• Estudo de viabilidade
• Analisar o problema em nível global
• Identificar soluções alternativas (custos
/ benefícios)
• Simulação do futuro processo de
desenvolvimento.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
27
Modelo Sequencial Linear
(ciclo de vida clássico)
• Estudo de viabilidade (cont)
Resultado  documentação contendo:
• Definição do problema
• Soluções alternativas, com os
benefícios esperados
• Fontes necessárias, custos e datas de
entrega para cada solução proposta.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
28
Modelo Sequencial Linear
(ciclo de vida clássico)
• Gerenciamento  Definição de políticas:
• Como produtos ou resultados
intermediários vão ser armazenados
acessados e modificados.
• Como versões diferentes de sistemas
são construídos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
29
Modelo Sequencial Linear
(ciclo de vida clássico)
• Gerenciamento  (cont.)
• Quais autorizações são necessárias
para acessar os componentes de
entrada/saída do banco de dados do
sistema.
• Recursos que afetam o processo de
produção, particularmente com os
recursos humanos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
30
Modelo Sequencial Linear
(ciclo de vida clássico)
• ANÁLISE DE REQUISITOS DE SOFTWARE
• 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.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
31
Modelo Sequencial Linear
(ciclo de vida clássico)
• ANÁLISE DE REQUISITOS DE SOFTWARE
• os requisitos (para o sistema e para o
software) são documentados e revistos com
o cliente.
Resultado  o contrato de desenvolvimento
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
32
Modelo Sequencial Linear
(ciclo de vida clássico)
• PROJETO
• É definida a solução do problema:
• Decomposição do produto
(subsistema, componentes etc).
• Representação das funções do
sistema em uma forma que possa ser
transformada em um ou mais
programas executáveis.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
33
Modelo Sequencial Linear
(ciclo de vida clássico)
• PROJETO
• Definição de “como” o produto deve
ser implementado.
• Dividido em:
• Projeto de alto nível – decomposição
lógica
• Projeto detalhado – decomposição
física.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
34
Modelo Sequencial Linear
(ciclo de vida clássico)
• PROJETO
• Concentra-se em:
• Estrutura de Dados;
• Arquitetura de Software;
• Detalhes Procedimentais e
• Caracterização de Interfaces.
Resultado  documentação de
especificação de projeto
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
35
Modelo Sequencial Linear
(ciclo de vida clássico)
• IMPLEMENTAÇÃO
• Tradução das representações do
projeto para uma linguagem “artificial”
resultando em instruções executáveis
pelo computador.
Resultado  coleção de programas
implementados e testados.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
36
Modelo Sequencial Linear
(ciclo de vida clássico)
• INTEGRAÇÃO
• Programas ou unidades de programas são
integrados e testados como sistema.
Programas ou unidades são integradas à
medida em que forem sendo desenvolvidos.
Resultado  produto pronto para ser
entregue ao cliente.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
37
Modelo Sequencial Linear
(ciclo de vida clássico)
• OPERAÇÃO
• Instalação e configuração
• Utilização – inicialmente operado
por um grupo de usuário
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
38
Modelo Sequencial Linear
(ciclo de vida clássico)
• MANUTENÇÃO
• Corretiva: correção de erros remanescentes
• Adaptativa: adaptação dos produtos às
mudanças novas versões e novas situações
de operação – hardware, sistemas
operacionais.
• Evolutiva: alteração dos requisitos e
manutenção da qualidade.
Resultado  produto em funcionamento.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
39
Modelo Sequencial Linear
(ciclo de vida clássico)
ETAPA
PERGUNTAS-CHAVES
Definição do Qual é o problema
problema
Estudo de
Há uma solução viável
viabilidade
Análise
CRITÉRIOS DE SAÍDA
Declaração da delimitação e objetivos.
Análise geral de custo/benefício
Alcance e objetivos do sistema.
Modelo lógico do sistema:
O que terá de ser feito
para resolver o problema?
Diagrama de Fluxo de Dados;
Diagrama de Entidade e Relacionamento
Diagrama de Transição de Estado;
Dicionário de Dados;
Especificação de Processos.
UML.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
40
Modelo Sequencial Linear
(ciclo de vida clássico)
ETAPA
Projeto
PERGUNTAS-CHAVES
Como o problema deve ser
resolvido?
Como o sistema deve ser
implementado?
CRITÉRIOS DE SAÍDA
Soluções Alternativas
Especificação de hard/soft;
Plano de implementação;
Plano de teste preliminares;
Procedimento de segurança;
Procedimento de auditoria.
Implementação Faça
Programas;
Plano de testes;
Procedimento de segurança;
Procedimento de auditoria.
Teste
Verificar o sistema
Testes do geral do sistema.
Manutenção
Modificar o sistema conforme Apoio continuado.
necessidade.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
41
Contribuições e problemas do ciclo
de vida clássico
• Contribuições
• Processo de desenvolvimento de software deve
ser sujeito à disciplina, planejamento e
gerenciamento.
• A implementação do produto deve ser
postergada até que os objetivos tenham sido
completamente entendidos.
• Deve ser utilizado quando os requisitos estão
bem claros no inicio do desenvolvimento.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
42
Contribuições e problemas do ciclo
de vida clássico
• Problema
• Rigidez
• Qualquer desvio é desencorajado
• Todo o planejamento é orientado para
a entrega do produto de software em
uma data única.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
43
Contribuições e problemas do ciclo
de vida clássico
• Problema (cont.)
• Processo de desenvolvimento pode ser
longo e a aplicação pode ser entregue
quando as necessidades do usuário já
tiverem sido alteradas.
• Projetos reais raramente seguem o
fluxo sequencial que o modelo propõe.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
44
Contribuições e problemas do ciclo
de vida clássico
• Problema (cont.)
• 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. Uma versão
executável do software só fica disponível
numa etapa avançada do desenvolvimento
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
45
Modelo Evolucionário
• Abordagem baseada na idéia de
desenvolver uma implementação inicial,
expor o resultado ao comentário do
usuário e fazer seu aprimoramento por
meio de muitas versões.
• Especificação e desenvolvimento são
intercalados
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
46
Modelo Evolucionário
• Tipos:
–Desenvolvimento exploratório
–Protótipo descartável
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
47
Modelo evolucionário
(Desenvolvimento exploratório )
Atividades
concorrentes
Especificação
Descrição do
esboço
Desenvolvimento
Validação
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
Versão
inicial
Versão
intermediárias
Versão
final
48
Modelo evolucionário
(Desenvolvimento exploratório )
• Trabalhar junto com o cliente, a fim
de explorar seus requisitos e entregar
um sistema final.
• O desenvolvimento se inicia com as
partes do sistema que são mais bem
compreendidas.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
49
Modelo evolucionário
(Desenvolvimento exploratório )
• O sistema evolui com o acréscimo de
novas características à medida que elas
são propostas pelo cliente.
• Importante quando é difícil, ou mesmo
impossível, estabelecer uma
especificação detalhada dos requisitos do
sistema a priori.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
50
Modelo evolucionário
(Protótipo descartável)
Construir/Revisar
protótipo
Conversar com
o Cliente
Revisão e Teste
pelo Cliente
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
51
Modelo evolucionário
(Protótipo descartável)
• Obter os requisitos do cliente e, a partir
disso, desenvolver uma melhor definição
de requisitos para o sistema.
• Concentra em fazer experimentos com
partes dos requisitos que estejam mal
entendidos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
52
Modelo evolucionário
(Protótipo descartável)
• Usuário define uma série de objetos para o
produto de software, mas não consegue
identificar detalhes de entrada, processamento
ou requisitos de saída.
• O desenvolvedor está incerto sobre a eficiência
de um algoritmo, a adaptação de um sistema
operacional ou ainda sobre a forma da
interação homem-máquina.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
53
PROTOTIPAÇÃO
Início
Fim
Coleta e
refinamento dos
requisitos
Engenharia do
produto
Projeto
rápido
Refinamento do
protótipo
Construção do
protótipo
Avaliação do
protótipo pelo
cliente
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
54
PROTOTIPAÇÃO
Início
COLETA DOS REQUISITOS:
Fim
Coleta e
refinamento dos
requisitos
Engenharia
do produto
Projeto
rápido
Refinamento
do protótipo
Avaliação do
protótipo
pelo cliente
Profa. Maria Auxiliadora
Construção
do
protótipo
desenvolvedor e
cliente definem os
objetivos gerais do
software, identificam
quais requisitos são
conhecidos e as áreas
que necessitam de
definições adicionais
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
55
PROTOTIPAÇÃO
Início
Fim
Coleta e
refinamento dos
requisitos
Engenharia
do produto
Projeto
rápido
Refinamento
do protótipo
Avaliação do
protótipo
pelo cliente
Profa. Maria Auxiliadora
Construção
do
protótipo
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)
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
56
PROTOTIPAÇÃO
Início
Fim
Coleta e
refinamento dos
requisitos
Engenharia
do produto
Projeto
rápido
Refinamento
do protótipo
Avaliação do
protótipo
pelo cliente
Profa. Maria Auxiliadora
Construção
do
protótipo
CONSTRUÇÃO
PROTÓTIPO:
Implementação
do projeto rápido
serve como o
“primeiro sistema”
- recomendado
que se jogue fora
futuramente
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
57
PROTOTIPAÇÃO
Início
Fim
Coleta e
refinamento dos
requisitos
Engenharia
do produto
Projeto
rápido
Refinamento
do protótipo
Avaliação do
protótipo
pelo cliente
Profa. Maria Auxiliadora
Construção
do
protótipo
AVALIAÇÃO DO
PROTÓTIPO:
Cliente e
desenvolvedor
avaliam o
protótipo
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
58
PROTOTIPAÇÃO
Início
Fim
Coleta e
refinamento dos
requisitos
Engenharia
do produto
Projeto
rápido
Refinamento
do protótipo
Avaliação do
protótipo
pelo cliente
Profa. Maria Auxiliadora
Construção
do
protótipo
REFINAMENTO DOS
REQUISITOS:
Cliente e
desenvolvedor
refinam os
requisitos do
software a ser
desenvolvido.
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
59
PROTOTIPAÇÃO
Início
Fim
Coleta e
refinamento dos
requisitos
Engenharia
do produto
Projeto
rápido
Refinamento
do protótipo
Avaliação do
protótipo
pelo cliente
Profa. Maria Auxiliadora
Construção
do
protótipo
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.
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
60
Contribuições e problemas do modelo
evolutivo
Contribuições:
• Sistemas pequenos
• Útil quando os requisitos estão obscuros
• Especificação é construída gradativamente
• Possibilitam um rápido desenvolvimento
da aplicação
• Testes podem ser mais efetivos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
61
Contribuições e problemas do modelo
evolutivo
Problemas:
• O processo não é visível
• Os sistemas são frequentemente malestruturados e mal-documentados
• Processo não é claro, dificuldade de
planejamento e gerenciamento
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
62
Contribuições e problemas do modelo
evolutivo
Problema (cont):
• 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.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
63
Contribuições e problemas do modelo
evolutivo
• Problema (cont)
• Desenvolvedor frequentemente faz
uma implementação comprometida
(utilizando o que está disponível) com o
objetivo de produzir rapidamente um
protótipo.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
64
Modelo Incremental
incremento 1
Engenharia de Sistemas /
Informação
Projeto
Análise
incremento 2
Projeto
Análise
incremento 3
incremento 4
Profa. Maria Auxiliadora
Análise
Testes
Codificação
Projeto
Análise
Projeto
produto liberado
do incremento 1
Testes
Codificação
Codificação
Codificação
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
Testes
produto liberado
do incremento 2
produto liberado
do incremento 3
Testes
produto
liberado
do
incremento 4
65
Modelo Incremental
• Combina elementos do Modelo Linear
com a filosofia da Prototipação.
• Aplica sequências lineares numa
abordagem de “saltos” à medida que o
tempo progride.
• Cada sequência linear produz um
incremento do software (proc. de texto)
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
66
Modelo Incremental
• O processo se repete até que um produto
completo seja produzido.
• Difere da Prototipação, pois a cada
incremento produz uma versão
operacional do software.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
67
Vantagens do desenvolvimento
incremental
• Entrega acelerada dos serviços de cliente.
Cada incremento fornece a funcionalidade de mais
alta prioridade para o cliente.
• Engajamento do usuário com o sistema.
Os usuários têm de estar envolvidos no processo
de desenvolvimento, o que significa que o sistema
muito provavelmente atenderá aos seus requisitos,
e que os usuários estarão mais comprometidos
com ele.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
68
Problemas com desenvolvimento
incremental
• Problemas de gerenciamento
O progresso pode ser difícil de julgar e os
problemas, difíceis de serem encontrados, porque
não há documentação que mostre o que foi feito.
• Problemas contratuais
O contrato normal pode incluir uma especificação;
sem uma especificação, formulários diferentes de
contrato têm de ser usados.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
69
Problemas com desenvolvimento
incremental
• Problemas de validação
Sem uma especificação, contra o que o sistema
está sendo testado.
• Problemas de manutenção
Mudanças contínuas tendem a corromper a
estrutura do software, o que torna mais
dispendioso mudar e evoluir para atender aos
novos requisitos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
70
Modelo espiral
(Boehm)
Planejamento
1
2
4
3
Avaliação do cliente
Profa. Maria Auxiliadora
Análise de
Risco
Engenharia
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
71
Modelo espiral
(Boehm)
• Desenvolvido para englobar as melhores
características do ciclo de vida clássico e
do paradigma evolutivo.
• São avaliados riscos explicitamente e são
solucionados ao longo do processo.
• Processo é representado como uma
espiral em lugar de ser representado
como uma sequência de atividades
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
72
Modelo espiral
(Boehm)
• Cada loop na espiral representa uma fase do
processo de software. Não existem fases fixas.
• Engloba as melhores características do ciclo de
vida Clássico como o da Prototipação,
adicionando um novo elemento: a ANÁLISE
DOS RISCOS
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
73
Modelo espirais
(Funcionamento)
• À medida que a volta na espiral acontece, versões
mais completas do software vão sendo
progressivamente construída.
• Durante a primeira volta, são definidos objetivos,
alternativas e restrições.
• Se a análise de risco indicar que há incerteza nos
requisitos, a prototipação pode ser usada para
auxiliar o desenvolvedor e o usuário.
• O usuário avalia o produto e faz sugestões de
modificações.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
74
Modelo Espiral
Planejamento
Coleta inicial dos requisitos e
planejamento do projeto
Análise de
risco
Planejamento baseado nos
comentários do cliente
Avaliação do cliente
Engenharia
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
75
Modelo Espiral
• São identificados objetivos específicos, tais como
desempenho e funcionalidade.
• São determinadas alternativas para atingir estes
objetivos.
• São identificadas restrições do processo e do
produto e é elaborado um relatório de gestão
detalhado.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
76
Modelo Espiral
Planejamento
Análise de
risco
Para cada risco do projeto identificado em
planejamento é levada a cabo uma análise
detalhada.
Decisão de prosseguir/não prosseguir
Avaliação do cliente
Engenharia
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
77
Modelo Espiral
Planejamento
Análise de
risco
Na direção de um sistema concluído
Protótipo de software inicial
Avaliação do cliente
Engenharia
Profa. Maria Auxiliadora
Sistema construído pela
engenharia
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
78
Modelo Espiral
• tarefas requeridas para
obter um feedback do
cliente baseado na
avaliação da
representação do
software criado durante a
fase de engenharia e
implementado durante a
fase de instalação
Profa. Maria Auxiliadora
Planejamento
Avaliação do
cliente
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
Análise de
risco
Engenharia
79
Modelo Espiral
• O projeto é revisado e a próxima fase da espiral
é planejada.
• Toma-se decisão sobre avançar para mais uma
volta na espiral.
• Se for para avançar são desenhados os planos
para a próxima fase do projeto.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
80
Desenvolvimento Rápido de Software
• Métodos ágeis
• Extreme programming
• Desenvolvimento rápido de aplicações
• Prototipação de software
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
81
Desenvolvimento Rápido de Software
• Devido à rápida mudança dos ambientes de
negócio, os negócios devem responder às novas
oportunidades e à competição.
• Isso requer software e desenvolvimento rápido, e a
entrega é, frequentemente, o requisito mais crítico
para sistemas de software.
• Os negócios podem estar dispostos a aceitar um
software de baixa qualidade se a entrega rápida e a
funcionalidade essencial for possível.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
82
Métodos Ágeis
• Movimento iniciado por programadores
experientes e consultores em desenvolvimento
de software.
• Objetivo: satisfazer o cliente entregando,
rapidamente e com frequência, sistemas com
algum valor.
• Os métodos ágeis são, provavelmente, os mais
adequados para sistemas de negócio de porte
pequeno/médio ou produtos para PC.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
83
Métodos Ágeis
• A insatisfação com os overheads envolvidos
nos métodos de projeto levou à criação dos
métodos ágeis. Esses métodos:
• Enfocam o código ao invés do projeto;
• São baseados na abordagem iterativa para
desenvolvimento de software;
• São destinados a entregar software de
trabalho e evoluí-lo rapidamente para
atender aos requisitos que se alteram.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
84
Princípios dos Métodos Ágeis
Envolvimento do cliente 
Seu papel é fornecer e priorizar novos
requisitos do sistema e avaliar as
iterações do sistema.Clientes devem
ser profundamente envolvidos no
processo de desenvolvimento.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
85
Princípios dos Métodos Ágeis
Entrega incremental 
O software é desenvolvido em
incrementos e o cliente especifica os
requisitos a serem incluídos em cada
incremento.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
86
Princípios dos Métodos Ágeis
Pessoas, não processo 
As habilidades da equipe de
desenvolvimento devem ser
reconhecidas e exploradas. Os
membros da equipe devem
desenvolver suas próprias maneiras
de trabalhar sem processos
prescritivos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
87
Princípios dos Métodos Ágeis
Aceite as mudanças 
Projete o sistema para acomodar
mudanças.
Mantenha a simplicidade 
Elimine a complexidade do sistema.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
88
Problemas com Métodos Ágeis
• Difícil manter o interesse dos clientes
que estão envolvidos no processo.
• Os membros da equipe podem ser
inadequados para o intenso envolvimento
que caracteriza os métodos ágeis.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
89
Problemas com Métodos Ágeis
• A priorização de mudanças pode ser difícil
onde existem múltiplos stakeholders.
• A manutenção da simplicidade requer
trabalho extra.
• Problemas nos contratos.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
90
Extreme Programming
• É talvez o mais conhecido e mais
amplamente usado dos métodos ágeis.
• A extreme programming (XP) leva uma
abordagem “extrema” para
desenvolvimento iterativo.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
91
Extreme Programming
• Novas versões podem ser compiladas
várias vezes por dia. Os incrementos são
entregues para os clientes a cada 2
semanas.
• Todos os testes devem ser realizados
para cada nova versão.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
92
Os 4 valores de XP
• Comunicação
• Simplicidade
• Retorno (feedback)
• Coragem
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
93
Extreme Programming
A quem se destina
•
•
•
Grupos de 2 a 10 programadores
Projetos de 1 a 36 meses (calendário)
De 1000 a 250 000 linhas de código
• Papéis:
• Programadores foco central (sem
hierarquia)
• “Treinador” ou “Técnico” (coach)
• “Acompanhador” (tracker)
• Cliente
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
94
Extreme Programming
“Treinador” ou “Técnico” (coach)
• Em geral, o mais experiente do grupo.
Identifica quem é bom no que.
Comunica-se com outros gerentes e
diretoria.
• Concentra-se na execução e evolução
técnica do projeto.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
95
Extreme Programming
“Treinador” ou “Técnico” (coach)
• Eventualmente faz programação
pareada.
• Não desenha arquitetura, apenas chama
a atenção para oportunidades de
melhorias.
• Seu papel diminui à medida em que o
time fica mais maduro.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
96
Extreme Programming
Tracker (Acompanhador)
• Coleta estatísticas sobre o andamento do projeto.
Alguns exemplos:
• Número de histórias definidas e implementadas.
• Número de unit tests.
• Número de testes funcionais definidos e
funcionando.
• Número de classes, métodos, linhas de código
• Mantém histórico do progresso. Faz estimativas para
o futuro.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
97
Um Dia na Vida de um
Programador XP
• Escolhe uma história do cliente.
• Procura um par livre.
• Escolhe um computador para
programação pareada (pair programming).
• Seleciona uma tarefa claramente
relacionada a uma característica (feature)
desejada pelo cliente.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
98
O ciclo de release em XP
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
99
Práticas do Extreme Programming
Planejamento Incremental 
Registrados em cartões de histórias
Pequenos releases Conjunto
mínimo útil de funcionalidade é
desenvolvido.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
100
Práticas do Extreme Programming
Projeto simples 
Projeto suficiente para atender aos
requisitos atuais.
Desenvolvimento test-first 
Uso um framework automatizado.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
101
Práticas do Extreme Programming
Refactoring 
Espera-se que todos os
desenvolvedores recriem o código
continuamente.
Programação em pares 
Os desenvolvedores trabalham em pares.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
102
Práticas do Extreme Programming
Propriedade coletiva 
Os pares trabalham em todas as áreas
do sistema.
Integração contínua 
Tarefa concluída é automaticamente
integrada ao sistema.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
103
Práticas do Extreme Programming
Ritmo sustentável 
Não aceitar grande quantidade de
horas extras.
Cliente on-site 
Um usuário do sistema deve estar
disponível em tempo integral..
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
104
Cenários de requisitos
• Em um processo XP, os requisitos de usuários são
expressos como cenários ou histórias de usuários.
• Essas histórias são escritas em cartões, e a
equipe de desenvolvimento quebra-os em tarefas
de implementação. Essas tarefas são as bases das
estimativas de cronograma e de custo.
•O cliente escolhe as histórias para inclusão no
próximo release, baseado nas suas prioridades e
nas estimativas de cronograma.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
105
Cartão de estória para baixar
documentos
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
106
Programação Pareada
• Erro de um é detectado imediatamente
pelo outro (grande economia de tempo).
• Maior diversidade de idéias, técnicas,
algoritmos.
•Enquanto um escreve, o outro pensa em
contra exemplos, problemas de eficiência,
etc. (Vergonha de escrever código feio
(gambiarras) na frente do seu par).
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
107
Propriedade Coletiva do Código
• Padrões de estilo adotados pelo grupo
inteiro.
• O mais claro possível.
• XP não se baseia em documentações.
• Comentários sempre que necessários e
padronizados.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
108
Propriedade Coletiva do Código
• O código do XP pertence a todos.
• Todo código é integrado e testado depois
de algumas horas, um dia no máximo.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
109
XP e mudanças
• A sabedoria convencional na
engenharia de software é projetar para
mudança. Vale despender tempo e
esforço antecipando mudanças quando
isso reduz custos posteriores no ciclo de
vida.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
110
XP e mudanças
• O XP, contudo, mantém que isto não
vale a pena quando as mudanças não
podem ser confiavelmente previstas.
• Por outro lado, ele propõe melhorias
constantes de código (refactoring), para
tornar as mudanças mais fáceis quando
elas têm de ser implementadas.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
111
Quando XP Não Deve Ser
Experimentada?
• Quando o cliente não aceita as regras do
jogo.
• Quando o cliente quer uma especificação
detalhada do sistema antes de começar.
• Quando os programadores não estão
dispostos a seguir (todas) as regras.
• Se (quase) todos os programadores do time
não são experientes.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
112
Quando XP Não Deve Ser
Experimentada?
• Grupos grandes (>10 programadores).
• Quando feedback rápido não é possível:
• sistema demora 6h para compilar.
• testes demoram 12h para rodar.
• exigência de certificação que demora meses.
•Quando o custo de mudanças é essencialmente
exponencial.
•Quando não é possível realizar testes
(muito raro).
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
113
Modelo de Métodos Formais
Um modelo de sistema matemático é
transformado formalmente em uma
implementação
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
114
Modelo de Métodos Formais
• Compreende um conjunto de atividades
que determinam uma especificação
matemática para o software.
• A especificação de requisitos de software
é redefinida em uma especificação
formal detalhada, que é expressa em
uma notação matemática.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
115
Escolher um modelo de
desenvolvimento para o sistema
• Riscos na integração dos sub-sistemas 
Modelo Cascata
• Riscos significativos na interface com o
utilizador  Desenvolvimento evolutivo.
• Riscos de segurança 
Desenvolvimento Formal
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
116
Técnicas de 4a Geração
Obtenção dos Requisitos
Estratégia de “Projeto”
Implementação usando
4GL
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
Testes
117
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
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
118
Técnicas de 4a Geração
• O ambiente de desenvolvimento 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
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
119
Atividades das
Técnicas de 4a Geração
Obtenção dos
Requisitos
Estratégia de “Projeto”
Implementação usando 4GL
Testes
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
120
Atividades das
Técnicas de 4a Geração
• 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
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
121
Atividades das
Técnicas de 4a Geração
Obtenção dos Requisitos
Estratégia de
“Projeto” Implementação usando 4GL
Testes
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
122
Atividades das
Técnicas de 4a Geração
• 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
• 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, manutenibilidade ruim, má aceitação
do cliente)
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
123
Atividades das
Técnicas de 4a Geração
Obtenção dos Requisitos
Estratégia de “Projeto”
Implementação
usando 4GL
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
Testes
124
Atividades das
Técnicas de 4a Geração
• IMPLEMENTAÇÃO USANDO 4GL:
– os resultados desejados são
representados de modo que haja geração
automática de código.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
125
Atividades das
Técnicas de 4a Geração
Obtenção dos Requisitos
Estratégia de “Projeto”
Implementação usando 4GL
Testes
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
126
Atividades das
Técnicas de 4a Geração
• 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.
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
127
Combinando Paradigmas
obtenção preliminar dos
requisitos
análise dos
requisitos
prototipação
projeto
prototipação
enésima interação
técnicas
4G
codificação
modelo espiral
técnicas
4G
modelo espiral:
enésima interação
técnicas 4G
testes
Sistema Completo
Manutenção
Profa. Maria Auxiliadora
Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE
- Engenharia de Software - 8° Edição
128