RUP - Rational Unified Process Genésio Gomes Neto
Objetivos Introdução Características Principais do RUP Fases & Ciclo de Vida Disciplinas Básicas e de Apoio Framework Descrição de Atividades  Artefatos Guias
Introdução ao RUP
Tendências... Necessidade de sistemas cada vez maiores e mais complexos. Necessidade por Sofisticação Sistemas cada vez mais adaptados às necessidades dos usuários Inclusão de melhoramento substanciais a cada versão Exigência de rapidez no desenvolvimento Competitividade de mercado.
Necessidades  Um processo integrado que: Provenha guias Direcione as tarefas  Especifique os artefatos  Ofereça ferramentas e métodos Apresente critérios para monitorar e medir o produto e processo “ A presença de um bem definido e bem gerenciado processo é o elemento que diferencia os projetos produtivos dos projetos mal sucedidos”   (Booch et al, 1999)
Processo Unificado Framework genérico e adaptável à uma grande classe de sistemas Baseado em componentes interconectados por interfaces bem definidas. Integrado a linguagem UML Aspectos Diferenciais: Direcionado por Casos de Uso Centrado em Arquitetura Iterativo e Incremental
Histórico do RUP Abordagem da Ericsson Objectory Process 1.0 - 3.8 1987-1995 UML Abordagem da  Rational IBM - Rational Unified Process Rational Objectory Process 4.1 1996-1997 Rational Unified Process 5.0 Outras fontes
Práticas e Conceitos Chaves Modelagem Visual Iterativo e Incremental Dirigido do Casos de Uso Centrado em Arquitetura
Modelagem Visual Porque Modelar ? Um modelo é uma visão simplificada do sistema. Mostra a essência do sistema sobre uma perspectiva particular e esconde detalhes não essenciais. Serve para Aumentar o entendimento de sistemas complexos Explorar e comparar diferentes projetos  Formar uma base para implementação Capturar os requisitos precisamente Comunicar as decisões de forma não-ambígua.
Modelagem Visual UML Uso de notações gráficas e textuais semanticamente ricas para capturar elementos do projeto de software Permite o nível de abstração ser aumentado, preservando uma sintaxe e semântica rigorosa
Iterativo-Incremental R1 R2 R5 R3 R4 R7 R6 R1 R2 R5 R3 R4 R7 R6 It.1 It.2 It.3 Definição inicial de requisitos Planejamento de iterações Desenvolvimento de iteração N Validação com usuário da it. N Plano iteração N O desenvolvimento ocorre em várias iterações, cada uma resultando em incrementos de funcionalidades do sistema.
Iterativo e Incremental Benefícios Análise antecipada de riscos com a integração progressiva do sistema Melhor acomodação de solicitações de mudanças  Maior qualidade devido ao refinamento contínuo do produto Melhor facilidade de aprendizagem e amadurecimento do processo Aumento da reusabilidade
Iterativo x cascata
Disciplinas das Iterações Básicas Requisitos (requirements) Análise & Projeto (analysis & design) Implementação (implementation) Teste (tests) Implantação (deployment)
Disciplinas das Iterações De Apoio Ger. Projeto (Project management) Ger. de Ambiente (Environment) Ger. de Configuração e Mudança (Configuration and change management)
Integração entre as Disciplinas Fonte: Rational
Iterações no RUP Fonte: Rational
Processo  Dirigido por Casos de Uso   Casos de Uso são utilizados para  conduzir  todo o  processo de software . Serve de base para a geração e integração dos diversos modelos e artefatos produzidos em todas as etapas do processo
Diagrama de Casos de Uso
Casos de Uso  Especificação (Pro.Net)  Nome do requisito   [RFXX001]  Prioridade:  (Essencial, Importante, Desejável) Ator(es) Requisitos associados Descrição:  Explicação do propósito do caso de uso Desenhos ou rascunhos das telas da aplicação, ou captura das telas dos protótipos Pré-condições:  Estado em que a aplicação deve estar ou um fator externo necessário para que o caso de uso possa ser realizado Pós-condições:  Lista de possíveis estados em que a aplicação pode ficar imediatamente após o término da execução do caso de uso, ou alteração de um fator externo à aplicação.
Casos de Uso Especificação (Pro.Net)  Fluxo principal Descreve passo a passo o que os atores e a aplicação fazem. Especifica se este Caso de Uso inclui ou estende outro. Faz referência a um fluxo alternativo ou de erro caso haja necessidade devido a alguma condição. Fluxos alternativos [FA 001] <Descreve uma seqüência que foge ao fluxo principal descrito, mas que não é um erro.> Fluxos de erro [FE 001]  <Descreve os passos a serem seguidos para cada situação de erro identificada (ex: consulta a dados que deveriam estar no banco, falha na comunicação via rede etc.)>
Casos de Uso  são usados para ... Modelar o processo do negócio Especificar requisitos Planejar iterações Realizar os modelo de projeto Implementar os componentes e seus casos de teste Descrição dos manuais e/ou procedimentos de uso e instalação
Arquitetura de Software Proporciona uma perspectiva mais clara do sistema. Melhor compreensão e organização do sistema Base sólida para o desenvolvimento Descreve a estrutura de como os requisitos devem ser implementados “ Uma arquitetura de software (em algum ponto no tempo) é uma organização ou estrutura de  componentes  que interagem entre si através de interfaces”.  IEEE
Estrutura de Camadas
Componentes Parte encapsulada do sistema.  não trivial , com certa  independência  e passível de  substitução  que satisfaz uma clara funcionalidade  Oferecem interfaces bem-definidas que permitem prover e esconder serviços e informações.
Diferentes Visões de uma Arquitetura Visão da estrutura do sistema sobre o ângulo de stakeholders específicos  usuários, analistas, desenvolvedores, etc. Visões Típicas  Visão de Casos de Uso Visão Lógica Visão de Implementação Visão de Processo Visão de Implantação
Visão de Casos de Uso Conjunto de Casos de Uso que englobam comportamentos e riscos que devem ser levados em consideração pela arquitetura.
Visão Lógica Classes de projeto mais importantes e sua organização em pacotes e subsistemas, que por sua vez são estruturados em camadas.
Demais Visões Típicas  Visão de Implementação:  organização dos módulos em pacotes e camadas. Visão de Processos:  descrição das threads (linhas de execução) e suas interações e configurações.  Necessária quando existe alto grau de concorrência. Visão de Implantação:  descrição dos nós físicos (hardwares) para as configurações de plataforma
RUP: Um Processo Centrado em Arquitetura de Software “  RUP oferece uma forma metodológica de projetar, desenvolver e validar uma arquitetura” Arquitetura é construída através de refinamentos sucessivos Inicia-se com um protótipo de arquitetura executável e gradualmente se torna um sistema. Serve para demonstrar funções específicas  Em particular aquelas que satisfazem requisitos não funcionais. Serve para analisar riscos  Relacionados a desempenho, capacidade, confiabilidade, entre outros.
Importância de uma Arquitetura  Auxilia no gerenciamento da complexidade do projeto e na manutenção de sua integridade Garante manutenabilidade e aderência a requisitos não funcionais Base efetiva para o reuso em larga-escala  Guia para a gerência de projeto
Disciplinas Básicas  e de Apoio
Modelagem do Negócio Entender a estrutura e dinâmica da organização (contexto) Especificação de Casos de Uso de negócio Modelo de análise de negócio
Requisitos Especificação de Requisitos descrever  o quê  o sistema deve fazer, em acordo com o cliente e usuários Especificação do detalhamento dos Requisitos através de Casos de Uso Delimitar o escopo do sistema e prover uma base para o planejamento das iterações Definir protótipos de interface com o usuário
Requisitos  Artefatos Gerados Software Requirement Specification Use Case Model Glossary Stakeholder Request Storyboard Suplementary Specification Casos de Uso Vision escopo Requisitos não funcionais
Análise e Projeto Transformar os requisitos em um modelo para implementação do sistema Encontrar uma arquitetura robusta para o sistema
Análise e Projeto Fonte: Rational
Análise Casos de Uso são refinados e estruturados do ponto de vista dos desenvolvedores. Desenvolvimento do modelo de objetos Diagrama de Classes,  Diagrama de colaboração,  descrição arquitetural
Projeto Redefine e Cria Classes de implementação Aprofundamento dos níveis de detalhes dos Casos de Uso e descrições de classes. Diagramas de Sequência Agrupamento da classes em Subsistemas. Visão arquitetural completa.
Implementação Implementar os componentes necessários. Testar os componentes implementados como unidades Integrar os componentes implementados em um sistema executável
Testes Verificar a interação e integração dos componentes Verificar se todos os requisitos foram corretamente implementados Identificar defeitos e assegurar as correções de acordo com as prioridades de entrega de cada componente
Implantação Produzir o (que falta do) software scripts de instalação, documentação para o usuário, programas para conversão de dados, etc. Embalar e distribuir o software Instalar o software Realizar migração troca de sistema antigo pelo novo, conversão de dados Treinamento do usuário Aceitação formal pelo cliente
Gerência de Projeto Prover um framework para gerenciar projetos e riscos Prover orientações para o planejamento de atividades, definição da equipe, execução e monitoração de projetos Planejamento e monitoração das iterações!
Gerência de Configuração e Mudanças Identificar, definir e manipular itens de software Controlar modificações e versões destes itens  Reportar e armazenar a situação dos itens e as solicitações de mudanças Garantir a completude, consistência e corretude dos itens Controlar o armazenamento, manipulação e entrega destes itens
Configuração do Ambiente Prover o processo e as ferramentas necessárias ao desenvolvimento Possíveis Atividades: configurar o RUP desenvolver guidelines selecionar e adquirir ferramentas adaptar ou desenvolver ferramentas  suportar o ambiente de desenvolvimento (backups, administração de contas, etc.) treinamento implantação do RUP na organização
Fases do RUP
Fases do RUP O ciclo de vida de todo o projeto (não de cada iteração) é subdividido em quatro fases: Concepção, Elaboração, Construção e Transição. Cada fase pode possuir  N  iterações.
Fases e Iterações Cada fase pode comportar diversas iterações Concepção Elaboração Construção Transição Iteração preliminar 1 2 i i+2 i+3 ... j j+1 ... grandes marcos tempo
Fases do RUP Estabelecer o escopo e viabilidade econômica do projeto Eliminar principais riscos e definir arquitetura estável Desenvolver o produto até que ele esteja pronto para  beta testes Entrar no ambiente do usuário Concepção Elaboração Construção Transição
Marcos Transição Elaboração Construção Concepção Entendimento  do sistema Arquitetura estável Produto operacional Produto  implantado
Fases x Disciplinas do RUP   Fonte: Rational
Concepção (inspetion) Estabelecer o escopo e os limites do projeto Identificar Casos de Uso principais Realizar Planejamento Inicial Analisar riscos críticos Definir custos e  cronogramas Gerar Plano de Negócio (“Business Case”)  Verificar viabilidade do projeto Avaliar alguma arquitetura candidata Preparar ambiente do projeto
Elaboração (Elaboration) Garantir que a arquitetura, os requisitos e os planos são estáveis  Analisar riscos de forma que seja possível determinar o custo e o cronograma do projeto Estabelecer uma baseline para arquitetura.  Produzir protótipos dos componentes para analisar riscos, tais como Balanceamentos entre requisitos e projeto Reuso de componentes Analisar a viabilidade do produto
Construção (Construction) Minimizar custos através da otimização dos recursos e evitando re-trabalho. Alcançar qualidade de forma rápida e prática Concluir a análise, projeto, implementação e teste de todas as funcionalidades requeridas Desenvolver de forma iterativa e incremental um produto completo pronto para ser instalado. Alcançar um degrau de paralelismo no trabalho dos times de desenvolvimento Decidir se o software e os usuários estão prontos para implantação.
Transição (Transition) Beta testes para validação do sistema.  Treinamento dos usuários e mantenedores.  Estratégias de marketing, distribuição e venda. Avaliação da baseline de implantação com relação a visão do sistema e o critério de aceitação do produto. Alcançar a concordância do usuário
Elementos Básicos
Elementos Básicos do RUP Fonte: Rational
Atividade Atividade é uma unidade de trabalho que um indivíduo (ou grupo) no papel de um trabalhador deve executar Uma atividade geralmente tem o objetivo de criar / alterar artefatos Atividades são divididas em passos Atividades possuem “guidelines” Capturar Vocabulário Comum
Trabalhador Representa o comportamento e responsabilidades de um indivíduo ou de um grupo As responsabilidades são expressas em termos de atividades Representa um “papel” Analista de  Sistemas
Artefato Um artefato é um conjunto de informações que é produzido, modificado e usado pelo processo Artefatos são utilizados como entrada para os trabalhadores executarem as atividades, que por sua vez produzem artefatos de saída Glossário
Fonte: Rational Artefatos  do RUP
Workflows Os fluxos de atividades do RUP são descritos através de responsáveis, atividades e artefatos Fonte: Rational
Modelagem do Negócio Glossário Modelo de Casos de  Uso do Negócio Modelo de Objetos do Negócio Fonte: Rational
Requisitos Glossário Documento de Visão Especificações Suplementares Modelo de Casos de Uso Protótipo da Interface Fonte: Rational
Análise e Projeto Fonte: Rational
Análise e Projeto Fonte: Rational
Implementação Modelo de Implementação Componentes implementados Subsistemas implementados Fonte: Rational
Testes Plano de Teste Modelo de Teste Casos de Teste Procedimentos de Teste Lista de defeitos Avaliação dos Testes Fonte: Rational
Gerência de Projeto Plano de Negócios Plano do Desenv. do Software: plano de métricas lista de riscos plano do projeto plano da iteração Fonte: Rational
Gerência de Configuração e Mudanças Plano de gerência de configuração Fonte: Rational
Conclusões
RUP Os 10´s Atributos Essenciais Desenvolver Visão Planejamento  Analisar Riscos  Examinar Plano de Negócio (Business Case) Projetar Arquitetura de Componentes Desenvolver de forma iterativa e incremental Avaliar regularmente os resultados Gerenciar e controlar mudanças Implantar produtos usáveis  Adotar Processo que se adapte ao projeto

Processo Unificado(RUP)

  • 1.
    RUP - RationalUnified Process Genésio Gomes Neto
  • 2.
    Objetivos Introdução CaracterísticasPrincipais do RUP Fases & Ciclo de Vida Disciplinas Básicas e de Apoio Framework Descrição de Atividades Artefatos Guias
  • 3.
  • 4.
    Tendências... Necessidade desistemas cada vez maiores e mais complexos. Necessidade por Sofisticação Sistemas cada vez mais adaptados às necessidades dos usuários Inclusão de melhoramento substanciais a cada versão Exigência de rapidez no desenvolvimento Competitividade de mercado.
  • 5.
    Necessidades Umprocesso integrado que: Provenha guias Direcione as tarefas Especifique os artefatos Ofereça ferramentas e métodos Apresente critérios para monitorar e medir o produto e processo “ A presença de um bem definido e bem gerenciado processo é o elemento que diferencia os projetos produtivos dos projetos mal sucedidos” (Booch et al, 1999)
  • 6.
    Processo Unificado Frameworkgenérico e adaptável à uma grande classe de sistemas Baseado em componentes interconectados por interfaces bem definidas. Integrado a linguagem UML Aspectos Diferenciais: Direcionado por Casos de Uso Centrado em Arquitetura Iterativo e Incremental
  • 7.
    Histórico do RUPAbordagem da Ericsson Objectory Process 1.0 - 3.8 1987-1995 UML Abordagem da Rational IBM - Rational Unified Process Rational Objectory Process 4.1 1996-1997 Rational Unified Process 5.0 Outras fontes
  • 8.
    Práticas e ConceitosChaves Modelagem Visual Iterativo e Incremental Dirigido do Casos de Uso Centrado em Arquitetura
  • 9.
    Modelagem Visual PorqueModelar ? Um modelo é uma visão simplificada do sistema. Mostra a essência do sistema sobre uma perspectiva particular e esconde detalhes não essenciais. Serve para Aumentar o entendimento de sistemas complexos Explorar e comparar diferentes projetos Formar uma base para implementação Capturar os requisitos precisamente Comunicar as decisões de forma não-ambígua.
  • 10.
    Modelagem Visual UMLUso de notações gráficas e textuais semanticamente ricas para capturar elementos do projeto de software Permite o nível de abstração ser aumentado, preservando uma sintaxe e semântica rigorosa
  • 11.
    Iterativo-Incremental R1 R2R5 R3 R4 R7 R6 R1 R2 R5 R3 R4 R7 R6 It.1 It.2 It.3 Definição inicial de requisitos Planejamento de iterações Desenvolvimento de iteração N Validação com usuário da it. N Plano iteração N O desenvolvimento ocorre em várias iterações, cada uma resultando em incrementos de funcionalidades do sistema.
  • 12.
    Iterativo e IncrementalBenefícios Análise antecipada de riscos com a integração progressiva do sistema Melhor acomodação de solicitações de mudanças Maior qualidade devido ao refinamento contínuo do produto Melhor facilidade de aprendizagem e amadurecimento do processo Aumento da reusabilidade
  • 13.
  • 14.
    Disciplinas das IteraçõesBásicas Requisitos (requirements) Análise & Projeto (analysis & design) Implementação (implementation) Teste (tests) Implantação (deployment)
  • 15.
    Disciplinas das IteraçõesDe Apoio Ger. Projeto (Project management) Ger. de Ambiente (Environment) Ger. de Configuração e Mudança (Configuration and change management)
  • 16.
    Integração entre asDisciplinas Fonte: Rational
  • 17.
    Iterações no RUPFonte: Rational
  • 18.
    Processo Dirigidopor Casos de Uso Casos de Uso são utilizados para conduzir todo o processo de software . Serve de base para a geração e integração dos diversos modelos e artefatos produzidos em todas as etapas do processo
  • 19.
  • 20.
    Casos de Uso Especificação (Pro.Net) Nome do requisito [RFXX001] Prioridade: (Essencial, Importante, Desejável) Ator(es) Requisitos associados Descrição: Explicação do propósito do caso de uso Desenhos ou rascunhos das telas da aplicação, ou captura das telas dos protótipos Pré-condições: Estado em que a aplicação deve estar ou um fator externo necessário para que o caso de uso possa ser realizado Pós-condições: Lista de possíveis estados em que a aplicação pode ficar imediatamente após o término da execução do caso de uso, ou alteração de um fator externo à aplicação.
  • 21.
    Casos de UsoEspecificação (Pro.Net) Fluxo principal Descreve passo a passo o que os atores e a aplicação fazem. Especifica se este Caso de Uso inclui ou estende outro. Faz referência a um fluxo alternativo ou de erro caso haja necessidade devido a alguma condição. Fluxos alternativos [FA 001] <Descreve uma seqüência que foge ao fluxo principal descrito, mas que não é um erro.> Fluxos de erro [FE 001] <Descreve os passos a serem seguidos para cada situação de erro identificada (ex: consulta a dados que deveriam estar no banco, falha na comunicação via rede etc.)>
  • 22.
    Casos de Uso são usados para ... Modelar o processo do negócio Especificar requisitos Planejar iterações Realizar os modelo de projeto Implementar os componentes e seus casos de teste Descrição dos manuais e/ou procedimentos de uso e instalação
  • 23.
    Arquitetura de SoftwareProporciona uma perspectiva mais clara do sistema. Melhor compreensão e organização do sistema Base sólida para o desenvolvimento Descreve a estrutura de como os requisitos devem ser implementados “ Uma arquitetura de software (em algum ponto no tempo) é uma organização ou estrutura de componentes que interagem entre si através de interfaces”. IEEE
  • 24.
  • 25.
    Componentes Parte encapsuladado sistema. não trivial , com certa independência e passível de substitução que satisfaz uma clara funcionalidade Oferecem interfaces bem-definidas que permitem prover e esconder serviços e informações.
  • 26.
    Diferentes Visões deuma Arquitetura Visão da estrutura do sistema sobre o ângulo de stakeholders específicos usuários, analistas, desenvolvedores, etc. Visões Típicas Visão de Casos de Uso Visão Lógica Visão de Implementação Visão de Processo Visão de Implantação
  • 27.
    Visão de Casosde Uso Conjunto de Casos de Uso que englobam comportamentos e riscos que devem ser levados em consideração pela arquitetura.
  • 28.
    Visão Lógica Classesde projeto mais importantes e sua organização em pacotes e subsistemas, que por sua vez são estruturados em camadas.
  • 29.
    Demais Visões Típicas Visão de Implementação: organização dos módulos em pacotes e camadas. Visão de Processos: descrição das threads (linhas de execução) e suas interações e configurações. Necessária quando existe alto grau de concorrência. Visão de Implantação: descrição dos nós físicos (hardwares) para as configurações de plataforma
  • 30.
    RUP: Um ProcessoCentrado em Arquitetura de Software “ RUP oferece uma forma metodológica de projetar, desenvolver e validar uma arquitetura” Arquitetura é construída através de refinamentos sucessivos Inicia-se com um protótipo de arquitetura executável e gradualmente se torna um sistema. Serve para demonstrar funções específicas Em particular aquelas que satisfazem requisitos não funcionais. Serve para analisar riscos Relacionados a desempenho, capacidade, confiabilidade, entre outros.
  • 31.
    Importância de umaArquitetura Auxilia no gerenciamento da complexidade do projeto e na manutenção de sua integridade Garante manutenabilidade e aderência a requisitos não funcionais Base efetiva para o reuso em larga-escala Guia para a gerência de projeto
  • 32.
  • 33.
    Modelagem do NegócioEntender a estrutura e dinâmica da organização (contexto) Especificação de Casos de Uso de negócio Modelo de análise de negócio
  • 34.
    Requisitos Especificação deRequisitos descrever o quê o sistema deve fazer, em acordo com o cliente e usuários Especificação do detalhamento dos Requisitos através de Casos de Uso Delimitar o escopo do sistema e prover uma base para o planejamento das iterações Definir protótipos de interface com o usuário
  • 35.
    Requisitos ArtefatosGerados Software Requirement Specification Use Case Model Glossary Stakeholder Request Storyboard Suplementary Specification Casos de Uso Vision escopo Requisitos não funcionais
  • 36.
    Análise e ProjetoTransformar os requisitos em um modelo para implementação do sistema Encontrar uma arquitetura robusta para o sistema
  • 37.
    Análise e ProjetoFonte: Rational
  • 38.
    Análise Casos deUso são refinados e estruturados do ponto de vista dos desenvolvedores. Desenvolvimento do modelo de objetos Diagrama de Classes, Diagrama de colaboração, descrição arquitetural
  • 39.
    Projeto Redefine eCria Classes de implementação Aprofundamento dos níveis de detalhes dos Casos de Uso e descrições de classes. Diagramas de Sequência Agrupamento da classes em Subsistemas. Visão arquitetural completa.
  • 40.
    Implementação Implementar oscomponentes necessários. Testar os componentes implementados como unidades Integrar os componentes implementados em um sistema executável
  • 41.
    Testes Verificar ainteração e integração dos componentes Verificar se todos os requisitos foram corretamente implementados Identificar defeitos e assegurar as correções de acordo com as prioridades de entrega de cada componente
  • 42.
    Implantação Produzir o(que falta do) software scripts de instalação, documentação para o usuário, programas para conversão de dados, etc. Embalar e distribuir o software Instalar o software Realizar migração troca de sistema antigo pelo novo, conversão de dados Treinamento do usuário Aceitação formal pelo cliente
  • 43.
    Gerência de ProjetoProver um framework para gerenciar projetos e riscos Prover orientações para o planejamento de atividades, definição da equipe, execução e monitoração de projetos Planejamento e monitoração das iterações!
  • 44.
    Gerência de Configuraçãoe Mudanças Identificar, definir e manipular itens de software Controlar modificações e versões destes itens Reportar e armazenar a situação dos itens e as solicitações de mudanças Garantir a completude, consistência e corretude dos itens Controlar o armazenamento, manipulação e entrega destes itens
  • 45.
    Configuração do AmbienteProver o processo e as ferramentas necessárias ao desenvolvimento Possíveis Atividades: configurar o RUP desenvolver guidelines selecionar e adquirir ferramentas adaptar ou desenvolver ferramentas suportar o ambiente de desenvolvimento (backups, administração de contas, etc.) treinamento implantação do RUP na organização
  • 46.
  • 47.
    Fases do RUPO ciclo de vida de todo o projeto (não de cada iteração) é subdividido em quatro fases: Concepção, Elaboração, Construção e Transição. Cada fase pode possuir N iterações.
  • 48.
    Fases e IteraçõesCada fase pode comportar diversas iterações Concepção Elaboração Construção Transição Iteração preliminar 1 2 i i+2 i+3 ... j j+1 ... grandes marcos tempo
  • 49.
    Fases do RUPEstabelecer o escopo e viabilidade econômica do projeto Eliminar principais riscos e definir arquitetura estável Desenvolver o produto até que ele esteja pronto para beta testes Entrar no ambiente do usuário Concepção Elaboração Construção Transição
  • 50.
    Marcos Transição ElaboraçãoConstrução Concepção Entendimento do sistema Arquitetura estável Produto operacional Produto implantado
  • 51.
    Fases x Disciplinasdo RUP Fonte: Rational
  • 52.
    Concepção (inspetion) Estabelecero escopo e os limites do projeto Identificar Casos de Uso principais Realizar Planejamento Inicial Analisar riscos críticos Definir custos e cronogramas Gerar Plano de Negócio (“Business Case”) Verificar viabilidade do projeto Avaliar alguma arquitetura candidata Preparar ambiente do projeto
  • 53.
    Elaboração (Elaboration) Garantirque a arquitetura, os requisitos e os planos são estáveis Analisar riscos de forma que seja possível determinar o custo e o cronograma do projeto Estabelecer uma baseline para arquitetura. Produzir protótipos dos componentes para analisar riscos, tais como Balanceamentos entre requisitos e projeto Reuso de componentes Analisar a viabilidade do produto
  • 54.
    Construção (Construction) Minimizarcustos através da otimização dos recursos e evitando re-trabalho. Alcançar qualidade de forma rápida e prática Concluir a análise, projeto, implementação e teste de todas as funcionalidades requeridas Desenvolver de forma iterativa e incremental um produto completo pronto para ser instalado. Alcançar um degrau de paralelismo no trabalho dos times de desenvolvimento Decidir se o software e os usuários estão prontos para implantação.
  • 55.
    Transição (Transition) Betatestes para validação do sistema. Treinamento dos usuários e mantenedores. Estratégias de marketing, distribuição e venda. Avaliação da baseline de implantação com relação a visão do sistema e o critério de aceitação do produto. Alcançar a concordância do usuário
  • 56.
  • 57.
    Elementos Básicos doRUP Fonte: Rational
  • 58.
    Atividade Atividade éuma unidade de trabalho que um indivíduo (ou grupo) no papel de um trabalhador deve executar Uma atividade geralmente tem o objetivo de criar / alterar artefatos Atividades são divididas em passos Atividades possuem “guidelines” Capturar Vocabulário Comum
  • 59.
    Trabalhador Representa ocomportamento e responsabilidades de um indivíduo ou de um grupo As responsabilidades são expressas em termos de atividades Representa um “papel” Analista de Sistemas
  • 60.
    Artefato Um artefatoé um conjunto de informações que é produzido, modificado e usado pelo processo Artefatos são utilizados como entrada para os trabalhadores executarem as atividades, que por sua vez produzem artefatos de saída Glossário
  • 61.
  • 62.
    Workflows Os fluxosde atividades do RUP são descritos através de responsáveis, atividades e artefatos Fonte: Rational
  • 63.
    Modelagem do NegócioGlossário Modelo de Casos de Uso do Negócio Modelo de Objetos do Negócio Fonte: Rational
  • 64.
    Requisitos Glossário Documentode Visão Especificações Suplementares Modelo de Casos de Uso Protótipo da Interface Fonte: Rational
  • 65.
    Análise e ProjetoFonte: Rational
  • 66.
    Análise e ProjetoFonte: Rational
  • 67.
    Implementação Modelo deImplementação Componentes implementados Subsistemas implementados Fonte: Rational
  • 68.
    Testes Plano deTeste Modelo de Teste Casos de Teste Procedimentos de Teste Lista de defeitos Avaliação dos Testes Fonte: Rational
  • 69.
    Gerência de ProjetoPlano de Negócios Plano do Desenv. do Software: plano de métricas lista de riscos plano do projeto plano da iteração Fonte: Rational
  • 70.
    Gerência de Configuraçãoe Mudanças Plano de gerência de configuração Fonte: Rational
  • 71.
  • 72.
    RUP Os 10´sAtributos Essenciais Desenvolver Visão Planejamento Analisar Riscos Examinar Plano de Negócio (Business Case) Projetar Arquitetura de Componentes Desenvolver de forma iterativa e incremental Avaliar regularmente os resultados Gerenciar e controlar mudanças Implantar produtos usáveis Adotar Processo que se adapte ao projeto