SlideShare uma empresa Scribd logo
1 de 20
Baixar para ler offline
Visão Geral do RUP – 
Rational Unified Process 
Jorge Fernandes 
UFRN – Junho de 2002
Resumo do Artigo de Krutchen 
• O que é o RUP? 
• 6 Práticas Comprovadamente Efetivas 
– Desenvolvimento Interativo 
– Gestão de Requisitos 
– Arquitetura Baseada em Componentes 
– Modelagem Visual do Software 
– Verificação de Qualidade do Software 
– Controle de Mudanças 
• Visão Geral do RUP 
– Dimensão temporal: Interações 
• Concepção, Elaboração, Construção e Transição 
– Dimensão espacial: Fluxos ou Workflows 
• O Produto RUP 
• Ferramentas de Automação
Organização do RUP 
Dimensão Temporal 
Dimensão Espacial
4 Fases 
ciclos, fases, interações e pontos 
de controle.
Fase de Concepção • Finalidade 
– Definir objetivos e viabilidade do projeto (o idéia do projeto) e o escopo de vários aspectos 
• Atividades 
– Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das 
principais etapas 
– Delimitar o escopo do projeto 
– Identificar os atores que interagem com o sistema 
– Identificar as interações dos atores com o sistema (casos de uso) 
• Resultados (artefatos) 
– Documento de visão: visão geral dos requisitos, características e restrições essenciais do 
projeto. 
– Modelo inicial de casos de uso (10%-20%). 
– Glossário do projeto (opcionalmente um modelo de domínio). 
– Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso, projeção 
de ROI, e prognóstico financeiro. 
– Avaliação inicial de riscos. 
– Plano de projeto, com fases e interações. 
– Modelo de negócios, se necessário. 
– Um ou vários protótipos. 
• Critérios de Satisfação 
– Concordância quanto à definição de escopo e estimativas de custo e cronograma. 
– Compreensão dos requisitos funcionais. 
– Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de 
desenvolvimento. 
– Profundidade e amplitude dos protótipos desenvolvidos. 
– Custos planejados versus realizados.
Fase de Elaboração • Finalidade 
– eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente 
e consistente da solução 
• Atividades 
– Construir protótipos executáveis, em uma ou mais interações 
– Atacar os casos de uso críticos, que expõe os maiores riscos técnicos 
– Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios, 
demonstrar para investidores, clientes e usuários 
• Resultados (artefatos) 
– Modelo de casos de uso (80% ou mais). 
– Requisitos não funcionais 
– Descrição da arquitetura do software 
– Protótipos arquiteturais executáveis 
– Revisão da visão de negócios e lista de riscos 
– Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação 
– Plano de processo de desenvolvimento 
– Manual de usuário preliminar 
• Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto) 
– A visão do produto é estável? 
– A arquitetura é estável? 
– A demonstração executável mostrou que os elementos de maior risco foram abordados 
satisfatoriamente? 
– O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e 
coerente? 
– Todos os interessados concordam quando à coerência entre visão, plano e arquitetura? 
– Os custos planejados e executados estão aceitáveis?
Fase de Construção • Finalidade 
– Desenvolver todos os componentes e características não resolvidas nas fases 
anteriores, testando-as e integrando-as na forma de um produto. 
• Atividades 
– Diversas 
• Resultados (artefatos) 
– O produto, descrito e integrado nas plataformas adequadas 
• Critérios de Satisfação 
– A release do produto é suficientemente estável e amadurecida para ser entregue ao 
usuário? 
– Todos os envolvidos e interessados estão preparados para a fase de transição? 
– O consumo de recursos é ainda aceitável?
Fase de Transição • Finalidade 
– Realizar a transição do produto para a comunidade de usuários 
• Atividades 
– “beta teste” 
– Operações paralellas com sistema legado 
– Conversão de bases de dados 
– Treinamento de usuários a mantenedores 
– Roll-out para setores de marketing, distribuição e vendas 
• Resultados (artefatos) 
– Em conformidade com atividades 
• Critérios de Satisfação 
– O usuário ainda está satisfeito? 
– Os custos de manutenção ainda são aceitáveis?
9 Fluxos 
activities, 
artifacts, workers and workflows.
Artefatos e Fluxos 
• Artefato 
– Peça de informação produzida, modificada ou 
usada por um processo 
• Fluxo 
– Seqüência de atividades que produz um 
resultado de valor observável
Estrutura Estática do RUP
Pessoas e Trabalhadores
Exemplo de Fluxo
Fluxos de Engenharia de 
Software 1/3 
• Modelagem de Negócios (Finalidades) 
• Documentar processos de negócio usando casos de uso de 
negócios, com o objetivo de facilitar a comunicação entre as 
equipes de engenharia de software e a engenharia de negócios 
• Requisitos (Finalidades) 
• Descrever o que o sistema deve fazer, de modo que clientes e 
desenvolvedores concordem sobre esta definição 
• Elicitar, organizar e documentar funcionalidades e restrições 
• Rastrear e documentar compromissos e decisões.
Fluxos de Engenharia de 
Software 2/3 
• Análise e Projeto (Finalidades) 
– Mostrar como o sistema será concretizado na fase de 
implementação 
– Provar que o sistema: 
• Executará as tarefas e funções projetadas 
• Satisfará os requisitos estabelecidos 
• Será robusto e ameno a mudanças 
• Implementação (Finalidades) 
– Organizar o código em subsistemas, camadas, componentes, 
pacotes 
– Implementar classes e objetos usando código 
– Testar unitariamente os componentes desenvolvidos 
– Integrar resultados, produzindo um sistema executável
Fluxos de Engenharia de 
Software 3/3 
• Teste (Finalidades) 
– Verificar a interação entre objetos 
– Verificar a integraçÃo adequada entre os componentes de software 
– Verificar a satisfação dos requisitos 
– Identificar e corrigir defeitos, antes da entrega do software 
• Instalação (Finalidades) 
– Realizar entrega bem sucedida do software ao seu cliente, através 
da: 
• Produção de releases externas 
• Empacotamento do software. 
• Distribuição do software 
• Instalação do software 
• Auxílio aos usuários
Fluxos de Suporte 
• Gerência de Projeto 
– Balancear objetivos conflitantes dos envolvidos, superando 
problemas e entregando, de forma bem sucedida, um produto que 
satisfaz a necessidade de clientes e usuários. 
• Gerência de Configuração e Mudanças 
– Controlar os numerosos artefatos produzidos, ajudando a evitar 
confusão e garantindo que não haverá conflitos no software em 
decorrência de: 
• Atualizações simultâneas 
• Notificação limitada 
• Múltiplas versões 
• Gerência de Ambiente 
– Prover o ambiente adequado para a organização, formando pelas 
ferramentas e processos capazes de suportar as atividades da 
equipe de desenvolvimento
O Produto RUP
Ferramentas de Automação de 
Processo da Rational 
Rational Requisite®Pro  Facilita escritura, compartilhamento e 
disseminação de requisitos. 
Rational ClearQuest™ — Controle de solicitação de mudanças. 
Rational Rose® 98 — Modelagem Visual de processos de negócios, 
requisitos e componentes. 
Rational SoDA®  Geração de documentação 
Rational Purify®  Perfil de consumo de memória 
Rational Visual Quantify™ —Perfil de consumo de CPU. 
Rational Visual PureCoverage™ — Alcançabilidade de código. 
Rational TeamTest — Automatiza testes funcionais. 
Rational PerformanceStudio™ — Analisa desempenho de sistemas 
cliente-servidor para a Web 
Rational ClearCase® — Gerência de configuração de software.
Visão Geral do RUP – 
Rational Unified Process 
Jorge Fernandes 
UFRN – Junho de 2002

Mais conteúdo relacionado

Mais procurados

Uml processo unificado
Uml   processo unificado Uml   processo unificado
Uml processo unificado
Julia
 

Mais procurados (20)

Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Qualidade de Software: MPS.BR
Qualidade de Software: MPS.BRQualidade de Software: MPS.BR
Qualidade de Software: MPS.BR
 
Rup e metodos ágies
Rup e metodos ágiesRup e metodos ágies
Rup e metodos ágies
 
ISO/IEC 9241-11
ISO/IEC 9241-11ISO/IEC 9241-11
ISO/IEC 9241-11
 
Apresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rupApresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rup
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Visao Geral Rup
Visao Geral RupVisao Geral Rup
Visao Geral Rup
 
Qualidade de Software - Introdução
Qualidade de Software - Introdução Qualidade de Software - Introdução
Qualidade de Software - Introdução
 
CMMI
CMMICMMI
CMMI
 
Áreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareÁreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de Software
 
Processo de Melhoria Contínua: PDCA
Processo de Melhoria Contínua: PDCAProcesso de Melhoria Contínua: PDCA
Processo de Melhoria Contínua: PDCA
 
Uml processo unificado
Uml   processo unificado Uml   processo unificado
Uml processo unificado
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Rational Unified Process - RUP
Rational Unified Process - RUPRational Unified Process - RUP
Rational Unified Process - RUP
 
Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4
 
Metodologia Desenvolvimento do Prefeitura Livre
Metodologia Desenvolvimento do Prefeitura LivreMetodologia Desenvolvimento do Prefeitura Livre
Metodologia Desenvolvimento do Prefeitura Livre
 
Processo e Processo de Software
Processo e Processo de SoftwareProcesso e Processo de Software
Processo e Processo de Software
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Fatores de Qualidade de MacCall e ISO/IEC 9126
Fatores de Qualidade de MacCall e ISO/IEC 9126Fatores de Qualidade de MacCall e ISO/IEC 9126
Fatores de Qualidade de MacCall e ISO/IEC 9126
 
Outras Metodologias Ágeis Parte1
Outras Metodologias Ágeis Parte1Outras Metodologias Ágeis Parte1
Outras Metodologias Ágeis Parte1
 

Semelhante a Visao geraldorup 20slides

1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
Frank Coelho
 
Es2 modelo de processo de software
Es2 modelo de processo de softwareEs2 modelo de processo de software
Es2 modelo de processo de software
luacal
 
Engenharia software rup
Engenharia software   rupEngenharia software   rup
Engenharia software rup
Felipe
 

Semelhante a Visao geraldorup 20slides (20)

347842.ppt
347842.ppt347842.ppt
347842.ppt
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcp
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
Organizando demandas de desenvolvimento com o microsoft team foundation server
Organizando demandas de desenvolvimento com o microsoft team foundation serverOrganizando demandas de desenvolvimento com o microsoft team foundation server
Organizando demandas de desenvolvimento com o microsoft team foundation server
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
Tendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de SoftwareTendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de Software
 
Es2 modelo de processo de software
Es2 modelo de processo de softwareEs2 modelo de processo de software
Es2 modelo de processo de software
 
Engenharia software rup
Engenharia software   rupEngenharia software   rup
Engenharia software rup
 
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
 
Microsoft ALM = Produtividade
Microsoft ALM = ProdutividadeMicrosoft ALM = Produtividade
Microsoft ALM = Produtividade
 
Aula 3
Aula 3Aula 3
Aula 3
 
ALM com VSTS (v2)
ALM com VSTS (v2)ALM com VSTS (v2)
ALM com VSTS (v2)
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Termo de Abertura do Projeto
Termo de Abertura do ProjetoTermo de Abertura do Projeto
Termo de Abertura do Projeto
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
 
Ciclo de vida processo
Ciclo de vida processoCiclo de vida processo
Ciclo de vida processo
 
SAFe - Como escalar algo artesanal?
SAFe - Como escalar algo artesanal?SAFe - Como escalar algo artesanal?
SAFe - Como escalar algo artesanal?
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
 

Visao geraldorup 20slides

  • 1. Visão Geral do RUP – Rational Unified Process Jorge Fernandes UFRN – Junho de 2002
  • 2. Resumo do Artigo de Krutchen • O que é o RUP? • 6 Práticas Comprovadamente Efetivas – Desenvolvimento Interativo – Gestão de Requisitos – Arquitetura Baseada em Componentes – Modelagem Visual do Software – Verificação de Qualidade do Software – Controle de Mudanças • Visão Geral do RUP – Dimensão temporal: Interações • Concepção, Elaboração, Construção e Transição – Dimensão espacial: Fluxos ou Workflows • O Produto RUP • Ferramentas de Automação
  • 3. Organização do RUP Dimensão Temporal Dimensão Espacial
  • 4. 4 Fases ciclos, fases, interações e pontos de controle.
  • 5. Fase de Concepção • Finalidade – Definir objetivos e viabilidade do projeto (o idéia do projeto) e o escopo de vários aspectos • Atividades – Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das principais etapas – Delimitar o escopo do projeto – Identificar os atores que interagem com o sistema – Identificar as interações dos atores com o sistema (casos de uso) • Resultados (artefatos) – Documento de visão: visão geral dos requisitos, características e restrições essenciais do projeto. – Modelo inicial de casos de uso (10%-20%). – Glossário do projeto (opcionalmente um modelo de domínio). – Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso, projeção de ROI, e prognóstico financeiro. – Avaliação inicial de riscos. – Plano de projeto, com fases e interações. – Modelo de negócios, se necessário. – Um ou vários protótipos. • Critérios de Satisfação – Concordância quanto à definição de escopo e estimativas de custo e cronograma. – Compreensão dos requisitos funcionais. – Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de desenvolvimento. – Profundidade e amplitude dos protótipos desenvolvidos. – Custos planejados versus realizados.
  • 6. Fase de Elaboração • Finalidade – eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente e consistente da solução • Atividades – Construir protótipos executáveis, em uma ou mais interações – Atacar os casos de uso críticos, que expõe os maiores riscos técnicos – Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios, demonstrar para investidores, clientes e usuários • Resultados (artefatos) – Modelo de casos de uso (80% ou mais). – Requisitos não funcionais – Descrição da arquitetura do software – Protótipos arquiteturais executáveis – Revisão da visão de negócios e lista de riscos – Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação – Plano de processo de desenvolvimento – Manual de usuário preliminar • Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto) – A visão do produto é estável? – A arquitetura é estável? – A demonstração executável mostrou que os elementos de maior risco foram abordados satisfatoriamente? – O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e coerente? – Todos os interessados concordam quando à coerência entre visão, plano e arquitetura? – Os custos planejados e executados estão aceitáveis?
  • 7. Fase de Construção • Finalidade – Desenvolver todos os componentes e características não resolvidas nas fases anteriores, testando-as e integrando-as na forma de um produto. • Atividades – Diversas • Resultados (artefatos) – O produto, descrito e integrado nas plataformas adequadas • Critérios de Satisfação – A release do produto é suficientemente estável e amadurecida para ser entregue ao usuário? – Todos os envolvidos e interessados estão preparados para a fase de transição? – O consumo de recursos é ainda aceitável?
  • 8. Fase de Transição • Finalidade – Realizar a transição do produto para a comunidade de usuários • Atividades – “beta teste” – Operações paralellas com sistema legado – Conversão de bases de dados – Treinamento de usuários a mantenedores – Roll-out para setores de marketing, distribuição e vendas • Resultados (artefatos) – Em conformidade com atividades • Critérios de Satisfação – O usuário ainda está satisfeito? – Os custos de manutenção ainda são aceitáveis?
  • 9. 9 Fluxos activities, artifacts, workers and workflows.
  • 10. Artefatos e Fluxos • Artefato – Peça de informação produzida, modificada ou usada por um processo • Fluxo – Seqüência de atividades que produz um resultado de valor observável
  • 14. Fluxos de Engenharia de Software 1/3 • Modelagem de Negócios (Finalidades) • Documentar processos de negócio usando casos de uso de negócios, com o objetivo de facilitar a comunicação entre as equipes de engenharia de software e a engenharia de negócios • Requisitos (Finalidades) • Descrever o que o sistema deve fazer, de modo que clientes e desenvolvedores concordem sobre esta definição • Elicitar, organizar e documentar funcionalidades e restrições • Rastrear e documentar compromissos e decisões.
  • 15. Fluxos de Engenharia de Software 2/3 • Análise e Projeto (Finalidades) – Mostrar como o sistema será concretizado na fase de implementação – Provar que o sistema: • Executará as tarefas e funções projetadas • Satisfará os requisitos estabelecidos • Será robusto e ameno a mudanças • Implementação (Finalidades) – Organizar o código em subsistemas, camadas, componentes, pacotes – Implementar classes e objetos usando código – Testar unitariamente os componentes desenvolvidos – Integrar resultados, produzindo um sistema executável
  • 16. Fluxos de Engenharia de Software 3/3 • Teste (Finalidades) – Verificar a interação entre objetos – Verificar a integraçÃo adequada entre os componentes de software – Verificar a satisfação dos requisitos – Identificar e corrigir defeitos, antes da entrega do software • Instalação (Finalidades) – Realizar entrega bem sucedida do software ao seu cliente, através da: • Produção de releases externas • Empacotamento do software. • Distribuição do software • Instalação do software • Auxílio aos usuários
  • 17. Fluxos de Suporte • Gerência de Projeto – Balancear objetivos conflitantes dos envolvidos, superando problemas e entregando, de forma bem sucedida, um produto que satisfaz a necessidade de clientes e usuários. • Gerência de Configuração e Mudanças – Controlar os numerosos artefatos produzidos, ajudando a evitar confusão e garantindo que não haverá conflitos no software em decorrência de: • Atualizações simultâneas • Notificação limitada • Múltiplas versões • Gerência de Ambiente – Prover o ambiente adequado para a organização, formando pelas ferramentas e processos capazes de suportar as atividades da equipe de desenvolvimento
  • 19. Ferramentas de Automação de Processo da Rational Rational Requisite®Pro  Facilita escritura, compartilhamento e disseminação de requisitos. Rational ClearQuest™ — Controle de solicitação de mudanças. Rational Rose® 98 — Modelagem Visual de processos de negócios, requisitos e componentes. Rational SoDA®  Geração de documentação Rational Purify®  Perfil de consumo de memória Rational Visual Quantify™ —Perfil de consumo de CPU. Rational Visual PureCoverage™ — Alcançabilidade de código. Rational TeamTest — Automatiza testes funcionais. Rational PerformanceStudio™ — Analisa desempenho de sistemas cliente-servidor para a Web Rational ClearCase® — Gerência de configuração de software.
  • 20. Visão Geral do RUP – Rational Unified Process Jorge Fernandes UFRN – Junho de 2002