Upload
carloscjmc
View
212
Download
0
Embed Size (px)
Citation preview
MIGUEL WILLIAN GUIRAO BRITO
RUP: ESTABELECENDO UM PROCESSO BASE
PARA PEQUENAS FÁBRICAS DE SOFTWARE
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.
Orientador: Prof. Ms. Sérgio Akio Tanaka
Londrina
2007
3
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
4
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.
5
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.
6
"No meio de qualquer dificuldade encontra-se a oportunidade."
Albert Einstein
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.
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.
8
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.
9
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
10
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.
11
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.
12
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;
13
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.
14
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
15
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
16
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.
17
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.
18
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;
19
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;
20
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;
21
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;
22
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.
23
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.
24
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.
25
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
26
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.
27
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.
28
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,
29
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.
30
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.
31
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.