Rational Unified Process (RUP)

Carlos Henrique M. da Silva
carloshenrique.85@globo.com

1. Histórico e Conceitos
2. Melhores práticas
3. Fases
4. Disciplinas

O RUP, Processo Unificado Racional é um processo proprietário de
Engenharia de software criado pela Rational Software Corporation,
adquirida pela IBM, ganhando um novo nome IRUP e tornando-se
uma brand na área de Software, fornecendo técnicas a serem
seguidas pelos membros da equipe de desenvolvimento de software
com o objetivo de aumentar a sua produtividade no processo de
desenvolvimento.
O RUP usa a abordagem da orientação a objetos em sua concepção e
é projetado e documentado utilizando a notação UML (Unified
Modeling Language) para ilustrar os processos em ação. Utiliza
técnicas e práticas aprovadas comercialmente.

O RUP é, por si só, um produto de software. É modular e
automatizado, e toda a sua metodologia é apoiada por diversas
ferramentas de desenvolvimento integradas e vendidas pela IBM
através de seus "Rational Suites".
Métodos concorrentes no campo da engenharia de software incluem
o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como
a Programação Extrema (XP), Scrum, FDD (Desenvolvimento Guiado
por Funcionalidades) entre outros.
Objetivo é assegurar a produção de software de alta qualidade
dentro de prazos e orçamentos previsíveis (Kruchten 2003, pág. 14)

O RUP define perfeitamente quem é responsável pelo que, como as
coisas deverão ser feitas e quando devem ser realizadas,
descrevendo todas as metas de desenvolvimento especificamente
para que sejam alcançadas.
Oferece uma abordagem organizada em disciplinas para atribuir
tarefas e responsabilidades dentro de uma organização de
desenvolvimento.

Melhores Práticas
 Desenvolver software iterativamente
 Gestão de requisitos
 Uso de arquitetura baseada em componentes
 Uso de software de modelos visuais
 Verificação da qualidade do software
 Gestão e Controle de Mudanças do Software

Desenvolver Software Iterativamente
Desenvolver iterativamente significa desenvolver em ciclos. Cada
ciclo é contém um objetivo que deve ser alcançado (lançamento de
um pré release ou beta, correção de um bug, etc.)
Esta prática acaba dando ao RUP uma série de vantagens, como:
 Possibilidade de identificar/modificar requerimentos com mais
facilidade;
 Integração progressiva (quase continua) de elementos ao
software, ocasionando uma melhora no descobrimento e
endereçamento de riscos;
 Desenvolvimento iterativo provê aos gerentes maneiras de
fazer mudanças táticas aos produtos; etc.

Gestão de Requisitos
O gerenciamento de recursos acarreta um melhor controle sobre
projetos complexos, além de maior qualidade e redução de custos.
O RUP é uma metodologia dirigida-a-casos-de-uso (use-
drivencase), de modo que é possível utilizar os mesmos casos de
uso definidos no sistema como base para o resto do processo.
Os casos de uso (em inglês Use Cases) e os cenários são exemplos
de artefatos dependentes do processo, que têm sido considerados
muito mais eficazes na captura de requisitos funcionais.

Arquitetura Baseada em
Componentes
Um componente normalmente se relaciona com um objeto na
programação orientada a objetos.
O RUP oferece uma forma sistemática para construir este tipo de
sistema, focando-se em produzir uma arquitetura executável nas
fases iniciais do projeto, ou seja, antes de comprometer recursos em
larga escala.
Estes componentes são normalmente incluídos em infraestruturas
existentes como o CORBA e o COM (Modelo de Componentes de
Objetos).

Uso de Software de Modelos Visuais
A modelagem visual permite melhor entender não só a concepção e a
complexidade do sistema, mas também “dimensionar” (no sentido de
qual a forma do sistema), além de facilitar a identificação e solução
de problemas.

Verificação da qualidade do software
Não assegurar a qualidade do software é a falha mais comum em
todos os projetos de sistemas computacionais. Normalmente pensa-
se em qualidade de software após o término dos projetos, ou a
qualidade é responsabilidade de uma equipe diferente da equipe de
desenvolvimento.
O RUP não toma a qualidade como responsabilidade de apenas uma
pessoa ou grupo, mas como uma responsabilidade de todos os
integrantes do projeto.
A qualidade é focada especialmente em duas áreas:
 Qualidade de produto: Sendo desenvolvido (software ou sistema) e
todos as partes envolvidas (componentes, subsistemas, arquitetura).
 Qualidade de processo: Dentro do projeto de desenvolvimento.

Gestão e Controle de Mudanças do
Software
Em todos os projetos de software a existência de mudanças é
inevitável. O RUP define métodos para controlar e monitorar
mudanças. Como uma pequena mudança pode afetar aplicações de
formas inteiramente imprevisíveis, o controle de mudanças é
essencial para o sucesso de um projeto.
O RUP também define áreas de trabalho seguras, garantindo a um
programador que as mudanças efetuadas noutro sistema não
afetarão o seu sistema.

Fases de Desenvolvimento
Até agora estas linhas de guia são gerais, a serem aderidas ao
percorrer do ciclo de vida de um projeto. As fases indicam a ênfase
que é dada no projeto em um dado instante. Para capturar a
dimensão do tempo de um projeto, o RUP divide o projeto em
quatro fases diferentes:
1. Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.

Fases de Desenvolvimento
O RUP também se baseia nos 4 Ps:
1. Pessoas
2. Projeto
3. Produto
4. Processo
As fases são compostas de iterações. As iterações são janelas de
tempo; as iterações possuem prazo definido enquanto as fases são
objetivas.
Todas as fases geram artefatos. Estes serão utilizados nas próximas
fases e documentam o projeto, além de
permitir melhor acompanhamento.

Fase de Concepçã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.

Disciplinas
As disciplinas descrevem o aspecto estático do processo, como ele é
descrito em termos de componentes, disciplinas, atividades, fluxos
de trabalho, artefatos e papéis do processo. São divididas em:
 Seis Disciplinas de Engenharia
 Modelagem de Negócios
 Requisitos
 Análise e Projeto ("Design")
 Implementação
 Teste
 Implantação
 Três Disciplinas de Apoio/Suporte
 Ambiente
 Configuração e Gerência de Mudança
 Gerência de Projeto

Engenharia - Disciplina de Modelagem de Negócios
Modelagem de negócios, explica como descrever uma visão da
organização na qual o sistema será implantado e como usar esta
visão como uma base para descrever o processo, papéis e
responsabilidades.
O objetivo de modelagem de negócios é, primeiramente, estabelecer
uma melhor compreensão e canal de comunicação entre engenharia
de negócios e engenharia de software. Compreender o negócio
significa que os engenheiros de software devem compreender a
estrutura e a dinâmica da empresa alvo (o cliente), os atuais
problemas na organização e possíveis melhorias.

Engenharia - Disciplina de Requisitos
Esta disciplina explica como levantar pedidos das partes interessadas
("stakeholders") e transformá-los em um conjunto de requisitos que
os produtos funcionam no âmbito do sistema a ser construído e
fornecem requisitos detalhados para o que deve fazer o sistema.

Engenharia - Disciplina de Análise e Projeto (“Design”)
O objetivo da análise e projeto é mostrar como o sistema vai ser
realizado. O objetivo é construir um sistema que:
 Execute as tarefas e funções especificadas nas descrições;
 Cumpra todas as suas necessidades;
 Seja fácil de manter quando ocorrerem mudanças de requisitos
funcionais.

Engenharia - Disciplina de Implementação
Os efeitos da implementação são:
 Para definir a organização do código, em termos de subsistemas
de implementação organizadas em camadas
 Para implementar classes e objetos em termos de componentes
(arquivos-fonte, binários, executáveis e outros)
 Para testar os componentes desenvolvidos como unidades
 Integrar os resultados produzidos por implementadores
individuais (ou equipes), em um sistema executável

Engenharia - Disciplina de Teste
As finalidades da disciplina de teste são:
 Verificar a interação entre objetos
 Verificar a integração adequada dos componentes do software
 Verificar se todos os requisitos foram corretamente
implementados
 Identificar e garantir que os defeitos são abordados antes da
implantação do software
 Garantir que todos os defeitos são corrigidos, reanalisados e
fechados
O RUP propõe uma abordagem iterativa, o que significa que deve-se
testar todo o projeto. Os testes são realizados ao longo de 4
dimensões da qualidade: Confiabilidade, Funcionalidade,
Desempenho da aplicação, e o Desempenho do sistema.

Engenharia - Disciplina de Implantação
O objetivo da implantação é o de produzir com sucesso lançamentos
de produtos e entregar o software para seus usuários finais.
Ele cobre uma vasta gama de atividades, incluindo a produção de
releases externos do software, a embalagem do software e
aplicativos de negócios, distribuição do software, instalação do
software e prestação de ajuda e assistência aos usuários.
Embora as atividades de implantação estejam principalmente
centradas em torno da fase de transição, muitas das atividades
devem ser incluídas nas fases anteriores para se preparar para a
implantação, no final da fase de construção.
Os processos ("workflows") de "Implantação e Ambiente" do RUP
contêm menos detalhes do que outros workflows.

Apoio/Suporte - Disciplina de Ambiente
O ambiente enfoca as atividades necessárias para configurar o
processo para um projeto.
Ele descreve as atividades necessárias para desenvolver as diretrizes
de apoio a um projeto.
A proposta das atividades de ambiente é prover à organização de
desenvolvimento de software os processos e as ferramentas que
darão suporte à equipe de desenvolvimento.
Se os usuários do RUP não entendem que o RUP é um framework de
processo, eles podem percebê-lo como um processo pesado e caro.

Apoio/Suporte - Disciplina de Configuração e
Gerência de Mudança
A disciplina de Gestão de Mudança em negócios com RUP abrange
três gerenciamentos específicos: de configuração, de solicitações de
mudança, e de status e medição.
A Rational também tem um produto para manter as solicitações de
mudança chamado ClearQuest.

Apoio/Suporte - Disciplina de Gerência de Projeto
Esta disciplina concentra-se principalmente sobre os aspectos
importantes de um processo de desenvolvimento iterativo:
Gestão de riscos; Planejamento de um projeto iterativo através do
ciclo de vida e para uma iteração particular; E o processo de
acompanhamento de um projeto iterativo, métricas. No entanto, esta
disciplina do RUP não tenta cobrir todos os aspectos do
gerenciamento de projetos. Por exemplo, não abrange questões
como:
 Gestão de Pessoas: contratação, treinamento, etc.
 Orçamento Geral: definição, alocação, etc.
 Gestão de Contratos: com fornecedores, clientes, etc.

Embora o RUP não seja um processo adequado a todos os tipos de
desenvolvimento de software, ele representa uma nova geração de
processos genéricos. A mais importante inovação é a separação de
fases e workflows, e o reconhecimento de que a implantação de
software no ambiente do usuário é parte do processo. As fases são
dinâmicas e tem objetivos. Os workflows são estáticos e constituem
atividades técnicas que não estão associadas a uma única fase, mas
podem ser utilizados ao longo do desenvolvimento para atingir os
objetivos de cada fase (Sommerville 2007, pág. 56).
Conclusão

DISCIPLINAS
Vamos agorar conhecer um pouco mais sobre as
6 disciplinas de engenharia do RUP:
Modelagem de Negócios
Requisitos
Análise e Projeto ("Design")
Implementação
Teste
Implantação

DISCIPLINA DE
MODELAGEM DE
NEGÓCIOS

É uma das 9 disciplinas do RUP e a primeira das 6 consideradas “core
disciplines”. Dentro do ciclo de desenvolvimento de software
podemos dizer que essa é sem dúvida a disciplina menos praticada.
RUP não define esta como uma disciplina obrigatória, mas recomenda
fortemente que ela seja executada especialmente para empresas que
estão iniciando um novo negócio e não possuam uma clara
modelagem do negócio.

Finalidades:
 Entender os problemas da organização identificando as
possíveis melhorias;
 Avaliar o impacto de mudanças na organização;
 Assegurar que os clientes, usuários, desenvolvedores e outros
parceiros tenham uma compreensão comum da organização;
 Gerar conteúdo para a fase de requisitos do sistema que
suportará a organização e seus processos;
 Entender como o software se ajustará à organização.

Papéis e Artefatos
A importância da definição de papéisnão é somente para melhorar
divisão do trabalho, mas principalmente para que hajana equipe
responsabilidades definidas para cada atividade realizada, fazendo,
assim,com que os membros tenham que cumprir direitinho as suas
tarefas e que respondam por elas.
 Gerente de Projeto
 Analista de Processos de Negócio (Dentro da disciplina de
Modelagem de Negócios, esse é o papel mais importante)
 Designer de Negócio

Gerente de Projeto
Talvez seja um dos únicos papéis que estarão presentes em todos os
projetos e em todas as suas fases, independente do tamanho,
natureza ou metodologia de desenvolvimento adotada.
Inicialmente, o gerente de projeto era o indivíduo que identificava as
tarefas necessárias, as delegava aos membros da equipe e ficava
pressionando cada um para cumprir os prazos.
Hoje, essa realidade mudou. O gerente de projeto é um indivíduo
extremamente participativo: realiza parcerias com os membros da
equipe, estimula e valoriza as soluções encontradas e conduz o
andamento do projeto, protegendo a equipe de distrações e
organizando cronogramas, defende os interesses do time e realiza a
comunicação com o cliente.

Analista de Processos de Negócio

Designer de Negócios

Relação com Outras Disciplinas
A disciplina Requisitos utiliza modelos de negócios como
um importante subsídio para entender os requisitos do
sistema.
A disciplina Análise e Design utiliza entidades de
negócios como subsídio para identificar classes de
entidade no modelo de design.
A disciplina Ambiente desenvolve e mantém artefatos de
suporte, como o Guia de Modelagem de Negócios.

O objetivo da disciplina Requisitos é descrever o que o sistema deve
fazer e permite que desenvolvedores e clientes concordem com essa
descrição. Para conseguir isso, obter, organizar e funcionalidade
documento desejado e restrições; acompanhar e documentar
compromissos e decisões.
Uma visão do documento é criada, e necessidades das partes
interessadas são extraídas. Atores e casos de uso são identificados.
REQUISITOS

O QUE É UM REQUISITO?
 Condição ou capacidade que um sistema deve desempenhar
 Qualidade de software
 Funcionalidade: requisitos funcionais
 Requisitos não funcionais
 Usabilidade
 Confiabilidade
 Performance
 Suportabilidade – manutenabilidade

TIPOS DE REQUISITOS
 Serviços (features)
 Expressões de comportamento do sistema em alto nível (o quê)
 Solicitações dos stakeholders
 Requisitos do software
 Requisitos de casos de usos

Processo de levantamento de requisitos
proposto pelo RUP (José Martins, 2004)
REQUISITOS

ENGENHARIA DE REQUISITOS
É fundamental para o desenvolvimento de um software a
compreensão dos requisitos. Se a análise e a especificação das
funções não forem definidas adequadamente o software não atenderá
as necessidades do usuário.
A Engenharia de Requisito tem como objetivo a elaboração de um
documento com as características do sistema. Este documento serve
de referência para todas as pessoas envolvidas no processo de
desenvolvimento inclusive os clientes.
Com a chegada da engenharia de requisitos, se fez necessário à
elaboração de um processo visando organizar as atividades. É o que
analisaremos nos tópicos abaixo.

Processo de Engenharia de Requisitos
O processo de Engenharia de Requisitos é um conjunto de atividades
a serem seguidas para desenvolver um documento de requisitos.
Sommerville sugere um modelo de atividades que pode descrever a
maioria dos processos de Engenharia de Requisitos.
As atividades nem sempre ocorrem sequencialmente, em geral
realizam varias repetições ou são executadas paralelamente.
 Elicitação
 Análise e Negociação
 Especificação
 Validação

Processo de Engenharia de Requisitos

Elicitação dos Requisitos
O objetivo é obter conhecimentos relevantes do problema a ser resolvido.
Segundo Kotonya e Sommerville existem 4 dimensões na atividade de
elicitação de requisitos:
 Entendimento do domínio da aplicação – entendes-e a área na qual o
sistema será aplicado;
 Entendimento do problema – com auxilio do sistema a ser resolvido,
entende-se os detalhes do problema especifico a ser resolvido;
 Entendimento do negócio – entende-se qual a contribuição do
sistema para que sejam atingidos os objetivos gerais da organização;
 Entendimento das necessidades e das restrições dos stakeholders –
entende-se detalhadamente: as necessidades de apoio a serem
providas pelo sistema à realização do trabalho e aos interesses de
cada um dos stakeholders; os trabalhos a serem apoiados pelo
sistema e; o papel de eventuais sistemas existentes na execução e
condução dos processos de trabalho.

Análise e Negociação dos Requisitos
Depois da elicitação de requisitos todo esse conhecimento adquirido pelos
stakeholders precisa ser representado através de notações diversas. Essas
representações precisam estar sempre consistentes.
Negociação de requisitos é uma atividade extremamente complexa, ter um
entendimento global de todos os objetivos, soluções e interação entre eles é
uma tarefa muito difícil de executar. Assim existem diferentes métodos e
técnicas de negociação.
Robinson estabelece uma infraestrutura para modelar o processo de
negociação:
 Perspectivas de negociação
 Processos de negociação
 Produtos da negociação

Especificação dos Requisitos
Após serem identificados e analisados os requisitos devem ser documentados
para que possam servir de base para o resto do processo.
Administrar o volume de informações que são gerados pelo processo de
engenharia de requisitos é um dos principais problemas que se enfrenta na
documentação de requisitos. Para se tornar um pouco mais fácil a
administração desse documento usa-se uma notação gráfica que diminui o
tamanho do modelo.
Cada engenheiro de requisitos usa um modelo para fazer sua documentação.
A seguir são mostrados três modelos de documentos que são encontrados na
literatura:
Modelo 1 – Roger S. Pressman
Modelo 2 – RUP (Rational Unified Process)
Modelo 3 – Wilson de Pádua Filho

Validação dos Requisitos
Esta atividade acontece no final da especificação de requisitos e seu
objetivo é verificar se a documentação dos requisitos esta
consistente e se contem todas as necessidades dos usuários.
A revisão é uma das técnicas usadas para validar os requisitos.
Uma das maneiras para essa tarefa é utilizar um relatório de revisão.
Um grande desafio para a validação de requisitos é mostrar que a
especificação de requisitos está correta, pois não existe uma forma
para isso.

GERENCIAMENTO DE REQUISITOS
Gerenciamento de requisitos trata-se de um modelo sistemático pra
identificar, organizar e documentar os requisitos do sistema,
estabelecer e manter acordo entre o cliente e a equipe do projeto nos
requisitos variáveis do sistema.
Para ter um gerenciamento eficiente de requisitos é preciso:
 Manter uma declaração de requisitos clara;
 Atributos aplicáveis a cada tipo de requisito e;
 Rastreabilidade para outros requisitos e outros artefatos do
projeto.

GERENCIAMENTO DE REQUISITOS
Existem requisitos funcionais e não-funcionais. Exemplos:
 Funcional: o usuário deve selecionar a opção de inclusão para
cadastrar um novo aluno no banco de dados.
 Não-funcional: o sistema deve ser compatível com as
plataformas Windows e Linux.
 Não-funcional: o sistema deverá ser desenvolvido em Java.
É natural que alguns requisitos possam não ser definidos corretamente no
início do projeto, para isso serão necessárias várias revisões periódicas, a
fim de detectar erros o mais cedo possível e corrigi-los logo em seguida.

DISCIPLINA DE
ANÁLISE E PROJETO
("DESIGN")

 Após a etapa de análise de requisitos,
temos documentos de requisitos e os
casos de uso em mãos.
 Queremos agora gerar um primeiro
modelo do sistema a partir dos casos de
uso.
 Este é chamado de modelo de análise.

 Vai proporcionar um método que permita que
criemos um modelo de classes do sistema a
partir dos casos de uso
 Trará a resposta para a pergunta:
◦ Quais classes preciso para implementar estes
casos de uso?

casos de uso análise
Descritos na linguagem do
cliente
Descrito na linguagem dos
desenvolvedores
Visão externa do sistema Visão interna do sistema
Captura as funcionalidades
do sistema
Mostra, de modo abstrato,
como a funcionalidade pode
ser realizada
Estruturado por casos
de uso
Estruturado por classes e
pacotes

 O modelo de análise e projeto contém as
realizações de casos de uso
 Pode ser particionado em dois modelos
◦ Modelo de Analise
◦ Modelo de Projeto

Diagramas de ClasseDiagramas de Classe
Realização de Caso
de Uso
Caso de Uso
Diagramas de ColaboraçãoDiagramas de Colaboração
Diagramas de SequênciaDiagramas de Sequência
Descreve como o
caso de uso é
realizado,
associando o caso
de uso com classes
e outros elementos
de projeto
 Requisitos   Analise e projeto 

MDS - Bacalá
Diagrama de
Atividades

1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados

Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de
Estoque
Socket

Para cada caso de uso
 Identificar as classes de análise
• Classes de fronteira
• Classes de controle
• Classes de entidade
Para cada classe
 Identificar responsabilidades das classes
 Identificar relacionamentos
 Identificar atributos

Para cada classe
1. Criar classes de projeto
2. Identificar classes persistentes
3. Definir métodos
4. Definir atributos
5. Definir estados
6. Definir relacionamentos
7. Contemplar os requisitos não-funcionais

 Mapear as classes persistentes em conceitos
do Banco de Dados
 Definir os tipos de dados mais adequados para
o Banco de Dados
 Normalizar se necessário

Disciplina de Implementação
OBJETIVOS
 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
(arquivos-fonte, binários, executáveis e outros)
 Testar os componentes desenvolvidos como unidades
 Integrar os resultados produzidos por implementadores
individuais (ou equipes) ao sistema executável

Modelo de projeto
Modelo de dados
Implementação
Documento da
arquitetura
Modelo de implementação
Componentes
Plano de Integração
Documento da
arquitetura

Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte

 Identificar quais componentes participam da iteração (colaboram
para os casos de uso da iteração)
: C lie n t e
C o n t ro la d o r
C lie n t e
M a q u in a
D in h e iro
B a n c oLe it o ra C a rt a o C lie n t eF o rm u la rio
S a q u e
in s e re c a rt a o
in ic ia r s e s s a o (d a d o s c a rt a o )
s oli ci t a s e nh a
s o lic it a s e n h a
e n t ra s e n h a
e n t ra s e n h a
n e w C lie n t e (d a d o s c a rt a o , s e n h a )
v e rif ic a s e n h a
so lic it a v a lo r
s o lic it a v a lo r
e n t ra v a lo r
e n t ra v a lo r
v e rif ic a s a ld o (v a lo r)
s o lic it a d e b it o (v a lo r)
s ol ici t a d e v ol uc a o c art a o
s o lic it a e n t re g a d in h e iro
c a rt a o
d in h e iro

 Identificar quais pacotes participam da iteração (colaboram para
os casos de uso da iteração)
Applicação
Negócio
Middleware
Básico
*
*
*
*
*
Candidatos a Stubs
x
x

Aplicação
Comunicação
Negócio
Dados
3
Stubs2
2
1
1
aa bb
cc dd
ee gg
ff
hh ii jj
 Definir os builds que serão gerados

 Avaliar resultados
◦ A ordem de integração reduz a necessidade de
criação de stubs?
◦ A ordem de integração facilita a detecção de erros?

 Modelo de Implementação
◦ Modelo de projeto gerado a partir da engenharia
reversa do código fonte do sistema

 Check-out dos componentes
 Implementar
◦ Operações
◦ Inicialização dos atributos
◦ Estados
 Comentar o código implementado
◦ Seguindo um padrão de codificação

 Avaliar o código implementado
◦ Padrão de codificação
◦ Fatores de qualidade de OO e Java
 Compilar o código implementado
◦ Com a última versão estável dos componentes auxiliares
◦ Com a versão mais recente dos componentes
implementados
 Check-in dos componentes

 Check-out dos componentes
 Estabilizar a ocorrência do defeito
◦ Identificar casos de teste mínimos que causam o defeito
 Localizar o defeito no código
◦ Isolado do ambiente de produção
◦ Com ferramenta de depuração
◦ Comentando trechos do código
◦ Criando stubs
 Corrigir o defeito no código

 Implementar componentes de teste
◦ Separados dos componentes a serem testados
◦ Usando ferramenta para geração dos componentes de teste
 Ex: Junit
◦ Aproveitando componentes implementados anteriormente
(Check-out)
 Check-in dos componentes de teste
 Executar testes e avaliar resultados

 Revisar código
◦ Com base nos seguintes documentos:
 Padrão de codificação
 Fatores de qualidade de OO e Java
◦ Sem verificar se casos de uso foram corretamente
implementados
◦ Função corretiva, mas também educativa
 Passar mudanças para o programador responsável

 Check-out de todos os componentes do
repositório principal
 Integrar componentes em um build
 Notificar responsável pelos defeitos
 Criar tag (identificador) para o build
 Divulgar o build

Finalidade: Descrever as atividades que garantam que o produto de
software será disponibilizado a seus usuários finais.
Disciplina de Implantação
Esta Disciplina descreve três modos de implantação de produto:
 A instalação personalizada
 O produto em uma forma "compacta"
 Acesso ao software por meio da Internet
Em cada instância, a ênfase é testar o produto no local de
desenvolvimento, seguido de testes beta, antes de ele ser finalmente
oferecido ao cliente.

Os papéis envolvidos e os artefatos produzidos na
disciplina Implantação.

 Formado em Análise de Sistemas
 Pós-Graduado em Auditoria em T.I.
 Gerente de TI da CLIOC – Coleção de Leishmania do
Instituto Oswaldo Cruz – Fiocruz
 Certificado em Gestão de Segurança da Informação e
Gerenciamento de T.I. pela Academia Latino-Americana
(Microsoft TechNet / Módulo Security)
Carlos Henrique M. da Silva
carloshenrique.85@globo.com

Rational Unified Process (RUP)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Rational Unified Process (RUP)

Similaire à Rational Unified Process (RUP) (20)

Plus de Carlos Henrique Martins da Silva

Plus de Carlos Henrique Martins da Silva (16)

Rational Unified Process (RUP)