FACULDADE JESUS MARIA JOSÉ

TECNOLOGIA EM REDES DE COMPUTADORES

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

THAIS DE AGUIAR COSTA

MAYHARA LIMA
RODRIGO DE JESUS
JARDEL BRITO

RUP (RATIONAL UNIFIED PROCESS)

Taguatinga

2010
 2

IMPLEMENTAÇÃO DO RUP (RATIONAL UNIFIED PROCESS) PARA

APERFEIÇOAMENTO DA GESTÃO DE DESENVOLVIMENTO DE SOFTWARE.

Mayhara Luayce T. Matos Lima (1)

Jardel Brito de Carvalho (2)
Rodrigo de Jesus Silva (3)
Thais de Aguiar Costa (4)

RESUMO: Quando se trata de tecnologia da informação uma boa gerencia dos processos de
desenvolvimento tem sido um diferencial para se obter padronização dos processos e uma boa
qualidade do produto final, a escolha da metodologia para resolução de problemas na gestão
do projeto ou na equipe de desenvolvimento do software deve ser peculiar às necessidades da
empresa. O RUP (Rational Unified Process) e uma metodologia que se aplica no
gerenciamento de processos que viabilizam padronizar técnicas e dividir as funções do
processo de construção. Entres as propriedades do RUP temos a implementação de técnicas de
Engenharia conhecido como Melhores Praticas que reduzem os riscos e otimizam o processo
de construção sendo estas técnicas a maior potencialidade do RUP. Por ser considerado um
método muito difícil de ser implementado e atendendo as tendências e necessidades de
mercado em suas versões mais recentes o RUP apresenta Modelos de metodologias ágeis
sendo este tipo uma nova tendência do mercado.

PALAVRAS-CHAVE: Software, Desenvolvimento, Padronização, Metodologia, Qualidade.

1
¹ Mayhara Luayce T. Matos Lima – Estudante de Tecnologia em Análise e desenvolvimento de sistemas, ²
Jardel de Carvalho Brito – Estudante de Tecnologia em Análise e desenvolvimento de sistemas, ³ Rodrigo de
Jesus Silva – Estudante de Tecnologia em Análise e desenvolvimento de sistemas, 4 Thais de Aguiar Costa –
Estudante de Tecnologia em redes de computadores. Professor Orientador: Flaviano Oliveira Silva - Especialista
em Gestão de Produção de Software e Bacharel em Ciências da Computação. Faculdade Jesus Maria José –
FAJESU.
 3

ABSTRACT: When we are talking about technology of information a good management of

development processes has been a differential to get standardization of processes and a good
final product quality, the choice of methodology for solving problems in project management
or development team software must be peculiar to the needs of the company. RUP (Rational
Unified Process) is a methodology that applies the processes that enable management to
standardizes technical and split the roles of the construction process. Entres properties of RUP
we have the implement engineering techniques known as Best Practices those minimize risk
and optimize the process of building, these techniques being the greater potentiality of RUP.
Because this is a method very difficult to be implemented and given the trends and market
needs in its most recent versions of RUP agile models has been such a new market trend.

KEYWORDS: Software, Development, Standardization, Methodology, Quality.

1. INTRODUÇÃO

O mundo de gestão de projetos para elaboração de Software esta em freqüente mudança para
se adaptar as novas tendências e necessidades do mercado, uma boa gerência de projetos tem
se tornado um fator competitivo no mercado, dado que influencia diretamente na qualidade do
produto final. E devido a essa complexidade surgem diversos problemas a serem enfrentados
pelas empresas desenvolvedoras como, por exemplo:

• Necessidades do usuário ou negócio não atendidas

• Requisitos Instáveis.
• Módulos que não se integram.
• Dificuldades de Manutenção.
• Descoberta tardia de erros.
• Qualidade ou experiência dos usuários pobres.
• Performance de carga sofrível.
• Esforço descoordenado da equipe.
• Questões de versionamento.
 4

Para solução dessa problemática, muitas empresas e organizações voltadas para o

desenvolvimento de softwares investem na melhoria de seus processos de desenvolvimento.
Existem diversos padrões, referências, ou modelos reconhecidos que podem ser aplicados
para atingir este fim. O Rational Unified Process (RUP) é um processo de engenharia de
software desenvolvido pela Rational Software Corporation adquirida pela IBM e surge da
necessidade de soluções para melhoria de Processos na construção de software sua meta é
garantir a produção de software de alta qualidade que atenda às necessidades dos usuários
dentro de um cronograma e de um orçamento previsível oferecendo uma abordagem que tem
como base 5 Linhas Mestras (Gestão de Requisitos, Uso da Arquitetura de Componentes, Uso
de Software de Modelo Visuais, Verificação de Qualidade do Software, Gestão e Controle e
Mudanças do Software) 4 Fases (Iniciação, Elaboração, Construção, Transição) 8 Disciplinas
(Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação,
Ambiente e Gerenciamento de Projeto, Gerenciamento de Configuração e Mudança) e 5
Melhores Praticas (Desenvolvimento Interativo, Gerenciamento de Requisitos, Uso da
Arquitetura de Componentes, Modelagem Visual, Continua Verificação de Qualidade,
Gerenciamento de Mudanças) que atribuem tarefas e responsabilidades dentro de uma equipe
de desenvolvimento. O RUP estabelece um processo em equipe que define quem (papel) esta
fazendo o que (artefatos) como (atividade) e quando (fluxo) de modo a alcançar determinada
meta.

2. RATIONAL UNIFIED PROCESS: LINHAS MESTRAS

O RUP define as seguintes linhas-mestras para avaliação do progresso do projeto pela sua
gerência.

2.1 GESTAO DE REQUISITOS

Uma documentação apropriada é essencial para qualquer grande projeto; note que o RUP
descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e
requisitos de negócio.

2.2 USO DA ARQUITETURA BASEADA EM COMPONETES

 5

A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível,
promovendo a reutilização de software e um entendimento intuitivo.

2.3 USO DE SOFTWARE DE MODELOS VISUAIS

Ao abstrair a programação do seu código e representá-la utilizando blocos de construção

gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução. O
uso de modelos visuais também pode permitir que indivíduos de perfil menos técnico (como
clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais
no projeto como um todo.

2.4 VERIFICACAO DE QUALIDADE DE SOFTWARE

O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção

de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.

2.5 GESTAO E CONTROLE DE MUDANCA DE 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.

3. RATIONAL UNIFIED PROCESS: FASES

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do 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. Embora isso varie muito de
acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio
tamanho deve prever a seguinte distribuição de esforço e programação:
 6

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro
fases produz uma geração do software. A menos que produto "desapareça", ele irá se
desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação,
elaboração, construção e transição, mas agora com ênfase diferente nas diversas fases. Esses
ciclos subseqüentes são chamados de ciclos de evolução. À medida que o produto atravessa
vários ciclos, são produzidas novas gerações.

• A fase de iniciação, foca no tratamento de riscos relacionados com o caso de negócio.

Deve ser verificado se o projeto é viável e se é financeiramente possível.
• Na fase elaboração, o foco deve ser nos riscos técnicos e arquiteturais. O escopo deve
ser revisado e os requisitos devem estar mais compreendidos.
• Durante a construção, a atenção será voltada para os riscos lógicos, e a maior parte do
trabalho será realizada.
• Na fase de transição, serão tratados os riscos associados com a logística de distribuição
do produto para a base de usuários.

Embora varie muito em empresas e projetos diferentes, um ciclo de desenvolvimento para um

projeto de tamanho médio, possui uma distribuição de esforço e programação.
 7

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários,
mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência
e assim por diante. Normalmente, a menos que ocorram mudanças significativas do produto
ou da arquitetura, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores,
pois a definição e a arquitetura básicas do produto foram determinadas por ciclos de
desenvolvimento anteriores.

4. RATIONAL UNIFIED PROCESS: DISCIPLINAS

Uma disciplina mostra todas as atividades que você deve realizar para produzir um
determinado conjunto de artefatos.
Disciplinas RUP:
- Modelagem de Negócios
- Requisitos
- Análise e Design
- Implementação
- Teste
- Implantação
- Ambiente e Gerenciamento de Projeto
- Gerenciamento de Configuração e Mudança

4.1 MODELAGEM DE NEGÓCIO

Finalidade:
- Entender a estrutura e a dinâmica da organização na qual um sistema deve ser implantado (a
organização-alvo).
- 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 sistema necessários para sustentar a organização-alvo.

4.2 REQUISITOS
 8

Finalidade:
- Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o
sistema deve fazer.
- Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do
sistema.
- Definir as fronteiras do sistema (ou delimitar o sistema).
- Fornecer uma base para planejar o conteúdo técnico das iterações.
- Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.
- Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos
usuários.

4.3 ANÁLISE E PROJETO

Finalidade:
- Transformar os requisitos em um projeto do sistema a ser criado.
- Desenvolver uma arquitetura sofisticada para o sistema.
- Adaptar o projeto para que corresponda ao ambiente de implementação, projetando-o para
fins de desempenho.

4.4 IMPLEMENTAÇÃO

Finalidade:
- 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.

4.5 TESTES
Finalidade:
- Localizar e documentar defeitos na qualidade do software.
- Avisar de forma geral sobre a qualidade observada no software.
 9

- Validar as suposições feitas nas especificações de design e requisito através de demonstração

concreta.
- Validar as funções do software conforme projetadas.
- Verificar se os requisitos foram implementados de forma adequada.

4.6 IMPLANTAÇÃO

Finalidade:
- Descrever as atividades que garantem que o produto de software será disponibilizado a seus
usuários finais:
• A instalação personalizada;
• O produto em uma forma "compacta”;
• Acesso ao software por meio da Internet.

4.7 GERENCIAMENTO DE CONFIGURAÇÃO E MUDANÇA

Finalidade:
- Controlar os inúmeros artefatos produzidos pelas muitas pessoas que trabalham em um
mesmo projeto.
- Evitar confusões dispendiosas e garantir que os artefatos resultantes não entrem em conflito
devido a algum dos seguintes problemas:
• Atualização Simultânea.
• Notificação Limitada.
• Várias Versões.

4.8 GERENCIAMENTO DE PROJETO

Finalidade:
- 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.
 10

4.9 AMBIENTE

Finalidade:
- A disciplina de Ambiente concentra-se nas atividades necessárias à configuração do processo
para um projeto.
- Oferece à organização o ambiente de desenvolvimento de software.
- Processos e ferramentas que dará suporte à equipe de desenvolvimento.

5. RATIONAL UNIFIED PROCESS: MELHORES PRATICAS

Um dos principais pilares do RUP é o conceito de melhores práticas (Best practices), que são
regras/práticas que visam reduzir o risco (existente em qualquer projeto de software) e tornar
o desenvolvimento mais eficiente. O RUP define seis melhores praticas (Best practices),
sendo elas:

Desenvolvimento Iterativo

Gerenciamento de Requisitos

Uso da Arquitetura de Componentes

Modelagem Visual (UML)

Contínua Verificação da Qualidade

Gerenciamento de Mudança

5.1 DESENVOLVIMENTO ITERATIVO

Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que consiste em várias
iterações. Uma iteração incorpora um conjunto quase seqüencial de atividades em modelagem
de negócios, requisitos, análise e projeto, implementação, teste e implantação, em várias
proporções, dependendo do local em que ela está localizada no ciclo de desenvolvimento.
Vantagens
 11

– Os riscos são reduzidos mais cedo, pois os elementos são integrados

progressivamente.
– As táticas e os requisitos variáveis são acomodados.
– A melhoria e o refinamento do produto são facilitados, resultando em um
produto mais robusto.
– As organizações podem aprender a partir dessa abordagem e melhorar seus
processos.
– A capacidade de reutilização aumenta.

5.2 GERENCIAMENTO DE REQUISITO

“Uma condição ou uma capacidade com a qual o sistema deverá estar em conformidade”
O gerenciamento de requisitos é uma abordagem sistemática para localizar, documentar,
organizar e controlar os requisitos variáveis em um sistema.
O gerenciamento de requisitos é definido formalmente como uma abordagem sistemática a
identificar, organizar e documentar os requisitos do sistema, além de firmar e atualizar
acordos entre o cliente e a equipe do projeto sobre os requisitos variáveis do sistema.
As chaves para o gerenciamento eficaz de requisitos incluem manter uma sentença clara dos
requisitos, junto com os atributos aplicáveis e a rastreabilidade para outros requisitos e outros
artefatos do projeto. A coleta de requisitos pode parecer uma tarefa bem precisa. Na realidade,
porém, os projetos enfrentam dificuldades pelos seguintes motivos:

• Nem sempre os requisitos são óbvios e podem vir de várias fontes.

• Existem diversos tipos de requisitos em diferentes níveis de detalhe.
• O número de requisitos pode se tornar impossível de gerenciar se eles não forem
controlados.
• Os requisitos estão relacionados uns com os outros, e também com o produto liberado
do processo de engenharia do software.
• Os requisitos têm propriedades exclusivas ou valores de propriedade. Por exemplo,
eles não são necessariamente igualmente importantes ou igualmente fáceis de se
atender.
 12

• Há várias partes interessadas, o que significa que os requisitos precisam ser

gerenciados por grupos de pessoas de diferentes funções.
• Os requisitos são alterados.

5.3 USO DA ARQUITETURA DE COMPONENTES

Os componentes são grupos de código coesos, na forma de código fonte ou executável, com
interfaces bem definidas e comportamentos que fornecem forte encapsulamento do conteúdo e
são, portanto, substituíveis. As arquiteturas baseadas em componentes tendem a reduzir o
tamanho efetivo e a complexidade da solução e, portanto, são mais robustas e flexíveis.
Um componente de software pode ser definido como um pedaço não-trivial de software, um
módulo, um pacote ou um subsistema, sendo que todos desempenham uma função clara,
possuem uma fronteira clara e podem ser integrados em uma arquitetura bem definida. É a
realização física de uma abstração do design.

5.4 MODELAGEM VISUAL (UML)

A modelagem visual é o uso de notações de design gráficas e textuais, semanticamente rico,

para capturar designs de software. Uma notação, como a UML, permite que o nível de
abstração seja aumentado, enquanto mantém sintaxe e semântica rígidas.

5.5 VERIFICAÇÃO DA QUALIDADE

 13

Obter qualidade não é simplesmente "atender a requisitos" ou produzir um produto que atende
às necessidades e expectativas dos usuários. Pelo contrário, a qualidade também inclui a
identificação das medidas e dos critérios para demonstrar a obtenção da qualidade e a
implementação de um processo para garantir que o produto por ele criado tenha atingido o
grau desejado de qualidade e possa ser repetido e gerenciado.
A localização e a solução dos problemas de software ficam de 100 a 1.000 vezes mais caros,
se realizados após a implantação. A verificação e o gerenciamento da qualidade durante o
ciclo de vida do projeto é essencial para atingir os objetivos corretos no momento certo.

5.6 GERENCIAMENTO DE MUDANÇAS

Um desafio importante quando se está desenvolvendo sistemas intensivos de software é lidar

com vários desenvolvedores, organizados em diferentes equipes, possivelmente em diferentes
locais, trabalhando juntos em várias iterações, releases, produtos e plataformas. Na ausência
de controle disciplinado, o processo de desenvolvimento rapidamente se transforma em caos.
Gerenciamento de Mudança consiste de um recurso utilizado para superar esse desafio.

6. CONCLUSÃO:

Na atualidade, o RUP, para algumas pessoas, é um tanto burocrático, complexo e

relativamente caro para ser implantado em uma empresa, em contra partida as metodologias
Ágeis estão emergindo como respostas para problemas persistentes na produção de softwares
de qualidade e falar em RUP pode parecer, errôneo, mas precisa-se ter a compreensão que
nenhum tipo de metodologia (Pesada ou Ágil) trará resolução de todos os problemas
encontrados no dia-a-dia da Tecnologia de Informação, cabendo cada empresa analisar
implementar uma metodologia que atenda as suas necessidades. O RUP na versão 7.1 trás
implementações de metodologia ágeis para poder atender as tendências.
Contudo comprova-se que RUP e suas técnicas de engenharia ainda são utilizadas por muitas
empresas que utilizam os conceitos da Orientação a Objetos como base para a Análise e
Projeto de Sistemas. Utilizando as metodologias e técnicas de melhores praticas e sabendo
executá-las independentemente da técnica de modelagem ou mesmo da notação em si em uso
 14

obtém-se o sucesso no processo com organização, difusão e capacitação das pessoas que irão
utilizá-lo.

REFERÊNCIAS BIBLIOGRÁFICAS:

Dantas, Fernando - Rational Unified Process 7 e ITIL v3

http://www-128.ibm.com

http://javafree.uol.com.br/artigo/871455/Obtendo-Qualidade-de-Software-com-o-RUP.html

http://www.guiafar.com.br/portal/index.php?
option=com_content&view=article&id=108%3Arup&catid=43%3Atecnologia-da-
informacao&Itemid=59&lang=pt

http://www.angusyoung.org/arquivos/artigos/trabalho_rup.pdf