Buscar

Rational Unified Process

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 5 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

PROCESSO UNIFICADO DA RATIONAL (RUP)
É um processo de engenharia de software criado para apoiar o 
desenvolvimento orientado a objetos, fornecendo uma forma sistemática 
para se obter vantagens no uso da UML. Foi criado pela Rational Software 
Corporation e adquirido em fevereiro de 2003 pela IBM.
 OBJETIVOS: 
O objetivo é reduzir a frequência e o impacto dos problemas comumente 
encontrados nos projetos de software. Estes problemas são na sua maior 
parte de natureza não tecnológica e normalmente estão relacionados a 
planejamento, tomada de decisões e gerenciamento do projeto, 
querendo assim atender a necessidades dos usuários garantindo uma 
produção de software de alta qualidade que cumpra um cronograma e 
orçamento previsíveis. 
Cada vez mais os sistemas são complexos e precisam estar prontos em 
menos tempo. Mais do que isso, as necessidades mudam ao longo do 
tempo e a especificação de um sistema provavelmente será alterada 
durante seu desenvolvimento.
Visando atacar estes problemas, o RUP adota as seguintes premissas 
básicas:
✗ Uso de iterações para evitar o impacto de mudanças no projeto.
✗ Gerenciamento de mudanças e a bordagens dos pontos de maior 
risco o mais cedo possível.
 CONTEÚDO DA RUP:
Workflows - Cada workflow é descrito em detalhe, apresentando passo a 
passo as tarefas, subprodutos a serem gerados e papéis de profissionais 
envolvidos. Cada tarefa, subproduto e papel é descrito em detalhe. Este 
modelo pode ser seguido à risca ou adaptado conforme sua necessidade 
específica.
Tarefas - Cada tarefa é descrita em detalhe, incluindo que papel é 
responsável por ela, a qual workflow ela pertence e quais são os 
subprodutos de entrada e saída.
Modelo de equipe - Os diversos papéis necessários no projeto são 
descritos em detalhe. Assim como no MSF, cada papel pode ser 
representado por mais de uma pessoa, ou uma pessoa pode ter mais de 
um papel, dependendo da carga de trabalho necessário. Porém o RUP 
aborda os papéis em um maior nível de detalhe. Ao todo são mais de 30. 
Exemplos de papéis são: analista de sistemas, analista de negócio, etc.
Modelos de documentos - O RUP apresenta modelos e exemplos para os 
diversos documentos (artifacts) gerados ao longo do projeto. Estes 
documentos são descritos em detalhe, assim como as tarefas que os 
geram e as que os utilizam. Para os usuários das ferramentas Rational, 
existe um recurso adicional e-coach, que orienta o usuário a usar 
ferramentas como o Requisite Pro passo a passo. Os documentos são 
totalmente compatíveis com a UML, o que reforça a questão de 
padronização.
 FASES DA RUP:
Fase de Concepção / Iniciação: Esta fase do RUP abrange as tarefas de 
comunicação com o cliente e planejamento. É feito um plano de projeto 
avaliando os possíveis riscos, as estimativas de custo e prazos, 
estabelecendo as prioridades, levantamento dos requisitos do sistema e 
preliminarmente analisá-lo. Assim, haverá uma anuência das partes 
interessadas na definição do escopo do projeto, onde são examinados os 
objetivos para se decidir sobre a continuidade do desenvolvimento.
 
Fase de Elaboração: Abrange a Modelagem do modelo genérico do 
processo. O objetivo desta fase é analisar de forma mais detalhada a 
análise do domínio do problema, revisando os riscos que o projeto pode 
sofrer e a arquitetura do projeto começa a ter sua forma básica. 
Indagações como "O plano do projeto é confiável?", "Os custos são 
admissíveis?" são esclarecidas nesta etapa. 
Fase de Construção: Desenvolve ou Adquire os componentes de 
Software. O principal objetivo desta fase é a construção do sistema de 
software, com foco no desenvolvimento de componentes e outros 
recursos do sistema. É na fase de Construção que a maior parte de 
codificação ocorre. 
Fase de Transição: Abrange a entrega do software ao usuário e a fase de 
testes. O objetivo desta fase é disponibilizar o sistema, tornando-o 
disponível e compreendido pelo usuário final. As atividades desta fase 
incluem o treinamento dos usuários finais e também a realização de 
testes da versão beta do sistema visando garantir que o mesmo possua o 
nível adequado de qualidade.
RUP EM PROJETOS PEQUENOS
 DEFINIÇÃO DE UM PROJETO PEQUENO:
Pequeno pode se referir ao número de pessoas envolvidas no projeto, ao 
tempo de duração do projeto ou ao volume de software que está sendo 
desenvolvido:
➔3 a 10 pessoas.
➔ duração menor que um ano.
 CARACTERÍSTICAS PROCESSO DE UM PROJETO PEQUENO:
Nível menor de formalidade.
A maioria dos artefatos e das atividades do RUP são necessários em um 
projeto pequeno - o que difere são os formatos dos artefatos e o nível 
de formalidade, detalhes e esforços aplicados a cada atividade. Para a 
finalidade deste roteiro, o “processo de um projeto pequeno” se 
concentrará em projetos que requerem pouca formalidade. Eis algumas 
características desse processo de projeto pequeno:
➔ O número de documentos tende a ser menor e menos detalhados. 
➔ Em vez de Planos de Gerenciamento de Riscos e Planos de Aceitação 
do Produto, os projetos pequenos podem reservar alguns parágrafos 
para esses tópicos no Plano de Desenvolvimento de Software. 
➔ O Plano de Teste para cada iteração pode se resumir a alguns 
parágrafos no Plano de Iteração.
➔ Projetos pequenos quase sempre começam com o mínimo de 
ferramentas de desenvolvimento de software. À medida que o projeto 
cresce e tem êxito (que é o objetivo de todos os projetos pequenos 
bem-sucedidos!), é importante incluir ferramentas eficientes para 
ajudar a implementar melhores práticas a equipe. 
➔ As revisões formais podem ser substituídas por reuniões e discussões
informais.
➔ Muitos dos artefatos podem ser captados informalmente. Uma lista 
de riscos pode ser criada em um quadro branco, e as avaliações de 
status podem se resumir a alguns parágrafos em um e-mail.
 PRIMEIROS PASSOS:
Para ajudar a criar projetos pequenos, fornecemos um exemplo de caso 
de desenvolvimento para projetos pequenos, o qual descreve um 
processo relativamente informal que pode ser usado em muitos projetos 
pequenos. Esse exemplo inclui informações como:
➔ Quais atividades e artefatos opcionais serão usados e quais serão 
eliminados.
➔ O andamento relativo das atividades de cada fase.
➔ As ferramentas que serão usadas e o nível de formalidade a ser 
aplicado.
	PROCESSO UNIFICADO DA RATIONAL (RUP)
	RUP EM PROJETOS PEQUENOS

Continue navegando