3-processos-de-software

1. Prof. André Hora
Facom/UFMS
2018.1
Processos de Software
Engenharia de Software
1

2. Agenda
1. Motivação e definiçõ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 um roteiro 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 e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
7

8. 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

9. 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

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 e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
12

13. 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

14. Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
14

15. 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

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 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

21. 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

22. Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
22

23. 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

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
• 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

29. 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

30. Modelos Tradicionais
1. Cascata
2. Incremental
3. Evolucionário
• Prototipação
• Espiral
30

31. 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

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. Modelo Evolucionário:
Prototipação
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
• 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

39. 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

40. Iterativo e Incremental
Incremental
Iterativo + Incremental
40

41. 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

42. 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

43. 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

44. 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

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
45

46. 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

47. Agenda
1. Motivação e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
47

48. • 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

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 Atividades do
Processo Unificado
50

51. 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

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.
52

53. 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

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.
54

55. 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

56. Agenda
1. Motivação e definições
2. Fluxo de processo
3. Modelos tradicionais
4. Processo Unificado
56