Metodologia RUP

U
N
I
M
I
N
A
S

1

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CINCIAS APLICADAS DE MINAS
Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAO

UM ESTUDO DE CASO DA APLICAO DA
METODOLOGIA RUP PARA ATUALIZAO DE UM
SOFTWARE

PAULO DONIZETT LORENA REIZ JNIOR

Uberlndia
2009
U
N
I
M
I
N
A
S

2

SOFTWARE

Trabalho de Final de curso submetido
UNIMINAS como parte dos requisitos para a
obteno do grau de Bacharel em Sistemas
de Informao.

Orientador: Prof. Walteno Martins Parreira Jr

U
N
I
M
I
N
A
S

3
UBERLNDIA - MG
2009

SOFTWARE

Trabalho de Final de curso submetido
UNIMINAS como parte dos requisitos para a
obteno do grau de Bacharel em Sistemas
de Informao.

Orientador: Prof. Walteno Martins Parreira Jr

Banca Examinadora:
Uberlndia, 04 de julho de 2009.

Prof. Esp. Walteno Martins Parreira Jnior (Orientador)

Prof. Dr. Mauro Hemerly Gazzani

Profa. Dra. Ktia Lopes Silva

UBERLNDIA - MG
2009
U
N
I
M
I
N
A
S

4

Dedico este trabalho a todos que colaboraram
para seu desenvolvimento, em especial ao Professor
Walteno Martins. Muito obrigado pelo apoio, dedicao e pacincia.

U
N
I
M
I
N
A
S

5
AGRADECIMENTOS

Agradeo a Deus por ter tido a chance de aprender uma profisso que me
satisfaz, atravs de uma escola responsvel e na companhia de pessoas to
agradveis como foram meus colegas e professores. Tambm agradeo a Deus a
fora para superar as dificuldades e a sorte em ter alcanado as recompensas
esperadas.
Agradeo ao meu pai, Paulo, e a minha me, Marli, que nunca pouparam
esforos para me dar a chance de ter uma vida com algum significado. Agradeo ao
meu irmo Fernando pelo apoio incondicional, a amizade e a companhia.
Agradeo ao professor Walteno Martins pela orientao, dedicao e pacincia.
Agradeo ao pessoal do Instituto Integrar, Edson Luiz e Rosana Denise, pela
oportunidade de ter trabalhado com pessoas to significantes, pelo apoio, orientao
e compartilhamento de experincias.
Agradeo a minha prima Cristiane Martins pela amizade e pelo abstract.

U
N
I
M
I
N
A
S

6
RESUMO

As organizaes tm se preocupado cada vez mais em obter maior
retorno sobre seus investimentos em projetos de software. Tambm procuram
planejar melhor seus recursos e seu tempo frente necessidades que surgem. Isso
porque, ainda hoje, a maioria dos projetos de desenvolvimento de software no
chega ao fim como planejado, e alguns no chegam ao fim. Prazos estourados,
custos extrapolados, escopo no atendido e usurio insatisfeito so o que se
procura evitar. Com este objetivo surgiram vrias metodologias e ferramentas de
gesto de projeto de desenvolvimento de software, entre elas o RUP. Este trabalho
fornece uma viso geral deste processo de desenvolvimento de software,
juntamente com um estudo de caso que serve como um exemplo de sua aplicao.

Palavra Chave: Engenharia de software, RUP, Desenvolvimento de projetos.

U
N
I
M
I
N
A
S

7
ABSTRACT

Organizations are increasingly concern in obtaining higher returns on
investments in software projects. In addition, organizations are seeking to better plan
their resources and time to address rising organizational needs. Currently, the
majority of software development projects are not finished as planned and some
projects are never finished. Overdue deadlines, over budgeted costs, failure to
address scope, and unsatisfied users are some of the issues organizations are trying
to avoid. To overcome these issues, organizations are implementing many
methodologies and project management tools for software development such as
RUP. This paper provides a general vision of the software development process and
a case study to exemplify its application as well.

Keywords: Software Engineering, RUP, Development of Projects.

U
N
I
M
I
N
A
S

8
LISTA DE FIGURAS
Figura 1 Grfico de Baleias....................................................................................20
Figura 2 Fluxo de Trabalho Disciplina Modelagem de Negcio ..........................27
Figura 3 Papeis x Artefatos Disciplina Modelagem de Negcio ..........................28
Figura 4 Papeis x Atividades Disciplina Modelagem de Negcio........................29
Figura 5 Fluxo de Trabalho Disciplina Requisitos ...............................................30
Figura 6 Papeis x Artefatos Disciplinas Requisitos .............................................31
Figura 7 Papeis x Atividades Disciplina Requisitos .............................................32
Figura 8 Fluxo de Trabalho Disciplina Anlise e Design .....................................33
Figura 9 Papeis x Artefatos Disciplina Anlise e Design .....................................34
Figura 10 Papeis x Atividades Disciplina Anlise e Design.................................35
Figura 11 Fluxo de Trabalho Disciplina Implementao......................................36
Figura 12 Papeis x Atividades Disciplina Implementao ...................................37
Figura 13 Papeis x Artefatos Disciplina Implementao .....................................37
Figura 14 Fluxo de Trabalho Disciplina Teste .....................................................38
Figura 15 Papeis x Artefatos Disciplina Teste.....................................................39
Figura 16 Papeis x Atividades Disciplina Teste...................................................40
Figura 17 Fluxo de trabalho Disciplina Implantao............................................41
Figura 18 Papeis x Atividades Disciplina Implantao ........................................42
Figura 19 Papeis x Artefatos Disciplina Implantao ..........................................43
Figura 20 Fluxo de Trabalho Disciplina Gerenciamento de Configurao e
Mudana ............................................................................................................44
Figura 21 Papeis x Atividades Disciplina Gerenciamento de Configurao e
Mudana ............................................................................................................45
Figura 22 Papeis x Artefatos Disciplina Gerenciamento de Configurao e
Mudana ............................................................................................................45
Figura 23 Fluxo de Trabalho Disciplina Gerenciamento do Projeto ....................46
Figura 24 Atividades x Papeis Disciplina Gerenciamento do Projeto..................47
Figura 25 Papeis x Artefatos Disciplina Gerenciamento do Projeto ....................48
Figura 26 Fluxo de Trabalho Disciplina Ambiente...............................................49
Figura 27 Atividades x Papeis Disciplina Ambiente.............................................50
Figura 28 Artefatos x Papeis Disciplina Ambiente...............................................51
Figura 29 WBS.......................................................................................................57
Figura 30 Diagrama de Caso de Uso.....................................................................59
Figura 31 Diagrama de Componente .....................................................................60
Figura 32 Diagrama de Seqncia Atualizar Tarifa................................................62
Figura 33 Diagrama de Seqncia Cadastrar Tarifas ............................................64
Figura 34 Diagrama de Seqncia Consultar Histrico de Tarifa...........................66
Figura 35 Diagrama de Seqncia Consultar Tarifa ..............................................68
Figura 36 Diagrama de Seqncia Obter Relatrio................................................70

U
N
I
M
I
N
A
S

9
LISTA DE ABREVIATURAS E SMBOLOS

1 RUP - Rational Unified Process
2 TIC - Tecnologia da Informao e Comunicao
3 CFO - Chefe de Setor Financeiro
4 CIO - Chief Information Officer responsvel pela Tecnologia da
Informao de uma empresa
5 NATO - Organizao do Tratado do Atlntico Norte
6 SAP - Empresa alem criadora do Software de Gesto de Negcios que
leva nome
7 EDI - Electronic Data Interchange troca estruturada de dados atravs de
uma rede de dados

U
N
I
M
I
N
A
S

10
SUMRIO
1. INTRODUO........................................................................................12
1.1. Cenrio atual ....................................................................................12
1.2. Identificao do Problema................................................................15
1.3. Objetivos do Trabalho ......................................................................15
1.3.1. Objetivos gerais do Trabalho........................................................15
1.3.2. Objetivos especficos do trabalho.................................................16
1.4. Justificativa para a pesquisa ............................................................16
1.5. Organizao do Trabalho.................................................................17
2. RUP Rational Unified Process..............................................................18
2.1. Introduo ........................................................................................18
2.2. Arquitetura........................................................................................19
2.2.1. Fases ..........................................................................................20
2.2.1.1. Inception ..................................................................................20
2.2.1.2. Elaboration...............................................................................21
2.2.1.3. Construction.............................................................................23
2.2.1.4. Transition .................................................................................24
2.2.2. Disciplinas...................................................................................26
2.2.2.1. Modelagem de Negcios .........................................................26
2.2.2.2. Disciplina Requerimentos ........................................................29
2.2.2.3. Disciplina Anlise e Design......................................................32
2.2.2.4. Disciplina Implementao ........................................................35
2.2.2.5. Disciplina Teste........................................................................37
2.2.2.6. Disciplina Implantao.............................................................40
2.2.2.7. Disciplina Gerenciamento de configurao e mudana...........43
2.2.2.8. Disciplina Gerenciamento do projeto .......................................45
2.2.2.9. Disciplina Ambiente .................................................................48
3. ANLISE DETALHADA DO ARTEFATO PLANO DE PROJETO............52
3.1. Necessidade do artefato ..................................................................52
3.2. Sumrio Executivo (Overview) .........................................................52
3.3. Viso Geral do Projeto (Overview) ...................................................52
3.4. Objetivos do Projeto (Overview).......................................................53
3.5. Escopo do Projeto (Overview)..........................................................53
3.6. Gerenciamento do Risco (Overview)................................................54
3.7. Recursos Requeridos e Custos (Work Plan) ....................................54
4. ESTUDO DE CASO EMPRESA X...........................................................55
4.1. Empresa X........................................................................................55
4.2. Projeto Apurao de Despesas Bancrias ....................................55
4.2.1. Definio do problema................................................................55
4.2.2. Escopo do projeto.......................................................................56
4.2.3. Fases e iteraes do projeto.......................................................56
4.2.4. Disciplinas e Papeis....................................................................58
4.2.5. Artefatos desenvolvidos projeto..................................................58
4.2.6. Diagrama de Caso de Uso..........................................................58
4.2.7. Diagrama de Componentes ........................................................59
4.2.8. Especificao de Caso de Uso / Diagramas de Sequncia ........60
4.2.8.1. Atualizar tarifa..........................................................................60
4.2.8.1.1. Descrio..............................................................................60
U
N
I
M
I
N
A
S

11
4.2.8.1.2. Atores....................................................................................60
4.2.8.1.3. Pr-condies .......................................................................60
4.2.8.1.4. Fluxo bsico de eventos .......................................................61
4.2.8.1.5. Fluxo alternativo de eventos .................................................61
4.2.8.1.6. Ps-condies ......................................................................61
4.2.8.1.7. Diagrama de sequncia ........................................................61
4.2.8.2. Cadastrar tarifa ........................................................................62
4.2.8.2.1. Descrio..............................................................................62
4.2.8.2.2. Atores....................................................................................62
4.2.8.2.3. Pr-condies .......................................................................63
4.2.8.2.6. Ps-condies ......................................................................63
4.2.8.3. Consultar Histrico de Tarifa....................................................64
4.2.8.3.1. Descrio..............................................................................64
4.2.8.3.2. Atores....................................................................................64
4.2.8.3.3. Pr-condies .......................................................................65
4.2.8.3.6. Ps-condies ......................................................................65
4.2.8.4. Consultar Tarifa Bancria ........................................................66
4.2.8.4.1. Descrio..............................................................................66
4.2.8.4.2. Atores....................................................................................67
4.2.8.4.3. Pr-condies .......................................................................67
4.2.8.4.6. Ps-condies ......................................................................67
4.2.8.5. Obter Relatrio.........................................................................68
4.2.8.5.1. Descrio..............................................................................68
4.2.8.5.2. Atores....................................................................................68
4.2.8.5.3. Pr-condies .......................................................................69
4.2.8.5.6. Ps-condies ......................................................................69
4.2.8.5.7. Diagrama de seqncia ........................................................69
5. CONCLUSES .......................................................................................71
REFERNCIAS BIBLIOGRFICAS ...............................................................73

U
N
I
M
I
N
A
S

12
1. INTRODUO

1.1. Cenrio atual

O software atingiu uma importncia vital para a sociedade moderna na
medida em que a informao se tornou o seu bem mais valioso. No mais possvel
imaginar o mundo sem os computadores e, conseqentemente, o software. At
mesmo as menores empresas hoje esto envolvidas de alguma forma com sistemas
computadorizados. Para as grandes empresas, o software uma necessidade bsica
para a manuteno de suas operaes.
Software elemento to fundamental para o desenvolvimento
econmico no sculo 21 quanto foi o ao na do sculo 20, e quanto foi
a agricultura anteriormente industrializao. A organizao da
sociedade nos pases desenvolvidos mudou, e continuar mudando
nos pases em desenvolvimento, rumo a economias cujo produto
primrio fundamental o software. Pois software o que agrega valor
de uso s Tecnologias da Informao e Comunicao (TIC), e essas
que habilitam o estado da arte em eficincia econmica. (DOURADO
DE REZENDE, 2007)
Pessoas comuns lidam com softwares cotidianamente em atividades
como comprar, vender, se divertir, etc. O software se tornou onipresente.
O volume e a complexidade do software cresceram bastante desde as
trs primeiras dcadas da era do computador.
Durante as trs primeiras dcadas da era do computador, o principal
desafio era desenvolver um hardware que reduzisse o custo de
processamento e armazenagem de dados. (PRESSMAN, 1995).
E complementa Rezende, que o maior desafio atualmente a melhoria da qualidade
do software.
Hoje o problema diferente, o principal desafio desta dcada
melhorar a qualidade (e reduzir o custo) de solues baseadas em
computador, que so implementadas com software. Na dcada de 70 e
80 destacaram-se o software tipo batch, distribuio e uso limitado,
multiusurio, em tempo real, banco de dados. Atualmente o software
deve ser distribuido, com inteligncia embutida, com visuais
orientados aos clientes ou usurios modulares e em redes complexas.
Modernamente, o software ou sistema de informao deve estar como
foco no negcio empresarial ou atividade organizacional e com o
objetivo de auxiliar os processos de tomada de decises (estratgicas,
tticas ou gerenciais e operacionais). (REZENDE, 2006).

U
N
I
M
I
N
A
S

13
Se inicialmente o perfil da fora de trabalho dedicada a TI se resumia aos
tcnicos e programadores, novas e importantes funes surgiram na medida em que o
oramento de TI cresceu e os CFOs comearam a cobrar retornos mais tangveis
sobre os investimentos. Entre estas novas funes destaca-se o Engenheiro de
Software, o Gerente de Projetos e o prprio CIO.
O termo Engenheiro de Software foi popularizado em 1968 pelo chairman
F. L. Bauer durante o 1968 NATO Software Engineering Conference e vem sendo
largamente empregado desde ento.
Hoje existem diversas definies para o termo Engenharia de Software.
Por exemplo: segundo MARTIN e McCLURE (1991) a engenharia de software o
estudo dos princpios e sua aplicao no desenvolvimento e manuteno de sistemas
de software [...] tanto a engenharia de software como as tcnicas estruturadas so
colees de metodologias de software e ferramentas ....
Engenharia de software uma rea do conhecimento da informtica
voltada para a especificao, desenvolvimento e manuteno de
sistemas de software aplicando tecnologias e prticas de cincia da
computao, gerncia de projetos e outras disciplinas, objetivando
organizao, produtividade e qualidade. (WIKIPDIA, 2008)
Atualmente, as reas de TI das organizaes lidam com duas principais
frentes de trabalho: numa precisam atender as novas demandas de solues em
software e noutra precisam manter os sistemas legados. Ausncia de processos bem
definidos, mtodos de trabalho, gerncia e organizao podem falir projetos,
empresas, gerar gastos excessivos e resultar em sistemas que futuramente tero
manuteno difcil e onerosa. Somam-se a isso a insatisfao do cliente, os desgastes
no decorrer do projeto e o prejuzo imagem do fornecedor.
Projetos envolvendo software so balizados por 3 variveis principais:
escopo, prazo e custo. O que se v freqentemente na prtica so escopos mal
definidos, muitos atrasos, imprevistos e oramentos estourados.
[...] engenheiros de software e gerentes de projeto para
desenvolvimento de sistemas computacionais tendem a concentrar
suas preocupaes no seguinte aspecto: a enorme impreciso das
estimativas de cronogramas e de custos de desenvolvimento. De fato,
a experincia tem mostrado que custos podem ser ultrapassados em
ordem de grandeza e cronogramas podem ser desrespeitados por
prazos de meses ou anos. Na realidade, esse aspecto constitui a
manifestao mais visvel de outras dificuldades inerentes ao processo
de desenvolvimento de software. (REZENDE, 2006).

U
N
I
M
I
N
A
S

14
Revistas como a Info Corporate trazem constantes estudos de caso
refletindo estes problemas.
Alguns exemplos:
[...] Imprevistos so rotina na rea de tecnologia das empresas, e os
executivos de TI sabem que faz parte da cartilha bsica de todo CIO ter
jogo de cintura para lidar com erros de avaliao da prpria equipe ou
de fornecedores. Mas h momentos em que a imprevisibilidade
exagera na dose. Foi o que aconteceu no Ibmec, [...]. Um recente erro
de avaliao elevou os custos de implementao de uma rede interna,
algo simples de ser feito, em 33%. E atrasou todo o cronograma da
instituio [...]. (Info Corporate, Outubro/2005).
[...] A BR Distribuidora enfrentou problemas graves para implantar o
SAP R/3. [...] Teoricamente, a idia de integrar todas as informaes
numa soluo e obter dados de todo o Brasil em tempo real sem
duplicidade era um sonho. Na prtica, foi um grande pesadelo. Pelo
menos nos primeiros 30 dias de Operao. A companhia, que emite
cerca de 10 mil notas fiscais por dia, passou a emitir 2 mil. Perdemos
mercado, dinheiro e muitas noites de sono. [...]. (Info Corporate,
Dezembro/2005).
Projetos de desenvolvimento de software falham de diversas formas e,
infelizmente, muitos deles falham mas possvel identificar vrios sintomas comuns
que caracterizam esses projetos (KRUCHTEN, 2003): incompreenso das
necessidades do usurio final; inabilidade para lidar com requisitos variveis; mdulos
que no se ajustam; software difcil de manter ou estender; descoberta tardia de srias
imperfeies no projeto; baixa qualidade de software; desempenho inaceitvel do
software; membros da equipe um no caminho do outro, tornando impossvel reconstruir
quem mudou o qu, quando, onde e por que; um processo de construo e
lanamento indigno de confiana.
Controlar estas variveis com equilbrio e preciso o desafio maior dos
gerentes de projetos/engenheiros de software. Com a finalidade de ser uma espcie de
guia nesta tarefa, surgiram vrios frameworks com todo o processo de
desenvolvimento de um software mapeado e seqenciado. Entre eles destaca-se o
RUP, que pode ser definido como:
O Rational Unified Process (RUP) um processo de engenharia de
software. Ele fornece uma abordagem disciplinada para assumir tarefas
e responsabilidades dentro de uma organizao de desenvolvimento.
Seu objetivo assegurar a produo de software de alta qualidade que
satisfaa as necessidades de seus usurios finais dentro do prazo e
oramento previsveis. [] O Rational Unified Process tambm uma
estrutura de processo que pode ser adaptada e estendida para compor
as necessidades de uma organizao que o esteja adotando.
(KRUCHTEN, 2003)
U
N
I
M
I
N
A
S

15
O objetivo do trabalho descrever os principais aspectos da ferramenta
RUP, bem como suas caractersticas e recursos para viabilizar o desenvolvimento
controlado e bem sucedido de um projeto de software.

1.2. Identificao do Problema

Com a competitividade cada vez mais acirrada nos mercados globais,
tornou-se vital para as empresas e organizaes estarem bem preparados
tecnologicamente, e no apenas para ampliar suas chances de sucesso no mercado,
mas tambm para atendimento a exigncias legais como, por exemplo, a lei Sarbanes-
Oxley. Isso exige um esforo constante, tendo em vista que a tecnologia est sempre
evoluindo.
Este esforo constante envolve recursos humanos qualificados,
investimentos em projetos de desenvolvimento e implantao de software, suporte,
treinamento, licenas, etc. Para gerir tudo isso, mdias e grandes empresas costumam
ter um CIO (Chief Information Officer). Para gerir os projetos temos os Engenheiros de
Software/Gerentes de Projeto.
O perfil do profissional de TI dentro das empresas tambm est
mudando. Cada vez mais este profissional est ligado aos negcios (REZENDE,
2006), com maior capacidade de gesto e viso tecnolgica, apesar de ser menos
tcnico.
Isso fica evidente quando observamos casos como o da TI da AGCO,
companhia americana dona de 20 marcas de equipamentos agrcolas, entre as quais a
conhecida Massey Ferguson, que teve seu mtodo de gerenciamento de processos
produzido pelo pessoal de TI adotado por toda empresa:
[...] O gerenciamento de processos implantado pela TI da AGCO
ganhou vida prpria e hoje se aplica a todos os departamentos da
fabricante de tratores [...]. (Info Corporate, Agosto/2006).

1.3. Objetivos do Trabalho

1.3.1. Objetivos gerais do Trabalho

U
N
I
M
I
N
A
S

16
Este trabalho tem por objetivo fazer um estudo descrevendo os principais
aspectos do RUP, fornecendo subsdio de informaes aos profissionais atuantes, bem
como queles que pretendem iniciar ou apenas conhecer melhor esta ferramenta.
O foco deste trabalho gesto de projetos de TI com foco em negcio.
Ser feito um levantamento sobre das principais caractersticas da metodologia.

1.3.2. Objetivos especficos do trabalho

Para atender o objetivo geral do trabalho tm-se os seguintes objetivos
especficos:
Apresentar uma introduo s origens do RUP
Descrever a arquitetura RUP
Descrever sinteticamente as fases do modelo
Descrever sinteticamente as disciplinas
Descrever o artefato Project Plan utilizado pela empresa que
originou o estudo de caso
Analisar um estudo de caso
Concluir

1.4. Justificativa para a pesquisa

A principal justificativa para a realizao desta pesquisa sobre a
metodologia de desenvolvimento de projeto RUP, a relevncia do assunto na
atualidade. Est importncia fica evidente na quantidade de texto publicado a respeito
pela mdia especializada.
O assunto de relevante importncia visto que influencia sensivelmente
o volume de capital investido em projetos de desenvolvimento de software e a
qualidade do produto final.
Planeja-se discutir aqui um mtodo que tem por objetivo melhorar o
retorno sobre o investimento feito em projetos de desenvolvimento de software.

U
N
I
M
I
N
A
S

17
1.5. Organizao do Trabalho

O trabalho est organizado da seguinte forma: primeiro temos uma
introduo as origens do RUP, mostrando como ele evoluiu a partir do modelo espiral
de Barry Bohem. Na segunda parte do captulo dois discutida a arquitetura. Nesta
parte temos uma definio mais ampla e precisa do RUP descrevendo seus principais
elementos e forma como organizado. Em seguida, no item 2.2.1 em diante, so
descritas as quatro fases do processo (eixo vertical do grfico de baleias). So
definidos seus objetivos, abrangncia, atividades bsicas e marcos (milestones). Em
seguida, so descritas as nove disciplinas (eixo horizontal do grfico de baleias). So
definidas as finalidades, atividades, artefatos, papeis e o fluxo de trabalho.
No captulo 3 feita uma analise do artefato Plano de Projeto, que o
principal artefato utilizado pela empresa onde foi observado o estudo de caso
apresentado. O captulo 4 contm o estudo de caso. Foram analisados a gesto e o
desenvolvimento de um software utilizando o RUP. E no captulo 5 apresenta a
concluso.

U
N
I
M
I
N
A
S

18
2. RUP RATIONAL UNIFIED PROCESS

2.1. Introduo

Pode-se dizer que o processo de desenvolvimento de software comea
com um problema especfico que um usurio quer resolver e termina com um sistema
que resolve este problema. Este processo pode envolver o desenvolvimento de um
novo software, embora cada vez mais, ocorram casos de um software ser
desenvolvido mediante a expanso e a modificao de sistemas j existentes
(SOMMERVILLE, 2003).
Um processo de desenvolvimento de software descreve as atividades
que devem ser realizadas no desenvolvimento de sistemas. O processo a definio
operacional do processo bsico que guia o estabelecimento de um processo comum
em uma organizao (BORGES; FALBO, 2002).
Assim necessrio considerar as caractersticas da organizao em
anlise. Estas caractersticas envolvem: atividades realizadas nos projetos de software
da organizao no provenientes de um modelo proposto na literatura, que so
consideradas atividades prprias da organizao; o fato de a organizao desenvolver
software para uso prprio, para comercializao ou sob encomenda; o fato de a
organizao ser especializada no desenvolvimento de um tipo de software especfico;
os principais problemas enfrentados pela organizao em seus projetos de software,
dentre outras.
Considerando a importncia da utilizao de um processo padro, um
considervel esforo tem sido feito para sua modelagem e, como forma
de auxiliar a sua criao, diversos processos esto surgindo. Eles
podem ser adotados por completo ou permitir ainda serem adaptados
de acordo com algumas caractersticas da organizao. possvel
tambm que uma organizao baseie-se em mais de um processo
para a definio de seu processo padro. (TEIXEIRA,2007)
As razes do RUP esto no modelo espiral original de Barry Boehm. Ken
Hartman, um dos principais colaboradores no desenvolvimento do RUP, tambm
colaborou com Boehm na pesquisa e redao do modelo espiral. Uma verso do
modelo espiral foi desenvolvida na Rational Software entre os anos 80 e 90.
Em 1995, a Rational Software comprou a Swedish Company Objectory
AB. O RUP foi o resultado da juno do modelo espiral que a Rational Software
U
N
I
M
I
N
A
S

19
desenvolveu nos anos 80 e 90 com o processo Objectory desenvolvido por Ivar
Jacobson. O primeiro resultado dessa juno foi o Rational Objectory Process,
desenvolvido para processos com alguma orientao a objetos, mas compatvel para
levar usurios Objectory ao uso do software Rational Rose. Este primeiro modelo
evoluiu e mudou de nome. A primeira verso do RUP, a 5.0, foi liberada em 1998. O
arquiteto chefe foi Philippe Kruchten.

2.2. Arquitetura

O RUP um mtodo/ferramenta que visa o sucesso no processo de
desenvolvimento de software. Trs elementos principais definem o RUP:
Um conjunto base de filosofias e prticas para o desenvolvimento de software bem
sucedido. Essas filosofias, prticas elementares e elementos essenciais so a
fundao na qual o RUP foi desenvolvido. O RUP tem uma longa histria de
evoluo que inclui o Rational Approach, o Objectory Process, ClearGuide, SQA
Process, entre outros.
Um modelo de processo e uma biblioteca associada. Definido e evoludo
inicialmente pela Rational Software, o modelo de processo do RUP e seu contedo
associado definem a base do framework do processo de engenharia de software do
RUP, a partir do qual o usurio pode criar sua prpria configurao do processo.
A linguagem fundamental de definio do processo. Na base de tudo est o meta-
modelo do processo. Este modelo prov uma linguagem para definio de
elementos para descrever um processo de engenharia de software. Esta linguagem
baseada na extenso da UML para processos de engenharia de software
chamada SPEM e na metodologia de Processo Unificado.
O RUP organizado em fases e disciplinas. A figura 1, popularmente
conhecida como grfico das baleias, ilustra e resume todo o processo.
O eixo horizontal representa o tempo e mostra os aspectos de clico de
vida do processo medida que ele desenvolvido. Esta primeira dimenso ilustra o
aspecto dinmico do processo e como ele representado em termos de fases,
iteraes e marcos (milestones).
O eixo vertical representa as disciplinas que agrupam logicamente
atividades por natureza. Esta segunda dimenso retrata o aspecto esttico do
U
N
I
M
I
N
A
S

20
processo. Ele descrito em termos de componentes de processo, disciplinas,
atividades, workflows, artefatos e papeis (roles).

Figura 1 Grfico de Baleias
Fonte: Rational Unified Process verso 20020500

2.2.1. Fases

As fases do RUP so: Iniciao, Elaborao, Construo e Transio.
Cada fase pode ser dividida em iteraes conforme a necessidade do projeto.

2.2.1.1. Inception

O objetivo principal da fase Inception alinhar os patrocinadores do
projeto em relao a seus objetivos. Esta fase bastante importante para projetos
novos, que exigem desenvolvimento inicial, pois nela necessrio listar e avaliar
significativos riscos de requerimentos, regras de negcios e viabilidade antes que o
desenvolvimento seja iniciado. Para projetos que so extenses de sistemas j
existentes, esta fase mais curta, porm ainda com foco em viabilidade e possibilidade
de desenvolvimento do trabalho.
U
N
I
M
I
N
A
S

21
Os principais objetivos da fase Inception so:
Definir o escopo do projeto, incluindo uma viso operacional, critrios de
aceitao e o que dever e o que no dever fazer parte do produto final;
Separar os casos de uso crticos do sistema, o cenrio primrio de operao no
qual ser baseado o produto final;
Mostrar a arquitetura candidata frente a alguns cenrios primrios;
Estimar o custo total e o tempo para o desenvolvimento do projeto e maiores
detalhes para a fase Elaborations que comea em seguida;
Estimar os potenciais riscos;
Preparar o ambiente de suporte para o projeto.

So consideradas atividades essenciais:
Definir o escopo do projeto. Isso envolve o entendimento do contexto e dos
requisitos e restries mais importantes bem como os critrios de aceitao
para o produto final;
Planejar e preparar um Business Case. Avaliar alternativas para o
gerenciamento de risco, recursos, plano de projeto, custo, prazo e viabilidade;
Compilar uma arquitetura candidata, avaliar alternativas de designe bem como
construo/compra/reutilizao de componentes. Avaliar custo, cronograma e
recursos. O objetivo aqui demonstrar que o projeto possvel atravs de uma
espcie de 'prova' ou demonstrao do conceito. Isso pode ter a forma de um
modelo que simule o que requerido, ou um prottipo inicial que explore os
pontos considerados de maior risco para o projeto;
Preparar o ambiente para o projeto e selecionar ferramentas;

Marco: Avaliao bsica da viabilidade do projeto.

2.2.1.2. Elaboration

O objetivo da fase Elaborao traar a arquitetura do sistema para
prover uma base consistente para o trabalho de design e implementao na fase de
construo. A arquitetura se desenvolve a partir de um exame dos requisitos mais
significativos (aqueles que tm grande impacto na arquitetura do sistema) e de uma
U
N
I
M
I
N
A
S

22
avaliao de risco. A estabilidade da arquitetura avaliada atravs de um ou mais
prottipos de arquitetura.
Os objetivos primrios da fase de elaborao incluem:
Assegurar que a arquitetura, os requisitos e os planos sejam estveis o
suficiente e que os riscos sejam suficientemente diminudos a fim de determinar
com segurana o custo e a programao para a concluso do desenvolvimento.
Para a maioria dos projetos, ultrapassar essa marca tambm corresponde
transio de uma operao rpida e de baixo risco para uma operao de alto
custo e alto risco com uma inrcia organizacional freqente;
Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto;
Estabelecer uma arquitetura da baseline derivada do tratamento dos cenrios
significativos do ponto de vista da arquitetura, que normalmente expem os
maiores riscos tcnicos do projeto;
Produzir um prottipo evolutivo dos componentes de qualidade de produo,
assim como um ou mais prottipos descartados para diminuir riscos especficos
como trocas de design/requisitos, reutilizao de componentes, possibilidade de
produo do produto ou demonstraes para investidores, clientes e usurios
finais;
Demonstrar que a arquitetura de baseline suportar os requisitos do sistema a
um custo justo e em tempo justo;
Estabelecer um ambiente de suporte.

Para atingir esses objetivos bsicos, tambm importante configurar o
ambiente de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar
templates e diretrizes, e configurar ferramentas.

So consideradas atividades bsicas:
Definir, validar e criar a baseline da arquitetura com rapidez e eficincia;
Refinar a Viso, com base nas informaes novas obtidas durante a fase,
estabelecendo uma compreenso slida dos casos de uso mais crticos que
conduzem as decises de arquitetura e planejamento;
Criar planos de iterao detalhados e baselines para a fase de construo;
U
N
I
M
I
N
A
S

23
Refinar o caso de desenvolvimento e posicionar o ambiente de
desenvolvimento, incluindo o processo, as ferramentas e o suporte de
automatizao necessrios para dar assistncia equipe de construo;
Refinar a arquitetura e selecionar componentes. Os componentes potenciais
so avaliados e as decises de fazer/comprar/reutilizar so bem compreendidas
para determinar o custo da fase de construo e programar com confiana. Os
componentes de arquitetura selecionados so integrados e avaliados em
comparao com os cenrios bsicos. As lies aprendidas dessas atividades
podem resultar em um novo design da arquitetura, levando em considerao
designs alternativos ou reconsiderando os requisitos.

Marco: Arquitetura do Ciclo de Vida. O marco Arquitetura do Ciclo de
Vida estabelece uma baseline gerenciada para a arquitetura do sistema e permite o
escalonamento da equipe do projeto na fase de Construo.

2.2.1.3. Construction

A meta da fase de construo esclarecer os requisitos restantes e
concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de
construo de certa forma um processo de manufatura, em que a nfase est no
gerenciamento de recursos e controle de operaes para otimizar custos,
programaes e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por
uma transio do desenvolvimento da propriedade intelectual durante a iniciao e
elaborao, para o desenvolvimento dos produtos que podem ser implantados durante
a construo e transio.
Os objetivos principais da fase de construo incluem:
Minimizar os custos de desenvolvimento, otimizando recursos e evitando
retalhamento e retrabalho desnecessrios;
Atingir a qualidade adequada com rapidez e eficincia;
Atingir as verses teis (alfa, beta e outros releases de teste) com rapidez e
eficincia;
Concluir a anlise, o design, o desenvolvimento e o teste de todas as
funcionalidades necessrias;
U
N
I
M
I
N
A
S

24
Desenvolver de modo iterativo e incremental um produto completo que esteja
pronto para a transio para a sua comunidade de usurios. Isso implica
descrever os casos de uso restantes e outros requisitos, incrementar o design,
concluir a implementao e testar o software;
Decidir se o software, os locais e os usurios esto prontos para que o
aplicativo seja implantado;
Atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento.
Mesmo em projetos menores, normalmente h componentes que podem ser
desenvolvidos um independente do outro, permitindo o paralelismo natural entre
as equipes (se os recursos permitirem). O paralelismo pode acelerar bastante
as atividades de desenvolvimento; mas tambm aumenta a complexidade do
gerenciamento de recursos e da sincronizao dos fluxos de trabalho. Uma
arquitetura sofisticada ser essencial para atingir um paralelismo significativo;

Atividades Bsicas:
Gerenciamento de recursos, otimizao de controle e processo;
Desenvolvimento completo do componente e teste dos critrios de avaliao
definidos;
Avaliao dos releases do produto de acordo com os critrios de aceitao.

Marco: Capacidade operacional inicial. Este marco determina se o
produto est pronto para ser implantado em um ambiente de teste beta.

2.2.1.4. Transition

O foco da Fase de Transio assegurar que o software esteja
disponvel para seus usurios finais. A Fase de Transio pode atravessar vrias
iteraes e inclui testar o produto em preparao para release e ajustes pequenos com
base no feedback do usurio. Nesse momento do ciclo de vida, o feedback do usurio
deve priorizar o ajuste fino do produto, a configurao, a instalao e os problemas de
usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado
muito antes no ciclo de vida do projeto.
U
N
I
M
I
N
A
S

25
No fim do ciclo de vida da Fase de Transio, os objetivos devem ter sido
atendidos e o projeto deve estar em uma posio para fechamento. Em alguns casos,
o fim do ciclo de vida atual pode coincidir com o incio de outro ciclo de vida no mesmo
produto, conduzindo nova gerao ou verso do produto. Para outros projetos, o fim
da Transio pode coincidir com uma liberao total dos artefatos a terceiros que
podero ser responsveis pela operao, manuteno e melhorias no sistema
liberado.
Essa Fase de Transio pode ser muito fcil ou muito complexa,
dependendo do tipo de produto. Um novo release de um produto de mesa existente
pode ser muito simples, ao passo que a substituio do sistema de controle do trfego
areo de um pas pode ser excessivamente complexa.
As atividades realizadas durante uma iterao na Fase de Transio
dependem da meta. Por exemplo, ao corrigir erros, normalmente bastam a
implementao e o teste. Se, no entanto, novas caractersticas tiverem de ser
adicionadas, a iterao ser semelhante a uma da fase de construo, exigindo
anlise, design, etc.
A Fase de Transio entra quando uma baseline estiver desenvolvida o
suficiente para ser implantada no domnio do usurio final. Isso normalmente requer
que algum subconjunto usvel do sistema tenha sido concludo com nvel de qualidade
aceitvel e documentao do usurio, de modo que a transio para o usurio fornea
resultados positivos para todas as partes.
Os objetivos principais da Fase de Transio so:
Teste beta para validar o novo sistema em confronto com as expectativas do
usurio;
Teste beta e operao paralela relativa a um sistema legado que est sendo
substitudo;
Converso de bancos de dados operacionais;
Treinamento de usurios e equipe de manuteno;
Introduo a marketing, distribuio e equipe de vendas;
Engenharia voltada para implantao, como preparao, empacotamento e
produo comercial, introduo a vendas, treinamento de pessoal em campo;
Atividades de ajuste, como correo de erros, melhoria no desempenho e na
usabilidade;
U
N
I
M
I
N
A
S

26
Avaliao das baselines de implantao tendo como base a viso completa e os
critrios de aceitao para o produto;
Obteno de auto-suportabilidade do usurio;
Obteno do consentimento dos envolvidos de que as baselines de implantao
esto completas;
Obteno do consentimento dos envolvidos de que as baselines de implantao
so consistentes com os critrios de avaliao da viso.

Atividades bsicas:
Executar planos de implantao;
Finalizar o material de suporte para o usurio final;
Testar o produto liberado no local do desenvolvimento;
Criar um release do produto;
Obter feedback do usurio;
Ajustar o produto com base em feedback;
Disponibilizar o produto para os usurios finais.

Marco: Release do Produto.

2.2.2. Disciplinas

Uma disciplina mostra todas as atividades que voc deve realizar para
produzir um determinado conjunto de artefatos. Essas disciplinas so descritas em
nvel geral - um resumo de todos os papis, atividades e artefatos envolvidos. Tambm
mostrado, em um nvel mais detalhado, como ocorre a colaborao entre papis e de
que forma eles usam e produzem artefatos. Os passos nesse nvel detalhado so
chamados de "detalhamentos do fluxo de trabalho".

2.2.2.1. Modelagem de Negcios

Seguindo o fluxo representado na Figura 2, as finalidades da disciplina
"modelagem de negcios" so entender a estrutura e a dinmica da organizao na
qual um sistema deve ser implantado, entender os problemas atuais da organizao-
U
N
I
M
I
N
A
S

27
alvo e identificar as possibilidades de melhoria, assegurar que os clientes, usurios e
desenvolvedores tenham um entendimento comum da organizao-alvo e derivar os
requisitos de sistema necessrios para sustentar a organizao-alvo.

Figura 2 Fluxo de Trabalho Disciplina Modelagem de Negcio

Para atingir essas metas, a disciplina de modelagem de negcios
descreve como desenvolver uma viso da nova organizao-alvo e, com base nesta
viso, definir os processos, os papis e as responsabilidades dessa organizao em
um modelo de casos de uso de negcios e em um modelo de objetos de negcios.
U
N
I
M
I
N
A
S

28
Em complemento a estes modelos, a disciplina tambm contempla o
desenvolvimento dos artefatos "Especificao Suplementar de Negcios", "Glossrio" e
"Relao com Outras Disciplinas", conforme demonstrado na Figura 3.

Figura 3 Papeis x Artefatos Disciplina Modelagem de Negcio

Como pode ser visto no grfico das baleias (figura 1), a maior
concentrao de trabalho desta disciplina se d nas primeiras fases de um projeto.
Conforme demonstra a Figura 4, os papeis e atividades que devem ser
desempenhados so: o Analista de Processo de Negcios, responsvel pela
coordenao e modelagem de casos de uso de negcios, definindo e delimitando a
organizao que est sendo modelada; o Designer de Negcios, que responsvel
por detalhar a especificao de uma parte da organizao, descrevendo o fluxo de
trabalho de um ou de vrios casos de uso de negcios; e o Revisor de Modelo de
Negcios, que participa das revises formais do modelo de casos de uso de negcios
e do modelo de objetos de negcios.

U
N
I
M
I
N
A
S

29

Figura 4 Papeis x Atividades Disciplina Modelagem de Negcio

2.2.2.2. Disciplina Requisitos

Seguindo o fluxo representado na Figura 5, temos as finalidades da
disciplina Requisitos: estabelecer e manter concordncia com os clientes e outros
envolvidos sobre o que o sistema deve fazer; oferecer aos desenvolvedores do
sistema uma compreenso melhor dos requisitos do sistema; definir as fronteiras do
sistema (fechar o escopo); fornecer uma base para planejar o contedo tcnico das
iteraes; fornecer uma base para estimar o custo e o tempo de desenvolvimento do
sistema; definir uma interface de usurio para o sistema, focando nas necessidades e
metas dos usurios.

U
N
I
M
I
N
A
S

30

Figura 5 Fluxo de Trabalho Disciplina Requisitos

Para atingir esses objetivos, importante, antes de tudo, entender a
definio e o escopo do problema que tentamos resolver com este sistema. As Regras
de Negcios, o Modelo de Casos de Uso de Negcios e o Modelo de Objetos de
Negcios desenvolvidos durante a Modelagem do Negcio serviro como informaes
importantes nesse trabalho. Os envolvidos so identificados, suas solicitaes so
colhidas, reunidas, analisadas e documentadas nos artefatos que fazem parte do
desenvolvimento da disciplina conforme demonstra a Figura 6.

U
N
I
M
I
N
A
S

31

Figura 6 Papeis x Artefatos Disciplinas Requisitos

Como a disciplina Modelagem de Negcios, a disciplina Requisitos
tambm tem seu volume de trabalho mais concentrado no incio de um projeto.
Como mostra a Figura 7, os papeis que devem ser desempenhados
nesta disciplina so: o Analista de Sistemas, que responsvel por liderar e coordenar
a identificao de requisitos e a modelagem de casos de uso, delimitando o sistema e
definindo sua funcionalidade; o Arquiteto de Software, que lidera e coordena as
atividades e os artefatos tcnicos no decorrer do projeto; o Epecificador de Requisitos,
que detalha a especificao de uma parte da funcionalidade do sistema, descrevendo
o aspecto Requisitos de um ou de vrios casos de uso e outros requisitos de software
de apoio; o Designer de Interface com o Usurio, responsvel por liderar e coordenar a
construo do prottipo e o design da interface do usurio; e o Revisor de Requisitos,
responsvel por planejar e conduzir a reviso formal do modelo de casos de uso.

U
N
I
M
I
N
A
S

32

Figura 7 Papeis x Atividades Disciplina Requisitos

2.2.2.3. Disciplina Anlise e Design

Os objetivos da disciplina Anlise e Design so: transformar os requisitos
em um design do sistema a ser criado; desenvolver uma arquitetura sofisticada para o
sistema; adaptar o design para que corresponda ao ambiente de implementao,
projetando-o para fins de desempenho. Estes objetivos so atingidos seguindo o fluxo
mostrado na Figura 8.

U
N
I
M
I
N
A
S

33

Figura 8 Fluxo de Trabalho Disciplina Anlise e Design

A disciplina Anlise e Design tem seu esforo mais concentrado na fase
de elaborao do projeto, apesar de tambm ser bastante desempenhada tambm na
fase de construo. Entre seus artefatos, como demonstra a Figura 9, destacam-se o
Documento de Arquitetura de Software produzido pelo papel Arquiteto de Software
e o Modelo de Dados produzido pelo papel Designer de Banco de Dados.

U
N
I
M
I
N
A
S

34

Figura 9 Papeis x Artefatos Disciplina Anlise e Design

Os papeis que devem ser desempenhados so: o Arquiteto de Software,
reponsvel por liderar e coordenar as atividades e os artefatos tcnicos no decorrer do
projeto; o Designer, responsvel por definir as responsabilidades, as operaes, os
atributos e os relacionamentos de uma ou de vrias classes e determina como eles
sero ajustados para o ambiente de implementao; o Designer de Banco de Dados,
responsvel pelo modelo de dados; o Revisor de Arquitetura, responsvel por planejar
e conduzir as revises formais da arquitetura de software em geral; e o Revisor de
Design, responsvel por planejar e conduzir as revises formais do Artefato Modelo de
Design conforme mostra a Figura 10.

U
N
I
M
I
N
A
S

35

Figura 10 Papeis x Atividades Disciplina Anlise e Design

2.2.2.4. Disciplina Implementao

Os objetivos da disciplina Implementao so: definir a organizao do
cdigo em termos de subsistemas de implementao organizados em camadas;
implementar classes e objetos em termos de componentes (arquivos-fonte, binrios,
executveis e outros); testar os componentes desenvolvidos como unidades; integrar
os resultados produzidos por implementadores individuais (ou equipes) ao sistema
executvel. O fluxo de trabalho da disciplina est representado na Figura 11.

U
N
I
M
I
N
A
S

36

Figura 11 Fluxo de Trabalho Disciplina Implementao

A disciplina Implementao limita o seu escopo a como classes
individuais devem ser testadas em unidade. O teste do sistema e o teste de integrao
so descritos na disciplina Teste.
A Implantao comea no fim da fase de concepo e vai praticamente
at o fim projeto, sendo bastante concentrada na fase Construo.
Os papeis que devem ser desempenhados so: o Arquiteto de Software,
responsvel por liderar e coordenar as atividades e os artefatos tcnicos no decorrer
do projeto; o Implementador, responsvel por desenvolver e testar componentes de
acordo com os padres adotados para o projeto, para fins de integrao com
subsistemas maiores; o Integrador, responsvel por combinar os componentes
desenvolvidos, testados e liberados em uma rea comum pelos Implementadores, para
criar um build; e o Revisor de Cdigo, responsvel por garantir a qualidade do cdigo-
U
N
I
M
I
N
A
S

37
fonte, alm de planejar e conduzir revises do cdigo-fonte, conforme mostra a Figura
12.

Figura 12 Papeis x Atividades Disciplina Implementao

Como mostra a Figura 13, a disciplina Implantao no desenvolve
muitos artefatos. O destaque o Modelo de Implementao produzido pelo arquiteto
de Software.

Figura 13 Papeis x Artefatos Disciplina Implementao

2.2.2.5. Disciplina Teste

A disciplina Teste atua em vrios aspectos como uma provedora de
servios para as outras disciplinas. Seu fluxo de trabalho est representado na Figura
14. O teste enfatiza principalmente a avaliao da qualidade do produto, realizada
atravs de vrias prticas centrais: localizar e documentar defeitos na qualidade do
software; avisar de forma geral sobre a qualidade observada no software; validar as
suposies feitas nas especificaes de design e requisito atravs de demonstrao
concreta; validar as funes do software conforme projetadas; verificar se os requisitos
foram implementados de forma adequada.

U
N
I
M
I
N
A
S

38

Figura 14 Fluxo de Trabalho Disciplina Teste

Como a Implementao, a disciplina Teste se estende por quase todo o
projeto, sendo mais concentrada no fim da fase Construo.
A disciplina desenvolve vrios artefatos, conforme mostra a Figura 15.
Dentre eles, os principais so os desenvolvidos pelo papel Gerente de Testes, que
so o artefato Plano de Teste e o Sumrio de Avaliao de Testes.

U
N
I
M
I
N
A
S

39

Figura 15 Papeis x Artefatos Disciplina Teste

A Figura 16 mostra os papeis e atividades que devem ser
desempenhados: Gerente de Testes, responsvel geral pelo xito do esforo de teste;
Analista de Teste, responsvel por inicialmente identificar e posteriormente definir os
testes necessrios, monitorar a abrangncia dos testes e avaliar a qualidade geral
obtida ao testar os Itens de Teste-alvo; o Designer de Teste, responsvel por definir a
abordagem de teste e assegurar sua correta implementao; e o Testador, que
responsvel pelas atividades centrais do esforo de teste, que envolve conduzir os
testes necessrios e registrar os resultados desses testes.

U
N
I
M
I
N
A
S

40

Figura 16 Papeis x Atividades Disciplina Teste

2.2.2.6. Disciplina Implantao

A Disciplina Implantao descreve as atividades que garantem que o
produto de software ser disponibilizado aos seus usurios finais seguindo o fluxo
mostrado na Figura 17.

U
N
I
M
I
N
A
S

41

Figura 17 Fluxo de trabalho Disciplina Implantao

A Disciplina Implantao apresenta trs modos de implantao de
produto: a instalao personalizada, o produto em uma forma "compacta" e o acesso
ao software por meio da Internet.
Em cada instncia, a nfase testar o produto no local de
desenvolvimento, seguido de testes beta, antes de ele ser finalmente oferecido ao
cliente.
Embora o pico das atividades de implantao seja a Fase de Transio,
algumas atividades ocorrem em fases anteriores ao planejamento e preparao para
a implantao.
A disciplina Implantao concentra-se do meio para o fim da fase de
Construo at o meio da fase de Transio.
Os papeis a serem desempenhados com suas respectivas atividades
nesta disciplina so (Figura 18): Gerente de Implantao, responsvel por planejar a
U
N
I
M
I
N
A
S

42
transio do produto para a comunidade de usurios e registrar este processo em
vrios documentos associados; Desenvolvedor de Curso, responsvel por gerar
material de orientao e manuais para os usurios do produto final; o Implementador,
j citado na disciplina anterior, porm desenvolvendo atividades diferentes nesta
disciplina; o Redator Tcnico, responsvel por elaborar o material de suporte para o
usurio final, como manuais do usurio, textos da ajuda, notas de release e outros; e o
Artista Grfico, responsvel pela arte-final do produto.

Figura 18 Papeis x Atividades Disciplina Implantao

A figura 19 mostra os artefatos e os papeis encarregados da construo
de cada um. O principal artefato desta disciplina o Plano de Implantao produzido
pelo Gerente de Implantao.

U
N
I
M
I
N
A
S

43

Figura 19 Papeis x Artefatos Disciplina Implantao

2.2.2.7. Disciplina Gerenciamento de configurao e mudana

Os mtodos, os processos e as ferramentas utilizados para o
gerenciamento de configurao e mudana de uma organizao podem ser
considerados como o Sistema de Configurao e Mudana da organizao.
Um Sistema de Configurao e Mudana fundamental para controlar
os inmeros artefatos produzidos pelas muitas pessoas que trabalham em um mesmo
projeto. O controle ajuda a evitar confuses dispendiosas e garante que os artefatos
resultantes no entrem em conflito devido a algum dos seguintes problemas:
atualizao simultnea, notificao limitada e vrias verses.
O fluxo de atividades da disciplina simples como demonstrado na
Figura 20: apenas trs nveis com 4 atividades podendo ser executadas em paralelo no
ltimo nvel.

U
N
I
M
I
N
A
S

44

Figura 20 Fluxo de Trabalho Disciplina Gerenciamento de Configurao e Mudana

Esta disciplina trabalha durante quase todo o projeto, sendo mais
concentrada a partir da fase de Construo.
Os papeis que devem ser desempenhados nesta disciplina so (Figura
21): Gerente de Configurao, responsvel por disponibilizar o ambiente e a infra-
estrutura geral de Gerenciamento de Configurao para a equipe de desenvolvimento
do produto; Gerente de Controle de Mudana, responsvel por supervisionar o
processo de controle de mudanas. Normalmente, este papel desempenhado por um
Comit de Controle de Configurao (ou Mudana), formado por representantes de
todas as partes interessadas, incluindo clientes, desenvolvedores e usurios; e o
Integrador, responsvel por criar espaos de trabalho de integrao, criar e promover
baselines.

U
N
I
M
I
N
A
S

45

Figura 21 Papeis x Atividades Disciplina Gerenciamento de Configurao e Mudana

A figura 22 mostra os artefatos e os papeis encarregados da construo
de cada um. O principal artefato da disciplina o Plano de Gerenciamento de
Configurao e Mudana desenvolvido pelo papel Gerente de Configurao.

Figura 22 Papeis x Artefatos Disciplina Gerenciamento de Configurao e Mudana

2.2.2.8. Disciplina Gerenciamento do projeto

U
N
I
M
I
N
A
S

46
O objetivo da disciplina Gerenciamento de Projeto de Software
confrontar os objetivos da concorrncia, gerenciar riscos e superar obstculos para
liberar com xito um produto que atenda s necessidades dos clientes (que pagaram
por ele) e dos usurios. O fato de que to poucos projetos sejam indiscutivelmente
bem-sucedidos o comentrio suficiente sobre a dificuldade da tarefa. Muitas
atividades so desenvolvidas e o fluxo mais complexo (Figura 23).

Figura 23 Fluxo de Trabalho Disciplina Gerenciamento do Projeto

A disciplina no trata de uma receita de sucesso, mas apresenta uma
abordagem para gerenciar o projeto que melhora notadamente a desigualdade da
liberao de software bem-sucedido.
U
N
I
M
I
N
A
S

47
As finalidades do Gerenciamento de Projeto so: fornecer um framework
para gerenciar projetos intensivos de software; fornecer diretrizes prticas para
planejar, montar a equipe, executar e monitorar os projetos; Fornecer um framework de
gerenciamento de risco.
A disciplina enfatiza principalmente os aspectos importantes de um
processo de desenvolvimento iterativo como, por exemplo, o gerenciamento de risco, o
planejamento de um projeto iterativo por meio do ciclo de vida de uma iterao
particular.
O Gerenciamento do Projeto desenvolvido homogeneamente ao longo
de todas as fases do ciclo de desenvolvimento do projeto.
Os papeis desempenhados so (Figura 24): Gerente de projeto,
responsvel por diversas atividades ao longo do projeto, destacando-se alocar
recursos, ajustar as prioridades, coordenar interaes com clientes e usurios e manter
a equipe do projeto concentrada na meta certa; e o Revisor do Projeto, responsvel por
avaliar os artefatos de planejamento e de avaliao do projeto nos principais pontos de
reviso do ciclo de vida do projeto.

Figura 24 Atividades x Papeis Disciplina Gerenciamento do Projeto

U
N
I
M
I
N
A
S

48
Vrios artefatos so desenvolvidos nesta disciplina (figura 25).
Praticamente todos so produzidos pelo Gerente de Projeto. A exceo o Registro
de Reviso que responsabilidade do Revisor do Projeto. Os principais artefatos
so o Plano de Desenvolvimento de Software, o Plano de Iterao, o Plano de
Gerenciamento de Riscos e o Lista de Riscos.

Figura 25 Papeis x Artefatos Disciplina Gerenciamento do Projeto

2.2.2.9. Disciplina Ambiente

A disciplina de Ambiente concentra-se nas atividades necessrias
configurao do processo para um projeto. Ela descreve as atividades para o
desenvolvimento das diretrizes de suporte de um projeto. A meta das atividades dessa
disciplina oferecer organizao o ambiente de desenvolvimento de software -
processos e ferramentas - que dar suporte equipe de desenvolvimento. A Figura 26
mostra o fluxo das atividades da disciplina.

U
N
I
M
I
N
A
S

49

Figura 26 Fluxo de Trabalho Disciplina Ambiente

Esta disciplina tem seus esforos mais concentrados a cada mudana de
fase do ciclo de vida do projeto.
Os papeis a serem desempenhados so (Figura 27): Engenheiro de
Processo, responsvel pelo processo de desenvolvimento de software. Isso inclui
configurar o processo antes da inicializao do projeto e aprimorar o processo
regularmente durante o esforo de desenvolvimento; o Especialista em Ferramentas,
responsvel por adquirir ferramentas, configurar, desenvolver guia de ferramentas e
verificar instalaes e configuraes; Designer de Interface de Usurio, responsvel
por liderar e coordenar a construo do prottipo e o design da interface do usurio; o
Analista de sistemas, j citado; o Analista do Processo de Negcios, responsvel por
liderar e coordenar a modelagem de casos de uso de negcios, definindo e delimitando
a organizao que est sendo modelada; o Arquiteto de Software, j citado; e o
Administrador de Sistema, responsvel por manter o ambiente de desenvolvimento,
cuidando do hardware e do software, da administrao do sistema, dos backups etc.

U
N
I
M
I
N
A
S

50

Figura 27 Atividades x Papeis Disciplina Ambiente

A disciplina inclui uma srie de artefatos desenvolvidos por vrios papeis
(Figura 28). Basicamente so todos guias que vo dar as diretrizes para o
desenvolvimento de outros artefatos durante o projeto.

U
N
I
M
I
N
A
S

51

Figura 28 Artefatos x Papeis Disciplina Ambiente

U
N
I
M
I
N
A
S

52
3. ANLISE DETALHADA DO ARTEFATO PLANO DE PROJETO

3.1. Necessidade do artefato

O Plano de Desenvolvimento de Software rene todas as informaes
necessrias ao controle do projeto. Ele descreve a abordagem dada ao
desenvolvimento do software e o plano de nvel mais alto gerado e usado pelos
gerentes para direcionar o esforo de desenvolvimento. O responsvel por seu
desenvolvimento e manuteno o Gerente de Projeto.
O plano de desenvolvimento de software evolui. Um Plano de
Desenvolvimento de Software til atualizado periodicamente e compreendido e
seguido por gerentes e executores. Ele o documento de definio do processo do
projeto.
Os principais discriminadores de um bom Plano de Desenvolvimento de
Software so conciso, falta de filosofia e enfoque em padres e procedimentos
significativos.
A seguir sero descritos alguns tpicos da verso 1.1 do Plano de Projeto
adotado pela empresa X. Ele dividido em trs sees: Overview, Work Plan e Plano
de Comunicao. O Work Plan inclui uma WBS do projeto.

3.2. Sumrio Executivo (Overview)

O Sumrio Executivo fornece um resumo do documento. Em muitos
casos isto se apresenta em MS PowerPoint. Se este o caso, uma referncia desta
apresentao deve ser mencionada aqui nesta seo.
Esta seo contm uma explanao em um nvel bem alto dos objetivos
do projeto, escopo, suposies, riscos, custos, calendrio ou "timeline", abordagem e
organizao que ser lido pelo executivo patrocinador do projeto. Este item deve ser o
ltimo a ser preenchido (remover este comentrio aps trmino do documento final).

3.3. Viso Geral do Projeto (Overview)

U
N
I
M
I
N
A
S

53
Esta sesso descreve o histrico e o contexto do projeto a se realizar,
bem como do valor sobre o negcio dos trabalhos em execuo. Este tpico precisa
conter informao suficiente de maneira que a definio do projeto faa sentido.

3.4. Objetivos do Projeto (Overview)

Objetivos so declaraes que descrevem o que o projeto vai alcanar e
entregar. Objetivos devem ser especficos, mensurveis, realizveis, realsticos, e
baseados no tempo (SMART). Para ser especfico e concreto, objetivos podem ser
baseados em deliverables. O objetivo completado deve ser evidenciado pela criao
de um ou mais deliverables. Se uma declarao est em um nvel muito alto e no
implica na criao de um deliverable, ento isto poder ser apenas uma meta a
alcanar. Se esta declarao for em nvel muito baixo e especfico descrevendo as
caractersticas e funcionalidades, ento isto poder ser um requerimento em vez de uma
declarao.

3.5. Escopo do Projeto (Overview)

Esta seo onde so definidas claramente as fronteiras lgicas do
projeto. Declaraes de Escopo so usadas para definir o que est dentro e o que est
fora das fronteiras do projeto. Exemplos so dados, processos, aplicaes, e reas de
negcio.
Por exemplo, os tipos de deliverables que esto dentro do escopo e fora
dele, os processos de ciclo de vida de maior impacto, as fontes de onde vieram os
dados (bancos de dados), os tipos de dados que esto fora e dentro do escopo
(financeiro, vendas, empregados), as organizaes que sero ou no afetadas
(recursos humanos, produo, representantes e vendedores), as funcionalidades mais
importantes que esto dentro e fora do escopo (suporte de deciso, entrada de dados,
relatrios gerenciais), etc.
O documento tambm contm as premissas nas quais o projeto est
baseado, as restries (cronograma, custos, qualidade, funcionalidade, etc) e fatores
que, para fins de planejamento, so considerados verdadeiros, reais ou certos. As
premissas afetam todos os aspectos do planejamento do projeto e fazem parte da sua
elaborao progressiva. Freqentemente, as equipes de projeto identificam,
U
N
I
M
I
N
A
S

54
documentam e validam as premissas durante o processo de planejamento.
Geralmente, as premissas envolvem um grau de risco. Tambm so relatadas as
restries que afetaro o desempenho do projeto.

3.6. Gerenciamento do Risco (Overview)

Esta seo descreve os principais riscos do projeto, como estes riscos
sero rastreados e como sero monitorados.
Riscos do projeto so circunstncias ou eventos que existem
externamente e fora do controle do time do projeto que, caso ocorra, causa um impacto
adverso no projeto (em outras palavras, risco um problema potencial e futuro que
ainda no ocorreu). Todos os projetos contm alguns riscos. Riscos podem no ser
eliminados totalmente, porm podem ser antecipados e gerenciados, reduzindo assim
sua probabilidade de ocorrer.
Riscos que tm alta probabilidade de ocorrer e que tm um grande
impacto negativo devem ser listados. Tambm so considerados riscos que tm uma
probabilidade menor de ocorrncia. Para cada risco so identificadas atividades para e
eliminao, e ou a mitigao dos mesmos.

3.7. Recursos Requeridos e Custos (Work Plan)

Esta parte lista dos recursos requeridos para cada atividade no WBS.
So includos recursos humanos, mquinas e facilidades fsicas necessrias.
Esta seo detalha como o oramento e os recursos sero alocados para
o desenvolvimento e suporte das funes do projeto. A estimativa de horas de
empenho junto com os custos do projeto pode ser representada de muitas maneiras,
incluindo custos/membro do time, custo/deliverable, custo/milestone, ou por categoria
(funcionrios, prestadores de servios, viagens, treinamento, fornecedores, e etc.)

U
N
I
M
I
N
A
S

55
4. ESTUDO DE CASO EMPRESA X

4.1. Empresa X

A empresa X foi inaugurada em Uberlndia no inicio da dcada de 50 do
sculo XX, sendo hoje uma das principais organizaes do segmento Atacado-
Distribuidor do pas. O processo de informatizao da empresa X teve incio em 1976
com a compra do Mainframe IBM 9121. A tecnologia fundamental para o
desempenho das atividades da empresa que, ao longo dos anos, adquiriu um nvel de
automao muito grande. Por exemplo, hoje mais de 70% dos novos clientes tm
contato apenas com o vendedor e o entregador. Todo o cadastro, transmisso,
processamento, roteirizao, montagem de carga, cobrana, etc. no exige
interveno humana.
Em 2007 seu oramento de TI foi de aproximadamente 16 milhes de
Reais. O departamento de TI da empresa X hoje conta com cerca de 80 profissionais
divididos em equipes com diferentes focos como sistemas de compras, vendas,
logstica, administrao financeira e suporte tcnico.
Em 2005 a empresa X, pensando em melhorar a qualidade de seu
desenvolvimento interno de sistemas (que hoje ainda corresponde a maior parte do
todo em produo), resolveu adotar o RUP como padro de processo e documentao
do desenvolvimento.
Este captulo apresenta um projeto desenvolvido na metodologia adotada
pela empresa X. Por se tratar de um projeto simples e de curta durao, foi utilizado
um conjunto reduzido de recursos da metodologia: os artefatos desenvolvidos foram
Viso e Plano de Projeto. Foram desenvolvidos tambm diagramas de classe,
seqncia e caso de uso.

4.2. Projeto Apurao de Despesas Bancrias

4.2.1. Definio do problema

A empresa X utiliza vrios servios oferecidos pelos bancos dos quais
cliente. Cada servio de cada banco tem uma tarifa. Para se ter uma idia do volume,
no ano de 2005 o oramento para despesas com tarifas bancrias foi de
U
N
I
M
I
N
A
S

56
aproximadamente R$ 1.200.000,00. Os bancos enviam diariamente extratos com a
movimentao da empresa em D-1 via EDI. Estes arquivos so internalizados no
sistema de gesto de caixa e tesouraria Universe, do fabricante XRT. Dessa forma, a
empresa X tinha apenas a informao de quanto estava pagando por cada servio,
sem no entanto, ter como fazer uma conciliao dos valores. A empresa no tinha
nenhum recurso que permitisse monitorar o volume utilizado e o valor negociado de
cada servio.
Sendo assim, a principal necessidade que o sistema dever suprir ficou
definida como sendo o de monitorar o volume de servios bancrios utilizado, o valor
negociado para cada servio e o valor cobrado pelos bancos.

4.2.2. Escopo do projeto

O escopo foi fechado com os seguintes itens includos:
Cadastro de tarifa acordada por instrumento e por banco;
Consulta de tarifa acordada por instrumento e por banco;
Atualizao de tarifa acordada por instrumento e por banco;
Histrico dirio de tarifas por banco e por instrumento;
Consulta de histrico de tarifas por banco e por instrumento;
Relatrio confrontando, por instrumento e por banco, o valor acordado X
(vezes) o volume utilizado versos a tarifa cobrada;
Com relao aos instrumentos de cobrana, segmentar por banco, tipo de
financiamento (Vendor ou no Vendor) e, se Vendor, indicar o que FIDIC e
o que no ;

O seguinte item foi citado como excludo do escopo:
Tratamento de mais de um valor de tarifa por banco, por instrumento e por
dia;

4.2.3. Fases e iteraes do projeto

O projeto foi planejado tendo pelo menos uma iterao em cada uma das
fases do RUP. A fase de construo foi dividia em duas iteraes: uma para
U
N
I
M
I
N
A
S

57
desenvolvimento de um prottipo e outra para o desenvolvimento integral do produto.
Isso se deveu ao fato de dentre os requisitos existir um mais complexo que poderia
inviabilizar o projeto caso no pudesse ser atendido. Este requisito um relatrio
contendo o volume de servios utilizados. Por exemplo: quantidade de TEDs, DOCs,
depsitos identificados, boletos emitidos, entre outros. Cada produto emitido em um
sistema diferente. Sendo assim, para gerar o relatrio, a princpio seria necessrio
consultar diversas bases de dados. A soluo adotada foi criar processos em paralelo
que os volumes utilizados de todos os servios em uma nica base. A WBS (Figura
29), que a estrutura analtica do projeto e serve para decompor o trabalho em partes
manejveis, ilustra como foram divididas as atividades do projeto.
O projeto durou 1 ms. A equipe foi composta por um analista de
sistemas, um programador e um analista de suporte responsvel pela implantao e
testes. O custo total do projeto ficou em R$ 12.000,00.

Figura 29 WBS

U
N
I
M
I
N
A
S

58
4.2.4. Disciplinas e Papeis

Apesar de ser um projeto pequeno, neste foram desempenhadas
praticamente todas as disciplinas e papeis listados no RUP. Os maiores esforos
ficaram concentrados na disciplina Requisitos, com o papel Analista de Sistemas
desempenhando as atividades como Localizar Atores e Casos de Uso, Estruturar o
Modelo de Caso de Uso, Identificar Solicitaes dos Principais Envolvidos e
Desenvolver Viso do projeto. Tambm recebeu bastante ateno a disciplina
Implementao, com o papel Implementador codificando o sistema e o papel Revisor
de Cdigo, bem como a disciplina Teste com o papel Testador com as atividades
Executar Conjunto de Testes e Analisar Falha de teste como exemplo.

4.2.5. Artefatos desenvolvidos projeto

Neste projeto foram desenvolvidos os artefatos Viso e Plano de Projeto.
O plano de projeto, documento que os stakholders assinaram, tem linguagem pouco
tcnica. J o documento Viso tem linguagem mais tcnica e voltado para os
analistas e desenvolvedores do projeto.

4.2.6. Diagrama de Caso de Uso

Foram definidos cinco casos de uso (figura 30) que englobam as
funcionalidades esperadas para o sistema: cadastrar tarifa, consultar tarifa, atualizar
tarifa, obter relatrio e consultar histrico de tarifa. H apenas um ator que intererage
com o sistema. O ator denominado Analista de Tesouraria. Ele consumidor de
informaes do sistema e tambm parametriza o mesmo atravs dos cadastros de
servios e tarifas bancrios.

U
N
I
M
I
N
A
S

59

Figura 30 Diagrama de Caso de Uso

4.2.7. Diagrama de Componentes

Foram definidos 4 componentes para o sistema: um componente
chamado Instrumento, que centralizar as operaes envolvendo os diversos produtos
bancrios; uma componente chamado HistoricoInstrumento para tratar operaes
envolvendo o histrico de valor de cada produto negociado com cada banco; um
componente chamado Banco para consultar bancos e instrumentos; e um componente
de controle. A figura 31 apresenta o diagrama de classes.

U
N
I
M
I
N
A
S

60

Figura 31 Diagrama de Componente

4.2.8. Especificao de Caso de Uso / Diagramas de Seqncia

4.2.8.1. Atualizar tarifa

4.2.8.1.1. Descrio

Atualizar tarifa cobrada por determinado banco em um determinado
servio. Este cadastro poder ser consultado posteriormente e ser usado na gerao
do relatrio que cruzar o volume de servio utilizado pela empresa com o valor
cobrado pelo banco.

4.2.8.1.2. Atores

Analista Financeiro: o papel usurio do sistema. So os funcionrios do
departamento Gesto de Caixa e Tesouraria da empresa X. Tero privilegio para
acessar todas as funes do sistema.

4.2.8.1.3. Pr-condies

U
N
I
M
I
N
A
S

61
Banco e tarifa j cadastrados e usurio com privilegio de atualizao de
tarifas.

4.2.8.1.4. Fluxo bsico de eventos

a) O usurio autorizado seleciona no menu a opo Atualizar Tarifa.
b) O sistema verifica que o usurio possui autorizao para atualizar
tarifas
c) O sistema carrega os bancos cadastrados
d) O usurio seleciona um banco
e) O sistema carrega os instrumentos do banco selecionado
f) O usurio atualiza a tarifa desejada
g) O sistema retorna uma mensagem confirmando a operao

4.2.8.1.5. Fluxo alternativo de eventos

b.1) Sistema verifica que usurio no tem permisso para atualizar
tarifas
b.2) Sistema emite uma mensagem informando que o usurio no est
autorizado a atualizar tarifas

4.2.8.1.6. Ps-condies

Tarifa atualizada.

4.2.8.1.7. Diagrama de sequncia
A figura 32 apresenta o diagrama de seqncia.
U
N
I
M
I
N
A
S

62

Figura 32 Diagrama de Seqncia Atualizar Tarifa

4.2.8.2. Cadastrar tarifa

4.2.8.2.1. Descrio

Cadastra tarifa cobrada por determinado banco em um determinado
servio. Este cadastro poder ser consultado posteriormente e ser usado na gerao
do relatrio que cruzar o volume de servio utilizado pela empresa com o valor
cobrado pelo banco.

4.2.8.2.2. Atores

U
N
I
M
I
N
A
S

63


O banco j dever ter sido cadastrados e usurio dever ter privilegio
para o cadastro de tarifas.


a) Usurio autorizado seleciona no menu a opo Cadastrar Tarifa
tarifas
e) O sistema busca as tarifas j cadastradas (caso exista) para o banco
selecionado
f) Usurio registra o valor da tarifa de um ou mais servios
g) O sistema insere uma linha no histrico de tarifas por servio e por
banco
h) O sistema cadastra a tarifa


b.1) Sistema verifica que usurio no tem permisso para cadastrar
tarifas
autorizado a cadastrar tarifas


Tarifa cadastrada

A figura 33 apresenta o diagrama de seqncia desta atividade.
U
N
I
M
I
N
A
S

64

Figura 33 Diagrama de Seqncia Cadastrar Tarifas

4.2.8.3. Consultar Histrico de Tarifa

4.2.8.3.1. Descrio

Consultar o histrico de tarifa cobrado por determinado banco por um
determinado servio. Sempre que uma tarifa cadastrada ou atualizada um registro de
histrico gerado contento o cdigo do banco, o cdigo do servio, a data e a hora e o
valor do servio (tarifa).

4.2.8.3.2. Atores

U
N
I
M
I
N
A
S

65


A tarifa deve ter sido cadastrada


a) Usurio autorizado seleciona no menu a opo Cadastrar Tarifa
tarifas
e) O sistema busca o histrico de todas as tarifas j cadastradas (caso
exista) para o banco selecionado


tarifas
e.1) Sistema verifica que no existem tarifas cadastradas para o banco
selecionado
e.2) Sistema emite uma mensagem informando no existem tarifas
cadastradas para o banco selecionado


Relatrio com o histrico das tarifas do banco selecionado exibido na tela

U
N
I
M
I
N
A
S

66

Figura 34 Diagrama de Seqncia Consultar Histrico de Tarifa

4.2.8.4. Consultar Tarifa Bancria

4.2.8.4.1. Descrio

Consultar o valor de uma tarifa cobrada por determinado banco por um
determinado servio. O valor retornado nesta consulta ser o valor utilizado pelo
sistema no momento da gerao do relatrio que mostrar o valor cobrado pelo banco
x o volume de servio utilizado pela empresa.

U
N
I
M
I
N
A
S

67
4.2.8.4.2. Atores



Banco e tarifa devem ter sido cadastrados


a) Usurio autorizado seleciona no menu a opo Consultar Tarifa
b) O sistema verifica que o usurio possui autorizao para consultar
tarifas
c) O sistema carrega os bancos e todas as tarifas cadastradas para eles


tarifas


Tarifas exibidas por banco na tela


U
N
I
M
I
N
A
S

68

Figura 35 Diagrama de Seqncia Consultar Tarifa

4.2.8.5. Obter Relatrio

4.2.8.5.1. Descrio

Este o caso de uso mais importante do projeto. Ele consulta os extratos
bancrios localizando o valor pago para cada servio cadastrado cruzando com o
volume utilizado pela empresa multiplicado pelo valor da tarifa cadastrada. Um relatrio
com estas informaes exibido na tela.

4.2.8.5.2. Atores

departamento Gesto de Caixa e Tesouraria da empresa X. Tero privilgio para
U
N
I
M
I
N
A
S

69


Bancos e tarifas cadastrados e extratos bancrios internalizados.


a) Usurio autorizado seleciona no menu a opo Obter Relatrio
b) O sistema verifica que o usurio possui autorizao para obter
relatrio de tarifas
e) O sistema busca o valor cobrado pelo banco por cada servio
cadastrado e o volume utilizado pela empresa multiplicado pela tarifa
do servio
f) O sistema exibe as informaes em um relatrio na tela


tarifas


Relatrio com o consumo de servios bancrios X o valor cobrado pelo
banco exibido na tela.

4.2.8.5.7. Diagrama de seqncia

U
N
I
M
I
N
A
S

70

Figura 36 Diagrama de Seqncia Obter Relatrio

U
N
I
M
I
N
A
S

71
5. CONCLUSES

O RUP um processo que valoriza a atividade de gesto. Apesar de s
vezes se mostrar burocrtico e repetitivo, o Processo Unificado visa garantir o sucesso
do projeto com a realizao de vrias atividades e artefatos relacionados gesto do
projeto. Tais atividades e artefatos so desenvolvidos por vrios papis.
Apesar de ter uma estrutura definida, o RUP flexvel o bastante para
permitir que determinadas atividades ou artefatos no sejam desenvolvidos,
dependendo da complexidade do projeto. Projetos simples no necessitam gastar
tempo e recursos com todas as atividades de gerncia sugeridas pelo RUP.
Entretanto, seguindo as especificaes sugeridas, pode-se obter
excelentes resultados no produto final em funo das boas prticas suportadas pelo
RUP.
No projeto estudado, por exemplo, foi aplicada uma pequena parcela do
RUP em funo da simplicidade do trabalho a ser desenvolvido: os artefatos Viso e
Plano de Plano de projeto, e os diagramas de Classe, Seqncia e Caso de Uso. No
entanto, mesmo com a utilizao de uma gama de recursos bem reduzida, os
benefcios para o processo de desenvolvimento do projeto e o produto final foram
grandes. Os artefatos e diagramas usados possibilitaram uma gesto consistente do
tempo, escopo e custos e possibilitaram tambm a comunicao efetiva entre todos os
envolvidos. Com o Plano de Projeto, o requerente pode se certificar de que havia sido
entendido, de que forma seu problema seria resolvido, o prazo e o custo desta soluo
e deu um aceite na proposta. O gerente do projeto se resguardou de mudanas
imprevistas de escopo que poderiam acontecer no decorrer do processo de
desenvolvimento e pode planejar com maior chance de acerto. Os desenvolvedores
tcnicos, atravs do artefato Viso e dos diagramas, puderam ter uma viso clara do
que precisaria ser desenvolvido.
Assim o uso do RUP provou ser de grande eficincia no processo de
gesto de projeto de software, principalmente com relao gesto das principais
variveis envolvidas num projeto de software (escopo, custo e prazo) como tambm
em relao comunicao entre todos os envolvidos.
A dificuldade em relao a uso do RUP relatada pelos gerentes de
projeto da empresa que originou o estudo de caso foi a questo do tempo. Como o
foco da empresa no desenvolvimento de software e sim comrcio, e como surgem
U
N
I
M
I
N
A
S

72
oportunidades de negcios que exigem desenvolvimento de sistemas em espaos de
tempo muito curtos, muitas vezes as boas prticas e o uso de ferramentas de gesto
de projeto ficam em segundo plano. Porm a empresa pesquisada, em virtude dos
benefcios do uso da metodologia j observados, estava criando na poca um pacote
mnimo de artefatos que deveriam ser desenvolvidos em todos os projetos
obrigatoriamente.

U
N
I
M
I
N
A
S

73
6. REFERNCIAS BIBLIOGRFICAS

BORGES, L. M. S.& FALBO R. A. Uma ferramenta de apoio instanciao de
processos de software com gerncia de conhecimento, I Concurso de Teses e
Dissertaes em Qualidade de Software, Anais do I Simpsio Brasileiro de Qualidade
de Software, 2002.

DOURADO DE REZENDE, O papel do software numa sociedade capitalista
informatizada, 2007 Disponivel em <http://www.rts.org.br/noticias/destaque-
1/arquivos/papel_software.doc> Acesso em 15 Nov 2008

Info Corporate. Disponvel em <http://info.abril.com.br/corporate/> acesso em 13 Ago
2006

KRUCHTEN, Philippe. Introduo ao RUP Rational Unified Process: Rio de
Janeiro, Editora Cincia Moderna, 2003.

MARTIN, James & McCLURE, Carma. Tcnicas Estruturadas e CASE: So Paulo:
Makron Books, 1991.

PRESSMAN, R. S. Engenharia de Software: So Paulo: Makron Books, 1995.

REZENDE, D. A. Engenharia de Software e Sistemas de Informao: Brasport,
2006.

SOMMERVILLE, I. Engenharia de Software: So Paulo: Pearson - Prentice Hall, 2007

TEIXEIRA, J. M. Modelagem de um Ambiente de Gerenciamento de
Desenvolvimento Distribudo de Software Baseado em Workflow (Monografia)
Pelotas(RS): UFPel. Disponvel em
<www.ufpel.tche.br/prg/sisbi/bibct/acervo/info/2007/mono_juliano_teixeira.pdf>
Acesso em 03 Dez 2008.

WIKIPDIA General Packet Radio Service. Disponvel em:
<http://www.wikipedia.org>. Acesso em: 20 out. 2005.

Metodologia RUP

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodologia RUP

Enviado por

Direitos autorais:

Formatos disponíveis

U

Você também pode gostar