FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA
CENTRO DE PÓS-GRADUAÇÃO
CURSO DE MBA - GESTÃO DE PROJETOS - 33PMI
Marcos Henrique Pansanato
Plano de Projeto
São Paulo
2008
Marcos Henrique Pansanato
Plano de Projeto
Monografia
de
Conclusão
de
Curso
apresentada como exigência parcial para
obtenção do título de pós-graduação Lato
Sensu em MBA – Gestão de Projetos - PMI
Orientador: Prof.(a) Augusto Camargos
São Paulo
2008
Marcos Henrique Pansanato
Plano de Projeto
Monografia
de
Conclusão
de
Curso
apresentada como exigência parcial para
obtenção do título de pós-graduação Lato
Sensu em MBA – Gestão de Projetos - PMI
Aprovada em 22 de Outubro de 2008
BANCA EXAMINADORA
___________________________________________________________________
Prof.(a) [Titulação e Nome]
Orientador: Mestre Augusto Camargos
Dedico este trabalho a toda minha família pela formação
que me deu até eu chegar aqui e dedico também a minha
noiva pela força que tem me dado.
AGRADECIMENTOS
RESUMO
Este trabalho é composto de um plano de projeto seguindo as melhores práticas do
PMI passando por todas as disciplinas proposta no PMBOK:
Integração;
Escopo;
Prazo;
Custo;
Qualidade;
Comunicação;
Riscos;
RH;
Aquisições.
Artefatos para cada uma das disciplinas fazem parte do plano do projeto, artefatos
que se integram para trabalharem de forma sincronizada visando o sucesso na
execução do projeto.
O projeto consiste na implementação de um sistema bancário, mobile, para que
clientes possam acessar suas contas, verificar saldo e extrato bancário, realizar
pagamentos e transferência, através de aparelhos celulares.
Palavras – chaves:
PMI: Project Management Institute
EAP: Estrutura Analítica do Projeto
RFP: Request for Proposals
DT: Declaração de Trabalho
ABSTRACT
This work is composed of a project plan following the best practices of PMI through
all disciplines proposed in PMBOK:
Integration;
Scope;
Time;
Cost;
Quality;
Communication;
Risk;
HR;
Acquisitions.
Artifacts for each of the disciplines are part of the plan of the project, artifacts that
may be linked to work order Synchro in the successful implementation of the project.
The project is the implementation of a banking system, mobile, so that customers can
access their accounts, check and bank balance, make payments and transfers
through mobile devices.
Key-words:
PMI: Project Management Institute
WBS: Work Breakdown Structure
RFP: Request for Proposals
DT: Statement of Work
Lista de Ilustrações
Ilustração 1: Formulário de requisição de mudança ........................................................ 23
Ilustração 2: Fluxo de requisição de mudanças ............................................................... 24
Ilustração 3: Organograma preliminar do projeto ............................................................. 30
Ilustração 4: EAP ................................................................................................................... 31
Ilustração 5: Dicionário da EAP........................................................................................... 32
Ilustração 6: Lista de atividades .......................................................................................... 36
Ilustração 7: Cronograma com recursos............................................................................ 37
Ilustração 8: Cronograma com custo.................................................................................. 38
Ilustração 9: Curva S............................................................................................................. 40
Ilustração 10: Política de qualidade corporativa ............................................................... 42
Ilustração 11: Política de qualidade da fábrica de software ........................................... 43
Ilustração 12: Modelo do gráfico de pareto ....................................................................... 46
Ilustração 13: Relatório semanal de acompanhamento de correções.......................... 46
Ilustração 14: Matriz dos stakeholders (SAM) .................................................................. 50
Ilustração 15: Matriz de riscos ............................................................................................. 53
Ilustração 16: Organograma do projeto ............................................................................. 56
Ilustração 17: Matriz de responsabilidades no projeto .................................................... 56
Ilustração 18: Ações gerencias ........................................................................................... 64
Ilustração 19: Acompanhamento de mudanças ............................................................... 65
Ilustração 20: Gráfico de controle - Projeto linha de base .............................................. 67
Ilustração 21: Gráfico de controle – Projeto real .............................................................. 68
Ilustração 22: Ishikawa – Análise de causa raiz ............................................................... 68
Ilustração 23: Ações corretivas/preventivas...................................................................... 69
Lista de Tabelas
Tabela 1: Entregas do projeto ............................................................................................. 21
Tabela 2: Cronograma preliminar ....................................................................................... 21
Tabela 3: Partes interessadas preliminar .......................................................................... 21
Tabela 4: Entregas/Faseamento do projeto ...................................................................... 28
Tabela 5: Entrega/Faseamento do produto....................................................................... 29
Tabela 6: Padrões adotados – Gerenciamento do projeto ............................................. 44
Tabela 7: Padrões adotados – Análise, design, implementação e testes.................... 45
Tabela 8: Garantia da qualidade – Matriz de responsabilidades................................... 45
Tabela 9: Ações da garantia da qualidade ........................................................................ 45
Tabela 10: Ações do controle da qualidade ...................................................................... 45
Tabela 11: Plano de comunicação...................................................................................... 48
Tabela 12: Plano de escalonamento .................................................................................. 49
Tabela 13: Matriz de relatórios ............................................................................................ 50
Tabela 14: Matriz de responsabilidades do plano de riscos........................................... 52
SUMÁRIO
RESUMO.....................................................................................................................5
ABSTRACT .................................................................................................................6
LISTA DE ILUSTRAÇÕES ..........................................................................................7
LISTA DE TABELAS ...................................................................................................8
SUMÁRIO....................................................................................................................9
INTRODUÇÃO ..........................................................................................................11
1 INTEGRAÇÃO ......................................................................................................14
1.1 ESTRATÉGIAS ................................................................................................14
1.2 TERMO DE ABERTURA E DECLARAÇÃO PRELIMINAR DE ESCOPO ........16
1.3 CONTROLE INTEGRADO DE MUDANÇAS....................................................21
1.3.1 FORMULÁRIO DE REQUISIÇÃO DE MUDANÇAS.........................................22
1.3.2 FLUXO DE REQUISIÇÃO DE MUDANÇAS.....................................................24
2 GERENCIAMENTO DO ESCOPO........................................................................25
2.1 PLANO DE GERENCIAMENTO DO ESCOPO ................................................25
2.1.1 DEFINIÇÃO DO ESCOPO ...............................................................................25
2.1.2 CONTROLE DO ESCOPO...............................................................................25
2.1.3 MUDANÇA DO ESCOPO.................................................................................25
2.2 DECLARAÇÃO DO ESCOPO ..........................................................................26
2.3 EAP (ESTRUTURA ANALÍTICA DO PROJETO) .............................................30
2.4 DICIONÁRIO DA EAP ......................................................................................31
2.5 PREMISSAS ....................................................................................................32
3 GERENCIAMENTO DO PRAZO...........................................................................33
3.1 PLANO DE GERENCIAMENTO DO PRAZO ...................................................33
3.1.1 DEFINIÇÃO DO CRONOGRAMA ....................................................................33
3.1.2 CONTROLE DO CRONOGRAMA....................................................................33
3.1.3 MUDANÇA DO CRONOGRAMA .....................................................................34
3.2 LISTA DE ATIVIDADES ...................................................................................34
3.3 CRONOGRAMA ...............................................................................................37
3.4 PREMISSAS ....................................................................................................38
4 GERENCIAMENTO DO CUSTO...........................................................................39
4.1 PLANO DE GERENCIAMENTO DO CUSTO...................................................39
4.1.1 DEFINIÇÃO DO CUSTO ..................................................................................39
4.1.2 CONTROLE DO CUSTO..................................................................................39
4.1.3 MUDANÇA DO CUSTO ...................................................................................39
4.2 ESTIMATIVAS..................................................................................................39
4.3 CURVA S .........................................................................................................40
4.4 PREMISSAS ....................................................................................................40
5 GERENCIAMENTO DA QUALIDADE...................................................................42
5.1 PLANO DE GERENCIAMENTO DA QUALIDADE ...........................................42
5.2 GARANTIA DA QUALIDADE ...........................................................................45
5.3 CONTROLE DA QUALIDADE..........................................................................45
5.4 PREMISSAS ....................................................................................................47
6 GERENCIAMENTO DA COMUNICAÇÃO ............................................................48
6.1 PLANO DA COMUNICAÇÃO ...........................................................................48
6.2 PLANO DE ESCALONAMENTO......................................................................49
6.3 MATRIZ DOS STAKEHOLDERS (SAM) ..........................................................49
6.4 MATRIZ DOS RELATÓRIOS (SRM) ................................................................50
6.5 PREMISSAS ....................................................................................................51
7 GERENCIAMENTO DE RISCOS..........................................................................52
7.1 PLANO DE GERENCIAMENTO DE RISCOS ..................................................52
7.2 MATRIZ DE RISCOS – PROBABILIDADE X IMPACTO ..................................52
7.3 PLANO DE RESPOSTAS AOS RISCOS .........................................................53
7.4 PREMISSAS ....................................................................................................54
8 GERENCIAMENTO DE RH ..................................................................................55
8.1 PLANO DE GERENCIAMENTO DE RH...........................................................55
8.2 ORGANOGRAMA ............................................................................................55
8.3 MATRIZ DE RESPONSABILIDADES...............................................................56
8.4 PREMISSAS ....................................................................................................57
9 GERENCIAMENTO DE AQUISIÇÕES .................................................................58
9.1 PLANO DE GERENCIAMENTO DE AQUISIÇÕES..........................................58
9.2 RFP E DT .........................................................................................................58
9.3 PREMISSAS ....................................................................................................63
10 CONTROLE E ACOMPANHAMENTO..................................................................64
10.1 PAINEL DE CONTROLE..................................................................................64
10.2 CONTROLE QUANTITATIVO ..........................................................................65
CONCLUSÃO............................................................................................................70
REFERÊNCIAS.........................................................................................................72
INTRODUÇÃO
Este trabalho representa o plano do projeto Mobile Bank – WAP da empresa TCCMHP. Este plano demonstra um conjunto de conhecimentos em gerenciamento de
projetos incluindo práticas tradicionais comprovadas e amplamente aplicadas, além
de conhecimentos de práticas inovadoras, segundo o PMI.
O projeto Mobile Bank – WAP se trata do desenvolvimento de um aplicativo bancário
pagamento de contas e transferência de valores através de celulares com a
tecnologia WAP. Este aplicativo tem como finalidade proporcionar que os Bancos
possam oferecer aos seus clientes um serviço moderno e inovador, proporcionando
uma facilidade nas transações bancárias e atraindo novos clientes. Já para a
empresa TCC-MHP, este projeto visa colocá-la entre as maiores empresas de TI do
Brasil.
O principal objetivo deste trabalho é fornecer uma visão geral de forma prática, das
disciplinas proposta pelo PMI: Integração, Escopo, Prazo, Custo, Qualidade,
Comunicação, Riscos, RH e Aquisição, demonstrando produtos da gestão de um
projeto.
Artefatos de cada uma das disciplinas irão compor o plano do projeto se integram de
forma que trabalhem sincronizados. Um capítulo será gerado para cada uma das
disciplinas, incluindo um último capítulo de controle e acompanhamento do projeto.
O plano do projeto nasce na elaboração do termo de abertura e declaração
preliminar do escopo, na disciplina de integração, onde é nomeado o gerente do
projeto. Nesta disciplina também será realizado o plano estratégico do projeto,
integrando todas as demais disciplinas. Ainda nesta disciplina será mapeado o
controle de mudanças no projeto.
12
Para gerenciamento do escopo será elaborado o plano de gerenciamento de
escopo, a declaração do escopo, a EAP e o dicionário da EAP visando garantir que
seja feito o que foi desejado.
Em gerenciamento do prazo será realizado o planejamento de gerenciamento do
prazo, a lista de atividades e cronograma com o objetivo de elencar todo trabalho
necessário para a conclusão do projeto e seqüenciá-lo já com previsão de tempo
para cada uma das atividades.
No gerenciamento do custo, está previsto uma estimativa de custo a lista de
atividades prevista para o gerenciamento do prazo. Com base nessas estimativas
será gerada uma curva-s representando o acumulo de gastos previstos no projeto.
Quanto o gerenciamento da qualidade está previsto um plano da qualidade
composto do controle e garantia da qualidade.
A comunicação do projeto estará representada num plano de comunicação, num
plano de escalonamento, numa matriz dos stakeholders e por fim numa matriz de
relatórios.
Os riscos do projeto serão planejados, identificados e mapeados numa matriz de
riscos, representando a probabilidade versus impacto de cada um dos riscos. Para
finalizar um plano de respostas a riscos será construído.
A disciplina de recursos humanos estará mapeada no plano de gerenciamento de
RH, no organograma e na matriz de responsabilidades, neste último artefato citando
as principais atividades de cada um dos envolvidos no projeto.
Subcontratações estão previstas e serão planejadas e geradas numa requisição de
propostas e numa declaração de trabalho.
13
Para garantir que tudo planejado seja executado da forma correta, um painel de
controle do projeto e uma análise quantitativa serão gerados no capítulo de controle
e acompanhamento do projeto.
Ao final deste trabalho teremos uma visão prática das melhores práticas proposta
pelo PMBOK do PMI.
14
1 Integração
Esta disciplina integra todas outras disciplinas de forma que elas se unifiquem e
consolidem com o objetivo de executar e acompanhar o projeto garantindo o
sucesso.
1.1 Estratégias
Este documento tem por objetivo estabelecer a estratégia de condução do
projeto Mobile Bank – WAP passando por todas as disciplinas proposta pelo
PMI no PMBOK.
Reuniões
Deverão ocorrer reuniões periódicas, conforme definido no plano de
comunicação do projeto.
Gerenciamento de Mudanças
Um comitê integrado de mudanças será montado para controle de mudanças.
Vide item 1.3 Comitê Integrado de Mudanças.
Gerenciamento de Versões
O controle de versão do código fonte da aplicação e documentação será de
responsabilidade do gerente do projeto, podendo este delegar este controle a
uma pessoa da equipe. Todos os artefatos deverão estar dentro de uma
ferramenta de controle de versão, com backups semanais.
Requisitos de Aprovação
Todos os produtos do projeto deverão ser aprovados pelo gerente e pelo
sponsor do projeto.
Sistema de Autorização de Trabalho
Os trabalhos serão autorizados pessoalmente ou por e-mail pelo gerente do
projeto.
15
Encerramento do Projeto
O projeto será encerrado quando:
Todos os artefatos estiverem concluídos e aprovados com o termo de
aceite assinado.
Uma reunião de encerramento deve ocorrer para análise final do projeto.
Documentos do Plano
O plano de projeto é composto pelos seguintes documentos:
•
Integração:
Termo de abertura e declaração preliminar de escopo;
Controle integrado de mudanças:
• Comitê integrado de mudanças;
• Formulário de requisição de mudanças;
• Fluxo de requisição de mudança.
•
Escopo:
Plano de gerenciamento de escopo;
Declaração de escopo;
EAP;
Dicionário da EAP.
•
Prazo:
Plano de gerenciamento do tempo;
Lista de atividades;
Cronograma.
•
Custo:
Plano de gerenciamento do custo;
Estimativas;
Curva S.
•
Qualidade:
Plano de gerenciamento da qualidade;
Garantia da qualidade;
Controle da qualidade.
•
Comunicação:
16
Plano da comunicação;
Plano de escalonamento;
Matriz dos stakeholders;
Matriz dos relatórios.
•
Riscos:
Plano de gerenciamento dos riscos;
Matriz de riscos;
Plano de resposta aos riscos.
•
RH:
Plano de gerenciamento de RH;
Organograma;
Matriz de responsabilidades.
•
Aquisições:
Plano de gerenciamento de aquisições;
RFP e DT.
•
Controle/Acompanhamento:
Painel de controle;
Controle quantitativo.
Estes produtos se integrarão uns aos outros com o propósito de desenhar um
plano de ação que visa o sucesso do projeto. Produtos de controle e
acompanhamento do projeto também foram gerados.
1.2 Termo de Abertura e Declaração Preliminar de Escopo
Designação
Marcos Pansanato, você foi designado como Gerente de Projeto do Projeto
Mobile Bank - WAP. Você é responsável por assegurar que os requerimentos
do cliente sejam satisfeitos e que todos os produtos e serviços cotados ou
contratados sejam entregues. Você é responsável pelo sucesso do projeto e
estará trabalhando próximo aos gerentes funcionais apropriados para
assegurar que todos objetivos do projeto sejam atingidos.
17
Responsabilidades
Abaixo seguem as responsabilidades do gerente de projetos:
•
Revisar a documentação formal do projeto e tomar uma decisão para
(Aceitar, Recusar ou Aceitar com condições) a responsabilidade pelo
projeto.
•
Atuar como ponto central de contato para toda comunicação formal
relacionada ao projeto dentro da organização.
•
Assegurar que os membros da equipe do projeto estejam cientes de
suas responsabilidades e também, que todos os compromissos
assumidos pelos indivíduos sejam realizados.
•
Gerenciar os compromissos contratuais para realizá-los em tempo,
dentro do orçamento e com satisfação do cliente.
•
Controlar os custos, cronogramas, orçamentos e variações técnicas
dentro das margens estabelecidas do projeto.
•
Manter toda documentação atualizada nos sistemas, bem como na
base de conhecimento.
•
Seguir todos os processos e padrões metodológicos.
•
Reportar formalmente o status do projeto a gerencia regularmente,
evitando supressas.
Autoridade
Abaixo seguem as autoridades do gerente de projetos:
•
Engajar e substituir o pessoal da equipe de projeto quando necessário
e dirigir as atividades da equipe.
•
Para acessar os Gerentes de Recursos em todos os assuntos relativos
ao projeto.
•
Para controlar o orçamento do projeto.
•
Para dirigir ações de monitoração de atividades referentes a tempo,
custo, risco, performance e qualidade de forma a garantir que todos os
problemas são prontamente identificados, reportados e solucionados.
•
Para contatar através das unidades funcionais e com todos os níveis
de gerencia para realizar os objetivos do projeto.
18
•
Para delegar a responsabilidade e autoridade do projeto dos membros
de sua equipe.
Escopo
Desenvolver um sistema Mobile Bank – WAP para o cliente BANK FIAP.
Os produtos a ser entregues incluem as seguintes funcionalidades:
•
Login
•
Pagamentos
Bloqueto
Concessionária
Recarga Celular
•
Transferências
Transfêrencia
DOC
TED
•
Consultas
Saldo
Extrato
Pagamentos
Transferências
O projeto se restringe a desenvolver a camada de apresentação utilizando a
linguagem de programação Java.
O cliente irá fornecer:
•
Serviços de regra de negócio, na tecnologia Cobol;
•
Um componente de comunicação entre a camada de apresentação
(Java) com a camada de regras de negócio (Cobol);
•
Especificações de comunicação;
•
Requisitos do sistema.
Justificativa do Projeto
O desenvolvimento de um sistema Mobile Bank - WAP tem como finalidade
ao Banco, oferecer aos seus clientes um serviço moderno e inovador,
19
proporcionando uma facilidade nas transações bancárias e atraindo novos
clientes. Já para a empresa TCC-MHP, este projeto visa colocá-la entre as
maiores empresas de TI do Brasil.
Premissas
Técnicas
O desenvolvimento do sistema Mobile Bank será baseado nas metodologias e
modelos do CMMi nível 5 da TCC-MHP.
O cliente irá fornecer:
•
Serviços de regra de negócio, na tecnologia Cobol;
•
Um componente de comunicação entre a camada de apresentação
(Java) com a camada de regras de negócio (Cobol);
•
Especificações de comunicação;
•
Requisitos do sistema.
Organizacionais
Serão utilizados como ponto de partida alguns procedimentos cooperativos
existentes e disponibilizados pelo departamento de engenharia de software.
Ambientais
Variáveis ambientais que impactam o projeto e devem ser acompanhadas.
Não aplicáveis.
Restrições
Técnicas
Por exigência do cliente a equipe deve ser composta por analistas
desenvolvedores certificados na tecnologia Java.
Gerenciais
A data limite para a finalização do projeto é no dia 03/09/2008. O sistema
Mobile Bank – WAP será exibido na semana da tecnologia bancária que se
iniciará no dia 08/09/2008.
Prazos
A data limite para a finalização do projeto é no dia 03/09/2008.
Investimentos
20
Para o desenvolvimento e conclusão do sistema Mobile Bank - WAP será
destinado um investimento em torno de R$ 130.000,00, contando com
R$10.000,00 em equipamentos.
Riscos Preliminares
Serviços de Regras de Negócio (Cobol) fornecido pelo cliente
A falta de consistência nos serviços de regra de negócio (Cobol) e nas
especificações de comunicação (Cobol-Java) fornecido pelo cliente.
Impacto no projeto – Atrasos no período de desenvolvimento.
Compatibilidade com aparelhos reais (celulares)
A falta de padrão de WAP e a grande variedade de aparelhos celulares que é
lançado no mercado.
Impacto no projeto – A inviabilidade do uso do sistema em alguns aparelhos e
o descontentamento dos clientes.
Entregas do projeto
Fase
Produto / Resultados
Termino
(dias)
PACOTE INICIAL
Protótipo, modelo de análise e 50
modelo de design
PACOTE 1
Funcionalidades:
Login;
Pagamentos
(Bloqueto,
Concessionária e Recarga
Desenvolvimento
Celular);
80
e testes
Consultas
(Pagamentos,
Extrato e Saldo);
Casos e evidências de teste
das funcionalidade citada
acima.
PACOTE 2
Funcionalidades:
Transferências
(Transferência,
DOC
e
Desenvolvimento
80
TED);
e testes
Consultas (Transferência);
Casos e evidências de teste
das funcionalidade citadas
acima.
Análise e Design
Custos
(R$)
25.000,00
35.000,00
35.000,00
21
Tabela 1: Entregas do projeto
SET
AGO
JUL
JUN
PACOTE INICIAL
PACOTE 1
PACOTE 2
MAI
1
2
3
ABR
ATIVIDADE
FEV
ITEM
MAR
Cronograma Preliminar
X
X
X
Tabela 2: Cronograma preliminar
Partes Interessadas Preliminar
Stakeholders
Cargo
Empresa
Danúbio Borba
Augusto
Camargos
Marcos
Pansanato
Equipe de Projeto
Diretor
BANK FIAP
Diretor
TCC-MHP
Gerente
Projeto
Variado
Participação
Influencia
Alta
Alta
TCC-MHP
Media
Baixa
X
X
Media
Baixa
X
X
X
X
X
TCC-MHP
Tabela 3: Partes interessadas preliminar
X
1.3 Controle Integrado de Mudanças
Assim que concluído o planejamento do projeto será gerado a linha de base
de escopo, uma linha de base de prazo e uma linha de base de custo que
serão usadas como referência para avaliar mudanças no projeto
O Comitê de Mudanças da Fábrica de Projetos da empresa será o
responsável para controlar as mudanças no projeto, através da linha de base
de escopo. Suas principais atividades são:
•
Identificar mudanças;
•
Revisar e aprovar mudanças solicitadas;
•
Gerenciar mudanças aprovadas, no momento da sua execução;
•
Gerar nova linha de base;
•
Revisar e aprovar ações preventivas e corretivas solicitadas;
22
•
Analisar e controlar impactos, gerando RCM (Relatório de Controle de
Mudanças), em custos, cronogramas, requisitos de qualidade e riscos.
1.3.1 Formulário de Requisição de Mudanças
Toda solicitação de alteração deverá ser requisita ao comitê através do
preenchimento do formulário de requisição de mudanças apresentado abaixo:
Projeto ID:
Baseline Versão:
Título Projeto:
Informações do Projeto:
Mudança #:
Versão:
Data:
Solicitante:
Descrição da Mudança:
Motivo da Mudança:
Impacto no Cronograma:
Milestone/Tarefas
Data Original
Nova Data
Comentário
Impacto no
Custo:
Aprovações:
Função/Cargo
Nome
Iniciais
/Chav
e
Comentário
23
Ilustração 1: Formulário de requisição de mudança
24
1.3.2 Fluxo de Requisição de Mudanças
act Business Process Model
Início
Preencher Formulário de
Requisição de Mudança
(Equipe)
Encamihar Formulário ao
Comitê de Mudanças
(Equipe)
Comitê de Mudanças
Analisa Requisição
(Comitê)
Comitê de Mudanças
mapeia Impactos (Comitê)
Aprova
[Não]
Emite Comunicado de Não
Aprov ação (Comitê)
[Sim]
Emite Comunicado de
Aprov ação (Comitê)
Realiza Replanej amento
j unto do Coordenador do
Proj eto, Salv a Nov a Linha
de Base e Publica (Comitê
e Coordenador)
Elabora RCM e Registra
Mudança no Relátório de
Controle de Mudanças
(Comitê)
Fim
Ilustração 2: Fluxo de requisição de mudanças
25
2 Gerenciamento do Escopo
2.1 Plano de Gerenciamento do Escopo
O plano de gerenciamento do escopo do projeto visa demonstrar os requisitos
que fazem parte do projeto e os requisitos que não fazem parte do projeto. O
objetivo deste plano é garantir que o trabalho proposto seja executado para
proporcionar o sucesso no projeto. Fazem parte deste plano: Definição do
Escopo, Controle do Escopo e Mudança do Escopo.
2.1.1 Definição do Escopo
A definição do escopo deverá fornecer uma visão das necessidades e
características do sistema a serem desenvolvidos pelo projeto. Detalhes do
projeto podem ser verificados nos requisitos funcionais, requisitos não
funcionais e na respectiva lista de requisitos.
Este artefato tratará principalmente da definição do que está e do que não
está incluído no projeto. Seu principal objetivo é de garantir que o resultado do
trabalho do projeto corresponda à entrega do escopo do produto especificado.
Por fim este plano deverá registrar os critérios de aceite do produto terminado.
2.1.2 Controle do Escopo
O controle do escopo será executado em cima da linha de base de escopo
que será salva no final do planejamento e no final de cada replanejamento. A
cada evento inesperado o escopo deve ser verificado para garantir que está
sendo elaborado exatamente o que foi proposto.
2.1.3 Mudança do Escopo
Como mencionado no item de integração, toda mudança de escopo deverá
ser requisitada através do preenchimento de um formulário a ser enviado ao
26
comitê integrado de mudanças. Este comitê tem a responsabilidade de
aprovar a mudança e controlar os impactos.
2.2 Declaração do Escopo
Escopo
Desenvolver um sistema Mobile Bank – WAP para o cliente BANK FIAP.
Os produtos a ser entregues incluem as seguintes funcionalidades:
•
Login: Processo autenticado com usuário e senha.
•
Pagamentos
Bloqueto: Pagamento de Bloquetos através do código de barras;
Concessionária: Pagamento de Concessionária através do código
de barras;
Recarga Celular: Recarregamento de Celular através do código da
operadora e número do aparelho.
•
Transferências
Transfêrencia: Transferência entre contas do mesmo Banco;
DOC: Transferências entre Bancos diferentes e com valor inferior a
R$ 5.000,00;
TED: Transferências entre Bancos diferentes e com valor igual ou
superior a R$ 5.000,00
•
Consultas
Saldo: Consulta de Saldo Bancário;
Extrato: Consulta de Extrato Banário, limitado dos últimos 30 dias;
Pagamentos: Consulta Pagamentos efetuados da Conta informada;
Transferências: Consulta Transferências efetuados da Conta
informada.
•
Manual do Usuário: Passo a Passo de cada funcionalidade.
O projeto se restringe a desenvolver a camada de apresentação utilizando a
linguagem de programação Java.
27
O cliente deverá fornecer:
•
Serviços de regra de negócio, na tecnologia Cobol;
•
Um componente de comunicação entre a camada de apresentação
(Java) com a camada de regras de negócio (Cobol);
•
Especificações de comunicação;
•
Requisitos do sistema.
Itens Excluídos
Funcionalidades
O escopo do projeto se restringe aos requisitos apresentados acima. Não
incluí nenhum tipo de transação bancária de investimentos outro tipo que não
esteja citado no item escopo.
Premissas
Técnicas
O desenvolvimento do sistema Mobile Bank será baseado nas metodologias e
modelos do CMMi nível 5 da TCC-MHP.
O cliente irá fornecer:
•
Serviços de regra de negócio, na tecnologia Cobol;
•
Um componente de comunicação entre a camada de apresentação
(Java) com a camada de regras de negócio (Cobol);
•
Especificações de comunicação;
•
Requisitos do sistema.
Organizacionais
Serão utilizados como ponto de partida alguns procedimentos cooperativos
existentes e disponibilizados pelo departamento de engenharia de software.
Ambientais
Variáveis ambientais que impactam o projeto e devem ser acompanhadas.
Não aplicáveis.
Restrições
Técnicas
28
Por exigência do patrocinador a equipe deve ser composta por analistas
desenvolvedores certificados na tecnologia Java.
Gerenciais
A data limite para a finalização do projeto é no dia 02/09/2008. O sistema
Mobile Bank – WAP será exibido na semana da tecnologia bancária que se
iniciará no dia 10/09/2008.
Riscos
Montagem da Equipe
Ter todos integrantes da equipe disponíveis na empresa e com a capacitação
exigida do patrocinador.
Entregas/Faseamento do Projeto
Fase
Produto / Resultados
Iniciação
Planejamento
Execução
e
Controle
Acompanhamento
Encerramento
e
Plano de Projeto;
Termo de Abertura e Dec. Preliminar de Escopo.
Plano de Gerenciamento de Escopo
o Declaração de Escopo;
o EAP;
o Dicionário da EAP.
Plano de Gerenciamento do Tempo
o Lista de Atividades;
o Cronograma.
Plano de Gerenciamento de Custo
o Curva S.
Plano de Gerenciamento da Qualidade
o Plano de Controle e Garantia da
Qualidade.
Plano de Gerenciamento da Comunicação
o Plano da Comunicação;
o Plano de Escalonamento;
o Matriz dos Stakeholders;
o Matriz dos Relatórios.
Plano de Gerenciamento de Riscos
o Matriz de Riscos e Plano de Respostas.
Plano de Gerenciamento de RH
o Organograma;
o Matriz de Responsabilidades.
Plano de Gerenciamento de Aquisições
o RFP.
Painel de Controle;
Controle Quantitativo.
Termo de Aceite
Tabela 4: Entregas/Faseamento do projeto
29
Entregas/Faseamento do Produto
Fase
Produto / Resultados
Análise e Design
Desenvolvimento
e testes
Desenvolvimento
e testes
Termino Custos
(dias)
(R$)
PACOTE INICIAL
Protótipo, modelo de análise e 50
modelo de design
PACOTE 1
Funcionalidades:
Login;
Pagamentos
(Bloqueto,
Concessionária e Recarga
Celular);
80
Consultas (Pagamentos,
Extrato e Saldo);
Casos e evidências de
teste das funcionalidade
citada acima.
PACOTE 2
Funcionalidades:
Transferências
(Transferência, DOC e
TED);
80
Consultas (Transferência);
Casos e evidências de
teste das funcionalidade
citadas acima.
20.000,00
40.000,00
40.000,00
Tabela 5: Entrega/Faseamento do produto
Detalhes dos Entregáveis do Produto:
•
Pacote Inicial: Corresponde ao Projeto Lógico e Projeto físico do
projeto gerando o protótipo, o modelo de análise e o modelo de design
do aplicativo;
•
Pacote1: Correspondem as seguintes funcionalidades do aplicativo já
concluídas e testadas:
o Login;
o Pagamentos de Bloqueto, Concessionária e Recarga de Celular;
o Consultas de pagamentos, extrato e saldo da conta corrente.
•
Pacote2: Corresponde as seguintes funcionalidades do aplicativo já
concluídas e testadas:
o Transferências de valores, DOCs eletrônicos e TED;
o Consultas de transferências.
30
Organograma Preliminar do Projeto
Patrocinador
Danubio
Borba
Responsável
pelo Projeto
Augusto
Camargos
Gerente de
Projeto
Gerentes
de
Recursos
Marcos
Pansanato
Membros
da
Equipe
Ilustração 3: Organograma preliminar do projeto
Critérios de aceitação
A aceitação do produto será realizada através testes com aparelhos reais
executados num ambiente de desenvolvimento do cliente. O teste será feito
com pelo menos 1 aparelho de cada marca, dentre as principais do mercado.
2.3 EAP (Estrutura Analítica do Projeto)
A EAP abaixo se trata do agrupamento dos elementos do projeto, orientados
para resultados, que organiza e define o completo escopo do projeto. Cada
nível descendente representa uma definição cada vez mais detalhada do
31
trabalho do projeto. O primeiro nível de decomposição da EAP deste projeto
deve conter as fases do projeto e o segundo nível deve conter os produtos do
projeto, ou seja, os pacotes de trabalho.
Ilustração 4: EAP
2.4 Dicionário da EAP
Segue abaixo o dicionário da EAP contem a descrição de todos os pacotes de
trabalho da EAP.
32
Ilustração 5: Dicionário da EAP
2.5 Premissas
Segue(m) abaixo premissa(s) do escopo do projeto:
•
Caso haja qualquer alteração no escopo do projeto, será enviada uma
requisição de mudança ao comitê integrado de mudanças.
•
Após a compreensão integral do escopo, uma nova avaliação de
esforço e duração do projeto deverá ser realizada devido ao nível de
detalhes do escopo fornecido.
33
3 Gerenciamento do Prazo
3.1 Plano de Gerenciamento do Prazo
O plano do prazo do projeto visa planejar e controlar a lista de atividades
realizando estimativas e acompanhamento de tempo, esforço e prazo de cada
atividade. A lista de atividades e as estimativas devem ser compiladas num
cronograma, representando a evolução do projeto seguindo a linha do tempo.
Este plano se divide em Definição do Cronograma, Controle do Cronograma e
Mudança do Cronograma.
3.1.1 Definição do Cronograma
O cronograma contempla o seqüenciamento das atividades, a estimativa de
duração e de recursos de cada atividade, e por fim demonstra uma visão do
diagrama de rede do projeto. A construção do cronograma deverá seguir a
estrutura da EAP e as atividades da lista de atividades.
3.1.2 Controle do Cronograma
Após conclusão do planejamento do prazo, será gerada uma linha de base do
tempo.
Semanalmente o andamento das atividades e os prazos do projeto serão
controlados. O percentual de conclusão de cada atividade será coletado junto
a equipe e lançado no cronograma (MS Project). Um relatório será gerado
através da função “Analisar dados de escala do tempo no Excel” da
ferramenta, onde apontará a quantidade de horas acumulada do projeto
perante o percentual de conclusão, através de uma curva “S”. Com este
relatório será analisado o andamento do projeto, comparando com alinha de
base do tempo e caso necessário, uma solicitação de alteração de prazo será
34
enviada ao Comitê de Mudanças do projeto. O gerente do projeto fica
responsável pelas renegociações de prazos junto à sponsor do projeto.
3.1.3 Mudança do Cronograma
Qualquer alteração no cronograma que impacte no prazo de algum entregável
e até mesmo na data final de conclusão do projeto, deverá ser solicitada
autorização ao comitê integrado de mudanças para o mesmo aprovar efetuar
a atualização da linha de base de prazo.
3.2 Lista de Atividades
A lista de atividades identifica e elenca todas as atividades necessárias para
completar todo trabalho do projeto, bem como uma estimativa de tempo e de
recurso necessário.
35
36
Ilustração 6: Lista de atividades
37
3.3 Cronograma
O cronograma contempla o seqüenciamento das atividades, a estimativa de duração
e de recursos de cada atividade, e por fim demonstra uma visão do diagrama de
rede do projeto.
Ilustração 7: Cronograma com recursos
38
Ilustração 8: Cronograma com custo
3.4 Premissas
Segue(m) abaixo premissa(s) do gerenciamento tempo do projeto:
•
Caso haja qualquer alteração no prazo do projeto, deverá ser
requisitada a aprovação ao comitê integrado de mudanças;
•
Após a compreensão integral do escopo, uma nova avaliação do
cronograma deverá ser feita devido ao nível de detalhes do escopo
fornecido.
39
4 Gerenciamento do Custo
4.1 Plano de Gerenciamento do Custo
O plano de gerenciamento de custo visa levantar as estimativas de custos e
acompanhar os gastos do projeto. Compõe este plano a Definição do Custo, o
Controle do Custo e Mudança de Custo.
4.1.1 Definição do Custo
A definição do custo será realizada na estimativa de custo levantada na lista
de atividades do projeto. Esta estimativa será consolidada dentro do
cronograma do projeto.
4.1.2 Controle do Custo
Após conclusão do planejamento do custo, será gerada uma linha de base de
custo.
Semanalmente os custos do projeto serão controlados através da análise da
curva “S”, comparando com a linha de base de custo. Qualquer desvio de
custo identificado será enviada uma solicitação de mudança ao Comitê de
Mudanças.
4.1.3 Mudança do Custo
Qualquer alteração no custo deverá ser solicitada autorização ao comitê
integrado de mudanças para o mesmo ao aprovar e efetuar a atualização da
linha de base de custo.
4.2 Estimativas
40
A estimativa de custo do projeto está representada na lista de atividades
criada no gerenciamento do tempo. Vide lista de atividades com estimativa de
custo no capítulo anterior. A estimativa deve ser realizada por atividade.
4.3 Curva S
O resultado da acumulação das distribuições percentuais, parciais e totais de
custo será representa através da curva “S”. Por conseguinte, a curva “S” será
extraída do cronograma (MS Project) através da funcionalidade de “Analisar
dados de escala de tempo no Excel”.
3.500,00h
R$ 140.000,00
3.000,00h
R$ 120.000,00
2.500,00h
R$ 100.000,00
2.000,00h
R$ 80.000,00
1.500,00h
R$ 60.000,00
1.000,00h
R$ 40.000,00
500,00h
R$ 20.000,00
C u sto
T rab alh o
Curva - S (Trabalho / Custo)
Total Trabalho acumulado
Total Custo acumulado
R$ 0,00
27
/1
1 0 /20
/2 0
2 4 /20 8
/2 0 8
/
9 / 20 0
3
2 3 /2 0 8
/3 0 8
/
6 / 20 0
4/ 8
20 20
/4 0 8
/
4 / 20 0
5/ 8
18 20
/5 0 8
/
1 / 20 0
6/ 8
15 20
/6 0
2 9 /20 8
/6 0
1 3 /20 8
/7 0
2 7 /20 8
/7 0 8
1 0 /20
/8 0
2 4 /20 8
/8 0 8
/2
00
8
0,00h
Semanas
Ilustração 9: Curva S
4.4 Premissas
Segue(m) abaixo premissa(s) do custo do projeto:
•
Caso haja qualquer alteração no custo do projeto deverá ser solicitada
aprovação ao comitê integrado de mudanças.
41
•
Após a compreensão integral do escopo, uma nova avaliação do custo
deverá ser feita devido ao nível de detalhes do escopo fornecido.
42
5 Gerenciamento da Qualidade
5.1 Plano de Gerenciamento da Qualidade
Política de qualidade corporativa
Ilustração 10: Política de qualidade corporativa
Interessada em produzir qualidade a TCC–MHP certificou pela ISO 9001 em
Janeiro de 2007.
Para ser líder é preciso chegar sempre à frente, por isso a TCC-MHP é
reconhecida no mercado de TI e ocupa uma posição de destaque entre os
líderes do segmento.
O crescimento é conseqüência da visão de futuro e um objetivo que faz parte
constante de nossos planejamentos.
Hoje a empresa segue as normas da ISO 9001, versão 2000.
Compromissos da empresa:
o Constância de propósitos;
o Compromisso com a qualidade;
o Envolvimento e foco no cliente;
o Orientado a processos;
o Melhoria contínua;
o Sistema centrado em gerenciamento;
o Investimento em conhecimento;
o Trabalho em equipe;
43
o Manutenção das pessoas
o Envolvimento total;
o Compromisso de longevidade.
Política de qualidade da fábrica de software
Ilustração 11: Política de qualidade da fábrica de software
Interessada em seguir um modelo de referência que contém práticas
(Genéricas ou Específicas) necessárias à maturidade em disciplinas
específicas a TCC-MHP se certificou em CMMI nível 5 em Janeiro de 2008 e
segue por sua vez 22 processos bem definidos:
o Análise Causal e Resolução;
o Gerência de Configuração;
o Análise de Decisão e Resolução;
o Gerenciamento Integrado de Projeto;
o Medição e Análise;
o Inovação Organizacional e Deployment;
o Definição de Processo Organizacional;
o Foco de Processo Organizacional;
o Desempenho de Processo Organizacional;
o Treinamento Organizacional;
o Monitoração e Controle de Projeto;
o Planejamento de Projeto;
o Garantia da Qualidade de Processo e Produto;
o Integração de Produto;
o Gerenciamento Quantitativo de Projeto;
44
o Gerenciamento de Requisitos;
o Desenvolvimento de Requisitos;
o Gerenciamento de Riscos;
o Gerenciamento de Acordo com Fornecedor;
o Solução Técnica;
o Validação;
o Verificação.
Critérios e Tolerâncias
Todos os requisitos de qualidade, demonstrados acima devem estar 100%
aderentes.
Padrões adotados para o projeto
Gerenciamento do Projeto:
Tipo de Aspectos Funcionais
Requisito
Requisito O gerenciamento de projetos deve seguir as melhores práticas
propostas pelo PMI no PMBOK.
Métricas Percentual de aderência aos processos;
de
qualidade
Critério de Atingir mais de 80% de aderência.
Aceitação
Método de Auditorias internas.
Verificação
Lista de Baseada nas disciplinas do PMBOK.
Verificação
da
Qualidade
Tabela 6: Padrões adotados – Gerenciamento do projeto
Análise, Design, Implementação e Testes:
Tipo de Aspectos Funcionais
Requisito
Requisito As fases do ciclo de vida, proposto pelo RUP, deverão seguir
os processos proposto pelo CMMI.
Métricas Percentual de aderência aos processos;
de
qualidade
Critério de Atingir mais de 90% de aderência.
Aceitação
Método de Auditorias internas.
Verificação
Lista de Baseada nos processos desenhados para cada fase.
45
Verificação
da
Qualidade
Tabela 7: Padrões adotados – Análise, design, implementação e testes
5.2 Garantia da Qualidade
Matriz de Responsabilidades
Função
Diretor – Sponsor
Diretor
Gerente de Projeto
Àrea de qualidade
Area Jurídica
Nome
Danúbio Boroba
Responsabilidade
Patrocinar o custo do projeto e
tomar decisões em tempo hábil.
Augusto Camargos Supervisionar que a qualidade
está sendo atendida.
Marcos Pansanato Garantir que as listas de
verificação estão sendo
executadas.
SEPG
Realizar as verificações de PMI,
CMMI e ISO
Advogado principal Realizar a verificação do contrato
de subcontratação.
Tabela 8: Garantia da qualidade – Matriz de responsabilidades
Ações da Garantia
Ação
Periodicidade
Executar
auditorias Semanalmente
internas CMMI.
Executar
auditorias Mensalmente
internas ISO.
Responsável Impacto
SEPG
Processos de
engenharia de
software.
SEPG
Processos
administrativos.
Tabela 9: Ações da garantia da qualidade
5.3 Controle da Qualidade
Ações do Controle
Ação
Executar as listas de
verificação de código
fonte.
Executar verificações
dos processos PMI.
Acompanhamento
jurídico do andamento
do
contrato
de
subcontratação.
Periodicidade Responsável
Impacto
No final de cada Marcos Pansanato Código fonte
funcionalidade
do aplicativo.
Quinzenalmente SEPG
Processos de
gestão.
Quinzenalmente Advogado principal Contrato.
Tabela 10: Ações do controle da qualidade
46
Controlar a implementação das correções indicadas pelas inspeções
realizadas dentro do prazo pré-estabelecido;
Gerar semanalmente o diagrama de pareto indicando os principais problemas
encontrados – Toda Sexta-Feira;
Modelo do gráfico Pareto:
Ilustração 12: Modelo do gráfico de pareto
Gerar semanalmente o relatório de acompanhamento das correções – Toda
sexta-feira.
Ilustração 13: Relatório semanal de acompanhamento de correções
47
5.4 Premissas
Segue(m) abaixo premissa(s) do gerenciamento da Qualidade:
•
Todos os requisitos de qualidade, demonstrados acima devem estar
100% aderentes.
48
6 Gerenciamento da Comunicação
6.1 Plano da Comunicação
O plano de comunicação fornece as ligações críticas entre pessoas e
informações que são necessárias para garantir a geração, coleta, distribuição,
armazenamento, recuperação e destinação final das informações sobre o
projeto de forma oportuna e adequada.
Foco
Kick off
Forma de
Quando
Comunicar
Reunião
Emissor
Início do Projeto Gerente do Projeto
Presencial
Receptor
Stakeholders
(Marcos)
Reunião
Status do
Presencial
Quinzenal
Projeto
E-mail
Gerente do Projeto
Stakeholders
(Marcos)
Dúvidas
Técnicas Processos e
Infra-
E-mail
Conforme
Telefone
Necessário
Equipe do Projeto
Equipe Técnica do
Cliente
Estrutura
Acompanha
mento
Interno
Validação
Reunião
Semanal
Presencial
E-mail
Gerente do Projeto
(Marcos)
Após entregas
Termo de Aceite
dos Produtos
Equipe do Projeto
Gerente do Projeto
Gerente do Projeto
(Marcos)
Tabela 11: Plano de comunicação
do lado Cliente
49
6.2 Plano de Escalonamento
O plano de escalonamento representa a hierarquia e o tempo onde um evento
crítico deve ser escalonado com a intenção que seja solucionada evitando
maiores impactos no projeto.
Severidade
Alta
Descrição
Forma
Afeta o Prazo final do
Telefone
Projeto
Conference
Afeta somente o Prazo
Média
de alguma fase do
Projeto
Afeta somente alguma
Baixa
atividade de uma fase do
Projeto
Reuniões/
E-mails
Tempo
3 dias
Responsável
Diretor
(Danúbio Borba)
Diretor
2 dias
(Augusto
Camargos)
Gerente do
Reuniões
E-mails
1 dia
Projeto
(Marcos
Pansanato)
Tabela 12: Plano de escalonamento
6.3 Matriz dos Stakeholders (SAM)
A matriz dos stakeholders mapeará os stakeholders através das categorias:
o A – Elevado interesse/ importância, Elevada influência
Estes stakeholders são à base de uma coligação de suporte efetiva do
projeto.
o B – Elevado interesse/ importância, Baixa influência
Estes stakeholders necessitarão de iniciativas especiais para os seus
interesses serem protegidos.
C – Baixo interesse/ importância, Elevada influência
Estes stakeholders podem influenciar os resultados do projeto, mas as
suas prioridades não são as do projeto. Podem ser um risco ou
obstáculo ao projeto.
o D – Baixo interesse/ importância, Baixa influência
Estes stakeholders têm menor importância para o projeto.
50
Ilustração 14: Matriz dos stakeholders (SAM)
6.4 Matriz dos Relatórios (SRM)
A Matriz de relatórios do projeto é apresentada através da seguinte tabela:
Emissor
Relatório
Period.
Formato
Marcos
Pansanato
Status Report
Quinzenal
Slides
(PPT)
Marcos
Pansanato
Diário de Bordo
Semanal
Planilha
(XLS)
Marcos
Pansanato
Marcos
Pansanato
Marcos
Pansanato
Marcos
Pansanato
Receptor
Augusto
Camargos /
Danúbio Borba
Augusto
Carmargos /
Equipe do Projeto
Acompanhamento de
Prazo – Curva S
Project
Augusto
Project: “Analise dados Quinzenal (expotado
Camargos
de escala do tempo no
para XLS)
Excel”
Acompanhamento de
Custo – Curva S
Project
Augusto
Project: “Analise dados Quinzenal (expotado
Camargos
de escala do tempo no
para XLS)
Excel”
Diagrama de pareto
indicando os principais
Planilha
Augusto
problemas
Semanal
(XLS)
Camargos / SEPG
encontrados de
qualidade.
Relatório de acomp.
Planilha
Augusto
das correções de
Semanal
(XLS)
Camargos / SEPG
problemas
Tabela 13: Matriz de relatórios
Canal
E-mail
E-mail
E-mail
E-mail
E-mail
E-mail
51
6.5 Premissas
Segue(m) abaixo premissa(s) do gerenciamento de comunicação:
•
Semanalmente a eficiência da comunicação do projeto será analisada
e ajustada caso necessário.
52
7 Gerenciamento de Riscos
7.1 Plano de Gerenciamento de Riscos
O objetivo do plano de gerenciamento de riscos é aumentar a probabilidade e
impacto dos eventos positivos e diminuir a probabilidade e impacto dos
eventos negativos do projeto.
Método de Identificação de Riscos
Os riscos serão identificados através de uma análise das premissas e
restrições do projeto. Possíveis eventos que podem impactar em escopo,
prazo e custo devem ser identificados e acompanhados.
Freqüência de Monitoramento dos Riscos
Semanalmente os riscos do projeto serão acompanhados. Novos riscos
poderão ser identificados e os já existentes serão analisados e/ou
mitigado/contigenciado/eliminado.
Matriz de Responsabilidades do Plano de Riscos
Identificação de Riscos
Equipe do Projeto
Análise Quantitativa/Qualitativa
Gerente do Projeto
Resposta a riscos
Equipe
do
Projeto/Gerente
do
Projeto
Controle e Monitoramento a Riscos
Gerente do Projeto
Tabela 14: Matriz de responsabilidades do plano de riscos
7.2 Matriz de Riscos – Probabilidade X Impacto
A matriz de riscos tem a função de quantificar as probabilidades de cada
evento de risco e o seu impacto no projeto. Cada risco é priorizado de acordo
com a probabilidade e impacto.
Critério de Probabilidade:
53
o De 1 a 3: Provavelmente não ocorra, mas é necessário
monitorar.
o De 4 a 6: Tem probabilidade de ocorrer;
o De 7 a 10: Bem provável que ocorra.
Critério de Impacto:
o De 1 a 3: Impacto insignificante no projeto;
o De 4 a 6: Impacto mensurável no projeto;
o De 7 a 10: Impacto significativo no projeto.
Critério da Avaliação:
o De 1 a 10: Severidade baixa;
o De 11 a 40: Severidade média;
o De 41 a 100: Severidade alta.
A avaliação representa a severidade do risco e é calculada da multiplicação
da probabilidade pelo impacto.
Ilustração 15: Matriz de riscos
7.3 Plano de Respostas aos Riscos
O plano de respostas ao risco está contido na mesma matriz de riscos, vide
item anterior, e representa a ação em cima de cada risco:
o Mitigar;
o Contingência;
54
o Follow-Up.
A matriz também representa o Status do risco:
o Identificado;
o Mitigado;
o Contigenciado;
o Eliminado.
7.4 Premissas
Segue(m) abaixo premissa(s) do gerenciamento de risco do projeto:
• Após a compreensão integral do escopo, uma nova avaliação dos riscos
deverá ser feita devido ao nível de detalhes do escopo fornecido.
• Semanalmente os riscos do projeto serão acompanhados. Novos riscos
poderão ser identificados e os já existentes serão analisados e/ou
mitigado/contigenciado/eliminado.
55
8 Gerenciamento de RH
8.1 Plano de Gerenciamento de RH
A equipe do projeto será montada com recursos da empresa, não havendo
necessidade de envolver a área de RH da empresa em novas contratações.
Alocações
As alocações dos recursos devem ocorrer 10 dias antes do início do projeto.
Perfil
O perfil dos recursos deve ser avaliado através de uma avaliação de
conhecimento técnico.
Decisão de Treinamento
Caso não seja montada a equipe por falta de perfil, deverá ser aplicado
treinamento as pessoas selecionadas e reprovadas na avaliação técnica.
Monitoramento do Recurso
Quinzenalmente os recursos devem ser avaliados para verificar o andamento
de suas atividades e sua motivação no projeto.
8.2 Organograma
O organograma é usado para mostrar posições e relacionamentos em um
formato gráfico de cima para baixo. A aparência do organograma é
semelhante com a da EAP, mas em vez de ser organizado de acordo com a
decomposição de entregas do projeto, ele é organizado de acordo com os
níveis hierárquicos, representa a equipe do projeto.
56
Ilustração 16: Organograma do projeto
8.3 Matriz de Responsabilidades
A matriz de rastreabilidade tem o objetivo de delimitar e demonstrar as
responsabilidades das pessoas envolvidas no projeto. Esta matriz está
contida no mesmo artefato do organograma, vide item anterior.
Ilustração 17: Matriz de responsabilidades no projeto
57
8.4 Premissas
Segue(m) abaixo premissa(s) do gerenciamento de RH:
•
Durante todo o projeto deve ser feito o acompanhamento motivacional
da equipe.
58
9 Gerenciamento de Aquisições
9.1 Plano de Gerenciamento de Aquisições
A construção do módulo de Login será subcontratada.
Motivo da Subcontratação:
o Falta de conhecimento na equipe interna na tecnologia JAAS
(Java).
Forma de Subcontratação:
o Uma RFP (Request for proposals) será elaborada para a seleção
do fornecedor;
Critérios de seleção do fornecedor:
o Cumprimento de todos os requisitos e restrições com o menor
valor, estipulado na forma de “Pacote Fechado”.
Administração do Contrato:
o O contrato será adminstrado pela área jurídica da TCC-MHP.
Penalidades:
o O não cumprimento integral do contrato implica em multa para a
contratada.
9.2 RFP e DT
A RFP (request for proposals) é o documento de aquisição onde descreve a
necessidade de contratação.
A RFP irá contemplar a DT (declaração de trabalho), base para a elaboração
do contrato a ser assinado.
59
RFP
Conceitos
RFP. Segundo
http://www.investorwords.com/cgi-
bin/getword.cgi?4277, Request For Proposal is an invitation for
providers of a product or service to bid on the right to supply that
product or service to the individual or entity that issued the RFP.
SLA. Service Level Agreement é um contrato entre fornecedor e
contratante que especifica, em métricas, como o serviço deverá
ser prestado. Entende-se por métrica de SLA, por exemplo:
acuracidade de estimativa de prazos; tempo e qualidade de
resposta ao atendimento a solicitações do cliente; número de
atendimentos simultâneos; penalidade para o caso de atrasos
no cumprimento de prazos.
Requisitos
Os requisitos deste sistema, objeto desta RFP, se restringem a construção
do módulo de login da aplicação Móbile Bank - WAP.
Requisitos do Fornecedor
1. Apresentação da TCC-MHP: funcionamento (métricas, precificação,
etc), nível de atendimento (artefatos, processo, equipe, etc),
avaliação do processo (padrões de qualidade, padrões de
codificação, padrões de acuracidade, etc);
2. O processo de desenvolvimento da fábrica a ser contrata deve levar
em consideração que os indivíduos que fazem parte do mesmo,
podem estar localizados em diferentes localidades. Isso pode
dificultar ou mesmo impossibilitar a realização de reuniões
presenciais.
3. A fábrica deve adotar um modelo de desenvolvimento de software
baseado no CMMi nível 3.
4. O processo de desenvolvimento da fábrica deve apresentar:
a. Políticas
que
normatizem
o
acesso
aos
artefatos
produzidos pela fábrica pelas instituições colaboradoras;
b. Políticas de validação e aceitação de artefatos submetidos
pelas instituições colaboradoras;
60
c. Mecanismos que estimulem a participação das instituições
colaboradoras.
5. A fábrica deve contar com profissionais experientes na tecnologia
JAAS (Java).
Requisitos do Sistema
1. O sistema deve ser desenvolvido em Java e em uma arquitetura em
camadas e fornecida pela TCC-MHP. Está arquitetura está
preparada para funcionamento da aplicação em aparelhos móveis
do tipo WAP;
2. Junto da arquitetura, também será fornecido pela TCC-MHP o
protótipo, modelo de análise e modelo de design do Módulo de
Login, a ser desenvolvido;
3. Mecanismos de login a serem implementados:
- Autenticação: Verificação de que o cliente é realmente
quem ele diz ser;
• Passos:
1. O cliente instancia um novo contexto de login.
Esta é uma classe fornecida pelo container.
Ela é responsável por coordenar o processo
de login.
2. O contexto de login instancia um novo objeto
Configuration, que deve ser escrito pelo
desenvolvedor. Esse objeto sabe o tipo de
autenticação que o sistema irá usar.
3. O
contexto
de
login
pede
ao
objeto
Configuration a lista de mecanismos de
autenticação que serão utilizados.
4. O objeto Configuration retorna uma lista de
mecanismos
de
autenticação.
Cada
um
desses é chamado de módulo de login
(LoginModule). Um módulo de login sabe
como contactar um provedor de segurança
específico e autenticar de uma maneira
proprietária.
61
5. O contexto de login instancia os módulos de
login. Podese ter muitos módulos de login se
for necessário fazer autenticação através de
vários provedores de segurança.
6. O contexto de login inicializa os módulos de
login.
7. O código cliente tenta logar chamando o
método login() no contexto de segurança.
8. O contexto de segurança delega a chamada
ao método login() aos módulos de login, já
que somente os módulos de login sabem
como executar a autenticação.
9. Os
módulos
de
login
(escritos
pelo
desenvolvedor) autenticam o usuário usando
um modo proprietário.
10. Se o login for feito com sucesso, então é
indicado aos módulos de login que eles
devem fazer o commit (commit()). Eles
também
podem
abortar
(abort())
se
a
autenticação falhar.
11. Um novo objeto Subject é retornado para o
código cliente. Esse objeto Subject representa
alguém (ou algo) que foi autenticado. Esse
objeto
pode
ser
usado
para
executar
operações seguras.
12. O código cliente instancia um novo objeto
Action. Esse objeto é uma instância de uma
classe escrita pelo desenvolvedor. Esse
objeto sabe como executar uma operação
que deve ser executada de forma segura.
13. O desenvolvedor diz ao objeto Subject para
fazer (do) a ação como (as) o objeto Subject,
por isso o nome doAs() do método.
62
14. O objeto Subject chama o método run() do
objeto Action.
15. O objeto Action executa a sua operação e o
contexto de segurança do usuário logado é
automáticamente propagado junto com a
chamada
do
método.
Isso
completa
a
autenticação. Já que o contexto de segurança
é passado para o servidor, o servidor pode
agora executar o processo de autorização.
- Autorização: Verificação de que um cliente previamente
autenticado tem permissão para executar uma operação
desejada. Para este caso será adota a autorização do tipo
programada.
• Passos:
1. Escrever a lógica de segurança.
2. Declarar os papéis de segurança abstratos
que o bean usa.
3. Mapear papéis abstratos para papéis reais.
Sistema
Segue abaixo o escopo completo da aplicação Mobile Bank – WAP:
•
Login: Processo autenticado com usuário e senha. Objeto desta
RFP.
•
Pagamentos
Bloqueto: Pagamento de Bloquetos através do código de barras;
Concessionária: Pagamento de Concessionária através do
código de barras;
Recarga Celular: Recarregamento de Celular através do código
da operadora e número do aparelho.
•
Transferências
Transfêrencia: Transferência entre contas do mesmo Banco;
DOC: Transferências entre Bancos diferentes e com valor
inferior a
R$ 5.000,00;
TED: Transferências entre Bancos diferentes e com valor igual
ou superior à R$ 5.000,00
63
•
Consultas
Saldo: Consulta de Saldo Bancário;
Extrato: Consulta de Extrato Bancário, limitado dos últimos 30
dias;
Pagamentos:
Consulta
Pagamentos
efetuados
da
Conta
informada;
Transferências: Consulta Transferências efetuados da Conta
informada.
Prazos e Condições
•
Prazo: A empresa a ser contrata deverá desenvolver o módulo de
login em 5 dias úteis, concluindo até o dia 04 de abril de 2008;
•
Condições: Caso haja estouro de prazo na conclusão e entrega do
módulo de login, será cobrada uma multa de 50% do valor a ser
fechado mais 10% por dia de atraso.
Premissas e Restrições
•
Premissas: Vide item 2.2 Requisitos do fornecedor;
•
Restrição: Concluir a demanda até o dia 04 de abril de 2008.
Critérios de Avaliação da RFP
A empresa concorrente terá enviar resposta à RFP estão dando um
acordo
nos
requisitos
e
condições
impostas,
principalmente
no
cumprimento do prazo, e fornecer o valor a ser cobrado na forma de
Pacote Fechado.
9.3 Premissas
Segue(m) abaixo premissa(s) do gerenciamento de Aquisições:
•
O contrato deverá ser assinado até 10 dias antes do início previsto da
atividade.
64
10 Controle e Acompanhamento
Para um maior controle e acompanhamento deste projeto, segue abaixo alguns
artefatos:
10.1
Painel de Controle
O painel de controle do projeto é uma planilha onde será registrada todas
ações gerenciais executadas para mitigação e eliminação de riscos e controle
de mudanças (RCM). Abaixo segue detalhamento de como será realizado o
controle e acompanhamento do projeto:
Ações Gerenciais:
Ilustração 18: Ações gerencias
65
Acompanhamento de Mudanças (RCM):
Ilustração 19: Acompanhamento de mudanças
10.2
Controle Quantitativo
O controle quantitativo do projeto representa uma análise de comparação de
esforço planejado para cada atividade do projeto, perante o esforço realizado.
O controle é representado numa planilha com as seguintes abas:
•
Análise - Atividades:
o Project Baseline: 20 atividades colhidas por dados históricos da
TCC-MHP como baseline para formação do desvio padrão
(sigma) e por sua vez formação dos seguintes indicadores:
LC Médio;
LC + 1 Sigma;
LC – 1 Sigma;
LC + 2 Sigma;
LC – 2 Sigma;
LC + 3 Sigma;
LC – 3 Sigma.
66
Obs: Esses indicadores formam um gráfico de controle
estável para as 20 atividades de baseline.
o Project Real: Local para inserir as atividades do projeto com
100% de conclusão, juntamente com seu esforço planejado mais
seu esforço realizado. Com base nos limites do formados no
Project Baseline um novo gráfico de controle é formado, desta
vez com desvios das atividades reais. Este gráfico de controle
deve ser analisado seguindo as seguintes regras:
Qualquer ponto acima do limite de +3 Sigma;
Qualquer ponto abaixo do limite de -3 Sigma;
2 pontos consecutivos acima do limite de +2 Sigma;
2 pontos consecutivos abaixo do limite de -2 Sigma;
4 pontos consecutivos acima do limite de +1 Sigma;
4 pontos consecutivos abaixo do limite de -1 Sigma;
6 pontos consecutivos em uma fileira tendendo para cima
ou para baixo;
14 pontos consecutivos em uma fileira alternada para
cima e para baixo.
•
Causa-Raiz:
o Nesta planilha deve ser elaborado um gráfico do tipo Ishikawa
para cada atividade que cair nas regras citadas acima, com a
intenção de identificar a verdadeira causa do desvio.
•
Plano de Ações:
o Nesta planilha deve ser registrado um plano de ação para cada
causa raiz de desvio identificado, através dos seguintes
atributos:
Número (ID);
Nome da Medição;
Data de Inclusão;
Causa Raiz;
Ação;
Abordagem;
Data Limite;
Responsável;
67
Situação;
Data de Conclusão.
O objetivo principal deste plano e atacar desvios de esforço identificando a
causa e montando um plano de ação, para acarretar na melhoria continua do
projeto.
Projeto Linha de Base
Ilustração 20: Gráfico de controle - Projeto linha de base
68
Projeto Real
Ilustração 21: Gráfico de controle – Projeto real
Análise de Causa Raiz
Ilustração 22: Ishikawa – Análise de causa raiz
69
Ações corretivas/preventivas
Ilustração 23: Ações corretivas/preventivas
70
CONCLUSÃO
Este trabalho procurou demonstrar na prática a elaboração de um plano de projetos
seguindo as melhores práticas de gerenciamento de projetos, segundo o PMI, desde
a iniciação do projeto até o encerramento do mesmo, passando pelo planejamento,
execução e controle do projeto.
O projeto case deste planejamento é o Móbile Bank – WAP, que se trata do
desenvolvimento de um aplicativo para efetuar algumas transações bancárias
através de aparelhos celulares.
O resultado final foi que os processos seguidos e os artefatos gerados para cada
uma das disciplinas, se integrando garantem uma maior assertividade de sucesso do
projeto.
O primeiro capítulo abriu a disciplina de integração levantando o plano estratégico
do projeto, o termo de abertura e declaração preliminar de escopo e fechando com
plano de gestão de mudanças. Foi previsto a montagem de um comitê integrado de
mudanças, visando o controle de mudanças incluindo replanejamento e salvamento
de novas linhas de bases.
Os três capítulos seguintes procuraram formar às principais linhas de base do
projeto, escopo garantindo que o produto atenda as expectativas dos stakeholders,
prazo controlando o tempo de conclusão e seqüenciamento de cada atividade do
projeto e por fim custo, demonstrando uma previsão de gastos do projeto.
O capítulo de qualidade procurou realizar um planejamento de controle da qualidade
do projeto, com o objetivo de garantir que tanto o trabalho do projeto quanto do
produto seja executado com qualidade.
Para comunicação, quatro artefatos foram gerados com as diretrizes de
planejamento da comunicação, plano de escalonamento de itens pendentes, matriz
71
dos stakeholders demonstrando os principais envolvidos no projeto e finalizando
com a matriz de distribuição de relatórios do projeto.
Já no capítulo de recursos humanos, em seu planejamento, foi explicitado que a
equipe será reaproveitada de dentro da empresa.
Em aquisições foi previsto a subcontratação da implementação do módulo de login
da aplicação. Para seleção de fornecedores foi elaborada a RFP. A RFP já
representa a declaração de trabalho.
Por último foi criado um capítulo de controle e acompanhamento do projeto. Foi
elaborado um painel de controle para registro de ações gerenciais, lições aprendidas
e relatório de controle de mudanças. Por fim foi elaborado um controle quantitativo
com o objetivo de analisar as divergências de tempo estimado perante tempo
realizado de cada atividade e procurar a causa raiz das divergências analisadas num
gráfico de controle.
Como novas abordagens ficam aqui a simulação do plano, incluindo replanejamento
e até a aplicação do método da corrente crítica no projeto.
72
REFERÊNCIAS
PMI. Guia PMBOK: Um guia de conhecimentos em gerenciamento de projetos.
2004. Terceira Edição.