OpenUP

Metodologia de desenvolvimento ágil

Prof. Paulo César de Macedo

OpenUP

 É um processo unificado enxuto que aplica

abordagens iterativas e incrementais
dentro de um ciclo de vida estruturado.
 OpenUP abraça uma filosofia pragmática,
ágil e essa centra-se sobre a natureza
colaboradora da programação de software.
 É um ferramenta-agnóstica, onde o processo
pode ser estendido para endereçar uma
grande variedade de tipos do projeto.
OpenUP
 Destina-se à pequenas equipes que trabalham
juntas no mesmo local. A equipe precisa se
engajar em total iteração face-a-face
diariamente. Os membros da equipe são os
stakeholders, desenvolvedores, arquitetos, o
gerente de projeto e os testadores.
 Os membros da equipe se engajam em uma
colaboração significativa, tomando suas
próprias decisões a respeito de quais
necessidades devem ser trabalhadas, quais são
as prioridades e como melhor direcionar as
necessidades dos stakeholders. A organização
deve suportar a equipe permitindo-lhes esta
responsabilidade.
OpenUP

É um processo iterativo ;
 Mínimo, Completo e Extensível,
valorizando a colaboração entre
a equipe e os benefícios aos
clientes ao invés da formalidade
desnecessária.
OpenUP/Basic

É organizado em quatro
grandes áreas de conteúdo:
 Comunicação e Colaboração,
Objetivo, Solução e Gerência
Ciclo de vida de desenvolvimento
de software
Ciclo de vida de desenvolvimento
de software

 Cada fase consiste de uma ou mais

iterações, onde versões de
trabalhando estáveis do software são
desenvolvidas e liberadas, com a
conclusão de cada iteração
representando um pequeno marco
para o projeto e contribuindo para a
realização bem sucedida do marco
principal da fase onde os objetivos da
fase são alcançados.
OpenUP/Basic
 O OpenUP é caracterizado por quatro
princípios mutuamente suportados:
 Colaborar para alinhar interesses e
compartilhar entendimento
 Balancear as prioridades (necessidades e
custos técnicos) para maximizar o valor dos
interessados
 Focar na articulação da arquitetura para
facilitar a colaboração técnica, reduzir o
risco, e minimizar o sucateamento e o
retrabalho.
 Evoluir continuamente para reduzir riscos,
demonstrar resultados, e ganhar feedback do
cliente.
OpenUP/Basic

 O OpenUP/Basic já vem pronto para ser

usado, não necessitando de adições ou
alterações.
 Pode também ser extendido para adicionar
novo conteúdo de desenvolvimento ou
personalizar o processo para qualquer
ambiente específico.
OpenUP - Como começar?
 “Evoluir para continuamente obter
feedback e promover melhorias”,
sugere uma abordagem iterativa e
incremental para adotar o OpenUP.
 Comece com os princípios básicos e
compreenda as intenções do OpenUP.
 Então, avalie o processo existente e
selecione uma ou duas áreas
principais que você gostaria de
melhorar.
 Comece a usar o OpenUP para
melhorar estas áreas primeiramente.
 Nas iterações posteriores ou ciclos de
desenvolvimento, faça melhorias
incrementais em outras áreas.
 Se você tiver pouca ou nenhuma
experiência com processos unificados
ou outros processos iterativos, use o
OpenUP em um projeto piloto
pequeno, talvez com somente três a
quatro pessoas que trabalhem por
somente dois a três meses.
Disciplinas OpenUP

 Análisee Projeto
 Gerência de Configuração e
Mudança
 Implementação
 Gerência de Projetos
 Requisitos
 Teste
Os propósitos da Análise & Design
são:

 Transformar os requisitos em um
projeto do que será o sistema.
 Desenvolver uma arquitetura robusta
para o sistema.
 Adaptar o projeto para corresponder
com ambiente de implementação.

 Esta disciplina explica como criar o projeto

através dos requisitos os quais podem ser
implementados pelos desenvolvedores.
Gerência de Configuração e
Mudança

 Estadisciplina explica como

controlar às mudanças nos
artefatos, assegurando uma
evolução sincronizada de todos
os Produtos de Trabalho que
compõem um sistema de
software.
Implementação
 Esta disciplina explica como implementar uma
solução técnica que seja aderente ao design,
trabalhe dentro da arquitetura e atenda aos
requisitos.
 Construir o sistema de forma incremental.
 Verificar que as unidades técnicas usadas para
construir o sistema funcionem como
especificado.
 Em cada iteração, as tarefas nesta disciplina
farão com que uma Construção evolua sempre
com mais funcionalidades e com mais
estabilidade
 Ao trabalhar no sistema, o Desenvolvedor usará
a arquitetura e também será restringido por ela.
Gerência de Projetos
 O propósito desta disciplina é:
 Manter a equipe focalizada na entrega
contínua do produto de software testado
para a avaliação dos Stakeholders
 Ajudar a priorizar à seqüência de trabalho

 Ajudar a criar um ambiente de trabalho

eficaz para maximizar a produtividade da
equipe
 Manter os Stakeholders e a equipe
informados sobre o progresso do projeto
 Fornecer uma estrutura para controlar o
risco do projeto e para adaptar-se
continuamente às mudanças
Requisitos
 Esta disciplina define as tarefas mínimas
necessárias para eliciar, analisar,
especificar, validar e gerenciar os requisitos
para o sistema a ser desenvolvido.
 Entender o problema a ser resolvido
 Entender as necessidades dos Stakeholders
(o que os usuários desejam)
 Definir os requisitos para a solução (o que o
sistema tem que fazer)
 Definir os limites (escopo) do sistema
 Identificar interfaces externas ao sistema
 Identificar restrições técnicas na solução
 Fornecer a base para o planejamento das
iterações
 Fornecer a base inicial para a estimativa de
custo e cronograma.
Testes
 Esta disciplina define um conjunto mínimo de
tarefas requeridas para planejar, implementar,
executar e avaliar o teste do sistema.
 Encontrar e documentar defeitos.

 Validar e provar as suposições feitas no

projeto e requisitos especificados através de
demonstrações concretas.
 Validar que o produto de software foi feito
como projetado.
 Validar que os requisitos estão
apropriadamente implementados.
 Um esforço de teste bom está baseado na
filosofia de testes breves e testes freqüentes.
Além disso, é guiado por perguntas como:
 Como este software poderia falhar?