Este trabalho apresenta um plano de projeto elaborado com base no PMBOK, o qual será usado como orientaç&a...
AFONSO FRANÇA DE OLIVEIRA
Plano de Projeto do desenvolvimento de um Sistema de Gerenciamento de Conteúdo integrado com redes sociais
Trabalho
apresentado
ao
curso
MBA
em
Gerenciamento de Projetos, Pós-Graduação lato sensu, da Fundação Getúlio Vargas como requisito parcial para a obtenção do Grau de Especialista em Gerenciamento de Projetos.
ORIENTADOR: Prof. André Valle
Volta Redonda - RJ 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 1
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 2
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 3
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 4
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
5
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. 6
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.
7
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,
8
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 9
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.
10
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. 11
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.
12
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.
13
4. PLANO DE PROJETO 4.1 TERMO DE ABERTURA PROJETO MEGA SITE TERMO DE ABERTURA PROJECT CHARTER Preparado por
Afonso França de Oliveira – Gerente do Projeto
Versão 1.0
Aprovado por
Afonso França de Oliveira – Gerente do Projeto
14/01/2013
4.1.1 Título do Projeto Mega Site 4.1.2 Resumo das condições do projeto Histórico: O patrocinador no intuito de iniciar uma startup viu um bom mercado para ser investido, o de sites institucionais, mais especificamente para micro e pequenas empresas do Sul Fluminense. Observa-se que muitos dos sites da região têm qualidade precária e são pouco atualizados devido às dificuldades impostas pelos Sistemas de Gerenciamento de Conteúdo usados. Objetivo do Projeto: Como possível solução para o problema, foi identificada a criação de um Sistema de Gerenciamento de Conteúdo fácil de usar, acessível, customizável e integrado às redes sociais Facebook e Youtube. 4.1.3 Nome do Gerente do Projeto, suas responsabilidades e sua autoridade Como gerente do projeto Mega Site será designado o profissional Afonso França de Oliveira. Sua autoridade
total na esfera deste projeto, podendo reali ar compras, contratações e gerenciar a equipe
do projeto de acordo com seus próprios critérios. No aspecto financeiro, sua atuação dever estar de acordo com o orçamento inicial, sendo que qualquer acréscimo neste orçamento dever seguir o flu o de alteraç o de orçamento descrito abai o. O gerente do projeto será o guardi o do escopo e, portanto, qualquer alteraç o neste quesito ser sua responsabilidade administrar. 4.1.4 Necessidades básicas do trabalho a ser realizado Será necessário que os colaboradores tenham estações de trabalho com os seguintes requisitos de hardware e software: Hardware
Processador: 2GHz ou superior; 14
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 15
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 Projeto
Versão 1.0
16
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; 17
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. 18
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; 19
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
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
Lições aprendidas Registradas
02/04/2013
Projeto Concluído
06/04/2013
Fase de Execução
Fase de Finalização
APROVAÇÕES
Afonso França de Oliveira Gerente do Projeto
Versão 1.0
20
4.3 ESTRUTURA ANALÍTICA DO PROJETO 4.3.1 Visualização Hierárquica PROJETO MEGA SITE
1. GERENCIAMENTO DO PROJETO
2. ANÁLISE E PROJETO DE SOFTWARE
1.2 Monitoramento e controle
3. IMPLEMENTAÇÃO
4. HOMOLOGAÇÃO
5. ENCERRAMENTO
2.1 Diagramas de casos de uso
3.1 Layout do painel administrativo
4.1 Instalação em cliente piloto
5.1 Registro de Lições Aprendidas
2.2 Diagramas de sequência
3.2 Modelagem do banco de dados
4.2 Teste de aceitação em cliente piloto
5.2 Finalização do Projeto
2.3 Diagrama de classes
3.3 API para modelagem de interface do site
4.3 Treinamento do cliente
2.4 Configurar ambientes de desenvolvimento
3.4 Layout de exemplo
4.4 Criação de FAQ do usuário
3.5 Tela de login do usuário
3.6 Tela de gerenciamento de destaques 3.7 Tela de gerenciamento de entidades customizadas 3.8 Tela de gerenciamento de usuários 3.9 Tela de gerenciamento de álbum de fotos
3.10 Tela de gerenciamento de objetos 3.11 Botão para Importação de álbum do Facebook 3.12 Botão para Importação de vídeo do Youtube
3.13 Documentar código
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
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
2.1 Diagramas de casos de uso
UML em um único arquivo gerado pela ferramenta Star UML.
Aprovar diagrama
21
Pacote de Trabalho
Descrição
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
2.2 Diagramas de sequência
arquivo gerado pela ferramenta Star UML.
Verificar se os diagramas atendem à especificação de usabilidade proposta no Plano de Gerenciamento da Qualidade
Aprovar diagrama
Listar todas as entidades do sistema no diagrama de classes. Deverá ser entregue junto com outros
2.3 Diagrama de classes
diagramas da linguagem UML em um único arquivo gerado pela ferramenta Star UML.
2.4 Configurar ambientes de
Aprovar diagrama
Instalar softwares
Desenhar no Photoshop o layout do painel
desenvolvimento 3. IMPLEMENTAÇÃO
administrativo.
3.1 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. 22
Pacote de Trabalho
3.4 Layout de exemplo
Descrição
Desenhar no Photoshop o layout de exemplo de site
Aprovar layout
Montar layout em HTML e CSS
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
3.5 Tela de login do usuário
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
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
3.6 Tela de gerenciamento de
o cumprimento da especificação de confiabilidade
destaques
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
Montar a tela utilizando a o HTML e CSS do layout do painel administrativo.
Programar lógica de criação de novos campos customizados
3.7 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
customizadas
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
23
Pacote de Trabalho
Descrição
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
3.8 Tela de gerenciamento de usuários
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
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
3.9 Tela de gerenciamento de álbum de
de sequência, criando testes de unidade, para garantir
fotos
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
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
3.10 Tela de gerenciamento de objetos
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
24
Pacote de Trabalho
3.11 Botão para Importação de álbum do Facebook
Descrição
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
Criar guia de referência da API para composição de novos temas
3.13 Documentar código
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
Submeter o sistema a um scanner de vulnerabilidades
4. HOMOLOGAÇÃO
para garantir que não existe nenhuma brecha de segurança 4.1 Instalação em cliente piloto
Instalar site no IIS
Configurar domínio
Configurar banco de dados
Configurar Firewall
Homologar junto ao cliente todas as funções do sistema
4.2 Teste de aceitação em cliente piloto
4.3 Treinamento do cliente
Relatar falhas
Corrigir falhas
Aprovar versão final
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 25
Pacote de Trabalho 4.4 Criação de FAQ do usuário
Descrição
Criar documento de respostas para perguntas frequentes do cliente
5. ENCERRAMENTO 5.1 Registro de Lições Aprendidas
5.2 Finalização do Projeto
Criar documentos com aprendizados proporcionados pelo projeto.
Arquivar no Google Drive para futuras referências
Reunir para encerrar formalmente o projeto
APROVAÇÕES
Admir Pinto de Oliveira Patrocinador
Versão 1.0
26
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.
27
INÍCIO
Solicitação de mudanças
Áreas afetadas Defeito ou melhoria Impacto nos custos e prazos Impacto na qualidade e riscos
Análise da mudança solicitada
Defeito ou melhoria
Melhoria
Ignorar
Baixo
Prioridade 3
Baixo
Prioridade 2
Relatório de Mudanças (Change Request)
Defeito
Impacto nos custos e ou prazos
Alto
Impacto em outras áreas
Alto
Prioridade 0
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.
28
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 Patrocinador
Versão 1.0
29
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 30
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
Áreas afetadas Defeito ou melhoria Impacto nos custos e prazos Impacto na qualidade e riscos
Avaliação dos desvios na Programação
Impacto no prazo final do projeto
Não
Nada a fazer
Sim
Prioridade 3
Sim
Prioridade 2
Relatório de Mudanças (Change Request)
Sim
Pode ser remanejado
Não
Percentual menor 25%
Não
Prioridade 1
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
31
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
32
APROVAÇÕES
Admir Pinto de Oliveira Patrocinador
Versão 1.0
33
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.
34
PROJETO MEGA SITE R$ 30.000,00
Contratações R$ 26.000,00
Total de Reservas R$ 4.000,00
Gerente do Projeto R$ 10.560,00
Reservas Contigenciais R$ 2.000,00
Programador Sênior R$ 7.040,00
Outras Reservas R$ 2.000,00
Programador Pleno R$ 4.000,00 Programador Junior R$ 3.120,00 Designer Gráfico R$ 1.280,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:
Gerente do projeto
Reservas de contingência
Outras reservas
Até R$ 100,00
Até R$ 200,00
Até R$ 200,00
Até R$ 400,00
Acima de R$ 200,00 até o
Acima de R$ 400,00 até o
limite das reservas
limite das reservas
isoladamente Gerente do projeto com aval do Patrocinador Somente patrocinador
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. 35
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 Patrocinador
Versão 1.0
36
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)
Médicos
Igrejas
Eventos
Total
Comércios
Restaurantes
Priorização dos clientes
Comércios
4.7.2 Priorização dos clientes
%
5
10
1/5
1/5
15,4
22%
5
1/5
1/10
5,5
8%
1/10
1/10
0,5
1%
1/5
20,2
28%
30,0
42%
Restaurantes
1/5
Médicos
1/10
1/5
Igrejas
5
5
10
Eventos
5
10
10
5
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 37
5. Site acessível em diversos dispositivos
Velocidade
Confiabilidade
Portabilidade
1/5
1
1/5
1
2,4
5%
5
1
10
21,0
48%
1
5
7,2
16%
5
12,0
27%
1,5
3%
1/5
Confiabilidade
5
1
1
Portabilidade
1
1/10
1/5
1/5
Priorização das necessidades Cliente: Restaurantes
1
1/5
1
2,4
5%
10
5
5
25,0
48%
1/5
1/10
1,4
3%
1
11,2
21%
12,2
23%
1/10
Confiabilidade
5
1/5
5
Portabilidade
1
1/5
10
1
Priorização das necessidades Cliente: Médicos
Total
Portabilidade
1
Confiabilidade
Velocidade
Velocidade
5
%
Relevância
Relevância
Usabilidade
Total
1/5
Usabilidade
5
1
1/5
1/5
6,4
15%
5
1/5
1
6,4
15%
1/5
1/5
1,6
4%
1
16,0
38%
12,0
28% 38
Relevância
1/5
Velocidade
1
1/5
Confiabilidade
5
5
5
Portabilidade
5
1
5
1
% Total
Usabilidade
Portabilidade
1
Confiabilidade
Velocidade
Velocidade
5
%
Relevância
Relevância
Usabilidade
Usabilidade
Relevância
Priorização das necessidades Cliente: Comércio
Usabilidade
4.7.4 Priorização das necessidades
Velocidade
Confiabilidade
Portabilidade
Total
1/5
1
5
5
11,2
24%
1
10
5
21,0
44%
5
5
12,0
25%
1
1,5
3%
1,6
3%
1
Confiabilidade
1/5
1/10
1/5
Portabilidade
1/5
1/5
1/5
Usabilidade
Relevância
Priorização das necessidades Cliente: Eventos
1
1
Total
1
%
Portabilidade
Velocidade
Velocidade
5
Usabilidade
Relevância
Confiabilidade
Usabilidade
Relevância
Usabilidade
Priorização das necessidades Cliente: Igrejas
%
5
5
1/5
11,2
21%
5
10
5
21,0
39%
5
1/5
5,6
10%
1/5
0,7
1%
15,2
28%
Relevância
1
Velocidade
1/5
1/5
Confiabilidade
1/5
1/10
1/5
Portabilidade
5
1/5
5
5
Comércios
Restaurantes
Médicos
Igrejas
Eventos
Total
4.7.5 Priorização clientes x necessidades
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%
Priorização clientes x necessidades
39
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.
40
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. 41
INÍCIO
Solicitação de Mudanças
Áreas afetadas Defeito ou melhoria Impacto nos custos e prazos Impacto na qualidade e riscos
Análise da mudança solicitada
Defeito ou melhoria
Melhoria
Ignorar
Baixo
Prioridade 3
Baixo
Prioridade 2
Relatório de Mudanças (Change Request)
Defeito
Impacto nos custos e ou prazos
Alto
Impacto em outras áreas
Alto
Prioridade 1
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.
42
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 Patrocinador
Versão 1.0
43
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 Admir Pinto de Oliveira Patrocinador
Afonso França de Oliveira Gerente de Projeto
Desenvolvimento Equipe: Desenvolvimento
Design Equipe: Design
Analista Programador Sênior Walter Amorim
Designer Gráfico Marlon Mendes
Analista Programador Pleno Rodrigo Rodrigues Analista Programador Junior Renan Borges
4.8.2 Diretório do time do projeto (Team directory) Nº
Nome
1
Área
e-mail
Telefone
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
44
2
Walter Amorim
Desenvolvimento
S
3
Rodrigo Rodrigues
Desenvolvimento
A
4
Renan Borges
Desenvolvimento
5
Marlon Mendes
Design
R- Responsável
A- Apoio
A
A
R
Encerramento
R
Homologação
Gerência Projeto
Documentação
Afonso França de Oliveira
Software
1
Engenharia de
Área
Layout
Nome
de Ambiente
Nº
Configuração
Ger. Projeto
4.8.3 Matriz de responsabilidades
R
S
S
A
A
S
S
R
R
S
A
R
A
S
R
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.
45
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. 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 46
APROVAÇÕES
Admir Pinto de Oliveira Patrocinador
Versão 1.0
47
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 Desenvolvimento 48
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
4.9.4 Estratégia de Gerenciamento de Partes Interessadas Nome
Equipe de Desenvolvimento 49
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, trazendoos 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 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
50
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 projeto 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 51
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 04 11 18 25
04
Março 11 18
25
Abril 01 08
Kick-off Meeting do Projeto Reunião do CCB 1 Reunião do CCB 2 Reunião do CCB 3 Reunião do CCB 4 Reunião do CCB 5 Reunião do CCB 6 Reunião do CCB 7 Reunião do CCB 8 Reunião mensal de avaliação dos planos Reunião mensal de avaliação dos planos Reunião avaliação da equipe Project Close out
4.9.7 Atas de Reunião Todos os eventos do projeto, com exceção do Kick-off meeting e do Project Close-out, deverão apresentar ata de reunião com, no mínimo, os seguintes dados:
Lista de presença 52
Pauta
Decisões tomadas
Pendências não solucionadas
Aprovações
4.9.8 Relatórios do projeto Os principais relatórios a serem publicados no Google Drive são apresentados pelos modelos a seguir. Os modelos têm como objetivo apenas caracterizar o layout do relatório. Os dados neles contidos são apenas ilustrativos. Todos esses relatórios serão gerados diariamente pelos responsáveis e publicados no Google Drive. 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. 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
53
PROJETO MEGA SITE 25%
1. GERENCIAMENTO DO PROJETO
2. ANÁLISE E PROJETO DE SOFTWARE 75%
3. IMPLEMENTAÇÃO 7%
4. HOMOLOGAÇÃO 0%
5. ENCERRAMENTO 0%
2.1 Diagramas de casos de uso 100%
3.1 Layout do painel administrativo 100%
4.1 Instalação em cliente piloto 0%
5.1 Registro de Lições Aprendidas 0%
2.2 Diagramas de sequência 100%
3.2 Modelagem do banco de dados 50%
4.2 Teste de aceitação em cliente piloto 0%
5.2 Finalização do Projeto 0%
2.3 Diagrama de classes 100%
3.3 API para modelagem de interface do site 50%
4.3 Treinamento do cliente 0%
2.4 Configurar ambientes de desenvolvimento 50%
3.4 Layout de exemplo 50%
4.4 Criação de FAQ do usuário 0%
1.2 Monitoramento e controle 100%
3.5 Tela de login do usuário 0%
3.6 Tela de gerenciamento de destaques 0% 3.7 Tela de gerenciamento de entidades customizadas 0% 3.8 Tela de gerenciamento de usuários 0%
3.9 Tela de gerenciamento de álbum de fotos 0% 3.10 Tela de gerenciamento de objetos 0%
3.11 Botão para Importação de álbum do Facebook 0% 3.12 Botão para Importação de vídeo do Youtube 0% 3.13 Documentar código 0%
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
54
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
55
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
56
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:
Usuário logado
Area de exibição dos arquivos
Area de estuturação da base de 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.
57
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 Patrocinador
Versão 1.0
58
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.
59
RISCO TOTAL
RISCOS ACEITOS
RISCOS CONSIDERADOS
Riscos externos imprevisíveis RISCOS TÉCNICOS
RISCOS LEGAL
RISCOS TÉCNICOS
Riscos externos previsíveis Gerenciais
Contratos
Mudanças na tecnologia
Prazos
Reclamações de terceiros
Performance
Custo
Reclamações contra terceiros
Riscos da tecnologia
Fluxo de caixa
Riscos do protótipo / piloto
Complexidade do projeto
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. GERENCIAMENTO DO PROJETO 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. ANÁLISE E PROJETO DE SOFTWARE 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. IMPLEMENTAÇÃO
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 3.4 Facebook e Youtube mudarem suas API's tornando a integração inválida
4. HOMOLOGAÇÃO
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 4.5 Cliente não conseguir usar o software com facilidade
5. ENCERRAMENTO
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 60
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). 61
INÍCIO
Estabelecer sistema de identificação de riscos
Áreas afetadas Defeito ou melhoria Impacto nos custos e prazos Impacto na qualidade e riscos
Atualizar a identificação dos riscos
Atualizar a avaliação dos novos riscos
Atualizar a avaliação dos ricos anteriores
Atualizar estratégias de resposta aos riscos
Rever e atualizar o plano do projeto incorporando estratégias
FIM
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. Com o
Item
Fase
Risco
Prob.
Grav.
Resposta
Descrição
Custo
1.1
Ger. Projeto
Escopo do projeto
Baixa
Alta
Aceitação
O risco não será
-
Agrava
passiva
respondido e verba de
-
Diminui
não retratar a real necessidade do
contingência será
cliente
utilizada em caso de
tempo
necessidade. 1.2
Ger. Projeto
Membros da equipe
Média
Média
Transferência
Inserir cláusula
romperem o
contratual de
contrato e saírem
permanência durante
durante a execução
todo o tempo do
do projeto
projeto, com multa rescisória
62
Com o
Item
Fase
Risco
Prob.
Grav.
Resposta
Descrição
Custo
2.1
Análise
Falta de
Média
Baixa
Aceitação
O risco não será
-
Diminui
passiva
respondido e verba de
-
Agrava
-
Constante
-
Agrava
-
Constante
-
Constante
-
Agrava
experiência na instalação do
contingência será
software pela
utilizada em caso de
equipe, podendo
necessidade.
tempo
atrasar o início da implementação 2.2
Análise
Diagramas não
Média
Média
Atenuação
Validar com o cliente
representarem a
piloto os casos de uso,
realidade de uso do
antes de iniciar a
cliente, causando
implementação
uma implementação ineficiente 3.1
Implementação
Membros da equipe
Baixa
Média
não conhecerem
Aceitação
O risco não será
passiva
respondido e verba de
profundamente a
contingência será
tecnologia utilizada
utilizada em caso de necessidade.
3.2
Implementação
Mudanças bruscas
Média
Alta
Evitar
Utilização de técnicas
na arquitetura do
homologadas do
software, gerando
mercado em padrões
retrabalho e atrasos
de projetos de softwares e frameworks amplamente testados e conhecidos no mercado
3.3
Implementação
Falha na
Alta
Baixa
Atenuação
Realizar reunião
comunicação
online diariamente
remota dos
para feedback e
membros da equipe
sincronização dos trabalhos
3.4
Implementação
Facebook e
Baixa
Baixa
Youtube mudarem
4.1
Homologação
Aceitação
O risco não será
passiva
respondido e verba de
suas API's tornando
contingência será
a integração
utilizada em caso de
inválida
necessidade.
Piloto retratar o
Alta
Alta
Atenuação
Convidar potenciais
cenário de um, mas
clientes de outras
não de todos
áreas para acompanhar
clientes, criando
passivamente o piloto
um produto não vendável
63
Com o
Item
Fase
Risco
Prob.
Grav.
Resposta
Descrição
Custo
4.2
Homologação
Performance do
Média
Média
Evitar
Utilização de técnicas
-
Agrava
-
Agrava
-
Agrava
-
Agrava
software criado não
homologadas do
atingir os padrões
mercado em padrões
necessários para
de projetos de
uma boa
softwares e
usabilidade
frameworks
tempo
amplamente testados e conhecidos no mercado 4.3
Homologação
Layout do site não
Média
Baixa
Evitar
Validar layout com o
agradar o gosto do
cliente antes de fazer a
cliente
implementação propriamente dita
4.4
Homologação
Sistema apresentar
Média
Alta
Atenuar
Programar utilizando
muitos erros,
técnicas de qualidade
requerendo uma
de software como
reprogramação
testes de unidade
extensa 4.5
Homologação
Cliente não
Média
Média
Atenuar
Criar mockups e
conseguir usar o
colher informações de
software com
experiência do usuário
facilidade
com o cliente piloto antes de começar a implementação
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 reservas 64
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. REGISTRO DE ALTERAÇÕES Data
Modificado por
Descrição da mudança
65
APROVAÇÕES
Admir Pinto de Oliveira Patrocinador
Versão 1.0
66
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 email, 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.
A elaboração dos contratos é de responsabilidade do gerente de projeto, sob supervisão de um consultor jurídico da empresa. 67
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.
68
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 Patrocinador
Versão 1.0
69
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.
70
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.
71
6. REFERÊNCIAS BIBLIOGRÁFICAS CETIC.BR.
TIC
-
Domicílios
e
Empresas
2011.
CETIC.br,
2012.
Disponivel
em:
. Acesso em: 18 mar. 2013. COMPUTERWORLD. Internet: quatro em cada 10 empresas brasileiras não têm site. ComputerWorld,
23
Maio
2012.
Disponivel
em:
. 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: . Acesso em: 06 abr. 2013. FRIEDMAN, V. 30 Usability Issues To Be Aware Of. Smashing Magazine, 9 Setembro 2007. Disponivel em: . Acesso em: 29 Abril 2008. GOOGLE. The 1000 most-visited sites on the web. Google Ad planner, Julho 2011. Disponivel em: . 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: Acesso
em: 20 abr. 2013. MUSEU DO COMPUTADOR. A Internet no Brasil. Museu do Computador, 2004. Disponivel em: . 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: . 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:
. Acesso em: 23 Março 2013. RAGGETT, D. HTML 3.2 Reference Specification. W3C, 14 Janeiro 1997. Disponivel em: . Acesso em: 23 mar. 2012. 72
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:
. Acesso em: 2013. SECUNIA.
Vulnerability
Report:
WordPress
3.x.
Secunia,
2013.
Disponivel
em:
. 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: . Acesso em: 28 Abril 2013. VALIN, A. A história e a evolução dos navegadores. Tecmundo, 7 Maio 2009. Disponivel em: . Acesso em: 23 mar. 2013. W3TECHS. Usage of content management systems for websites. W3Techs, 2013. Disponivel em: . 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:
Disponivel
em:
. Acesso em: 1 Março 2013. WIKIPEDIA.
Active
Server
Pages.
Wikipedia,
18
Março
2013.
. Acesso em: 23 Março 2013. WIKIPEDIA. PHP. Wikipedia, 22 mar. 2013. Disponivel em: . Acesso em: 23 mar. 2013.
73
