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

(1)

AFONSO FRANÇA DE OLIVEIRA

Plano de Projeto do desenvolvimento de um Sistema de

Gerenciamento 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

(2)

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

(3)

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

(4)

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.

(5)

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.

(6)

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.

(7)

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.

(8)

1

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

(9)

2

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

(10)

3

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

(11)

4

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

(12)

5

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

4.10.8 Outros assuntos relacionados ao gerenciamento de risco do projeto não previstos neste plano ... 69

5. Conclusões ... 70

(13)

6

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.

(14)

7

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.

(15)

8

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,

(16)

9 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

(17)

10 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.

(18)

11 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.

(19)

12 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.

(20)

13

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.

(21)

14

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 reali ar 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 flu o de alteraç o de orçamento descrito abai o. 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

(22)

15  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

(23)

16 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

Afonso França de Oliveira

(24)

17

4.2 DECLARAÇÃO DE ESCOPO

PROJETO MEGA SITE DECLARAÇÃO DE ESCOPO

SCOPE STATEMENT

Preparado por Afonso França de Oliveira – Gerente do Projeto Versão 1.0 Aprovado por Afonso França de Oliveira – Gerente do Projeto 16/01/2013 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;

(25)

18  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.

(26)

19

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;

(27)

20 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

Afonso França de Oliveira

(28)

21

4.3 ESTRUTURA ANALÍTICA DO PROJETO

4.3.1 Visualização Hierárquica

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 3. IMPLEMENTAÇÃO 3.1 Layout do painel administrativo 3.2 Modelagem do banco de dados

3.3 API para modelagem de interface do site 3.4 Layout de exemplo 3.5 Tela de login do usuário 3.6 Tela de gerenciamento de destaques 3.7 Tela de gerenciamento de entidades customizadas 3.8 Tela de gerenciamento de usuários 3.9 Tela de gerenciamento de álbum de fotos 3.10 Tela de gerenciamento de objetos

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

3.12 Botão para Importação de vídeo do Youtube 3.13 Documentar código 2. ANÁLISE E PROJETO DE SOFTWARE 2.4 Configurar ambientes de desenvolvimento 2.1 Diagramas de casos de uso 2.2 Diagramas de sequência 2.3 Diagrama de classes 4. HOMOLOGAÇÃO 4.1 Instalação em cliente piloto 4.2 Teste de aceitação em cliente piloto 4.3 Treinamento do cliente 4.4 Criação de FAQ do usuário 5. ENCERRAMENTO 5.1 Registro de Lições Aprendidas 5.2 Finalização do Projeto PROJETO MEGA SITE

1. GERENCIAMENTO DO PROJETO

1.2 Monitoramento e controle

(29)

22

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.

(30)

23

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 Gerenciamento da Qualidade

3.6 Tela de gerenciamento de destaques

 Montar a tela utilizando a o HTML e CSS do layout do painel administrativo

3.7 Tela de gerenciamento de entidades customizadas

 Montar a tela utilizando a o HTML e CSS do layout do painel administrativo.

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

(31)

24

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

(32)

25

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

(33)

26

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

(34)

27

4.4 PLANO DE GERENCIAMENTO DE ESCOPO

PROJETO MEGA SITE

PLANO DE GERENCIAMENTO DE ESCOPO

SCOPE MANAGEMENT PLAN

Preparado por Afonso França de Oliveira – Gerente do Projeto Versão 1.0 Aprovado por Afonso França de Oliveira – Gerente do Projeto 16/01/2013 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.

(35)

28 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.

INÍCIO Solicitação de mudanças Análise da mudança solicitada Defeito ou melhoria Ignorar Impacto nos custos e ou prazos Prioridade 3 Impacto em

outras áreas Prioridade 2

Áreas afetadas Defeito ou melhoria Impacto nos custos e prazos Impacto na qualidade e riscos

Relatório de Mudanças (Change Request) Melhoria Defeito Baixo Alto Baixo Prioridade 0 Alto

(36)

29 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

(37)

30

4.5 PLANO DE GERENCIAMENTO DE TEMPO

PLANO DE GERENCIAMENTO DE TEMPO

SCHEDULE MANAGEMENT PLAN

Preparado por Afonso França de Oliveira – Gerente do Projeto Versão 1.0 Aprovado por Afonso França de Oliveira – Gerente do Projeto 16/01/2013 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

(38)

31 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.

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

INÍCIO Atualização da Programação Avaliação dos desvios na Programação Impacto no prazo final do projeto Nada a fazer Pode ser remanejado Prioridade 3 Percentual menor 25% Prioridade 2 Prioridade 1 Áreas afetadas Defeito ou melhoria Impacto nos custos e prazos Impacto na qualidade e riscos

Relatório de Mudanças (Change Request) Não Sim Não Sim Não Sim

(39)

32 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

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

 Walter Amorim, membro da equipe de desenvolvimento, será suplente do responsável direto 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, juntamente com os outros planos de gerenciamento de projeto.

4.5.9 Outros assuntos relacionados ao gerenciamento de tempo 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 tempo com o devido registro das alterações efetivadas.

(40)

33 APROVAÇÕES

(41)

34

4.6 PLANO DE GERENCIAMENTO DE CUSTOS

PLANO DE GERENCIAMENTO DE CUSTOS

COST MANAGEMENT PLAN

Preparado por Afonso França de Oliveira – Gerente do Projeto Versão 1.0 Aprovado por Afonso França de Oliveira – Gerente do Projeto 16/01/2013 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.

(42)

35

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.

Contratações R$ 26.000,00 Gerente do Projeto R$ 10.560,00 Programador Sênior R$ 7.040,00 Programador Pleno R$ 4.000,00 Programador Junior R$ 3.120,00 Designer Gráfico R$ 1.280,00 Total de Reservas R$ 4.000,00 Reservas Contigenciais R$ 2.000,00 Outras Reservas R$ 2.000,00 PROJETO MEGA SITE

(43)

36 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

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

 Walter Amorim, membro da equipe de desenvolvimento, será suplente do responsável direto 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, juntamente com os outros planos de gerenciamento de projeto.

4.6.8 Outros assuntos relacionados ao gerenciamento de custos 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 custos com o devido registro das alterações efetivadas.

Data Modificado por Descrição da mudança

APROVAÇÕES

(44)

37

4.7 PLANO DE GERENCIAMENTO DE QUALIDADE

PLANO DE GERENCIAMENTO DE QUALIDADE

SCHEDULE MANAGEMENT PLAN

Preparado por Afonso França de Oliveira – Gerente do Projeto Versão 1.0 Aprovado por Afonso França de Oliveira – Gerente do Projeto 16/01/2013 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

C om ér ci o s R es tau ran te s Mé di cos Igr ej as Event o s T ot 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

(45)

38 5. Site acessível em diversos dispositivos

4.7.4 Priorização das necessidades

Priorização das necessidades Cliente: Comércio U sa bi li d ade R el evâ nci a V el oc idad e C onf ia bi li d ade Port abi li d ade T ot 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 necessidades Cliente: Restaurantes U sa bi li d ade R el evâ nci a V el oc idad e C onf ia bi li d ade Port abi li d ade T ot 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 necessidades Cliente: Médicos U sa bi li d ade R el evâ nci a V el oc idad e C onf ia bi li d ade Port abi li d ade T ot 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%

(46)

39 Priorização das necessidades

Cliente: Igrejas U sa bi li d ade R el evâ nci a V el oc idad e C onf ia bi li d ade Port abi li d ade T ot 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 necessidades Cliente: Eventos U sa bi li d ade R el evâ nci a V el oc idad e C onf ia bi li d ade Port abi li d ade T ot 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

C om ér ci o s R es tau ran te s Mé di cos Igr ej as Event o s T ot 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%