plano de projeto do desenvolvimento de um sistema de gerenciamento de conteúdo integrado com redes...
TRANSCRIPT
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
4.10.8 Outros assuntos relacionados ao gerenciamento de risco do projeto não previstos neste
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
Afonso França de Oliveira
Gerente do ProjetoVersão 1.0
23
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;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
Afonso França de Oliveira
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
Pacote de Trabalho Descrição
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
Pacote de Trabalho Descrição
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
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.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
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
30
Pacote de Trabalho Descrição
3.8 Tela de gerenciamento de usuários
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.9 Tela de gerenciamento de álbum de
fotos
Montar a tela utilizando a o HTML e CSS do layout
do painel administrativo.
Programar lógica de upload de fotos
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.10 Tela de gerenciamento de objetos
Montar a tela utilizando a o HTML e CSS do layout
do painel administrativo.
Programar lógica de exibição dos campos
customizados criados na tela de gerenciamento de
entidades
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
31
Pacote de Trabalho Descrição
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
Pacote de Trabalho Descrição
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
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.
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
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
36
4.5 PLANO DE GERENCIAMENTO DE TEMPO
PROJETO MEGA SITE
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 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
Áreas afetadasDefeito ou melhoriaImpacto nos custos e prazosImpacto na qualidade e riscos
Relatório deMudanças
(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
Responsável pelo plano
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.
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
39
APROVAÇÕES
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
40
4.6 PLANO DE GERENCIAMENTO DE CUSTOS
PROJETO MEGA SITE
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.
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
Responsável pelo plano
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.
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
APROVAÇÕES
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
43
4.7 PLANO DE GERENCIAMENTO DE QUALIDADE
PROJETO MEGA SITE
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
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
1. Administração do site fácil de usar
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.
2. Site relevante na Internet
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.
3. Páginas abertas rapidamente
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.
4. Site seguro e com poucos erros
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.
5. Site acessível em diversos dispositivos
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
1. Administração do site fácil de usar
Atividade: Verificar se os diagramas de sequência atendem à especificação de usabilidade.
2. Site relevante na Internet
Atividade: Durante a criação do layout do Painel Administrativo, verificar se o layout HTML
atende à especificação de SEO (Search Engine Optimization).
3. Páginas abertas rapidamente
Atividade: Durante a criação de todas as telas, verificar se o tempo de carregamento a atende
à especificação de velocidade.
4. Site seguro e com poucos erros
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.
5. Site acessível em diversos dispositivos
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
Áreas afetadasDefeito ou melhoriaImpacto nos custos e prazosImpacto na qualidade e riscos
Relatório deMudanças
(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
Responsável pelo plano
Afonso França de Oliveira, gerente do projeto, será o responsável direto pelo plano de
gerenciamento de qualidade.
49
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 qualidade será reavaliado semanalmente dentro da reunião do CCB,
juntamente com os outros planos de gerenciamento de projeto.
4.7.12 Outros assuntos relacionados ao gerenciamento de qualidade 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. Imediatamente após sua aprovação, deverá ser atualizado o plano de gerenciamento de
qualidade com o devido registro das alterações efetivadas.
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
APROVAÇÕES
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
50
4.8 PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS
PROJETO MEGA SITE
PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS
HUMAN RESOURCES 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.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
Responsável pelo plano
Afonso França de Oliveira, gerente do projeto, será o responsável direto pelo plano de
gerenciamento de recursos humanos.
Walter Amorim, membro da equipe de desenvolvimento, será suplente do responsável direto
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,
juntamente com os outros planos de gerenciamento de projeto.
4.8.11 Outros assuntos relacionados ao gerenciamento de RH 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.
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
APROVAÇÕES
54
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
55
4.9 PLANO DE GERENCIAMENTO DE COMUNICAÇÕES
PROJETO MEGA SITE
PLANO DE GERENCIAMENTO DAS COMUNICAÇÕES
COMMUNICATIONS 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.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.
3. Responsável: Afonso França de Oliveira, gerente do projeto
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
6. Duração: 2 horas
7. Local: Auditório do SESC – Barra Mansa
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.
3. Responsável: Afonso França de Oliveira, gerente do projeto
4. Envolvidos: Gerente de projetos e os integrantes do time do projeto
5. Data e horário: 08/04/2013 às 10h00
6. Duração: 2 horas
7. Local: SESC – Barra Mansa
8. Outros: Ata de reunião
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.
3. Responsável: Afonso França de Oliveira, gerente do 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
6. Duração: 2 horas
7. Local: SESC – Barra Mansa
8. Outros: Ata de reunião
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
5. Data e horário: 08/03/2013 às 10h00
6. Duração: 4 horas
7. Local: Auditório do SESC – Barra Mansa
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. GERENCIAMENTODO PROJETO
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.
Responsável: Afonso França de Oliveira
Á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.
Responsável: Afonso França de Oliveira
Á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.
Responsável: Afonso França de Oliveira
Á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
Responsável pelo plano
Afonso França de Oliveira, gerente do projeto, será o responsável direto pelo plano de
gerenciamento de comunicações.
Walter Amorim, membro da equipe de desenvolvimento, será suplente do responsável direto
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.
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
APROVAÇÕES
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
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
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.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
1. GERENCIAMENTODO PROJETO
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
Áreas afetadasDefeito ou melhoriaImpacto nos custos e prazosImpacto na qualidade e riscos
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
Item Fase Risco Prob. Grav. Resposta Descrição CustoCom o
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á
respondido e verba de
contingência será
utilizada em caso de
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á
respondido e verba de
contingência será
utilizada em caso de
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á
respondido e verba de
contingência será
utilizada em caso de
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
Item Fase Risco Prob. Grav. Resposta Descrição CustoCom o
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
Responsável pelo plano
Afonso França de Oliveira, gerente do projeto, será o responsável direto pelo plano de
gerenciamento de riscos.
Walter Amorim, membro da equipe de desenvolvimento, será suplente do responsável direto
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,
juntamente com os outros planos de gerenciamento de projeto.
4.10.12 Outros assuntos relacionados ao gerenciamento de risco 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 riscos com o devido registro das alterações efetivadas.
72
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
APROVAÇÕES
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
73
4.11 PLANO DE GERENCIAMENTO DE AQUISIÇÕES
PROJETO MEGA SITE
PLANO DE GERENCIAMENTO DE AQUISIÇÕES
PROCUREMENT 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.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
Responsável pelo plano
Afonso França de Oliveira, gerente do projeto, será o responsável direto pelo plano de
gerenciamento de aquisições.
Walter Amorim, membro da equipe de desenvolvimento, será suplente do responsável direto
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,
juntamente com os outros planos de gerenciamento de projeto.
4.10.8 Outros assuntos relacionados ao gerenciamento de risco 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 aquisições com o devido registro das alterações efetivadas.
REGISTRO DE ALTERAÇÕES
Data Modificado por Descrição da mudança
APROVAÇÕES
Admir Pinto de Oliveira
PatrocinadorVersão 1.0
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