RUP – Rational Unified Process É composto por quatro fases e nove disciplinas (workflow/fluxo de trabalho). É uma

metodologia de desenvolvimento incremental e iterativa. Sua meta é produzir software de alta qualidade que atenda aos requisitos dos usuários dentro de um cronograma e orçamento previsíveis.

Um processo define quem (papel) está fazendo o quê (artefatos), como (atividades) e quando (fluxo) de modo a alcançar determinado objetivo.

• Um papel descreve quem executa as atividades que geram os artefatos. o uma pessoa pode representar diversos papéis

• Artefatos são quaisquer produtos resultantes do processo de software. • Atividade é uma unidade de trabalho que um indivíduo desempenhando um papel

pode ser chamado a realizar.

O RUP possui duas dimensões:

• O eixo horizontal representa o aspecto dinâmico do processo e é expresso em termos de fases, iterações e marcos.

• O eixo vertical representa o aspecto estático do processo, representa as disciplinas.

PRECISA DECORAR ESTE GRÁFICO

1

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases produz uma geração do software. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Uma passagem pelas nove disciplinas é uma iteração. O número de iterações para completar um projeto depende da complexidade do mesmo.

FASES DO RUP

Iniciação/Concepção

Objetivos • Estabelecer o escopo do software do projeto

• Discriminar os casos de uso críticos do sistema

• Exibir pelo menos uma opção de arquitetura básica

• Estimar o custo geral e a programação para o projeto inteiro

• Estimar riscos

• Preparar o ambiente e dar suporte para o projeto

Atividades Básicas • Formular o escopo do projeto • Planejar e preparar um caso de negócio • Sintetizar uma possível arquitetura

o Arquitetura é a organização lógica do conjunto de classes que vai compor o software

• Preparar o ambiente para o projeto

Marco: Objetivos do Ciclo de vida • Decide se o projeto é financeiramente viável e se vai ou não prosseguir com ele

Artefatos • Visão

• Caso de Negócio o Para determinar se vale ou não a pena investir no projeto

• Plano de Desenvolvimento de Software o Informações necessárias ao desenvolvimento do software

• Modelo de Casos de Uso (20%)

• Glossário o Define os termos importantes usados no projeto

2

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

Objetivos • Assegurar que a arquitetura, os requisitos e os planos estejam estáveis o suficiente e

que os riscos sejam suficientemente diminuídos • Tratar os riscos significativos do ponto de vista da arquitetura • Demonstrar que a arquitetura suportará os requisitos do sistema a um custo/tempo

justo • Estabelecer um ambiente de suporte

Atividades • Definir, validar e criar a baseline da arquitetura • Refinar a visão • Criar planos de iteração detalhados • Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento • Refinar a arquitetura e selecionar componentes

Marco: Arquitetura do Ciclo de Vida • Arquitetura estável

o Um dos critérios de avaliação é comparar a despesa real com a planejada

Artefatos • Protótipos • Lista de Riscos • Documento de Arquitetura de Software • Modelo de Projeto • Modelo de Dados • Modelo de Casos de Uso (80%)

Construção A meta é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema

com base na arquitetura da baseline.

Objetivos • Minimizar os custos do desenvolvimento • Atingir a qualidade adequada • Atingir as versões úteis (alfa, beta e etc.) • Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades

necessárias • Decidir se o software, os locais e os usuários estão prontos para a implantação • Atingir um paralelismo entre o trabalho das equipes para acelerar o desenvolvimento do

software

Atividades • Gerenciamento de recursos, otimização de controle e processo • Desenvolvimento completo do componente e teste dos critérios de avaliação definidos • Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão

3

Marco: Capacidade Operacional Inicial • Determina se o produto está pronto para ser implantado num ambiente de teste beta

Artefatos • Manuais de Usuário Completos • Sistema executável para iniciar testes beta • Conjunto de Testes • Plano de Implantação

Transição O objetivo é assegurar que o software esteja disponível para seus usuários finais. Inclui

testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário, que deve priorizar o ajuste fino do produto, a instalação, configuração e problemas de usabilidade. Problemas estruturais mais graves já devem ter sido tratados antes.

Objetivos • Teste beta para validar o novo sistema • Teste beta e operação paralela relativa a um sistema legado que está sendo substituído • Conversão de bancos de dados operacionais • Treinamento de usuários e equipe de manutenção • Atividades de ajuste • Obtenção do consentimento dos envolvidos de que as baselines estão consistentes com

os critérios de avaliação da visão

Atividades • Executar os planos de implantação

• Finalizar o material de suporte para o usuário final

• Testar o produto liberado no local do desenvolvimento

• Criar um release do produto

• Obter feedback do usuário e ajustar o produto com base nele

• Disponibilizar o produto para os usuários finais

Marco: Release do Produto • Você decide se os objetivos foram atendidos e se outro ciclo de desenvolvimento deve

ser iniciado.

Artefatos • Notas de Release

• Artefatos de Instalação

• Materiais de Treinamento e Suporte

• Build do Produto

4

Disciplinas do RUP (Workflow/Fluxo de Trabalho) (MRAITIGGA) Uma disciplina mostra todas as atividades que devem ser realizadas para produzir um determinado conjunto de artefatos. O RUP descreve detalhadamente as suas nove disciplinas.

Modelagem de Negócios • Entender a estrutura e a dinâmica da organização na qual o sistema deve ser

implantado. Entender como funciona a organização. • Entender os problemas atuais da organização-alvo e identificar as possibilidades de

melhoria. • Assegurar que os clientes, usuários e desenvolvedores tenham um entendimento

comum da organização-alvo. • Derivar os requisitos de sistemas necessários para sustentar a organização-alvo

Requisitos • Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o

sistema deve fazer • Oferecer aos desenvolvedores uma compreensão melhor dos requisitos do sistema • Definir as fronteiras do sistema • Base para planejar o conteúdo técnico das iterações • Base para estimar o custo e o tempo de desenvolvimento do sistema • Definir uma interface de usuário para o sistema

5

Análise e Design (Análise e Projeto) • Transformar os requisitos em um design do sistema a ser criado • Desenvolver uma arquitetura sofisticada para o sistema • Adaptar o design para que corresponda ao ambiente de implementação, projetando-o

para fins de desempenho

Implementação • Definir a organização do código em termos de subsistemas de implementação

organizados em camadas • Implementar classes e objetos em termos de componentes • Teste de unidade dos componentes • Integrara os resultados produzidos ao sistema executável

Testes • O teste enfatiza a avaliação da qualidade do produto • Localizar e documentar defeitos na qualidade do software • Avisar de forma geral sobre a qualidade observada no software • Validar as suposições feitas na Análise e Design/Requisitos • Validar as funções do software conforme projetadas • Verificar se os requisitos foram implementados de maneira adequada

6

Implantação • Descrevem as atividades que garantem que o produto de software será disponibilizado a

seus usuários finais. • Existem 3 modos de implantação:

o Caixa comercializável o Download pela web o Ir à empresa e instalar o produto

Gerenciamento de Configuração e Mudança • Controla mudanças feitas nos artefatos de um projeto e mantém a integridade deles • Evita:

o Atualização simultânea o Notificação limitada o Várias versões

7

Gerenciamento de Projetos • Fornecer um framework para gerenciar projetos intensivos de software. • Fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar os

projetos. • Fornecer um framework de gerenciamento de risco. • O Gerenciamento de Projetos não cobre:

o Gerenciamento de pessoal o Gerenciamento de custos o Gerenciamento de contratos, entre outros

Ambiente

• Atividades necessárias à configuração do processo para um projeto • Fornece à organização o ambiente de desenvolvimento de software (ferramentas e

processos) que dará suporte à equipe de desenvolvimento • Disciplina ligada a garantia de qualidade de processos

8

Arquitetura 4 + 1

Visão de Arquitetura • Visão de um sistema a partir de uma determinada perspectiva • Foco na estrutura, modularidade, componentes essenciais e nos principais fluxos de

controle • São cinco visões no total (4 + 1)

Visão de Casos de Uso • Descreve como casos de uso críticos são executados no sistema, dando ênfase

principalmente a componentes arquiteturalmente significativos.

Visão de Implantação • Descreve uma ou várias configurações do sistema. É o mapeamento dos componentes

de software para nós de computação nessas configurações.

Visão de Implementação • Descreve a organização dos elementos estáticos do software no ambiente de

desenvolvimento em termos de empacotamento, divisão em camadas e gerenciamento da configuração.

Visão de Processos • Descreve o aspecto simultâneo do sistema, tarefas (processos) e suas interações.

Visão Lógica • Descreve as principais classes no design do sistema: classes relacionadas aos principais

negócios e classes que definem os principais mecanismos estruturais e comportamentais (persistência, comunicações, tolerância e falhas, interface do usuário)

• Endereça as exigências funcionais do sistema, isto é, expressa o que o sistema deveria fazer para os seus usuários finais.

• É uma abstração do modelo de projeto e identifica pacotes de projetos principais, subsistemas e classes.

9