Rational Unified Process Ana Maria M. Moura anammmoura@gmail.com Material em Desenvolvimento

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

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

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

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.

Produto O RUP é composto por alguns produtos Uma versão online do RUP http://www.wthreex.com/rup/portugues/index.htm Um livro de introdução KRUCHTEN, P. Introdução ao RUP. Addison Wesley, 2003.

Estrutura

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.

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

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.

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

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.

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

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)

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

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

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

Modelagem de Negócio

Modelagem de Negócio - Artefatos

Requisitos

Requisitos - Artefatos

Análise e Design

Análise e Design - Artefatos

Implementação

Implementação - Artefatos

Teste

Teste - Artefatos

Implantação

Implantação - Artefatos

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

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

Gerenciamento de Projeto

Gerenciamento de Projeto – Artefatos

Ambiente

Ambiente - Artefatos

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: http://www.ibm.com/developerworks/rational/library/feb05/krebs/