plano de projeto do desenvolvimento de um sistema de gerenciamento de conteúdo integrado com redes...

AFONSO FRANÇA DE OLIVEIRA

Plano de Projeto do desenvolvimento de um Sistema deGerenciamento de Conteúdo integrado com redes sociais

Trabalho apresentado ao curso MBA em

Gerenciamento de Projetos, Pós-Graduação lato

sensu, da Fundação Getúlio Vargas como requisito

parcial para a obtenção do Grau de Especialista em

Gerenciamento de Projetos.

ORIENTADOR: Prof. André Valle

Volta Redonda - RJ

Janeiro / 2013

FUNDAÇÃO GETULIO VARGAS

PROGRAMA FGV MANAGEMENT

MBA EM GERENCIAMENTO DE PROJETOS

O Trabalho de Conclusão de Curso

Plano de Projeto do desenvolvimento de um Sistema de Gerenciamento de Conteúdo integrado com

redes sociais

Elaborado por Afonso França de Oliveira

e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos, foi aceito

como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de

especialização do Programa FGV Management.

Volta Redonda, 5 de Janeiro de 2013

André Bittencourt do Valle

Coordenador Acadêmico Executivo

André Bittencourt do Valle

Professor Orientador

TERMO DE COMPROMISSO

O aluno Afonso França de Oliveira, abaixo assinado, do curso de MBA em Gerenciamento de

Projetos, Turma AEDB1/TMBAGPJ*0608-1 do Programa FGV Management, realizado nas

dependências da AEDB – Volta Redonda, no período de 07/05/2008 a 21/01/2010, declara que o

conteúdo do Trabalho de Conclusão de Curso intitulado Plano de Projeto do desenvolvimento de um

Sistema de Gerenciamento de Conteúdo integrado com redes sociais, é autêntico, original e de sua

autoria exclusiva.

Volta Redonda, 15 de Março de 2013

Afonso França de Oliveira

Dedicatória

Ao meu pai por despertar em mim

a criatividade, e a minha mãe por incitar

a curiosidade, dedico a conquista

desta etapa.

RESUMO

Este trabalho apresenta um plano de projeto elaborado com base no PMBOK, o qual será

usado como orientação principal na criação de um sistema de gerenciamento de conteúdos diferente,

voltado à integração com redes sociais, à facilidade de uso e à alta capacidade de personalização. O

sistema terá como objetivo atender a micro e pequenas empresas da região sul do estado do Rio de

Janeiro. Região que está em pleno crescimento e carente de sites de qualidade.

Palavras Chave: Gerenciamento de Conteúdo, Redes sociais, WYSIWYG, CMS, Web Design, Web

Site e Gerenciamento de projetos.

ABSTRACT

This paper presents a project plan prepared based on the PMBOK, which will be used as the

main guidance in creating a different content management system, based on social networking

integration, ease of use and highly customizable. The system will attend micro and small enterprises in

the southern state of Rio de Janeiro. That region is growing and needs high quality sites.

Key Words: Content Management, Social Networking, WYSIWYG, CMS, Web Design, Web Site

and Project Management.

AGRADECIMENTOS

Pela saúde e força a mim proporcionadas, agradeço a Deus.

Aos familiares e amigos agradeço o apoio e colaboração, sem as quais não obteria êxito em

minha conquista. Sobretudo ao amigo de classe Jeferson Azevedo, sou grato por seu companheirismo

e auxílio ao longo do curso.

A minha companheira Juliana, dedico meus sinceros agradecimentos por seu empenho em me

amparar no decorrer do curso e também por revisar este trabalho.

SUMÁRIO

Sumário.....................................................................................................................................................1

1. Introdução.............................................................................................................................................6

1.1 Objetivos do Trabalho....................................................................................................................7

1.2 Estrutura do trabalho......................................................................................................................7

2. Fundamentação Teórica........................................................................................................................8

2.1 Sistema de Gerenciamento de Conteúdo........................................................................................8

2.1.1 Problemas de usabilidade dos CMS’s.....................................................................................9

2.1.2 Problemas de segurança dos CMS’s......................................................................................11

2.2 Integração dos sistemas de gerenciamento de conteúdo..............................................................11

3. Metodologia Científica.......................................................................................................................13

4. Plano de Projeto..................................................................................................................................14

4.1 Termo de abertura.........................................................................................................................14

4.1.1 Título do Projeto....................................................................................................................14

4.1.2 Resumo das condições do projeto.........................................................................................14

4.1.3 Nome do Gerente do Projeto, suas responsabilidades e sua autoridade................................14

4.1.4 Necessidades básicas do trabalho a ser realizado..................................................................14

4.1.5 Descrição do Projeto..............................................................................................................15

4.1.6 Administração........................................................................................................................15

4.2 Declaração de Escopo...................................................................................................................17

4.2.1 Time do Projeto.....................................................................................................................17

4.2.2 Descrição do projeto..............................................................................................................17

4.2.3 Objetivo do projeto................................................................................................................17

4.2.4 Justificativa do Projeto..........................................................................................................17

4.2.5 Produto do Projeto.................................................................................................................17

4.2.6 Expectativa do Patrocinador..................................................................................................17

4.2.7 Fatores de sucesso do projeto................................................................................................18

4.2.8 Restrições...............................................................................................................................18

8

4.2.9 Premissas...............................................................................................................................18

4.2.10 Limites do Projeto e exclusões específicas..........................................................................18

4.2.11 Principais atividades e estratégias do projeto......................................................................18

4.2.12 Entregas do Projeto..............................................................................................................20

4.2.13 Orçamento do Projeto..........................................................................................................20

4.2.14 Plano de entregas e marcos do projeto................................................................................20

4.3 Estrutura Analítica do Projeto......................................................................................................21

4.3.1 Visualização Hierárquica.......................................................................................................21

4.3.2 Dicionário da EAP.................................................................................................................21

4.4 Plano de Gerenciamento de Escopo.............................................................................................27

4.4.1 Descrição dos processos de gerenciamento de escopo..........................................................27

4.4.2 Priorização das mudanças de escopo e respostas..................................................................27

4.4.3 Gerenciamento das configurações (Configuration management).........................................27

4.4.4 Freqüência de avaliação do escopo do projeto......................................................................28

4.4.5 Alocação financeira das mudanças de escopo.......................................................................28

4.4.6 Administração do plano de gerenciamento de escopo...........................................................29

4.4.7 Outros assuntos relacionados ao gerenciamento do escopo do projeto não previstos neste

plano...............................................................................................................................................29

4.5 Plano de Gerenciamento de Tempo..............................................................................................30

4.5.1 Descrição dos processos de gerenciamento de tempo...........................................................30

4.5.2 Priorização das mudanças nos prazos....................................................................................30

4.5.3 Sistema de controle de mudanças de prazos (Schedule Change Control System)................31

4.5.4 Mecanismo adotado para conflitos de recursos.....................................................................31

4.5.5 Buffer de tempo do projeto....................................................................................................32

4.5.6 Freqüência de avaliação dos prazos do projeto.....................................................................32

4.5.7 Alocação financeira para o gerenciamento de tempo............................................................32

4.5.8 Administração do plano de gerenciamento de tempo............................................................32

4.5.9 Outros assuntos relacionados ao gerenciamento de tempo do projeto não previstos neste

plano...............................................................................................................................................32

9

4.6 Plano de Gerenciamento de Custos..............................................................................................34

4.6.1 Descrição dos processos de gerenciamento de custos...........................................................34

4.6.2 Freqüência de avaliação do orçamento do projeto e das reservas gerenciais........................34

4.6.3 Reservas gerenciais................................................................................................................34

4.6.5 Autonomias............................................................................................................................35

4.6.6 Alocação financeira das mudanças no orçamento.................................................................36

4.6.7 Administração do plano de gerenciamento de custos............................................................36

4.6.8 Outros assuntos relacionados ao gerenciamento de custos do projeto não previstos neste

plano...............................................................................................................................................36

4.7 Plano de Gerenciamento de Qualidade.........................................................................................37

4.7.1 Identificação dos clientes.......................................................................................................37

4.7.2 Priorização dos clientes.........................................................................................................37

4.7.3 Identificação das necessidades..............................................................................................37

4.7.4 Priorização das necessidades.................................................................................................38

4.7.5 Priorização clientes x necessidades.......................................................................................39

4.7.6 Desenvolvimento de especificações......................................................................................40

4.7.7 Garantia de Qualidade...........................................................................................................41

4.7.8 Priorização das mudanças nos quesitos de qualidade e respostas.........................................41

4.7.9 Sistema de controle de mudanças da qualidade (Quality change control system)................41

4.7.10 Alocação financeira das mudanças nos requisitos de qualidade.........................................42

4.7.11 Administração do plano de gerenciamento de qualidade....................................................42

4.7.12 Outros assuntos relacionados ao gerenciamento de qualidade do projeto não previstos

neste plano......................................................................................................................................43

4.8 Plano de Gerenciamento de Recursos Humanos..........................................................................44

4.8.1 Organograma do projeto........................................................................................................44

4.8.2 Diretório do time do projeto (Team directory)......................................................................44

4.8.3 Matriz de responsabilidades..................................................................................................45

4.8.4 Novos recursos, realocação e substituição de membros do time...........................................45

4.8.5 Treinamento...........................................................................................................................45

10

4.8.6 Avaliação de resultados.........................................................................................................45

4.8.7 Bonificação............................................................................................................................45

4.8.8 Frequência de avaliação consolidada dos resultados do time................................................46

4.8.9 Alocação financeira para o gerenciamento de RH................................................................46

4.8.10 Administração do plano de gerenciamento de recursos humanos.......................................46

4.8.11 Outros assuntos relacionados ao gerenciamento de RH do projeto não previstos neste

plano...............................................................................................................................................46

4.9 Plano de Gerenciamento de Comunicações..................................................................................48

4.9.1 Descrição dos processos de gerenciamento das comunicações.............................................48

4.9.2 Registros das partes interessadas...........................................................................................48

4.9.3 Matriz de análise das partes interessadas..............................................................................49

4.9.4 Estratégia de Gerenciamento de Partes Interessadas.............................................................49

4.9.5 Eventos de Comunicação.......................................................................................................50

4.9.6 Cronograma dos Eventos de Comunicação...........................................................................52

4.9.7 Atas de Reunião.....................................................................................................................52

4.9.8 Relatórios do projeto.............................................................................................................53

4.9.9 Ambiente técnico e estrutura de armazenamento e distribuição da informação (EPM).......56

4.9.10 Alocação financeira para o gerenciamento das comunicações............................................57

4.9.11 Administração do plano de gerenciamento das comunicações...........................................58

4.9.12 Outros assuntos relacionados ao gerenciamento das comunicações do projeto não previstos

neste plano......................................................................................................................................58

4.10 Plano de Gerenciamento de Riscos............................................................................................59

4.10.1 Descrição dos processos de gerenciamento de riscos..........................................................59

4.10.2 RBS – Risk Breakdown Structure para a identificação dos riscos......................................59

4.10.3 Riscos identificados.............................................................................................................60

4.10.4 Qualificação dos riscos........................................................................................................60

4.10.5 Quantificação dos riscos......................................................................................................61

4.10.6 Sistema de controle de mudanças de riscos (Risk change control system).........................61

4.10.7 Respostas planejadas aos riscos...........................................................................................62

11

4.10.8 Reservas de contingência.....................................................................................................64

4.10.9 Frequência de avaliação dos riscos do projeto....................................................................65

4.10.10 Alocação financeira para o gerenciamento de riscos.........................................................65

4.10.11 Administração do plano de gerenciamento de riscos........................................................65

4.10.12 Outros assuntos relacionados ao gerenciamento de risco do projeto não previstos neste

plano...............................................................................................................................................65

4.11 Plano de Gerenciamento de Aquisições.....................................................................................67

4.11.1 Descrição dos processos de gerenciamento das aquisições.................................................67

4.11.2 Gerenciamento e tipos de contratos.....................................................................................67

4.11.3 Critérios de avaliação de cotações e propostas....................................................................68

4.11.4 Avaliação de fornecedores...................................................................................................68

4.11.5 Frequência de avaliação das aquisições do projeto.............................................................68

4.10.6 Alocação financeira para o gerenciamento de aquisições...................................................68

4.10.7 Administração do plano de gerenciamento de aquisições...................................................69


plano...............................................................................................................................................69

5. Conclusões..........................................................................................................................................70

6. Referências Bibliográficas..................................................................................................................72

12

1. INTRODUÇÃO

De acordo com (MUSEU DO COMPUTADOR, 2004), há 17 anos o Brasil, acompanhando o

mundo se adentrou na era da Internet. A partir daí muitas empresas iniciaram a migração de algumas

de suas atividades para o ambiente online. Lembro-me de fazer em 1996 um curso de "Introdução à

Internet" em que fui apresentado a um dos primeiros portais desbravadores da Internet do Brasil, o

UOL, e tive a oportunidade de acessar de forma espantada o site da NASA.

Naquela época pouquíssimas pessoas tinham acesso, os sites eram simples e a principal

linguagem em que eles eram desenvolvidos, o HTML, estava em sua versão 3.2, conforme

(RAGGETT, 1997), que havia pela primeira vez sido especificada por um consórcio, porém a

iniciativa privada liderada pelos navegadores Netscape e Internet Explorer (VALIN, 2009) dificultava

a criação de sites, pois, uma página que funcionava em determinado navegador funcionava

obrigatoriamente funcionava em outro. Nesta mesma época, outra ferramenta necessária para o

desenvolvimento de sites, a linguagem de servidor, estava dando seus primeiros passos com CGI, ASP

(WIKIPEDIA, 2013) e PHP (WIKIPEDIA, 2013). Essa era mais uma barreira que dificultava a

criação de sites dinâmicos, usáveis e próximos da experiência que já tínhamos ao usar um software

nativo do sistema operacional.

Hoje, segundo (QUAINO, 2012) as coisas estão muito diferentes. Em 2011, mais da metade

da população brasileira acessou de alguma maneira regularmente a Internet. Isso se deve muito ao

fenômeno das redes sociais digitais no Brasil. Sites como o Fotolog, o Orkut e o Facebook foram aos

poucos acelerando a inclusão digital e formaram usuários habilidosos pela simples necessidade deles

de se expressarem socialmente (RECUERO, 2009).

Na área empresarial a evolução está sendo um pouco mais rápida. Segundo uma pesquisa

divulgada em 2011 pelo Centro de Estudos sobre as Tecnologias da Informação e da Comunicação

(CETIC.BR, 2012), 60% das empresas brasileiras já possuem site institucional. A pesquisa ainda

informa que 50% das empresas de pequeno porte possuem site e apenas 27% das microempresas

possuem uma página própria na Internet. Ainda podemos constatar neste estudo que, 93% das

empresas brasileiras possuem acesso à Internet.

Considerando estes dados, podemos observar um grande mercado à frente no que diz respeito

à construção de sites institucionais de micro e pequenas empresas. Além disso, se considerarmos que

muitas dessas empresas optaram, em um primeiro momento, por sites mais simples e viáveis ao seu

orçamento e não obtiveram resultados satisfatórios, ou ainda se considerarmos que, algumas

tecnologias estão tendo que ser adaptadas para acesso dos sites em dispositivos portáteis, o mercado é

ainda maior que o indicado pela pesquisa. 13

1.1 OBJETIVOS DO TRABALHO

Tendo essas informações supracitadas como premissas, o objetivo deste trabalho é propor um

plano de projeto seguindo as práticas do PMBOK para criar uma plataforma diferenciada de

gerenciamento de conteúdo, focada na satisfação das necessidades de micro e pequenas empresas, que

seja ao mesmo tempo viável economicamente e de qualidade profissional. Esta plataforma também

precisa ser fácil de usar, segura e inteiramente integrada às redes sociais, permitindo ao cliente

gerenciar o seu conteúdo de forma unificada.

Para reduzir o preço de venda, a ferramenta também precisa ser maleável o suficiente ao ponto

de se adaptar à criação de qualquer layout que um designer faça, sem que haja retrabalho por parte de

programação do sistema, apenas alterando arquivos HTML, de estilo e imagens.

1.2 ESTRUTURA DO TRABALHO

O trabalho está estruturado em seis capítulos:

O primeiro capítulo apresenta a introdução do trabalho com informações históricas sobre a

criação de sites e a situação atual do mercado de desenvolvimento.

O segundo capítulo descreve a fundamentação teórica que envolve o produto do projeto.

O terceiro capítulo apresenta a metodologia científica utilizada na criação do trabalho.

O quarto capítulo envolve o plano de projeto do desenvolvimento do software, onde constam

o planejamento e artefatos das áreas de conhecimento estabelecidas pelo PMBOK.

Na conclusão do trabalho, ou seja, o quinto capítulo apresenta os resultados obtidos e

considerações finais.

14

2. FUNDAMENTAÇÃO TEÓRICA

A fim de atender ao mercado de sites para profissionais liberais e micro empresas, o

patrocinador idealizou desenvolver um sistema de gerenciamento de conteúdo integrado com redes

sociais, visando ser uma opção acessível, fácil de usar, altamente personalizável e seguro.

2.1 SISTEMA DE GERENCIAMENTO DE CONTEÚDO

O sistema de gerenciamento de conteúdo (CMS) é parte integrante de um paradigma que

surgiu no início dos anos 2000, que é chamado de Web 2.0. Este paradigma mudou a forma que as

pessoas enxergavam a internet. Os usuários deixaram de ser meros expectadores e passaram a serem

colaboradores na criação de conteúdo na Web. Nos CMS’s as pessoas podem alimentar a rede com seu

próprio conteúdo e os seus leitores podem colaborar através de comentários, imagens etc. Hoje,

conforme (W3TECHS, 2013), 32% de todos os sites do mundo utilizam algum CMS.

Em consultas realizadas na internet, em sistemas já desenvolvidos e trabalhos correlatos, foi

possível identificar que existem CMS’s similares ao proposto neste trabalho, mas que para atender por

completo as funcionalidades propostas, a instalação de plugins seria necessária. Podemos afirmar que

isto implica em dois problemas: Aumento da complexidade da interface do usuário e abertura de

brechas de segurança. Segue abaixo uma tabela comparativa com os principais sistemas do mercado:

Funcionalidades Wordpress Joomla! Drupal

Aprovação de conteúdo SIM SIM SIM

Editor WYSIWYG SIM SIM SIM

Blog SIM SIM SIM

Categorização SIM SIM SIM

Temas personalizados SIM SIM SIM

API do usuário SIM SIM SIM

Gerenciamento de eventos PLUGIN PLUGIN PLUGIN

Galeria de Fotos PLUGIN PLUGIN PLUGIN

Importação de Álbuns do Facebook PLUGIN PLUGIN PLUGIN

Importação de Vídeos do Youtube PLUGIN PLUGIN PLUGIN

Gerenciamento de destaques PLUGIN PLUGIN PLUGIN

Dentre os citados, o Wordpress é o mais usado entre os CMS’s, hoje ocupando 54% do

mercado de gerenciadores e sendo plataforma base para 17% de todos os sites do mundo (W3TECHS,

15

2013). Por isto avaliaremos um pouco mais a fundo os problemas de usabilidade e segurança desta

ferramenta a fim de explicitar a necessidade da criação do sistema proposto neste trabalho.

2.1.1 Problemas de usabilidade dos CMS’s

Com o passar do tempo os CMS’s passaram a incorporar tantas funcionalidades que se

tornaram complexos demais para um usuário comum utilizar. Por exemplo, para publicar um álbum de

fotos no Wordpress pode se fazer com os seguintes passos:

1. Entrar na tela de administração do sistema;

2. Clicar no menu plugins;

3. Clicar no menu “Adicionar novo”;

4. Digitar “album” na caixa de pesquisa;

5. Clicar em “pesquisar plugins”;

6. Escolher “WP Photo Album Plus”;

7. Clicar em “Instalar agora”;

8. Aceitar a confirmação de instalação;

9. Aguardar a instalação;

10. Clicar em “Ativar plugin”;

11. Descobrir como o plugin funciona (esta parte é difícil);

12. Clicar no menu “Photo Albums”;

13. Clicar no menu “Album Admin”;

14. Clicar em “Create Empty Album”;

15. Inserir as informações do álbum;

16. Clicar em “Save Album”;

17. Clicar no menu “Upload Photos”;

18. Clicar na caixa de seleção de arquivos;

19. Escolher fotos;

20. Clicar em “Upload Multiple Photos”;

21. Aguardar carregamento das fotos;

22. Descobrir como fazer as fotos aparecerem no site (esta parte também é difícil);

23. Clicar no menu “Posts”;

24. Clicar no menu “Adicionar Novo”;

25. Clicar em “WPPA+ Gallery Shortcode” (ícone que apareceu na barra de ferramentas);

26. Escolher o álbum a ser inserido no post;

27. Clicar em “Publicar”.

No exemplo acima utilizamos o plugin “WP Photo Album Plus”, mas poderíamos ter utilizado

qualquer outro plugin de galeria de fotos. Podemos considerar também que uma vez que o plugin

16

esteja instalado a quantidade de passos seja reduzida e isto realmente acontece. Se removermos os

passos de instalação do plugin ainda sobram 16 passos que o usuário precisa executar toda vez que for

enviar um álbum de fotos, o que ainda é muito para um usuário normal executar sem se perder. O

problema se agrava ainda mais se for levado em conta que a partir do passo 12 as instruções foram

exibidas em inglês, mesmo o sistema sendo instalado em português. Podemos observar o mesmo

problema ao tentar gerenciar eventos, importar álbuns do Facebook e vídeos do Youtube. Em todos os

casos é necessário instalar algum plugin e cada plugin tem a sua maneira particular de funcionar,

fugindo de um padrão.

De acordo com (NIELSEN, 1999), uma das regras para o desenvolvimento de um site com uma

boa usabilidade é a regra dos 3 cliques. Ela diz que, para acessar qualquer área do site, o usuário deve

clicar no máximo 3 vezes. (FRIEDMAN, 2007) complementa dizendo que na maioria das situações o

que importa é que o usuário saiba onde ele está, onde ele estava e onde ele pode ir ao próximo passo.

E que mesmo 10 cliques são viáveis se os usuários sentirem que estão entendendo como o sistema

funciona. Logo se conclui que, no caso acima, o problema do idioma e a complexidade do módulo

quebram todas as regras mencionadas, fazendo com que o usuário clique em muitos itens, e por não

saber onde está, não entenda a operação do sistema.

No produto deste trabalho, projeta-se que a mesma ação executada no Wordpress poderá ser

executada em 8 passos:

1. Entrar na tela de administração do sistema;

2. Clicar no menu “Álbuns de Fotos”;

3. Clicar em “Adicionar Álbum”;

4. Inserir as informações do álbum;

5. Clicar na caixa de seleção de arquivos;

6. Escolher fotos;

7. Clicar em “Salvar Álbum”;

8. As fotos aparecem no menu “Álbuns” do site.

Este é um entre outros casos de uso do projeto que serão focados em prover usabilidade de

acordo com o Plano de Gerenciamento da Qualidade.

Vale ressaltar, que este problema não faz do Wordpress um sistema ruim e sim um sistema

que implementa esta tarefa de forma que a experiência do usuário é prejudicada. Ele possui centenas

de funcionalidades que são muito úteis para diversos tipos de clientes, porém, não serão inseridas no

escopo deste projeto, pois o objetivo é foca-lo unicamente no público alvo anteriormente citado.

17

2.1.2 Problemas de segurança dos CMS’s

Outro problema que atinge drasticamente os sites é a vulnerabilidade, devido a falhas na

implementação de sua segurança. O Relatório de segurança em sites da (WHITEHAT SECURITY,

2012) diz que em 2011 foram descobertas em média 79 vulnerabilidades sérias por site no mundo.

Este é um valor bem relevante uma vez que engloba desde pequenos sites até grandes portais.

“As vulnerabilidades em aplicações web podem assumir dezenas de formas. Muitos

destes ataques usam injeção de falhas, que explora vulnerabilidades na sintaxe e

semântica de uma aplicação web. Em termos simples, um atacante manipula dados

no link de uma página web para forçar uma falha explorável na aplicação. As duas

variedades mais comuns são a injeção de SQL e cross-site scripting.”

(SHEMA, 2011)

Podemos entender que uma considerável parte destas vulnerabilidades é causada pelos CMS’s,

já que, conforme já mencionado, cerca de um terço dos sites do mundo funcionam sobre um CMS.

O Relatório da (SECUNIA, 2013) diz que, desde 2003 foram reportadas 39 vulnerabilidades

no Wordpress versão 3, das quais 13% ainda não foram corrigidas. Este é um fato preocupante, porém

o que é ainda mais desanimador é que estas vulnerabilidades estão apenas no núcleo do Wordpress.

No mesmo período foram reportadas vulnerabilidades em mais de 400 plugins de Wordpress, tornando

a instalação de qualquer extensão no sistema potencialmente insegura.

Este projeto visa criar um sistema em que, a garantia de segurança seja feita durante o ciclo de

desenvolvimento do software. Ao final do processo de desenvolvimento, na etapa de homologação, o

sistema será submetido a um scanner de vulnerabilidades a fim de garantir que ele está seguro.

2.2 INTEGRAÇÃO DOS SISTEMAS DE GERENCIAMENTO DE CONTEÚDO

Entendemos redes sociais como qualquer grupo que compartilhe de um interesse em

comum, um ideal, preferência, etc. Exemplos de redes sociais: Clube de futebol,

igreja, sala de aula, empresa. Quando essa interação social parte para o ambiente

online, nesse momento temos as chamadas redes sociais digitais, estas tem passado

costantemente por uma série de evoluções.

(OLIVEIRA, 2011)

Conforme (GOOGLE, 2011), o Facebook, seguido do Youtube são os dois sites com mais

acessos diários no mundo. Este é o estágio evolutivo atual das redes sociais. Sendo assim, da mesma

forma que hoje não existe mais oportunidade para empresas com sites estáticos, também não existe

para as que não estiverem integradas às redes sociais, e ter apenas um site não é o suficiente.

18

Em 2012 o Facebook contou com 46 milhões de brasileiros cadastrados de acordo com

(SOCIAL BAKERS, 2012), logo se presume que é indispensável para uma empresa, que quer falar

direto com seu público, ter uma página na rede social de Mark Zuckerberg. O mesmo vale para o

Youtube quando está se falando de conteúdo em vídeo.

A partir do momento em que a empresa se encontra imersa nas redes sociais, pode ser um

pouco incômodo manter o mesmo conteúdo em seu site. Por exemplo, suponhamos que um fotógrafo

deseje exibir os seus trabalhos no Facebook, posta 100MB de fotos na rede social e então tem que

subir as mesmas fotos para o seu site. Tendo como alvo a superação desta dificuldade, o projeto deste

trabalho planeja integrar o site do cliente no Facebook e Youtube, possibilitando a importação do

conteúdo destes serviços.

19

3. METODOLOGIA CIENTÍFICA

A metodologia implementada neste trabalho se baseia nas práticas gestão de projetos do PMI. O plano

de projeto contemplará as 9 áreas propostas no PMBOK tendo como saída os seguintes artefatos:

Termo de Abertura;

Declaração de Escopo;

Estrutura Analítica do Projeto (EAP);

Plano de Gerenciamento de Escopo;

Plano de Gerenciamento de Tempo;

Plano de Gerenciamento de Custos;

Plano de Gerenciamento de Qualidade;

Plano de Gerenciamento de Recursos Humanos;

Plano de Gerenciamento de Comunicações;

Plano de Gerenciamento de Riscos;

Plano de Gerenciamento de Aquisições.

Para compor os capítulos de introdução e fundamentação teórica, foram consultados livros, artigos,

reportagens e relatórios com estatísticas de acessos de sites, vulnerabilidade e market share. Também

foram consultados e analisados vários sistemas de gerenciamento de conteúdo existentes.

Para o desenvolvimento do software, optou-se pelo desenvolvimento tradicional em cascata, pois se

acredita que o escopo pode ser bem definido, o risco de mudanças durante o processo de

desenvolvimento é relativamente baixo e a quantidade de pacotes de trabalho é pequena.

De acordo com (DE CARVALHO e MOLINA, 2012), as fases do modelo em cascata são: análise de

requisitos, projeto (design), implementação e testes. A análise de requisitos funcionais será feita

durante a declaração de escopo, enquanto as outras 3 fases serão incorporadas na EAP e farão parte da

execução efetiva do projeto.

20

4. PLANO DE PROJETO

4.1 TERMO DE ABERTURA

PROJETO MEGA SITE

TERMO DE ABERTURA

PROJECT CHARTER

Preparado por Afonso França de Oliveira – Gerente do Projeto Versão 1.0

Aprovado por Afonso França de Oliveira – Gerente do Projeto 14/01/2013

4.1.1 Título do Projeto

Mega Site

4.1.2 Resumo das condições do projeto

Histórico: O patrocinador no intuito de iniciar uma startup viu um bom mercado para ser investido, o

de sites institucionais, mais especificamente para micro e pequenas empresas do Sul Fluminense.

Observa-se que muitos dos sites da região têm qualidade precária e são pouco atualizados devido às

dificuldades impostas pelos Sistemas de Gerenciamento de Conteúdo usados.

Objetivo do Projeto: Como possível solução para o problema, foi identificada a criação de um

Sistema de Gerenciamento de Conteúdo fácil de usar, acessível, customizável e integrado às redes

sociais Facebook e Youtube.

4.1.3 Nome do Gerente do Projeto, suas responsabilidades e sua autoridade

Como gerente do projeto Mega Site será designado o profissional Afonso França de Oliveira. Sua

autoridade é total na esfera deste projeto, podendo realizar compras, contratações e gerenciar a equipe

do projeto de acordo com seus próprios critérios.

No aspecto financeiro, sua atuação deverá estar de acordo com o orçamento inicial, sendo que

qualquer acréscimo neste orçamento deverá seguir o fluxo de alteração de orçamento descrito abaixo.

O gerente do projeto será o guardião do escopo e, portanto, qualquer alteração neste quesito será́ sua

responsabilidade administrar.

4.1.4 Necessidades básicas do trabalho a ser realizado

Será necessário que os colaboradores tenham estações de trabalho com os seguintes requisitos de

hardware e software:

Hardware

Processador: 2GHz ou superior;21

Memória: 2GB ou superior;

Disco: 100 GB ou superior;

Velocidade de Internet: 1Mb/s ou superior.

Software

Repositório: Tortoise SVN;

Interface de Desenvolvimento: Visual Studio 2010 Express (C# com ASP NET MVC e Razor,

HTML, Javascript, CSS);

Banco de Dados: MySQL;

Navegadores: Internet Explorer 9, Mozilla Firefox e Google Chrome;

Sistema operacional: Windows 7 ou superior;

Design: Adobe Photoshop CS5 ou superior;

UML: StarUML;

Gerenciamento do Projeto: Microsoft Project 2010;

Edição de Documentos: Microsoft Word;

Gráficos: Yed Graph Editor;

Comunicação: Skype.

Será necessário também que o cliente piloto possua a infraestrutura supracitada para realização da

homologação no seu ambiente.

4.1.5 Descrição do Projeto

Produto do projeto

Sistema implementado e documentado com aprovação do patrocinador, bem como a implementação

em um cliente piloto para validar a eficácia do produto.

Cronograma básico do projeto

A execução do projeto terá inicio em janeiro de 2013 e deve durar aproximadamente 70 dias.

Estimativas iniciais de custo

A receita bruta inicial para este projeto é de R$ 30.000,00, valor que será pago pelo patrocinador.

4.1.6 Administração

Necessidade inicial de recursos

O gerente terá uma equipe de quatro profissionais, sendo um Analista Programador Sênior, um

Analista Programador Pleno, um Analista Programador Junior e um Designer Gráfico. Toda a equipe

será contratada como free lancer, não havendo alocação exclusiva, porém estima-se que cada membro

22

alocará 4 horas do seu dia nas atividades do projeto. Cada profissional trabalhará em home office com

seu próprio equipamento.

Necessidade de suporte pela organização

Por ser o primeiro projeto da startup ele será tratado como um projeto isolado, sendo que o

patrocinador ira suportar todas as necessidades extra.

Controle de Gerenciamento das informações do projeto

O gerente do projeto é responsável pelas informações. Todas as informações devem ser armazenadas

no Google Drive e compartilhadas entre todos os envolvidos.

APROVAÇÕES


Gerente do ProjetoVersão 1.0

23

4.2 DECLARAÇÃO DE ESCOPO

PROJETO MEGA SITE

DECLARAÇÃO DE ESCOPO

SCOPE STATEMENT



4.2.1 Time do Projeto

CARGO TAREFAS A SEREM REALIZADAS

Analista Programador Sênior Arquitetura, API, diagramas, telas, importação e testes de aceitação

Analista Programador Pleno Modelagem de BD, telas, importação e treinamento do cliente

Analista Programador Junior Documentação, configuração de ambiente, telas e diagramas

Designer Gráfico Layout do painel administrativo e cliente piloto

4.2.2 Descrição do projeto

O projeto envolverá contratações de profissionais, análise de sistemas, implementação do sistema de

gerenciamento de conteúdo e testes em um cliente piloto.

4.2.3 Objetivo do projeto

Implementar uma plataforma de gerenciamento de conteúdo que satisfaça a confecção de sites de

micro e pequenas empresas que tenha preço acessível, integração com redes sociais e que seja seguro.

A plataforma também precisa ser fácil de usar e altamente customizável. O projeto precisa ser

executado dentro de um prazo máximo de 70 dias corridos a partir de janeiro de 2013 e com um custo

total de R$ 30.000,00.

4.2.4 Justificativa do Projeto

Em virtude de apenas 27% das microempresas do Brasil possuírem websites, o patrocinador do projeto

viu a oportunidade de iniciar uma startup, com o intuito de fornecer sites de qualidades para

profissionais liberais, micro e pequenas empresas, os quais terão uma oportunidade acessível de expor

seus trabalhos em meio digital.

4.2.5 Produto do Projeto

Sistema de gerenciamento de conteúdo implementado e aprovado pelo patrocinador, bem como um

site piloto implementado em um cliente para avaliar sua efetividade.

4.2.6 Expectativa do Patrocinador

Projeto cumprindo os quesitos informados no Termo de Abertura;

Projeto executado dentro do orçamento planejado;24

Projeto executado dentro do prazo planejado.

4.2.7 Fatores de sucesso do projeto

Poucos ruídos na comunicação entre os colaboradores;

Comprometimento total dos colaboradores em trabalho remoto;

Conexão de Internet satisfatória para sincronizar o repositório de código;

Frequente avaliação do patrocinador e cliente piloto sobre alcance das metas.

4.2.8 Restrições

O orçamento é limitado;

O projeto deve manter o nível de qualidade aceitável no código fonte, para torná-lo

implantável em no mínimo 24 clientes nos próximos 3 anos, sem grandes problemas técnicos;

É necessário haver um procedimento rápido para implantação de novos clientes.

4.2.9 Premissas

A comunicação do time será através do Google Docs, através de uma planilha de

acompanhamento do projeto;

O repositório do código-fonte será o Assembla.com, utilizando o protocolo SVN;

O cliente piloto deve fornecer todas as informações para implementação do seu site;

O time do projeto deverá ter noções de engenharia de software, desenvolvimento para web,

testes unitários, montagem de sites com HTML e CSS, Javascript, jQuery, ASP.NET e

Configuração de servidores IIS;

Os membros do time dedicarão 4 horas diárias no projeto.

4.2.10 Limites do Projeto e exclusões específicas

O projeto não tem como objetivo atender sites de grande porte;

O projeto não abrangerá e-commerce;

O projeto não permitirá aos clientes acessar os arquivos fonte por FTP ou qualquer outra

forma de conexão.

4.2.11 Principais atividades e estratégias do projeto

Geral

O custo com aquisição de equipamentos de informática não está incluído no valor anterior e

não será considerado, pois os colaboradores contratados trabalharão em home office com seu

próprio equipamento;

O projeto passará por revisão semanal e acompanhamento do patrocinador, que alinhará com

os desenvolvedores qual a sua expectativa com as funcionalidades.

25

Contratações

Serão contratados três programadores e um designer gráfico. Estas contratações não terão

vínculo empregatício, pois a prestação de serviço será única e sem criar expectativas de

trabalhos eventuais com os contratados;

Os colaboradores contratados terão horários flexíveis, porém, para efeitos de planejamento,

recomenda-se que cada um deles trabalhe num período de 4 horas diárias;

Estes colaboradores devem também arcar com os possíveis custos de aquisições de hardware e

de licenças para os softwares instalados;

O cliente piloto deverá assumir os riscos da implantação do seu site e deverá ser contratado

considerando que possíveis bugs podem ocorrer durante a homologação em seu site.

Análise e Projeto de Software

Será definida a arquitetura do projeto, a tecnologia utilizada e a configuração dos ambientes

de desenvolvimento.

A análise do sistema contará com a criação dos casos de usos e diagrama de classes e

sequência.

Implementação

O painel administrativo deverá ser fácil de usar e acessível através de senha;

O sistema deverá ter uma API para criação da interface dos sites;

A integração com Facebook e Youtube deve usar as respectivas API’s fornecidas pelos

serviços;

Deverá ser criado um layout de exemplo para que futuros sites usem-o como base;

O sistema deverá ter um gerenciamento interno de fotos e vídeos, além da integração;

O sistema deverá ter uma tela para gerenciamento dos usuários administrativos;

O sistema deverá ser maleável o suficiente para que sejam criadas entidades customizáveis

pelos clientes, isto é, se o cliente tem uma lista de produtos para ser inserida no site, o site

deve comportar que o cliente os insira com suas características. Estas características precisam

ser acessíveis pela API.

Homologação

Deverá ser criado na infraestrutura do cliente um ambiente de homologação em paralelo ao

site atual dele, se houver;

O processo de implantação deverá ser documentado para que as implantações posteriores

sejam facilitadas;

Deverá ser criado durante o treinamento do cliente um FAQ com as dúvidas que o cliente

teve, para auxiliar futuras implantações;

26

4.2.12 Entregas do Projeto

Análise do sistema concluída;

Sistema de gerenciamento de conteúdo implementado;

Sistema de gerenciamento de conteúdo homologado no cliente piloto;

FAQ do usuário concluído.

4.2.13 Orçamento do Projeto

O projeto prevê um gasto de R$ 30.000,00, incluindo as reservas gerenciais;

As reservas gerenciais e de contingência somadas não podem ultrapassar R$ 4.000,00 (13%

do orçamento);

O pagamento das despesas com pessoal e aquisições se efetuará segundo o fluxo de caixa a ser

desenvolvido para o projeto e aprovado pelo patrocinador;

4.2.14 Plano de entregas e marcos do projeto

A execução dos trabalhos terá início em janeiro de 2013 e deve durar aproximadamente 70 dias

corridos.

ENTREGA DESCRIÇÃO TÉRMINO

Fase de Iniciação Project Charter Aprovado 28/01/2013

Fase de Planejamento Declaração do Escopo Aprovada 30/01/2013

Cronograma definido 01/02/2013

Orçamento definido 02/02/2013

Plano de Projeto Concluído 03/02/2013

Aprovação do Plano de Projeto 04/02/2013

Contratações Concluídas 01/03/2013

Fase de Execução Análise de Sistemas Concluída 08/02/2013

Implementação do Sistema Concluída 19/03/2013

Piloto realizado e avaliado 28/03/2013

Fase de Finalização Lições aprendidas Registradas 02/04/2013

Projeto Concluído 06/04/2013

APROVAÇÕES


Gerente do ProjetoVersão 1.0

27

4.3 ESTRUTURA ANALÍTICA DO PROJETO

4.3.1 Visualização Hierárquica

3. IMPLEMENTAÇÃO

3.1 Layout dopainel administrativo

3.2 Modelagem dobanco de dados

3.3 API para modelagemde interface do site

3.4 Layout de exemplo

3.5 Tela de login dousuário

3.6 Tela de gerenciamentode destaques

3.7 Tela de gerenciamento de entidades customizadas

3.8 Tela de gerenciamentode usuários

3.9 Tela de gerenciamentode álbum de fotos

3.10 Tela de gerenciamentode objetos

3.11 Botão para Importaçãode álbum do Facebook

3.12 Botão para Importaçãode vídeo do Youtube

3.13 Documentar código

2. ANÁLISE E PROJETODE SOFTWARE

2.4 Configurar ambientesde desenvolvimento

2.1 Diagramas de casosde uso

2.2 Diagramas desequência

2.3 Diagrama de classes

4. HOMOLOGAÇÃO

4.1 Instalação emcliente piloto

4.2 Teste de aceitaçãoem cliente piloto

4.3 Treinamento docliente

4.4 Criação de FAQdo usuário

5. ENCERRAMENTO

5.1 Registro de LiçõesAprendidas

5.2 Finalização doProjeto

PROJETO MEGA SITE

1. GERENCIAMENTODO PROJETO

1.2 Monitoramento econtrole

4.3.2 Dicionário da EAP

Pacote de Trabalho Descrição

1. GERENCIAMENTO DO PROJETO

1.1 Plano de Projeto Elaborar os planos conforme as diretrizes do PMI do

PMBOK 1.2 Monitoramento e Controle

2. ANÁLISE E PROJETO DE SOFTWARE

2.1 Diagramas de casos de uso

Listar todos os casos de uso do sistema, na forma de

diagramas de caso de uso da UML. Deverá ser

entregue junto com outros diagramas da linguagem

UML em um único arquivo gerado pela ferramenta

Star UML.

Aprovar diagrama

28


2.2 Diagramas de sequência

Listar todas as operações do sistema no diagrama de

sequência da UML. Deverá ser entregue junto com

outros diagramas da linguagem UML em um único

arquivo gerado pela ferramenta Star UML.

Verificar se os diagramas atendem à especificação de

usabilidade proposta no Plano de Gerenciamento da

Qualidade

Aprovar diagrama

2.3 Diagrama de classes

Listar todas as entidades do sistema no diagrama de

classes. Deverá ser entregue junto com outros

diagramas da linguagem UML em um único arquivo

gerado pela ferramenta Star UML.

Aprovar diagrama

2.4 Configurar ambientes de

desenvolvimento

Instalar softwares

3. IMPLEMENTAÇÃO

3.1 Layout do painel administrativo

Desenhar no Photoshop o layout do painel

administrativo.

Aprovar layout

Montar layout em HTML e CSS

Verificar se o layout atende à especificação de SEO

(Search Engine Optimization) proposta no Plano de

Gerenciamento da Qualidade

Verificar se o layout atende à especificação de

portabilidade proposta no Plano de Gerenciamento da

Qualidade

3.2 Modelagem do banco de dados

Criar no MySQL a estrutura de banco de dados

proposta pelo diagrama de classes, com os devidos

relacionamentos e chaves.

3.3 API para modelagem de interface

do site

Criar aplicação no Visual Studio 2010 Express

Configurar NHibernate na aplicação

Desenhar API através do NHibernate mapeando toda a

estrutura do banco de dados em objetos acessíveis

pelo site.

29


3.4 Layout de exemplo

Desenhar no Photoshop o layout de exemplo de site

Aprovar layout

Montar layout em HTML e CSS

3.5 Tela de login do usuário

Montar a tela utilizando a o HTML e CSS do layout

do painel administrativo

Programar a lógica da tela de acordo com o diagrama

de sequência, criando testes de unidade, para garantir

o cumprimento da especificação de confiabilidade

proposta no Plano de Gerenciamento da Qualidade.

Verificar se o tempo de abertura da tela atende à

especificação de velocidade proposta no Plano de


3.6 Tela de gerenciamento de

destaques


do painel administrativo








3.7 Tela de gerenciamento de entidades

customizadas


do painel administrativo.

Programar lógica de criação de novos campos

customizados








30


3.8 Tela de gerenciamento de usuários










3.9 Tela de gerenciamento de álbum de

fotos



Programar lógica de upload de fotos








3.10 Tela de gerenciamento de objetos



Programar lógica de exibição dos campos

customizados criados na tela de gerenciamento de

entidades








31


3.11 Botão para Importação de álbum

do Facebook

Criar botão

Programar lógica de autorização e importação de fotos

do Facebook

Programar lógica de escolha de fotos a serem

importadas pelo usuário

3.12 Botão para Importação de vídeo

do Youtube

Criar botão

Programar lógica de autorização e importação de

vídeos do Youtube

Programar lógica de escolha de vídeos a serem

importados pelo usuário

3.13 Documentar código

Criar guia de referência da API para composição de

novos temas

Documentar funções do código com descrição e

explicação dos parâmetros

Criar guia “Getting Started” para iniciantes

Criar guia de uso do cliente final

4. HOMOLOGAÇÃO

4.1 Instalação em cliente piloto

Submeter o sistema a um scanner de vulnerabilidades

para garantir que não existe nenhuma brecha de

segurança

Instalar site no IIS

Configurar domínio

Configurar banco de dados

Configurar Firewall

4.2 Teste de aceitação em cliente piloto

Homologar junto ao cliente todas as funções do

sistema

Relatar falhas

Corrigir falhas

Aprovar versão final

4.3 Treinamento do cliente

Apresentar guia de uso para o cliente

Registrar todas as dúvidas e problemas relatados pelo

cliente

Sanar as dúvidas e explicar os procedimentos

32


4.4 Criação de FAQ do usuário Criar documento de respostas para perguntas

frequentes do cliente

5. ENCERRAMENTO

5.1 Registro de Lições Aprendidas

Criar documentos com aprendizados proporcionados

pelo projeto.

Arquivar no Google Drive para futuras referências

5.2 Finalização do Projeto Reunir para encerrar formalmente o projeto

APROVAÇÕES

Admir Pinto de Oliveira

PatrocinadorVersão 1.0

33

4.4 PLANO DE GERENCIAMENTO DE ESCOPO

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE ESCOPO

SCOPE MANAGEMENT PLAN



4.4.1 Descrição dos processos de gerenciamento de escopo

O gerenciamento do escopo será realizado com base em dois documentos específicos:

Declaração de escopo para o escopo funcional do projeto e EAP para o escopo das atividades

a serem realizadas pelo projeto, com suas devidas entregas.

Todas as mudanças no escopo devem ser avaliadas e classificadas dentro do sistema de

controle de mudanças exposto no item 4.4.3

Só serão consideradas mudanças correções de defeitos encontrados. Ideias e melhorias não

serão abraçadas pelo gerenciamento de escopo.

As solicitações de mudanças deverão ser adicionadas na planilha solicitação de mudanças na

pasta do projeto no Google Drive.

4.4.2 Priorização das mudanças de escopo e respostas

As mudanças de escopo serão classificadas em 3 níveis de prioridade:

1. Defeitos impeditivos: requer ação imediata do gerente de projeto, pois pode impactar

diretamente no sucesso do projeto.

2. Defeitos graves: requer planejamento para ação juntamente com a equipe se houver

disponibilidade, pois agregam valor ao sucesso do projeto, mas não impedem que a solução

funcione.

3. Defeitos leves: equipe deve ser informada do defeito e este deve ser feito somente se houver

folga no final da entrega do pacote de trabalho, sem que impacte nos demais.

4.4.3 Gerenciamento das configurações (Configuration management)

O sistema de controle de mudanças deve garantir que todas as mudanças no escopo do projeto sejam

tratadas de acordo com o fluxo a seguir e seus resultados sejam apresentados na reunião semanal com

a conclusão, prioridade e ações.

34

INÍCIO

Solicitaçãode mudanças

Análise damudançasolicitada

Defeitoou melhoria Ignorar

Impactonos custos e

ou prazosPrioridade 3

Impacto emoutras áreas Prioridade 2

Áreas afetadasDefeito ou melhoriaImpacto nos custos e prazosImpacto na qualidade e riscos

Relatório deMudanças

(Change Request)

Melhoria

Defeito

Baixo

Alto

Baixo

Prioridade 0

Alto

4.4.4 Freqüência de avaliação do escopo do projeto

O escopo do projeto deve ser avaliado semanalmente dentro da reunião de CCB (Change Control

Board), prevista no plano de gerenciamento de comunicações.

4.4.5 Alocação financeira das mudanças de escopo

As mudanças de escopo corretivas podem ser alocadas dentro das reservas gerenciais do projeto, desde

que dentro da alçada do gerente de projeto. Caso contrário ou se não existir mais reserva, deverá ser

acionado o patrocinador, pois o gerente de projeto não tem autonomia para usar a reserva de

contingência de riscos para mudanças no escopo.

35

4.4.6 Administração do plano de gerenciamento de escopo

Responsável pelo plano

Afonso França de Oliveira, gerente do projeto, será o responsável direto pelo plano de

gerenciamento de escopo.

Walter Amorim, membro da equipe de desenvolvimento, será suplente do responsável direto

pelo plano de gerenciamento de escopo.

Frequência de atualização do plano de gerenciamento de escopo

O plano de gerenciamento de escopo será reavaliado mensalmente na primeira reunião do CCB,

juntamente com os outros planos de gerenciamento de projeto.

4.4.7 Outros assuntos relacionados ao gerenciamento do escopo do projeto não previstos neste

plano

Todas as solicitações não previstas neste plano deverão ser submetidas para aprovação na reunião do

CCB para aprovação. Imediatamente após sua aprovação, deverá ser atualizado o plano de

gerenciamento de escopo com o devido registro das alterações efetivadas.

REGISTRO DE ALTERAÇÕES

Data Modificado por Descrição da mudança

APROVAÇÕES



36

4.5 PLANO DE GERENCIAMENTO DE TEMPO

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE TEMPO

SCHEDULE MANAGEMENT PLAN



4.5.1 Descrição dos processos de gerenciamento de tempo

O gerenciamento de tempo será realizado a partir da alocação de percentual completo nas

atividades do projeto através do Microsoft Project.

A atualização dos prazos do projeto será realizada no Microsoft Project através da publicação

no Google Drive dos seguintes relatórios:

o Gráfico de Gantt;

o Diagrama de rede;

o Percentual completo;

o Diagrama de marcos.

A avaliação de desempenho do projeto será realizada através da Análise de Valor Agregado

(Earned Value), onde o custo e o prazo do projeto são acompanhados em um único processo

de controle (relatório Análise de Valor Agregado).

Serão consideradas críticas todas as atividades com folga menor ou igual a 2 dias. Uma folga

de 2 dias ou menos não será considerada como disponibilidade, devido a remanejamento de

horas de trabalho no projeto.

Todas as mudanças no prazo inicialmente previsto para o projeto devem ser avaliadas e

classificadas dentro do sistema de controle de mudanças de tempo.

Serão considerados atrasos os defeitos impeditivos que deverão ser integrados no plano. Todo

e qualquer tipo de nova funcionalidade não será abordado pelo gerenciamento de tempo e será

ignorado.

A atualização da linha de base do projeto será permitida somente com autorização do gerente

de projeto e patrocinador, sendo a linha de base anterior arquivada, documentada e publicada,

para fins de lições aprendidas.

As solicitações de mudanças deverão ser adicionadas na planilha solicitação de mudanças na

pasta do projeto no Google Drive.

4.5.2 Priorização das mudanças nos prazos

1. Requer ação imediata do gerente de projeto para que analise e discuta com o patrocinador,

pois pode impactar diretamente no sucesso do projeto. Devem ser acionadas medidas de 37

recuperação de prazo através de horas-extras. Os custos dessas ações deverão ser alocados nas

reservas gerenciais. Deve-se evitar fazer Fast-Tracking e Crashing.

2. Requer replanejamento de atividades futuras junto com a equipe na CCB uma vez que o

projeto ainda não completou 25% de conclusão.

3. São atrasos pequenos e podem ser remanejados sem ser preciso fazer horas-extra.

4.5.3 Sistema de controle de mudanças de prazos (Schedule Change Control System)

Todas as mudanças nos prazos do projeto devem ser tratadas de acordo com o fluxo a seguir, com suas

conclusões, prioridades e ações relacionadas apresentadas na reunião semanal do CCB.

INÍCIO

Atualização da Programação

Avaliação dosdesvios na

Programação

Impacto noprazo final do

projetoNada a fazer

Pode serremanejado Prioridade 3

Percentualmenor 25% Prioridade 2

Prioridade 1



(Change Request)

Não

Sim

Não

Sim

Não

Sim

4.5.4 Mecanismo adotado para conflitos de recursos

Deverá ser executado sempre que o cálculo de duração das atividades for realizado. Caso um recurso

esteja alocado em duas tarefas ao mesmo tempo, em primeiro lugar deve-se verificar se é possível

38

renivelar os recursos através do Microsoft Project. Caso o projeto estoure o prazo, deve-se tentar

programar uma hora extra.

4.5.5 Buffer de tempo do projeto

Não prevê a folga baseada em corrente crítica, uma vez que o cronograma foi construído baseado em

caminho crítico e não em corrente crítica.

4.5.6 Freqüência de avaliação dos prazos do projeto

Os prazos do projeto deverão ser reavaliados todos os dias e os resultados publicados no Google

Drive. Tais resultados devem ser apresentados na reunião de CCB.

4.5.7 Alocação financeira para o gerenciamento de tempo

As ações de recuperação de atrasos, que requerem gasto extra, devem ser alocadas dentro das reservas

gerenciais do projeto, desde que dentro da alçada do gerente de projeto. Caso contrário ou se não

existir mais reserva, deverá ser acionado o patrocinador, pois o gerente de projeto não tem autonomia

para usar a reserva de contingência de riscos para a recuperação de atrasos.

4.5.8 Administração do plano de gerenciamento de tempo



gerenciamento de tempo.


pelo plano de gerenciamento de tempo.

Frequência de atualização do plano de gerenciamento de tempo

O plano de gerenciamento de tempo será reavaliado mensalmente na primeira reunião do CCB,


4.5.9 Outros assuntos relacionados ao gerenciamento de tempo do projeto não previstos neste

plano



gerenciamento de tempo com o devido registro das alterações efetivadas.



39

APROVAÇÕES



40

4.6 PLANO DE GERENCIAMENTO DE CUSTOS

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE CUSTOS

COST MANAGEMENT PLAN



4.6.1 Descrição dos processos de gerenciamento de custos

A atualização do orçamento será realizada no Microsoft Project e será publicada no Google

Drive.

A avaliação de desempenho do projeto será realizada através da Análise de Valor Agregado

(Earned Value), onde o custo e o prazo do projeto são acompanhados em um único processo

de controle (relatório Análise de Valor Agregado).

O gerenciamento de custos será realizado com base no orçamento previsto para o projeto e

com o fluxo de caixa do projeto.

Serão contempladas no gerenciamento de custos das despesas com contratação. Parte das

despesas com hardware e software será considerada recurso interno da empresa e outra parte

ficará por conta dos contratados, que terão que ter o hardware e software necessários para

realizar os trabalhos.

Todas as mudanças no orçamento devem ser avaliadas e classificadas de acordo com o sistema

de controle de mudanças de orçamento.

Só serão consideradas mudanças orçamentárias de correções de defeitos encontrados. Ideias e

melhorias não serão abraçadas pelo gerenciamento de custos.

As solicitações de verbas deverão ser adicionadas na planilha solicitação de verbas na pasta do

projeto no Google Drive.

4.6.2 Freqüência de avaliação do orçamento do projeto e das reservas gerenciais

O orçamento do projeto deverá ser reavaliado todos os dias e os resultados publicados no Google

Drive. Tais resultados devem ser apresentados na reunião de CCB.

4.6.3 Reservas gerenciais

Foi aprovada pelo patrocinador uma reserva gerencial total de R$ 2.000,00 (dois mil reais), que

juntamente com o orçamento do projeto, compõem o custo final do empreendimento.

41

ContrataçõesR$ 26.000,00

Gerente do ProjetoR$ 10.560,00

Programador SêniorR$ 7.040,00

Programador PlenoR$ 4.000,00

Programador JuniorR$ 3.120,00

Designer GráficoR$ 1.280,00

Total de ReservasR$ 4.000,00

Reservas ContigenciaisR$ 2.000,00

Outras ReservasR$ 2.000,00

PROJETO MEGA SITER$ 30.000,00

Reservas de contingência

São reservas destinadas exclusivamente ao processo de gerenciamento de riscos, conforme descrito no

plano de gerenciamento de riscos.

Outras reservas

São todas as reservas destinadas a outros eventos criados a partir de alguma solicitação de mudança

proveniente dos outros planos e dentro da autonomia do gerente do projeto e patrocinador.

4.6.5 Autonomias

O gerente do projeto tem as seguintes autonomias quanto à utilização das reservas:

Reservas de contingência Outras reservas

Gerente do projeto

isoladamente

Até R$ 100,00 Até R$ 200,00

Gerente do projeto com aval do

Patrocinador

Até R$ 200,00 Até R$ 400,00

Somente patrocinador Acima de R$ 200,00 até o

limite das reservas

Acima de R$ 400,00 até o

limite das reservas

Essa autonomia é por cada solicitação de mudanças proveniente dos outros planos, podendo o gerente

de projeto consumir a reserva, desde que em diferentes solicitações.

Com o fim das reservas, somente o patrocinador poderá solicitar e decidir sobre a criação de novas

reservas conforme será apresentado a seguir neste plano.

42

De acordo com o plano de gerenciamento de recursos humanos, todo o saldo contido na reserva

gerencial será distribuído para todos integrantes do time, excluindo o gerente de projeto, em parcelas

de iguais valores, independente do cargo.

4.6.6 Alocação financeira das mudanças no orçamento

As mudanças de natureza corretiva podem ser alocadas dentro das reservas gerenciais do projeto,

desde que dentro da alçada do gerente de projeto. Caso contrário ou se não existir mais reserva, deverá

ser acionado o patrocinador, pois o gerente de projeto não tem autonomia para usar a reserva de

contingência de riscos para mudanças no escopo.

4.6.7 Administração do plano de gerenciamento de custos



gerenciamento de custos.


pelo plano de gerenciamento de custos.

Frequência de atualização do plano de gerenciamento de custos

O plano de gerenciamento de custos será reavaliado mensalmente na primeira reunião do CCB,


4.6.8 Outros assuntos relacionados ao gerenciamento de custos do projeto não previstos neste

plano



gerenciamento de custos com o devido registro das alterações efetivadas.



APROVAÇÕES



43

4.7 PLANO DE GERENCIAMENTO DE QUALIDADE

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE QUALIDADE

SCHEDULE MANAGEMENT PLAN



4.7.1 Identificação dos clientes

De acordo com o proposto na declaração do escopo, o público alvo do produto criado será micro e

pequenas empresas do Sul Fluminense. Serão consideradas como clientes finais em potencial as cinco

categorias com maior quantidade de estabelecimentos na cidade de maior PIB na região (Volta

Redonda) de acordo com (SEBRAE, 2011):

1. Comércios em geral

2. Serviços de Restaurantes

3. Serviços de médicos e odontológicos

4. Organizações religiosas

5. Serviços para eventos (Fotografia, filmagem, buffet etc)

4.7.2 Priorização dos clientes

Priorização dos clientes

Com

érci

os

Res

taur

ante

s

Méd

icos

Igre

jas

Even

tos

Tot

al%

Comércios 5 10 1/5 1/5 15,4 22%

Restaurantes 1/5 5 1/5 1/10 5,5 8%

Médicos 1/10 1/5 1/10 1/10 0,5 1%

Igrejas 5 5 10 1/5 20,2 28%

Eventos 5 10 10 5 30,0 42%

4.7.3 Identificação das necessidades

1. Administração do site fácil de usar

2. Site relevante na Internet

3. Páginas abertas rapidamente

4. Site seguro e com poucos erros

44

5. Site acessível em diversos dispositivos

4.7.4 Priorização das necessidades

Priorização das necessidadesCliente: Comércio

Usa

bilid

ade

Rel

evân

cia

Vel

ocid

ade

Con

fiabi

lidad

e

Porta

bilid

ade

Tot

al

%

Usabilidade 1/5 1 1/5 1 2,4 5%

Relevância 5 5 1 10 21,0 48%

Velocidade 1 1/5 1 5 7,2 16%

Confiabilidade 5 1 1 5 12,0 27%

Portabilidade 1 1/10 1/5 1/5 1,5 3%

Priorização das necessidadesCliente: Restaurantes

Usa

bilid

ade

Rel

evân

cia

Vel

ocid

ade

Con

fiabi

lidad

e

Porta

bilid

ade

Tot

al

%

Usabilidade 1/5 1 1/5 1 2,4 5%

Relevância 5 10 5 5 25,0 48%

Velocidade 1 1/10 1/5 1/10 1,4 3%

Confiabilidade 5 1/5 5 1 11,2 21%

Portabilidade 1 1/5 10 1 12,2 23%

Priorização das necessidadesCliente: Médicos

Usa

bilid

ade

Rel

evân

cia

Vel

ocid

ade

Con

fiabi

lidad

e

Porta

bilid

ade

Tot

al

%

Usabilidade 5 1 1/5 1/5 6,4 15%

Relevância 1/5 5 1/5 1 6,4 15%

Velocidade 1 1/5 1/5 1/5 1,6 4%

Confiabilidade 5 5 5 1 16,0 38%

Portabilidade 5 1 5 1 12,0 28%

45

Priorização das necessidadesCliente: Igrejas

Usa

bilid

ade

Rel

evân

cia

Vel

ocid

ade

Con

fiabi

lidad

e

Porta

bilid

ade

Tot

al

%

Usabilidade 1/5 1 5 5 11,2 24%

Relevância 5 1 10 5 21,0 44%

Velocidade 1 1 5 5 12,0 25%

Confiabilidade 1/5 1/10 1/5 1 1,5 3%

Portabilidade 1/5 1/5 1/5 1 1,6 3%

Priorização das necessidadesCliente: Eventos

Usa

bilid

ade

Rel

evân

cia

Vel

ocid

ade

Con

fiabi

lidad

e

Porta

bilid

ade

Tot

al

%

Usabilidade 1 5 5 1/5 11,2 21%

Relevância 1 5 10 5 21,0 39%

Velocidade 1/5 1/5 5 1/5 5,6 10%

Confiabilidade 1/5 1/10 1/5 1/5 0,7 1%

Portabilidade 5 1/5 5 5 15,2 28%

4.7.5 Priorização clientes x necessidades

Priorização clientes x necessidades

Com

érci

os

Res

taur

ante

s

Méd

icos

Igre

jas

Even

tos

Tot

al

Usabilidade 1% 0% 0% 7% 9% 17%

Relevância 10% 4% 0% 13% 16% 43%

Velocidade 4% 0% 0% 7% 4% 15%

Confiabilidade 6% 2% 0% 1% 1% 9%

Portabilidade 1% 2% 0% 1% 12% 16%

46

4.7.6 Desenvolvimento de especificações


Definição operacional: As telas devem ser autoexplicativas, com ícones representando as

seções o usuário tem que conseguir chegar a qualquer área da administração em poucos

cliques.

Valor a ser medido: Todas as funcionalidades do site devem estar acessíveis em

aproximadamente 3 cliques, a partir do momento em que o usuário fez o login. As telas

precisam ser descritivas, de forma que o usuário saiba de onde veio, onde está e para onde

pode ir ao próximo passo.


Definição operacional: O desenvolvedor deve usar técnicas de SEO (Search Engine

Optimization) para desenvolvimento dos arquivos HTML de modo que o site fique bem

posicionado nos buscadores.

Valor a ser medido: Após o site estar no ar por 30 dias e já estiver visível no Google, uma

busca pelo nome da empresa deve retornar o endereço da página web do cliente ainda na

primeira página do buscador.


Definição operacional: As páginas do site devem abrir rapidamente, evitando a desistência

do usuário.

Valor a ser medido: Uma página simples, sem muitas imagens e scripts deve demorar até 1

segundo para carregar, em condições normais de operação dos servidores.


Definição operacional: Tanto o site, quanto a área de administração deve operar com de

forma que não esteja vulnerável às brechas de segurança existentes na plataforma web e com o

mínimo de erros possível.

Valor a ser medido: Não deve haver nenhuma brecha de segurança no site e nenhuma

funcionalidade deve estar não operacional. No máximo 3 erros leves devem acontecer em todo

escopo do site.


Definição operacional: O site tem que funcionar de maneira total ou parcial em navegadores

desktop e mobile.

47

Valor a ser medido: Site totalmente funcional em Internet Explorer 9+, Mozilla Firefox e

Google Chrome. Site parcialmente funcional em Celulares e Tablets Android e IOS.

4.7.7 Garantia de Qualidade


Atividade: Verificar se os diagramas de sequência atendem à especificação de usabilidade.


Atividade: Durante a criação do layout do Painel Administrativo, verificar se o layout HTML

atende à especificação de SEO (Search Engine Optimization).


Atividade: Durante a criação de todas as telas, verificar se o tempo de carregamento a atende

à especificação de velocidade.


Atividade: Durante a criação de todas as telas, escrever testes de unidade que garantam a

confiabilidade de acordo com a especificação. Após a finalização, o sistema deve ser

submetido a um scanner de vulnerabilidades.


Atividade: Durante a criação do layout do Painel Administrativo e do layout padrão, verificar

se eles cumprem as especificações de portabilidade.

4.7.8 Priorização das mudanças nos quesitos de qualidade e respostas

As mudanças dos requisitos de qualidade são classificadas em quatro níveis de prioridade:

1. Requer ação imediata do gerente de projeto, pois pode impactar diretamente no sucesso do

projeto.

2. Requer planejamento para ação juntamente com a equipe se houver disponibilidade, pois

agregam valor ao sucesso do projeto, mas não impedem que a solução funcione.

3. A equipe deve ser informada sobre a mudança que deve ser feita somente se houver folga no

final da entrega do projeto.

4.7.9 Sistema de controle de mudanças da qualidade (Quality change control system)

Todas as mudanças na qualidade do projeto devem ser tratadas segundo o fluxo apresentado a seguir

com suas conclusões apresentadas na reunião semanal do CCB com suas conclusões, prioridades e

ações relacionadas.

48

INÍCIO

Solicitaçãode Mudanças

Análise damudançasolicitada

Defeitoou melhoria Ignorar

Impactonos custos e

ou prazosPrioridade 3

Impacto emoutras áreas Prioridade 2

Prioridade 1



(Change Request)

Melhoria

Defeito

Baixo

Alto

Baixo

Alto

4.7.10 Alocação financeira das mudanças nos requisitos de qualidade

As mudanças na qualidade, que requerem gasto extra, devem ser alocadas dentro das reservas

gerenciais do projeto, desde que dentro da alçada do gerente de projeto. Caso contrário ou se não

existir mais reserva, deverá ser acionado o patrocinador, pois o gerente de projeto não tem autonomia

para usar a reserva de contingência de riscos para mudanças na qualidade.

4.7.11 Administração do plano de gerenciamento de qualidade



gerenciamento de qualidade.

49


pelo plano de gerenciamento de tempo.

Frequência de atualização do plano de gerenciamento de tempo

O plano de gerenciamento de qualidade será reavaliado semanalmente dentro da reunião do CCB,


4.7.12 Outros assuntos relacionados ao gerenciamento de qualidade do projeto não previstos

neste plano


CCB. Imediatamente após sua aprovação, deverá ser atualizado o plano de gerenciamento de

qualidade com o devido registro das alterações efetivadas.



APROVAÇÕES



50

4.8 PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS

HUMAN RESOURCES MANAGEMENT PLAN



4.8.1 Organograma do projeto

DesenvolvimentoEquipe: Desenvolvimento

Analista Programador SêniorWalter Amorim

Analista Programador PlenoRodrigo Rodrigues

Analista Programador JuniorRenan Borges

Designer GráficoMarlon Mendes

Afonso França de OliveiraGerente de Projeto

Admir Pinto de OliveiraPatrocinador

DesignEquipe: Design

4.8.2 Diretório do time do projeto (Team directory)

Nº Nome Área e-mail Telefone

1 Afonso França de Oliveira Gerência Projeto [email protected] 24 9947-5822

2 Walter Amorim Desenvolvimento [email protected] 24 9907-9994

3 Rodrigo Rodrigues Desenvolvimento [email protected] 24 9857-7896

4 Renan Borges Desenvolvimento [email protected] 24 8817-8867

5 Marlon Mendes Design [email protected] 24 9962-7864

51

4.8.3 Matriz de responsabilidades

Nº Nome Área

Ger

. Pro

jeto

Con

figur

ação

de A

mbi

ente

Lay

out

Eng

enha

ria

de

Soft

war

e

Doc

umen

taçã

o

Hom

olog

ação

Enc

erra

men

to

1Afonso França de

OliveiraGerência Projeto R A R

2 Walter Amorim Desenvolvimento S A R S S

3 Rodrigo Rodrigues Desenvolvimento A A S S R A

4 Renan Borges Desenvolvimento R S A R A

5 Marlon Mendes Design S R

R- Responsável A- Apoio S- Suplente

4.8.4 Novos recursos, realocação e substituição de membros do time

O gerente de projeto deve se empenhar pessoalmente na permanência de todos os integrantes da equipe durante o projeto e por isso será o coordenador deste plano de recursos humanos.

No caso de realocação do profissional integrante do projeto, caberá ao gerente de projeto, a identificação do substituto em comum acordo com as diretrizes do projeto e as funções a serem exercidas.

Novos recursos solicitados para o time devem ser previamente autorizados pelo patrocinador e serão arcados integralmente pelas reservas gerenciais do projeto.

4.8.5 Treinamento

Não estão previstos treinamentos para a equipe de projeto. Qualquer necessidade extraordinária de treinamento deve ser aprovada previamente pelo gerente de projeto, tendo seus custos alocados nas reservas gerenciais.

4.8.6 Avaliação de resultados

O resultado do trabalho da equipe será avaliado no final do projeto pelo gerente de projeto em reunião individual com cada membro do time do projeto.

O gerente de projeto será avaliado pelo patrocinador do projeto, da mesma forma como os membros do time são avaliados.

4.8.7 Bonificação

Será destinado, no final do projeto, todo o saldo contido na reserva gerencial para serem distribuídos

para todos os integrantes do time, incluindo o gerente de projeto, em parcelas iguais de valores,

independentemente do cargo.

52

A bonificação somente será paga após o término do projeto e para os membros do time que

participaram integralmente dele, realizando suas atividades previstas quando foram inicialmente

alocados no projeto.

Membros que foram substituídos não terão direito à bonificação.

O patrocinador não participará da bonificação.

53

4.8.8 Frequência de avaliação consolidada dos resultados do time

O resultado da avaliação será apresentado uma única vez no encerramento do projeto.

4.8.9 Alocação financeira para o gerenciamento de RH

Todas as medidas de gerenciamento de recursos humanos do projeto que requererem gasto adicional

deverão ser alocadas dentro das reservas gerenciais do projeto, na categoria Outras reservas, desde que

dentro da alçada do gerente de projeto.

Para medidas prioritárias ou urgentes que dizem respeito ao gerenciamento do time que estejam fora

da alçada do gerente de projeto, ou quando não existir mais reserva gerencial disponível, deverá ser

acionado o patrocinador, uma vez que o gerente de projeto não tem autonomia para decidir utilizar a

reserva de contingência de riscos no gerenciamento do time.

4.8.10 Administração do plano de gerenciamento de recursos humanos



gerenciamento de recursos humanos.


pelo plano de gerenciamento de recursos humanos.

Frequência de atualização do plano de gerenciamento de custos

O plano de gerenciamento de custos será reavaliado mensalmente na primeira reunião do CCB,


4.8.11 Outros assuntos relacionados ao gerenciamento de RH do projeto não previstos neste

plano



gerenciamento de custos com o devido registro das alterações efetivadas.



APROVAÇÕES

54



55

4.9 PLANO DE GERENCIAMENTO DE COMUNICAÇÕES

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DAS COMUNICAÇÕES

COMMUNICATIONS MANAGEMENT PLAN



4.9.1 Descrição dos processos de gerenciamento das comunicações

O gerenciamento das comunicações do projeto será realizado através dos processos de

comunicação formal, estando incluídos:

o e-mails,

o publicações no Google Drive,

o reuniões com ata lavrada.

Todas as reuniões formais serão realizadas às segundas-feiras para disponibilizar tempo livre

para os trabalhos do projeto nos dias subsequentes.

Todas as informações do projeto devem ser atualizadas de modo constante no Google Drive,

incluindo as atualizações diárias nos custos e nos prazos.

Todas as solicitações de mudança no processo de comunicação devem ser feitas por escrito ou

através de e-mail e aprovadas pelo gerente do projeto.

4.9.2 Registros das partes interessadas

Nome Afonso França de Oliveira

Papel Gerente do Projeto

Contato [email protected]

Necessidades Projeto executado dentro de acordo com o Plano de Gerenciamento de Projeto

Expectativas Sistema funcionando e clientes satisfeitos

Nome Admir Pinto de Oliveira

Papel Patrocinador

Contato [email protected]

Necessidades Projeto executado dentro do prazo e custo estabelecidos

Expectativas Produto vendido para 24 clientes em 1 ano

Nome Equipe de Desenvolvimento56

Papel Equipe

Necessidades Motivação intrínseca e extrínseca

Expectativas Produto desenvolvido com tecnologia de ponta e engenharia de software eficiente

Nome Equipe de Design

Papel Equipe

Necessidades Motivação intrínseca e extrínseca

Expectativas Produto bonito e com usabilidade excepcional

Nome Clientes

Papel Cliente

Necessidades Expor seu produto / serviço na Internet

Expectativas Aumentar o faturamento e promover o nome da empresa

4.9.3 Matriz de análise das partes interessadas

Alto poder, baixo interesse Alto poder, alto interesse

Patrocinador

Gerente do Projeto

Baixo poder, baixo interesse Baixo poder, alto interesse

Equipe de Desenvolvimento

Equipe de Design

57

4.9.4 Estratégia de Gerenciamento de Partes Interessadas

Nome Equipe de Desenvolvimento

Influência Desmotivação dos membros da equipe

Avaliação do impacto Alto

Estratégias Capacitar o Gerente de Projetos para lidar

com as motivações intrínsecas dos membros

da equipe.

Remunerar os membros da equipe

adequadamente

Nome Clientes

Influência Desistirem do Projeto no meio

Avaliação do impacto Alto

Estratégias Prover alta frequência de feedback, trazendo-

os para participar da reunião do CCD.

4.9.5 Eventos de Comunicação

O projeto terá os seguintes eventos de comunicação:

Kick Off Meeting

1. Objetivo: Dar início ao projeto, apresentando as informações quanto ao seu objetivo e à sua

importância, aos seus prazos, aos custos, etc. Devem também ser apresentadas as principais

entregas do projeto e os elementos de alto nível no WBS. Outro objetivo do evento é motivar e

dar suporte gerencial ao gerente de projeto e ao seu time, de modo a construir um ambiente

colaborativo e integrado.

2. Metodologia: Apresentação em auditório com utilização de projetor, notebook e sistema de

som.

3. Responsável: Afonso França de Oliveira, gerente do projeto

4. Envolvidos: Todos os envolvidos no time do projeto e patrocinador

5. Data e horário: 04/02/2013 às 10h00

6. Duração: 4 horas

7. Local: Auditório do SESC – Barra Mansa

8. Outros: Lista de Presença Requerida

58

Reunião de CCB

1. Objetivo: Avaliar todos os indicadores do projeto, incluindo os resultados parciais obtidos e a

avaliação do cronograma, do orçamento, das reservas gerenciais e de contingência, dos riscos

identificados e da qualidade obtida. Tem como base garantir o cumprimento do plano de

projeto, sendo o processo principal a aprovação das solicitações de mudança apresentadas.

2. Metodologia: Apresentação em auditório com utilização de projetor, notebook e sistema de

som.


4. Envolvidos: Gerente de projetos e patrocinador

5. Data e horário: Semanal, às segundas-feiras, com início dia 11/02/2013 e término em

01/04/2013 às 10h00



8. Outros: Ata de reunião

Reunião de Avaliação da equipe

1. Objetivo: Avaliar o desempenho do time do projeto, conforme previsto no plano de

gerenciamento de RH, na categoria Avaliação de Resultados.

2. Metodologia: Reuniões individuais entre os integrantes do time do projeto e o Gerente de

Projetos para o preenchimento da avaliação de desempenho dos profissionais, conforme

descrito no plano de RH.


4. Envolvidos: Gerente de projetos e os integrantes do time do projeto



7. Local: SESC – Barra Mansa


Reunião de Avaliação dos planos de projeto

1. Objetivo: Avaliar a efetividade dos planos de gerenciamento do projeto, verificando se o que

está estabelecido como regra no plano está sendo cumprido e se o plano precisa de

atualização.

2. Metodologia: Reunião convencional, onde o Gerente de Projetos, o responsável pelos planos,

apresenta os potenciais desvios e necessidades de atualização para os demais integrantes do

time, que realizam comentários e sugestões até que o plano seja atualizado e aprovado pelo

gerente de projeto.


4. Envolvidos: Gerente de projetos e os integrantes do time do projeto59

5. Data e horário: Mensal com início dia 04/03/2013 e término em 01/04/2013 às 12h00


7. Local: SESC – Barra Mansa


Project Close out

1. Objetivo: Apresentar os resultados obtidos no projeto, bem como discutir as falhas e os

problemas ocorridos de modo a fornecer base para o acúmulo de experiências sobre o projeto.

2. Metodologia: Apresentação dos resultados pelo gerente do projeto, bem como discussão direta

através de mapas mentais sobre todas as questões e melhorias possíveis para futuros projetos.

3. Responsável: Afonso França de Oliveira, gerente do projeto e patrocinador

4. Envolvidos: Gerente de projetos e os integrantes do time do projeto




8. Outros: Lista de Presença requerida

4.9.6 Cronograma dos Eventos de Comunicação

Evento de Comunicação Fevereiro Março Abril04 11 18 25 04 11 18 25 01 08

Kick-off Meeting do ProjetoReunião do CCB 1Reunião do CCB 2Reunião do CCB 3Reunião do CCB 4Reunião do CCB 5Reunião do CCB 6Reunião do CCB 7Reunião do CCB 8Reunião mensal de avaliação dos planosReunião mensal de avaliação dos planosReunião avaliação da equipeProject Close out

Qualquer outra necessidade de relatórios de progresso para as reuniões de CCB previstas deverá ser

solicitada com antecedência de 48 horas e por escrito com autorização do gerente do projeto.

60

Modelo de relatório de Estrutura Analítica do Projeto (EAP)

A representação a seguir é o padrão para a visualização da EAP durante o progresso do projeto, onde

as atividades concluídas são apresentadas em preto, as atividades em execução em cinza e as não

iniciadas em branco, incluindo também o percentual completo da atividade dentro da caixa da

atividade.

Responsável: Afonso França de Oliveira

Área: Gerenciamento de escopo

3. IMPLEMENTAÇÃO 7%

3.1 Layout dopainel administrativo 100%

3.2 Modelagem dobanco de dados 50%

3.3 API para modelagemde interface do site 50%

3.4 Layout de exemplo 50%

3.5 Tela de login dousuário 0%

3.6 Tela de gerenciamentode destaques 0%

3.7 Tela de gerenciamento de entidades customizadas 0%

3.8 Tela de gerenciamentode usuários 0%

3.9 Tela de gerenciamentode álbum de fotos 0%

3.10 Tela de gerenciamentode objetos 0%

3.11 Botão para Importaçãode álbum do Facebook 0%

3.12 Botão para Importaçãode vídeo do Youtube 0%

3.13 Documentar código0%

2. ANÁLISE E PROJETODE SOFTWARE75%

2.4 Configurar ambientesde desenvolvimento50%

2.1 Diagramas de casosde uso 100%

2.2 Diagramas desequência100%

2.3 Diagrama de classes100%

4. HOMOLOGAÇÃO 0%

4.1 Instalação emcliente piloto0%

4.2 Teste de aceitaçãoem cliente piloto0%

4.3 Treinamento docliente0%

4.4 Criação de FAQdo usuário0%

5. ENCERRAMENTO 0%

5.1 Registro de LiçõesAprendidas0%

5.2 Finalização doProjeto0%

PROJETO MEGA SITE25%


1.2 Monitoramento econtrole100%

Modelo de Gráfico de Gantt

O gráfico de Gantt do projeto será evidenciado através de barras no tempo para todas as atividades do

projeto ao longo de sua execução. As dependências são mostradas através de setas e o caminho crítico

em vermelho.


Área: Gerenciamento de tempo

61

Modelo de acompanhamento do Orçamento do Projeto

O orçamento do projeto será acompanhado apresentando o orçamento de cada atividade e o seu custo

atualizado, resumindo essas informações em um indicador gráfico de status do projeto, onde o status

branco indica o gasto abaixo do orçamento, o status cinza indica um custo real inferior ao custo orçado

em menos de 5%, o status preto indica um custo real superior ao orçado.


Área: Gerenciamento de custos

62

Modelo de acompanhamento do Orçamento do Projeto

O orçamento do projeto será acompanhado apresentando o orçamento de cada atividade e o seu custo

atualizado, resumindo essas informações em um indicador gráfico de status do projeto, onde o status

branco indica o gasto abaixo do orçamento, o status cinza indica um custo real inferior ao custo orçado

em menos de 5%, o status preto indica um custo real superior ao orçado.


Área: Gerenciamento de custos

4.9.9 Ambiente técnico e estrutura de armazenamento e distribuição da informação (EPM)

A estrutura de armazenamento e distribuição da informação será realizada integralmente pela internet

através de uma pasta compartilhada no Google Drive.

Os usuários do ambiente utilizarão a internet para atualizar e acessar informações do projeto,

permitindo o planejamento de colaboração entre os integrantes do grupo de trabalho, o gerentes de

projeto e o patrocinador, facilitando a troca de informações sobre o projeto e o trabalho com elas em

um site da Web.

O ambiente também permitirá que os usuários exibam, atualizem e analisem informações sobre o

projeto através de um navegador da Web, além de ajudar os integrantes da equipe a se comunicarem

63

com o gerente sobre as tarefas que estão executando, fornecendo um local onde todos, podem obter

informações sobre o projeto.

O Google Drive apresenta a seguinte arquitetura de acesso:

Area de exibição dos arquivos

Usuário logado

Area de estuturação da basede conhecimento

Todo o ambiente para armazenamento das informações já está disponível, de graça, na infraestrutura

do Google, não existindo custos adicionais para o projeto.

4.9.10 Alocação financeira para o gerenciamento das comunicações

Os custos relativos ao gerenciamento das comunicações serão considerados, para fins de projeto, como

despesas administrativas e não serão incluídos nos custos do projeto, uma vez que o plano de

gerenciamento de custos prevê a contabilização de apenas gastos adicionais ao projeto.

No caso de necessidade de despesas no processo de comunicação, essas despesas podem ser alocadas

dentro das reservas gerenciais do projeto, na categoria Outras reservas, desde que dentro da alçada do

gerente de projeto.

Para necessidades prioritárias que estejam fora da alçada do gerente de projeto, ou quando não existe

mais reserva gerencial disponível, deverá ser acionado o patrocinador, já que o gerente de projeto não

tem autonomia necessária para decidir utilizar a reserva de contingência de riscos no gerenciamento

das comunicações.

64

4.9.11 Administração do plano de gerenciamento das comunicações



gerenciamento de comunicações.


pelo plano de gerenciamento de comunicações.

Frequência de atualização do plano de gerenciamento das comunicações

O plano de gerenciamento das comunicações será reavaliado mensalmente na primeira reunião mensal

do CCB, juntamente com os outros planos de gerenciamento do projeto.

4.9.12 Outros assuntos relacionados ao gerenciamento das comunicações do projeto não

previstos neste plano

Todas as solicitações não previstas neste plano devem ser submetidas para aprovação na reunião do

CCB (Comitê de Controle de Mudanças) para aprovação. Imediatamente após sua aprovação devem

ser atualizadas no plano de gerenciamento das comunicações com seu devido registro de alterações.



APROVAÇÕES



65

4.10 PLANO DE GERENCIAMENTO DE RISCOS

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE RISCOS E RESPOSTAS AOS RISCOS

RISK MANAGEMENT PLAN AND RISK RESPONSE MANAGEMENT PLAN



4.10.1 Descrição dos processos de gerenciamento de riscos

O gerenciamento de riscos do projeto será realizado com base nos riscos previamente

identificados, bem como no monitoramento e no controle de novos riscos que podem não ter

sido identificados oportunamente.

Todos os riscos não previstos no plano devem ser incorporados ao projeto dentro do sistema

de controle de mudanças de riscos (Risk Change Control System).

Os riscos a serem identificados serão apenas os riscos internos ao projeto. Riscos relacionados

ao mercado ou à sociedade serão automaticamente aceitos sem análise e sem uma resposta

prevista (aceitação passiva).

As respostas possíveis aos riscos identificados pelo projeto serão as aceitações passiva e ativa

(através de contingências), a atenuação e a transferência através de seguro. Não será aceito

como uma possível resposta ao risco o ato de evitá-lo (avoidance), uma vez que não serão

aceitas alterações no escopo que não sejam de caráter corretivo no produto final do projeto.

A identificação, a avaliação e o monitoramento de riscos devem ser feitos por escrito ou

através de e-mail, conforme descrito no plano de comunicações do projeto.

4.10.2 RBS – Risk Breakdown Structure para a identificação dos riscos

O modelo de estrutura de riscos a ser utilizado pelo projeto será o proposto por Wideman, porém

abordando apenas os Riscos internos não técnicos, os Riscos legais e os Riscos técnicos. Riscos

externos não serão considerados, conforme já apresentado anteriormente. O modelo a seguir foi

utilizado como base para a identificação dos riscos do projeto.

66

RISCOS TÉCNICOS

Mudanças na tecnologia

Performance

Riscos da tecnologia

Riscos do protótipo / piloto

Complexidade doprojeto

RISCOS TÉCNICOS

Fluxo de caixa

Gerenciais

Prazos

Custo

RISCOS LEGAL

Contratos

Reclamações deterceiros

Reclamações contraterceiros

RISCO TOTAL

RISCOS ACEITOS

Riscos externosimprevisíveis

Riscos externosprevisíveis

RISCOS CONSIDERADOS

4.10.3 Riscos identificados

Os riscos identificados no projeto, segundo o WBS do projeto e a RBS anteriormente apresentada

estão listados na estrutura a seguir.

PROJETO MEGA SITE


2. ANÁLISE E PROJETODE SOFTWARE

3. IMPLEMENTAÇÃO

4. HOMOLOGAÇÃO

5. ENCERRAMENTO

1.1 Escopo do projeto não retratar a real necessidade do cliente

1.2 Membros da equipe romperem o contrato e saírem durante a execução do projeto

2.1 Falta de experiência na instalação do software pela equipe, podendo atrasar o início da implementação

2.2 Diagramas não representarem a realidade de uso do cliente, causando uma implementação ineficiente

3.1 Membros da equipe não conhecerem profundamente a tecnologia utilizada

3.2 Mudanças bruscas na arquitetura do software, gerando retrabalho e atrasos

3.3 Falha na comunicação remota dos membros da equipe

4.1 Piloto retratar o cenário de um, mas não de todos clientes, criando um produto não vendável

4.2 Performance do software criado não atingir os padrões necessários para uma boa usabilidade

4.3 Layout do site não agradar o gosto do cliente

4.4 Sistema apresentar muitos erros, requerendo uma reprogramação extensa

3.4 Facebook e Youtube mudarem suas API's tornando a integração inválida

4.5 Cliente não conseguir usar o software com facilidade

Os riscos anteriores foram identificados pelo time de projeto utilizando-se do RBS através da técnica

de Brainstorming.

4.10.4 Qualificação dos riscos

Os riscos identificados serão qualificados na sua probabilidade de ocorrência e impacto ou gravidade

dos seus resultados

67

Probabilidade

Baixa – A probabilidade de ocorrência do risco pode ser considerada pequena ou

imperceptível (menor do que 20%).

Média – Existe uma probabilidade razoável de ocorrência do risco (probabilidade entre 20 e

60%).

Alta – O risco é iminente (probabilidade maior que 60%).

Gravidade

Baixa – O impacto do evento de risco é irrelevante para o projeto, tanto em termos de custo

quanto de prazos, podendo ser facilmente resolvido.

Média – O impacto do evento de risco é relevante para o projeto e necessita de um

gerenciamento mais preciso, sob pena de prejudicar os seus resultados.

Alta – O impacto do evento de risco é extremamente elevado e, no caso de não existir uma

interferência direta, imediata e precisa da equipe do projeto, os resultados serão seriamente

comprometidos.

4.10.5 Quantificação dos riscos

Por se tratar de um projeto onde somente os riscos internos serão avaliados, optou-se por analisar

apenas os riscos segundo aspectos qualitativos, utilizando-se o conceito qualitativo de valor agregado,

anteriormente apresentado para os riscos identificados. Portanto, não será feita, neste plano, a análise

quantitativa dos riscos.

4.10.6 Sistema de controle de mudanças de riscos (Risk change control system)

Toda a identificação de riscos e alterações nos riscos já identificados (variação na probabilidade e

impacto dos riscos deve ser tratada segundo o fluxo apresentado a seguir com suas conclusões

apresentadas na reunião semanal de CCB com suas conclusões, prioridades e ações relacionadas).

68

INÍCIO

Estabelecersistema de

identificação deriscos

FIM


Atualizar aidentificação dos

riscos

Atualizar aavaliação dosnovos riscos

Atualizar aavaliação dos

ricos anteriores

Atualizarestratégias deresposta aos

riscos

Rever e atualizaro plano do projeto

incorporandoestratégias

4.10.7 Respostas planejadas aos riscos

Para os riscos identificados e qualificados, optou-se por estratégias diferenciadas para cada

necessidade, conforme quadro a seguir.

Item Fase Risco Prob. Grav. Resposta Descrição CustoCom o

tempo

1.1 Ger. Projeto Escopo do projeto

não retratar a real

necessidade do

cliente

Baixa Alta Aceitação

passiva

O risco não será

respondido e verba de

contingência será

utilizada em caso de

necessidade.

- Agrava

1.2 Ger. Projeto Membros da

equipe romperem

o contrato e saírem

durante a execução

do projeto

Médi

a

Médi

a

Transferência Inserir cláusula

contratual de

permanência durante

todo o tempo do

projeto, com multa

rescisória

- Diminui

69


tempo

2.1 Análise Falta de

experiência na

instalação do

software pela

equipe, podendo

atrasar o início da

implementação

Médi

a

Baixa Aceitação

passiva

O risco não será


contingência será


necessidade.

- Diminui

2.2 Análise Diagramas não

representarem a

realidade de uso do

cliente, causando

uma

implementação

ineficiente

Médi

a

Médi

a

Atenuação Validar com o cliente

piloto os casos de uso,

antes de iniciar a

implementação

- Agrava

3.1 Implementaçã

o

Membros da

equipe não

conhecerem

profundamente a

tecnologia

utilizada

Baixa Médi

a

Aceitação

passiva

O risco não será


contingência será


necessidade.

- Constante

3.2 Implementaçã

o

Mudanças bruscas

na arquitetura do

software, gerando

retrabalho e

atrasos

Médi

a

Alta Evitar Utilização de técnicas

homologadas do

mercado em padrões

de projetos de

softwares e

frameworks

amplamente testados

e conhecidos no

mercado

- Agrava

3.3 Implementaçã

o

Falha na

comunicação

remota dos

membros da

equipe

Alta Baixa Atenuação Realizar reunião

online diariamente

para feedback e

sincronização dos

trabalhos

- Constante

3.4 Implementaçã

o

Facebook e

Youtube mudarem

suas API's

tornando a

integração inválida

Baixa Baixa Aceitação

passiva

O risco não será


contingência será


necessidade.

- Constante

4.1 Homologação Piloto retratar o

cenário de um,

mas não de todos

clientes, criando

um produto não

vendável

Alta Alta Atenuação Convidar potenciais

clientes de outras

áreas para

acompanhar

passivamente o piloto

- Agrava

70


tempo

4.2 Homologação Performance do

software criado

não atingir os

padrões

necessários para

uma boa

usabilidade

Médi

a

Médi

a

Evitar Utilização de técnicas

homologadas do

mercado em padrões

de projetos de

softwares e

frameworks

amplamente testados

e conhecidos no

mercado

- Agrava

4.3 Homologação Layout do site não

agradar o gosto do

cliente

Médi

a

Baixa Evitar Validar layout com o

cliente antes de fazer

a implementação

propriamente dita

- Agrava

4.4 Homologação Sistema apresentar

muitos erros,

requerendo uma

reprogramação

extensa

Médi

a

Alta Atenuar Programar utilizando

técnicas de qualidade

de software como

testes de unidade

- Agrava

4.5 Homologação Cliente não

conseguir usar o

software com

facilidade

Médi

a

Médi

a

Atenuar Criar mockups e

colher informações de

experiência do

usuário com o cliente

piloto antes de

começar a

implementação

- Agrava

4.10.8 Reservas de contingência

Conforme descrito no plano de gerenciamento de custos, as reservas de contingência são reservas

destinadas exclusivamente ao processo de gerenciamento de riscos para os eventos de riscos aceitos

ativamente e para os riscos atenuados ou riscos não identificados de modo preliminar no projeto.

As ações de contorno do projeto (respostas não planejadas aos riscos) devem utilizar exclusivamente

as reservas de contingência do projeto.

As reservas serão consumidas com base nas solicitações de mudanças provenientes dos outros planos e

dentro da autonomia do gerente do projeto e do patrocinador.

As reservas de contingência totalizam R$ 2.000, e o gerente de projeto tem as seguintes autonomias

quanto à utilização das reservas:

Reservas de Contingência

Gerente de projeto isoladamente Até R$ 100,00

Gerente de projeto com aval do patrocinador Até R$ 200,00

Somente patrocinador Acima de R$ 200,00 até o limite das reservas71

Essa autonomia é por cada evento de risco, podendo o gerente de projeto consumir toda a reserva,

desde que em eventos diferentes. Com o fim das reservas, somente o patrocinador poderá solicitar a

criação de novas reservas conforme será apresentado a seguir nesse plano.

4.10.9 Frequência de avaliação dos riscos do projeto

Os riscos identificados no projeto devem ser avaliados semanalmente dentro da reunião de CCB

(Change Control Board), prevista no plano de gerenciamento das comunicações.

4.10.10 Alocação financeira para o gerenciamento de riscos

As necessidades relacionadas à identificação, qualificação, quantificação e desenvolvimento de

respostas aos riscos que não estiverem listados neste documento devem ser alocadas dentro das

reservas gerenciais do projeto, na categoria Reservas de contingência, desde que dentro da alçada do

gerente de projeto.

Para ações prioritárias que estejam fora da alçada do gerente de projeto, ou quando não existe mais

reserva de contingência disponível, deverá ser acionado o patrocinador, uma vez que o gerente de

projeto não tem autonomia necessária para decidir utilizar o capital disponível em Outras reservas para

gerenciar riscos.

4.10.11 Administração do plano de gerenciamento de riscos



gerenciamento de riscos.


pelo plano de gerenciamento de riscos.

Frequência de atualização do plano de gerenciamento de riscos

O plano de gerenciamento de riscos será reavaliado mensalmente na primeira reunião do CCB,



plano



gerenciamento de riscos com o devido registro das alterações efetivadas.

72



APROVAÇÕES



73

4.11 PLANO DE GERENCIAMENTO DE AQUISIÇÕES

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE AQUISIÇÕES

PROCUREMENT MANAGEMENT PLAN



4.11.1 Descrição dos processos de gerenciamento das aquisições

O gerenciamento das aquisições terá basicamente um único foco principal: contratação e

administração dos contratos com os membros da equipe.

A autonomia sobre os contratos é de exclusiva competência do gerente do projeto, que irá

assinar todos os contratos e medições de serviços previstos no orçamento.

Os aspectos éticos do processo de aquisição serão rigorosamente acompanhados, respeitados

os seguintes princípios:

o Legalidade

o Igualdade

o Publicidade

o Impessoalidade

o Imparcialidade

o Moralidade

o Probidade administrativa

o Lealdade à empresa

Quaisquer infrações a esses aspectos serão consideradas faltas gravíssimas pelo gerente do

projeto e pelo patrocinador.

Serão consideradas para o gerenciamento das aquisições apenas as aquisições diretamente

relacionadas ao escopo do projeto. Inovações e novos recursos não serão abordados pelo

gerenciamento das aquisições e serão passíveis de novas negociações.

Quaisquer solicitações de mudança no processo de aquisições devem ser feitas através de e-

mail, conforme descrito no plano de comunicações do projeto.

4.11.2 Gerenciamento e tipos de contratos

Todas as cláusulas contratuais pactuadas devem ser rigorosamente respeitadas, principalmente

no que diz respeito ao cumprimento de prazos de entrega e atendimento aos requisitos

solicitados.

74

A elaboração dos contratos é de responsabilidade do gerente de projeto, sob supervisão de um

consultor jurídico da empresa.

Todos os contratos deste projeto são do tipo Preço Unitário Fixo e Irreajustável, onde os

valores unitários das mercadorias e o custo/hora dos serviços serão fixados em contrato, e o

número de horas previstas será baseado nas necessidades orçadas para o projeto.

4.11.3 Critérios de avaliação de cotações e propostas

A avaliação para contratação dos membros da equipe será baseada no conceito de técnica e

preço.

4.11.4 Avaliação de fornecedores

Será realizada mensalmente uma reunião interna para a avaliação dos resultados dos fornecedores na

1ª segunda-feira de cada mês em seguida à reunião de CCB juntamente com a avaliação da equipe,

pois o processo de contratação envolve apenas a contratação da equipe. O objetivo da reunião será

verificar o cumprimento de prazos e qualidade do serviço prestado.

Nos casos de não cumprimento dos itens de contrato por parte do fornecedor, as seguintes medidas

podem ser tomadas:

advertência ao fornecedor – para desvios leves que não comprometam o sucesso no

cumprimento dos prazos e escopo do projeto;

suspensão do fornecedor – para desvios médios que comprometam parte do escopo do projeto

ou para fornecedores já advertidos anteriormente;

cancelamento do contrato – para desvios graves que comprometam o projeto e que necessitem

de intervenção direta do gerente do projeto e do patrocinador ou para fornecedores já

suspensos anteriormente.

4.11.5 Frequência de avaliação das aquisições do projeto

Os processos de aquisições devem ser avaliados semanalmente e apresentados na reunião semanal de

CCB (Change Control Board), prevista no plano de gerenciamento das comunicações.

4.10.6 Alocação financeira para o gerenciamento de aquisições

Qualquer necessidade de aquisição não prevista no orçamento e que requeira gasto adicional do

projeto deve ser alocada dentro das reservas gerenciais do projeto, na categoria Outras reservas, desde

que dentro da alçada do gerente de projeto.

Para compras urgentes e prioritárias que estejam fora da alçada do gerente de projeto, ou quando não

existe mais reserva gerencial disponível, deverá ser acionado o patrocinador, uma vez que o gerente de

projeto não tem autonomia necessária para decidir utilizar a reserva de contingência de riscos para

aquisições.

75

4.10.7 Administração do plano de gerenciamento de aquisições



gerenciamento de aquisições.


pelo plano de gerenciamento de aquisições.

Frequência de atualização do plano de gerenciamento de aquisições

O plano de gerenciamento de aquisições será reavaliado mensalmente na primeira reunião do CCB,



plano



gerenciamento de aquisições com o devido registro das alterações efetivadas.



APROVAÇÕES



76

5. CONCLUSÕES

Atualmente trabalho como coordenador de projetos de software em uma empresa que utiliza

métodos ágeis para planejamento e execução dos projetos de software. Lá existe uma grande

mobilização em tornar os processos cada vez mais rápidos e atenderem as mudanças de forma mais

eficiente. Apesar disto ainda esbarramos constantemente na deficiência em iniciar de forma efetiva um

projeto.

Na minha visão, muitas empresas de software, que utilizam métodos ágeis, focam muito em

algumas áreas de conhecimento como gerenciamento de escopo, tempo e custos, deixando um pouco

de lado outras áreas como gerenciamento da qualidade, riscos, comunicações e aquisições. Acredito

que enquanto o gerenciamento em todas as áreas não for eficiente, os projetos não terão os melhores

resultados.

Como exemplo posso citar o último projeto que participei. Durante o seu planejamento, cujo

escopo seria a migração de um produto de uma linguagem de programação legada para uma de

plataforma web, foi decidido na reunião inicial entre a diretoria da empresa que o sistema novo não

englobaria uma determinada funcionalidade que o antigo possuía, pois nenhum cliente a utilizava. No

entanto, no decorrer do projeto, na etapa de homologação, foi detectado que esta funcionalidade não

poderia ser abandonada, e era uma funcionalidade que compunha 30% do escopo do antigo produto.

Esta mudança ocasionou prejuízo financeiro para a empresa, atraso nos prazos, desgaste no

relacionamento das equipes, e muitos outros problemas. Tenho certeza que se o gerente do projeto

tivesse tido mais atenção, principalmente no gerenciamento das comunicações e dos riscos, este

problema poderia ter sido evitado.

Os processos ágeis de alguma forma dizem que é necessário planejar pouco pois, a

possibilidade de que o plano mude é grande. Porém, acredito que em alguns projetos de software é

possível ter um escopo bem definido e um planejamento completo. Projetos de atualização de

tecnologia legada ou estruturação de um protótipo já funcional são dois dos casos que entendo esta

premissa como verdadeira.

No caso do projeto deste trabalho, foi possível prever com muita precisão o escopo porque ele

se encaixava no segundo caso que mencionei. Já existia um protótipo funcional e restava apenas

reestruturá-lo de forma que ele se tornasse um produto vendável. Por isto acredito que a utilização das

práticas, processos e padrões divulgados pelo PMI através do PMBOK para desenvolvimento de

software podem ser de muita utilidade e auxiliam a criação de um projeto maduro.

77

Em suma acredito que para o planejamento e execução eficiente de um projeto de software

não existe apenas uma ferramenta. Existem vários frameworks e conjuntos de boas práticas que

precisam ser usados no lugar certo, na hora certa.

Outro item importante que podemos destacar é que vale a pena as empresas de software

investirem significativamente em treinamento e certificação de seus profissionais, seja em PMI, ou

seja em qualquer outra metodologia de gerenciamento de projetos.

Sem dúvida o mercado de software vem evoluindo significativamente no gerenciamento de

projetos. No entanto ainda há um grande desafio no sentido de despertar as empresas que ainda estão

dando os primeiros passos na estrutura de projetização, bem como melhorar o nível de

amadurecimento das empresas que já praticam um gerenciamento eficiente e por fim conscientizar os

gerentes de projetos e outros profissionais a entenderem o valor de se utilizar as melhores práticas e

práticas emergentes para desenvolvimento de software.

78

6. REFERÊNCIAS BIBLIOGRÁFICAS

CETIC.BR. TIC - Domicílios e Empresas 2011. CETIC.br, 2012. Disponivel em:

<http://op.ceptro.br/cgi-bin/cetic/tic-domicilios-e-empresas-2011.pdf>. Acesso em: 18 mar. 2013.

COMPUTERWORLD. Internet: quatro em cada 10 empresas brasileiras não têm site.

ComputerWorld, 23 Maio 2012. Disponivel em:

<http://computerworld.uol.com.br/tecnologia/2012/05/23/internet-quatro-em-cada-10-empresas-

brasileiras-nao-tem-site/>. Acesso em: 18 mar. 2013.

DE CARVALHO, L. G.; MOLINA, M. F. F. Uma Abordagem para o Gerenciamento de Escopo em

Projetos de Desenvolvimento de Software com o Modelo Cascata. PMI São Paulo, Março 2012.

Disponivel em: <http://www.pmisp.org.br/enews/edicao1203/artigo_01.asp>. Acesso em: 06 abr.

2013.

FRIEDMAN, V. 30 Usability Issues To Be Aware Of. Smashing Magazine, 9 Setembro 2007.

Disponivel em: <http://uxdesign.smashingmagazine.com/2007/10/09/30-usability-issues-to-be-aware-

of/>. Acesso em: 29 Abril 2008.

GOOGLE. The 1000 most-visited sites on the web. Google Ad planner, Julho 2011. Disponivel em:

<http://www.google.com/adplanner/static/top1000/>. Acesso em: 28 abr. 2013.

IBGE. Micro e Pequenas Empresas comerciais de serviços no Brasil. Instituto Brasileiro de

Geografia e Estatística, 2001. Disponivel em:

<http://www.ibge.gov.br/home/estatistica/economia/microempresa/microempresa2001.pdf>. Acesso

em: 20 abr. 2013.

MUSEU DO COMPUTADOR. A Internet no Brasil. Museu do Computador, 2004. Disponivel em:

<http://www.museudocomputador.com.br/internet_brasil.php>. Acesso em: 22 Março 2013.

NIELSEN, J. In: ______ Designing Web Usability. [S.l.]: [s.n.], 1999.

OLIVEIRA, N. A história das redes sociais. Natanael Oliveira, 22 Março 2011. Disponivel em:

<http://www.natanaeloliveira.com.br/a-historia-das-redes-sociais/>. Acesso em: 28 Abril 2013.

QUAINO, L. Metade da população brasileira está incluída no mundo digital, diz FGV. G1, 31 Julho

2012. Disponivel em: <http://g1.globo.com/tecnologia/noticia/2012/07/metade-da-populacao-

brasileira-esta-incluida-no-mundo-digital-diz-fgv.html>. Acesso em: 23 Março 2013.

RAGGETT, D. HTML 3.2 Reference Specification. W3C, 14 Janeiro 1997. Disponivel em:

<http://www.w3.org/TR/REC-html32>. Acesso em: 23 mar. 2012.79

RECUERO, R. In: RECUERO, R. Redes Sociais na Internet. Porto Alegre - RS: Editora Meridional,

2009. p. 164-172.

SEBRAE. Informações Socioeconômicas do município de Volta Redonda. Biblioteca Sebrae, 2011.

Disponivel em:

<http://www.biblioteca.sebrae.com.br/bds/bds.nsf/2F7ACF8BFC9C03FD832579A500433611/$File/

Volta%20Redonda.pdf>. Acesso em: 2013.

SECUNIA. Vulnerability Report: WordPress 3.x. Secunia, 2013. Disponivel em:

<http://secunia.com/advisories/product/33191/>. Acesso em: 10 Março 2013.

SHEMA, M. In: SHEMA, M. Web Application Security for Dummies. West Sussex: John Wiley &

Sons, Ltd, 2011. p. 4-5.

SOCIAL BAKERS. TOP Facebook Pages and Industries in Brazil. Social Bakers, Abril 2012.

Disponivel em: <http://www.socialbakers.com/blog/560-april-2012-social-media-report-top-facebook-

pages-and-industries-in-brazil>. Acesso em: 28 Abril 2013.

VALIN, A. A história e a evolução dos navegadores. Tecmundo, 7 Maio 2009. Disponivel em:

<http://www.tecmundo.com.br/web/2063-a-historia-e-a-evolucao-dos-navegadores.htm>. Acesso em:

23 mar. 2013.

W3TECHS. Usage of content management systems for websites. W3Techs, 2013. Disponivel em:

<http://w3techs.com/technologies/overview/content_management/all>. Acesso em: 28 Abril 2013.

WHITEHAT SECURITY. Statistics report summer 2012, 12th edition. How does your website

security stack up against your peers? WhiteHat Security, 2012. Disponivel em:

<https://www.whitehatsec.com/resource/stats.html>. Acesso em: 1 Março 2013.

WIKIPEDIA. Active Server Pages. Wikipedia, 18 Março 2013. Disponivel em:

<http://en.wikipedia.org/wiki/Active_Server_Pages>. Acesso em: 23 Março 2013.

WIKIPEDIA. PHP. Wikipedia, 22 mar. 2013. Disponivel em: <http://en.wikipedia.org/wiki/Php>.

Acesso em: 23 mar. 2013.

80

plano de projeto do desenvolvimento de um sistema de gerenciamento de conteúdo integrado com redes...

Documents