Slides da disciplina de Engenharia de Software

1. Modelos de Processo de
Software
Leinylson Fontinele Pereira
Engenharia de Software

2. Conjunto de atividades relacionadas que levam à
produção de um produto de software (Sommerville, 2013)
Incluem:
1. Produtos gerados em cada atividade
2. Papéis envolvidos
3. Pré e pós-condições das atividades
Processo de software

3. •Processos de software são complexos e dependem de
vários fatores como:
• Produto a ser desenvolvido
• Equipe
• Recursos disponíveis
•Não existe um processo ideal, ele pode ser adaptado de
acordo com o contexto.
Motivação

4. •Envolvem criatividade e fatores humanos
•Decisões precisam ser tomadas ao longo do
processo
•Decisões erradas podem levar a prejuizos e perda
de oportunidades
Motivação
Modelos de Processo de Software
Como obter uma representação simplificada de um processo de software?

5. Modelos de Processo de Software
• Modelo Sequencial Linear ou Modelo Cascata
• Modelo de Prototipação
• Modelo RAD (Rapid Application Development)
• Modelos Evolutivos de Processo de Software
– Modelo Incremental
– Modelo Espiral
– Modelo de Montagem de Componentes
– Modelo de Desenvolvimento Concorrente
– Modelo Ágil
– Processo Unificado
• Modelo de Métodos Formais
• Técnicas de Quarta Geração
5

6. Modelo Cascata

7. Modelo 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
• O resultado de uma fase se constitui na
entrada da outra
7

8. Modelo Cascata
8
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção

9. Modelo Cascata
9
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
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)

10. Modelo Cascata
10
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
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

11. Modelo Cascata
11
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
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

12. Modelo Cascata
12
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Codificação
• Tradução das representações do projeto para
uma linguagem “artificial” resultando em
instruções executáveis pelo computador

13. Modelo Cascata
13
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Testes
• Concentra-se:
• Aspectos lógicos internos do software,
garantindo que todas as instruções tenham
sido testadas
• Aspectos funcionais externos, para descobrir
erros e garantir que a entrada definida produza
resultados que concordem com os esperados.

14. Modelo Cascata
14
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
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

15. Problemas com o Modelo Cascata
• 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. Uma versão
executável do software só fica disponível
numa etapa avançada do desenvolvimento
15

16. Variações do Modelo Cascata
(Wazlawick, 2013)
16

17. Variações do Modelo Cascata
(Wazlawick, 2013)
17

18. Modelo Cascata
• O modelo Cascata trouxe contribuições
importantes para o processo de
desenvolvimento de software:
– Imposição de disciplina, planejamento e
gerenciamento
– a implementação do produto deve ser postergada
até que os objetivos tenham sido completamente
entendidos
18

19. Modelo de Prototipação

20. Modelo de Prototipação
• o objetivo é entender os requisitos do usuário
e, assim, obter uma melhor definição dos
requisitos do sistema.
• possibilita que o desenvolvedor crie um
modelo (protótipo)do software que deve ser
construído
20

21. O Paradigma de Prototipação para
obtenção dos requisitos
21
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo

22. O Paradigma de Prototipação para
obtenção dos requisitos
22
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo
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.

23. O Paradigma de Prototipação para
obtenção dos requisitos
23
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo
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)

24. O Paradigma de Prototipação para
obtenção dos requisitos
24
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo
3- CONSTRUÇÃO PROTÓTIPO:
implementação rápida do
projeto

25. O Paradigma de Prototipação para
obtenção dos requisitos
25
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo
4- AVALIAÇÃO DO PROTÓTIPO:
cliente e desenvolvedor avaliam o
protótipo

26. O Paradigma de Prototipação para
obtenção dos requisitos
26
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo
5- REFINAMENTO DO PROTÓTIPO: cliente
e desenvolvedor refinam os requisitos
do software a ser desenvolvido.

27. O Paradigma de Prototipação para
obtenção dos requisitos
27
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo
CONSTRUÇÃO
DO PRODUTO

28. O Paradigma de Prototipação para
obtenção dos requisitos
28
Obter Requisitos
Elaborar Projeto Rápido
Construir Protótipo
Avaliar Protótipo
Refinamento do Protótipo
CONSTRUÇÃO
DO PRODUTO
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.

29. 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
• Desenvolvedor frequentemente faz uma
implementação comprometida, com o
objetivo de produzir rapidamente um
protótipo
29

30. Modelo de Prototipação
• Ainda que possam ocorrer problemas, a
prototipação é um ciclo de vida eficiente.
• O cliente e o desenvolvedor devem concordar
que o protótipo seja construído para servir
como um mecanismo a fim de definir os
requisitos
30

31. Modelo RAD

32. Modelo RAD
• RAD (Rapid Application Development) é um
modelo sequencial linear que enfatiza um
ciclo de desenvolvimento extremamente curto
• O desenvolvimento rápido é obtido usando
uma abordagem de construção baseada em
componentes.
32

33. Modelo RAD
• Os requisitos devem ser bem entendidos e o alcance
do projeto restrito
• Utilizado principalmente para aplicações de sistema
de informação
• Cada função principal pode ser direcionada para uma
equipe RAD separada e então integrada para formar
o todo.
33

34. Modelo RAD
34
Modelagem do
Negócio
Modelagem dos
Dados
Modelagem do
Processo
Geração da
Aplicação
Teste e Modificação
Equipe #1
Modelagem
do Negócio
Modelagem
dos Dados
Modelagem
do Processo
Geração da
Aplicação
Teste e
Modificação
Equipe #2 Modelagem
do Negócio
Modelagem
dos Dados
Modelagem
do Processo
Geração da
Aplicação
Teste e
Modificação
Equipe #3
60 a 90 dias

35. Modelo RAD
• Desvantagens:
– Exige recursos humanos suficientes para todas as
equipes
– Exige que desenvolvedores e clientes estejam
comprometidos com as atividades de “fogo-
rápido” a fim de terminar o projeto num prazo
curto
35

36. Modelo RAD
• Nem todos os tipos de aplicação são
apropriadas para o RAD:
– Deve ser possível a modularização efetiva da
aplicação
– Se alto desempenho é uma característica e o
desempenho é obtido sintonizando as interfaces
dos componentes do sistema, a abordagem RAD
pode não funcionar
36

37. Modelos Evolutivos

38. Modelos Evolutivos
• São modelos utilizados no desenvolvimento
de softwares que precisam evoluir com o
passar do tempo
• Modelos evolutivos são iterativos
• Possibilitam o desenvolvimento de versões
cada vez mais completas
38

39. Modelos Evolutivos
• Necessidades de evolução:
– Mudanças nos requisitos de produto e de negócio
durante o desenvolvimento
– Prazo de entrega apertado - impossível a
conclusão do produto completo
– Quando um conjunto de requisitos importantes é
bem conhecido, porém os detalhes ainda devem
ser definidos
39

40. Modelos Evolutivos
• Tipos de Modelos Evolutivos:
– O Modelo Incremental
– O Modelo Espiral
– O Modelo de Montagem de Componentes
– O Modelo de Desenvolvimento Concorrente
– O Modelo Ágil
– O Processo Unificado

41. Modelo Incremental

42. Modelo Incremental
• Combina elementos do modelo cascata
(aplicado repetidamente) com características
da prototipação (interação com cliente)
• Objetivo:
– Interagir com o usuário para descobrir os
requisitos de forma gradativa (incremental), até a
conclusão do produto final
42

43. Modelo Incremental
43
Versão Inicial
Descrição
geral Descrição
geral
Descrição
geral
Versões
Intermediárias
Versão Final
Análise Projeto
Codificação
Teste
Engenharia de
sistemas/informação

44. Modelo Incremental
• Versão inicial:
– É o núcleo do produto (a parte mais importante)
• Evolui quando o usuário solicita a adição de novas
características
– Apropriado para:
• Sistemas pequenos, ou
• Difíceis de estabelecer uma especificação detalhada
dos requisitos, a priori
44

45. Modelo Incremental
• Novas versões
– Planejadas com o foco no controle de riscos
técnicos (Ex. disponibilidade de equipamento)
45

46. Modelo Espiral

47. Modelo Espiral
• Engloba as melhores características do Modelo Cascata
e da Prototipação, adicionando um novo elemento: a
Análise de Riscos
– Modelo Cascata
• Segue a abordagem de passos sistemáticos
– Prototipação
• Interatividade com o usuário
– Modelo Espiral
• Sistematização (Cascata) + interatividade (prototipação) + Análise
de Riscos (novo)

48. Modelo Espiral
• Dividido em uma série de regiões (3 a 6) que
delimitam atividades de arcabouço
• Usa a Prototipação em qualquer etapa da
evolução do produto:
– Mecanismo de redução de riscos

49. Modelo Espiral
• Abordagem realista para o desenvolvimento
de sistemas de grande porte
• Exige a consideração direta dos riscos técnicos
em todos os estágios do projeto
– Aplicado adequadamente, pode reduzir os riscos
antes que eles fiquem problemáticos

50. Modelo Espiral
• Funcionamento:
– Para cada volta na espiral:
• Determinar os objetivos, alternativas e restrições
relacionadas à iteração que vai se iniciar
• Identificar e resolver os riscos relacionados
• Avaliar alternativas disponíveis. Podem ser feitos protótipos
para analisar a viabilidade de diferentes alternativas
• Desenvolver os artefatos relacionados à iteração corrente e
valida-los
• Planejar a próxima iteração
• Obter concordância em relação ao planejamento

51. Modelo Espiral (com 4 regiões)
51
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integr ation
testAcceptance
testService
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E RESTRIÇÕES
PLANEJAR PRÓXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL

52. Modelo Espiral (com 4 regiões)
52
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integr ation
testAcceptance
testService
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E RESTRIÇÕES
PLANEJAR PRÓXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL
cada “loop” no
espiral representa
uma fase do
processo de
software

53. Modelo Espiral (com 4 regiões)
53
Risk
analysis Proto-
type 1
Concept of
Operation
Requirements plan
Life-cycle plan
REVIEW
o “loop” mais
interno está
concentrado nas
possibilidades do
sistema

54. Modelo Espiral (com 4 regiões)
54
Risk
analysis
Prototype
Simulations, models, benchmarks
SW
requirements
Requirement
validation
Development
plan
o próximo “loop”
está concentrado na
definição dos
requisitos do
sistema

55. Modelo Espiral (com 4 regiões)
55
Risk
analysis
prototype 3
simulations, models, benchmarks
Design
V&V
Product
design
Integration
and test plan
o “loop” um pouco
mais externo está
concentrado no
projeto do sistema

56. Modelo Espiral (com 4 regiões)
56
Risk
nalysis
Opera-
tional
protoype
Simulations, models, benchmarks
Detailed
design
Code
Unit test
Integration
testAcceptance
testService
um “loop” ainda
mais externo está
concentrado na
construção do
sistema

57. Modelo Espiral (com 4 regiões)
57
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integr ation
testAcceptance
testService
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E RESTRIÇÕES
PLANEJAR PRÓXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL
• Não existem fases fixas no modelo
• As fases mostradas na figura são meramente
exemplos
• A gerência decide como estruturar o projeto
em fases

58. O Modelo Espiral (com 4 regiões)
58
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integr ation
testAcceptance
testService
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
DETERMINAR OBJETIVOS,
ALTERNATIVAS E RESTRIÇÕES
PLANEJAR PRÓXIMA FASE
AVALIAR ALTERNATIVAS
IDENTIFICAR, RESOLVER RISCOS
DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL
AVALIAÇÃO E
REDUÇÃO DE
RISCOS
➢ Cada “loop” do espiral é dividido em 4
setores
DESENVOLVIMENTO E
VALIDAÇÃO
PLANEJAMENTO
DEFINIÇÃO DE
OBJETIVOS

59. Modelo Espiral (com 4 regiões)
59
são definidos objetivos específicos para a fase
do projeto
são identificadas restrições sobre o processo e
o produto
é projetado um plano de gerenciamento
detalhado
são identificados riscos do projeto
dependendo dos riscos, estratégias
alternativas podem ser planejadas
DEFINIÇÃO DE
OBJETIVOS

60. Modelo Espiral (com 4 regiões)
60
AVALIAÇÃO E
REDUÇÃO DE
RISCOS
para cada um dos riscos identificados, uma
análise detalhada é executada.
passos são tomados para reduzir o risco

61. Modelo Espiral (com 4 regiões)
61
AVALIAÇÃO E
REDUÇÃO DE
RISCOS
depois da avaliação do risco, um modelo de
desenvolvimento é escolhido para o
sistema DESENVOLVIMENTO
E VALIDAÇÃO
DEFINIÇÃO DE
OBJETIVOS

62. Modelo Espiral (com 4 regiões)
62
AVALIAÇÃO E
REDUÇÃO DE
RISCOS
DESENVOLVIMENTO
E VALIDAÇÃO
PLANEJAMENTO
o projeto é revisto e é tomada uma decisão
de continuidade
se é decidido continuar, são projetados
planos para a próxima fase do projeto
(próximo “loop” )
DEFINIÇÃO DE
OBJETIVOS

63. Modelo Espiral (com 6 regiões)
63
Planejamento
Análise de Riscos
Engenharia
Construção e Liberação
Avaliação do Cliente
Comunicação com
Cliente

64. Modelo 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
• Usa a Prototipação, em qualquer etapa da
evolução do produto, como mecanismo de
redução de riscos
64

65. Principais Fases do Modelo Espiral
• Desenvolvimento de Objetivos
• Avaliação e Redução de Riscos
• Desenvolvimento e Validação
• Planejamento

66. Principais Fases do Modelo Espiral
• Desenvolvimento de objetivos
– Definição dos objetivos específicos
– Identificação de restrições do projeto e produto
– Elaboração do plano de gerenciamento
– Identificação do riscos do projeto
• Os risco identificados influenciam no planejamento das
estratégias

67. Principais Fases do Modelo Espiral
• Avaliação de redução de riscos
– Todos os riscos identificados são analisados
detalhadamente
– Devem ser planejadas e executadas ações para reduzir
os riscos
– Ex: Se houver o risco de que existem requisitos não
apropriados, pode-se desenvolver protótipos do
sistema para verificar a importância dos requisitos

68. Principais Fases do Modelo Espiral
• Desenvolvimento e validação
– Após a avaliação de risco, um modelo de
desenvolvimento de sistema deve ser selecionado:
• Se os riscos de interfaces forem os principais riscos
identificados pode-se adotar o modelo de prototipação
• Se o risco de integração de subsistemas for o principal
risco identificado pode-se escolher o modelo em
cascata

69. Principais Fases do Modelo Espiral
• Planejamento
– O projeto é revisado e a decisão de prosseguir ao
próximo loop é tomada
– Para o próximo loop o planejamento será
elaborado para a próxima fase do projeto

70. Vantagens
• É, atualmente, a abordagem mais realística para
o desenvolvimento de software em grande
escala.
• Estimativas (por exemplo: cronograma) tornam-
se mais realísticas com o progresso do trabalho.
• É mais versátil para lidar com mudanças.
• Fácil de decidir quando testar
• Não faz distinção entre desenvolvimento e
manutenção.

71. Desvantagens
• Pode ser difícil convencer os clientes de que a
abordagem evolucionária é controlável.
• Avaliação dos riscos exige muita experiência para
o sucesso.
– Se um risco não for descoberto, inevitavelmente
ocorrerão problemas.
• O modelo é relativamente novo e não tem sido
amplamente utilizado.

72. Atividade

73. Atividade
• Crie uma empresa de desenvolvimento de Software e dê um nome
fantasia para sua empresa
• A empresa é formada por uma equipe de 4 desenvolvedores:
– Forme sua equipe e escolha o gerente de projeto
• Baseado nos modelos de processo (Cascata, Prototipação,
Incremental e Espiral) defina uma abordagem para o
desenvolvimento de software (adotado na empresa) adotando as
melhores características e as vantagens de cada modelo
• Gravem em vídeo a rotina de um dia da empresa (sejam criativos!)