Processos de Desenvolvimento de Software

Prévia do material em texto

Processos de Desenvolvimento de Processos de Desenvolvimento de 
Software
Prof. Humberto Torres Marques Neto
Fevereiro/ 2008
PUC-MINAS
Referências BibliográficasReferências Bibliográficas
PRESSMAN, Roger S. Engenharia de Software. 6 ed. 
M G Hill 2006McGraw-Hill, 2006.
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. The 
unified software development process. Addison Wesley, 1998.p p y,
PAULA FILHO, Wilson de Pádua. Engenharia de Software: 
fundamentos, métodos e padrões. 2 ed. Rio de Janeiro: LTC, 
20032003.
SEI - CARNEGIE MELLON UNIVERSITY. The Capability 
Maturity Model: guidelines for improving the software process. 
Addison Wesley 1995Addison Wesley, 1995. 
SCOTT, Kendall. Processo unificado explicado. Porto Alegre: 
Bookman, 2003.
YOURDON, Edward. Análise estruturada moderna. Rio de 
Janeiro: Campus, 1990.
A crise do softwaref
9É á i t i ft d9É necessário construir softwares cada vez 
mais confiáveis e de qualidade
9O crescimento da demanda de softwares 
não tem fortalecido o projeto de sua 
construção, bem como a utilização de 
recursos mais apropriados para resolver 
os problemas
9O prazo para desenvolvimento de um p p
software é cada vez mais curto
Algumas questões para discussãog m q p
9Por que a finalização dos softwares é tãoPor que a finalização dos softwares é tão 
demorada?
9Por que os custos de desenvolvimento de9Por que os custos de desenvolvimento de 
software são tão elevados?
9P é í l id ifi9Por que não é possível identificar os erros 
antes de entregar o software para o 
usuário?usuário?
9Por que se tem dificuldades em 
acompanhar o progresso do 
desenvolvimento do software enquanto ele 
tá d t íd ?está sendo construído? 
Projetos da Área de TIj
http://www.standishgroup.com/chaos_resources/index.php
O triângulo da qualidadeg q
Requisitos
Qualidade
PrazoRecursos
Um conceito para SOFTWAREm p F W E
“Software is (1) instructions (computer 
programs) that when executed provideprograms) that when executed provide 
desired function and performance, (2) 
data structures that enable the programsdata structures that enable the programs 
to adequately manipulate information, 
and (3) documents that describe theand (3) documents that describe the 
operation and use of the programs.” 
(PRESSMAN 2001 p 6)(PRESSMAN, 2001. p. 6)
Curva de falha do hardwaref
(PRESSMAN, 2001. p. 7)
Curva de falha do softwaref f
(PRESSMAN, 2001. p. 8)
Processo de Desenvolvimento de 
Software
O que é um Processo?O que é um Processo?
“Um processo é uma seqüência de passosUm processo é uma seqüência de passos 
realizados com um propósito. Ou seja, 
processo é o que você faz O processoprocesso é o que você faz. O processo 
integra pessoas, ferramentas e 
procedimentos. Processo é o que pessoas p q p
fazem, utilizando procedimentos, métodos, 
ferramentas, e equipamentos, para 
f é i i (i )transformar matéria prima (inputs) em um 
produto (outputs) de valor para os seus 
clientes ”clientes. (SEI - CARNEGIE MELLON UNIVERSITY. The 
Capability Maturity Model: guidelines for improving the software process. 
Addison Wesley, 1995. p. 8.)
O que é um Processo de 
Desenvolvimento de Software?
“Um processo de desenvolvimento de software pode 
ser definido como um conjunto de atividades, métodos, 
práticas e transformações que pessoas utilizam para 
desenvolver ou dar manutenção em softwares ou em 
seus produtos associados (projetos manuais códigoseus produtos associados (projetos, manuais, código, 
etc.)” (SEI - CARNEGIE MELLON UNIVERSITY. The Capability Maturity 
Model: guidelines for improving the software process. Addison Wesley, 
1995 8 )1995. p. 8.)
“... we define a software process as a framework for 
the tasks that are required to build high-quality 
software.” (PRESSMAN, Roger S. Software Engineering: a practitioner’s 
h F th diti ( l ) M G Hill 1997 Ch t 2 Thapproach. Fourth edition. (s.l.) McGraw-Hill, 1997. Chapter 2: The process, p. 
22)
Processo de Desenvolvimento de Software e a 
9 Qual a diferença ou relação entre o processo de
Engenharia de Software
9 Qual a diferença ou relação entre o processo de 
desenvolvimento de software e a engenharia de software?
“Software Engineering: (1) The application of a systematic, disciplined, 
quantifiable approach to the development, operation, and maintenance 
of software; that is the application of engineering to software (2) Theof software; that is, the application of engineering to software. (2) The 
study of approaches as in (1).” (PRESSMAN, Roger S. Software Engineering: 
a practitioner’s approach. Fifth edition. (s.l.) McGraw-Hill, 2001. Chapter 2: The 
process p 20)process, p. 20)
“Software Engineering is a discipline that integrates process, methods, 
and tools for the development of computer software” (PRESSMAN, Roger 
S. Software Engineering: a practitioner’s approach. Fifth edition. (s.l.) McGraw-Hill, 
2001. Chapter 2: The process, p. 47)
Processos, Métodos e Ferramentasroc ssos, M to os F rram ntas
FerramentasFerramentas
ProcessoProcesso
MétodosMétodos
O foco na qualidadeO foco na qualidade
(Adaptado de PRESSMAN Roger S Software Engineering: a practitioner’s approach(Adaptado de PRESSMAN, Roger S. Software Engineering: a practitioner’s approach. 
Fourth edition. (s.l.) McGraw-Hill, 1997. Chapter 2: The process, p. 23)
Questões para a Q p
Engenharia de Software
9 Qual problema tem que ser resolvido?
9 Quais características do software são utilizadas para9 Quais características do software são utilizadas para 
resolver o problema?
9 Como o software será construído?9 Como o software será construído?
9 Qual abordagem será utilizada para identificar os 
t d d t j t t ãerros encontrados durante o projeto e a construção 
do software?
9 Como o software será mantido durante o tempo, 
quando correções, adaptações e evoluções serão 
requisitadas pelos os usuários?requisitadas pelos os usuários?
As fases genéricas da g
Engenharia de Software
9D fi i ã ( h t?)9Definição (what?)
9Desenvolvimento (how?)9Desenvolvimento (how?)
9Manutenção (change!)ç ( g )
Existem casos que uma dessas fases não se 
aplica? Quais? 
Atividades que complementam as fases 
9 Gerência de projeto
genéricas da Engenharia de Software
9 Gerência de projeto
9 Revisões técnicas
9 Gerência da qualidade
9 Gerência de configuração de software
9 Preparação e produção de documentos9 Preparação e produção de documentos
9 Gerenciamento da reusabilidade
9 Medição
9 G i d i9 Gerenciamento de risco
Atributos de um Processo de Atributos de um Processo de 
Desenvolvimento de Software
9 Capacidade ou competência de atingir os resultados 
desperados.
9 Performance em relação aos resultados atingidos ç g
(realizado em função do previsto)
9 Maturidade para evoluir a competência e a9 Maturidade para evoluir a competência e a 
performance
(SEI CARNEGIE MELLON UNIVERSITY The Capability Maturity Model:(SEI - CARNEGIE MELLON UNIVERSITY. The Capability Maturity Model: 
guidelines for improving the software process. Addison Wesley, 1995. p. 9.)
Níveis de Maturidade do Processo de 
Desenvolvimento de Software
9 Nível Inicial: poucos processos são definidos e o 
sucesso depende do esforço e do “heroísmo” 
pessoal ((CaosCaos))pessoal. ((CaosCaos))
9 Nível de Repetição: políticas básicas de 
gerenciamento do processo são estabelecidos paragerenciamento do processo são estabelecidos para 
determinar custos, prazos e funcionalidades; a 
disciplina do processo é necessária para a repetição p p p p ç
de sucessos recentes em aplicações similares. 
((DisciplinaDisciplina))
(SEI - CARNEGIE MELLON UNIVERSITY. The Capability Maturity Model: 
guidelines for improving the software process. Addison Wesley, 1995. p. 
15-20.)
Níveis deMaturidade do Processo de 
9
Desenvolvimento de Software
9 Nível de Definição: as atividades de gerenciamento e 
a engenharia de software são documentadas, 
padronizadas e integradas ((PadronizaçãoPadronização))padronizadas e integradas. ((PadronizaçãoPadronização))
9 Nível de Gerenciamento: o processo de 
desenvolvimento de software e o seu respectivodesenvolvimento de software e o seu respectivo 
produto são qualitativamente estudados e controlados. 
((AperfeiçoamentoAperfeiçoamento))
9 Nível de Otimização: o melhoramento contínuo do 
processo é alimentado pelo feedback do próprio 
processo. ((OtimizaçãoOtimização))
(SEI - CARNEGIE MELLON UNIVERSITY. The Capability Maturity Model: 
id li f i i th ft Addi W l 1995 15guidelines for improving the software process. Addison Wesley, 1995. p. 15-
20.)
Fases do loop de solução de problemasFases do loop de solução de problemas
blproblem 
definition
status quo technical 
developmentdevelopment
solution 
integration
(Adaptado de PRESSMAN Roger S Software Engineering: a practitioner’s approach(Adaptado de PRESSMAN, Roger S. Software Engineering: a practitioner’s approach. 
Fifth edition. (s.l.) McGraw-Hill, 2001. Chapter 2: The process, p. 27)
Modelo Seqüencial Linearq
E h i dEngenharia de
Sistemas/informação
análise projeto codificação teste
(Adaptado de PRESSMAN Roger S Software Engineering: a practitioner’s approach(Adaptado de PRESSMAN, Roger S. Software Engineering: a practitioner’s approach. 
Fifth edition. McGraw-Hill, 2001. Chapter 2: The process, p. 29)
Modelo Cascata
9Baseado apenas em fases9Baseado apenas em fases
Fase
Requisitos
Análise
Design
Construção
TesteTeste
Manutenção
Tempo
Modelo Cascata
9Problemas
– Adia a identificação de riscos, tornandoAdia a identificação de riscos, tornando 
extremamente caro desfazer algum erro cometido 
nas fases iniciais
– Atrasa e agrupa os testes do sistema, o que torna 
a integração um processo difícil
– Torna difícil a entrega parcial de produtos
– Difícil de lidar com mudanças de requisitos
Modelo Code And Fix
9Codificação começa imediatamente, 
com pouca ou nenhuma análisecom pouca ou nenhuma análise.
9Produto é entregueProduto é entregue
9Defeitos são consertados à medida que 
são reportados pelos usuário
Modelo Baseado na Prototipaçãop ç
9 O que é um protótipo?
9 Quais as vantagens da 
prototipação?
9 Quais as desvantagens?
9 A prototipação deve ser9 A prototipação deve ser 
utilizada em todos os tipos 
de sistemas?
(PRESSMAN, 2001. p. 31)
Modelo RAD 
(Rapid Application Development)
9 O software deve estar disponível em um prazo entre 
60 e 90 dias.
9 Necessidade de modularização do negócio para 
integração de equipes (RAD teams)
9 Principais fases:
– Modelagem funcional do negóciog g
– Modelagem de dados
– Modelagem de processos para manipulação dos dados
Geração de aplicação (linguagens de 4ª geração /– Geração de aplicação (linguagens de 4ª geração / 
componentes / reutilização)
– Teste (mais fácil devido a reutilização)
Modelo RAD 
(R id A li ti D l t)(Rapid Application Development)
(PRESSMAN, 2001. p. 33)
Modelo Incrementalm
9Cada seqüência linear produz um incrementoCada seqüência linear produz um incremento 
executável do software
9Cada incremento é um núcleo uma base9Cada incremento é um núcleo, uma base 
para o próximo
9Exemplo: um editor de texto que é9Exemplo: um editor de texto que é 
implementado só com as funções básicas
Modelo Incrementalm
(PRESSMAN, 2001. p. 35)
Modelo Espiralp
9Desenvolvimento incremental
9Regiões de tarefas:g
– Comunicação com o cliente
– Planejamentoj
– Análise de risco
– Engenhariag
– Construção e implantação
– Avaliação do clienteAvaliação do cliente
Modelo EspiralE p
(PRESSMAN, 2001. p. 37)
Modelo Espiral “WinWin”E p W W
(PRESSMAN, 2001. p. 39)
Modelo de Desenvolvimento Concorrente
(PRESSMAN, 2001. p. 41)
Modelo Baseado em Componentesm mp
(PRESSMAN, 2001. p. 42)
Processo WebEW E
(PRESSMAN, 2000. p. 775)
Metodologia de g
Desenvolvimento de Sistemas
9Organizar o desenvolvimento de sistemas
9Componentes de uma Metodologia:p g
– Processo
„ Conjunto de diretrizes que organizam o desenvolvimento 
de softwarede software
„ Atividades, Seqüências de atividades, Papéis, 
Procedimentos
– Linguagem de modelagem
„ Notação (principalmente gráfica) para especificação, 
documentação comunicação e visualização de artefatosdocumentação, comunicação e visualização de artefatos. 
– Ferramentas
„ Conjunto de instrumentos que permitem que artefatos 
sejam produzidos 
Ciclo de Vida de Ciclo de Vida de 
Desenvolvimento de Sistemas
9Conjunto de disciplinas/atividades/fases j p
que regem a vida de um 
desenvolvimento de software.
– Requisitos
– Análise e Desenho
– Implementação
– TestesTestes
– Implantação
Ciclo de Vida: ObjetivosCiclo de Vida: Objetivos
9Definir as etapas tarefas e técnicas que9Definir as etapas, tarefas e técnicas que 
serão utilizadas durante o processo
9Garantir a qualidade do sistema9Garantir a qualidade do sistema 
9Padronizar para criar cultura
9Viabilizar uma consistência entre os 
projetos da organização
9Facilitar a Gerência dos Projetos
– Planejamento
– Acompanhamento (pontos de controle)
– Controle (revisão técnica)
Ciclo de Vida do Projeto 
d
pedido de
semi-estruturado
1
LEVANTA-
MENTO
4
ESTUDO DE
HARDWARE
requisitos do 
usuário
exigências de 
d h
pedido de
hardware
2
ANÁLISE
declaração 
de viabilidade 
orçamento, 
cronograma
desempenho
especificação 
dados de 
configuração 
de hardware
requisitos do 
usuário
3
PROJETO
ESTRUTURADO
cronograma funcional
narrativa
plano
de testesusuário ESTRUTURADO
5
IMPLEMENTA-
ÇÃO 
projeto
empacotado
de testes
Ç
TOP-DOWN
empacotado
sistema 
(YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990. p. 107.)
Detalhes da Atividade de Projeto 
d Ci l d Vid i t t ddo Ciclo de Vida semi-estruturado
3.1
CODIFICAR 
ESPECIFICAÇÃO
FUNCIONAL
3.2
DERIVAR 
DIAGRAMA 
ESTRUTURAL
Especificação
funcional
narrativa
diagramação de fluxo 
de dados
diagrama de fluxo de dados, 
3.3 
PROJETAR 
diagrama 
estrutural
g ,
especificação de processos, 
dicionário de dados 
diMÓDULO 
descrição 
de módulo
especificação de 
banco de dados
diagrama 
estrutural
3.4
EMPACOTAR 
PROJETO
dados de
configuração
plano de testes
projeto
empacotado
(YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990. p. 108.)
Ciclo de Vida do Projeto Estruturado
banco depolíticas do requisitos do
Usuários Direção Operações
1
LEVANTAMENTO 2
ANÁLISE
3
PROJETO 
8
CONVERSÃO
DE BANCO DE 
DADOS
banco de 
dados 
existente
especificação de 
projeto 
restrições 
operativas 
especificação 
estruturada 
restrições
p
usuário 
charter
requisitos do 
sistema
DADOS
4
banco de dados 
convertido
especificação de 
projeto restrições
relatório 
experimental de 
custo/benefício
relatório 
especificação 
estruturada 
7
DESCRIÇÃO DE 
PROCEDIMENTOS
4
IMPLEMENTAÇÃO
convertido 
l d
sistema 
i t d
de custo/
benefício
Direção
5
GERAÇÃO DO 
TESTE DE 
ACEITAÇÃO
9
INSTALAÇÃO
sistema 
aceito
conjunto de teste de 
controle de qualidade 
manual do 
usuário
integrado
6
CONTROLE DE 
QUALIDADE sistema 
instalado
(YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990. p. 110.)
Fases do Ciclo de Vida do 
Projeto Estruturado
9 Levantamento ou estudo de viabilidade ou estudo inicial das 
atividades
– interaçãocom os usuários responsáveis para identificação do escopointeração com os usuários responsáveis para identificação do escopo 
inicial do sistema
– identificação de deficiências do ambiente atual 
elaboração da proposta preliminar de desenvolvimento do sistema– elaboração da proposta preliminar de desenvolvimento do sistema
– construção do Diagrama de Contexto preliminar
9 Análise
Necessidades do 
usuário e Previsão 
do Projeto
Especificação 
Estruturada
– construção do Modelo do Sistema
– conclusão do conjunto de orçamentos e cálculos de custo-benefício
Fases do Ciclo de Vida do 
Projeto Estruturado
9 Projeto
Modelo do Sistema X Recursos Humanos e 
Tecnológicos X TarefasTecnológicos X Tarefas
9 Implementação
9 Geração de teste de aceitação9 Geração de teste de aceitação
9 Controle de qualidade
9 Descrição de procedimentos9 Descrição de procedimentos
9 Conversão de banco de dados
9 InstalaçãoInstalação
9 Treinamento
Implementação 
lRadical versus Conservadora
Ultra 
Radical
Ultra 
Conservadora
Moderadamente 
Conservadora
Moderadamente 
Radical
– Quais as situações mais adequadas para cada tipo de– Quais as situações mais adequadas para cada tipo de 
implementação?
(YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: 
Campus, 1990. p. 116-124.)
Fases do Ciclo de Vida do Processo de 
Manutenção de Sistemas
9 Identificação do problema
9 Análise do impacto da alteração demandada pelo p ç p
problema
9 Planejamento da forma de abordagem do 
problema
9 Atualização da documentação existente, levando 
id ã t i ã d õem consideração a transição de versões 
9 Implementação das alterações
9 Implantação das alterações
9 Treinamento9 Treinamento
Processos e Equipes no Modelo CascataProcessos e Equipes no Modelo Cascata
9 Modelo monolítico (Analista-Projetista-Desenvolvedor) 
– Não é escalável
– Reflete modelo em cascata (waterfall)( )
– Requisitos “perfeitos” são transformados em desenhos 
imutáveis que são implementados em códigos por 
programadores mecânicos 
– Antítese do modelo iterativo e incremental
Processos e Equipes Modelos Iterativos Processos e Equipes Modelos Iterativos 
Processos e Equipes Modelos IterativosProcessos e Equipes Modelos Iterativos
9 Modelo hierárquico
Arquiteto de Sistemas com visão macro– Arquiteto de Sistemas com visão macro
– Analista de Sistemas com visão micro
Desenvolvedores (engenheiros de aplicação)– Desenvolvedores (engenheiros de aplicação) 
realizam visão micro
9 Centro de gravidade de projetos OO bem9 Centro de gravidade de projetos OO bem 
realizados oscila entre gerente de projeto, 
arquiteto de sistemas, analistas de sistemas e 
d l ddesenvolvedores
Desafios do Processo de 
D l i d S fDesenvolvimento de Software
9 SSO S9 Relacionados às PESSOAS
– “Inteligência compartilhada”
– Integração– Integração
– Comunicação
9 Relacionados aos PROBLEMAS
– “Dividir para conquistar”
9 Relacionados aos PROCESSOS
Vi ã i t d– Visão integrada
– Ciclo de vida do processo de desenvolvimento de 
sistemas
9 Relacionados ao PROJETO
– Gerenciamento, controle e resultado
Gerenciamento de RiscosGerenciamento de Riscos
9 Como identificar os riscos que envolvem o 
processo de desenvolvimento de um software?
– Tamanho do projeto
– Interferência no negócio– Interferência no negócio
– Características do cliente / usuário
D fi i ã d ( t d l i )– Definição do processo (metodologia)
– Ambiente de desenvolvimento (tecnologia)
– Experiência da equipe
Riscos em Processos de SoftwareRiscos em Processos de Software
Risco
Cascata
Iterativo
Tempo
Planejamento e Acompanhamento do Projeto de 
Desenvolvimento de Software
9 Como dividir e organizar as atividades que devem ser9 Como dividir e organizar as atividades que devem ser 
realizadas?
9 Q i i i i f t tili d9 Quais as principais ferramentas utilizadas para 
acompanhar o desenvolvimento de um processo de 
desenvolvimento de software?desenvolvimento de software?
9 Alguns critérios que devem ser considerados para 
relacionar pessoas às tarefas / atividadesrelacionar pessoas às tarefas / atividades
– Conhecimento da tecnologia
– Habilidade e experiência para lidar com a tecnologia
– Grau de dificuldade da tarefa / atividade
– Interdependência das tarefas / atividades
– Prazo para realização da tarefa / atividadep ç
Processo Unificado (UP)Processo Unificado (UP)
JACOBSON Ivar BOOCH Grady RUMBAUGH JamesJACOBSON Ivar BOOCH Grady RUMBAUGH JamesJACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. 
The unified software development processThe unified software development process. Addison . Addison 
Wesley, 1998.Wesley, 1998.
9 Baseado em componentes
– O software é construído a partir de componentes 
interconectados através de interfaces bem definidas
9 Utiliza a UML (Unified Modeling Language)9 Utiliza a UML (Unified Modeling Language)
9 Características chave
– Dirigido por caso de uso
– Centrado na arquitetura
– Iterativo e incremental
Processo Iterativo e Incrementalm
R i it A áli & D i
Planejamento Inicial
Planejamento
Requisitos Análise & Design
ImplementaçãoPlanejamento Implementação
Teste
Avaliação
Implantação
Avaliação
Cada iteração resulta
em uma liberação
executável
A vida de um processoA vida de um processo
(JACOBSON, 1998. p. 8)
Um ciclo com suas fase e iteraçõesUm ciclo com suas fase e iterações
(JACOBSON, 1998. p. 9)
Modelos do Processo UnificadoModelos do Processo Unificado
(JACOBSON, 1998. p. 10)
RUP: Ciclo de Vida (“Gráfico das Baleias”)( f )
Fases do Processo UnificadoF f
9 Concepção: definição dos use cases mais críticos, os quais 
t f õ h d i t D li itrepresentam as funções chave do sistema. Delimita-se o 
escopo do produto a ser desenvolvido, identifica-se e reduz-se 
principalmente os riscos críticos.
9 Elaboração: descrição arquitetural do software. Procura-se 
também definir a maioria dos use cases, capturando a maioria 
dos requisitos do software. No final desta fase deve-se estar 
apto a planejar a fase de construção em detalhes.
9 Construção: o software deve ser construído completamente. 
Ou seja, deve-se adicionar a musculatura ao esqueleto 
(arquitetura). Visa-se a capacidade operacional do software.
9 Transição: Esta fase envolve a realização de testes com o 
usuário, corrigir defeitos encontrados e realizar treinamento., g
Número de Iteraçõesm ç
9Projetos muito simples:
–– ConcepçãoConcepção: 1–– ConcepçãoConcepção: 1
• Protótipo GUI ou prova de conceito
–– ElaboraçãoElaboração: 1–– ElaboraçãoElaboração: 1
• Protótipo arquitetural
–– ConstruçãoConstrução: 1–– ConstruçãoConstrução: 1
• Montagem do produto
TransiçãoTransição: 1–– TransiçãoTransição: 1
• Finalização do produto
Número de Iteraçõesm ç
9Projetos maiores:9Projetos maiores:
–– ConcepçãoConcepção: 1
P tóti GUI d it• Protótipo GUI ou prova de conceito
–– ElaboraçãoElaboração: 2
• Protótipo arquitetural 
• Finalização da arquitetura
C t ãC t ã 2–– ConstruçãoConstrução: 2
• Montagem parcial do produto
Maturação e montagem final do produto• Maturação e montagem final do produto
–– TransiçãoTransição: 1
Finalização do produto• Finalização do produto
Número de Iteraçõesm ç
9Projetos maiores ainda, com muitasProjetos maiores ainda, com muitas 
tecnologias desconhecidas:
C ãC ã 1 it ã–– ConcepçãoConcepção: +1 iteração
• Para mais protótipos
–– ElaboraçãoElaboração: +1 iteração
• Para mais explorações arquiteturais
–– ConstruçãoConstrução: +1 iteração
• Devido ao tamanho do produto
–– TransiçãoTransição: +1 iteração
• Para mais feeback operacional
Iterações em um Cicloç m m
Projetos Número de iterações
Iterações por 
fase (aproximado)Simples 3 [0, 1, 1, 1]
Típico 6 [1, 2, 2, 1]
Alto 9 [1, 3, 3, 2]
Muito alto 10 [2, 3, 3, 2]
Variações nas Iteraçõesç ç
9Modelo de domínio completamente 
diferente:d e e te
– Consolidação de conceitos
– Mais iterações na concepçãoMais iterações na concepção
9Nova arquitetura precisa ser montada ou 
i t it iexistem muitos riscos
– Mais iterações na elaboração
Variações nas Iteraçõesç ç
9Produto grande e complexo:
– Mais iterações na construçãoç ç
9Organização com pouca experiência 
em projetos iterativos:em projetos iterativos:
– Três iterações que produzem software 
[0, 1, 1, 1][ , , , ]
9 Projetos normalmente possuem entre 6 e 8 
iterações em projetos típicos em empresas ç p j p p
com experiência em projetos iterativos.
Tempo de uma Iteraçãomp m ç
9 Regra do dedão: Divida o tempo da fase pelo 
número de iteraçõesç
9 Tamanho de uma iteração depende do número 
de pessoas e da cultura de desenvolvimentode pessoas e da cultura de desenvolvimento
9 Iterações menores que 1 mês devem ser 
d fi id id d tdefinidas cuidadosamente
9 Iterações não devem ser maiores que 3 meses
RUP: EstruturaE
FasesFases versus FluxosFluxosFasesFases versus FluxosFluxos
C ã El b ã C t ã T i ãConcepção Elaboração Construção Transição
RequisitosRequisitos
Análise
Projeto
Implementação
Teste