Professional Documents
Culture Documents
Aula 2
Processo de Desenvolvimento de Software
2
Conteúdo da Aula
3
O que é um Processo?
4
Papéis e Atividades no Desenvolvimento de
Software
Time de Desenvolvimento
Gerente de Projetos Programadores
Analistas de Sistemas Testadores
Arquitetos de Software Designers
Problema
Implantação
Verificação
&Validação
Projeto da Solução
Testes
Desenvolvimento
Entendimento do Sistema
do problema
Usuários
5
Modelo de Ciclo de Vida em
Cascata
• Método sistemático e sequencial
• O resultado de uma fase se constitui na entrada
da outra
• Também conhecido como Modelo Clássico
6
Problemas Modelo de Ciclo de Vida em
Cascata
• Rigidez do processo
• Projetos reais raramente seguem um fluxo
seqüencial
• Assume que é possível declarar
detalhadamente todos os requisitos antes do
início das demais fases do desenvolvimento.
– propagação de erros pelas as fases do processo.
• Uma versão de produção do sistema não
estará pronta até que o ciclo do projeto de
desenvolvimento chegue ao final.
7
Cascata com Prototipação
8
Prototipação
9
Tipos de Protótipos
• Evolutivo
– Protótipo desenvolvido via programação para ser
usado de base para o produto final. Terá a cara do
produto final.
• Descartável
– Protótipo desenvolvido rapidamente via
programação e com baixa qualidade de código. Só
serve para validar os requisitos de usuários e
depois deve ser jogado fora.
• Baixa Fidelidade
– Protótipo desenvolvido em papel ou em
ferramentas gráficas, mas sem se preocupar com a
cara final do sistema
Engenharia de Software 10
Cascata com Prototipação
11
Modelo em V (Cascata com fases de Testes)
• Apesar de
adicionar uma
fase de teste
para cada fase
do cascata,
ainda possui a
característica de
entregar
software apenas
no final de todo
o processo
Engenharia de Software 12
Novo Modelo de Ciclo de Vida
13
Vários Mini-Cascatas
• Cada cascata é uma iteração...
14
Modelo Iterativo e Incremental
15
Modelo Iterativo e Incremental
Incremental
Iterativo
Modelo Iterativo e Incremental
• Vantagens
– Antecipa possíveis problemas no
desenvolvimento de software através de
versões preliminares
– Entrega acelerado dos serviços ao cliente
– Engajamento do usuário do sistema com o
processo de desenvolvimento
– Redução do risco de lançar o projeto no
mercado fora da data planejada. Identificando
os riscos numa fase inicial o esforço
despendido para gerenciá-los ocorre cedo,
quando as pessoas estão sob menos pressão
do que numa fase final de projeto.
17
Modelo Iterativo e Incremental
• Desvantagens
– Passa a ter uma camada a mais de
gerenciamento, que é o controle e a
ordem de cada iteração
– Problemas Contratuais pois o software
desenvolvido pode caminhar para um
produto muito diferente do que foi
contratado
18
Processo em Espiral – preocupação explícita
com os riscos do projeto de
desenvolvimento
19
Processo em Espiral
• O processo é representado por uma espiral
ao invés de ser representado como uma
sequencia de atividades
• Cada volta da espiral (loop) representa uma
única fase de desenvolvimento de software
• Capacita o desenvolvedor e o cliente a
entender e a reagir aos riscos em cada etapa
evolutiva
• Engloba as melhores características do ciclo
de vida Clássico como o da Prototipação
adicionando um novo elemento: a Análise de
Riscos
20
Questões que determinam a escolha
de um processo
• Quão bem os analistas e o cliente podem conhecer os
requisitos do sistema?
• Quão bem é compreendida a arquitetura do sistema?
• Qual o grau de confiabilidade necessário em relação
ao cronograma?
• Quanto planejamento é efetivamente necessário?
• Qual o grau de risco que este projeto apresenta?
• Será necessário entregar partes do sistema
funcionando antes de terminar o projeto todo?
• Será desenvolvido um único sistema ou uma família
de sistemas semelhantes?
• Qual o tamanho do projeto?
21
Questões de Concursos
24
O Processo Unificado - RUP
RUP é organizado:
• Por tempo
– Fases e Iterações
• Por Conteúdo
– Disciplinas
27
Organização do RUP por Tempo - Fases
28
Organização do RUP por Conteúdo - Disciplinas
29
Disciplinas X Fases
30
Iteração 1
Gráfico das Fases x Disciplinas
Foco nas
disciplinas de
Análise de
Negócios e
Requisitos
Engenharia de Software 31
Iteração 2
Gráfico das Fases x Disciplinas
O Foco é em
validar a
Arquitetura e o
que possuir
mais riscos
Engenharia de Software 32
Iteração 3
Gráfico das Fases x Disciplinas
O Foco é em
validar a
Arquitetura e o
que possuir
mais riscos
Engenharia de Software 33
Iteração 4,
Gráfico das Fases x Disciplinas 5, 6.... n
O Foco é na
construção do
software e nos
testes
Engenharia de Software 34
Iteração 4,
Gráfico das Fases x Disciplinas 5, 6.... n
O Foco é na
implantação do
sistema em
produção
Engenharia de Software 35
Conteúdo da Aula
36
Scrum
Engenharia de Software 37
Mas o que é o Scrum?
38
Framework Scrum
3 Papéis 3 Artefatos
4 Cerimônias
Scrum
Papéis no Scrum: Scrum Master
41
Papéis no Scrum: Product Owner
42
Papéis no Scrum: Time
43
Scrum
44
Planejamento da Sprint
• O Sprint é o ciclo de desenvolvimento de poucas
semanas de duração sobre o qual se estrutura o Scrum.
• Normalmente tem duração de 2 a 4 semanas.
• No início de cada Sprint é feito uma reunião de
planejamento da Sprint, no qual a equipe prioriza os
elementos do Backlog de produto a serem
implementados, e transfere estes elementos do Backlog
de produto para o Backlog da Sprint, ou seja, a lista de
funcionalidades a serem implementadas no ciclo que se
inicia.
• A equipe se compromete a desenvolver as
funcionalidades, e o Product Owner (PO) se compromete
a não trazer novas funcionalidades durante o mesmo
Sprint. Se novas funcionalidades forem descobertas,
serão abordadas em Sprints posteriores.
45
Itens de Topo do Backlog
47
Sprint
• O sprint é o ciclo de desenvolvimento de poucas
semanas de duração sobre o qual se estrutura o Scrum.
• No início de cada sprint é feito uma reunião de
planejamento da sprint, no qual a equipe prioriza os
elementos do backlog de produto a serem
implementados, e transfere estes elementos do backlog
de produto para o backlog da sprint, ou seja, a lista de
funcionalidades a serem implementadas no ciclo que se
inicia.
• A equipe se compromete a desenvolver as
funcionalidades, e o product owner (PO) se compromete
a não trazer novas funcionalidades durante o mesmo
sprint. Se novas funcionalidades forem descobertas,
serão abordadas em sprints posteriores.
48
Reunião Diária
49
Finalização da Sprint
50