Rational Unified Process

Apresentação em tema: "Rational Unified Process"— Transcrição da apresentação:

1 Rational Unified Process
Ana Maria M. Moura Material em Desenvolvimento

2 Agenda Problemas do Desenvolvimento de Software
Melhores Práticas do Desenvolvimento de Software Definição Produto Estrutura Fases Papéis Disciplinas

3 Sintomas de Problemas no Desenvolvimento de Software
Incompreensão das necessidades do usuário final Inabilidade para lidar com requisitos variáveis Módulos que não se ajustam Software difícil de manter ou estender Descoberta tardia de imperfeições do projeto Baixa qualidade do software Desempenho inaceitável do software Falta de controle de modificações feitas pelos membros da equipe Um processo de construção e lançamento indigno de confiança

4 Melhores Práticas de Software
Desenvolver software iterativamente Gerenciar os requisitos Usar arquiteturas baseadas em componente Modelar o software visualmente Verificar a qualidade do software continuamente Controlar mudanças do software

5 Definição O Rational Unified Process (RUP) é um processo de desenvolvimento de software. Ele fornece uma abordagem disciplina para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento.

6 Produto O RUP é composto por alguns produtos Uma versão online do RUP
Um livro de introdução KRUCHTEN, P. Introdução ao RUP. Addison Wesley, 2003.

7 Estrutura

8 Fases A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Iniciação Elaboração Construção Transição Em cada final de fase, é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

9 Distribuição de Tempo e Esforço por Fases
Iniciação Elaboração Construção Transição Esforço 5% 20% 65% 10% Tempo 30% 50% É interessante que o tempo de cada iteração varie entre 2 a 6 semanas

10 Iniciação Objetivos A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. Os objetivos principais da fase de iniciação incluem: Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto. Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design. Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos. Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração imediatamente a seguir). Estimar riscos em potencial (as origens de imprevistos). Preparar o ambiente de suporte para o projeto.

11 Iniciação Artefatos Visão Lista de Riscos
Plano de Desenvolvimento (Plano de Projeto) Plano de Iteração Nesta fase deve ser feito o planejamento da primeira iteração de elaboração detalhado. Para isto, considere a priorização dos riscos do projeto. Ferramentas Glossário Modelo de Caso de uso Diagrama de Casos de Uso Descrição do fluxo principal dos principais casos de uso Documento de Regras de Negócio

12 Elaboração Objetivos Principais Objetivos
A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. Principais Objetivos Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento. Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto. Estabelecer uma arquitetura da baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto. Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim como um ou mais protótipos descartados para diminuir riscos específicos como: Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo. Estabelecer um ambiente de suporte.

13 Elaboração Protótipos Lista de Riscos (Atualizada)
Documento de Arquitetura Modelo de Design Modelo de Dados Visão (Atualizada) Plano de Iteração para as Fases de Construção e Transição Modelo de Caso de Uso (80%) Especificação Suplementar Conjunto de Testes

14 Construção Sistema em versão executável Plano de Implantação
Modelo de Implementação Conjunto de Testes Materiais de Treinamento Plano de Iteração para a Fase de Transição Modelo de Design (Atualizado) Modelo de Dados (Atualizado)

15 Transição Produto final Artefatos de Instalação
Material de Treinamento Material de Suporte para o Usuário

16 Papéis Os principais papéis são: Analistas Desenvolvedores Testadores
Gerentes

17 Disciplinas Modelagem de Negócios Requisitos Análise e Design
Implementação Teste Implantação Gerência de Configuração e Mudança Gerência de Projeto Ambiente

18 Modelagem de Negócio

19 Modelagem de Negócio - Artefatos

20 Requisitos

21 Requisitos - Artefatos

22 Análise e Design

23 Análise e Design - Artefatos

24 Implementação

25 Implementação - Artefatos

26 Teste

27 Teste - Artefatos

28 Implantação

29 Implantação - Artefatos

30 Gerência de Configuração e Mudança

31 Gerência de Configuração e Mudança – Artefatos

32 Gerenciamento de Projeto

33 Gerenciamento de Projeto – Artefatos

34 Ambiente

35 Ambiente - Artefatos

36 RUP X SCRUM A IBM Rational disponibilizou um artigo com dicas para aplicar algumas técnicas da metodologia ágil Scrum ao RUP. Este artigo pode ser encontrado em: