Modéstia à parte, sua

melhor opção para

se destacar no mercado!
A Escola Superior da Tecnologia da PÓS- GRADUAÇÃO
Informação oferece as melhores Engenharia de Software:
opções em cursos, formações, Desenvolvimento Java
graduações e pós-graduações para Engenharia de Software:
Desenvolvimento .NET
profissionais de desenvolvimento
GRADUAÇÃO
e programação.
Engenharia de Computação
São programas voltados para a Análise e Desenv. de Sistemas
formação de profissionais de elite,
F ORMAÇÕES
com aulas 100% práticas, corpo
Desenvolvedor Java
docente atuante no mercado,
Desenv. Java: Sist. Distribuídos
acesso à mais atualizada biblioteca
Gestor de TI
de TI do Rio, laboratórios equipados
Desenvolvedor Web .NET 2008
com tecnologia de ponta, salas de
MCITP Server Administrator
estudo e exames.
SQL Server 2008

r/esti
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti

TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800

EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO


Ano 4 - 40ª Edição - 2011 Marco Antônio Pereira Araújo
Corpo Editorial
Editor
Rodrigo Oliveira Spínola
Colaboradores
Marco Antônio Pereira Araújo
Eduardo Oliveira Spínola
Jornalista Responsável
Kaline Dolabella - JP24185
Na Web
www.devmedia.com.br/esmag
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se
você tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/mancad
(21) 2220-5338
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
EDITORIAL
A
s abstrações são uma ferramenta valiosíssima no tratamento de proble-
mas mais complexos por focar apenas nas partes essenciais, deixando
em segundo plano detalhes que não influenciam de forma determi-
nante na compreensão do problema. Os modelos gerados a partir dessas abs-
trações estão presentes em diversos aspectos da vida humana, indo dos mais
corriqueiros, como uma receita culinária, aos mais complexos projetos de enge-
nharia. Um modelo pode ser definido como sendo uma simplificação da realida-
de que nos ajuda a dominar um sistema grande e complexo que não pode ser
facilmente compreendido em sua totalidade.
No mundo dos negócios, o emprego de técnicas de modelagem de pro-
cesso de negócios contribui de maneira decisiva para a obtenção de melho-
rias em processos já estabelecidos ou no planejamento de novos processos.
Um processo de negócios seria “uma coleção de atividades que recebe uma
ou mais entradas e cria uma saída de valor para o cliente. Um processo de
negócios tem um objetivo e é afetado por eventos que ocorrem no mun-
do externo e em outros processos”. Além disso, também é importante que
se visualizem os processos de negócios como tarefas ordenadas de forma
sistemática no tempo e no espaço, ao invés de apenas uma coleção de ati-
Rodrigo Oliveira Spínola
rodrigo.devmedia@gmail.com
Editor Chefe – Engenharia de Software Magazine
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Autor de diversos artigos científicos
sobre Engenharia de Software publicados em revistas e conferências renomadas, dentro e fora do
país. Experiência de participação em mais de 20 projetos de consultoria para diferentes empresas
tendo atuado com gerência de projetos, requisitos e testes de software. Implementador certificado
do MPS.BR, tendo também experiência atuando junto a empresas certificadas CMMI.
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Linha de Pesquisa
em Engenharia de Software, Especialista em Métodos Estatísticos Computacionais e Bacharel em
Matemática com Habilitação em Informática pela UFJF, Professor e Coordenador do curso de Ba-
charelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, Professor do
curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Professor e
Diretor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador
da Engenharia de Software Magazine.
Eduardo Oliveira Spínola
eduspinola@gmail.com
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. É ba-
charel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o
mestrado em Sistemas e Computação na linha de Engenharia de Software, sendo membro do GESA
(Grupo de Engenharia de Software e Aplicações).
Fale com o Editor!
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você
gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a vontade para
entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria
de publicar.
vidades. Desta forma poder-se-ia identificar mais objetivamente as tarefas
que necessitam de melhorias no sentido de se obter melhor desempenho.
Uma das técnicas com maior alcance neste setor é o BPM (Business Process
Management).
Neste contexto, esta edição da Engenharia de Software Magazine destaca
como tema de capa Modelagem de Processos. Neste sentido, teremos três arti-
gos abordando o assunto sob diferentes perspectivas: Otimização de Processos
de Negócio usando BPM, Integrando ferramentas de modelagem de processos
com XPDL, e Modelagem de processos de negócio com BPMN e Intalio.
Além destes três artigos que formam a capa desta edição, teremos mais cinco
artigos:
• O Ócio Criativo
• Elaboração de cronogramas com base nas melhores práticas PMI
• Aprimorando o gerenciamento de projetos com mapeamento de processos
• Boas práticas para escrita de métodos, funções e procedimentos – Parte 2
• Refatoração para Padrões – Parte 13
Desejamos uma ótima leitura!
 ÍNDICE

Caro Leitor, Por trás do óbvio

05 – O Ócio Criativo
Glênio Cabral

Planejamento e Gerência
Para esta edição, temos um conjunto de 4 vídeo aulas. Estas vídeo
06 - Elaboração de cronogramas com base nas melhores práticas PMI
aulas estão disponíveis para download no Portal da Engenharia de Alexandre Paiva de Lacerda Costa
Software Magazine e certamente trarão uma significativa contri-
20 - Aprimorando o gerenciamento de projetos com mapeamento de processos
buição para seu aprendizado. A lista de aulas publicadas pode ser Renato Borges de Souza
vista abaixo: Engenharia
26 - Otimização de Processos de Negócio usando BPM – Parte 4
Ricardo S. Ferreira

Tipo: Processo 31 - Integrando ferramentas de modelagem de processos com XPDL

Título: Curso Scrum Product Owner – Partes 9 a 12
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta é uma série de aulas de um treinamento voltado ex-
clusivamente para Product Owners. O Product Owner é um papel prescrito
pelo método ágil SCRUM responsável pelo sucesso ou fracasso do desen-
volvimento de um produto. Este é um papel complexo de ser exercido no
dia-a-dia e, este curso, distribuído em uma sequência de vídeo-aulas, tem
como objetivo tornar mais fácil a transição para aqueles que pretendem
ou necessitam trabalhar como Product Owner.
André de Jesus Silva, Asher Lionel Coelho e José Luis Braga
Desenvolvimento
41 - Boas práticas para escrita de métodos, funções e procedimentos – Parte 2
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo
48 - Refatoração para Padrões – Parte 13
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo
Por trás do Óbvio
O Ócio Criativo
D
ia desses resolvi comprar um livro que há muito tem-
po desejava ler. Fui a uma livraria e adquiri o livro “O
Ócio Criativo”, do italiano Domenico Le Mase.
Em linhas gerais, Domenico defende que é possível trans-
formar o trabalho numa atividade tão prazerosa quanto ir ao
cinema. De que forma? Utilizando determinadas tecnologias
de informação para diminuir o excesso de trabalho. Segundo
ele, o trabalho a distância, por exemplo, poderia reduzir dras-
ticamente a jornada de trabalho e promover o fim do excesso
de procedimentos nas empresas. Ou seja, com mais tempo
para o lazer e o divertimento, as pessoas seriam naturalmente
mais motivadas e criativas em suas profissões, o que alavan-
caria os índices de produtividade das organizações.
Não nego que a idéia geral do livro é atraente. Trabalhar em
casa, exercer atividades sem pressão e com total liberdade
para tomada de decisão é algo, no mínimo, simpático. Prin-
cipalmente quando a visão que ainda se tem do trabalho é
de uma atividade enfadonha, impositiva e desgastante. Mas
o fato é que tentar reinventar as relações trabalhistas pode
ser muito mais complicado do que se imagina.
Isso porque em muitas cidades, principalmente nas gran-
des metrópoles, as relações profissionais ainda são bastante
tradicionais. Há uma grande competitividade entre os cola-
boradores, as estruturas hierárquicas se mostram rígidas e a
ênfase no controle é grande. Implantar um estilo de gestão
como o “Ócio Criativo”, que enfatiza a autonomia, o trabalho
Glênio Cabral
gleniocabral@yahoo.com.br
É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músi-
co. Idealizador do site de educação infantil www.novainfancia.com.br.
a distância e redução da jornada de trabalho ainda se mostra
uma tarefa quase inviável no mundo contemporâneo.
Seja como for, as idéias de Domenico me fizeram pensar
sobre o tipo de ócio que tenho praticado. Talvez meus súbitos
desejos de mandar às favas meu trabalho para entregar-me
aos lençóis pela manhã deva-se ao fato de que tenho praticado
o ócio preguiçoso, aquele que nos torna inativos e por vezes
alienados. Mas há o ócio produtivo, aquele que mantém a
mente ativa e gera o crescimento pessoal e profissional. A
prática desse ócio exige apenas sensibilidade para aprovei-
tar o tempo de forma inteligente e leve, de modo a tornar o
trabalho uma atividade prazerosa e energizada. Enquanto
os dias do “Ócio Criativo” não chegam por aqui, tentarei
de agora em diante praticá-lo dentro do que for possível,
valorizando atividades que ”ventilam” minhas idéias e que
proporcionam momentos de prazer pela arte, cultura, esporte,
ciência, etc, etc, e etc...
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 40 - Engenharia de Software Magazine 5
Planejamento e Gerência
Nesta seção você encontra artigos voltados para o planejamento
e gerência de seus projetos de software.
Elaboração de cronogramas com base nas
melhores práticas PMI
Gerenciamento do tempo do projeto
Alexandre Paiva de Lacerda
Costa
alexandre.paiva@gerentedeprojeto.net.br
Graduado em Engenharia Eletrônica para
Universidade Federal do Rio de Janeiro
(UFRJ), pós-graduado em Tecnologia da
Informação em Análise e Gestão de Negó-
cios pela Universidade do Estado do Rio de
Janeiro (UERJ), certificado PMP - Project
Management Professional pelo Project
Management Institute (PMI), certificado
ITIL Foundation pela Exin, certificado MCTS
70-632 Microsoft Certified Technology
Specialist (Microsoft Office Project 2007,
Managing Projects) pela Microsoft e possui
experiência em Planejamento, Execução e
Controle de Projetos adquirida em grandes
empresas como IBM Brasil, Oi/Telemar, Pe-
trobras e Eletrobrás Termonuclear.
6 Engenharia de Software Magazine - Elaboração de cronogramas com base nas melhores práticas PMI
C
om o mercado cada vez mais
competitivo, organizações com
objetivos estratégicos cada vez
mais arrojados e projetos cada vez mais
complexos, é importante desenvolver um
plano consistente que permita alcançar
tais metas estratégicas. Este plano, em
parte, é representado pela figura do
cronograma do projeto, que tem por
objetivo prover um roadmap que defina
como, com que recursos e em quanto
tempo o projeto fornecerá suas entregas
e pacotes de trabalho mapeados durante
a etapa de definição do escopo.
Neste artigo veremos como desen-
volver um cronograma com base nas
De que se trata o artigo?
Este artigo apresenta conceitos e boas práticas
PMI relacionadas à elaboração de cronogramas
para aprimorar o gerenciamento do tempo de
projetos de software.
Em que situação o tema é útil?
O tema é útil a todo gerente de projetos que
estiver envolvido com a elaboração do crono-
grama de projetos de software.
Resumo:
Este artigo apresenta diversos elementos a
serem levados em consideração durante a
elaboração e atualização de cronogramas de
projetos. Conhecer estas técnicas ajudará a
reduzir os erros nesta etapa que é tão crítica
para o sucesso do projeto.
melhores práticas PMI (Project Mana-
gement Institute).
Motivadores – Problemas de prazo
e orçamento nos projetos
Projetos entregues fora do prazo
podem significar, em vários casos, um
atraso relevante no lançamento de um

produto ou serviço estratégico para a empresa, acarretando
em perdas de cliente e receita.
De acordo com o 7º Fórum Nacional de Benchmarking em Ge-
renciamento de Projetos realizado no Rio de Janeiro em Novem-
bro de 2010, 60,2% das organizações que participaram da pesquisa
apontaram o não cumprimento dos prazos como o problema que
ocorre com maior frequência nos projetos (Figura 1).
Na maioria dos casos, os atrasos são ocasionados por fato-
res que permeiam o projeto como, por exemplo, escopo mal
dimensionado, risco mal gerenciado, requisitos incompletos
e por aí vai. O prazo funciona como “termômetro”, que ajuda
a diagnosticar a causa-raiz do problema, mostrando que algo
está errado com o projeto.
Além disso, com a quantidade de situações adversas pelas
quais um projeto passa ao longo de seu ciclo de vida, é neces-
sário desenvolver cronogramas dinâmicos que acompanhem
e reflitam essas mudanças, tornando claros os impactos para o
gerente e o time do projeto, possibilitando assim o diagnóstico
e o planejamento de ações corretivas que permitam colocar o
projeto novamente no trilho.
O cronograma tem papel fundamental nisto tudo, pois retrata
de forma estruturada todo o trabalho necessário e os prazos
previstos para alcançar os objetivos do projeto.
Alinhamento e conceitos básicos
Antes de iniciar nosso estudo, é preciso alinhar alguns concei-
tos básicos de gerenciamento de projetos para embasar o tema
gerenciamento do tempo do projeto e as melhores práticas para
desenvolvimento de cronogramas, assunto deste artigo.
Figura 1. Pesquisa sobre gerência de projetos – Fonte: 7º Fórum Nacional de Benchmarking em Gerenciamento de Projetos (PMI Survey)
PL ANEJAM ENTO
PMI
O PMI (Project Management Institute) é uma das principais
instituições em Gerenciamento de Projetos no mundo. Fun-
dado em 1969 e com sede na Pensilvânia (EUA), o PMI é uma
entidade sem fins lucrativos que possui como meta principal
avançar na prática, na ciência e na profissão de gerenciamento
de projetos, objetivando a valorização deste tema no mercado
de trabalho e em outros fóruns.
Outro ponto forte da instituição são as certificações profis-
sionais em gerenciamento de projeto, além das publicações de
Standards que fornecem padrões e melhores práticas para o
gerenciamento do projeto.
PMBOK
O principal padrão para o tema gerenciamento de projeto é o
Project Management Body of Knowledge, também conhecido
como PMBOK. Atualmente em sua quarta edição, o PMBOK
constitui a base de conhecimento em gerenciamento de pro-
jeto do PMI e contempla os processos, ferramentas e técnicas
necessárias para a realização de um projeto em conformidade
com as melhores práticas definidas.
O projeto, os grupos de processos e as áreas de conhecimento
De acordo com as definições do PMBOK 4ª Edição, projeto
é um esforço temporário empreendido para criar um pro-
duto, serviço ou resultado exclusivo. Normalmente nascem
a partir do desdobramento do planejamento estratégico de
uma organização e da necessidade de atendimento de metas
específicas.
Edição 40 - Engenharia de Software Magazine 7
 Outro elemento utilizado para caracterizar um projeto
é a sua natureza temporária, estipulando início, meio e
principalmente, fim.
Cada projeto é composto por cinco grupos de processo, nove áreas
do conhecimento e 42 processos de gerenciamento de projetos.
Os grupos de processo (Iniciação, Planejamento, Execução,
Controle e Encerramento) organizam os processos de geren-
ciamento de projetos mais detalhadamente ao longo do seu
ciclo de vida, como indica a Figura 2.
• Grupo de Iniciação  – processos com foco na obtenção da
autorização para a definição de um novo projeto ou fase; Figura 2. Fases do ciclo de vida do projeto
• Grupo de Planejamento – processos com foco na definição
do escopo do projeto, refinamento dos objetivos através dos
quais um projeto é criado e desenvolvimento de ações para
alcançar tais objetivos;
• Grupo de Execução  – processos com foco na execução do
trabalho definido na fase de planejamento;
• Grupo de Monitoramento e Controle – processos com foco no
acompanhamento, revisão e ajuste do andamento e desempe-
nho do projeto, identificando mudanças necessárias e obtendo
a aprovação para a implantação das mesmas;
• Grupo de Encerramento – processos com foco na finalização
das atividades de todos os grupos de processos, com o objetivo
de encerrar formalmente o projeto ou fase.
Figura 3. Interação entre processos

Estes processos não são isolados e interagem uns com os ou-

tros ao longo de todo o ciclo de vida do projeto, como podemos
observar na Figura 3.
As áreas do conhecimento incorporam os grupos e os pro-
cessos, organizando os temas em gerências específicas. As
nove áreas de conhecimento em gerenciamento de projetos,
de acordo com o PMBOK (veja a Figura 4), são:
• Gerenciamento de Integração: contém os processos neces-
sários para garantir que os diversos elementos do projeto
estão devidamente coordenados. Esta área é responsável pelo
desenvolvimento do plano de projeto, execução do plano e
controle de mudanças;
• Gerenciamento de Escopo: contém os processos necessários
para garantir que o projeto inclui todo o trabalho requerido,
e somente o trabalho requerido, para que seja concluído com
sucesso. Esta área é responsável por planejar e definir o escopo
do projeto, bem como monitorá-lo;
• Gerenciamento do Tempo: contém os processos necessários
para garantir que o projeto seja concluído no tempo correto.
Consiste de definição das atividades, sequenciamento de
atividades, estimativas de duração de atividades, criação do
cronograma e controle do cronograma;
• Gerenciamento de Custo: contém os processos necessários
para garantir que o projeto seja realizado dentro do orçamento
previsto. Consiste em planejar recursos, estimar custos, definir
o orçamento e controlar os custos;
• Gerenciamento da Qualidade: contém os processos necessá-
rios para garantir que o projeto satisfaça as necessidades para
as quais foi criado. Consiste em planejar, assegurar e controlar
a qualidade do projeto;
• Gerenciamento de Recursos Humanos: contém os processos
necessários para garantir o uso mais eficiente das pessoas en-
volvidas no projeto. Consiste em planejar, formar e desenvolver
a equipe do projeto;
• Gerenciamento de Comunicações: contém os processos
necessários para garantir que a informação do projeto seja
gerada, coletada, disseminada, armazenada e/ou descartada
da forma correta. Consiste em planejar a comunicação, dis-
tribuir a informação, produzir relatórios de desempenho e
fechamento do projeto;
• Gerenciamento de Risco: contém os processos necessários
para identificar, analisar e responder aos riscos do projeto.
Consiste em identificar, quantificar e qualificar riscos e de-
senvolver e controlar as respostas a estes riscos;
• Gerenciamento de Aquisições: contém os processos necessá-
rios para a aquisição de bens e serviços de terceiros. Consiste
em planejar as aquisições e solicitações, selecionar fornecedo-
res, administrar e encerrar contratos.
Gerenciamento de projetos
Gerenciar projetos é aplicar conhecimentos, habilidades, fer-
ramentas e técnicas nas atividades do projeto a fim de atender
os requisitos do projeto. Estas atividades estão agrupadas nos
cinco grupos de processo e nas nove áreas de conhecimento
descritas acima.
De forma prática, o gerente de projeto é responsável por
realizar, de forma estruturada, todos os 42 processos de-
finidos com o intuito de entregar o projeto com o escopo
acordado, dentro do prazo estabelecido, dentro do custo

8 Engenharia de Software Magazine - Elaboração de cronogramas com base nas melhores práticas PMI

estipulado e com os requisitos de qua-
lidade estabelecidos.
O objetivo deste artigo é entender as
entradas, ferramentas, técnicas e saídas
previstas nos processos da área de Ge-
renciamento do Tempo do projeto, com
o objetivo de alcançar o término pontual
do projeto.
Figura 4. As nove áreas de conhecimento do projeto e seus processos
Figura 5. Gerenciamento do tempo dos processos
Gerenciamento do Tempo do
projeto
Gerenciar tempo em projeto é aplicar
os processos necessários para garantir
o término do projeto dentro do prazo
acordado.
Ao todo são seis processos: cinco pro-
cessos de Planejamento e um processo de
Edição 40 - Engenharia de Software Magazine
PL ANEJAM ENTO
Monitoramento e Controle. Todos esses
processos integrados e sequenciados
têm como objetivo maior desenvolver
e controlar o cronograma do projeto,
gerando um “roadmap” de entregas no
tempo (Figura 5).
1. Vamos entender cada um dos pro-
cessos, com foco nos processos de
planejamento responsáveis por criar
o cronograma. O processo de controle
“Controlar o cronograma” não será foco
deste artigo.
Definir as atividades: é o processo res-
ponsável por identificar todas as ações
necessárias a serem realizadas para
produzir as entregas do projeto. Estas
ações serão traduzidas por atividades
dentro do cronograma, que deverão ser
descritas de forma única através do uso
de verbo no infinitivo e de um objeto
para complementar e deixar a ação clara
(ex.: instalar o software, revisar o artigo,
etc.). Observe a Figura 6.
Observe que o principal insumo para
o processo de definição das atividades
é a linha de base do escopo gerada na
área de conhecimento Gerenciamento do
Escopo do Projeto. A linha de base do es-
copo consiste fundamentalmente de três
elementos importantes: a declaração de
escopo do projeto, a Estrutura Analítica
do Projeto (EAP) e o dicionário da EAP.
A Declaração de escopo do projeto de-
fine as fronteiras do projeto e descreve o
trabalho necessário para a realização de
todas as entregas previstas. Este docu-
mento inclui uma descrição do escopo do
produto e seus critérios de aceitação, as
entregas do projeto que serão a base para
o mapeamento das atividades necessá-
rias a serem realizadas para produzi-las,
as restrições que limitarão o trabalho de
planejamento e execução (orçamento,
prazos e marcos contratuais de entregas
são bons exemplos de restrições), as ex-
clusões ou o que não será feito pelo pro-
jeto, garantindo assim um alinhamento
de expectativa entre todos os envolvidos
e, por último mas não menos importante,
as premissas assumidas pela equipe
junto com os impactos iniciais caso elas
não aconteçam (potenciais riscos).
Desta forma, a declaração de escopo do
projeto colabora na definição da linha de
9
base de escopo para auxiliar na tomada de decisões durante
a definição de atividades, estipulando o que será e o que não
será feito pelo projeto.
A EAP ou Estrutura Analítica do Projeto é um elemento
importante de controle do escopo do projeto e base para a
definição das atividades, pois contém entregas e pacotes de
trabalho representados de uma forma hierárquica. A partir
desses pacotes de trabalho definidos em sua estrutura é que
poderemos desdobrá-los em pequenos pedaços mais fáceis de
serem gerenciáveis (atividades) – Figura 7.
Figura 6. Ilustração do processo Definir as atividades
Figura 7. Exemplo de uma EAP – entregas e pacotes de trabalho no
último nível da EAP
O Dicionário da EAP complementa a EAP, fornecendo infor-
mações importantes a respeito dos componentes existentes em
sua estrutura hierárquica. Essas informações podem ser defi-
nidas através do uso de identificadores únicos (nível da EAP)
para as fases, entregas e pacotes de trabalho, uma descrição
do pacote de trabalho e produto esperado, principais marcos
de realização, áreas responsáveis dentro da organização e os
recursos (perfis) necessários, uma definição preliminar das
ações e estratégias necessárias para a entrega dos pacotes,
estimativas de custo, requisitos de aceitação dos pacotes e
produtos gerados (requisitos de qualidade) e seus critérios de
aceitação, riscos iniciais identificados, etc.
No exemplo acima, o dicionário da EAP para o pacote de
trabalho bebidas alcoólicas do tipo cerveja pode trazer, de
forma preliminar, as atividades associadas para a realização
10 Engenharia de Software Magazine - Elaboração de cronogramas com base nas melhores práticas PMI
do pacote como, por exemplo, “Comprar bebida” e “Entregar
bebida”. Além disso, poderíamos observar as principais prede-
cessoras e sucessoras. No caso do pacote bebidas alcoólicas, um
bom exemplo seria a definição e reserva do local do churrasco
como predecessora da atividade “Entregar bebida”.
Os recursos envolvidos em cada pacote de trabalho e suas com-
petências também poderão estar listados no dicionário. Isto faci-
litará o processo Estimar recursos para as atividades, fornecendo
informações prévias para auxiliar a estimativa. No exemplo, um
recurso com experiência em bebida e conhecedor de locais com
bons preços poderá auxiliar na execução do pacote bebidas.
Outro ponto importante que pode ser identificado preli-
minarmente na EAP é o risco envolvido em cada pacote. No
caso da bebida, podemos dizer que existe o risco de atraso na
entrega da bebida.
Enfim, o dicionário da EAP possui o detalhamento de cada
componente e funcionará como um grande “banco de dados” que
servirá de insumo para o processo de definição das atividades.
Estes três documentos compõem a linha de base do escopo do
projeto, definindo entregas, premissas e restrições do projeto.
Estes são fatores-chave para a definição das atividades.
Outros dois elementos importantes de entrada para este pro-
cesso são: fatores ambientais da empresa e ativos de processos
organizacionais.
Os fatores ambientais da empresa são – de acordo com o
PMBOK 4ª Edição – fatores internos e externos a organiza-
ção que influenciam o sucesso do projeto. Bons exemplos de
fatores internos são a cultura e estrutura da organização e o
conhecimento dos recursos humanos da mesma. Já os fatores
externos podem ser representados por padrões de indústria e
condições de marketing que podem influenciar, por exemplo,
na necessidade de realização de uma atividade específica.
Os ativos de processos organizacionais influenciam neste
processo e podem ser resumidos através de políticas e pro-
cedimentos da organização para a definição das atividades
(padrões de execução de processo, templates de lista de ativi-
dades, requisitos de comunicação, requisitos de encerramento
de um projeto definidos pela organização e por aí vai), lições
aprendidas e informações históricas de projetos anteriores, lista
de tarefas e questões (issues) de outros projetos, etc.
A partir da linha de base do escopo (Declaração de Escopo, EAP e
dicionário) e através de decomposições e opinião técnica especiali-
zada, é que definiremos todo o esforço necessário para produzi-los
(leia-se lista de atividades) – de acordo com a Figura 8.
Logo, para o exemplo do churrasco, o pacote de trabalho bebi-
das alcoólicas é decomposto em três atividades: pesquisar pre-
ço, comprar a bebida e entregar a bebida no local da festa.
Com base na lista de atividades produzida, precisaremos
definir os atributos de cada uma delas como saída importante
do processo de definição das atividades.
Basicamente, atributos de atividades são informações que
complementam e caracterizam uma atividade dando a ela
um sentido.
Considerando a atividade Comprar bebida, os atributos po-
dem ser definidos como apresentado na Figura 9.
 PL ANEJAM ENTO

Estes atributos são identificados ini- Segundo o PMBOK 4ª Edição, a uti- setas que representam as dependências
cialmente neste processo, atualizados no lização do método de diagramação de lógicas entre essas atividades. Desta
dicionário da EAP para resgate futuro precedência e a inclusão de atrasos e forma, a combinação de atividades e suas
dessas informações em etapas poste- antecipações também são importantes dependências lógicas são graficamente
riores e definidas de fato ao longo dos para criarmos uma rede mais próxima representadas por uma rede de prece-
demais processos de gerenciamento do da realidade do projeto. dência (Figura 12).
tempo do projeto. O Método de Diagrama de Prece- Além disso, é preciso definir o tipo
Utilizando novamente o exemplo do dência (PDM - Precedence Diagram- de dependência entre essas atividades
pacote de trabalho bebidas alcoólicas do ming Method), técnica utilizada para a para definir a sequência de execução.
tipo cerveja, pense que será necessário construção da rede de precedência do Basicamente, temos quatro tipos de de-
definir quais os recursos que deverão projeto, utiliza a estrutura de nós para pendências para o método PDM e elas
realizar a compra das bebidas, quais representar atividades e as conecta por são definidas basicamente em função
atividades precedem a compra das be-
bidas e o tipo de dependência entre elas
(é necessário terminar uma atividade
para começar a outra, começo as duas
atividades ao mesmo tempo, etc.).
Outra saída importante do processo de
definição de atividades, fruto do proces-
so de decomposição, é a lista de marcos.
Marcos são “atividades” com duração
zero e que, consequentemente, não pos-
suem esforço ou trabalho associados.
Servem para caracterizar eventos signifi-
cativos que necessitam ser monitorados,
pois sua conclusão retrata a conquista de
alguns objetivos relevantes do projeto.
Em alguns casos, estamos falando de Figura 8. Decomposição para definição do esforço
exigências contratuais (Figura 10).

1. Sendo assim, uma lista de marcos

nada mais é do que uma lista de ativida-
des com duração zero – sem consumo de
tempo e esforço/recurso – que represen-
tam eventos relevantes para o projeto,
cuja entrega precisa ser monitorada (Ex:
instalação realizada, migração concluí-
da, projeto finalizado, etc.).
2. Sequenciar as atividades: sequenciar
atividades é o processo de identificação Figura 9. Definição dos atributos da atividade Comprar bebida
e documentação dos relacionamentos
(dependências) entre as atividades do
projeto. Cada atividade e marco, com
exceção do marco de início e término
do projeto, são conectados a pelo menos
uma atividade predecessora e a uma ati-
vidade sucessora. Veja a Figura 11.
Podemos observar que a lista de ativi-
dades oriunda do processo anterior (De-
finir atividades), juntamente com seus
atributos, formam a entrada principal
para a definição do relacionamento en-
tre atividades, caracterizada através do
diagrama de rede do projeto (principal
saída deste processo). Figura 10. Lista de Marcos

Edição 40 - Engenharia de Software Magazine 11

de três razões específicas. São elas:
a. Razões lógicas (dependências obrigatórias): é impossível
comer um bolo antes de terminar de fazê-lo. Logicamente
falando, a atividade Fazer o bolo deverá acontecer antes que a
atividade Comer o bolo;
b. Limitações de recursos: é possível cozinhar 10 bolos ao
mesmo tempo, mas temos um pequeno forno para cozinhá-
los. Então, certamente, você fará um ou dois de cada vez em
função da limitação do recurso;
c. Razões preferenciais (dependências arbitradas): Supondo
que, pelo exemplo acima, você tenha que fazer dois bolos de
cada vez em função da limitação do forno. Preferencialmente,
você opta por começar fazendo os bolos de chocolate. Só depois
serão feitos os bolos de morango. Logo, por razões preferen-
ciais, optamos por iniciar por um tipo de bolo para depois
preparar os demais tipos.
Figura 11. Ilustração do Processo Sequenciar as atividades
Figura 12. Exemplo de PDM
Os quarto tipos de dependências existentes são:
a. Término-Início  (TI): a atividade dependente (B) não pode
começar até que a atividade da qual ela depende (A) seja conclu-
ída. No exemplo da Figura 13, considere as atividades Preparar
a massa, Preparar a cobertura e Cozinhar a pizza. A atividade
Cozinhar a pizza não poderá ser iniciada até que as atividades
Preparar a massa e Preparar a cobertura estejam concluídas;
b. Início-Início (II): a atividade dependente (B) somente pode co-
meçar com o início da atividade da qual ela depende (A), fazendo
assim com que duas atividades aconteçam ao mesmo tempo e
resultando em compressão no prazo de realização final das duas
atividades. Por exemplo, se você tiver duas atividades Preparar
a massa e Preparar a cobertura e supondo não haver nenhuma
12 Engenharia de Software Magazine - Elaboração de cronogramas com base nas melhores práticas PMI
limitação de recursos para executar essas duas atividades, elas
poderão iniciar ao mesmo tempo, conforme a Figura 14;
Figura 13. Dependência término-início (TI) entre atividades
Figura 14. Dependência início-início (II) entre atividades
c. Término-Término (TT): a atividade dependente (B) não pode
terminar até que a atividade da qual ela dependa (A) seja con-
cluída. Ambas as atividades não necessitam ser encerradas ao
mesmo tempo, levando a atividade B terminar em qualquer
momento após o término da atividade A. O fato é que, neste
tipo de dependência, a atividade B não pode terminar antes da
atividade A. No exemplo da Figura 15, depois que a pizza for
preparada, faremos a entrega ao cliente. Podemos usar uma
relação de dependência do tipo término-término para mostrar
que realizaremos o pagamento da pizza durante o processo
de entrega da pizza, mas a entrega da pizza só será concluída
após a comprovação do pagamento;
Figura 15. Dependência término-término (TT) entre atividades
d. Início-Término (IT): esta talvez seja a relação de dependência
mais difícil de compreender por ser a menos utilizada. Ela
ocorre quando o término de uma atividade depende do início
de uma atividade anterior. No exemplo da Figura 16, podemos
dizer que o processo de cobrança do cliente começa tão logo o
pedido é recebido, mas não é concluído até que o processo de
entrega da pizza inicie.
Outros elementos importantes que necessitam ser definidos
no momento em que estamos montando a rede de precedência
entre atividades são as antecipações (leads) e atrasos (lags)
entre as atividades. Em outras palavras, quando terminamos
uma atividade podemos antecipar ou atrasar o início de sua

atividade sucessora inserindo em suas definições de depen-
dência, atrasos e antecipações (Figura 17).
Este caso ocorre quando, por exemplo, existe um período
de não realização de trabalho entre atividades por motivo de
ausência do recurso que a executará.
Uma vez definidas as atividades e sua relação de dependência
mapeada, temos como resultado principal do processo Sequenciar
atividades, o diagrama de rede do projeto. Observe a Figura 18.
Figura 16. Dependência início-término (IT) entre atividades
Figura 17. Antecipações e atrasos nas dependências entre atividades
Figura 18. Saída principal do processo Sequenciar atividades - Diagrama
de rede do cronograma do projeto
Os diagramas de rede são mostras esquemáticas das ativida-
des do cronograma e das relações lógicas entre elas, também
chamadas de dependências.
Uma vez definidas as atividades e o tipo de dependência
entre elas, o próximo passo é definir os recursos que realizarão
as atividades previstas no processo “Definir atividades”.
1. Estimar os recursos das atividades: é o processo de estimar tipos
e quantidades de material, pessoas, equipamentos ou suprimentos
que serão necessários para realizar cada atividade (Figura 19).
É possível observar que algumas saídas do processo Definir
atividades como a lista e o atributo das atividades são entradas
para o processo Estimar os recursos das atividades.
Em linhas gerais, é necessário estimar recursos para a re-
alização de cada atividade prevista no pacote de trabalho.
PL ANEJAM ENTO
No caso da pizza, é necessário estimar os recursos necessários
para a atividade preparar a massa. Esta atividade considera
basicamente recursos do tipo pessoa, equipamentos e materiais
(Figura 20).
Figura 19. Processo Estimar os recursos das atividades
Figura 20. Recursos para executar a atividade preparar a massa
A lista de atividades elenca todas as atividades do crono-
grama que devem ser executadas por recursos para produzir
os pacotes de trabalho. Logo, é necessário considerarmos esta
entrada para definirmos os recursos necessários para a reali-
zação das atividades.
Os atributos das atividades trazem informações adicionais de
cada atividade que complementa sua definição. Por exemplo:
a descrição da atividade pode ajudar na definição adequada
do perfil do recurso requerido para executá-la. No caso do
preparo da massa da pizza, será necessário um pizzaiolo com
experiência em fazer massa de pizza.
É preciso verificar se o recurso pizzaiolo está disponível no
período necessário para a execução da atividade. Então, é preciso
considerar a disponibilidade do recurso para alocá-lo ao projeto.
Observe que o recurso necessário e sua disponibilidade podem
se transformar em restrição do projeto. Por isso é preciso consi-
derar o calendário dos recursos como entrada neste processo.
Os fatores ambientais da empresa e os ativos de processos or-
ganizacionais impactam diretamente na estimativa dos recursos
para a realização de uma atividade à medida que podem atuar
como restrição, limitando a forma de execução da atividade.
Edição 40 - Engenharia de Software Magazine 13
 No exemplo, ao preparar a massa é necessário seguir algumas
diretrizes de manipulação dos ingredientes ilustrando como
os ativos interferem no processo. Se, eventualmente, existe a
necessidade de contratação de mais um pizzaiolo para atender a
demanda, é necessário observar as políticas de contratação. Este Figura 21. Tabela de requisitos dos recursos
último ilustra como fatores ambientais interferem no processo.
Para processarmos estas entradas, alguns elementos serão
importantes, conforme veremos a seguir.
A Opinião especializada faz uso de especialistas com ex-
periência na execução de uma determinada atividade para
auxiliar na estimativa mais assertiva de recursos necessários
para a realização da atividade.
Um pizzaiolo mais experiente pode definir com maior
exatidão quantos ovos e a quantidade de sal necessária para
produzir uma determinada quantidade de massa.
Observe que o não uso de uma opinião especializada gera,
automaticamente, um risco para o projeto. Neste caso, existe o
risco da quantidade de ovos serem insuficiente e interromper
a produção.
A Análise de alternativas considera as diferentes possibilida-
des de realização de uma determinada atividade, verificando
a utilização de recursos para cada uma delas. Imagine, por
exemplo, a possibilidade de uma determinada atividade,
Figura 22. Estrutura Analítica de Recursos para a atividade Preparar Massa
que possui a necessidade de ter um recurso indisponível no
momento, possa ser executada de uma forma automatizada
por meio de softwares. São essas alternativas que necessitam As Atualizações dos documentos do projeto são necessá-
ser verificadas neste momento e devem considerar sempre os rias à medida que o projeto caminha ao longo do seu ciclo
impactos em custo, prazo e qualidade de realização. de vida. Novos recursos serão necessários e outros serão
Os Dados publicados para auxílio a estimativas auxiliam a substituídos.
estimativa de recursos como, por exemplo, informações refe- Após estimar os recursos para a realização das atividades,
rentes a taxa-padrão dos recursos humanos a serem utilizados é preciso estimar a duração das atividades com base nos re-
no projeto, bem como o mapeamento das competências de cursos alocados.
cada recurso. 1. Estimar as durações das atividades: é o processo res-
A Estimativa “bottom-up” é uma técnica que calcula as ponsável por estimar as durações das atividades através da
necessidades de recursos de cada atividade do cronograma, determinação do número de períodos de trabalho necessários
somando as estimativas parciais até a obtenção dos recursos para concluir as atividades definidas no processo “Definir
totais de cada pacote de trabalho e do projeto (de baixo para atividades”, com os recursos estimados no processo “Estimar
cima), gerando uma melhor precisão. os recursos das atividades” – Figura 23.
E finalmente o uso de software de gerenciamento de projetos É possível observar que algumas saídas dos processos ante-
para auxiliar o planejamento, organização e gerenciamento riores são entradas para o processo Estimar as durações das
do pool de recursos, e o desenvolvimento das estimativas de atividades.
recursos (Ex: MS Project). A Lista de atividades contém todas as atividades do crono-
As principais saídas deste processo fornecerão os tipos e grama que devem ter suas durações estimadas.
quantidades de recursos necessários para a realização das Os Atributos das Atividades são as informações adicionais
atividades. de cada atividade que complementam sua definição e auxiliam
Os Requisitos de recursos das atividades documentam os ti- na estimativa de duração da atividade.
pos e quantidades de recursos necessários para cada atividade No exemplo da pizza, ao verificarmos a descrição da ativida-
do cronograma do projeto, bem como algumas considerações de preparar massa, poderemos constatar que será necessário
como competências e requisitos de recursos necessários para um tempo adicional para deixar a massa descansar antes de
a realização das atividades (Figura 21). levá-la ao forno. Este tempo adicional deverá ser considerado
A Estrutura Analítica dos Recursos é uma estrutura hierár- na estimativa de duração da atividade.
quica de recursos identificados para o projeto, organizados Os Requisitos dos Recursos das Atividades fornecem um
por tipo de recurso e outras classificações possíveis como indício de quanto tempo será necessário para realizar uma
competências, habilidades, áreas da organização, etc. Um determinada atividade à medida que informa a disponibi-
exemplo disso é apresentado na Figura 22. lidade e competência dos recursos necessários (requisitos).

14 Engenharia de Software Magazine - Elaboração de cronogramas com base nas melhores práticas PMI

Figura 23. Processo Estimar a duração das atividades
Estas características do recurso servem
de base para a estimativa de duração da
atividade.
No exemplo da pizza, um pizzaiolo
com maior experiência fará o trabalho de
preparar a massa na metade do tempo do
que um pizzaiolo menos experiente.
O Calendário dos recursos é base para
verificarmos a disponibilidade dos re-
cursos necessários.
No exemplo da pizza, é possível utili-
zar o pizzaiolo com maior experiência
para realizar a atividade preparar a
massa na metade do tempo, entretanto
é preciso verificar sua disponibilidade
no período de tempo desejado.
A Declaração de escopo do projeto con-
tém as premissas e restrições que devem
ser consideradas para estimarmos a dura-
ção da atividade. Por exemplo, podemos
considerar como premissas a carga diária
de trabalho do recurso, influenciando di-
retamente na duração de uma atividade.
Como restrição, podemos considerar da-
tas impostas em contrato para a entrega
de equipamentos para instalação.
Os fatores ambientais da empresa e
ativos de processos organizacionais
devem ser considerados neste processo.
Índices de produtividade dos recursos
humanos da sua organização ou uma
base de dados de estimativas de duração
de atividades similares em projetos ante-
riores são alguns dos fatores ambientais
que podem auxiliar na estimativa de
duração das atividades. A base de lições
aprendidas com informações históricas
de outros projetos pode ser um bom
exemplo do uso de ativos como entra-
da para este processo, pois teríamos a
percepção de estimativas utilizadas em
projetos anteriores.
As ferramentas e técnicas a serem con-
sideradas neste processo gerarão uma
base de estimativa de duração para as
atividades listadas.
A Opinião especializada é uma téc-
nica utilizada para garantir uma boa
estimativa de duração, pois sempre
será estimada por quem conhece muito
bem o trabalho que será realizado. A
experiência de um especialista no tema
é fundamental para uma estimativa mais
precisa, com pequenos desvios.
No caso do uso de estimativas análo-
gas, existe a combinação de informações
históricas de durações reais de ativida-
des em projetos anteriores com uma
opinião especializada para analisar
o uso desta estimativa com o cenário
apresentado pelo projeto e verificar a
viabilidade desta estimativa.
A estimativa paramétrica utiliza uma
projeção de valores com base em uma
relação estatística de dados históricos
ou valores atuais.
No exemplo da pizza, suponha que o
pizzaiolo gaste um dia para preparar
20 massas de pizza. Se utilizarmos o
mesmo pizzaiolo ou outro com a mesma
experiência para preparar 40 massas, por
estimativa paramétrica podemos dizer
Edição 40 - Engenharia de Software Magazine
PL ANEJAM ENTO
que a duração estimada seria duas vezes
o trabalho para preparar as 20 massas.
Desta forma, o tempo gasto seria de
dois dias.
i. A estimativa de três pontos utiliza três
estimativas para gerar a estimativa final
de duração da atividade, como exibido
na Figura 24. As três estimativas são:
Figura 24. Estimativa de três pontos
ii. Pessimista (P) – Considera que algo vai
dar errado e, consequentemente, se leva-
rá mais tempo para concluir a atividade.
É a maior estimativa;
iii. Mais Provável (MP) – Considera que
não existem ameaças nem oportunida-
des e a atividade poderá ser concluída
conforme o planejado;
Otimista (O) – Considera o melhor
cenário, apresentando a menor duração
para concluir a atividade
É possível também determinar o
desvio-padrão associado a este cálculo
e obter assim, a margem de erro da esti-
mativa (Figura 25).
Figura 25. Desvio padrão para obter margem
de erro da estimativa
Desta forma, a medida da estimativa
de duração de uma atividade utilizando
a técnica de estimativa de três pontos
pode ser representada pela fórmula
apresentada na Figura 26.
Figura 26. Estimativa de duração de uma
atividade
A Análise de Reserva é a resposta ao
nível de incerteza. É uma forma de con-
tornar um eventual risco. Podemos en-
carar esta análise como uma “gordura”
que deve ser queimada em caso de uma
estimativa ruim ou do acontecimento de
15

Figura 27. Processo desenvolver o cronograma das atividades
um “imprevisto”. Imagine que você terá
que desempenhar determinada ativida-
de e o tempo estimado para executá-la é
de 10 dias. Existe um alto grau de incer-
teza nesta estimativa, pois esta atividade
nunca foi executada ou não temos base
histórica para utilizarmos uma estima-
tiva análoga, por exemplo. De forma
arbitrada, criaremos uma reserva nesta
atividade de 30% da duração estimada
para garantirmos eventuais atrasos.
Utilizando estas técnicas, poderemos
obter as estimativas de duração das ati-
vidades, razão de ser deste processo. As
estimativas de duração das atividades
definirão o número de períodos de traba-
lho (horas, dias, meses, etc.) necessários
para concluirmos uma determinada
atividade.
De posse das estimativas, as atuali-
zações de documentação do projeto
serão necessárias para refletir tais
informações.
1. O próximo passo é desenvolver o cro-
nograma do projeto onde todo o trabalho
realizado nos processos anteriores será
analisado e ajustado com o propósito de
obtermos um cronograma aceitável pelo
patrocinador do projeto.
2. Desenvolver o cronograma: como dis-
semos anteriormente, este processo fará
uma análise crítica de tudo o que foi feito
anteriormente. Observe que a maioria
16 Engenharia de Software Magazine - Elaboração de cronogramas com base nas melhores práticas PMI
das entradas deste processo é oriunda
dos processos anteriores. A ideia aqui
é tornar o cronograma o mais realista
possível e dentro das expectativas das
partes interessadas no projeto (principal-
mente as expectativas do patrocinador
do projeto) – Figura 27.
A lista de atividades precisará ser
revista de forma a verificar se algum tra-
balho necessário para entregar o pacote
de trabalho foi esquecido.
Os atributos de atividades como infor-
mações de predecessoras ou sucessoras,
durações, datas impostas e outros, po-
derão ser verificados com o objetivo de
aperfeiçoar o cronograma do projeto.
O diagrama de rede do projeto repre-
senta graficamente os relacionamentos
entre atividades e pode facilitar a identi-
ficação de uma dependência que precisa
ser verificada para, por exemplo, encur-
tarmos o prazo de um projeto.
Os requisitos dos recursos das ativida-
des também necessitam ser verificados
neste processo, pois trazem informações
referentes à quantidade de recursos
necessários para desempenhar uma de-
terminada atividade e competências ne-
cessárias para a realização do trabalho.
O calendário dos recursos mostra o
período de disponibilidade dos recursos
e influencia diretamente no processo de
desenvolvimento do cronograma uma
vez que estabelece quando um determi-
nado recurso estará apto a trabalhar em
uma atividade.
A estimativa de duração das ativida-
des é a estimativa do período de tempo
necessário para realizar uma atividade
e, neste processo, pode ser revista com
o objetivo de atender à expectativa de
término por parte do patrocinador e
demais partes interessadas.
A declaração de escopo do projeto
contém premissas e restrições que
interferem no processo de desenvolvi-
mento do cronograma. Datas impostas
funcionam como restrições e limitam o
prazo de execução de uma determinada
atividade. Alguns marcos do projeto
também funcionam como restrições à
medida que definem datas relevantes
para a realização de uma atividade (ex.:
prazos contratuais).
Os fatores ambientais da empresa e ati-
vos de processos organizacionais como
o uso de softwares de gerenciamento de
projetos que podem auxiliar no trabalho
de identificação de caminhos críticos
que veremos mais a frente e no traba-
lho de simulação de novas alternativas
de sequenciamento de atividades, por
exemplo, são fatores ambientais a serem
considerados. Já para os ativos, podemos
considerar templates de cronograma
e cronogramas utilizados em projetos
anteriores. Outro ativo que merece
destaque neste caso é o calendário da
empresa, definindo dias úteis e não úteis
para a realização das atividades.
As ferramentas e técnicas processarão
as entradas de forma a produzir o cro-
nograma do projeto.
A análise da rede do projeto gera o
cronograma do projeto a partir de um
modelo e da aplicação de várias técnicas
analíticas no diagrama de rede a fim de
calcular as datas de início e término mais
cedo e mais tarde de cada atividade.
O método do caminho crítico (CPM) é
uma técnica utilizada para calcular as
datas de início e término mais cedo e
de início e término mais tarde de cada
atividade do projeto, sem considerar
quaisquer limitações de recursos. Vere-
mos a seguir que o método da corrente
crítica considera os recursos limitados
 PL ANEJAM ENTO

de uma organização para produzir o atividades que não estão no caminho A ideia do nivelamento seria distribuir
cronograma do projeto. crítico do projeto (atividades não críticas) melhor os recursos utilizados da primei-
Voltando ao método do caminho críti- nas suas datas de início mais tarde, ao ra semana para a segunda semana, por
co, os diferentes caminhos existentes no contrário do caminho crítico que priori- exemplo, garantindo uma distribuição mais
diagrama de rede do projeto permitem za o início mais cedo. Veja a Figura 28. homogênea da utilização desses recursos.
com que uma atividade possua um range O Nivelamento de recursos fatalmente A Análise do cenário “E-se” simula o
de datas possíveis de início e término ocorrerá se o método utilizado para o acontecimento de várias premissas (e se...)
(datas mais cedo e mais tarde de início desenvolvimento do cronograma for o e verifica os impactos nas atividades do
e término). método do caminho crítico. Lembre-se cronograma. (Ex.: Se chover, o que ocorre-
Através destas datas, é possível de- que caminho crítico não leva em con- rá com a atividade pintar a parede?).
terminar a folga livre e a folga total de sideração recursos limitados em uma Observe que para este caso, o pintor
uma atividade. A folga livre informa organização. Sendo assim, teremos ativi- sugere que a parede não seja pintada em
quanto tempo uma atividade pode dades sendo realizadas em paralelo pelo dias de chuva. Com isto, um atraso no
atrasar sem que haja impacto no início mesmo recurso, ocasionando superalo- cronograma seria produzido. Para tal,
da atividade sucessora. Já a folga total cação. Neste caso, é necessário resolver é preciso construir uma resposta a este
informa quanto tempo uma atividade esta superalocação com o nivelamento cenário negativo (risco).
pode atrasar sem que haja impacto no de recursos. O nivelamento consiste em • Uma técnica muito utilizada para
término do projeto. distribuir, de maneira homogênea, a análise de cenários é a Simulação Monte
Ao identificarmos o caminho que con- utilização dos recursos a fim de elimi- Carlo, que testa a execução do projeto
tém as atividades com folga total igual nar sobrecarga ou falta de utilização do várias vezes de forma a obter uma distri-
a zero ou ainda o caminho que contém recurso em determinados períodos do buição estatística dos resultados gerados
a maior duração na soma das durações projeto (Figura 29). (Figura 30).
parciais das atividades, estaremos de-
terminando assim, o caminho crítico
do projeto.
As atividades que residem no caminho
crítico são denominadas atividades
críticas e são aquelas que necessitam
ser mais bem gerenciadas sob o risco de
comprometerem o prazo do projeto.
O método da corrente crítica, diferen-
temente do método do caminho crítico,
considera o uso limitado de recursos no
projeto. No modelo anterior, realizamos
uma super estimativa das atividades ob-
jetivando reduzir o impacto de eventuais
Figura 28. Diagrama de rede do cronograma do projeto e as atividades em vermelho indicando o
riscos em sua realização. Desta forma, caminho crítico do projeto (com maior duração)
introduzimos uma gordura na duração
das atividades. O fato é que a soma des-
sas gorduras em atividades críticas, por
exemplo, podem determinar um término
não factível e contrário às expectativas
do patrocinador do projeto.
É aí que surge o método da corrente
crítica. Ele tem o propósito de utilizar
as estimativas sem gordura para as
atividades e, no intuito de minimizar
o risco destas estimativas sem gordura
não serem alcançáveis, a corrente crí-
tica insere “pulmões” conhecidos por
buffers ao longo do diagrama de rede
do projeto.
Outro diferencial da corrente crítica
para o caminho crítico é o fato de a Figura 29. Quadro de alocação de recursos no projeto. Alta utilização dos recursos na primeira
corrente crítica priorizar o início das semana e baixa utilização dos recursos na semana seguinte

Edição 40 - Engenharia de Software Magazine 17

 Ao término da simulação poderemos observar algumas
informações importantes como:
• A probabilidade de encerrar um projeto em uma data espe-
cífica e dentro do orçamento previsto;
• A probabilidade de uma atividade residir no caminho crítico
do projeto;
• Que atividades afetam mais a duração do projeto;
A taxa de sucesso de um projeto.
Figura 30. Simulação Monte Carlo para a definição das probabilidades de
encerramento do projeto em uma data específica
As antecipações e esperas produzidas no processo Se-
quenciar atividades precisam ser revistas de forma a pro-
duzir um cronograma realista e aderente às expectativas do
patrocinador.
Outra técnica que pode ser utilizada neste processo para
alcançarmos a data esperada de término do projeto é a com-
pressão do cronograma. Em várias situações, ao finalizarmos
a elaboração do cronograma nos deparamos com uma data
diferente da acordada com o patrocinador do projeto. Para que
possamos trazer o cronograma para a data desejada, aplicamos
técnicas de compressão de cronograma nas atividades que
residem no caminho crítico do projeto (atividades críticas).
Estas técnicas reduzem o prazo de realização das atividades
sem que haja necessariamente uma mudança do escopo. Em
outras palavras, podemos incluir mais recursos em atividades
para reduzir seu prazo de execução (Crashing) ou realizar
atividades em paralelo que originalmente estariam em série
(Fast Tracking).
O Fast Tracking, em função do paralelismo de atividades,
gera uma sobrecarga de utilização do recurso no projeto. Esta
sobrecarga vem acompanhada de problemas de qualidade das
entregas previstas, uma vez que o retrabalho é quase certo
neste tipo de situação.
No caso do Crashing, devemos ter em mente que esta redução
de prazo pode trazer um aumento de custo com a utilização
de recursos adicionais na realização das atividades.
18 Engenharia de Software Magazine - Elaboração de cronogramas com base nas melhores práticas PMI
Todas estas técnicas podem ser realizadas através da ferra-
menta de desenvolvimento do cronograma
Ao aplicarmos todas as ferramentas e técnicas para este pro-
cesso geraremos enfim o Cronograma do projeto, constituindo
assim a principal saída deste processo e, por que não, da área
de conhecimento Gerenciamento do Tempo como um todo.
O cronograma do projeto fornece toda a lógica de realização
das atividades, identificando as entregas do projeto, os prazos de
realização, a sequência de realização, quem fará determinada ati-
vidade, marcos importas e datas impostas pelo patrocinador.
Podemos utilizar várias formas de representação para o
cronograma do projeto. Os mais importantes são os cronogra-
mas de Marcos (Figura 31), o Gráfico de Gantt (Figura 32) e o
diagrama de rede do projeto (Figura 33).
Figura 31. Cronograma de Marcos
Figura 32. Gráfico de Gantt
Uma vez analisado e aprovado, o cronograma terá suas da-
tas registradas para servirem de base de comparação com o
desempenho do projeto (previsto versus realizado). É a linha
de base do cronograma.
Os dados do cronograma como marcos, atividades, atributos
e a documentação de todas as premissas e restrições em relação
ao cronograma elaborado são saídas deste processo.
Todo este trabalho de revisão e desenvolvimento do crono-
grama resulta em atualizações dos documentos do projeto, de
forma a manter o plano aderente à nova situação.
O último processo de gerenciamento do tempo do projeto,
“Controlar o cronograma”, pertence ao grupo de processos
de Monitoramento e Controle do projeto. Ele é responsável
 PL ANEJAM ENTO

O cronograma apenas indica que o “paciente está doen-

te”, mas é preciso diagnosticar as causas da doença. E, na
maioria dos casos, alguma etapa do gerenciamento do pro-
jeto e suas demais áreas de conhecimento não foram bem
analisadas. É o velho ditado: “Se você falha ao planejar, está
planejando falhar”.
Então muito cuidado. Dedique uma atenção especial para
todas as áreas de conhecimento do projeto (Escopo, Riscos,
Custo, Qualidade, etc.), pois sem elas de nada adianta um
bom gerenciamento do tempo com cronogramas “estado da
arte”. Ter um termômetro bem calibrado é fundamental para
identificar a doença, mas eles apenas formalizarão a sua falta
de planejamento e seu projeto certamente não alcançará os
objetivos que justificaram sua existência.
Figura 33. Diagrama de rede do projeto com as datas de início e término
mais cedo e mais tarde obtidas

por monitorar o desempenho do projeto com o intuito de Referências

identificar os possíveis desvios em relação à linha de base do
HELDMAN, Kim. Gerência de Projetos: Guia para o exame oficial do PMI. Elsevier, 2009.
cronograma, que será comparada aos resultados apurados
durante a realização do projeto para determinar se uma ação MULCAHY, Rita. PMP® Exam Prep. RMC Publications, 2009.
corretiva ou preventiva é necessária.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos
Como o foco era mostrar como desenvolver um cronograma,
(Guia PMBOK®), 4a edição. Pennsylvania: PMI, 2008.
vamos nos ater apenas aos processos de planejamento listados
anteriormente.

Dê seu feedback sobre esta edição! Feedback

Conclusão eu

s
Dê
É importante deixar claro aqui que gerenciar corretamente o A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
tempo do projeto, desenvolvendo cronogramas com base nas Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
melhores práticas PMI, não garante o sucesso no atendimento Dê seu voto sobre este artigo, através do link:
ao prazo estabelecido pelo patrocinador. Ao contrário do que
www.devmedia.com.br/esmag/feedback
é dito, a culpa quase sempre não é do cronograma.

Edição 40 - Engenharia de Software Magazine 19

Planejamento e Gerência
Nesta seção você encontra artigos voltados para o planejamento
e gerência de seus projetos de software.
Aprimorando o gerenciamento de projetos
com mapeamento de processos
Gerenciamento de projetos utilizando conceitos de Mapeamento de Processos
Renato Borges de Souza
renato@sopixel.com.br
Bacharel em Ciência da Computação
(UFAM), Especialista em Gerenciamento
de Projetos (UGF). Analista de Negócios
em Processamento de Dados do Amazonas
(PRODAM), atua no ramo de gerenciamen-
to e tecnologia há mais de 5 anos, a maior
parte dele prestando serviços em TIC para
a PETROBRAS. Na área acadêmica, lecionou
na UNILASALLE e para o Governo do Esta-
do do Amazonas. É um dos fundadores do
blog Qualidade Manaus (http://qualida-
demanaus.sopixel.com.br) e da empresa
Sopixel (http://www.sopixel.com.br).
20 Engenharia de Software Magazine - Aprimorando o gerenciamento de projetos com mapeamento de processos
N
a literatura de Administração
de Empresas e Empreendedo-
rismo, muitos são os caminhos
para criação, desenvolvimento e firma-
ção de uma Empresa. A criação de uma
empresa pode ser motivada por uma
ideia, necessidade ou oportunidade.
Diante do fator motivador, as ações para
transformação de uma ideia em produto
são inúmeras, até que a empresa possa
fabricar o produto de maneira contínua.
Mas apenas a fabricação do produto
não é suficiente. Existem fatores não
De que se trata o artigo?
Neste artigo veremos a importância da utilização dos
modelos gerados pelo mapeamento de processos
organizacionais para o gerenciamento de projetos
na organização, bem como alguns documentos das
áreas de conhecimento do PMBOK que podem fazer
uso das informações geradas pelo mapeamento de
processos.
Em que situação o tema é útil?
Na busca pelo alinhamento estratégico do projeto
com os negócios empresariais. Visto que o projeto
será guiado pelos fatores ambientais da empresa,
seus processos, estratégias e cadeia de valor.
Resumo:
O presente artigo trata da utilização das infor-
mações geradas pelo mapeamento de processos
empresarial no gerenciamento de projetos, bus-
cando o alinhamento estratégico do projeto com
os negócios empresariais.
previsíveis como o mercado, concor-
rentes, custos, clima, entre outros, que
podem prejudicar o funcionamento
organizacional e a comercialização
de seu produto ou serviço. Entender
o funcionamento da empresa e seus

diferenciais perante os concorrentes é fator essencial para a
firmação da empresa.
Para manterem-se na frente, muitas empresas investem em
novos produtos, mercados, inovação e fidelização de clientes.
Cada uma dessas ações deve ser gerenciada de maneira que
o risco de perda seja reduzido e o retorno do projeto maximi-
zado. Dessa forma, pode-se dizer que a chave para o sucesso
empresarial reside na capacidade de atrair e realizar projetos
com sucesso.
Cada projeto tem sua particularidade e exige um número
grande de envolvidos trabalhando juntos. Um desses envolvi-
dos é a própria organização, que no momento do seu processo
de criação, desenvolveu sua missão, visão, valores, objetivos
estratégicos e identificou suas atividades, buscando sempre
executá-las de forma eficiente.
Diante desse cenário complexo de funcionamento da empre-
sa, surge o papel do Gerente de Projetos (GP), que segundo
MULCAHY, tem como alguns de seus papéis, coordenar
interações entre o projeto e as principais partes interessadas
da empresa, identificar quais fatores ambientais da empresa
podem ter influência sobre o projeto e, quando disponível a
informação, considerar os ativos de processos organizacionais
(processos, procedimentos e informações históricas) no desen-
volvimento do plano de projeto.
A busca por informações a ser realizada pelo GP visa a
compreensão da situação atual da empresa, informada em
suas metas, planos e objetivos, permitindo ao mesmo perceber
onde será o resultado do projeto. Essas informações o GP uti-
lizará no desenvolvimento do seu plano de projeto, buscando
o alinhamento entre as áreas de conhecimento, citadas pelo
PMBOK (4ª Edição) – integração, escopo, tempo, custo, recursos
humanos, aquisições, qualidade, riscos – e o planejamento
estratégico empresarial. Cada plano de uma área do conheci-
mento será desenvolvido em cima da premissa principal da
visão empresarial, permitindo o projeto como um todo fazer
parte do objetivo da organização. Isso poderá evitar que um
projeto, após um tempo de planejamento, possa não ser apro-
vado ou ser descontinuado por ir de encontro à maneira do
funcionamento empresarial.
Por meio deste artigo busca-se a construção de conheci-
mento em torno do tema estudado, analisando a influên-
cia dos modelos gerados pelo mapeamento de processos
organizacionais diante do gerenciamento de projetos na
organização. Por isso, nós tentaremos preencher a lacuna
entre a determinação dos processos de negócios, que deve
representar a visão da empresa, e o planejamento de pro-
jetos, no qual muitos gerentes não prosseguem com seus
projetos por estes não estarem alinhados aos objetivos da
empresa. Observa-se que o foco deste artigo detém-se aos
conceitos superficiais de mapeamento de processos e geren-
ciamento de projetos, considerando que o leitor possua um
conhecimento prévio nas áreas citadas. Por fim, apontam-
se maneiras de utilização dos modelos de mapeamento de
processos no desenvolvimento dos planos de gerenciamento
de projetos.
PL ANEJAM ENTO
Fatores Ambientais
Segundo o PMBOK (PMI - 4ª Edição), projeto é um esforço
temporário empreendido para criar um produto, serviço ou
resultado exclusivo. Trabalhando com projetos, o Gerente de
Projetos (GP) deve aplicar todo seu conhecimento, habilidade,
ferramentas e técnicas às atividades do projeto a fim de atender
seus requisitos, visando atingir o nível de qualidade exigido
pelo cliente. O GP enfrenta a todo o momento restrições con-
flitantes, tais como escopo, cronograma, orçamento, recursos,
qualidade e riscos, onde a alteração em uma delas poderá
ocasionar mudanças, positivas ou negativas, impactantes ou
não, nas outras restrições. Isso demanda um alinhamento com
o tratamento dessas restrições de acordo com a prioridade
definida na organização.
O PMBOK trata os fatores ambientais da empresa como um
termo chave, que cerca ou influencia o sucesso de um projeto.
Nesses fatores estão incluídos a cultura, a estrutura e os pro-
cessos organizacionais. Os fatores ambientais são considerados
didaticamente como entrada para a maioria dos processos de
planejamento do projeto e podem restringir as opções de ge-
renciamento de projeto. Por exemplo, no processo Desenvolver
o termo de abertura do projeto, que tem como algumas de suas
entradas os fatores ambientais e os ativos de processos organi-
zacionais. Para desenvolver esse termo, o GP precisa saber qual
a ideologia central de funcionamento da empresa, se a mesma
baseia-se em lucro ou qualidade, se tem uma atitude conserva-
dora ou com ações ambiciosas, se seus projetos são de longo ou
curto prazo, entre outras informações. Como ativo de processo
organizacional, pode-se observar quais os processos básicos
para o funcionamento da empresa, independente de pessoas,
se os mesmos são duradouros e preparados para mudanças,
se os mesmos representam o funcionamento real da empresa
e quais princípios esses processos estão sendo guiados.
Apesar de toda importância didática dos fatores ambien-
tais, muitas empresas não possuem um volume grande de
informações sobre elas, sendo que muitas dessas informações
estão somente na cabeça de alguns poucos funcionários. Para
contornar essa dificuldade, o GP não pode focar somente nas
ferramentas pesadas do negócio, como cronograma, orçamento
e escopo, e perder a visão dos aspectos mais subjetivos do
projeto, como a cultura, a qualidade dos recursos humanos e
os objetivos previamente definidos pela empresa.
Considerando os fatores ambientais importantes para o
gerenciamento de projetos e para o entendimento do funcio-
namento empresarial, onde o Gerente de Projetos poderia
coletar essas informações? No organograma empresarial, na
infraestrutura, no mercado no qual a empresa está inserida, na
estrutura organizacional (matricial, funcional ou projetizada),
nas leis que a regem e, principalmente, em seus processos de
negócios. Este último, particularmente, será tratado com mais
frequência no artigo.
Mapeamento de Processos
Em busca de um maior entendimento de sua realidade orga-
nizacional e de uma visão compartilhada de suas competências
Edição 40 - Engenharia de Software Magazine 21
e estratégias, as empresas vêm utilizando o Mapeamento de
Processos para representar modelos, explicitar conhecimen-
tos e experiências, tornando-o um guia para análise crítica e
suporte à tomada de decisão.
O Mapeamento de Processos é o trabalho realizado para
conhecer o comportamento organizacional, permitindo, atra-
vés da modelagem de processo, o desenho ou representação
das sequências dos processos, sub-processos, atividades e
objetivos. Entende-se como Processo de negócio as atividades
coordenadas a fim de atingir um determinado objetivo.
A finalidade do mapeamento é entender e documentar os
processos empresariais, para que com essas informações, com o
nível ideal de detalhamento desejado, a empresa reduza o custo
no desenvolvimento de produtos e serviços, reduza falhas na
integração entre sistemas e elimine ou simplifique processos
quando necessário (BIZINOTO, 2009).
O Mapeamento de Processos tem como resultado um conjun-
to de modelos que devem representar o padrão atual (AS IS)
ou esperado/futuro (TO BE) de comportamento do processo
empresarial, seguindo sempre os princípios da modelagem de
processos. Esses princípios são:
• Aderência: Representar o mais próximo possível a estrutura
e a realidade modelada. A modelagem de processo não pode
ser apenas um documento desenvolvido para seguir um
padrão de mercado. Ela deve ser condizente com a realidade
empresarial;
• Relevância ou suficiência: Representar o que é importante
para o processo, de acordo com o escopo definido previa-
mente, com todas as informações relevantes. Nesse momento,
deve-se observar toda a cadeia de valor e a ligação entre os
processos para que não se esqueça dos elementos chaves na
cadeia. A dificuldade reside na determinação sobre o que é
ou não importante;
• Custo/Benefício: Representar modelos cujo trabalho atual
vem apresentando dúvidas e erros durante sua execução, oca-
sionando perdas para a empresa. Assim é possível saber se o
tempo despendido para o mapeamento do processo equivale
ao valor do mesmo;
• Clareza: A certeza de que o diagrama desenvolvido repre-
senta de maneira clara o processo, permitindo o entendimento
de seu público alvo;
• Comparabilidade: Utilizar para o mapeamento de diferentes
processos a mesma metodologia, permitindo uma comparação
entre os mesmos;
• Estruturação sistêmica: Representar de forma clara a in-
tegração entre modelos, reconhecendo diversos aspectos da
realidade, com a capacidade desses modelos se estruturarem
metodologicamente.
Diagramas
Comunicar-se bem é fundamental para o bom funcionamento
empresarial. Tudo é valido para que o receptor compreenda
com clareza a informação transmitida pelo emissor. Comu-
nicação esta que pode ser oral ou escrita, utilizando meios
como textos, vídeos, imagens ou diagramas, por exemplo.
22 Engenharia de Software Magazine - Aprimorando o gerenciamento de projetos com mapeamento de processos
Particularmente, no Mapeamento de Processos, a notação em
Diagramas é utilizada para a construção de um esboço do
funcionamento do sistema organizacional.
Para a elaboração dos diagramas, técnicas de modelagem
e notação de processos de negócio foram desenvolvidas ao
longo do tempo, tais como o SADT (Structured Analysis and
Design Technique), IDEF (Integrated Computer Aided Manufactu-
ring Definition) e suas variações IDEF0, IDEF1X, e EPC (Event-
driven Process Chain). Cada uma com o objetivo de representar
graficamente os processos, atividades, fluxo de informações e
estrutura de informações no negócio.
A tarefa de desenhar os processos de negócio em diagramas
é facilitada por diversas ferramentas disponíveis no mercado,
conhecidas como Ferramentas CASE (Computer-Aided Software
Engineering), variando em níveis de sofisticação e abrangên-
cia. A ferramenta escolhida deverá ter recursos que permita
representar elementos como entidades, atividades, ligações,
associações, atribuições, entradas e saídas de processo, entre
outros, visando representar o funcionamento do sistema or-
ganizacional. Entre essas ferramentas podemos citar o BPWin,
Visio, Smartdraw, Synthis Process Modeler e ARIS (Architecture
of Integrated Information Systems).
No referido artigo, os diagramas do mapeamento de processo
foram desenvolvidos com o apoio da ferramenta ARIS. Segundo
MACEDO, essa ferramenta permite avaliar métodos de modela-
gem e integrá-los pela concentração de seus focos, como foco em
processos, atividades ou objetivos, e serve como uma estrutura
de orientação para o desenvolvimento de projetos complexos
porque ela contém um modelo de procedimento para o desen-
volvimento de sistemas de informações integrados.
Por representar os processos empresariais, os modelos ge-
rados pela ferramenta ARIS podem ser utilizados como fonte
de informação para entendimento dos fatores ambientais da
empresa no desenvolvimento de um novo projeto. Dentre os
diagramas a serem utilizados, citamos o VAC (Value Added
Chain) ou Cadeia de Valor, EPC e o OD (Objective Diagram),
conceituados conforme abaixo:
• Diagrama VAC – especifica as funções de uma organiza-
ção as quais influenciam diretamente o real valor agregado
da organização. Estas funções podem ser ligadas a outras,
de forma a sequenciá-las e, então, formar a cadeia de valor
agregado. Descreve os processos de negócio do ponto de vista
mais abstrato. A cadeia de valor do nível mais alto representa
o processo de negócio da organização;
• Diagrama EPC – Sequência de tarefas ou atividades que
representam o processo e agregam valor ao negócio. Englobam
algumas informações como papéis executores e unidades or-
ganizacionais, raias, interfaces para outros processos e eventos
que marcam o início e fim de cada processo;
• Diagrama OD – o Diagrama OD representa os diferentes
objetivos presentes em uma organização ou instância organi-
zacional, além de explicitar as relações de causalidade entre
eles. Cada objetivo pode conter um Fator Crítico de Sucesso,
que representa um elemento que pode comprometer o alcance
de um objetivo.

Estudo de caso
Para o presente artigo, desenvolveremos diagramas de mape-
amento de processo baseados em uma empresa de Tecnologia
da Informação, focada em tecnologia Web, com a missão de
lançar produtos inovadores no mercado de mídias sociais. A
empresa é nova no mercado, com funcionários jovens, comuni-
cação direta entre eles, capital de giro baixo, prezando sempre
pela criatividade e inovação.
O foco dos diagramas será na cadeia de valor Gerir Vendas,
responsável por atrair e reter clientes. A Figura 1 representa a
cadeia de valor para o Macro Processo Gerir Vendas.
Figura 1. Cadeia de Valor
A Cadeia de Valor, representada na Figura 1, mostra a ligação
entre as fronteiras organizacionais, onde o processo se inicia, e
os passos que devem ser executados para seguir em frente. A
cadeia de valor deve ser mapeada de uma maneira que permita
à empresa atingir seus objetivos. O processo Prospectar Clientes,
ao mesmo tempo em que consome recursos empresariais, tem
como resultado a criação de valor a ser consumido pelo processo
Segmentar Clientes. A não execução correta de um desses pro-
cessos comprometerá todo o Macro processo Gerir Vendas.
Cada processo da cadeia de valor possui objetivos relacionados
a ele. A execução correta de um processo visa o atendimento de
um objetivo estratégico. A Figura 2 representa o Diagrama de
Objetivos da empresa em questão, no processo Realizar Vendas,
que está abaixo do macro processo Gerir Vendas.
Figura 2. Diagrama de Objetivos
Nesta figura, o objetivo Otimizar a produtividade em
vendas representa o que a organização pretende com suas
ações no processo Realizar Vendas. O Objetivo citado tem um
PL ANEJAM ENTO
relacionamento de causa e efeito com outros objetivos, como
por exemplo, Reduzir Custo Operacional, podendo este ser
de uma área ou de diversas áreas da empresa. A realização
eficiente dos objetivos Reduzir Custo Operacional, Melhorar
controle de Estoque e Otimizar relacionamento com o cliente,
permitirá que o objetivo Otimizar a produtividade em vendas
seja atingido.
Um dos benefícios do Diagrama de Objetivos é permitir que
as áreas da empresa conheçam em quais objetivos elas estão
inseridas, percebendo assim o seu papel dentro da cadeia de
valor empresarial. Com os objetivos bem definidos, presume-se
que os mesmos representem a estratégia da empresa e podem
servir como base para nortear as atividades empresariais,
incluindo os projetos a serem desenvolvidos.
O diagrama EPC segue um fluxo de eventos e funções. O mes-
mo possui um número maior de informações sobre o processo,
tais como os participantes e suas atividades e tarefas, pontos
de decisão representados por conectores, processamento de
informações e ponto de interface com outros processos. Você
pode criar níveis de hierarquia para o seu diagrama EPC de
acordo com sua necessidade de entendimento dos detalhes do
processo. Isso pode ser feito através do refinamento de uma
função em outros diagramas EPC ou ligando uma função
a um diagrama de atividade que detalhe mais os passos de
execução da mesma.
Para o gerenciamento de projetos, as informações dos diagra-
mas de processo podem ser utilizadas para saber quem está
envolvido, quando e como uma função é realizada, antecipan-
do quais stakeholders serão afetados caso uma atividade seja
alterada. Para projetos de softwares o uso do Diagrama EPC é
um grande benefício, pois representa o fluxo de informação de
um processo dentro da empresa, utilizado no desenvolvimento
do diagrama de Casos de Uso.
Mapear para Gerenciar
Um estudo de benchmarking realizado pelos capítulos bra-
sileiros do PMI (Project Management Institute) aponta que 58%
dos projetos nem sempre estão alinhados ao planejamento
estratégico empresarial, não atingindo assim, em sua maioria,
os benefícios e retornos estratégicos esperados. Para responder
a essas preocupações, os executivos e os proponentes do geren-
ciamento de projetos necessitam de métodos e técnicas para
identificar, medir e demonstrar o valor dessas iniciativas.
Visto que a estratégia da empresa impacta na maneira como
o projeto será desenvolvido, a técnica de mapeamento de pro-
cessos irá prover produtos que permitirão analisar aspectos da
organização, para realizar melhores decisões sobre as opera-
ções atuais e aprimorar o gerenciamento de projetos futuros.
Quando um Gerente de Projetos for demandado a liderar um
novo projeto, sabendo da importância dos fatores ambientais
da empresa e processos de negócios, o primeiro passo será ana-
lisar as diretrizes empresariais, a cadeia de valor que o projeto
será inserido e quais objetivos estratégicos estão envolvidos.
Isso permite um entendimento prévio da complexidade do
projeto, bem como da sua importância para a empresa.
Edição 40 - Engenharia de Software Magazine 23
 As informações do mapeamento de processos servirão como
fonte para o desenvolvimento dos planos de projeto. Usando
técnicas de elicitação de requisitos, algumas perguntas pode-
rão ser feitas aos envolvidos na cadeia de valor empresarial,
visando o desenvolvimento dos planos de projeto, como por
exemplo:
1. O projeto está inserido em um processo chave?
2. Por quais setores empresariais da cadeia de valor o processo
está envolvido?
3. Os donos dos processos têm poderes de decisão no
projeto?
4. Os donos dos processos estão informados sobre a iniciativa
do projeto?
5. Quais seriam os impactos e riscos da alteração do fluxo do
processo atual?
A percepção prévia dos processos envolvidos permitirá um
foco maior do GP na realização das entrevistas. As informações
coletadas acima, como o processo chave, seus donos e setores
envolvidos, sendo devidamente organizadas, serão entradas
para a composição dos planos de projetos. Dentre os planos,
podemos citar os seguintes:
1) Gerenciamento de comunicação:
a. Quem são os envolvidos, seus papéis e responsabilidades
dentro do processo e objetivos?
b. Quem deverá ser informado, o meio de comunicação e
a frequência?
c. Como a comunicação é realizada entre os processos?
d. Qual a expectativa dos donos do processo?
2) Gerenciamento de Escopo
a. Quais são as fronteiras do projeto, dentro dos processos
empresariais?
b. Quais processos serão afetados e os seus requisitos de
funcionamento?
c. Qual objetivo empresarial será afetado ao final do
projeto?
d. Quais pontos críticos devem ser analisados?
As informações dos planos citados acima possivelmente não
estarão completas apenas com as informações coletadas do
mapeamento de processos. Outras fontes e pessoas deverão
ser consultadas pelo GP.
Outros planos do projeto poderão fazer uso das informações
geradas pelo mapeamento do processo, como o Plano de Ris-
cos, utilizando os fatores críticos do objetivo como entrada;
Plano de Custo, adequando-se de acordo com o orçamento da
empresa, definida em seus objetivos; e Plano de Qualidade, no
qual o GP determinará os métodos de aceitação de entregas,
de acordo com os objetivos do processo.
Sendo a proposta do artigo o mapeamento de processos para
o gerenciamento de projetos, vamos utilizar o objetivo empre-
sarial “Otimizar o relacionamento com o Cliente”, conforme a
Figura 2, que está inserido na cadeia de valor “Gerir Vendas”,
para desenvolver o documento de Termo de Abertura do
projeto. O Termo de Abertura abaixo conterá alguns campos
24 Engenharia de Software Magazine - Aprimorando o gerenciamento de projetos com mapeamento de processos
propostos pelo PMBOK. As informações nele contida terão
como base um projeto de CRM (Customer Relationship Mana-
gement), observando onde as informações dos diagramas de
processo são utilizadas neste documento.
Termo de Abertura – Projeto CRM
1) Propósito do projeto ou justificativa:
• Aumento da produtividade de vendas, através da Fide-
lização, visto que é mais caro conquistar um cliente que
manter um novo.
2) Objetivos mensuráveis:
• Aumentar em 20% a venda anual para cada cliente.
3) Requisitos de alto nível:
• Gestão da base de clientes segmentadas; Histórico de ações
e tarefas realizadas com o cliente; Relatório de produtos
vendidos; Facilidade de acesso.
4) Descrição do projeto em alto nível, características do
produto:
• Projeto: Visa o acompanhamento de informações dos
clientes, com acesso rápido às mesmas, apoiando o atendi-
mento ao cliente, otimizando assim o relacionamento com
o mesmo, tornando-o fiel a empresa;
• Características do Produto: Interface Web; Facilidade de
acesso via navegadores de Internet; Segurança no acesso
aos dados; Usabilidade.
5) Riscos de alto nível:
• Entendimento falho da Cadeia de Valor – O projeto não
atender o objetivo da cadeia de valor.
• Falha na Prospecção de Clientes – Escolha equivocada
de clientes, que não necessitam do produto oferecido, para
compor a base.
• Falta de infraestrutura tecnológica – Diante da solução propos-
ta, não ter a infraestrutura necessária para funcionamento.
6) Nome e responsabilidade das pessoas autorizando o termo
de abertura:
• Espaço para adicionar os envolvidos na Cadeia de Valor
e nos objetivos empresariais.
Observa-se que no Termo de Abertura, boa parte das frases
puderam ser coletadas da Cadeia de Valor e do Diagrama de
Objetivos, como por exemplo, no item 1), que corresponde ao
objetivo do processo “Realizar Vendas” e no item 4), com o
objetivo “Gerir Registro de Informações”. Mais uma vez, as
informações não estão completas e reuniões com os envolvidos
serão necessárias. Sendo que, esses envolvidos já podem ser
visualizados através desses diagramas, indicando assim um
caminho a ser seguido pelo GP.
Na Tabela 1, é feito um “de-para” visando listar em quais planos
de projeto as informações do Mapeamento de Processos podem
ser utilizadas. Essa utilização pode ser muito maior, visto que
as informações dos diagramas de processo dependem da ne-
cessidade da empresa. Caso a necessidade da empresa seja um
entendimento macro de seu funcionamento, elas não adicionarão
certas informações, consideradas irrelevantes em seus processos,
mas que seriam de grande valia para os planos de projeto.
 PL ANEJAM ENTO

Mapeamento de Processos Plano de Projetos

Escopo – Premissas e Restrições, Cultura da empresa, Benefícios esperados, Áreas envolvidas, Business Case, Patrocinador, Termo de Abertura.
Diagrama de Objetivos
Riscos – Ameaças e oportunidades, Tolerância e limites para riscos, Complexidade das relações.
Integração – Reunião dos ativos das partes interessadas, Custo-benefício.
Comunicação – Áreas envolvidas, Processos afetados.
Integração – Stakeholders, Controle integrado de mudanças.
Cadeia de Valor
Tempo – Definição de cronograma.
Escopo – Complexidade do processo, Stakeholders, Objetivos mensuráveis, Patrocinador.
Comunicação – Stakeholders, Gerenciamento de expectativas, ligação entre setores.
Recursos Humanos – Conhecimentos e Habilidades dos gestores.
Fluxo de Processos
Riscos – Processos e procedimentos da empresa.
Tempo e Custo – Definição de cronograma, Estimativa de custos.
Tabela 1. Utilização de Diagrama de Processos nos Planos de Projeto

Benefícios Diante da importância elucidada do mapeamento de processos

Uma das grandes dificuldades em gerenciar projetos é en-
tender o funcionamento empresarial e suas estratégias, bem
como manter o projeto alinhado às estratégias empresariais.
Os tópicos acima citaram na prática como entender o fun-
cionamento baseando-se nas informações dos documentos
gerados pelo Mapeamento de Processo. A reutilização dessas
informações, não a sua duplicação, é o principal benefício para
o Gerenciamento de Projetos, visto que a empresa realizou
um trabalho de investimento na estruturação empresarial,
definição de processos, documentação, criando suas instruções
de trabalho, nomeando os setores envolvidos nos processos,
validando esses documentos, tornando-os oficiais dentro da
empresa. Quanto mais pessoas se beneficiarem com essas
informações, mais vantajoso terá sido o investimento.
Nestas circunstâncias, o GP iria compartilhar a visão empre-
sarial, definida em seus documentos, em prol de seu projeto,
utilizando-a como um guia para a coleta de requisitos e desen-
volvimento dos planos de projeto. Dessa forma, o GP “venderá”
seu projeto com mais confiança por saber que o mesmo está
envolvido em um objetivo empresarial, em uma cadeia de valor
crítica ou reduzindo a complexidade de um processo. Tudo isso
de acordo com o que foi priorizado e previamente definido pela
empresa, presumindo-se o envolvimento e interesse da mesma
na execução do projeto. Ou seja, alinhamento do projeto com
a estratégia da empresa.
Conclusão
Conforme os trabalhos indicados na referência do presente
artigo, inúmeros são os casos de utilização do Mapeamento de
Processos como apoio para diversas frentes de trabalho.
O objetivo almejado neste artigo foi alinhar-se às estratégias
da empresa, através de um melhor uso dos fatores ambientais
e das diretrizes que alicerçam o funcionamento empresarial,
e do gerenciamento de projetos para a empresa, foi traçado um
paralelo de utilização do Mapeamento de processos no Gerencia-
mento de Projetos, sendo que as fronteiras entre os dois podem
ser muito maiores, permitindo uma reutilização significante de
informações, cujo principal beneficiado será a empresa.
Referências
Artigo “Proposta para concepção de um Sistema de Medição de Desempenho
Orientado por Processos: Aplicação em uma Prestadora de Serviços de Suporte
Operacional”, escrito por Oliveira, Sando e Cameira.
http://trac2.assembla.com/projeto_pri/export/23/Paim,%2520Cameira,%2520Clemente,%25
20Clemente%2520-%2520Engenharia%2520de%2520Processos%2520de%2520Negocios%2
520-%2520XXII%2520ENEGEP%2520-%25202002.pdf
Artigo “Modelo de Processo de Negócio Analisar Pedido de Crédito” escrito por Diir,
Souza, Azevedo e Santoro
http://np2tec.uniriotec.br:9093/np2tec/publicacoes/RT-NP2TEC-2010-008-ModeloProcesso-
AnalisarPedidoCredito-20100811.pdf
Artigo “Workshop – Melhoria de Processos - Mapeamento de Processos”
http://www.mp.go.gov.br/portalweb/hp/12/docs/mapeamento_dos_processos.pdf
Apresentação “Governança de Processos: Os elementos de um Framework”
http://www.enjourney.com.br/wp-content/uploads/2010/10/wp-2-governanca-de-
processos-1.pdf
Artigo “Ferramentas de Modelagem de Processo: Uma avaliação” escrito por
Macedo, Rodrigo dos Santos e Schmitz, Eber Assis
http://www.triadesolucoes.com.br/Files/Artigo_001.pdf
Trabalho de Conclusão de Curso “Modelagem de Processos: GAP Conceitual Quanto
ao nível ideal de detalhamento de processo” escrito por Vitor Bizinoto
http://bdm.bce.unb.br/bitstream/10483/767/1/2009_V%C3%ADtorBizinotoSantosAnjo.pdf
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê

para o gerenciamento de projetos. Partes desses fatores podem A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e

estar documentados através de um trabalho de mapeamento de Para isso, precisamos saber o que você, leitor, acha da revista!
s

ta
processos, que orienta a ação dos colaboradores e da empresa Dê seu voto sobre este artigo, através do link:
edição

como um todo, e permite uma visão clara e compartilhada dos

www.devmedia.com.br/esmag/feedback
processos, seus riscos, setores envolvidos e seus objetivos.

Edição 40 - Engenharia de Software Magazine 25

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros

Otimização de Processos de Negócio usando BPM

Transformando organizações “Boas” em organizações “Ótimas”

Ricardo S. Ferreira gócio em uma organização pode fazê-la obter esse

rferreira@progress.com
Profissional com amplo conhecimento em
diversos domínios de negócio, em especial na
área de telecomunicações e conteúdo digital.
Possui mais de 13 anos de experiência, onde
durante estes anos já atuou em dezenas de
projetos envolvendo complexos cenários de
integração corporativa, e na definição, imple-
mentação e implantação de projetos que se
utilizam de arquiteturas orientadas a servi-
ços. Possui mais de 10 anos de experiência na
plataforma Java EE, tendo ajudado diversas
organizações na implementação de sistemas
críticos usando servidores de aplicação como
JBoss, WebLogic e Websphere. Atualmente
trabalha na área de soluções da Progress
Software, ajudando organizações da américa
latina a adquirem maior responsividade ope-
racional por meio de produtos de BPM, CEP,
SOA e gestão semântica de dados. Antes de
atuar na Progress Software, foi arquiteto de
De que se trata o artigo?
Este artigo irá mostrar os detalhes e problemas relacio-
nados a processos de negócio dentro de uma organiza-
ção, além de explicar, passo a passo, como conduzir uma
iniciativa de otimização de um processo de negócio com
o intuito de torná-lo mais eficaz e mais eficiente.
Em que situação o tema é útil?
Organizações de diferentes segmentos precisam
mais do que nunca ter um bom diferencial e servir
com cada vez mais eficiência e agilidade aos seus
clientes, a fim de sobreviver num mercado onde a
decisão de ir para a concorrência está a apenas um
clique de distância ou com o custo de apenas uma
ligação. A otimização constante de processos de ne-
diferencial e essa agilidade, além de prover um nível
de satisfação e excelência superior aos seus clientes,
fornecedores e funcionários, por meio da simplifica-
ção destes processos.
Resumo:
Este artigo pode ser uma ferramenta muito valiosa
para gerentes ou líderes de área de organizações que
estejam engajadas em otimizar seus processos de
negócio objetivando obter maior diferencial perante
seus clientes, fornecedores e funcionários. Ao final da
leitura desta série de artigos, será possível que o caro
leitor possa conduzir uma iniciativa de otimização de
processos dentro de qualquer organização.

soluções na JBoss, a divisão de middleware da
Red Hat. Possui as certificações SCEA, SCBCD,
SCWCD, SCJP, Oracle SOA Architect Certified
Expert, IBM Certified SOA Solution Designer,
IBM Certified RUP v7.0 Solution Designer,
Borland JBuilder Product Certified Developer,
Borland Delphi Product Certified Developer e
de Borland Certified Instructor. Já palestrou
em diversos eventos de tecnologia do Brasil
como Just Java, The Developers Conference,
Sun Tech Days, COMDEX, JBoss in Bossa, Futu-
recom e CIAB.
T
oda jornada possui um fim. Na
edição 35 da revista Engenharia
de Software Magazine, iniciamos
a jornada de estudo dos conceitos e prá-
ticas relacionadas à melhoria contínua
de processos de negócio, bem como uma
metodologia para condução de projetos
de BPI. Já nas edições 36 e 39 da revista,
aprofundamos ainda mais nesta meto-
dologia, abordando as fases de análise
e redesenho de processos de negócio.
Neste artigo, iremos dar continuidade
às demais fases que são necessárias para
o fechamento de um projeto de BPI, a
saber, as fases de aquisição de recursos,
implementação e melhoria contínua do
processo. Com isso, iremos dar fim ao
estudo da metodologia de BPI e deixar
como referência as fases e práticas estu-
dadas, para que qualquer gestor ou líder

26 Engenharia de Software Magazine - Otimização de Processos de Negócio usando BPM


de área interessado em melhorar a eficiência ou eficácia de um
ou mais processos de negócio de uma organização possam
segui-lo e utilizá-lo na prática.
Fase de Aquisição de Recursos
Agora que seu time de BPI criou um novo modelo para o
processo de negócio problemático, é hora de identificar e ob-
ter os recursos que você precisará para colocar a nova versão
do processo de negócio em operação. Independente de qual
departamento ou unidade de negócio você pertence, esta fase
irá fazer com que você colabore com diversos outros departa-
mentos da sua organização. Se o escopo da mudança proposta
for muito grande, você será forçado a trabalhar em conjunto
com os seguintes departamentos:
• Recursos Humanos;
• Tecnologia da Informação;
• Financeiro.
Os recursos que você precisará adquirir podem variar de acor-
do com a complexidade da mudança no processo de negócio. Por
exemplo, um processo de negócio pode requerer que:
• Novos papéis sejam criados ou alterados: Ocorre com a
maioria dos projetos de BPI. Pode ser que você tenha que
utilizar consultores ou terceiros para realizar a implementa-
ção do processo que foi redesenhado. Pode ser também que
você tenha que alterar as responsabilidades de um papel
existente da organização, de forma que ela seja responsável
por algumas das novas atividades do processo, ou pode ser
que você tenha que criar um papel completamente novo na
organização;
• Adquirir novos equipamentos ou softwares: Alguns proces-
sos redesenhados requerem que você adquira novos equipa-
mentos ou pacotes de software. Para exemplificar isso, imagine
uma empresa que precisa compartilhar seus documentos
eletrônicos entre as equipes de marketing e desenvolvimento
de produtos. Para que isso ocorra, a empresa decidiu comprar
uma solução de software de portal e ECM, para dar suporte
a todo o ciclo de vida de criação, edição e compartilhamentos
de documentos na empresa;
• Novos espaços físicos para acomodar os novos equipamen-
tos ou pessoas contratadas: É possível que você tenha que
aumentar seu espaço físico da organização, para acomodar
novas salas para as pessoas contratadas ou os equipamentos
(ex: impressoras) comprados;
• Suporte de especialistas em tecnologia da informação: Por
exemplo, uma empresa de vendas que deseja realizar uma
nova pesquisa de mercado requer a utilização de um sof-
tware de CRM (Customer Relationship Management). Vários
especialistas terão que ser contratados para ajudar a equipe
da organização a integrar a nova solução aos seus bancos de
dados de clientes;
• Treinamento: Pode ser que devido à aquisição de novos
equipamentos, softwares ou mesmo a utilização de novas
práticas, as pessoas envolvidas no novo processo tenham que
ser treinadas e capacitadas.
proce s s o
Claro, para muitos processos de negócio os recursos que
deverão ser adquiridos serão mínimos. Por exemplo, para a
implementação de um novo processo de abertura de contas
pode ser necessário apenas que a equipe de RH crie uma nova
posição de coordenador de contas, e que a área de TI assegure
que os escritórios de empréstimos irão usar as ferramentas
corretas para garantir a colaboração entre os funcionários e
clientes.
Uma vez que você tenha identificado corretamente quais se-
rão os recursos que terão que ser adquiridos, você deve pensar
em o que precisa ser feito para consegui-los. Para construir
a infraestrutura necessária e levantar o material adequado,
você deverá negociar fundos com a organização ou mesmo
realizar empréstimos de recursos de outras áreas e departa-
mentos. Se várias pessoas requerem capacitação para atuar
no novo processo de negócio, você poderá ter que trabalhar
em conjunto com as áreas de RH para que a capacitação lhes
seja propiciada. Entretanto, se apenas uma pessoa precisa ser
treinada para que o novo processo de negócio seja posto em
prática, você não precisará ter que pedir a área de RH tais
recursos de capacitação.
Fase de Implementação do Processo Redesenhado
Com os recursos em mãos e o processo de negócio completa-
mente redesenhado e testado, é hora de colocá-lo em prática.
Isto é, chega a hora de você começar a experimentar o novo pro-
cesso dentro da organização. Muitos especialistas defendem
que a implementação é a fase mais difícil da metodologia. De
fato, existem sim algumas dificuldades a serem endereçadas,
mas algumas medidas podem ser tomadas para evitar tais
dificuldades. São elas:
• Entendimento dos obstáculos e dificuldades;
• Rollout do novo processo de negócio.
Antes de implementar seu novo processo, é muito importante
entender claramente quais são os obstáculos do novo processo
e perguntar para o seu time que passos podem ser dados para
evitá-los. A Tabela 1 sintetiza os obstáculos mais comuns da
fase de implementação de processos redesenhados.
Existem também algumas práticas clássicas que podem ser
utilizadas para que certos obstáculos sejam ultrapassados.
São elas:
• Envolva os stakeholders (as pessoas envolvidas no processo)
o máximo possível. Pessoas se sentem muito mais inclinadas
a apoiar as coisas que elas ajudaram a construir;
• Pergunte a todos os stakeholders sobre feedback quanto ao
novo processo de negócio. Faça-os enxergar as reais melhorias
que o novo processo irá trazer para a organização;
• Convide cada participante do projeto a escrever suas preocu-
pações num quadro branco. Faça com que todo o time entenda
as preocupações e proponha uma solução explícita para cada
problema. Faça com que os participantes se sintam mais a von-
tade ao ver os problemas citados sendo atacados um a um;
• Deixe bem claro a todos os participantes que o problema esta-
va no processo de negócio e não nas pessoas. Isso é importante
Edição 40 - Engenharia de Software Magazine 27
 Obstáculo Explicação Formas de se Evitar
Qualquer mudança no processo traz a impressão errada de que alguém estava
Faça com que todos os funcionários envolvidos tenham ciência de quais os ganhos
fazendo as coisas da forma errada. Por isso, é normal ocorrer alguma resistência por
Resistência dos Funcionários com o novo processo. Em especial, eduque-os sobre quais serão as compensações
parte dos funcionários envolvidos, especialmente se eles não conseguirem enxergar
que o novo processo de negócio irá trazer para eles e para a organização.
os benefícios do novo processo.
Se o novo processo de negócio extrapola fronteiras departamentais, gerentes irão Este tipo de problema precisa ser endereçado antes da fase de implementação,
começar a disputar pelos recursos e pela autoridade. Pode ser que aconteça que preferencialmente nas fases anteriores. Os gerentes precisam entender que o
Resistência dos Gerentes
alguns gerentes tenham que mudar a forma como conduzem seu trabalho (ter mais novo processo visa melhorar a performance da organização, e, portanto, é de
responsabilidades) em pró de uma iniciativa que era de outro gerente. interesse deles enquanto gestores e líderes.
Todo processo de negócio precisa de um dono, alguém que cuide dos interesses do
Se o processo não tiver um dono, então ele nunca deveria ter sido criado na
que o processo visa operacionalizar. É importante que o processo tenha um dono para
Novo Processo sem um “Dono” organização. Caso exista um dono para este processo, lembre-o constantemente
que os recursos necessários para sua implementação sejam providenciados e que o
sobre a importância do projeto de BPI e da melhoria do seu processo de negócio.
novo processo seja defendido dentro da organização.
Tabela 1. Obstáculos mais comuns durante a implementação de um processo redesenhado

para quebrar algumas resistências de pessoas que trabalham
há muito tempo na versão anterior do processo de negócio;
• Tente o máximo possível ressaltar as coisas positivas que a
versão anterior do processo trouxe para a organização. Isso
pode fazer com que os donos do processo se sintam mais
confortáveis em galgar novos desafios com o novo processo
de negócio;
• Faça com que as pessoas que ainda estiverem resistentes
quanto ao novo processo de negócio escutem o que pessoas de
outras organizações que passarem pelo mesmo tipo de proble-
ma tem a dizer. Pode ser que elas, ao ouvirem de outras pessoas
neutras, se sintam mais confiantes em apoiarem as mudanças
e implementação do novo processo de negócio.
É de suma importância que você dê uma visão geral do novo
processo a todos os stakeholders do projeto. Dê aos gerentes,
funcionários e outras pessoas envolvidas no processo, tempo
para entender ou reafirmar porque o novo processo é neces-
sário, como as coisas vão ser diferentes e melhores, e o que vai
acontecer quando o novo processo se tornar parte de operações
diárias. Isso fará com que todos os interessados já comecem a
refletir e planejar como irão executar suas atividades no novo
processo de negócio.
Eduque e familiarize. Crie uma visão concreta e detalhada de
como o novo processo funciona por meio de role-play, prática e
simulação. Assim como você usou estas técnicas durante a fase
três (redesenho do processo problemático), você pode usá-las
agora para testar (ou demonstrar) quão bem o seu novo pro-
cesso funciona. Por exemplo, se você se decidir praticar o novo
processo, peça a todos que estarão trabalhando no processo
para experimentá-lo exatamente como ele está destinado a se
desenrolar. Durante a prática, assista aos problemas, e então
decida como eliminá-los.
Pilote se necessário. Se você suspeitar que o novo processo
ainda possa ter algumas dificuldades que precisam ser traba-
lhadas, pilote-o. Durante um piloto, você executa o processo
como se estivesse valendo e realmente entregando os objetivos
esperados, mas limitando o âmbito do processo. Por exemplo,
você pode tentar o novo processo com apenas um grupo de
clientes, uma região de vendas, ou uma categoria de produto.
Você também pode restringir o piloto por hora, por exemplo,
executando-o durante vários meses e, em seguida, avaliar a
sua eficácia.
Pilotos são mais arriscados do que role-play, prática e simu-
lação, porque envolvem clientes reais, produtos ou serviços.
No entanto, se você monitorar os pilotos de perto, você pode
corrigir problemas assim que eles ocorrerem, enquanto ganha
um valioso feedback que ajudará a melhorar o processo. Outra
vantagem de usar os pilotos é que as pessoas que participam
do piloto irão treinar outras pessoas quando você desenrolar
o novo processo para outras regiões, produtos e grupos de
clientes. Os pilotos também darão aos céticos a oportunidade
de observar o novo processo em ação e para tranquilizar-se
que ela é eficaz.
Ponha em prática. Coloque o novo processo para a produção,
ao declarar o início de novas operações. Comece a coletar da-
dos sobre o desempenho de novas medidas relacionadas com
o processo, e garanta que você e seu time estejam disponíveis
para responder perguntas e apoiar as pessoas sobre como
o processo muda a forma como eles realizam suas tarefas.
Reconheça que haverá uma curva de aprendizado e que as
pessoas precisam de tempo para começar a se dar bem com
o novo processo.
Quebre a ruptura com o passado. Remova os artefatos do
antigo processo para reduzir qualquer tentação de fazer as
coisas da forma antiga. Esses artefatos podem incluir formas
antigas, tipo de papel, equipamentos, sinalização, e assim por
diante. Remover esses itens envia uma mensagem clara de que
o novo processo veio para ficar.
Melhorando Contínuamente seu Processo de Negócio
Depois que você tiver implementado seu novo processo de
negócio, haverá em você e no seu time uma vontade incon-
trolável de medir o processo e capturar os resultados. Com
isso, será feito um trabalho natural e espontâneo de análise
sobre que pontos do processo foram melhorados de fato, quais
pontos ainda merecem atenção e que tipo de ações podem ser
tomadas para melhorar ainda mais o processo. Pessoas que
participam de projetos de BPI tendem a se tornar aficionados
por melhoria de processos, e passam a dedicar grande parte

28 Engenharia de Software Magazine - Otimização de Processos de Negócio usando BPM


do seu tempo na organização pensando em como melhorar
o processo de negócio. Isso acontece porque essas pessoas se
tornaram parte de algo que é importante para a organização,
e elas irão defender esse processo como se fossem delas.
Existem hoje diversas literaturas no mercado que falam
sobre métodos e práticas sobre como implementar melhoria
contínua de processos de negócio, mas a experiência diz que
nenhuma metodologia será mais eficaz do que fazer com que
as pessoas envolvidas no processo passem a ser as responsá-
veis pela sua mudança de performance. Criar essa paixão nas
pessoas de forma que elas se sintam naturalmente motivadas a
querer melhorar sempre o processo é o segredo para ter ciclos
contínuos de melhoria de processos, fazendo até mesmo com
que as organizações não tenham que ter iniciativas formais
de BPI, e sim, pessoas que como parte de suas atividades
dedicam tempo para melhorar continuamente a performance
dos processos da organização.
É claro que as pessoas não podem simplesmente melhorar e
mudar continuamente os processos de negócio da organiza-
ção, uma vez que se trata de processos vivos que modificam
coisas importantes da organização como clientes, parceiros e
produtos. Esta é a razão com que as organizações devem eleger
um grupo ou área de negócios responsável por coordenar e
validar as iniciativas relacionadas à melhoria de processos,
sejam estas iniciativas formais ou informais. Normalmente,
essa área de negócios chama-se centro de excelência BPM, e
apesar de não ser uma regra, é composto pelos gestores de cada
área de negócio da organização, bem como alguns gestores de
áreas comuns como TI e RH.
Uma das atividades mais importantes que esse centro de
excelência realiza é a definição e apresentação dos objetivos
estratégicos da organização. Conhecer e divulgar os objetivos
estratégicos da organização ajudará os gestores a decidirem
sobre quais iniciativas de melhoria serão mais importantes ou
críticas, o que é um insight importante para quando diferentes
iniciativas de melhoria de processos estiverem disputando por
recursos ou investimentos para a condução de um novo proje-
to de BPI. Apesar de não ser agradável, é importante que em
certas ocasiões alguns projetos de BPI sejam mais prioritários
que outros, pois mais importante que a realização de todas as
iniciativas de BPI, é a garantia de que os objetivos estratégicos
da organização sejam cumpridos. Um bom exemplo de objetivo
estratégico é quando uma organização declara que deseja redu-
zir seus custos operacionais em 30%. Para atingir este objetivo,
é necessário saber o tempo necessário para isso, quais serão
os recursos que deverão ser controlados e quais unidades de
negócio da organização serão responsáveis por esta redução.
Vários pontos de decisão podem ser retirados a partir destas
definições, e a escolha de qual projeto de BPI deverá ou não
ser iniciado deverá ser fácil de resolver.
Um resultado positivo de quando se implementa melhoria
contínua de processos é que as unidades de negócio começam a
ganhar maior afinidade umas com as outras à medida que vá-
rios projetos de BPI são finalizados com sucesso. Isso acontece
porque, uma das características mais marcantes de processos
proce s s o
de negócio é que eles extrapolam fronteiras organizacionais,
e, por isso, acabam fazendo com que diferentes departamen-
tos entrem em sinergia para alcançar um objetivo que lhes é
comum. Quando equipes de diferentes unidades de negócio
começam a interagir e negociar melhores resultados, cria-se
uma dinâmica de trabalho muito eficiente na organização,
pois as unidades de negócio passam a enxergar não mais
resultados isolados e pessoais, mas resultados coletivos e sob
a ótica da organização. Se isso realmente ocorrer, é de suma
importância começar a pensar na definição e implementação
de arquiteturas corporativas de negócio, ou seja, grandes
blocos de valor que representam as estruturas pelas quais a
organização atinge seus objetivos estratégicos.
Arquiteturas corporativas é um assunto extremamente denso,
mas é sem duvida uma grande consequência do pensamento
de melhoria contínua de processos. De fato, as disciplinas de
BPM e arquitetura corporativa possuem diversos aspectos em
comum, e elas com certeza merecem uma considerável atenção
de organizações que necessitam dar resultados melhores e mais
rápidos. As organizações que buscam a constante melhora no
seu mercado devem estar cientes de que para conseguir isso,
ela deverá ter um arcabouço muito bem definido de processos,
pessoas e de tecnologia, e para controlar esses três elementos é
necessário balizar esse arcabouço numa arquitetura de referên-
cia, preferencialmente uma arquitetura de referência de merca-
do, como é o caso do TOGAF e do Zachman Framework. Se você
desprender algum tempo estudando tais frameworks arquite-
turais corporativos, verá que melhoria contínua de processos é
uma premissa para que as organizações possam estruturar seus
objetivos estratégicos. Apesar de estes frameworks possuírem
uma vertente bastante forte quanto a TI, é importante notar que,
tais arquiteturas de referência usam TI como facilitador para
que os processos de negócio organizacionais possam entregar
valor a organização e atingir objetivos estratégicos.
Outra ferramenta bastante poderosa usada na melhoria con-
tínua de processos de negócio é a monitoração dos processos e
transações da organização através da análise de indicadores,
alertas e falhas dos processos. A monitoração de processos
de negócio faz com que as organizações possam ter maior
insight sobre como os processos de negócio atuais estão ou
não cumprindo com seus objetivos. Como exemplo, imagine
uma empresa que vive de vendas de seus produtos. Ao definir
apropriadamente indicadores de negócio como quantidade de
produtos vendidos por mês, quantidade de clientes novos por
região, quantidade de produtos que não foram entregues a tem-
po e quantidade de produtos devolvidos por baixa qualidade,
já é possível capturar diferentes insights sobre pontos críticos
desta organização como faturamento, meios de produção, satis-
fação dos clientes, controle do estoque e rentabilidade mensal.
Esses pontos definem claramente quais são os processos de
negócios envolvidos e que tipo de atividades destes processos
é importante para que as métricas reflitam os valores que a
organização espera.
Atualmente existem diferentes tecnologias no mercado
que ajudam nesta questão de monitoração de processos e
Edição 40 - Engenharia de Software Magazine 29
transações de negócio. O BI (Business Intelligence) é uma
tecnologia que há tempos tem dado às organizações insights
importantes sobre como seus processos têm sido executados,
em especial quando condições especiais são configuradas para
análise. No entanto, um ponto fraco das ferramentas e soluções
de BI é que elas lidam com informações do passado, geralmente
informações que possuem dias, semanas ou até meses de de-
fasagem, pois são informações que sofrem processamento em
lote ou em massa. Esse tipo de informação fornece um valor
pequeno para a organização, em especial àquelas organizações
que precisam lidar com situações do momento e desejam dar
respostas rápidas a estas situações.
Para este caso, utilizam-se tecnologias de BAM (Business
Activity Monitoring), que são tecnologias capazes de coletar
informações e indicadores de negócio de processos e transações
que estão acontecendo agora. A Figura 1 mostra um exemplo
de produto de BAM sendo usado para monitorar processos
em tempo real.
Figura 1. Produto de BAM da Oracle para monitoração de processos em
tempo real
30 Engenharia de Software Magazine - Otimização de Processos de Negócio usando BPM
Considerações Finais
Nesta quarta parte da série de artigos sobre otimização de
processos de negócio, realizamos o estudo sobre as últimas
fases da metodologia de BPI que iniciamos nas edições
anteriores da revista. Vimos um pouco sobre as fases de
aquisição de recursos, implementação e melhoria contínua
dos processos, fases estas que representam a finalização de
um projeto de BPI numa organização. Através desta série,
é possível que você mesmo possa conduzir um projeto de
BPI na sua organização ou na organização do seu cliente,
com o intuito de melhorar um ou mais processos de negócio
e tornar a organização mais eficaz e eficiente, dando-lhe,
portanto, os ingredientes básicos para ser diferenciada entre
a concorrência.
Referências
Livro “Good to Great: Why some companies make the leap... and others don’t” -
ISSBN 9780066620992
http://amzn.to/48NA0
Livro“Business Process Management:Practical guidelines to successful implementations”
– ISSBN 9780750686563
http://amzn.to/huu5qb
Link para o site oficial da notação BPMN
http://www.bpmn.org/
Blog “O BPM que faço hoje... é realmente BPM?”
http://bit.ly/hwUCXo
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Modelagem de processos de negócio com BPMN
e Intalio
Conhecendo os Bastidores
Simone Dornelas Costa
sidornellas@gmail.com
Mestranda em Ciência da Computação pela
Universidade Federal de Viçosa (UFV). Bacharel
em Ciência da Computação pelas Faculdades
Integradas de Caratinga – FIC. Experiência em
desenvolvimento de software e sistemas Web,
atuando a mais de 4 anos nessa área. Áreas de
Interesse: Engenharia de Software, Processos
de Desenvolvimento de Software, Modelagem
de Processos, Dinâmica de Sistemas.
Glauber Costa
glaubercosta@gmail.com
Possui graduação em Ciência da Computação
– Faculdades Integradas de Caratinga e Pós
Graduação em Distribuição de Serviços Com-
putacionais: Redes e E-commerce. Atualmente
é analista de sistemas e professor universitário
- Faculdades Integradas de Caratinga, atuando
principalmente em disciplinas voltadas para
desenvolvimento de sistemas, engenharia de
software, projeto e análise de banco de dados
e Pesquisa Operacional. Tem experiência na
área de Ciência da Computação, com ênfase
em Banco de Dados e Projetos em análise
de aplicativos em ambiente Web, atuando
principalmente nos seguintes temas: gestão
acadêmica, gestão de acervo bibliográfico, data
warehouse, data mining e banco de dados geo-
gráficos. Atualmente está cursando o mestrado
em Ciência da Computação na Universidade
Federal de Viçosa.
José Luis Braga
zeluis@dpi.ufv.br
Pós-doutoramento em Tecnologias da Infor-
mação na University of Florida. Doutor em
Informática - Departamento de Informática
da PUC-Rio. Mestre em Ciências da Computa-
ção - Departamento de Ciência da Computação
da UFMG. Atualmente é Professor Titular do
Departamento de Informática do Centro de
Ciências Exatas e Tecnológicas da Universidade
Federal de Viçosa-MG. Atua na área de Ciência
da Computação, com ênfase em Engenharia
de Software e Sistemas de Informação. Áreas
de Interesse: Qualidade de Software com Foco
em Processos, Engenharia de Software Experi-
mental, Engenharia de Software Apoiada por
Ontologias, Engenharia de Software Baseada
em Agentes, Sistemas de Apoio à Decisão.
A
s abstrações são uma ferramenta
valiosíssima no tratamento de
problemas mais complexos por
focar apenas nas partes essenciais, dei-
xando em segundo plano detalhes que
não influenciam de forma determinante
na compreensão do problema. Os mode-
los gerados a partir dessas abstrações
estão presentes em diversos aspectos da
vida humana, indo dos mais corriquei-
ros, como uma receita culinária, aos mais
Edição 40 - Engenharia de Software Magazine
De que se trata o artigo?
A modelagem de processos tem por objetivo me-
lhorar a visão que a empresa tem de seus processos
a fim de identificar pontos importantes que se tor-
nam base para a tomada de decisões mais precisas e
seguras, além de identificar gargalos e poder otimi-
zar todo o processo.
Em que situação o tema é útil?
Neste sentido, este artigo relata como a mode-
lagem de processos pode ser benéfica para as
empresas exemplificando com a modelagem
do caso da Ford realizada no Intalio, o qual uti-
liza a notação BPMN.
Resumo:
O sucesso de qualquer tipo de empreendimento
está fortemente ligado ao conhecimento que
seus gestores têm de seus processos e as inte-
rações entre eles. Nesse sentido, técnicas como
o BPM e sua notação gráfica de modelagem, o
BPMN, são ferramentas essenciais para a análise
e projeto de processos de negócios. Este traba-
lho apresenta conceitos básicos de BPM/BPMN,
demonstra o clássico trabalho de Hammer sobre
a reengenharia de processos na Ford Motors e a
modelagem do mesmo usando o Intalio.
31
complexos projetos de engenharia. Um modelo é definido por
Kruchten (2003) como “uma simplificação da realidade que nos
ajuda a dominar um sistema grande e complexo que não pode
ser facilmente compreendido em sua totalidade”.
No mundo dos negócios, o emprego de técnicas de modela-
gem de processo de negócios contribui de maneira decisiva
para a obtenção de melhorias em processos já estabelecidos ou
no planejamento de novos processos. Um processo de negócios
seria “uma coleção de atividades que recebe uma ou mais en-
tradas e cria uma saída de valor para o cliente. Um processo
de negócios tem um objetivo e é afetado por eventos que ocor-
rem no mundo externo e em outros processos”. Mas Ko (2009)
sugere também que se visualizem os processos de negócios
como tarefas ordenadas de forma sistemática no tempo e no
espaço, ao invés de apenas uma coleção de atividades. Desta
forma poder-se-ia identificar mais objetivamente as tarefas
que necessitam de melhorias no sentido de se obter melhor
desempenho. Uma das técnicas com maior alcance neste setor
é o BPM (Business Process Management).
BPM – Business Process Management
O gerenciamento de processo de negócios (BPM) foi defi-
nido por Van der Aals como sendo uma “forma de apoiar
processos de negócios usando métodos, técnicas e software
para contratar, controlar e analisar processos operacionais
envolvendo pessoas, organizações, aplicações, documentos
e outras fontes de informação”. Sistemas computacionais que
dão apoio informatizado ao BPM são conhecidos como BPMS
(Business Process Management Systems).
A maneira mais didática de se contextualizar o BPM é por meio
da análise de ciclo de vida básico proposto por Van der Aals:
• Projeto do processo: onde o processo é modelado por meio
de um BPMS;
• Configuração do sistema: ocorre a configuração do BPMS e in-
fraestrutura subjacente (papéis dos usuários, organizações, etc);
• Adoção do processo: o modelo é gerado eletronicamente e
implantado em uma máquina de BPMS que permita executar
o modelo;
• Diagnóstico: monitoramento dos resultados da análise para
identificação de possíveis gargalos e outras consequências da
simulação.
Os benefícios obtidos por meio da utilização do BPM são
grandes. Segundo Ko (2009), torna-se possível aumentar a visibi-
lidade e conhecimento das atividades da organização, aumenta
a habilidade para identificar gargalos, aumenta em potencial
a identificação das áreas para otimização, reduz o tempo de
execução de tarefas, melhora a definição de direitos e papéis na
organização e é uma boa ferramenta para prevenção de fraudes,
auditoria e avaliação do cumprimento da regulamentação.
BPMN – Business Process Model and Notation
A BPMN (Nota do Devman 1) é uma notação gráfica de-
senvolvida pela OMG (Object Management Group) com dois
objetivos principais:
32 Engenharia de Software Magazine - Modelagem de processos de negócio com BPMN e Intalio
• Fornecer uma notação padronizada para projetos em BPM,
compreensível para usuários da área de negócios, para de-
senvolvedores técnicos responsáveis pela implementação e
execução dos processos e para gerentes de processo;
• Assegurar que linguagens derivadas da XML, projetadas
para representação de processos de negócio pudessem ser
vistas como uma notação orientada a negócios.
Uma das ideias iniciais para a criação era consolidar os pontos
positivos dessas ferramentas em uma única ferramenta, cha-
mada inicialmente por Business Process Modelling Notation até
sua versão 1.2. Atualmente, tal notação encontra-se na versão
2.0, à qual foram agregadas várias características novas, pas-
sando a ser chamada de Business Process Model and Notation.
Outro ponto positivo em favor da criação do padrão foi a pos-
sibilidade de se aproveitar toda sua riqueza para que pudesse
ser mapeado para linguagens que permitissem a execução do
processo representado por um diagrama. Linguagens como
BPEL (Business Process Execution Language) e XPDL (XML
Process Definition Language) tornam possível a execução do
processo modelado em workflow engine, que são aplicativos
que gerenciam e executam processos modelados.
Nota do DevMan 1
BPMN
Notação e modelo de processo de negócios. A versão 2.0 recebeu o nome de Bu-
siness Process Model and Notation.
Elementos BPMN
O BPMN define um diagrama de processo de negócios (BPD
– Business Process Diagram) baseado em técnicas de gráficos de
fluxo projetadas para criar modelos gráficos para operações de
processo de negócios. O BPD é composto por quatro categorias
básicas de elementos, sendo:
1) Objetos de fluxo: são os elementos centrais da notação;
2) Objetos de conexão: usados para conectar objetos de fluxo
para criar a estrutura básica do processo;
3) Raias: mecanismo usado para organizar atividades em ca-
tegorias visuais separadas com objetivo de ilustrar diferentes
capacidades funcionais ou responsabilidades;
4) Artefatos: utilizados para dar extensibilidade à linguagem
ao permitir a geração de novos elementos contextualizados a
uma modelagem específica. Atualmente existem três artefatos
básicos pré-definidos.
As Tabelas 1 a 4 apresentam os elementos de cada categoria.
Intalio|BPMS
O Intalio|BPMS é uma suíte de sistemas voltados para o
desenvolvimento completo do ciclo de vida do BPM. Desen-
volvido pela Intalio (www.intalio.com) e disponibilizado
 proce s s o

Nome Notação Descrição

Eventos Esses elementos afetam o fluxo do processo e em geral possuem uma causa (trigger) ou um impacto.

Atividades Termo genérico para uma tarefa a ser executada.

Gateways (portais, em tradução livre) Usado para controlar as convergências ou divergências da sequência do fluxo.

Tabela 1. Objetos de fluxo

Nome Notação Descrição

Fluxo de sequência Usada para indicar a ordem em que uma atividade será executada.

Fluxo de Mensagem Usada para mostrar o fluxo de mensagem entre dois processos participantes separados.

Associação Usado para associar dados, textos e outros artefatos com os objetos de fluxo.

Tabela 2. Objetos de conexão

Nome Notação Descrição

Pool Representa um participante no processo.

Lane Subpartição de pool. Usadas para categorizar e organizar atividades.

Tabela 3. Raias

Nome Notação Descrição

Objeto de dados Mecanismo para mostrar como os dados são produzidos ou requisitados pelas atividades.

Grupo Pode ser usado para documentação ou para análise. Não afeta a sequência de fluxo.

Anotação Fornecem ao usuário um mecanismo para informação textual ao leitor do diagrama.

Tabela 4. Artefatos

Edição 40 - Engenharia de Software Magazine 33

nas versões: community edition, total-
mente livre de encargos e com suporte Nota do DevMan 2
por meio de uma comunidade (www.
intalio.com/community) bastante ati-
va; e enterprise edition, com diversos Eclipse
componentes oferecidos apenas nesta O Eclipse é um ambiente integrado de desenvolvimento (IDE - Integrated Development Enviroment) (O.T. Interna-
versão. tional, 2003). É possível estender o ambiente de desenvolvimento do Eclipse para que atenda a diversas linguagens
O Intalio|Designer é uma ferramenta diferentes (JAVA, C, C++, PHP, entre outras) por meio do desenvolvimento de plugins para a plataforma.
que compõe o Intalio|BPMS e tem por
objetivo permitir ao usuário a criação
de diagramas de processo de negócios
e outras tarefas de monitoramento e
gestão de processo de negócios.
A ferramenta é oferecida em duas
versões:
• Comunitária: sem custos, mas com nú-
mero limitado de recursos. As limitações
não impedem a construção de modelos
funcionais;
• Enterprise: com acesso a todos os re-
cursos do sistema e com custo de licença
de aproximadamente U$9.500 ao ano.

O Intalio|Designer foi desenvolvido a

partir de uma série de plug-ins para Eclip-
se (ler Nota 2), o que possibilita o sistema
rodar em qualquer sistema operacional
suportado por essa plataforma. Outros
módulos podem ser instalados para con-
trole, gerenciamento de tarefas, acesso a
banco de dados e suporte a linguagens de
programação, como Java, PHP e C++.
Outra ferramenta que compõe o
Intalio|BPMS é o Intalio|Server que
tem como função executar códigos em
BPEL gerados a partir do diagrama de
processos gerado pelo Intalio|Designer.
As duas ferramentas em conjunto pos-
sibilitam o projeto, implementação e
execução de processos de negócio com
recursos avançados, como geração de
formulários Web e conexão com banco
de dados.
A instalação das ferramentas é bastante
simples, podendo os arquivos de instala-
ção da versão comunitária serem obtidos
a partir do site do Intalio (http://www.
intalio.com/downloads).
Exemplo de modelagem: o caso Ford
Para ilustrar o alcance da metodologia
BPM e da notação BPMN, bem como
o apoio tecnológico oferecido pelo
Intalio|Designer, a próxima seção apre-
senta o processo de reengenharia pelo
Figura 1. O processo de compras antes de passar pela reengenharia
qual passou alguns dos departamentos
da montadora de automóveis americana
Ford Motors.
O caso é apresentado em Hammer (1990)
e é um exemplo bem claro dos bons re-
sultados que se pode alcançar a partir da
abstração de determinado problema e sua
modelagem. As Figuras 1 e 2 auxiliam na
melhor compreensão do caso.
Originalmente o processo de aquisi-
ção de mercadorias ocorria da seguinte
forma:
“Quando o departamento de compras
da Ford gerava uma nota de compra,
ela era enviada para o departamento
de contas a pagar. Posteriormente,
quando o controle de material recebia
o produto, uma cópia do documen-
to de recebimento era enviada para
o departamento de contas a pagar.
Enquanto isso, o vendedor enviava
uma fatura para o departamento de
contas a pagar. Ficava por conta do
departamento de contas a pagar juntar
a ordem de compra, o documento de
recebimento e a fatura. Se conseguisse
juntá-los, o departamento efetuava o
pagamento...”.
Esse processo era ineficiente, pois
muitas vezes sumiam documentos, não
sendo possível juntá-los. Percebendo
essa falha do processo, a Ford decidiu
por modelar seu processo e eliminar as
notas que eram enviadas para o depar-
tamento de compras. Assim o processo
passou por uma reengenharia obtendo-
se o seguinte resultado descrito a seguir,
e apresentado na Figura 2.
“Agora, quando o departamento de
compras inicia uma ordem, a informa-
ção é lançada em um banco de dados
online. A nota de compra não era reme-
tida a ninguém. Quando os produtos
chegavam na recepção, o funcionário
que a recebia acessava a base de dados
para verificar se correspondia a uma
ordem de compra pendente. Em caso
positivo, aceitava-o e entrava com a
informação no sistema do computador
(se o recebedor não puder detectar a
entrada para o respectivo bem, simples-
mente devolvia a compra)”.

34 Engenharia de Software Magazine - Modelagem de processos de negócio com BPMN e Intalio


Figura 2. O processo de compras após passar pela reengenharia
Figura 4. Adicionar Projeto do Processo de Negócio Intalio|BPMS
Representação usando o Intalio
Para iniciar a modelagem do processo
do Caso Ford com Intalio, deve-se ter
o Intalio|Designer e o Intalio|BPMS
devidamente instalados. Consulte o
Help (http://community.intalio.com/
getting-started/getting-started-with-
intalio-bpms-server.html) e o Foru-
ms (http://community.intalio.com/
forums/installation/steps-to-install-
intalio-server/view.html) do Intalio
para entender melhor como instalar o
Intalio|BPMS.
Para modelar o processo do caso Ford
foram utilizados alguns elementos da
notação BPMN 1.2, e alguns recursos
do Intalio|Designer (versão 6.0.3). Os
elementos da notação BPMN utilizados
foram basicamente: pools, tasks, ga-
teways (Exclusive Data-based gateway
e Parallel gateway), Flow Connector,
Message Connection e Event (Empty End
Event), conforme a Figura 3.
Os recursos do Intalio|Designer uti-
lizados foram: formulários, tratamento
dos dados passados entre formulários,
Edição 40 - Engenharia de Software Magazine
proce s s o
Figura 3. Elementos BPMN utilizados
tratamento das decisões dos gateways
e tratamento de como cada formulário
deve ser usado na modelagem do pro-
cesso da Ford.
Neste caso em específico, os formu-
lários foram usados para: (1) pessoas/
usuários iniciarem uma atividade do
processo (initProcess); (2) atribuir uma
atividade para uma pessoa/usuário (cre-
ate and complete); e (3) notificar (notify).
Existe outra forma de usar o formulário,
mas como não foi utilizada nessa mode-
lagem, não será abordada.
Neste artigo a modelagem do processo
da Ford é apresentada em cinco subse-
ções para facilitar o entendimento:
• Criando o Projeto do Processo de Ne-
gócio Intalio|BPMS;
• Criando de Formulários;
• Iniciando a Modelagem: Tratando o uso
dos Formulários;
• Tratando a Ligação entre as variáveis
dos Formulários;
• Tratando Operação de Gateways.
Criando o Projeto do Processo de
Negócio Intalio|BPMS
Com o Intalio|Designer aberto, os
passos abaixo guiam o usuário para a
criação de um projeto.
Passo 1: Deve-se clicar com o botão di-
reito no espaço da aba “Explorar Proces-
so” e selecionar a opção “Nova - Projeto
do Processo de Negócio Intalio|BPMS”,
conforme Figura 4.
Passo 2: Uma nova janela é exibida,
devendo-se dar um nome para o projeto.
Neste caso, o projeto foi nomeado de
“ProjetoCasoFord”, após isso deve-se cli-
car em “Concluir”, conforme Figura 5.
Passo 3: Para criar qualquer recurso a ser
adicionado ao projeto deve-se clicar com
o botão direito em cima do projeto e sele-
cionar a opção “Nova - recurso desejado”.
Para criar o diagrama deve-se selecionar
a opção “Nova - Diagrama do Processo
35
Figura 5. Nomeando o Projeto.
de Negócio”, conforme Figura 6. Esse
diagrama é onde, de fato, a modelagem
do processo é realizada
Passo 4: Uma nova janela é exibida,
devendo-se dar um nome para o recur-
so adicionado ao projeto. Nesse caso,
o diagrama foi nomeado de “CasoFor-
dDiagram”, após isso deve-se clicar em
“Concluir”, conforme Figura 7.
Criando Formulários
A criação de formulários é realizada
da mesma forma, selecionando a opção
“Nova - Formulário do Workflow”, e
nomeando o formulário para “Compra-
Form.xform”.
Os passos abaixo guiam o usuário para
a criação/edição de formulários.
Passo 1: Para melhor visualizar os
elementos a serem inseridos no formu-
lário deve-se selecionar a Perspectiva
“Intalio|BPMS Editor de Formulário”,
conforme Figura 8.
Passo 2: Para acrescentar os elementos
disponíveis no Intalio|Designer para a
criação do formulário, basta clicar no
elemento e arrastá-lo para a área qua-
driculada. A Figura 9 já possui alguns
elementos, os quais compõem o formu-
lário “CompraForm.xform”. Para editar
tais elementos deve-se clicar no elemento
desejado e setar as configurações na aba
propriedaes.
Para melhor entender as propriedades
configuradas para este formulário, abai-
xo são explicadas algumas dessas pro-
priedades, e os valores atribuídos a elas.
A Tabela 5 descreve as propriedades e
valores atribuídos ao campo 3 – Data da
Compra do formulário.
36 Engenharia de Software Magazine - Modelagem de processos de negócio com BPMN e Intalio
Figura 6. Adicionar Diagrama do Processo de Negócio
Iniciando a Modelagem: Tratando
o uso dos Formulários
A parte em destaque da Figura 10 re-
presenta uma parte do processo do Caso
Ford, o qual é explicado neste artigo e
abrange todos os recursos utilizados
durante toda a modelagem, tornando
desnecessária a explicação do restante da
modelagem do processo da Ford.
Algumas observações são necessárias
antes de iniciar o tratamento da utilização
do formulário na modelagem do processo.
Sendo assim: (1) parte-se do pressuposto
que já se têm criadas as pools que são
abrangidas nesta parte do processo, sendo
Figura 7. Nomeando o Diagrama
elas: “process” (a qual representa o pro-
cesso a ser executado); “purchasing” (que
representa o departamento de compras); e
“vendor” (que representa o fornecedor). As
duas últimas devem ser setadas como não
executáveis, pois representam usuários
interagindo no processo; (2) O processo
modelado no Intalio|Designer se torna
executável no servidor do Intalio, portanto Figura 8. Selecionar a Perspectiva “Intalio|BPMS
Editor de Formulário”
a parte do processo que é executável deve
ser criada em uma pool executável, a qual
no caso da Ford é a pool “process”; (3) O Os passos abaixo guiam o usuário para
processo da Ford é iniciado pelo Depar- dar início à modelagem do processo da
tamento de Compras, o qual realiza uma Ford a partir das observações acima.
compra e, por meio desta, um pedido de Passo 1: Como já se sabe, o departa-
mercadoria é enviado ao fornecedor. O mento de compras (purchasing) é o
fornecedor então deve definir se o pedido responsável pelo início do processo e o
pode ou não ser concluído. Enquanto isso, formulário “Compraform.xform” repre-
o fluxo do processo é “pausado” só dan- senta a atividade de realizar compras.
do continuidade após o posicionamento Sendo assim, tal formulário foi selecio-
do fornecedor com relação ao pedido de nado e arrastado até a pool “purchasing”
mercadoria solicitado. selecionando a opção “Use Compraform
 proce s s o

for People Initiating Process Activity
(initProcess)”, conforme Figura 11. Essa
opção define que o Departamento de
Compras (purchasing), que é um usuário
interagindo no sistema, inicie o processo
por meio do formulário.
É importante ressaltar que o formulário
a ser arrastado para a pool é o formulário
Figura 9. Propriedades do campo do formulário
Figura 10. Processo caso Ford modelado no Intalio
que termina com “.xform”, ou seja,
“Compraform.xform”, e não “Compra-
form.xform.xsd”.
Passo 2: Conectar o formulário da pool
“purchasing” com a atividade (task)
“expedir compra” da pool “process”.
Para realizar a conexão de atividades
entre pools diferentes, deve-se utilizar
o elemento “Message Connection”. De-
vido ao formulário nessa conexão ser o
responsável pelo início do processo, essa
conexão deve ser feita do formulário
para a atividade, ou seja, a “Message
Connection” deve sair do formulário
para a atividade “Expedir Compra”, e só
depois o inverso, conforme Figura 12.
Passo 3: Setar o participante do proces-
so. Para a pool “purchasing”, o usuário
é o “purchasing-department” que é per-
tencente a “ford” e tem como papel “pur-
chasing-dep”. Para isso deve-se: clicar
na pool; clicar no ícone “Propriedades”;
clicar na aba “Workflow”; preencher os
campos “User(s)” e “Role(s)”, conforme
Figura 12. Esse passo deve ser realizado
em todas as pools representadas por
usuários no proCesso.
Após setar o participante, a pool passa
a apresentar um ícone com um “boneco”.
Esse usuário é utilizado posteriormente
durante a execução do processo modela-
do para logar no sistema.
Passo 4: O formulário “PedidoMerca-
doriaform.xform” foi criado e tem como
objetivo ser uma tarefa para o fornecedor,
representando a parte de decisão a ser
tomada quando chega um pedido de mer-
cadoria para o mesmo, fazendo com que o
fluxo do processo espere por sua decisão.
Para isso, o formulário foi adicionado na
pool do “vendor” selecionando a opção
“Use PedidoMercadoriaform for People
Activity (create and complete)”, a qual
representa essa necessidade.
Como a chamada para esse formulário
parte do processo, após este ter recebido
o pedido de compra, a “Message Con-
nection” deve sair da atividade da pool
“process” para o formulário adicionado
na pool “vendor”. Observe a Figura 13
para entender como deve ser realizado
esse relacionamento.

Propriedade Valor (atribuído) Descrição

Label de Controle 3 - Data da Compra Nome apresentado no formulário.
Nome Data_da_Compra Nome da variável atribuída a esse campo.
Entrada/Saída in-out Permite o campo ser preenchido e lido.
Requerido true() Torna o campo obrigatório, permitindo o envio do formulário somente após ter preenchido tal campo.
Na propriedade “Somente Leitura”, quando atribuído o valor “true()”, mesmo que a propriedade “Entrada/Saída” esteja setada com o valor
Somente leitura
“in-out”, o campo só estará disponível para leitura, ou seja, não poderá ser modificado.
Tabela 5. Propriedades e valores do campo do formulário

Edição 40 - Engenharia de Software Magazine 37

Figura 11. Opções de uso de formulário
Figura 12. Atribuindo participante a uma pool
Para acrescentar um formulário como sendo uma notificação
para o usuário, deve-se selecionar a opção “Use nomedofor-
mulario for Notification (notify)”. O tratamento das variáveis
dessa opção de formulário é tratado da mesma forma que
explicado anteriormente.
Passo 5: Atribuir um nome para a tarefa do usuário “vendor”,
criada no passo anterior. Para isso, deve-se clicar em: “Pedi-
doMercadoriaform-create”; depois no ícone “Propriedades”;
depois em “Workflow”; e atribuir um nome para “Workflow”,
nesse caso foi atribuído “Pedido de Mercadoria”, conforme
Figura 13.
Tratando a Ligação entre as variáveis dos Formulários
Passo 1: Tratar as variáveis passadas entre os formulários
“Compraform.xform” e “PedidoMercadoria.xform”. Para
melhor entender como deve funcionar esse relacionamento,
observe a Figura 14.
Nota-se que os campos 1, 2, 3 e 4 do formulário “PedidoMerca-
doriaform.xform” devem ser setados como “Somente Leitura”,
pois eles são “preenchidos” pela ligação com os campos 1, 2 e
3 do formulário “Compraform.xform”.
Passo 2: Para fazer essa ligação deve-se primeiramente clicar
em “fazer pedido”; depois em “Mapeamento”, assim a aba
38 Engenharia de Software Magazine - Modelagem de processos de negócio com BPMN e Intalio
Figura 13. Atribuir nome para tarefas de usuários
Figura 14. Formulários
“Mapeamento” é exibida. Agora é só ligar as variáveis da saída
(output) do formulário “Compraform” às variáveis de entrada
(input) do formulário “PedidoMercadoriaform”,conforme a
Figura 15.
Assim, quando o processo for executado, o formulário “Pedi-
doMercadoriaform” será exibido com esses campos (1, 2, 3 e 4)
já preenchidos e disponíveis apenas para visualizar (leitura),
enquanto os outros campos deverão ser preenchidos.
Tratando Operação de Gateways
Esse item trata da utilização de gateways na modelagem do
processo. O primeiro gateway a ser utilizado é o “Exclusive
Data-based gateway”, o qual possui a função de: (1) verificar
uma operação, neste caso, se o pedido foi concluído ou não; (2)
dar duas opções para continuar o fluxo do processo modelado;
(3) excluir uma das duas opções baseado no dado/valor rece-
bido. Os dois caminhos são: (1) pedido concluído (dá continui-
dade ao fluxo do processo); e (2) pedido não concluído, sendo
o caminho default (notifica ao departamento de compras que
o pedido da mercadoria não foi concluído, por algum motivo
do fornecedor, e finaliza o processo).
O caminho (1), que dá continuidade ao fluxo do processo,
foi conectado ao “Parallel gateway”, permite duas ou mais
atividades serem realizadas ao mesmo tempo. Sendo elas:
(1) notificar ao departamento de compras que o pedido foi
realizado com sucesso; (2) aguardar o fornecedor enviar a
mercadoria. Para este gateway não há a necessidade de tratar
nenhuma operação.
 proce s s o

Os passos abaixo guiam o usuário para Comentários Finais auxilia na detecção de gargalo no fluxo de
atribuir uma operação para o “Exclusive O fluxo de informações dentro de uma informações e permite aos tomadores de
Data-based Gateway” baseado nas des- empresa, ou de algum de seus setores, a decisão procurar formas de contorná-los.
crições desenvolvidas acima. iteração entre estas informações e seus Além da vantagem gerencial que esta suíte
Passo 1: Atribuir o tipo de condição responsáveis são vitais para seu bom ge- de ferramentas propicia, outras caracterís-
“default” para o caminho 2. Para atri- renciamento. Obter uma forma de capturar ticas fazem dela uma boa solução a quem
buir essa condição deve-se clicar com toda esta rede de informações não é tarefa busca ter uma visão ampla sobre os pro-
o botão direito no “Flow Connector” trivial, mas o uso de técnicas e ferramentas cessos em seus empreendimentos:
entre o “Exclusive Data-based gateway” adequadas trará, ao longo do tempo, retor- • A aderência a notação BPMN, que
e a atividade “notificar” e selecionar no na forma de processos otimizados. garante uma comunicação sem ruídos
“Condition Type - Defaut”, conforme • O Intalio|BPMS fornece apoio informa- entre os diversos participantes do pro-
Figura 16. tizado à modelagem de processos, o que cesso de tomada de decisão;
Após atribuir tal condição para o cami-
nho (2), este passa a apresentar um risco
indicando que ele é o caminho default,
conforme a Figura 17.
Passo 2: Atribuir condição/operação do
“Exclusive Data-based gateway”. Para atri-
buir uma condição/operação ao gateway,
primeiramente deve-se clicar no gateway e
depois no ícone “Mapeamento”. Para criar
uma operação, deve-se clicar no botão
“Criar uma nova operação” (botão qua-
drado vermelho) e clicar na área central.
Precisam-se criar duas operações, sendo
elas: (1) o símbolo de igual (=); (2) o valor
Figura 15. Tratando a ligação entre as variáveis dos formulários
“true”, conforme Figura 17.
Após isso, deve-se realizar a ligação
da variável do formulário que é tes-
tada pela condição do gateway, nesse
caso é a variável “Pedido_Concluido”
(caso não se lembre dessa variável é
sugerido que visualize o campo 5 do
formulário “PedidoMercadoriaform.
xform”, Figura 11). Este campo pos-
sui duas opções: sim (true); ou não
(false). Esses valores são passados do
formulário para o gateway quando se
atribui tal variável para ser verificada
na condição do gateway, conforme Figura 16. Atribuir condição default para caminho 2
Figura 17.
Nota-se na Figura 17 como é feita a
ligação, saindo da variável do formulá-
rio “Pedido_Concluido” e “true” ambos
ligando à operação (=) e saindo uma li-
gação dessa operação para a “condition”.
Sendo assim, a condição do gatway foi
tratada com sucesso.
Como o restante do processo utiliza
os recursos que já foram explicados
para a modelagem até este ponto, não se
faz necessária a explicação de como foi
modelado o restante do processo. Para
visualizar todo o processo modelado
basta visualizar a Figura 10. Figura 17. Tratando operação do Exclusive Data-based Gateway

Edição 40 - Engenharia de Software Magazine 39

• A possibilidade de integrar o processo modelado com outros
softwares da empresa a partir do uso de webservices;
• O uso de interfaces gráficas bastante intuitivas que garante
a geração do modelo de processo e sua execução sem a neces-
sidade de se trabalhar diretamente com o código;
Uma curva de aprendizado adequada a partir do momento
que se domine a notação BPMN.
Referências
P. Kruchten, The Rational Unified Process: An Introduction, New York, New York,
USA: 2003.
R.K.L. Ko, “A Computer Scientist’s Introductory Guide to Business Process
Management (BPM),” Crossroads, vol. 15, 2009, pp. 11-18.
R.K.L. Ko, S.S.G. Lee, and E.W. Lee, “Business process management (BPM) standards:
a survey,” Business Process Management Journal, vol. 15, 2009, pp. 744-791.

Para melhor ilustrar o trabalho realizado durante este arti-
go, foi disponibilizado o projeto da modelagem do processo
da Ford, como também o vídeo da modelagem explicada
neste artigo e a parte da simulação deste processo no site
http://www.sidornellas/mestrado/modelagem-de-processo.
OMG, “Business Process Model and Notation (BPMN),” Business, 2011.
S.A. White, “XPDL and BPMN” Management, 2003, pp. 221-238.
S.A. White, “Introduction to BPMN” BPTrends, 2004, pp. 1-11.
O.T. International, “Eclipse Platform Technical Overview,” Technology, vol. 2003,
2003, pp. 1-20.

Dê seu feedback sobre esta edição! Feedback M. Hammer, “Reengineering Work: Don ’t Automate , Obliterate,” Harvard Business
eu
Review, vol. 68, 1990, pp. 104-112.
s
Dê

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback

40 Engenharia de Software Magazine - Modelagem de processos de negócio com BPMN e Intalio

Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Boas práticas para escrita de métodos, funções e
procedimentos – Parte 2
Código Limpo
Jacimar Fernandes Tavares
jacimar.tavares@studentpartners.com.br
Bacharel em Ciência da Computação FAGOC
- Faculdade Governador Ozanam Coelho,
Microsoft Student Partners.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
É Doutor e Mestre em Engenharia de Sis-
temas e Computação pela COPPE/UFRJ,
Especialista em Métodos Estatísticos Com-
putacionais e Bacharel em Informática pela
UFJF, professor do curso de Bacharelado em
Ciência da Computação da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informação do Centro de Ensino Superior
de Juiz de Fora e da Faculdade Metodista
Granbery, Analista de Sistemas da Prefeitu-
ra de Juiz de Fora, Editor da Engenharia de
Software Magazine.
De que se trata o artigo?
Aborda o tema Código Limpo com o objetivo de mos-
trar como o desenvolvedor pode usá-lo para melhorar
a qualidade do código fonte de suas aplicações. A dis-
cussão deste tópico é interessante uma vez que provê
conhecimento ao desenvolvedor sobre como trans-
formar códigos considerados ruins em bons códigos
demonstrando através de exemplos práticos as teorias
aqui abordadas.
Em que situação o tema é útil?
O tema se torna fundamental para desenvolvedores
que buscam cada vez mais melhorar suas aplicações
ao focar em qualidade de código. Esta tarefa será
possível graças ao conhecimento adquirido sobre
limpeza de código.
A
escrita de código de forma
sequencial, isto é, código que
é executado de cima para bai-
xo, da primeira linha até a última,
restringe uma ação a ser executada
somente depois da sua anterior, não
considerando estruturas condicionais
que fornecem mais de um caminho.
As funções, métodos e procedimentos
permitem que o código seja organizado
Edição 40 - Engenharia de Software Magazine
Resumo:
Esta série de artigos discutirá os aspectos que per-
meiam o assunto Código Limpo, seguindo a linha
de raciocínio que propõe um aumento na qualidade
do código das aplicações existentes ou proporcio-
nar conhecimento de como criar projetos de código
melhores quando se está iniciando um novo pro-
jeto. Neste contexto, código limpo se refere a um
conjunto de características desejáveis de serem
encontradas no código de nossa aplicação. Algu-
mas dessas características são: ter um código que
atenda os requisitos de eficiência, lógica do negó-
cio bem modelada e definida em forma de código
fonte, mecanismos de tratamento de erro bem de-
finidos e código que não dê margem à necessidade
da realização de novas otimizações.
em sequência, mas também em blocos,
o que traz como benefício a organização
do código em estruturas que podem
ser executadas em qualquer ponto de
uma classe ou arquivo de código fonte
quando invocados.
Media nte a i mpor tâ nc ia das es-
truturas como métodos, funções e
procedimentos em uma aplicação, é
necessário que eles sejam escritos de
41
forma limpa e mantidos limpos durante todo o ciclo de
vida do software.
Todas as teorias que serão abordadas neste artigo contribui-
rão para uma melhora efetiva na qualidade e legibilidade do
código fonte, mas além das técnicas sobre código limpo, outros
recursos se fazem importantes, que são as técnicas de refatora-
ção de código. As teorias sobre código limpo não prevêem uma
forma controlada de modificar o código dos métodos, funções
e procedimentos como as técnicas de refatoração de código
(FOWLER, 2004), portanto a sugestão para que o sucesso seja
obtido nessa tarefa é a utilização de refatorações em alguns
casos específicos. Quando necessárias, elas serão destacadas,
bem como onde aprender mais sobre elas.
Como dito anteriormente, os métodos, funções e procedi-
mentos são estruturas de dados que permitem que tarefas
sejam organizadas em blocos e executadas quando necessário.
É fato também que todo desenvolvedor conhece os tipos de
funções, métodos e procedimentos existentes que são, no caso
dos métodos, estruturas que possuem um moderador de acesso
(privado, público e protegido, entre outros), um tipo de dados
de retorno (inteiro, string, void, entre outros), um nome para o
método e uma lista de parâmetros, que pode ser vazia. Alguns
métodos possuem um retorno de alguma informação, e outros
não, como os que utilizam void como tipo de retorno.
Cada um dos tipos de métodos citados aqui, e também as
funções e procedimentos, possuem suas particularidades.
Nesse sentido, o objetivo deste artigo é apresentar as teorias
sobre código limpo, relativo a funções, que proporcionarão
ao desenvolvedor a capacidade de criar estruturas limpas. Os
assuntos que serão abordados na seção Funções permitirão ao
desenvolvedor criar ou modificar métodos, procedimentos e
funções utilizando nomes significativos, isto é, que deixem
clara a intenção da estrutura. Outros pontos que receberão
destaque neste artigo são referentes ao tamanho das estrutu-
ras, ao corpo dos métodos e aos seus objetivos. Além disso,
serão abordadas em detalhes todas as teorias que envolvem a
definição de bons parâmetros e os riscos das muitas respon-
sabilidades em uma única estrutura.
Funções
Nesta seção são abordadas teorias que serão utilizadas para
que o desenvolvedor possa melhorar o código fonte de suas
funções, métodos, procedimentos e estruturas com propósito
semelhantes. O objetivo desta seção é mostrar as caracterís-
ticas desejáveis na escrita de funções para que elas possam
ser consideradas limpas. Aqui o nome método será adotado
para representar não só os métodos propriamente ditos, mas
também as demais estruturas com propósito semelhante, como
funções e procedimentos.
O tamanho dos métodos
O trabalho de escrever um método deve ser precedido do
trabalho de planejar qual ação tal método vai executar em
seu corpo. Em seguida, a escrita do método deve conter a me-
nor quantidade de linhas possível para definir seu objetivo,
42 Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 2
cuidando para que o método seja legível e de fácil entendi-
mento. É recomendado que cada linha do método contenha
no máximo 150 caracteres, e que não necessite ser rolada para
o lado para ser lida, isto é, utilizar a barra de rolagem da IDE
para visualizá-la por completo. Caso 150 caracteres forme uma
linha que necessite mover a barra de rolagem da IDE para ser
lida, então a linha deve ser menor que 150 caracteres. Também
é aconselhável que um método não possua mais de 20 linhas,
para que possa ser considerado pequeno.
É importante que, caso o método escrito possua mais de
20 linhas, o desenvolvedor analise-o para se certificar se há
a possibilidade de dividi-lo em dois ou mais métodos. Essa
tarefa pode ser auxiliada por uma técnica de refatoração de
código chamada Extrair Método (FOWLER, 2004) (ver Nota
do DevMan 1).
Nota do DevMan 1
Refatoração Extrair Método.
A técnica de refatoração Extrair Método foi apresentada na edição de número 29 da
Engenharia de Software Magazine.
O corpo dos métodos
Entende-se por corpo do método todo código contido dentro
do método. Existem algumas regras para a definição do corpo.
Uma delas deve ser aplicada caso haja estruturas de seleção e
repetição no corpo de um método. A Listagem 1 ajudará no
entendimento.
Listagem 1. Método calcularNovoValorParcela
01. public Decimal calcularNovoValorParcela(DateTime dataVencimento,
Decimal valorParcela)
02. {
03. if (descobrirSePrestacaoVenceu(dataVencimento))
04. {
05. Int16 qtdDiasEmAtrazo = obterQtdDiasAtrazo(dataVencimento);
06. Decimal jurosTotais = qtdDiasEmAtrazo * 2.38m;
07. Decimal valorParcelaCorrigida = valorParcela + jurosTotais;
08. return valorParcelaCorrigida;
09. }
10. else
11. {
12. valorParcela = valorParcela - 7.25m;
13. return valorParcela;
14. }
15. }
Nas linhas 3 a 14 da Listagem 1 é possível perceber a existên-
cia de um if e um else. Caso a parcela esteja vencida, é executado
o bloco if. Caso contrário, é executado o else. Entrar no bloco if
significa que a parcela será cobrada com juros. Entrar no bloco
else implica em cobrar a parcela com desconto.
Dada a existência de uma estrutura de seleção (ou de condi-
ção), sugere-se que deva ter o menor número possível de linhas
para os blocos if e else, ou mesmo uma única linha no caso uma
chamada para outro método. O que se deve fazer, portanto,
com o método da Listagem 1 é refatorá-lo com o auxilio da

técnica de refatoração de código Extrair Método. O resultado
da aplicação da técnica pode ser visto na Listagem 2.
Listagem 2. Código da Listagem 1 refatorado
01. public Decimal calcularNovoValorParcela(DateTime dataVencimento,
Decimal valorParcela)
02. {
03. if (descobrirSePrestacaoVenceu(dataVencimento))
04. {
05. return calcularParcelaEmAtrazo(dataVencimento, valorParcela);
06. }
07. else
08. {
09. return calcularParcelaComDesconto(valorParcela);
10. }
11. }
12. private Decimal calcularParcelaEmAtrazo(DateTime dataVencimento,
Decimal valorParcela)
13. {
14. Int16 qtdDiasEmAtrazo = obterQtdDiasAtrazo(dataVencimento);
15. Decimal jurosTotais = qtdDiasEmAtrazo * 2.38m;
16. Decimal valorParcelaCorrigida = valorParcela + jurosTotais;
17. return valorParcelaCorrigida;
18. }
19. private Decimal calcularParcelaComDesconto(Decimal valorParcela)
20. {
21. valorParcela = valorParcela - 7.25m;
22. return valorParcela;
23. }
Na Listagem 2 é possível ver que após a utilização da re-
fatoração Extrair Método, nos blocos if e else do método cal-
cularNovoValorParcela, dois novos métodos foram gerados,
calcularParcelaEmAtrazo e calcularParcelaComDesconto,
ficando no corpo dos blocos if e else do método calcularNo-
voValorPrestacao (linhas 5 e 9) a chamada para os métodos
extraídos, o que é a aplicação da regra, que tem como objetivo
simplificar o código do corpo dos métodos ao simplificar e
reduzir as estruturas de seleção e repetição contidas nele.
Ainda sobre as estruturas de seleção, no caso um switch, é
aconselhável que as estruturas sejam substituídas por algum
recurso que elimine o switch, como o padrão de projeto Strategy,
tornando o método mais simples e menos complexo ao reduzir
sua complexidade ciclomática (ver Nota do DevMan 2).
Nota do DevMan 2
Inserindo o padrão de projeto Strategy.
Para aprender sobre como eliminar lógica condicional, leia a refatoração para pa-
drões Substituir Lógica Condicional por Strategy, na edição de número 32 da Enge-
nharia de Software Magazine.
Definindo o objetivo dos métodos
Definir o objetivo de um método gira em torno do que ele
deve fazer, ou seja, qual ação a ser executada é de sua responsa-
bilidade. Definir a responsabilidade de um método implica em
codificar a tarefa pela qual ele é responsável. Nota-se que foi
dito tarefa e não tarefas, pois um método deve apenas realizar
proce s s o
uma única tarefa. Caso um método possua duas tarefas, ele
deverá ser dividido com a refatoração Extrair Método, ficando
com apenas uma das tarefas que ele realizava.
Um método que possui uma única tarefa é mais fácil de
manter e se torna mais fácil de entender. O objetivo é que a sua
única tarefa seja feita de maneira clara e bem definida.
Métodos cujos nomes são bem definidos tendem a facilitar a
identificação da tarefa que ele realiza. Se, ao ler o nome do mé-
todo e ler o código do corpo do método for possível identificar
uma tarefa que não corresponda ao que o nome do método diz
que ele faz, então possivelmente ele deverá ser modificado.
Regra Decrescente (MARTIN, 2009)
Esta regra descrita em Código Limpo – Habilidades Práticas
do Agile Software refere-se à forma como o código deve poder
ser lido. É importante que a leitura do código contido no corpo
do método possa ser feita de forma sequencial, de cima para
baixo, como um texto que narra os passos de uma ação que
está sendo realizada.
Definindo os nomes para os métodos
Definir um nome para um método pode ser uma tarefa de
tentativa e erro, ou seja, define-se um nome, analisa-o para se
certificar que é o melhor para o método. Se não for, muda-se
o nome para outro que melhor indique a ação que o método
é responsável por executar. Um método pode ter um nome
grande, com mais de uma palavra. A meta é que ele reflita o
objetivo do método. Utilizar a notação primeira letra de cada
palavra maiúscula (exceto a primeira palavra, em caso de no-
mes compostos) e as demais da mesma palavra minúsculas é
uma boa prática. A exemplo tem-se o método criarAluno(), que
segue a notação descrita. Vale lembrar que algumas linguagens
de programação, como C#, são Case Sensitive, ou seja, definir
um nome em maiúsculo não é o mesmo que definir o mesmo
nome em minúsculo.
Alguns desenvolvedores gostam de utilizar seus conheci-
mentos em inglês para formular o que consideram nomes
sofisticados para seus métodos, com o objetivo de mostrar
que conhecem uma língua estrangeira, tentando impressionar
outros desenvolvedores. Caso não seja importante que o nome
dos métodos seja escrito em outra língua, não o faça, a menos
que a palavra em questão seja de conhecimento de qualquer
programador. Definir um método com o nome em português
é mais simples e objetivo, podendo facilitar o entendimento
do nome por parte de um futuro desenvolvedor que dará
manutenção no código.
Definindo parâmetros para métodos
A definição de parâmetros para um método, assim como a
definição do nome e do corpo, deve seguir algumas recomen-
dações. A primeira delas é relativa à quantidade de parâmetros
aconselháveis, que deve ser de no máximo três. O ideal é não
haver parâmetros, mas em alguns casos isso é impossível.
Métodos com parâmetros exigem um esforço maior por parte
do desenvolvedor para entendê-lo, visto que, além de ter que
Edição 40 - Engenharia de Software Magazine 43
entender o objetivo do método e como ele chega ao seu obje-
tivo, através de uma análise do código contido nele, o desen-
volvedor terá ainda que entender o porquê da existência dos
parâmetros e o que cada um deles representa para o método.
Esta recomendação na prática é difícil de ser implementada,
mas os benefícios existem.
Quando o assunto é teste unitário, os benefícios da não exis-
tência de parâmetros são ainda maiores. Testar um método
sem parâmetros é mais simples que testar um com parâmetros,
dado o fato de que, no caso de mais de um parâmetro, deve-se
testar uma série de dados para saber as combinações aceitas
pelos parâmetros, e as que não são.
Em relação aos nomes dos parâmetros, os princípios devem
seguir as mesmas regras discutidas até o momento sobre boas
práticas para definição de nomes, Nomes Significativos (ver
Nota do DevMan 3). Contudo, pode-se utilizar uma notação
desejada para a definição de nomes, como a descrita neste
artigo.
Nota do DevMan 3
Nomes Significativos.
A seção que aborda a importância da definição de nomes significativos em
uma aplicação foi publicada na edição de número 39 da Engenharia de Software
Magazine.
A definição dos tipos que podem ser utilizados para a de-
claração de um parâmetro deve seguir as necessidades dos
métodos, mas um tipo em específico deve ser evitado que é o
tipo boolean. Para entender o porquê da recomendação, deve-se
analisar o código da Listagem 3.
Listagem 3. Método com parâmetro do tipo Boolean
01. public Decimal decidirNovoValorParcela(Boolean situacaoAtual)
02. {
03. Decimal valorParcela = obterValorParcela();
04. if (situacaoAtual == true)
05. {
06. Int16 qtdDiasEmAtrazo = obterQtdDiasAtrazo();
07. Decimal jurosTotais = qtdDiasEmAtrazo * 2.38m;
08. Decimal valorParcelaCorrigida = valorParcela + jurosTotais;
09. return valorParcelaCorrigida;
10. }
11. else
12. {
13. valorParcela = valorParcela - 7.25m;
14. return valorParcela;
15. }
16. }
O método da Listagem 3 toma duas diferentes decisões
dependendo do valor que recebe por parâmetro. Se o valor
recebido for verdadeiro (true), linha 4 da Listagem 3, uma ação
em específico é tomada, caso contrário outra ação diferente é
executada. O fato de um valor booleano ser o ponto principal
para que uma das ações seja a escolhida pode caracterizar o
44 Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 2
método como método de dois objetivos diferentes, o que fere
um dos princípios básicos de um método que é o de possuir
apenas um objetivo (MARTIN, 2009).
Os métodos, quanto aos seus parâmetros, podem ser classi-
ficados como métodos nulos, que são os métodos que não tem
parâmetro, métodos mônades, que são os que possuem apenas
um parâmetro, métodos díades, que são os que possuem dois
parâmetros, métodos tríades, que possuem três parâmetros
e métodos políades, que são os que possuem mais de três
parâmetros. A Listagem 4 possui um exemplo de cada um
desses métodos.
Trabalhar com métodos que possuem mais de dois parâ-
metros, isto é, díades, tríades e políades, requer uma maior
atenção na passagem de dados. O método da linha 35 da
Listagem 4, por exemplo, pode retornar um valor diferente ou
ter um comportamento inesperado caso os parâmetros sejam
invertidos. No caso, passar o valor do parâmetro min no lugar
do parâmetro max, ou vice-versa.
Os riscos dos métodos com muitas responsabilidades
Neste artigo já foi apresentada uma solução para a divisão de
métodos que possuem mais de uma responsabilidade, que é o
uso da refatoração Extrair Método. Esse assunto é importante
de tal forma que deve ser discutido em detalhes. Um método
com duas ou mais responsabilidades pode ocasionar proble-
mas para o sistema como um todo. Considere a Listagem 5.
O método da Listagem 5, calcularMedia, foi implementado
devido à necessidade do sistema em exibir a quantidade de
notas existentes em uma lista de notas, descobrir a média das
notas contidas na lista, exibir a quantidade de notas da lista
e exibir a média calculada. Rapidamente o desenvolvedor o
implementou e resolveu todos os problemas em um único
método, com pouco esforço de programação.
O método calcularMedia funciona perfeitamente de acordo
com a necessidade do sistema no momento, mas possui alguns
problemas conceituais. O primeiro deles é que seu nome não
revela exatamente o que ele faz (apenas uma de suas responsa-
bilidades, que é calcular média). Trocar seu nome para sinalizar
o que ele realmente faz não é uma boa opção, visto que ele tem
várias responsabilidades e um novo nome seria muito grande,
além de não resolver todos os problemas.
Outro problema conceitual de calcularMédia está relacionado
ao fato de que, se o sistema necessitar obter somente a média e
não exibi-la seria impossível, já que chamar o método implica
em também exibir na tela a média capturada. Em outra hipó-
tese, poderia ser preciso obter somente a quantidade de notas
existentes na lista, mas isto também não seria possível, já que
o método não permite executar uma única responsabilidade.
O acoplamento existente entre as quatro responsabilidades
presentes no método calcularMedia pode gerar outro proble-
ma, como um efeito colateral, ao se realizar uma modificação
em uma dessas responsabilidades. Um exemplo seria o de
querer, além de descobrir quantas notas há na lista de notas
(linha 3, Listagem 5), também o desenvolvedor necessitar
exibir a lista de notas e não apenas a quantidade de notas.
 proce s s o

Listagem 4. Exemplo de métodos e suas classificações

01. public class Aluno 40. Commando.ExecuteNonQuery();

02. { 41. SqlDataReader dados = Commando.ExecuteReader();
03. // Método nulo (sem parâmetros) 42. while (dados.Read())
04. private Int64 consultarID() 43. {
05. { 44. Aluno aluno = new Aluno ();
06. ... 45. aluno.ID = Convert.ToInt64(dados[0]);
07. Commando.ExecuteNonQuery(); 46. aluno.Matricula = Convert.ToString(dados[1]);
08. SqlDataReader dados = Commando.ExecuteReader(); 47. aluno.Nomealuno = Convert.ToString(dados[2]);
09. Int64 ultimoIDtop = 0; 48. listaAlunos.Add(aluno);
10. while (dados.Read()) 49. }
11. { 50. dados.Close();
12. ultimoIDtop = Convert.ToInt64(dados[0]); 51. return listaAlunos;
13. } 52. }
14. dados.Close(); 53. catch
15. return ultimoIDtop; 54. {
16. } 55. return listaAlunos;
17. // Método Mônade (com 1 parâmetro) 56. }
18. private Boolean gravaAluno(Aluno aluno) 57. }
19. { 58. // Método Tríade (Com três parâmetros)
20. ... 59. public ArrayList visualizaAluno(Int32 id, String matricula, String nome)
21. try 60. {
22. { 61. ArrayList aluno = recuperaAluno(id, matricula, nome);
23. Commando9.ExecuteNonQuery(); 62. return aluno;
24. return true; 63. }
25. } 64. // Método Políade (Com quatro parâmetros)
26. catch 65. private Boolean atualizarAluno(Int32 id, String nome, String cpf, String rg)
27. { 66. {
28. String queryExcluiLoginAlunoAlocado = “DELETE FROM TBLogin 67. SqlConnection Conexao = classAcesso.getConexao();
WHERE IDLOGIN = ‘” + aluno.Idlogin + “’”; 68. ...
29. SqlCommand Commando13 = new SqlCommand(queryExcluiLogin 69. try
AlunoAlocado, Conexao); 70. {
30. Commando13.ExecuteNonQuery(); 71. Commando.ExecuteNonQuery();
31. return false; 72. return true;
32. } 73. }
33. } 74. catch
34. // Método Díade (Com dois parâmetros) 75. {
35. private ArrayList consultarAlunosBanco(Int64 min, Int64 max) 76. return false;
36. { 77. }
37. ... 78. }
38. try 79. }
39. {

Listagem 5. Método com duas responsabilidades Listagem 6. Método calcularMedia refatorado

01. public void calcularMedia(ArrayList listaNotas) 01. public void calcularMedia(ArrayList listaNotas)
02. { 02. {
03. Int32 quantidadeNotas = listaNotas.Count; 03. Int32 quantidadeNotas = obterQuantidadeNotas(listaNotas);
04. Decimal soma = 0.0M; 04. Decimal soma = 0.0M;
05. Decimal média = 0.0M;
05. Decimal média = 0.0M;
06. for (Int32 i = 0; i < listaNotas.Count; ++i)
06. for (Int32 i = 0; i < listaNotas.Count; ++i)
07. {
08. soma += Convert.ToInt32(listaNotas[i]); 07. {
09. } 08. soma += Convert.ToInt32(listaNotas[i]);
10. média = soma / quantidadeNotas; 09. }
10. média = soma / quantidadeNotas;
11. Console.WriteLine(“Quantidade de notas: “ + quantidadeNotas); 11. exibirQuantidadeNotas(quantidadeNotas);
12. Console.WriteLine(“Média : “ + média); 12. exibirMedia(média);
13. Console.Read(); 13. }
14. } 14. private Int32 obterQuantidadeNotas(ArrayList listaNotas)
15. {
Implementar essa nova necessidade ao método vai gerar o 16. return listaNotas.Count;
efeito colateral de toda vez que ele for invocado, a lista de 17. }
18. private void exibirQuantidadeNotas(Int32 quantidadeNotas)
notas também vai ser exibida, o que é um problema, uma vez 19. {
que nem todos os pontos do sistema necessitariam visualizar 20. Console.WriteLine(“Quantidade de notas: “ + quantidadeNotas);
a lista de notas. 21. }
22. private void exibirMedia(Decimal média)
Com a divisão de calcularMedia, poderá se resolver o 23. {
principal dos problemas conceituais citados: mais de uma 24. Console.WriteLine(“Média : “ + média);
responsabilidade por método. A divisão também pode reduzir 25. Console.Read();
26. }
a possibilidade de surgirem efeitos colaterais como o citado,
mediante as modificações futuras. A Listagem 6 mostra como

Edição 40 - Engenharia de Software Magazine 45

ficou o método calcularMedia depois de aplicada a refatoração a função deve deixar clara a ação que realiza que, no caso da
Extrair Método. função entre as linhas 21 a 31, é limpar datas inválidas. Utilizar
O método calcularMedia agora tem suas responsabilidades Return ao invés do nome da função para retornar dados facilita
divididas com mais três métodos: obterQuantidadeNotas, a leitura da função, além de diminuir o impacto de mudanças
exibirQuantidadeNotas e exibirMedia. como alteração no nome da função, que neste caso levará a
A divisão das responsabilidades do método calcularMedia alterar todas as linhas onde o nome da função é utilizado no
da Listagem 5 para os métodos da Listagem 6 proporcionaram corpo da função.
a divisão de basicamente duas operações diferentes que um A função das linhas 21 a 31 da Listagem 7 deve ser modi-
método pode realizar, que são executar comando ou consultar ficada para ficar como a função da Listagem 8. As linhas 5 e
informações (estas operações são conhecidas como Operação 9 da Listagem 8 foram modificadas em relação à sua função
Comando-Consulta) e não devem coexistir em um mesmo correspondente na Listagem 7.
método. A operação comando caracteriza-se na Listagem 5
pela execução dos comandos que levam ao resultado do cálculo Listagem 7. Funções em Pascal
da média (linhas 4 a 10) e da descoberta do número de notas 01. Function trocaVirgulaPorPonto(Valor: string): String;
contidas na lista (linha 3). Já a operação consulta leva a exibir os 02. var i:integer;
dados obtidos pelos comandos executados (linhas 11 e 12). 03. begin
04. if Valor <>’’ then begin
05. for i := 0 to Length(Valor) do begin
Os problemas do código duplicado 06. if Valor[i]=’,’ then Valor[i]:=’.’;
07. end;
Lidar com código duplicado requer atenção, visto que nem 08. end;
sempre a duplicação é tão visível como de um control-C e 09. Result := valor;
10. end;
control-V. Alguns casos exigem análise detalhada para se 11. Function trocarPontoPorVirgula(Valor: string): String;
identificar a duplicação. Um código é considerado duplicado 12. var i:integer;
quando em outro ponto do sistema há outro trecho de código 13. begin
14. if Valor <>’’ then begin
com o mesmo propósito, mesmo que a escrita não seja igual. 15. for i := 0 to Length(Valor) do begin
Código duplicado pode estar em diversas classes, em seus 16. if Valor[i]=’.’ then Valor[i]:=’,’;
17. end;
métodos e até atributos. É possível ter atributos duplicados em 18. end;
subclasses de uma hierarquia, nesse caso a duplicação deve 19. Result := valor;
20. end;
ser removida e o atributo levado para a superclasse. O mesmo 21. Function limparDatasInvalidas(campo: String): String;
pode acontecer com métodos nas subclasses. Algumas cos- 22. begin
tumam carregar comportamentos semelhantes as das outras 23. if(campo = ‘11/11/1111’)then
24. begin
subclasses, quando na verdade o comportamento semelhante, 25. limparDatasInvalidas:= ‘ / / ‘;
isto é, o código duplicado, deveria estar na superclasse. Caso os 26. end
27. else
métodos que possuem código duplicado não pertençam a uma 28. begin
hierarquia de classes, o que se tem a fazer é remover o código 29. limparDatasInvalidas:= campo;
30. end;
duplicado para um outro método extraído (Extrair Método 31. end;
ajuda neste sentido), e fazer com que os métodos o invoquem,
ao invés de carregar o trecho duplicado em seus corpos. Listagem 8. Função limparDatasInvalidas modificada

01. Function limparDatasInvalidas(campo: String): String;

Retorno de funções 02. begin
Linguagens como Pascal possuem um recurso de permitir 03. if(campo = ‘11/11/1111’)then
04. begin
que o desenvolvedor defina o nome para suas funções (func- 05. Result:= ‘ / / ‘;
tions) e use a própria declaração da função como retorno. O 06. end
07. else
código da Listagem 7 servirá como exemplo. 08. begin
As funções das linhas 1 a 10 e 11 a 20 são funções simples 09. Result:= campo;
que desempenham o papel de trocar um ponto em meio a uma 10. end;
11. end;
string por uma vírgula, e trocar uma vírgula em meio a uma
string por um ponto. Nota-se, nas linhas 9 e 19 que, após ter-
minado o trabalho da função, a string modificada é retornada, Como utilizar os conceitos vistos nesta seção
utilizando a palavra Result. Esta é uma prática comum a vários Os conceitos que esta seção abordou devem ser úteis para
desenvolvedores que trabalham com Pascal. que o desenvolvedor possa criar ou tornar limpos métodos,
Funções em Pascal fornecem uma outra maneira de retornar funções, procedimentos e estruturas semelhantes.
os resultados de uma função, que é utilizar a declaração da Código Limpo (MARTIN, 2009) sugere que o desenvol-
função (nome da função especificamente) para retornar o re- vedor escreva seus métodos da forma como inicialmente
sultado de uma função (ver linhas 25 e 29 da Listagem 7). Essa julgarem melhor. Posteriormente escrevem-se casos de teste
prática não é recomendada, visto que o nome definido para unitários para que se certifique que os métodos funcionam

46 Engenharia de Software Magazine - Boas práticas para escrita de métodos, funções e procedimentos – Parte 2

como planejados. Em seguida, executam-se as modificações
necessárias para que o método se torne limpo. Basicamente,
segue-se esta sequência de passos:
• Escrevem-se métodos para satisfazerem as necessidades do
sistema.
• Escrevem-se casos de teste unitários.
• Rodam-se os testes para se certificar que os métodos funcio-
nam como necessário.
• Inicia-se a análise das responsabilidades que o método pos-
sui. Se mais de uma responsabilidade for detectada, divide-se
o método com a refatoração Extrair Método.
• Remove-se toda duplicação existente no método em análise
e nos métodos extraídos, caso existam.
• Rode os casos de testes para se certificar que o método ainda
funciona como antes das modificações.
• Repetem-se os passos até aplicar as teorias que tornarão o
método limpo.
• Certifica-se que os nomes definidos para os métodos cor-
respondem ao objetivo que cada um deles foi concebido. Caso
contrário, modificam-se os nomes até que se encontrem nomes
significativos.
• Os métodos devem estar em constante análise, para sempre
estarem em mudanças, com o objetivo de torná-los cada vez
mais limpos.
Um recurso que não poderia deixar de ser citado neste artigo
é o de utilizar a técnica de refatoração para padrões Compor
Método, que auxiliará no processo de tornar o corpo de um
método considerado confuso em um mais simples, ao modifi-
car o código tornando-o mais legível, sem remover nenhuma
funcionalidade (ver Nota do DevMan 4).
Nota do DevMan 4
Compor Métodos
A refatoração para padrões Compor Método foi publicada na edição de núme-
ro 31 da Engenharia de Software Magazine.
proce s s o
Conclusão
Este artigo teve por objetivo apresentar boas práticas para
a escrita ou reescrita de métodos, funções e procedimentos.
Aqui foram abordados pontos relativos a essas estruturas,
como o tamanho que elas devem ter, como definir o corpo das
estruturas, como definir seus objetivos, nomes e parâmetros,
além de abordar importantes aspectos sobre as responsabili-
dades de tais estruturas, e como lidar com código duplicado,
um problema que muita das vezes causa efeitos colaterais
indesejáveis.
É importante que o desenvolvedor manipule as informações
contidas neste artigo como sugere o tópico Como utilizar os
conceitos vistos nesta seção, pois ele fornece um passo a passo
que pode ser útil para que o processo de tornar o código mais
limpo não cause problemas à aplicação ao invés de contribuir
positivamente.
Também é importante destacar a necessidade da definição
de casos de testes unitários para que as mudanças ocorridas
com o processo de limpeza do código não venham a modifi-
car o projeto de código de tal forma a gerar novos defeitos ou
remover funcionalidades. De nada adianta aplicar as abor-
dagens descritas neste artigo e não se ter a garantia que os
testes proporcionam de que a estrutura a ser limpa continua
funcionando.
Referências
MARTIN, Robert C, 2009. Código Limpo: Habilidades Práticas do Agile Software, 1ª ed. Rio de
Janeiro: Alta Books, 2009.
FOWLER, Martin. Refatoração: aperfeiçoando o projeto de código existente, 1ª ed. Porto Alegre:
Bookman, 2004.
Dê seu feedback sobre esta edição! eu
Feedback
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 40 - Engenharia de Software Magazine 47
Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatoração para Padrões – Parte 13 (Final)
Refatorações Utilitárias: Extrair Parâmetro, Encadear Construtores e Unificar
Interfaces
Jacimar Fernandes Tavares
jacimar.tavares@studentpartners.com.br
Bacharel em Ciência da Computação FAGOC
- Faculdade Governador Ozanam Coelho,
Microsoft Student Partners.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
É Doutor e Mestre em Engenharia de Sis-
temas e Computação pela COPPE/UFRJ,
Especialista em Métodos Estatísticos Com-
putacionais e Bacharel em Informática pela
UFJF, professor do curso de Bacharelado em
Ciência da Computação da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informação do Centro de Ensino Superior
de Juiz de Fora e da Faculdade Metodista
Granbery, Analista de Sistemas da Prefeitu-
ra de Juiz de Fora, Editor da Engenharia de
Software Magazine.
48 Engenharia de Software Magazine - Refatoração para Padrões – Parte 13 (Final)
M
elhorar o projeto de código
existente implica em mui-
tas vezes dividir trechos de
código em outras partes menores. Um
exemplo seria a divisão de um método
considerado grande em outros vários
métodos menores. A iniciativa de dividir
um método em outros menores é uma
decisão que deve ser tomada de acordo
com a necessidade do desenvolvedor no
momento. É fato que toda divisão requer
cuidados, que vão desde dominar o
processo de refatoração de código até o
domínio de técnicas de testes que darão
a segurança ao desenvolvedor de que
o processo de refatoração foi efetuado
com sucesso.
Seguindo esta vertente da refatoração
de código, que é a divisão de métodos
De que se trata o artigo?
Aborda o tema refatoração para padrões com o ob-
jetivo de mostrar como o desenvolvedor pode usá-lo
para melhorar o código-fonte de suas aplicações.
A discussão deste tema é importante para prover
conhecimento ao desenvolvedor sobre refatoração
para padrões e demonstrar através de exemplos
práticos a aplicação das técnicas de refatoração para
padrões Encadear Construtores, Unificar Interfaces e
Extrair Parâmetro.
Em que situação o tema é útil?
O tema se torna fundamental para desenvolvedores
que já estão familiarizados com padrões de proje-
to e já os implementam em seus softwares e que
querem saber mais sobre refatoração para padrões,
conhecendo os benefícios que sua utilização traz.
Resumo:
O objetivo deste artigo é apresentar as técnicas de
refatoração Extrair Parâmetro, Encadear Constru-
tores e Unificar Interfaces.
maiores em vários métodos menores, o
desenvolvedor poderá se deparar com a
necessidade de adicionar um novo parâ-
metro a um dos métodos recém criados,

pois se verificou a necessidade de se obter mais informações
para que o método realize seu trabalho. Nesse sentido, foi
criada a refatoração de código Adicionar Parâmetro, que per-
mite ao desenvolvedor realizar a tarefa de adicionar novos
parâmetros com segurança.
O desenvolvedor, ainda durante o processo de refatoração de
código, poderá precisar remover parâmetros de métodos modi-
ficados e levá-los para outros métodos. A refatoração Remover
Parâmetro também foi criada para auxiliar, com segurança, o
desenvolvedor nessa tarefa (ver Nota do DevMan 1).
Neste contexto, este artigo abordará as refatorações para
padrões Encadear Construtores, Unificar Interfaces e Extrair
Parâmetro, todas pertencentes ao último conjunto das refatora-
ções para padrões que esta série aborda, que são as refatorações
para padrões utilitárias. É fundamental que o desenvolvedor
esteja familiarizado com as refatorações Adicionar Parâmetro
e Remover Parâmetro.
O objetivo das técnicas de refatoração para padrões deste
artigo é suprir necessidades como eliminar código duplicado.
Com esse objetivo, tem-se a refatoração para padrões Encadear
Construtores, que possibilita que métodos construtores sejam
vinculados, o que garante a eliminação de grande parte do
código duplicado entre eles.
Há ainda momentos em que o desenvolvedor precisa ter in-
terfaces de classes idênticas. Atuando neste sentido, Unificar
Interfaces fornece um mecanismo para que interfaces passem
a atender as necessidades de igualdade do desenvolvedor.
Um recurso útil durante o processo de refatoração de códi-
go é a extração de novos parâmetros para os métodos recém
extraídos. Extrair Parâmetro é a refatoração para padrões uti-
litária que atua nesse cenário, sendo fundamental em alguns
processos de refatoração de código.
Nota do DevMan 1
Refatorações apresentadas em outros artigos
A técnica de refatoração Remover Parâmetro foi apresentada na edição de número
33 da Engenharia de Software Magazine.
Refatoração Adicionar Parâmetro
Esta refatoração é pertencente ao grupo de refatorações
classificadas como Tornando as Chamadas de Métodos Mais
Simples.
Nome da refatoração: O nome original da refatoração é Acres-
centar Parâmetro (FOWLER, 2004), mas é citada nas técnicas
de refatoração para padrões como Adicionar Parâmetro.
Resumo: Alguns métodos precisam de mais informações
para executar determinada tarefa. Acrescenta-se um parâme-
tro a ele e alteram-se as chamadas para que possam fornecer
esse dado.
Motivação: Usa-se esta refatoração quando um método recém
modificado precisa de mais informações para realizar suas
proce s s o
operações. Como as informações antes disponíveis são poucas,
acrescenta-se um parâmetro ao método.
Mecânica:
• Certifique-se de que o método não tem sua assinatura imple-
mentada em uma super ou subclasse. Caso tenha, cada passo
da mecânica deve ser repetido em todas as implementações
existentes.
• Cria-se um novo método com o nome desejado e com a lista
de parâmetros do método antigo mais o parâmetro que se
deseja acrescentar.
• Move-se o corpo do método para o método recém criado e
apaga-se o método antigo.
• Modifica-se os pontos que chamam o método antigo, para que,
a partir desse momento, passem a referenciar o método novo.
• Executa-se os testes.
A seguir são apresentadas as refatorações para padrões En-
cadear Construtores, Unificar Interfaces e Extrair Parâmetro,
pertencentes ao conjunto das refatorações utilitárias, as últimas
refatorações para padrões desta série de artigos.
Refatoração para padrões Encadear Construtores
Resumo: Devido à grande quantidade de código duplicado
em vários construtores, utiliza-se esta técnica a fim de remover
parte do código duplicado.
Motivação: A maior motivação para essa refatoração para
padrões está ligada ao fato de que código duplicado aumenta
a chance de surgirem problemas no código quando se faz
uma manutenção. Com essa técnica, consegue-se encadear
os construtores de tal forma que um acesse o outro, e assim
código duplicado possa ser eliminado.
Mecânica:
1. Busca-se por construtores que podem invocar um outro
construtor, afim de que a duplicação possa ser removida.
2. O processo deve ser repetido em todos os construtores
possíveis.
3. Alteram-se os moderadores de acesso dos construtores para
privados, caso seja possível.
Exemplo: A classe Aluno possui três construtores, com muito
código duplicado, como pode ser visto na Listagem 1.
Analisando os dois primeiros construtores da Listagem 1,
percebe-se que há muito código duplicado com o terceiro cons-
trutor, que é o que recebe como parâmetro dados para todos os
atributos. Aplicando a técnica Encadear Construtores, tem-se um
código com menos duplicação, como pode ser visto na Listagem 2,
que mostra o resultado desta refatoração para padrões.
Refatoração para padrões Unificar Interfaces
Resumo: Há momentos em que surge a necessidade de se
ter uma superclasse e/ou uma interface idêntica à interface
de uma subclasse. Modifica-se a superclasse e/ou a interface
para que se tenham interfaces idênticas.
Motivação: Às vezes, dada a necessidade de se instanciar
objetos polimorficamente, o desenvolvedor precisa, como
Edição 40 - Engenharia de Software Magazine 49
pré-requisito para essa tarefa, que a interface da superclasse Mecânica:
seja idêntica à da subclasse para que assim ele possa passar a 1. Para cada método da subclasse que deseja ter acesso através
tarefa de instanciar objetos à subclasse através de um método da superclasse, repita os passos da mecânica. Este método
implementado na subclasse. Quando as interfaces não são presente na subclasse, mas não na superclasse, é classificado
iguais, surge a necessidade da aplicação desta técnica de refa- como método ausente.
toração para padrões, que unificará a interface da superclasse 2. Faça uma cópia do método ausente para a superclasse ou
e a tornará idêntica à da subclasse. interface. Remova o código do corpo do método copiado para
a superclasse ou interface e modifique-o para abstrato.
Listagem 1. Classe Aluno 3. Execute os testes.
01. public class Aluno
02. { Exemplo: A superclasse Emprestimo não possui interface
03. …
04. public Aluno(String nome, String cpf )
idêntica à subclasse EmprestimoPessoa. Assim, o método Cal-
05. { culoDePrestacao presente na subclasse EmprestimoPessoa não
06. this.Nomealuno = nome; pode ser acessado polimorficamente pela superclasse Empres-
07. this.Cpf = cpf;
08. BuscarAluno(this); timo. A Listagem 3 mostra a subclasse EmprestimoPessoa.
09. } Aplicando o passo 1 desta técnica, copia-se o método Cal-
10. public Aluno(String nome, String cpf, String rg)
11. { culoDePrestacao, Listagem 3, para a superclasse Emprestimo
12. this.Nomealuno = nome; e remove-se o corpo do método. Declare-o como abstrato.
13. this.Cpf = cpf;
14. this.Rg = rg;
Para que o método CalculoDePrestacao possa ser acessado
15. AtualizarDocumentos(this); polimorficamente, modifique-o permitindo a implementação
16. } polimórfica. A Listagem 4 mostra a superclasse Emprestimo e
17. public Aluno(String nome, String cpf, String rg, String rua, UInt32
numeroCasa, String bairro, String cidade, String estado, String cep) a Listagem 5 mostra como ficou o método CalculoDePrestacao
18. { depois das mudanças.
19. this.Nomealuno = nome;
20. this.Cpf = cpf;
21. this.Rg = rg; Listagem 3. Classe EmprestimoPessoa
22. this.Rua = rua;
23. this.Numerocasa = numeroCasa; 01. public class EmprestimoPessoa: Emprestimo
24. this.Bairro = bairro; 02. {
25. this.Cidade = cidade; 03. public override Decimal calculoDePrestacao(Decimal valorTotal,
26. this.Estado = estado; Decimal valorEntrada, UInt32 qtdParcelas)
27. this.Cep = cep; 04. {
28. }
05. Decimal valorParcela = valorTotal - valorEntrada;
29. …
06. valorParcela = Convert.ToDecimal((valorParcela / qtdParcelas) + 0.2m);
30. }
07. gravarParcela(valorParcela);
08. return valorParcela;
Listagem 2. Classe Aluno refatorada 09. }
10. ...
01. public class Aluno
11. }
02. {
03. …
04. public Aluno(String nome, String cpf ) Listagem 4. Superclasse Emprestimo
05. {
06. Aluno aluno = new Aluno(nome, cpf, null, null, 0, null, null, null, null); 01. public abstract class Emprestimo
07. BuscarAluno(aluno); 02. {
08. } 03. ...
04. public abstract Decimal calculoDePrestacao(Decimal valorTotal,
09. public Aluno(String nome, String cpf, String rg) Decimal valorEntrada, UInt32 qtdParcelas);
10. { 05. ...
Aluno aluno = new Aluno(nome, cpf, rg, null, 0, null, null, null, null); 06. }
AtualizarDocumentos(aluno);
11. }
Listagem 5. Método CalculoDePresta0 depois das mudanças
12. public Aluno(String nome, String cpf, String rg, String rua, UInt32
numeroCasa, String bairro, String cidade, String estado, String cep) 02. public class EmprestimoPessoa: Emprestimo
13. { 03. {
14. this.Nomealuno = nome; 04. public override Decimal calculoDePrestacao(Decimal valorTotal,
15. this.Cpf = cpf; Decimal valorEntrada, UInt32 qtdParcelas)
16. this.Rg = rg; 05. {
17. this.Rua = rua; 06. Decimal valorParcela = valorTotal - valorEntrada;
18. this.Numerocasa = numeroCasa; 07. valorParcela = Convert.ToDecimal((valorParcela / qtdParcelas) + 0.2m);
19. this.Bairro = bairro; 08. gravarParcela(valorParcela);
20. this.Cidade = cidade;
09. return valorParcela;
21. this.Estado = estado;
10. }
22. this.Cep = cep;
23. } 11. ...
24. ... 12. }
25. }

50 Engenharia de Software Magazine - Refatoração para Padrões – Parte 13 (Final)


Refatoração para padrões Extrair Parâmetro
Resumo: Um atributo de uma classe recebe um valor obtido
através de uma operação dentro de um método ou construtor.
Cria-se um parâmetro neste método, ou construtor, e o atribui
ao atributo da classe.
Motivação: Esta técnica pode fornecer outra forma de atribuir
valores a um atributo, e ao mesmo tempo melhorar a forma
como parâmetros são passados. Além disso, ela é uma técnica
base (utilitária) que será utilizada por outras técnicas de refa-
toração para padrões maiores.
Mecânica:
1. Verifique se a atribuição feita a um atributo está ocorrendo
dentro de um método ou construtor. Se não, esta refatoração
não se aplica.
2. Utiliza-se a refatoração Adicionar Parâmetro para modificar
os parâmetros do método, ou construtor, fazendo com que o
atributo passe a receber os parâmetros, e não mais atribuição
direta. Caso seja necessário, aplique a refatoração Remover
Parâmetro para remover os parâmetros desnecessários após
o término dessa refatoração para padrões.
Exemplo: A classe Emprestimo apresenta um construtor
onde um atributo recebe um valor que foi originado dos pa-
râmetros recebidos pelo construtor. A Listagem 6 mostra o
método construtor.
O passo 1 da mecânica é verificado, visto que o atributo já está
recebendo dados dentro de um construtor, portanto pode-se
seguir com a refatoração.
O passo 2 implica em adicionar um parâmetro ao construtor
a fim de substituir a atribuição direta pelo parâmetro e, poste-
riormente, atualiza-se o código cliente. A Listagem 7 mostra o
código cliente que invoca o construtor da classe Emprestimo.
A Listagem 8 mostra o construtor da classe Emprestimo
depois das modificações.
Listagem 6. Construtor da classe Emprestimo
01. public class Emprestimo
02. {
03. private Decimal taxa;
04. ...
05. public Emprestimo(Decimal valorEmprestimo, Decimal Imposto)
06. {
07. this.Taxa = Financiamento.recuperaTaxa(valorEmprestimo, Imposto);
08. ...
09. }
10. ...
11. }
Listagem 7. Código cliente que invoca o construtor de Emprestimo
01. Emprestimo emprestimo = new Emprestimo(1000.0m, 0.12m);
Agora resta atualizar o código cliente da Listagem 7, que
ficará como pode ser visto na Listagem 9.
Algumas considerações
As refatorações para padrões abordadas neste artigo são
utilitárias, isto é, são refatorações para padrões menores.
proce s s o
Conhecendo as refatorações para padrões utilitárias e onde elas
atuam, o desenvolvedor será capaz de utilizar cada uma delas
no momento que julgar importante no processo de melhoria
do código fonte de sua aplicação.
Listagem 8. Classe Emprestimo refatorada
01. public class Emprestimo
02. {
03. private Decimal taxa;
04. ...
05. public Emprestimo(Decimal taxa)
06. {
07. this.Taxa = taxa;
08. ...
09. }
10. ...
11. }
Listagem 9. Código cliente que invoca o construtor de Emprestimo refatorado
01. E mprestimo emprestimo = new Emprestimo
(Financiamento.recuperaTaxa(1000.0m, 0.12m));
Conclusão
Ao final desta série têm-se todos os objetivos cumpridos,
o que inclui uma gama de conteúdos relacionados à refa-
toração para padrões, bem como uma grande quantidade
de exemplos sobre padrões de projeto em C#, linguagem
na qual não se encontram muitas referências sobre imple-
mentação de padrões de projeto. Além disso, espera-se que
todo conhecimento que foi compartilhado ao longo desta
série de artigos possa ser útil no processo de melhorar a
qualidade dos projetos de código existente ao se inserir
padrões de projeto.
Esta série abordou alguns dos diferentes padrões de projeto
existentes na literatura técnicas sobre padrões de projeto, e
tornou possível uma série de melhorias de código fonte, dis-
cutidas ao longo da série de artigos. Além de prover o conhe-
cimento necessário sobre como trabalhar com determinados
padrões de projeto, esta série mostrou outra abordagem para
se trabalhar com padrões, que é através da refatoração de có-
digo com objetivo de inserir padrões de projeto, ao contrario
da abordagem tradicional que visa inserir padrões de projeto
ainda na fase de planejamento do desenvolvimento.
Vimos também que esta série de artigos não está apenas
relacionada a padrões de projeto, mas também a qualida-
de de código fonte. Conhecidas as técnicas de refatoração
para padrões aqui abordadas, agora cabe ao desenvolvedor
sempre estar em processo contínuo de refatoração para
padrões, mantendo sempre as características que formam
um padrão de projeto, e mantendo a qualidade do código
fonte ao melhorar o projeto de código existente.
Sobre os padrões de projeto apresentados
É evidente que o uso de padrões de projeto no desenvolvi-
mento de software trás benefícios mas, o sucesso da aplicação
em determinado contexto depende de algumas características
do projeto.
Edição 40 - Engenharia de Software Magazine 51
 Algo a se considerar nesses casos é a complexidade do projeto
da aplicação. Em alguns momentos, o uso de um padrão de
projeto pode não ser uma boa solução, pois sua implementação
pode complicar o projeto de código existente quando uma outra
solução sem padrões de projeto seria ideal. A esse problema dá
se o nome deslumbramento com padrões (KERIEVSKY, 2008),
visto que a implementação de alguns padrões não são tão
simples mas, mesmo assim, para resolver problemas simples,
alguns desenvolvedores ainda insistem em utilizá-los.
Os padrões de projeto aqui apresentados são utilizados por
diferentes desenvolvedores de diversas formas. Uma das for-
mas, que é planejar a solução já pensando em quais padrões
de projeto implementar, pode fazer com que o desenvolvedor
acabe utilizando-os em excesso. O uso para estes padrões de
projeto nesta série de artigos é voltado para refatorações para
padrões, o que evita que o desenvolvedor implemente padrões
em excesso, dado que eles serão inseridos de acordo com as
necessidades do projeto existente.
Sobre as refatorações apresentadas
Um dos objetivos de se descrever as técnicas de refatoração nesta
série de artigos é o de prover conhecimento ao desenvolvedor
que o auxiliará no processo de refatoração para padrões, além de
permitir que ele melhore o projeto de código existente. Para que
possa fazer bom uso desse conhecimento adquirido, é importante
que saiba os prós e contras da aplicação dessas técnicas.
É importante destacar que, apesar das refatorações terem
uma motivação, a escolha de usá-las fica com o desenvolve-
dor. Algumas refatorações podem não ser uma boa escolha,
dependendo do tipo de software em questão. Como exemplo,
pode-se destacar a refatoração Substituir Método por Objeto
Método, que permite a criação de uma nova classe. Apesar
dos seus benefícios, se usada em um software que possui uma
documentação detalhada, com diagramas de classe, por exem-
plo, o desenvolvedor teria que atualizar essa documentação e,
naturalmente, justificar o motivo dessas mudanças, o que em
algumas situações pode não ser tão simples.
Outro ponto a se considerar é a questão da produtividade em
algumas empresas. As melhorias que a aplicação das técnicas
de refatoração proporcionam são evidentes, mas elas apenas
melhoram o código das funcionalidades que já existem, mas
não servem para implantar novas funcionalidades. Com isso,
algumas empresas, devido a, por exemplo, terem cronogramas
apertados, podem não permitir ao desenvolvedor investir o
tempo necessário para se dedicarem a aplicar essas técnicas
no software. Portanto, não é aconselhável que o desenvolvedor
use o tempo que é destinado a implementar novas funcionali-
dades para refatorar as que já existem. O processo de refatorar
deve coexistir em harmonia com o processo de implementar
novas funcionalidades. Em um momento se implementa novas
funcionalidades, não se preocupando em refatorar ao mesmo
tempo, e em outro momento se refatora a funcionalidade
criada, caso necessário.
Por fim, vale a pena ressaltar que as técnicas de refatoração
não descrevem como projetar arquiteturas de software, mas
52 Engenharia de Software Magazine - Refatoração para Padrões – Parte 13 (Final)
sim como melhorar o código da arquitetura existente, planejada
ou não, para o software em questão.
Sobre as refatorações para padrões apresentadas
Até este momento foram apresentadas as técnicas de refatora-
ção para padrões existentes, e seus benefícios, que são visíveis
melhoras no projeto de código fonte existente, tornando-os
mais reutilizáveis, através da implementação dos padrões de
projeto que elas propõem, além de promoverem outros bene-
fícios, como simplificação de código, remoção de duplicação,
entre outros destacados.
Além dos benefícios que as técnicas de refatoração para pa-
drões proporcionam, elas apresentam algumas desvantagens
que devem ser consideradas antes de aplicá-las. Antes de
iniciar o processo de refatoração para padrões, utilizando de-
terminada técnica, o desenvolvedor deve analisar se, ao invés
de melhorar o projeto de código, a refatoração para padrões
não complicará o projeto, ou que os benefícios sejam mínimos,
a ponto de não justificar a refatoração.
Outro fator importante a se considerar é a questão do mo-
mento de refatorar para padrões. A preocupação de alguns
desenvolvedores está no fato de como utilizar as técnicas de
refatoração para padrões em um ambiente onde a necessida-
de da implementação de novas funcionalidades surge a cada
instante. Um desafio nesse sentido é convencer os gestores que
o tempo que é necessário para refatorar uma aplicação não im-
plicará num desperdício de dinheiro para a empresa. Refatorar
para padrões não envolve mudanças externas ao software, nem
mudanças nas funcionalidades antes encontradas. Elas apenas
atuam na formação de soluções reutilizáveis e na melhoria do
projeto de código existente (KERIEVISKY, 2008).
O que se propõe nesses casos é que o desenvolvedor imple-
mente as novas funcionalidades, de acordo com as solicitações
que vão surgindo e, posteriormente, reserve um tempo para
refatorá-las, o que permitirá uma melhora no código escrito
para a funcionalidade.
Referências
GAMMA, Erich, 2000. Padrões de Projeto: soluções reutilizáveis de software orientado a objetos,
1ed. Porto Alegre: Bookman, 2000.
KERIEVSKY, Joshua. Refatoração para Padrões, 1ed. Porto Alegre: Bookman, 2008.
FOWLER, Martin. Refatoração: aperfeiçoando o projeto de código existente, 1ed. Porto Alegre:
Bookman, 2004.
SILVA, L.; SAYÃO, M.; LEITE, J. C. S. P.; BREITMAN, K. (2003) “Enriquecendo o código com cenários”,
In: Simpósio Brasileiro de Engenharia de Software (SBES), Manaus, AM, Brasil, Outubro.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
Dê seu voto sobre este artigo, através do link:
edição
www.devmedia.com.br/esmag/feedback
 proce s s o

Edição 40 - Engenharia de Software Magazine 53