RUP
RUP
RUP
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
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
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
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
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 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.