Solucao Para Melhoria de Performance Em Projetos de Aplicativos

40
UNIVERSIDADE PAULISTA JOSÉ ALEXANDRE ROSA VERDEROSA RA 0920667 SOLUÇÃO PARA MELHORIA DE PERFORMANCE EM PROJETOS DE APLICATIVOS

description

pl

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