Desenvolvimento de Um Protótipo de Sistema de Apoio A Decisao para Ggestao de Portifolio de Projetos de Tecnologia Da Informação

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
ESCOLA DE ADMINISTRAO
DEPARTAMENTO DE CINCIAS ADMINISTRATIVAS

Gustavo Schirmer dos Santos

DESENVOLVIMENTO DE UM PROTTIPO DE SISTEMA DE APOIO
DECISO PARA GESTO DE PORTFLIO DE PROJ ETOS DE
TECNOLOGIA DA INFORMAO

Porto Alegre
2010



Trabalho de concluso de curso de graduao
apresentado ao Departamento de Cincias
Administrativas da Universidade Federal do Rio
Grande do Sul, como requisito parcial para a obteno
do grau de Bacharel em Administrao.
Orientador: Prof. Dr. Antnio Carlos Gastaud Maada

Porto Alegre
2010



Trabalho de concluso de curso de graduao
apresentado ao Departamento de Cincias
Administrativas da Universidade Federal do
Rio Grande do Sul, como requisito parcial para
a obteno do grau de Bacharel em
Administrao.

Conceito Final: ..........
Aprovado em ........ de .................................. de ................
BANCA EXAMINADORA
______________________________________________
Prof.:.................................................................... Instituio:................

______________________________________________
Prof.:.................................................................... Instituio:................

______________________________________________
Prof.:.................................................................... Instituio:................

______________________________________________
Orientador: Prof. Dr. Antnio Carlos Gastaud Maada EA-UFRGS

AGRADECIMENTOS

Primeiramente, agradeo ao Prof. Dr. Antnio Carlos Gastaud Maada, com quem
aprendi muito na execuo deste trabalho. Nunca pareceu fcil e nem sempre pareceu
provvel, mas c estamos, pelo que sou muito grato.
Aos meus colegas do Tribunal Regional do Trabalho da 4a Regio, pelo apoio e
genuno interesse.
Sou grato a meus pais, J os Luiz e Lcia, e meus irmos, Csar, Ana Paula e Eduardo,
pelo apoio permanente e pelos bons momentos que passamos juntos.
Por fim e mais importante, agradeo a J uliana, minha esposa, companheira, inspirao
e ainda revisora, cuja presena fez tudo valer a pena.
RESUMO

A gesto dos investimentos em tecnologia da informao complicada pela
dificuldade de avaliar o retorno dos investimentos, que no meramente financeiro. Para
facilitar esta tarefa, outra ferramenta financeira, a gesto de portflios, foi adaptada ao uso
neste tipo de investimentos, de modo a proporcionar ao tomador de deciso uma medida
agregada de risco e retorno dos seus investimentos. A diviso destes investimentos em quatro
classes, de infraestrutura, transacional, informacional e estratgica, facilita a avaliao do
portflio por classificar tambm o risco e tipo de retorno esperado de cada classe. Para a parte
dos investimentos que servir para que a rea de tecnologia da informao da organizao
oferea novos produtos e servios ou melhore sua capacidade de operar, que so os projetos, a
gesto se torna ainda mais complexa pelo carter temporrio dos projetos. O presente trabalho
prope o desenvolvimento de um sistema de apoio deciso para priorizar os projetos de
tecnologia da informao com base na classificao dos projetos nas quatro categorias citadas.
O prottipo foi ento desenvolvido e aplicado ao portflio de projetos de tecnologia da
informao do Tribunal Regional do Trabalho da 4a Regio, para validar o conceito proposto.

Palavras-chave: Gesto de Portflio de Tecnologia da Informao. Gesto de Portflio de
Projetos. Sistemas de Apoio Deciso.
LISTA DE ILUSTRAES
Figura 3.1: objetivos e exemplos das classes de investimento em TI ...................................... 17
Figura 3.2: distribuio dos investimentos por classe do portflio de TI ................................. 18
Figura 3.3: componentes do SAD............................................................................................. 21
Figura 3.4: processo de tomada de deciso .............................................................................. 22
Figura 3.5: informao necessria por categoria de deciso .................................................... 24
Figura 3.6: matriz de decises .................................................................................................. 24
Figura 4.1: Organograma da STI .............................................................................................. 26
Figura 5.1: exemplo de matriz de projetos ............................................................................... 33
Figura 5.2: formato do arquivo de objetos do sistema ............................................................. 39
Figura 5.3: formato de arquivo para portflio .......................................................................... 40
Figura 5.4: interface inicial do sistema ..................................................................................... 41
Figura 5.5: grfico de classes de investimento ......................................................................... 43
Figura 5.6: grfico de projetos .................................................................................................. 44
Figura 5.7: grfico de uso de recursos ...................................................................................... 44
Figura 5.8: escala de tempo para os grficos ............................................................................ 44
Figura 5.9: menu do sistema ..................................................................................................... 45
Figura 5.10: investimento por classe no portflio atual ........................................................... 48
Figura 5.11: projetos do portflio atual .................................................................................... 49
Figura 5.12: uso de recursos no portflio atual ........................................................................ 51

LISTA DE QUADROS
Quadro 5.1: softwares para mquinas virtuais analisados ........................................................ 31
Quadro 5.2: requisitos iniciais .................................................................................................. 36
Quadro 5.3: comparao entre resultados planejados e reais ................................................... 46
LISTA DE ABREVIATURAS E SIGLAS
GPTI Gesto de Portflio de Tecnologia da Informao
OMG Object Management Group
PMI Project Management Institute
SAD Sistema de apoio deciso
STI Secretaria de Tecnologia da Informao do Tribunal Regional do Trabalho da 4a
Regio
TI Tecnologia da Informao
TRT4 Tribunal Regional do Trabalho da 4a Regio
UML Unified Modeling Language
XML Extensible Markup Language
XP Extreme Programming
SUMRIO
1 INTRODUO ........................................................................................................ 10
2 PROBLEMA ............................................................................................................. 11
2.1 J USTIFICATIVA ........................................................................................................ 13
2.2 OBJ ETIVOS ............................................................................................................... 13
2.2.1 Objetivo geral ........................................................................................................... 14
2.2.2 Objetivo especfico .................................................................................................... 14
3 REVISO DA LITERATURA ................................................................................ 15
3.1 GESTO DE PORTFLIO DE TI ............................................................................ 15
3.1.1 Classes de investimentos .......................................................................................... 16
3.2 GESTO DE PROJ ETOS DE TI ............................................................................... 19
3.3 GESTO DE PORTFLIO DE PROJ ETOS DE TI.................................................. 19
3.4 SISTEMAS DE APOIO DECISO ....................................................................... 20
3.4.1 Tomada de deciso .................................................................................................... 21
3.4.2 Informaes para tomada de deciso ..................................................................... 23
4 MTODO .................................................................................................................. 25
4.1 ORGANIZAO E AMBIENTE .............................................................................. 25
4.2 DESENVOLVIMENTO DO SISTEMA .................................................................... 26
4.2.1 Definio dos requisitos ........................................................................................... 27
4.2.2 Definio da arquitetura do sistema ....................................................................... 27
4.2.3 Modelagem, codificao e testes do sistema ........................................................... 28
5 RESULTADOS .......................................................................................................... 30
5.1 DESENVOLVIMENTO DO PROTTIPO ............................................................... 30
5.1.1 Modelo de classes do prottipo ................................................................................ 32
5.1.2 Funcionalidades bsicas do sistema ........................................................................ 33
5.1.3 Implementao do prottipo ................................................................................... 33
5.1.4 Configurao do ambiente ....................................................................................... 34
5.1.5 Requisitos iniciais ..................................................................................................... 34
5.1.6 Implementao das classes ...................................................................................... 35
5.1.6.1 Atributos ..................................................................................................................... 35
5.1.7 Iteraes .................................................................................................................... 36
5.1.7.1 Iterao 1 .................................................................................................................... 36
5.1.7.2 Iteraes 2 e 3 ............................................................................................................. 37
5.1.7.3 Iterao 4 .................................................................................................................... 40
5.1.7.4 Iterao 5 .................................................................................................................... 42
5.1.7.5 Avaliao do processo de desenvolvimento do sistema ............................................. 45
5.2 APLICAO DO SISTEMA AO PORTFLIO ATUAL DO TRT4 ........................ 47
5.2.1 Grfico de classes de investimento .......................................................................... 48
5.2.2 Grfico de projetos ................................................................................................... 49
5.2.3 Grfico de recursos ................................................................................................... 51
5.3 APRESENTAO DO PROTTIPO AOS ESPECIALISTAS ................................ 52
6 CONCLUSO .......................................................................................................... 54
REFERNCIAS ....................................................................................................... 56
10

1 INTRODUO
Uma grande organizao de servios, como o Tribunal Regional de Trabalho da 4a
Regio (TRT4), precisa prestar diversos servios de tecnologia da informao (TI) para seus
usurios internos e para o pblico externo. Para melhorar constantemente a oferta destes
servios, a organizao se vale de projetos, que criam novos produtos ou permitem acesso a
novas capacidades de operar. A gesto de um conjunto coordenado de projetos, ou gesto de
portflio, essencial para garantir que os melhores projetos sejam empreendidos, e que cada
um destes projetos tenha a maior possibilidade de sucesso.
Selecionar os melhores projetos para execuo e definir o momento correto para iniciar
cada um deles exige que o tomador de deciso tenha acesso a diversas informaes sobre
estes projetos e critrios claros para deciso, de modo a tornar o processo de deciso mais
objetivo e seus resultados mais justificveis. A Gesto de Portflio de TI (GPTI) uma
ferramenta que serve para auxiliar na justificativa dos investimentos em TI, e pode ser
adaptada para a seleo dos projetos mais adequados estratgia da organizao.
Os projetos precisam de recursos de diversas naturezas para sua execuo. No caso de
uma organizao como o TRT4, onde a contratao de recursos de mo de obra muito
demorada e dispendiosa, os recursos que mais restringem a ao do tomador de deciso so os
recursos humanos. Isso torna ainda mais importante a seleo dos melhores projetos e
complica a deciso sobre o incio dos projetos.
Para facilitar este tipo de deciso, o presente trabalho prope o uso de um sistema de
apoio deciso (SAD) criado especificamente para a situao do TRT e apresenta um
prottipo deste sistema. O processo de desenvolvimento deste prottipo e o resultado da
aplicao do sistema aos projetos so apresentados.
11

2 PROBLEMA
O valor da TI para as organizaes muito difcil de mensurar. Medidas financeiras
tradicionais, como retorno sobre investimento ou valor presente lquido, no conseguem
avaliar os efeitos da TI na produtividade e as vantagens competitivas que podem ser obtidas.
Em geral, as organizaes tm mais oportunidades para investir seus recursos em TI de
que recursos disponveis ou mesmo capacidade gerencial. Alm dos novos investimentos, os
sistemas e servios existentes precisam ser mantidos, o que consome ainda mais recursos. Por
isso, os novos investimentos precisam ser muito bem selecionados, considerando as restries
de recursos e capacidade gerencial, os riscos e os retornos esperados. O processo de seleo e
priorizao dos investimentos, novos ou existentes, em TI parte da gesto de portflio de TI
(J EFFERY; LELIVELD, 2004).
Em um processo de seleo eficaz, as iniciativas selecionadas daro origem a projetos
que traro os maiores benefcios possveis para a organizao. O gerenciamento de projetos
uma disciplina complexa mas razoavelmente definida, com um corpo de conhecimentos bem
conhecido e apoio de entidades, como o Project Management Institute (PMI), que coletam,
organizam e divulgam informaes a respeito das melhores tcnicas. O gerenciamento de
projetos tambm facilitado pelo uso de sistemas de TI bem desenvolvidos.
Mesmo com o uso das melhores tcnicas e ferramentas, um projeto no ser bem
sucedido se os recursos necessrios no estiverem disponveis no momento certo, e no trar
os maiores benefcios para a organizao que o comissionou caso tenha consumido recursos
necessrios a outro projeto, mais importante. A gesto do portflio de projetos de TI um
meio para garantir que as iniciativas selecionadas e priorizadas sejam iniciadas no momento
correto, com recursos garantidos para sua execuo, e que o conjunto das iniciativas o
portflio de projetos de TI traga o maior benefcio para a organizao.
Por representar a implementao da estratgia de TI da organizao, o portflio de
projetos de TI pode ser considerado a real medida de suas intenes, direo e progresso
(PMI, 2009). Cada um dos projetos pode ser apenas a soluo de um problema localizado,
mas seu conjunto deve refletir o planejamento estratgico da organizao, e a execuo deste
conjunto de projetos o meio de que a organizao dispe para implementar sua estratgia.
A gesto do portflio de TI deve seguir um processo bem definido, transparente, e que
enfatize a responsabilidade dos tomadores de deciso quanto a seu resultado. Para isso, os
tomadores de deciso precisam ter acesso a toda informao relevante e comparar com clareza
as consequncias de cada uma das opes a seu alcance (DINSMORE; COOKE-DAVIES,
12

2006). No caso do portflio de projetos, em que os projetos concorrem entre si pelo uso de
recursos financeiros, humanos de outra natureza escassos da organizao, cada
combinao de projetos resulta em um conjunto diferente de benefcios distribudos de
maneira diferente pelo tempo e com riscos diferentes. O tomador de deciso deve poder ver
estas diferenas com clareza, de modo a tomar uma deciso informada e pela qual possa
assumir plena responsabilidade.
Em uma organizao pblica, recursos financeiros no podem ser convertidos em
outros tipos com a mesma facilidade das organizaes privadas. O processo de contratao de
recursos humanos prprios muito demorado, dependendo da aprovao da criao de novos
cargos pelo J udicirio, aprovao dos candidatos a estes cargos em concurso pblico,
nomeao e capacitao para o servio. A contratao de recursos humanos de terceiros
menos demorada, mas ainda assim depende de uma licitao sujeita a diversas restries.
Mesmo a aquisio de equipamentos pode ser demorada, caso seja necessrio fazer uma
concorrncia pblica. Enquanto os prazos para contratao de recursos humanos de terceiros
ou para aquisio de equipamentos precisam ser levados em conta no planejamento de cada
projeto, os recursos humanos prprios podem ser considerados fixos para todo o portflio de
projetos, e por isso representam uma restrio global, como o oramento da organizao.
Atualmente, no existe um processo como o descrito acima no TRT4. Os projetos so
priorizados com base em poucas informaes, sem avaliao do uso de recursos, e todos os
projetos priorizados so iniciados imediatamente. O resultado deste processo ineficaz que
vrios projetos esto em andamento ao mesmo tempo, exigindo participao dos mesmos
servidores. Alguns dos projetos esto alinhados com os objetivos da organizao, mas este
no um critrio de seleo, e cada um dos projetos acompanhado individualmente. Os
projetos acabam tendo srios problemas de atraso, apesar do esforo de seus executantes.
O TRT4 no obtm retorno financeiro de suas atividades e depende do oramento
federal para custeio e investimentos. A falta de relao entre desempenho e oramento elimina
a possibilidade de avaliar o desempenho organizacional por medidas financeiras. Para
contornar isso, pode-se esperar que os processos de gesto que melhoram o retorno dos
investimentos em TI na iniciativa privada funcionem do mesmo modo no TRT4.
Para que um processo de gesto de portflio de projetos de TI possa ser utilizado pelo
TRT4, preciso fornecer meios para que os tomadores de deciso tenham acesso s
informaes de todas as iniciativas propostas, verifiquem as combinaes de iniciativas com
maior potencial e compararem as alternativas entre si, e por fim decidam pelo conjunto de
projetos que acharem mais correto, assumindo os compromissos de riscos, benefcios e uso de
13

recursos deste conjunto de projetos.
2.1 J USTIFICATIVA
O presente trabalho uma oportunidade de aplicar os conceitos de gesto de portflio
de TI aos projetos de tecnologia da informao do Tribunal Regional do Trabalho da 4a
Regio, para ter uma medida do desempenho atual e apresentar possibilidades de melhora aos
seus gestores de maneira relativamente fcil de compreender. O sistema proposto poder ser
usado na prtica, ficando a implementao dos resultados a critrio dos gestores do Tribunal.
Para resolver o problema proposto, preciso primeiro definir quais sero os critrios
para avaliao dos projetos; a seguir, levantar quais restries precisam ser consideradas, para
que os projetos selecionados possam ser executados sem concorrncia por recursos; e ento,
definir quais sero os benefcios esperados da cada um dos projetos. Tais caractersticas daro
origem a um modelo, a ser implementado atravs de um SAD, que listar as combinaes de
projetos possveis, com as respectivas datas ideais de incio. Este sistema deve apresentar
como funcionalidade adicional a comparao, interativa com o usurio, das combinaes
possveis entre si, para que este usurio possa selecionar a combinao que melhor atenda
suas expectativas de benefcios distribudos no tempo.
Este trabalho no pretende indicar como deve ser feita a definio correta dos projetos
ou como execut-los adequadamente, somente como obter a melhor combinao de projetos
em uma dada situao, visando obter os mximos benefcios gerados dentro das restries de
pessoal, oramento e tempo da organizao em estudo. A possibilidade de cada projeto
individual obter sucesso ser mais alta devido ao compartilhamento correto de recursos, e
com o tempo a capacidade de avaliao do uso de recursos durante a fase de planejamento
deve melhorar sensivelmente medida que os projetos no sejam mais suspensos durante a
fase de execuo devido falta de recursos.
2.2 OBJ ETIVOS
A seguir, sero definidos os objetivos geral e especfico do presente trabalho.
14

2.2.1 Objetivo geral
Desenvolver um prottipo de SAD para auxiliar no processo de justificativa dos
investimentos em projetos de TI do TRT4.
2.2.2 Objetivo especfico
Desenvolver um modelo do portflio de projetos de TI do TRT4, incluindo o
levantamento dos requisitos funcionais para o SAD e a implementao do sistema, com as
funcionalidades necessrias para aplicar o modelo desenvolvido ao TRT4. Aplicar o prottipo
ao portflio de projetos de TI do TRT4. Apresentar o prottipo a especialistas para que
avaliem seu uso.
15

3 REVISO DA LITERATURA
Segundo Beltrame e Maada (2009), o valor da TI para as organizaes um os
tpicos de estudo mais evidentes, sendo estudado h mais de 50 anos. As medidas tradicionais
de desempenho financeiro, como retorno sobre investimento ou retorno sobre ativos, nem
sempre so as maneiras mais adequadas de identificar os benefcios resultantes dos
investimentos em TI.
O que estas medidas no conseguem avaliar que a TI no simplesmente uma
ferramenta para para automatizar processos, mas facilitadora de mudanas organizacionais
que podem levar a ganhos de produtividade difceis de mensurar financeiramente
(BELTRAME; MAADA, 2009). Conforme Melville et al. (2004, apud BELTRAME;
MAADA, 2009), o valor da TI para as organizaes pode ser definido como a importncia
dos benefcios que a TI proporciona ao desempenho da organizao nos nveis de processos
intermedirios, como reduo de custos e aumento da produtividade em uma tarefa especfica,
e no mbito de toda a organizao, como criao de vantagem competitiva.
O valor da TI para as organizaes e seu retorno financeiro so difceis de mensurar.
No caso do TRT4, no esperado que os investimentos em TI apresentem qualquer retorno
financeiro, embora algumas iniciativas possam trazer como resultado a reduo de custos
operacionais. A mensurao dos benefcios da TI precisa ser feita de outra maneira, no
financeira.
3.1 GESTO DE PORTFLIO DE TI
A maneira de que a organizao dispe para garantir que as decises relativas aos
investimentos em TI sejam tomadas de maneira a gerar mais valor pela gesto de portflio
de TI. Segundo J effery e Leliveld (2004), a gesto do portflio de TI prov um veculo para
priorizao de investimentos, atendendo aos critrios de clareza de propsito nas decises,
transparncia no processo e monitoramento dos resultados dos investimentos passados. O
processo de priorizao dos investimentos pela gesto de portflio permite que as
responsabilidades sejam bem definidas e que os direitos de deciso sejam devidamente
atribudos, e assim melhora a governana da TI.
A priorizao de alguns projetos em detrimento de outros pode aumentar
consideravelmente a quantidade de projetos concludos. Dinsmore e Cooke-Davies (2006)
citam um caso em que o aumento na quantidade de projetos concludos foi da ordem de 500%
16

em um ano aps uma reunio de priorizao que cancelou 220 dos 292 projetos anteriormente
existentes no portflio de uma empresa britnica do ramo financeiro. O ganho foi devido ao
engajamento dos recursos nos poucos projetos que continuaram e que por isso puderam ser
terminados em prazo mais curto. Este resultado, porm, foi obtido como resultado de um
esforo concentrado, no de um processo bem definido.
As decises de priorizao do portflio de projetos de TI vo definir qual a estratgia
real de TI adotada pela organizao. Por isso, estas decises so de responsabilidade da
gerncia snior, que deve analisar as propostas de investimento em TI quanto ao alinhamento
estratgico e risco (WEILL; WOERNER; RUBIN, 2008).
Aral e Weill (2005) apresentam um framework para gesto de portflio de TI. Um dos
princpios deste framework a diviso dos investimentos em TI em quatro classes e a anlise
da proporo dos investimentos em cada uma delas, que deve ser comparada s distribuies
mdias do tipo de organizao. Ao comparar o portflio da organizao com as mdias de
investimentos de outras organizaes do mesmo ramo, a gerncia snior deve ter poder
justificar pela estratgia de organizao as diferenas que eventualmente sejam encontradas.
3.1.1 Classes de investimentos
Aral e Weill (2005) dividem os investimentos em TI em quatro classes, cada uma com
riscos e retornos distintos: infraestrutura, transacional, informacional e estratgica. As classes
so descritas abaixo:
Infraestrutura: a infraestrutura inclui os investimentos em equipamentos, redes, bancos
de dados e outros que fornecem a base sobre a qual os servios de TI sero prestados. Os
investimentos em infraestrutura podem reduzir custos de TI ou prover uma base flexvel para
as iniciativas futuras.
Transacional: a classe transacional reduz os custos e aumenta a capacidade de operao
pela automao de transaes repetitivas, e composta pelas aplicaes que a organizao
utiliza para suas operaes.
Informacional: os investimentos informacionais so aqueles feitos para obter
informaes sobre contabilidade, gerenciamento ou anlise, por exemplo.
Estratgica: os investimentos estratgicos em TI so os fornecem vantagem
competitiva ou posicionamento no mercado. Os investimentos que so classificados como
estratgicos em determinada circunstncia podero ser classificados de outra maneira,
17

medida que o produto ou servio a que se referem deixem de ser diferenciais ou inovadores.
Um exemplo tpico a adoo de terminais de autoatendimento pelos bancos, que comeou
como um diferencial competitivo investimento estratgico e hoje servem para reduzir
custos, na classe transacional (ARAL; WEILL, 2007).
A figura 3.1 resume contm um resumo destas definies.
A pesquisa de Aral e Weill (2005, 2007) comparou a proporo de investimentos nas
quatro classes entre diversas organizaes. Um dos resultados desta pesquisa foi a constatao
que a distribuio dos investimentos dentre as classes tem correlao com o desempenho das
mesmas, e similar entre organizao do mesmo ramo. A figura 3.2 mostra a distribuio
mdia dos investimentos em TI por classe, segundo a pesquisa de Weill e Aral (2005).
Figura 1: objetivos e exemplos das classes de investimento em TI
Fonte: elaborado pelo autor a partir de Weill e Aral (2005)
18

O portflio de TI deve conter todos os investimentos da organizao, tanto propostos
quanto continuados. As iniciativas sustentadas consumem 66% dos recursos, restando apenas
34% para novos investimentos (WEILL; WOERNER; RUBIN, 2008). As iniciativas
sustentadas incluem manuteno dos sistemas atuais e atualizaes, e os investimentos nestas
iniciativas so vistos como no discricionrios.
O investimento em novas iniciativas muito baixo na maior parte das organizaes
pela proliferao de sistemas e falta de foco na substituio dos sistemas antigos (WEILL;
WOERNER; RUBIN, 2008). O oramento de TI acaba por ser consumido em grande parte
pela manuteno dos sistemas antigos e a parcela a ser investida em novos projetos acaba por
diminuir.
3.2 GESTO DE PROJ ETOS DE TI
Os novos investimentos em TI incluem todas as novas iniciativas e grandes mudanas
F
igura 2: distribuio dos investimentos por classe do portflio de TI
Fonte: elaborado pelo autor a partir de Weill e Aral (2005)
19

em aplicaes e processos existentes, incluindo infraestrutura. Estes investimentos so em
geral aprovados e gerenciados como projetos e programas, dando origem a um portflio de
projetos de TI. Segundo o PMI (2009), um projeto
[...] um esforo temporrio empreendido para criar um produto, servio ou resultado
exclusivo. A sua natureza temporria indica um incio e um trmino definidos. [...]
Temporrio no significa necessariamente de curta durao. Alm disso, geralmente
o termo temporrio no se aplica ao produto, servio ou resultado criado pelo
projeto; a maioria dos projetos realizada para criar um resultado duradouro.
Um grupo de projetos relacionados pode ser gerenciado de modo coordenado para a
obteno de benefcios que no estariam disponveis caso cada um dos projetos fosse
gerenciado individualmente, formando um programa (PMI, 2009). Tanto os programas quanto
os projetos so includos no portflio de projetos da organizao, que definido como [...]
uma coleo de projetos ou programas [...] que so agrupados para facilitar seu gerenciamento
efetivo visando atingir objetivos estratgicos. (PMI, 2008, traduo nossa).
3.3 GESTO DE PORTFLIO DE PROJ ETOS DE TI
O presente trabalho trata da gesto do portflio de projetos de TI, considerado como o
subconjunto dos investimentos em TI formado por novas iniciativas. Conforme Weill,
Woerner e Rubin (2008), Todas as firmas tm mais oportunidades para investir em TI do que
recursos (ou ateno). A efetiva priorizao de projetos de TI uma questo crtica de gesto,
que faz a diferena entre alto desempenho nos negcios e recursos desperdiados. (traduo
nossa).
Estes mesmos autores levantam uma srie de requisitos para o processo de priorizao
dos projetos. Segundo eles,
A priorizao efetiva dos projetos de TI requer clareza de propsitos, processo
decisrio transparente, bons casos de negcio (business cases), um grupo de
tomadores de deciso diverso mas bem balanceado quanto a conhecimento e um
processo de acompanhamento dos resultados que enfatize responsabilidade e
aprendizado. (2008, traduo nossa).
Ghasemzadeh e Archer (2000) enumeram algumas das dificuldades tcnicas para
priorizao de projetos: objetivos mltiplos e conflitantes, alguns dos quais qualitativos;
incerteza e risco; interdependncias entre projetos. Estas dificuldades precisam ser tratadas no
processo de priorizao, especificamente no momento da deciso sobre os projetos
priorizados.
Existem diversos meios para selecionar os projetos a serem executados em um
portflio. Ghasemzadeh e Archer (2000) citam modelos usando retorno econmico, como o
20

de valor presente lquido e taxa interna de retorno; modelos de pontuao (scoring models),
que atribuem uma pontuao a cada projeto de acordo com o grau em que so desejveis;
modelos para otimizao, que indicam a combinao de projetos que maximiza um critrio
(valor presente lquido, por exemplo) dentro das restries existentes, como os recursos
disponveis; e sistemas de apoio deciso, que podem usar uma abordagem de otimizao
para gerar um ponto de partida e a partir deste interagir com o tomador de deciso para
ajustes, levando em conta fatores difceis de modelar como o balanceamento de riscos. Esta
a abordagem considerada mais adequada para a situao do TRT4, em que os resultados
esperados so difceis de quantificar.
3.4 SISTEMAS DE APOIO DECISO
Um SAD um sistema de informao computadorizado que combina modelos e dados
para tentar resolver problemas semiestruturados ou no estruturados, com envolvimento do
usurio (TURBAN et al., 2007). O SAD normalmente composto por pelo menos quatro
subsistemas, que so o gerenciamento de dados, gerenciamento de modelos, interface com o
usurio e os prprios usurios.
O subsistema de gerenciamento de dados contm os dados necessrios para o modelo,
que por sua vez gerenciado pelo subsistema de gerenciamento de modelos. Os modelos
podem ser completos ou elementares, incluindo modelos financeiros, estatsticos ou de
pesquisa operacional. A interface com o usurio composta de todos os aspectos da
comunicao entre os usurios e o SAD. Por fim, os usurios, que incluem os tomadores de
deciso e especialistas. A figura 3.3 mostra alguns dos possveis componentes de um SAD e
sua relao com outros servios da organizao.
21

3.4.1 Tomada de deciso
Turban et al. (2007) dividem o processo de tomada de deciso em quatro etapas:
inteligncia, projeto, escolha e implementao. A etapa de inteligncia aquela em que os
tomadores de deciso examinam a situao e identificam o problema. Na etapa de projeto, os
tomadores de deciso modelam o problema, incluindo suposies que simplifiquem a
realidade, e o modelo validado e os critrios de avaliao das alternativas de soluo do
problema so definidos. Na etapa de escolha, umas das solues possveis para o problema
escolhida. Esta soluo depois utilizada na etapa de implementao, cujo critrio de sucesso
a soluo de problema que ensejou o processo. Em caso de insucesso, retorna-se s etapas
anteriores. A figura 3.4 mostra as etapas que compem este processo, com as atividades
correspondentes a cada etapa do processo.
A anlise da tomada de deciso a seguir baseada e Turban et al. (2007) e Gorry e
Figura 3: componentes do SAD
Fonte: elaborado pelo autor a partir de Turban et al. (2007)
22

Scott-Morton (1971). Estes autores classificaram a tomada de deciso em duas dimenses:
estrutura do problema e natureza da deciso. A estrutura do problema se refere a quo
rotineiro e repetitivo o problema em anlise. J a natureza diz respeito aos tipos de decises
a tomar e ao modo como o tomador de deciso lida com o problema.
Quanto estrutura, um problema pode ser estruturado, no estruturado ou estar entre
os dois extremos. Uma deciso estruturada aquela em que as etapas e procedimentos para
tomada de deciso so bem definidos, ou seja, em que todas as fases descritas acima esto
estruturadas. Deste modo, pode-se especificar algoritmos ou regras para a deciso. Decises
no estruturadas, por outro lado, so aquelas em que nenhuma das etapas bem estruturada e
que acabam sendo tomadas com base na intuio e julgamento pessoal. Entre os extremos,
existem as decises semiestruturadas, em que apenas parte das etapas e processos bem
definida.
A natureza das decises se divide em trs categorias, que so controle operacional,
Figura 4: processo de tomada de deciso
Fonte: elaborado pelo autor a partir de Turban et al. (2007)
23

controle administrativo ou planejamento ttico, e planejamento estratgico.
As decises de planejamento estratgico envolvem os objetivos da organizao e
recursos para alcanar estes objetivos. Um dos principais problemas nesta categoria predizer
o futuro da organizao e do seu ambiente. O processo de planejamento estratgico
tipicamente envolve uma pequena quantidade de pessoas de alto nvel operando de modo no
repetitivo e frequentemente criativo. A complexidade dos problemas desta categoria e a
maneira como so tratados tornam a anlise da qualidade deste processo de planejamento
difcil de avaliar.
A categoria de controle gerencial, ou planejamento ttico, inclui as decises para
garantir que os recursos necessrios estejam disponveis e sejam usados com efetividade e
eficincia para atingir os objetivos da organizao. As atividades de controle gerencial
ocorrem dentro do contexto do planejamento estratgico com interao entre pessoas.
O controle operacional diz respeito execuo de atividades com efetividade e
eficincia. Em comparao com o controle gerencial, a principal diferena que, enquanto o
controle gerencial envolve principalmente pessoas, o controle operacional trata de atividades
cujas metas e recursos j foram definidos.
3.4.2 Informaes para tomada de deciso
Embora no exista um limite claro entre as categorias, a distino entre os tipos de
deciso til para analisar os requisitos de informao para cada categoria. As informaes
para planejamento estratgico so agregada, no precisam de muita preciso e podem ser
obtidas de fontes externas, mas por outro lado so mais variadas. As informaes necessrias
para controle operacional precisam ser bem definidas, precisas e detalhadas. Entre estes dois
extremos, as informaes para controle gerencial tem como caracterstica serem obtidas
principalmente pela interao pessoal. A figura 3.5 resume a relao entre as categorias de
deciso e as necessidades de informao.

Caractersticas da
informao
Controle operacional Controle gerencial
Planejamento
estratgico
Fonte Interna Externa
Escopo Bem definido, estreito Muito amplo
Nvel de agregao Detalhada Agregada
Horizonte de tempo Histrico Futuro
Atualidade Muito atual Anterior
24

Preciso requerida Alta Baixa
Frequncia de uso Muito frequente Espordico
Figura 5: informao necessria por categoria de deciso
Fonte: Gorry e Scott-Morton (1971)

A partir de uma matriz cruzando os tipos de problemas e categorias de deciso,
possvel listar alguns exemplos de atividades, como na figura 3.6 . As decises nas atividades
das clulas 1, 2 e 4 so geralmente tomadas por gerentes de nvel hierrquico inferior,
enquanto as decises referentes s clulas 6, 8, e 9 so de responsabilidade dos executivos
seniores.

Natureza da deciso
Controle operacional Controle gerencial Planejamento estratgico
Tipo
Estruturado
Contas a receber
Entrada de pedidos
1
Anlise oramentria
Relatrios pessoais
2 Gerncia financeira
Sistemas de
distribuio
3

Semiestruturado
Progr. da produo
Controle de estoque
4
Avaliao de crdito
Layout de fbrica
5 Fuses e aquisies
Planejamento de
novos produtos
6

No-estruturado
Comprar software
Aprovar emprstimos
7
Contratar executivo
Comprar hardware
8 Planejamento de P&D
Desenvolvimento de
novas tecnologias
9

Figura 6: matriz de decises
Fonte: Turban et al. (2007)

Os sistemas de apoio deciso so utilizados para apoiar decises semiestruturadas ou
no estruturadas. Nestes casos, as fases estruturadas do problema em questo podem ser
modeladas e as demais podem ser analisadas pelo tomador de deciso. importante que o
modelo do processo de deciso seja construdo antes do projeto do sistema, de modo a
garantir uma boa perspectiva das aplicaes em potencial de sistemas de apoio.
25

4 MTODO
O presente trabalho consistiu no desenvolvimento de um prottipo de SAD para gesto
de portflio de projetos, adaptado realidade dos projetos de TI do TRT4 e a demonstrao
deste prottipo com os dados reais destes projetos.
Para implementar o prottipo do sistema de automao da gesto de portflio de
projetos de TI, primeiramente foi necessrio levantar os requisitos de uso junto aos usurios e
criar um modelo do portflio, com todos os participantes, seus atributos e relaes. A seguir, o
prottipo de SAD usando este modelo foi implementado e testado com dados reais e ajustado.
Como ltima etapa, o SAD foi utilizado com dados reais da Secretaria de Tecnologia da
Informao do TRT4 (STI), e o resultado obtido foi comparado ao estado atual do portflio de
projetos.
4.1 ORGANIZAO E AMBIENTE
A organizao a ser estudada neste trabalho a STI. Esta organizao responsvel
pelo atendimento de todas as demandas de TI da 4a Regio da J ustia do Trabalho, que
abrange o estado do Rio Grande do Sul.
O TRT4 composto pelo prprio Tribunal, situado em Porto Alegre, e mais 115 Varas
do Trabalho, 30 das quais em Porto Alegre e as demais distribudas pelo interior do estado,
alm de diversos setores de apoio, dentre os quais a STI. O quadro de pessoal da 4a Regio
conta com cerca de 3.500 servidores.
A STI, por sua vez, conta com 77 servidores de diversas especialidades. A STI est
estruturada em quatro Diretorias e treze Coordenaes, conforme o organograma da figura
4.1. Todos os servios de TI utilizados na 4a Regio so fornecidos pela STI, desde o
desenvolvimento de aplicaes, servio de banco de dados, redes de comunicao e
servidores at o fornecimento de equipamentos pessoais e suporte aos usurios.
26

Para coordenar a execuo de seus projetos, a STI conta com um Escritrio de Projetos
divisional, com atribuies bastante limitadas. O Escritrio de Projetos definiu e mantm as
metodologias de gesto de projetos e de portflio de projetos utilizadas pela STI e coleta
informaes geradas pelos gerentes dos projetos em execuo, alm de apoi-los no seu
trabalho, e responsvel pelo gerenciamento de alguns projetos, mas no tem
responsabilidade pela definio ou pela priorizao do portflio.
4.2 DESENVOLVIMENTO DO SISTEMA
O desenvolvimento do sistema foi planejada para quatro iteraes de uma semana, de
acordo com o mtodo XP (LARMAN, 2004). O contedo planejado para estas iteraes foi:
diagrama de classes
arquitetura
ambiente de desenvolvimento
biblioteca de classes
interface web
Figura 7: Organograma da STI
27

testes com dados reais
Cada uma das iteraes deveria dar origem a um aspecto ou funcionalidade pronto do
sistema, que assim poderia ser testado e os prximos requisitos ento reavaliados. Devido a
problemas encontrados na implementao da interface web, o sistema foi modificado para
usar uma interface desktop padro Windows e uma iterao adicionada para isto, conforme
previsto pelos mtodos em que o processo de desenvolvimento foi baseado (SCHWABER,
2004; LARMAN, 2004).
4.2.1 Definio dos requisitos
Parte dos requisitos foi definida a partir do estudo da literatura relevante e parte foi
levantado junto aos usurios do sistema, e posteriormente os requisitos foram documentados
na forma de user stories (COHN, 2004). Como limitao do prottipo, apenas dois usurios
foram entrevistados para levantamento de requisitos, um representando o perfil de usurio
tcnico, responsvel por alimentar o SAD com informaes sobre os projetos, e outro
representando os usurios tomadores de deciso, que utilizam o sistema para auxiliar nas
decises de portflio de projetos.
Devido ao prazo curto de desenvolvimento, os requisitos no foram priorizados com os
usurios antes de cada ciclo de implementao. A abordagem utilizada foi definir inicialmente
os recursos de infraestrutura necessrios, depois implementar as funcionalidades que
acrescentam maior valor ao prottipo, conforme indicado por Cohn (2004). Por ser um
prottipo com objetivo de validar um meio de gerir o portflio de projeto, as funcionalidades
relativas facilidade de uso no foram priorizadas, especialmente para as operaes de
alimentao do sistema com dados do portflio.
4.2.2 Definio da arquitetura do sistema
O SAD desenvolvido neste trabalho foi um prottipo para validar o mtodo de apoio
ao processo de deciso sobre portflio de projetos, e por isso no dar origem a algum sistema
de produo. Essa caracterstica permite mais liberdade nas decises referentes arquitetura
do sistema, que no precisa seguir nenhum padro em uso no TRT4.
O prottipo de sistema foi inicialmente baseado em ferramentas e bibliotecas open
source, pela facilidade de acesso s informaes necessrias e para evitar que problemas com
28

prazo de licenciamento, por exemplo, impedissem que o sistema continuasse em uso aps a
demonstrao. Para reduzir o risco de mau funcionamento do sistema devido a condies do
ambiente de testes, o sistema foi planejado para executar a partir de uma mquina virtual
rodando sistema operacional Linux, que serviu de ambiente de desenvolvimento e poderia ser
copiada para uma mquina do TRT4 para executar a demonstrao. Para que o sistema fosse
acessvel pelos usurios sem que estes tivessem que usar a mquina virtual, seria necessrio
que o sistema rodasse como um servidor web, ao qual os usurios poderiam conectar-se
usando o browser instalado nas suas estaes de trabalho.
A arquitetura inicial teve de ser alterada devido baixa qualidade e deficincia de
documentao de alguns componentes selecionados, principalmente do servidor web. Optou-
se por desenvolver a interface do sistema como uma aplicao padro para plataforma
Windows, o que permitiu que os testes fossem executados mas reduziu as possibilidades de
compartilhamento de informaes em relao ao sistema web inicialmente previsto.
A principal ferramenta de desenvolvimento foram os compiladores C++dos ambientes
Windows e Linux. A linguagem C++foi selecionada pela quantidade de software open source
disponvel e pela familiaridade do autor e no pelo desempenho, que no um fator
importante na operao de um SAD (GORRY; SCOTT-MORTON, 1971). Os outros
componentes de software foram definidos a partir dessa seleo.
4.2.3 Modelagem, codificao e testes do sistema
As classes principais do sistema foram documentadas usando a linguagem UML. A
documentao foi feita apenas como esboo para facilitar a compreenso do sistema,
conforme definido por Fowler (2005). Os modelos foram feitos usando o editor de desenhos
do software de escritrio OpenOffice.
Os modelos criados inicialmente foram modificados durante a codificao, de acordo
com a resoluo das dificuldades encontradas. Como este prottipo implementou um modelo
do portflio de projetos como seu elemento principal, deixando a interao com o usurio em
segundo plano, o principal tipo de diagrama utilizado foi o diagrama de classes. Este tipo de
diagrama o mais adequado para representar aspectos estticos do sistema.
Os testes do sistema se limitaram a testes funcionais, para validar a implementao dos
requisitos. Pelo tamanho do sistema e durao do projeto, a adoo de alguma outra
metodologia de testes associada a mtodos geis, como test-driven development, seria
29

excessivamente dispendiosa em termos do tempo necessrio para configurao do framework
de testes e codificao dos testes unitrios. A incluso de testes no cdigo tornaria o sistema
mais robusto, mas foi assumido o risco da ocorrncia de problemas durante a avaliao do
portflio da STI, tendo mais cuidado para garantir a qualidade dos dados utilizados para
compensar a fragilidade do sistema quanto a entradas incorretas.
Os testes de desenvolvimento foram feitos com dados fictcios at o final da iterao
final, quando o portflio de projetos de TI foi modelado para a avaliao do portflio da STI.

30

5 RESULTADOS
O prottipo completo inclui dois tipos de modelo, o modelo do software desenvolvido
e o do portflio de projetos. O primeiro se refere ao modelo no sentido usado pela UML, de
artefatos de software a serem codificados ou integrados, enquanto o segundo se refere ao
modelo do portflio de projetos, com seus atributos e variveis de deciso e objetivo.
O prottipo inclui, alm do software desenvolvido para demonstrao, uma arquitetura
de hardware e software sobre a qual o software executa. A incluso dos outros itens da
arquitetura visa diminuir as dificuldades advindas de executar o sistema sobre uma plataforma
que esteja fora do controle, e que por isso pode apresentar incompatibilidades de rede,
biblioteca de sistema ou mesmo de direitos de acesso, como pode ocorrer ao se executar um
sistema baseado em servidor web em uma rede corporativa.
5.1 DESENVOLVIMENTO DO PROTTIPO
A arquitetura do prottipo inclui o hardware e software de suporte para a soluo
implementada. Como hardware, foi definido que uma mquina virtual mais adequada, pela
facilidade de implantao e de manuteno. A mquina virtual pode ter seu estado copiado
para um arquivo no sistema hospedeiro e transportado para outras mquinas fsicas, mesmo
rodando sistemas operacionais diversos. O software de virtualizao escolhido foi o Sun
Virtualbox
1
, que tem uma verso open source e pode rodar em hospedeiros Windows e Linux.
As outras opes avaliadas, Microsoft VirtualPC
2
e VMWare
3
(este nas opes Workstation e
Player), tem mais restries de licenciamento e por isso podem ter uso limitado em um
ambiente corporativo. O quadro 5.1 resume as caractersticas de cada uma das solues para
virtualizao consideradas.
Soluo Fornecedor Licena Caractersticas
Virtualbox Sun GPL open source
roda em hospedeiros Windows e Linux
roda sistemas Windows e Linux
VirtualPC Microsoft Comercial software comercial
roda apenas em hospedeiros Windows
suporta apenas sistemas Windows
VMWare Workstation VMWare Comercial software comercial

1 Documento eletrnico
31

VMWare Player VMWare Comercial software comercial
no permite a criao de mquinas virtuais, apenas
executa mquinas virtuais existentes
Quadro 1: softwares para mquinas virtuais analisados

O sistema operacional da mquina virtual o Debian Linux
4
na verso estvel,
escolhido devido estabilidade comprovada e disponibilidade de software pronto para uso.
Este sistema acessvel remotamente pela interface de rede usando o protocolo Remote
Desktop, o que facilita a preparao do ambiente e o desenvolvimento da soluo.
O sistema roda em um servidor web, para fornecer acesso remoto usando um browser
padro e assim diminuir a dependncia de bibliotecas ou de configurao nas mquinas dos
usurios. As opes avaliadas foram o Apache
5
, que o servidor web mais utilizado no
mundo e que possui diversos plug-ins para facilitar a integrao com outros sistemas; o
servidor de aplicaes Apache Tomcat
6
, que roda aplicaes J ava; e o servidor web integrado
fornecido com a biblioteca de aplicaes web Wt
7
. Optou-se por utilizar o servidor integrado
da Wt, pela simplicidade de configurao e uso, e principalmente por suportar a linguagem de
programao C++. O armazenamento dos dados feito no sistema Debian onde o servidor
web est rodando, usando arquivos em formato Extensible Markup Language (XML). O
programa principal do SAD, desenvolvido em C++, acessvel diretamente pelo servidor web
Wt.
Vrias das decises de arquitetura do sistema puderam ser feitas devido ao objetivo do
trabalho ser apenas um prottipo de SAD, sem visar um sistema apto para ser aperfeioado e
posto em produo. Em um sistema de produo, aspectos como segurana da informao,
autenticao dos usurios e disponibilidade do sistema levariam a opes diferentes.
Para um sistema de produo, o servidor web precisa ser mais robusto e estvel,
suportando tambm um sistema de autenticao e autorizao dos usurios para acesso ao
sistema. Os dados deveriam ser armazenados em um banco de dados, que poderia ser
tradicional, como MySQL
8
, ou um banco de dados sem esquema para simplificar a
modelagem, como MongoDB
9
. O TRT4 est padronizando seus sistemas com uso da
linguagem de programao J ava e servidor de aplicaes J Boss, e o sistema deveria ser

32

planejado seguindo este padro.
5.1.1 Modelo de classes do prottipo
O portflio de projetos de TI do TRT4 foi modelado com base nas informaes que so
documentadas atualmente para estes projetos, acrescidas das dimenses do portflio de TI
conforme definidas por Weill e Aral (2005). Os recursos disponveis para execuo de
projetos foram levantados a partir da documentao da STI.
A STI, atravs de seu Escritrio de Projetos, documenta todas as iniciativas que deram
origem a projetos formais. O primeiro documento de cada projeto, ainda como proposta, um
termo de abertura, que indica as necessidades que o projeto proposto deve atender e quais so
os recursos necessrios. A partir da aprovao do projeto, um plano de projeto mais detalhado
redigido, e aps o incio da execuo o gerente do projeto passa a emitir relatrios de estado
peridicos. Os relatrios de status atualmente no contm informaes teis para a gesto do
portflio, mas eventuais alteraes em prazo e uso de recursos devem ser documentadas no
plano do projeto. No existe um processo formal de controle das informaes do plano de
projeto, o que faz com que alguns destes planos fiquem defasados em relao ao andamento
real dos projetos.
O modelo precisa permitir que sejam feitas algumas concesses realidade do TRT4.
Alguns projetos de TI precisam ser executados por exigncia legal em determinado perodo,
por isso precisam ser includos no portflio e planejados para concluso neste perodo. Alm
disso, o portflio de projetos atual excede a capacidade de execuo, e isto precisa ser
permitido, com uma indicao de aumento no risco dos projetos em que recursos com
alocao excessiva participem.
5.1.2 Funcionalidades bsicas do sistema
O objetivo da execuo do sistema obter uma combinao de projetos dispostos no
tempo de modo a compartilhar corretamente os recursos do TRT4 e oferecer o maior
benefcio, com apoio do usurio tomador de deciso. A figura 5.1 mostra um exemplo de
matriz de projetos, com seis projetos distribudos por seis perodos.
33

Neste exemplo, os projetos de nmero 1, 3, 4 e 6 sero priorizados para execuo,
enquanto os de nmeros 2 e 5 no esto com execuo prevista. Os benefcios de cada projeto
sero obtidos ao final da execuo, no perodo indicado pelo nmero em negrito.
Existem dois tipos de usurios no sistema, o Escritrio de Projetos e o tomador de
deciso. O Escritrio de Projetos responsvel por inserir os dados iniciais no sistema e
mant-lo atualizado, para que o tomador de deciso possa fazer a priorizao e comparar
alternativas.
Os portflios j priorizados podem ser salvos e recuperados, alm de comparados entre
si. A sada do sistema se d atravs de grficos com os projetos distribudos no tempo com na
figura 5.1 e grficos de barras indicando os benefcios obtidos. Nas comparaes entre
portflios, o desempenho dos dois portflios comparados so apresentados no mesmo grfico,
acrescidos de uma indicao da diferena de desempenho.
5.1.3 Implementao do prottipo
O desenvolvimento do sistema foi planejado com quatro iteraes de uma semana at o
teste inicial, com dados reais, e mais uma iterao de uma semana para ajuste do modelo. O
processo de desenvolvimento foi baseado em XP (LARMAN, 2004), mas, por ser um projeto
individual, poucas prticas deste mtodo puderam ser adotadas.
O plano sofreu algumas alteraes devido a dificuldades tcnicas encontradas, que
provocaram mudanas de arquitetura e cronograma. Estas alteraes foram facilitadas pelo
uso do mtodo gil, que ajudou a garantir que parte do esforo j dispendido pudesse ser
aproveitado porque as iteraes anteriores haviam produzido funcionalidades completas e
testveis, de acordo com o que defendido por Schwaber (2004).
Figura 8: exemplo de matriz de projetos
34

5.1.4 Configurao do ambiente
O ambiente descrito na seo foi configurado em um PC rodando Windows XP SP3,
dispondo de 1,5 GB de memria e com processador AMD AthlonX2 3800+. Todo o software
utilizado na mquina virtual, incluindo o sistema operacional, foi baixado dos sites dos seus
respectivos desenvolvedores.
O servidor de mquinas virtuais Virtualbox foi instalado a partir de um instalador
padro para Windows, que responsvel por toda a configurao. Aps a instalao foi criada
uma mquina virtual com as pr-configuraes do Virtualbox para Linux, usando 512 MB da
memria do hospedeiro e disco virtual de 8 GB.
A instalao do sistema operacional Debian a partir do CD de instalao foi bem direta
e no causou dificuldades. Aps a instalao, alguns pacotes adicionais foram instalados com
o uso do programa de controle pacotes padro do Debian, chamado Synaptic. As bibliotecas
de classes utilizadas pelo prottipo foram baixadas como pacotes de cdigo-fonte e
compiladas localmente.
A primeira biblioteca a ser compilada foi a Boost, da qual as outras dependem para
algumas funcionalidades. O pacote de cdigo-fonte foi copiado e descompactado, depois a
biblioteca foi compilada usando o compilador C++padro do Debian. A seguir, o pacote de
cdigo-fonte da biblioteca de classes web Wt foi copiado, descompactado e compilado em um
processo similar ao da biblioteca Boost. O ambiente de desenvolvimento e testes estava ento
pronto para uso, e acessvel remotamente usando o protocolo Remote Desktop, que padro
dos sistemas operacionais Windows.
5.1.5 Requisitos iniciais
Os requisitos iniciais dos usurios foram coletados durante a primeira iterao, atravs
de entrevistas com a coordenadora do Escritrio de Projetos, que forneceu requisitos do perfil
de usurios do Escritrio, e da diretora da STI, que forneceu os requisitos do perfil tomador
de deciso. Os requisitos foram coletados como user stories e documentados em formato de
texto simples.
35

5.1.6 Implementao das classes
As classes definidas no incio do processo de desenvolvimento foram implementadas
como classes C++, sendo as classes de interface definidas apenas em um arquivo de
cabealho e as classes concretas em um arquivo cabealho e um arquivo-fonte. Cada classe
deu origem a um arquivo ou par de arquivos.
As principais classes implementadas foram Projeto, Recurso e Portflio. A partir do
incio da implementao foi possvel definir melhor os requisitos de cada classe,
principalmente os requisitos voltados interao com o ambiente, como armazenamento e
recuperao dos dados.
5.1.6.1 Atributos
Os diagramas de classe no incluem parte da informao necessria para modelar o
portflio de projetos, que so os valores de alguns atributos. Tais valores foram buscados na
literatura de gerenciamento de projetos ou na documentao de gerenciamento de projetos do
TRT4.
A metodologia de gerenciamento de projetos do TRT4 define dois nveis de
comprometimento dos recursos humanos com um projeto, que so o envolvimento parcial e
integral. O envolvimento parcial , por definio, equivalente a usar 25% da capacidade de
um recurso humano que esteja disponvel em tempo integral para participar de projetos. Este
valor para nvel de envolvimento baseado em observao, no em pesquisa formal, por isso
uma possvel fonte de erros de avaliao. Cada projeto tem suas particularidades e uma
necessidade de envolvimento diferente para cada um dos participantes, mas o uso de um valor
fixo para estes atributos serviu para avaliar a capacidade e consumo de recursos de maneira
agregada.
5.1.7 Iteraes
A implementao foi planejada para durar quatro iteraes de uma semana cada, de
acordo com o que defendido pelo mtodo XP. A cada iterao foi preciso priorizar os
requisitos restantes, para garantir que o esforo foi dedicado aos aspectos mais importantes do
sistema.
36

Foi previsto que ao final destas quatro iteraes o sistema estaria utilizvel para testes,
os dados iniciais estariam inseridos e os resultados de uma execuo estariam disponveis para
avaliao. A lista inicial de requisitos foi a do quadro 5.2.

Preparao do ambiente de desenvolvimento
Diagrama de classes
Classes do modelo
Classes de criao e interao
Armazenamento e recuperao de dados
Interface com usurio
Anlise de portflio
Modelo para otimizao matemtica
Comparao entre portflios
Edio dos entes do modelo pela interface de usurio
Quadro 2: requisitos iniciais

5.1.7.1 Iterao 1
A primeira iterao foi consumida inteiramente pela preparao do ambiente de
desenvolvimento e criao do diagrama de classes. A mquina virtual foi instalada em um
hospedeiro rodando Windows XP, em seguida o sistema operacional Debian foi instalado
nesta mquina virtual.
O sistema operacional fornece ferramentas de desenvolvimento bsicas, as quais foram
adicionados alguns outros componentes. O principal componente foi a biblioteca de classes
Boost
10
, da qual o servidor web Wt depende e que fornece algumas facilidades para o
desenvolvimento de sistemas mais robustos. Tanto Boost quanto Wt so fornecidos como
cdigo-fonte e por isso precisam ser compilados para cada sistema em que so usados.
Alm do sistema principal para execuo do prottipo, um ambiente de
desenvolvimento de apoio foi instalado em um computador rodando Windows 7 com
ferramentas de desenvolvimento da Microsoft. Este sistema serviu para facilitar a codificao,
ao evitar que fosse necessrio acessar a mquina virtual sempre que fosse necessrio

37

modificar o cdigo, e por fim serviu como ambiente principal de execuo no final do
processo de desenvolvimento.
A preparao do ambiente foi um processo demorado devido s dependncias de
cdigo do servidor Wt, que exigiram a instalao de diversos outros componentes open
source. Cada um destes componentes teve um processo de configurao e instalao prprios,
eventualmente exigindo que mais algum componente fosse obtido, compilado e instalado. Ao
final da iterao, a arquitetura planejada estava preparada e dois ambientes de
desenvolvimento estavam prontos para uso.
5.1.7.2 Iteraes 2 e 3
A segunda e terceira iteraes serviram para criar os diagramas de classe apresentados
anteriormente e para codificar as classes em C++. Estas classes foram sofrendo alteraes
medida que o desenvolvimento prosseguiu devido a dificuldades imprevistas e necessidades
prticas do uso destas classes, como controle do ciclo de vida dos objetos.
As principais ferramentas utilizadas nestas iteraes foram os compiladores C++da
GNU Compiler Collection11, que so utilizados como padro no Linux e esto disponveis
em diversas plataformas. O ambiente de desenvolvimento utilizado foi o NetBeans
12
, que
oferece diversas facilidades para edio de cdigo-fonte, como a verificao em tempo real
do cdigo sem compilao.
Foi criada uma classe para gerenciamento dos recursos e projetos disponveis, para que
a definio de um portflio pudesse ser feita em termos dos projetos distribudos no tempo. O
uso de recursos e a proporo de investimento em cada classe determinada pelos projetos
em execuo em cada perodo, portanto como resultado da definio de um portflio de
projetos.
A sequncia de procedimentos para criar um portflio de acordo com as definies
deste modelo a que segue:
a) criar o arquivo com dados dos recursos e projetos;
b) iniciar a execuo do sistema;
c) carregar os dados de projetos e recursos a partir do arquivo;
d) criar novo portflio ou carregar portflio existente;
e) inserir, modificar ou excluir projetos neste portflio. Cada projeto inserido com

38

um atraso, positivo ou negativo, associado. O atraso serve para indicar quais
projetos devem ser iniciados em perodos subsequentes (se positivo) e quais
projetos j esto em execuo (quando negativo). Atraso nulo indica que o projeto
deve iniciar no perodo atual;
f) verificar o uso e disponibilidade de recursos. Modificar o planejamento de projetos
de acordo com essa verificao;
g) avaliar a alocao de recursos de acordo com as classes de investimento, e ajustar
os projetos conforme necessrio.
A primeira etapa deste procedimento atribuio do Escritrio de Projetos e as demais
do usurio tomador de deciso. A disponibilidade de recursos em cada perodo no foi
considerada uma restrio ao seu uso, mas o uso excessivo de recursos foi modelada no
sistema para fornecer uma indicao ao usurio.
A classe GerProj foi criada para controlar o acesso aos objetos Recurso e Projeto, que
so criados uma s vez e compartilhados com todas as instncias de Portflio que forem
criadas. A classe GerProj foi codificada seguindo o padro de projeto Singleton (GAMMA et
al., 2000), que serve para garantir que apenas uma instncia desta classe pode existir no
sistema. Alm disso, os objetos foram criados usando smart pointers, que garantem a
existncia dos objetos durante o tempo em que esto sendo utilizados e a liberao dos
recursos utilizados assim que os objetos se tornam desnecessrios. Estas providncias ajudam
a garantir que o desenvolvimento do sistema ocorra sem perda de tempo com depurao
devido ao mau uso de objetos compartilhados, que so uma grande causa de erros difceis de
resolver em sistemas que usam ponteiros comuns
13
.
Foi decidido pelo armazenamento dos dados e dos portflios em arquivos texto, no
formato de valores separados por vrgula. Esse formato fcil de processar e muito flexvel, e
foi escolhido por facilitar as alteraes de formato e por evitar mais um ponto de risco
tcnico, que seria o uso de um banco de dados para estes dados. Por outro lado, o formato
separado por vrgula no estruturado e muito sujeito a erros. A soluo para estas

13 Um ponteiro uma referncia localizao de um objeto alocado em memria, que por isso pode ser criado
por outro objeto e compartilhado com outros que acessam a mesma referncia (Stroustrup). O problema deste
compartilhamento que o objeto precisa existir, isto , a regio de memria que o objeto utiliza precisa estar
disponvel para todos os outros objetos que o compartilham exatamente durante o tempo em que o objeto
necessrio. Caso o objeto seja destrudo (ou seja, a memria que ele utiliza seja liberada) enquanto ele ainda
necessrio, a prxima tentativa de acesso vai causar um erro de sistema; caso ele continue existindo depois
que as referncias a ele sejam destrudas, a memria e outros recursos que o objeto esteja utilizando sero
irrecuperveis, causando o chamado vazamento de memria. Os smart pointers so objetos que se
comportam como ponteiros comuns para compartilhamento, mas que garantem que a memria esteja
disponvel exatamente durante o tempo necessrio e que aps isso os recursos sejam liberados.
39

dificuldades seria o uso de um formato baseado em XML, conforme planejado, a ser
implementado em outra iterao. O formato para armazenamento dos dados transparente
para o usurio tomador de deciso, sendo de alguma importncia apenas para o Escritrio de
Projetos.
O formato do arquivo com os dados dos projetos e recursos o da figura 5.2. Cada
linha corresponde a um objeto do sistema; a primeira parte indica o tipo de objeto e o restante
indica os dados do objeto. O uso do tipo de objeto permitiu que o arquivo inteiro fosse
processado uma s vez para os dois tipos atuais de objetos, que seguem o padro de projetos
Prototype (GAMMA et al., 2000). Cada objeto criado corretamente a partir dos dados
seguintes, sem que o sistema precise analisar a sequncia de caracteres que o define.
O trecho de arquivo no exemplo serve para criar dois Recursos, de nomes Lemmy
Caution e Tom Araya, com as respectivas disponibilidades, e um Projeto chamado
Abstrao de Quintessncia, de classe estratgica, com seis meses de durao e que usa os
dois Recursos criados anteriormente. O arquivo de definio de objetos nico para o
sistema.
O formato de arquivo para dados de portflio diferente. A primeira linha til do
arquivo uma data, que serve para indicar o ms inicial do portflio. As linhas seguintes so
descries de projetos dentro do portflio. O primeiro item o nome, que deve ser idntico ao
do arquivo de dados, e o segundo o deslocamento. A indicao do deslocamento serve para
ajustar a data de incio do projeto dentro do horizonte de planejamento, tanto para menos
(indicando um projeto que j est em execuo) quanto para mais (indicando um projeto que
iniciar mais tarde).
Figura 9: formato do arquivo de objetos do sistema
40

O portflio precisa ser carregado no sistema depois da carga dos dados de recursos e
projetos. O processamento de cada linha provoca um reclculo de todo o portflio, alterando o
uso de recursos, a distribuio do uso de recursos entre as quatro classes de investimento e
eventualmente a durao do perodo de planejamento. Caso o mesmo projeto seja carregado
mais de uma vez, a ltima carga prevalecer, pois cada projeto pode aparecer apenas uma vez
no portflio.
Os requisitos implementados at o final da terceira iterao no dependiam de
interface de o usurio. O processamento foi feito todo por programas de teste em linha de
comando, gerando sada para o terminal e para arquivos texto como sada. Ao final desta
iterao, o principal mdulo do sistema estava pronto para ser integrado a uma interface de
usurio.
5.1.7.3 Iterao 4
Para a quarta iterao, foi prevista a criao da interface de usurio baseada em
browser. Para isso, o servidor Wt criado na primeira iterao foi utilizado para montar as
pginas e prover a interao com o usurio, sendo necessrio criar o cdigo para tal.
A interface de usurio foi definida como um painel, que permitiria que o usurio
editasse o portflio de projetos vendo imediatamente os resultados de suas opes, similar
da figura 5.4.
Figura 10: formato de arquivo para portflio
41

A implementao da interface foi dificultada pela falta de documentao do servidor
web Wt. A principal documentao do servidor o prprio cdigo-fonte, j que o sistema
open source, e alguns exemplos. O servidor Wt tem algumas capacidades de gerao de
grficos que foram consideradas muito teis no momento da seleo deste componente, mas
que na prtica se demonstraram difceis de usar pela falta de documentao.
Os exemplos de utilizao fornecidos pelo fabricante variam entre simplrios e
excessivamente detalhados. Alguns aspectos importantes da implementao de servios com
Wt ficam esclarecidos pelos exemplos mais simples, mas os mais complexos contm tantos
detalhes que se demonstraram inteis como elemento de apoio para o desenvolvimento do
sistema, ao menos considerando o tempo disponvel.
Ao final desta iterao optou-se por alterar radicalmente a arquitetura do sistema, de
modo a ter alguma maneira de demonstrar o conceito que o objetivo do trabalho
reduzindo o risco tcnico, em troca de um esforo mais acentuado nas iteraes seguintes. Foi
necessrio, alm disso, reduzir as funcionalidades do sistema para finaliz-lo a tempo e fazer
testes com dados reais.
A nova arquitetura passou a utilizar um sistema desktop baseado em plataforma
Figura 11: interface inicial do sistema
42

Windows. A apresentao continua sendo similar prevista para o ambiente baseado em
browser, com o acrscimo de algumas facilidades oferecidas pelo uso do desktop, como
menus em lugar dos botes.
Para reduzir o risco tcnico da nova soluo e compensar em parte o atraso ocorrido, o
ambiente de desenvolvimento escolhido foi o Visual C++2005 Professional
14
, usando o
framework Qt
15
para a interface de usurio. O framework Qt foi a principal influncia no
desenvolvimento do servidor web Wt, por isso esta opo pode permitir que mais tarde o
sistema seja portado para a arquitetura prevista originalmente. O uso do Visual C++2005
inclui um componente de cdigo-fonte proprietrio no sistema, em troca de oferecer mais
agilidade no desenvolvimento por sua integrao com o Qt. O cdigo-fonte produzido
continua a ser portvel para outras plataformas e compiladores, por isso a opo pelo C++no
implica em uma mudana drstica nas opes feitas no planejamento do sistema.
A mudana de arquitetura exigiu uma nova compilao da biblioteca Boost e a gerao
do framework Qt a partir do cdigo-fonte obtido. A gerao do Qt exigiu cerca de seis horas
ininterruptas de compilao no sistema utilizado, o que se deve tanto complexidade e
tamanho do framework quanto debilidade do equipamento utilizado no processo.
O processo de mudana de arquitetura no estava concludo ao final da quarta iterao
e exigiu algum esforo no incio da iterao seguinte, quando a implementao da interface de
usurio foi reiniciada. O mdulo do sistema que trata de gesto de portflio no precisou de
nenhuma alterao devida esta mudana por ter sido codificado usando os padres de C++,
sendo por isso portvel.
5.1.7.4 Iterao 5
A quinta e ltima iterao do desenvolvimento do prottipo iniciou com a continuao
da preparao do ambiente de desenvolvimento para o sistema desktop. Aps a preparao,
uma interface de usurio foi criada utilizando o editor de interfaces do Qt, utilizando uma
tabela para apresentar os dados, com um formato similar a uma planilha.
Aps alguns testes, esta interface pareceu muito pouco intuitiva, mesmo utilizando
cores para indicar a condio de alguns aspectos do portflio. A utilizao e disponibilidade
dos recursos, por exemplo, precisava ser exibida de modo grfico para facilitar a tomada de
deciso. Alm disso, seria ideal que as informaes referentes ao mesmo perodo ficassem

43

alinhadas verticalmente para que ficasse mais claro quais projetos estariam causando alguma
distoro, e assim facilitar a correo do problema.
A soluo encontrada foi utilizar uma imagem para dispor todas as informaes,
desenhando o grfico elemento a elemento. Para gerar a imagem, foi utilizada uma classe do
framework Qt, chamada QPixmap (BLANCHETTE; SUMMERFIELD, 2006), que representa
uma rea de tela disponvel para desenho. Os grficos correspondentes ao cronograma, classes
de investimento, projetos e recursos foram ento desenhados sobre esta rea de tela.
Para cada tipo de informao, foi definido o uso de um tipo diferente de grfico, de
acordo com aspecto que foi considerado mais importante apresentar. As informaes em que o
aspecto mais importante a proporo entre os valores foram apresentadas como barras,
informaes cuja evoluo importante foram apresentadas como linhas e os projetos foram
apresentados com um grfico de Gantt. As informaes qualitativas foram apresentadas como
cores.
Para a proporo de investimentos em cada classe, foram sobrepostos dois grficos,
com uma barra indicando a proporo de investimento no ms atual e uma linha com o valor
acumulado. As cores utilizadas neste grfico foram as mesmas do diagrama das classes de
investimento. Como o valor exato da proporo de investimento acumulado a informao
mais importante, seu valor foi indicado como porcentagem no alto da linha.
O grfico utilizado para indicar o perodo de atividade dos projetos foi um grfico de
Gantt, que a maneira mais usual de apresentar este tipo de informao. Como no foi
considerado necessrio indicar alguma outra condio, todos os projetos so apresentados
Figur
a 12: grfico de classes de investimento
44

com a mesma cor.
O uso de recurso foi apresentado como um par de barras, indicando o uso e a
capacidade no ms. A barra indicadora de uso foi colorida conforme a proporo de uso, com
barra vermelha indicando uso excessivo, amarela indicando limite de uso e verde indicando
uso abaixo da capacidade. A barra cinza indica a capacidade do recurso. As duas barras so
proporcionais entre si e com as demais barras da mesma linha, isto , do mesmo recurso, mas
no so comparveis com as barras dos demais projetos.
A escala de tempo representada como uma rgua, no alto dos demais grficos. Todos
os grficos tm seus perodos alinhados com esta rgua.
Para facilitar o uso da ferramenta, foi adicionado um menu com as funcionalidades
oferecidas ao usurio. A partir do menu possvel inserir um projeto, carregar e salvar
Figura 13: grfico de projetos
Figura 14: grfico de uso de recursos
Figura 15: escala de tempo para os grficos
45

arquivos de portflio e salvar uma imagem com os grficos.
Uma caracterstica importante do sistema a interatividade, que foi implementada com
a atualizao imediata de todos os grficos no momento em que o portflio alterado. Esta
alterao implica em reclculo de todas as variveis e redesenho completo de todos os
componentes do grfico. Deste modo, o usurio pode verificar imediatamente o resultado de
uma deciso, e alter-la para que os resultados sejam os mais adequados.
Ao final da iterao, o sistema estava pronto para uso, com as funcionalidades bsicas
implementadas e sem erros de execuo. Alguns aspectos de facilidade de uso do sistema
foram omitidos, como a edio dos projetos e recursos, mas j era possvel criar um portflio
de projetos com os dados existentes, definindo o perodo para incio de cada projeto e
verificando o impacto no investimento e uso de recursos.
5.1.7.5 Avaliao do processo de desenvolvimento do sistema
O resultado do processo de desenvolvimento do prottipo levou mais tempo do que o
planejado e entregou ao final um sistema com menos funcionalidade do que o previsto, mas
pode ser considerado bem-sucedido pela entrega de um sistema utilizvel para testes, portanto
tornando vivel a continuao do trabalho.
Em comparao com o plano inicial, o processo consumiu uma iterao de uma
semana a mais e produziu um sistema desktop em vez de um sistema baseado em web, e
apenas com as funcionalidades mais essenciais. O estado do sistema ao final do processo no
o torna prtico para uso normal, principalmente pela dificuldade de inserir dados de projetos e
recursos, mas possibilita testes controlados. O quadro 5.3 traz uma comparao entre os
resultados planejados para cada iterao e os resultados obtidos.
Figura 16: menu do sistema
46

Iterao Resultado planejado Resultado real
1
diagrama de classes
arquitetura
diagrama de classes
arquitetura
2 biblioteca de classes biblioteca de classes
3 interface web para usurio interface web para usurio (incompleta)
4
testes com dados reais
melhora do sistema
interface web para usurio (descartada)
alterao da arquitetura (no planejada,
incompleta)
5
no foi prevista alterao da arquitetura
interface desktop para usurio (no
planejada)
teste com dados reais
Quadro 3: comparao entre resultados planejados e reais

possvel observar que o andamento do processo foi adequado at a terceira iterao,
quando os problemas com o servidor web comearam a aparecer. A partir da, a implantao
da interface de usurio usando servidor web consumiu a terceira iterao e parte da quarta,
quando pareceu mais prudente descartar a arquitetura planejada em troca de obter um sistema
diferente e com mais esforo necessrio, mas com menor risco tcnico. Esta deciso pareceu a
mais adequada ao tempo curto que restava para desenvolvimento, por trazer um resultado
mais previsvel em troca da incluso de mais uma iterao. possvel que fosse possvel
desenvolver o sistema com a arquitetura planejada durante a quinta iterao, mas havia o risco
de a arquitetura se demonstrar definitivamente invivel e assim inviabilizar qualquer teste.
O uso de um mtodo gil de desenvolvimento permitiu que a situao fosse reavaliada
durante o desenvolvimento e que o desenvolvimento fosse replanejado com as mudanas
necessrias. Caso fosse preciso manter o plano inicial, como nos mtodos mais tradicionais de
desenvolvimento, o prottipo talvez no estivesse pronto para testes no final do prazo. Outra
vantagem do mtodo de desenvolvimento foi a nfase em funcionalidades completas ao final
de cada iterao. A biblioteca de classes criada na iterao 2 foi utilizada at o final, com
modificaes mnimas para adapt-la interface.
A mudana de arquitetura implicou em maior esforo e ainda provocou reduo nos
requisitos implementados. Em relao ao planejado, no foram implementados a edio dos
objetos pelo sistema, o modelo matemtico para otimizao e a comparao de portflios.
Os problemas de arquitetura poderiam ter sido evitados ou reduzidos pela aplicao
mais literal do mtodo de desenvolvimento. Uma das regras para priorizao de requisitos o
risco tcnico: os requisitos que apresentam maior risco tcnico devem ser implementados o
47

mais cedo possvel para evitar atrasos insuperveis (SCHWABER, 2004; COHN, 2004). O
requisito que foi considerado mais arriscado, e por isso implementado cedo, foi a biblioteca
de classes. Este demonstrou ser um erro de avaliao, j que este requisito apresentou alta
complexidade mas pouco risco. As dificuldades causadas pela complexidade foram resolvidas
com uso judicioso da linguagem de programao C++e padres de projeto, o que exigiu
muito esforo e tempo mas eventualmente traria resultados, enquanto os problemas causados
pelo servidor web no puderam ser contornados com os recursos e tempo disponveis. Talvez
o primeiro requisito de codificao devesse ter sido uma pequena aplicao de demonstrao
do servidor web Wt utilizando os recursos necessrios para o sistema conforme planejado,
como gerao de grficos, por exemplo. Caso esta pequena aplicao fosse bem-sucedida, o
desenvolvimento continuaria conforme planejado, caso contrrio haveria mais tempo para
estudar alternativas.
Uma das sugestes de Frederick Brooks no clssico The Mythical Man-Month
(BROOKS, 1995) planejar desde o incio descartar a primeira verso de um sistema, j que
esta verso ser inadequada mesmo. O prottipo construdo ao final deste processo um tipo
de rascunho de um sistema usvel, mas que cumpre sua funo bsica de apoiar uma deciso
com base no modelo definido, e por isso pode servir como primeira verso de um sistema
mais completo e utilizvel.
5.2 APLICAO DO SISTEMA AO PORTFLIO ATUAL DO TRT4
Os projetos atuais da STI e os recursos que estes projetos utilizam foram modelados e
armazenados no arquivo de dados do sistema, e a partir destes dados o portflio atual de
projetos da STI foi gerado usando a interface do sistema, dando origem aos grficos
apresentados nesta seo. Os dados dos projetos foram retirados da documentao oficial dos
projetos, conforme armazenada no repositrio de documentos do Escritrio de Projetos. O
horizonte de planejamento foi determinado a partir dos projetos planejados e incluiu o perodo
de novembro de 2010 at dezembro de 2012, mas a partir de maro de 2012 at o final do
perodo apenas um projeto estava planejado para execuo, utilizando poucos recursos, por
isso este ltimo intervalo foi retirado dos grficos para melhorar a apresentao.
48

5.2.1 Grfico de classes de investimento
A principal informao fornecida pelo sistema a alocao proporcional dos
investimentos de recursos humanos nas quatro classes de investimento definidas por Weill e
Aral (2005). Os valores obtidos pelo sistema esto apresentados na figura 5.10.
Conforme descrito anteriormente, em cada ms a barra indica a proporo de
investimentos na classe do ms e a linha indica a proporo de investimento acumulado. O
primeiro detalhe a observar a proporo exagerada do investimento estratgico. Enquanto
Weill e Aral (2005) observaram um valor mdio de 13%, o valor para o TRT de 42% no
final do perodo de estudo. Esta diferena pode ser explicada pelo projeto Processo
Eletrnico, que usa muitos recursos em tempo integral e foi classificado como estratgico, e
por isso causa grande impacto nos nmeros. Sem este projeto, o valor para investimentos
estratgicos oscila entre 7% e 10%. A classe estratgica est associada no setor pblico com
inovao e grandes mudanas, o que corresponde realidade do TRT4, que est fazendo um
grande investimento estratgico visando mudar sua maneira de trabalhar e de se relacionar
com a sociedade com o projeto Processo Eletrnico.
O valor dos investimentos informacionais est adequado ao levantado por Weill e Aral
no cenrio sem o Processo Eletrnico, e se apresenta mais baixo no cenrio real por causa do
alto investimento estratgico. Este tipo de investimento se apresenta bem distribudo no
Figura 17: investimento por classe no portflio atual
49

tempo.
O investimento transacional tem valor mais alto do que o esperado 18% contra 13%
mesmo em face do investimento no Processo Eletrnico. No cenrio sem o Processo
Eletrnico o valor ainda mais alto, de 25% no final do perodo. Pode-se observar que o
investimento feito acentuadamente no incio do perodo, at maro de 2011, tendo
proporo menor at setembro de 2011 e cessando a partir da. Tal investimento muito
concentrado em um projeto, o E-jus2, que usa cinco recursos em tempo integral.
A classe de infraestrutura tem um investimento muito mais baixo do que o esperado,
de apenas 26% contra 54% esperados. Este valor resulta de dois fatores principalmente, o
Processo Eletrnico e o tipo de dados medidos. No cenrio sem o Processo Eletrnico o valor
vai para 46%, muito prximo do previsto, e os investimentos que esto sendo medidos so
apenas os de recursos humanos. A incluso de recursos financeiros deve causar uma diferena
maior nesta classe do que nas demais, j que a infraestrutura se presta mais a contratao
externa ou aquisio do que as demais classes, principalmente no caso do TRT4, que mantm
uma rede de comunicao entre todas as unidades do estado e a sede em Porto Alegre.
Chama a ateno neste grfico o baixo impacto que os investimentos nos meses finais
tm no resultado acumulado. A causa disso fica evidente no grfico seguinte, o dos projetos.
5.2.2 Grfico de projetos

Figura 18: projetos do portflio atual
50

Todos os projetos esto concentrados no incio do perodo de planejamento.
Absolutamente nenhum projeto est planejado para iniciar a qualquer momento do perodo, o
que pode ser explicado como ausncia de planejamento real, substitudo pela simples reao a
demandas do ambiente. Isto explica que todos os aumentos proporcionais de investimento em
alguma das classes, na figura 5.11, so resultado da reduo do investimento em alguma outra
devida ao fim de algum projeto. O esforo total menor repartido de maneira diferente pelos
projetos restantes, sem nenhuma nova iniciativa.
5.2.3 Grfico de recursos
51

O grfico seguinte, de uso de recursos, demonstra este mesmo efeito de outra maneira.
A figura 5.12 mostra todo o perodo em que existem projetos planejados, no apenas os meses
mais importantes como nos grficos anteriores. O padro demostrado o que seria de esperar
Figura 19: uso de recursos no portflio atual
52

pela observao dos grficos anteriores, com grande uso de recursos no incio do perodo e
reduo medida que os projetos so concludos. As barras vermelhas indicam os meses em
que o recurso est sobre-alocado e as barras amarelas indicam uso no limite da capacidade.
Apenas os 23 servidores da STI cuja participao em projetos est documentada aparecem no
grfico, dos 77 disponveis, e mesmo estes apresentam muita disponibilidade para trabalhar
em outros projetos.
Os recursos sobre-alocados no comeo do perodo de anlise representam um risco
para a execuo dos projetos conforme planejados. O impacto da ocorrncia deste risco
atenuado pela disponibilidade dos recursos nos meses seguintes, mas compensar uso
excessivo com ociosidade demonstra falta de planejamento na alocao dos recursos. O
planejamento complicado atualmente pela falta de uma ferramenta que fornea meios para
avaliar o efeito de cada projeto em todo o portflio.
5.3 APRESENTAO DO PROTTIPO AOS ESPECIALISTAS
Foi feita uma apresentao do prottipo para dois usurios com perfis distintos, de
usurio do Escritrio de Projetos e usurio tomador de deciso. A demonstrao visou
responder s seguintes questes, referentes a gesto de portflio de projetos de TI e ao
prottipo:
a) Atualmente, a viso que a STI tem do portflio de projetos adequada?
b) As informaes apresentadas pelo sistema so coerentes com o que se espera?
c) As informaes apresentadas pelo sistema so completas?
d) O sistema fcil de usar? Quais caractersticas tornariam o sistema mais
utilizvel?
e) Este tipo de sistema til para auxiliar no planejamento do portflio de projetos?
Ambos os entrevistados consideraram a viso do portflio inadequada, tanto devido s
informaes incompletas e defasadas sobre cada projeto como falta de uma ferramenta que
fornea uma viso agregada do portflio de projetos. A apresentao da viso de projetos,
conforme a seo, ajudou a evidenciar a dificuldade de planejamento dos projetos, que
tendem a ser iniciados imediatamente e no planejados para o momento mais adequado.
As informaes apresentadas foram consideradas coerentes com o modelo mas, por
outro lado, incompletas. A demonstrao foi baseada nos dados fornecidos pelos gerentes de
projeto ao Escritrio de Projetos. Alguns projetos em execuo no estavam documentados,
53

portanto no faziam parte do portflio apresentado pelo sistema. A falta destes projetos
certamente afetou a distribuio dos investimentos entre as quatro classes. Alm disso, foi
declarado que seria til ter as informaes correspondentes s atividades continuadas.
A demonstrao foi conduzida pelo autor, isto , os usurios no utilizaram
pessoalmente o sistema, apenas acompanharam a execuo. Por conta disso, alguns aspectos
de usabilidade no foram testados. Mesmo assim, algumas melhorias foram sugeridas, como
edio local dos projetos e detalhamento dos dados agregados (drill down). A apresentao
das informaes foi considerada adequada. O sistema no foi avaliado como fcil de usar,
mesmo que os aspectos mais complexos, como a edio dos dados dos projetos, no tenham
sido demonstradas.
Finalmente, o conceito do sistema foi considerado muito til para auxiliar no
planejamento e acompanhamento do portflio de projetos. O prottipo apresentou uma viso
que ainda no estava disponvel em outras ferramentas, e o uso do conceito de GPTI por
classes de investimento (Weill e Aral, 2005) agrega um mtodo de balanceamento dos
investimentos ao simples balanceamento do uso dos recursos humanos.

54

6 CONCLUSO
O objetivo do presente trabalho foi desenvolver um prottipo de SAD para auxiliar no
processo de justificativa dos investimentos em TI do TRT4. O desenvolvimento deste
prottipo envolveu a modelagem do portflio de projetos de TI do TRT4, o levantamento de
requisitos funcionais e a implementao do prottipo, que pde ento ser usado com os dados
do portflio atual de projetos de TI do TRT4 e seus resultados serem comparados com o
estado deste portflio.
O modelo do portflio foi criado a partir do framework de GPTI que classifica os
investimentos em TI em quatro classes, que so infraestrutura, transacional, informacional e
estratgica. A classificao dos investimentos permite que projetos distintos sejam
comparados entre si quanto ao tipo de retorno que podem trazer ao TRT4.
O modelo inicial para o portflio de projetos de TI do TRT4 para uso do prottipo foi
criado, e a arquitetura do sistema foi definida. A seguir, a implementao do prottipo iniciou,
comeando pelo modelo de portflio e seguindo pela interface de usurio. A partir de
problemas de implementao com a interface web planejada, o sistema foi repensado para
utilizar uma interface de usurio baseada em desktop, com arquitetura mais simples. A partir
desta nova arquitetura, o prottipo foi concludo e os dados do portflio de projetos de TI do
TRT4 foram inseridos para validao.
O prottipo foi utilizado para fazer uma anlise do portflio atual de projetos do TRT4.
A partir desta anlise, verificou-se que o portflio de projetos de TI do TRT4 apresenta
investimentos muito elevados em relao aos encontrados na literatura para as classes
estratgicos e transacionais, e que consequentemente os valores para investimentos em
infraestrutura e informacionais so mais baixos do que o esperado. Contudo, tais diferenas
podem ser justificadas pelos objetivos da organizao, que est investindo em grandes
projetos para inovao e reduo de custos operacionais.
Outro resultado da anlise foi a verificao de que os projetos no foram planejados
com o uso balanceado dos recursos em mente, mas foram todos iniciados e que se encontram
em execuo simultaneamente. Esta situao aumenta o risco para os projetos que
compartilham recursos sobre-alocados. A m distribuio dos projetos no perodo de anlise
pode ser explicada pela dificuldade de entender como cada um dos projetos impacta no
portflio sem uma ferramenta prpria para este tipo de anlise, que exatamente o problema
que o SAD desenvolvido aqui como prottipo prope resolver.
O prottipo foi apresentado a usurios do TRT4, que avaliaram a utilidade do SAD
55

proposto e deram suas opinies a respeito dos aspectos a melhorar no prottipo, indicando
assim um possvel caminho para criar um SAD completo e funcional. A viso que o prottipo
apresentou dos projetos foi avaliada positivamente e o uso dos conceitos de GPTI foi
considerado til, por permitir que as decises de priorizao dos projetos seja feita visando o
retorno dos projetos para a organizao e no apenas o balanceamento do uso de recursos.
Por fim, pode-se concluir que o presente trabalho foi bem-sucedido em desenvolver o
prottipo proposto, e que os conceitos em que o prottipo foi baseado se demonstraram
vlidos na avaliao do portflio do TRT4 e na demonstrao aos usurios.

56

REFERNCIAS
APACHE Tomcat. Disponvel em: <tomcat.apache.org>. Acesso em: 23 out. 2010.

APACHE: http server project. Disponvel em: <httpd.apache.org>. Acesso em: 23 out. 2010.

ARAL, S.; WEILL, P. It assets, organizational capabilities and firm performance: do resource
allocations and organizational differences explain performance variation?. SSRN eLibrary,
Cambridge, n. 360, p. 1-27, jul. 2007. Disponvel em: <http://ssrn.com/paper=882088>.
Acesso em: 31 mai. 2010.

ARCHER, N.; GHASEMZADEH, F. Project Portfolio Selection and Management. In:
MORRIS, P. W.; PINTO, J . The wiley guide to project, program and portfolio
management. New York: J ohn Wiley & Sons, 2007.

BELTRAME, M. M.; MAADA, A. C. G. Modelo de valor da TI para as organizaes que
fazem uso intensivo de informaes. In: ENADI 2009, 2009, Recife. Trabalhos... Recife:
EnADI 2009, 2009. v. 1. p. 1-16.

BLANCHETTE, J .; SUMMERFIELD, M. C++ GUI programming with Qt 4. Upper Saddle
River: Prentice Hall, 2006.

BOOST: C++libraries. Disponvel em: <www.boost.org>. Acesso em: 23 out. 2010.

COHN, M. User stories applied: for agile software development. Boston: Addison-Wesley
2004.

DEBIAN. Disponvel em: <www.debian.org>. Acesso em: 23 out. 2010.

DOLCI, P. C. Uso da gesto do portflio de TI no processo de gerenciamento e
justificativa dos investimentos em TI. 2009. 198 f. Dissertao (Mestrado)- Universidade
Federal do Rio Grande do Sul, Escola de Administrao, Programa de Ps-Graduao em
Administrao, 2009.

FOWLER, M. UML essencial: um breve guia para a linguagem-padro de modelagem de
objetos. 3.ed. Porto Alegre: Bookman, 2005.

GAMMA, E.; HELM, R.; J OHNSON, R.; et al. Padres de projeto: solues reutilizveis de
software orientado a objetos. Porto Alegre: Bookman, 2000.
57

GCC: the GNU Compiler Collection. Disponvel em: <gcc.gnu.org>. Acesso em: 12 nov.
2010.

GHASEMZADEH, F.; ARCHER, N. P. Project portfolio selection through decision support.
Decision Support Systems, v. 29, n. 1, p. 73-88., jul. 2000. Disponvel em:
<http://www.sciencedirect.com/science/article/B6V8S-40D0MHG-
7/2/07c6fd5d643869bacdea1a98bbd30fb6>. Acesso em: 1 set. 2010.

GORRY, G. A.; SCOTT-MORTON, M. S. A framework for management information systems.
Sloan School of Management, Cambridge, 510-71, fevereiro 1971. Disponvel em:
<http://hdl.handle.net/1721.1/47936>. Acesso em: 1 out. 2010.

J EFFERY, M.; LELIVELD, I. Best practices in IT portfolio management. MIT Sloan
Management Review, , v. 45, n. 3, p. 41-49, primavera 2004. Disponvel em:
<http://www.pubservice.com/MSStore/ProductDetails.aspx?CPC=45309>. Acesso em: 1 set.
2010.

LARMAN, C. Agile and iteractive development: a manager's guide. Boston: Addison
Wesley, 2004.

MAADA, A. C. G.; DOLCI, P. C.; BELTRAME, M. M. Gesto do portflio de
investimentos em TI: estudo de casos mltiplos em empresas de manufatura. In: ENCONTRO
DE ADMINISTRAO DA INFORMAO, 1., 2007, Florianpolis. Trabalhos...
Florianpolis: EnADI, 2007. Disponvel em:
<http://www.anpad.org.br/evento.php?acao=trabalho&cod_edicao_subsecao=292&cod_event
o_edicao=34&cod_edicao_trabalho=8104>. Acesso em: 31 mai. 2010.

MEYER, B. Object-oriented software construction. 2nd ed. Upper Saddle River: Prentice
Hall, 1997.

MICROSOFT Dream Spark. Disponvel em: <www.dreamspark.com>. Acesso em: 12 nov.
2010.

MICROSOFT. WINDOWS Virtual PC. Disponvel em:
<www.microsoft.com/windows/virtual-pc>. Acesso em: 23 out. 2010.

MONGODB. Disponvel em: <www.mongodb.org>. Acesso em: 23 out. 2010.

MYSQL: the world's most popular open source database. Disponvel em: <www.mysql.com>.
Acesso em: 23 out. 2010.
58

NETBeans. Disponvel em: <www.netbeans.org>. Acesso em: 12 nov. 2010.

PMI - Project Management Institute. The standard for portfolio management. 2 ed. Newton
Square: Project Management Institute, 2008.

PMI - Project Management Institute. Um guia do conhecimento em gerenciamento de
projetos: guia PMBOK. 4 ed. Newton Square: Project Management Institute, 2009.

Qt. Disponvel em: <qt.nokia.com>. Acesso em: 12 nov. 2010.

SCHWABER, K. Agile project management with Scrum. Redmond: Microsoft Press, 2004.
STROUSTRUP, B. A linguagem de programao C++. 3. ed. Porto Alegre: Bookman,
2000.

TURBAN, E.; RAINER J R., R. K.; POTTER, R. E. Introduo a sistemas de informao:
uma abordagem gerencial. Rio de J aneiro: Elsevier, 2007.

VIRTUALBox. Disponvel em: <www.virtualbox.org>. Acesso em: 23 out. 2010.

VMWare. Disponvel em: <www.vmware.com>. Acesso em: 23 out. 2010.

WEILL, P.; ARAL, S. Generating premium returns on your IT investments. Sloan
Management Review, v. 47, n. 2, p. 38-48, inverno 2006. Disponvel em:
<http://ssrn.com/paper=942303>. Acesso em: 31 mai. 2010.

WEILL, P.; ARAL, S. IT savvy pays off: how top performers match IT portfolios and
organizational practices. SSRN eLibrary, Cambridge, n. 353, p. 1-12, mai. 2005. Disponvel
em: <http://ssrn.com/paper=779345>. Acesso em: 31 mai. 2010.

WEILL, P.; ROSS, J . IT Savvy: what top executives must know to go from pain to gain.
Boston: Harvard Business Press, 2009.

WT: a C++web toolkit. Disponvel em: <www.webtoolkit.eu/wt>. Acesso em: 23 out. 2010.

Desenvolvimento de Um Protótipo de Sistema de Apoio A Decisao para Ggestao de Portifolio de Projetos de Tecnologia Da Informação

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Desenvolvimento de Um Protótipo de Sistema de Apoio A Decisao para Ggestao de Portifolio de Projetos de Tecnologia Da Informação

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Вам также может понравиться