MIGUEL WILLIAN GUIRAO BRITO

RUP: ESTABELECENDO UM PROCESSO BASE

PARA PEQUENAS FÁBRICAS DE SOFTWARE

Londrina
2007
 MIGUEL WILLIAN GUIRAO BRITO

RUP: ESTABELECENDO UM PROCESSO BASE

PARA PEQUENAS FÁBRICAS DE SOFTWARE

Monografia apresentada ao Curso de

Pós-Graduação em Engenharia de
Software e Banco de Dados da
Universidade Estadual de Londrina, como
requisito parcial à obtenção do título de
Especialista.

Orientador: Prof. Ms. Sérgio Akio Tanaka

Londrina
2007

2
 MIGUEL WILLIAN GUIRAO BRITO

RUP: ESTABELECENDO UM PROCESSO BASE PARA

PEQUENAS FÁBRICAS DE SOFTWARE
Monografia apresentada ao Curso de
Pós-Graduação em Engenharia de
Software e Banco de Dados da
Universidade Estadual de Londrina, como
requisito parcial à obtenção do título de
Especialista.

COMISSÃO EXAMINADORA

______________________________________

______________________________________

______________________________________

Londrina, ____ de____________ de 2007

3
DEDICATÓRIA

Dedico este trabalho aos meus pais,

Miguel e Telma e aos meus irmãos,
Jussara e Thiago, por sempre acreditarem
no meu potencial e sempre apoiarem
minhas decisões.

4
 AGRADECIMENTOS

Agradeço a Deus, por me dar forças e capacidade para realizar as tarefas árduas do
dia a dia.

Aos meus pais, Miguel e Telma, pela educação e confiança no meu potencial.

Aos meus irmãos, Thiago e Jussara, por me descontrair e ajudar sempre que foi
necessário.
Aos companheiros pessoais e profissionais que se mostraram sempre presentes e
dispostos a ajudar.

Ao orientador Sérgio Akio Tanaka, por ser compreensivo, acreditando que temos
uma vida profissional agitada e que, às vezes, aparecem ótimas oportunidades
profissionais que competem com as obrigações acadêmicas.

A todos que contribuíram para a realização deste trabalho.

Muito obrigado.

5
"No meio de qualquer dificuldade encontra-se a oportunidade."

Albert Einstein

6
BRITO, Miguel W. G. RUP: Estabelecendo um processo base para pequenas
fábricas de software. 2007. Monografia (Especialização em Engenharia de
Software e Banco de Dados) - Universidade Estadual de Londrina.

RESUMO

Este trabalho tem por objetivo reunir as principais disciplinas e artefatos do RUP
para definição de um processo unificado base, proporcionando produtividade,
melhoria na qualidade do produto e maior organização para pequenas fábricas de
software.

Palavras-Chave: RUP, fábricas de software, processo unificado.

7
BRITO, Miguel W. G. RUP: Estabelecendo um processo base para pequenas
fábricas de software. 2007. Monografia (Especialização em Engenharia de
Software e Banco de Dados) - Universidade Estadual de Londrina.

ABSTRACT

This work has for objective to congregate the main ones disciplines and artifacts of
the RUP for definition of a unified process base, providing productivity, improvement
in the product quality and greater organization for small software factory.

Keywords: RUP, software factory, unified process.

8
 SUMÁRIO

RESUMO......................................................................................................................7
ABSTRACT..................................................................................................................8
1 INTRODUÇÃO........................................................................................................10
2 FUNDAMENTAÇÃO TEÓRICA..............................................................................12
2.1 RUP...........................................................................................................12
2.1.1 Definição.....................................................................................12
2.1.2 Disciplinas..................................................................................15
3 ESTABELECENDO UM PROCESSO BASE.........................................................23
3.1 DEFINIÇÃO DO PROCESSO BASE........................................................24
4 CONCLUSÕES E TRABALHOS FUTUROS..........................................................30
REFERÊNCIAS..........................................................................................................31

9
1 INTRODUÇÃO

No cenário atual do mercado de fábricas de software, a grande maioria das

empresas não possuem um processo de desenvolvimento bem definido, que

acarreta em produtos com qualidade prejudicada.

Dados mostram que as empresas que não possuem um processo e não estão

focadas na melhoria contínua da qualidade dos seus produtos acabam

desaparecendo mais cedo do mercado.

Essas empresas dependem muito da capacidade de seus desenvolvedores

para manter um produto pois eles fazem papéis de analistas, projetistas, arquitetos,

instrutores de novos funcionários, etc. No entanto, caso um desses desenvolvedores

resolva deixar a empresa ou fique doente por um bom tempo, por exemplo, o

produto é prejudicado pois ele detêm, por culpa do processo (ou da falta de um), a

regra do negócio e a forma com que o sistema foi implementado. Nesse caso, a

perda desse profissional é trágica para a empresa, podendo até acarretar na morte

do software e, consequentemente, na rescisão de contratos com clientes e

parceiros.

Com base nessas constatações, a forma encontrada para melhorar,

continuadamente, a qualidade e dividir as responsabilidades, aumentando o

desacoplamento do profissional com o produto, é investir na definição e

implementação de um processo unificado baseado no RUP.

No próximo capitulo será apresentado o RUP, mostrando suas disciplinas,

fases e papéis a fim de compreender os seus benefícios.

10
 O capitulo 3 apresenta uma solução baseada no RUP para pequenas fábricas

de software e o capítulo 4 mostra as conclusões e os trabalhos futuros.

11
2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo é apresentado o RUP, que é o produto escolhido neste

trabalho para a implementação de processo em pequenas fábricas de software.

2.1 RUP – Rational Unified Process

2.1.1 Definição

O RUP é um processo de Engenharia de Software proprietário criado pela

Rational que foi adquirida pela IBM. Conforme RMC AND RUP, “ele oferece uma

abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro

de uma organização de desenvolvimento. Sua meta é garantir a produção de

software de alta qualidade que atenda às necessidades dos usuários dentro de um

cronograma e de um orçamento previsíveis.”.

É um processo geralmente utilizado para grandes projetos com um número

alto de participantes, no entanto, por ser customizável, e com isso ser utilizado para

projetos de menor escala.

As principais qualidades do RUP são:

melhora a produtividade da equipe;

ajuda a manter modelos para documentação;

usa abordagem orientada a objetos;

utiliza linguagem UML;

12
 possui várias ferramentas disponíveis para controlar o processo

(apesar das soluções livres, as mais conhecidas e utilizadas são da

Rational Suíte);

processo configurável;

aumento da qualidade do produto final.

O RUP é um produto que tem práticas testadas comercialmente e incentiva o

uso das chamadas “6 best practies” que são:

1. desenvolver o software iterativamente;

2. gerenciar requisitos;

3. usar arquitetura baseada em componentes;

4. modelar o software visualmente, através de diagramas;

5. verificar a qualidade do software;

6. controlar as mudanças do software.

A Figura 1 mostra o famoso gráfico das baleias como a visão geral do RUP.

13
 Figura 1 – Gráfico das Baleias – Visão Geral do RUP

Como mostra a Figura 1, o RUP possui 9 disciplinas e 4 fases dentro do seu

processo iterativo. As disciplinas são mais utilizadas dependendo da fase que mais

corresponde a ela, mas todas as disciplinas estão participando de todas as fases do

processo sendo que a de Gerenciamento de Projetos mantém foco constante no

decorrer da construção do produto. No final de cada fase a disciplina deve gerar os

recursos com os resultados obtidos para a fase seguinte. Na seqüência serão

apresentadas cada disciplina e sua importância dentro do processo. Na

documentação do RUP, disponível em RMC AND RUP, existe uma opção completa

e bem detalhada de cada disciplina, mas como o foco deste trabalho é criar um

processo base, portanto, dará uma visão geral das disciplinas, sem aprofundar nos

artefatos, papéis e fluxo de trabalho para que o leitor tenha base da complexidade
14
da implantação do RUP, afim de poder compreender a customização do processo

proposto neste trabalho.

2.1.2 Disciplinas

Modelagem de Negócios.

Objetivos:

entender o negócio da empresa alvo;

entender os problemas para propor melhorias;

assegurar que todos os envolvidos no projeto tenham entendimento

uniforme da empresa.

Papéis:

analista do processo de negócio

designer de negócio;

revisor do modelo de negócio.

Artefatos principais:

glossário de negócios;

regra de negócios;

avaliação da organização-alvo;

visão do negócio;

documento de arquitetura de negócios;

especificação suplementar de negócios.

Requisitos

15
Objetivos:

estabelecer e manter concordância com os envolvidos sobre o que o

sistema deve realmente fazer;

definir os limites do sistema;

definir uma interface de usuário para o sistema.

Papéis:

analista de sistemas;

arquiteto de software;

especificador de requisitos;

designer de interface com o usuário;

revisor dos requisitos.

Artefatos principais:

plano de gerenciamento de requisitos;

visão;

solicitações dos principais envolvidos;

glossário;

especificações suplementares.

Análise e Design.

Objetivos:

transformar os requisitos em um design no sistema;

evoluir uma arquitetura robusta para o sistema;

adaptar o design para que corresponda ao ambiente de

implementação.
16
Papéis:

arquiteto de software;

designer;

designer de banco de dados;

revisor de design.

Artefatos principais:

documento de arquitetura de software;

arquitetura de referência.

Implementação.

Objetivos:

definir organização do código, separando em camadas;

fazer implementação baseado em componentes;

testar os componentes como unidades independentes;

integrar os códigos produzidos por cada indivíduo ao sistema.

Papéis:

arquiteto de software;

implementador;

integrador;

revisor de código.

Artefatos principais:

componente;

subsistema de implementação;

plano de integração.
17
Teste.

Objetivos:

localizar e documentar defeitos;

verificar que todos os requisitos foram implementados corretamente;

verificar a integração dos componentes.

Papéis:

gerente de testes;

analista de teste;

designer de teste;

testador;

designer;

implementador.

Artefatos principais:

plano de teste;

sumário de avaliação de testes;

arquitetura para automatização de testes;

guia de teste.

Implantação.

Objetivos:

liberar o produto de software finalizado para o usuário;

instala o software;

testa o software em seu ambiente operacional final;

18
 treina os usuários finais.

Papéis:

gerente de implantação;

desenvolvedor do curso;

implementador;

redator técnico;

gerente de configuração.

Artefatos principais:

plano de implantação;

notas de releases;

artefatos de instalação;

materiais de treinamento;

material de suporte ao usuário.

Gerência de configuração e mudança.

Objetivos:

acompanhar e manter a integridade dos produtos do projeto em

desenvolvimento;

possibilitar que membros da equipe identifiquem e localizem artefato

para:

o selecionar versão apropriada;

o entender o estado atual de um artefato e as razões que foi

alterado;

o identificar o responsável pela mudança;

19
 o identificar o atual responsável.

Papéis:

gerente de configuração;

gerente de controle de mudança;

integrador.

Artefatos principais:

plano de gerenciamento de configuração;

registro de auditoria de configuração;

solicitação de mudança.

Gerenciamento de projeto

Objetivos:

fornecer diretrizes práticas para planejar, montar equipe, executar e

monitorar os projetos;

fornecer um framework para gerenciamento de riscos.

acompanhar todo o desenvolvimento do projeto no decorrer do

processo.

Papéis:

gerente de projetos;

revisor do projeto.

Artefatos principais:

plano de desenvolvimento de software;

caso de negócio;

plano de iteração;

20
 plano de resolução de problemas;

plano de gerenciamento de riscos;

lista de riscos;

plano de métricas;

plano de garantia de qualidade;

lista de problemas.

Ambiente.

Objetivos:

configurar o processo para o projeto;

fornecer a organização um ambiente de desenvolvimento – processos

e ferramentas – para apoiar o desenvolvimento.

Papéis:

engenheiro de processo;

especialista em ferramentas;

designer de interface com o usuário;

analista de sistemas;

analista do processo de negócios;

arquiteto de software;

designer de teste;

redator técnico;

administrador de sistema.

Artefatos principais:

caso de desenvolvimento;
21
avaliação da organização de desenvolvimento;

guia de modelagem de negócios;

guia de design;

guia de programação;

guia de modelagem de caso de uso;

guia de interface com o usuário;

guia de teste;

manual de guia de estilo;

guia de ferramentas;

infra-estrutura de desenvolvimento.

22
3 ESTABELECENDO UM PROCESSO BASE

Este capítulo irá apresentar uma solução para os problemas identificados

nos capítulos anteriores. Como foi apresentado no capítulo 2, o RUP disponibiliza

uma série de disciplinas, com uma relação considerável de artefatos e papéis que

dificilmente se encaixariam em uma pequena empresa por alguns motivos:

1. comunicação simples: pequenas empresas necessitam de

comunicação rápida e simples devido ao tamanho da equipe e

projeto.

2. agilidade: por não se preocuparem com dados estatísticos e

históricos do tempo gasto para o desenvolvimento das aplicações, os

gestores acreditam que o produto será desenvolvido em tempo

menor do que é realmente, prejudicando a qualidade.

3. recursos limitados: normalmente essas empresas possuem

profissionais com menor experiência.

4. falta de experiência na área de engenharia de software: como a área

é vista com visão acadêmica, o mercado das pequenas empresas

acaba não utilizando essas metodologias de processo acreditando

ser apenas para grandes corporações que podem investir em

profissionais qualificados.

5. aumento no orçamento: os processos presentes no mercado

apresentam muitos papéis para o desenvolvimento de cada

disciplina, no entanto, uma pessoa pode desempenhar mais de uma

função.

23
 6. falta de empenho da diretoria: normalmente a diretoria não age com

comprometimento às diretrizes do processo quando é iniciado

resultando em problemas que antes não havia, decretando a

descontinuidade da implantação.

Diante do cenário exposto, a solução é criar um processo que não seja

burocrático nem informal demais, respeitando o orçamento do projeto para um

crescimento sustentável, pois dessa forma a empresa pode se organizar aos

poucos, adquirindo uma nova cultura e aumentando a competitividade pela

qualidade do produto final.

3.1 Definição do processo base

Baseado nos problemas e na idéia, foi encontrada a seguinte definição para

um processo base, sendo que os objetivos de cada disciplina ainda continuam o

mesmo da definição do RUP:

Modelagem de Negócios

Papéis:

analista do processo de negócio

Artefatos:

regras de negócio;

visão do negócio;

modelo de caso de uso de negócio.

24
Requisitos

Papéis:

analista de sistemas;

arquiteto de software.

Artefatos:

solicitação dos principais envolvidos;

visão;

modelo de caso de uso.

Análise e Design

Papéis:

arquiteto de software.

Artefatos:

documento de arquitetura.

Implementação

Papéis:

arquiteto de software;

implementador.

Artefatos:

modelo de implementação;

componente.

Teste

25
Papéis:

testador;

implementador;

analista de testes.

Artefatos:

plano de teste;

log de testes.

Implantação

Papéis:

gerente de implantação;

gerente de configuração.

Artefatos:

plano de implantação;

artefatos de instalação.

Gerenciamento de configuração e mudança

Papéis:

gerente de configuração;

Artefatos:

plano de gerenciamento de configuração;

registro de auditoria de configuração;

solicitação de mudança.

26
Gerenciamento de projeto

Papéis:

gerente de projeto.

Artefatos:

plano de desenvolvimento de software;

plano de iteração;

plano de gerenciamento de riscos;

lista de riscos;

plano de garantia de qualidade;

plano de métricas.

Ambiente

Papéis:

engenheiro de processo;

analista de sistemas;

arquiteto de software.

Artefatos:

caso de desenvolvimento;

avaliação da organização de desenvolvimento;

guia de modelagem de negócios;

guia de teste;

guia de programação;

guia de modelagem de caso de uso;

infra-estrutura de desenvolvimento.
27
 A lista acima possui o básico para o bom funcionamento de uma fábrica de

software. Na disciplina de modelagem de negócios existe a figura do analista de

negócio que descreve os problemas da empresa e suas regras de negócio. Em

requisitos, o analista de sistemas desenvolve os artefatos criando também o modelo

de casos de uso, com o acompanhamento do arquiteto de software que na disciplina

de análise e design propõe a arquitetura para a implementação dos componentes.

Em teste é desenvolvido o plano de testes e gerado os logs de testes pelo testador

com o acompanhamento do implementador e do analista de testes.

Na disciplina de implantação, o gerente cria um plano de implantação e os

artefatos de instalação com o acompanhamento do gerente de configuração que faz

seu plano de configuração e mudança para registro de auditoria e solicitação de

mudança.

Em gerenciamento de projeto, o gerente deve possuir os planos para garantir

a qualidade e os prazos, ficando atento aos riscos listados, e por fim na disciplina de

ambiente o engenheiro de processo, o arquiteto de software e o analista de sistemas

configuram a infra-estrutura da empresa para o desenvolvimento do projeto.

É de fundamental importância um guia para o processo, apresentado para

todos da empresa, com o workflow e um mapa visual do processo por área para que

todos tenham conhecimento da sua importância e se sintam comprometidos no

andamento do projeto.

A quantidade de iterações deve variar de empresa para empresa assim

como a possibilidade de uma pessoa cumprir mais de um papel. O analista de

sistemas também pode ser usado como analista de negócios, ou o implementador

pode fazer os testes, desde que não teste os componentes desenvolvidos por ele,

28
ou mesmo o gerente de implantação e o gerente de configuração e mudança sejam

o mesmo profissional.

Vale ressaltar, também, que se deve manter documentado os problemas

encontrados para que sirva de histórico para projetos futuros. Com o

aperfeiçoamento do processo e aumento da qualidade, alguns artefatos podem não

ser mais necessários como os artefatos de ambiente: guia de testes, guia de

programação, guia de modelagem de caso de uso, etc. Pois esses já podem estar

implícitos no processo e nas suas disciplinas.

Enfim, com o comprometimento dos envolvidos e um processo base definido,

é possível desenvolver um software com qualidade, sem aumento considerável de

burocracia e orçamento.

29
4 CONCLUSÕES E TRABALHOS FUTUROS

Hoje em dia é difícil de compreender que uma empresa não possua um

processo para desenvolvimento de software e mantenha o foco para a qualidade e

aperfeiçoamento desse processo, no entanto, existem muitas empresas que ainda

trabalham dessa forma e esse trabalho mostrou uma maneira de começar a mudar

essa história.

Para apoiar futuros trabalhos, a sugestão é detalhar mais cada uma das

disciplinas, mostrando os artefatos e ferramentas, open-source e proprietárias, para

apoiar a gerência das fases e das disciplinas. Também se pode demonstrar o uso do

RUP para pequenas fábricas de software com implementações reais como estudo

de caso, que fornecerá uma maior segurança aos proprietários em uma futura

implantação do processo.

É fato que a mudança para um processo não é fácil de ser realizada, exige

custo, alteração de paradigmas, foco, concentração, comprometimento, muito

estudo e paciência, mas para empresas que pretendem reconhecimento no mercado

e um crescimento sustentável e constante essa mudança deve ser feita o mais

rápido possível.

30
 REFERÊNCIAS

SOFTWARE ENGINEERING INSTITUTE. Capability Maturity Model® Integration

(CMMI). Disponível em: http://www.sei.cmu.edu/cmmi/. Acessado em: 23 ago. 2007.

WIKIPÉDIA. Rational Unified Process. Disponível em

http://pt.wikipedia.org/wiki/RUP/. Acessado em: 24 ago. 2007.

KRUCHTEN, P. Introdução ao RUP: Rational Unified Process. 1. ed. Ciência

Moderna, 2003.

MARTINS, J. C. C. Gerenciando Projetos de Desenvolvimento de Software com

PMI, RUP e UML. 4. ed. Brasport, 2007.

RATIONAL. Rational Software. Disponível em http://www-

306.ibm.com/software/rational/. Acessado em 25 ago. 2007.

RMC AND RUP. Rational Method Composer and RUP. Disponível em http://www-
128.ibm.com/developerworks/rational/products/rup/. Acessado em 21 ago. 2007.

31