Prof. André Hora
Facom/UFMS
2018.1
Processos de Software
Engenharia de Software
1
Agenda
1. Motivação e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
2
Processo de Software
• Conjunto de atividades para o desenvolvimento de
software com alta qualidade
• Ordenação das atividades no tempo e espaço
• Possui início e fim, inputs e outputs
• Um processo define:
• Quem faz, o que faz e quando fazer
• Nem sempre define como fazer
• Não existe um processo ideal
3
Vantagens
• Oferece um roteiro para o trabalho de ES
• Padroniza os artefatos gerados
• Melhora a comunicação entre stakeholders
• Diminui necessidade treinamento
4
Atividades Genéricas
1. Comunicação
2. Planejamento
3. Modelagem
4. Construção
5. Implantação
5
Modelos de Processo
• Modelos de processo
• Fornecem uma descrição do processo
• Especificam atividades, artefatos e papéis
• Exemplos:
• Cascata
• Incremental
• Evolucionário
• Processo Unificado
6
Agenda
1. Motivação e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
7
Fluxo de Processo:
Linear
Comunicação Planejamento Modelagem Construção Implantação
• Executa cada atividade de forma sequencial
• Começa na comunicação e termina na
implantação
8
Fluxo de Processo:
Iterativo
Comunicação Planejamento Modelagem Construção Implantação
• Repete uma ou mais atividades antes de ir
para a próxima
9
Fluxo de Processo:
Evolucionário
• Executa as atividades de forma circular
• Cada circuito leva a uma versão mais
completa do software
Comunicação
Planejamento
Modelagem
Construção
Implantação
Incremento
ou release
10
Fluxo de Processo:
Paralelo
• Executa uma ou
mais atividades
em paralelo
• Ex: modelagem de
um aspecto e
construção de outro
Comunicação Planejamento
Modelagem
Construção Implantação
11
Agenda
1. Motivação e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
12
Modelos Tradicionais
• Também conhecidos como modelos
prescritivos
• Devem ser adaptados ao time, problema
e projeto
• Modelos:
• Cascata
• Incremental
• Evolucionário (Prototipação & Espiral)
13
Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
14
Modelo Cascata
• Executa atividades de forma sequencial
• Começa na comunicação e termina na
implantação
• Difícil de ocorrer em projetos reais atualmente
Comunicação Planejamento Modelagem Construção Implantação
15
Modelo Cascata
Quando usar?
• Requisitos do problema são bem entendidos,
definidos e estáveis
• Quando há pouca chance dos requisitos mudarem
• Sistemas críticos
• Ex: melhoria de sistemas através da adição de novas
funcionalidades
Comunicação Planejamento Modelagem Construção Implantação
16
Modelo Cascata
Pontos fortes
• Paradigma + antigo, estável e testado
• Documentação robusta em cada atividade
• Pode ser combinado com outros modelos
• Simples; atividades são claras e bem definidas
Comunicação Planejamento Modelagem Construção Implantação
17
Modelo Cascata
Pontos fracos ?
Comunicação Planejamento Modelagem Construção Implantação
18
Modelo Cascata
Pontos fracos
• Projetos reais raramente seguem um fluxo sequencial
• Difícil para o cliente definir todos os requisitos antes
• Clientes devem esperar (versão do produto somente
ficará pronta no final do projeto)
• Difícil para lidar com mudanças inevitáveis de requisitos
• Atrasos em fase reflete nas demais
Comunicação Planejamento Modelagem Construção Implantação
19
Exercício 1
O modelo de ciclo de vida em Cascata é considerado o paradigma
mais antigo da Engenharia de Software. Apesar de apresentar
diversas desvantagens em relação ao modelo incremental, pode ser
útil principalmente em situações que:
a) a equipe de desenvolvimento é grande
b) os requisitos são fixos
c) o prazo é curto
d) o cliente é indeciso
e) os requisitos são instáveis
20
Exercício 1
O modelo de ciclo de vida em Cascata é considerado o paradigma
mais antigo da Engenharia de Software. Apesar de apresentar
diversas desvantagens em relação ao modelo incremental, pode ser
útil principalmente em situações que:
a) a equipe de desenvolvimento é grande
b) os requisitos são fixos
c) o prazo é curto
d) o cliente é indeciso
e) os requisitos são instáveis
21
Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
22
Modelo Incremental
• Combina elementos do modelo Cascata (fluxo
linear) & fluxo paralelo
• Cada sequência produz um incremento (isto é, um
produto operacional)
• Exemplo: Processador de Texto
• 1a entrega: abrir, editar e salvar documentos (núcleo do produto)
• 2a entrega: undo, redo, copiar, colar
• 3a entrega: corretor ortográfico
• 4a entrega: configuração de layout
23
Modelo Incremental
Quando usar?
• Requisitos de software estão razoavelmente
bem definidos
• Escopo de desenvolvimento não pode ser
puramente linear
• Necessidade de fornecer número limitado de
funcionalidades para usuários rapidamente
24
Modelo Incremental
Comunicação
Planejamento
Modelagem (análise + projeto)
Construção (código + teste)
Implantação (entrega + feedback)
Incremento #1
1a entrega
25
Modelo Incremental
Comunicação
Planejamento
Modelagem (análise + projeto)
Construção (código + teste)
Implantação (entrega + feedback)
Incremento #1
1a entrega
Incremento #2
2a entrega
26
Modelo Incremental
Comunicação
Planejamento
Modelagem (análise + projeto)
Construção (código + teste)
Implantação (entrega + feedback)
Incremento #1
1a entrega
Incremento #2
2a entrega
Incremento #n
entrega n
27
Pontos fortes
• Custo reduzido para acomodar mudanças
• Feedback do cliente
• Cliente acompanha evolução do sistema (desde o
início do projeto)
• Início do sistema pelas partes melhor entendidas
• Riscos críticos são resolvidos antes de grandes
investimentos
Modelo Incremental
28
Pontos fracos
• Cuidado ao definir o incremento para que não se
aproxime do Modelo Cascata
• Difícil gerência de software pois o sistema não é
completamente especificado anteriormente
• Produto pode se corromper com novos incrementos
e se tornar mal estruturado
Modelo Incremental
29
Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
30
Modelo Evolucionário
• Modelos evolucionários são iterativos (repete
atividades)
• Entregam uma versão mais completa do sistema a
cada iteração (curto prazo)
• Produtos crescem e mudam com o tempo
• Algumas funcionalidades são bem entendidas, mas
detalhes precisam ser definidos
• Modelos: Prototipação e Espiral
31
Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
32
Modelo Evolucionário:
Prototipação
• Frequentemente, clientes definem objetivos para o
software, mas não identificam claramente os requisitos
• Mecanismo para identificar e refinar requisitos de software
• Quando usar? Quando requisitos não estão claros
Comunicação
Planejamento
rápido
Modelagem
rápida
Construção
do protótipo
Implantação
33
Modelo Evolucionário:
Prototipação
34
Modelo Evolucionário:
Prototipação
Pontos fortes
• Facilita definição de requisitos
• Reduz riscos do desenvolvimento
• Protótipo pode reduzir custos das próximas
etapas
35
Modelo Evolucionário:
Prototipação
Pontos fracos
• Clientes devem estar cientes que produto
deverá ser refeito pois apenas um protótipo
foi construído
• Desenvolvedores não devem aproveitar
código do protótipo, geralmente desenvolvido
rapidamente e sem qualidade
36
Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
37
Modelo Evolucionário:
Espiral
• Combina a natureza iterativa
da Prototipação + aspectos
sistemáticos do Cascata
• Possibilita o desenvolvimento
rápido de versões mais
completas
• Prototipação no início e
incremental depois
38
Modelo Evolucionário:
Espiral
• Utilizado para minimizar
riscos (orientado a riscos)
• Pode ser utilizado em todo
ciclo de vida do produto
• Abordagem realista para
desenvolvimento de
software de grande porte
39
Iterativo e Incremental
Incremental
Iterativo + Incremental
40
Comparação:
Modelos Tradicionais
Propriedade Cascata Incremental Espiral
Especificação dos req.
Planejamento anterior
Retorna para fase anterior
Software de grande porte
Flexibilidade p/ mudança
Envolvimento do usuário
Fluxo
Fases sobreescritas
41
Comparação:
Modelos Tradicionais
Propriedade Cascata Incremental Espiral
Especificação dos req. sim, todos não todos e mudam não todos e mudam
Planejamento anterior sim sim sim
Retorna para fase anterior não sim sim
Software de grande porte não apropriado não apropriado apropriado
Flexibilidade p/ mudança difícil fácil fácil
Envolvimento do usuário somente no início intermediário alto
Fluxo linear linear + paralelo iterativo + evol.
Fases sobreescritas não sim (paralelo) não
42
Exercício 2
O modelo de processo de software que atende às
características do projeto que João e Maria irão desenvolver é:
43
Exercício 2
Evolucionário
O modelo de processo de software que atende às
características do projeto que João e Maria irão desenvolver é:
44
Exercício 3
Considere as seguintes afirmações feitas sobre um modelo de
processo de software.
I. Combina a natureza iterativa com aspectos sistemáticos do modelo
em cascata.
II. Pode ser aplicado em todo ciclo de vida de uma aplicação,
inclusive, após a entrega do software.
III. É um modelo que reconhece explicitamente a necessidade de
gerenciar riscos.
As três afirmações se referem ao:
a) Modelo cascata
b) Protótipo evolucionário
c) Processo unificado
d) Modelo espiral
e) Modelo incremental
45
Exercício 3
Considere as seguintes afirmações feitas sobre um modelo de
processo de software.
I. Combina a natureza iterativa com aspectos sistemáticos do modelo
em cascata.
II. Pode ser aplicado em todo ciclo de vida de uma aplicação,
inclusive, após a entrega do software.
III. É um modelo que reconhece explicitamente a necessidade de
gerenciar riscos.
As três afirmações se referem ao:
a) Modelo cascata
b) Protótipo evolucionário
c) Processo unificado
d) Modelo espiral
e) Modelo incremental
46
Agenda
1. Motivação e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
47
• Tentativa de unificar as melhores características dos
modelos tradicionais e do desenvolvimento ágil
• Reconhece a importância da comunicação com o
cliente e métodos para descrever seu ponto de vista
(casos de uso)
• Enfatiza a importância da arquitetura de software
• Fluxo iterativo e incremental
• Desenvolvimento guiado por risco
Processo Unificado (PU)
48
Processo Unificado (PU)
• Em suma: dirigido a caso de uso, centrado na
arquitetura, iterativo e incremental, focado em risco
• Fases:
• Concepção
• Elaboração
• Construção
• Transição
• Produção
49
Fases e Atividades do
Processo Unificado
50
Você não entendeu o desenvolvimento
iterativo ou PU quando…
• Você tenta definir a maior parte dos requisitos antes
do projeto/implementação
• Você gasta dias ou semanas em modelagem UML
• Você pensa que Concepção = Requisitos, Elaboração
= Projeto e Construção = Implementação
• Você pensa que a duração da iteração é de 3 meses
• Você tentar planejar um projeto em detalhes do
começo ao fim
51
Exercício 4
O Processo Unificado estabelece que as maiores porções (cargas
ou fluxos de trabalho) da Modelagem de Negócios e de Requisitos
são realizadas durante as fases de
a) Concepção e Elaboração.
b) Elaboração e Construção.
c) Transição e Construção.
d) Implementação e Transição
e) Implantação e Implementação.
52
Exercício 4
O Processo Unificado estabelece que as maiores porções (cargas
ou fluxos de trabalho) da Modelagem de Negócios e de Requisitos
são realizadas durante as fases de
a) Concepção e Elaboração.
b) Elaboração e Construção.
c) Transição e Construção.
d) Implementação e Transição
e) Implantação e Implementação.
53
Exercício 5
Na fase de Concepção do Processo Unificado são levantados os principais
requisitos e:
a) identificados os casos de uso de alto nível que implementam as
funcionalidades requeridas pelo cliente.
b) um modelo definitivo, com análise detalhada, será construído e refinado,
permitindo o entendimento da arquitetura do sistema.
c) a codificação do software será gerada e testada, dando origem ao
protótipo executável que será instalado no cliente.
d) as histórias de usuário que comporão o product backlog serão escritas e
classificadas por prioridade.
e) um modelo conceitual é criado, dando origem a um documento conhecido
como Lifecycle Architecture Milestone – LCA.
54
Exercício 5
Na fase de Concepção do Processo Unificado são levantados os principais
requisitos e:
a) identificados os casos de uso de alto nível que implementam as
funcionalidades requeridas pelo cliente.
b) um modelo definitivo, com análise detalhada, será construído e refinado,
permitindo o entendimento da arquitetura do sistema.
c) a codificação do software será gerada e testada, dando origem ao
protótipo executável que será instalado no cliente.
d) as histórias de usuário que comporão o product backlog serão escritas e
classificadas por prioridade.
e) um modelo conceitual é criado, dando origem a um documento conhecido
como Lifecycle Architecture Milestone – LCA.
55
Agenda
1. Motivação e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
56

Engenharia de Software: Processos de Software

  • 1.
    Prof. André Hora Facom/UFMS 2018.1 Processosde Software Engenharia de Software 1
  • 2.
    Agenda 1. Motivação edefinições 2. Fluxo de processo 3. Modelos tradicionais 4. Processo Unificado 2
  • 3.
    Processo de Software •Conjunto de atividades para o desenvolvimento de software com alta qualidade • Ordenação das atividades no tempo e espaço • Possui início e fim, inputs e outputs • Um processo define: • Quem faz, o que faz e quando fazer • Nem sempre define como fazer • Não existe um processo ideal 3
  • 4.
    Vantagens • Oferece umroteiro para o trabalho de ES • Padroniza os artefatos gerados • Melhora a comunicação entre stakeholders • Diminui necessidade treinamento 4
  • 5.
    Atividades Genéricas 1. Comunicação 2.Planejamento 3. Modelagem 4. Construção 5. Implantação 5
  • 6.
    Modelos de Processo •Modelos de processo • Fornecem uma descrição do processo • Especificam atividades, artefatos e papéis • Exemplos: • Cascata • Incremental • Evolucionário • Processo Unificado 6
  • 7.
    Agenda 1. Motivação edefinições 2. Fluxo de processo 3. Modelos tradicionais 4. Processo Unificado 7
  • 8.
    Fluxo de Processo: Linear ComunicaçãoPlanejamento Modelagem Construção Implantação • Executa cada atividade de forma sequencial • Começa na comunicação e termina na implantação 8
  • 9.
    Fluxo de Processo: Iterativo ComunicaçãoPlanejamento Modelagem Construção Implantação • Repete uma ou mais atividades antes de ir para a próxima 9
  • 10.
    Fluxo de Processo: Evolucionário •Executa as atividades de forma circular • Cada circuito leva a uma versão mais completa do software Comunicação Planejamento Modelagem Construção Implantação Incremento ou release 10
  • 11.
    Fluxo de Processo: Paralelo •Executa uma ou mais atividades em paralelo • Ex: modelagem de um aspecto e construção de outro Comunicação Planejamento Modelagem Construção Implantação 11
  • 12.
    Agenda 1. Motivação edefinições 2. Fluxo de processo 3. Modelos tradicionais 4. Processo Unificado 12
  • 13.
    Modelos Tradicionais • Tambémconhecidos como modelos prescritivos • Devem ser adaptados ao time, problema e projeto • Modelos: • Cascata • Incremental • Evolucionário (Prototipação & Espiral) 13
  • 14.
    Modelos Tradicionais 1. Cascata 2.Incremental 3. Evolucionário • Prototipação • Espiral 14
  • 15.
    Modelo Cascata • Executaatividades de forma sequencial • Começa na comunicação e termina na implantação • Difícil de ocorrer em projetos reais atualmente Comunicação Planejamento Modelagem Construção Implantação 15
  • 16.
    Modelo Cascata Quando usar? •Requisitos do problema são bem entendidos, definidos e estáveis • Quando há pouca chance dos requisitos mudarem • Sistemas críticos • Ex: melhoria de sistemas através da adição de novas funcionalidades Comunicação Planejamento Modelagem Construção Implantação 16
  • 17.
    Modelo Cascata Pontos fortes •Paradigma + antigo, estável e testado • Documentação robusta em cada atividade • Pode ser combinado com outros modelos • Simples; atividades são claras e bem definidas Comunicação Planejamento Modelagem Construção Implantação 17
  • 18.
    Modelo Cascata Pontos fracos? Comunicação Planejamento Modelagem Construção Implantação 18
  • 19.
    Modelo Cascata Pontos fracos •Projetos reais raramente seguem um fluxo sequencial • Difícil para o cliente definir todos os requisitos antes • Clientes devem esperar (versão do produto somente ficará pronta no final do projeto) • Difícil para lidar com mudanças inevitáveis de requisitos • Atrasos em fase reflete nas demais Comunicação Planejamento Modelagem Construção Implantação 19
  • 20.
    Exercício 1 O modelode ciclo de vida em Cascata é considerado o paradigma mais antigo da Engenharia de Software. Apesar de apresentar diversas desvantagens em relação ao modelo incremental, pode ser útil principalmente em situações que: a) a equipe de desenvolvimento é grande b) os requisitos são fixos c) o prazo é curto d) o cliente é indeciso e) os requisitos são instáveis 20
  • 21.
    Exercício 1 O modelode ciclo de vida em Cascata é considerado o paradigma mais antigo da Engenharia de Software. Apesar de apresentar diversas desvantagens em relação ao modelo incremental, pode ser útil principalmente em situações que: a) a equipe de desenvolvimento é grande b) os requisitos são fixos c) o prazo é curto d) o cliente é indeciso e) os requisitos são instáveis 21
  • 22.
    Modelos Tradicionais 1. Cascata 2.Incremental 3. Evolucionário • Prototipação • Espiral 22
  • 23.
    Modelo Incremental • Combinaelementos do modelo Cascata (fluxo linear) & fluxo paralelo • Cada sequência produz um incremento (isto é, um produto operacional) • Exemplo: Processador de Texto • 1a entrega: abrir, editar e salvar documentos (núcleo do produto) • 2a entrega: undo, redo, copiar, colar • 3a entrega: corretor ortográfico • 4a entrega: configuração de layout 23
  • 24.
    Modelo Incremental Quando usar? •Requisitos de software estão razoavelmente bem definidos • Escopo de desenvolvimento não pode ser puramente linear • Necessidade de fornecer número limitado de funcionalidades para usuários rapidamente 24
  • 25.
    Modelo Incremental Comunicação Planejamento Modelagem (análise+ projeto) Construção (código + teste) Implantação (entrega + feedback) Incremento #1 1a entrega 25
  • 26.
    Modelo Incremental Comunicação Planejamento Modelagem (análise+ projeto) Construção (código + teste) Implantação (entrega + feedback) Incremento #1 1a entrega Incremento #2 2a entrega 26
  • 27.
    Modelo Incremental Comunicação Planejamento Modelagem (análise+ projeto) Construção (código + teste) Implantação (entrega + feedback) Incremento #1 1a entrega Incremento #2 2a entrega Incremento #n entrega n 27
  • 28.
    Pontos fortes • Custoreduzido para acomodar mudanças • Feedback do cliente • Cliente acompanha evolução do sistema (desde o início do projeto) • Início do sistema pelas partes melhor entendidas • Riscos críticos são resolvidos antes de grandes investimentos Modelo Incremental 28
  • 29.
    Pontos fracos • Cuidadoao definir o incremento para que não se aproxime do Modelo Cascata • Difícil gerência de software pois o sistema não é completamente especificado anteriormente • Produto pode se corromper com novos incrementos e se tornar mal estruturado Modelo Incremental 29
  • 30.
    Modelos Tradicionais 1. Cascata 2.Incremental 3. Evolucionário • Prototipação • Espiral 30
  • 31.
    Modelo Evolucionário • Modelosevolucionários são iterativos (repete atividades) • Entregam uma versão mais completa do sistema a cada iteração (curto prazo) • Produtos crescem e mudam com o tempo • Algumas funcionalidades são bem entendidas, mas detalhes precisam ser definidos • Modelos: Prototipação e Espiral 31
  • 32.
    Modelos Tradicionais 1. Cascata 2.Incremental 3. Evolucionário • Prototipação • Espiral 32
  • 33.
    Modelo Evolucionário: Prototipação • Frequentemente,clientes definem objetivos para o software, mas não identificam claramente os requisitos • Mecanismo para identificar e refinar requisitos de software • Quando usar? Quando requisitos não estão claros Comunicação Planejamento rápido Modelagem rápida Construção do protótipo Implantação 33
  • 34.
  • 35.
    Modelo Evolucionário: Prototipação Pontos fortes •Facilita definição de requisitos • Reduz riscos do desenvolvimento • Protótipo pode reduzir custos das próximas etapas 35
  • 36.
    Modelo Evolucionário: Prototipação Pontos fracos •Clientes devem estar cientes que produto deverá ser refeito pois apenas um protótipo foi construído • Desenvolvedores não devem aproveitar código do protótipo, geralmente desenvolvido rapidamente e sem qualidade 36
  • 37.
    Modelos Tradicionais 1. Cascata 2.Incremental 3. Evolucionário • Prototipação • Espiral 37
  • 38.
    Modelo Evolucionário: Espiral • Combinaa natureza iterativa da Prototipação + aspectos sistemáticos do Cascata • Possibilita o desenvolvimento rápido de versões mais completas • Prototipação no início e incremental depois 38
  • 39.
    Modelo Evolucionário: Espiral • Utilizadopara minimizar riscos (orientado a riscos) • Pode ser utilizado em todo ciclo de vida do produto • Abordagem realista para desenvolvimento de software de grande porte 39
  • 40.
  • 41.
    Comparação: Modelos Tradicionais Propriedade CascataIncremental Espiral Especificação dos req. Planejamento anterior Retorna para fase anterior Software de grande porte Flexibilidade p/ mudança Envolvimento do usuário Fluxo Fases sobreescritas 41
  • 42.
    Comparação: Modelos Tradicionais Propriedade CascataIncremental Espiral Especificação dos req. sim, todos não todos e mudam não todos e mudam Planejamento anterior sim sim sim Retorna para fase anterior não sim sim Software de grande porte não apropriado não apropriado apropriado Flexibilidade p/ mudança difícil fácil fácil Envolvimento do usuário somente no início intermediário alto Fluxo linear linear + paralelo iterativo + evol. Fases sobreescritas não sim (paralelo) não 42
  • 43.
    Exercício 2 O modelode processo de software que atende às características do projeto que João e Maria irão desenvolver é: 43
  • 44.
    Exercício 2 Evolucionário O modelode processo de software que atende às características do projeto que João e Maria irão desenvolver é: 44
  • 45.
    Exercício 3 Considere asseguintes afirmações feitas sobre um modelo de processo de software. I. Combina a natureza iterativa com aspectos sistemáticos do modelo em cascata. II. Pode ser aplicado em todo ciclo de vida de uma aplicação, inclusive, após a entrega do software. III. É um modelo que reconhece explicitamente a necessidade de gerenciar riscos. As três afirmações se referem ao: a) Modelo cascata b) Protótipo evolucionário c) Processo unificado d) Modelo espiral e) Modelo incremental 45
  • 46.
    Exercício 3 Considere asseguintes afirmações feitas sobre um modelo de processo de software. I. Combina a natureza iterativa com aspectos sistemáticos do modelo em cascata. II. Pode ser aplicado em todo ciclo de vida de uma aplicação, inclusive, após a entrega do software. III. É um modelo que reconhece explicitamente a necessidade de gerenciar riscos. As três afirmações se referem ao: a) Modelo cascata b) Protótipo evolucionário c) Processo unificado d) Modelo espiral e) Modelo incremental 46
  • 47.
    Agenda 1. Motivação edefinições 2. Fluxo de processo 3. Modelos tradicionais 4. Processo Unificado 47
  • 48.
    • Tentativa deunificar as melhores características dos modelos tradicionais e do desenvolvimento ágil • Reconhece a importância da comunicação com o cliente e métodos para descrever seu ponto de vista (casos de uso) • Enfatiza a importância da arquitetura de software • Fluxo iterativo e incremental • Desenvolvimento guiado por risco Processo Unificado (PU) 48
  • 49.
    Processo Unificado (PU) •Em suma: dirigido a caso de uso, centrado na arquitetura, iterativo e incremental, focado em risco • Fases: • Concepção • Elaboração • Construção • Transição • Produção 49
  • 50.
    Fases e Atividadesdo Processo Unificado 50
  • 51.
    Você não entendeuo desenvolvimento iterativo ou PU quando… • Você tenta definir a maior parte dos requisitos antes do projeto/implementação • Você gasta dias ou semanas em modelagem UML • Você pensa que Concepção = Requisitos, Elaboração = Projeto e Construção = Implementação • Você pensa que a duração da iteração é de 3 meses • Você tentar planejar um projeto em detalhes do começo ao fim 51
  • 52.
    Exercício 4 O ProcessoUnificado estabelece que as maiores porções (cargas ou fluxos de trabalho) da Modelagem de Negócios e de Requisitos são realizadas durante as fases de a) Concepção e Elaboração. b) Elaboração e Construção. c) Transição e Construção. d) Implementação e Transição e) Implantação e Implementação. 52
  • 53.
    Exercício 4 O ProcessoUnificado estabelece que as maiores porções (cargas ou fluxos de trabalho) da Modelagem de Negócios e de Requisitos são realizadas durante as fases de a) Concepção e Elaboração. b) Elaboração e Construção. c) Transição e Construção. d) Implementação e Transição e) Implantação e Implementação. 53
  • 54.
    Exercício 5 Na fasede Concepção do Processo Unificado são levantados os principais requisitos e: a) identificados os casos de uso de alto nível que implementam as funcionalidades requeridas pelo cliente. b) um modelo definitivo, com análise detalhada, será construído e refinado, permitindo o entendimento da arquitetura do sistema. c) a codificação do software será gerada e testada, dando origem ao protótipo executável que será instalado no cliente. d) as histórias de usuário que comporão o product backlog serão escritas e classificadas por prioridade. e) um modelo conceitual é criado, dando origem a um documento conhecido como Lifecycle Architecture Milestone – LCA. 54
  • 55.
    Exercício 5 Na fasede Concepção do Processo Unificado são levantados os principais requisitos e: a) identificados os casos de uso de alto nível que implementam as funcionalidades requeridas pelo cliente. b) um modelo definitivo, com análise detalhada, será construído e refinado, permitindo o entendimento da arquitetura do sistema. c) a codificação do software será gerada e testada, dando origem ao protótipo executável que será instalado no cliente. d) as histórias de usuário que comporão o product backlog serão escritas e classificadas por prioridade. e) um modelo conceitual é criado, dando origem a um documento conhecido como Lifecycle Architecture Milestone – LCA. 55
  • 56.
    Agenda 1. Motivação edefinições 2. Fluxo de processo 3. Modelos tradicionais 4. Processo Unificado 56