Post on 16-Apr-2015
RUP 1
Prof. Pedro A. Oliveira
PUC Minas – São Gabriel
Sistemas de Informação
Engenharia de Software II
Rational Unified Process - RUP
RUP 2
O que é o RUP Abordagem de desenvolvimento de software
iterativa, centrada em arquitetura, e dirigida por casos de uso.
Processo de engenharia de software definido e estruturado: define quem faz o que, como e quando. Possui ainda
uma estrutura definida para o ciclo de vida de um projeto, articulando marcos e pontos de decisão.
Produto (IBM/Rational):
framework de processo personalizável para engenharia de software.
RUP 3
Princípios essenciais “Filho” do Processo Unificado (UP).
Define uma arquitetura executável no início.
Acomoda mudanças desde o início.
Ataca os maiores riscos primeiro.
Garante entregas significativas ao cliente.
Mantem o foco em software executável.
Visa Construir sistemas a partir de componentes.
Trabalho em equipe é requerido.
Faz da qualidade um “modo de vida”, não um alvo.
RUP 4
Paradigma do RUP
Centrado na arquitetura
Iterativo e incremental
Dirigido por casos de uso
RUP 5
Centrado na arquitetura A arquitetura é a organização fundamental
do sistema como um todo, incluindo elementos estáticos e dinâmicos e sua interação.
Consequências: Possibilita o entendimento da visão geral; Organiza o esforço de desenvolvimento; Facilita as possibilidades de reuso; Facilita a evolução do sistema; Dirige a seleção de casos de uso relevantes.
RUP 6
Arquitetura como Ponte
REQUISITOS
CÓDIGO
ARQUITETURA
Fonte: Garlan (2000)
Diagrama de Pacotes
RUP Processo de software PBH/Prodabel 7
RUP 8
Dirigido por casos de uso Os casos de uso dirigem (guiam) todo o trabalho
de desenvolvimento, desde a captação inicial e negociação de requisitos até a aceitação do código.
Justificativas: São expressos sob a perspectiva do usuário; São expressos em linguagem natural; Oferecem uma habilidade maior para a compreensão
dos requisitos reais do sistema; Oferecem a habilidade para atingir um alto grau de
rastreabilidade de requisitos; Oferecem um meio simples de decompor os requisitos
em partes (módulos, pacotes), que permitem a alocação de trabalho a subequipes, facilitando a gerência do projeto.
RUP 9
Múltiplas visões
RUP 10
Abordagem iterativa
Acomoda mudanças de requisitos. Integração não é mais feita como “big
bang”, no final do projeto. Riscos descobertos e tratados durante as
integrações iniciais. Gerenciamento tem um significado de
fazer mudanças táticas no produto. Reuso é facilitado.
RUP 11
Abordagem iterativa
Defeitos podem ser encontrados e corrigidos ao longo das iterações.
Otimiza a execução de funções da equipe de projeto.
Membros da equipe aprendem ao longo do projeto.
O processo de desenvolvimento é evoluido e refinado ao longo do projeto.
RUP 12
Organização estrutural do RUP
RUP 13
Estruturas Estrutura dinâmica: dimensão horizontal
que representa o tempo do processo. Mostra como o processo, expresso em termos de ciclos, fases, iterações e marcos, desenvolve-se ao longo do ciclo de vida de um projeto.
Estrutura estática: dimensão vertical que descreve como os elementos do processo (atividades, disciplinas, artefatos e papéis) são logicamente agrupados em temas (disciplinas ou fluxos).
RUP 14
Estrutura dinâmica
RUP 15
Ciclo
Um ciclo de desenvolvimento é um período de tempo que envolve do começo do projeto até a entrega do produto (ou cancelamento).
Há diferentes ciclos dependendo do produto como ciclo inicial de desenvolvimento e ciclo de evolução ou manutenção.
RUP 16
Fase
Cada ciclo no processo é dividida em uma sequência de quatro fases: Concepção, Elaboração, Construção, Transição.
As fases sempre existem e são fundamentais, não por causa do que é executado ou pelo seu tamanho, mas pelo que é atingido pelos marcos principais que concluem cada fase.
RUP 17
Ciclos típicos
RUP 18
Marcos principais
O propósito das fases não é particionar as atividades por tipo (análise, codificação, etc) e sim executar o suficiente de cada disciplina para atingir os objetivos da fase no momento que os marco são atingidos.
Os marcos principais do RUP não são expressos em termos de completar certos artefatos ou documentos, mas principalmente em termos de mitigação de riscos e completude do produto.
RUP 19
Fluxos variáveis
Os marcos principais são constantes em todos projetos que utilizam o RUP.
Entretanto, isso não significa que há uma prescrição fixa ou pré-determinada de um conjunto de atividades a seguir em todas as fases.
Alguns fatores influenciam o trabalho a ser feito, tais como: tamanho e natureza do projeto, riscos, número de envolvidos.
RUP 20
Artefatos congelados Os objetivos de uma fase não estão descritos
em termos de terminar um artefato, mas trazer o nível adequado de maturidade para tornar-se capaz de tomar as decisões corretas.
À medida que o projeto evolui mais entendimento é obtido a respeito dos objetivos, à medida que novas dificuldades são descobertas, mudanças são introduzidas, artefatos são revisados, atualizados e corrigidos.
Portanto, atividades já realizadas são executadas novamente, com maior grau de refinamento.
RUP 21
Fase concepção Objetivos:
Entender o que será construído; Identificar funcionalidades-chave do sistema; Determinar pelo menos uma solução
possível; Entender o cronograma, custos e riscos do
projeto; Decidir qual processo e ferramentas seguir.
Marco: Objetivo do ciclo de vida.
Identifique um produto: ___________________
RUP 22
Fase elaboração
Objetivos: Ter um entendimento detalhado dos
requisitos; Desenhar, implementar e validar a
arquitetura; Mitigar riscos essenciais e produzir um plano
mais refinado; Preparar o ambiente de desenvolvimento.
Marco: Arquitetura do ciclo de vida.
Identifique um produto: ___________________
RUP 23
Fase construção
Objetivos: Minimizar custos de desenvolvimento e
atingir certo grau de paralelismo para melhorar o desempenho no projeto;
Desenvolver iterativamente um produto pronto para a comunidade de usuários.
Marco: Capacidade operacional inicial.
Identifique um produto: ___________________
RUP 24
Fase Transição Objetivos:
Realizar testes beta para validar expectativas dos usuários;
Treinar usuários e demais envolvidos visando sua
independência.
Preparar ambiente e converter banco de dados;
Preparar empacotamento e distribuição;
Obter lições aprendidas;
Marco:
Liberação do produto para produção.
Identifique um produto: _____________________________
RUP 25
Iteração
Dentro de cada fase podem existir uma ou mais iterações.
Software é desenvolvido em cada iteração, que é concluída em uma revisão secundária (minor milestone), incluindo uma liberação (release) interna ou externa que torna-se um ponto de avaliação do progresso do projeto.
O produto cresce de forma incremental, à medida que são feitas as iterações e suas atividades.
RUP 26
Iterações por fase
RUP 27
Build
Dentro de cada iteração, os vários desenvolvedores ou times podem produzir builds de software; em alguns casos em frequências elevadas, até diariamente.
Isso permite integração contínua, testes (inclusive de regressão) e indicadores gerais de progresso.
Frequentemente, o último build de uma iteração é parte da liberação daquela iteração.
RUP 28
Estrutura estática - RUP
RUP 29
Fluxo
Sequência organizada e coerente, que produz algum resultado significativo.
Mostra a interação entre papéis, atividades e artefatos.
Os principais tipos de fluxo são: Disciplinas Detalhes das disciplinas.
RUP 30
Disciplina
As disciplinas representam uma partição de todos os papéis e atividades em agrupamentos lógicos, organizados por áreas de conhecimento ou especialidade.
Dividem-se em: Disciplinas técnicas.
Disciplinas de apoio.
RUP 31
Disciplinas Disciplinas técnicas
Modelagem de negócio;
Requisitos;
Análise e desenho;
Implementação;
Implantação;
Teste;
Disciplinas de apoio: Gerenciamento de projetos;
Gerencia de configuração;
Ambiente.
RUP 32
Atividade Uma unidade de trabalho que deve ser
desenvolvida. Tem um propósito claro, usualmente expresso em termos de criação ou atualização de algum artefato, modelo, componente ou plano.
Atividade é uma subdivisão de Iteração. A cada atividade é atribuído um papel
específico. Exemplos: Elaborar caso de uso => Analista de
requisitos; Preparar plano de projeto => Gerente de
projeto.
RUP 33
Papel
É um “chapéu” que um indivíduo ou grupo coloca em um dado momento, no projeto.
Um indivíduo pode desempenhar vários papéis, que não podem ser confundidos com cargos na organização.
Exemplos de papéis: Desenhista (designer); Analista de requsitos; Testador.
RUP 34
Artefato
Conjunto de informações produzido, modificado ou utilizado num processo.
Traduz-se num produto (plano, desenho, código, etc).
São elementos tangíveis de um projeto: coisas que um projeto produz ou usa enquanto o trabalho é executado.
Tipos de artefato: modelos, elementos de modelo, documento, código fonte, executável.
RUP 35
Elementos adicionais
Guias Gabaritos (templates) Mentor de ferramenta Conceitos Roteiros
Como o PSP trata isto?
RUP 36
Planejamento de projetos
Conceitos-chave: Ciclo. Fase. Iteração. Build.
RUP 37
Estratégia de planejamento
Devido ao fato do processo iterativo ser altamente dinâmico, adaptável e desenhado para acomodar mudanças, não é interessante gastar tempo e esforço produzindo planos detalhados que ultrapassem o horizonte do projeto.
Planos “burocráticos” são difíceis de manter, tornando-se rapidamente obsoletos; são tipicamente ignorados pela organização, após algumas semanas.
RUP 38
Plano de projeto e iterações
A abordagem iterativa e incremental estabelece dois tipos de planejamento: Alto-nível (coarse-grain): contido no
plano de projeto, que aborda as fases, iterações, seus objetivos e informações gerais. Há um plano por projeto.
Baixo-nível (fine-grain): contido em planos de iteração, que traz as atividades e recursos individuais. Há um plano por iteração.
RUP 39
Planejamento de alto nível e detalhado
RUP 40
Plano de projeto Gerentes de níveis superiores e stakeholders
raramente se interessam por detalhes sobre quem está fazendo o que e quando. O foco gerencial está no produto final, datas de liberação, marcos significativos…
Decisões importantes devem ser tomadas pelo gerente, no sentido de avaliar o progresso geral do projeto e solucionar problemas.
O plano de projeto é um plano de alto nível, que atua como um “envelope” para os planos detalhados de cada iteração.
RUP 41
Plano de iteração
Plano detalhado e com tempo bem definido, com um intervalo de tempo suficientemente pequeno para prover a equipe de um tipo de detalhamento com o qual ela está acostumada.
Deve definir tarefas e alocação de cada membro da equipe.
Em alguns projetos, o plano de iteração corresponde a uma simples lista de “tarefas por fazer”.
RUP 42
Problemas gerenciais - gerais Organização funcionalmente especializada, ao
invés de equipes multifuncionais (burocracia). Falta de definição clara sobre as expectativas
dos stakeholders, que podem esperar os mesmos resultados de um processo cascata.
Alocação de muitos desenvolvedores no começo do projeto, antes de entender bem o que fazer.
Resolver as questões fáceis primeiro ao invés de tratar as questões de maior risco.
Outro: _____________________________________
RUP 43
Problemas gerenciais - tempo
Iteração inicial muito longa, tentando fazer muitas coisas no começo.
Iterações sobrepostas, iniciando a próxima iteração sem o feedback da anterior. Confusão típica de quem não domina o RUP.
Mudanças excessivas nos momentos finais do projeto, levando a atrasos.
Outro: __________________________________
RUP 44
Problemas técnicos - equipe Número excessivo de casos de uso, tratando-os
como uma decomposição funcional e tornando os requisitos incompreensíveis.
“Paralisia da análise”, devido ao excesso de detalhes.
Inclusão de decisões de desenho nos requisitos, forçando decisões prematuras.
Falta de comprometimento dos clientes, levando a um sistema potencialmente rejeitável.
Outro: ________________________________
RUP 45
Problemas técnicos - gerente
Mentalidade “o que não foi inventado aqui não presta”, reduzindo reuso.
Fim da elaboração antes da maturidade da arquitetura, causando retrabalho.
Foco em inspeções e revisões ao invés de software executando, causando um processo de garantia de qualidade ineficiente, abordando apenas documentos ao invés do executável.
Outro: __________________________________
RUP 46
Alguns dados históricos sobre o RUP
Durações típicas de projetos: De 6 semanas a 54 meses.
Durações típicas de uma iteração: De 2 semanas a 6 meses.
Quantidade típica de iterações por projeto: De 3 a 9 iterações.
Quantidade de artefatos definidos: Aproximadamente 100.
Quantidade de papéis definidos: Aproximadamente 30.
RUP 47
Iniciação Elaboração Construção TransiçãoEsforço ~5 % 20 % 65 % 10%
Programação
10 % 30 % 50 % 10%
Fases de Planejamento
As fases não são idênticas em termos de programação e esforço. Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de tamanho médio deve prever a seguinte distribuição de esforço e programação:
Fonte: http://www.wthreex.com/rup/portugues/index.html
RUP 48
Iterações por fase
Tamanho do projeto (pessoas)
Duração do projeto (m)
Duração por iteração (s)
Concepção Elaboração Construção Transição
3 4 2-3 1 1 3 110 8 4 1 2 3 280 20 7-8 2 3 4 2
Iterações por fase
RUP 49
Dados sobre projetos com o RUP
Duração de cada iteração em semanasDuração do projeto em mesesPF (pontos por função) é uma técnica para estimativa de tamanhoUm PF corresponde aproximadamente a 50 linhas de código JavaProdutividade histórica: 7,4; 7 e 6,5 PF/pessoa-mês, respectivamente.
Concepção Elaboração Construção Transição ProjetosEquipe 1,5 2,5 4 3 27 Pessoas-mêsDuração 4 7 20 4 8 mesesIterações 1 1 3 1 200 PF
Equipe 3 5 10 8 115 Pessoas-mêsDuração 6 16 36 6 15 mesesIterações 1 2 4 1 800 PF
Equipe 35 70 140 100 4600 Pessoas-mêsDuração 20 50 100 20 45 mesesIterações 2 2 3 2 30000 PF
RUP 50
Detalhamento das disciplinas Disciplinas técnicas
Modelagem de negócio;
Requisitos;
Análise e desenho;
Implementação;
Implantação;
Teste;
Disciplinas de apoio:
Gerenciamento de projetos;
Gerencia de configuração;
Ambiente.
RUP 51
Modelagem de negócio
Objetivos Entender a estrutura e a dinâmica da
organização na qual o sistema deve ser implantado.
Entender os problemas atuais e identificar melhorias potenciais.
Garantir um entendimento comum entre clientes, usuários e desenvolvedores.
Derivar os requisitos de sistemas necessários.
RUP 52
Modelagem de negócio Principais papéis:
Analista de negócio Desenhista de processo de negócio Stakeholders Revisores
Principais artefatos: Documento de visão de negócios Modelo de casos de uso de negócio Modelo de objetos de negócio Especificação suplementar de negócio Glossário de negócio
RUP 53
Requisitos
Objetivos Estabelecer e manter acordo entre
stakeholders sobre o que o sistema deve fazer Prover aos desenvolvedores um melhor
entendimento dos requisitos do sistema Definir as fronteiras do sistema Prover a base para planejamento do conteúdo
técnico das iterações Prover a base para estimativas de duração e
custo
RUP 54
Requisitos
Principais papéis : Analista de sistemas Especificador de casos de uso Desenhista de interfaces com usuário
Principais artefatos: Glossário Descrição dos casos de uso Protótipos de interface com usuário
RUP 55
Análise e desenho
Objetivos Traduzir os requisitos em uma especificação
que descreva como implementar o sistema Selecionar a melhor estratégia de
implementação Estabelecer uma arquitetura robusta para a
aplicação
RUP 56
Análise e desenho
Principais papéis : Arquiteto Desenhista Desenhista de banco de dados Revisor
Principais artefatos: Modelo de análise Modelo de desenho Documento de arquitetura de software
RUP 57
Implementação
Objetivos Definir a organização do código em termos de
subsistemas e camadas Implementar classes, objetos e componentes Testar unidades criadas Integrar em um ambiente executável os
resultados produzidos individualmente
RUP 58
Implementação
Principais papéis : Implementador Integrador de sistemas Arquiteto Revisor de código
Principais artefatos: Implementação de subsistema Componente Plano de integração
RUP 59
Testes
Objetivos Verificar a interação dos atores com cada
componente. Verificar a integração entre os componentes. Verificar a implementação correta de todos os
requisitos. Identificar e garantir que todos os defeitos
descobertos sejam tratados.
RUP 60
Testes Principais papéis :
Desenhista de testes Testador
Principais artefatos: Plano de testes Modelo de testes Resultados dos testes Modelo de carga Defeitos gerados
RUP 61
Gerenciamento de configuração e mudanças
Objetivos Rastrear e manter a integridade do projeto. Habilitar membros da equipe a identificar e
localizar artefatos, selecionar a versão adequada e avaliar o histórico do artefato.
Acompanhar a evolução do projeto.
RUP 62
Gerenciamento de configuração e mudanças
Principais papéis : Gerente de configuração Gerente de controle de mudanças Implementador Integrador Arquiteto
Principais artefatos: Plano de gerenciamento de configurações Requisições de mudança Modelo de implementação Métricas e relatórios de status
RUP 63
Gerenciamento de projetos
Objetivos Prover uma estrutura para gerenciar projetos
de desenvolvimento. Prover diretrizes práticas para planejar,
executar, apoiar e monitorar projetos. Prover uma estrutura para gerenciar riscos.
RUP 64
Gerenciamento de projetos
Principais papéis: Gerente de projetos
Principais artefatos: Plano de desenvolvimento de projeto Plano de iterações Modelo de negócio Medidas do projeto
RUP 65
Ambiente
Objetivos Seleção e aquisição de ferramentas Configuração e personalização de ferramentas Configuração de processos Melhoria dos processos Prover serviços de apoio: infra-estrutura,
administração de contas, backup, etc.
RUP 66
Ambiente Principais papéis:
Analista de processos de negócio Analista de sistemas Desenhista de interfaces com usuário Arquiteto Redator Administrador do sistema Especialista em ferramentas
Principais artefatos: Diretrizes gerais
RUP 67
Implantação
Objetivos Testar o software no ambiente final (produção). Empacotar o software para implantação. Distribuir o software. Instalar o software. Treinar os usuários finais. Migrar o software existente (se for o caso) e
converter sua base de dados
RUP 68
Implantação Principais papéis:
Gerente de implantação Gerente de projetos Redator Implementador
Principais artefatos: Software executável. Artefatos de instalação: scripts, ferramentas, arquivos,
guias, etc. Notas de release. Material de apoio e treinamento.
RUP 69
Referências Bibliográficas
KRUCHTEN, Philippe, The Rational Unified Process – An Introdution, 2a ed., Adisson Wesley, 2000.
KROLL, Per, KRUCHTEN, Philippe, The Rational Unified Process Made Easy, Adisson Wesley, 2003.
http://www.wthreex.com/rup