Análise e Projeto de Sistemas

Aula 2
Processo de Desenvolvimento de Software

Prof. Jorge Viana Doria Junior, M.Sc.

jjunior@unicarioca.edu.br
 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
Conteúdo da Aula

• Processo de Desenvolvimento de Software

Clássicos
– Cascata
– Prototipação
– Iterativo e Incremental
– Espiral
• RUP
• Metodologias Ágeis

3
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

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

Levantamento Análise de Implantação

Projeto Implementação Testes
de Requisitos Requisitos

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

• 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

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

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

13
Vários Mini-Cascatas
• Cada cascata é uma iteração...

Iteração 1 Iteração 2 Iteração 3

14
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

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

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.
22
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.
23
Conteúdo da Aula

• Processo de Desenvolvimento de Software

Clássicos
– Cascata
– Prototipação
– Iterativo e Incremental
– Espiral
• RUP
• Metodologias Ágeis

24
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
25
Dimensões necessárias para
Desenvolver Sistemas
Processo
RUP / Processo Unificado

Linguagem de Modelagem Ferramentas

UML Ferramentas CASE
26
Organização do RUP

RUP é organizado:

• Por tempo
– Fases e Iterações

• Por Conteúdo
– Disciplinas

27
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 requisitos
prioritá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.

28
Organização do RUP por Conteúdo - Disciplinas

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

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

• Processo de Desenvolvimento de Software

Clássicos
– Cascata
– Prototipação
– Iterativo e Incremental
– Espiral
• RUP
• Metodologias Ágeis

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

38
Framework Scrum

3 Papéis 3 Artefatos

4 Cerimônias
Scrum
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

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

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

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

Backlog de Produto menor

granularidade
• 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
Requisitos dos Usuários são definidos
em Histórias
• Cartões de Histórias dos Usuários
Como um <tipo_de_usuário>, eu gostaria de
<funcionalidade> para <benefício>

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

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

49
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.).

50