Você está na página 1de 12

MODELANDO PROCESSOS DE NEGÓCIOS COM RUP EM BUSCA DE

EXCELÊNCIA NO DESENVOLVIMENTO DE SOFTWARE


MARCELO NOGUEIRA
Universidade Paulista
Rua Dr. Bacelar 1212 – 4º - CEP 04026-002 – São Paulo – SP.
marcelo@noginfo.com.br

Resumo
As empresas de desenvolvimento de software desde a década de 60, buscam um modelo ideal
para realizar seus processos de criação de software. Diante do aumento da complexidade e
da necessidade das informações cada vez mais rápida e de relevância, o desenvolvimento
continua buscando utilizar uma coleção de melhores práticas a fim de obter sucesso no
desenvolvimento. Com a adoção do RUP (Rational Unified Process) que é um processo que
se utiliza de uma modelagem orientada a objetos com foco na especificação do negócio como
um todo, facilita a compreensão dos fluxos, e permite a realização de um projeto de software
mais próximo das necessidades das organizações.

Palavras-chave: UML, RUP, Modelagem de Processos de Negócios.

Abstract
The software development companies since decade of 60, they seek an ideal model to
accomplish their software creation processes. In front of the increase of the complexity and of
the need to information more and more fast and of relevance, the development continues
seeking to use a best practices collection in order to obtain success in the development. With
RUP's Adoption (Rational Unified Process) which is a process that is used of a guided
modeling for objects with focus in the specification of the business as one all, it facilitates the
comprehension of the flows, and it allows the accomplishment of a project of nearest software
in the needs to organizations.

Key words: UML, RUP, Business Processes Modeling.

1. INTRODUÇÃO
Num ambiente competitivo e de mudança cada vez mais complexo, a gestão adequada da
Informação assume uma importância decisiva no processo de tomada de decisão nas organizações.
Tratando-se de um tema simultaneamente abrangente e especializado, a adoção de uma metodologia
de desenvolvimento de software como linha base da Gestão da Informação, possibilitará, não só
desenvolver e consolidar os conhecimentos, bem como preparar os desenvolvedores para encarar
com confiança os novos desafios no mundo dos negócios, e reforçar as competências profissionais,
mantendo-se atualizado em relação ao potencial dos sistemas de informação e das novas tecnologias
numa perspectiva empresarial e competitiva globalmente.
A partir do conhecimento adquirido do RUP para a Engenharia de Software, o desenvolvedor será
elemento multiplicador de soluções, contribuindo e agregando valor aos sistemas novos e para os já
existentes, com aplicação de metodologias e tecnologias adequadas, capazes de gerir com sucesso as
informações relevantes aos negócios aplicáveis, trazendo ás organizações, vantagens competitivas.
No estudo da Engenharia de Software, o autor Roger S. Pressman [PRESSMAN02], demonstra
preocupação com a “Crise do Software” que atualmente ele intitula como “Aflição Crônica”,

1
chegando a determinar números expressivos sobre a não finalização de projetos de sistemas
começados e não terminados.
Num mundo cada vez mais de recursos financeiros escassos, como é possível aceitar tal desperdício
de tempo e dinheiro. O mesmo autor também aponta para o possível problema causador de tal
absurdo: “A falta de adoção de métodos, ferramentas e procedimentos adequados no
desenvolvimento de software e a difícil relação de entendimento entre o usuário com o analista
desenvolvedor”.
Existem várias técnicas de levantamento de requisitos e modelagem de software e o analista
desenvolvedor que não às implementam, tem dificuldades de realizar um projeto de sistemas livre de
manutenções e re-trabalhos, condenando diretamente a qualidade do produto.
A implementação do RUP, pelo desenvolvedor de software, direciona como realizar os principais
processos necessários para o desenvolvimento do software, proporcionando um método sistemático
de levantamento e modelagem, acompanhando todo o processo, permitindo que o software venha
representar a realidade da empresa, para geração de um sistema personalizado, atendendo assim as
necessidades desta empresa, obtendo qualidade no software, bem como criar a real possibilidade de
extrair de um sistema, informações relevantes que venham não só para contribuir com a decisão,
mas para ser um fator de excelência empresarial, permitindo novos negócios, permanência e
sobrevivência num mercado atuante.
2. RELEVÂNCIA
Segundo Lee [LEE02], as organizações estão se convertendo em organizações baseadas em
informações que dependem de um fluxo contínuo de dados para lidar com, virtualmente, todos os
aspectos de suas operações. A informação está se tornando cada vez mais crucial a todas as
decisões e oportunidades de negócios. Entretanto, o volume de informação está crescendo mais
rapidamente do que a capacidade de processá-las e de fazer um bom uso delas. Dessa maneira, as
organizações estão se “afundando” em seus próprios dados.
O problema é que:
• Os custos de projeto de software estão crescendo e os custos relativos a hardware diminuindo.
• O prazo para desenvolvimento de software está se tornando mais longo e os custos de
manutenção maiores, ao passo que simultaneamente, o tempo de desenvolvimento de
hardware está encurtando e se tornando mais barato.
• Os erros de software estão se tornando mais freqüentes, enquanto os erros de hardware,
praticamente inexistentes.
• O software é desenvolvido utilizando-se um processo rigidamente estruturado, que é
inflexível.
Tabela 1 – Custos de Projeto de Software por fase de desenvolvimento. [LEE02]
Etapa do Trabalho %
Análise dos Requisitos 3
Desenho 8
Programação 7
Testes 15
Manutenção 67
Os métodos atuais de criação de software resultam em sistemas de manutenção muito
dispendiosa. As organizações estão dependendo uma grande parcela de seus recursos financeiros
em testes e manutenção de sistemas. Infelizmente esses métodos atuais não são eficazes nos
estágios de análise de requisitos e desenho, em que o custo de correção é muito baixo. Além
disso, 85% de nossos erros são cometidos durante estes dois estágios citados. Aperfeiçoar essas
duas etapas é o modo mais rentável de melhorar a qualidade do software. [LEE02]

2
Tabela 2 – Custos para correção de erros de software. [LEE02]

Fase de desenvolvimento do % % Erros % Erros Custo Relativo


Software Desvios Introduzidos encontrados para correção
Análise dos requisitos 5 55 18 1,0
Desenho 25 30 10 1,0 – 1,5
Teste de código 10
Teste de Integração 50 10 50 1,0 – 5,0
Validação e Documentação 10
Manutenção Operacional 5 22 10 – 100
O tamanho da crise no desenvolvimento é medido quando: [LEE02]
• 16,2% dos projetos são bem-sucedidos (83,8% fracassados).
• 52,7% dos projetos são contestados.
• 31,1 % são cancelados antes de sua colocação no mercado.
Para reverter tal quadro, a adoção de processos sistêmicos, normas e modelos de qualidade, faz-se
necessário, pois a falta de metodologias compromete o sucesso do projeto.

Na implementação de qualquer processo é preciso fazer mudanças nos processos atuais. As


mudanças ocorrerão de acordo com o alinhamento aos objetivos de negócios da organização e
tratada como atividade permanente, controlada e quase rotineira, alcançando assim melhorias nos
processos. [PADUA03]

O sucesso no desenvolvimento de software depende em grande parte do conhecimento que não só


envolve programação e habilidades de gerenciamento, mas também do conhecimento e
compreensão das mais recentes inovações na industria do software. [FURLAN98]

3. PARADIGMA DA ORIENTAÇÃO A OBJETOS


Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo
homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos,
organizados, combinados, manipulados e criados. Conseqüentemente, não é surpresa que um
enfoque orientado a objetos fosse proposto para a criação de software, ou seja uma abstração que
nos permite modelar o mundo em modos que nos ajudam a melhor entendê-lo e a navegar nele.
[PRESSMAN02]
A grande maioria dos métodos empregados como modelo para o desenvolvimento de software, em
geral, é baseada em duas abordagens: na decomposição funcional e na modelagem de dados.
Verifica-se que tais métodos estão constituídos segundo um paradigma estruturado, onde se têm
visões dissociadas em que se distingue claramente os processos de dados. Os processos possuem
uma modelagem própria e os dados idem. Em algum ponto, nos métodos tradicionais empregados
como análise estruturada e análise essencial, as abordagens de processos e dados se cruzam, uma
vez que na realidade os processos acessam os dados, de alguma forma, o método deve retratar com
fidelidade o que ocorre no ambiente real. Tanto nos métodos da análise estruturada quanto na
análise essencial, o Diagrama de Fluxo de Dados é empregado na representação da funcionalidade;
porém, como elemento necessário que dá subsídios às funções, também aparecem os dados nos
depósitos de dados; posteriormente, ou paralelamente, desenvolve-se uma modelagem de dados, em
geral, empregando-se o Diagrama de Entidade de Relacionamento. [TONSIG03]
No paradigma orientado a objetos, os dados e as funções são vistos de forma agregada, não
ocorrendo uma modelagem separada para cada um desses componentes; portanto, sob esse ponto de
vista, a orientação a objetos favorece uma modelagem mais natural, que melhor retrata a realidade,
pois processos e dados estão coligados, não se encontram dissociados em nenhuma atividade real.
[AMBER97]

3
A orientação a objetos fundamenta-se em princípios que não são novos [YOURDON92].
Especialmente como modelo para o desenvolvimento de software, a orientação a objetos possui uma
propriedade sinergética, na qual seus componentes podem ser arranjados para melhor espelhar a
solução sistêmica dada a um problema do usuário; o qual deve previamente ser entendido na fase de
levantamento dos requisitos. [BOOCH00]
O paradigma da orientação a objetos surgiu primeiramente com a programação de computadores no
final dos anos 60, com a linguagem SIMULA. Nos anos 70, era parte importante da linguagem
SMALLTALK, desenvolvida pela Xerox. Esse paradigma só estreou na análise de sistemas no final
da década de 80 [RUMBAUGH94], [YOURDON92].

No início dos anos 90, o paradigma da orientação a objetos passou a ocupar lugar de destaque no
desenvolvimento de software. Três aspectos foram relevantes para a ascensão da orientação a
objetos, contrapondo-se aos métodos estruturados: a unificação de conceitos entre as fases de análise
e programação, o grande potencial de reutilização do software e a facilidade de manutenção. A
orientação a objetos também se apresentou com a esperança de suprir algumas das preocupações da
indústria do software: a necessidade de criar softwares corporativos muito mais rapidamente, mais
confiáveis e a um custo baixo. Os meios para conseguir essa proeza encontram-se nas características
apresentadas pelo paradigma da orientação a objetos, o que leva a um salto quantitativo e qualitativo
na produção do software [BOOCH00].
A característica básica dos métodos orientados a objetos, que se apresenta como uma grande
vantagem quanto a sua utilização, é a façanha de terem unificado os formalismos utilizados na
análise, projeto e programação. Os conceitos envolvidos são os mesmos, independentemente da fase
no desenvolvimento do software, o que, teoricamente, vem facilitar a forma de comunicação entre o
pessoal técnico envolvido no projeto. [TONSIG03]
A orientação ao objeto se dedica a desenvolver um modelo orientado a objetos do domínio da
aplicação. Os objetos identificados refletem entidades e operações que estão associadas com o
problema a ser resolvido. [SOMMERVILLE03]
O enfoque da orientação a objetos, é uma visão sobre um mundo como uma coletânea de objetos
que interagem entre si, apresentando características próprias que são representadas pelos seus
atributos e operações. [FURLAN98]
3.1 O QUE É UM OBJETO?
Quando nos damos conta das coisas que nos cercam, intuitivamente constatamos a presença de
vários objetos. É também muito natural classificar esses objetos a partir de vários pontos de vista:
forma, utilidade, etc. Percebe-se que cada objeto tem características segundo sua estrutura e
funcionalidade. Ao examinar mais cuidadosamente determinado ambiente, verifica-se que existem
objetos que são semelhantes. [TONSIG03]
Um objeto é uma entidade que possui um estado e um conjunto definido de operações que operam
nesse estado. O estado é representado por um conjunto de atributos de objeto. As operações
associadas com o objeto fornecem serviços para outros objetos, que requisitam esses serviços
quando uma computação é necessária. Os objetos são criados de acordo com uma definição de
classe de objetos, que serve com um modelo para criar objetos. Essa classe apresenta declarações de
todos os atributos e operações que devem ser associados a um objeto dessa classe. A notação
utilizada para as classes de objetos é definida na UML. [SOMMERVILLE03]
Objeto é uma unidade de software que consiste em atributos, e de métodos. [LEE02]

Algumas propriedades dos objetos: [TONSIG03]


• Estado: Diz respeito à situação em que pode estar um determinado objeto. O estado depende da
natureza do objeto.

4
• Comportamento: Qualquer objeto apresenta um comportamento. O comportamento é o meio
pelo qual o objeto passa de um estado para o outro. Normalmente, isso dá mediante uma
condição/ação a qual será sempre um método a ser executado.
• Identificação: Todo o objeto é identificável,portanto, são distinguíveis entre si.
3.2 CLASSE DE OBJETOS
Uma classe representa um conjunto de objetos da mesma característica. Cada um deles é uma
instância da classe, dado a sua existência são diferenciados por sua identidade. Uma instância herda
as características da classe a que pertence. [LEE02]
No conceito de orientação a objeto, classe é um conceito que encapsula as abstrações de dados e
procedimental necessárias para descrever o conteúdo e comportamento de alguma entidade do
mundo real. [PRESSMAN02]
Classe é uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas
operações. [FURLAN98]
3.3 ENCAPSULAMENTO
Encapsulamento é o conceito que faz referência à ocultação ou empacotamento dos dados e
procedimentos dentro do objeto. Não há dados ou procedimentos fora de um objeto. Cada objeto
poderá conter atributos, e procedimentos que guardará dentro de si. [LEE02]
O encapsulamento de operações e atributos, atribui vida própria ao objeto. [FURLAN98]

3.4 ACOPLAMENTO DINÂMICO, HERANÇA E POLIMORFISMO


Ao receber uma mensagem, o objeto verificará se existe um serviço, também chamado de método,
que defina seu comportamento perante essa mensagem. A mensagem sempre aciona um método
correspondente no objeto que recebeu a mensagem. [TONSIG03]

Pode ser que não exista no objeto acionado, um método de acordo com a inovação feita pela
mensagem. Caso o objeto não encontre um método dentro de seu encapsulamento, verificará em
seus ramos de herança aquelas superclasses que tenham o método invocado.

Esse mecanismo de busca de serviços é chamado de acoplamento dinâmico. [LEE02]

Mensagens iguais, destinadas a objetos diferentes, podem gerar comportamentos diferentes. Para
uma mesma mensagem, objetos diferentes podem responder ou agir de forma diferenciada; a isso
chamamos polimorfismo.
3.5 BENEFÍCIOS DO PARADIGMA DA ORIENTAÇÃO A OBJETOS
Espera-se uma ampla gama de benefícios com os quais a aplicação da orientação a objetos possa vir
a trazer no desenvolvimento do software. A expectativa é que venha a superar todos os benefícios
atingidos pelos métodos convencionais de construção de software ainda utilizados. [TONSIG03]
• Modelagem mais natural: A aplicação dos conceitos da orientação a objetos na análise de
sistemas permitirá modelar a empresa ou as áreas da aplicação de uma forma mais natural, visto
que os recursos a serem aplicados retratam com mais facilidade o mundo real. A capacidade de
retratar o universo pesquisado é moldado em diagramas que refletem exatamente o arranjo dos
objetos no mundo real. A própria transição entre etapas na construção do software, aplicando-se
o paradigma orientado a objetos, são refinações sucessivas com os mesmos conceitos e
linguagem.
• Reutilização: Diante da forma como são projetados os recursos do software, é possível atingir a
maximização na reutilização. Várias classes projetadas constituirão bibliotecas, que poderão ser
acionadas por outros projetos diferentes daqueles que a originaram.

5
• Projetos mais rápidos com qualidade: Em função da característica da reutilização, uma vez que
existam bibliotecas que ofereçam classes com recursos necessários, novos projetos utilizarão
esses componentes pré-existentes. Em conseqüência, se espera que novas construções devam
demorar menos tempo do que se feitas de outra forma. O fato das bibliotecas serem utilizadas
por diversos projetos, implica que os recursos lá existentes estarão testados e com sua
funcionalidade aprovada; portanto, além da velocidade na construção de novos projetos, acabam
colaborando para a inexistência de erros, aumentando o grau de qualidade do software.
• Codificação mais simples de programas: Também dado à estrutura de como se apresenta o
paradigma da orientação a objetos, a codificação de métodos reduz a complexidade na
construção do código dos programas. Isso traz simplicidade no momento de codificar, testar e
manter o software.
É importante destacar que os benefícios da tecnologia orientada a objetos são ampliadas se ela é
adotada no início e ao longo de todo o processo de engenharia de software. [PRESSMAN02]
4. UML – Unified Modeling Language
A UML é uma linguagem de modelagem para documentar e visualizar os artefatos que
especificamos e construímos na análise e desenho de um sistema. [LEE02]
A UML é uma linguagem de modelagem, totalmente orientada a objetos, que une as melhores
práticas e metodologias da Engenharia de Software. É considerada a sintaxe geral para criar um
modelo lógico de um sistema. Ela é utilizada para descrever pontos de um sistema e da forma como
ele é percebido de várias visões durante a análise e sua arquitetura. É uma linguagem que visa
capturar conhecimento e expressar esse conhecimento. Seu propósito é a modelagem de sistemas,
documentar de maneira interativa e visual, proporcionar melhor compreensão e sinergia entre o
analista e o cliente envolvido no processo de desenvolvimento. [NOGUEIRA02]
4.1 Modelagem Visual
A modelagem visual é o uso de notações de design gráficas e textuais, semanticamente ricas, para
capturar design 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ígida. Dessa maneira, a comunicação na equipe
de design melhora, à medida que o design é formado e revisado, permitindo ao leitor raciocinar
sobre ele e fornecendo uma base não ambígua para a implementação. [IBM03] [NOGUEIRA02]
4.2 Por que Modelamos?
Um modelo é uma visão simplificada de um sistema. Ele mostra os elementos essenciais do sistema
de uma perspectiva específica e oculta os detalhes não essenciais. Os modelos podem ajudar das
seguintes maneiras: [IBM03] [LEE02]
• ajudando na compreensão de sistemas complexos
• explorando e comparando alternativas de design a um baixo custo
• formando uma base para implementação
• capturando requisitos com precisão
• comunicando decisões sem ambigüidade
4.3 Ajuda na compreensão de sistemas complexos

A importância dos modelos aumenta à medida que os sistemas se tornam mais complexos. Um
aplicativo pequeno, criado por uma única pessoa em alguns dias, pode ser facilmente compreendido
em sua totalidade. No entanto, um sistema de comércio eletrônico com dezenas de milhares de
linhas de código-fonte, ou um sistema de controle de tráfego aéreo de centenas de milhares de linhas
de código, não pode mais ser facilmente entendido por uma única pessoa. A construção de modelos
permite a um desenvolvedor se concentrar na visão geral, entender como os componentes interagem
e identificar falhas fatais.

6
Alguns exemplos de modelos são: [IBM03]
• Casos de Uso para especificar comportamento de forma não ambígua.
• Diagramas de Classes e Diagramas de Modelo de Dados para capturar design.
• Diagramas de Transição de Estado para modelar comportamento dinâmico.

A modelagem é importante, pois ajuda a equipe a visualizar, construir e documentar a estrutura e o


comportamento do sistema, sem se perder na complexidade.
4.4 Exploração e comparação de alternativas de design a um baixo custo
Modelos simples podem ser criados e modificados a um baixo custo para explorar alternativas de
design. Idéias inovadoras podem ser capturadas e revisadas por outros desenvolvedores, antes de
investir em um desenvolvimento de código caro. Quando associada ao desenvolvimento iterativo, a
modelagem visual ajuda os desenvolvedores a avaliar mudanças de design e a comunicar essas
mudanças a toda a equipe de desenvolvimento. [IBM03]
4.5 Formação de uma base para implementação
Atualmente, muitos projetos empregam linguagens de programação orientadas a objetos para obter
sistemas reutilizáveis, tolerantes a mudanças e estáveis. Para obter essas vantagens, é ainda mais
importante usar tecnologia de objetos em design. O Rational Unified Process (RUP) produz um
modelo de design orientado a objetos que é a base para a implementação. Com o suporte das
ferramentas adequadas, um modelo de design pode ser usado para gerar um conjunto inicial de
código para implementação. Isso é referido como "engenharia direta" ou "geração de código". Os
modelos de design também podem ser aprimorados para incluir informações suficientes para criar o
sistema. [IBM03]
A engenharia reversa também pode ser aplicada para gerar modelos de design a partir de
implementações existentes. Isso pode ser usado para avaliar implementações existentes.
"A engenharia round-trip" combina as técnicas de engenharia direta e reversa para garantir código e
design consistentes. Combinada com um processo iterativo e com as ferramentas certas, a
engenharia round-trip permite que o código e o design sejam sincronizados durante cada iteração.
4.6 Captura de requisitos com precisão
Antes de criar um sistema, é essencial capturar os requisitos. A especificação dos requisitos usando
um modelo preciso e não ambíguo ajuda a garantir que todos os envolvidos possam entender e
concordar com os requisitos. Um modelo que separa o comportamento externo do sistema da
implementação o ajuda a se concentrar no uso pretendido do sistema, sem ficar perdido nos detalhes
de implementação. [IBM03]
4.7 Comunicação de decisões sem ambigüidade

O RUP usa a UML, que é uma notação consistente que pode ser aplicada tanto para a engenharia de
sistemas quanto a engenharia de negócios. Uma notação padrão serve aos seguintes papéis: [IBM03]

• "Serve como uma linguagem para comunicar decisões que não são óbvias ou que não podem ser
deduzidas do próprio código."
• "Fornece semântica rica o suficiente para capturar todas as decisões estratégicas e táticas
importantes."
• "Oferece uma forma concreta o suficiente para que as pessoas raciocinem e para que as
ferramentas sejam manipuladas."
UML representa a convergência da melhor prática em modelagem de software por toda a
indústria de tecnologia de objetos.

7
5. RUP
O RUP (Rational Unified Process) é um framework genérico para processos de desenvolvimento de
software, criado pela empresa Rational Software Corporation, que está fortemente centrado na
arquitetura, funcionalidade (caso de uso) e o desenvolvimento iterativo e incremental (inspirado no
ciclo de vida espiral de Boehm), que aplica a UML, para o projeto e a documentação. [TONSIG03]

O RUP é um processo de desenvolvimento de software e, como tal, descreve os papéis e as


atividades que cada membro da equipe de projeto deve desempenhar ao longo do ciclo de
desenvolvimento do software e os produtos que devem ser gerados como resultado destas
atividades, os chamados artefatos. [BALDUINO02]

5.1 Histórico
Consta como primórdios do RUP a metodologia da empresa Ericsson, que era uma abordagem
baseada em componentes, os quais se agrupam desde uma visão de baixo nível até atingir-se
subsistemas em alto nível. A especificação de como blocos ou componentes se aglutinavam e
cooperavam entre si dava-se pelos ‘caso de negócio’ (casos de uso), que previamente deveriam ser
identificados. Além disso se gerava uma série de diagramas que mostravam como os diferentes
blocos ou componentes dinamicamente, para satisfazer os casos de negócio. Seu grande ponto
positivo foi o de permitir uma nova configuração do sistema, a partir de um replanejamento dos
blocos com interfaces bem definidas, para tanto bastava trocar um bloco por outro que
proporcionasse a mesma interface.
Entre os anos de 1987 e 1995, Jacobson lança e evolui um processo de desenvolvimento de software
chamado Objectory (Object Factory), na sua empresa ‘Objectory AB’. Nesse processo, se verifica
um aprofundamento e amadurecimento do conceito de ‘casos de negócio’ criado pela Ericsson,
passando-se a ter os casos de uso como uma técnica para sua representação, além da idéia de
ampliar sua utilização para uma grande variedade de aplicações.
No final de 1995, a Rational Software Corporation comprou a empresa Objectory AB com o
propósito de unificar os princípios básicos dos diferentes processos de desenvolvimentos então
existentes. A partir dessa aquisição até 1997, se desenvolve o Rational Objetory Process (ROP),
fruto da união da abordagem Rational com o Objectory, e adota-se a UML, como linguagem de
modelagem.
O novo processo, contudo, não tratava de questões como a gestão do projeto e ambiente nem
oferecia aprofundamento relativo à implementação e testes. A partir desse cenário, surge uma nova
proposta que buscou expandir os conceitos do ROP, incorporando vários elementos, tais como os
fluxos de trabalho.
5.2 Estrutura do RUP
Falando sob o aspecto da engenharia de processo, onde o RUP dá diretrizes para sua própria
implementação, implementar um novo processo em uma empresa de desenvolvimento de software é
um projeto por si só e que, por sua vez, pode ser descrito em quatro passos distintos.
[BALDUINO02]
Figura 1 – Passos para implementar o processo. [BALDUINO02]

8
O RUP se preocupa em retratar a arquitetura do sistema, isto é, uma visão do desenho completo
ressaltando as mais importantes características, identificadas pelas pessoas que tenham
responsabilidade na construção do projeto (clientes, usuários e analistas). Cada projeto de software
tem uma forma (arquitetura) e uma funcionalidade, que devem coexistir de maneira equilibrada para
a obtenção de êxito na implantação do produto. [TONSIG03]
A funcionalidade no RUP corresponde a casos de uso, os quais podem ser vistos como fragmentos
da funcionalidade de um sistema. Por intermédio dos casos de uso, de representa os requisitos
funcionais, porém, eles não só começam os processos de desenvolvimento mas provêem uma linha
condutiva, fazendo com que o processo avance através de uma série de fluxos de trabalho, chegando
até a serem as fontes a partir das quais se constitui os ‘casos de teste’.
Existem diferentes maneiras de se implementar o processo e as ferramentas em um projeto. A
diferença básica consiste em se adotar todo o RUP e todas as ferramentas de suporte ou somente
parte do RUP e das ferramentas, naquelas áreas do projeto que estejam descobertas ou com
problemas. A abordagem escolhida depende do estado atual do projeto e das áreas envolvidas. Em
linhas gerais, a escolha depende dos problemas que foram identificados e priorizados para o projeto
e qual a capacidade de mudança que a equipe pode suportar. [BALDUINO02]
Todo o conjunto que forma o RUP está baseado em uma série de princípios considerados
fundamentais para o desenvolvimento de um software: [IBM03]
• Desenvolvimento iterativo do software: Facilita os ajustes táticos dos requisitos e de novas
características. Provoca-se a identificação antecipada de riscos no projeto, quando ainda é
possível interferir a tempo e eficientemente. As inconsistências entre os requisitos, projeto e
implementação são detectadas antecipadamente.
• Administração dos requisitos: Consiste na administração dos requisitos de um sistema, os quais
são dinâmicos e podem mudar ainda durante a elaboração do projeto do sistema.
• Utilização de arquitetura baseada em componente: Apresenta a possibilidade de reutilização e
adaptação de componentes existentes em inúmeras fontes. Os componentes são módulos,
pacotes ou subsistemas que contemplam uma funcionalidade claramente delimitada. Trata-se de
uma realização física de uma abstração existente no projeto.
• Modelagem visual do software: As ferramentas de modelagem visuais facilitam a administração
de modelos. Os modelos são criados para ajudar a equipe de desenvolvimento a visualizar,
construir e documentar a estrutura e o comportamento da arquitetura de um sistema. Ao utilizar
uma linguagem de modelagem padrão, os diferentes membros da equipe no projeto podem
comunicar suas decisões sem ambigüidades.
• Qualidade do software: A construção de um software deve considerar a avaliação contínua da
qualidade, com relação à funcionalidade, confiabilidade e validação.
• Gestão das alterações no software: Coordenação das atividades que originam os módulos e suas
respectivas versões.
O RUP apresenta a característica de ser configurável pela organização que vai empregá-lo, de
maneira que é possível sua adequação para uma utilização efetiva. Por meio de processos iterativos,
permite uma compreensão crescente dos requisitos na medida em que o sistema vai ganhando corpo.
A interação trata de um grupo de casos de uso que, juntos, ampliam a funcionalidade do produto
desenvolvido até certo momento, ajudando também na identificação de riscos potenciais. Em cada
iteração se identifica e se faz a especificação dos casos de uso mais relevantes, se desenvolve um
projeto utilizando a arquitetura como guia, se implementa o projeto por intermédio de componentes,
os quais, posteriormente, devem ser verificados quanto ao atendimento dos casos de uso.
[TONSIG03]
O RUP tem uma definição de atividades que contemplam desde o planejamento do projeto até os
processos de testes. Em função da reunião de todas essas características, o método parece adequado
à construção de sistemas de maneira a atender os parâmetros de qualidade e produtividade. [IBM03]

9
O processo de desenvolvimento utilizando o RUP se dá mediante uma série de ciclos que constituem
uma versão do produto. Cada ciclo é constituído de quatro frases: concepção, elaboração, construção
e transição. Em cada uma dessas fases é que se realizam as iterações abrangendo uma série de fluxos
de trabalho (atividades).
Figura 2 – Processo de Desenvolvimento – RUP. [IBM03]

A estrutura global do RUP é estabelecida em quatro fases que possuem objetivos específicos:
[BALDUINO02]
• Concepção: Deve-se estabelecer o escopo e a viabilidade econômica do projeto.
• Elaboração: Nesta fase, busca-se identificar e eliminar os principais riscos, estabelecendo-se
uma arquitetura estável a partir da qual o sistema a ser projetado poderá evoluir.
• Construção: De forma iterativa, ocorre o desenvolvimento do produto até sua conclusão.
• Transição: Nesta fase, o produto pronto é disponibilizado ao usuário (versão beta). No final da
fase, decorrente de vários fatores que contribuem para a evolução do produto, um novo ciclo
dentro da estrutura global pode ser iniciado (envolvendo todas as fases novamente).

Todas as fases do modelo são finalizadas com um milestones, no qual se verifica se os objetos
traçados foram efetivamente alcançados. Em cada uma dessas fases (concepção, elaboração,
construção e transição) podem ser necessárias várias iterações. Cada iteração é um ciclo dentro da
fase que pode compreender até nove atividades (workflow).
As atividades existentes no RUP podem ser divididas em dois blocos, nos quais as seis primeiras
constituem o bloco da Engenharia de Software e as três últimas o bloco de suporte. [TONSIG03]
Atividades referentes à Engenharia de Software:
• Modelagem do Negócio (Business Modeling): Trata-se da sociabilização ou entendimento
partilhado por todos quanto à estrutura, dinâmica e o modelo de gestão da organização do
cliente, de maneira que tanto os usuários quanto a equipe de desenvolvimento possam ter a
mesma visão organizacional, para qual é planejado um novo software.
• Requisitos (Requirements): Envolve a busca, compreensão e documentação dos requisitos do
sistema, bem como a gestão do escopo e mudanças.
• Análise e Projeto (Analysis and Design): Transformação dos requisitos em especificação
técnicas que descrevem como implementar o software.
• Implementação (Implementation): Trata-se da criação de programas de computador, segundo as
especificações técnicas existentes. Espera-se que os programas sejam criados segundo os
conceitos da orientação a objetos e sejam testados (testes de unidade). Também devem ser
construídas as integrações eventualmente necessárias com outros sistemas.
• Testes (Test): Considera-se que devem ser realizados os testes de conjunto (sistema criado) e de
integração com outros sistemas existentes. Devem ser realizadas atividades de validação, isto é,
checar se os resultados apresentados são compatíveis com os requisitos especificados.

10
• Desenvolvimento (Deployment): Envolve o planejamento de beta testes, atividades de
empacotamento do software, distribuição, instalação e treinamento de usuários.
Atividades referentes a suporte:
• Gestão de configuração (configuration and Change Management): Considera o gerenciamento
de todos os artefatos criados durante o processo de desenvolvimento do software.
• Gestão do projeto (Project Management): Trata-se das atividades de planejamento,
acompanhamento do desenvolvimento do projeto e gerenciamento dos riscos.
• Ambiente (Environment): Atividades de organização do ambiente de trabalho para a equipe do
projeto e o acompanhamento da configuração do RUP para o projeto.

Os profissionais de desenvolvimento de software, dentro de um ambiente que venha a empregar o


RUP, passarão a conviver com alguns conceitos existentes no modelo: [TONSIG03]
• Artefato: Refere-se à informação tangível que é utilizada, criada ou alterada pelos trabalhadores
em suas atividades. Representa uma área de responsabilidade, a qual deve ser considerada no
controle da configuração do modelo.
• Atividade: Trata-se de uma unidade tangível de trabalho bem delimitado, que é realizado por um
trabalhador dentro de uma rotina, implicando em uma responsabilidade bem definida,
produzindo um resultado que possa ser avaliado a partir de entradas conhecidas.
• Modelo: É uma completa descrição de um sistema a partir de uma perspectiva particular, uma
abstração.
6. EXEMPLO DE APLICAÇÃO
Para melhor ilustrar os benefícios da modelagem de processos de negócios, utilizando o RUP e
sua ferramenta específica para realizar a modelagem em UML, a seguir, um exemplo de processo
de negócio de uma empresa cuja estratégia é a de realização de cursos livres, modelado utilizando
o RUP.
Figura 3 - Business Use Cases – Empresa de Cursos Livres.
Business
Use Case

Business
Ator

Business
Worker

11
Através da modelagem acima, aumenta a visibilidade dos processos de negócios, permitindo
identificar quais processos devem ou não ser transformados em sistemas informatizados.
É possível também identificar antes da implementação, quais processos são redundantes e se
devem ou não sofrer alterações de seus fluxos, permitindo otimização e redução de caminhos
para alcançar os mesmos objetivos, sem perder a essência da existência daquele processo.
7. CONCLUSÃO
Com a implementação do RUP, a empresa desenvolvedora terá mais controle e gerenciamento
através de uma metodologia focada aos processos fundamentais de desenvolvimento de software.

Sendo também um processo sistêmico e que contém as melhores práticas da engenharia de


software, permitirá aderência de normas e modelos como ISO 12.207 e CMMI.
Além dos benefícios que a adoção da UML já traz, a implementação de um processo completo de
desenvolvimento de software com uma modelagem de processo de negócio, evitará fracassos nas
fases mais críticas de todo o processo, levantamento de requisitos e design do software.
Com a adoção do RUP como fator crítico de sucesso no desenvolvimento de software, permitirá
eventuais correções dos processos de negócios, antes da sua identificação como requisito de um
sistema, evitando falhas na compreensão e concepção daquilo que se deve ser desenvolvido.
Os softwares que atenderem os requisitos dos clientes e aderirem aos processos de negócios da
empresa, naturalmente proporcionarão novos negócios e principalmente vantagens competitivas,
alcançando efetivamente a excelência empresarial.
8. REFERÊNCIAS BIBLIOGRÁFICAS
[AMBLER97] AMBLER , S.W.Análise e projeto orientados a objeto, Infobook, Rio de Janeiro,1997.

[BALDUINO02] BALDUINO, RICARDO, Implementando um processo de desenvolvimento de software: uma abordagem passo
- a - passo,Rational Software White Paper, IBM, São Paulo, 2002.

[BOOCH00] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.UML, Guia do usuário. Campus, Rio de Janeiro,2000.

[FURLAN98] FURLAN, JOSÉ DAVI, Modelagem de objetos através da UML, Makron, São Paulo, 1998.

[IBM03] Modelagem Visual, IBM, São Paulo, 2003. http://www.rational.com/worldwide/brazil/port_uml.jsp

[JACOBSON98] JACOBSON, IVAR, et al., The Unified Software Development Process, Addison Wesley, 1998. ISBN 0-201-57169-
2.

[KRUCHTEN98] KRUCHTEN, PHILIPPE, The Rational Unified Process – an Introduction, Addison-Wesley, 1998. ISBN: 0-201-
60459-0.

[NOGUEIRA02] NOGUEIRA, MARCELO, UML – Modelando sistemas com UML, The Club Magazine, ed. 99, Avaré – SP,
2002.

[PADUA03] FILHO, WILSON DE PÁDUA PAULA, Engenharia de Software, Ed. LTC, São Paulo, 2003.

[PRESSMAN02] PRESSMAN, ROGER S., Engenharia de Software,MC Graw Hill, Rio de Janeiro,2002.

[SOMMERVILLE03] SOMMERVILLE, IAN, Engenharia de Software, Addison Wesley, São Paulo,2003.

[TONSIG03] TONSIG, SERGIO LUIZ, Engenharia de Software, Ed. Futura, São Paulo, 2003.

[YORDON92] YOURDON, E.Análise baseada em objetos. 2ºEd.,Campus, Rio de Janeiro,1992.

Publicação:

- Anais do IEEE, WCETE2004 World Congress on Engineering and Technology Education,


em 12 de março de 2004, Guarujá – SP.

12

Você também pode gostar