[02] APS Processo Desenv de Sftw

Prévia do material em texto

1
Análise e Projeto de Sistemas
Aula 2
Processo de Desenvolvimento de Software
Prof. Rafael Targino
rtargino@unicarioca.edu.br
2
O conteúdo desta aula foi parcialmente 
baseado nos slides disponíveis para o livro:
Engenharia de Software – Conceitos e Práticas
Raul Sidnei Wazlawick, Elsevier, 1a edição, 2013
2
3
Conteúdo da Aula
• Processo de Desenvolvimento de Software 
Clássicos
– Cascata
– Prototipação
– Iterativo e Incremental
– Espiral
• RUP
• Metodologias Ágeis
4
O que é um Processo?
• Processo é um conjunto de atividades que 
são executadas de forma sequencial para 
atingir algum objetivo
– Atividades Interdependentes
– Com responsáveis
– Com entradas e saídas definidas
3
5
Papéis e Atividades no Desenvolvimento de 
Software
Usuários
Problema
Entendimento 
do problema
Verificação 
&Validação
Projeto da Solução
Testes
Time de Desenvolvimento
Programadores
Testadores
Designers
Gerente de Projetos
Analistas de Sistemas
Arquitetos de Software
Implantação
Levantamento 
de Requisitos
Análise de 
Requisitos
Projeto Implementação Testes Implantação
Desenvolvimento 
do Sistema
6
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
4
7
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. 
8
Cascata com Prototipação
• Tem como objetivo assegurar que os 
requisitos do sistema foram bem entendidos. 
• Técnica frequentemente aplicada quando:
– há dificuldades no entendimento dos requisitos 
do sistema
– há requisitos que precisam ser mais bem 
entendidos
– O próprio usuário não tem compreensão completa 
do problema
5
9
Prototipação
10
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
6
11
Cascata com Prototipação
12
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
7
13
Novo Modelo de Ciclo de Vida
Vamos assumir nossa incompetência em 
planejamento a longo prazo e vamos dividir o 
planejamento em pequenos pedaços 
chamados de iteração!
 Ciclo de Vida Incrementa e Iterativo
14
Vários Mini-Cascatas
• Cada cascata é uma iteração...
I t e r a ç ã o 1 I t e r a ç ã o 2 I t e r a ç ã o 3
8
15
Modelo Iterativo e Incremental
• Dividir para conquistar
• O desenvolvimento ocorre em várias 
iterações, cada uma delas resultando em 
extensão de funcionamento e/ou maior 
conhecimento do sistema
• As funcionalidades mais críticas devem ser 
tratadas nas primeiras iterações
Modelo Iterativo e Incremental
Incremental
Iterativo
9
17
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. 
18
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
10
19
Processo em Espiral – preocupação explícita 
com os riscos do projeto de 
desenvolvimento
20
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
11
21
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?
22
Questões de Concursos
Dentro da Engenharia de Software, encontramos uma 
gama de conceitos. Embasado nisso, analise as 
assertivas e assinale a alternativa que aponta a(s) 
correta(s) sobre Processos de Software. 
I. Podemos definir um processo de software como um 
conjunto de atividades relacionadas que levam à 
produção de um produto de software. 
II. A definição das funcionalidades do software e as 
restrições a seu funcionamento devem ser definidas 
na produção de um software. Essa atividade está 
incluída no processo de software. 
12
23
Questões de Concursos
III. A validação de software também é uma atividade 
presente no processo de software. 
IV. Os processos de software são complexos e, como 
todos os processos intelectuais e criativos, dependem 
de pessoas para tomar decisões e fazer julgamentos. 
Não existe um processo ideal, a maioria das 
organizações desenvolve seus próprios processos de 
desenvolvimento de software. 
a) Apenas I. 
b) Apenas I e III. 
c) Apenas I e IV. 
d) Apenas II, III e IV. 
e) I, II, III e IV. 
24
Conteúdo da Aula
• Processo de Desenvolvimento de Software 
Clássicos
– Cascata
– Prototipação
– Iterativo e Incremental
– Espiral
• RUP
• Metodologias Ágeis
13
25
O Processo Unificado - RUP
• Ele usa uma abordagem de orientação a 
objetos em sua concepção e é projetado e 
documentado utilizando a notação UML para 
ilustrar os processos em ação.
• Primeiro modelo de processo inteiramente 
adaptado ao uso com a UML (Unified 
Modeling Language).
• Inicialmente desenvolvido e comercializado 
pela Rational, e desde 2003 pertence a 
IBM.
– Usando o seu nome original RUP
26
Dimensões necessárias para 
Desenvolver Sistemas
Processo
Linguagem de Modelagem Ferramentas
RUP / Processo Unificado
UML Ferramentas CASE
14
27
Organização do RUP
RUP é organizado:
• Por tempo
– Fases e Iterações
• Por Conteúdo
– Disciplinas 
28
Organização do RUP por Tempo - Fases
• Concepção: Definir o escopo do projeto e 
alcançar a cooperação entre todos os 
stakeholders.
• Elaboração: Especificar os requisitosprioritários e estabelecer a arquitetura.
• Construção: Finalizar a implementação do 
Produto.
• Transição: Garantir que o produto esteja 
disponível para seus usuários finais.
15
29
Organização do RUP por Conteúdo - Disciplinas
30
Disciplinas X Fases
• Cada Iteração corresponde a um ciclo completo em 
todas as Disciplinas do processo.
• Cada Fase (Concepção, Elaboração, Construção e 
Transição) é composta de uma ou mais Iterações. 
• O peso de cada Disciplina em uma Fase é variável.
• Cada iteração gera um Release (interno ou externo) que 
é uma versão estável e executável do sistema bem como 
quaisquer outros elementos necessários para sua 
utilização (a integração não fica concentrada no final ).
16
31
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 1
Foco nas 
disciplinas de 
Análise de 
Negócios e 
Requisitos
32
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 2
O Foco é em 
validar a 
Arquitetura e o 
que possuir 
mais riscos
17
33
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 3
O Foco é em 
validar a 
Arquitetura e o 
que possuir 
mais riscos
34
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 4, 
5, 6.... n
O Foco é na 
construção do 
software e nos 
testes
18
35
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 4, 
5, 6.... n
O Foco é na 
implantação do 
sistema em 
produção
36
Conteúdo da Aula
• Processo de Desenvolvimento de Software 
Clássicos
– Cascata
– Prototipação
– Iterativo e Incremental
– Espiral
• RUP
• Metodologias Ágeis
19
37
Scrum
• Scrum é um processo ágil para gestão de 
projetos de software.
• Em Scrum, o negócio define suas prioridades 
e a equipe se auto-organiza para determinar 
a melhor forma para entregar 
funcionalidades.
• Scrum é embasado no empirismo e utiliza 
uma abordagem iterativa e incremental para 
entregar valor com frequência e, assim, 
reduzir s riscos de projeto.
Engenharia de Software
38
Mas o que é o Scrum?
Planejamento por Iteração
Aprendizado a partir do que 
está sendo entregue
Interações inter e intra
equipes rápidas e constantes
20
Framework Scrum
3 Papéis 3 Artefatos
4 Cerimônias
Scrum
21
41
Papéis no Scrum: Scrum Master
• O Scrum master não é um gerente no 
sentido dos modelos prescritivos. O Scrum 
master não é um líder, já que as equipes são 
auto-organizadas, mas um facilitador 
(pessoa que conhece bem o modelo) e 
resolvedor de conflitos
42
Papéis no Scrum: Product Owner
• O Product Owner (PO), ou seja, a pessoa 
responsável pelo projeto em si. O product 
owner tem, entre outras atribuições, a de 
indicar quais são os requisitos mais 
importantes a serem tratados em cada 
sprint. O product owner é o responsável pelo 
ROI (Return Of Investment), e também por 
conhecer e avaliar as necessidades do 
cliente.
22
43
Papéis no Scrum: Time
• O Time Scrum é a equipe de 
desenvolvimento. Essa equipe não é 
necessariamente dividida em papeis como 
analista, designer e programador, mas todos 
interagem para desenvolver o produto em 
conjunto. Usualmente são recomendadas 
equipes de 6 a 10 pessoas.
44
Scrum
23
45
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.
Backlog de Produto
• As funcionalidades ou 
característica a serem 
implementadas ou produzidas 
em cada projeto (requisitos, 
casos de uso ou histórias de 
usuário) são mantidas em uma 
lista chamada de Backlog de 
Produto. 
• Cada funcionalidade é 
classificada genericamente como 
um item de backlog
Topo do Backlog
Itens de 
menor 
granularidade
24
47
• Cartões de Histórias dos Usuários
Como um <tipo_de_usuário>, eu gostaria de 
<funcionalidade> para <benefício>
Requisitos dos Usuários são definidos 
em Histórias
48
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.
25
49
Reunião Diária
• O modelo sugere que a equipe realize uma reunião 
diária, onde o objetivo é que cada membro da equipe 
fale sobre o que fez no dia anterior, o que vai fazer no 
dia que se segue e, se for o caso, o que o impede de 
prosseguir.
• Essas reuniões devem ser rápidas. Por isso, se sugere 
que sejam feitas com as pessoas em pé e em frente a 
um quadro de anotações. Além disso, recomenda-se 
que sejam feitas logo após o almoço, quando os 
participantes estarão mais imersos nas questões do 
trabalho (longe dos problemas pessoais), além de ser 
uma boa maneira de dissipar o cansaço que atinge os 
desenvolvedores no início da tarde.
50
Finalização da Sprint
• Ao final de cada sprint a equipe deve fazer um 
reunião de revisão da sprint para verificar o que 
foi feito e, a partir daí, partir para uma nova 
sprint. Na reunião de revisão da sprint ocorre a 
demonstração e avaliação do produto do sprint.
• Outra reunião que pode ser feita ao final de 
uma sprint é a reunião de retrospectiva da 
sprint, cujo objetivo é avaliar a equipe e os 
processos (impedimentos, problemas, 
dificuldades, ideias novas etc.).