Conhecimento

faz diferença!

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

Engenharia de Software
Saiba seu significado e para que serve
magazine

Edição Especial






  
Entenda os principais conceitos sobre
Testes e Inspeção de Software

Verificação, Validação & Teste

Ferramentas Open Source e melhores
práticas na gestão de defeitos
Requisitos Projeto
Conheça 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 através da
análise 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 edição!

Faça já sua assinatura digital! | www.devmedia.com.br/es

Faça um up grade em sua carreira.

Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, análises,
testes, entre outros, pode ser a diferença entre conquistar ou não uma boa posição profissional. Sabendo disso a DevMedia
lança 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 (aplicações orientadas a servicos); Analise de sistemas; modelagem; Métricas;
orientação à objetos; UML; testes e muito mais. Assine já!
 EDITORIAL

N
esta edição a Engenharia de Software Magazine volta a des-
tacar como tema de capa a agilidade no desenvolvimento de
software. Desta vez, o foco da discussão será sobre a gerência
de projetos. Para isto, trazemos duas matérias muito interessantes. Na
primeira delas, Desafios para o gerenciamento ágil de projetos cola-
Ano 2 - 19ª Edição 2009 Impresso no Brasil
borativos, serão apresentadas as definições e os desafios envolvidos
Corpo Editorial no gerenciamento de projetos colaborativos, gerenciamento de pro-
jetos tradicionais e gerenciamento ágil, realizando uma comparação
Colaboradores
com os conceitos clássicos do gerenciamento de projetos.
Rodrigo Oliveira Spínola
rodrigo@sqlmagazine.com.br No segundo artigo, Softwares para gerenciamento de projetos, vere-
Marco Antônio Pereira Araújo mos o que são softwares para apoiar o Gerenciamento de Projetos, as
Eduardo Oliveira Spínola suas funcionalidades e uma abordagem dos principais sistemas exis-
Revisão e Supervisão tentes no mercado, destacando o que pode ser evoluído para abraçar
Thiago Vincenzo Ciancio - thiago.v.ciancio@devmedia.com.br o gerenciamento de projetos colaborativos e o desenvolvimento ágil.
Coordenação Geral Além destas matérias, esta edição traz mais quatro artigos:
Daniella Costa - daniella@devmedia.com.br • Arquitetura Orientada a Serviços
Diagramação • Arquitetura REST: Uma alternativa para construção de Serviços Web
Janete Feitosa • Usando banco de dados objeto-relacionais
Capa • Gestão de Portfólio 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 Spínola
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação
(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 implementação 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, endereço de
bancas de jornal, entre outros, entre em contato com:
Cristiany Queiróz – Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338 Marco Antônio Pereira Araújo
Kaline Dolabella (maraujo@devmedia.com.br)
Gerente de Marketing e Atendimento
kalined@terra.com.br Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
(21) 2220-5338 nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos
Computacionais e Bacharel em Matemática com Habilitação em Informática pela
Publicidade
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação
Para informações sobre veiculação de anúncio 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 Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-
Kaline Dolabella
publicidade@devmedia.com.br so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
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 sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine, Eduardo Oliveira Spínola
entre em contato com os editores, informando o título 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 Spínola - Colaborador É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde
editor@sqlmagazine.com.br atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de
Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).
 Caro Leitor
Para esta edição, temos um conjunto de 5 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da
Engenharia de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de
aulas publicadas pode ser vista abaixo:

Tipo: Projeto Tipo: Projeto

Título: Diagrama de Classes na Prática – Partes 9 a 11 –
Estudo de Caso 2
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta aula é parte de uma série sobre a construção de
diagrama de classes da UML. O objetivo do conjunto de aulas é apresentar
de forma prática como elaborar o diagrama de classes a partir de diferentes
estudos de caso. Nestas aulas, daremos continuidade à elaboração do
diagrama de classes para o segundo estudo de caso. Nesta etapa, serão
identificadas as operações e relacionamentos das classes.Ao final teremos
o diagrama de classes elaborado para o segundo estudo de caso.
Título: Diagrama de Classes na Prática – Partes 12 e 13 –
Estudo de Caso 3
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta aula é parte de uma série sobre a construção
de diagrama de classes da UML. O objetivo do conjunto de aulas é
apresentar de forma prática como elaborar o diagrama de classes
a partir de diferentes estudos de caso. Nestas aulas, é dado início à
elaboração do diagrama de classes para o terceiro estudo de caso.
Nesta etapa, serão 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 Serviços
Anderson Dias Ribeiro e Giuliano Prado de Morais Giglio

33 - Arquitetura REST
Lívia Ruback e Regina Braga

39 - Usando banco de dados objeto-relacionais

Ana Cristina Melo

Planejamento e Gerência
47 - Gestão de Portfólio de Projetos
Cristine Gusmão e Carlos Henrique R. Alexandria

4 Engenharia de Software Magazine


Desafios para o gerenciamento ágil de projetos
colaborativos
Camila de Araujo
Possui graduação em Bacharelado em Siste-
mas de Informação pela Universidade Esta-
dual Paulista Júlio de Mesquita Filho (2003)
e mestrado em Engenharia de Produção pela
Universidade de São Paulo (EESC-USP, 2008).
Atualmente é doutoranda em Engenharia
de Produção na Universidade de São Paulo
(EESC-USP), com a pesquisa “Software de
apoio ao gerenciamento ágil de projetos cola-
borativos de novos produtos”. Tem experiência
na área de Engenharia de Produção, com
ênfase em Gerência 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
informação e desenvolvimento de produto.
O
objetivo deste artigo é apresentar
as definições 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 (clássicos)
de gerenciamento de projetos. Não se
pretende descrever os tradicionais,
pois há uma vasta literatura sobre o
tema, de fácil acesso e padronizada por
associações profissionais1. A primeira
seção apresenta a definição de Geren-
ciamento de Projetos Colaborativos e
seus conceitos básicos como colaboração
e classificação de projetos. A seção se-
guinte apresenta as críticas à teoria de
gerenciamento de projetos e o enfoque
ágil no gerenciamento de projetos com
sua definição, seus objetivos, princípios
Edição 19 - Engenharia de Software Magazine
M etodologias Ágeis
De que se trata o artigo?
Este artigo apresenta as definições e os desafios
envolvidos no gerenciamento de projetos colabora-
tivos, gerenciamento de projetos tradicionais e ge-
renciamento ágil, realizando uma comparação com
os conceitos clássicos do gerenciamento de projetos.
Para que serve?
Com a constante aquisição de empresas de desen-
volvimento por outras empresas de desenvolvimen-
to acredita-se que em alguns anos será comum a
gerência de projetos de forma colaborativa, visto que
estas empresas estarão espalhadas geograficamen-
te. Além disso, a necessidade de entregar versões do
sistema mais rapidamente e que atendem em evo-
lução às necessidades do cliente indicam um cenário
adequado para o desenvolvimento ágil. Nesse artigo
você conhecerá estas duas formas de GP.
Em que situação o tema é útil?
Este tema é útil para todos aqueles que lidam com
gerência de projetos e que estão interessados em
conhecer e/ou adotar o gerenciamento de projetos
colaborativos ou métodos ágeis em seus projetos.
1 Gestão tradicional, aqui tratada como clássica.
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
síntese dos desafios identificados.
Desafios no gerenciamento de projetos colaborativos
Definição e conceitos básicos da colaboração
Nooteboom (1999) diz que a razão fundamental pela qual
as empresas se associam é a oportunidade de complementar
suas competências para produzir valor agregado e inovação.
A associação com outras empresas é fundamental no atual
cenário de desenvolvimento tecnológico. O caso da Procter &
Gamble, apresentado por Huston e Sakkab (2006), demonstra
claramente esse problema. Uma empresa que possui uma es-
trutura de desenvolvimento tecnológico significativa, frente ao
padrão da maioria das empresas, e que, apesar disso, reconhece
a dificuldade de manter-se atualizada nas várias tecnologias
necessárias ao seu negócio. Assim, apesar do tradicional inves-
timento em P&D, a empresa permanece na busca de parcerias,
criando redes de colaboração.
Rycroft e Kash (2004) identificam a globalização como sendo
a força que induz à colaboração entre vários tipos de organiza-
ção. Combinando a força, a perícia e o conhecimento de equipes
técnicas diversas e dispersas geograficamente, as tecnologias
podem ser desenvolvidas em menos tempo (DAVIS, KEYS e
CHEN, 2004). Talvez, no futuro, as empresas que conseguirão
manter-se na liderança do desenvolvimento tecnológico e de
produtos sejam aquelas que consigam se associar às redes que
contemplem todas as competências necessárias para o desen-
volvimento dos produtos e que saibam melhor como atuar de
forma colaborativa (HUSTON e SAKKAB, 2006). Empresas que
sejam também aptas a criar processos de negócio capazes de
acessar o conhecimento compartilhado (KODAMA, 2007).
O desenvolvimento colaborativo é, portanto, um fenômeno
atual. Na literatura existem várias definições de colaboração
em termos de desenvolvimento de produto. Desde a década
de 80 que esse fenômeno vem sendo desenvolvido do ponto
de vista gerencial, com diversos nomes (alianças estratégicas,
parcerias, etc.) e sob diferentes aspectos. Amaral (1997) e
Amaral e Toledo (2000) apresentam uma compilação espe-
cífica sobre a colaboração no desenvolvimento de produtos,
na qual identificam linhas de pesquisa distintas e comparam
diferentes definições.
Em um estudo recente, Emden, Calantone e Droge (2006)
apresentam uma extensa revisão sobre colaboração no desen-
volvimento de produto. Os autores definem colaboração no
desenvolvimento de produto como um tipo de relacionamento
inter-organizacional, caracterizado por níveis elevados de
transparência e onde cada participante contribui com uma
parcela significativa do resultado final do projeto. Essas duas
características – interação e objetivos comuns – são os aspectos
fundamentais que designam praticamente todas as definições
de colaboração. Exemplos de definições que seguem essa linha
são as de Mattessich e Monsey (1992), segundo a qual cola-
boração é uma relação bem definida e mutuamente benéfica
6 Engenharia de Software Magazine - Desafios para o gerenciamento ágil de projetos colaborativos
entre duas ou mais organizações, a fim de atingir objetivos
comuns; e a de Katz e Martin (1997), como o trabalho conjunto
de indivíduos para atingir objetivos comuns.
Mas essas definições não exploram em profundidade um aspec-
to do trabalho colaborativo: a criação conjunta. Duas empresas
que trabalham em um mesmo projeto podem, não necessaria-
mente, influenciar da mesma maneira no resultado final. Assim
corre-se o risco de confundir colaboração com outros tipos de
relacionamentos que não apresentam níveis similares de com-
plexidade gerencial. Um caso emblemático é a subcontratação
de serviços de desenvolvimento. O cliente concebe o produto,
define as características essenciais e delega a outra empresa
trabalhos específicos de detalhamento, sem que haja interação
ou contribuição do fornecedor no resultado preconcebido. Neste
caso, pode haver uma divisão de tarefas clara e bem delimitada,
que faz o esforço não ser realmente de cooperação, na medida em
que envolve pequena interação entre as partes.
O estudo de Camarinha-Matos et al. (2006) descreve os vários
níveis de integração entre parceiros que foram analisados e
utilizados na definição de colaboração. Os autores apresen-
tam uma classificação de quatro tipos de envolvimento: rede,
coordenação, cooperação e colaboração. O mais avançado, dito
colaboração, envolve objetivos, identidades, responsabilidades
e trabalho conjuntos, quer dizer, a criação do produto final é
realizada conjuntamente pelos parceiros: por meio de intensa
troca de informações. Por deixar esse aspecto mais evidente,
adota-se neste trabalho a definição do nível mais avançado
desses autores (CAMARINHA-MATOS et al., 2006): “Um pro-
cesso em que entidades compartilham informações, recursos
e responsabilidades para planejar, implementar e validar um
programa de atividades para atingir um objetivo comum”.
Definição de projeto colaborativo
Um dos fatores que contribuíram para a difusão da literatura
de gerenciamento de projetos foi o lançamento, 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 padrão, um projeto é um esforço temporário
para criar um produto (item final ou componente), serviço
(funções de negócio para suporte ou distribuição) ou resul-
tado exclusivo (documentos, por exemplo, de conhecimento
aplicado de pesquisa científica) (PMBOK, 2004). Os membros
dessa associação consideram também 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 múltiplos (programa). Evaristo e Fenema (1999)
propuseram uma tipologia de projetos e programas de acordo
com a localização física. Segundo os autores, os projetos ou
programas podem ser realizados e gerenciados dentro de uma
única organização ou distribuídos em diferentes organizações,
com localizações distintas. Essa diferença representaria desa-
fios e esforços gerenciais distintos, justificando a necessidade
da categorização.

Quando comparada ao conceito de projetos colaborativos,
descrito na seção anterior, nota-se que essa classificação
considera apenas o aspecto do envolvimento de diferentes
organizações em um mesmo projeto, porém não caracteriza o
aspecto da divisão de tarefas. Há projetos que são realizados
por duas ou mais organizações e distribuídos, 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 organizações
tenham que definir e criar as soluções conjuntamente,
negociar prazos e métodos de trabalho, como é o caso do
envolvimento de parceiros de risco no desenvolvimento de
novos produtos. As duas situações representam problemas
com níveis de complexidade distintos em termos de geren-
ciamento de projetos.
Portanto, propõe-se neste artigo uma adaptação da tipo-
logia de Evaristo e Fenema (1999). A Figura 1 representa
a adaptação dessa tipologia, que considera não somen-
te o conceito de distribuição física, como também o de
colaboração.
Figura 1. Tipologia de Projetos para o desenvolvimento de Produtos
(Fonte: adaptado de Evaristo e Fenema (1999))
Definem-se como colaborativos, então, os projetos onde há
um esforço compartilhado no conteúdo e, portanto, prazos,
metas e o controle gerencial negociados; independentemente
de as equipes de cada organização estarem em um mesmo
local ou de trabalharem distribuídas.
A tipologia a ser empregada neste trabalho utiliza, por-
tanto, quatro classificações, conforme apresentadas na
Figura 1.
A literatura sobre projetos colaborativos de desenvolvi-
mento de produtos tradicionalmente aborda os projetos do
tipo Colaborativo-Distribuídos (KVAN, 2000; NAOUM, 2003;
e HUSTON e SAKKAB, 2006).
Este artigo ocupa-se dos problemas e limitações dessa te-
oria. Foram observadas críticas 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
Síntese dos desafios no gerenciamento de projetos colaborativos
Dodgson (1992) afirmava que a interação entre os parceiros
era um ponto crítico no desenvolvimento de projetos (DODG-
SON, 1992). Esses problemas ainda são perceptíveis. Moody e
Dodgson (2006) apresentam um estudo de caso de um projeto
complexo de desenvolvimento de satélite que envolveu a cola-
boração de várias organizações. Uma das conclusões do estudo
é que a influência da liderança é significativamente maior se
comparada aos projetos tradicionais. Ela é fundamental para
garantir uma interação suficiente entre as equipes das dife-
rentes organizações.
No começo da atual década, Kerzner (2002) afirmou que
com as “constantes fusões e aquisições de empresas, o ge-
renciamento de projetos multinacionais será um dos grandes
desafios desta década”, 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 informação sobre o que as outras equipes do projeto
estão fazendo (progresso das tarefas);
• Falha no controle de mudança do projeto;
• Visões diferentes sobre os objetivos do projeto;
• Rigidez no planejamento do projeto e das rotinas;
• Reações pouco produtivas em relação às mudanças repenti-
nas no ambiente do projeto;
• Dificuldades tecnológicas inesperadas.
Barnes, Pashby e Gibbons (2006) realizaram uma revisão da
literatura e identificaram os fatores de sucesso dos projetos
colaborativos no caso indústria-indústria:
• Objetivos claramente definidos;
• Responsabilidades claramente definidas;
• Plano de projeto aceito pelas partes;
• Recursos adequados;
• Marcos de projeto definidos;
• Monitoramento regular do progresso;
• Comunicação 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 informação sobre o que as outras
Comunicação efetiva
equipes do projeto estão fazendo
Visões diferentes sobre os objetivos do
Objetivos claramente definidos
projeto
Plano de Projeto aceito pelas partes, recursos
Falha no controle de mudança do projeto
adequados.
Tabela 1. Alinhamento de fatores para sucesso de um projeto colaborativo
Edição 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 comunicação, a atualização
das informações e um controle da progressão das atividades
regulado por entregas efetivas.
Desafios do gerenciamento de projetos e o
gerenciamento ágil de projetos
Críticas aos métodos tradicionais de gerenciamento de projetos
A teoria tradicional de gerenciamento de projetos recebeu
grande atenção no início dos anos 90 com a publicação de
padrões de “corpos de conhecimentos” pelas associações pro-
fissionais de gerenciamento de projetos. O mais difundido é a
proposta pelo Project Management Institute (PMBOK, 2004). Esse
padrão propõe a descrição dos conceitos em um conjunto de
processos do gerenciamento de projetos. Esses processos são
organizados em Áreas do Conhecimento. São nove áreas do
conhecimento: Integração, Escopo, Tempo, Custos, Qualidade,
Recursos Humanos, Comunicação, Riscos e Aquisições. E
consideram cinco grupos de processo: Iniciação, Planejamento,
Execução, Controle e Encerramento. Essas áreas e grupos de
processo são empregados neste artigo, mas não serão descritos
em detalhe, pois há muitas referências de fácil 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
expansão na difusão e aplicação dos métodos e técnicas de
gerenciamento de projetos, surgiram abordagens alternativas
e propostas de modificação.
Uma das primeiras foi a atualmente conhecida como Teoria
da Corrente Crítica, proposta por Goldratt (2005). Trata-se
de uma modificação em alguns aspectos da teoria de geren-
ciamento de projetos, segundo os conceitos da Teoria das
Restrições, desenvolvida pelo mesmo autor. Neste enfoque
gerencial, os problemas são analisados sempre sob o ponto de
vista da restrição. No caso do gerenciamento de projetos, tais
autores propõem a realização de planejamentos em quais os
recursos são programados segundo a capacidade máxima do
recurso-gargalo, isto é, aquele com maior carga de trabalho.
Para fazê-lo, os autores propõem pequenas alterações, intro-
duzindo conceitos como pulmão de projeto e recurso-tambor
(GOLDRATT, 2005).
Maylor (2001) afirma que muitas empresas que apresentam
excelência em gerenciamento de projetos, em determinadas
áreas de atividade não fazem uso da teoria tradicional de
gerenciamento de projetos. Empregam outras técnicas e sim-
plificações que não têm sido sistematicamente estudadas pelos
teóricos da área de gerenciamento e que, por isso, as técnicas
teriam evoluído pouco nos últimos 20 anos até 2001. As ques-
tões principais a serem estudadas, segundo o autor, seriam:
• Relacionamento entre estratégia organizacional e a estra-
tégia na condução dos projetos. Segundo o autor, a teoria
apresentaria um relacionamento fraco entre as duas estra-
tégias por haver poucos métodos e técnicas que relacionem
8 Engenharia de Software Magazine - Desafios para o gerenciamento ágil de projetos colaborativos
estratégia organizacional, gerenciamento de portifólio (plano
agregado de projetos) e a definição e estratégias na condução
dos projetos;
• Medidas para avaliação dos projetos. Segundo o autor, o
enfoque tradicional mediria o sucesso do projeto em termos
apenas de cumprimento das metas do projeto: orçamento,
escopo e restrições de tempo. Questões como necessidade de
excelência, melhoria contínua e superação das necessidades
dos clientes não estariam sendo tratadas;
• Alteração do enfoque da manufatura para o enfoque de
serviços. De acordo com o autor, o enfoque da teoria atual
ajusta-se aos padrões e especificações, comuns em um ambien-
te de grandes projetos, onde o mais importante é o produto
físico obtido, manufaturado. Atualmente, os serviços seriam
tão, ou mais, importantes. O grau de orientação ao cliente teria
que ser muito maior, fazendo com que a gestão das expecta-
tivas dos interessados (stakeholders), a percepção deles quanto
ao sucesso do projeto, seja fundamental para a avaliação do
resultado do projeto;
• Foco na fase de execução. O autor afirma que a fase de
execução é pouco desenvolvida na teoria de gerenciamento
de projetos e que muitos textos da área parecem sugerir que
o planejamento e uso de sistemas de informação 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, é necessário que as estimativas possuam certo nível de
confiança, que é difícil de ser obtida. Na prática, seria possível
apenas em intervalos de curto prazo, diferentemente dos que são
utilizados no planejamento tradicional de projetos. Cita ainda,
neste aspecto, as críticas realizadas por Goldratt (2005)2;
• Foco no Gráfico de Gantt. Segundo o autor, haveria uma
valorização e emprego excessivo do Gráfico de Gantt na abor-
dagem tradicional. Na opinião deste, o gráfico bem elaborado,
por meio do uso de ferramentas computacionais, teria como
efeito a criação de uma forte credibilidade e a ilusão de que
há um bom plano de projeto; mesmo quando as atividades
e recursos não tenham sido bem definidos e/ou estimados.
Mais, o Gráfico encorajaria uma abordagem de planejamento
de um único passo, isto é, sem o necessário acompanhamento e
contínuo replanejamento. Em terceiro lugar, o Gráfico 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
à tendência de transformar gerentes de projeto em operadores
de softwares computacionais, mais do que pessoas responsáveis
pela discussão e negociação;
• Uso de recursos alternativos de planejamento. O autor
cita um caso de uma empresa transnacional que obteve um
desempenho de excelência 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 edição em português. Maylor (2001) cita a referência original
de 1997. Goldratt apud Maylor (2001).

maneira híbrida, com as ferramentas computacionais, onde os
colaboradores utilizavam softwares de planejamento de projetos
para subprojetos ou entregas específicas. O autor cita outro
caso de um gerente de projetos de construção civil em que
as ferramentas computacionais atuais, baseadas no Gráfico
de Gantt e PERT/COM, foram consideradas inadequadas e
ultrapassadas.
Mais recentemente, em 2002, surgiu uma crítica que se tornou
conhecida como a teoria do Gerenciamento Ágil de Projetos
(Agile Project Management - APM). Trata-se do manifesto, lança-
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): inovação contínua – 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 adaptação do processo e das pessoas – para responder
rapidamente às mudanças de negócios e produtos; e resul-
tados confiáveis – 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 idéias dominantes da literatura de
gerenciamento de projetos e apresentar direções 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 três sub-temas – Teoria sobre Prática (direção 1), Teoria para
Prática (direções 2-4) e Teoria na Prática (direção 5), demons-
trados na Figura 2 (WINTER et al., 2006).
Na Teoria sobre a Prática, é apresentada a necessidade do
desenvolvimento de novos modelos devido à complexidade
dos projetos e do seu gerenciamento. Segundo os autores, os
modelos empregariam um padrão de ciclo de vida “fechado”,
isto é, previamente definido. A crítica é que o aumento da
complexidade exigiria modelos de ciclo de vida mais flexíveis,
e pesquisas neste sentido deveriam ser conduzidas. Para os au-
tores, os novos modelos precisarão demonstrar a realidade das
práticas de GP, que procuram atender a um ambiente dinâmico,
de rápidas mudanças e altos riscos (WINTER et al., 2006).
A segunda linha de pesquisa identificada foi chamada de
Teoria para Prática. Na visão dos autores, os projetos são em
geral imprevisíveis e multidimensionais, mais complexos que
os modelos racionais e determinísticos, que predominariam
na literatura de GP. Assim, aprimoramentos que possam con-
siderar de forma mais eficiente os aspectos, como a mudança
contínua do fluxo de eventos, os efeitos da interação social e
da ação humana. As interações entre organizações e relações
M etodologias Ágeis
entre diferentes grupos com interesses diferentes fazem parte
dessa direção (WINTER et al., 2006).
A terceira linha de pesquisa destaca a mudança de foco na
criação do produto para a criação do valor. As metodologias
que focam a produção de um produto físico ou de um sistema
mudam para a entrega de um “valor” e não unicamente de
um produto. Por exemplo, o foco pode estar na estratégia de
escolha de um projeto de um produto que seja relacionado
com as estratégias de negócio da organização, permanecendo
o valor do projeto mesmo após a entrega do produto (WINTER
et al., 2006).
A linha de pesquisa 4, ainda na Teoria para Prática, apresenta
a mudança de concepção estreita do projeto para uma ampla
concepção dele. Isso quer dizer entender o projeto do produto
mais do que simples ações para criar um objeto físico, olhar
para ele de várias perspectivas e, assim, criar um conjunto de
imagens que podem indicar novas idéias e formas de gerenciar
projetos (WINTER et al., 2006).
A última linha de pesquisa, Teoria na Prática, diz que os
praticantes de GP não devem ser apenas técnicos treinados nos
procedimentos e ferramentas de GP, mas devem ser praticantes
reflexivos e críticos, que aprendem e aplicam suas experiências
no desenvolvimento de um projeto (WINTER et al., 2006).
Teoria sobre Prática
Direção 1
Modelo de Ciclo de Vida de GP  Teorias da Complexidade de GP
Teoria para Prática
Direção 2
Projetos como Processo Instrumental  Projetos como Processo Social
Direção 3
Foco na Criação do Produto  Foco na Criação do Valor
Direção 4
Concepção Estreita dos Projetos  Concepção Ampla dos Projetos
Teoria na Prática
Direção 5
Praticantes como Técnicos Treinados  Praticantes como Praticantes Críticos
Figura 2. Linhas para futuras pesquisas em GP (Fonte: adaptado de
Winter et al. (2006))
Três fatores são identificados por Cicmil et al. (2006) que
causam “atropelamento” na execução dos projetos, quando
esses são gerenciados pelo modelo clássico:
• Complexidade estrutural do produto;
• Mudanças devido ao desconhecimento de atividades e ações
necessárias;
• Tempo restrito para execução das atividades.
Então, o projeto de um produto de alta complexidade possui
na sua gênese, em sua complexidade estrutural e tecnológica,
Edição 19 - Engenharia de Software Magazine 9
uma fonte de incertezas que dificulta a sua execução. O planeja-
mento do tempo é, portanto, impreciso, e, como conseqüência,
muitas vezes há restrição dele para execução das atividades. Os
gerentes de projeto são forçados a tomar ações paliativas, que
acelerem o ritmo do projeto e podem gerar novos problemas
(CICMIL et al., 2006). Dessa forma, cria-se um círculo vicioso
difícil de romper.
Winter et al. (2006) propõem que se deve aprofundar a pesquisa
em técnicas e métodos, visando o desenvolvimento de soluções
capazes de “gerenciar a complexidade”. Essa idéia é próxima da
proposta de Highsmith (2004) e demais autores do Gerencia-
mento Ágil de Projetos, que criticam os métodos tradicionais
de gerenciamento de projetos por não conseguirem lidar com
o ambiente de incerteza, gerado pela complexidade dos proje-
tos atuais. A solução, segundo os autores, seria a utilização de
equipes auto gerenciadas e flexíveis. Não há dúvida, portanto,
da concordância dos autores de que a teoria tradicional, dita
clássica, não seria útil para projetos de alta complexidade, com
alto grau de inovação e envolvendo diferentes organizações.
Em um exemplo de gerenciamento de um projeto de alta com-
plexidade, descrito por Moody e Dodgson (2006), observou-se
que as tarefas são continuamente ajustadas e redefinidas con-
forme o projeto se desenvolve, sendo necessária a adaptação
constante do planejamento das atividades. A interação cons-
tante entre os colaboradores, mais informal e independente
da posição hierárquica, também foi observada como mais
adequada. Desta forma, segundo Moody e Dodgson (2006),
os métodos para o gerenciamento do projeto devem ser adap-
tados, de forma a atender essas necessidades de flexibilidade,
corroborando as opiniões de Winter et al. (2006) e dos autores
do Gerenciamento Ágil.
A contribuição do grupo de pesquisa “Rethinking Project
Management” é importante, porém, limita-se a criticar a teoria.
Esses autores não propõem soluções práticas, como métodos,
técnicas ou ferramentas. Já os autores do Gerenciamento Ágil
de Projetos propõem soluções que visam formar um novo cor-
po teórico, segundo eles, uma nova abordagem para o geren-
ciamento de projetos e que se distinguiria fundamentalmente
da abordagem tradicional. Nas próximas seções, analisa-se de
maneira crítica os conceitos e métodos 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 clássico de projetos.
Definição do gerenciamento ágil de projetos
As empresas de software operam em um ambiente de rápidas
mudanças e altos riscos. O gerenciamento de projetos é funda-
mental, porém sua introdução não havia sido fácil, devido ao que
se considerava como rigidez e foco excessivo no planejamento. Em
2001, lançou-se o Manifesto Agile for Software Development (BECK
et al., 2001), que procura enfatizar o uso dos métodos chamados
de ágeis, voltado para a colaboração com o cliente, nos indivíduos
e respostas rápidas às mudanças. Alguns exemplos desses méto-
dos ágeis, aplicados para o desenvolvimento de softwares, são o
Extreme Programming (XP), Scrum e Crystal Methods.
10 Engenharia de Software Magazine - Desafios para o gerenciamento ágil de projetos colaborativos
Outras indústrias passaram a adotar práticas denominadas
de ágeis, criando adaptações nos métodos e técnicas de Geren-
ciamento Clássico de Projetos, para suprir suas necessidades
no gerenciamento de projetos complexos. Mas, muitas vezes,
essas adaptações apresentam restrições devido aos métodos e
técnicas do Gerenciamento Clássico e podem apresentar um
desempenho ruim, com redução da eficiência e eficácia dos
resultados (CHIN, 2004).
Chin (2004), então, propõe o que ele denomina de uma nova
abordagem para o gerenciamento de projetos, quebrando a vi-
são do forte planejamento prévio das atividades. Assim, temos
o início do Agile Project Management (APM) ou Gerenciamento
Ágil de Projetos.
O APM foi definido por Highsmith (2004) como “´[]... um
conjunto de valores, princípios e práticas que auxiliam a equi-
pe a entregar produtos ou serviços de valor em um ambiente
desafiador”.
A Figura 3 mostra esquematicamente a distinção entre as
duas abordagens. A base de “tijolos” representa a eficiência,
eficácia de uma plataforma de gerenciamento de projetos. Esta
figura tem por objetivo transmitir a mensagem de que a teoria
clássica necessitaria de uma dedicação maior em atividades
exclusivas de gerenciamento (“base maior”). Ao passo que no
gerenciamento ágil, parte dessas atividades são substituídas
por autocontrole da equipe ou atenuadas por meio do emprego
de técnicas simplificadas e visuais.
Figura 3. Relacionamento entre as abordagens clássica e ágil de
gerenciamento de projetos (Fonte: CHIN, 2004, p. 3)
A Figura 3 não é suficiente para descrever as diferenças
entre as abordagens ágil e clássica. Uma forma de fazê-lo é
descrevendo os objetivos, valores e princípios.
Objetivos, valores, princípios e fases do GP ágil
São cinco os objetivos principais para um bom processo de
exploração do APM (HIGHSMITH, 2004, p. 6):
1. Inovação contínua. Um dos objetivos básicos do APM é entre-
gar produtos que atendam aos requisitos atuais dos clientes de
maneira inovadora. A geração de idéias inovadoras não ocorreria
em ambientes autoritários e burocraticamente estruturados,
isto é, com regras bem definidas e tarefas cuidadosamente
planejadas. Mas, sim, em ambientes que eles denominam de
“adaptativos”, onde a inovação e novas soluções são priorizadas.
Segundo esses teóricos, as práticas como o planejamento prévio
e detalhado das atividades de cada membro e atribuição do

controle dos projetos para estruturas organizacionais específi-
cas estimulariam o comportamento individualista e inibiriam
a proposição de idéias 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 práticas ágeis integram o custo de
mudanças como parte do processo de desenvolvimento, para
atender as mudanças do mercado. Na teoria clássica, o produto
é definido com todas as suas características no início do projeto,
gerando o planejamento detalhado de todas as atividades. Des-
sa forma, alterar uma característica do produto para atender
a um requisito, por exemplo, pode se tornar uma barreira. O
resultado é que os integrantes podem adiar demasiadamente
as mudanças, gerando custos diretos mais elevados, conse-
qüentemente, prejuízo para a organização 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 idéia é a iteratividade, gerando entregas
de curto prazo. Sugere-se que equipes pequenas e qualifica-
das poderiam manter atenção constante nas características
do produto e foco no curto prazo. Elas deveriam também
considerar cuidadosamente quais características devem ser
incluídas no produto e criar, assim, um processo de desen-
volvimento concentrado em atividades que agregam valor. A
crítica subentendida, que não é 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 urgência e distanciando a equipe do foco no valor
agregado pelas atividades;
4. Capacidade de adaptação do processo e das pessoas. O
APM procura responder rapidamente às mudanças de negó-
cios e produtos. A meta proposta pelo autor é que os membros
da equipe não resistam às mudanças no decorrer do projeto,
mas entendam que os produtos podem ser modificados ao
longo do seu desenvolvimento. As equipes também precisam
ser receptivas às novas idéias. A crítica ao gerenciamento
de projetos clássico é a de que a especialização e distancia-
mento dos membros da equipe fazem com que resistam às
mudanças na forma como conduzir as atividades de projeto,
isto é, tenderiam a replicar formas de conduta realizadas em
projetos anteriores. E que práticas como controle de mudança
e verificação desestimulariam alterações nos projetos nas fases
iniciais, gerando problemas futuros. Especialmente no caso de
projetos inovadores em que, segundo o autor, tais mudanças
são necessárias;
5. Resultados confiáveis. O APM possui o objetivo de apoiar
o crescimento e aumento de lucratividade do negócio. O
processo de desenvolvimento deve medir a importância da
entrega para o cliente ou se a entrega está compatível com o
custo e o tempo estabelecidos para o projeto. Na teoria clás-
sica, como dito anteriormente, o foco está no planejamento
e controle, com ênfase na documentação e atividades. Isso
diminui a preocupação com o valor efetivo. Já no enfoque
ágil, a maior preocupação é 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
nível de satisfação. Com isso, mais do que se preocupar com
a satisfação de metas previamente estipuladas, os membros
das equipes estariam preocupados se os resultados estão
de acordo com as expectativas do cliente: uma análise mais
qualitativa, portanto.
Além dos objetivos, os autores de APM descrevem um
conjunto de valores e princípios que norteiam o desenvol-
vimento de suas atividades, e que, em tese, habilitariam os
gerentes de projetos a alcançar o desenvolvimento de produtos
inovadores.
Os quatro valores descritos no Manifesto Agile for Software
Development são também os valores centrais nos textos de
Gerenciamento Ágil de Projetos (HIGHSMITH, 2004):
1. Respostas às mudanças: as respostas às mudanças são 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 documentação;
3. Colaboração do cliente: a colaboração do cliente é mais
importante do que a negociação de contratos;
4. Indivíduos e interações: os indivíduos e suas interações são
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 parâmetros tempo e custo. Já um gerente ágil de projeto
preocupa-se em ajustar continuamente os resultados por meio
de uma relação colaborativa com os clientes.
São seis os princípios do APM, divididos em duas categorias.
A primeira é relacionada ao produto/cliente e a segunda, ao
gerenciamento (HIGHSMITH, 2004). Esses princípios e seus
relacionamentos estão apresentados na Figura 4.
Figura 4. Princípios do Gerenciamento Ágil de Projetos (Fonte: HIGHSMITH,
2004, p. 28)
Edição 19 - Engenharia de Software Magazine 11
 Esses princípios possuem pontos importantes para a caracte-
rização do APM, tais como a geração de entregas iterativas, que
incluem o pressuposto de que um projeto possa ser estruturado
em iterações curtas e de período fixo, e a construção de equipes
adaptativas, que possuem formação variável, de acordo com as
necessidades e mudanças necessárias durante o desenvolvimen-
to do projeto, ajustando-se às variações do ambiente.
Apesar de o APM enfatizar as pessoas frente ao processo, os
próprios autores enfatizam que o processo de negócio não deve
ser ignorado. Highsmith (2004) afirma que o processo, como
qualquer outro elemento da organização, deve estar totalmente
alinhado com os objetivos de negócio.
Mas, se a plataforma Ágil é voltada à adaptação, flexibilidade
e aprendizado, então seus processos devem contemplar essas
características, que definem seu ciclo de vida e fases. São cinco
as fases do Gerenciamento Ágil de Projetos e estão 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. Visão: determinação da visão do produto e do escopo do
projeto, identificação da comunidade participante do projeto e
definição de como a equipe do projeto trabalhará em conjunto.
A principal diferença entre o escopo, derivado da prática clássica,
e a visão, da prática ágil, está na ênfase no produto. A descrição
principal que se faz na visão é a das especificações do produto,
primando pela simplificação da documentação, que deve fornecer
uma descrição de alto nível do produto para os desenvolvedores,
de forma a facilitar a especulação e exploração. Acredita-se que
isso levaria a um envolvimento maior com o cliente do que nas
práticas clássicas de iniciação do projeto, devido ao enfoque con-
tratual (obtenção de regras e “leis”) em linguagem textual;
2. Especulação: planejamento preliminar, que será seguido por
planejamentos específicos detalhados a cada iteração. Consiste
na identificação dos requisitos para o produto, desenvolvi-
mento de um plano de projeto, contendo entregas, marcos,
iterações, cronograma de trabalho e alocação de recursos,
incorporação de estratégias para mitigação de riscos e esti-
mativas de custos e outras informações financeiras relevantes.
12 Engenharia de Software Magazine - Desafios para o gerenciamento ágil de projetos colaborativos
Uma grande diferença da exploração ágil para o planejamento
clássico é o nível de detalhe. Aqui, o planejamento só é feito
até um futuro previsível, onde é colocado um próximo marco
ou ponto de decisão, evitando assim riscos de planejamentos
de longo prazo. A fase repete-se ao longo do projeto quantas
vezes for necessário;
3. Exploração: composta de três atividades críticas. A primeira
é a entrega dos produtos planejados, através do gerenciamento
da carga de trabalho. A segunda é a criação de uma comuni-
dade auto organizada do projeto e a terceira, o gerenciamento
das interações das equipes com os clientes, gerente de projeto
e stakeholders, que são 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 não 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 não esperando que esse último tome
todas as decisões necessárias para entregar o produto ao cliente
e apresentar os resultados aos stakeholders;
4. Adaptação: revisão dos resultados entregues, análise da
situação atual, avaliação do desempenho da equipe de projeto
e mudanças, se necessárias. Essa revisão considera também,
além da comparação do realizado versus o planejado, o reali-
zado versus informações e requisitos atualizados do projeto.
Esta fase, junto com a especulação e exploração, ocorre várias
vezes durante o projeto e envolve o esforço não só do gerente
do projeto, mas de toda a comunidade. Ela caracteriza os
vários ciclos de mudanças que ocorrem ao longo do projeto
para suprir as demandas atuais e atingir o sucesso do projeto.
Nas práticas clássicas, o planejamento detalhado, que é feito
no início do projeto, inibe adaptações necessárias, conforme
apresentado nos objetivos do ágil. Aqui o objetivo é adaptar o
projeto segundo as necessidades atuais, incentivando a equipe
do projeto a ter um espírito crítico e participar da próxima
especulação do projeto;
5. Encerramento: finalização das atividades do projeto, transfe-
rência dos aprendizados-chave e celebração. Como última fase,
após uma adaptação onde não são identificados mais requisitos
e realizadas as avaliações de entregas e status do realizado
versus planejado, o projeto pode ser encerrado. Aqui as práticas
ágeis e clássicas são idênticas. Nos dois casos é realizado um
histórico do projeto para possíveis consultas futuras.
A Tabela 2 apresenta uma correspondência entre os prin-
cipais grupos de processo da plataforma Clássica de GP e as
fases do APM.
Segundo Chin (2004), uma estrutura que apóie as práticas
de GP é indicada e pode trazer benefícios. O mesmo autor
propõe que essa estrutura deve incluir: processos, práticas,
ferramentas de software, modelos de documentos e formu-
lários, representados na Figura 6, com as suas interações.
Esses elementos auxiliariam na elaboração de relatórios e
documentos contendo informações valiosas para a tomada
de decisão no projeto. Highsmith (2004) enfatiza que os

relatórios de status de projeto devem adicionar valor para o
gerente do projeto, gerente de produto, stakeholders e para a
própria equipe de projeto.
Analisando-se a estrutura operacional de Chin (2004), é pos-
sível reconhecer uma significativa influência com os modelos
de estruturas para gerenciamento tradicional de projetos, tais
como escritórios de projetos e modelos de gestão de projetos.
Notem-se as definições de responsabilidades, cronogramas,
uso de padrões. Isso se explica na premissa de que a proposta
dos teóricos do ágil não significa negligenciar controles, planos
e padronização.
Grupo de Processos da GP Clássica Fases do GP Ágil
Iniciação: autorização/definição de um escopo Visão: do produto e escopo inicial do projeto
preliminar
Planejamento: detalhamento de todo projeto Especulação: plano inicial, planejamento a cada
iteração
Execução: execução do plano do projeto Exploração: entrega funcionalidade/produto a
cada ciclo
Monitoramento e Controle: progresso do Adaptação: revisão dos resultados entregues e
trabalho e gerenciamento de mudanças adaptações do escopo
Encerramento: Formalização do aceite final do Encerramento: aceites do cliente a cada ciclo e
projeto formalização final
Tabela 2. Correspondência entre as abordagens clássica 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 análise leva a crer que a proposta desses autores é mantê-
los, porém com uma diferença na forma de aplicação desses
conceitos. Trata-se, portanto, de uma proposta de processos
de gerenciamento de projetos que busca procedimentos mais
simples por meio das estratégias como: emprego de quadros e
elementos visuais; eliminação de atividades de gerenciamento
que não agregam valor; e transferência de mecanismos de
controles burocráticos para a equipe, por meio da autogestão
(HIGHSMITH, 2004 e CHIN, 2004).
Em virtude dessa análise é 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 teóricos do
APM. A palavra enfoque remete a modelo, padrão3. Portanto,
dizer novo paradigma parece representar uma forma totalmen-
te inovadora de se gerenciar projeto. Enfoque, ao contrário, sig-
nificaria uma nova forma de utilizar as ferramentas existentes.
A revisão aqui apresentada permite concluir que as propostas
dos autores de APM representam mais uma especialização da
teoria de gerenciamento de projetos, para um caso específico,
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 prática os conceitos do gerenciamento ágil em seus
projetos. A literatura sobre o tema é principalmente constituída
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 também 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 aplicação da abordagem ágil,
segundo Highsmith (2004).
Figura 7. Ambientes para aplicação do enfoque ágil (Fonte: adaptado de
Highsmith (2004) por Conforto e Amaral (2007))
A aplicação do gerenciamento ágil no desenvolvimento
de produtos físicos ainda está em fase de estudos. Benassi e
Amaral (2007) e Conforto e Amaral (2007) apresentam análi-
ses teóricas da aplicação do APM para o desenvolvimento de
produtos. Benassi e Amaral (2007) revisaram a literatura sobre
gerenciamento de projetos e identificaram apenas um trabalho
de aplicações do APM fora do contexto de software. Mais, os
trabalhos identificados são em sua totalidade teóricos. Portan-
to, não há dados efetivos de campo, verificando a aplicação
3 Segundo Larousse (1992), paradigma é um substantivo que designa modelo,
padrão ou norma. O mesmo dicionário fornece o significado de enfoque como
ação de enfocar, modo de considerar ou entender um assunto ou questão.
Edição 19 - Engenharia de Software Magazine 13
desses métodos. Mesmo tendo se passado vários anos desde
que Maylor (2001) apresentou a mesma dificuldade.
Conclusão - Síntese dos desafios encontrados
O tópico “Desafios no gerenciamento de projetos colabora-
tivos” apresentou as críticas realizadas pelos teóricos da área
de gerenciamento de projetos e também pelos autores do
enfoque Ágil. A análise dos trabalhos permite mostrar uma
convergência em termos de críticas à teoria de gerenciamento
de projetos. Conforme ilustrado na Figura 8, as direções de
pesquisa apontadas no estudo de Winter et al. (2006) são coe-
rentes com as idéias propostas no enfoque Ágil.
Figura 8. Coerência entre as direções do EPSRC e idéias 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, além
da convergência das críticas, os principais desafios:
a) Falta de modelos e técnicas capazes de adequar-se às
mudanças dos projetos. Existe a necessidade de técnicas e
métodos para o planejamento e controle capazes de: aumentar
a velocidade da elaboração de planos e sua atualização; criar
técnicas de planejamento com planos mais sintéticos, sem
perder a precisão e efetividade; criar sistemas de controle
que sejam mais rápidos na identificação das necessidades
de mudança;
b) Falta de modelos e técnicas que apóiem o acompanhamen-
to e alterações constantes no resultado final. Em virtude das
maiores mudanças, devem-se criar soluções para aprimorar o
acompanhamento dos resultados no produto do projeto. As-
sim, é preciso criar técnicas de gerenciamento de requisitos e
controles de configuração do produto;
c) Compartilhamento efetivo de recursos. As técnicas tradi-
cionais priorizam o gerenciamento centralizado de dados de
recursos, por meio da criação de pools de recursos. Em projetos
compartilhados ou onde competências são identificadas no
decorrer do projeto, geram-se problemas. É necessário criar
técnicas e métodos que facilitem o planejamento de recur-
sos compartilhados entre projetos de diferentes níveis de
complexidade.
d) Consumo de tempo em extensa documentação do projeto.
A padronização, sem dúvida, é algo importante. O desafio,
14 Engenharia de Software Magazine - Desafios para o gerenciamento ágil de projetos colaborativos
então, é realizá-la de forma adequada, garantindo que ela seja o
suficiente para agregar valor ao projeto. Formas mais simples,
rápidas e eficientes de documentação e criação dos padrões são
fundamentais. Outro desafio é combinar a utilização de pa-
drões com a melhoria contínua, isto é, a atualização constante
desses padrões de forma a garantir a introdução de melhorias
conforme as experiências em projetos anteriores;
e) Implantar técnicas que permitam o emprego dos princípios
propostos pelo gerenciamento ágil de projetos. Conforme
demonstrado, embora os teóricos do gerenciamento ágil de
projetos tenham proposto um conjunto bem organizado de
princípios, há falta de métodos e técnicas que permitam utilizá-
los. Ou, então, a identificação de como adaptar os métodos e
técnicas atuais. Os principais desafios são: foco nas pessoas;
equipes auto gerenciadas e flexíveis; criação de valor para o
cliente; exploração e adaptabilidade do produto; capacidade
de adaptação do processo e das pessoas.
A Figura 9 apresenta uma síntese dos desafios identificados
na literatura de gerenciamento de projetos e na de gerencia-
mento ágil. Identifica também a relação entre eles, por meio de
flechas, que indicam quais os desafios são equivalentes.
Figura 9. Síntese e relação entre os desafios encontrados na
literatura (Fonte: elaborada pela autora)
Agradecimentos
Meus agradecimentos ao professor doutor Daniel Capaldo
Amaral (EESC;USP), pela orientação durante o desenvolvi-
mento deste trabalho. Agradeço também à CAPES pelo apoio
financeiro e à Escola de Engenharia de São Carlos (EESC, USP)
pela infra-estrutura.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback

Referências Bibliográficas
AMARAL, D. C. Colaboração cliente-fornecedor no processo de desenvolvimento de produtos: estudos de
caso na indústria automobilística: escopo, integração e qualidade do produto. Dissertação (Mestrado em
Engenharia de Produção). Universidade Federal de São Carlos, São Carlos, 1997.
AMARAL, D. C.; TOLEDO, J. C. Colaboração cliente-fornecedor no processo de desenvolvimento de produto.
Gestão & Produção, São Carlos, v. 7, n. 1, p. 56-72, abril, 2000.
AUGUSTINE, S.; WOODCOCK, S. Agile project management: emergent order through visionary leadership.
May, 2003. Disponível 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. 395–404,
julho, 2006.
BECK, K. et al. Manifesto for agile software development. 2001. Disponível em <http://www.
agilemanifesto.org>. Acesso em janeiro, 2007.
BECK, K.et al. Chrysler goes to “extremes”.Out., 1998. Disponível 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 FÍSICO. In: XIV Simpósio de Engenharia de Produção, 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. Disponível 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. Disponível 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,  NAOUM, S. An overview into the concept of partnering. International Journal of Project Management, v.
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. Escritório de Projetos e Gerenciamento Ágil: Um Novo Enfoque para a
Estrutura de Apoio à Gestão de Projetos Ágeis. In: XXVII Encontro Nacional de Engenharia de Produção,
2007, Foz do Iguaçu. Anais... Foz do Iguaçu: ABEPRO, 2007.
DAVIS, J. M.; KEYS, L K.; CHEN. I. J. Collaborative Engineering for Research and Development. 13th
International Conference on Management of Technology. Anais…Washington, DC, April 3–7, 2004.
DIAS, M. V. B. Um novo enfoque para o gerenciamento de projetos de desenvolvimento de software.
Dissertação (Mestrado em Administração). Faculdade de Economia, Administração e Contabilidade,
Universidade de São Paulo, São 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
with Maximum Potential to Create Value. Journal of Product Innovation Management, v.23, n.4, p. 330-
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. Disponível em <http://www.martinfowler.com/articles/
newMethodologyOriginal.html> Acesso em: 24 jan. 2007.
GOLDRATT, E. M. Corrente Crítica. Editora Nobel, Brasil: São 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 & Gamble’s 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. 1–18, março, 1997.
KERZNER, H. Gestão de projetos: as melhores práticas. Tradução 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, março, 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. 568–588, setembro, 2006.
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, março, 2004.
VERZUH, E. MBA compacto: gestão 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.
Edição 19 - Engenharia de Software Magazine 15
 Softwares para gerenciamento de projetos
Camila de Araujo
Possui graduação em Bacharelado em Siste-
mas de Informação pela Universidade Esta-
dual Paulista Júlio de Mesquita Filho (2003)
e mestrado em Engenharia de Produção pela
Universidade de São Paulo (EESC-USP, 2008).
Atualmente é doutoranda em Engenharia
de Produção na Universidade de São Paulo
(EESC-USP), com a pesquisa “Software de
apoio ao gerenciamento ágil de projetos cola-
borativos de novos produtos”. Tem experiência
na área de Engenharia de Produção, com
ênfase em Gerência 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
informação e desenvolvimento de produto.
16 Engenharia de Software Magazine - Softwares para gerenciamento de projetos
E
ste artigo apresenta a definição de
Software para Gerenciamento de
Projetos (SGP), as funcionalidades
que caracterizam tais soluções e uma
análise da situação atual dos principais
sistemas disponíveis no mercado. Ao
final, apresenta uma síntese dos princi-
pais desafios, considerando a situação
atual dos SGPs segundo a literatura e os
desafios apontados no artigo Desafios
para o gerenciamento ágil de projetos
colaborativos, segundo a literatura de
métodos de gerenciamento de projetos.
De que se trata o artigo?
Este artigo apresenta o que são 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
evoluído para abraçar 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á possível escolher a mais adequada
para o seu trabalho.
Em que situação o tema é útil?
No momento de adquirir uma ferramenta, é bastan-
te importante conhecer as funcionalidades que ela
deve cobrir e o que ela trás 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.
Definição e funcionalidades dos
softwares de gerenciamento de
projetos
O gerenciamento de projetos inclui
uma mistura complexa de atividades
de planejamento, avaliação e tomada de

decisões. As informações geradas no decorrer do projeto são
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 específicos, 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, elaboração de cronogramas, comunica-
ção, colaboração, gerenciamento de configuração, controle de
documentos, gerenciamento de registros e análise de risco.”
Um conjunto de funcionalidades típicas pode ser observado
para os SGPs, tais como (ROZENFELD et al., 2005):
• Gerenciamento de Atividades: registro, visualização e orga-
nização das atividades do projeto. Envolve várias definições,
tais como: de precedência, de duração, de esforço, Gráfico de
Gantt e WBS (Work Breakdown Structure);
• Gerenciamento de Calendário e Agenda: organização e
programação de um ou mais calendários para o projeto, re-
cursos ou tarefas;
• Gerenciamento de Recursos: gerenciamento das pessoas
e materiais necessários para o projeto. Envolve funções de
análise de alocação de recursos e seu nivelamento;
• Gerenciamento de Custos: ajuda a preparação do orçamento
e acompanhamento dos gastos do projeto;
• Ferramentas de Monitoramento: funções para acompanha-
mento do projeto, como armazenamento de linhas de base e
comparações entre parâmetros de planejamento atual com os
parâmetros das linhas de base, bem como análise do valor
agregado;
• Gerenciamento de múltiplos projetos: funções para análise
do portifólio da empresa e compartilhamento de dados entre
os projetos.
Na próxima seção, é realizada a revisão de softwares, mostran-
do-se suas categorias, segundo a forma de distribuição.
Softwares de GP segundo a literatura
Nesta seção, procura-se mostrar um panorama geral dos
SGPs disponíveis atualmente. Deve-se observar que o objeti-
vo não é fazer um estudo exaustivo de todas as ferramentas,
mas apresentar uma descrição das funcionalidades dos SGPs
encontrados no mercado, segundo informações da literatura.
Os SGPs podem ser classificados em três grandes categorias,
segundo a forma de comercialização:
• Código Fechado: são os softwares distribuídos com o código
inacessível ao usuário final. Segundo a Wikipedia (2008), o
que caracteriza este tipo de software é que ele não é distribuído
com seu código fonte e, para alterá-lo, seria necessário utilizar
a prática da engenharia reversa, o que costuma ser dificulta-
do seja pelo uso de licenças, seja pela distribuição apenas de
arquivos compilados e ou outros mecanismos de segurança
como Hard-Keys. Em sua maioria, os softwares utilizam licenças
de comercialização tradicionais, isto é, por meio da compra do
Gerência de Projetos
código por pacote, número de usuários ou acesso. A Licença
Comercial pode reservar também direitos de uso, tais como
suporte, atualização periódica e acesso à documentação e
outros materiais. Outro modelo de software que se encaixa na
categoria de código fechado é o denominado “freeware”, que
também não apresenta o código fonte, apesar de sua utilização
não implicar o pagamento de licenças de uso;
• Código Aberto: São softwares onde o código-fonte está dis-
ponível para ser lido, estudado ou modificado por qualquer
pessoa interessada. Os softwares desta categoria são chamados
de software livre e o código-fonte aberto é a principal caracte-
rística desses (REIS, 2003). Um software livre também concede
as seguintes quatro liberdades: a liberdade de executar o pro-
grama, para qualquer propósito (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
cópias de modo que se possa ajudar ao seu próximo (liber-
dade nº. 2) e a liberdade de aperfeiçoar o programa, e liberar
os seus aperfeiçoamentos, de modo que toda a comunidade
se beneficie (liberdade nº. 3). As licenças de software livre
permitem que eles sejam comercializados. Na prática, já que
é possível copiar o código de qualquer pessoa que já o tenha,
o preço que o usuário paga por um software livre tende a ser
baixo o suficiente para motivar as pessoas a comprarem e não
o copiarem. (REIS, 2003);
• Modelos Científicos: são protótipos de softwares propostos
em estudos acadêmicos, que testam novos conceitos e funciona-
lidades. Esses modelos visam avanços científicos, solucionando
os problemas apresentados nos sistemas de código fechado
e/ou aberto, apresentados pelas necessidades do mercado ou
para viabilizar prova de conceito de alguma teoria. A principal
característica é que a ferramenta está em estudo, em fase de
prototipação ou validação, não sendo acessível ao mercado.
A seguir, apresentam-se as análises realizadas, a partir de
documentos, nos dois primeiros tipos: softwares comerciais
para gerenciamento de projetos e softwares livres.
No caso dos modelos científicos, não foi identificada nenhu-
ma revisão bibliográfica exaustiva. Há apenas artigos que
realizam revisões limitadas como os de Voropajev e Schinberg
(1992), Nicolo (1993), Li et al. (2001), Ren et al. (2006) e Liu et al.
(2005). Portanto, não vamos realizar uma revisão específica
desses tipos de software.
Softwares de código fechado
Em uma avaliação dos softwares comerciais de Gerenciamento
de Projetos de alta representatividade no mercado, realizada
pelo Gartner Group (2007), pôde-se observar alguns aspectos
das funcionalidades disponíveis. Foi desenvolvido um qua-
drante de classificação dos softwares (Quadrante Mágico), com
dois eixos: habilidades para executar e abrangência da visão. O
eixo “Habilidade para Executar” refere-se ao desenvolvimento
e desempenho do fornecedor de software (vendor) e incluiu os
critérios: lucratividade, nível e crescimento dos rendimentos
da empresa; equipe de gerenciamento do vendor; integridade;
Edição 19 - Engenharia de Software Magazine 17
aprofundamento (detalhamento) das funcionalidades das fer-
ramentas de aplicação; serviço e suporte; vendas e marketing.
Já o eixo “Abrangência da Visão” inclui critérios relacionados
às funcionalidades dos softwares como Abrangência, são eles:
compatibilidade com plataformas; colaboração, funcionali-
dades específicas; tecnologia e mercado; gerenciamento de
recursos; e serviços de suporte.
No quadrante dos Líderes, não basta o sistema ter funcio-
nalidades abrangentes, mas também o fornecedor do software
(vendor) deve incluir as tecnologias de desenvolvimento mais
modernas e comprometimento com um serviço de excelência.
O quadrante dos Desafiantes, segundo esta análise, contém
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 seção “Definição e funcionalidades dos
softwares de gerenciamento de projetos”. Isso foi confirmado
analisando-se a documentação técnica de Microsoft Project
(EPM) e a do Primavera, disponíveis na internet (MICROSOFT,
2008; PRIMAVERA, 2008).
Para esta pesquisa, interessam os dois últimos quadrantes:
visionários e nichos. Os Visionários são aqueles, segundo a
pesquisa, que possuem funcionalidades e ou configurações
alternativas. Para verificá-las, empregou-se uma análise da
documentação técnica presente na internet dos softwares indi-
cados na Figura 1. O critério utilizado foi a busca de funções
diferentes das citadas no tópico “Definição e funcionalidades
dos softwares de gerenciamento de projetos”. A seguir, é apre-
sentada uma breve descrição das funcionalidades diferenciais
de cada software verificado, isto é, aquelas que diferem da lista
apresentada por Rozenfeld et al. (2005).
Figura 1. Quadrante de classificação dos softwares comerciais (Fonte:
relatório do Gartner Group (2007))
O IBM RPM inclui o controle de colaboração no projeto, além
das funcionalidades já citadas como básicas dos SGPs. Ele
18 Engenharia de Software Magazine - Softwares para gerenciamento de projetos
fornece aos gerentes e participantes do projeto informações
sobre acontecimentos e alterações durante o decorrer do pro-
jeto, utilizando notificações de estado e condições de disparo
de e-mails configurados pelo usuário especificamente para
cada projeto (IBM, 2008).
Nas informações técnicas publicadas sobre o Serena (2008),
não há explicações suficientes sobre suas funcionalidades (SE-
RENA, 2008). Portanto, não foi possível 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 informações
técnicas disponíveis no site, disponibiliza as funcionalidades
básicas dos SGPs, incluindo também coleta de informações
que permite modelar documentos padrão do projeto e do
planejamento, como formulários on-line; relatório de acompa-
nhamento de sanidade do projeto, como relatórios imediatos
de progresso, alertas de vencimento de prazo de tarefas e no-
tificações aos membros da equipe (BORLAND, 2008). Portanto,
não foi possível identificar funcionalidades diferenciais.
Já o software da EProject (Daptiv PPM) possui foco em funcio-
nalidades de colaboração. Um exemplo é a troca de mensagens
assíncronas integrada às funções tradicionais de GP, inclusão
de documentos no projeto utilizando função drag-and-drop
(arrastar e soltar) nas janelas; e funcionalidade para registro e
gerenciamento de Lições Aprendidas (EPROJECT, 2008).
O Sciforma (PS8) tem como diferencial o apoio à criação de
templates para os projetos. Dispõe de funcionalidades para criar
gráficos e relatórios, além dos existentes no software, com o in-
tuito de melhorar o acompanhamento e avaliações do projeto.
Ele também disponibiliza troca de mensagens assíncronas pelo
software (SCIFORMA, 2008).
O site da Powersteering não disponibilizou informações
técnicas do seu produto, por isso não foi possível avaliá-lo
(POWERSTEERING, 2008). Pelo mesmo motivo, também não
foi possível avaliar o software da ITM (ITM, 2008).
A análise, embora parcial, indica que os softwares ditos “vi-
sionários” não apresentam funcionalidades tão distantes dos
softwares tradicionais. A diferença está principalmente na in-
clusão de ferramentas de troca de mensagens, nos relatórios de
acompanhamento mais avançados e nas lições aprendidas.
No quadrante do Nicho, estão os softwares que, segundo a
análise, atendem necessidades específicas de determinado
grupo de clientes, como funcionalidades específicas de geren-
ciamento de portfolios ou adaptações para padrões de regiões
geográficas.
Os softwares da Instantis e Augeo Software possuem funcio-
nalidades específicas para projetos de desenvolvimento de
novos produtos, mas não detalham essas funcionalidades em
seus sites. Os demais softwares que compõem o quadrante não
apresentaram, pelas informações técnicas nos sites, funciona-
lidades diferenciais.
Conforme o objetivo deste artigo, chamam a atenção nessa
categoria as soluções voltadas para o desenvolvimento de
projetos de TI, pois entre os sistemas de nicho há fabricantes
que se propõem a implementar funcionalidades conforme as
 Gerência de Projetos

diretrizes do enfoque ágil de desenvolvimento de produtos.
Analisando-se sua documentação, identificaram-se como
funções diferenciais o cadastro dos projetos, iterações e en-
tregas programadas por iteração, registro para acompanha-
mento dos problemas e mudanças necessárias no decorrer
do projeto e controle dos Releases do software desenvolvido
integrado com os planos de iteração. Suas funcionalidades
são baseadas nos métodos Scrum, XP (eXtreme Programming),
DSDM (Dynamic Systems Development Method) e Agile Up.
Por serem soluções que visam o mesmo propósito desse
trabalho, julgou-se que seria fundamental uma análise
pormenorizada desses softwares. Portanto, optou-se por
realizar uma avaliação específica, a partir do contato com o
próprio sistema, indo além da documentação. Essa análise
é apresentada na seção “Softwares para gerenciamento ágil
de projetos”.
Softwares de código aberto
Os softwares de código aberto disponíveis no mercado são
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 código aberto e encontraram mais de
50 softwares. O método empregou as seguintes etapas:
1) Análise da ferramenta MSProject 2002 e Primavera para a
elaboração dos critérios de análise das funcionalidades;
2) Criação dos critérios de análise das funcionalidades do
GP, gerando uma lista com 58 critérios, divididos em nove
categorias;
3) Depois de uma primeira seleção dos softwares disponíveis,
que descartou as ferramentas com funcionalidades específicas
ou com graves limitações, obteve-se uma lista com 25 softwares.
Utilizando-se consultas a duas listas de discussões 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 critérios;
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 pontuação
na análise, em relação à sua aplicação nas empresas de base
tecnológica, encontra-se em nível de sofisticação bem inferior
à dos softwares proprietários utilizados como base para os
critérios. Desta forma tem-se um panorama onde as ferramen-
tas de código aberto apresentam deficiências e não possuem
maturidade suficiente para sua utilização direta, sem imple-
mentações de novas funcionalidades (RORIZ, JUCÁ JUNIOR
e AMARAL, 2005).
Softwares para gerenciamento ágil de projetos
A literatura não contempla propostas de softwares para
apoiar o gerenciamento ágil de projetos. Porém, foram en-
contradas soluções voltadas para esse enfoque. As buscas na
internet e em grupos sobre APM (Agile Project Management)
identificaram três sistemas comerciais. Todos são específicos
para o gerenciamento de projetos de desenvolvimento de
softwares. As ferramentas encontradas são de código fecha-
do, comercializadas por meio de licenças, mas possuem uma
versão Trial, para teste de 30 dias, as quais foram utilizadas
para efeito de avaliação.
Os software avaliados, com seus respectivos sites, foram:
• VersionOne – www.versionone.com;
• Target – www.targetprocess.com;
• Rally – www.rallydev.com.
As impressões e diferenças em relação aos sistemas tradicio-
nais, comparadas segundo as funcionalidades apresentadas na
seção “Definição e funcionalidades dos softwares de gerencia-
mento de projetos”, foram coletadas e registradas.
As principais diferenças em relação às funcionalidades tra-
dicionais são as seguintes:
• Utilizam como principal idéia um planejamento inicial sim-
plificado (Workitem Planning) e iterações (Sprints) dentro do
projeto. Dentro de cada iteração são registradas as entregas que
devem ser realizadas e seu prazo. A Figura 2 é um exemplo
da visão geral do processo de desenvolvimento do projeto,
utilizado no software VersionOne. A representação mostra
desde o planejamento do projeto até o andamento das iterações.
É possível observar na figura que esse software não segue
o mesmo padrão e as funcionalidades típicas dos softwares

  TUTOS PHProjekt PHPcollab Dotproject Planner Open Workbench

Banco de dados 100% 100% 100% 90% 25% 5%
Calendário e agenda 23% 13% 3% 13% 37% 37%
Gestão de atividades 38% 36% 30% 42% 46% 64%
Gestão de recursos 36% 32% 10% 14% 22% 32%
Gestão de custos 30% 10% 0% 10% 15% 55%
Gestão de documentos relatórios e impressão 33% 40% 27% 27% 27% 33%
Ferramentas de monitoramento 10% 3% 10% 10% 3% 50%
Gestão de múltiplos projetos 4% 4% 4% 4% 0% 36%
Ferramentas de comunicação e integração 38% 65% 75% 65% 3% 13%
Tabela 1. Avaliação dos softwares de código aberto (Fonte: Roriz, Jucá Junior e Amaral (2005)

Edição 19 - Engenharia de Software Magazine 19

de gerenciamento clássico de projetos. Os demais softwares
analisados seguem padrões similares. Cada entrega pode ser
detalhada em subentregas, que também 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 painéis de controle, chamado nesses softwares de

Dashboard. Trata-se de relatórios resumidos que proporcionam
uma visão geral do projeto. Os relatórios apresentados nesses
softwares contêm informações similares como próximas
atividades a serem desenvolvidas e últimas mudanças 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 gráfico de Gantt não é utilizado, mas existem
outras ferramentas para acompanhamento visual do andamen-
to do projeto, como status de cada iteração, entrega, subentrega,
e relatórios “Burndown”, isto é, que descrevem o progresso de
uma equipe e o denominado “Roadmap”, relacionado ao escopo
do projeto e suas mudanças ao longo do projeto. A Figura 3
demonstra um relatório do tipo “Burndown” nas iterações do
software Rally.

Figura 5. Tela do software Target – Dashboard

(Fonte: www.targetprocess.com)

• Possuem também área para guardar as retrospectivas,

Figura 3. Tela do software Rally – relatório Burndown (Fonte: www.
rallydev.com)
• Outra funcionalidade existente é o registro das ações neces-
sárias para as próximas entregas, como correções de problemas
(Defects). O registro de problemas é feito da mesma forma que
uma entrega, relatando o problema a ser resolvido, e é associado
a uma iteração dentro do projeto. A Figura 4 do software Rally
demonstra o registro de problemas, Defects. Nota-se que não é
muito diferente de um relatório de issues (problemas) nos SGPs
tradicionais, a não ser pela relação cada uma das entregas.
que seriam as lições aprendidas, além das análises das
estimativas iniciais do projeto.
• Nos softwares voltados para o enfoque ágil de gerenciamento
de projetos, todas as mudanças de escopo são gerenciadas e po-
dem ser analisadas em relatórios, permitindo aos colaboradores
acompanhar as alterações do projeto. A diferença dos softwares
tradicionais é que os relatórios, além de indicarem as mudanças
de escopo, indicam também as tendências 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

 Gerência de Projetos

Desafios Fonte
serem adaptadas ao desenvolvimento de produtos.
Dessa forma, seria possível a criação de um software Falta de informação sobre o que as outras equipes do Hameri e Puittinen (2003)
para gerenciamento de projetos de desenvolvimento projeto estão fazendo (progresso das tarefas)
de produtos utilizando-se o enfoque ágil. Falha no controle de mudança do projeto Hameri e Puittinen (2003)
Visões diferentes sobre os objetivos do projeto Hameri e Puittinen (2003); Barnes, Pashby e Gibbons (2006)
Conclusão - Síntese dos softwares de GP frente Rigidez no planejamento do projeto e das rotinas Hameri e Puittinen (2003)
à colaboração e agilidade Reações“pobres”em relação às mudanças repentinas Hameri e Puittinen (2003)
Os primeiros softwares de gerenciamento de projetos no ambiente do projeto
foram concebidos no contexto de grandes projetos, Dificuldades tecnológicas inesperadas Hameri e Puittinen (2003)
com localização única. Um exemplo é um dos SGPs
Falha no controle de mudança do projeto Hameri e Puittinen (2003)
comerciais mais conhecidos, o Microsoft Project, que
teve sua primeira versão lançada em 1987. No decor- Falta de Responsabilidades claramente definidas Barnes, Pashby e Gibbons (2006)
rer desse período até hoje, esses softwares evoluíram Criação 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 seção “De- Falta de recursos adequados Barnes, Pashby e Gibbons (2006)
finição 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 comunicação 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, porém, na seção “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 níveis de inovação são dinâmicos e
incertos, com escopo impreciso e acontecem em cola-
boração com universidades, institutos de pesquisa ou
outras empresas fornecedoras e clientes – organizações
com características significativamente distintas. Essa
realidade é bastante diferente do contexto no qual os
primeiros SGPs foram concebidos, conforme constata-
do por vários autores da revisão bibliográfica. Como
resultado, há uma série de problemas específicos e
desafios, apresentados na Tabela 2.
Também no artigo Desafios para o gerenciamento
ágil de projetos colaborativos, na seção Desafios do
gerenciamento de projetos e o gerenciamento ágil de
projetos, demonstrou-se que há novas tendências 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 métodos e ferramentas
existentes, que denominam usualmente de Geren-
ciamento de Projetos Clássico, não responderiam às
necessidades das organizações que convivem nesse
novo cenário. Seria preciso desenvolver métodos e
técnicas que fossem capazes de atender aos seguintes
desafios:
• Adequar-se às mudanças dos projetos;
• Apoiar o acompanhamento e alterações no resultado
final;
• Compartilhar recursos entre projetos;
• Consumir pouco tempo com documentação;
• Empregar os princípios do gerenciamento ágil.

A revisão bibliográfica demonstrou a inexistência

de estudos empíricos com avaliações de problemas no

Edição 19 - Engenharia de Software Magazine 21

uso de SGPs existentes, em casos de projetos reais e segundo
a perspectiva dos usuários. Há trabalhos correlatos, que des-
crevem a aplicação de uma solução específica ou que, entre
outras questões, abordam também o aspecto SGP. Apesar
da quantidade pequena, eles indicam que há ineficiências 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
experiências reais de gerenciamento de projetos. O questionário
foi desenvolvido para identificar os métodos, ferramentas e técni-
cas em uso atualmente, e estabelecer uma lista de fatores críticos
de sucesso em gerenciamento de projetos. Foram escolhidos
995 gerentes de projetos, que representavam 620 organizações
diferentes, tanto do setor público como do privado. Do total de
questionários 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 limitações entre os métodos/ferramentas/técnicas do
gerenciamento de projetos. A explicação apresentada é que
esses softwares seriam inadequados às necessidades das empresas,
principalmente para projetos complexos. As autoras chamam de
complexo um projeto onde várias organizações 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 apóiem
o compartilhamento de recursos e informações segundo as ne-
cessidades desses tipos de projeto.
Bergman e Baker (2000) afirmam que as soluções para o com-
partilhamento dos dados de projetos utilizadas nas empresas,
na época do estudo, eram ferramentas ou família de ferramentas
simples de escritório, como o MS-Office. Segundo os autores, elas
são insuficientes para engenheiros, porque eles usam muitas
ferramentas diferentes e diversas plataformas computacionais.
Liu (2003) propõe uma arquitetura para integrar os diferentes
sistemas utilizados pelas empresas para ajudar no gerenciamento
de seus projetos, convertendo informações de um sistema para
o outro.
Ren et al. (2006), baseados na experiência de proposição de uma
solução específica para gerenciamento de projetos colaborativos,
afirmam que uma nova geração de ferramentas de planejamento
de projetos colaborativos precisa ser construída. Seu estudo é di-
recionado para as parcerias de pequenas e médias empresas, e o
modelo apresentado foca na preparação e planejamento dos proje-
tos colaborativos. Segundo Woerner e Woern (2005), a maioria das
plataformas de colaboração possui uma arquitetura centralizada
e focada nas fases de desenvolvimento de novos produtos e novos
processos de produção. Esse é um aspecto inadequado quando
se trata de colaboração em pequenas e médias empresas, onde o
controle sobre os dados é um critério 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 documentação 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 execução e torna-o
mais burocrático.
Portanto, os problemas enfrentados no gerenciamento de pro-
jetos colaborativos pelas empresas são:
• Falta de recursos que apóiem o acompanhamento e alterações
constantes no resultado final, isto é, no produto do projeto;
• Falta de compartilhamento efetivo de recursos, já que os sof-
twares tradicionais centralizam as informações em um lugar e
não permitem que cada empresa tenha seus dados em formatos
distintos;
• Falta de um modelo capaz de adequar-se às mudanças dos
projetos;
• Consumo de tempo em extensa documentação do projeto.
Portanto, os trabalhos citados, que avaliam casos reais de SGPs,
reforçam ainda mais a necessidade de avanço nas soluções. Nota-
se também que os problemas são especialmente maiores no caso
de projetos de alta complexidade e alto grau de inovação. Esses
problemas seguem na mesma linha das críticas do gerenciamento
de projetos tradicional.
Ao analisarmos as mudanças em desenvolvimento atualmente
nos softwares de gerenciamento de projetos, é possível identificar
preocupações semelhantes. O levantamento realizado na seção
“Softwares de código fechado” demonstra que os sistemas mais
inovadores estão incorporando:
• Funcionalidades de colaboração integradas com as funcionali-
dades de gerenciamento de projetos;
• Funcionalidades para acompanhamento contínuo das mudan-
ças no produto;
• Funcionalidades para apoio na elaboração de relatório de con-
troles e acompanhamentos mais sofisticados.
A análise dos SGPs existentes identificou também o surgimento
de sistemas que se propõem especificamente ao Gerenciamento
de Projetos segundo o modelo do Gerenciamento Ágil. As novas
ferramentas englobam, de forma geral, o cadastro dos projetos,
suas iterações e as entregas programadas para cada iteração,
com acompanhamento dos problemas e mudanças necessárias
ao decorrer do projeto e controle dos Releases do software desen-
volvido. Suas funcionalidades são baseadas nos métodos Scrum,
XP (eXtreme Programming), DSDM (Dynamic Systems Development
Method) e Agile Up.
Os resultados obtidos demonstram uma coerência entre os
problemas identificados no gerenciamento colaborativo de
projetos, as tendências de melhoria das técnicas e métodos de
GP e as inovações em funcionalidades dos SGPs. A Figura 6
demonstra a relação.
Portanto, os desafios para a evolução de SGPs envolvem os
seguintes aspectos:
• Desenvolver ambientes customizados para cada projeto com
funcionalidades que privilegiem a visão do produto final, isto
é, a agregação de valor;
• Criar sistemas que explorem planos baseados em entregas e
iterações, e que sejam mais “visuais”;
 Gerência de Projetos

• Criar funcionalidades que facilitem as alterações constantes no

produto e gerem informações “realistas” e em tempo real sobre
o andamento do projeto;
• Apoiar a colaboração, com ferramentas e funcionalidades que
facilitem a troca rápida de informações, garantindo também a
privacidade das partes interessadas;
• Utilizar plataformas heterogêneas (promovendo a descentralização
da informação e permitindo inclusive que diferentes equipes pos-
sam utilizar sistemas distintos conforme sua conveniência).

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

eu

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

sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
Dê seu voto sobre este artigo, através do link:

Figura 6. Desafios para os SGPs Colaborativos (Fonte: elaborada pela autora) www.devmedia.com.br/esmag/feedback

Referências

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. 395–404,
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. Disponível em <http://www.borland.com/br/products/tempo/index.html>. Acesso em
27 fev 2008.
DOTPROJECT. Disponível em < http://www.dotproject.net/ >. Acesso em 10 jul 2008.
EPROJECT. Disponível em < http://www.eproject.com/>. Acesso em 27 fev 2008.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Mass.: Project
Management Institute, Inc, 2004.
POWERSTEERING. Disponível em <http://www.powersteeringsoftware.com>. Acesso em 27 fev 2008.
PRIMAVERA. Disponível em <http://www.primavera.com/index.asp >. Acesso em 27 fev 2008.
REIS, C. R. Caracterização do modelo de processo para projetos de software livre. Dissertação
(Mestrado em Computação e Matemática Computacional). Instituto de Ciências Matemáticas e de
Computação – Universidade de São Paulo, São 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.

GARTNER GROUP. Magic Quadrant for IT Project and Portfolio Management. 2007. RORIZ, J. H. R.; JUCÁ JUNIOR, A. S.; AMARAL, D. C. Avaliação de ferramentas de gestão de projetos de
código aberto.. In: 12º Simpósio Internacional de Iniciação Científica, 2004, São Paulo. Resumos....
HAMERI, A. PUITTINEN, R. WWW-enabled knowledge management for distributed engineering
São Paulo : USP, 2004.
projects. Computers in Industry, vol. 50, n. 2, p. 165-177, fevereiro, 2003.
ROZENFELD, H. et al. Gestão de desenvolvimento de produtos: uma abordagem por processos. São
ITM. Disponível em < http://itm-software.com/products/ppm.shtml>. Acesso em 27 fev 2008.
Paulo: Saraiva, 2006.
LI, H. et al. Co-operative benchmarking: a tool for partnering excellence in construction. International
SCIFORMA. Disponível em < http://www.sciforma.com/us/home/index.jsp>. Acesso em 27 fev 2008.
Journal of Project Management, v.19, n. 3, p. 171-179, abril, 2001.
SERENA. Disponível em <http://www.serena.com/products/mariner/index.html>. Acesso em
LIU, D. et al. Composition of engineering web services with distributed data-flows and computations.
27 fev 2008.
Advanced Engineering Informatics, v.19, n. 1, p. 25–42, Janeiro, 2005.
TUTOS. Disponível em <http://www.tutos.org/homepage/index.html>. Acesso em 10 jul 2008.
LIU, W. D. A Distributed Data Flow Model for Composing Software Services. Tese (Doutorado em
Filosofia) – Stanford University, 2003. VOROPAJEV, V.; SCHEINBERG, M. Project-management methods and tools for the 21st century: the

MICROSOFT. Disponível 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. Disponível em < http://www.openworkbench.org/>. Acesso em 10 jul 2008.
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. Disponível em < http://pt.wikipedia.org/wiki/P%C3%A1gina_principal >. Acesso em
05 março 2008.

PHPCOLLAB. Disponível em < http://www.php-collab.com/blog/ >. Acesso em 10 jul 2008.
PHPROJEKT. Disponível em < http://www.phprojekt.com/index.php > . Acesso em 10 jul 2008.
PLANNER. Disponível em < http://live.gnome.org/Planner>. Acesso em 10 jul 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.

Edição 19 - Engenharia de Software Magazine 23

 Arquitetura Orientada a Serviços
Aspectos de Modelagem de Negócios
Anderson Dias Ribeiro
(andersondr@gmail.com)
É formado em Tecnologia em Informática In-
dustrial e pós-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 serviços à MRS Logística 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 experiência em aplicações Win32.
Graduado em Informática pela UFJF, com
Especialização em Desenvolvimento de Apli-
cações para Web pelo CES de Juiz de Fora/
MG, e Mestrado em Computação pela UFF/
Niterói-RJ. Atualmente é professor univer-
sitário em diversas instituições, em cursos
de Sistemas de Informação, e atua como
consultor, pesquisador e desenvolvedor de
aplicações Java, sobretudo na plataforma
J2EE para Web, e J2ME, sendo especialista
em aplicações Mobile.
24 Engenharia de Software Magazine - Arquitetura Orientada a Serviços
De que se trata o artigo?
• Conceito de Arquitetura Orientada a Serviços (SOA
- Service Oriented Architecture);
• Vantagens da utilização de SOA nos aspectos ge-
renciais de TI;
• Tecnologias e características para modelagem de
processos de negócios em SOA, voltados para Web
Services;
• Descreve as principais características 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 negócios numa ar-
quitetura SOA;
S
ervice Oriented Architecture (SOA)
tenta aproximar o entendimento
entre as áreas de tecnologia de in-
formação (TI) e de negócios a uma visão
mais semelhante de como um sistema de
informação deve ser abordado.
A abordagem voltada a serviços propõe
uma solução mais próxima dos processos
• Utilizar novas metodologias e técnicas aplicadas
ao gerenciamento de negócios, 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 situação o tema é útil?
• Na administração dos processos de negócios em
áreas de TI;
• Tornar possível a orquestração de serviços, ou seja,
de Web Services, possibilitando a interação entre as
várias etapas do fluxo, de forma gráfica;
• O uso de novas tecnologias de projeto e desenvol-
vimento de software aliadas ao mapeamento de
processos das empresas, facilitando a produção e
manutenção de uma solução baseada na Web.
de negócio, uma vez que se tem um fluxo
de execução montado a partir de peças
ou unidades bem definidas que execu-
tam determinada funcionalidade. Sendo
assim, uma unidade demanda, como pré-
requisito, informações na entrada e, neces-
sariamente, criará algo modificado como
resultado do sucesso de sua execução.

SOA propõe que se faça a modelagem de um processo,
não 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 execução 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 serviço.
Mais que uma simples proposta de modelagem ou resolução
de problemas computacionais, SOA é uma arquitetura de TI
e, como tal, define cada componente como um serviço geren-
ciável, sendo que cada serviço deve possuir um ciclo de vida
próprio, os quais, também, devem possuir aspectos funcionais
e de qualidade mensuráveis.
Podemos notar que uma arquitetura SOA é mais que um
sistema, pois envolve uma abordagem e dita o modo como
um sistema de informação será modelado. O importante é
saber que podemos montar soluções baseadas em serviços
e workflow com tecnologias bastante variadas, desde que
sejam respeitados os aspectos arquiteturais de serviços e os
processos de negócio.
A arquitetura orientada a serviços trata-se de um modelo,
em que as funcionalidades ou serviços são totalmente desa-
coplados e independentes, buscando atender às mais diversas
tarefas e, ainda, podem ser reutilizados nos mais diferentes
tipos de domínios de negócios demandados pelo mercado
coorporativo.
Esses mesmos serviços são publicáveis, de tal forma que
possam ter suas interfaces acessíveis por meio de mecanismos
de localização e, também, são descritos por meio de uma lin-
guagem totalmente independente da plataforma utilizada.
Já no ponto de vista do negócio, SOA se apresenta como
uma solução de maior flexibilidade, permitindo que as mais
diversas demandas do mercado sejam absorvidas e atendidas
pela empresa com agilidade e eficiência.
Questões que envolvem aspectos como segurança, benefícios
e recomendações sobre implantação, dentre outros, não serão
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 decisão de se adotar a arquitetura
SOA em detrimento às demais existentes no mercado.
Modelagem de Processos na Arquitetura SOA
As tecnologias descritas a seguir, não somente buscam uma
aproximação de modo a permitir que haja uma maior comuni-
cação entre as áreas de negócio e TI, mas também de forma que
partes de um sistema possam ser criadas ou gerenciadas fora
do ambiente de TI pelos próprios profissionais de negócio, tor-
nando esta relação de proximidade cada vez mais estreita.
BPM (Business Process Management)
BPM pode ser definido como uma disciplina de gerência
focada na melhora do desempenho corporativo através da
projeto
gestão dos processos de negócio da empresa. BPM é a forma
de se atingir os objetivos de uma organização através do
aperfeiçoamento, gestão e controle dos processos essenciais
do negócio (PEREIRA, 2007).
Os grandes institutos de pesquisa estão validando essa visão.
O Gartner aponta projetos de BPM como os de maior ROI (Re-
turn On Investiment) em TI, e o Forrester Research anunciou
um novo acrônimo, IC-BPMS (Integration Centric BPMS), como
um novo modelo de desenvolvimento de aplicações.
BPMS (Business Process Management Suite)
BPMS é um sistema que automatiza a gestão por proces-
sos (execução, controle e monitoração). Tipicamente, inclui
o mapeamento dos processos ponta a ponta, desenho dos
fluxos e formulários eletrônicos, definição de workflow,
regras de negócio, integradores, monitoração em tempo
real das atividades e alertas. É uma poderosa ferramenta
de gestão, para garantir que os processos estão sendo efe-
tivamente executados como modelados, contribuindo para
os objetivos da organização.
Ilustramos na Figura 1 os elementos que compõem um sis-
tema BPMS, de acordo com Glauco Reis (2007).
Figura 1. Componentes de um BPMS
A figura em forma de um pentágono ilustra em seus cinco
vértices, os principais componentes de um sistema BPMS, como
o BPMN, ferramenta responsável pelo desenho dos processos
de negócio; o BPEL4WS que se destina a orquestração destes
serviços, de forma a organizá-los melhor; a arquitetura SOA,
que busca de forma padronizada a componentização dos ser-
viços; 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 negócio
que englobe uma solução BPMS, torna-se necessário a ob-
servância de alguns pontos de suma importância, tais como
mencionados a seguir. Um BPMS completo teria os seguintes
módulos ou funcionalidades para ser classificado como tal
(Ghalimi, 2006):
Edição 19 - Engenharia de Software Magazine 25
• Funcionalidades mínimas 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 execução do processo; que darão origem aos nossos diagramas, como Atividades,
• Orquestração de web services; Eventos, Condicionais e Ligações. Esses elementos podem ser
• Interface de workflow para usuários. subdivididos em categorias, tais como são apresentadas pelo
software livre Editor BPMN (Portal BPM, 2008) para desenho
• Funcionalidades intermediárias de modelos BPMN, apresentados a seguir.
• Suporte para regras de negócio complexas;
• Business Activity Monitoring (BAM); 1. Atividades
• Controle de versão dos documentos anexados a instân- As atividades são representadas por retângulos 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);
• Repositório de metadados;
• Uma suite de business intelligence.

BPMN (Business Process Modeling Notation)

O BPMN é uma tecnologia gráfica para construção de mo-
delos destinados a representar os processos de negócio da
empresa, que serão abordados e exemplificados a seguir.
Enquanto o BPEL é um formato binário para execução de
serviços em seqüência, o BPMN é a notação gráfica que permite
representar como os serviços irão interagir.
O BPMN define os símbolos e como estes devem ser conec-
tados para gerar modelos representativos. Por outro lado, ele
não define formatos de arquivos nem mesmo características
particulares de ambientes de execução. Trata-se de uma no-
tação visual para representação de fluxos de processos que
pode ser mapeada para diversos formatos de execução, como
BPML e BPEL. Em uma analogia com a orientação a objetos, o
BPMN seria como a UML (Unified Modeling Language), que
define elementos gráficos para representar objetos e classes, Figura 2. Componentes do diagrama BPMN - Atividades
como também sua interação. Da mesma forma que a UML, o
BPMN não define formatos de armazenamento nem elemen- 2. Eventos
tos programáticos relacionados à implementação, como por Eventos indicam acontecimentos que, de alguma forma, po-
exemplo, as rotinas. Por outro lado, a especificação é completa o dem alterar a seqüência de execução em um fluxo, sendo que
suficiente para permitir a representação de fluxos de processo iniciar ou terminar a realização de um processo são exemplos
pelas áreas de negócio, com detalhamento bem próximo das de eventos, conforme a Figura 3.
complexidades de um ambiente real, além de ter elementos
que se aproximam de mecanismos de execução.

Diagramas
Observamos também que a notação do BPMN se assemelha
bastante a de alguns diagramas da UML, como os diagramas
de atividades – que também podem ser comparados aos
fluxogramas. Também é 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 questão, de alguma forma, possa
ser mapeado para um formato de execução, tal como o próprio
BPEL ou BPML.
O objetivo da notação BPMN é criar modelos gráficos de
alto nível, visando uma proximidade maior à realidade dos
analistas de negócio. Os elementos gráficos permitem desde Figura 3. Componentes do diagrama BPMN - Eventos

26 Engenharia de Software Magazine - Arquitetura Orientada a Serviços


3. Condicionais
Os losangos indicam tanto pontos em que o fluxo pode
divergir ou convergir, como pontos de tomada de decisão,
conforme a Figura 4.
Figura 4. Componentes do diagrama BPMN - Condicionais
4. Ligações
A seqüência em que os elementos são 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 - Ligações
5. Dados e Outros
Os elementos de dados fornecem informações a serem
compartilhadas entre várias atividades em um fluxo. Dados
como valores de cartões de crédito, carrinhos de compras po-
dem ser, por exemplo, indicados por essa notação, conforme
a Figura 6.
Figura 6. Componentes do diagrama BPMN - Dados
Os diagramas podem ser representados de diversas maneiras,
desde uma visão mais superficial, ou de alto nível, até uma
representação minuciosa de um processo.
Conforme a notação BPMN, exemplificamos um tipo de
diagrama de “Processo de negócio privado”, quando se está
interessado no detalhe. Neste diagrama, pode-se visualizar
um “pedaço” de um processo sem se importar com seu modo
de contextualização em relação ao restante do processo.
Podemos observar esta característica 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 representação, não importa
quem está envolvido com a tarefa nem quais outras atividades
foram ou serão executadas.
BPEL (Business Process Execution Language) –
Orquestração
BPEL (Business Process Execution Language) é uma lin-
guagem baseada em XML para a especificação formal dos
processos empresariais e de negócios.
BPEL alarga o modelo de interação e serviços Web que lhe
permite apoiar as operações comerciais. É o resultado de uma
iniciativa cruzada entre IBM, BEA e Microsoft para desenvolver
um processo universalmente relacionado com a linguagem
suportada.
Na programação tradicional, a execução de serviços de ma-
neira coordenada se faz mediante a criação de códigos que se
conectam aos objetos. Esses códigos obtêm informações e as
repassam a outros objetos. Um programa orientado a objetos
é exatamente isso, uma seqüência de objetos se comunicando
e passando informações uns aos outros.
A proposta do BPEL ou BPEL4WS é executar serviços em
seqüência, mas por meio de um mecanismo não programáti-
co, reduzindo custos de manutenção causados por alterações
freqüentes nos códigos. Sua versão inicial foi liberada em 2002,
exatamente como proposta para a execução de serviços Web
em seqüência.
O caminho adotado foi o de arquivos XML que descrevem
como os serviços se comunicam, definindo-se mecanismos
para armazenar informações de forma não programática, 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 código XML, que executam atividades como
se fosse um programa, mas de manutenção facilitada, já que
apenas esses XML são afetados nessa atividade. Não utilizar
tecnologias programáticas nos traz o benefício de se ter ferra-
mentas de criação gráfica mais simples, que podem ser geridas
e até mesmo mantidas pelas áreas de negócio.
É relevante dizer que o BPEL orquestra apenas Web Services.
Se o mecanismo adotado para realizar a comunicação entre os
serviços não for um Web Service, o BPEL se torna inaplicável,
o que não é este caso, pois este artigo se baseia totalmente na
tecnologia de Web Services.
Edição 19 - Engenharia de Software Magazine 27
 Desta forma, diríamos que o BPEL torna uniformes vários
paradigmas da TI, traduzindo-os em Web Services. Por outro
lado, em função das suas características, não é interessante
a sua utilização em aplicações que demandam a troca de
documentos e nem em aplicações que geram muita interação
humana.
Quando for utilizada alguma ferramenta visual com nota-
ção BPMN, alguns elementos gráficos como eventos gerados
por dados não terão mapeamento direto para o BPEL, sendo
normalmente disponibilizados por serviços de execução. O
início de uma atividade causado pela alteração no valor de uma
cotação, por exemplo, precisa ser codificado como elemento
programático e disponibilizado como Web Service.
O BPEL ainda não define nada relacionado às telas de
interação com o usuário. Isso significa que, se a ferramenta
de desenho estiver gerando BPEL, serão necessários outros
artefatos para que se tenha condições de operacionalizar o
processo da forma esperada.
A característica de orquestrar apenas Web Services, peculiar
ao BPEL, tornam necessários estudos no intuito de identificar
se os elementos programáticos do legado da empresa, necessá-
rios à operacionalização do fluxo, proporcionam a capacidade
de se tornar Web Services.
Estudo de Caso
Pretendemos neste estudo de caso utilizar novas metodo-
logias e técnicas aplicadas ao gerenciamento de negócios,
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 produção e manutenção de uma solução
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 manutenção.
Este estudo de caso consiste na elaboração 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 solicitação do aplicativo já foi feita aos
Web Services disponibilizados, os quais irão se comunicar com
os fluxos BPEL, que por sua vez irão executar todas as regras
de negócio, conforme exemplificado nos diagramas a seguir.
Ferramentas utilizadas
Para a confecção deste trabalho foi necessária a utilização de
um aparato de tecnologias voltadas ao BPM e SOA. Optamos
por utilizar as ferramentas da Oracle, devido à grande capa-
cidade de integração 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 Serviços
Como servidor de Banco de Dados utilizamos o Oracle
10g; alem do servidor de aplicações Oracle Application
Server e BPEL Control; para manipulação do BPEL uti-
lizamos o JDeveloper e, finalmente, para a criação dos
diagramas BPMN e conversão para o BPEL, a ferramenta
BPA (Oracle Business Process Architect). Todas as ferra-
mentas citadas podem ser encontradas em Oracle SOA
Suite (2009).
Com relação às licenças de uso das ferramentas Oracle
SOA Suite, as mesmas podem ser obtidas com licença trial
de acordo com OTN License Agreement (2009), a qual foi
utilizada para o desenvolvimento deste estudo.
Necessidades do Negócio
Nosso contexto compreende uma empresa do ramo de
eletrônicos, a qual disponibiliza, através da Internet, seus
produtos e serviços, os quais podem ser contratados por
meio de solicitações enviadas pela Web, utilizando-se o
computador ou mesmo um dispositivo móvel, 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 fictícia, a qual denomi-
namos de M-Eletronics, com o objetivo de modernizar
seus negócios e expandir suas fronteiras, além de estar
buscando novas tecnologias que a possibilitem alçar
novos mercados.
Desta forma, a empresa tem uma expectativa em médio
prazo, de poder alcançar 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 confiáveis tarefas
que anteriormente eram executadas manualmente, sem
desprezar a intervenção humana quando necessária.
Os principais requisitos são:
1. O Sistema deve receber o pedido através de um arquivo
XML contendo as informações do mesmo;
2. O Sistema deve processar o arquivo XML, extraindo
as informações 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 cartão de crédito
do cliente;
7. O Sistema deve efetivar o pedido caso todas as infor-
mações necessárias sejam validadas;
8. O Sistema deve dar baixa em estoque da quantidade
do produto comprado.

Como regras de negócio, podemos definir:
• A partir de uma aplicação executada em um dispositivo móvel,
será repassado para o BPEL, no formato XML, o id do cliente e
uma coleção com os ids dos produtos selecionados, também o
número do cartão de crédito do cliente;
• O pedido é armazenado e controlado em banco de dados pelo
próprio BPEL, que mantém o estado de cada solicitação realiza-
da, e ainda as persiste em Banco de Dados, sem nenhuma inter-
ferência humana. Para o objeto em questão, optamos por utilizar
um BPEL assíncrono, pois algumas etapas do fluxo, como por
exemplo, a “validação de cartão de crédito”, eventualmente
pode estar fora de operação e, desta forma, o processo ficaria
aguardando uma resposta, até que o serviço se restabeleça;
• São recuperados todos os dados do cliente como, por exemplo,
o endereço de entrega;
• Os produtos são debitados em estoque;
• É efetuado o débito no cartão de crédito do cliente;
• Em caso de erro na operação, como falta de crédito disponível
no cartão, por exemplo, os produtos são retornados para estoque
novamente.
Arquitetura do Projeto
Este projeto BPM tem como objetivo receber uma requisição
de compra, disparada por meio de qualquer dispositivo com-
putacional que ofereça suporte à linguagem XML. Neste estudo
de caso, iremos enfatizar uma requisição enviada por meio de
um dispositivo móvel, conforme a Figura 8.
Figura 8. Arquitetura do Projeto BPM
Vale ressaltar, ainda, a importância da utilização de uma
arquitetura baseada no Enterprise Service Bus - ESB, que tem a
funcionalidade de melhorar o acoplamento, fazendo a função
de um roteador das informações que por ali trafegam.
Desta forma, caso o sistema evolua sofrendo modificações,
que é um fato normal, haverá necessidade de mudanças nos
processos em BPEL. Sendo assim, bastará apenas alterarmos o
ESB de entrada. O mesmo fato ocorrerá com o serviço dos Cor-
reios, por exemplo, caso a empresa passe a negociar com uma
outra transportadora, o BPEL não precisa ser alterado.
projeto
Modelagem BPMN
No diagrama BPMN da Figura 9 demonstramos graficamente
o fluxo no qual se enquadra nosso processo de negócio.
Os elementos apresentados no gráfico demonstram de for-
ma clara e objetiva as ligações entre as atividades, eventos e
condicionais existentes em um processo de realização de um
pedido no que se refere ao negócio da empresa.
Figura 9. Diagrama BPM
Na seqüência, detalharemos melhor as atividades que en-
volvem o processo de negócio de um pedido, na concepção
de nosso estudo de caso.
Após o início do fluxo, foi criada uma atividade Criar Pedido,
responsável 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 Informações de Credito, que
tem o objetivo de recuperar o número do cartão de crédito
do cliente e verificar o status do mesmo, ou seja, se o cartão é
válido e se o saldo é suficiente para realizar aquela operação.
Em seguida, a atividade Aprovar Pedido deve fazer a apro-
vação 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 operações 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, não será
necessário descrever novamente passo a passo a sua execução,
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 funções, quase idêntico
ao diagrama BPMN, diferindo apenas na representação gráfica e
Edição 19 - Engenharia de Software Magazine 29
nas interfaces com os serviços disponíveis. Um segundo diagrama
BPEL poderia ser feito para demonstrar, detalhadamente, todas
as funcionalidades desempenhadas pelo fluxo, bem como os
tratamentos de exceção e suas interfaces com os serviços. Porém
procuramos não estender demasiadamente este estudo de caso,
optando por não incluí-los.

Figura 11. Detalhe do Escopo Criar_Pedido

Figura 10. Diagrama BPEL

Descrição do Escopo “Criar_Pedido”

Detalharemos a seguir, um dos principais escopos do nosso
diagrama BPEL, “Criar_Pedido”, conforme indicado pelo próprio
nome, o qual é o responsável pela efetivação do pedido recebido
pelo BPEL, apresentado na Figura 11.
Os seguintes passos são observados:
1º passo - O BPEL solicita ao serviço “PedidoSequencia”, que
retorna um número sequencial do pedido referente ao pedido
em questão;
2º passo - O BPEL irá definir as diversas variáveis 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 através do serviço
“InserirPedido” e, ainda, dar baixa no estoque caso o pedido a opção “Variable” e expandimos o escopo “CriarPedido”. Em
seja concluído. “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 saída, à direita, conforme a árvore Variable > inputVariable >
e saídas necessárias no mapeamento dos arquivos XML a serem payload > client > PurchaseOrder > ID.
gerados. Por exemplo, no escopo Criar_Pedido, podemos trans- Através da próxima interface, podemos observar que será de-
ferir um determinado conteúdo de entrada de uma variável para finido o status do nosso pedido para “Pendente”, atribuído em
sua saída. Definimos, desta forma, um status “Pendente” para a forma de String ao selecionarmos o Type Expression, conforme
variável de controle do status “AssignStatusOrdem”, conforme a Figura 14. Desta forma, a String “Pendente” será atribuída à
a Figura 12. variável OrderStatus.
Executando um duplo clique sobre a variável em questão, será Após a execução 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 recuperação 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 Serviços

 projeto

Figura 13. Tela Copy Operation do JDeveloper

Figura 14. Tela Copy Operation do JDeveloper (continuação)

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”/>

Edição 19 - Engenharia de Software Magazine 31

Considerações Finais Referências Bibliográficas
A aproximação da área de TI com a área de negócios vem (GHALIMI, 2006) GHALIMI, Ismael C. BPM 2.0. In: Projeler. 2006. Disponível em: <http://www.
colaborar, de inúmeras maneiras, ao ambiente de uma or- projeler.com.br/artigos_bpm20.jsp>. Acesso em: 20 out. 2008
ganização. Dessa forma, o BPM, em conjunto com a arqui-
(Oracle SOA Suíte, 2009) Oracle SOA Suite.Oracle SOA Suite 10g Softwares Downloads.Disponível
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 dinâmicos e gerenciáveis.
Neste artigo, procuramos apresentar os principais con- (OTN, 2009) OTN. OTN License Agreement. Disponível 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 tópicos aqui levantados objetivam a serem
(PEREIRA, 2007) PEREIRA, Hélio. BPMS Brasil: algumas definições e conceitos. Disponível em:
mais um ponto de orientação 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.Disponível 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 implementação de uma solução completa
(REIS, 2007) REIS, Glauco. Introdução ao BPM, BPMS e SOA. Revista Portal BPM, ano I, n. 1, p.
SOA/BPM, sobretudo em relação às suas bases, as quais se
22-29-48. Bimestral/2007. Disponível em: <http://www.portalbpm.com.br>. Acesso em: 20
fundamentam nos padrões XML. A modelagem e imple-
ago. 2008.
mentação foram tratadas com o emprego de ferramentas
específicas onde, através destas, sugerimos uma alternativa
Dê seu feedback sobre esta edição! Feedback
extremamente viável 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 evolução. 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, através do link:
edição

do e detalhando o que foi apresentado neste trabalho.

www.devmedia.com.br/esmag/feedback

32 Engenharia de Software Magazine - Arquitetura Orientada a Serviços


Arquitetura REST
Uma alternativa para construção de Serviços Web
Lívia Ruback
liviaruback@gmail.com
Graduada em Ciência da Computação pela
Universidade Federal de Juiz de Fora.
Regina Braga
regina.braga@ufjf.edu.br
Regina Braga é professora adjunta do
departamento de Ciência da Computação
da Universidade Federal de Juiz de Fora.
Suas linhas de pesquisa principais são re-
lacionadas a reutilização de software, mais
especificamente com desenvolvimento ba-
seado em componentes (DBC). O Núcleo de
Pesquisa em Qualidade de Software, do qual
faz parte, atua principalmente em pesquisas
relacionadas a multidisciplinaridade, nota-
damente na área de software científico, que
tem sido seu foco de pesquisas atual (DBC e
software científico).
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 relação à arquitetura de serviços tradicional.
Para que serve?
O surgimento da Arquitetura de Web Services tornou
possível a interoperabilidade entre aplicações hetero-
gêneas através do acesso aos serviços, que podem ser
invocados remotamente. Essa forma tradicional de
uso de Web Services gera uma camada de abstração
acima do protocolo HTTP, pois as mensagens são tro-
N
os últ imos a nos, alg umas
alternativas surgiram para
melhorar o desempenho de
aplicações que acessam serviços remo-
tamente. Uma destas alternativas e a
que tem tido mais sucesso atualmente é
a arquitetura REST.
A utilização da arquitetura REST tem
tornado mais simples e eficientes muitas
aplicações que antes eram implementa-
das de maneira tradicional – baseadas
no protocolo SOAP.
As principais aplicações que se benefi-
ciam da utilização desta arquitetura são
aquelas nas quais cada requisição tem
Edição 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 conteúdo contido nas men-
sagens envelopadas pelo protocolo SOAP.
Em que situação o tema é útil?
No entanto, surgiram algumas alternativas que po-
dem melhorar o desempenho dessas aplicações. Uma
destas alternativas, e a que tem tido mais sucesso
atualmente, é a arquitetura REST.
um custo relativamente alto, como por
exemplo, serviços remotos acessados via
celular e PDA’s.
Arquitetura de Web Services
Antes de iniciarmos o estudo desta
nova abordagem de manipulação de Web
Services e demonstrar na prática 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
aplicações 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 serviços, conhecida como WSDL
(Web Services Description Language). Na prática, em sistemas
que seguem essa visão de Web Services, as mensagens de re-
quisição e resposta são “envelopadas” pelo protocolo SOAP e
os seus serviços são “descritos” em interfaces WSDL.
Porém, um grande problema tem sido observado por usu-
ários desse tipo de arquitetura: a perda de desempenho das
aplicações. O que acontece é que, ao utilizar o protocolo SOAP,
é gerada uma camada de abstração que envolve o protocolo
HTTP – quando na verdade ela não precisaria existir. Como
veremos mais adiante, a comunicação entre serviços pode ser
feita de maneira mais simples e eficiente utilizando somente
os recursos básicos da Web – XML e HTTP; e o melhor: sem
comprometer o desempenho! resposta das aplicações. Além disso, seu uso gera uma maior
Arquitetura REST
Antes de apresentarmos uma aplicação prática dos princípios
por trás da arquitetura REST e entender os seus objetivos e as
suas vantagens, precisamos entender alguns conceitos rela-
cionados ao paradigma, suas principais características e seus
elementos arquiteturais.
REST é uma abreviação de Representation State Transfer,
ou traduzindo, Transferência 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 prática os conceitos apresentados.
Origem arquitetural do paradigma
O paradigma REST foi criado no ano de 2000 por um cientista
da computação norte-americano e um dos principais criadores
da especificação HTTP, Roy Fielding. REST surgiu como um
estilo arquitetural híbrido, a partir da combinação de outros
Elemento Definição / Função
Conceito-chave da arquitetura REST.
Recursos Um recurso é qualquer informação que possa receber um nome.
Na prática, é tudo que possa ser armazenado em uma base de dados.
Identifica um recurso específico envolvido em uma interação entre clientes e servidores. Por exemplo,
Identificadores de Recursos
REST usa o URI (Unified Resource Identifier) como identificador de recursos.
As representações de um recurso são usadas para capturar o estado atual e o estado
Representações de Recursos desejado de um recurso solicitado.
Na prática, são seqüências 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 características
adicionais.
• As principais características arquiteturais incorporadas por
Fielding foram:
• Separação de responsabilidades entre as camadas cliente e
servidor;
• Comunicações independentes (stateless);
• Uso de cache (para eliminar algumas interações 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 características, quando
aplicadas ao desenvolvimento de Web Services, são capazes
de melhorar o desempenho geral do sistema – se comparadas
à utilização 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 organização” [2]. Esta definição
destaca a importância de conhecermos os elementos arquite-
turais de uma determinada arquitetura e suas inter-relações
para obtermos um entendimento global da mesma.
Para entendermos como REST surgiu, além de conhecer
suas características arquiteturais, precisamos saber como ela
foi composta.
Como qualquer outro modelo arquitetural, REST também é
composto por um conjunto de elementos arquiteturais e seus
inter-relacionamentos. Fielding especificou em sua tese [3], que
deu origem à arquitetura, as três 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: São os elementos que contêm a
informação a ser usada e transformada. Os principais ele-
mentos de dados de REST estão definidos e exemplificados
na Tabela 1.
Exemplo
Um filme.
Por exemplo,
Forrest Gump
Uma URI contendo o código específico e único de um filme.
http://localhost:8080/
REST/filme/1
Uma página da Web contendo o estado atual solicitado do recurso
(ano, título, gênero).
Por exemplo,
Ano: 1994
Título: Forrest Gump – O Contador de Histórias
Gênero: Drama

Para exemplificar os elementos de dados apresentados
na Tabela 1, pode-se considerar um sistema que fornece
informações a respeito de um determinado filme (ou de
uma lista de filmes). Neste cenário, os filmes representam
os recursos armazenados na base de dados do sistema. Cada
filme representa um determinado recurso e é identificado
com um código específico e único. Este código irá compor
a URL que fornecerá acesso ao recurso – o identificador do
recurso. A página da Web contendo as informações solici-
tadas dos filmes (ano, título, gênero) seria a representação
destes recursos – ou destes filmes.
• Componentes: São os elementos que usam ou transformam
a informação. Em REST, os componentes são caracterizados
de acordo com o papel que exercem. São eles:
• Servidor de Origem (trata as requisições de um clien-
te). Por exemplo, o Servidor Web Apache.
• Proxy e Gateway (utilizados para permitir o encami-
nhamento das requisições e respostas). Como exemplo,
podemos considerar respectivamente o Netscape Proxy
e o Apache API;
• Agente do Usuário (inicia a requisição e, logo em
seguida, se torna o destino final de uma resposta – o
Web Browser).
• Conectores: São os elementos que interligam outros ele-
mentos. REST usa conectores para encapsular a atividade de
acesso aos recursos e para transferir as suas representações.
De acordo com Fielding, “A utilização de conectores provê uma
interface abstrata para a comunicação entre os componentes, melho-
rando a simplicidade do sistema através da separação de responsa-
bilidades e ocultando a implementação de recursos e os mecanismos
de comunicação”. Os principais conectores de REST são:
• 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 passíveis de cache). Por
exemplo, a cache de um Web Browser;
• Resolver (responsável pela conversão de um URI em
um endereço de rede). Exemplo: Bind (DNS lookup
library);
• Túnel (cria um caminho virtual para o tráfego dos
recursos). Exemplo: SOCKS ou um SSL (Secure Sockets
Layer) após um HTTP CONNECT.
• Interface Uniforme e os Métodos Nativos HTTP
• Como já explicado anteriormente, em REST os com-
ponentes se comunicam através de transferências de
representações de um determinado recurso. Para pa-
dronizar o formato destas representações, REST utiliza
uma interface uniforme de componentes.
• Na prática, essa interface uniforme é aplicada através
da utilização dos métodos nativos do protocolo HTTP. A
Tabela 2 exibe os principais métodos HTTP utilizados
em aplicações RESTFul (Web Services construídos de
acordo com os conceitos REST).
Projeto
Método Função
GET Obter uma representação 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 métodos HTTP utilizados em aplicações RESTFul
Um exemplo de utilização do método GET, aplicado ao exem-
plo de busca de filmes citado previamente, seria:
GET http://localhost:8080/REST/filme/1
A invocação deste método retornaria a representação do
filme (recurso) de código 1. Esta situação será detalhada na
apresentação do exemplo prático mais adiante. Vale lembrar
que o trecho “localhost:8080” pode variar de acordo com a
máquina servidora e a porta utilizadas.
Um exemplo prático
Agora que os conceitos relativos a esta nova abordagem de
utilização de serviços já foram apresentados, poderemos enten-
der como eles são aplicados na prática através de uma consulta
a um acervo de filmes, implementado em Java.
A IDE utilizada para demonstrar o exemplo foi o Eclipse
[4] – versão Galileo – e o contêiner web utilizado foi o Apache
Tomcat [5] – versão 6.0.
O serviço oferecido consiste em um acervo simplificado de
filmes e as operações permitidas são as de cadastro e de busca
aos filmes. Por questões de simplicidade, os dados do exemplo
não são persistidos e as camadas de acesso aos dados (padrão
DAO) e de serviço (padrão Service) foram omitidas, assim
como os métodos get e set dos atributos e as declarações do
tipo import.
A classe Filme.java, ilustrada na Figura 1 representa a classe
de modelo do exemplo. Os dados do filme, neste contexto, são
as representações dos recursos que estão sendo disponibiliza-
dos para acesso – os filmes.
Figura 1. Classe de modelo da aplicação de exemplo
Para oferecer suporte a serviços REST em Java, foi criada a
JAX-RS [6] – uma API que surgiu para simplificar o desen-
volvimento da linha de serviços REST e oferecer uma forma
Edição 19 - Engenharia de Software Magazine 35
padrão de implementação da mesma. Sua implementação de
referência é conhecida como Jersey [7].
Para utilizar o Jersey em uma aplicação RESTFul, os pre-
fixos de URI’s do serviço devem ser mapeados para um
Servlet do Jersey. A Figura 2 exibe o arquivo web.xml da
aplicação configurado com este mapeamento. Como todas
as URI’s são do serviço REST, toda a aplicação é mapeada
para o Servlet do Jersey.
Figura 2. Arquivo web.xml da aplicação
Com a utilização do Jersey, um serviço é implementado como
um recurso através de uma classe de Recurso e as requisições
são tratadas por métodos da mesma. Uma classe de Recurso
contém anotações da JAX-RS para indicar os mapeamentos e
as operações disponíveis existentes [8].
A classe de recurso do nosso exemplo é a exibida na
Figura 3, FilmeResource.java. Como os recursos do nosso
exemplo são representados pelos próprios 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 requisições contendo esse
prefixo serão redirecionadas para esta classe de recurso,
onde seus métodos devem ser públicos, como por exemplo,
GET http://localhost:8080/REST/filme/1 .
Além disso, a classe deve conter as anotações @Consumes e @
Produces, que declaram que os serviços da mesma são capazes
de consumir e gerar conteúdo nos formatos text/XML e applica-
tion/json. O formato JSON (JavaScript Objection Notation) é um
formato independente de linguagem baseado em JavaScript.
Para utilização do recurso por uma aplicação cliente RESTFul,
as solicitações HTTP devem ser feitas através da classe Http-
Client (da API commons-http-client)[9]. Esta API permite que
se montem requisições 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 aplicação
Método de busca de filmes
O primeiro método oferecido pelo recurso é o de bus-
ca de filmes. O método buscarFilme foi anotado com @
Path(“{codFilme}”). A junção da anotação do método @
Path(“{codFilme}”) com a da classe (@Path(“filme”)) especi-
fica que o método é capaz de responder a requisições para
a URI /filme/codFilme, como por exemplo /filme/1.
Como também foi inserida a anotação @GET no método
de busca, todas as requisições do tipo HTTP GET serão
tratadas por este método. A anotação @PathParam é utili-
zada para injetar no parâmetro codFilme o valor que veio
da URI.
Método de cadastro de filmes
O outro método oferecido é o de cadastro de filmes. A
utilização da anotação @POST garante que todas as re-
quisições do tipo HTTP POST serão encaminhadas para o
método anotado. O parâmetro do método cadastrarFilme
é um objeto do tipo Filme, que será enviado no formato
XML em uma requisição.
Além das anotações @GET e @POST do exemplo, existem
outras que podem ser utilizadas nos métodos, como @
DELETE e @PUT.
Consumindo o serviço
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 conversão do filme criado em formato XML é feita com
o auxílio da classe XStream, que pertence a uma biblioteca
criada para serializar objetos.
Na execução da classe, ainda são exibidos o cabeçalho e
o corpo, tanto da requisição quanto da resposta, para fins
de demonstração. A Figura 5 mostra a saída da execução
da classe FilmeMain.java.
 Projeto

Figura 4. Classe Main da aplicação

Figura 5. Saída da execução da classe Main
Uma das grandes vantagens de REST é que as requisições
do tipo GET podem ainda ser feitas de forma bem simples e
rápida através de um browser, como ilustra a Figura 6. Atra-
vés das URI’s http://localhost:8080/REST/filme/1 e http://
localhost:8080/REST/filme/2, os dados dos filmes de códigos 1
e 2, respectivamente, foram retornados em formato XML. Neste
contexto, estas URI’s representam os identificadores de recurso
definidos por Fielding.

Casos de sucesso
Buscando, sobretudo simplicidade e maior desempenho
das aplicações, o paradigma REST tem sido utilizado em
larga escala por algumas organizações, listadas a seguir:

Google Search REST API

No ano de 2008, mais de um ano após o Google ter descon-
tinuado o Google SOAP Search API – conjunto de bibliotecas
para acessar os serviços de busca do Google através de Web
Services em sua forma tradicional, utilizando SOAP – a or-
ganização lançou o AJAX Search API [10], que oferece uma
interface simples REST. A API suporta o método HTTP GET
e retorna mensagens do tipo JSON. acessem de forma simples as diversas funcionalidades que
A utilização da API é bem simples. Basta fazer uma solici-
tação GET como a mostrada no exemplo prático e processar
uma resposta do tipo JSON. Além disso, não é necessária
a utilização de uma chave de licença – obrigatória para a
Google SOAP Search API. Outra vantagem é a facilidade
de uso e o número ilimitado de requisições. Porém, a Goo-
gle Search REST API ainda apresenta algumas restrições,
como o número máximo de oito resultados por requisição
e a não-permissão para alterar a ordem dos resultados da
pesquisa.
Figura 6. Requisições 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 usuários
a ferramenta disponibiliza – a Twitter REST API [11].
A Twitter REST API permite automatizar todas as funcio-
nalidades da ferramenta que são acessadas manualmente.
A mesma torna possível, através de requisições HTTP, obter
tweets – mensagens enviadas – de um determinado usuário,
responder um usuário ou até mesmo filtrar tweets com base
em critérios pré-definidos.
Para ilustrar este cenário, 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 usuário liviaruback.

Edição 19 - Engenharia de Software Magazine 37

 Assim como a API REST do Google, a Twitter REST API
ainda tem algumas limitações como o número máximo de
100 requisições por hora. Porém, caso sejam necessárias mais
de 100 requisições, pode-se requisitar ao Twitter pertencer a
uma “lista branca” que permite aos seus usuários mais de 100
acessos por hora.
Conclusão
Como apresentado neste artigo, a implementação de Web
Services pode ser feita de duas maneiras: da forma como a
Arquitetura de Web Services foi especificada (utilizando SOAP
e WSDL) ou através dos princípios do paradigma REST.
A visão tradicional para implementação 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 abstração da comunicação onde
ferramentas devem encapsular a informação para que o seu
receptor a entenda e a processe. Além disso, as trocas de men-
sagens precisam ser envelopadas dentro de um pacote SOAP,
e o que é realmente utilizado é uma parte muito pequena do
conteúdo contido no mesmo. Estas informações desnecessárias
podem comprometer o desempenho de um sistema – e é o que
geralmente acontece.
De acordo com a visão arquitetural de REST, o protocolo
HTTP já é rico o suficiente para que seja criada uma abstração
para a construção de serviços.
Como detalhado no exemplo, pode-se fazer o uso unicamente
do protocolo HTTP para a comunicação, através do acesso di-
reto aos métodos nativos – GET, POST, PUT e DELETE. Como
a Web é baseada em HTTP, em muitos casos a utilização de
REST é a mais adequada, pois aumenta a velocidade de comu-
nicação entre os serviços e, consequentemente, o desempenho
geral da aplicação.
Porém, para integrações em aplicações corporativas ou
aplicações nas quais realmente existe a necessidade de serem
manipulados vários formatos - em vez de só XML, ou que os
serviços oferecidos devem possuir um contrato formal, serem
desacoplados e reutilizáveis, o paradigma REST não é a melhor
opção, pois não possui um padrão oficial para a descrição dos
seus serviços, como o WSDL.
O fato é que para determinadas aplicações, REST é claramente
mais adequado do que a visão tradicional, por exemplo, quan-
do se pode ter uma interação usuário-aplicação. Um exemplo
38 Engenharia de Software Magazine - Arquitetura REST
que ilustra este cenário é um serviço que poderia ser acessado
via Ajax através de um browser diretamente por um usuário.
Em casos como esse, a utilização de REST é muito mais simples.
Basta ter um conhecimento sobre o protocolo HTTP e seus mé-
todos invocando-os a partir de métodos nativos do protocolo.
No exemplo demonstrado anteriormente, por exemplo, para se
buscar informações sobre um determinado filme, a abordagem
REST visivelmente é a mais simples, visto que a solicitação GET
pode ser realizada até mesmo através de um browser.
Outros exemplos de utilização são os serviços para celulares
e PDA’s, e outros dispositivos móveis, onde cada requisição
tem um custo relativamente alto. Nestes casos, utilizar servi-
ços REST sem dúvida é a melhor opção, devido sobretudo à
simplicidade e ao desempenho. A maior prova disso tem sido
a utilização em larga escala do paradigma por organizações
como o Google, Twitter e Facebook.
Referências
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 edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
Dê seu voto sobre este artigo, através do link:
edição
www.devmedia.com.br/esmag/feedback

Usando banco de dados objeto-relacionais
Transição das classes para um modelo de dados objeto-relacional
Ana Cristina Melo
informatica@anacristinamelo.com.br
É especialista em Análise de Sistemas e pro-
fessora de graduação e pós-graduação da
Universidade Estácio de Sá. Atua em análise
e programação há 21 anos, sendo os últimos
11 anos no serviço público. Autora do livro
“Desenvolvendo aplicações com UML - do
conceitual à implementação”, na segunda
edição, 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). Além disso, será demonstrado como é
feita a transição de um modelo de classes para
um modelo objeto-relacional, usando como
exemplos de implementação, o banco de dados
Oracle.
E
m tempos remotos, pensar em for-
ma de armazenamento era pensar
em dados organizados em coleções
logicamente relacionadas compondo ar-
quivos. Contudo, mesmo com a separação
física de programas e dados, toda a gerên-
cia destes dados ainda ficava embutida no
código-fonte dos programas.
A evolução ocorreu na década de 60
com o surgimento dos sistemas de ban-
cos de dados, reunindo num só lugar to-
das as funções necessárias à localização
e manipulação dos dados, tornando-se
uma camada lógica entre a aplicação e
os dados propriamente ditos.
Edição 19 - Engenharia de Software Magazine
Projeto
Para que serve?
Fornecer aos desenvolvedores ou estudantes
da área de sistemas exemplos práticos 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 situação o tema é útil?
Para entender como a ligação entre os modelos
de classes e o modelo de dados pode ser mais
transparente quando esse banco pertence ao
mesmo paradigma; além de compreender como
o Oracle trabalha como um banco de objetos.
Os bancos de dados trabalham com
uma arquitetura que separa a parte
física das aplicações por meio de três
esquemas:
• Esquema interno: descreve a estrutura
física de armazenamento do banco de
dados, sua organização de arquivos e os
seus métodos de acesso;
• Esquema conceitual: descreve a estru-
tura do banco de dados sob o ponto de
vista do usuário, escondendo os detalhes
de armazenamento e concentrando-se
na descrição de entidades, atributos,
relacionamentos, operações do usuário
e restrições sobre os dados;
39
• Esquema externo (ou visões do usuário): descreve as par-
tes do banco de dados que são do interesse de um grupo de
usuários, escondendo as demais.
Os esquemas são apenas camadas lógicas, pois o único nível
que realmente existe armazenando os dados é o nível interno.
A representação dos conceitos de cada nível é feita com o uso
de modelos de dados.
No esquema interno são utilizados modelos físicos de dados,
que são usados para descrever a organização dos arquivos e os
métodos de acesso, tal como é definido no esquema.
Nos esquemas conceitual e externo existem duas categorias
de modelos: o modelo conceitual, um modelo de alto nível que
traz conceitos próximos da percepção que os usuários têm dos
dados; e o modelo lógico, um modelo de nível intermediário
que traz conceitos que podem ser entendidos pelos usuários
finais, mas que não estão muito distantes do formato como os
dados são 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, hierárquico, relacional e OO são
conhecidos como modelos lógicos.
O modelo relacional foi introduzido por E. Codd em 1970,
propondo o trabalho com tabelas, baseando-se em conceitos
matemáticos da Álgebra Relacional. Nos últimos anos, novas
demandas surgiram a partir das aplicações não-convencionais.
Contudo, os requisitos necessários para se atender a essas de-
mandas não eram encontrados nos modelos lógicos existentes.
Este problema incitou o surgimento dos modelos relacionais
estendidos ou objeto-relacionais, que trazem em sua essência
a incorporação de características do paradigma orientado a
objetos como extensões aos sistemas relacionais.
Os modelos de dados OO apresentam conceitos de: objetos
(com encapsulamento), classes (com atributos e métodos), re-
lacionamentos (herança, associação e agregação) e identidade
de objetos.
Cada objeto encapsula os atributos e os métodos.
São características da identidade de objetos, conhecida como
OID (object identifier):
— são gerados pelo sistema;
— não são visíveis aos usuários;
— são independentes do endereço de armazenamento;
— não sofrem mutações;
— é desejado que seja utilizado uma única vez (mesmo após
a exclusão 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 várias décadas.
Contudo, com o surgimento e solidificação do paradigma
da orientação a objetos, as limitações dos bancos relacionais
tornaram-se mais evidentes, trazendo à discussão:
— o número reduzido de tipos de dados;
— os valores dos campos não serem atômicos;
— inapropriação para armazenamento e busca de novos tipos
de dados como imagens, áudio e vídeo.
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 início da década de 90, surgiram vários SGBD-OOs (sis-
temas gerenciadores de bancos de dados orientados a objetos),
onde o centro da atenção deixou de ser a relação com a tabela
e passou a ser com a classe.
Em 1991, um grupo de fabricantes de SGBDs e empresas
que trabalham com padrões criaram o grupo ODMG (Object
Database Management Group), responsável por padronizar
as funcionalidades dos bancos de dados orientados a objetos.
Esse grupo definiu não só o modelo de dados OO, mas também
os padrões ODL (Object Definition Language) e OQL (Object
Query Language).
Um SGBD-OO é um sistema com as características de SGBDs,
acrescidos da manipulação de objetos contemplando:
— definição de objetos complexos, com estrutura aninhada,
como conjuntos ou listas de objetos, além dos tipos de dados
primitivos;
— implementação de encapsulamento, determinando que
todo acesso aos objetos seja por meio da aplicação 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 reação dos princi-
pais fabricantes de SGBD-R aos SGBD-OOs. Nos bancos de
dados objeto-relacionais, o banco relacional tem uma parte
transformada, além de receber a adição de novos recursos que
permitam implementações orientadas a objetos.
Um SGBD-OR é um SGBD que suporta SQL-3. Leia no Box 1
sobre a evolução do SQL.
Alguns bancos objeto-relacionais atuais: Oracle, PostgreSQL,
Informix, DB2, Cachê e SQLServer.
Veja na Tabela 1 as principais diferenças entre os SGBD-OOs
e os SGBD-ORs.
A SQL foi projetada como uma linguagem de alto nível para
banco de dados, próxima da linguagem natural, para ser usada
em aplicações e/ou diretamente por usuários finais em consultas
ao banco.
Foi adotada como padrão na sua versão SQL-86. Novas versões
surgiram em 89 (SQL-89) e em 92 (SQL-2).
Em 1999, aparece a versão SQL:1999 (SQL-3), contendo exten-
sões ao padrão SQL-92, entre outros, a modelagem de objetos.
Ficou definido como o padrão de linguagem objeto-relacional
em bancos.
Nova versão surgiu em 2003 (SQL: 2003), introduzindo, entre
outras características, suporte ao XML.
Box 1. Diferenças entre SGBD-OO e SGBD-OR
 Projeto

SGBD-OO SGBD-OR
— privilégio de “CREATE UNDERTYPE”: para criar
- modelo de dados mais rico - combina as melhores características do modelo de subtipos;
- é adequado ao mercado de aplicações não- objetos no modelo relacional
convencionais - combina um modelo rico com mais eficiência no Veja na Listagem 1 a sintaxe do comando CREATE TYPE para
- baixa performance e escalabilidade gerenciamento de dados criação de tipos e criação de subtipos (uso de UNDER).
- os dados são objetos com estrutura complexa - os dados são tabelas com estrutura complexa
- capacidade de consulta limitada, baseada em - uso do padrão SQL estendido (SQL-3) para garantir
Listagem 1. Sintaxe do comando CREATE TYPE
navegação 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. Diferenças entre SGBD-OO e SGBD-OR tipo_dado1
especificação_elemento_1,
atributon
tipo_dadon
Oracle como Banco Objeto-Relacional especificação_elemento_n)
[[NOT] [FINAL]] [[NOT][INSTANTIABLE]]
Devido à falta de padronização do modelo objeto-relacional,
cada fabricante definiu as características 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- especificação_elemento_1,
atributon
tir da sua versão 8i, quando passou a seguir o SQL-3, como tipo_dadon
padrão. especificação_elemento_n)
[[NOT] [FINAL]] [[NOT][INSTANTIABLE]]

Object Type
Representam uma extensão dos tipos de dados relacionais
do Oracle. O Object Type é o tipo de dado que corresponderá ao
conceito de classe, no paradigma de orientação a objetos.
Os Object Types são 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 métodos que são funções ou procedimentos
implementados em PL/SQL, C ou Java (dependendo do banco)
e armazenados no próprio banco.
O Object Type por ser a abstração de uma classe, não permite
nenhum tipo de armazenamento direto. Enxergado como um
tipo de dados, é usado na definição de uma tabela, coluna ou
em variáveis dos métodos.
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 também 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 não possuirá OID.
Contudo, objetos que são divididos entre vários outros obje-
tos, por meio de relacionamentos, precisam ser referenciados
como Object Row.
Para criar um object type no Delphi, usamos a declaração
CREATE TYPE. Já a declaração CREATE TYPE BODY define
o código para os métodos referenciados no tipo. Veja os privi-
légios necessários para criação de tipos:
— privilégio de “CREATE TYPE”: para criar tipos de objeto
no próprio esquema;
— privilégio de “CREATE ANYTYPE”: para criar tipos de
objeto em outros esquemas;
Para entendermos o uso do Object Type, considere o pedaço
de modelo de classes da Figura 1.
Figura 1. Trecho de um modelo de classes para exemplificar criação 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 convenção minha para
indicar um tipo definido pelo usuário. A classe Cliente se trans-
formará no Object Type TCliente. Como um object type não 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
colocação 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 não é 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 começa similar ao que
conhecemos no SQL. A diferença reside em como vamos inserir

Edição 19 - Engenharia de Software Magazine 41

os dados do Object Type. Para isso, faz-se a chamada de um Imagine que quiséssemos obter o telefone completo com o
construtor, que consiste em colocar à frente dos dados que farão ddd. Bastaria colocar na query uma concatenação de ddd + o
parte do tipo de dados criado, o próprio nome da classe. número de telefone. Só que toda vez que quiséssemos obter
A nossa object table já possui alguns dados. Então, o natural essa combinação, teríamos que escrevê-la no select. Só que ob-
agora é recuperar esses dados. Imagine que quiséssemos saber ter o telefone completo pode ser um método da classe telefone,
o nome do cliente e o número de telefone de todos os clientes como poderia ser de uma “classe nota” o método “calcularMe-
que têm 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 método que mostre o telefone completo.
No primeiro comando da Listagem 6, estamos alterando o
tipo TTelefone. A alteração consiste da inclusão de um méto-
Listagem 2. Criando object type e object table
do (ADD MEMBER), contudo poderia ser a inclusão de um
CREATE TYPE TTelefone AS OBJECT
(ddd varchar2(2),
atributo (ADD ATTRIBUTE). Uma cláusula importantíssima,
numero varchar2(8), nesse caso, é a CASCADE. Essa cláusula determina que essa
tipo char(1));
alteração 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 documentação da Oracle, qualquer operação
CREATE TABLE Cliente OF TCliente;
feita após uma alteração 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 operação.
INSERT INTO Cliente VALUES (
12, ‘Veronica da Silva’, O método que definimos na Listagem 6 contempla um
TTelefone(‘21’, ‘98765432’, ‘C’) );
método de escopo de instância (ou não estático), ou seja, que
INSERT INTO Cliente VALUES ( depende do valor da instância (do objeto) para retornar a sua
13, ‘Terezina do Espírito Santo’,
TTelefone(‘21’, ‘31115555’, ‘R’) ); informação. Também podemos definir um método de escopo
INSERT INTO Cliente VALUES ( de classe (ou estático), ou seja, que independe do valor de uma
14, ‘Pierre Le Monge’, instância, sendo sempre um mesmo valor ou procedimento
TTelefone(‘24’, ‘98776655’, ‘C’) );
para todas as instâncias. Para se definir um método estático
INSERT INTO Cliente VALUES (
15, ‘Dourivaldo Bezerra’, (com escopo de classe), no lugar da cláusula MEMBER, colo-
TTelefone(‘21’, ‘45667788’, ‘T’) );
camos a cláusula 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 é possível 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 obtém
os telefones, fazendo uso do método TelCompleto() adicio-
nado ao tipo.
Repare que o acesso é feito pela notação 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 vários 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. Então, para GROUP BY C.TEL.TIPO;
se fazer referência ao número 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. Alteração um object type com a inclusão de um método

Antes do atributo TEL, foi colocado o alias “C.”. Pois é obri- ALTER TYPE TTelefone
ADD MEMBER FUNCTION TelCompleto RETURN VARCHAR2 CASCADE;
gatória a utilização de aliases na manipulação 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 quiséssemos saber quantos telefones têm de cada tipo, END;
END;
poderíamos aplicar a query descrita na Listagem 5.

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

 Projeto

Referências e coleções de referências Listagem 7. Alteração de um atributo pertence a object type e query
Usamos as referências e as coleções de referências para definir- chamando método
mos relacionamentos entre objetos. Para que um objeto possa ter UPDATE Cliente C
uma coluna que é uma referência para outro objeto (que pode SET C.TEL.NUMERO = ‘87564321’
WHERE C.CODIGO = 14
ser referência de vários 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 referência, esse NOME TELEFONE
--------------------------------- -------------
atributo deve apontar para uma object table Cidade. Armando Santos (21) 21116666
Dourivaldo Bezerra (21) 45667788
A coluna que contém a referência armazenará um ponteiro Pierre Le Monge (24) 87564321
Terezina do Espírito 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 lógico para uma object row.
Vejamos o trecho de um modelo de classes, apresentado na Listagem 8. Utilização de referência em object type. CREATE TYPE TCargo AS

Figura 2, para exemplificarmos o uso de referências. 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 coleção de referências. 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
referências CREATE TABLE Cargo OF TCargo;
CREATE TABLE Funcionario OF Tfuncionario;

A Listagem 8 apresenta a criação da classe Cargo e da Listagem 9. Insert em object table que possui referências
classe Funcionario. Repare que na definição do atributo INSERT INTO Cargo VALUES (100, ‘Secretária Jr’, 1500);
cargo da classe Funcionario que faz referência à tabela Car- INSERT INTO Cargo VALUES (110, ‘Secretária Sr’, 2300);
INSERT INTO Cargo VALUES (200, ‘Programador Jr’, 2000);
go, temos a cláusula 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 método calculaSalario(), para o qual aplicamos INSERT INTO Cargo VALUES (300, ‘Auditor’, 7900);

uma fórmula bem simples, apenas para fins didáticos. O INSERT INTO Funcionario
SELECT ‘95001’, ‘Marieta da Silva’, REF(C)
salário tem uma comissão de 15%, e depois é descontado FROM Cargo C
um percentual de 9% de previdência. WHERE C.codigo = 110;

Vejamos agora na Listagem 9 como é feita a inserção 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 serão inseridos na FROM Cargo C
object table Funcionario. Essa é a primeira solução, adotada WHERE C.codigo = 200;

nos quatro primeiros inserts. A segunda forma mantém INSERT INTO Funcionario VALUES (
‘06010’, ‘Marilia Votoran’,
os valores fixos como campos da cláusula VALUES, e, (select REF(C) from Cargo C where c.codigo = 210) );
quando da colocação no atributo cargo, fazemos o select
INSERT INTO Funcionario VALUES (
na object table Cargo. Essa solução é 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 funcionários que têm INSERT INTO Funcionario VALUES (
o cargo menor que 200. Para cada funcionário, exibir o ‘04050’, ‘Raul da Silva’,
(select REF(C) from Cargo C where c.codigo = 230) );
nome, o cargo e o salário líquido, obtido com o método
calculaSalario().

Edição 19 - Engenharia de Software Magazine 43

 Se utilizarmos na pesquisa apenas a referência 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 cláusula DEREF, o
NOME CARGO SLIQ
Oracle primeiro copia o objeto, para depois exibi-lo. Veja na --------------------------------- --------------- -------
Listagem 12. Marieta da Silva Secretária Sr 2406,95
Joana Filigrama Secretária Jr 1569,75
As coleções permitem o agrupamento de elementos de mes-
Listagem 11. Select direto na object column
mo tipo e podem ser constituídas de: tipos primitivos, object
types ou referências. As coleções são de dois tipos: Varray e SELECT F.NOME, F.CARGO
FROM FUNCIONARIO F
Nested Tables. WHERE F.MATRICULA = ‘95001’

O Varray permite definirmos coleções com um número fixo NOME

---------------------------------
de elementos. No caso de ser usado como tipo de dados de uma CARGO
coluna, os elementos são armazenados na própria tabela. Não ----------------------------------------------------------
Marieta da Silva
podemos apagar elementos individuais de um varray. 00002202083F4BA34F15C44568A3CF411CA6DE2C7
F06C3E663F32C40F6BACF849D5157FF21
A Nested Table (tabela aninhada) permite definirmos coleções
Listagem 12. Select usando DEREF
com número ilimitado de elementos. No caso de ser usado
como tipo de dados de uma coluna, os elementos são 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 pedaço 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, porém, agora, o nosso cliente TCARGO(110, ‘Secretária Sr.’, 2300)

pode ter três telefones. Listagem 13. Criação 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 criação da coleção 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 à coleção TTelefone(‘21’, ‘21334455’, ‘R’),
TTelefone(‘21’, ‘40010009’, ‘T’) ) );
(TListaTelefones) e depois dizemos que ela é uma coleção fixa
(varray) de três 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 inserção de SELECT C.NOME, C.TELEFONES

FROM CLIENTEESP C
dados na tabela de objetos ClienteEsp. Repare que a grande WHERE C.CODIGO = 1024;
alteração está no momento de inserir os telefones. Para que NOME
possamos inserir uma lista de telefones, temos que usar o ---------------------------------
TELEFONES
método construtor que inicializa uma coleção, 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 método construtor TTelefone. Na Listagem 17 preparamos uma query usando o varray, não
Para exibir o campo telefones, podemos verificar na Listagem 15 só no relacionamento como na cláusula where.
como isso é feito. Também podemos exibir esses telefones utili- Agora, para encerrar, considere o trecho de um modelo de
zando uma “Unnesting Query”, que permite a visualização 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. criação 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 começamos criando a object type TDependente.
NOMEDEP
Para que ela possa ser incorporada a uma object table como ---------------------------------
-----------------------
uma coleção de produtos, precisamos criar o tipo TListaDe- BARTOLOMEU VIEIRA
ANITA VIEIRA
pendentes que é uma tabela de TDependente. Repare que não BARTOLOMEU VIEIRA
é um array, mas uma tabela, que permite manipulações 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 criação
apresentará um comando extra, que é da criação da tabela
aninhada. A tabela aninhada indica onde será armazenado o invistam no suporte necessário para que as empresas migrem
conteúdo do atributo dependentes. suas bases de dados para modelos orientados a objetos.
Na Listagem 19 vemos como inserir dados na object table Os benefícios para balizar essa decisão já existem, visto
Servidor. que bancos objeto-relacionais têm melhor perfomance, em
Na Listagem 20 vemos como recuperar os dados de Servidor. função do uso de ponteiros, além de oferecer consultas mais
Observe que a tabela TAB_DEPENDENTES não pode ser aces- rápidas e compactas. Desta forma, resta aguardarmos que
sada diretamente. A mesma é apenas um meio de armazena- a teoria dê lugar à prática, unificando todas as fases do de-
mento para os dados aninhados à object table Servidor. senvolvimento de sistemas, sob um único paradigma – o da
orientação a objetos.
Conclusão
Hoje a realidade aponta para o uso intensivo de modelos
Dê seu feedback sobre esta edição! Feedback
orientados a objetos. Para que os ganhos sejam reais, no nível 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 não é a melhor solução, pois Para isso, precisamos saber o que você, leitor, acha da revista!
s

ta
os bancos relacionais não foram concebidos para atender a
edição
Dê seu voto sobre este artigo, através do link:
este tipo de modelo de negócios. Assim, espera-se que, mais
www.devmedia.com.br/esmag/feedback
cedo ou mais tarde, os grandes fabricantes de banco de dados

Edição 19 - Engenharia de Software Magazine 45

 Referências Nota 3. JSR 172 e KSoap

MELO, Ana Cristina. Apostila de Banco de Dados objetos-relacionais. GILLEANES, T.A.G.,“UML2 (2a Edição): Guia de Consulta Rápida”, Editora Novatec, 2005.

MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.0: do conceitual à implementação. Rio
de Janeiro: Brasport, 2004.
BEZZERRA, E.,“Princípios de Análise e Projetos de Sistemas com Uml”, 2007.
BOOCH, G., RUMBAUGH, J., JACOBSON, I.,“UML 2.0-Guia do Usuário”, Editora Campus, 2005.
FOWLER, M.,“UML Essencial”, 3ed, Editora Bookman, 2005.
FOWLER, M.,“Refatoração - Aperfeiçoando o Projeto de Código Existente”, Editora Bookman, 2004.
GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.,“Padrões de Projeto”, Editora Bookman, 2000.
GORTON, I.,“Essential Software Architecture”, Springer, 2006.
LARMAN, G.,“Utilizando UML e Padrões”, 3ed, Editora Bookman, 2007.
MENDES, A.,“Arquitetura de Software”, Editora Campus, 2003.
WASZLAWICK, R.S., “Análise e Projeto de Sistemas de Informação Orientados a Objetos”, Editora
Campus, 2004.

Existem coisas
que não conseguimos
ficar sem!

COMIDA ...só pra lembrar,

sua assinatura pode
estar acabando!
Renove Já!

www.devmedia.com.br/renovacao

Para mais informações:

www.devmedia.com.br/central
46 Engenharia de Software Magazine - Usando banco de dados objeto-relacionais

Gestão de Portfólio de Projetos
Cristine Gusmão
cristine@dsc.upe.br
Professora do Departamento de Sistemas e
Computação da Escola Politécnica da Universi-
dade de Pernambuco (POLI -UPE), onde leciona
várias disciplinas na graduação e pós-gradu-
ação (especialização e mestrado). Coordena o
Mestrado em Engenharia da Computação 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 Informação das Faculdades Integradas
Barros Melo. Doutora e Mestre em Ciência da
Computação pela Universidade Federal de
Pernambuco. Graduada em Engenharia Elé-
trica - Eletrotécnica pela Universidade Federal
de Pernambuco. Pesquisadora associada do
Núcleo de Telesáude - NUTES - HC -UFPE.
Carlos Henrique R. Alexandria
chra@dsc.upe.br
Possui graduação em Ciência da Computação
pela Universidade Católica de Pernambuco.
Atualmente é mestrando em Engenharia da
Computação, pela Universidade de Pernam-
buco e Analista de Sistemas do Serviço Federal
de Processamento de Dados, onde atua como
Gerente de Projetos e Membro do Escritório de
Projetos da organização. Tem experiência na
área de Ciência da Computação, com ênfase
em Engenharia de Software. Membro do gru-
po de pesquisa Project Management Impro-
vements in Software Engineering (PROMISE).
Gerência de Projetos
C
omo as organizações podem de-
finir qual a melhor combinação
de projetos para seu portfólio e
ainda alinhá-lo às suas estratégias de
negócio? A questão colocada reflete uma
necessidade crítica que está presente,
tanto no setor público, quanto privado.
Fazer com que o Portfólio de Projetos re-
flita as estratégias organizacionais não é
tarefa trivial, tendo em vista que envolve
a análise de vários cenários, tais como,
necessidades do negócio, problemas
corporativos, demandas dos clientes, ob-
jetivos estratégicos, entre outros, que na
maioria dos casos são avaliados apenas
com base no sentimento dos executivos e
dos especialistas da organização. Possuir
um processo decisório mais consciente e
que não adote unicamente este sentimen-
to é a chave para resolver essa questão.
Edição 19 - Engenharia de Software Magazine
De que se trata o artigo?
Este artigo apresenta uma revisão de literatura so-
bre Gestão de Portfólio de Projetos, apresentando
alguns modelos e padrões existentes.
Para que serve?
O levantamento apresentado serve para auxiliar
organizações e gestores a ampliarem seus conheci-
mentos sobre Gestão de Portfólio de Projetos.
Em que situação o tema é útil?
Como definir qual a melhor combinação de proje-
tos para uma organização, ou seja, qual o melhor
Portfólio? Atualmente, definir e manter essa com-
binação de forma sistematizada, sustentada por
parâmetros claros e coerentes, tem sido o grande
desafio organizacional. Ter o melhor Portfólio
também significa distribuir, da melhor maneira,
entre os projetos, os recursos (humanos, físicos e
financeiros) da organização, de modo que projetos
importantes tenham prioridade.
Definição de Portfólio
Para entender o que é um Portfólio,
em primeiro lugar é preciso saber o que
é uma organização, um projeto e um
programa. De acordo com Montana,
47
organizações são caracterizadas pela combinação de esfor-
ços individuais que tem por finalidade realizar propósitos
coletivos, orientados a um objetivo comum [Montana 2003].
As organizações normalmente são compostas de estruturas
físicas e tecnológicas, recursos financeiros e pessoas. Já um
projeto, segundo o Project Management Institute – PMI
pode ser definido como um trabalho temporário realizado
para gerar um resultado exclusivo, como por exemplo, um
produto ou serviço [PMI 2004]. Outra definição para projeto
é dada por Kerzner. Para ele, projeto é um empreendimento
com objetivo bem definido, que consome recursos e opera
sob pressões de prazo, custo e qualidade [Kerzner 2004].
Já um programa é um conjunto de projetos interligados e
gerenciados de forma coordenada onde se busca a obtenção
de benefícios e controles que não seriam possíveis 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 portfólio é uma coleção de projetos, programas e outros
trabalhos que são agrupados em conjunto para facilitar a
gestão eficaz, de modo a cumprir estratégias do negócio.
Os projetos e programas (denominados “componentes”)
do Portfólio podem ser mutuamente independentes ou
diretamente relacionados [PMI 2006]. A Figura 1 ilustra
os relacionamentos entre os diversos componentes de um
portfólio. Frequentemente esses componentes competem
por uma quantidade de recursos (físicos, financeiros e hu-
manos) disponíveis ao patrocinador, que normalmente são
insuficientes para executar todas as demandas existentes
na organização [Archer e Ghasemzadeh 1999].
Kerzner define a gestão de portfólio como um processo de
tomada de decisões que busca o melhor para a organização
como um todo, ressaltando que essas decisões não são tomadas
no vácuo. A decisão geralmente está relacionada com outros
projetos e diversos fatores, tais como reservas financeiras
disponíveis e a alocação de recursos [Kerzner 2004].
Figura 1. Exemplo dos relacionamentos entre os componentes de um
Portfólio
Em um determinado momento temporal, o portfólio re-
presentará uma “fotografia” dos componentes selecionados
pela organização, de modo que reflitam e afetem os objetivos
48 Engenharia de Software Magazine - Gestão de Portfólio de Projetos
estratégicos da organização, ou seja, será o conjunto ativo
de programas, projetos e outros trabalhos [PMI 2006].
Estratégia Corporativa e Gestão de Portfólio
Os projetos são normalmente utilizados pelas organiza-
ções como um meio para atingir os seus objetivos estraté-
gicos. Estes projetos normalmente advêm das mais diver-
sas fontes. Uma demanda de mercado, uma necessidade
organizacional, uma solicitação de um cliente, um avanço
tecnológico, um requisito legal podem ser citados como
típicas fontes de projetos [PMI 2004]. No entanto, como
saber qual conjunto de projetos pode trazer maior valor
agregado à organização e de fato facilitam a realização dos
objetivos estratégicos?
Primeiramente, é necessário chegar até os objetivos estra-
tégicos organizacionais. Atualmente existem diversas fer-
ramentas que auxiliam no desenvolvimento da estratégia
organizacional. Uma delas é a Análise das Forças, Fraque-
zas, Oportunidades e Ameaças, também conhecida como
Análise SWOT – Strengths, Weaknesses, Opportunities,
Threats. Essa ferramenta auxilia na definição dos objetivos
que a organização deverá atingir para maximizar forças,
minimizar fraquezas, aproveitar oportunidades e tratar
as ameaças [Tarapanoff 2001]. Outra abordagem bastante
utilizada é o Balanced Scorecard - BSC, fortemente pautado
em gestão estratégica, que reúne componentes necessários
ao alinhamento do planejamento estratégico com as ações
operacionais da organização [Kaplan e Norton 1996].
De uma forma mais ampla, pode-se dizer que a gestão
de um portfólio envolve as atividades de identificação,
priorização, autorização, monitoração e controle de pro-
jetos, programas e outros trabalhos, visando assegurar
que os investimentos alcancem os objetivos estratégicos
definidos pela organização. Por outro lado, a gestão de
projetos envolve a aplicação de conhecimento, habilidades,
ferramentas e técnicas ligadas às atividades do projeto,
possibilitando o alcance de contribuições individuais aos
objetivos estratégicos.
Independente da forma como as organizações realizam
seus planejamentos estratégicos, elas normalmente definem
sua visão e missão, para então definirem suas estratégias e
objetivos corporativos. A execução destas estratégias, auxi-
liadas pelo necessário apoio de processos de gerenciamento,
ferramentas e técnicas, acabam oferecendo subsídios ao
planejamento e gerenciamento das operações e também ao
portfólio de projetos da organização.
Na Figura 2, os itens Visão, Missão, Estratégias e Objetivos
Corporativos ilustram os componentes utilizados para defi-
nir os objetivos da organização. A partir destes componentes
é que são definidas todas as demais ações corporativas. Os
componentes do nível tático: Planejamento e gerenciamento
de operações e Planejamento e gerenciamento de portfólio
de projetos representam os processos que estabelecem as
ações necessárias para realizar os objetivos da organização.
Tais componentes interagem com os do nível operacional,

que são: Gerenciamento de operações, Gestão de múltiplos
projetos, abordada na próxima seção, e o Gerenciamento de
programas e projetos autorizados, que são os componentes
que tentam garantir à organização que suas operações e pro-
jetos sejam executados de forma eficiente [PMI 2006].
Figura 2. Exemplo do contexto organizacional onde o portfólio de
projetos está inserido [PMI 2006]
Tanto as ações operacionais, quanto as de projetos, devem
ser consideradas na gestão de portfólio. As ações operacio-
nais utilizam atividades recorrentes e processos de gestão
operacional para facilitar a execução do planejamento de alto
nível. Já os projetos utilizam processos de gerenciamento
que permitam o planejamento e execução eficiente das ati-
vidades [PMI 2006]. Nesse nível tático de gestão, uma das
principais preocupações será fazer com que as operações
e os projetos sejam geridos de forma eficiente, trazendo
bons resultados, utilizando a quantidade mínima possível
de recursos, com o mínimo esforço e em conformidade com
valores e normas organizacionais.
O fato é que as organizações dependem de projetos e pro-
gramas para atingir seus objetivos estratégicos. A gestão de
portfólio permite interligação harmoniosa entre os projetos
e os objetivos estratégicos através da divisão e alocação de
recursos [PMI 2006].
Sendo assim, a estratégia da organização impulsiona as
definições das metas e objetivos estratégicos. Esses objetivos
são passados para a gestão de portfólio que visa garantir que
os projetos e programas da organização estejam alinhados
para alcançar os objetivos da organização. Com base nesse
princípio, a gestão de portfólio irá selecionar, priorizar e
aprovar projetos e programas para fazer parte do portfólio
da organização. A gestão de portfólio também deve estar
preocupada com o equilíbrio do portfólio em termos de
retorno financeiro versus investimento e risco versus be-
nefício, assim como, em negociar acordo entre as partes
interessadas, por exemplo, entre a gerência executiva e os
gestores de projetos [PMI 2006].
Gerência de Projetos
Gestão de Portfólio versus Gestão de Múltiplos Projetos
A grande diferença entre a gestão de portfólio e a gestão de
múltiplos projetos está no foco organizacional desses proces-
sos. A gestão de portfólio tem como uma de suas principais
preocupações o constante alinhamento estratégico dos seus
componentes, o que a aproxima do nível mais estratégico da
organização. Outra atribuição da gestão de portfólio, segundo
o PMI, está na identificação, seleção, avaliação e priorização
dos componentes do portfólio [PMI 2006].
No caso da gestão de múltiplos projetos, que tem o foco muito
mais operacional, devido ao fato de trabalhar em conjunto com
a gestão dos projetos em execução, a principal responsabilidade
está na distribuição equilibrada dos recursos disponibilizados
no portfólio aos projetos sob sua responsabilidade. Ou seja, a
gestão de múltiplos projetos estará constantemente analisando
a alocação dos recursos e re-distribuindo os disponíveis entre
seus projetos. Também poderá fazer parte do conjunto de
atividades da gestão de múltiplos projetos o auxílio na reso-
lução de conflitos no âmbito de cada projeto, apoio técnico em
metodologia de gestão de projetos, além do acompanhamento
gerencial para que os projetos alcancem as metas estabelecidas
e obtenham sucesso em relação aos seus requisitos.
É importante reforçar que a retirada de recurso em uso de
um determinado projeto, para outro de maior prioridade, é
responsabilidade da gestão de portfólio, pois foi ela quem
realizou a priorização dos projetos e está constantemente pre-
ocupada com o bom andamento dos projetos de maior valor
para a organização.
Relação entre a Gestão de Portfólio e a Gestão de
Projetos/Programas
A gestão de portfólio utiliza uma gama de informações
coletadas a partir dos projetos e programas que o integram.
De uma forma geral, são analisadas informações referentes
ao andamento das ações planejadas, ao esforço desprendido
e ao orçamento. Esta análise tem como objetivo determinar
ações necessárias para resolver desvios que forem sendo
identificados [PMI 2006].
A gestão de projetos/programas pode trabalhar em conjunto
com a gestão de portfólio na determinação dos critérios de en-
cerramento de suas ações, assim como, na avaliação para deter-
minar se um projeto/programa deve ou não ser cancelado. Outro
ponto em que a gestão de projeto/programa pode interagir com
a gestão de portfólio é no planejamento da capacidade de suas
ações, pois afetará a distribuição dos recursos (humanos, físicos
e financeiros) disponíveis ao portfólio [PMI 2006].
Dependendo da estrutura organizacional, a gestão de por-
tfólio, em conjunto com a gestão de projetos/programa, irá
administrar a distribuição dos recursos (humanos, físicos e
financeiros) aos componentes do portfólio [PMI 2006].
Métricas em Gestão de Portfólio
As métricas de gestão de portfólio normalmente incluem medi-
das sobre a capacidade de recursos disponíveis e o desempenho
do portfólio de uma forma geral. Essas métricas incluem:
Edição 19 - Engenharia de Software Magazine 49
• Disponibilidade e os tipos de recursos necessários para
suportar os componentes do portfólio como planejado e
durante a execução
• Andamento do progresso dos componentes em direção às
metas estabelecidas
• Medidas financeiras, tais como, rentabilidade total do in-
vestimento, valor presente líquido e a diversidade de apoio
financeiro entre os objetivos estratégicos
• Orçamento gastos versus orçamento planejado
• Índices de satisfação do cliente
• Desempenho de lançamento do produto.
Essas métricas descrevem o valor do portfólio para a
organização onde, de acordo com a necessidade, cada item
pode ser melhor detalhado conforme a importância do
componente, facilitando o acompanhamento.
Gerente de Portfólio
O papel de gerente do portfólio, que normalmente é
desempenhado por um gerente sênior ou uma equipe de
gerentes seniores, é responsável por monitorar o portfólio.
Essa monitoração consiste em:
• Buscar o constante alinhamento dos componentes do por-
tfólio aos objetivos estratégicos da organização
• Distribuir às principais partes interessadas do portfólio,
informações sobre o desempenho dos componentes, assim
como, sobre os atuais e potenciais problemas
• Medir o valor do portfólio através de instrumentos de investi-
mento, tais como, retorno sobre o investimento (return on invest-
ment – ROI), valor presente líquido (net present value – NPV),
período de retorno (payback period – PP), entre outros.
Para ter sucesso neste papel, o Gerente de Portfólio deve
ter algum nível de conhecimento nas seguintes áreas:
Visão Estratégica
O gerente de portfólio deve ter uma boa compreensão da
visão, missão e estratégia corporativa, de modo a auxiliar na
otimização do portfólio da organização. Ele deve compre-
ender o relacionamento entre os componentes do portfólio
e os objetivos estratégicos, assim como o plano para atingir
esses objetivos.
Métodos e Técnicas de Gerenciamento de Projetos e
Programas
O gerente do portfólio deve ter um conhecimento avançado
dos métodos e técnicas de gerenciamento de projetos e pro-
gramas. Além disso, ele deve ser capaz de compreender não
só informações de alto nível sobre o andamento dos projetos,
mas também, os detalhes da gestão de projetos, de modo a
determinar se esta gestão está sendo eficiente ou não.
Desenvolvimento e Melhoria Contínua do Processo
O gerente do portfólio deve entender o desenvolvimento
e melhoria contínua do processo de gestão de portfólio,
50 Engenharia de Software Magazine - Gestão de Portfólio de Projetos
visando buscar um processo mais adequado ao portfólio da
organização. Além disso, ele, juntamente com outros líderes
da organização, deverá ter a capacidade de desenvolver
estruturado e bem pensado processo de gestão de portfólio
que melhor se adapte ao negócio, e que se integre bem aos
outros processos da organização.
Competências Gerais
Um bom gerente de portfólio deve possuir uma vasta gama
de habilidades pessoais (comunicação, liderança, persuasão,
criatividade, entre outras) e ser capaz de interagir facilmente
com os executivos e demais tomadores de decisão da or-
ganização. Além disso, ele deve ter conhecimento sobre o
mercado da organização, sua base de clientes, suas normas
internas e leis que regulamentam o seu negócio. Deve ter
também a capacidade de analisar dados e tomar decisões
com base em relatórios de desempenho do portfólio e suas
métricas.
Modelos e Padrões de Gestão de Portfólio
Os modelos e padrões de gestão de portfólio são propos-
tas de processos de trabalho, criados para sistematizar a
dinâmica decisória do portfólio [Blomquist e Muller 2006],
de modo que essas decisões tentem garantir a melhor
distribuição e utilização dos recursos (humanos, físicos e
financeiros) pelos componentes, assim como, a execução
dos componentes que realmente estejam alinhados com
as estratégias da organização e que proporcionem maior
valor agregado.
A seguir serão detalhados alguns modelos e padrões exis-
tentes na literatura e no mercado.
Padrão de Gestão de Portfólio [PMI 2006]
Segundo o PMI, o Padrão para Gestão de Portfólio proposto
é composto de vários processos que possuem dependências
claras e são executados durante a gestão de cada portfólio.
Esses processos são independentes da área de aplicação ou
negócio da organização que o utiliza. Eles foram agrupa-
dos em dois grupos, denominados Grupos de Processos de
Gestão de Portfólio, detalhados a seguir:
• Grupo Processo Alinhamento: inclui os processos que
dirão o que será gerenciado no portfólio, quais as categorias
e quais os componentes que serão avaliados e escolhidos,
ou não, para fazerem parte do portfólio.
• Grupo Processo Monitoração e Controle: inclui os proces-
sos responsáveis pela monitoração periódica dos componen-
tes, assim como o alinhamento dos mesmos às estratégias
da organização.
Interações entre os Processos de Gestão de
Portfólio
A Figura 3 apresenta um resumo dos processos que inte-
gram o Padrão de Gestão de Portfólio do PMI e mostra suas
interações com o Plano Estratégico da Organização e com
a Gestão de Projetos.

Figura 3. Processo de Gestão de Portfólio – Ilustração de Alto Nível
[PMI 2006]
A partir do diagrama disponibilizado na Figura 3, tem-se:
• Plano planejamento estratégico: é a base para tomada de
decisões da gestão de portfólio, assim como, para determinar
o que cada portfólio irá fazer em termos de projetos.
• Processo de gestão de portfólio: representa uma série de
processos integrados que abrangem desde a identificação a
autorização de cada componente do portfólio.
• Processo componente: é a aplicação de uma série de conheci-
mentos, habilidades, ferramentas e técnicas com o objetivo de
executar o componente que teve seu início autorizado.
Ainda de acordo com as informações apresentadas através
da Figura 3, o processo de Gestão de Portfólio é composto por
um conjunto de atividades de:
Identificação
O objetivo deste processo é criar uma lista atualizada com
diversas informações sobre os componentes que estão em exe-
cução e sobre os novos componentes que entrarão no portfólio
da organização. As principais atividades deste processo são:
• Comparar os atuais componentes e as novas propostas de
componentes com os direcionamentos da organização;
• Rejeitar os componentes que não estejam alinhados com as
diretrizes da organização;
• Classificar os componentes identificados em classes pré-
definidas, tais como projeto, programa, portfólio, entre
outros.
Categorização
O objetivo deste processo é separar os componentes em ca-
tegorias empresariais relevantes, de modo que um conjunto
comum de filtros e critérios de decisão possa ser aplicado
durante os processos de avaliação, seleção, priorização e ba-
lanceamento. Essas categorias são definidas com base no plano
estratégico. Os componentes de uma determinada categoria
terão um objetivo comum e poderão ser medidos com base nes-
se objetivo, independentemente da sua origem na organização.
A categorização dos componentes permite que a organização
eventualmente possa equilibrar os seus investimentos e seus
riscos entre todas as categorias e objetivos estratégicos. As
principais atividades deste processo são:
Gerência de Projetos
• Identificar categorias estratégicas com base no plano
estratégico;
• Comparar os componentes identificados com os critérios de
categorização;
• Agrupar os componentes em apenas uma categoria.
Avaliação
O objetivo deste processo é reunir todas as informações
necessárias para avaliar os componentes com a finalidade
de compará-los para facilitar o processo de seleção. As infor-
mações são levantadas para cada componente do portfólio e
podem ser qualitativas ou quantitativas, vindas das mais va-
riadas fontes da organização. Deve-se ter o cuidado necessário
para não comprometer a precisão das informações durante a
atividade de levantamento. Gráficos, diagramas, documentos e
recomendações são gerados para apoiar o processo de seleção.
As principais atividades deste processo são:
• Avaliar os componentes do portfólio através da aplicação de
modelos de pontuação que inclui critérios-chave;
• Produzir representações gráficas para facilitar a tomada de
decisão no processo de seleção;
• Fazer recomendações para o processo de seleção.
Seleção
O objetivo deste processo é produzir uma lista de compo-
nentes baseada nas recomendações do processo de avaliação
e nas capacidades de recursos da organização. A avaliação
determina o valor de cada componente, enquanto a capaci-
dade de recursos da organização determinar o número de
componentes que poderão 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 organização com base na capacidade
disponível. As principais atividades deste processo são:
• Selecionar componentes com base nos resultados da avaliação
e da capacidade da organização;
• Definir os recursos humanos, financeiros e capacidade de
ativos da organização;
• Fazer recomendações para o processo de priorização.
Priorização
O objetivo deste processo é classificar os componentes dentro
de cada categoria estratégica ou de financiamento (inovação,
redução de custos, crescimento, manutenção e operações), de
tempo de retorno do investimento (curto, médio ou longo pra-
zo), de risco versus retorno ou de foco organizacional (cliente,
fornecedor e interno) de acordo com critérios estabelecidos.
Essa etapa classifica os componentes para posteriormente fa-
cilitar a análise e o balanceamento do portfólio. As principais
atividades deste processo são:
• Confirmar a classificação dos componentes nas categorias
estratégicas previamente determinadas;
• Estabelecer e aplicar critérios de pontuação nos componentes,
gerando assim a classificação dos mesmos;
Edição 19 - Engenharia de Software Magazine 51
• Determinar quais os componentes que devem receber má-
xima prioridade dentro do portfólio.
Balanceamento do Portfólio
O objetivo deste processo é proporcionar a combinação de
componentes com maior potencial para a organização e, para-
lelamente, apoiar as iniciativas estratégicas, buscando atingir
seus objetivos. O balanceamento do portfólio permite a visi-
bilidade dos principais benefícios da gestão do portfólio, que
são: (i) a capacidade de planejar e alocar recursos (financeiro,
físicos e humanos) alinhados com as orientações estratégicas
e; (ii) a capacidade de maximizar o retorno do portfólio den-
tro do que foi predefinido em termos de risco aceitável pela
organização.
O balanceamento do portfólio também implica na revisão
das atividades desenvolvidas nos processos de seleção e prio-
rização de componentes. Um portfólio balanceado suportará
os objetivos estratégicos estabelecidos de acordo com critérios
pré-definidos pela gestão de portfólio, assim como, estará ali-
nhado com o perfil de risco da organização, com suas métricas
de desempenho e suas restrições de capacidade. As recomen-
dações para manutenção e ajustes no portfólio também são
realizadas durante o balanceamento. As principais atividades
deste processo são:
• Adição de novos componentes que foram selecionados e
priorizados para autorização;
• Identificar os componentes que não estão autorizados com
base no processo de revisão;
• Eliminar componentes suspensos, re-priorizados ou cance-
lados com base no processo de revisão.
Autorização
O objetivo deste processo é comunicar formalmente à orga-
nização as decisões tomadas no processo de balanceamento
do portfólio, assim como, formalizar a alocação dos recursos
(físicos, humanos e financeiros) necessários para executar os
componentes selecionados. As principais atividades deste
processo são:
• Comunicar as decisões tomadas no processo de balancea-
mento do portfólio às principais partes interessadas, o que
engloba informações referentes aos componentes selecionados
e aos não selecionados;
• Autorizar as decisões referentes a componentes selecionados,
inativos e finalizados;
• Realocar os recursos dos componentes inativos ou
finalizados;
• Alocação rec ursos para exec utar os componentes
selecionados;
• Comunicar os resultados esperados (por exemplo, os ciclos
de revisão, métricas de desempenho de cronograma, e os re-
sultados necessários) para cada componente selecionado.
Revisão e Relato Periódico do Portfólio
O objetivo deste processo é coletar indicadores de desempe-
nho, apresentar relatórios periódicos sobre eles, assim como,
52 Engenharia de Software Magazine - Gestão de Portfólio de Projetos
revisar o portfólio dentro de uma frequência pré-determinada,
de maneira a assegurar o alinhamento dos seus componentes
com as estratégias de negócios, além de garantir a utilização
eficaz dos recursos. O ciclo de revisão examina todos os
componentes durante um período determinado pela organi-
zação. Cada ciclo pode conter várias análises com um foco e
profundidade diferente. Os indicadores chave de desempenho
também podem variar a cada ciclo executado.
O principal objetivo das revisões é assegurar que o portfó-
lio contenha apenas os componentes que realmente estejam
alinhados como os objetivos estratégicos da organização. Para
garantir isso, os componentes devem ser periodicamente adi-
cionados, realinhados, ou até mesmo removidos, com base no
seu desempenho e alinhamento com as estratégias definidas, a
fim de assegurar uma gestão eficaz do portfólio. As principais
atividades deste processo são:
• Revisar o patrocínio e financiamento do componente;
• Revisar e acompanhar a prioridade, dependências, escopo,
retorno esperado, riscos e desempenho financeiro do compo-
nente em relação aos critérios de portfólio;
• Analisar o impacto das previsões referentes ao negócio, a
utilização de recursos e as limitações da capacidade no de-
sempenho do portfólio;
• Determinar a continuidade, a inclusão ou o cancelamento de
um componente, assim como, re-priorizar e re-alinhar deter-
minado componente com os objetivos estratégicos;
• Fazer recomendações e/ou fornecer orientação para a gestão
de um determinado componente
• Propor alterações, caso necessário, na forma como o portfólio
é administrado.
Mudança Estratégica
O objetivo deste processo é permitir que o processo de gestão
de portfólio responda às mudanças estratégicas organizacio-
nais. Pequenas mudanças no plano estratégico, normalmente
não exigem alterações no portfólio, no entanto, alterações sig-
nificativas muitas vezes resultam em nova direção estratégica,
desta forma, impactando o portfólio. Mudanças estratégicas
também poderão causar impactos no processo de categoriza-
ção de componentes, o que exigirá um novo rebalanceamento
do portfólio.
Processo Stage-Gate [Cooper et al 2001]
Segundo Cooper e outros autores, antes de seguir em frente
com a gestão de portfólio 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 adoção do processo Stage-Gate, reforçando que
um efetivo processo de desenvolvimento de novos produtos é
fundamental para a gestão de portfólio, por duas razões:
• Independente da sofisticação do modelo de gestão de
portfólio usado, deve-se ter certeza de que as informações
utilizadas pelo portfólio estão corretas. Essas informações
serão provenientes do processo de desenvolvimento de
novos produtos.

• O processo decisório de avaliação de projetos deve finalizar
os projetos ruins, fazendo com que o portfólio esteja cada vez
mais alinhado com os objetivos da organização.
A seguir será detalhado o processo Stage-Gate, como visua-
lizado através da Figura 4, de desenvolvimento de novos pro-
dutos. Este modelo fragmenta o desenvolvimento do produto
em estágios pré-determinados, onde cada estágio consiste de
um conjunto de atividades pré-definidas.
Figura 4. Processo Stage-Gate [Cooper et al 2001]
A entrada de cada estágio é um ponto de decisão, de modo
que estes pontos comandam o processo, tendo como funções,
o controle da qualidade do projeto e a tomada de decisão que
englobam as seguintes saídas: Inicia, Continua, Aborta, Sus-
pende ou Recicla. Cada Portão ou Ponto de decisão (continua/
finaliza) é composto de:
• Um conjunto de Entradas;
• Critérios de julgamento do projeto, incluindo obrigatórios
e facultativos;
• Saídas
Descoberta
O processo de desenvolvimento de novos produtos se inicia
com a descoberta da idéia de um novo produto ou otimização
em um já existente, que é avaliada no Portão 1 de decisão.
Portão 1 – Exame da Idéia
Neste ponto, se a decisão for de iniciar, nascerá o projeto,
havendo o comprometimento de recursos e passando para
o Estágio 1, Definição do Escopo. Para se tomar esta deci-
são, serão analisados os seguintes critérios: alinhamento
estratégico, viabilidade do projeto, magnitude da oportu-
nidade, vantagens diferenciais, atratividade de mercado e
sinergia da atividade primária do negócio com os recursos
da organização.
Estágio 1 – Definição do Escopo
Este estágio tem como objetivo estabelecer os méritos téc-
nicos e de mercado do projeto. Uma análise de mercado é
realizada envolvendo pesquisas, contatos com as partes inte-
ressadas e testes com usuários potenciais. O foco é detalhar
informações quanto ao tamanho e ao potencial do mercado,
além de sua possível aceitação. Paralelamente, uma avaliação
técnica preliminar é realizada como o objetivo de verificar
Gerência de Projetos
a viabilidade de desenvolvimento e de produção, além dos
possíveis custos e tempo de execução do projeto.
Portão 2 – Segundo Exame da Idéia
Este estágio é praticamente uma repetição do Portão 1, onde o
projeto é reavaliado, no entanto, com base nas informações for-
necidas pelo Estágio 1. Neste ponto, o nível de incerteza referente
às informações adquiridas já é um pouco menor. Se a decisão for
de prosseguir, o projeto passará para um estágio onde já ocor-
rerão maiores gastos. Complementarmente, são utilizadas listas
de verificação para fatores que devem ser atendidos e modelos
ponderados para fatores que se desejam atender.
Estágio 2 – Avaliação do Negócio
Este estágio conduz ao desenvolvimento do produto, onde o
projeto deve ser claramente definido. Neste ponto do processo
são realizadas pesquisas de mercado para determinar as neces-
sidades, desejos e preferências dos consumidores. Determina-
ção dos mercados-alvo, posicionamento do produto, benefícios
que devem ser entregues, proposta de valor, funcionalidades,
atributos, requisitos e especificações do produto.
Portão 3 – Vai para o Desenvolvimento
Este é o ponto de decisão final antes do estágio 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 organização
com o projeto é significativo. Nesta fase, o projeto também é
avaliado com base em critérios e modelos de maneira similar
aos pontos de decisão anteriores. Porém, outra parte da ava-
liação também envolve a revisão de cada uma das atividades
do Estágio 2, verificando se as atividades foram realizadas
conforme planejado e se os resultados foram positivos.
Estágio 3 – Desenvolvimento
Este estágio tem em seu escopo o desenvolvimento do pro-
duto e ocorre juntamente com a execução de testes detalhados,
com o planejamento do marketing e com o desenvolvimento
dos processos de fabricação. Simultaneamente, uma atua-
lização na análise financeira é preparada em conjunto com
questões legais.
Portão 4 – Vai para Teste
Este portão tem como atividade a verificação do progresso
do projeto e da atratividade do produto. O trabalho do Estágio
3 (Desenvolvimento) é verificado de forma a tentar garantir
que o projeto atinja o nível de qualidade esperado. É realizada
também a verificação da análise financeira, tomando como
base os novos dados, que nesse momento já serão um pouco
mais precisos.
Estágio 4 – Teste e Validação
Neste estágio é avaliada a viabilidade do projeto como um todo,
o que evolve análises do produto, do processo produtivo, da
aceitação do mercado e das questões financeiras do projeto.
Edição 19 - Engenharia de Software Magazine 53
Portão 5 – Vai para Lançamento
Neste portão é decidida a comercialização ou não do pro-
duto. Para tomar essa decisão é necessário que se faça uma
avaliação das fases anteriores e dos resultados alcançados. O
planejamento das operações e do lançamento do produto no
mercado são reavaliados, se aprovados, serão implementados
no Estágio 5 (Lançamento).
Estágio 5 – Lançamento
Neste estágio são executados os planejamentos realizados
para o lançamento do produto e sua colocação em operação,
o que certamente envolverá todo o marketing planejado.
Após o lançamento, se inicia a fase de encerramento do
projeto que contempla atividades como liberação da equipe
envolvida, liberação de recursos alocados, encerramento dos
contratos, comunicação formal a todas as partes envolvidas,
entre outras.
Revisão pós Lançamento
Neste momento será realizada uma avaliação criteriosa do
projeto onde é revisado todo o seu desempenho e seus pontos
fortes e fracos. Todas estas informações serão registradas, de
modo a servirem como lições e base de conhecimento para
o desenvolvimento de novos projetos, aumentando assim a
qualidade dos projetos da organização. Essa etapa marca o
fim do projeto.
Processo Integrado de Seleção e Priorização de
Projetos [Archer e Ghasemzadeh 1999]
Segundo Archer e Ghasemzadeh, o processo de seleção de
projetos na gestão de portfólio é de suma importância para
esta gestão e ocorre com bastante frequência em muitas orga-
nizações. Há muitas técnicas disponíveis para auxiliar neste
processo, no entanto, não existe um processo integrado para
a sua execução.
O processo proposto por Archer e Ghasemzadeh simplifica
a seleção de projetos em um portfólio através do desenvol-
vimento de uma estrutura que separa o trabalho em fases
distintas. Cada fase é responsável por um objetivo particular
e cria insumos para a próxima fase. O processo também per-
mite que os usuários sejam livres para escolher as técnicas
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 seleção de projetos, como visualiza-
do através 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 execução do
processo, que conta também com as atividades representadas
pelas caixas delineadas por linhas claras, as quais fornecem
informações de entrada e recebem informações de saída pro-
duzidas no processo de seleção.
A seguir serão detalhadas as principais atividades que com-
põem o processo integrado de seleção de projetos.
54 Engenharia de Software Magazine - Gestão de Portfólio de Projetos
Figura 5. Processo Integrado de Seleção de Projetos [Archer e
Ghasemzadeh 1999]
Pré-filtragem
Nesta fase, que utiliza informações produzidas no Desenvolvi-
mento Estratégico, busca-se garantir que todas as proposições de
projetos considerados para entrar no portfólio estejam alinhados
com os objetivos estratégicos da organização. Nesta fase tam-
bém será realizada uma análise de viabilidade e estimativas de
parâmetros necessários para avaliar cada projeto, bem como as
metas para cada parâmetro, o que será uma fonte de informações
para outras fases. Projetos essenciais também são identificados
neste ponto, uma vez que serão incluídos no restante do processo
de seleção do portfólio. Projetos essenciais podem incluir ações
de melhorias aos produtos da organização que deixaram de ser
competitivos, ou seja, são os projetos sem os quais a organização
não poderia funcionar adequadamente.
Análise Individual de Projeto
Nesta fase um conjunto de parâmetros necessários para a próxi-
ma fase é calculado separadamente para cada projeto, tendo como
base as estimativas disponíveis nas análises de viabilidade e/ou
no banco de dados de projetos da organização. Algumas técnicas
poderão ser utilizadas nesta fase para realizar as estimativas, tais
como, levantamento dos riscos do projeto, valor presente líquido,
retorno sobre o investimento, entre outras. Projetos em andamen-
to também poderão ser re-avaliados nesta fase, proporcionando
estimativas com menor grau de incerteza em relação aos projetos
que estão sendo propostos. A saída desta fase é um conjunto de
estimativas de parâmetros para cada projeto.
Filtragem
Nesta fase, que ocorre após a fase de análise individual dos pro-
jetos, são verificados criteriosamente os parâmetros produzidos na
análise. Essa filtragem servirá de base para a seleção dos projetos,
assim como, para eliminar quaisquer projetos que não preencham
critérios pré-estabelecidos. Vale ressaltar que projetos obrigatórios
ou necessários para apoiar outros projetos não serão eliminados.
Seleção do Portfólio Ótimo
Nesta fase são consideradas e analisadas as interações entre
os projetos, suas dependências e competição por recursos,
assim como o valor do projeto para a organização. Com base

nestas informações podem ser produzidos modelos de pon-
tuação e gráficos, que auxiliarão os tomadores de decisão na
seleção do melhor portfólio, permitindo avaliações quantita-
tivas e qualitativas.
Ajuste do Portfólio
Nesta fase, que é a etapa final do processo, é realizada a aná-
lise do portfólio como um todo, buscando o equilíbrio entre os
projetos selecionados. Para isso, serão verificadas caracterís-
ticas críticas de importância dos projetos, por exemplo, valor
presente líquido, estimativa de tempo para finalizar, risco,
entre outras. Como exemplo do equilíbrio a ser alcançado no
portfólio, pode-se falar que a proporção de projetos de alto
risco não deve ser muito elevada, devido ao fato de que as
falhas de vários desses projetos pode ser perigo para o futuro
da organização. Por outro lado, os projetos de baixo risco, que
geralmente não trazem elevado retorno financeiro quando
comparados aos de alto risco, não podem ser maioria absoluta
no portfólio, o que prejudicaria o seu valor.
Considerações Finais e Sugestões de Leitura
A Gestão de Portfólio é um processo que vem sendo traba-
lhado por diversos autores estudados neste levantamento,
que sempre colocam em evidência como núcleo deste pro-
cesso as atividades de identificação, seleção, priorização e
balanceamento dos projetos do portfólio, além da gestão dos
recursos (humanos, físicos e financeiros) disponibilizados no
portfólio.
Entendemos que as organizações que realizam estas ativida-
des citadas, conseguindo alcançar, através dos projetos, seus
objetivos estratégicos, metas e indicadores estabelecidos em
seu planejamento, estão cumprindo o objetivo principal da
Gestão de Portfólio.
Como sugestão de leitura para aprofundamento nos prin-
cipais assuntos abordados neste artigo sugerimos as fontes
citadas a seguir:
Para um maior detalhamento sobre o Padrão de Gestão de
Portfólio 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 Gestão 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].
Tópicos de Pesquisa (trabalhos futuros e correntes)
Durante a escrita deste artigo foram encontrados as seguin-
tes pesquisas e trabalhos relacionados com o tema Gestão de
Portfólio:
Gerência de Projetos
O Impacto da Gestão de Portfólio de Projetos em Projetos
de Tecnologia da Informação [Reyck et al 2005]
Neste trabalho foi avaliado se existe uma correspondên-
cia entre a utilização de processos de Gestão de Portfólio
de Projetos e as melhorias no desempenho dos projetos
do portfólio. O estudo apontou uma forte correlação entre
aumentar a adoção de processos de Gestão de Portfólio e
uma redução dos problemas relacionados com projeto, assim
como, melhoria no desempenho dos projetos.
Portfolius: Um Modelo de Gestão de Portfólio de Projetos
de Software [Correia 2005]
Neste trabalho foi proposto um processo, que é um modelo
de gestão de portfólio de projetos de software, com a finali-
dade de auxiliar os tomadores de decisões de uma empresa
de desenvolvimento de software na escolha do portfólio de
projetos mais adequado à realidade da organização. O mo-
delo proposto possibilita a criação de uma ligação entre os
projetos e a estratégia da organização e auxiliará na adoção
uma visão de longo prazo.
Seleção de Projetos em um Portfólio para Apoio a Tomada
de Decisão [Ghasemzadeh e Archer 2000]
Neste trabalho foi discutida a implementação de uma
estrutura organizada para a seleção de projetos em um por-
tfólio através de um Sistema de Apoio Tomada de Decisão
(SATD), que foi chamado de Sistema de Seleção e Análise
de Projeto (SSAP). Foram descritos os resultados dos testes
laboratoriais realizados para medir sua usabilidade e qua-
lidade, comparado com os processos de seleção manual,
na seleção de problemas típicos da portfólio. Também foi
discutido o potencial da SSAP no apoio empresarial a to-
mada de decisão.
Um Processo Integrado para Seleção de Projetos em um
Portfólio [Archer e Ghasemzadeh 1999]
Neste trabalho foi proposto um processo integrado para
seleção de projetos na gestão de um portfólio. O processo
de seleção proposto segmenta o trabalho em fases distintas,
onde cada fase aborda um objetivo específico e cria insumos
para a próxima fase. O processo pode ser utilizado sob a
forma de um sistema de apoio a decisão.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
Dê seu voto sobre este artigo, através do link:
edição
www.devmedia.com.br/esmag/feedback
Edição 19 - Engenharia de Software Magazine 55
 Referências Bibliográficas
[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 Gestão de Portfólio de Projetos de Software,
Dissertação 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 - Gestão de Portfólio 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. Administração. 2. ed. São 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. Inteligência Organizacional e Competitiva. Brasília: Editora UNB, 2001.
[Luecke 2008] Luecke, Richard. Estratégia, Harvard Business Essentials, Record, 2008.
 Gerência de Projetos

Edição 19 - Engenharia de Software Magazine 57

 Modéstia à parte, sua
melhor opção para
se destacar no mercado!
A Escola Superior da Tecnologia da PÓS- GRADUAÇÃO
Informação oferece as melhores Engenharia de Software:
opções em cursos, formações, Desenvolvimento Java
graduações e pós-graduações para GRADUAÇÃO
profissionais de desenvolvimento Análise e Desenvolvimento
e programação. de Sistemas

São programas voltados para a FORMAÇÕES

formação de profissionais de elite, Desenvolvedor Java

com aulas 100% práticas, corpo Desenvolvedor Java: Sistemas
Distribuídos
docente atuante no mercado,
Gestor de TI
acesso à mais atualizada biblioteca
Desenvolvedor Web .NET 2008
de TI do Rio, laboratórios equipados
MCITP Server Administrator
com tecnologia de ponta, salas de
estudo e exames. SQL Server 2008

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

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

EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO

58 Engenharia de Software Magazine - Gestão de Portfólio de Projetos