Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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]
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]
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]
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.
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.
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]
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.
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.
[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.
[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.
[TONSIG03] TONSIG, SERGIO LUIZ, Engenharia de Software, Ed. Futura, São Paulo, 2003.
Publicação:
12