Conhecimento

faz diferena!

Capa ESM - Final .pdf 19.02.08 18:15:13

Engenharia de Software
Saiba seu significado e para que serve
magazine

Edio Especial






  
Entenda os principais conceitos sobre
Testes e Inspeo de Software

Verificao, Validao & Teste

Ferramentas Open Source e melhores
prticas na gesto de defeitos
Requisitos Projeto
Conhea os principais conceitos envolvidos Entenda o conceito de Arquitetura de Software e
na Engenharia de Requisitos como trabalhar com os Estilos Arquiteturais

Especial
Melhore seus processos atravs da
anlise de risco e conformidade
Processos
Mais de 60 mil downloads
Veja como integrar conceitos de
Modelos Tradicionais e geis
Veja como integrar o Processo
Unificado ao desenvolvimento Web
na primeira edio!

Faa j sua assinatura digital! | www.devmedia.com.br/es

Faa um up grade em sua carreira.

Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, anlises,
testes, entre outros, pode ser a diferena entre conquistar ou no uma boa posio profissional. Sabendo disso a DevMedia
lana para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software.
Todos os meses voc ir encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais (document driven);
ALM (application lifecycle management); SOA (aplicaes orientadas a servicos); Analise de sistemas; modelagem; Mtricas;
orientao objetos; UML; testes e muito mais. Assine j!
 EDITORIAL

N
esta edio a Engenharia de Software Magazine volta a des-
tacar como tema de capa a agilidade no desenvolvimento de
software. Desta vez, o foco da discusso ser sobre a gerncia
de projetos. Para isto, trazemos duas matrias muito interessantes. Na
primeira delas, Desafios para o gerenciamento gil de projetos cola-
Ano 2 - 19 Edio 2009 Impresso no Brasil
borativos, sero apresentadas as definies e os desafios envolvidos
Corpo Editorial no gerenciamento de projetos colaborativos, gerenciamento de pro-
jetos tradicionais e gerenciamento gil, realizando uma comparao
Colaboradores
com os conceitos clssicos do gerenciamento de projetos.
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br No segundo artigo, Softwares para gerenciamento de projetos, vere-
Marco Antnio Pereira Arajo mos o que so softwares para apoiar o Gerenciamento de Projetos, as
Eduardo Oliveira Spnola suas funcionalidades e uma abordagem dos principais sistemas exis-
Reviso e Superviso tentes no mercado, destacando o que pode ser evoludo para abraar
Thiago Vincenzo Ciancio - thiago.v.ciancio@devmedia.com.br o gerenciamento de projetos colaborativos e o desenvolvimento gil.
Coordenao Geral Alm destas matrias, esta edio traz mais quatro artigos:
Daniella Costa - daniella@devmedia.com.br Arquitetura Orientada a Servios
Diagramao Arquitetura REST: Uma alternativa para construo de Servios Web
Janete Feitosa Usando banco de dados objeto-relacionais
Capa Gesto de Portflio de Projetos
Romulo Araujo - romulo@devmedia.com.br
Na Web
www.devmedia.com.br/esmag
Apoio
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine

Parceiros:
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo mi-
nistrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos
Atendimento ao Leitor e Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.BR.
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de
bancas de jornal, entre outros, entre em contato com:
Cristiany Queirz Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338 Marco Antnio Pereira Arajo
Kaline Dolabella (maraujo@devmedia.com.br)
Gerente de Marketing e Atendimento
kalined@terra.com.br Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Li-
(21) 2220-5338 nha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos
Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela
Publicidade
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao
Para informaes sobre veiculao de anncio na revista ou no site entre em
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em
contato com:
Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Cur-
Kaline Dolabella
publicidade@devmedia.com.br so Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
Fale com o Editor!
Colaborador da Engenharia de Software Magazine.
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 sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine, Eduardo Oliveira Spnola
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc (eduspinola@gmail.com)
gostaria de publicar: Editor das revistas Engenharia de Software Magazine, SQL Magazine, WebMobile.
Rodrigo Oliveira Spnola - Colaborador bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde
editor@sqlmagazine.com.br atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de
Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
 Caro Leitor
Para esta edio, temos um conjunto de 5 vdeo aulas. Estas vdeo aulas esto disponveis para download no Portal da
Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de
aulas publicadas pode ser vista abaixo:

Tipo: Projeto Tipo: Projeto

Ttulo: Diagrama de Classes na Prtica Partes 9 a 11
Estudo de Caso 2
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Esta aula parte de uma srie sobre a construo de
diagrama de classes da UML. O objetivo do conjunto de aulas apresentar
de forma prtica como elaborar o diagrama de classes a partir de diferentes
estudos de caso. Nestas aulas, daremos continuidade elaborao do
diagrama de classes para o segundo estudo de caso. Nesta etapa, sero
identificadas as operaes e relacionamentos das classes.Ao final teremos
o diagrama de classes elaborado para o segundo estudo de caso.
Ttulo: Diagrama de Classes na Prtica Partes 12 e 13
Estudo de Caso 3
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Esta aula parte de uma srie sobre a construo
de diagrama de classes da UML. O objetivo do conjunto de aulas
apresentar de forma prtica como elaborar o diagrama de classes
a partir de diferentes estudos de caso. Nestas aulas, dado incio
elaborao do diagrama de classes para o terceiro estudo de caso.
Nesta etapa, sero identificados os atributos e as classes de nosso
diagrama.

NDICE

Abordagens geis de Desenvolvimento

05 - Desafios para o gerenciamento gil de projetos colaborativos

Camila de Araujo

16 - Softwares para gerenciamento de projetos

Camila de Araujo

Abordagens Tradicionais de Desenvolvimento

24 - Arquitetura Orientada a Servios
Anderson Dias Ribeiro e Giuliano Prado de Morais Giglio

33 - Arquitetura REST
Lvia Ruback e Regina Braga

39 - Usando banco de dados objeto-relacionais

Ana Cristina Melo

Planejamento e Gerncia
47 - Gesto de Portflio de Projetos
Cristine Gusmo e Carlos Henrique R. Alexandria

4 Engenharia de Software Magazine


Desafios para o gerenciamento gil de projetos
colaborativos
Camila de Araujo
Possui graduao em Bacharelado em Siste-
mas de Informao pela Universidade Esta-
dual Paulista Jlio de Mesquita Filho (2003)
e mestrado em Engenharia de Produo pela
Universidade de So Paulo (EESC-USP, 2008).
Atualmente doutoranda em Engenharia
de Produo na Universidade de So Paulo
(EESC-USP), com a pesquisa Software de
apoio ao gerenciamento gil de projetos cola-
borativos de novos produtos. Tem experincia
na rea de Engenharia de Produo, com
nfase em Gerncia do Projeto e do Produto,
atuando principalmente nos seguintes temas:
softwares de gerenciamento de projetos,
gerenciamento gil de projetos, projetos co-
laborativos de novos produtos, sistemas de
informao e desenvolvimento de produto.
O
objetivo deste artigo apresentar
as definies e, principalmente,
os desafios envolvidos no ge-
renciamento de projetos colaborativos,
gerenciamento de projetos tradicionais e
propostos no enfoque do gerenciamento
gil de projetos, contrapondo-os aos
conceitos ditos tradicionais (clssicos)
de gerenciamento de projetos. No se
pretende descrever os tradicionais,
pois h uma vasta literatura sobre o
tema, de fcil acesso e padronizada por
associaes profissionais1. A primeira
seo apresenta a definio de Geren-
ciamento de Projetos Colaborativos e
seus conceitos bsicos como colaborao
e classificao de projetos. A seo se-
guinte apresenta as crticas teoria de
gerenciamento de projetos e o enfoque
gil no gerenciamento de projetos com
sua definio, seus objetivos, princpios
Edio 19 - Engenharia de Software Magazine
M etodologias geis
De que se trata o artigo?
Este artigo apresenta as definies e os desafios
envolvidos no gerenciamento de projetos colabora-
tivos, gerenciamento de projetos tradicionais e ge-
renciamento gil, realizando uma comparao com
os conceitos clssicos do gerenciamento de projetos.
Para que serve?
Com a constante aquisio de empresas de desen-
volvimento por outras empresas de desenvolvimen-
to acredita-se que em alguns anos ser comum a
gerncia de projetos de forma colaborativa, visto que
estas empresas estaro espalhadas geograficamen-
te. Alm disso, a necessidade de entregar verses do
sistema mais rapidamente e que atendem em evo-
luo s necessidades do cliente indicam um cenrio
adequado para o desenvolvimento gil. Nesse artigo
voc conhecer estas duas formas de GP.
Em que situao o tema til?
Este tema til para todos aqueles que lidam com
gerncia de projetos e que esto interessados em
conhecer e/ou adotar o gerenciamento de projetos
colaborativos ou mtodos geis em seus projetos.
1 Gesto tradicional, aqui tratada como clssica.
Sugere-se que se consulte a seguinte bibliografia:
VERZUH(2000); PMBOK(2004); e KERZNER(2002).
5
e valores, e sua aplicabilidade no gerenciamento de projetos
de desenvolvimento de produtos. Por fim, realizamos uma
sntese dos desafios identificados.
Desafios no gerenciamento de projetos colaborativos
Definio e conceitos bsicos da colaborao
Nooteboom (1999) diz que a razo fundamental pela qual
as empresas se associam a oportunidade de complementar
suas competncias para produzir valor agregado e inovao.
A associao com outras empresas fundamental no atual
cenrio de desenvolvimento tecnolgico. O caso da Procter &
Gamble, apresentado por Huston e Sakkab (2006), demonstra
claramente esse problema. Uma empresa que possui uma es-
trutura de desenvolvimento tecnolgico significativa, frente ao
padro da maioria das empresas, e que, apesar disso, reconhece
a dificuldade de manter-se atualizada nas vrias tecnologias
necessrias ao seu negcio. Assim, apesar do tradicional inves-
timento em P&D, a empresa permanece na busca de parcerias,
criando redes de colaborao.
Rycroft e Kash (2004) identificam a globalizao como sendo
a fora que induz colaborao entre vrios tipos de organiza-
o. Combinando a fora, a percia e o conhecimento de equipes
tcnicas diversas e dispersas geograficamente, as tecnologias
podem ser desenvolvidas em menos tempo (DAVIS, KEYS e
CHEN, 2004). Talvez, no futuro, as empresas que conseguiro
manter-se na liderana do desenvolvimento tecnolgico e de
produtos sejam aquelas que consigam se associar s redes que
contemplem todas as competncias necessrias para o desen-
volvimento dos produtos e que saibam melhor como atuar de
forma colaborativa (HUSTON e SAKKAB, 2006). Empresas que
sejam tambm aptas a criar processos de negcio capazes de
acessar o conhecimento compartilhado (KODAMA, 2007).
O desenvolvimento colaborativo , portanto, um fenmeno
atual. Na literatura existem vrias definies de colaborao
em termos de desenvolvimento de produto. Desde a dcada
de 80 que esse fenmeno vem sendo desenvolvido do ponto
de vista gerencial, com diversos nomes (alianas estratgicas,
parcerias, etc.) e sob diferentes aspectos. Amaral (1997) e
Amaral e Toledo (2000) apresentam uma compilao espe-
cfica sobre a colaborao no desenvolvimento de produtos,
na qual identificam linhas de pesquisa distintas e comparam
diferentes definies.
Em um estudo recente, Emden, Calantone e Droge (2006)
apresentam uma extensa reviso sobre colaborao no desen-
volvimento de produto. Os autores definem colaborao no
desenvolvimento de produto como um tipo de relacionamento
inter-organizacional, caracterizado por nveis elevados de
transparncia e onde cada participante contribui com uma
parcela significativa do resultado final do projeto. Essas duas
caractersticas interao e objetivos comuns so os aspectos
fundamentais que designam praticamente todas as definies
de colaborao. Exemplos de definies que seguem essa linha
so as de Mattessich e Monsey (1992), segundo a qual cola-
borao uma relao bem definida e mutuamente benfica
6 Engenharia de Software Magazine - Desafios para o gerenciamento gil de projetos colaborativos
entre duas ou mais organizaes, a fim de atingir objetivos
comuns; e a de Katz e Martin (1997), como o trabalho conjunto
de indivduos para atingir objetivos comuns.
Mas essas definies no exploram em profundidade um aspec-
to do trabalho colaborativo: a criao conjunta. Duas empresas
que trabalham em um mesmo projeto podem, no necessaria-
mente, influenciar da mesma maneira no resultado final. Assim
corre-se o risco de confundir colaborao com outros tipos de
relacionamentos que no apresentam nveis similares de com-
plexidade gerencial. Um caso emblemtico a subcontratao
de servios de desenvolvimento. O cliente concebe o produto,
define as caractersticas essenciais e delega a outra empresa
trabalhos especficos de detalhamento, sem que haja interao
ou contribuio do fornecedor no resultado preconcebido. Neste
caso, pode haver uma diviso de tarefas clara e bem delimitada,
que faz o esforo no ser realmente de cooperao, na medida em
que envolve pequena interao entre as partes.
O estudo de Camarinha-Matos et al. (2006) descreve os vrios
nveis de integrao entre parceiros que foram analisados e
utilizados na definio de colaborao. Os autores apresen-
tam uma classificao de quatro tipos de envolvimento: rede,
coordenao, cooperao e colaborao. O mais avanado, dito
colaborao, envolve objetivos, identidades, responsabilidades
e trabalho conjuntos, quer dizer, a criao do produto final
realizada conjuntamente pelos parceiros: por meio de intensa
troca de informaes. Por deixar esse aspecto mais evidente,
adota-se neste trabalho a definio do nvel mais avanado
desses autores (CAMARINHA-MATOS et al., 2006): Um pro-
cesso em que entidades compartilham informaes, recursos
e responsabilidades para planejar, implementar e validar um
programa de atividades para atingir um objetivo comum.
Definio de projeto colaborativo
Um dos fatores que contriburam para a difuso da literatura
de gerenciamento de projetos foi o lanamento, a partir de 1987,
do PMBOK (Project Management Body of Knowledge) pelo PMI
(Project Management Institute), difundindo e padronizando os
termos empregados no gerenciamento de projetos.
Segundo esse padro, um projeto um esforo temporrio
para criar um produto (item final ou componente), servio
(funes de negcio para suporte ou distribuio) ou resul-
tado exclusivo (documentos, por exemplo, de conhecimento
aplicado de pesquisa cientfica) (PMBOK, 2004). Os membros
dessa associao consideram tambm o conceito de programa,
definido como um conjunto de projetos visando um resultado
principal (PMBOK, 2004).
At 2003, os projetos eram classificados, de forma simples,
como nicos ou mltiplos (programa). Evaristo e Fenema (1999)
propuseram uma tipologia de projetos e programas de acordo
com a localizao fsica. Segundo os autores, os projetos ou
programas podem ser realizados e gerenciados dentro de uma
nica organizao ou distribudos em diferentes organizaes,
com localizaes distintas. Essa diferena representaria desa-
fios e esforos gerenciais distintos, justificando a necessidade
da categorizao.

Quando comparada ao conceito de projetos colaborativos,
descrito na seo anterior, nota-se que essa classificao
considera apenas o aspecto do envolvimento de diferentes
organizaes em um mesmo projeto, porm no caracteriza o
aspecto da diviso de tarefas. H projetos que so realizados
por duas ou mais organizaes e distribudos, nos quais o
trabalho concebido, planejado e controlado por apenas
uma delas, como o caso de projetos de desenvolvimento
de produtos totalmente controlados pelos clientes. Segundo
a teoria de projetos colaborativos, esses casos seriam distin-
tos daqueles nos quais os membros das duas organizaes
tenham que definir e criar as solues conjuntamente,
negociar prazos e mtodos de trabalho, como o caso do
envolvimento de parceiros de risco no desenvolvimento de
novos produtos. As duas situaes representam problemas
com nveis de complexidade distintos em termos de geren-
ciamento de projetos.
Portanto, prope-se neste artigo uma adaptao da tipo-
logia de Evaristo e Fenema (1999). A Figura 1 representa
a adaptao dessa tipologia, que considera no somen-
te o conceito de distribuio fsica, como tambm o de
colaborao.
Figura 1. Tipologia de Projetos para o desenvolvimento de Produtos
(Fonte: adaptado de Evaristo e Fenema (1999))
Definem-se como colaborativos, ento, os projetos onde h
um esforo compartilhado no contedo e, portanto, prazos,
metas e o controle gerencial negociados; independentemente
de as equipes de cada organizao estarem em um mesmo
local ou de trabalharem distribudas.
A tipologia a ser empregada neste trabalho utiliza, por-
tanto, quatro classificaes, conforme apresentadas na
Figura 1.
A literatura sobre projetos colaborativos de desenvolvi-
mento de produtos tradicionalmente aborda os projetos do
tipo Colaborativo-Distribudos (KVAN, 2000; NAOUM, 2003;
e HUSTON e SAKKAB, 2006).
Este artigo ocupa-se dos problemas e limitaes dessa te-
oria. Foram observadas crticas e desafios em dois tipos de
literatura: nos trabalhos sobre gerenciamento colaborativo
de projetos de produtos e na literatura sobre gerenciamento
de projetos em geral.
M etodologias geis
Sntese dos desafios no gerenciamento de projetos colaborativos
Dodgson (1992) afirmava que a interao entre os parceiros
era um ponto crtico no desenvolvimento de projetos (DODG-
SON, 1992). Esses problemas ainda so perceptveis. Moody e
Dodgson (2006) apresentam um estudo de caso de um projeto
complexo de desenvolvimento de satlite que envolveu a cola-
borao de vrias organizaes. Uma das concluses do estudo
que a influncia da liderana significativamente maior se
comparada aos projetos tradicionais. Ela fundamental para
garantir uma interao suficiente entre as equipes das dife-
rentes organizaes.
No comeo da atual dcada, Kerzner (2002) afirmou que
com as constantes fuses e aquisies de empresas, o ge-
renciamento de projetos multinacionais ser um dos grandes
desafios desta dcada, pois existem muitas dificuldades
inerentes s fronteiras organizacionais (BARNES, PASHBY e
GIBBONS, 2006).
Pesquisas sobre projetos colaborativos de engenharia apre-
sentam alguns fatores que os impedem de atingirem seus
objetivos (HAMERI e PUITTINEN, 2003):
Falta de informao sobre o que as outras equipes do projeto
esto fazendo (progresso das tarefas);
Falha no controle de mudana do projeto;
Vises diferentes sobre os objetivos do projeto;
Rigidez no planejamento do projeto e das rotinas;
Reaes pouco produtivas em relao s mudanas repenti-
nas no ambiente do projeto;
Dificuldades tecnolgicas inesperadas.
Barnes, Pashby e Gibbons (2006) realizaram uma reviso da
literatura e identificaram os fatores de sucesso dos projetos
colaborativos no caso indstria-indstria:
Objetivos claramente definidos;
Responsabilidades claramente definidas;
Plano de projeto aceito pelas partes;
Recursos adequados;
Marcos de projeto definidos;
Monitoramento regular do progresso;
Comunicao efetiva;
Entrega garantida dos colaboradores.
Pode-se notar que existe um alinhamento dos fatores cr-
ticos de sucessos observados por Barnes, Pashby e Gibbons
(2006) com os fatores que impedem o alcance dos objetivos
de um projeto, por Hameri e Puittinen (2003), apresentados
na Tabela 1.
Fatores de Hameri e Puittinen (2003) Fatores de Barnes, Pashby e Gibbons (2006)
Falta de informao sobre o que as outras
Comunicao efetiva
equipes do projeto esto fazendo
Vises diferentes sobre os objetivos do
Objetivos claramente definidos
projeto
Plano de Projeto aceito pelas partes, recursos
Falha no controle de mudana do projeto
adequados.
Tabela 1. Alinhamento de fatores para sucesso de um projeto colaborativo
Edio 19 - Engenharia de Software Magazine 7
 Portanto, para tentar superar os desafios existentes, o ge-
renciamento de projetos colaborativos necessita do apoio de
ferramentas que privilegiem a comunicao, a atualizao
das informaes e um controle da progresso das atividades
regulado por entregas efetivas.
Desafios do gerenciamento de projetos e o
gerenciamento gil de projetos
Crticas aos mtodos tradicionais de gerenciamento de projetos
A teoria tradicional de gerenciamento de projetos recebeu
grande ateno no incio dos anos 90 com a publicao de
padres de corpos de conhecimentos pelas associaes pro-
fissionais de gerenciamento de projetos. O mais difundido a
proposta pelo Project Management Institute (PMBOK, 2004). Esse
padro prope a descrio dos conceitos em um conjunto de
processos do gerenciamento de projetos. Esses processos so
organizados em reas do Conhecimento. So nove reas do
conhecimento: Integrao, Escopo, Tempo, Custos, Qualidade,
Recursos Humanos, Comunicao, Riscos e Aquisies. E
consideram cinco grupos de processo: Iniciao, Planejamento,
Execuo, Controle e Encerramento. Essas reas e grupos de
processo so empregados neste artigo, mas no sero descritos
em detalhe, pois h muitas referncias de fcil acesso sobre
o assunto, tais como: PMBOK (2004); Carvalho e Rabechini
(2005), entre outros.
No final dos anos 90, ao mesmo tempo em que houve uma
expanso na difuso e aplicao dos mtodos e tcnicas de
gerenciamento de projetos, surgiram abordagens alternativas
e propostas de modificao.
Uma das primeiras foi a atualmente conhecida como Teoria
da Corrente Crtica, proposta por Goldratt (2005). Trata-se
de uma modificao em alguns aspectos da teoria de geren-
ciamento de projetos, segundo os conceitos da Teoria das
Restries, desenvolvida pelo mesmo autor. Neste enfoque
gerencial, os problemas so analisados sempre sob o ponto de
vista da restrio. No caso do gerenciamento de projetos, tais
autores propem a realizao de planejamentos em quais os
recursos so programados segundo a capacidade mxima do
recurso-gargalo, isto , aquele com maior carga de trabalho.
Para faz-lo, os autores propem pequenas alteraes, intro-
duzindo conceitos como pulmo de projeto e recurso-tambor
(GOLDRATT, 2005).
Maylor (2001) afirma que muitas empresas que apresentam
excelncia em gerenciamento de projetos, em determinadas
reas de atividade no fazem uso da teoria tradicional de
gerenciamento de projetos. Empregam outras tcnicas e sim-
plificaes que no tm sido sistematicamente estudadas pelos
tericos da rea de gerenciamento e que, por isso, as tcnicas
teriam evoludo pouco nos ltimos 20 anos at 2001. As ques-
tes principais a serem estudadas, segundo o autor, seriam:
Relacionamento entre estratgia organizacional e a estra-
tgia na conduo dos projetos. Segundo o autor, a teoria
apresentaria um relacionamento fraco entre as duas estra-
tgias por haver poucos mtodos e tcnicas que relacionem
8 Engenharia de Software Magazine - Desafios para o gerenciamento gil de projetos colaborativos
estratgia organizacional, gerenciamento de portiflio (plano
agregado de projetos) e a definio e estratgias na conduo
dos projetos;
Medidas para avaliao dos projetos. Segundo o autor, o
enfoque tradicional mediria o sucesso do projeto em termos
apenas de cumprimento das metas do projeto: oramento,
escopo e restries de tempo. Questes como necessidade de
excelncia, melhoria contnua e superao das necessidades
dos clientes no estariam sendo tratadas;
Alterao do enfoque da manufatura para o enfoque de
servios. De acordo com o autor, o enfoque da teoria atual
ajusta-se aos padres e especificaes, comuns em um ambien-
te de grandes projetos, onde o mais importante o produto
fsico obtido, manufaturado. Atualmente, os servios seriam
to, ou mais, importantes. O grau de orientao ao cliente teria
que ser muito maior, fazendo com que a gesto das expecta-
tivas dos interessados (stakeholders), a percepo deles quanto
ao sucesso do projeto, seja fundamental para a avaliao do
resultado do projeto;
Foco na fase de execuo. O autor afirma que a fase de
execuo pouco desenvolvida na teoria de gerenciamento
de projetos e que muitos textos da rea parecem sugerir que
o planejamento e uso de sistemas de informao seriam sufi-
cientes para controle dos projetos;
Incertezas quanto s estimativas empregadas no plane-
jamento de projetos. O autor afirma que, para planejar um
projeto, necessrio que as estimativas possuam certo nvel de
confiana, que difcil de ser obtida. Na prtica, seria possvel
apenas em intervalos de curto prazo, diferentemente dos que so
utilizados no planejamento tradicional de projetos. Cita ainda,
neste aspecto, as crticas realizadas por Goldratt (2005)2;
Foco no Grfico de Gantt. Segundo o autor, haveria uma
valorizao e emprego excessivo do Grfico de Gantt na abor-
dagem tradicional. Na opinio deste, o grfico bem elaborado,
por meio do uso de ferramentas computacionais, teria como
efeito a criao de uma forte credibilidade e a iluso de que
h um bom plano de projeto; mesmo quando as atividades
e recursos no tenham sido bem definidos e/ou estimados.
Mais, o Grfico encorajaria uma abordagem de planejamento
de um nico passo, isto , sem o necessrio acompanhamento e
contnuo replanejamento. Em terceiro lugar, o Grfico de Gantt
encorajaria o gerente de projeto a controlar todas as atividades
do projeto, transferindo parte da responsabilidade da equipe
pelo controle de tempo. Segundo o autor, isso estaria levando
tendncia de transformar gerentes de projeto em operadores
de softwares computacionais, mais do que pessoas responsveis
pela discusso e negociao;
Uso de recursos alternativos de planejamento. O autor
cita um caso de uma empresa transnacional que obteve um
desempenho de excelncia em projetos de desenvolvimento de
produtos utilizando recursos como quadro branco e post-its.
Eles eram empregados para planejar o conjunto de projetos de
2 Referenciamos a edio em portugus. Maylor (2001) cita a referncia original
de 1997. Goldratt apud Maylor (2001).

maneira hbrida, com as ferramentas computacionais, onde os
colaboradores utilizavam softwares de planejamento de projetos
para subprojetos ou entregas especficas. O autor cita outro
caso de um gerente de projetos de construo civil em que
as ferramentas computacionais atuais, baseadas no Grfico
de Gantt e PERT/COM, foram consideradas inadequadas e
ultrapassadas.
Mais recentemente, em 2002, surgiu uma crtica que se tornou
conhecida como a teoria do Gerenciamento gil de Projetos
(Agile Project Management - APM). Trata-se do manifesto, lana-
do em 2001, conhecido como Manifesto gil. Ele foi elaborado
por profissionais da rea de desenvolvimento de software que
queriam melhorar o desempenho de seus projetos.
De acordo com esses autores, haveria cinco objetivos princi-
pais que consistiriam a base do APM (HIGHSMITH, 2004, p.
6): inovao contnua para entregar produtos que atendam
os requisitos atuais dos clientes; adaptabilidade do produto
para entregar produtos que atendam os requisitos futuros dos
clientes; tempo de entrega reduzido para encontrar novos
mercados e melhorar o retorno de investimento; capacidade
de adaptao do processo e das pessoas para responder
rapidamente s mudanas de negcios e produtos; e resul-
tados confiveis para apoiar o crescimento e aumento de
lucratividade.
Em 2003, foi fundado um projeto de pesquisa chamado de
Rethinking Project Management (2004-2006), apoiado pelo
Engineering and Physical Sciences Research Council (EPSRC) do
Reino Unido. Trata-se de um projeto em rede, desenvolvido
com o intuito de avaliar as idias dominantes da literatura de
gerenciamento de projetos e apresentar direes para futuras
pesquisas sobre o tema (WINTER et al., 2006).
O grupo identificou cinco principais linhas de pesquisa para
a melhoria do gerenciamento de projetos, que foram agrupadas
em trs sub-temas Teoria sobre Prtica (direo 1), Teoria para
Prtica (direes 2-4) e Teoria na Prtica (direo 5), demons-
trados na Figura 2 (WINTER et al., 2006).
Na Teoria sobre a Prtica, apresentada a necessidade do
desenvolvimento de novos modelos devido complexidade
dos projetos e do seu gerenciamento. Segundo os autores, os
modelos empregariam um padro de ciclo de vida fechado,
isto , previamente definido. A crtica que o aumento da
complexidade exigiria modelos de ciclo de vida mais flexveis,
e pesquisas neste sentido deveriam ser conduzidas. Para os au-
tores, os novos modelos precisaro demonstrar a realidade das
prticas de GP, que procuram atender a um ambiente dinmico,
de rpidas mudanas e altos riscos (WINTER et al., 2006).
A segunda linha de pesquisa identificada foi chamada de
Teoria para Prtica. Na viso dos autores, os projetos so em
geral imprevisveis e multidimensionais, mais complexos que
os modelos racionais e determinsticos, que predominariam
na literatura de GP. Assim, aprimoramentos que possam con-
siderar de forma mais eficiente os aspectos, como a mudana
contnua do fluxo de eventos, os efeitos da interao social e
da ao humana. As interaes entre organizaes e relaes na sua gnese, em sua complexidade estrutural e tecnolgica,
M etodologias geis
entre diferentes grupos com interesses diferentes fazem parte
dessa direo (WINTER et al., 2006).
A terceira linha de pesquisa destaca a mudana de foco na
criao do produto para a criao do valor. As metodologias
que focam a produo de um produto fsico ou de um sistema
mudam para a entrega de um valor e no unicamente de
um produto. Por exemplo, o foco pode estar na estratgia de
escolha de um projeto de um produto que seja relacionado
com as estratgias de negcio da organizao, permanecendo
o valor do projeto mesmo aps a entrega do produto (WINTER
et al., 2006).
A linha de pesquisa 4, ainda na Teoria para Prtica, apresenta
a mudana de concepo estreita do projeto para uma ampla
concepo dele. Isso quer dizer entender o projeto do produto
mais do que simples aes para criar um objeto fsico, olhar
para ele de vrias perspectivas e, assim, criar um conjunto de
imagens que podem indicar novas idias e formas de gerenciar
projetos (WINTER et al., 2006).
A ltima linha de pesquisa, Teoria na Prtica, diz que os
praticantes de GP no devem ser apenas tcnicos treinados nos
procedimentos e ferramentas de GP, mas devem ser praticantes
reflexivos e crticos, que aprendem e aplicam suas experincias
no desenvolvimento de um projeto (WINTER et al., 2006).
Teoria sobre Prtica
Direo 1
Modelo de Ciclo de Vida de GP Teorias da Complexidade de GP
Teoria para Prtica
Direo 2
Projetos como Processo Instrumental Projetos como Processo Social
Direo 3
Foco na Criao do Produto Foco na Criao do Valor
Direo 4
Concepo Estreita dos Projetos Concepo Ampla dos Projetos
Teoria na Prtica
Direo 5
Praticantes como Tcnicos Treinados Praticantes como Praticantes Crticos
Figura 2. Linhas para futuras pesquisas em GP (Fonte: adaptado de
Winter et al. (2006))
Trs fatores so identificados por Cicmil et al. (2006) que
causam atropelamento na execuo dos projetos, quando
esses so gerenciados pelo modelo clssico:
Complexidade estrutural do produto;
Mudanas devido ao desconhecimento de atividades e aes
necessrias;
Tempo restrito para execuo das atividades.
Ento, o projeto de um produto de alta complexidade possui
Edio 19 - Engenharia de Software Magazine 9
uma fonte de incertezas que dificulta a sua execuo. O planeja-
mento do tempo , portanto, impreciso, e, como conseqncia,
muitas vezes h restrio dele para execuo das atividades. Os
gerentes de projeto so forados a tomar aes paliativas, que
acelerem o ritmo do projeto e podem gerar novos problemas
(CICMIL et al., 2006). Dessa forma, cria-se um crculo vicioso
difcil de romper.
Winter et al. (2006) propem que se deve aprofundar a pesquisa
em tcnicas e mtodos, visando o desenvolvimento de solues
capazes de gerenciar a complexidade. Essa idia prxima da
proposta de Highsmith (2004) e demais autores do Gerencia-
mento gil de Projetos, que criticam os mtodos tradicionais
de gerenciamento de projetos por no conseguirem lidar com
o ambiente de incerteza, gerado pela complexidade dos proje-
tos atuais. A soluo, segundo os autores, seria a utilizao de
equipes auto gerenciadas e flexveis. No h dvida, portanto,
da concordncia dos autores de que a teoria tradicional, dita
clssica, no seria til para projetos de alta complexidade, com
alto grau de inovao e envolvendo diferentes organizaes.
Em um exemplo de gerenciamento de um projeto de alta com-
plexidade, descrito por Moody e Dodgson (2006), observou-se
que as tarefas so continuamente ajustadas e redefinidas con-
forme o projeto se desenvolve, sendo necessria a adaptao
constante do planejamento das atividades. A interao cons-
tante entre os colaboradores, mais informal e independente
da posio hierrquica, tambm foi observada como mais
adequada. Desta forma, segundo Moody e Dodgson (2006),
os mtodos para o gerenciamento do projeto devem ser adap-
tados, de forma a atender essas necessidades de flexibilidade,
corroborando as opinies de Winter et al. (2006) e dos autores
do Gerenciamento gil.
A contribuio do grupo de pesquisa Rethinking Project
Management importante, porm, limita-se a criticar a teoria.
Esses autores no propem solues prticas, como mtodos,
tcnicas ou ferramentas. J os autores do Gerenciamento gil
de Projetos propem solues que visam formar um novo cor-
po terico, segundo eles, uma nova abordagem para o geren-
ciamento de projetos e que se distinguiria fundamentalmente
da abordagem tradicional. Nas prximas sees, analisa-se de
maneira crtica os conceitos e mtodos propostos pelos autores
do Gerenciamento gil de Projetos. Pelo mesmo motivo, optou-
se por utilizar o termo Gerenciamento gil de Projetos para
diferenciar do gerenciamento clssico de projetos.
Definio do gerenciamento gil de projetos
As empresas de software operam em um ambiente de rpidas
mudanas e altos riscos. O gerenciamento de projetos funda-
mental, porm sua introduo no havia sido fcil, devido ao que
se considerava como rigidez e foco excessivo no planejamento. Em
2001, lanou-se o Manifesto Agile for Software Development (BECK
et al., 2001), que procura enfatizar o uso dos mtodos chamados
de geis, voltado para a colaborao com o cliente, nos indivduos
e respostas rpidas s mudanas. Alguns exemplos desses mto-
dos geis, aplicados para o desenvolvimento de softwares, so o
Extreme Programming (XP), Scrum e Crystal Methods.
10 Engenharia de Software Magazine - Desafios para o gerenciamento gil de projetos colaborativos
Outras indstrias passaram a adotar prticas denominadas
de geis, criando adaptaes nos mtodos e tcnicas de Geren-
ciamento Clssico de Projetos, para suprir suas necessidades
no gerenciamento de projetos complexos. Mas, muitas vezes,
essas adaptaes apresentam restries devido aos mtodos e
tcnicas do Gerenciamento Clssico e podem apresentar um
desempenho ruim, com reduo da eficincia e eficcia dos
resultados (CHIN, 2004).
Chin (2004), ento, prope o que ele denomina de uma nova
abordagem para o gerenciamento de projetos, quebrando a vi-
so do forte planejamento prvio das atividades. Assim, temos
o incio do Agile Project Management (APM) ou Gerenciamento
gil de Projetos.
O APM foi definido por Highsmith (2004) como []... um
conjunto de valores, princpios e prticas que auxiliam a equi-
pe a entregar produtos ou servios de valor em um ambiente
desafiador.
A Figura 3 mostra esquematicamente a distino entre as
duas abordagens. A base de tijolos representa a eficincia,
eficcia de uma plataforma de gerenciamento de projetos. Esta
figura tem por objetivo transmitir a mensagem de que a teoria
clssica necessitaria de uma dedicao maior em atividades
exclusivas de gerenciamento (base maior). Ao passo que no
gerenciamento gil, parte dessas atividades so substitudas
por autocontrole da equipe ou atenuadas por meio do emprego
de tcnicas simplificadas e visuais.
Figura 3. Relacionamento entre as abordagens clssica e gil de
gerenciamento de projetos (Fonte: CHIN, 2004, p. 3)
A Figura 3 no suficiente para descrever as diferenas
entre as abordagens gil e clssica. Uma forma de faz-lo
descrevendo os objetivos, valores e princpios.
Objetivos, valores, princpios e fases do GP gil
So cinco os objetivos principais para um bom processo de
explorao do APM (HIGHSMITH, 2004, p. 6):
1. Inovao contnua. Um dos objetivos bsicos do APM entre-
gar produtos que atendam aos requisitos atuais dos clientes de
maneira inovadora. A gerao de idias inovadoras no ocorreria
em ambientes autoritrios e burocraticamente estruturados,
isto , com regras bem definidas e tarefas cuidadosamente
planejadas. Mas, sim, em ambientes que eles denominam de
adaptativos, onde a inovao e novas solues so priorizadas.
Segundo esses tericos, as prticas como o planejamento prvio
e detalhado das atividades de cada membro e atribuio do

controle dos projetos para estruturas organizacionais especfi-
cas estimulariam o comportamento individualista e inibiriam
a proposio de idias inovadoras e o envolvimento da equipe
em tarefas como planejamento e controle;
2. Adaptabilidade do produto. Segundo os autores da rea,
o APM busca entregar produtos que atendam os requisitos
futuros dos clientes. As prticas geis integram o custo de
mudanas como parte do processo de desenvolvimento, para
atender as mudanas do mercado. Na teoria clssica, o produto
definido com todas as suas caractersticas no incio do projeto,
gerando o planejamento detalhado de todas as atividades. Des-
sa forma, alterar uma caracterstica do produto para atender
a um requisito, por exemplo, pode se tornar uma barreira. O
resultado que os integrantes podem adiar demasiadamente
as mudanas, gerando custos diretos mais elevados, conse-
qentemente, prejuzo para a organizao e o cliente;
3. Tempo de entrega reduzido. O APM tem o objetivo de
encontrar novos mercados e melhorar o retorno de investi-
mento. A principal idia a iteratividade, gerando entregas
de curto prazo. Sugere-se que equipes pequenas e qualifica-
das poderiam manter ateno constante nas caractersticas
do produto e foco no curto prazo. Elas deveriam tambm
considerar cuidadosamente quais caractersticas devem ser
includas no produto e criar, assim, um processo de desen-
volvimento concentrado em atividades que agregam valor. A
crtica subentendida, que no explicitamente apresentada por
Highsmith (2004), a de que a teoria de GP tradicional incenti-
varia planejamentos detalhados e de longo prazo, diminuindo
o senso de urgncia e distanciando a equipe do foco no valor
agregado pelas atividades;
4. Capacidade de adaptao do processo e das pessoas. O
APM procura responder rapidamente s mudanas de neg-
cios e produtos. A meta proposta pelo autor que os membros
da equipe no resistam s mudanas no decorrer do projeto,
mas entendam que os produtos podem ser modificados ao
longo do seu desenvolvimento. As equipes tambm precisam
ser receptivas s novas idias. A crtica ao gerenciamento
de projetos clssico a de que a especializao e distancia-
mento dos membros da equipe fazem com que resistam s
mudanas na forma como conduzir as atividades de projeto,
isto , tenderiam a replicar formas de conduta realizadas em
projetos anteriores. E que prticas como controle de mudana
e verificao desestimulariam alteraes nos projetos nas fases
iniciais, gerando problemas futuros. Especialmente no caso de
projetos inovadores em que, segundo o autor, tais mudanas
so necessrias;
5. Resultados confiveis. O APM possui o objetivo de apoiar
o crescimento e aumento de lucratividade do negcio. O
processo de desenvolvimento deve medir a importncia da
entrega para o cliente ou se a entrega est compatvel com o
custo e o tempo estabelecidos para o projeto. Na teoria cls-
sica, como dito anteriormente, o foco est no planejamento
e controle, com nfase na documentao e atividades. Isso
diminui a preocupao com o valor efetivo. J no enfoque
gil, a maior preocupao com o cliente, deixando em
M etodologias geis
segundo plano as metas definidas para o projeto, j que
o cliente quem vai indicar o sucesso do projeto pelo seu
nvel de satisfao. Com isso, mais do que se preocupar com
a satisfao de metas previamente estipuladas, os membros
das equipes estariam preocupados se os resultados esto
de acordo com as expectativas do cliente: uma anlise mais
qualitativa, portanto.
Alm dos objetivos, os autores de APM descrevem um
conjunto de valores e princpios que norteiam o desenvol-
vimento de suas atividades, e que, em tese, habilitariam os
gerentes de projetos a alcanar o desenvolvimento de produtos
inovadores.
Os quatro valores descritos no Manifesto Agile for Software
Development so tambm os valores centrais nos textos de
Gerenciamento gil de Projetos (HIGHSMITH, 2004):
1. Respostas s mudanas: as respostas s mudanas so mais
importantes do que seguir um plano previamente definido;
2. Entrega de produtos: a entrega de produtos mais impor-
tante do que a entrega da documentao;
3. Colaborao do cliente: a colaborao do cliente mais
importante do que a negociao de contratos;
4. Indivduos e interaes: os indivduos e suas interaes so
mais importantes que os processos e ferramentas.
O APM foca nos clientes, produtos e pessoas. Ele visa agre-
gar valor e procura gerar produtos adaptados s necessidades
e visa unir as pessoas em torno de um trabalho efetivamente
colaborativo (HIGHSMITH, 2004).
Cockburn e Highsmith (2001) afirmam que um gerente de
projeto tradicional preocupa-se principalmente com o contra-
to inicial e com o sistema em si, avaliando-os principalmente
nos parmetros tempo e custo. J um gerente gil de projeto
preocupa-se em ajustar continuamente os resultados por meio
de uma relao colaborativa com os clientes.
So seis os princpios do APM, divididos em duas categorias.
A primeira relacionada ao produto/cliente e a segunda, ao
gerenciamento (HIGHSMITH, 2004). Esses princpios e seus
relacionamentos esto apresentados na Figura 4.
Figura 4. Princpios do Gerenciamento gil de Projetos (Fonte: HIGHSMITH,
2004, p. 28)
Edio 19 - Engenharia de Software Magazine 11
 Esses princpios possuem pontos importantes para a caracte-
rizao do APM, tais como a gerao de entregas iterativas, que
incluem o pressuposto de que um projeto possa ser estruturado
em iteraes curtas e de perodo fixo, e a construo de equipes
adaptativas, que possuem formao varivel, de acordo com as
necessidades e mudanas necessrias durante o desenvolvimen-
to do projeto, ajustando-se s variaes do ambiente.
Apesar de o APM enfatizar as pessoas frente ao processo, os
prprios autores enfatizam que o processo de negcio no deve
ser ignorado. Highsmith (2004) afirma que o processo, como
qualquer outro elemento da organizao, deve estar totalmente
alinhado com os objetivos de negcio.
Mas, se a plataforma gil voltada adaptao, flexibilidade
e aprendizado, ento seus processos devem contemplar essas
caractersticas, que definem seu ciclo de vida e fases. So cinco
as fases do Gerenciamento gil de Projetos e esto apresenta-
das na Figura 5 (HIGHSMITH, 2004, p. 81).
Figura 5. Plataforma do Processo de Gerenciamento gil de Projetos
(Fonte: Adaptado de Highsmith, 2004, p. 81)
1. Viso: determinao da viso do produto e do escopo do
projeto, identificao da comunidade participante do projeto e
definio de como a equipe do projeto trabalhar em conjunto.
A principal diferena entre o escopo, derivado da prtica clssica,
e a viso, da prtica gil, est na nfase no produto. A descrio
principal que se faz na viso a das especificaes do produto,
primando pela simplificao da documentao, que deve fornecer
uma descrio de alto nvel do produto para os desenvolvedores,
de forma a facilitar a especulao e explorao. Acredita-se que
isso levaria a um envolvimento maior com o cliente do que nas
prticas clssicas de iniciao do projeto, devido ao enfoque con-
tratual (obteno de regras e leis) em linguagem textual;
2. Especulao: planejamento preliminar, que ser seguido por
planejamentos especficos detalhados a cada iterao. Consiste
na identificao dos requisitos para o produto, desenvolvi-
mento de um plano de projeto, contendo entregas, marcos,
iteraes, cronograma de trabalho e alocao de recursos,
incorporao de estratgias para mitigao de riscos e esti-
mativas de custos e outras informaes financeiras relevantes.
12 Engenharia de Software Magazine - Desafios para o gerenciamento gil de projetos colaborativos
Uma grande diferena da explorao gil para o planejamento
clssico o nvel de detalhe. Aqui, o planejamento s feito
at um futuro previsvel, onde colocado um prximo marco
ou ponto de deciso, evitando assim riscos de planejamentos
de longo prazo. A fase repete-se ao longo do projeto quantas
vezes for necessrio;
3. Explorao: composta de trs atividades crticas. A primeira
a entrega dos produtos planejados, atravs do gerenciamento
da carga de trabalho. A segunda a criao de uma comuni-
dade auto organizada do projeto e a terceira, o gerenciamento
das interaes das equipes com os clientes, gerente de projeto
e stakeholders, que so as partes interessadas no projeto.
Nesta fase, o autocontrole um diferencial. A proposta que
a comunidade do projeto esteja comprometida em realizar as
entregas e no sejam apenas participantes passivos, aguardan-
do ordens para cumprir tarefas. Eles ajudam a gerenciar sua
carga de trabalho da melhor maneira, contando com a ajuda
do gerente do projeto e no esperando que esse ltimo tome
todas as decises necessrias para entregar o produto ao cliente
e apresentar os resultados aos stakeholders;
4. Adaptao: reviso dos resultados entregues, anlise da
situao atual, avaliao do desempenho da equipe de projeto
e mudanas, se necessrias. Essa reviso considera tambm,
alm da comparao do realizado versus o planejado, o reali-
zado versus informaes e requisitos atualizados do projeto.
Esta fase, junto com a especulao e explorao, ocorre vrias
vezes durante o projeto e envolve o esforo no s do gerente
do projeto, mas de toda a comunidade. Ela caracteriza os
vrios ciclos de mudanas que ocorrem ao longo do projeto
para suprir as demandas atuais e atingir o sucesso do projeto.
Nas prticas clssicas, o planejamento detalhado, que feito
no incio do projeto, inibe adaptaes necessrias, conforme
apresentado nos objetivos do gil. Aqui o objetivo adaptar o
projeto segundo as necessidades atuais, incentivando a equipe
do projeto a ter um esprito crtico e participar da prxima
especulao do projeto;
5. Encerramento: finalizao das atividades do projeto, transfe-
rncia dos aprendizados-chave e celebrao. Como ltima fase,
aps uma adaptao onde no so identificados mais requisitos
e realizadas as avaliaes de entregas e status do realizado
versus planejado, o projeto pode ser encerrado. Aqui as prticas
geis e clssicas so idnticas. Nos dois casos realizado um
histrico do projeto para possveis consultas futuras.
A Tabela 2 apresenta uma correspondncia entre os prin-
cipais grupos de processo da plataforma Clssica de GP e as
fases do APM.
Segundo Chin (2004), uma estrutura que apie as prticas
de GP indicada e pode trazer benefcios. O mesmo autor
prope que essa estrutura deve incluir: processos, prticas,
ferramentas de software, modelos de documentos e formu-
lrios, representados na Figura 6, com as suas interaes.
Esses elementos auxiliariam na elaborao de relatrios e
documentos contendo informaes valiosas para a tomada
de deciso no projeto. Highsmith (2004) enfatiza que os

relatrios de status de projeto devem adicionar valor para o
gerente do projeto, gerente de produto, stakeholders e para a
prpria equipe de projeto.
Analisando-se a estrutura operacional de Chin (2004), pos-
svel reconhecer uma significativa influncia com os modelos
de estruturas para gerenciamento tradicional de projetos, tais
como escritrios de projetos e modelos de gesto de projetos.
Notem-se as definies de responsabilidades, cronogramas,
uso de padres. Isso se explica na premissa de que a proposta
dos tericos do gil no significa negligenciar controles, planos
e padronizao.
Grupo de Processos da GP Clssica Fases do GP gil
Iniciao: autorizao/definio de um escopo Viso: do produto e escopo inicial do projeto
preliminar
Planejamento: detalhamento de todo projeto Especulao: plano inicial, planejamento a cada
iterao
Execuo: execuo do plano do projeto Explorao: entrega funcionalidade/produto a
cada ciclo
Monitoramento e Controle: progresso do Adaptao: reviso dos resultados entregues e
trabalho e gerenciamento de mudanas adaptaes do escopo
Encerramento: Formalizao do aceite final do Encerramento: aceites do cliente a cada ciclo e
projeto formalizao final
Tabela 2. Correspondncia entre as abordagens clssica e gil de GP
(Fonte: Dias (2005)
Figura 6. Estrutura operacional para apoio ao gerenciamento gil de
projetos (Fonte: Adaptado de CHIN, 2004 p. 166)
A anlise leva a crer que a proposta desses autores mant-
los, porm com uma diferena na forma de aplicao desses
conceitos. Trata-se, portanto, de uma proposta de processos
de gerenciamento de projetos que busca procedimentos mais
simples por meio das estratgias como: emprego de quadros e
elementos visuais; eliminao de atividades de gerenciamento
que no agregam valor; e transferncia de mecanismos de
controles burocrticos para a equipe, por meio da autogesto
(HIGHSMITH, 2004 e CHIN, 2004).
Em virtude dessa anlise que se convencionou neste artigo
o uso do termo enfoque para designar o APM, em lugar do
M etodologias geis
termo paradigma, amplamente empregado pelos tericos do
APM. A palavra enfoque remete a modelo, padro3. Portanto,
dizer novo paradigma parece representar uma forma totalmen-
te inovadora de se gerenciar projeto. Enfoque, ao contrrio, sig-
nificaria uma nova forma de utilizar as ferramentas existentes.
A reviso aqui apresentada permite concluir que as propostas
dos autores de APM representam mais uma especializao da
teoria de gerenciamento de projetos, para um caso especfico,
que o de projetos complexos e de produtos inovadores.
Aplicabilidade do gerenciamento gil de projetos
A comunidade de desenvolvimento de software foi a primeira
a adotar na prtica os conceitos do gerenciamento gil em seus
projetos. A literatura sobre o tema principalmente constituda
de casos nessa rea (BECK, 1998; BOEHM, 2002; COCKBURN,
2002; COHN e FORD, 2003; FOWLER, 2000; AUGUSTINE e
WOODCOCK, 2003).
Chin (2004) e Highsmith (2004) indicam o uso do gerencia-
mento gil para projetos tambm para o desenvolvimento de
produtos manufaturados, desde que com aspectos inovadores
e em ambientes competitivos. A Figura 7 apresenta os poss-
veis ambientes de projeto para aplicao da abordagem gil,
segundo Highsmith (2004).
Figura 7. Ambientes para aplicao do enfoque gil (Fonte: adaptado de
Highsmith (2004) por Conforto e Amaral (2007))
A aplicao do gerenciamento gil no desenvolvimento
de produtos fsicos ainda est em fase de estudos. Benassi e
Amaral (2007) e Conforto e Amaral (2007) apresentam anli-
ses tericas da aplicao do APM para o desenvolvimento de
produtos. Benassi e Amaral (2007) revisaram a literatura sobre
gerenciamento de projetos e identificaram apenas um trabalho
de aplicaes do APM fora do contexto de software. Mais, os
trabalhos identificados so em sua totalidade tericos. Portan-
to, no h dados efetivos de campo, verificando a aplicao
3 Segundo Larousse (1992), paradigma um substantivo que designa modelo,
padro ou norma. O mesmo dicionrio fornece o significado de enfoque como
ao de enfocar, modo de considerar ou entender um assunto ou questo.
Edio 19 - Engenharia de Software Magazine 13
desses mtodos. Mesmo tendo se passado vrios anos desde
que Maylor (2001) apresentou a mesma dificuldade.
Concluso - Sntese dos desafios encontrados
O tpico Desafios no gerenciamento de projetos colabora-
tivos apresentou as crticas realizadas pelos tericos da rea
de gerenciamento de projetos e tambm pelos autores do
enfoque gil. A anlise dos trabalhos permite mostrar uma
convergncia em termos de crticas teoria de gerenciamento
de projetos. Conforme ilustrado na Figura 8, as direes de
pesquisa apontadas no estudo de Winter et al. (2006) so coe-
rentes com as idias propostas no enfoque gil.
Figura 8. Coerncia entre as direes do EPSRC e idias do enfoque
gil (Fonte: elaborado pela autora, com base em Winter et al. (2006) e
Highsmith (2004))
A partir da literatura analisada, podem-se identificar, alm
da convergncia das crticas, os principais desafios:
a) Falta de modelos e tcnicas capazes de adequar-se s
mudanas dos projetos. Existe a necessidade de tcnicas e
mtodos para o planejamento e controle capazes de: aumentar
a velocidade da elaborao de planos e sua atualizao; criar
tcnicas de planejamento com planos mais sintticos, sem
perder a preciso e efetividade; criar sistemas de controle
que sejam mais rpidos na identificao das necessidades
de mudana;
b) Falta de modelos e tcnicas que apiem o acompanhamen-
to e alteraes constantes no resultado final. Em virtude das
maiores mudanas, devem-se criar solues para aprimorar o
acompanhamento dos resultados no produto do projeto. As-
sim, preciso criar tcnicas de gerenciamento de requisitos e
controles de configurao do produto;
c) Compartilhamento efetivo de recursos. As tcnicas tradi-
cionais priorizam o gerenciamento centralizado de dados de
recursos, por meio da criao de pools de recursos. Em projetos
compartilhados ou onde competncias so identificadas no
decorrer do projeto, geram-se problemas. necessrio criar
tcnicas e mtodos que facilitem o planejamento de recur-
sos compartilhados entre projetos de diferentes nveis de
complexidade.
d) Consumo de tempo em extensa documentao do projeto.
A padronizao, sem dvida, algo importante. O desafio,
14 Engenharia de Software Magazine - Desafios para o gerenciamento gil de projetos colaborativos
ento, realiz-la de forma adequada, garantindo que ela seja o
suficiente para agregar valor ao projeto. Formas mais simples,
rpidas e eficientes de documentao e criao dos padres so
fundamentais. Outro desafio combinar a utilizao de pa-
dres com a melhoria contnua, isto , a atualizao constante
desses padres de forma a garantir a introduo de melhorias
conforme as experincias em projetos anteriores;
e) Implantar tcnicas que permitam o emprego dos princpios
propostos pelo gerenciamento gil de projetos. Conforme
demonstrado, embora os tericos do gerenciamento gil de
projetos tenham proposto um conjunto bem organizado de
princpios, h falta de mtodos e tcnicas que permitam utiliz-
los. Ou, ento, a identificao de como adaptar os mtodos e
tcnicas atuais. Os principais desafios so: foco nas pessoas;
equipes auto gerenciadas e flexveis; criao de valor para o
cliente; explorao e adaptabilidade do produto; capacidade
de adaptao do processo e das pessoas.
A Figura 9 apresenta uma sntese dos desafios identificados
na literatura de gerenciamento de projetos e na de gerencia-
mento gil. Identifica tambm a relao entre eles, por meio de
flechas, que indicam quais os desafios so equivalentes.
Figura 9. Sntese e relao entre os desafios encontrados na
literatura (Fonte: elaborada pela autora)
Agradecimentos
Meus agradecimentos ao professor doutor Daniel Capaldo
Amaral (EESC;USP), pela orientao durante o desenvolvi-
mento deste trabalho. Agradeo tambm CAPES pelo apoio
financeiro e Escola de Engenharia de So Carlos (EESC, USP)
pela infra-estrutura.
D seu feedback sobre esta edio! 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
edio
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback

Referncias Bibliogrficas
AMARAL, D. C. Colaborao cliente-fornecedor no processo de desenvolvimento de produtos: estudos de
caso na indstria automobilstica: escopo, integrao e qualidade do produto. Dissertao (Mestrado em with Maximum Potential to Create Value. Journal of Product Innovation Management, v.23, n.4, p. 330-
Engenharia de Produo). Universidade Federal de So Carlos, So Carlos, 1997.
AMARAL, D. C.; TOLEDO, J. C. Colaborao cliente-fornecedor no processo de desenvolvimento de produto.
Gesto & Produo, So Carlos, v. 7, n. 1, p. 56-72, abril, 2000.
AUGUSTINE, S.; WOODCOCK, S. Agile project management: emergent order through visionary leadership.
May, 2003. Disponvel em: <http:ccpace.com/resources/AgileProjectManagement.pdf>. Acesso em: 26
jan. 2007.
BARNES, T. A.; PASHBY, I. R.; GIBBONS, A. M. Managing collaborative R&D projects development of a
practical management tool. International Journal of Project Management, vol. 24, n 5, p. 395404,
julho, 2006.
BECK, K. et al. Manifesto for agile software development. 2001. Disponvel em <http://www.
agilemanifesto.org>. Acesso em janeiro, 2007.
BECK, K.et al. Chrysler goes to extremes.Out., 1998. Disponvel em <http://www.xprogramming.com/
publications/dc9810cs.pdf > Acesso em: 16 jan. 2007.
BENASSI, J. L. G.; AMARAL, D. C. GERENCIAMENTO GIL DE PROJETOS APLICADO AO DESENVOLVIMENTO DE
PRODUTO FSICO. In: XIV Simpsio de Engenharia de Produo, 2007, Bauru. Anais... Bauru: FEB, 2007.
BOEHM, B. Get ready for agile methods, with care. IEEE Computer Magazine, [S.l], p. 64-69, 2002.
CAMARINHA-MATOS, L. M. et al. Rough reference model for Collaborative Networks. Disponvel em <
http://www.ve-forum.org/projects/284/Deliverables/D52.2_Final.pdf >. Acesso em dez. 2006.
CHIN, G. Agile Project Management: how to succeed in the face of changing project requirements. NY:
Amacon, 2004.
CICMIL, S. et al. Rethinking Project Management: Researching the actuality of projects. International
Journal of Project Management, v. 24, n. 8, p. 675-686, novembro, 2006.
COCKBURN, A. Agile software development joins the would-be crowd. Disponvel em: <http://www.
agilealliance.org/system/article/file/782/file.pdf> Acesso em: 17 jan. 2007.
COCKBURN, A.; HIGHSMITH, J. Agile software development, the people factor. Computer, vol. 34, n 11,
p.131 133, novembro, 2001.
COHN, M., FORD, D. Introducing an agile process to an organization. IEEE Computer Magazine, June 2003,
[S.l.], p. 74-78.
CONFORTO, E. C.; AMARAL, D. C. Escritrio de Projetos e Gerenciamento gil: Um Novo Enfoque para a
Estrutura de Apoio Gesto de Projetos geis. In: XXVII Encontro Nacional de Engenharia de Produo,
2007, Foz do Iguau. Anais... Foz do Iguau: ABEPRO, 2007.
DAVIS, J. M.; KEYS, L K.; CHEN. I. J. Collaborative Engineering for Research and Development. 13th
International Conference on Management of Technology. AnaisWashington, DC, April 37, 2004.
DIAS, M. V. B. Um novo enfoque para o gerenciamento de projetos de desenvolvimento de software.
Dissertao (Mestrado em Administrao). Faculdade de Economia, Administrao e Contabilidade,
Universidade de So Paulo, So Paulo, 2005.
DODGSON, M.The future for technological collaboration. Futures, p. 459-470, junho, 1992.
M etodologias geis
EMDEN, Z.; CALANTONE, R.; DROGE, C. Collaborating for New Product Development: Selecting the Partner
341, 2006.
EVARISTO, R.; FENEMA P.C. A typology of project management: emergence and evolution of new forms.
International Journal of Project Management, v.17, n.5, p.275- 281, outubro, 1999.
FOWLER, M.The new methodology. Jul., 2000. Disponvel em <http://www.martinfowler.com/articles/
newMethodologyOriginal.html> Acesso em: 24 jan. 2007.
GOLDRATT, E. M. Corrente Crtica. Editora Nobel, Brasil: So Paulo, 2005.
HAMERI, A. PUITTINEN, R.WWW-enabled knowledge management for distributed engineering projects.
Computers in Industry, vol. 50, n. 2, p. 165-177, fevereiro, 2003.
HIGHSMITH, J. Agile Project Management: Creating Innovative Products. Boston: Adison-Wesley, 2004.
HUSTON, L.; SAKKAB, N. Connect and develop: inside Procter & Gambles new model for innovation.
Harvard business review, fevereiro, 2006.
KATZ, J.S.; MARTIN, B.R.What is research collaboration? Research Policy, v.26 , n. 1, pp. 118, maro, 1997.
KERZNER, H. Gesto de projetos: as melhores prticas. Traduo de Marco Antonio Viana Borges et al.
Porto Alegre: Ed. Bookman, 2002.
KODAMA, M. Innovation and knowledge creation through leadership-based stratregic community: case
study on high-tech company in Japan.Technovation,v.27, n.3,p. 115-132, maro, 2007.
KVAN,T. Collaborative design: what is it? Automation in Construction, v.9, n. 4,p. 409-415, julho, 2000.
MATTESSICH, P. W.; MONSEY, B. R. Collaboration: What makes it work. A review of research literature on
factors influencing successful collaboration. St. Paul, MN: Amherst H.Wilder Foundation, 1992.
MAYLOR, H. Beyound the Gantt Chart: project management moving on. Business Management Journal,
v.19, n.1, pp.92-100, 2001.
MOODY, J.B.; DODGSON, M.Managing Complex Collaborative Projects:Lessons from the Development of a
New Satellite. Journal of Technology Transfer, v.31, n.5, p. 568588, setembro, 2006.
NAOUM, S. An overview into the concept of partnering. International Journal of Project Management, v.
21, n. 1, p.71-76, janeiro, 2003.
NOOTEBOOM, B. Innovation and inter-firms linkages: new implications for policy. Research Policy, v. 28, n.
8, p. 793- 805, novembro, 1999.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Mass.: Project
Management Institute, Inc, 2004.
RYCROFT, R. W. KASH, D. E. Self-organizing innovation networks: implications for globalization.
Technovation, v. 24, n. 3, p. 187-197, maro, 2004.
VERZUH, E. MBA compacto: gesto de projetos. Rio de Janeiro: Campus, 2000.
WINTER, M. et al. Directions for future research in project management: the main findings of a UK
government-funded research network. International Journal of Project Management, v. 24, n. 8, p. 638-
649, novembro, 2006.
Edio 19 - Engenharia de Software Magazine 15
 Softwares para gerenciamento de projetos
Camila de Araujo
Possui graduao em Bacharelado em Siste-
mas de Informao pela Universidade Esta-
dual Paulista Jlio de Mesquita Filho (2003)
e mestrado em Engenharia de Produo pela
Universidade de So Paulo (EESC-USP, 2008).
Atualmente doutoranda em Engenharia
de Produo na Universidade de So Paulo
(EESC-USP), com a pesquisa Software de
apoio ao gerenciamento gil de projetos cola-
borativos de novos produtos. Tem experincia
na rea de Engenharia de Produo, com
nfase em Gerncia do Projeto e do Produto,
atuando principalmente nos seguintes temas:
softwares de gerenciamento de projetos,
gerenciamento gil de projetos, projetos co-
laborativos de novos produtos, sistemas de
informao e desenvolvimento de produto.
16 Engenharia de Software Magazine - Softwares para gerenciamento de projetos
E
ste artigo apresenta a definio de
Software para Gerenciamento de
Projetos (SGP), as funcionalidades
que caracterizam tais solues e uma
anlise da situao atual dos principais
sistemas disponveis no mercado. Ao
final, apresenta uma sntese dos princi-
pais desafios, considerando a situao Definio e funcionalidades dos
atual dos SGPs segundo a literatura e os
desafios apontados no artigo Desafios
para o gerenciamento gil de projetos
colaborativos, segundo a literatura de
mtodos de gerenciamento de projetos.
De que se trata o artigo?
Este artigo apresenta o que so softwares para
apoiar o Gerenciamento de Projetos, as suas funcio-
nalidades e uma abordagem dos principais sistemas
existentes no mercado, destacando o que pode ser
evoludo para abraar o gerenciamento de projetos
colaborativos e o desenvolvimento gil.
Para que serve?
Este artigo serve para conhecer algumas das princi-
pais ferramentas para gerenciamento de projetos.
Dessa forma ser possvel escolher a mais adequada
para o seu trabalho.
Em que situao o tema til?
No momento de adquirir uma ferramenta, bastan-
te importante conhecer as funcionalidades que ela
deve cobrir e o que ela trs de diferencial. A partir
desse artigo o leitor conhecer as principais ferra-
mentas para gerenciamento de projetos colaborati-
vos e de agilidade e poder encontrar a que mais se
adequa a suas necessidades.
softwares de gerenciamento de
projetos
O gerenciamento de projetos inclui
uma mistura complexa de atividades
de planejamento, avaliao e tomada de

decises. As informaes geradas no decorrer do projeto so
fundamentais para o sucesso. Elas precisam ser coletadas, atu-
alizadas e apresentadas de forma correta a todos os envolvidos
no projeto. Para auxiliar nesse gerenciamento, tornou-se im-
portante o uso de softwares especficos, chamados de Softwares
de Gerenciamento de Projetos (SGP). O PMBOK (2004) define
os SGPs como: aplicativos de software especificamente proje-
tados para auxiliar a equipe de gerenciamento de projetos no
planejamento, monitoramento e controle do projeto, inclusive:
estimativa de custos, elaborao de cronogramas, comunica-
o, colaborao, gerenciamento de configurao, controle de de software livre e o cdigo-fonte aberto a principal caracte-
documentos, gerenciamento de registros e anlise de risco.
Um conjunto de funcionalidades tpicas pode ser observado
para os SGPs, tais como (ROZENFELD et al., 2005):
Gerenciamento de Atividades: registro, visualizao e orga-
nizao das atividades do projeto. Envolve vrias definies,
tais como: de precedncia, de durao, de esforo, Grfico de
Gantt e WBS (Work Breakdown Structure);
Gerenciamento de Calendrio e Agenda: organizao e
programao de um ou mais calendrios para o projeto, re-
cursos ou tarefas;
Gerenciamento de Recursos: gerenciamento das pessoas
e materiais necessrios para o projeto. Envolve funes de
anlise de alocao de recursos e seu nivelamento;
Gerenciamento de Custos: ajuda a preparao do oramento
e acompanhamento dos gastos do projeto;
Ferramentas de Monitoramento: funes para acompanha-
mento do projeto, como armazenamento de linhas de base e
comparaes entre parmetros de planejamento atual com os
parmetros das linhas de base, bem como anlise do valor
agregado;
Gerenciamento de mltiplos projetos: funes para anlise
do portiflio da empresa e compartilhamento de dados entre
os projetos.
Na prxima seo, realizada a reviso de softwares, mostran-
do-se suas categorias, segundo a forma de distribuio.
Softwares de GP segundo a literatura
Nesta seo, procura-se mostrar um panorama geral dos
SGPs disponveis atualmente. Deve-se observar que o objeti-
vo no fazer um estudo exaustivo de todas as ferramentas,
mas apresentar uma descrio das funcionalidades dos SGPs
encontrados no mercado, segundo informaes da literatura.
Os SGPs podem ser classificados em trs grandes categorias,
segundo a forma de comercializao:
Cdigo Fechado: so os softwares distribudos com o cdigo
inacessvel ao usurio final. Segundo a Wikipedia (2008), o
que caracteriza este tipo de software que ele no distribudo
com seu cdigo fonte e, para alter-lo, seria necessrio utilizar
a prtica da engenharia reversa, o que costuma ser dificulta-
do seja pelo uso de licenas, seja pela distribuio apenas de
arquivos compilados e ou outros mecanismos de segurana
como Hard-Keys. Em sua maioria, os softwares utilizam licenas
de comercializao tradicionais, isto , por meio da compra do
Gerncia de Projetos
cdigo por pacote, nmero de usurios ou acesso. A Licena
Comercial pode reservar tambm direitos de uso, tais como
suporte, atualizao peridica e acesso documentao e
outros materiais. Outro modelo de software que se encaixa na
categoria de cdigo fechado o denominado freeware, que
tambm no apresenta o cdigo fonte, apesar de sua utilizao
no implicar o pagamento de licenas de uso;
Cdigo Aberto: So softwares onde o cdigo-fonte est dis-
ponvel para ser lido, estudado ou modificado por qualquer
pessoa interessada. Os softwares desta categoria so chamados
rstica desses (REIS, 2003). Um software livre tambm concede
as seguintes quatro liberdades: a liberdade de executar o pro-
grama, para qualquer propsito (liberdade n. 0); a liberdade
de estudar como o programa funciona e adapt-lo para as
suas necessidades (liberdade n. 1); a liberdade de redistribuir
cpias de modo que se possa ajudar ao seu prximo (liber-
dade n. 2) e a liberdade de aperfeioar o programa, e liberar
os seus aperfeioamentos, de modo que toda a comunidade
se beneficie (liberdade n. 3). As licenas de software livre
permitem que eles sejam comercializados. Na prtica, j que
possvel copiar o cdigo de qualquer pessoa que j o tenha,
o preo que o usurio paga por um software livre tende a ser
baixo o suficiente para motivar as pessoas a comprarem e no
o copiarem. (REIS, 2003);
Modelos Cientficos: so prottipos de softwares propostos
em estudos acadmicos, que testam novos conceitos e funciona-
lidades. Esses modelos visam avanos cientficos, solucionando
os problemas apresentados nos sistemas de cdigo fechado
e/ou aberto, apresentados pelas necessidades do mercado ou
para viabilizar prova de conceito de alguma teoria. A principal
caracterstica que a ferramenta est em estudo, em fase de
prototipao ou validao, no sendo acessvel ao mercado.
A seguir, apresentam-se as anlises realizadas, a partir de
documentos, nos dois primeiros tipos: softwares comerciais
para gerenciamento de projetos e softwares livres.
No caso dos modelos cientficos, no foi identificada nenhu-
ma reviso bibliogrfica exaustiva. H apenas artigos que
realizam revises limitadas como os de Voropajev e Schinberg
(1992), Nicolo (1993), Li et al. (2001), Ren et al. (2006) e Liu et al.
(2005). Portanto, no vamos realizar uma reviso especfica
desses tipos de software.
Softwares de cdigo fechado
Em uma avaliao dos softwares comerciais de Gerenciamento
de Projetos de alta representatividade no mercado, realizada
pelo Gartner Group (2007), pde-se observar alguns aspectos
das funcionalidades disponveis. Foi desenvolvido um qua-
drante de classificao dos softwares (Quadrante Mgico), com
dois eixos: habilidades para executar e abrangncia da viso. O
eixo Habilidade para Executar refere-se ao desenvolvimento
e desempenho do fornecedor de software (vendor) e incluiu os
critrios: lucratividade, nvel e crescimento dos rendimentos
da empresa; equipe de gerenciamento do vendor; integridade;
Edio 19 - Engenharia de Software Magazine 17
aprofundamento (detalhamento) das funcionalidades das fer-
ramentas de aplicao; servio e suporte; vendas e marketing.
J o eixo Abrangncia da Viso inclui critrios relacionados
s funcionalidades dos softwares como Abrangncia, so eles:
compatibilidade com plataformas; colaborao, funcionali-
dades especficas; tecnologia e mercado; gerenciamento de
recursos; e servios de suporte.
No quadrante dos Lderes, no basta o sistema ter funcio-
nalidades abrangentes, mas tambm o fornecedor do software
(vendor) deve incluir as tecnologias de desenvolvimento mais
modernas e comprometimento com um servio de excelncia.
O quadrante dos Desafiantes, segundo esta anlise, contm
os softwares que oferecem funcionalidades, que, apesar de
limitadas, podem impulsionar o canal de vendas. Sua presen-
a internacional e possuem base instalada. Esses produtos
seguem as funcionalidades tradicionais, descritas em Rozen-
feld et al. (2006) e na seo Definio e funcionalidades dos
softwares de gerenciamento de projetos. Isso foi confirmado
analisando-se a documentao tcnica de Microsoft Project
(EPM) e a do Primavera, disponveis na internet (MICROSOFT,
2008; PRIMAVERA, 2008).
Para esta pesquisa, interessam os dois ltimos quadrantes:
visionrios e nichos. Os Visionrios so aqueles, segundo a
pesquisa, que possuem funcionalidades e ou configuraes
alternativas. Para verific-las, empregou-se uma anlise da
documentao tcnica presente na internet dos softwares indi-
cados na Figura 1. O critrio utilizado foi a busca de funes
diferentes das citadas no tpico Definio e funcionalidades
dos softwares de gerenciamento de projetos. A seguir, apre-
sentada uma breve descrio das funcionalidades diferenciais
de cada software verificado, isto , aquelas que diferem da lista
apresentada por Rozenfeld et al. (2005).
Figura 1. Quadrante de classificao dos softwares comerciais (Fonte:
relatrio do Gartner Group (2007))
O IBM RPM inclui o controle de colaborao no projeto, alm
das funcionalidades j citadas como bsicas dos SGPs. Ele
18 Engenharia de Software Magazine - Softwares para gerenciamento de projetos
fornece aos gerentes e participantes do projeto informaes
sobre acontecimentos e alteraes durante o decorrer do pro-
jeto, utilizando notificaes de estado e condies de disparo
de e-mails configurados pelo usurio especificamente para
cada projeto (IBM, 2008).
Nas informaes tcnicas publicadas sobre o Serena (2008),
no h explicaes suficientes sobre suas funcionalidades (SE-
RENA, 2008). Portanto, no foi possvel avaliar o diferencial. O
texto destaca uma funcionalidade de monitor de desempenho
do projeto em tempo real (SERENA, 2008).
O aplicativo da Borland (Borland Tempo), pelas informaes
tcnicas disponveis no site, disponibiliza as funcionalidades
bsicas dos SGPs, incluindo tambm coleta de informaes
que permite modelar documentos padro do projeto e do
planejamento, como formulrios on-line; relatrio de acompa-
nhamento de sanidade do projeto, como relatrios imediatos
de progresso, alertas de vencimento de prazo de tarefas e no-
tificaes aos membros da equipe (BORLAND, 2008). Portanto,
no foi possvel identificar funcionalidades diferenciais.
J o software da EProject (Daptiv PPM) possui foco em funcio-
nalidades de colaborao. Um exemplo a troca de mensagens
assncronas integrada s funes tradicionais de GP, incluso
de documentos no projeto utilizando funo drag-and-drop
(arrastar e soltar) nas janelas; e funcionalidade para registro e
gerenciamento de Lies Aprendidas (EPROJECT, 2008).
O Sciforma (PS8) tem como diferencial o apoio criao de
templates para os projetos. Dispe de funcionalidades para criar
grficos e relatrios, alm dos existentes no software, com o in-
tuito de melhorar o acompanhamento e avaliaes do projeto.
Ele tambm disponibiliza troca de mensagens assncronas pelo
software (SCIFORMA, 2008).
O site da Powersteering no disponibilizou informaes
tcnicas do seu produto, por isso no foi possvel avali-lo
(POWERSTEERING, 2008). Pelo mesmo motivo, tambm no
foi possvel avaliar o software da ITM (ITM, 2008).
A anlise, embora parcial, indica que os softwares ditos vi-
sionrios no apresentam funcionalidades to distantes dos
softwares tradicionais. A diferena est principalmente na in-
cluso de ferramentas de troca de mensagens, nos relatrios de
acompanhamento mais avanados e nas lies aprendidas.
No quadrante do Nicho, esto os softwares que, segundo a
anlise, atendem necessidades especficas de determinado
grupo de clientes, como funcionalidades especficas de geren-
ciamento de portfolios ou adaptaes para padres de regies
geogrficas.
Os softwares da Instantis e Augeo Software possuem funcio-
nalidades especficas para projetos de desenvolvimento de
novos produtos, mas no detalham essas funcionalidades em
seus sites. Os demais softwares que compem o quadrante no
apresentaram, pelas informaes tcnicas nos sites, funciona-
lidades diferenciais.
Conforme o objetivo deste artigo, chamam a ateno nessa
categoria as solues voltadas para o desenvolvimento de
projetos de TI, pois entre os sistemas de nicho h fabricantes
que se propem a implementar funcionalidades conforme as
 Gerncia de Projetos

diretrizes do enfoque gil de desenvolvimento de produtos.
Analisando-se sua documentao, identificaram-se como
funes diferenciais o cadastro dos projetos, iteraes e en-
tregas programadas por iterao, registro para acompanha-
mento dos problemas e mudanas necessrias no decorrer
do projeto e controle dos Releases do software desenvolvido
integrado com os planos de iterao. Suas funcionalidades
so baseadas nos mtodos Scrum, XP (eXtreme Programming),
DSDM (Dynamic Systems Development Method) e Agile Up.
Por serem solues que visam o mesmo propsito desse
trabalho, julgou-se que seria fundamental uma anlise
pormenorizada desses softwares. Portanto, optou-se por
realizar uma avaliao especfica, a partir do contato com o
prprio sistema, indo alm da documentao. Essa anlise
apresentada na seo Softwares para gerenciamento gil
de projetos.
Softwares de cdigo aberto
Os softwares de cdigo aberto disponveis no mercado so
muitos. Nos sites http://freshmeat.net/ e http://sourceforge.net/
possivel observar dezenas de ferramentas nessa categoria.
Roriz, Juc Junior e Amaral (2004) realizaram um estudo
dessas ferramentas de cdigo aberto e encontraram mais de
50 softwares. O mtodo empregou as seguintes etapas:
1) Anlise da ferramenta MSProject 2002 e Primavera para a
elaborao dos critrios de anlise das funcionalidades;
2) Criao dos critrios de anlise das funcionalidades do
GP, gerando uma lista com 58 critrios, divididos em nove
categorias;
3) Depois de uma primeira seleo dos softwares disponveis,
que descartou as ferramentas com funcionalidades especficas
ou com graves limitaes, obteve-se uma lista com 25 softwares.
Utilizando-se consultas a duas listas de discusses de gerentes
de projeto, foram selecionados os seis mais citados (TUTOS,
2008; PHPROJEKT, 2008; PHPCOLLAB, 2008; DOTPROJECT,
2008; PLANNER, 2008; OPEN WORKBENCH, 2008), que foram
analisados segundo os 58 critrios;
O quadro final apresentado na Tabela 1, onde 100% signi-
ficaria o atendimento a todas as funcionalidades presentes no
software PRIMAVERA e MS PROJECT.
Portanto, a ferramenta que recebeu a melhor pontuao
na anlise, em relao sua aplicao nas empresas de base
tecnolgica, encontra-se em nvel de sofisticao bem inferior
dos softwares proprietrios utilizados como base para os
critrios. Desta forma tem-se um panorama onde as ferramen-
tas de cdigo aberto apresentam deficincias e no possuem
maturidade suficiente para sua utilizao direta, sem imple-
mentaes de novas funcionalidades (RORIZ, JUC JUNIOR
e AMARAL, 2005).
Softwares para gerenciamento gil de projetos
A literatura no contempla propostas de softwares para
apoiar o gerenciamento gil de projetos. Porm, foram en-
contradas solues voltadas para esse enfoque. As buscas na
internet e em grupos sobre APM (Agile Project Management)
identificaram trs sistemas comerciais. Todos so especficos
para o gerenciamento de projetos de desenvolvimento de
softwares. As ferramentas encontradas so de cdigo fecha-
do, comercializadas por meio de licenas, mas possuem uma
verso Trial, para teste de 30 dias, as quais foram utilizadas
para efeito de avaliao.
Os software avaliados, com seus respectivos sites, foram:
VersionOne www.versionone.com;
Target www.targetprocess.com;
Rally www.rallydev.com.
As impresses e diferenas em relao aos sistemas tradicio-
nais, comparadas segundo as funcionalidades apresentadas na
seo Definio e funcionalidades dos softwares de gerencia-
mento de projetos, foram coletadas e registradas.
As principais diferenas em relao s funcionalidades tra-
dicionais so as seguintes:
Utilizam como principal idia um planejamento inicial sim-
plificado (Workitem Planning) e iteraes (Sprints) dentro do
projeto. Dentro de cada iterao so registradas as entregas que
devem ser realizadas e seu prazo. A Figura 2 um exemplo
da viso geral do processo de desenvolvimento do projeto,
utilizado no software VersionOne. A representao mostra
desde o planejamento do projeto at o andamento das iteraes.
possvel observar na figura que esse software no segue
o mesmo padro e as funcionalidades tpicas dos softwares

TUTOS PHProjekt PHPcollab Dotproject Planner Open Workbench

Banco de dados 100% 100% 100% 90% 25% 5%
Calendrio e agenda 23% 13% 3% 13% 37% 37%
Gesto de atividades 38% 36% 30% 42% 46% 64%
Gesto de recursos 36% 32% 10% 14% 22% 32%
Gesto de custos 30% 10% 0% 10% 15% 55%
Gesto de documentos relatrios e impresso 33% 40% 27% 27% 27% 33%
Ferramentas de monitoramento 10% 3% 10% 10% 3% 50%
Gesto de mltiplos projetos 4% 4% 4% 4% 0% 36%
Ferramentas de comunicao e integrao 38% 65% 75% 65% 3% 13%
Tabela 1. Avaliao dos softwares de cdigo aberto (Fonte: Roriz, Juc Junior e Amaral (2005)

Edio 19 - Engenharia de Software Magazine 19

de gerenciamento clssico de projetos. Os demais softwares
analisados seguem padres similares. Cada entrega pode ser
detalhada em subentregas, que tambm possuem prazo esti-
pulado. A responsabilidade de cada entrega ou subentrega
associada a um recurso humano.

Figura 4. Tela do software Rally Defects (Fonte: www.rallydev.com)

O uso de painis de controle, chamado nesses softwares de

Dashboard. Trata-se de relatrios resumidos que proporcionam
uma viso geral do projeto. Os relatrios apresentados nesses
softwares contm informaes similares como prximas
atividades a serem desenvolvidas e ltimas mudanas que
Figura 2. Tela do software VersionOne (Fonte: www.versionone.com) ocorreram no projeto. A Figura 5 d exemplo do Dashboard
do software Target.
O tradicional grfico de Gantt no utilizado, mas existem
outras ferramentas para acompanhamento visual do andamen-
to do projeto, como status de cada iterao, entrega, subentrega,
e relatrios Burndown, isto , que descrevem o progresso de
uma equipe e o denominado Roadmap, relacionado ao escopo
do projeto e suas mudanas ao longo do projeto. A Figura 3
demonstra um relatrio do tipo Burndown nas iteraes do
software Rally.

Figura 5. Tela do software Target Dashboard

(Fonte: www.targetprocess.com)

Possuem tambm rea para guardar as retrospectivas,

Figura 3. Tela do software Rally relatrio Burndown (Fonte: www.
rallydev.com)
Outra funcionalidade existente o registro das aes neces-
srias para as prximas entregas, como correes de problemas
(Defects). O registro de problemas feito da mesma forma que
uma entrega, relatando o problema a ser resolvido, e associado
a uma iterao dentro do projeto. A Figura 4 do software Rally
demonstra o registro de problemas, Defects. Nota-se que no
muito diferente de um relatrio de issues (problemas) nos SGPs
tradicionais, a no ser pela relao cada uma das entregas.
que seriam as lies aprendidas, alm das anlises das
estimativas iniciais do projeto.
Nos softwares voltados para o enfoque gil de gerenciamento
de projetos, todas as mudanas de escopo so gerenciadas e po-
dem ser analisadas em relatrios, permitindo aos colaboradores
acompanhar as alteraes do projeto. A diferena dos softwares
tradicionais que os relatrios, alm de indicarem as mudanas
de escopo, indicam tambm as tendncias de estimativas de
tempo, atividades e problemas para as novas entregas.
As funcionalidades citadas, apesar de estarem voltadas ao
desenvolvimento de softwares, podem ser estudadas para

20 Engenharia de Software Magazine - Softwares para gerenciamento de projetos

 Gerncia de Projetos

Desafios Fonte
serem adaptadas ao desenvolvimento de produtos.
Dessa forma, seria possvel a criao de um software Falta de informao sobre o que as outras equipes do Hameri e Puittinen (2003)
para gerenciamento de projetos de desenvolvimento projeto esto fazendo (progresso das tarefas)
de produtos utilizando-se o enfoque gil. Falha no controle de mudana do projeto Hameri e Puittinen (2003)
Vises diferentes sobre os objetivos do projeto Hameri e Puittinen (2003); Barnes, Pashby e Gibbons (2006)
Concluso - Sntese dos softwares de GP frente Rigidez no planejamento do projeto e das rotinas Hameri e Puittinen (2003)
colaborao e agilidade Reaespobresem relao s mudanas repentinas Hameri e Puittinen (2003)
Os primeiros softwares de gerenciamento de projetos no ambiente do projeto
foram concebidos no contexto de grandes projetos, Dificuldades tecnolgicas inesperadas Hameri e Puittinen (2003)
com localizao nica. Um exemplo um dos SGPs
Falha no controle de mudana do projeto Hameri e Puittinen (2003)
comerciais mais conhecidos, o Microsoft Project, que
teve sua primeira verso lanada em 1987. No decor- Falta de Responsabilidades claramente definidas Barnes, Pashby e Gibbons (2006)
rer desse perodo at hoje, esses softwares evoluram Criao de um plano de projeto aceito entre as partes Barnes, Pashby e Gibbons (2006)
no sentido de apoiar praticamente todas as reas do Falta de marcos de projeto definidos Barnes, Pashby e Gibbons (2006)
gerenciamento de projetos tradicional. Na seo De- Falta de recursos adequados Barnes, Pashby e Gibbons (2006)
finio e funcionalidades dos softwares de gerencia-
Falha no monitoramento regular do progresso Barnes, Pashby e Gibbons (2006)
mento de projetos, presente no artigo Desafios para
Falta de comunicao efetiva Barnes, Pashby e Gibbons (2006)
o gerenciamento gil de projetos colaborativos, foram
descritas as funcionalidades comumente encontradas Falta de compromisso na entrega por parte dos Barnes, Pashby e Gibbons (2006)
nesses softwares. Observou-se, porm, na seo Desa- colaboradores
fios no gerenciamento de projetos colaborativos (do Tabela 2. Novos desafios para o gerenciamento de projetos colaborativos
mesmo artigo), que os projetos de desenvolvimento de
produtos com altos nveis de inovao so dinmicos e
incertos, com escopo impreciso e acontecem em cola-
borao com universidades, institutos de pesquisa ou
outras empresas fornecedoras e clientes organizaes
com caractersticas significativamente distintas. Essa
realidade bastante diferente do contexto no qual os
primeiros SGPs foram concebidos, conforme constata-
do por vrios autores da reviso bibliogrfica. Como
resultado, h uma srie de problemas especficos e
desafios, apresentados na Tabela 2.
Tambm no artigo Desafios para o gerenciamento
gil de projetos colaborativos, na seo Desafios do
gerenciamento de projetos e o gerenciamento gil de
projetos, demonstrou-se que h novas tendncias na
teoria de Gerenciamento de Projetos, como o enfoque
gil e os trabalhos de autores como o grupo do ESPRC.
Elas caminham no sentido de criticar o foco da
teoria atual. Sugerem que os mtodos e ferramentas
existentes, que denominam usualmente de Geren-
ciamento de Projetos Clssico, no responderiam s
necessidades das organizaes que convivem nesse
novo cenrio. Seria preciso desenvolver mtodos e
tcnicas que fossem capazes de atender aos seguintes
desafios:
Adequar-se s mudanas dos projetos;
Apoiar o acompanhamento e alteraes no resultado
final;
Compartilhar recursos entre projetos;
Consumir pouco tempo com documentao;
Empregar os princpios do gerenciamento gil.

A reviso bibliogrfica demonstrou a inexistncia

de estudos empricos com avaliaes de problemas no

Edio 19 - Engenharia de Software Magazine 21

uso de SGPs existentes, em casos de projetos reais e segundo
a perspectiva dos usurios. H trabalhos correlatos, que des-
crevem a aplicao de uma soluo especfica ou que, entre
outras questes, abordam tambm o aspecto SGP. Apesar
da quantidade pequena, eles indicam que h ineficincias e
problemas que precisam ser solucionados.
Dentre os estudos que apontam problemas nos SGPs, est o de
White e Fortune (2002). Os autores apresentam um survey sobre
experincias reais de gerenciamento de projetos. O questionrio
foi desenvolvido para identificar os mtodos, ferramentas e tcni-
cas em uso atualmente, e estabelecer uma lista de fatores crticos
de sucesso em gerenciamento de projetos. Foram escolhidos
995 gerentes de projetos, que representavam 620 organizaes
diferentes, tanto do setor pblico como do privado. Do total de
questionrios enviados (995), 236 retornaram e foram avaliados
no desenvolvimento da pesquisa. Nesse estudo, os softwares
de gerenciamento de projetos aparecem como uma das prin-
cipais limitaes entre os mtodos/ferramentas/tcnicas do
gerenciamento de projetos. A explicao apresentada que
esses softwares seriam inadequados s necessidades das empresas,
principalmente para projetos complexos. As autoras chamam de
complexo um projeto onde vrias organizaes participam de
seu desenvolvimento, caso dos projetos colaborativos. Cotterrel
(1998)1 apud White e Fortune (2002) diz que poucos softwares de
gerenciamento de projetos possuem funcionalidades que apiem
o compartilhamento de recursos e informaes segundo as ne-
cessidades desses tipos de projeto.
Bergman e Baker (2000) afirmam que as solues para o com-
partilhamento dos dados de projetos utilizadas nas empresas,
na poca do estudo, eram ferramentas ou famlia de ferramentas
simples de escritrio, como o MS-Office. Segundo os autores, elas
so insuficientes para engenheiros, porque eles usam muitas
ferramentas diferentes e diversas plataformas computacionais.
Liu (2003) prope uma arquitetura para integrar os diferentes
sistemas utilizados pelas empresas para ajudar no gerenciamento
de seus projetos, convertendo informaes de um sistema para
o outro.
Ren et al. (2006), baseados na experincia de proposio de uma
soluo especfica para gerenciamento de projetos colaborativos,
afirmam que uma nova gerao de ferramentas de planejamento
de projetos colaborativos precisa ser construda. Seu estudo di-
recionado para as parcerias de pequenas e mdias empresas, e o
modelo apresentado foca na preparao e planejamento dos proje-
tos colaborativos. Segundo Woerner e Woern (2005), a maioria das
plataformas de colaborao possui uma arquitetura centralizada
e focada nas fases de desenvolvimento de novos produtos e novos
processos de produo. Esse um aspecto inadequado quando
se trata de colaborao em pequenas e mdias empresas, onde o
controle sobre os dados um critrio fundamental.
Outro dado relevante apresentado na pesquisa de White e
Fortune (2002) a dificuldade de um modelo que demonstre
o mundo real dos projetos e a documentao extensa do
1 COTTERREL, S. Annual Software Review 1998. Project Manager Today 1998;
August: 22-3.
22 Engenharia de Software Magazine - Softwares para gerenciamento de projetos
projeto, que consome muito tempo na sua execuo e torna-o
mais burocrtico.
Portanto, os problemas enfrentados no gerenciamento de pro-
jetos colaborativos pelas empresas so:
Falta de recursos que apiem o acompanhamento e alteraes
constantes no resultado final, isto , no produto do projeto;
Falta de compartilhamento efetivo de recursos, j que os sof-
twares tradicionais centralizam as informaes em um lugar e
no permitem que cada empresa tenha seus dados em formatos
distintos;
Falta de um modelo capaz de adequar-se s mudanas dos
projetos;
Consumo de tempo em extensa documentao do projeto.
Portanto, os trabalhos citados, que avaliam casos reais de SGPs,
reforam ainda mais a necessidade de avano nas solues. Nota-
se tambm que os problemas so especialmente maiores no caso
de projetos de alta complexidade e alto grau de inovao. Esses
problemas seguem na mesma linha das crticas do gerenciamento
de projetos tradicional.
Ao analisarmos as mudanas em desenvolvimento atualmente
nos softwares de gerenciamento de projetos, possvel identificar
preocupaes semelhantes. O levantamento realizado na seo
Softwares de cdigo fechado demonstra que os sistemas mais
inovadores esto incorporando:
Funcionalidades de colaborao integradas com as funcionali-
dades de gerenciamento de projetos;
Funcionalidades para acompanhamento contnuo das mudan-
as no produto;
Funcionalidades para apoio na elaborao de relatrio de con-
troles e acompanhamentos mais sofisticados.
A anlise dos SGPs existentes identificou tambm o surgimento
de sistemas que se propem especificamente ao Gerenciamento
de Projetos segundo o modelo do Gerenciamento gil. As novas
ferramentas englobam, de forma geral, o cadastro dos projetos,
suas iteraes e as entregas programadas para cada iterao,
com acompanhamento dos problemas e mudanas necessrias
ao decorrer do projeto e controle dos Releases do software desen-
volvido. Suas funcionalidades so baseadas nos mtodos Scrum,
XP (eXtreme Programming), DSDM (Dynamic Systems Development
Method) e Agile Up.
Os resultados obtidos demonstram uma coerncia entre os
problemas identificados no gerenciamento colaborativo de
projetos, as tendncias de melhoria das tcnicas e mtodos de
GP e as inovaes em funcionalidades dos SGPs. A Figura 6
demonstra a relao.
Portanto, os desafios para a evoluo de SGPs envolvem os
seguintes aspectos:
Desenvolver ambientes customizados para cada projeto com
funcionalidades que privilegiem a viso do produto final, isto
, a agregao de valor;
Criar sistemas que explorem planos baseados em entregas e
iteraes, e que sejam mais visuais;

Figura 6. Desafios para os SGPs Colaborativos (Fonte: elaborada pela autora)
Referncias
BARNES, T. A.; PASHBY, I. R.; GIBBONS, A. M. Managing collaborative R&D projects development of a
practical management tool. International Journal of Project Management, vol. 24, n 5, p. 395404,
julho, 2006.
BERGMAN, R.; BAKER, J. D. Enabling collaborative engineering and science at JPL. Advances in
Engineering Software,vol. 31, n 8-9,p. 661-668, agosto, 2000.
BORLAND. Disponvel em <http://www.borland.com/br/products/tempo/index.html>. Acesso em
27 fev 2008.
DOTPROJECT. Disponvel em < http://www.dotproject.net/ >. Acesso em 10 jul 2008.
EPROJECT. Disponvel em < http://www.eproject.com/>. Acesso em 27 fev 2008.
GARTNER GROUP. Magic Quadrant for IT Project and Portfolio Management. 2007.
HAMERI, A. PUITTINEN, R. WWW-enabled knowledge management for distributed engineering
projects. Computers in Industry, vol. 50, n. 2, p. 165-177, fevereiro, 2003.
ITM. Disponvel em < http://itm-software.com/products/ppm.shtml>. Acesso em 27 fev 2008.
LI, H. et al. Co-operative benchmarking: a tool for partnering excellence in construction. International
Journal of Project Management, v.19, n. 3, p. 171-179, abril, 2001.
LIU, D. et al. Composition of engineering web services with distributed data-flows and computations.
Advanced Engineering Informatics, v.19, n. 1, p. 2542, Janeiro, 2005.
LIU, W. D. A Distributed Data Flow Model for Composing Software Services. Tese (Doutorado em
Filosofia) Stanford University, 2003.
MICROSOFT. Disponvel em <http://office.microsoft.com/pt-br/project/HA101656381046.aspx>.
Acesso em 27/02/2008.
NICOLO, E. Metaproject analysis: multiagent virtual project networks for strategic decisions in
preplanning. International Journal of Project Management, v.11, n.4, P. 215-226, novembro, 1993.
OPEN WORKBENCH. Disponvel em < http://www.openworkbench.org/>. Acesso em 10 jul 2008.
PHPCOLLAB. Disponvel em < http://www.php-collab.com/blog/ >. Acesso em 10 jul 2008.
PHPROJEKT. Disponvel em < http://www.phprojekt.com/index.php > . Acesso em 10 jul 2008.
PLANNER. Disponvel em < http://live.gnome.org/Planner>. Acesso em 10 jul 2008.
Gerncia de Projetos
Criar funcionalidades que facilitem as alteraes constantes no
produto e gerem informaes realistas e em tempo real sobre
o andamento do projeto;
Apoiar a colaborao, com ferramentas e funcionalidades que
facilitem a troca rpida de informaes, garantindo tambm a
privacidade das partes interessadas;
Utilizar plataformas heterogneas (promovendo a descentralizao
da informao e permitindo inclusive que diferentes equipes pos-
sam utilizar sistemas distintos conforme sua convenincia).
D seu feedback sobre esta edio! 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
edio
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Mass.: Project
Management Institute, Inc, 2004.
POWERSTEERING. Disponvel em <http://www.powersteeringsoftware.com>. Acesso em 27 fev 2008.
PRIMAVERA. Disponvel em <http://www.primavera.com/index.asp >. Acesso em 27 fev 2008.
REIS, C. R. Caracterizao do modelo de processo para projetos de software livre. Dissertao
(Mestrado em Computao e Matemtica Computacional). Instituto de Cincias Matemticas e de
Computao Universidade de So Paulo, So Carlos, 158 f , 2003.
REN, Z. et al. Collaborative project planning: A case study of seismic risk analysis using an
e-engineering hub. Computers in Industry, v.57, n. 3, 218-230, abril, 2006.
RORIZ, J. H. R.; JUC JUNIOR, A. S.; AMARAL, D. C. Avaliao de ferramentas de gesto de projetos de
cdigo aberto.. In: 12 Simpsio Internacional de Iniciao Cientfica, 2004, So Paulo. Resumos....
So Paulo : USP, 2004.
ROZENFELD, H. et al. Gesto de desenvolvimento de produtos: uma abordagem por processos. So
Paulo: Saraiva, 2006.
SCIFORMA. Disponvel em < http://www.sciforma.com/us/home/index.jsp>. Acesso em 27 fev 2008.
SERENA. Disponvel em <http://www.serena.com/products/mariner/index.html>. Acesso em
27 fev 2008.
TUTOS. Disponvel em <http://www.tutos.org/homepage/index.html>. Acesso em 10 jul 2008.
VOROPAJEV, V.; SCHEINBERG, M. Project-management methods and tools for the 21st century: the
SOVNET view. Internet 92, v. 10, n. 4, novembro, 1992.
WHITE, D.; FORTUNE, J. Current practice in project management: an empirical study. International
Journal of Project Management, v. 20, n. 1, p. 1-11, janeiro, 2002.
WIKIPEDIA. Disponvel em < http://pt.wikipedia.org/wiki/P%C3%A1gina_principal >. Acesso em
05 maro 2008.
WOERNER, J.; WOERN, H. A security architecture integrated co-operative engineering platform for
organised model exchange in a Digital Factory environment. Computers in Industry, v. 56, n.4, p.
347-360, maio, 2005.
Edio 19 - Engenharia de Software Magazine 23
 Arquitetura Orientada a Servios
Aspectos de Modelagem de Negcios

De que se trata o artigo? Utilizar novas metodologias e tcnicas aplicadas

Anderson Dias Ribeiro
(andersondr@gmail.com)
formado em Tecnologia em Informtica In-
dustrial e ps-graduado em Engenharia de
Software. Atua como analista de sistemas
h 10 anos no mercado, tendo participado
no desenvolvimento de diversos sistemas
nas plataformas WEB, Java, .NET, dentre ou-
tros. Atualmente analista do Grupo Mult,
prestando servios MRS Logstica de Juiz
de Fora/MG, onde atua como desenvolve-
dor e pesquisador da plataforma SOA/Java
e gerenciamento de projetos SGP, baseados
em PMBOK.
Giuliano Prado de Morais Giglio
(giulianopmg@yahoo.com.br)
desenvolvedor Delphi desde 1997, com
ampla experincia em aplicaes Win32.
Graduado em Informtica pela UFJF, com
Conceito de Arquitetura Orientada a Servios (SOA
- Service Oriented Architecture);
Vantagens da utilizao de SOA nos aspectos ge-
renciais de TI;
Tecnologias e caractersticas para modelagem de
processos de negcios em SOA, voltados para Web
Services;
Descreve as principais caractersticas de uma ar-
quitetura de sistemas computacionais baseada no
paradigma SOA, aliada tecnologia de Web Services
como principal recurso computacional de apoio a
essa arquitetura.
Para que serve?
Demonstrar as diversas tecnologias e conceitos
relacionados modelagem de negcios numa ar-
quitetura SOA;
ao gerenciamento de negcios, utilizando-se BPM
e seus derivados;
Projetar um sistema BPM (Business Process Ma-
nagement) utilizando tecnologias relacionadas no
lugar onde foram usadas tecnologias de Workflow
tradicionais.
Em que situao o tema til?
Na administrao dos processos de negcios em
reas de TI;
Tornar possvel a orquestrao de servios, ou seja,
de Web Services, possibilitando a interao entre as
vrias etapas do fluxo, de forma grfica;
O uso de novas tecnologias de projeto e desenvol-
vimento de software aliadas ao mapeamento de
processos das empresas, facilitando a produo e
manuteno de uma soluo baseada na Web.

Especializao em Desenvolvimento de Apli-
caes para Web pelo CES de Juiz de Fora/
MG, e Mestrado em Computao pela UFF/
Niteri-RJ. Atualmente professor univer-
sitrio em diversas instituies, em cursos
de Sistemas de Informao, e atua como
consultor, pesquisador e desenvolvedor de
aplicaes Java, sobretudo na plataforma
J2EE para Web, e J2ME, sendo especialista
em aplicaes Mobile.
S
ervice Oriented Architecture (SOA)
tenta aproximar o entendimento
entre as reas de tecnologia de in-
formao (TI) e de negcios a uma viso
mais semelhante de como um sistema de
informao deve ser abordado.
A abordagem voltada a servios prope
uma soluo mais prxima dos processos
de negcio, uma vez que se tem um fluxo
de execuo montado a partir de peas
ou unidades bem definidas que execu-
tam determinada funcionalidade. Sendo
assim, uma unidade demanda, como pr-
requisito, informaes na entrada e, neces-
sariamente, criar algo modificado como
resultado do sucesso de sua execuo.

24 Engenharia de Software Magazine - Arquitetura Orientada a Servios


SOA prope que se faa a modelagem de um processo,
no mais como um monobloco, mas sim por um conjunto
ordenado de unidades bem definidas, cada qual com sua
funcionalidade convenientemente descrita, de modo que,
ao final da execuo de todas as unidades, teremos o resul-
tado esperado. Esse conjunto ordenado de unidades recebe
o nome de workflow (fluxo de trabalho) e cada unidade
recebe o nome de servio.
Mais que uma simples proposta de modelagem ou resoluo
de problemas computacionais, SOA uma arquitetura de TI
e, como tal, define cada componente como um servio geren-
civel, sendo que cada servio deve possuir um ciclo de vida
prprio, os quais, tambm, devem possuir aspectos funcionais
e de qualidade mensurveis.
Podemos notar que uma arquitetura SOA mais que um
sistema, pois envolve uma abordagem e dita o modo como
um sistema de informao ser modelado. O importante
saber que podemos montar solues baseadas em servios
e workflow com tecnologias bastante variadas, desde que
sejam respeitados os aspectos arquiteturais de servios e os
processos de negcio.
A arquitetura orientada a servios trata-se de um modelo,
em que as funcionalidades ou servios so totalmente desa-
coplados e independentes, buscando atender s mais diversas
tarefas e, ainda, podem ser reutilizados nos mais diferentes
tipos de domnios de negcios demandados pelo mercado
coorporativo.
Esses mesmos servios so publicveis, de tal forma que
possam ter suas interfaces acessveis por meio de mecanismos
de localizao e, tambm, so descritos por meio de uma lin-
guagem totalmente independente da plataforma utilizada.
J no ponto de vista do negcio, SOA se apresenta como
uma soluo de maior flexibilidade, permitindo que as mais
diversas demandas do mercado sejam absorvidas e atendidas
pela empresa com agilidade e eficincia.
Questes que envolvem aspectos como segurana, benefcios
e recomendaes sobre implantao, dentre outros, no sero
abordados neste artigo. Pretendemos, portanto, mostrar os
aspectos de modelagem de processos na arquitetura SOA
voltados para Web Services, conceitos, ferramentas e exemplos
de modelagem que possam contribuir com os diversos profis-
sionais de TI na tomada de deciso de se adotar a arquitetura
SOA em detrimento s demais existentes no mercado.
Modelagem de Processos na Arquitetura SOA
As tecnologias descritas a seguir, no somente buscam uma
aproximao de modo a permitir que haja uma maior comuni-
cao entre as reas de negcio e TI, mas tambm de forma que
partes de um sistema possam ser criadas ou gerenciadas fora
do ambiente de TI pelos prprios profissionais de negcio, tor-
nando esta relao de proximidade cada vez mais estreita.
BPM (Business Process Management)
BPM pode ser definido como uma disciplina de gerncia
focada na melhora do desempenho corporativo atravs da
projeto
gesto dos processos de negcio da empresa. BPM a forma
de se atingir os objetivos de uma organizao atravs do
aperfeioamento, gesto e controle dos processos essenciais
do negcio (PEREIRA, 2007).
Os grandes institutos de pesquisa esto validando essa viso.
O Gartner aponta projetos de BPM como os de maior ROI (Re-
turn On Investiment) em TI, e o Forrester Research anunciou
um novo acrnimo, IC-BPMS (Integration Centric BPMS), como
um novo modelo de desenvolvimento de aplicaes.
BPMS (Business Process Management Suite)
BPMS um sistema que automatiza a gesto por proces-
sos (execuo, controle e monitorao). Tipicamente, inclui
o mapeamento dos processos ponta a ponta, desenho dos
fluxos e formulrios eletrnicos, definio de workflow,
regras de negcio, integradores, monitorao em tempo
real das atividades e alertas. uma poderosa ferramenta
de gesto, para garantir que os processos esto sendo efe-
tivamente executados como modelados, contribuindo para
os objetivos da organizao.
Ilustramos na Figura 1 os elementos que compem um sis-
tema BPMS, de acordo com Glauco Reis (2007).
Figura 1. Componentes de um BPMS
A figura em forma de um pentgono ilustra em seus cinco
vrtices, os principais componentes de um sistema BPMS, como
o BPMN, ferramenta responsvel pelo desenho dos processos
de negcio; o BPEL4WS que se destina a orquestrao destes
servios, de forma a organiz-los melhor; a arquitetura SOA,
que busca de forma padronizada a componentizao dos ser-
vios; o DashBoard, ou seja, o monitoramento em tempo real
dos seus processos; e, finalmente, o BPMN + SOA, que permite
o realinhamento de todos os processos.
Um BPMS Completo
Para que tenhamos um ambiente de processos de negcio
que englobe uma soluo BPMS, torna-se necessrio a ob-
servncia de alguns pontos de suma importncia, tais como
mencionados a seguir. Um BPMS completo teria os seguintes
mdulos ou funcionalidades para ser classificado como tal
(Ghalimi, 2006):
Edio 19 - Engenharia de Software Magazine 25
 Funcionalidades mnimas a modelagem mais simples at as mais complexas. Na seq-
Ferramenta de modelagem e desenho do processo; ncia iremos definir o conjunto de elementos representativos
Engenho de execuo do processo; que daro origem aos nossos diagramas, como Atividades,
Orquestrao de web services; Eventos, Condicionais e Ligaes. Esses elementos podem ser
Interface de workflow para usurios. subdivididos em categorias, tais como so apresentadas pelo
software livre Editor BPMN (Portal BPM, 2008) para desenho
Funcionalidades intermedirias de modelos BPMN, apresentados a seguir.
Suporte para regras de negcio complexas;
Business Activity Monitoring (BAM); 1. Atividades
Controle de verso dos documentos anexados a instn- As atividades so representadas por retngulos com bordas
cias do processo. arredondadas, conforme a Figura 2, e podem representar dife-
rentes tipos de atividades conforme a necessidade do modelo
Funcionalidades completas a ser representado.
Enterprise Service Bus (ESB);
Repositrio de metadados;
Uma suite de business intelligence.

BPMN (Business Process Modeling Notation)

O BPMN uma tecnologia grfica para construo de mo-
delos destinados a representar os processos de negcio da
empresa, que sero abordados e exemplificados a seguir.
Enquanto o BPEL um formato binrio para execuo de
servios em seqncia, o BPMN a notao grfica que permite
representar como os servios iro interagir.
O BPMN define os smbolos e como estes devem ser conec-
tados para gerar modelos representativos. Por outro lado, ele
no define formatos de arquivos nem mesmo caractersticas
particulares de ambientes de execuo. Trata-se de uma no-
tao visual para representao de fluxos de processos que
pode ser mapeada para diversos formatos de execuo, como
BPML e BPEL. Em uma analogia com a orientao a objetos, o
BPMN seria como a UML (Unified Modeling Language), que
define elementos grficos para representar objetos e classes, Figura 2. Componentes do diagrama BPMN - Atividades
como tambm sua interao. Da mesma forma que a UML, o
BPMN no define formatos de armazenamento nem elemen- 2. Eventos
tos programticos relacionados implementao, como por Eventos indicam acontecimentos que, de alguma forma, po-
exemplo, as rotinas. Por outro lado, a especificao completa o dem alterar a seqncia de execuo em um fluxo, sendo que
suficiente para permitir a representao de fluxos de processo iniciar ou terminar a realizao de um processo so exemplos
pelas reas de negcio, com detalhamento bem prximo das de eventos, conforme a Figura 3.
complexidades de um ambiente real, alm de ter elementos
que se aproximam de mecanismos de execuo.

Diagramas
Observamos tambm que a notao do BPMN se assemelha
bastante a de alguns diagramas da UML, como os diagramas
de atividades que tambm podem ser comparados aos
fluxogramas. Tambm relevante mencionar que o BPMN
composto por um conjunto de BPDs (Business Process
Diagram), sendo que esses diagramas de processos devem
permitir que o desenho em questo, de alguma forma, possa
ser mapeado para um formato de execuo, tal como o prprio
BPEL ou BPML.
O objetivo da notao BPMN criar modelos grficos de
alto nvel, visando uma proximidade maior realidade dos
analistas de negcio. Os elementos grficos permitem desde Figura 3. Componentes do diagrama BPMN - Eventos

26 Engenharia de Software Magazine - Arquitetura Orientada a Servios


3. Condicionais
Os losangos indicam tanto pontos em que o fluxo pode
divergir ou convergir, como pontos de tomada de deciso,
conforme a Figura 4.
Figura 4. Componentes do diagrama BPMN - Condicionais
4. Ligaes
A seqncia em que os elementos so executados dentro
de um fluxo indicada pelas setas de fluxo, e dois elemen-
tos conectados indicam o sentido deste fluxo, conforme a
Figura 5.
Figura 5. Componentes do diagrama BPMN - Ligaes
5. Dados e Outros
Os elementos de dados fornecem informaes a serem
compartilhadas entre vrias atividades em um fluxo. Dados
como valores de cartes de crdito, carrinhos de compras po-
dem ser, por exemplo, indicados por essa notao, conforme
a Figura 6.
Figura 6. Componentes do diagrama BPMN - Dados
Os diagramas podem ser representados de diversas maneiras,
desde uma viso mais superficial, ou de alto nvel, at uma
representao minuciosa de um processo.
Conforme a notao BPMN, exemplificamos um tipo de
diagrama de Processo de negcio privado, quando se est
interessado no detalhe. Neste diagrama, pode-se visualizar
um pedao de um processo sem se importar com seu modo
de contextualizao em relao ao restante do processo.
Podemos observar esta caracterstica na Figura 7.
projeto
Figura 7. Exemplo de Diagrama BPMN
O processo se inicia com a escolha de uma forma de paga-
mento. Observando-se o fluxo, conseguiremos notar como ele
pode ser parte de um fluxo maior, por exemplo, um processo
de compra em uma loja. Nesta representao, no importa
quem est envolvido com a tarefa nem quais outras atividades
foram ou sero executadas.
BPEL (Business Process Execution Language)
Orquestrao
BPEL (Business Process Execution Language) uma lin-
guagem baseada em XML para a especificao formal dos
processos empresariais e de negcios.
BPEL alarga o modelo de interao e servios Web que lhe
permite apoiar as operaes comerciais. o resultado de uma
iniciativa cruzada entre IBM, BEA e Microsoft para desenvolver
um processo universalmente relacionado com a linguagem
suportada.
Na programao tradicional, a execuo de servios de ma-
neira coordenada se faz mediante a criao de cdigos que se
conectam aos objetos. Esses cdigos obtm informaes e as
repassam a outros objetos. Um programa orientado a objetos
exatamente isso, uma seqncia de objetos se comunicando
e passando informaes uns aos outros.
A proposta do BPEL ou BPEL4WS executar servios em
seqncia, mas por meio de um mecanismo no programti-
co, reduzindo custos de manuteno causados por alteraes
freqentes nos cdigos. Sua verso inicial foi liberada em 2002,
exatamente como proposta para a execuo de servios Web
em seqncia.
O caminho adotado foi o de arquivos XML que descrevem
como os servios se comunicam, definindo-se mecanismos
para armazenar informaes de forma no programtica, e
criando-se engines que interpretam o XML, de modo a atuar
como se fosse o programa em si.
Em resumo, os engines BPEL funcionam como grandes in-
terpretadores de cdigo XML, que executam atividades como
se fosse um programa, mas de manuteno facilitada, j que
apenas esses XML so afetados nessa atividade. No utilizar
tecnologias programticas nos traz o benefcio de se ter ferra-
mentas de criao grfica mais simples, que podem ser geridas
e at mesmo mantidas pelas reas de negcio.
relevante dizer que o BPEL orquestra apenas Web Services.
Se o mecanismo adotado para realizar a comunicao entre os
servios no for um Web Service, o BPEL se torna inaplicvel,
o que no este caso, pois este artigo se baseia totalmente na
tecnologia de Web Services.
Edio 19 - Engenharia de Software Magazine 27
 Desta forma, diramos que o BPEL torna uniformes vrios
paradigmas da TI, traduzindo-os em Web Services. Por outro
lado, em funo das suas caractersticas, no interessante
a sua utilizao em aplicaes que demandam a troca de
documentos e nem em aplicaes que geram muita interao
humana.
Quando for utilizada alguma ferramenta visual com nota-
o BPMN, alguns elementos grficos como eventos gerados
por dados no tero mapeamento direto para o BPEL, sendo
normalmente disponibilizados por servios de execuo. O
incio de uma atividade causado pela alterao no valor de uma
cotao, por exemplo, precisa ser codificado como elemento
programtico e disponibilizado como Web Service.
O BPEL ainda no define nada relacionado s telas de
interao com o usurio. Isso significa que, se a ferramenta
de desenho estiver gerando BPEL, sero necessrios outros
artefatos para que se tenha condies de operacionalizar o
processo da forma esperada.
A caracterstica de orquestrar apenas Web Services, peculiar
ao BPEL, tornam necessrios estudos no intuito de identificar
se os elementos programticos do legado da empresa, necess-
rios operacionalizao do fluxo, proporcionam a capacidade
de se tornar Web Services.
Estudo de Caso
Pretendemos neste estudo de caso utilizar novas metodo-
logias e tcnicas aplicadas ao gerenciamento de negcios,
utilizando-se BPM e seus derivados.
O uso dessas novas tecnologias de projeto e desenvolvi-
mento de software, aliadas ao mapeamento de processos das
empresas, facilita a produo e manuteno de uma soluo
que se baseia em Web. Portanto, este artigo trata de projetar
um sistema BPM utilizando tecnologias relacionadas no lugar
onde foram usadas tecnologias de Workflow tradicionais, o
qual mais restritivo quanto flexibilidade de um projeto e
sua manuteno.
Este estudo de caso consiste na elaborao de diversos
diagramas, entre eles, um diagrama com o fluxo e a macro
arquitetura do projeto BPM, um diagrama BPMN, diagramas
BPEL e alguns trechos de XML gerados automaticamente pelas
ferramentas utilizadas.
importante observarmos que este projeto de Workflow
parte do ponto em que a solicitao do aplicativo j foi feita aos
Web Services disponibilizados, os quais iro se comunicar com
os fluxos BPEL, que por sua vez iro executar todas as regras
de negcio, conforme exemplificado nos diagramas a seguir.
Ferramentas utilizadas
Para a confeco deste trabalho foi necessria a utilizao de
um aparato de tecnologias voltadas ao BPM e SOA. Optamos
por utilizar as ferramentas da Oracle, devido grande capa-
cidade de integrao das tecnologias envolvidas oferecidas
por estas e, ainda, pela robustez e confiabilidade destas, j
consagradas no mercado e atestadas por diversos profissionais
da rea.
28 Engenharia de Software Magazine - Arquitetura Orientada a Servios
Como servidor de Banco de Dados utilizamos o Oracle
10g; alem do servidor de aplicaes Oracle Application
Server e BPEL Control; para manipulao do BPEL uti-
lizamos o JDeveloper e, finalmente, para a criao dos
diagramas BPMN e converso para o BPEL, a ferramenta
BPA (Oracle Business Process Architect). Todas as ferra-
mentas citadas podem ser encontradas em Oracle SOA
Suite (2009).
Com relao s licenas de uso das ferramentas Oracle
SOA Suite, as mesmas podem ser obtidas com licena trial
de acordo com OTN License Agreement (2009), a qual foi
utilizada para o desenvolvimento deste estudo.
Necessidades do Negcio
Nosso contexto compreende uma empresa do ramo de
eletrnicos, a qual disponibiliza, atravs da Internet, seus
produtos e servios, os quais podem ser contratados por
meio de solicitaes enviadas pela Web, utilizando-se o
computador ou mesmo um dispositivo mvel, como um
celular. Em suma, o cliente estar efetuando pedidos em
uma loja virtual.
A fim de definirmos um escopo para o estudo de caso,
partiremos de uma empresa fictcia, a qual denomi-
namos de M-Eletronics, com o objetivo de modernizar
seus negcios e expandir suas fronteiras, alm de estar
buscando novas tecnologias que a possibilitem alar
novos mercados.
Desta forma, a empresa tem uma expectativa em mdio
prazo, de poder alcanar maior lucratividade, associada
ao bom atendimento ao seu cliente.
Requisitos
O sistema desenvolvido trata-se de um gerenciador
de pedidos, destinado a qualquer processo de pedidos,
podendo ainda ser invocado a partir de qualquer pla-
taforma. Este foi projetado, desenvolvido e executado a
fim de facilitar, agilizar e tornar mais confiveis tarefas
que anteriormente eram executadas manualmente, sem
desprezar a interveno humana quando necessria.
Os principais requisitos so:
1. O Sistema deve receber o pedido atravs de um arquivo
XML contendo as informaes do mesmo;
2. O Sistema deve processar o arquivo XML, extraindo
as informaes do pedido;
3. O Sistema deve inserir o pedido;
4. O Sistema deve ler os dados do cliente, e validar os
mesmos;
5. O Sistema deve verificar em estoque a disponibilidade
do produto;
6. O Sistema deve validar os dados do carto de crdito
do cliente;
7. O Sistema deve efetivar o pedido caso todas as infor-
maes necessrias sejam validadas;
8. O Sistema deve dar baixa em estoque da quantidade
do produto comprado.

Como regras de negcio, podemos definir:
A partir de uma aplicao executada em um dispositivo mvel,
ser repassado para o BPEL, no formato XML, o id do cliente e
uma coleo com os ids dos produtos selecionados, tambm o
nmero do carto de crdito do cliente;
O pedido armazenado e controlado em banco de dados pelo
prprio BPEL, que mantm o estado de cada solicitao realiza-
da, e ainda as persiste em Banco de Dados, sem nenhuma inter-
ferncia humana. Para o objeto em questo, optamos por utilizar
um BPEL assncrono, pois algumas etapas do fluxo, como por
exemplo, a validao de carto de crdito, eventualmente
pode estar fora de operao e, desta forma, o processo ficaria
aguardando uma resposta, at que o servio se restabelea;
So recuperados todos os dados do cliente como, por exemplo,
o endereo de entrega;
Os produtos so debitados em estoque;
efetuado o dbito no carto de crdito do cliente;
Em caso de erro na operao, como falta de crdito disponvel
no carto, por exemplo, os produtos so retornados para estoque
novamente.
Arquitetura do Projeto
Este projeto BPM tem como objetivo receber uma requisio
de compra, disparada por meio de qualquer dispositivo com-
putacional que oferea suporte linguagem XML. Neste estudo
de caso, iremos enfatizar uma requisio enviada por meio de
um dispositivo mvel, conforme a Figura 8.
Figura 8. Arquitetura do Projeto BPM
Vale ressaltar, ainda, a importncia da utilizao de uma
arquitetura baseada no Enterprise Service Bus - ESB, que tem a
funcionalidade de melhorar o acoplamento, fazendo a funo
de um roteador das informaes que por ali trafegam.
Desta forma, caso o sistema evolua sofrendo modificaes,
que um fato normal, haver necessidade de mudanas nos
processos em BPEL. Sendo assim, bastar apenas alterarmos o
ESB de entrada. O mesmo fato ocorrer com o servio dos Cor-
reios, por exemplo, caso a empresa passe a negociar com uma
outra transportadora, o BPEL no precisa ser alterado.
projeto
Modelagem BPMN
No diagrama BPMN da Figura 9 demonstramos graficamente
o fluxo no qual se enquadra nosso processo de negcio.
Os elementos apresentados no grfico demonstram de for-
ma clara e objetiva as ligaes entre as atividades, eventos e
condicionais existentes em um processo de realizao de um
pedido no que se refere ao negcio da empresa.
Figura 9. Diagrama BPM
Na seqncia, detalharemos melhor as atividades que en-
volvem o processo de negcio de um pedido, na concepo
de nosso estudo de caso.
Aps o incio do fluxo, foi criada uma atividade Criar Pedido,
responsvel por criar e gravar um conjunto de registros com
status do pedido e receber a ordem de compra.
Posteriormente, foi inserida a atividade Get Dados Cliente,
na qual utilizamos o id (identificador nico) do cliente para
o registro da ordem de compra, sendo este, a chave de busca
para os dados do cliente.
Inserimos agora a atividade Get Informaes de Credito, que
tem o objetivo de recuperar o nmero do carto de crdito
do cliente e verificar o status do mesmo, ou seja, se o carto
vlido e se o saldo suficiente para realizar aquela operao.
Em seguida, a atividade Aprovar Pedido deve fazer a apro-
vao do pedido, podendo ter dois resultados: aprovar ou
rejeitar.
No caso do pedido ser rejeitado, o fluxo ser direcionado para
a atividade Cancelar Pedido, que efetuar o cancelamento do
pedido, desfazendo todas as operaes anteriormente reali-
zadas, finalizando o fluxo. No caso do pedido ser aprovado,
o fluxo ser direcionado para a atividade Fechar Pedido que,
por sua vez, efetiva o pedido solicitado e conclui o fluxo de
um pedido, finalizando o fluxo.
Modelagem BPEL
Os diagramas a seguir correspondem exatamente ao fluxo repre-
sentado no digrama anterior em BPMN. Por esse motivo, no ser
necessrio descrever novamente passo a passo a sua execuo,
observando apenas que os diagramas BPEL foram separados em
duas partes. A primeira, conforme a Figura 10, exibe o fluxo como
um todo, contendo apenas as principais funes, quase idntico
ao diagrama BPMN, diferindo apenas na representao grfica e
Edio 19 - Engenharia de Software Magazine 29
nas interfaces com os servios disponveis. Um segundo diagrama
BPEL poderia ser feito para demonstrar, detalhadamente, todas
as funcionalidades desempenhadas pelo fluxo, bem como os
tratamentos de exceo e suas interfaces com os servios. Porm
procuramos no estender demasiadamente este estudo de caso,
optando por no inclu-los.

Figura 11. Detalhe do Escopo Criar_Pedido

Figura 10. Diagrama BPEL

Descrio do Escopo Criar_Pedido

Detalharemos a seguir, um dos principais escopos do nosso
diagrama BPEL, Criar_Pedido, conforme indicado pelo prprio
nome, o qual o responsvel pela efetivao do pedido recebido
pelo BPEL, apresentado na Figura 11.
Os seguintes passos so observados:
1 passo - O BPEL solicita ao servio PedidoSequencia, que
retorna um nmero sequencial do pedido referente ao pedido
em questo;
2 passo - O BPEL ir definir as diversas variveis do sistema
para seu controle interno;
3 passo - Ir adicionar os itens do pedido; Figura 12. Tela Assign do JDeveloper
4 passo - Em seguida, ir inserir o pedido atravs do servio
InserirPedido e, ainda, dar baixa no estoque caso o pedido a opo Variable e expandimos o escopo CriarPedido. Em
seja concludo. orderSequenceOutput identifica-se sua origem e, seleciona-
mos a sequence order_seq_id_gen.nextval, direcionando para
Por meio do JDeveloper, podemos manipular todas as entradas a sada, direita, conforme a rvore Variable > inputVariable >
e sadas necessrias no mapeamento dos arquivos XML a serem payload > client > PurchaseOrder > ID.
gerados. Por exemplo, no escopo Criar_Pedido, podemos trans- Atravs da prxima interface, podemos observar que ser de-
ferir um determinado contedo de entrada de uma varivel para finido o status do nosso pedido para Pendente, atribudo em
sua sada. Definimos, desta forma, um status Pendente para a forma de String ao selecionarmos o Type Expression, conforme
varivel de controle do status AssignStatusOrdem, conforme a Figura 14. Desta forma, a String Pendente ser atribuda
a Figura 12. varivel OrderStatus.
Executando um duplo clique sobre a varivel em questo, ser Aps a execuo dos passos anteriores, teremos o arquivo
aberta uma nova tela, ilustrada pela Figura 13, na qual podemos XML gerado pela ferramenta (Listagem 1), representando o
notar a recuperao do ID que foi previamente gerado. Confor- escopo Criar_Pedido, que expressa exatamente os passos
me se pode observar na figura, escolhemos na origem e destino executados anteriormente.

30 Engenharia de Software Magazine - Arquitetura Orientada a Servios

 projeto

Figura 13. Tela Copy Operation do JDeveloper

Figura 14. Tela Copy Operation do JDeveloper (continuao)

Listagem 1. XML Gerado pelo JDeveloper Escopo Criar_Pedido.

1 <scope name=Criar_Pedido> 21 </copy>
2 <variables> 22 <copy>
3 <variable name=orderRequest messageType=ns8:Orders 23 <from expression=string(Pendente)/>
Collection_msg/> 24 <to variable=inputVariable part=payload
4 <variable name=orderSequenceInput 25 query=/client:SOAOrderBookingProcessRequest/
5 messageType=ns12:OrderSequenceInput_msg/> ns4:PurchaseOrder/ns4:OrderInfo/
6 <variable name=orderSequenceOutput ns4:OrderStatus/>
7 messageType=ns12:OrderSequenceOutput 26 </copy>
Collection_msg/> 27 </assign>
8 </variables> 28 <assign name=AdicionarItensPedidos>
9 <sequence name=Sequence_11> 29 <bpelx:annotation>
10 <invoke name=RecuperarIdPedido partnerLink=PedidoSequencia 30 <bpelx:pattern>transformation</bpelx:pattern>
11 portType=ns12:OrderSequence_ptt 31 </bpelx:annotation>
operation=OrderSequence 32 <copy>
12 inputVariable=orderSequenceInput 33 <from expression=ora:processXSLT(TransformOrder.
13 outputVariable=orderSequenceOutput/> xsl,bpws:getVariableData(inputVariable,
14 <assign name=AssignStatusOrdem> payload))/>
15 <copy> 34 <to variable=orderRequest part=OrdersCollection/>
16 <from variable=orderSequenceOutput 35 </copy>
17 part=OrderSequenceOutputCollection 36 </assign>
18 query=/ns18:OrderSequenceOutputCollection/ 37 <invoke name=InserirPedido partnerLink=InseriPedido
ns18:OrderSequenceOutput/ns18: 38 portType=ns8:Order_ptt operation=write
order_seq_id_gen.nextval/> 39 inputVariable=orderRequest/>
19 <to variable=inputVariable part=payload 40 </sequence>
20 query=/client:SOAOrderBookingProcessRequest/ 41 </scope>
ns4:PurchaseOrder/ns4:ID/>

Edio 19 - Engenharia de Software Magazine 31

Consideraes Finais Referncias Bibliogrficas
A aproximao da rea de TI com a rea de negcios vem (GHALIMI, 2006) GHALIMI, Ismael C. BPM 2.0. In: Projeler. 2006. Disponvel em: <http://www.
colaborar, de inmeras maneiras, ao ambiente de uma or- projeler.com.br/artigos_bpm20.jsp>. Acesso em: 20 out. 2008
ganizao. Dessa forma, o BPM, em conjunto com a arqui-
(Oracle SOA Sute, 2009) Oracle SOA Suite.Oracle SOA Suite 10g Softwares Downloads.Disponvel
tetura SOA, vem se completar a fim de tornar os processos
em: <http://otn.oracle.com/software/tech/webservices>. Acesso em: 23 mai. 2009.
empresariais cada vez mais dinmicos e gerenciveis.
Neste artigo, procuramos apresentar os principais con- (OTN, 2009) OTN. OTN License Agreement. Disponvel em: <http://www.oracle.com/
ceitos que envolvem o SOA/BPM e os seus principais com- technology/software/popup-license/standard-license.html>. Acesso em: 23 mai. 2009.
ponentes. Os tpicos aqui levantados objetivam a serem
(PEREIRA, 2007) PEREIRA, Hlio. BPMS Brasil: algumas definies e conceitos. Disponvel em:
mais um ponto de orientao para as empresas, estudantes
<http://bpmsbrasil.blogspot.com/2007_01_01_archive. html>. Acesso em: 14 out. 2008
e profissionais da rea de TI que desejam conhecer ou im-
plementar uma arquitetura SOA. (PORTAL BPM, 2008) Revista Portal BPM.Editor BPMN.Disponvel em:<http://www.portalbpm.
Com um estudo de caso, demonstramos as tecnologias com.br/index.jsp?page=/downloads.jsp&dummy=279657439. Acesso em: 20 out. 2009.
envolvidas na implementao de uma soluo completa
(REIS, 2007) REIS, Glauco. Introduo ao BPM, BPMS e SOA. Revista Portal BPM, ano I, n. 1, p.
SOA/BPM, sobretudo em relao s suas bases, as quais se
22-29-48. Bimestral/2007. Disponvel em: <http://www.portalbpm.com.br>. Acesso em: 20
fundamentam nos padres XML. A modelagem e imple-
ago. 2008.
mentao foram tratadas com o emprego de ferramentas
especficas onde, atravs destas, sugerimos uma alternativa
D seu feedback sobre esta edio! Feedback
extremamente vivel para a tarefa proposta, em termos de eu

s
D
usabilidade e recursos funcionais. A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
SOA/BPM um assunto muito rico e em constante evoluo. Para isso, precisamos saber o que voc, leitor, acha da revista!

s
ta
Outros estudos podem ser conduzidos nesta rea, expandin- D seu voto sobre este artigo, atravs do link:
edio

do e detalhando o que foi apresentado neste trabalho.

www.devmedia.com.br/esmag/feedback

32 Engenharia de Software Magazine - Arquitetura Orientada a Servios


Arquitetura REST
Uma alternativa para construo de Servios Web
Lvia Ruback
liviaruback@gmail.com
Graduada em Cincia da Computao pela
Universidade Federal de Juiz de Fora.
Regina Braga
regina.braga@ufjf.edu.br
Regina Braga professora adjunta do
departamento de Cincia da Computao que tem tido mais sucesso atualmente
da Universidade Federal de Juiz de Fora.
Suas linhas de pesquisa principais so re-
lacionadas a reutilizao de software, mais
especificamente com desenvolvimento ba-
seado em componentes (DBC). O Ncleo de
Pesquisa em Qualidade de Software, do qual
faz parte, atua principalmente em pesquisas
relacionadas a multidisciplinaridade, nota-
damente na rea de software cientfico, que
tem sido seu foco de pesquisas atual (DBC e
software cientfico).
De que se trata o artigo?
Este artigo detalha a arquitetura REST, apresenta um
pequeno exemplo de seu uso e suas principais vanta-
gens em relao arquitetura de servios tradicional.
Para que serve?
O surgimento da Arquitetura de Web Services tornou
possvel a interoperabilidade entre aplicaes hetero-
gneas atravs do acesso aos servios, que podem ser
invocados remotamente. Essa forma tradicional de
uso de Web Services gera uma camada de abstrao
acima do protocolo HTTP, pois as mensagens so tro-
N
os lt imos a nos, alg umas
alternativas surgiram para
melhorar o desempenho de
aplicaes que acessam servios remo-
tamente. Uma destas alternativas e a
a arquitetura REST.
A utilizao da arquitetura REST tem
tornado mais simples e eficientes muitas
aplicaes que antes eram implementa-
das de maneira tradicional baseadas
no protocolo SOAP.
As principais aplicaes que se benefi-
ciam da utilizao desta arquitetura so
aquelas nas quais cada requisio tem
Edio 19 - Engenharia de Software Magazine
Projeto
cadas envelopadas por um outro protocolo o proto-
colo SOAP. Dessa forma, muitas vezes o desempenho
do sistema comprometido devido ao tamanho das
mensagens, pois o que realmente utilizado uma
parte muito pequena do contedo contido nas men-
sagens envelopadas pelo protocolo SOAP.
Em que situao o tema til?
No entanto, surgiram algumas alternativas que po-
dem melhorar o desempenho dessas aplicaes. Uma
destas alternativas, e a que tem tido mais sucesso
atualmente, a arquitetura REST.
um custo relativamente alto, como por
exemplo, servios remotos acessados via
celular e PDAs.
Arquitetura de Web Services
Antes de iniciarmos o estudo desta
nova abordagem de manipulao de Web
Services e demonstrar na prtica suas
principais vantagens, precisamos enten-
der como funciona a forma tradicional e
mais utilizada atualmente de construir
e consumir Web Services a baseada na
Arquitetura de Web Services [1].
A Arquitetura de Web Services surgiu
para permitir a interoperabilidade entre
33
aplicaes rodando em diferentes plataformas. Foi especifica-
da com base em um protocolo que encapsula as mensagens
(SOAP Simple Object Access Protocol) e em uma linguagem
que descreve as interfaces dos servios, conhecida como WSDL
(Web Services Description Language). Na prtica, em sistemas
que seguem essa viso de Web Services, as mensagens de re-
quisio e resposta so envelopadas pelo protocolo SOAP e
os seus servios so descritos em interfaces WSDL.
Porm, um grande problema tem sido observado por usu-
rios desse tipo de arquitetura: a perda de desempenho das
aplicaes. O que acontece que, ao utilizar o protocolo SOAP,
gerada uma camada de abstrao que envolve o protocolo
HTTP quando na verdade ela no precisaria existir. Como
veremos mais adiante, a comunicao entre servios pode ser
feita de maneira mais simples e eficiente utilizando somente
os recursos bsicos da Web XML e HTTP; e o melhor: sem
comprometer o desempenho! resposta das aplicaes. Alm disso, seu uso gera uma maior
Arquitetura REST
Antes de apresentarmos uma aplicao prtica dos princpios
por trs da arquitetura REST e entender os seus objetivos e as
suas vantagens, precisamos entender alguns conceitos rela-
cionados ao paradigma, suas principais caractersticas e seus
elementos arquiteturais.
REST uma abreviao de Representation State Transfer,
ou traduzindo, Transferncia de Estado Representacional e se
baseia em um novo conceito a ser exemplificado mais adiante:
os recursos.
Iniciaremos apresentando a origem arquitetural do paradig-
ma e seus elementos arquiteturais: os elementos de dados, os
conectores e os componentes. Para finalizar, ser apresentada
uma consulta simples a um acervo de filmes para exemplificar
na prtica os conceitos apresentados.
Origem arquitetural do paradigma
O paradigma REST foi criado no ano de 2000 por um cientista
da computao norte-americano e um dos principais criadores
da especificao HTTP, Roy Fielding. REST surgiu como um
estilo arquitetural hbrido, a partir da combinao de outros
Elemento Definio / Funo
Conceito-chave da arquitetura REST.
Recursos Um recurso qualquer informao que possa receber um nome.
Na prtica, tudo que possa ser armazenado em uma base de dados.
Identifica um recurso especfico envolvido em uma interao entre clientes e servidores. Por exemplo,
Identificadores de Recursos
REST usa o URI (Unified Resource Identifier) como identificador de recursos.
As representaes de um recurso so usadas para capturar o estado atual e o estado
Representaes de Recursos desejado de um recurso solicitado.
Na prtica, so seqncias de bytes acrescidas de meta-dados que descrevem estes bytes.
Tabela 1. Elementos de dados da Arquitetura REST
34 Engenharia de Software Magazine - Arquitetura REST
estilos arquiteturais, acrescido de algumas caractersticas
adicionais.
As principais caractersticas arquiteturais incorporadas por
Fielding foram:
Separao de responsabilidades entre as camadas cliente e
servidor;
Comunicaes independentes (stateless);
Uso de cache (para eliminar algumas interaes desnecess-
rias entre cliente e servidor);
Ut i l i z a o de u m a i nt e r f ac e u n i f or me e nt r e o s
componentes.
Como veremos mais adiante, estas caractersticas, quando
aplicadas ao desenvolvimento de Web Services, so capazes
de melhorar o desempenho geral do sistema se comparadas
utilizao do protocolo SOAP, pois diminui o tempo de
flexibilidade e simplicidade.
Elementos Arquiteturais REST
Arquitetura de software um conjunto de elementos arqui-
teturais que possuem alguma organizao [2]. Esta definio
destaca a importncia de conhecermos os elementos arquite-
turais de uma determinada arquitetura e suas inter-relaes
para obtermos um entendimento global da mesma.
Para entendermos como REST surgiu, alm de conhecer
suas caractersticas arquiteturais, precisamos saber como ela
foi composta.
Como qualquer outro modelo arquitetural, REST tambm
composto por um conjunto de elementos arquiteturais e seus
inter-relacionamentos. Fielding especificou em sua tese [3], que
deu origem arquitetura, as trs classes de elementos arqui-
teturais: Elementos de Dados, Conectores e Componentes. A
seguir, cada uma destas classes de elementos da arquitetura
ser detalhada e exemplificada.
Elementos de Dados: So os elementos que contm a
informao a ser usada e transformada. Os principais ele-
mentos de dados de REST esto definidos e exemplificados
na Tabela 1.
Exemplo
Um filme.
Por exemplo,
Forrest Gump
Uma URI contendo o cdigo especfico e nico de um filme.
http://localhost:8080/
REST/filme/1
Uma pgina da Web contendo o estado atual solicitado do recurso
(ano, ttulo, gnero).
Por exemplo,
Ano: 1994
Ttulo: Forrest Gump O Contador de Histrias
Gnero: Drama

Para exemplificar os elementos de dados apresentados
na Tabela 1, pode-se considerar um sistema que fornece
informaes a respeito de um determinado filme (ou de
uma lista de filmes). Neste cenrio, os filmes representam
os recursos armazenados na base de dados do sistema. Cada
filme representa um determinado recurso e identificado
com um cdigo especfico e nico. Este cdigo ir compor
a URL que fornecer acesso ao recurso o identificador do
recurso. A pgina da Web contendo as informaes solici-
tadas dos filmes (ano, ttulo, gnero) seria a representao
destes recursos ou destes filmes.
Componentes: So os elementos que usam ou transformam
a informao. Em REST, os componentes so caracterizados
de acordo com o papel que exercem. So eles:
Servidor de Origem (trata as requisies de um clien-
te). Por exemplo, o Servidor Web Apache.
Proxy e Gateway (utilizados para permitir o encami-
nhamento das requisies e respostas). Como exemplo,
podemos considerar respectivamente o Netscape Proxy
e o Apache API;
Agente do Usurio (inicia a requisio e, logo em
seguida, se torna o destino final de uma resposta o
Web Browser).
Conectores: So os elementos que interligam outros ele-
mentos. REST usa conectores para encapsular a atividade de
acesso aos recursos e para transferir as suas representaes.
De acordo com Fielding, A utilizao de conectores prov uma
interface abstrata para a comunicao entre os componentes, melho-
rando a simplicidade do sistema atravs da separao de responsa-
bilidades e ocultando a implementao de recursos e os mecanismos
de comunicao. Os principais conectores de REST so:
C l ie nt e e S er v idor (r e sp on s vei s p elo ac e s s o
aos rec u rsos). Exemplos: Libwww e Apache A PI,
respectivamente;
Cache (armazena as respostas passveis de cache). Por
exemplo, a cache de um Web Browser;
Resolver (responsvel pela converso de um URI em
um endereo de rede). Exemplo: Bind (DNS lookup
library);
Tnel (cria um caminho virtual para o trfego dos
recursos). Exemplo: SOCKS ou um SSL (Secure Sockets
Layer) aps um HTTP CONNECT.
Interface Uniforme e os Mtodos Nativos HTTP
Como j explicado anteriormente, em REST os com-
ponentes se comunicam atravs de transferncias de
representaes de um determinado recurso. Para pa-
dronizar o formato destas representaes, REST utiliza
uma interface uniforme de componentes.
Na prtica, essa interface uniforme aplicada atravs
da utilizao dos mtodos nativos do protocolo HTTP. A
Tabela 2 exibe os principais mtodos HTTP utilizados
em aplicaes RESTFul (Web Services construdos de
acordo com os conceitos REST).
Projeto
Mtodo Funo
GET Obter uma representao de um recurso
POST Criar um novo recurso
PUT Criar um novo recurso / Modificar um j existente
DELETE Remover um recurso existente
Tabela 2. Principais mtodos HTTP utilizados em aplicaes RESTFul
Um exemplo de utilizao do mtodo GET, aplicado ao exem-
plo de busca de filmes citado previamente, seria:
GET http://localhost:8080/REST/filme/1
A invocao deste mtodo retornaria a representao do
filme (recurso) de cdigo 1. Esta situao ser detalhada na
apresentao do exemplo prtico mais adiante. Vale lembrar
que o trecho localhost:8080 pode variar de acordo com a
mquina servidora e a porta utilizadas.
Um exemplo prtico
Agora que os conceitos relativos a esta nova abordagem de
utilizao de servios j foram apresentados, poderemos enten-
der como eles so aplicados na prtica atravs de uma consulta
a um acervo de filmes, implementado em Java.
A IDE utilizada para demonstrar o exemplo foi o Eclipse
[4] verso Galileo e o continer web utilizado foi o Apache
Tomcat [5] verso 6.0.
O servio oferecido consiste em um acervo simplificado de
filmes e as operaes permitidas so as de cadastro e de busca
aos filmes. Por questes de simplicidade, os dados do exemplo
no so persistidos e as camadas de acesso aos dados (padro
DAO) e de servio (padro Service) foram omitidas, assim
como os mtodos get e set dos atributos e as declaraes do
tipo import.
A classe Filme.java, ilustrada na Figura 1 representa a classe
de modelo do exemplo. Os dados do filme, neste contexto, so
as representaes dos recursos que esto sendo disponibiliza-
dos para acesso os filmes.
Figura 1. Classe de modelo da aplicao de exemplo
Para oferecer suporte a servios REST em Java, foi criada a
JAX-RS [6] uma API que surgiu para simplificar o desen-
volvimento da linha de servios REST e oferecer uma forma
Edio 19 - Engenharia de Software Magazine 35
padro de implementao da mesma. Sua implementao de
referncia conhecida como Jersey [7].
Para utilizar o Jersey em uma aplicao RESTFul, os pre-
fixos de URIs do servio devem ser mapeados para um
Servlet do Jersey. A Figura 2 exibe o arquivo web.xml da
aplicao configurado com este mapeamento. Como todas
as URIs so do servio REST, toda a aplicao mapeada
para o Servlet do Jersey.
Figura 2. Arquivo web.xml da aplicao
Com a utilizao do Jersey, um servio implementado como
um recurso atravs de uma classe de Recurso e as requisies
so tratadas por mtodos da mesma. Uma classe de Recurso
contm anotaes da JAX-RS para indicar os mapeamentos e
as operaes disponveis existentes [8].
A classe de recurso do nosso exemplo a exibida na
Figura 3, FilmeResource.java. Como os recursos do nosso
exemplo so representados pelos prprios filmes, a nossa
classe de recurso conter o prefixo /filme. Dessa forma, a
classe deve ser anotada com @Path contendo o prefixo /
filme para garantir que todas as requisies contendo esse
prefixo sero redirecionadas para esta classe de recurso,
onde seus mtodos devem ser pblicos, como por exemplo,
GET http://localhost:8080/REST/filme/1 .
Alm disso, a classe deve conter as anotaes @Consumes e @
Produces, que declaram que os servios da mesma so capazes
de consumir e gerar contedo nos formatos text/XML e applica-
tion/json. O formato JSON (JavaScript Objection Notation) um
formato independente de linguagem baseado em JavaScript.
Para utilizao do recurso por uma aplicao cliente RESTFul,
as solicitaes HTTP devem ser feitas atravs da classe Http-
Client (da API commons-http-client)[9]. Esta API permite que
se montem requisies HTTP e sejam recebidas suas respostas,
da mesma forma que ocorreria com um browser simples.
36 Engenharia de Software Magazine - Arquitetura REST
Figura 3. Classe de Recurso FilmeResource.java da aplicao
Mtodo de busca de filmes
O primeiro mtodo oferecido pelo recurso o de bus-
ca de filmes. O mtodo buscarFilme foi anotado com @
Path({codFilme}). A juno da anotao do mtodo @
Path({codFilme}) com a da classe (@Path(filme)) especi-
fica que o mtodo capaz de responder a requisies para
a URI /filme/codFilme, como por exemplo /filme/1.
Como tambm foi inserida a anotao @GET no mtodo
de busca, todas as requisies do tipo HTTP GET sero
tratadas por este mtodo. A anotao @PathParam utili-
zada para injetar no parmetro codFilme o valor que veio
da URI.
Mtodo de cadastro de filmes
O outro mtodo oferecido o de cadastro de filmes. A
utilizao da anotao @POST garante que todas as re-
quisies do tipo HTTP POST sero encaminhadas para o
mtodo anotado. O parmetro do mtodo cadastrarFilme
um objeto do tipo Filme, que ser enviado no formato
XML em uma requisio.
Alm das anotaes @GET e @POST do exemplo, existem
outras que podem ser utilizadas nos mtodos, como @
DELETE e @PUT.
Consumindo o servio
Para consumir o recurso disponibilizado pelo servidor,
a classe FilmeMain.java (Figura 4) efetua um cadastro de
um filme e realiza uma busca do mesmo.
A converso do filme criado em formato XML feita com
o auxlio da classe XStream, que pertence a uma biblioteca
criada para serializar objetos.
Na execuo da classe, ainda so exibidos o cabealho e
o corpo, tanto da requisio quanto da resposta, para fins
de demonstrao. A Figura 5 mostra a sada da execuo
da classe FilmeMain.java.
 Projeto

Figura 4. Classe Main da aplicao

Figura 5. Sada da execuo da classe Main
Uma das grandes vantagens de REST que as requisies
do tipo GET podem ainda ser feitas de forma bem simples e
rpida atravs de um browser, como ilustra a Figura 6. Atra-
vs das URIs http://localhost:8080/REST/filme/1 e http://
localhost:8080/REST/filme/2, os dados dos filmes de cdigos 1
e 2, respectivamente, foram retornados em formato XML. Neste
contexto, estas URIs representam os identificadores de recurso
definidos por Fielding.

Casos de sucesso
Buscando, sobretudo simplicidade e maior desempenho
das aplicaes, o paradigma REST tem sido utilizado em
larga escala por algumas organizaes, listadas a seguir:

Google Search REST API

No ano de 2008, mais de um ano aps o Google ter descon-
tinuado o Google SOAP Search API conjunto de bibliotecas
para acessar os servios de busca do Google atravs de Web
Services em sua forma tradicional, utilizando SOAP a or-
ganizao lanou o AJAX Search API [10], que oferece uma
interface simples REST. A API suporta o mtodo HTTP GET
e retorna mensagens do tipo JSON. acessem de forma simples as diversas funcionalidades que
A utilizao da API bem simples. Basta fazer uma solici-
tao GET como a mostrada no exemplo prtico e processar
uma resposta do tipo JSON. Alm disso, no necessria
a utilizao de uma chave de licena obrigatria para a
Google SOAP Search API. Outra vantagem a facilidade
de uso e o nmero ilimitado de requisies. Porm, a Goo-
gle Search REST API ainda apresenta algumas restries,
como o nmero mximo de oito resultados por requisio
e a no-permisso para alterar a ordem dos resultados da
pesquisa.
Figura 6. Requisies GET de maneira RESTFul diretamente pelo Browser
Twitter
O Twitter representa um dos mais recentes e bem suce-
didos exemplos de redes sociais da Web. Oferece uma API
para desenvolvedores web possibilitando que os usurios
a ferramenta disponibiliza a Twitter REST API [11].
A Twitter REST API permite automatizar todas as funcio-
nalidades da ferramenta que so acessadas manualmente.
A mesma torna possvel, atravs de requisies HTTP, obter
tweets mensagens enviadas de um determinado usurio,
responder um usurio ou at mesmo filtrar tweets com base
em critrios pr-definidos.
Para ilustrar este cenrio, pode-se considerar a URI http://
twitter.com/statuses/user_timeline.atom?id=liviaruback. A
mesma retorna o timeline ltima mensagem enviada em
formato XML, do usurio liviaruback.

Edio 19 - Engenharia de Software Magazine 37

 Assim como a API REST do Google, a Twitter REST API
ainda tem algumas limitaes como o nmero mximo de
100 requisies por hora. Porm, caso sejam necessrias mais
de 100 requisies, pode-se requisitar ao Twitter pertencer a
uma lista branca que permite aos seus usurios mais de 100
acessos por hora.
Concluso
Como apresentado neste artigo, a implementao de Web
Services pode ser feita de duas maneiras: da forma como a
Arquitetura de Web Services foi especificada (utilizando SOAP
e WSDL) ou atravs dos princpios do paradigma REST.
A viso tradicional para implementao de Web Services
baseada em trocas de mensagens no formato do protocolo
SOAP e que devem seguir um contrato WSDL. Nesse contexto,
o protocolo HTTP utilizado somente para transporte. Ambos
os lados cliente e servidor precisam conhecer e entender
SOAP e WSDL para desempacotar e utilizar os dados.
Dessa forma, cria-se uma abstrao da comunicao onde
ferramentas devem encapsular a informao para que o seu
receptor a entenda e a processe. Alm disso, as trocas de men-
sagens precisam ser envelopadas dentro de um pacote SOAP,
e o que realmente utilizado uma parte muito pequena do
contedo contido no mesmo. Estas informaes desnecessrias
podem comprometer o desempenho de um sistema e o que
geralmente acontece.
De acordo com a viso arquitetural de REST, o protocolo
HTTP j rico o suficiente para que seja criada uma abstrao
para a construo de servios.
Como detalhado no exemplo, pode-se fazer o uso unicamente
do protocolo HTTP para a comunicao, atravs do acesso di-
reto aos mtodos nativos GET, POST, PUT e DELETE. Como
a Web baseada em HTTP, em muitos casos a utilizao de
REST a mais adequada, pois aumenta a velocidade de comu-
nicao entre os servios e, consequentemente, o desempenho
geral da aplicao.
Porm, para integraes em aplicaes corporativas ou
aplicaes nas quais realmente existe a necessidade de serem
manipulados vrios formatos - em vez de s XML, ou que os
servios oferecidos devem possuir um contrato formal, serem
desacoplados e reutilizveis, o paradigma REST no a melhor
opo, pois no possui um padro oficial para a descrio dos
seus servios, como o WSDL.
O fato que para determinadas aplicaes, REST claramente
mais adequado do que a viso tradicional, por exemplo, quan-
do se pode ter uma interao usurio-aplicao. Um exemplo
38 Engenharia de Software Magazine - Arquitetura REST
que ilustra este cenrio um servio que poderia ser acessado
via Ajax atravs de um browser diretamente por um usurio.
Em casos como esse, a utilizao de REST muito mais simples.
Basta ter um conhecimento sobre o protocolo HTTP e seus m-
todos invocando-os a partir de mtodos nativos do protocolo.
No exemplo demonstrado anteriormente, por exemplo, para se
buscar informaes sobre um determinado filme, a abordagem
REST visivelmente a mais simples, visto que a solicitao GET
pode ser realizada at mesmo atravs de um browser.
Outros exemplos de utilizao so os servios para celulares
e PDAs, e outros dispositivos mveis, onde cada requisio
tem um custo relativamente alto. Nestes casos, utilizar servi-
os REST sem dvida a melhor opo, devido sobretudo
simplicidade e ao desempenho. A maior prova disso tem sido
a utilizao em larga escala do paradigma por organizaes
como o Google, Twitter e Facebook.
Referncias
1. WSA Web Service Architecture: http://www.w3.org/TR/ws-arch/wsa.pdf
2. Fundamentos de Arquitetura de Software Guilherme Gerloglio: http://cnx.org/content/
m17524/1.20/
3. Tese de doutorado de Roy Fielding: http://www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.htm
4. Eclipse: http://www.eclipse.org/
5. Apache Tomcat: http://tomcat.apache.org/
6. JSR 311: JAX-RS: The Java API for RESTful Web Services: http://jcp.org/en/jsr/detail?id=311
7. Jersey: http://jersey.dev.java.net/
8. Web Services REST Bruno Pereira: http://brunopereira.org/webservicesrest-indice/
9. Jakarta Commons Http Client: http://hc.apache.org/httpclient-3.x/
10. Google Search REST API: http://googlesystem.blogspot.com/2008/04/google-search-rest-api.html
11. Using the Twitter REST API: http://www.ibm.com/developerworks/web/library/x-
twitterREST/index.html?ca=drs-
D seu feedback sobre esta edio! 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, atravs do link:
edio
www.devmedia.com.br/esmag/feedback

Usando banco de dados objeto-relacionais
Transio das classes para um modelo de dados objeto-relacional
Ana Cristina Melo
informatica@anacristinamelo.com.br
especialista em Anlise de Sistemas e pro-
fessora de graduao e ps-graduao da
Universidade Estcio de S. Atua em anlise
e programao h 21 anos, sendo os ltimos
11 anos no servio pblico. Autora do livro
Desenvolvendo aplicaes com UML - do
conceitual implementao, na segunda
edio, e Exercitando modelagem em UML.
Palestrante em alguns eventos, entre eles,
Congresso Fenasoft, OD e Sepai.
De que se trata o artigo?
Este artigo tem por objetivo apresentar um
SGBD-OR (sistema gerenciador de banco de
dados objeto-relacional), comparando-o com
o modelo vigente em mercado, o SGBD-R
(sistema gerenciador de banco de dados rela-
cional). Alm disso, ser demonstrado como
feita a transio de um modelo de classes para
um modelo objeto-relacional, usando como
exemplos de implementao, o banco de dados
Oracle.
E
m tempos remotos, pensar em for-
ma de armazenamento era pensar
em dados organizados em colees
logicamente relacionadas compondo ar-
quivos. Contudo, mesmo com a separao
fsica de programas e dados, toda a gern-
cia destes dados ainda ficava embutida no
cdigo-fonte dos programas.
A evoluo ocorreu na dcada de 60
com o surgimento dos sistemas de ban-
cos de dados, reunindo num s lugar to-
das as funes necessrias localizao
e manipulao dos dados, tornando-se
uma camada lgica entre a aplicao e
os dados propriamente ditos.
Edio 19 - Engenharia de Software Magazine
Projeto
Para que serve?
Fornecer aos desenvolvedores ou estudantes
da rea de sistemas exemplos prticos de como
transpor um modelo de classes para o projeto
de banco por meio de um modelo objeto-rela-
cional implementado em um SGBDOR.
Em que situao o tema til?
Para entender como a ligao entre os modelos
de classes e o modelo de dados pode ser mais
transparente quando esse banco pertence ao
mesmo paradigma; alm de compreender como
o Oracle trabalha como um banco de objetos.
Os bancos de dados trabalham com
uma arquitetura que separa a parte
fsica das aplicaes por meio de trs
esquemas:
Esquema interno: descreve a estrutura
fsica de armazenamento do banco de
dados, sua organizao de arquivos e os
seus mtodos de acesso;
Esquema conceitual: descreve a estru-
tura do banco de dados sob o ponto de
vista do usurio, escondendo os detalhes
de armazenamento e concentrando-se
na descrio de entidades, atributos,
relacionamentos, operaes do usurio
e restries sobre os dados;
39
 Esquema externo (ou vises do usurio): descreve as par-
tes do banco de dados que so do interesse de um grupo de
usurios, escondendo as demais.
Os esquemas so apenas camadas lgicas, pois o nico nvel
que realmente existe armazenando os dados o nvel interno.
A representao dos conceitos de cada nvel feita com o uso
de modelos de dados.
No esquema interno so utilizados modelos fsicos de dados,
que so usados para descrever a organizao dos arquivos e os
mtodos de acesso, tal como definido no esquema.
Nos esquemas conceitual e externo existem duas categorias
de modelos: o modelo conceitual, um modelo de alto nvel que
traz conceitos prximos da percepo que os usurios tm dos
dados; e o modelo lgico, um modelo de nvel intermedirio
que traz conceitos que podem ser entendidos pelos usurios
finais, mas que no esto muito distantes do formato como os
dados so organizados no computador.
O Modelo de Entidades-Relacionamentos (ER) o modelo con-
ceitual mais utilizado no projeto de banco de dados.
Os modelos de dados em rede, hierrquico, relacional e OO so
conhecidos como modelos lgicos.
O modelo relacional foi introduzido por E. Codd em 1970,
propondo o trabalho com tabelas, baseando-se em conceitos
matemticos da lgebra Relacional. Nos ltimos anos, novas
demandas surgiram a partir das aplicaes no-convencionais.
Contudo, os requisitos necessrios para se atender a essas de-
mandas no eram encontrados nos modelos lgicos existentes.
Este problema incitou o surgimento dos modelos relacionais
estendidos ou objeto-relacionais, que trazem em sua essncia
a incorporao de caractersticas do paradigma orientado a
objetos como extenses aos sistemas relacionais.
Os modelos de dados OO apresentam conceitos de: objetos
(com encapsulamento), classes (com atributos e mtodos), re-
lacionamentos (herana, associao e agregao) e identidade
de objetos.
Cada objeto encapsula os atributos e os mtodos.
So caractersticas da identidade de objetos, conhecida como
OID (object identifier):
so gerados pelo sistema;
no so visveis aos usurios;
so independentes do endereo de armazenamento;
no sofrem mutaes;
desejado que seja utilizado uma nica vez (mesmo aps
a excluso do objeto).
O modelo relacional trouxe a realidade de SGBD-Rs (Siste-
mas Gerenciadores de Bancos de Dados Relacionais) robustos
e eficientes, que atenderam ao mercado por vrias dcadas.
Contudo, com o surgimento e solidificao do paradigma
da orientao a objetos, as limitaes dos bancos relacionais
tornaram-se mais evidentes, trazendo discusso:
o nmero reduzido de tipos de dados;
os valores dos campos no serem atmicos;
inapropriao para armazenamento e busca de novos tipos
de dados como imagens, udio e vdeo.
40 Engenharia de Software Magazine - Usando banco de dados objeto-relacionais
SGBD-OOs (Sistemas Gerenciadores de Bancos de Dados
orientados a objeto) e SGBD-ORs (Sistemas Gerenciadores
de Bancos de Dados Objetos Relacionais)
No incio da dcada de 90, surgiram vrios SGBD-OOs (sis-
temas gerenciadores de bancos de dados orientados a objetos),
onde o centro da ateno deixou de ser a relao com a tabela
e passou a ser com a classe.
Em 1991, um grupo de fabricantes de SGBDs e empresas
que trabalham com padres criaram o grupo ODMG (Object
Database Management Group), responsvel por padronizar
as funcionalidades dos bancos de dados orientados a objetos.
Esse grupo definiu no s o modelo de dados OO, mas tambm
os padres ODL (Object Definition Language) e OQL (Object
Query Language).
Um SGBD-OO um sistema com as caractersticas de SGBDs,
acrescidos da manipulao de objetos contemplando:
definio de objetos complexos, com estrutura aninhada,
como conjuntos ou listas de objetos, alm dos tipos de dados
primitivos;
implementao de encapsulamento, determinando que
todo acesso aos objetos seja por meio da aplicao de um
procedimento;
identidade de objeto, fazendo com que os objetos sejam
distinguidos por um identificador nico, mesmo que os valores
dos atributos sejam os mesmos.
Atualmente existem poucos bancos orientados a objetos.
Podemos citar: Gemstone, ObjectStore, Versant, Jasmine, Poet,
Objectivity e O2.
Os SGBD-ORs (sistemas gerenciadores de bancos de dados
objetos-relacionais) surgiram como uma reao dos princi-
pais fabricantes de SGBD-R aos SGBD-OOs. Nos bancos de
dados objeto-relacionais, o banco relacional tem uma parte
transformada, alm de receber a adio de novos recursos que
permitam implementaes orientadas a objetos.
Um SGBD-OR um SGBD que suporta SQL-3. Leia no Box 1
sobre a evoluo do SQL.
Alguns bancos objeto-relacionais atuais: Oracle, PostgreSQL,
Informix, DB2, Cach e SQLServer.
Veja na Tabela 1 as principais diferenas entre os SGBD-OOs
e os SGBD-ORs.
A SQL foi projetada como uma linguagem de alto nvel para
banco de dados, prxima da linguagem natural, para ser usada
em aplicaes e/ou diretamente por usurios finais em consultas
ao banco.
Foi adotada como padro na sua verso SQL-86. Novas verses
surgiram em 89 (SQL-89) e em 92 (SQL-2).
Em 1999, aparece a verso SQL:1999 (SQL-3), contendo exten-
ses ao padro SQL-92, entre outros, a modelagem de objetos.
Ficou definido como o padro de linguagem objeto-relacional
em bancos.
Nova verso surgiu em 2003 (SQL: 2003), introduzindo, entre
outras caractersticas, suporte ao XML.
Box 1. Diferenas entre SGBD-OO e SGBD-OR
 Projeto

SGBD-OO SGBD-OR
privilgio de CREATE UNDERTYPE: para criar
- modelo de dados mais rico - combina as melhores caractersticas do modelo de subtipos;
- adequado ao mercado de aplicaes no- objetos no modelo relacional
convencionais - combina um modelo rico com mais eficincia no Veja na Listagem 1 a sintaxe do comando CREATE TYPE para
- baixa performance e escalabilidade gerenciamento de dados criao de tipos e criao de subtipos (uso de UNDER).
- os dados so objetos com estrutura complexa - os dados so tabelas com estrutura complexa
- capacidade de consulta limitada, baseada em - uso do padro SQL estendido (SQL-3) para garantir
Listagem 1. Sintaxe do comando CREATE TYPE
navegao por objetos flexibilidade nas consultas
- baixa performance - espera-se alta performance CREATE [OR REPLACE] TYPE nome_esquema.nome_tipo IS/AS OBJECT
(atributo1
Tabela 1. Diferenas entre SGBD-OO e SGBD-OR tipo_dado1
especificao_elemento_1,
atributon
tipo_dadon
Oracle como Banco Objeto-Relacional especificao_elemento_n)
[[NOT] [FINAL]] [[NOT][INSTANTIABLE]]
Devido falta de padronizao do modelo objeto-relacional,
cada fabricante definiu as caractersticas do seu SGBD. CREATE [OR REPLACE] TYPE nome_esquema.nome_tipo UNDER nome_
esquema.nome_supertipo
Como linha de trabalho, vamos analisar a forma como o (atributo1
tipo_dado1
Oracle se comporta como um banco objeto-relacional, a par- especificao_elemento_1,
atributon
tir da sua verso 8i, quando passou a seguir o SQL-3, como tipo_dadon
padro. especificao_elemento_n)
[[NOT] [FINAL]] [[NOT][INSTANTIABLE]]

Object Type
Representam uma extenso dos tipos de dados relacionais
do Oracle. O Object Type o tipo de dado que corresponder ao
conceito de classe, no paradigma de orientao a objetos.
Os Object Types so compostos de:
um nome que identifica o objeto unicamente dentro do
esquema;
um ou mais atributos que modelam a estrutura do objeto,
podendo ser tipos primitivos ou outros Object Types;
zero ou mais mtodos que so funes ou procedimentos
implementados em PL/SQL, C ou Java (dependendo do banco)
e armazenados no prprio banco.
O Object Type por ser a abstrao de uma classe, no permite
nenhum tipo de armazenamento direto. Enxergado como um
tipo de dados, usado na definio de uma tabela, coluna ou
em variveis dos mtodos.
Uma tabela criada a partir de um Object Type chamada
Object Table (tabela de objetos). Cada linha dessa object table
chamada de object row (linha objeto). Cada object row tem
associado a ela um OID Object Identifier.
Mas um Object Type tambm pode ser utilizado em uma tabela
relacional. Nesse caso, ser utilizado como tipo de dados de
uma coluna. Essa coluna ser identificada como object column
(coluna objeto). E esse registro no possuir OID.
Contudo, objetos que so divididos entre vrios outros obje-
tos, por meio de relacionamentos, precisam ser referenciados
como Object Row.
Para criar um object type no Delphi, usamos a declarao
CREATE TYPE. J a declarao CREATE TYPE BODY define
o cdigo para os mtodos referenciados no tipo. Veja os privi-
lgios necessrios para criao de tipos:
privilgio de CREATE TYPE: para criar tipos de objeto
no prprio esquema;
privilgio de CREATE ANYTYPE: para criar tipos de
objeto em outros esquemas;
Para entendermos o uso do Object Type, considere o pedao
de modelo de classes da Figura 1.
Figura 1. Trecho de um modelo de classes para exemplificar criao de
object types
Vejamos agora na Listagem 2 os comandos do Oracle para
criar a classe Telefone e a classe Cliente.
Repare que a classe Telefone se transformar no Object Type
TTelefone. Esse T na frente uma conveno minha para
indicar um tipo definido pelo usurio. A classe Cliente se trans-
formar no Object Type TCliente. Como um object type no recebe
dados, criaremos a Object Table (tabela de objetos) Cliente.
O relacionamento da classe Cliente com Telefone, nesse caso,
tem apenas uma multiplicidade de 1. Sendo assim, usamos
a forma mais simples de definir esse relacionamento, por
colocao da object type apenas como tipo de dados.
O primeiro comando da listagem 1 cria o tipo (classe) TTe-
lefone contendo os atributos ddd, numero e tipo. O segundo
comando cria o tipo (classe) TCliente contendo os atributos
codigo, nome e tel. Sendo que tel um atributo, cujo tipo de
dados no um tipo primitivo, mas um object type. Para
que possamos efetivamente armazenar os nossos dados,
precisamos criar uma tabela de objetos a partir da classe
TCliente. Assim feito no terceiro comando, onde criada a
Object Table Cliente.
Na Listagem 3 exemplificamos como inserir dados na Object
Table Cliente.
Repare na Listagem 3 que o INSERT comea similar ao que
conhecemos no SQL. A diferena reside em como vamos inserir

Edio 19 - Engenharia de Software Magazine 41

os dados do Object Type. Para isso, faz-se a chamada de um Imagine que quisssemos obter o telefone completo com o
construtor, que consiste em colocar frente dos dados que faro ddd. Bastaria colocar na query uma concatenao de ddd + o
parte do tipo de dados criado, o prprio nome da classe. nmero de telefone. S que toda vez que quisssemos obter
A nossa object table j possui alguns dados. Ento, o natural essa combinao, teramos que escrev-la no select. S que ob-
agora recuperar esses dados. Imagine que quisssemos saber ter o telefone completo pode ser um mtodo da classe telefone,
o nome do cliente e o nmero de telefone de todos os clientes como poderia ser de uma classe nota o mtodo calcularMe-
que tm ddd igual a 24. Repare na Listagem 4 como ficaria dia. Assim, vejamos na Listagem 6 como alterar esse tipo para
essa query. incluir um mtodo que mostre o telefone completo.
No primeiro comando da Listagem 6, estamos alterando o
tipo TTelefone. A alterao consiste da incluso de um mto-
Listagem 2. Criando object type e object table
do (ADD MEMBER), contudo poderia ser a incluso de um
CREATE TYPE TTelefone AS OBJECT
(ddd varchar2(2),
atributo (ADD ATTRIBUTE). Uma clusula importantssima,
numero varchar2(8), nesse caso, a CASCADE. Essa clusula determina que essa
tipo char(1));
alterao deve ser refletida em cascata a todas as tabelas de
CREATE TYPE TCliente AS OBJECT
(codigo number(4), objetos, colunas objetos ou object types criados a partir do tipo
nome varchar2(50),
tel TTelefone);
TTelefone.
De acordo com a documentao da Oracle, qualquer operao
CREATE TABLE Cliente OF TCliente;
feita aps uma alterao de tipo resultar no erro abaixo:
Listagem 3. Inserindo objetos numa Object Table ORA-22337: o tipo do objeto acessado evoluiu
INSERT INTO Cliente VALUES (
11, Armando Santos, Para se evitar esse erro, deve-se reconectar, antes de sub-
TTelefone(21, 21116666, R) );
meter o comando de operao.
INSERT INTO Cliente VALUES (
12, Veronica da Silva, O mtodo que definimos na Listagem 6 contempla um
TTelefone(21, 98765432, C) );
mtodo de escopo de instncia (ou no esttico), ou seja, que
INSERT INTO Cliente VALUES ( depende do valor da instncia (do objeto) para retornar a sua
13, Terezina do Esprito Santo,
TTelefone(21, 31115555, R) ); informao. Tambm podemos definir um mtodo de escopo
INSERT INTO Cliente VALUES ( de classe (ou esttico), ou seja, que independe do valor de uma
14, Pierre Le Monge, instncia, sendo sempre um mesmo valor ou procedimento
TTelefone(24, 98776655, C) );
para todas as instncias. Para se definir um mtodo esttico
INSERT INTO Cliente VALUES (
15, Dourivaldo Bezerra, (com escopo de classe), no lugar da clusula MEMBER, colo-
TTelefone(21, 45667788, T) );
camos a clusula STATIC. Veja exemplo abaixo:
Listagem 4. Exemplo de um select numa object table MEMBER PROCEDURE FuncaoNaoEstatica IS
STATIC PROCEDURE FuncaoEstatica IS
SELECT C.NOME, C.TEL.NUMERO
FROM Cliente C
WHERE C.TEL.DDD = 24
Na Listagem 7, vemos como possvel alterar o valor de
NOME
---------------------------------
TEL.NUMERO
----------
um dado que pertence a uma object type, usando o nosso
Pierre Le Monge 98776655 exemplo do telefone, e, em seguida, uma query que obtm
os telefones, fazendo uso do mtodo TelCompleto() adicio-
nado ao tipo.
Repare que o acesso feito pela notao de ponto. Se a
tabela de objetos tem um atributo TEL e esse atributo, por Listagem 5. Exemplo de um select numa object table usando recurso de
sua vez, possui vrios atributos, pois foi criado a partir group by
de uma classe, basta que eu navegue at o atributo TEL e SELECT C.TEL.TIPO TipoTelefone, COUNT(*) QtdClientes
FROM Cliente C
a partir dele chegue at o atributo desejado. Ento, para GROUP BY C.TEL.TIPO;
se fazer referncia ao nmero do telefone, seja para exibir
TipoTelefone QtdClientes
como campo, seja para filtrar a pesquisa por meio dele, o ------------ -----------
R 2
acesso se dar assim: C 2
T 1
C.TEL.NUMERO
Listagem 6. Alterao um object type com a incluso de um mtodo

Antes do atributo TEL, foi colocado o alias C.. Pois obri- ALTER TYPE TTelefone
ADD MEMBER FUNCTION TelCompleto RETURN VARCHAR2 CASCADE;
gatria a utilizao de aliases na manipulao de objetos.
CREATE OR REPLACE TYPE BODY TTelefone IS
As consultas feitas em object tables podem utilizar todos MEMBER FUNCTION TelCompleto RETURN VARCHAR2 IS
os recursos usados em consultas relacionais. Por exemplo, BEGIN
RETURN ( || DDD || ) || NUMERO;
se quisssemos saber quantos telefones tm de cada tipo, END;
END;
poderamos aplicar a query descrita na Listagem 5.

42 Engenharia de Software Magazine - Usando banco de dados objeto-relacionais

 Projeto

Referncias e colees de referncias Listagem 7. Alterao de um atributo pertence a object type e query
Usamos as referncias e as colees de referncias para definir- chamando mtodo
mos relacionamentos entre objetos. Para que um objeto possa ter UPDATE Cliente C
uma coluna que uma referncia para outro objeto (que pode SET C.TEL.NUMERO = 87564321
WHERE C.CODIGO = 14
ser referncia de vrios outros objetos), essa tabela referencia-
SELECT C.NOME, C.TEL.TELCOMPLETO() TELEFONE
da precisa ser uma object table, ou seja, essa linha referenciada FROM Cliente C
ORDER BY C.NOME
precisa ser uma object row. Por exemplo: Se tivermos uma tabela
Bairro que tenha um atributo cidade que uma referncia, esse NOME TELEFONE
--------------------------------- -------------
atributo deve apontar para uma object table Cidade. Armando Santos (21) 21116666
Dourivaldo Bezerra (21) 45667788
A coluna que contm a referncia armazenar um ponteiro Pierre Le Monge (24) 87564321
Terezina do Esprito Santo (21) 31115555
para a linha objeto da outra tabela. Sendo assim, um REF nada Veronica da Silva (21) 98765432
mais do que um ponteiro lgico para uma object row.
Vejamos o trecho de um modelo de classes, apresentado na Listagem 8. Utilizao de referncia em object type. CREATE TYPE TCargo AS

Figura 2, para exemplificarmos o uso de referncias. Lembra- OBJECT

mos que REF usado quando temos um relacionamento de (codigo number(3),

titulo varchar2(30),
multiplicidade 1. Para multiplicidades acima de 1, devemos salario number(7,2),
usar uma coleo de referncias. MEMBER FUNCTION CalculaSalario RETURN number);

CREATE OR REPLACE TYPE BODY TCargo IS

MEMBER FUNCTION CalculaSalario RETURN number IS
BEGIN
return (salario * 1.15) * 0.91;
END;
END;

CREATE TYPE TFuncionario AS OBJECT

(matricula varchar2(5),
nome varchar2(50),
cargo REF TCargo);
Figura 2. Trecho de um modelo de classes para exemplificar uso de
referncias CREATE TABLE Cargo OF TCargo;
CREATE TABLE Funcionario OF Tfuncionario;

A Listagem 8 apresenta a criao da classe Cargo e da Listagem 9. Insert em object table que possui referncias
classe Funcionario. Repare que na definio do atributo INSERT INTO Cargo VALUES (100, Secretria Jr, 1500);
cargo da classe Funcionario que faz referncia tabela Car- INSERT INTO Cargo VALUES (110, Secretria Sr, 2300);
INSERT INTO Cargo VALUES (200, Programador Jr, 2000);
go, temos a clusula REF. Depois criaremos as object tables INSERT INTO Cargo VALUES (210, Programador Sr, 3100);
INSERT INTO Cargo VALUES (220, Analista Jr, 4000);
Funcionario e Cargo. Repare que a classe Cargo j est sendo INSERT INTO Cargo VALUES (230, Analista Sr, 5600);
criada com o mtodo calculaSalario(), para o qual aplicamos INSERT INTO Cargo VALUES (300, Auditor, 7900);

uma frmula bem simples, apenas para fins didticos. O INSERT INTO Funcionario
SELECT 95001, Marieta da Silva, REF(C)
salrio tem uma comisso de 15%, e depois descontado FROM Cargo C
um percentual de 9% de previdncia. WHERE C.codigo = 110;

Vejamos agora na Listagem 9 como feita a insero de INSERT INTO Funcionario

SELECT 99005, Joana Filigrama, REF(C)
dados nas duas object tables. Repare que apresentamos duas FROM Cargo C
formas de fazer o mesmo insert. Em qualquer uma das WHERE C.codigo = 100;

duas precisamos fazer um select na object table Cargo para INSERT INTO Funcionario
SELECT 05003, Raul da Ferrugem, REF(C)
obter o OID da mesma e associ-lo ao atributo cargo. Para FROM Cargo C
se obter esse OID, basta pedir o REF(alias-da-tabela). WHERE C.codigo = 200;

Como j vamos fazer um select, podemos montar nos INSERT INTO Funcionario
SELECT 05004, Vitor da Silva, REF(C)
campos do select os valores fixos que sero inseridos na FROM Cargo C
object table Funcionario. Essa a primeira soluo, adotada WHERE C.codigo = 200;

nos quatro primeiros inserts. A segunda forma mantm INSERT INTO Funcionario VALUES (
06010, Marilia Votoran,
os valores fixos como campos da clusula VALUES, e, (select REF(C) from Cargo C where c.codigo = 210) );
quando da colocao no atributo cargo, fazemos o select
INSERT INTO Funcionario VALUES (
na object table Cargo. Essa soluo adotada nos ltimos 03030, Paulino Freire,
(select REF(C) from Cargo C where c.codigo = 220) );
quatro inserts.
Na Listagem 10 podemos conferir como feito o select INSERT INTO Funcionario VALUES (
03050, Ana Miranda,
para recuperar o relacionamento entre Funcionario e (select REF(C) from Cargo C where c.codigo = 230) );
Cargo. Queremos trazer todos os funcionrios que tm INSERT INTO Funcionario VALUES (
o cargo menor que 200. Para cada funcionrio, exibir o 04050, Raul da Silva,
(select REF(C) from Cargo C where c.codigo = 230) );
nome, o cargo e o salrio lquido, obtido com o mtodo
calculaSalario().

Edio 19 - Engenharia de Software Magazine 43

 Se utilizarmos na pesquisa apenas a referncia de cargo, di- Listagem 10. Select usando REF
retamente, o banco trar o OID que est armazenado na object SELECT F.NOME, F.CARGO.TITULO, F.CARGO.CALCULASALARIO() SLIQ
column. Veja na Listagem 11. FROM Funcionario F
WHERE F.CARGO.CODIGO < 200
Contudo, se utilizarmos na pesquisa a clusula DEREF, o
NOME CARGO SLIQ
Oracle primeiro copia o objeto, para depois exibi-lo. Veja na --------------------------------- --------------- -------
Listagem 12. Marieta da Silva Secretria Sr 2406,95
Joana Filigrama Secretria Jr 1569,75
As colees permitem o agrupamento de elementos de mes-
Listagem 11. Select direto na object column
mo tipo e podem ser constitudas de: tipos primitivos, object
types ou referncias. As colees so de dois tipos: Varray e SELECT F.NOME, F.CARGO
FROM FUNCIONARIO F
Nested Tables. WHERE F.MATRICULA = 95001

O Varray permite definirmos colees com um nmero fixo NOME

---------------------------------
de elementos. No caso de ser usado como tipo de dados de uma CARGO
coluna, os elementos so armazenados na prpria tabela. No ----------------------------------------------------------
Marieta da Silva
podemos apagar elementos individuais de um varray. 00002202083F4BA34F15C44568A3CF411CA6DE2C7
F06C3E663F32C40F6BACF849D5157FF21
A Nested Table (tabela aninhada) permite definirmos colees
Listagem 12. Select usando DEREF
com nmero ilimitado de elementos. No caso de ser usado
como tipo de dados de uma coluna, os elementos so armaze- SELECT F.NOME, DEREF(F.CARGO)
FROM FUNCIONARIO F
nados em uma outra tabela (tabela aninhada). Podemos apagar WHERE F.MATRICULA = 95001

elementos individuais de uma nested table. NOME

---------------------------------
Vamos considerar o pedao de um modelo de classes apresen- DEREF(CARGO) (CODIGO, TITULO, SALARIO)
tado na Figura 3 para exemplificar o uso do varray. Repare que ----------------------------------------------------------
Marieta da Silva
o mesmo modelo da Figura 1, porm, agora, o nosso cliente TCARGO(110, Secretria Sr., 2300)

pode ter trs telefones. Listagem 13. Criao de um varray

CREATE TYPE TListaTelefones AS VARRAY(3) OF TTELEFONE;

CREATE TYPE TClienteEsp AS OBJECT

(codigo
number(4),
nome varchar2(50),
telefones T
ListaTelefones);

CREATE TABLE ClienteEsp OF TClienteEsp;

Listagem 14. Insert em varray

Figura 3. Trecho de um modelo de classes usando INSERT INTO ClienteEsp VALUES (
multiplicidade maior do que 1 1001, Vitoriana Silva,
TListaTelefones( TTelefone(21, 99998888, C),
TTelefone(21, 22221111, R) ) );
Na Listagem 13 vemos como feita a criao da coleo de
INSERT INTO ClienteEsp VALUES (
telefones. Vamos considerar que j est criada a object type 1005, Suzanete Pedreira,
TListaTelefones( TTelefone(24, 76660001, C),
TTelefone. Sendo assim, primeiro damos um nome coleo TTelefone(21, 21334455, R),
TTelefone(21, 40010009, T) ) );
(TListaTelefones) e depois dizemos que ela uma coleo fixa
(varray) de trs elementos, no qual cada elemento tem a estru- INSERT INTO ClienteEsp VALUES (
1024, Machadiana Fonseca,
tura/formato da object type TTelefone. TListaTelefones( TTelefone(21, 21110000, R),
TTelefone(21, 23330000, R),
A seguir criamos uma nova classe Cliente, que vamos cha- TTelefone(21, 99988887, C ) );
mar de TClienteEsp. E a partir dela, criamos uma object table
chamada ClienteEsp. Listagem 15. select de um varray

Vejamos agora na Listagem 14 como fazemos a insero de SELECT C.NOME, C.TELEFONES

FROM CLIENTEESP C
dados na tabela de objetos ClienteEsp. Repare que a grande WHERE C.CODIGO = 1024;
alterao est no momento de inserir os telefones. Para que NOME
possamos inserir uma lista de telefones, temos que usar o ---------------------------------
TELEFONES
mtodo construtor que inicializa uma coleo, de acordo com o ----------------------------------------------------------
Machadiana Fonseca
que foi definido no atributo. Por isso, para dar carga no atributo TLISTATELEFONES(TTELEFONE(21, 21110000, R),
telefones, usamos o construtor TListaTelefones, pois esse o nome TTELEFONE(21, 23330000, R), TTELEFONE(21, 99988887,
C))
da varray criada. Contudo, como cada elemento dessa lista
por sua vez uma object type, para inserirmos cada elemento
preciso usar o mtodo construtor TTelefone. Na Listagem 17 preparamos uma query usando o varray, no
Para exibir o campo telefones, podemos verificar na Listagem 15 s no relacionamento como na clusula where.
como isso feito. Tambm podemos exibir esses telefones utili- Agora, para encerrar, considere o trecho de um modelo de
zando uma Unnesting Query, que permite a visualizao dos classes apresentado na Figura 4, para exemplificar o uso da
dados num formato de tabela relacional. Veja na Listagem 16. Nested Table.

44 Engenharia de Software Magazine - Usando banco de dados objeto-relacionais

 Projeto

Listagem 16. select de um varray usando unnesting query Listagem 18. criao de uma nested table

SELECT C.NOME, VALUE(T) CREATE TYPE TDEPENDENTE AS OBJECT

FROM CLIENTEESP C, TABLE(C.TELEFONES) T (nome
WHERE C.CODIGO = 1024; varchar2(40),
parentesco
NOME varchar2(1));
VALUE(T)

CREATE TYPE TListaDependentes AS TABLE OF TDEPENDENTE;
---------------------------------
------------------
Machadiana Fonseca CREATE TYPE TSERVIDOR AS OBJECT
21110000 (matricula
Machadiana Fonseca
number(5),
23330000 nome
Machadiana Fonseca varchar2(40),
99988887 dependentes

TListaDependentes);
Listagem 17. select de um varray
CREATE TABLE SERVIDOR OF TSERVIDOR
-- Mostrar o nome dos clientes que possuem telefone celular. NESTED TABLE DEPENDENTES STORE AS TAB_DEPENDENTES;
SELECT C.NOME Listagem 19. insert em uma nested table
FROM CLIENTEESP C, TABLE(C.TELEFONES) T
WHERE T.TIPO = C;
INSERT INTO SERVIDOR VALUES (
NOME 1001, BARTOLOMEU VIEIRA,
TLISTADEPENDENTES(
--------------------------------- TDEPENDENTE(ANITA VIEIRA, C),
TDEPENDENTE(ANUSKA VIEIRA, F),
Vitoriana Silva TDEPENDENTE(VITOR VIEIRA, F)));
Suzanete Pedreira
Machadiana Fonseca
INSERT INTO SERVIDOR VALUES (
1205, JULIETA VIDAL,
TLISTADEPENDENTES(
TDEPENDENTE(CARLO VIDAL, C),
TDEPENDENTE(SUZANA VIDAL, F)));

Listagem 20. select com uma nested table

-- Mostrar o nome de todos os dependentes de todos os

servidores.
Figura 4. Trecho de um modelo de classes com multiplicidade
SELECT S.NOME, D.NOME NOMEDEP
de muitos, para exemplificar uma nested table FROM SERVIDOR S, TABLE(DEPENDENTES) D

NOME
Na Listagem 18 comeamos criando a object type TDependente.
NOMEDEP
Para que ela possa ser incorporada a uma object table como ---------------------------------
-----------------------
uma coleo de produtos, precisamos criar o tipo TListaDe- BARTOLOMEU VIEIRA
ANITA VIEIRA
pendentes que uma tabela de TDependente. Repare que no BARTOLOMEU VIEIRA
um array, mas uma tabela, que permite manipulaes mais ANUSKA VIEIRA
BARTOLOMEU VIEIRA
livres e infinitas. VITOR VIEIRA
Depois criamos a object type TServidor, com o atributo dependen- JULIETA VIDAL

CARLO VIDAL
tes que estar apontando para o object type TListaDependentes. JULIETA VIDAL

SUZANA VIDAL
Agora vamos criar a object table Servidor. Contudo essa criao
apresentar um comando extra, que da criao da tabela
aninhada. A tabela aninhada indica onde ser armazenado o invistam no suporte necessrio para que as empresas migrem
contedo do atributo dependentes. suas bases de dados para modelos orientados a objetos.
Na Listagem 19 vemos como inserir dados na object table Os benefcios para balizar essa deciso j existem, visto
Servidor. que bancos objeto-relacionais tm melhor perfomance, em
Na Listagem 20 vemos como recuperar os dados de Servidor. funo do uso de ponteiros, alm de oferecer consultas mais
Observe que a tabela TAB_DEPENDENTES no pode ser aces- rpidas e compactas. Desta forma, resta aguardarmos que
sada diretamente. A mesma apenas um meio de armazena- a teoria d lugar prtica, unificando todas as fases do de-
mento para os dados aninhados object table Servidor. senvolvimento de sistemas, sob um nico paradigma o da
orientao a objetos.
Concluso
Hoje a realidade aponta para o uso intensivo de modelos
D seu feedback sobre esta edio! Feedback
orientados a objetos. Para que os ganhos sejam reais, no nvel eu
s
D

de banco de dados, o mapeamento objeto-relacional usado A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e

em larga escala. Contudo, essa no a melhor soluo, pois Para isso, precisamos saber o que voc, leitor, acha da revista!
s

ta
os bancos relacionais no foram concebidos para atender a
edio
D seu voto sobre este artigo, atravs do link:
este tipo de modelo de negcios. Assim, espera-se que, mais
www.devmedia.com.br/esmag/feedback
cedo ou mais tarde, os grandes fabricantes de banco de dados

Edio 19 - Engenharia de Software Magazine 45

 Referncias Nota 3. JSR 172 e KSoap

MELO, Ana Cristina. Apostila de Banco de Dados objetos-relacionais. GILLEANES, T.A.G.,UML2 (2a Edio): Guia de Consulta Rpida, Editora Novatec, 2005.

MELO, Ana Cristina. Desenvolvendo aplicaes com UML 2.0: do conceitual implementao. Rio
de Janeiro: Brasport, 2004.
BEZZERRA, E.,Princpios de Anlise e Projetos de Sistemas com Uml, 2007.
BOOCH, G., RUMBAUGH, J., JACOBSON, I.,UML 2.0-Guia do Usurio, Editora Campus, 2005.
FOWLER, M.,UML Essencial, 3ed, Editora Bookman, 2005.
FOWLER, M.,Refatorao - Aperfeioando o Projeto de Cdigo Existente, Editora Bookman, 2004.
GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.,Padres de Projeto, Editora Bookman, 2000.
GORTON, I.,Essential Software Architecture, Springer, 2006.
LARMAN, G.,Utilizando UML e Padres, 3ed, Editora Bookman, 2007.
MENDES, A.,Arquitetura de Software, Editora Campus, 2003.
WASZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a Objetos, Editora
Campus, 2004.

Existem coisas
que no conseguimos
ficar sem!

COMIDA ...s pra lembrar,

sua assinatura pode
estar acabando!
Renove J!

www.devmedia.com.br/renovacao

Para mais informaes:

www.devmedia.com.br/central
46 Engenharia de Software Magazine - Usando banco de dados objeto-relacionais

Gesto de Portflio de Projetos
Cristine Gusmo
cristine@dsc.upe.br
Professora do Departamento de Sistemas e
Computao da Escola Politcnica da Universi-
dade de Pernambuco (POLI -UPE), onde leciona
vrias disciplinas na graduao e ps-gradu-
ao (especializao e mestrado). Coordena o
Mestrado em Engenharia da Computao e o
PROMISE Project Management Improvements
in Software Engineering - grupo de pesquisa
na rea de Engenharia de Software. coorde-
nadora do Curso de Bacharelado em Sistemas
de Informao das Faculdades Integradas
Barros Melo. Doutora e Mestre em Cincia da
Computao pela Universidade Federal de
Pernambuco. Graduada em Engenharia El-
trica - Eletrotcnica pela Universidade Federal
de Pernambuco. Pesquisadora associada do
Ncleo de Telesude - NUTES - HC -UFPE.
Carlos Henrique R. Alexandria
chra@dsc.upe.br
Possui graduao em Cincia da Computao a anlise de vrios cenrios, tais como,
pela Universidade Catlica de Pernambuco.
Atualmente mestrando em Engenharia da
Computao, pela Universidade de Pernam-
buco e Analista de Sistemas do Servio Federal
de Processamento de Dados, onde atua como
Gerente de Projetos e Membro do Escritrio de
Projetos da organizao. Tem experincia na
rea de Cincia da Computao, com nfase
em Engenharia de Software. Membro do gru-
po de pesquisa Project Management Impro-
vements in Software Engineering (PROMISE).
Gerncia de Projetos
De que se trata o artigo?
Este artigo apresenta uma reviso de literatura so-
bre Gesto de Portflio de Projetos, apresentando
alguns modelos e padres existentes.
Para que serve?
O levantamento apresentado serve para auxiliar
organizaes e gestores a ampliarem seus conheci-
mentos sobre Gesto de Portflio de Projetos.
C
omo as organizaes podem de-
finir qual a melhor combinao Em que situao o tema til?
de projetos para seu portflio e Como definir qual a melhor combinao de proje-
ainda alinh-lo s suas estratgias de tos para uma organizao, ou seja, qual o melhor
negcio? A questo colocada reflete uma Portflio? Atualmente, definir e manter essa com-
necessidade crtica que est presente, binao de forma sistematizada, sustentada por
tanto no setor pblico, quanto privado. parmetros claros e coerentes, tem sido o grande
Fazer com que o Portflio de Projetos re- desafio organizacional. Ter o melhor Portflio
flita as estratgias organizacionais no tambm significa distribuir, da melhor maneira,
tarefa trivial, tendo em vista que envolve entre os projetos, os recursos (humanos, fsicos e
financeiros) da organizao, de modo que projetos
necessidades do negcio, problemas importantes tenham prioridade.
corporativos, demandas dos clientes, ob-
jetivos estratgicos, entre outros, que na
maioria dos casos so avaliados apenas
com base no sentimento dos executivos e Definio de Portflio
dos especialistas da organizao. Possuir Para entender o que um Portflio,
um processo decisrio mais consciente e em primeiro lugar preciso saber o que
que no adote unicamente este sentimen- uma organizao, um projeto e um
to a chave para resolver essa questo. programa. De acordo com Montana,
Edio 19 - Engenharia de Software Magazine 47
organizaes so caracterizadas pela combinao de esfor-
os individuais que tem por finalidade realizar propsitos
coletivos, orientados a um objetivo comum [Montana 2003].
As organizaes normalmente so compostas de estruturas
fsicas e tecnolgicas, recursos financeiros e pessoas. J um
projeto, segundo o Project Management Institute PMI
pode ser definido como um trabalho temporrio realizado
para gerar um resultado exclusivo, como por exemplo, um
produto ou servio [PMI 2004]. Outra definio para projeto
dada por Kerzner. Para ele, projeto um empreendimento
com objetivo bem definido, que consome recursos e opera
sob presses de prazo, custo e qualidade [Kerzner 2004].
J um programa um conjunto de projetos interligados e
gerenciados de forma coordenada onde se busca a obteno
de benefcios e controles que no seriam possveis se fossem
gerenciados separadamente. Programas podem incluir ele-
mentos de trabalho relacionados fora do escopo dos projetos
que fazem parte do programa [PMI 2004].
Um portflio uma coleo de projetos, programas e outros
trabalhos que so agrupados em conjunto para facilitar a
gesto eficaz, de modo a cumprir estratgias do negcio.
Os projetos e programas (denominados componentes)
do Portflio podem ser mutuamente independentes ou
diretamente relacionados [PMI 2006]. A Figura 1 ilustra
os relacionamentos entre os diversos componentes de um
portflio. Frequentemente esses componentes competem
por uma quantidade de recursos (fsicos, financeiros e hu-
manos) disponveis ao patrocinador, que normalmente so
insuficientes para executar todas as demandas existentes
na organizao [Archer e Ghasemzadeh 1999].
Kerzner define a gesto de portflio como um processo de
tomada de decises que busca o melhor para a organizao
como um todo, ressaltando que essas decises no so tomadas
no vcuo. A deciso geralmente est relacionada com outros
projetos e diversos fatores, tais como reservas financeiras
disponveis e a alocao de recursos [Kerzner 2004].
Figura 1. Exemplo dos relacionamentos entre os componentes de um
Portflio
Em um determinado momento temporal, o portflio re-
presentar uma fotografia dos componentes selecionados
pela organizao, de modo que reflitam e afetem os objetivos
48 Engenharia de Software Magazine - Gesto de Portflio de Projetos
estratgicos da organizao, ou seja, ser o conjunto ativo
de programas, projetos e outros trabalhos [PMI 2006].
Estratgia Corporativa e Gesto de Portflio
Os projetos so normalmente utilizados pelas organiza-
es como um meio para atingir os seus objetivos estrat-
gicos. Estes projetos normalmente advm das mais diver-
sas fontes. Uma demanda de mercado, uma necessidade
organizacional, uma solicitao de um cliente, um avano
tecnolgico, um requisito legal podem ser citados como
tpicas fontes de projetos [PMI 2004]. No entanto, como
saber qual conjunto de projetos pode trazer maior valor
agregado organizao e de fato facilitam a realizao dos
objetivos estratgicos?
Primeiramente, necessrio chegar at os objetivos estra-
tgicos organizacionais. Atualmente existem diversas fer-
ramentas que auxiliam no desenvolvimento da estratgia
organizacional. Uma delas a Anlise das Foras, Fraque-
zas, Oportunidades e Ameaas, tambm conhecida como
Anlise SWOT Strengths, Weaknesses, Opportunities,
Threats. Essa ferramenta auxilia na definio dos objetivos
que a organizao dever atingir para maximizar foras,
minimizar fraquezas, aproveitar oportunidades e tratar
as ameaas [Tarapanoff 2001]. Outra abordagem bastante
utilizada o Balanced Scorecard - BSC, fortemente pautado
em gesto estratgica, que rene componentes necessrios
ao alinhamento do planejamento estratgico com as aes
operacionais da organizao [Kaplan e Norton 1996].
De uma forma mais ampla, pode-se dizer que a gesto
de um portflio envolve as atividades de identificao,
priorizao, autorizao, monitorao e controle de pro-
jetos, programas e outros trabalhos, visando assegurar
que os investimentos alcancem os objetivos estratgicos
definidos pela organizao. Por outro lado, a gesto de
projetos envolve a aplicao de conhecimento, habilidades,
ferramentas e tcnicas ligadas s atividades do projeto,
possibilitando o alcance de contribuies individuais aos
objetivos estratgicos.
Independente da forma como as organizaes realizam
seus planejamentos estratgicos, elas normalmente definem
sua viso e misso, para ento definirem suas estratgias e
objetivos corporativos. A execuo destas estratgias, auxi-
liadas pelo necessrio apoio de processos de gerenciamento,
ferramentas e tcnicas, acabam oferecendo subsdios ao
planejamento e gerenciamento das operaes e tambm ao
portflio de projetos da organizao.
Na Figura 2, os itens Viso, Misso, Estratgias e Objetivos
Corporativos ilustram os componentes utilizados para defi-
nir os objetivos da organizao. A partir destes componentes
que so definidas todas as demais aes corporativas. Os
componentes do nvel ttico: Planejamento e gerenciamento
de operaes e Planejamento e gerenciamento de portflio
de projetos representam os processos que estabelecem as
aes necessrias para realizar os objetivos da organizao.
Tais componentes interagem com os do nvel operacional,

que so: Gerenciamento de operaes, Gesto de mltiplos
projetos, abordada na prxima seo, e o Gerenciamento de
programas e projetos autorizados, que so os componentes
que tentam garantir organizao que suas operaes e pro-
jetos sejam executados de forma eficiente [PMI 2006].
Figura 2. Exemplo do contexto organizacional onde o portflio de
projetos est inserido [PMI 2006]
Tanto as aes operacionais, quanto as de projetos, devem
ser consideradas na gesto de portflio. As aes operacio-
nais utilizam atividades recorrentes e processos de gesto
operacional para facilitar a execuo do planejamento de alto
nvel. J os projetos utilizam processos de gerenciamento
que permitam o planejamento e execuo eficiente das ati-
vidades [PMI 2006]. Nesse nvel ttico de gesto, uma das
principais preocupaes ser fazer com que as operaes
e os projetos sejam geridos de forma eficiente, trazendo
bons resultados, utilizando a quantidade mnima possvel
de recursos, com o mnimo esforo e em conformidade com
valores e normas organizacionais.
O fato que as organizaes dependem de projetos e pro-
gramas para atingir seus objetivos estratgicos. A gesto de
portflio permite interligao harmoniosa entre os projetos
e os objetivos estratgicos atravs da diviso e alocao de
recursos [PMI 2006].
Sendo assim, a estratgia da organizao impulsiona as
definies das metas e objetivos estratgicos. Esses objetivos
so passados para a gesto de portflio que visa garantir que
os projetos e programas da organizao estejam alinhados
para alcanar os objetivos da organizao. Com base nesse
princpio, a gesto de portflio ir selecionar, priorizar e
aprovar projetos e programas para fazer parte do portflio
da organizao. A gesto de portflio tambm deve estar
preocupada com o equilbrio do portflio em termos de
retorno financeiro versus investimento e risco versus be-
nefcio, assim como, em negociar acordo entre as partes
interessadas, por exemplo, entre a gerncia executiva e os
gestores de projetos [PMI 2006].
Gerncia de Projetos
Gesto de Portflio versus Gesto de Mltiplos Projetos
A grande diferena entre a gesto de portflio e a gesto de
mltiplos projetos est no foco organizacional desses proces-
sos. A gesto de portflio tem como uma de suas principais
preocupaes o constante alinhamento estratgico dos seus
componentes, o que a aproxima do nvel mais estratgico da
organizao. Outra atribuio da gesto de portflio, segundo
o PMI, est na identificao, seleo, avaliao e priorizao
dos componentes do portflio [PMI 2006].
No caso da gesto de mltiplos projetos, que tem o foco muito
mais operacional, devido ao fato de trabalhar em conjunto com
a gesto dos projetos em execuo, a principal responsabilidade
est na distribuio equilibrada dos recursos disponibilizados
no portflio aos projetos sob sua responsabilidade. Ou seja, a
gesto de mltiplos projetos estar constantemente analisando
a alocao dos recursos e re-distribuindo os disponveis entre
seus projetos. Tambm poder fazer parte do conjunto de
atividades da gesto de mltiplos projetos o auxlio na reso-
luo de conflitos no mbito de cada projeto, apoio tcnico em
metodologia de gesto de projetos, alm do acompanhamento
gerencial para que os projetos alcancem as metas estabelecidas
e obtenham sucesso em relao aos seus requisitos.
importante reforar que a retirada de recurso em uso de
um determinado projeto, para outro de maior prioridade,
responsabilidade da gesto de portflio, pois foi ela quem
realizou a priorizao dos projetos e est constantemente pre-
ocupada com o bom andamento dos projetos de maior valor
para a organizao.
Relao entre a Gesto de Portflio e a Gesto de
Projetos/Programas
A gesto de portflio utiliza uma gama de informaes
coletadas a partir dos projetos e programas que o integram.
De uma forma geral, so analisadas informaes referentes
ao andamento das aes planejadas, ao esforo desprendido
e ao oramento. Esta anlise tem como objetivo determinar
aes necessrias para resolver desvios que forem sendo
identificados [PMI 2006].
A gesto de projetos/programas pode trabalhar em conjunto
com a gesto de portflio na determinao dos critrios de en-
cerramento de suas aes, assim como, na avaliao para deter-
minar se um projeto/programa deve ou no ser cancelado. Outro
ponto em que a gesto de projeto/programa pode interagir com
a gesto de portflio no planejamento da capacidade de suas
aes, pois afetar a distribuio dos recursos (humanos, fsicos
e financeiros) disponveis ao portflio [PMI 2006].
Dependendo da estrutura organizacional, a gesto de por-
tflio, em conjunto com a gesto de projetos/programa, ir
administrar a distribuio dos recursos (humanos, fsicos e
financeiros) aos componentes do portflio [PMI 2006].
Mtricas em Gesto de Portflio
As mtricas de gesto de portflio normalmente incluem medi-
das sobre a capacidade de recursos disponveis e o desempenho
do portflio de uma forma geral. Essas mtricas incluem:
Edio 19 - Engenharia de Software Magazine 49
 Disponibilidade e os tipos de recursos necessrios para
suportar os componentes do portflio como planejado e
durante a execuo
Andamento do progresso dos componentes em direo s
metas estabelecidas
Medidas financeiras, tais como, rentabilidade total do in-
vestimento, valor presente lquido e a diversidade de apoio
financeiro entre os objetivos estratgicos
Oramento gastos versus oramento planejado
ndices de satisfao do cliente
Desempenho de lanamento do produto.
Essas mtricas descrevem o valor do portflio para a
organizao onde, de acordo com a necessidade, cada item
pode ser melhor detalhado conforme a importncia do
componente, facilitando o acompanhamento.
Gerente de Portflio
O papel de gerente do portflio, que normalmente
desempenhado por um gerente snior ou uma equipe de
gerentes seniores, responsvel por monitorar o portflio.
Essa monitorao consiste em:
Buscar o constante alinhamento dos componentes do por-
tflio aos objetivos estratgicos da organizao
Distribuir s principais partes interessadas do portflio,
informaes sobre o desempenho dos componentes, assim
como, sobre os atuais e potenciais problemas
Medir o valor do portflio atravs de instrumentos de investi-
mento, tais como, retorno sobre o investimento (return on invest-
ment ROI), valor presente lquido (net present value NPV),
perodo de retorno (payback period PP), entre outros.
Para ter sucesso neste papel, o Gerente de Portflio deve
ter algum nvel de conhecimento nas seguintes reas:
Viso Estratgica
O gerente de portflio deve ter uma boa compreenso da
viso, misso e estratgia corporativa, de modo a auxiliar na
otimizao do portflio da organizao. Ele deve compre-
ender o relacionamento entre os componentes do portflio
e os objetivos estratgicos, assim como o plano para atingir
esses objetivos.
Mtodos e Tcnicas de Gerenciamento de Projetos e
Programas
O gerente do portflio deve ter um conhecimento avanado
dos mtodos e tcnicas de gerenciamento de projetos e pro-
gramas. Alm disso, ele deve ser capaz de compreender no
s informaes de alto nvel sobre o andamento dos projetos,
mas tambm, os detalhes da gesto de projetos, de modo a
determinar se esta gesto est sendo eficiente ou no.
Desenvolvimento e Melhoria Contnua do Processo
O gerente do portflio deve entender o desenvolvimento
e melhoria contnua do processo de gesto de portflio,
50 Engenharia de Software Magazine - Gesto de Portflio de Projetos
visando buscar um processo mais adequado ao portflio da
organizao. Alm disso, ele, juntamente com outros lderes
da organizao, dever ter a capacidade de desenvolver
estruturado e bem pensado processo de gesto de portflio
que melhor se adapte ao negcio, e que se integre bem aos
outros processos da organizao.
Competncias Gerais
Um bom gerente de portflio deve possuir uma vasta gama
de habilidades pessoais (comunicao, liderana, persuaso,
criatividade, entre outras) e ser capaz de interagir facilmente
com os executivos e demais tomadores de deciso da or-
ganizao. Alm disso, ele deve ter conhecimento sobre o
mercado da organizao, sua base de clientes, suas normas
internas e leis que regulamentam o seu negcio. Deve ter
tambm a capacidade de analisar dados e tomar decises
com base em relatrios de desempenho do portflio e suas
mtricas.
Modelos e Padres de Gesto de Portflio
Os modelos e padres de gesto de portflio so propos-
tas de processos de trabalho, criados para sistematizar a
dinmica decisria do portflio [Blomquist e Muller 2006],
de modo que essas decises tentem garantir a melhor
distribuio e utilizao dos recursos (humanos, fsicos e
financeiros) pelos componentes, assim como, a execuo
dos componentes que realmente estejam alinhados com
as estratgias da organizao e que proporcionem maior
valor agregado.
A seguir sero detalhados alguns modelos e padres exis-
tentes na literatura e no mercado.
Padro de Gesto de Portflio [PMI 2006]
Segundo o PMI, o Padro para Gesto de Portflio proposto
composto de vrios processos que possuem dependncias
claras e so executados durante a gesto de cada portflio.
Esses processos so independentes da rea de aplicao ou
negcio da organizao que o utiliza. Eles foram agrupa-
dos em dois grupos, denominados Grupos de Processos de
Gesto de Portflio, detalhados a seguir:
Grupo Processo Alinhamento: inclui os processos que
diro o que ser gerenciado no portflio, quais as categorias
e quais os componentes que sero avaliados e escolhidos,
ou no, para fazerem parte do portflio.
Grupo Processo Monitorao e Controle: inclui os proces-
sos responsveis pela monitorao peridica dos componen-
tes, assim como o alinhamento dos mesmos s estratgias
da organizao.
Interaes entre os Processos de Gesto de
Portflio
A Figura 3 apresenta um resumo dos processos que inte-
gram o Padro de Gesto de Portflio do PMI e mostra suas
interaes com o Plano Estratgico da Organizao e com
a Gesto de Projetos.

Figura 3. Processo de Gesto de Portflio Ilustrao de Alto Nvel
[PMI 2006]
A partir do diagrama disponibilizado na Figura 3, tem-se:
Plano planejamento estratgico: a base para tomada de
decises da gesto de portflio, assim como, para determinar
o que cada portflio ir fazer em termos de projetos.
Processo de gesto de portflio: representa uma srie de
processos integrados que abrangem desde a identificao a
autorizao de cada componente do portflio.
Processo componente: a aplicao de uma srie de conheci-
mentos, habilidades, ferramentas e tcnicas com o objetivo de
executar o componente que teve seu incio autorizado.
Ainda de acordo com as informaes apresentadas atravs
da Figura 3, o processo de Gesto de Portflio composto por
um conjunto de atividades de:
Identificao
O objetivo deste processo criar uma lista atualizada com
diversas informaes sobre os componentes que esto em exe-
cuo e sobre os novos componentes que entraro no portflio
da organizao. As principais atividades deste processo so:
Comparar os atuais componentes e as novas propostas de
componentes com os direcionamentos da organizao;
Rejeitar os componentes que no estejam alinhados com as
diretrizes da organizao;
Classificar os componentes identificados em classes pr-
definidas, tais como projeto, programa, portflio, entre
outros.
Categorizao
O objetivo deste processo separar os componentes em ca-
tegorias empresariais relevantes, de modo que um conjunto
comum de filtros e critrios de deciso possa ser aplicado
durante os processos de avaliao, seleo, priorizao e ba-
lanceamento. Essas categorias so definidas com base no plano
estratgico. Os componentes de uma determinada categoria
tero um objetivo comum e podero ser medidos com base nes-
se objetivo, independentemente da sua origem na organizao.
A categorizao dos componentes permite que a organizao
eventualmente possa equilibrar os seus investimentos e seus
riscos entre todas as categorias e objetivos estratgicos. As
principais atividades deste processo so:
Gerncia de Projetos
Identificar categorias estratgicas com base no plano
estratgico;
Comparar os componentes identificados com os critrios de
categorizao;
Agrupar os componentes em apenas uma categoria.
Avaliao
O objetivo deste processo reunir todas as informaes
necessrias para avaliar os componentes com a finalidade
de compar-los para facilitar o processo de seleo. As infor-
maes so levantadas para cada componente do portflio e
podem ser qualitativas ou quantitativas, vindas das mais va-
riadas fontes da organizao. Deve-se ter o cuidado necessrio
para no comprometer a preciso das informaes durante a
atividade de levantamento. Grficos, diagramas, documentos e
recomendaes so gerados para apoiar o processo de seleo.
As principais atividades deste processo so:
Avaliar os componentes do portflio atravs da aplicao de
modelos de pontuao que inclui critrios-chave;
Produzir representaes grficas para facilitar a tomada de
deciso no processo de seleo;
Fazer recomendaes para o processo de seleo.
Seleo
O objetivo deste processo produzir uma lista de compo-
nentes baseada nas recomendaes do processo de avaliao
e nas capacidades de recursos da organizao. A avaliao
determina o valor de cada componente, enquanto a capaci-
dade de recursos da organizao determinar o nmero de
componentes que podero ser autorizados a iniciar. Recursos
organizacionais podem incluir recursos humanos internos e/
ou externos, recursos financeiros, equipamentos e outros bens.
Esse processo gerar uma lista de componentes que representa
o melhor valor para a organizao com base na capacidade
disponvel. As principais atividades deste processo so:
Selecionar componentes com base nos resultados da avaliao
e da capacidade da organizao;
Definir os recursos humanos, financeiros e capacidade de
ativos da organizao;
Fazer recomendaes para o processo de priorizao.
Priorizao
O objetivo deste processo classificar os componentes dentro
de cada categoria estratgica ou de financiamento (inovao,
reduo de custos, crescimento, manuteno e operaes), de
tempo de retorno do investimento (curto, mdio ou longo pra-
zo), de risco versus retorno ou de foco organizacional (cliente,
fornecedor e interno) de acordo com critrios estabelecidos.
Essa etapa classifica os componentes para posteriormente fa-
cilitar a anlise e o balanceamento do portflio. As principais
atividades deste processo so:
Confirmar a classificao dos componentes nas categorias
estratgicas previamente determinadas;
Estabelecer e aplicar critrios de pontuao nos componentes,
gerando assim a classificao dos mesmos;
Edio 19 - Engenharia de Software Magazine 51
 Determinar quais os componentes que devem receber m-
xima prioridade dentro do portflio.
Balanceamento do Portflio
O objetivo deste processo proporcionar a combinao de
componentes com maior potencial para a organizao e, para-
lelamente, apoiar as iniciativas estratgicas, buscando atingir
seus objetivos. O balanceamento do portflio permite a visi-
bilidade dos principais benefcios da gesto do portflio, que
so: (i) a capacidade de planejar e alocar recursos (financeiro,
fsicos e humanos) alinhados com as orientaes estratgicas
e; (ii) a capacidade de maximizar o retorno do portflio den-
tro do que foi predefinido em termos de risco aceitvel pela
organizao.
O balanceamento do portflio tambm implica na reviso
das atividades desenvolvidas nos processos de seleo e prio-
rizao de componentes. Um portflio balanceado suportar
os objetivos estratgicos estabelecidos de acordo com critrios
pr-definidos pela gesto de portflio, assim como, estar ali-
nhado com o perfil de risco da organizao, com suas mtricas
de desempenho e suas restries de capacidade. As recomen-
daes para manuteno e ajustes no portflio tambm so
realizadas durante o balanceamento. As principais atividades
deste processo so:
Adio de novos componentes que foram selecionados e
priorizados para autorizao;
Identificar os componentes que no esto autorizados com
base no processo de reviso;
Eliminar componentes suspensos, re-priorizados ou cance-
lados com base no processo de reviso.
Autorizao
O objetivo deste processo comunicar formalmente orga-
nizao as decises tomadas no processo de balanceamento
do portflio, assim como, formalizar a alocao dos recursos
(fsicos, humanos e financeiros) necessrios para executar os
componentes selecionados. As principais atividades deste
processo so:
Comunicar as decises tomadas no processo de balancea-
mento do portflio s principais partes interessadas, o que
engloba informaes referentes aos componentes selecionados
e aos no selecionados;
Autorizar as decises referentes a componentes selecionados,
inativos e finalizados;
Realocar os recursos dos componentes inativos ou
finalizados;
Alocao rec ursos para exec utar os componentes
selecionados;
Comunicar os resultados esperados (por exemplo, os ciclos
de reviso, mtricas de desempenho de cronograma, e os re-
sultados necessrios) para cada componente selecionado.
Reviso e Relato Peridico do Portflio
O objetivo deste processo coletar indicadores de desempe-
nho, apresentar relatrios peridicos sobre eles, assim como,
52 Engenharia de Software Magazine - Gesto de Portflio de Projetos
revisar o portflio dentro de uma frequncia pr-determinada,
de maneira a assegurar o alinhamento dos seus componentes
com as estratgias de negcios, alm de garantir a utilizao
eficaz dos recursos. O ciclo de reviso examina todos os
componentes durante um perodo determinado pela organi-
zao. Cada ciclo pode conter vrias anlises com um foco e
profundidade diferente. Os indicadores chave de desempenho
tambm podem variar a cada ciclo executado.
O principal objetivo das revises assegurar que o portf-
lio contenha apenas os componentes que realmente estejam
alinhados como os objetivos estratgicos da organizao. Para
garantir isso, os componentes devem ser periodicamente adi-
cionados, realinhados, ou at mesmo removidos, com base no
seu desempenho e alinhamento com as estratgias definidas, a
fim de assegurar uma gesto eficaz do portflio. As principais
atividades deste processo so:
Revisar o patrocnio e financiamento do componente;
Revisar e acompanhar a prioridade, dependncias, escopo,
retorno esperado, riscos e desempenho financeiro do compo-
nente em relao aos critrios de portflio;
Analisar o impacto das previses referentes ao negcio, a
utilizao de recursos e as limitaes da capacidade no de-
sempenho do portflio;
Determinar a continuidade, a incluso ou o cancelamento de
um componente, assim como, re-priorizar e re-alinhar deter-
minado componente com os objetivos estratgicos;
Fazer recomendaes e/ou fornecer orientao para a gesto
de um determinado componente
Propor alteraes, caso necessrio, na forma como o portflio
administrado.
Mudana Estratgica
O objetivo deste processo permitir que o processo de gesto
de portflio responda s mudanas estratgicas organizacio-
nais. Pequenas mudanas no plano estratgico, normalmente
no exigem alteraes no portflio, no entanto, alteraes sig-
nificativas muitas vezes resultam em nova direo estratgica,
desta forma, impactando o portflio. Mudanas estratgicas
tambm podero causar impactos no processo de categoriza-
o de componentes, o que exigir um novo rebalanceamento
do portflio.
Processo Stage-Gate [Cooper et al 2001]
Segundo Cooper e outros autores, antes de seguir em frente
com a gesto de portflio propriamente dita, o gestor deve
ter certeza que seu processo de desenvolvimento de novos
produtos est funcionando corretamente [Cooper et al 2001].
Ele sugere a adoo do processo Stage-Gate, reforando que
um efetivo processo de desenvolvimento de novos produtos
fundamental para a gesto de portflio, por duas razes:
Independente da sofisticao do modelo de gesto de
portflio usado, deve-se ter certeza de que as informaes
utilizadas pelo portflio esto corretas. Essas informaes
sero provenientes do processo de desenvolvimento de
novos produtos.

O processo decisrio de avaliao de projetos deve finalizar
os projetos ruins, fazendo com que o portflio esteja cada vez
mais alinhado com os objetivos da organizao.
A seguir ser detalhado o processo Stage-Gate, como visua-
lizado atravs da Figura 4, de desenvolvimento de novos pro-
dutos. Este modelo fragmenta o desenvolvimento do produto
em estgios pr-determinados, onde cada estgio consiste de
um conjunto de atividades pr-definidas.
Figura 4. Processo Stage-Gate [Cooper et al 2001]
A entrada de cada estgio um ponto de deciso, de modo
que estes pontos comandam o processo, tendo como funes,
o controle da qualidade do projeto e a tomada de deciso que
englobam as seguintes sadas: Inicia, Continua, Aborta, Sus-
pende ou Recicla. Cada Porto ou Ponto de deciso (continua/
finaliza) composto de:
Um conjunto de Entradas;
Critrios de julgamento do projeto, incluindo obrigatrios
e facultativos;
Sadas
Descoberta
O processo de desenvolvimento de novos produtos se inicia
com a descoberta da idia de um novo produto ou otimizao
em um j existente, que avaliada no Porto 1 de deciso.
Porto 1 Exame da Idia
Neste ponto, se a deciso for de iniciar, nascer o projeto,
havendo o comprometimento de recursos e passando para
o Estgio 1, Definio do Escopo. Para se tomar esta deci-
so, sero analisados os seguintes critrios: alinhamento
estratgico, viabilidade do projeto, magnitude da oportu-
nidade, vantagens diferenciais, atratividade de mercado e
sinergia da atividade primria do negcio com os recursos
da organizao.
Estgio 1 Definio do Escopo
Este estgio tem como objetivo estabelecer os mritos tc-
nicos e de mercado do projeto. Uma anlise de mercado
realizada envolvendo pesquisas, contatos com as partes inte-
ressadas e testes com usurios potenciais. O foco detalhar
informaes quanto ao tamanho e ao potencial do mercado,
alm de sua possvel aceitao. Paralelamente, uma avaliao o que evolve anlises do produto, do processo produtivo, da
tcnica preliminar realizada como o objetivo de verificar
Gerncia de Projetos
a viabilidade de desenvolvimento e de produo, alm dos
possveis custos e tempo de execuo do projeto.
Porto 2 Segundo Exame da Idia
Este estgio praticamente uma repetio do Porto 1, onde o
projeto reavaliado, no entanto, com base nas informaes for-
necidas pelo Estgio 1. Neste ponto, o nvel de incerteza referente
s informaes adquiridas j um pouco menor. Se a deciso for
de prosseguir, o projeto passar para um estgio onde j ocor-
rero maiores gastos. Complementarmente, so utilizadas listas
de verificao para fatores que devem ser atendidos e modelos
ponderados para fatores que se desejam atender.
Estgio 2 Avaliao do Negcio
Este estgio conduz ao desenvolvimento do produto, onde o
projeto deve ser claramente definido. Neste ponto do processo
so realizadas pesquisas de mercado para determinar as neces-
sidades, desejos e preferncias dos consumidores. Determina-
o dos mercados-alvo, posicionamento do produto, benefcios
que devem ser entregues, proposta de valor, funcionalidades,
atributos, requisitos e especificaes do produto.
Porto 3 Vai para o Desenvolvimento
Este o ponto de deciso final antes do estgio de desenvol-
vimento, ou seja, o ltimo ponto no qual o projeto pode ser
cancelado antes de se iniciar grandes gastos. Se o projeto passar
desta etapa, o comprometimento financeiro da organizao
com o projeto significativo. Nesta fase, o projeto tambm
avaliado com base em critrios e modelos de maneira similar
aos pontos de deciso anteriores. Porm, outra parte da ava-
liao tambm envolve a reviso de cada uma das atividades
do Estgio 2, verificando se as atividades foram realizadas
conforme planejado e se os resultados foram positivos.
Estgio 3 Desenvolvimento
Este estgio tem em seu escopo o desenvolvimento do pro-
duto e ocorre juntamente com a execuo de testes detalhados,
com o planejamento do marketing e com o desenvolvimento
dos processos de fabricao. Simultaneamente, uma atua-
lizao na anlise financeira preparada em conjunto com
questes legais.
Porto 4 Vai para Teste
Este porto tem como atividade a verificao do progresso
do projeto e da atratividade do produto. O trabalho do Estgio
3 (Desenvolvimento) verificado de forma a tentar garantir
que o projeto atinja o nvel de qualidade esperado. realizada
tambm a verificao da anlise financeira, tomando como
base os novos dados, que nesse momento j sero um pouco
mais precisos.
Estgio 4 Teste e Validao
Neste estgio avaliada a viabilidade do projeto como um todo,
aceitao do mercado e das questes financeiras do projeto.
Edio 19 - Engenharia de Software Magazine 53
Porto 5 Vai para Lanamento
Neste porto decidida a comercializao ou no do pro-
duto. Para tomar essa deciso necessrio que se faa uma
avaliao das fases anteriores e dos resultados alcanados. O
planejamento das operaes e do lanamento do produto no
mercado so reavaliados, se aprovados, sero implementados
no Estgio 5 (Lanamento).
Estgio 5 Lanamento
Neste estgio so executados os planejamentos realizados
para o lanamento do produto e sua colocao em operao,
o que certamente envolver todo o marketing planejado.
Aps o lanamento, se inicia a fase de encerramento do
projeto que contempla atividades como liberao da equipe
envolvida, liberao de recursos alocados, encerramento dos
contratos, comunicao formal a todas as partes envolvidas,
entre outras.
Reviso ps Lanamento
Neste momento ser realizada uma avaliao criteriosa do
projeto onde revisado todo o seu desempenho e seus pontos
fortes e fracos. Todas estas informaes sero registradas, de
modo a servirem como lies e base de conhecimento para
o desenvolvimento de novos projetos, aumentando assim a
qualidade dos projetos da organizao. Essa etapa marca o
fim do projeto.
Processo Integrado de Seleo e Priorizao de
Projetos [Archer e Ghasemzadeh 1999]
Segundo Archer e Ghasemzadeh, o processo de seleo de
projetos na gesto de portflio de suma importncia para
esta gesto e ocorre com bastante frequncia em muitas orga-
nizaes. H muitas tcnicas disponveis para auxiliar neste
processo, no entanto, no existe um processo integrado para
a sua execuo.
O processo proposto por Archer e Ghasemzadeh simplifica
a seleo de projetos em um portflio atravs do desenvol-
vimento de uma estrutura que separa o trabalho em fases
distintas. Cada fase responsvel por um objetivo particular
e cria insumos para a prxima fase. O processo tambm per-
mite que os usurios sejam livres para escolher as tcnicas
mais adequadas para cada fase ou, em alguns casos, omitir ou
at mesmo modificar uma fase com o intuito de simplificar e
agilizar o processo.
O processo integrado de seleo de projetos, como visualiza-
do atravs da Figura 5, mostra as principais etapas represen-
tadas pelas caixas delineadas por linhas escuras. J as figuras
ovais representam as atividades que antecedem a execuo do
processo, que conta tambm com as atividades representadas
pelas caixas delineadas por linhas claras, as quais fornecem
informaes de entrada e recebem informaes de sada pro-
duzidas no processo de seleo.
A seguir sero detalhadas as principais atividades que com-
pem o processo integrado de seleo de projetos.
54 Engenharia de Software Magazine - Gesto de Portflio de Projetos
Figura 5. Processo Integrado de Seleo de Projetos [Archer e
Ghasemzadeh 1999]
Pr-filtragem
Nesta fase, que utiliza informaes produzidas no Desenvolvi-
mento Estratgico, busca-se garantir que todas as proposies de
projetos considerados para entrar no portflio estejam alinhados
com os objetivos estratgicos da organizao. Nesta fase tam-
bm ser realizada uma anlise de viabilidade e estimativas de
parmetros necessrios para avaliar cada projeto, bem como as
metas para cada parmetro, o que ser uma fonte de informaes
para outras fases. Projetos essenciais tambm so identificados
neste ponto, uma vez que sero includos no restante do processo
de seleo do portflio. Projetos essenciais podem incluir aes
de melhorias aos produtos da organizao que deixaram de ser
competitivos, ou seja, so os projetos sem os quais a organizao
no poderia funcionar adequadamente.
Anlise Individual de Projeto
Nesta fase um conjunto de parmetros necessrios para a prxi-
ma fase calculado separadamente para cada projeto, tendo como
base as estimativas disponveis nas anlises de viabilidade e/ou
no banco de dados de projetos da organizao. Algumas tcnicas
podero ser utilizadas nesta fase para realizar as estimativas, tais
como, levantamento dos riscos do projeto, valor presente lquido,
retorno sobre o investimento, entre outras. Projetos em andamen-
to tambm podero ser re-avaliados nesta fase, proporcionando
estimativas com menor grau de incerteza em relao aos projetos
que esto sendo propostos. A sada desta fase um conjunto de
estimativas de parmetros para cada projeto.
Filtragem
Nesta fase, que ocorre aps a fase de anlise individual dos pro-
jetos, so verificados criteriosamente os parmetros produzidos na
anlise. Essa filtragem servir de base para a seleo dos projetos,
assim como, para eliminar quaisquer projetos que no preencham
critrios pr-estabelecidos. Vale ressaltar que projetos obrigatrios
ou necessrios para apoiar outros projetos no sero eliminados.
Seleo do Portflio timo
Nesta fase so consideradas e analisadas as interaes entre
os projetos, suas dependncias e competio por recursos,
assim como o valor do projeto para a organizao. Com base

nestas informaes podem ser produzidos modelos de pon-
tuao e grficos, que auxiliaro os tomadores de deciso na
seleo do melhor portflio, permitindo avaliaes quantita-
tivas e qualitativas.
Ajuste do Portflio
Nesta fase, que a etapa final do processo, realizada a an-
lise do portflio como um todo, buscando o equilbrio entre os
projetos selecionados. Para isso, sero verificadas caracters-
ticas crticas de importncia dos projetos, por exemplo, valor
presente lquido, estimativa de tempo para finalizar, risco,
entre outras. Como exemplo do equilbrio a ser alcanado no
portflio, pode-se falar que a proporo de projetos de alto
risco no deve ser muito elevada, devido ao fato de que as
falhas de vrios desses projetos pode ser perigo para o futuro
da organizao. Por outro lado, os projetos de baixo risco, que
geralmente no trazem elevado retorno financeiro quando
comparados aos de alto risco, no podem ser maioria absoluta
no portflio, o que prejudicaria o seu valor.
Consideraes Finais e Sugestes de Leitura
A Gesto de Portflio um processo que vem sendo traba-
lhado por diversos autores estudados neste levantamento,
que sempre colocam em evidncia como ncleo deste pro-
cesso as atividades de identificao, seleo, priorizao e
balanceamento dos projetos do portflio, alm da gesto dos
recursos (humanos, fsicos e financeiros) disponibilizados no
portflio.
Entendemos que as organizaes que realizam estas ativida-
des citadas, conseguindo alcanar, atravs dos projetos, seus
objetivos estratgicos, metas e indicadores estabelecidos em
seu planejamento, esto cumprindo o objetivo principal da
Gesto de Portflio.
Como sugesto de leitura para aprofundamento nos prin-
cipais assuntos abordados neste artigo sugerimos as fontes
citadas a seguir:
Para um maior detalhamento sobre o Padro de Gesto de
Portflio de Projetos do PMI ler: The Standards For Portfolio
Management [PMI 2006] e Portfolio Management For New
Products [Cooper et al 2002].
Para um maior detalhamento sobre o Gesto de Projetos
ler: A Guide to the Project Management Body of Knowledge
[PMI 2004], Advanced Project Management: Best Practices
on Implementation [Kerzner 2004] e Project Management: A
Systems Approach to Planning, Scheduling, and Controlling
[Kerzner 2006].
Tpicos de Pesquisa (trabalhos futuros e correntes)
Durante a escrita deste artigo foram encontrados as seguin-
tes pesquisas e trabalhos relacionados com o tema Gesto de
Portflio:
Gerncia de Projetos
O Impacto da Gesto de Portflio de Projetos em Projetos
de Tecnologia da Informao [Reyck et al 2005]
Neste trabalho foi avaliado se existe uma correspondn-
cia entre a utilizao de processos de Gesto de Portflio
de Projetos e as melhorias no desempenho dos projetos
do portflio. O estudo apontou uma forte correlao entre
aumentar a adoo de processos de Gesto de Portflio e
uma reduo dos problemas relacionados com projeto, assim
como, melhoria no desempenho dos projetos.
Portfolius: Um Modelo de Gesto de Portflio de Projetos
de Software [Correia 2005]
Neste trabalho foi proposto um processo, que um modelo
de gesto de portflio de projetos de software, com a finali-
dade de auxiliar os tomadores de decises de uma empresa
de desenvolvimento de software na escolha do portflio de
projetos mais adequado realidade da organizao. O mo-
delo proposto possibilita a criao de uma ligao entre os
projetos e a estratgia da organizao e auxiliar na adoo
uma viso de longo prazo.
Seleo de Projetos em um Portflio para Apoio a Tomada
de Deciso [Ghasemzadeh e Archer 2000]
Neste trabalho foi discutida a implementao de uma
estrutura organizada para a seleo de projetos em um por-
tflio atravs de um Sistema de Apoio Tomada de Deciso
(SATD), que foi chamado de Sistema de Seleo e Anlise
de Projeto (SSAP). Foram descritos os resultados dos testes
laboratoriais realizados para medir sua usabilidade e qua-
lidade, comparado com os processos de seleo manual,
na seleo de problemas tpicos da portflio. Tambm foi
discutido o potencial da SSAP no apoio empresarial a to-
mada de deciso.
Um Processo Integrado para Seleo de Projetos em um
Portflio [Archer e Ghasemzadeh 1999]
Neste trabalho foi proposto um processo integrado para
seleo de projetos na gesto de um portflio. O processo
de seleo proposto segmenta o trabalho em fases distintas,
onde cada fase aborda um objetivo especfico e cria insumos
para a prxima fase. O processo pode ser utilizado sob a
forma de um sistema de apoio a deciso.
D seu feedback sobre esta edio! 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, atravs do link:
edio
www.devmedia.com.br/esmag/feedback
Edio 19 - Engenharia de Software Magazine 55
 Referncias Bibliogrficas
[PMI 2004] PMI - Project Management Institute. (2004) A Guide to the Project Management Body of
Knowledge. 2004. Project Management Institute. Four Campus Boulevard. Newtown Square. USA.
[PMI 2006] PMI - Project Management Institute. (2006) The Standards For Portfolio Management. 2006.
Project Management Institute. Four Campus Boulevard. Newtown Square. USA.
[Archer and Ghasemzadeh 1999] Archer, N. P., Ghasemzadeh, F. An Integrated Framework for Project
Portfolio Selection, International Journal of Project Management,Vol. 17, No. 4, pp. 207-216, ON, 1999.
[Correia 2005] Correia, B. C. S. Portfolius: Um Modelo de Gesto de Portflio de Projetos de Software,
Dissertao de Mestrado, UFPE, 2005.
[Kerzner 2006] Kerzner, H. Project Management: A Systems Approach to Planning, Scheduling, and
Controlling. 9th ed, 2006. John Wiley & Sons, Inc., Hoboken, New Jersey. USA.
[Kerzner 2004] Kerzner, H. Advanced Project Management: Best Practices on Implementation. 2th ed,
2004. John Wiley & Sons, Inc., Hoboken, New Jersey. USA.
[Reyck et al 2005] Bert De Reyck,Yael Grushka-Cockayne, Martin Lockett, Sergio Ricardo Calderini, Marcio
Moura, Andrew Sloper.The impact of project portfolio management on information technology projects.
International Journal of Project Management,Volume 23, Issue 7, October 2005, Pages 524-537
[Archer e Ghasemzadeh 1999] N. P Archer, F Ghasemzadeh. An integrated framework for project portfolio
selection.International Journal of Project Management,Volume 17, Issue 4, August 1999, Pages 207-216
56 Engenharia de Software Magazine - Gesto de Portflio de Projetos
[Ghasemzadeh e Archer 2000] F. Ghasemzadeh, N. P. Archer. Project portfolio selection through decision
support. Decision Support Systems,Volume 29, Issue 1, July 2000, Pages 73-88
[Blomquist e Muller 2006] Blomquist, Tomas; Muller, Ralf. Practices, Roles, and Responsibilities of Middle
Managers in Program and Portfolio Management. Project Management Journal v. 37 no. 1 (March 2006)
p. 52-66
[Cooper et al 2002] Robert G. Cooper, Scott J. Edgett, and Elko J. Kleinschmidt. Portfolio Management For
New Products: Second Edition (Hardcover - Jan 3, 2002)
[Cooper et al 2001] Cooper, R. G., Edgett, S. J. and Kleinschmidt, E. J. Portfolio Management for New
Products, 2dn edn, Perseus Publishing, NY, 2001.
[Montana 2003] Montana, Patrick J. Administrao. 2. ed. So Paulo: Saraiva, 2003.
[Kaplan e Norton 1996] Kaplan, Robert S., Norton, David P. The Balanced Scorecard: Translating Strategy
into Action by Robert S. Kaplan and David P. Norton, Hardcover - Sep 1, 1996.
[Tarapanoff 2001] Tarapanoff, K. Inteligncia Organizacional e Competitiva. Braslia: Editora UNB, 2001.
[Luecke 2008] Luecke, Richard. Estratgia, Harvard Business Essentials, Record, 2008.
 Gerncia de Projetos

Edio 19 - Engenharia de Software Magazine 57

 Modstia parte, sua
melhor opo para
se destacar no mercado!
A Escola Superior da Tecnologia da PS- GRADUAO
Informao oferece as melhores Engenharia de Software:
opes em cursos, formaes, Desenvolvimento Java
graduaes e ps-graduaes para GRADUAO
profissionais de desenvolvimento Anlise e Desenvolvimento
e programao. de Sistemas

So programas voltados para a FORMAES

formao de profissionais de elite, Desenvolvedor Java

com aulas 100% prticas, corpo Desenvolvedor Java: Sistemas
Distribudos
docente atuante no mercado,
Gestor de TI
acesso mais atualizada biblioteca
Desenvolvedor Web .NET 2008
de TI do Rio, laboratrios equipados
MCITP Server Administrator
com tecnologia de ponta, salas de
estudo e exames. SQL Server 2008

Acesse nosso site e conhea 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

EDUCAO SUPERIOR ORIENTADA AO MERCADO

58 Engenharia de Software Magazine - Gesto de Portflio de Projetos