1-Principais - Paradigmas 2020

Engenharia de Software
Tema da Aula
Modelos de Ciclos de Vida de Software
1 – Modelo em Cascata (Waterfall)
Engenharia
de Ciclos de Vida de Software
Software
Existem vários modelos de ciclo de vida de software

(também chamados de Paradigmas da Engenharia de
Software), alguns cobrindo apenas as fases do processo
que vão da concepção ao desenvolvimento, enquanto
outros cobrem concepção, desenvolvimento, implantação
e manutenção.
São modelos prescritivos porque prescrevem um conjunto de

elementos de processo num fluxo de trabalho (sequência
e comunicação entre esses elementos).
Engenharia
de Ciclos de Vida de Software
Software
Existem vários modelos de ciclo de vida de software

(também chamados de Paradigmas da Engenharia de
Software), alguns cobrindo apenas asPRESCREVER
fases do processo
ORDENAR DE
que vão da concepção ao desenvolvimento, enquanto
MANEIRA EXPLÍCITA
outros cobrem concepção, desenvolvimento, implantação
PREVIAMENTE
e manutenção.
São modelos prescritivos porque prescrevem um conjunto de

elementos de processo num fluxo de trabalho (sequência
e comunicação entre esses elementos).
Engenharia
de
Ciclos de Vida de Software
Software Modelo Clássico (Cascata)
Modelo Waterfall (cascata):
Modelo didático que divide o ciclo de vida de 5 a 12 fases
(cf. o autor). Criado por Winston W. Royce (1970) e
aperfeiçoado por Barry Boehm (1976).
Adequação:
✓Projetos grandes (cobre todas as fases do ciclo de vida),
✓Os requisitos estão claramente definidos no início do
desenvolvimento
✓Complexidade baixa
✓Riscos técnicos e de projeto bem entendidos.
Engenharia
de
Engenharia
de
Engenharia
de
1) Definição de Requisitos:
Foco:
1) No usuário (voz do usuário)
2) No processo
3) Na documentação
4) No sistema antigo ou legado (quando existe)
Tarefas:
Extrair os requisitos, especificar cada um deles, redigir
uma Definição de Requisitos e validá-los junto ao usuário.
Engenharia
de
Definição de Requisitos:
Ferramentas:
Não tem.
Técnicas:
Psicologia
Entrevistas
Questionários
Mapeamento de Processos
JAD, PIECES, Benchmarking, Brainstorming, etc.
Engenharia
de
Engenharia
de
✓ Requisitos Funcionais:
O que o produtos de software deve fazer
(funcionalidades).
• Casos de Uso ou eventos
• Atividades do Processo
• Aquisição de informações
• Tratamento das informações
• Armazenamento das informações
• Distribuição das informações
• Acionamento de dispositivos
Engenharia
de
✓ Requisitos Não Funcionais:

Metas e restrições que o sistema deve atender.
1. Confiabilidade
2. Disponibilidade (missão crítica)
3. Segurança
4. Portabilidade
5. Economia
6. Compatibilidade (legados)
7. Flexibilidade
8. Acurácia (precisão)
9. Adequação a Legislação
10. Desempenho
11. Problemas da interface homem-máquina
12. Restrições físicas e operacionais
Etc.
Engenharia
de
Engenharia
de
2) Análise de Requisitos:
Foco:
Nos objetivos, restrições, alternativas e riscos de cada
alternativa.
Ferramentas:
Metodologias e técnicas de modelagem e análise,
ferramentas (editores gráficos, CASE’s, etc).
Engenharia
de
Análise de Requisitos:
Definição detalhada do domínio das informações e do
domínio das funcionalidades requeridas para o software.
Modelos de Modelos de
Dados Funcionalidade
SISTEMA
Engenharia
de
Análise de Requisitos, Definição de Requisitos ou
Engenharia de Requisitos:
Alguns autores apresentam como uma só atividade:
Engenharia
de
Análise de Requisitos, Definição de Requisitos ou
Engenharia de Requisitos:
Obter uma compreensão completa dos requisitos de
software, através de:
Descoberta
Refinamento
Especificação
Técnica
Modelagem
Engenharia
de
Engenharia
de
3) Projeto de Software:
Foco:
Nos dados, componentes de software e no produto final
de software (projeto arquitetural do produto de software).
Ferramentas:
Metodologias e técnicas de modelagem e análise,
ferramentas (editores gráficos, ferramentas CASE, etc).
Engenharia
de
ARQUITETURA DE SOFTWARE
SISTEMA MÓDULO INFORMAÇÕES
PRINCIPAL
FUNÇÕES
MÓDULO 01 MÓDULO 02 MÓDULO 03
MÓDULO 04 MÓDULO 05 MÓDULO 06 MÓDULO 04 MÓDULO 07
MÓDULO 09
MÓDULO 09
Engenharia
de
ARQUITETURA DE SOFTWARE
SISTEMA MÓDULO INFORMAÇÕES
PRINCIPAL
FUNÇÕES
MÓDULO 04 MÓDULO 05 MÓDULO 06 MÓDULO 04 MÓDULO 07
MÓDULO 09
MÓDULO 09 REUSABILIDADE
Engenharia
de
Projeto de Software:
Representação das funções do sistema, em uma forma
que possa ser transformada em programas executáveis.
Decompor o produto de software desejado em partes

(programas, módulos, componentes, etc).
Recompor, pensando no produto final e nas arquiteturas

candidatas.
Engenharia
de
Projeto de Software:
O projeto de interfaces (IHC) é um projeto específico
dentro do ciclo de vida do software.
Com a tendência de prototipação das interfaces para o
usuário validar, esse tipo de projeto está se tornando
presente também na fase de definição de requisitos.

Engenharia
de
Engenharia
de
4) Codificação:
Foco:
Nos algoritmos e nas linguagens de programação
(sintaxe, limitações, funcionalidade disponível, etc.)
Ferramentas:
Linguagens de programação, geradores de código fonte,
CASE de amplo espectro, etc.
Engenharia
de
4) Codificação:
Engenharia
de
4) Codificação:
ESTA METAMORFOSE AMBULANTE

Raul Seixas
Engenharia
de
4) Codificação:
Engenharia
de
4) Codificação:
Engenharia
de
4) Codificação:
Engenharia
de
4) Codificação:
Engenharia
de
Engenharia
de
5) Teste:
Foco:
Nas especificações e nas saídas do produto de software.
Ferramentas:
Técnicas de testagem, procedimentos da Qualidade,
procedimentos da instalação, ferramentas de testagem.
Engenharia
de
Teste:
• Testar contra especificações de requisitos
• Testar contra padrões da instalação

• Nomenclatura de campos, tabelas
• Padrões de interfaces
• Padrões da qualidade
Engenharia
de
Teste:
• Teste Unitário (cada unidade do software)

• Teste de Integração (todos os componentes, a partir
de uma estratégia de aglutinação progressiva)
• Teste de Validação ou Aceitação: (conformidade com
os Requisitos).
• Teste de Sistema (integração entre o sistema gerado e
outros sistemas com os quais haverá troca de
informações).
Engenharia
de
Teste:
Testes especiais:
• Performance
• Segurança
• Stress etc.
Teste nas áreas de produção:

• Teste inicial (alfa)
• Beta teste
Engenharia
de
Engenharia
de
6) Manutenção:
Foco:
Depende do tipo de manutenção (algoritmo, legislação,
estrutura organizacional, processo, tecnologia, etc.)
Ferramentas:
Linguagens de programação, ferramentas CASE, etc.
Engenharia
de
Manutenção:
Fase mais longa do ciclo.
Tipos de manutenção:
• Corrigir erros remanescentes
• Adaptar a novas situações e necessidades
• Preparar para futuras alterações
Engenharia
de
Manutenção:
Engenharia
de
Falhas do modelo Cascata:
Como todo modelo, tem suas limitações.
1) Imagina o processo como sendo sequencial e

progressivo, onde cada fase é estanque, mesmo com as
setas indicando retorno a fases anteriores, cada fase é
vista isoladamente. Tenta manter a linearidade (similar a
uma linha de produção-manufatura) para manter o
processo previsível e de fácil gerenciamento.
Engenharia
de
2) A fase de Análise só se inicia após obtenção dos
requisitos, que devem ser:
• Completos
• Corretos
• Não ambíguos
• Não redundantes
• Sem detalhes de implementação

Engenharia
de
3) Não estimula o desenvolvimento conjunto
(desenvolvedor e usuário). O trabalho com o usuário está
restrito à fase de Definição de Requisitos.
4) A entrega do produto só ocorre depois de terminado.

Quando o usuário tem a chance de ver se o produto
atende suas necessidades e expectativa, ele já está
pronto.
Engenharia
de
5) Não prevê um “Estudo de Viabilidade”, que deveria

iniciar ao término da Definição de Requisitos e, no
máximo prolongar-se até o início da Análise.
Sua finalidade é evitar que recursos sejam gastos na

tentativa de solucionar o problema de maneira errada,
além de verificar se a solução é viável do ponto de vista
econômico.
Engenharia
de
Ver vídeo:
2 ENGENHEIROS E 8 MILHÕES
(Mário Sergio Cortella)
https://www.youtube.com/watch?v=p-okhv8mY4M
Meus vídeos\EngSof\2 Engenheiros e 8 milhoes

Engenharia
de
O “Estudo de Viabilidade” dever avaliar:
• Se o problema é passível de solução via software
• As possíveis soluções (desenvolver, comprar)
• Estudo de custos x benefícios
Deve conter:
• Definição do problema
• Possíveis soluções (inclusive alternativas)
• Benefício de cada uma delas
• Custo e Prazo de cada uma delas (todos os recursos
necessários)
Engenharia
de
Estudo de Viabilidade:
No Estudo de Viabilidades investimos poucos recursos
para termos certeza de que o projeto é viável, evitando
perder muitos recursos.
A análise de riscos (mitigação* de riscos) é uma das
formas de evitar grandes perdas de recurso durante ou no
término do projeto.
(*)Mitigar: atenuar, diminuir, reduzir.
Engenharia
de
6) Não menciona o Gerenciamento do Processo de
Software, que ocorre simultaneamente à construção do
produto e é altamente influenciado pela complexidade
deste último.
Engenharia
de
GERENCIAMENTO DO PROJETO
Engenharia
de
Gerenciar o processo de produção do software:
Objetivo: Controlar o processo.
1. Adaptar o modelo de gerenciamento do processo
ao tipo de ciclo de vida e tipo de produto.
2. Definir Políticas (autorização de acessos, períodos
de backup, responsabilidades, documentação
obrigatória, etc).
3. Obter recursos
4. Gerenciar recursos
5. Corrigir desvios do projeto e monitorar prazos e
custos.
Engenharia
de
Software Modelo Clássico Atualizado

1-Principais - Paradigmas 2020

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1-Principais - Paradigmas 2020

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Existem vários modelos de ciclo de vida de software

São modelos prescritivos porque prescrevem um conjunto de

Existem vários modelos de ciclo de vida de software

São modelos prescritivos porque prescrevem um conjunto de

✓ Requisitos Não Funcionais:

MÓDULO 01 MÓDULO 02 MÓDULO 03

MÓDULO 04 MÓDULO 05 MÓDULO 06 MÓDULO 04 MÓDULO 07

MÓDULO 08 MÓDULO 10 MÓDULO 11

MÓDULO 01 MÓDULO 02 MÓDULO 03

MÓDULO 04 MÓDULO 05 MÓDULO 06 MÓDULO 04 MÓDULO 07

MÓDULO 08 MÓDULO 10 MÓDULO 11

Decompor o produto de software desejado em partes

Recompor, pensando no produto final e nas arquiteturas

O projeto de interfaces (IHC) é um projeto específico

dentro do ciclo de vida do software.

Com a tendência de prototipação das interfaces para o

usuário validar, esse tipo de projeto está se tornando

presente também na fase de definição de requisitos.

ESTA METAMORFOSE AMBULANTE

• Testar contra especificações de requisitos

• Testar contra padrões da instalação

• Teste Unitário (cada unidade do software)

Teste nas áreas de produção:

1) Imagina o processo como sendo sequencial e

• Sem detalhes de implementação

4) A entrega do produto só ocorre depois de terminado.

5) Não prevê um “Estudo de Viabilidade”, que deveria

Sua finalidade é evitar que recursos sejam gastos na

Meus vídeos\EngSof\2 Engenheiros e 8 milhoes

No Estudo de Viabilidades investimos poucos recursos

para termos certeza de que o projeto é viável, evitando

perder muitos recursos.

A análise de riscos (mitigação* de riscos) é uma das

formas de evitar grandes perdas de recurso durante ou no

Falhas do modelo Cascata:

6) Não menciona o Gerenciamento do Processo de

Software, que ocorre simultaneamente à construção do

produto e é altamente influenciado pela complexidade

Você também pode gostar