UNIVERSIDADE PAULISTA

JOS ALEXANDRE ROSA VERDEROSA

RA 0920667

SOLUO PARA MELHORIA DE PERFORMANCE EM PROJETOS DE APLICATIVOS

MARAB
2011

JOS ALEXANDRE ROSA VERDEROSA

RA 0920667

SOLUO PARA MELHORIA DE PERFORMANCE EM PROJETOS DE APLICATIVOS

Projeto Integrado Disciplinar para obteno

de mdia em Gesto de Tecnologia da
Informao

apresentado

Paulista - UNIP

Orientador: Prof Ivanirso Lima

MARAB
2011

Universidade

RESUMO
Esta proposta tcnica tem como objetivo apresentar solues para melhoraria na
performance em projetos de aplicativos no que tange ao binmio prazo e
oramento em projetos de TI. Haja vista o quanto essas duas variveis tm
influenciado o mercado de TI brasileiro, a melhor soluo encontrada para sanar
essas deficincias foi o uso da metodologia de gerenciamento de projetos
PRINCE2 Project in Controlled Environments (Projeto em Ambientes Controlados)
usada em paralelo com a ferramenta para o controle de alteraes em projetos de
software em desenvolvimento: Token.

Palavras-chave: Prazo. Oramento. Gerenciamento de projetos. PRINCE2. Token.

.

ABSTRACT
This proposal aims to present technical solutions to improve performance in
application design with respect to the binomial time and budget on IT projects.
Considering how these two variables have influenced the Brazilian IT market, the
best solution to address these shortcomings was the use of project management
methodology PRINCE2 Project in Controlled Environments used in parallel with the
tool to control changes to software projects in development: Token.

Keywords: Time. Budget. Project management. PRINCE2. Token.

.

SUMRIO

1 INTRODUO..........................................................................................................7
2 DESENVOLVIMENTO..............................................................................................8
2.1 Motivos da incapacidade em gerenciamento de projetos......................................8
2.1.1. Principais falhas no gerenciamento de projetos de TI.......................................9
2.2 Modelos de melhores prticas e o modelo de Governana de TI........................11
2.3 PRINCE2 Project in Controlled Environments...12
2.3.1 Benefcios do modelo.................................................................................12
2.3.2 Objetivos do modelo..........................................................................................13
2.3.3 Estrutura do modelo..........................................................................................14
2.3.4 Os processos da metodologia...........................................................................16
2.3.4.1 Criando o projeto............................................................................................16
2.3.4.2 Dirigindo o projeto..........................................................................................16
2.3.4.3 Iniciando o projeto..........................................................................................16
2.3.4.4 Gerenciando a fronteiras de um estgio........................................................17
2.3.4.5 Controlando um estgio.................................................................................17
2.3.4.6 Gerenciando a entrega do produto................................................................18
2.3.4.7 Fechando um projeto.....................................................................................18
2.3.4.8 Planejamento.................................................................................................19
2.3.5 Os componentes da metodologia.....................................................................19
2.3.5.1 Business Case...............................................................................................19
2.3.5.2 Organizao...................................................................................................19
2.3.5.3 Planos............................................................................................................20
2.3.5.4 Controles........................................................................................................20
2.3.5.5 Gesto de riscos............................................................................................20
2.3.5.6 Qualidade no ambiente do projeto.................................................................20
2.3.5.7 Gesto da configurao.................................................................................20
2.3.5.8 Controle da mudana.....................................................................................21
2.3.6 As tcnicas da metodologia..............................................................................21
2.4 Ferramenta para o controle de alteraes em projetos de software
em desenvolvimento..................................................................................................21

2.4.1 Cadastramento de Desenvolvedores...............................................................22

2.4.2 Mecanismos de Comunicao entre Desenvolvedores...................................23
2.4.3 Mecanismos de Controle de Alterao..............................................................24
3. CONCLUSO.........................................................................................................27
REFERENCIAS..........................................................................................................28

1. INTRODUO

Uma empresa bem conceituada no mercado quando consegue atender a

dois requisitos que medem sua eficincia: prazo e oramento.
De acordo com a Gartner, apenas 67% das organizaes conseguem
entregar seus projetos dentro do oramento. As estatsticas so ainda mais
alarmantes quando se trata de prazo, apenas 57% das organizaes conseguem
atender a esse indicador.
Projetos de TI historicamente so caracterizados por atrasos demasiados,
aparentes descaso para com o oramento, e resultados aqum das expectativas dos
clientes e usurios finais. O acmulo destas falhas acaba provocando por sua vez,
retrabalho.
A soluo para essas deficincias uma estruturao por parte da
concepo, planejamento, execuo e fechamento dos projetos. Essa estruturao
pode ser alcanada atravs de uma metodologia de gerenciamento de projetos em
concomitante uso com uma ferramenta de apoio.

2. DESENVOLVIMENTO
2.1. Motivos da incapacidade em gerenciamento de projetos
Os projetos de TI possuem caractersticas diferentes dos projetos de outras
reas do conhecimento, O setor de tecnologia da informao (TI) apresenta
historicamente uma grande desvantagem em relao a segmentos mais maduros da
nossa economia. Por exemplo, um dos setores que h mais tempo trabalha de
maneira formal e organizada gerncia de projetos o da construo civil, onde
muito comum que empreendimentos aconteam dentro do prazo previsto, dentro do
oramento e que no desmoronem aps sua concluso. Uma das razes
conhecidas por trs deste fato em funo do tempo que gasto com detalhes do
desenho do empreendimento antes de sua construo. O desenho tem que ficar
estvel em determinado momento para que possa ser construdo. A flexibilidade
para mudanas, apesar de reconhecidamente existir, menor durante seu
desenvolvimento. Quando nos voltamos para projetos de tecnologia da informao
essa lgica no necessariamente a mesma. At em funo das constantes
mudanas que o ambiente de negcios impe a realidade das corporaes e a
velocidade da evoluo que TI teve que apresentar para acomodar estas mudanas
de uma forma mais flexvel. No existe outro setor que tenha se desenvolvido e
evoludo tanto e em um ritmo to devastador quanto o de tecnologia (IEEE, 2001). E
particularmente quando nos referimos ao desenvolvimento de software esta
evoluo frentica teria que apresentar conseqncias, principalmente no que diz
respeito taxa de sucesso em projetos.
Projetos de informtica so diferentes e merecem tratamento diferenciado.
Mas, estes projetos possuem os mesmos desafios que todos os outros projetos tem.
A soluo para os responsveis nas organizaes bem como os profissionais da
rea so de ficar atentos aos pecados clssicos historicamente cometidos e passar
a praticar a boa gerncia de projetos. Assim reduzir-se- o nmero de fracassos e
aumentar-se- a probabilidade de realizar o sonho de projetos de TI que atendam
aos parmetros de custo, prazo e qualidade e atendendo plenamente aos clientes e
usurios. Eis algumas das caractersticas inerentes a projetos de informtica:
indefinio no estado final dos projetos; sobreposio entre as fases dos projetos;

9
pouca informao histrica para auxiliar nas estimativas; papis distintos como
anlise, execuo do projeto, programao e testes de qualidade geralmente so
realizados pela mesma pessoa; os pontos de no retorno (cancelamento) no so
claros; e h tendncia do profissional de TI querer engordar o projeto.
2.1.1. Principais falhas no gerenciamento de projetos de TI
No cumprimento dos prazos e estabelecidos: No gerenciar mudanas nos
requisitos do sistema e no escopo do trabalho (EAP) Mudanas nos requisitos
(funes ou caractersticas do sistema) so frutos de avanos tecnolgicos, novos
cenrios de mercado e decises polticas internas. Tais mudanas requerem
controles e acompanhamento, pois as mesmas provocam repercusses no trabalho
necessrio para completar o projeto a contento.
Problemas de comunicao: Definio ambgua dos requisitos do sistema e
do escopo do trabalho (EAP) Os requisitos do sistema so as caractersticas e
funes a serem includas no sistema. Estes por sua vez partem dos requerimentos
do negcio. A clara definio dos requisitos do sistema aumenta substancialmente
as chances para se obter xito no projeto.
Iniciar bem um projeto de TI significa definir com clareza os requerimentos do
negcio, entender o cenrio em torno do projeto e verificar o alinhamento do projeto
com as estratgias da empresa. Parte destas aes extrapola a responsabilidade da
rea de TI, no entanto, em funo do forte impacto destes itens no projeto em si,
merecem ser monitorados e alinhados atravs de interface com as outras reas
envolvidas. O bom incio tambm exige a existncia de metodologia ou processo
para bem gerenciar as etapas do projeto, particularmente no que diz respeito aos
requisitos do sistema a ser desenvolvido e o escopo do trabalho a ser realizado para
construir o sistema ou aplicativo.
Dar pouca nfase a questes comportamentais e de gerncia de stakeholders
Quando a rea de TI solicitada a desenvolver um projeto, parte-se da premissa
que a soluo ser fundamentalmente tcnica em natureza. Logicamente, as
solues desenvolvidas pelos profissionais de TI espalharo aquela necessidade.
Este contexto tecnolgico induz os responsveis pelo projeto a dar pouca nfase ao
lado humano. Mesmo reconhecendo que a soluo final ser de essncia tcnica, o
trabalho realizado por pessoas que enfrentam desafios semelhantes aos de

10
profissionais de outras reas. Isto , existem desafios de comunicao, conflito de
personalidades, necessidade de criar esprito de equipe, e questes polticas, entre
outros. Os stakeholders, portanto (todos que tem a ganhar ou a perder com o
sucesso ou no do projeto) precisam ser proativamente gerenciados para evitar um
fracasso na conduo do trabalho.
Mudanas de escopo constantes: O escopo do trabalho, por outro lado,
engloba todas as atividades de trabalho (planejamento, elaborao de cdigos, etc.)
necessrias para os requisitos fixados. Isto se desenvolve atravs da estrutura
analtica do projeto (EAP), tambm chamada de WBS Work Breakdown Structure.
A clara fixao do escopo do trabalho garante que todo o trabalho necessrio ser
realizado e elimina a realizao de trabalho desnecessrio.
As mudanas no escopo do trabalho tambm precisam ser monitoradas, pois
novas atividades ou flutuaes no volume das atividades existentes, certamente
provocaro novos trabalhos ou retrabalhos, que por sua vez provocaro impacto no
cronograma e oramento do projeto.
Estimativas erradas de prazo: Dar pouca ateno ao controle dos projetos
Um cenrio no raro em projetos de TI descobrir, no quinto ms de um projeto
programado para seis meses, que preciso prorrogar o prazo por um perodo de
seis meses adicionais, conseqentemente dobrados o prazo inicial. Tal descoberta
feita apenas no penltimo ms por falta de controle. Um sistema de controle que
acompanha as datas chaves e marcos principais, identificaria esta tendncia cedo
no projeto, em tempo hbil para se tomar medidas corretivas e reduzir o risco de
ocorrer atrasos.
Riscos no avaliados corretamente: Possibilidade de no possuir recursos
humanos suficientes caso algum profissional venha a ter que se ausentar, falta de
infra-estrutura caso algum computador venha a queimar e no possuir outro para
substitu-lo, falta de gerenciamento e controle dos riscos envolvidos com
fornecedores, interrupo no fornecimento de energia eltrica.
Recursos humanos insuficientes: A rea de TI era notria pela falta de
estruturao na conduo de seus projetos e pelo pouco preparo dos profissionais
na gerencia de projetos. Em funo da inteligncia e competncia dos profissionais
dentro de suas especialidades, as habilidades administrativas e gerenciais
associadas gerencia de projetos eram valorizados.

11

Figura 2.1 Problemas que ocorrem com maior freqncia nos projetos

O gerenciamento de todos os projetos de TI em perfeito atendimento aos

parmetros de custo, prazo e qualidade pode ser um sonho inatingvel, no entanto
no nmero excessivo de fracassos pode ser reduzido substancialmente. O passado
de atrasos horripilantes, pouca ateno aos oramentos e resultados abaixo das
expectativas dos clientes e usurios finais aos poucos poder ceder caminho a
projetos mais estruturados que desviam menos dos caminhos traados. Com isto
reduz-se o retrabalho.
2.2 Modelos de melhores prticas e o modelo de Governana de TI
Para solucionar tantos problemas que acabam ocasionando extrapolao no
oramento e no tempo de entrega do produto, e assim, consequentemente, melhorar
a performance em projetos, existem quatro modelos de melhores prticas propostas.
Estes modelos com seus respectivos escopos esto mencionados na tabela a
seguir:

12
Modelos de melhores prticas
PRINCE2 Project in Controlled

Escopo do modelo
Metodologia de gerenciamento

Environments
P3M3 Portiflio, Programme & Project

projetos
Modelo

Management Maturity Model

gerenciamento de projetos, programas e

PMBOK Project Management Body of

portiflio
Base de conhecimento em gesto de

Knowledge
OPM3

projetos
Modelo

Organizational

Management Maturity Model

Project

de

de

maturidade

maturidade

para

para

de
o

gerenciamento de projetos

Tabela 2.1 Principais modelos de melhores prticas aplicadas ao

gerenciamento de projetos
2.3 PRINCE2 Project in Controlled Environments
Dentre os modelos apresentados acima, o que mais se encaixa como soluo
na situao em questo o PRINCE2. Da mesma forma que o PMBOK, o PRINCE2
tambm possui seu modelo de maturidade. A metodologia PRINCE2 baseada nas
experincias com os projetos, gerente de projetos e equipes de projeto que
contriburam com seus erros, acertos e sucessos.
A metodologia , atualmente, o padro usado pelo governo Britnico, sendo
tambm reconhecida e usada no setor privado, tanto na Gr-Bretanha como
internacionalmente.
A PRINCE2 , de fato, uma metodologia de gerenciamento de projetos, ao
contrrio do PMBOK, que um conjunto de conhecimentos.
Ela se aplica a qualquer tipo de projeto, incluindo os projetos de Tecnologia da
Informao.
2.3.1 Benefcios do modelo
De acordo com uma pesquisa realizada em 2001 pelo Center for Business
Practices (2001) em 43 organizaes de variados portes, os seguintes benefcios
foram obtidos com a implantao da gesto de projetos em organizaes de TI:

38,6% foi a melhoria na estimativa de prazo;

13

32,8% foi a melhoria na estimativa de esforo e de custo;

7,6% foi a melhoria na estimativa de qualidade;
37,8% foi a melhoria na satisfao dos clientes;
37% foi a melhoria no alinhamento dos projetos com as estratgias do

negcio;
21,7% foi a melhoria no time-to-market;
31,9% foi a melhoria na qualidade;
32,5% foi a melhoria na entrega dos projetos dentro do oramento;
25,6% foi a melhoria na utilizao das horas de trabalho;
32,1% foi a melhoria no desempenho do trabalho;
23,8% foi a melhoria no desempenho do custo;
12,9% foi a melhoria na taxa de defeitos;
22,8% foi a melhoria na produtividade do staff do projeto;
23% foi a melhoria no tempo de resposta;
O ROI (Retorno de Investimento) total observado foi de 27,9%.

2.3.2 Objetivos do modelo

O objetivo da PRINCE2 fornecer um mtodo que:

Possa ser repetido por todos os projetos;

Possa ser ensinado;
Assegure que os membros do projeto saibam o que esperar deles, onde,

como e quando;
Previna mais cedo contra problemas no projeto;
Permita ser proativo, no reativo, mas capaz de acomodar mudanas

repentinas, oriundos de eventos inesperados;

Fornea um guia consistente para os gerentes de projetos e demais
interessados, facilitando o planejamento, o controle e a comunicao no
mbito do projeto.

2.3.3 Estrutura do modelo

O PRINCE2 (2005) composto por processos, componentes e tcnicas. O
modelo de processos do PRINCE2 contempla cerca de oito processos gerenciais
distintos, oito componentes e trs tcnicas. A Figura 2.2 mostra o relacionamento

14
entre os processos e componentes. Na PRINCE2, os processos utilizam os
componentes e as tcnicas conforme mostra a Figura 2.3.

Figura 2.2 Processos e componentes da PRINCE2

15

Figura 2.3 Componentes e tcnicas nos processos do PRINCE2

Em relao s descries dos processos, o manual est estruturado de tal
forma que o usurio encontre o fundamento e o contexto do processo, mostrando o
relacionamento dos sub-processos, as descries do processo e dos sub-processos,
dicas de aplicao do processo responsabilidades, necessidades de informaes
dos sub-processos e critrios chave de execuo (tambm com suas dicas).
Em relao aos componentes, o manual apresenta, ainda que no de forma
padronizada em relao aos tpicos, o objetivo, os benefcios, os elementos e/ou
controles do componente e o seu mapeamento para os processos.
Por fim, em relao s tcnicas, as mesmas so descritas de forma breve,
mas indicando tambm o que cada tcnica, os passos para utiliz-la e assim por
diante.
A metodologia estabelece os templates para serem aplicados imediatamente,
assim como descreve os papis e responsabilidades das equipes.

16
2.3.4 Os processos da metodologia
2.3.4.1 Criando o projeto
Processo cujo objetivo assegurar que os requisitos para que se inicie um
projeto estejam presentes. Contempla:

Designao da equipe do projeto;

Descrio do projeto;
Definio sobre como, em termos gerais, a soluo ser fornecida;
Expectativas dos clientes em relao a qualidade;
Lista de riscos; e
Plano do estgio de iniciao.
Deve existir um termo ou documento que autorize o incio do projeto.

2.3.4.2 Dirigindo o projeto

Processo que ocorre desde o incio do projeto at o seu encerramento, sendo
de responsabilidade do Comit do Projeto ou do grupo de tomadores de deciso que
representam o negcio, usurios e fornecedores, e abrange:

Autorizao da iniciao (processo anterior);

Autorizao para o projeto;
Comprometimento de alocao de recursos, a partir de verificaes nas

fronteiras dos estgios do projeto;

Monitoramento do progresso;
Estabelecimento de diretrizes para o projeto;
Aes em funo de ameaas de riscos ao projeto; e
Encerramento do projeto, controlando todo encerramento de contratos,
desmobilizao de recursos, instalaes e servios.

2.3.4.3 Iniciando o projeto

O produto principal deste processo o Documento de Incio do Projeto ou
Termo de Abertura do Projeto. Seus objetivos:

Definir o nvel de qualidade do produto a ser gerado;

Planejar o projeto e seu custo;
Revisar o Business Case;

17

Assegurar que o prazo e o esforo possam ser justificados em funo dos

riscos do projeto;
Permitir e encorajar o Comit do Projeto a envolver-se na direo do projeto e

a se comprometer com a disponibilizao dos recursos; e

Estabelecer a linha de base inicial do projeto.

2.3.4.4 Gerenciando a fronteiras de um estgio

Como produtos deste processo, podem ser relacionados: Relatrio de
Encerramento de Estgio, Plano de Estgio Atual, Plano de Estgio Seguinte, Log
de Risco Atualizado, Business Case atualizado, Log de Lies Aprendidas,
mudanas na equipe. Ojetivos:

Assegurar, para o Comit do Projeto, que os produtos planejados do Plano de

Estgio atual foram completados;

Prover informao para o Comit do Projeto para que o mesmo avalie a

viabilidade do projeto;
Prover para o Comit do Projeto informaes necessrias para que aprove o

estgio atual do projeto e que autorize o incio do estgio seguinte; e

Registrar medies e lies aprendidas que possam ajudar estgios
posteriores do projeto ou outros projetos.

2.3.4.5 Controlando um estgio

O objetivo deste processo assegurar que cada estgio seja desempenhado
conforme o Plano do Estgio. Como produtos deste processo podem ser
relacionados: Pacotes de Trabalho (do WBS), Relatrios de Progresso, Dirio de
Bordo, Lista de Pendncias, Log de Risco Atualizado e Plano de Estgio Adaptado.
Este processo compreende atividades como:

Autorizao para execuo do trabalho planejado;

Obteno de informao sobre o progresso do projeto;
Anlise de mudanas;
Reviso do projeto;
Comunicao acerca do projeto;
Tomada de aes corretivas em funo de desvios; e
Prover informao para o Comit do Projeto para que o mesmo avalie a
viabilidade do projeto.

18

2.3.4.6 Gerenciando a entrega do produto

Objetiva assegurar que os produtos previstos pelo projeto sejam produzidos e
entregues, considerando:

Negociar com o gerente da equipe sobre a realizao dos produtos de

trabalho conforme definidos;

Assegurar o compromisso da equipe do projeto com o resultado esperado;
Avaliar o progresso do projeto;
Assegurar que os produtos atendam as suas respectivas especificaes de

qualidade; e
Obter a homologao ou aprovao dos produtos contemplados.

2.3.4.7 Fechando um projeto

Objetivos:

Verificar se os objetivos pretendidos foram atendidos;

Verificar se todos os produtos esperados foram entregues aceitos pelo cliente;
Confirmar que providencias relativas manuteno e operao foram

realizadas, incluindo treinamento, se for o caso;

Realizar recomendaes para trabalhos futuros;
Registrar lies aprendidas em um relatrio especfico, divulgado para a

operao;
Prepara um relatrio de finalizao do projeto;
Arquivar os documentos e artefatos gerados pelo projeto;
Produzir um plano de reviso ps-projeto; e
Solicitar do Comit do Projeto a desmobilizao dos recursos alocados ao
projeto.

2.3.4.8 Planejamento
Para o PRINCE2 o processo de planejamento se repete e tem um papel
importante em outros processos:

Planejamento do estgio de iniciao do projeto;

Planejamento do projeto;
Planejamento de cada estgio;
Atualizao do Plano do Projeto;

19

Aceitao de um pacote de trabalho; e

Na gerao de um Plano de Exceo.

2.3.5 Os componentes da metodologia

2.3.5.1 Business Case
Documento que demonstra a viabilidade do projeto. Este documento contm a
principal condio de controle, ou seja, o resultado do projeto deve atender aos
resultados estimados e documentados no Business Case.
2.3.5.2 Organizao
A metodologia prope uma organizao para o projeto, considerando papis
responsabilidades e relacionamentos de todos os papis envolvidos no projeto,
assim como indica como esses papis so exercido, conforme a complexidade do
projeto.

2.3.5.3 Planos
A metodologia oferece uma srie de nveis de planos que podem ser
adaptados s necessidades do projeto, alm de uma abordagem para o
planejamento baseado em produtos, ao contrrio de atividades.
2.3.5.4 Controles
Conjunto de controles orientados para a gesto por exceo e que atuam
sobre os estgios. Tais controles permitem a avaliao dos produtos em termos de
atendimento a escopo e qualidade, e do projeto em termos de prazo, custo, esforo,

20
qualidade, etc. A metodologia inclui tambm revises formais em vrios pontos do
ciclo de vida do projeto.
2.3.5.5 Gesto de riscos
Gesto dos riscos em todo o ciclo de vida do projeto, determinado os pontos
de sua reviso.
2.3.5.6 Qualidade no ambiente do projeto
Gerenciamento da qualidade do projeto, compreendendo um Plano da
Qualidade, critrios de aceitao, requisitos de qualidade do produto, registros e
verificaes da qualidade.
2.3.5.7 Gesto da configurao
Permite o rastreamento dos componentes produzidos ao longo do projeto at
a montagem do produto final. Estabelece um plano de configurao e um mtodo
abrangente para sua execuo.

2.3.5.8 Controle da mudana

Conjunto de diretrizes acerca de como gerenciar as mudanas no projeto, que
acontecem em funo de ocorrncia de riscos, surgimento de restries, etc.
2.3.6 As tcnicas da metodologia
So basicamente trs as tcnicas empregadas pela PRINCE2:

Planejamento baseado em produto, que na realidade so tcnicas para a

elaborao de um Work Breakdown Structure (a PRINCE2 denomina o WBS
como PBS ou Product Breakdown Structure);

21

Tcnica de controle da mudana e, por fim;

Tcnica de reviso da qualidade.

2.4 Ferramenta para o controle de alteraes em projetos de software em

desenvolvimento
Os projetos de desenvolvimento de aplicativos contemporneos tm
progressivamente aumentado de tamanho e complexidade, sendo cada vez mais
comum sua realizao por equipes de mdio porte (entre 10 e 20 desenvolvedores)
e grande porte (acima de 20 desenvolvedores). Com as facilidades de comunicao
proporcionadas pela Internet, a necessidade de experincia em diversas reas de
conhecimento e a presso por cronogramas mais restritos, alguns projetos so
realizados por diversas equipes trabalhando concorrentemente. Ainda mais, as
dificuldades de reunir os especialistas necessrios em um mesmo local fsico e a
delegao do desenvolvimento de determinados componentes para outras
empresas, so exemplos de fatores que podem exigir que as equipes participantes
de um projeto estejam geograficamente distribudas.
Entretanto, a existncia de mecanismos eficientes de comunicao, como a
Internet, no soluciona os problemas de desenvolvimento concorrente de projetos de
software. Ao contrrio, o novo cenrio traz novos problemas para o processo de
desenvolvimento. Por exemplo, o trabalho concorrente de equipes geograficamente
distribudas dificulta o controle de alteraes nos componentes de um projeto em
desenvolvimento. Mesmo quando precedida de uma precisa definio das interfaces
entre os componentes, a realizao de um projeto pode exigir que diversos
desenvolvedores alterem simultaneamente os mesmos componentes. Estas
situaes exigem a adoo de polticas para manter a consistncia entre os
componentes da verso atual do projeto ou permitir que essa consistncia seja
posteriormente restituda.
A ferramenta Token foi desenvolvida para apoiar o desenvolvimento
concorrente de projetos de software, auxiliando na resoluo dos problemas de
controle de alteraes nos componentes do projeto. Token sincroniza o acesso aos
componentes que compem um projeto de software, inibindo vrios usurios para
alterar um componente especfico em simultneo. Suas principais funcionalidades
so: o cadastramento dos desenvolvedores participantes do projeto, a troca de

22
informaes entre estes desenvolvedores e o controle de alteraes nos
componentes do projeto. Token foi desenvolvida em ambiente Linux, utilizando a
linguagem de script PHP3, o banco de dados MySQL e o servidor web Apache. A
ferramenta acessvel via um navegador Internet, sendo independente da
plataforma cliente.
Algumas das vantagens em utilizar o Token so: o seu custo reduzido, por ser
baseado em plataforma gratuita (Linux, Apache, PHP3 e MySQL), ter como meio de
comunicao a Internet, permitindo um desenvolvimento totalmente distribudo, e ser
independente de plataforma, tanto no lado cliente como no lado servidor.
2.4.1 Cadastramento de Desenvolvedores
Token

fornece

suporte

para

cadastramento

dos

desenvolvedores

participantes de um projeto. Este cadastramento necessrio para que os

desenvolvedores tenham acesso aos recursos de comunicao oferecidos pela
ferramenta. Alm disso, somente os desenvolvedores cadastrados tero acesso aos
componentes do projeto, acessados atravs dos mecanismos de controle de
alterao da ferramenta.
O incio da pgina de cadastramento de desenvolvedores lista as informaes
de todos os desenvolvedores previamente cadastrados como participantes do
projeto. O restante da pgina permite a troca da senha do desenvolvedor corrente, o
cadastramento de um novo desenvolvedor e a remoo de um desenvolvedor
previamente cadastrado.
2.4.2 Mecanismos de Comunicao entre Desenvolvedores
Para facilitar a comunicao entre os desenvolvedores, Token oferece um
quadro de mensagens. Para controlar um grande nmero de mensagens, estas so
indexadas por assuntos. A pgina de mensagens, apresentada na Figura 2.4,
permite visualizar as mensagens recebidas, enviar novas mensagens em
determinados assuntos, adicionar e remover assuntos.
Sempre que uma mensagem enviada atravs da ferramenta Token, os
desenvolvedores cadastrados recebem uma notificao por e-mail. A notificao
indica o assunto da mensagem, seu tipo e contm um link para a pgina de
mensagens da Token. Os tipos de mensagem utilizados na Token so: pergunta,

23
resposta, informao e urgente. Na verso atual da ferramenta, os tipos de
mensagem so meramente informativos, permitindo ao leitor uma rpida
identificao do objetivo da mensagem e a criao de filtros em seu e-mail.

Figura 2.4 Pgina de comunicao entre usurios

2.4.3 Mecanismos de Controle de Alterao
As pginas de cadastramento de desenvolvedores e de mensagens servem
como suporte para a principal funcionalidade oferecida pela ferramenta Token:
permitir que um projeto seja implementado simultaneamente por diversas pessoas
geograficamente distribudas.
A abordagem adotada consiste na diviso de um projeto em diversos
componentes atmicos de software. Os componentes so acessveis pelos
desenvolvedores atravs da ferramenta, que permite que apenas um desenvolvedor
altere um determinado componente a cada instante. Um componente o elemento
de menor granularidade controlado pela ferramenta.

24
Token segue a mesma abstrao dos protocolos de comunicao das redes
de computadores Token Ring e Token Bus. Nestas redes, diversos computadores
compartilham um meio de comunicao comum, que deve ser utilizado por um
computador de cada vez. Para sincronizar os acessos rede, um pacote de dados
padronizado, denominado token, permanece em trfego na rede enquanto nenhuma
mensagem transmitida. Quando um computador deseja transmitir uma mensagem,
ele retira o token da rede, envia sua mensagem, e, por fim, restaura o token,
permitindo que outros computadores enviem suas mensagens.
Da mesma forma, atravs da ferramenta Token, os desenvolvedores podem
alocar ou desalocar componentes. Cada componente possui um token, que se
encontra disponvel quando o componente no est reservado para nenhum
desenvolvedor. Quando um desenvolvedor decide alterar um componente, ele deve
pegar o token do componente. Sendo o token nico por componente, apenas um
desenvolvedor poder alterar um determinado componente por vez. Se o
componente desejado foi previamente reservado para um desenvolvedor, este deve
liberar seu token para que outro desenvolvedor tenha permisso para alter-lo.
A pgina de controle de alteraes da Token, apresentada na Figura 2.5,
exibe o estado de todos os componentes que esto sob custdia do Token. A pgina
oferece comandos para visualizar as alocaes efetuadas sobre um componente,
alocar, desalocar, adicionar e remover componentes. Token controla a alocao de
componentes no nvel lgico, limitando o acesso aos componentes presena de
seus tokens, e no nvel fsico, disponibilizando os arquivos com o cdigo fonte dos
componentes.

25

Figura 2.5 Pgina de controle de alterao em componentes

A desalocao de componentes um processo complexo, onde Token
reconstri a estrutura do projeto a partir dos componentes existentes em sua base e
do componente recentemente liberado. Para que um componente seja desalocado,
necessrio que ele tenha sido previamente alocado pelo desenvolvedor corrente e
que esse desenvolvedor informe o nome do componente, o arquivo contendo seu
cdigo fonte e uma descrio das alteraes que o componente sofreu. Os passos
executados pela ferramenta na desalocao de um componente so:

Fazer um backup do arquivo que contm o cdigo fonte do componente,

antes das alteraes realizadas pelo desenvolvedor corrente;

Atualizar uma pgina que indica todas as atualizaes sofridas pelo
componente, mantendo um histrico das alteraes realizadas por cada

desenvolvedor; e
Reconstruir o arquivo que contm o cdigo fonte completo do projeto, a partir
dos arquivos com o cdigo fonte de seus componentes.

26
O diagrama apresentado na figura 2.6 exibe a forma de iterao da Token
com suas bases de dados e com o usurio, representado por uma conexo HTTP
vinda de uma mquina cliente.

Figura 2.6 Diagrama de iterao da Token

27
3. CONCLUSO

Atravs da aplicabilidade de melhores prticas em gerenciamento de projetos,

possvel anular ou amenizar as principais falhas que ocasionam tantos fracassos
em projetos. Pois com essas melhores prticas, ser possvel entregar o projeto com
toda a especificao prevista no escopo, o projeto se encaixar no oramento
previsto, o projeto ser entregue no cronograma previsto e a satisfao do cliente
estar garantida com o atendimento da qualidade esperada.

28

REFERENCIAS

PRESSMAN, Roger S. Engenharia de Software. 6 Edio. So Paulo. Pearson

Education do Brasil, 2006.
FREEMAN, Eric. et al. Use a Cabea! Padres e Projetos. 2 Edio. Rio de
Janeiro. Alta Books, 2009.
FERNANDES, Aguinaldo Aragon; ABREU, Vladimir Ferraz de. Implantando a
Governana de TI: Da Estratgia Gesto dos Processos e Servios. 2 Edio.
Rio de Janeiro: Brasport, 2008.
PRESSMAN, Roger S. Engenharia de Software: Uma Abordagem Prtica. 6
Edio. So Paulo. Macgraw Hill, 2009.
Vargas, Ricardo Viana. Manual Prtico do Plano de Projeto: Utilizando o PMBOK
Guide. 4 Edio. Rio de Janeiro: Brasport, 2009.
NGELO, ALDACIR DA SILVA. Entendendo o PRINCE2. Mundo PM - Project
Management, Paran, Notcias e Mercado.
PROFESSOR
PROJETO.
Internet.
Disponvel
<www.professorprojeto.blogspot.com>. Acesso em: 29 de maro de 2011.

em:

CONFLITOS E AS FASES DO PROJETO. Internet. Disponvel em: www.ricardovargas.com/pt/podcasts/conflicts-and-project-phases. Acesso em: 30 de maro de
2011.
AS SETES FASES DE UM PROJETO. Internet. Disponvel em: <http://estousem.blogspot.com/2009/02/as-sete-fases-de-um-projeto-by-max.html>. Acesso em:
31 de maro de 2011.
FASES DE UM PROJETO SEGUNDO O PMBOK. Internet. Disponvel em:
<http://www.augustovespermann.com/2010/03/fases-de-um-projeto-segundo-opmbok>. Acesso em 01 de abril de 2011.
AS FASES DO GERENCIAMENTO DE PROJETOS. Internet. Disponvel em: <
http://www.ogerente.com.br/novo/colunas_ler.php?
canal=14&canallocal=46&canalsub2=149&id=1355>. Acesso em 02 de abril de 2011.

29

ETAPAS
DE
UM
PROJETO.
Internet.
Disponvel
<http://www.avellareduarte.com.br/projeto/conceitos/projeto/projetoa.htm>.
em: 02 de abril de 2011

em:
Acesso