Solucao Para Melhoria de Performance Em Projetos de Aplicativos
description
Transcript of Solucao Para Melhoria de Performance Em Projetos de Aplicativos
UNIVERSIDADE PAULISTA
JOSÉ ALEXANDRE ROSA VERDEROSA
RA 0920667
SOLUÇÃO PARA MELHORIA DE PERFORMANCE EM PROJETOS DE APLICATIVOS
MARABÁ
2011
JOSÉ ALEXANDRE ROSA VERDEROSA
RA 0920667
SOLUÇÃO PARA MELHORIA DE PERFORMANCE EM PROJETOS DE APLICATIVOS
Projeto Integrado Disciplinar para obtenção
de média em Gestão de Tecnologia da
Informação apresentado à Universidade
Paulista - UNIP
Orientador: Prof° Ivanirso Lima
MARABÁ
2011
RESUMO
Esta proposta técnica tem como objetivo apresentar soluções para melhoraria na
performance em projetos de aplicativos no que tange ao binômio prazo e
orçamento em projetos de TI. Haja vista o quanto essas duas variáveis têm
influenciado o mercado de TI brasileiro, a melhor solução encontrada para sanar
essas deficiências 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 alterações em projetos de
software em desenvolvimento: Token.
Palavras-chave: Prazo. Orçamento. 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.
.
SUMÁRIO
1 INTRODUÇÃO..........................................................................................................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 práticas e o modelo de Governança de TI........................11
2.3 PRINCE2 – Project in Controlled Environments…………………………………...12
2.3.1 Benefícios 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 estágio........................................................17
2.3.4.5 Controlando um estágio.................................................................................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 Organização...................................................................................................19
2.3.5.3 Planos............................................................................................................20
2.3.5.4 Controles........................................................................................................20
2.3.5.5 Gestão de riscos............................................................................................20
2.3.5.6 Qualidade no ambiente do projeto.................................................................20
2.3.5.7 Gestão da configuração.................................................................................20
2.3.5.8 Controle da mudança.....................................................................................21
2.3.6 As técnicas da metodologia..............................................................................21
2.4 Ferramenta para o controle de alterações em projetos de software
em desenvolvimento..................................................................................................21
2.4.1 Cadastramento de Desenvolvedores...............................................................22
2.4.2 Mecanismos de Comunicação entre Desenvolvedores...................................23
2.4.3 Mecanismos de Controle de Alteração..............................................................24
3. CONCLUSÃO.........................................................................................................27
REFERENCIAS..........................................................................................................28
7
1. INTRODUÇÃO
Uma empresa é bem conceituada no mercado quando consegue atender a
dois requisitos que medem sua eficiência: prazo e orçamento.
De acordo com a Gartner, apenas 67% das organizações conseguem
entregar seus projetos dentro do orçamento. As estatísticas são ainda mais
alarmantes quando se trata de prazo, apenas 57% das organizações conseguem
atender a esse indicador.
Projetos de TI historicamente são caracterizados por atrasos demasiados,
aparentes descaso para com o orçamento, e resultados aquém das expectativas dos
clientes e usuários finais. O acúmulo destas falhas acaba provocando por sua vez,
retrabalho.
A solução para essas deficiências é uma estruturação por parte da
concepção, planejamento, execução e fechamento dos projetos. Essa estruturação
pode ser alcançada através de uma metodologia de gerenciamento de projetos em
concomitante uso com uma ferramenta de apoio.
8
2. DESENVOLVIMENTO
2.1. Motivos da incapacidade em gerenciamento de projetos
Os projetos de TI possuem características diferentes dos projetos de outras
áreas do conhecimento, O setor de tecnologia da informação (TI) apresenta
historicamente uma grande desvantagem em relação a segmentos mais maduros da
nossa economia. Por exemplo, um dos setores que há mais tempo trabalha de
maneira formal e organizada gerência de projetos é o da construção civil, onde é
muito comum que empreendimentos aconteçam dentro do prazo previsto, dentro do
orçamento e que não desmoronem após sua conclusão. Uma das razões
conhecidas por trás deste fato é em função do tempo que é gasto com detalhes do
desenho do empreendimento antes de sua construção. O desenho tem que ficar
estável em determinado momento para que possa ser construído. A flexibilidade
para mudanças, apesar de reconhecidamente existir, é menor durante seu
desenvolvimento. Quando nos voltamos para projetos de tecnologia da informação
essa lógica não é necessariamente a mesma. Até em função das constantes
mudanças que o ambiente de negócios impõe a realidade das corporações e a
velocidade da evolução que TI teve que apresentar para acomodar estas mudanças
de uma forma mais flexível. Não existe outro setor que tenha se desenvolvido e
evoluído tanto e em um ritmo tão devastador quanto o de tecnologia (IEEE, 2001). E
particularmente quando nos referimos ao desenvolvimento de software esta
evolução frenética teria que apresentar conseqüências, principalmente no que diz
respeito à taxa de sucesso em projetos.
Projetos de informática são diferentes e merecem tratamento diferenciado.
Mas, estes projetos possuem os mesmos desafios que todos os outros projetos tem.
A solução para os responsáveis nas organizações bem como os profissionais da
área são de ficar atentos aos pecados clássicos historicamente cometidos e passar
a praticar a boa gerência de projetos. Assim reduzir-se-á o número de fracassos e
aumentar-se-á a probabilidade de realizar o sonho de projetos de TI que atendam
aos parâmetros de custo, prazo e qualidade e atendendo plenamente aos clientes e
usuários. Eis algumas das características inerentes a projetos de informática:
indefinição no estado final dos projetos; sobreposição entre as fases dos projetos;
pouca informação histórica para auxiliar nas estimativas; papéis distintos como
9
análise, execução do projeto, programação e testes de qualidade geralmente são
realizados pela mesma pessoa; os pontos de não retorno (cancelamento) não são
claros; e há tendência do profissional de TI querer “engordar” o projeto.
2.1.1. Principais falhas no gerenciamento de projetos de TI
Não cumprimento dos prazos e estabelecidos: Não gerenciar mudanças nos
requisitos do sistema e no escopo do trabalho (EAP) – Mudanças nos requisitos
(funções ou características do sistema) são frutos de avanços tecnológicos, novos
cenários de mercado e decisões políticas internas. Tais mudanças requerem
controles e acompanhamento, pois as mesmas provocam repercussões no trabalho
necessário para completar o projeto a contento.
Problemas de comunicação: Definição ambígua dos requisitos do sistema e
do escopo do trabalho (EAP) – Os requisitos do sistema são as características e
funções a serem incluídas no sistema. Estes por sua vez partem dos “requerimentos
do negócio”. A clara definição 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
negócio, entender o cenário em torno do projeto e verificar o alinhamento do projeto
com as estratégias da empresa. Parte destas ações extrapola a responsabilidade da
área de TI, no entanto, em função do forte impacto destes itens no projeto em si,
merecem ser monitorados e alinhados através de interface com as outras áreas
envolvidas. O bom início também exige a existência 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 questões comportamentais e de gerência de stakeholders
– Quando a área de TI é solicitada a desenvolver um projeto, parte-se da premissa
que a solução será fundamentalmente técnica em natureza. Logicamente, as
soluções desenvolvidas pelos profissionais de TI espalharão aquela necessidade.
Este contexto tecnológico induz os responsáveis pelo projeto a dar pouca ênfase ao
lado humano. Mesmo reconhecendo que a solução final será de essência técnica, o
trabalho é realizado por pessoas que enfrentam desafios semelhantes aos de
profissionais de outras áreas. Isto é, existem desafios de comunicação, conflito de
10
personalidades, necessidade de criar espírito de equipe, e questões políticas, entre
outros. Os stakeholders, portanto (todos que tem a ganhar ou a perder com o
sucesso ou não do projeto) precisam ser proativamente gerenciados para evitar um
fracasso na condução do trabalho.
Mudanças de escopo constantes: O escopo do trabalho, por outro lado,
engloba todas as atividades de trabalho (planejamento, elaboração de códigos, etc.)
necessárias para os requisitos fixados. Isto se desenvolve através da estrutura
analítica do projeto (EAP), também chamada de WBS – Work Breakdown Structure.
A clara fixação do escopo do trabalho garante que todo o trabalho necessário será
realizado e elimina a realização de trabalho desnecessário.
As mudanças no escopo do trabalho também precisam ser monitoradas, pois
novas atividades ou flutuações no volume das atividades existentes, certamente
provocarão novos trabalhos ou retrabalhos, que por sua vez provocarão impacto no
cronograma e orçamento do projeto.
Estimativas erradas de prazo: Dar pouca atenção ao controle dos projetos –
Um cenário não raro em projetos de TI é descobrir, no quinto mês de um projeto
programado para seis meses, que é preciso prorrogar o prazo por um período de
seis meses adicionais, conseqüentemente dobrados o prazo inicial. Tal “descoberta”
é feita apenas no penúltimo mês por falta de controle. Um sistema de controle que
acompanha as datas chaves e marcos principais, identificaria esta tendência cedo
no projeto, em tempo hábil para se tomar medidas corretivas e reduzir o risco de
ocorrer atrasos.
Riscos não avaliados corretamente: Possibilidade de não possuir recursos
humanos suficientes caso algum profissional venha a ter que se ausentar, falta de
infra-estrutura caso algum computador venha a queimar e não possuir outro para
substituí-lo, falta de gerenciamento e controle dos riscos envolvidos com
fornecedores, interrupção no fornecimento de energia elétrica.
Recursos humanos insuficientes: A área de TI era notória pela falta de
estruturação na condução de seus projetos e pelo pouco preparo dos profissionais
na gerencia de projetos. Em função da inteligência e competência 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 freqüência nos projetos
O gerenciamento de todos os projetos de TI em perfeito atendimento aos
parâmetros de custo, prazo e qualidade pode ser um sonho inatingível, no entanto
no número excessivo de fracassos pode ser reduzido substancialmente. O passado
de atrasos horripilantes, pouca atenção aos orçamentos e resultados abaixo das
expectativas dos clientes e usuários finais aos poucos poderá ceder caminho a
projetos mais estruturados que desviam menos dos caminhos traçados. Com isto
reduz-se o retrabalho.
2.2 Modelos de melhores práticas e o modelo de Governança de TI
Para solucionar tantos problemas que acabam ocasionando extrapolação no
orçamento e no tempo de entrega do produto, e assim, consequentemente, melhorar
a performance em projetos, existem quatro modelos de melhores práticas propostas.
Estes modelos com seus respectivos escopos estão mencionados na tabela a
seguir:
12
Modelos de melhores práticas Escopo do modelo
PRINCE2 – Project in Controlled Environments Metodologia de gerenciamento de projetos
P3M3 – Portifólio, Programme & Project
Management Maturity Model
Modelo de maturidade para o gerenciamento de
projetos, programas e portifólio
PMBOK – Project Management Body of
Knowledge
Base de conhecimento em gestão de projetos
OPM3 – Organizational Project Management
Maturity Model
Modelo de maturidade para o gerenciamento de
projetos
Tabela 2.1 – Principais modelos de melhores práticas aplicadas ao
gerenciamento de projetos
2.3 PRINCE2 – Project in Controlled Environments
Dentre os modelos apresentados acima, o que mais se encaixa como solução
na situação em questão é o PRINCE2. Da mesma forma que o PMBOK, o PRINCE2
também possui seu modelo de maturidade. A metodologia PRINCE2 é baseada nas
experiências com os projetos, gerente de projetos e equipes de projeto que
contribuíram com seus erros, acertos e sucessos.
A metodologia é, atualmente, o padrão usado pelo governo Britânico, sendo
também reconhecida e usada no setor privado, tanto na Grã-Bretanha como
internacionalmente.
A PRINCE2 é, de fato, uma metodologia de gerenciamento de projetos, ao
contrário do PMBOK, que é um conjunto de conhecimentos.
Ela se aplica a qualquer tipo de projeto, incluindo os projetos de Tecnologia
da Informação.
2.3.1 Benefícios do modelo
De acordo com uma pesquisa realizada em 2001 pelo Center for Business
Practices (2001) em 43 organizações de variados portes, os seguintes benefícios
foram obtidos com a implantação da gestão de projetos em organizações de TI:
38,6% foi a melhoria na estimativa de prazo;
32,8% foi a melhoria na estimativa de esforço e de custo;
7,6% foi a melhoria na estimativa de qualidade;
13
37,8% foi a melhoria na satisfação dos clientes;
37% foi a melhoria no alinhamento dos projetos com as estratégias do
negócio;
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 orçamento;
25,6% foi a melhoria na utilização 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 método 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, não reativo, mas capaz de acomodar mudanças
repentinas, oriundos de eventos inesperados;
Forneça um guia consistente para os gerentes de projetos e demais
interessados, facilitando o planejamento, o controle e a comunicação no
âmbito do projeto.
2.3.3 Estrutura do modelo
O PRINCE2 (2005) é composto por processos, componentes e técnicas. O
modelo de processos do PRINCE2 contempla cerca de oito processos gerenciais
14
distintos, oito componentes e três técnicas. A Figura 2.2 mostra o relacionamento
entre os processos e componentes. Na PRINCE2, os processos utilizam os
componentes e as técnicas conforme mostra a Figura 2.3.
Figura 2.2 – Processos e componentes da PRINCE2
15
Figura 2.3 – Componentes e técnicas nos processos do PRINCE2
Em relação às descrições dos processos, o manual está estruturado de tal
forma que o usuário encontre o fundamento e o contexto do processo, mostrando o
relacionamento dos sub-processos, as descrições do processo e dos sub-processos,
dicas de aplicação do processo responsabilidades, necessidades de informações
dos sub-processos e critérios chave de execução (também com suas dicas).
Em relação aos componentes, o manual apresenta, ainda que não de forma
padronizada em relação aos tópicos, o objetivo, os benefícios, os elementos e/ou
controles do componente e o seu mapeamento para os processos.
Por fim, em relação às técnicas, as mesmas são descritas de forma breve,
mas indicando também o que é cada técnica, os passos para utilizá-la e assim por
diante.
A metodologia estabelece os templates para serem aplicados imediatamente,
assim como descreve os papéis 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:
Designação da equipe do projeto;
Descrição do projeto;
Definição sobre como, em termos gerais, a solução será fornecida;
Expectativas dos clientes em relação a qualidade;
Lista de riscos; e
Plano do estágio de iniciação.
Deve existir um termo ou documento que autorize o início do projeto.
2.3.4.2 Dirigindo o projeto
Processo que ocorre desde o início do projeto até o seu encerramento, sendo
de responsabilidade do Comitê do Projeto ou do grupo de tomadores de decisão que
representam o negócio, usuários e fornecedores, e abrange:
Autorização da iniciação (processo anterior);
Autorização para o projeto;
Comprometimento de alocação de recursos, a partir de verificações nas
fronteiras dos estágios do projeto;
Monitoramento do progresso;
Estabelecimento de diretrizes para o projeto;
Ações em função de ameaças de riscos ao projeto; e
Encerramento do projeto, controlando todo encerramento de contratos,
desmobilização de recursos, instalações e serviços.
2.3.4.3 Iniciando o projeto
O produto principal deste processo é o Documento de Início do Projeto ou
Termo de Abertura do Projeto. Seus objetivos:
Definir o nível de qualidade do produto a ser gerado;
17
Planejar o projeto e seu custo;
Revisar o Business Case;
Assegurar que o prazo e o esforço possam ser justificados em função dos
riscos do projeto;
Permitir e encorajar o Comitê do Projeto a envolver-se na direção do projeto e
a se comprometer com a disponibilização dos recursos; e
Estabelecer a linha de base inicial do projeto.
2.3.4.4 Gerenciando a fronteiras de um estágio
Como produtos deste processo, podem ser relacionados: Relatório de
Encerramento de Estágio, Plano de Estágio Atual, Plano de Estágio Seguinte, Log
de Risco Atualizado, Business Case atualizado, Log de Lições Aprendidas,
mudanças na equipe. Ojetivos:
Assegurar, para o Comitê do Projeto, que os produtos planejados do Plano de
Estágio atual foram completados;
Prover informação para o Comitê do Projeto para que o mesmo avalie a
viabilidade do projeto;
Prover para o Comitê do Projeto informações necessárias para que aprove o
estágio atual do projeto e que autorize o início do estágio seguinte; e
Registrar medições e lições aprendidas que possam ajudar estágios
posteriores do projeto ou outros projetos.
2.3.4.5 Controlando um estágio
O objetivo deste processo é assegurar que cada estágio seja desempenhado
conforme o Plano do Estágio. Como produtos deste processo podem ser
relacionados: Pacotes de Trabalho (do WBS), Relatórios de Progresso, Diário de
Bordo, Lista de Pendências, Log de Risco Atualizado e Plano de Estágio Adaptado.
Este processo compreende atividades como:
Autorização para execução do trabalho planejado;
Obtenção de informação sobre o progresso do projeto;
Análise de mudanças;
Revisão do projeto;
18
Comunicação acerca do projeto;
Tomada de ações corretivas em função de desvios; e
Prover informação para o Comitê do Projeto para que o mesmo avalie a
viabilidade do projeto.
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 realização 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 especificações de
qualidade; e
Obter a homologação ou aprovação 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 à manutenção e operação foram
realizadas, incluindo treinamento, se for o caso;
Realizar recomendações para trabalhos futuros;
Registrar lições aprendidas em um relatório específico, divulgado para a
operação;
Prepara um relatório de finalização do projeto;
Arquivar os documentos e artefatos gerados pelo projeto;
Produzir um plano de revisão pós-projeto; e
Solicitar do Comitê do Projeto a desmobilização dos recursos alocados ao
projeto.
19
2.3.4.8 Planejamento
Para o PRINCE2 o processo de planejamento se repete e tem um papel
importante em outros processos:
Planejamento do estágio de iniciação do projeto;
Planejamento do projeto;
Planejamento de cada estágio;
Atualização do Plano do Projeto;
Aceitação de um pacote de trabalho; e
Na geração de um Plano de Exceção.
2.3.5 Os componentes da metodologia
2.3.5.1 Business Case
Documento que demonstra a viabilidade do projeto. Este documento contém a
principal condição de controle, ou seja, o resultado do projeto deve atender aos
resultados estimados e documentados no Business Case.
2.3.5.2 Organização
A metodologia propõe uma organização para o projeto, considerando papéis
responsabilidades e relacionamentos de todos os papéis envolvidos no projeto,
assim como indica como esses papéis são exercido, conforme a complexidade do
projeto.
2.3.5.3 Planos
20
A metodologia oferece uma série de níveis de planos que podem ser
adaptados às necessidades do projeto, além de uma abordagem para o
planejamento baseado em produtos, ao contrário de atividades.
2.3.5.4 Controles
Conjunto de controles orientados para a gestão por exceção e que atuam
sobre os estágios. Tais controles permitem a avaliação dos produtos em termos de
atendimento a escopo e qualidade, e do projeto em termos de prazo, custo, esforço,
qualidade, etc. A metodologia inclui também revisões formais em vários pontos do
ciclo de vida do projeto.
2.3.5.5 Gestão de riscos
Gestão dos riscos em todo o ciclo de vida do projeto, determinado os pontos
de sua revisão.
2.3.5.6 Qualidade no ambiente do projeto
Gerenciamento da qualidade do projeto, compreendendo um Plano da
Qualidade, critérios de aceitação, requisitos de qualidade do produto, registros e
verificações da qualidade.
2.3.5.7 Gestão da configuração
Permite o rastreamento dos componentes produzidos ao longo do projeto até
a montagem do produto final. Estabelece um plano de configuração e um método
abrangente para sua execução.
2.3.5.8 Controle da mudança
21
Conjunto de diretrizes acerca de como gerenciar as mudanças no projeto, que
acontecem em função de ocorrência de riscos, surgimento de restrições, etc.
2.3.6 As técnicas da metodologia
São basicamente três as técnicas empregadas pela PRINCE2:
Planejamento baseado em produto, que na realidade são técnicas para a
elaboração de um Work Breakdown Structure (a PRINCE2 denomina o WBS
como PBS ou Product Breakdown Structure);
Técnica de controle da mudança e, por fim;
Técnica de revisão da qualidade.
2.4 Ferramenta para o controle de alterações em projetos de software em
desenvolvimento
Os projetos de desenvolvimento de aplicativos contemporâneos têm
progressivamente aumentado de tamanho e complexidade, sendo cada vez mais
comum sua realização por equipes de médio porte (entre 10 e 20 desenvolvedores)
e grande porte (acima de 20 desenvolvedores). Com as facilidades de comunicação
proporcionadas pela Internet, a necessidade de experiência em diversas áreas de
conhecimento e a pressão por cronogramas mais restritos, alguns projetos são
realizados por diversas equipes trabalhando concorrentemente. Ainda mais, as
dificuldades de reunir os especialistas necessários em um mesmo local físico e a
delegação do desenvolvimento de determinados componentes para outras
empresas, são exemplos de fatores que podem exigir que as equipes participantes
de um projeto estejam geograficamente distribuídas.
Entretanto, a existência de mecanismos eficientes de comunicação, como a
Internet, não soluciona os problemas de desenvolvimento concorrente de projetos de
software. Ao contrário, o novo cenário traz novos problemas para o processo de
desenvolvimento. Por exemplo, o trabalho concorrente de equipes geograficamente
distribuídas dificulta o controle de alterações nos componentes de um projeto em
desenvolvimento. Mesmo quando precedida de uma precisa definição das interfaces
entre os componentes, a realização de um projeto pode exigir que diversos
desenvolvedores alterem simultaneamente os mesmos componentes. Estas
22
situações exigem a adoção de políticas para manter a consistência entre os
componentes da versão atual do projeto ou permitir que essa consistência seja
posteriormente restituída.
A ferramenta Token foi desenvolvida para apoiar o desenvolvimento
concorrente de projetos de software, auxiliando na resolução dos problemas de
controle de alterações nos componentes do projeto. Token sincroniza o acesso aos
componentes que compõem um projeto de software, inibindo vários usuários para
alterar um componente específico em simultâneo. Suas principais funcionalidades
são: o cadastramento dos desenvolvedores participantes do projeto, a troca de
informações entre estes desenvolvedores e o controle de alterações 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 é acessível via um navegador Internet, sendo independente da
plataforma cliente.
Algumas das vantagens em utilizar o Token são: o seu custo reduzido, por ser
baseado em plataforma gratuita (Linux, Apache, PHP3 e MySQL), ter como meio de
comunicação a Internet, permitindo um desenvolvimento totalmente distribuído, e ser
independente de plataforma, tanto no lado cliente como no lado servidor.
2.4.1 Cadastramento de Desenvolvedores
Token fornece suporte para o cadastramento dos desenvolvedores
participantes de um projeto. Este cadastramento é necessário para que os
desenvolvedores tenham acesso aos recursos de comunicação oferecidos pela
ferramenta. Além disso, somente os desenvolvedores cadastrados terão acesso aos
componentes do projeto, acessados através dos mecanismos de controle de
alteração da ferramenta.
O início da página de cadastramento de desenvolvedores lista as informações
de todos os desenvolvedores previamente cadastrados como participantes do
projeto. O restante da página permite a troca da senha do desenvolvedor corrente, o
cadastramento de um novo desenvolvedor e a remoção de um desenvolvedor
previamente cadastrado.
2.4.2 Mecanismos de Comunicação entre Desenvolvedores
23
Para facilitar a comunicação entre os desenvolvedores, Token oferece um
quadro de mensagens. Para controlar um grande número de mensagens, estas são
indexadas por assuntos. A página 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 através da ferramenta Token, os
desenvolvedores cadastrados recebem uma notificação por e-mail. A notificação
indica o assunto da mensagem, seu tipo e contém um link para a página de
mensagens da Token. Os tipos de mensagem utilizados na Token são: pergunta,
resposta, informação e urgente. Na versão atual da ferramenta, os tipos de
mensagem são meramente informativos, permitindo ao leitor uma rápida
identificação do objetivo da mensagem e a criação de filtros em seu e-mail.
Figura 2.4 – Página de comunicação entre usuários
2.4.3 Mecanismos de Controle de Alteração
24
As páginas 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 distribuídas.
A abordagem adotada consiste na divisão de um projeto em diversos
componentes atômicos de software. Os componentes são acessíveis pelos
desenvolvedores através 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.
Token segue a mesma abstração dos protocolos de comunicação das redes
de computadores Token Ring e Token Bus. Nestas redes, diversos computadores
compartilham um meio de comunicação 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 tráfego 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, através da ferramenta Token, os desenvolvedores podem
alocar ou desalocar componentes. Cada componente possui um token, que se
encontra disponível quando o componente não 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 permissão para alterá-lo.
A página de controle de alterações da Token, apresentada na Figura 2.5,
exibe o estado de todos os componentes que estão sob custódia do Token. A página
oferece comandos para visualizar as alocações efetuadas sobre um componente,
alocar, desalocar, adicionar e remover componentes. Token controla a alocação de
componentes no nível lógico, limitando o acesso aos componentes à presença de
seus tokens, e no nível físico, disponibilizando os arquivos com o código fonte dos
componentes.
25
Figura 2.5 – Página de controle de alteração em componentes
A desalocação de componentes é um processo complexo, onde Token
reconstrói a estrutura do projeto a partir dos componentes existentes em sua base e
do componente recentemente liberado. Para que um componente seja desalocado,
é necessário que ele tenha sido previamente alocado pelo desenvolvedor corrente e
que esse desenvolvedor informe o nome do componente, o arquivo contendo seu
código fonte e uma descrição das alterações que o componente sofreu. Os passos
executados pela ferramenta na desalocação de um componente são:
Fazer um backup do arquivo que contém o código fonte do componente,
antes das alterações realizadas pelo desenvolvedor corrente;
Atualizar uma página que indica todas as atualizações sofridas pelo
componente, mantendo um histórico das alterações realizadas por cada
desenvolvedor; e
Reconstruir o arquivo que contém o código fonte completo do projeto, a partir
dos arquivos com o código fonte de seus componentes.
26
O diagrama apresentado na figura 2.6 exibe a forma de iteração da Token
com suas bases de dados e com o usuário, representado por uma conexão HTTP
vinda de uma máquina cliente.
Figura 2.6 – Diagrama de iteração da Token
27
3. CONCLUSÃO
Através da aplicabilidade de melhores práticas em gerenciamento de projetos,
é possível anular ou amenizar as principais falhas que ocasionam tantos fracassos
em projetos. Pois com essas melhores práticas, será possível entregar o projeto com
toda a especificação prevista no escopo, o projeto se encaixará no orçamento
previsto, o projeto será entregue no cronograma previsto e a satisfação do cliente
estará garantida com o atendimento da qualidade esperada.
28
REFERENCIAS
PRESSMAN, Roger S. Engenharia de Software. 6° Edição. São Paulo. Pearson
Education do Brasil, 2006.
FREEMAN, Eric. et al. Use a Cabeça! Padrões e Projetos. 2° Edição. Rio de
Janeiro. Alta Books, 2009.
FERNANDES, Aguinaldo Aragon; ABREU, Vladimir Ferraz de. Implantando a
Governança de TI: Da Estratégia à Gestão dos Processos e Serviços. 2° Edição.
Rio de Janeiro: Brasport, 2008.
PRESSMAN, Roger S. Engenharia de Software: Uma Abordagem Prática. 6°
Edição. São Paulo. Macgraw Hill, 2009.
Vargas, Ricardo Viana. Manual Prático do Plano de Projeto: Utilizando o PMBOK
Guide. 4° Edição. Rio de Janeiro: Brasport, 2009.
ÂNGELO, ALDACIR DA SILVA. Entendendo o PRINCE2. Mundo PM - Project Management, Paraná, Notícias e Mercado.
PROFESSOR PROJETO. Internet. Disponível em: <www.professorprojeto.blogspot.com>. Acesso em: 29 de março de 2011.
CONFLITOS E AS FASES DO PROJETO. Internet. Disponível em: www.ricardo-vargas.com/pt/podcasts/conflicts-and-project-phases. Acesso em: 30 de março de 2011.
AS SETES FASES DE UM PROJETO. Internet. Disponível em: <http://estou-sem.blogspot.com/2009/02/as-sete-fases-de-um-projeto-by-max.html>. Acesso em: 31 de março de 2011.
FASES DE UM PROJETO SEGUNDO O PMBOK. Internet. Disponível em: <http://www.augustovespermann.com/2010/03/fases-de-um-projeto-segundo-o-pmbok>. Acesso em 01 de abril de 2011.
AS FASES DO GERENCIAMENTO DE PROJETOS. Internet. Disponível 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.
ETAPAS DE UM PROJETO. Internet. Disponível em: <http://www.avellareduarte.com.br/projeto/conceitos/projeto/projetoa.htm>. Acesso em: 02 de abril de 2011