Carregar apresentação
A apresentação está carregando. Por favor, espere
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:
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.