universidade candido mendes pÓs-graduaÇÃo “lato … · previdência privada, é um sistema...
TRANSCRIPT
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
FACULDADE INTEGRADA AVM
COMO GERENCIAR UM PROJETO DE MIGRAÇÃO DE
SISTEMAS DE PREVIDÊNCIA
Por: Aline da Silva Miled
Orientador
Prof. Luiz Cláudio Lopes Alves
Rio de Janeiro
2011
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
FACULDADE INTEGRADA AVM
COMO GERENCIAR UM PROJETO DE MIGRAÇÃO DE
SISTEMAS DE PREVIDÊNCIA
Apresentação de monografia à Universidade
Candido Mendes como requisito parcial para
obtenção do grau de especialista em gestão de
projetos.
Por: Aline da Silva Miled
3
AGRADECIMENTOS
Aos colegas de trabalho que me
incentivaram a retornar a vida
acadêmica e aos que trabalharam junto
comigo no projeto. Aos meus amigos e
parentes que sempre me apoiaram. Em
especial, agradeço a Deus pela vida e
por ter me dado o meu filho Rafael,
que é a minha inspiração e meu amor.
4
DEDICATÓRIA
Dedico a minha família, aos meus amigos
e ao meu amado filho Rafael.
5
RESUMO
Este trabalho visa contar a experiência vivida pela autora, demonstrando
como gerenciar um projeto de migração de sistemas de previdência privada e
quais as ferramentas e documentos de gestão de projetos foram utilizados.
O sistema atualmente utilizado pela empresa especialista em
previdência privada, é um sistema instável, com muitos problemas de
faturamento, sem flexibilidade para implantação de novos negócios e
adequação as constantes mudanças de legislações do mercado de previdência
privada.
Com o intuito de resolver o problema, a empresa comprou um sistema
de mercado, já utilizado por outras empresas, possuidor de soluções
customizadas para faturamento, parametrizações de produtos, adequações
rápidas as novas legislações e com isso, será necessário fazer a migração de
dados do sistema legado para o novo sistema.
6
METODOLOGIA
A metodologia a ser utilizado neste trabalho será a experiência vivida
em uma empresa especialista em previdência privada e consultas
bibliográficas.
7
SUMÁRIO
INTRODUÇÃO 08
CAPÍTULO I - INÍCIO DO PROJETO 11
CAPÍTULO II - ESTRUTURA DO PROJETO 14
CAPÍTULO III – INSTRUMENTOS UTILIZADOS 25
CONCLUSÃO 27
ANEXOS 28
BIBLIOGRAFIA CONSULTADA 72
REFERÊNCIA DE SITES 73
FOLHA DE AVALIAÇÃO 74
8
INTRODUÇÃO
Segundo a empresa especialista em previdência privada (2009), uma
das perguntas que foram feitas é o sistema atualmente utilizado pela empresa
é instável? Tem boa performance? Como a resposta foi negativa, o que será
preciso fazer resolver essa situação?
Escolhida para gerenciar um projeto de migração de um sistema de
previdência, a autora desta monografia foi buscar entendimento de como se
deve gerenciar um projeto e qual é o papel desse indivíduo.
A gerência de projetos é frequentemente a responsabilidade de um
indivíduo intitulado gerente de projeto.
É papel do gerente de projeto determinar e executar as necessidades
do cliente, baseado nos seus próprios conhecimentos.
Em campo, um gerente de projeto bem sucedido deve poder imaginar
o projeto inteiro do seu começo ao seu término, assegurando que esta visão
seja realizada.
O gerente de projeto é um profissional que tem a responsabilidade de
planejar , controlar e coordenar o desenvolvimento do projeto, colhendo
métricas, suprindo necessidade, recrutando recursos adequados e mantendo o
foco na meta do projeto, devendo: Estar sempre alerta, mas não avesso a
mudanças; Ser sensível a aspectos políticos; Agendar reuniões, acompanhar
treinamento, avaliar o desempenho de sua equipe e mantê-la motivada,
resolvendo conflitos.
9
Gerenciamento de projetos é a aplicação de conhecimentos,
habilidades e técnicas na elaboração de atividades relacionadas, que tem por
finalidade atingir um conjunto de objetivos pré-definidos, através da
mobilização de recursos humanos e ferramentas técnicas, num certo prazo,
com certo custo e qualidade.
O PMI (Project Management Institute), define gestão de projetos como
sendo o processo através do qual se aplicam conhecimentos, capacidades,
instrumentos e técnicas as atividades do projeto, de forma a satisfazer as
necessidades e expectativas dos diversos stakeholders (indivíduos ativamente
envolvidos no projeto) ou cujo resultado do mesmo poderá afetá-lo
positivamente ou negativamente.
Duas das principais iniciativas do PMI na difusão do conhecimento em
gerenciamento de projetos são: a certificação profissional em gerência de
projetos - Project Management Professional (PMP) e Certified Associate in
Project Management (CAPM) — e a publicação de um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos (Guia PMBOK® - Project
Management Body of Knowledge).
O guia do conjunto de conhecimentos em gerenciamento de projetos,
PMBOK, formaliza diversos conceitos em gerenciamento de projetos, como a
própria definição de projeto e do seu ciclo de vida. Também identifica na
comunidade de gerenciamento de projetos um conjunto de conhecimentos
amplamente reconhecido como boa prática, aplicáveis à maioria dos projetos
na maior parte do tempo. Estes conhecimentos estão categorizados em nove
áreas e os processos relacionados são organizados em cinco grupos de
processos ao longo do ciclo de vida do projeto.
As nove áreas de conhecimento caracterizam os principais aspectos
envolvidos em um projeto e no se gerenciamento, são elas: Integração,
10
escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos
aquisições.
Conhecendo um pouco mais sobre gerenciamento de projeto, será
contando em três capítulos a experiência vivida pela autora dessa monografia,
como gerenciar um projeto de migração de sistemas de previdência privada e
quais as ferramentas e documentos de gestão de projetos foram utilizados,
pois a solução encontrada pela empresa para resolver seu problema, foi
comprar um sistema de mercado.
11
CAPÍTULO I
INÍCIO DO PROJETO
“A vida está cheia de desafios que, se aproveitados de
forma criativa, transformam-se em oportunidades”
Marxwell Maltz.
1.1 - Premissas do Projeto
O projeto de migração de sistemas de previdência que vamos tratar
neste capítulo, já foi designado ao gerente de projeto com algumas premissas
que deveriam ser assumidas e respeitadas.
Podemos definir as premissas como hipóteses, condições que são
assumidas como verdadeiras para o projeto. São fatores que, para propósitos
de planejamento, são considerados como certas, reais e seguras.
As premissas de projetos devem ser específicas, precisas e claras.
São extremamente necessárias para todo o cliclo de vida do projeto e
principalmente no planejamento e execução. As premissas permeiam todo o
clico de vida e as fases dos projetos, exigindo muitas vezes do gerente do
projeto, a lembrança aos envolvidos para que o projeto continue andando no
rumo planejado e estruturado.
Fazem parte do projeto e devem ser validadas por todos os
stakeholders (envolvidos). Servem também para resguardar ao gerente de
projeto.
É importante identificar desde o início do projeto o maior número
possível de premissas e documentá-las.
12
1.2 – Levantamento das necessidades do projeto
Neste capítulo, vou citar as ferramentas que foram utilizadas para
realizar um levantamento das necessidades do projeto de migração do sistema
de previdência. O levantamento de necessidades deve envolver as áreas da
empresa, pois os problemas afetam as pessoas de maneiras diferentes.
1.2.1 – Ferramenta 1: Escutar
Ao assumir o projeto, foram feitas perguntas para descobrir ao
patrocinador do projeto e área de TI, com a finalidade de alinhar as premissas
e expectativas para o projeto. O método utilizado foi, escutar cuidadosamente
e explorar as respostas dos envolvidos, para compreender as necessidades o
melhor possível.
Foram realizadas reuniões freqüentes , para tratar de assuntos
específicos e reuniões semanais com todos os envolvidos, para alinhamento
com as áreas envolvidas no projeto, em relação à estratégia de migração de
sistemas que seria utilizada e as premissas do projeto, com a finalidade de
preparar o projeto para sua fase de execução.
1.2.2 - Ferramenta 2: Entrevista
Outra ferramenta utilizada no início do projeto foi a conversa com
funcionários-chaves da empresa. Cada área da empresa designou um
funcionário mais sênior, para trabalhar no projeto e informar as necessidades
de sua área especificamente.
13
1.2.3 - Ferramenta 3: Grupos focais
Depois de escutar e entrevistar os envolvidos no projeto, foi chegado o
momento de montar o grupo de trabalho, que deverá trabalhar para o projeto e
participar de todas as suas etapas, com a finalidade de permitir que os
funcionários discutam as suas diferentes opiniões e cheguem a um
entendimento coletivo das necessidades do projeto. Com essa atitude,
entendemos que as áreas da empresa envolvidas no projeto desde início, se
sentirão proprietárias e parte integrante do projeto, ajudando e auxiliando o
bom andamento do mesmo, junto ao gerente de projeto.
1.2.4 - Ferramenta 4: Reconhecer a necessidade prioritária
Uma vez que as necessidades tenham sido reconhecidas, os
funcionários envolvidos no projeto, devem ter a oportunidade de dizer quais
necessidades acham que são prioritárias. O ideal será iniciar o trabalho de
planejamento do projeto, descrevendo as ações que deverão ser priorizadas
no projeto, e posteriormente, planejar as próximas prioridades.
14
CAPÍTULO II
ESTRUTURA DO PROJETO
2.1 – Estrutura da empresa para gerenciar o projeto
A empresa especialista em previdência, citada neste trabalho, já possui
uma metodologia de gerenciamento de projeto, iniciada em 2008, com a
reestruturação das áreas de Processos e TI, e sobre essa estrutura de
gerenciamento de projetos que vamos tratar neste capítulo, especificando
como foi estruturado o projeto de migração do sistema de previdência.
Foi decidido pela Diretoria da empresa comprar um novo sistema de
previdência privada, com mais flexibilidade e instabilidade.
O projeto de migração começou a ser elaborado pelo Diretor de TI, que
levou uma proposta inovadora para o comitê de diretoria, com a finalidade de
aprovar sua proposta.
Trata-se de uma proposta de migração de sistemas por digitação e não
da forma tradicional por arquivo, como adotada atualmente pelo mercado. Para
isso levou os argumentos de porque que sua proposta seria melhor, do que a
praticada pelo mercado e a Diretoria da empresa aprovou sua proposta de
migração de sistemas por digitação.
Após a aprovação da proposta, foi montada a equipe do projeto e o
comitê de diretoria. A equipe do projeto foi composta por: Patrocinador,
gerente de projeto, líder de TI e PMO. A equipe do projeto ficou responsável
por dar continuidade ao projeto em todas as suas etapas, interagindo com as
15
áreas envolvidas, nas definições e fases do mesmo. Segundo o PMBOK,
trabalha-se no projeto com cinco grupos de processos, que também são
entendido como o clico de vida do projeto. São eles: Iniciação; Planejamento;
Execução; Monitoramento e controle; Encerramento.
O comitê de diretoria do projeto foi composto por: Diretor de TI, diretor
de operações, diretor financeiro, diretor de compliance, diretor de marketing,
cujo seu objetivo foi levar assuntos gerais do projeto e discutir custo, prazos e
entregas do mesmo. Este comitê executivo se reuniu quinzenalmente com a
equipe do projeto para alinhamento.
Os funcionários envolvidos no projeto foram designados por seus
gestores de área aqueles com perfil mais sênior, devido à grandeza do projeto,
migrar a base do sistema de previdência atual para outro sistema de mercado.
Ás áreas que designaram os funcionários foram: Produtos de previdência,
marketing, TI, operações, contabilidade, atuarial, controle de investimentos,
comercial, processos, tributos, compliance, Central de relacionamento com o
cliente, Este comitê se reuniu semanalmente para alinhamento do projeto.
2.2 – Estrutura da equipe do projeto
A empresa montou uma sala para equipe do projeto, contando com os
consultores da empresa que vendeu o novo sistema de mercado, com a
finalidade de auxiliar no melhor entendimento da nova ferramenta e na sua
implantação.
2.2.1 – Patrocinador
O patrocinador do projeto, no PMBOK sponsor do projeto, tem a
função de fazer a conexão dos projetos dentre as várias áreas de gestão de
uma empresa. Segundo o consultor de gestão Paul Campbell (2006), este
16
profissional tem como meta, inclusive, estimular o encerramento adequado de
um projeto.
O nome do sponsor ficará registrado em campo específico, em toda
documentação do projeto.
2.2.2 – Gerente do projeto
O gerente de projeto foi chamado e para ele foi designado à função de
tocar o projeto inovador, de fazer uma migração de sistemas por digitação.
Nesse primeiro contato o patrocinador do projeto informou que o sistema
legado precisava de um saneamento de dados, reafirmou as premissas do
projeto e informou como idealiza a proposta de migração dos dados. Sendo
assim, o inicialmente foi designado ao gerente do projeto às seguintes
atividades: Levantamento e definições das necessidades do projeto,
elaboração dos requisitos de negócios, levantamento e definições dos
saneamentos, levantamento e definições dos fluxos do processo, levantamento
dos custos e da viabilidade do projeto de migração por digitação, validar os
orçamentos de digitação, impressão, transporte e pistola de leitura 2D,
direcionar e controlar as atividades com as áreas envolvidas no projeto, fazer
reuniões periódicas com a equipe do Projeto, comitê de diretoria e com o grupo
de trabalho.
De acordo com o PMBOK, o trabalho do gerente de projeto pode ser
sintetizado em dois grandes elementos:
• Planejar (antes) e Controlar (durante) as atividades do projeto e
seu gerenciamento, conforme se pode constatar pela concentração de
processos de gerenciamento de um projeto abrangendo todos os aspectos
envolvidos.
17
• Comunicar: os gerentes de projetos passam a maior parte do seu
tempo se comunicando com os membros da equipe e outras partes
interessadas do projeto.
O nome do gerente do projeto ficará registrado em campo específico,
em toda documentação do projeto.
2.2.3 – Líder de TI
O Líder de TI foi fundamental para evolução deste trabalho de
migração de dados de um sistema para o outro, pois através deste indivíduo foi
possível fazer o acompanhamento das linhas de base dos projetos, foi dele a
responsabilidade em alguns momentos da elaboração e em outros das
validações de toda a documentação pertencente ao projeto. Documentos que
fizeram parte da elaboração os líderes de TI foram: Estudo do projeto,
especificação funcional, especificação técnica, plano de teste.
É um facilitador técnico do projeto, auxiliando o gerente de projeto no
planejamento e construção das atividades junto à área de TI.
O nome do líder de TI ficará registrado em campo específico, em toda
documentação do projeto.
2.2.4 – PMO
O PMO do projeto para essa empresa especialista em previdência
também foi fundamental para evolução deste trabalho de migração de dados
de um sistema para o outro, pois para essa empresa o PMO tem um papel
importante de apoio ao gerente de projeto. Através deste indivíduo foi possível
fazer o acompanhamento de todo projeto, pois o mesmo tem a função de
elaborar o cronograma, EAP e plano do projeto. Na parte de controle, o PMO
18
desta empresa faz o controle do orçamento do projeto, das atividades do
cronograma, das atividades de testes de TI junto com os líderes de TI do
projeto.
Segundo Eduardo de Souza, mestre em engenharia da computação,
com MBA em gestão de projetos, um PMO supervisiona o gerenciamento de
projetos, programas ou uma combinação dos dois. Os projetos apoiados ou
administrados pelo PMO não podem estar relacionados de outra forma que
não seja por serem gerenciados juntos. Alguns PMOs, no entanto, realmente
coordenam e gerenciam projetos relacionados. Em muitas organizações, esses
projetos são de fato agrupados ou estão relacionados de alguma maneira com
base no modo com que serão coordenados e gerenciados pelo PMO. O PMO
se concentra no planejamento, na priorização e na execução coordenados de
projetos e subprojetos vinculados aos objetivos gerais de negócios da matriz
ou do cliente.
Os PMOs podem operar de modo contínuo, desde o fornecimento de
funções de apoio ao gerenciamento de projetos na forma de treinamento,
software, políticas padronizadas e procedimentos, até o gerenciamento direto
real e a responsabilidade pela realização dos objetivos do projeto. Um PMO
específico, pode receber uma autoridade delegada para atuar como parte
interessada integral e um importante tomador de decisões durante o estágio de
iniciação de cada projeto. Pode ter autoridade para fazer recomendações ou
pode encerrar projetos para manter a consistência dos objetivos de negócios.
Além disso, o PMO pode estar envolvido na seleção, no gerenciamento e na
realocação, se necessário, do pessoal compartilhado do projeto e, quando
possível, do pessoal dedicado do projeto.
O nome do PMO ficará registrado em campo específico, em toda
documentação do projeto.
2.3 – Estrutura do projeto
19
Para o projeto de migração de sistemas de previdência dessa empresa
especialista em previdência, um projeto é estruturado por grupo de processos
e fases. São dessas fases e grupo de processos que vamos tratar neste item.
De acordo com a metodologia adorada pela empresa, o projeto foi
estruturado da seguinte forma:
• Grupo de processos: Iniciação, planejamento, execução e
encerramento.
• Fases: Plano, análise, desenho, construção, teste e
implantação.
2.3.1 Iniciação:
Na iniciação do projeto são tratados os requisitos de negócios, feito através de
um modelo padrão específico de documentos, definido pela metodologia de
gestão de projetos da empresa. Neste documento deve conter a necessidade
dos envolvidos (usuários de cada área) em relação ao projeto, para que os
líderes de TI validem e passem uma solução para atender ao requisito
solicitado.
De acordo com a metodologia de gestão adotada pela empresa, foram
definidas as seguintes atividades para iniciação:
• Criar primeira linha de base do projeto
• DLV: Criar requisito de negócio
• Avaliar Requisito de Negócio
• Avaliar Requisito de Negócio
• Concluir fase de Iniciação
20
2.3.2 Planejamento:
O planejamento do projeto é uma etapa dentro da metodologia de
gestão de projetos da empresa, com o maior número de entregas. As entregas
que permeiam esta etapa do projeto são:
Estudo do projeto -> O documento estudo, tem a finalidade de
entender a necessidade do usuário, através da leitura do requisito de negócios,
e dizer se o projeto é viável ou não. O responsável por essa atividade é o líder
de TI.
Especificação funcional -> O documento de especificação funcional foi
criado para que a área de TI possa dizer qual a solução encontrada para
necessidade do usuário. O responsável por essa atividade é o líder de TI.
EAP -> A EAP foi criada para entender o ciclo de vida do projeto e as
entregas contidas em cada fase. É um documento que facilita a criação do
cronograma. O responsável por essa atividade é o PMO.
Segundo Carlos Magno Xavier e outros autores , no livro Metodologia
de gerenciamento de projetos - Methodware, a EAP é uma ferramenta de
decomposição do trabalho do projeto em partes. É estruturada em árvore
exaustiva, hierárquica (de mais geral para mais específica) orientada às
entregas (deliverables) que precisam ser feitas para completar um projeto.
Cronograma -> No cronograma constam todos grupos de processos,
fases e atividades que deverão ser realizadas durante todo o projeto, com a
finalidade de dar ao projeto maior visibilidade e controle. O responsável por
essa atividade é o PMO.
21
Segundo definição da Wikipédia (2011), cronograma é um instrumento
de planejamento e controle semelhante a um diagrama, em que são definidas
e detalhadas minuciosamente as atividades a serem executadas durante um
período estimado.
Fluxo do processo - > O fluxo do processo é desenhado para
demonstrar como a solicitação do usuário irá acontecer em cadeia. O fluxo
serve também para demonstrar a empresa como as atividades serão
desempenhadas, visando otimizar redução de custos, aumento de
produtividade, automação de tarefas, possibilitando aprender como a solução
inovadora de migração de sistemas deverá acontecer, quando o ou os projetos
estiverem prontos. O fluxo ou mapeamento do processo, oferece ao projeto
maior visibilidade e controle. O responsável por essa atividade é a área de
processos.
Plano de testes - > O plano de teste foi planejado e elaborado pelas
áreas envolvidas no projeto e pela área de TI. Serve como um roteiro de
testes, com a finalidade de orientar quem vai testar o projeto e auxilia na
apresentação das evidências de testes. O responsável por essa atividade são
os usuários das áreas envolvidas e o líder de TI.
Na etapa de planejamento do projeto, de acordo com a metodologia de
gestão adotada pela empresa, divide-se em duas fases: Plano e análise.
Foram definidas as seguintes atividades de planejamento:
Plano
• Elaborar EAP
• Avaliar EAP
• DLV: Criar Cronograma
• Avaliar Cronograma
• Elaborar Pano do Projeto
• Avaliar Plano do Projeto
22
• Criar segunda linha de base do Projeto
Análise
• DLV: Criar Especificação Funcional
• Avaliar Especificação Funcional
• Elaborar fluxo do processo
• Validar fluxo do processo
• Avaliar Especificação Funcional Teste
• Executar mudança em teste
• DLV: Gerar evidências e resultados dos testes integrados
• Avaliar evidências dos testes
• DLV: Gerar evidências e resultados dos testes de aceitação do usuário
• Avaliar evidências dos testes de aceitação do usuário
• Autorizar subida para produção
• Concluir fase de análise
2.3.3 Execução:
A execução do projeto é uma etapa dentro da metodologia de gestão
de projetos da empresa, onde acontece toda a construção e programação do
sistema e as liberações de tudo que foi construído para teste.
Na execução do projeto, de acordo com a metodologia de gestão
adotada pela empresa, divide-se em três fases: Desenho, construção e teste.
Foram definidas as seguintes atividades de execução:
Desenho
• DLV: Criar Especificação Técnica
• Avaliar Especificação Técnica
• DLV: Criar plano de testes funcionais
• Avaliar plano de testes funcionais
• DLV: Criar plano de testes integrados
23
• Avaliar plano de testes integrados
• Concluir fase de desenho
Construção
• DLV: Criar Pacote de Implantação
• Resolver Pacote de Implantação
• Executar mudança em desenvolvimento
• DLV: Criar RunBook
• Avaliar RunBook
• DLV: Criar plano de testes de aceitação do usuário
• Avaliar plano de testes de aceitação do usuário
• Autorizar passagem para fase de teste
Testes
• Executar mudança em teste
• DLV: Gerar evidências e resultados dos testes integrados
• Avaliar evidências dos testes
• DLV: Gerar evidências e resultados dos testes de aceitação do usuário
• Avaliar evidências dos testes de aceitação do usuário
• Avaliar evidências dos testes de aceitação do usuário
• Autorizar subida para produção
2.3.4 Encerramento:
O encerramento do projeto é a etapa final, dentro da metodologia de
gestão de projetos da empresa, onde acontece a entregue total do projeto.
Após a atividade de teste completada, a área de TI sobe as modificações para
um ambiente de produção do sistema, mas antes é colhida a assinatura da
equipe do projeto e do usuário envolvido, para que dê o aceite final ao projeto,
aceitando o que lhe foi entregue. Podemos entender que essa etapa é
entregue do produto do projeto.
24
No encerramento do projeto, de acordo com a metodologia de gestão
adotada pela empresa, foram definidas as seguintes atividades, que fazem
parte da fase de implantação do projeto:
Implantação
• DLV: Executar mudança em produção
• Avaliar e comunicar o resultado da mudança em produção
• DLV: Coletar aceite final do Projeto junto ao gerente de projeto
Nesta etapa poderá ser realizada uma reunião de lições aprendidas
com toda equipe que se envolveu e trabalhou no projeto, com a finalidade de
levantar o que foi bom nesse projeto e o que poderá ser melhorado para um
próximo. Alguns estudiosos chamam essa atividade de uma ferramenta.
De acordo com a metodologia de processos da empresa, lições
aprendidas consiste no registro formal das respostas a perguntas como estas:
• O que deu certo?
• O que deu errado?
• O que faríamos novamente da mesma forma?
• O que faríamos de forma diferente?
• O que não sabíamos antes e agora sabemos?
25
CAPÍTULO III
INSTRUMENTOS UTILIZADOS
Para o projeto de migração de sistemas de previdência dessa empresa
especialista em previdência acontecer, a equipe do projeto se utilizou de
instrumentos de apoio. Quando digo instrumento de apoio neste capítulo, me
refiro a software (Project, Word, Excel, etc...) e vou explicar qual e onde foram
utilizados os instrumentos de apoio.
3.1 – Instrumentos da empresa para gerenciar o projeto
De acordo com a metodologia adotada pela empresa a equipe do
projeto acompanhou o mesmo, através de uma ferramenta (solução
customizada) chamada clear quest, da IBM e todas as documentações que
foram desenvolvidas e ou produzidas durante todo o projeto, foram anexadas
nesta, sempre seguindo um modelo estipulado pela empresa.
As documentações do projeto foram criadas, conforme descrito abaixo:
EAP -> A EAP (Estrutura analítica do projeto) foi criada em um
software chamado WBS Chart Pro.
Cronograma -> O cronograma foi criado em Project, da Microsoft,
Fluxo do processo - > O fluxo ou fluxograma do processo foi criado em
visio, da Microsoft.
Atas de reuniões -> As atas de reuniões foram criadas em Word.
26
Planilhas de acompanhamento-> As planilhas de acompanhamento do
projeto foram criadas em Excel.
27
CONCLUSÃO
Gerenciar Projetos em uma empresa que já tenha uma metodologia
determinada torna o trabalho do gerente do projeto mais organizado, mesmo
assim, gerenciar projeto é um grande desafio, como o que eu enfrentei
gerenciando este projeto inovador de migração de sistemas por digitação.
Entendi com essa experiência o quanto é importante que o gerente do projeto
e quem trabalhe no mesmo, estejam alinhados com as premissas e com um
objetivo único de fazer o melhor.
Vários conflitos tiveram que ser administrados. Como foi a primeira vez
que exerci essa função na empresa, enfrentei problemas com o planejamento.
Houve repactuação de prazos, houve arrocho de orçamento, tive que aprender
que todo o ciclo de vida do projeto é importante, mas se a etapa de
planejamento for bem feita, as próximas etapas serão mais fáceis de
administrar.
O projeto de migração de sistemas dessa empresa, no início foi
rejeitado pelos envolvidos, criticado de diversas formas e tive que ser
perseverante em defender a visão inovadora do Diretor, de fazer uma migração
de sistemas por digitação.
Gerenciar projetos é um processo através do qual um projeto é levado
a uma conclusão. Conclui-se que é a entrega do produto.
Conclui que mesmo com todos os problemas enfrentados, o projeto
está em sua fase de implantação e deve-se de fazer uma primeira migração de
dados ainda este ano de 2011.
28
ANEXOS
Índice de anexos
Anexo 1 >> Modelo de requisito de negócios;
Anexo 2 >> Modelo de estudo;
Anexo 3 >> Modelo de especificação funcional;
Anexo 4 >> Modelo de especificação técnica;
Anexo 5 >> Modelo de plano de teste;
Anexo 6 >> Modelo de EAP;
Anexo 7 >> Modelo de plano do projeto;
Anexo 8 >> Modelo de cronograma;
Anexo 9 >> Modelo de atas;
Anexo 10 >> Modelo de planilha de controle;
Anexo 11 >> Modelo de fluxo;
29
ANEXO 1
Modelo de requisito de negócios
Número do ProjetoNúmero do ProjetoNúmero do ProjetoNúmero do Projeto 0000000000000000000000000000
Nome do Projeto nome
Controle de Mudança
Versão
Data Mudança Responsável Revisor
Requisitos de Negócio
30
Índice
ÍNDICE ................................................................................................................................................................................................ 30
1 PRINCIPAIS ÁREAS ENVOLVIDAS ......................................................................................................................................... 31
2 EQUIPE PARTICIPANTE ......................................................................................................................................................... 31
3 VISÃO GERAL DO PROJETO ................................................................................................................................................. 31
3.1 Objetivo e justificativa ............................................................................................................................... 31
3.2 Descrição do Processo ............................................................................................................................. 31
3.2.1 Processo atual .......................................................................................................................................... 31
3.2.2 Processo futuro ........................................................................................................................................ 31
3.3 Benefícios ................................................................................................................................................ 31
3.3.1 Benefícios quantitativos ............................................................................................................................ 31
3.3.2 Benefícios qualitativos .............................................................................................................................. 31
3.4 Riscos ...................................................................................................................................................... 32
3.5 Necessidades de negócio ......................................................................................................................... 32
4 PREMISSAS DO PROJETO ..................................................................................................................................................... 32
4.1 Premissa 1 ............................................................................................................................................... 32
5 REFERÊNCIAS: ....................................................................................................................................................................... 32
6 ANEXOS ................................................................................................................................................................................... 32
7 INFORMAÇÕES COMPLEMENTARES ................................................................................................................................... 32
Expectativa de Conclusão ........................................................................................... Erro! Indicador não definido.
8 OBSERVAÇÕES ...................................................................................................................................................................... 32
31
Principais Áreas Envolvidas
Áreas consultadas na construção da solução da necessidade
Área Responsável Data
Equipe participante
Equipe participante
Nome Papel
Nome Gerente do Projeto
Nome Líder em TI
Nome PMO
xxxx xxxxx
Visão Geral do Projeto
Objetivo e justificativa
3.2 Descrição do Processo
3.2.1 Processo atual
3.2.2 Processo futuro
3.3 Benefícios
3.3.1 Benefícios quantitativos
3.3.2 Benefícios qualitativos
32
3.4 Riscos
3.5 Necessidades de negócio
Premissas do Projeto
4.1 Premissa 1
5 Referências:
6 Anexos
7 Informações Complementares
Data esperada pela conclusão do projeto: xx/xx/xxxx.
8 Observações
33
ANEXO 2
Modelo de estudo
Número do Projeto (1)
Nome do Projeto (2)
Nome do Sistema (3)
<
1) Inserir o número ( identificação) do projeto;
2) Inserir o nome do projeto.
3) Inserir a sigla ou mnemônico do sistema.>
Controle de Mudança
Versão
Data Mudança Responsável Revisor
Estudo
34
Índice
1 ÍNDICE...................................................................................................................................................................................... 34
2 VISÃO GERAL DO PROJETO ................................................................................................................................................. 35
2.1 Objetivo e Justificativa .............................................................................................................................. 35 2.2 Participantes do Projeto ........................................................................................................................... 35 2.3 Premissas ................................................................................................................................................ 35 2.4 Restrições ................................................................................................................................................ 35 2.5 Riscos ...................................................................................................................................................... 35 2.6 Características não contempladas ............................................................................................................ 36 2.7 Sistemas Impactados ............................................................................................................................... 36 2.8 Referências: ............................................................................................................................................. 36
3 DETALHAMENTO DO ESCOPO .............................................................................................................................................. 37
3.1 Descrição do Problema ............................................................................................................................ 37 3.2 Escopo do Projeto .................................................................................................................................... 37 3.3 Descrição do Processo ............................................................................................................................. 37 3.4 Necessidades dos Usuários ..................................................................................................................... 37 3.5 Capacidades do Sistema .......................................................................................................................... 37 3.6 Lista de Casos de Uso impactados .......................................................................................................... 38
4 REQUISITOS SUPLEMENTARES DA DEMANDA ................................................................................................................... 38
5 PENDÊNCIAS........................................................................................................................................................................... 39
6 ANEXOS ................................................................................................................................................................................... 39
7 DEPENDÊNCIA COM OUTROS REQUISITOS ........................................................................................................................ 39
8 CLASSIFICAÇÃO DA DEMANDA ............................................................................................................................................ 39
9 PRODUTOS/DOCUMENTAÇÃO: ............................................................................................................................................. 39
10 ESTIMATIVAS DE CUSTO ....................................................................................................................................................... 40
10.1 OG ........................................................................................................................................................... 40 10.2 Prazo ........................................................................................................................................................ 40 10.3 Classificação do projeto: .......................................................................................................................... 40
35
Visão Geral do Projeto
Objetivo e Justificativa <Orientação: Por qual motivo o cliente deseja esse serviço? O que o cliente consegue fazer precisamente quando o serviço desempenhado pelo projeto estiver disponível? Qual o objetivo do cliente ao realizar a ação contida no projeto? O objetivo pode enfatizar a diferença entre a situação atual e a situação requerida ou desejada.>
Participantes do Projeto
Equipe participante Nome Papel
<Nota: Preencher com os dados dos empregados que participaram na elaboração do presente documento. Identificar na equipe os papéis dos componentes: patrocinador, gerente de projeto, participante.>
Premissas <Descrever objetivamente cada premissa do projeto. A premissa deve enfatizar alguma dependência organizacional externa com algum fornecedor ou parceiro ou com outras áreas internas, as dependências podem ser de algum aspecto funcional ou de recurso (informacional ou material).>
Restrições <Identificar as condições de restrição que podem afetam o projeto.>
Riscos <Identificar os riscos e situações que podem criar ameaças ao projeto.>
36
Características não contempladas
<Identificar as características ou capacidades não contempladas de maneira que o projeto não cause falsa expectativa quanto a abrangência.>
Sistemas Impactados
Sistemas Módulo
Tipo do Impacto
(*)
Detalhes do Impacto
Tipo de Interface (**)
(*) Classificar entre Desenvolvimento, Leitura de Dados ou Atualização de Dados. Em caso de outro, especificar;
Consultar documento lista de sistema/módulos.
(**) Interface Síncrona = SYNC , Interface Assíncrona = ASYNC;
Referências:
Documento Data da última versão Fonte de Origem
37
Detalhamento do Escopo
Descrição do Problema <Um problema pode ser definido pela diferença entre a situação atual e a situação requerida ou desejada.>
Escopo do Projeto <Identificar que funcionalidades podem ser esperadas ao final do projeto. Deve ser também identificada a abrangência física e geográfica, bem como a abrangência qualitativa promovida.>
Descrição do Processo
Processo Atual <Descrever a situação atual do processo do usuário, ou seja, o processo que é atingido com o problema/necessidade do requerimento em questão.Se possível escrever passo a passo na forma de tópicos.>
Processo Futuro <Descrever como ficará o processo do usuário após a entrada da demanda em produção. Se possível escrever passo a passo na forma de tópicos.>
Necessidades dos Usuários <Identificar as necessidades em termos de funcionalidades ou pelos benefícios qualitativos alcançados pelo projeto. O procedimento, o padrão para a obtenção e a descrição dos requisitos de usuário podem ser obtidos consultando o livro de Princípios de Governança (3Ps-Aplicações). NEC1: Necessidades de .... EX: NEC2: Necessidade de gerar segurança para o processo de pagamento e contabilização das comissões NEC4: Necessidade de gerar controle sobre o processo de pagamento e contabilização das comissões. NEC5: Necessidade de automatizar o processo de pagamento e contabilização das comissões. >
Capacidades do Sistema <Identificar as capacidades do sistema que serão agregadas pelo projeto.>
38
CAP1: Capacidades de .... <Ex: CAP02 – Capacidade de permitir que a troca de informações entre os ambientes Icatu Seguros e de Parceiros seja criptografada.
Em caso de dúvida, consulte o livro de Princípios de Governança (3Ps- Aplicações) >
Lista de Casos de Uso impactados
<Preparar a lista dos casos de uso novos e os casos de uso impactados pelo projeto.>
Código Nome dos Casos de Uso Classificação (*)
UC2 <Nome do caso de uso 1>
UC3 <Nome do caso de uso 2>
(*) N=Novo, R=Reutilizado, A=Alterado
Requisitos Suplementares da Demanda <Descrever as demandas por requisitos não funcionais do tipo: usabilidade, confiabilidade, segurança e de desempenho.> Requisito Suplementar de Usabilidade <SUPL1: Será necessário treinamento na administração do sistema e treinamento por módulo para os usuários> Requisito Suplementar de Confiabilidade <SUPL2: Não serão permitidas falhas no resultado das faturas ou todos as falhas deverão ser registradas de forma histórica para posterior tratamento. SUPL3: Deveremos garantir um tempo inferior a 24 horas para reparos em caso de falhas no sistema> Requisito Suplementar de Desempenho <SUPL4: Cada tela deverá responder em menos de 1 segundo> Requisito Suplementar de Interface <SUPL5: A geração das informações deve ser feita em forma de arquivo no formato XML.
39
Pendências <Descrever as pendências com outros projetos ou com outros sistemas.>
Anexos <Colocar em anexo os documentos importantes ao andamento do projeto.>
Dependência com Outros Requisitos
<Listar, caso existam, as demandas em andamento (número e título) relacionadas a implantação da demanda solicitada. Podem ser demandas que dependam desta implantação ou vice versa.>
Dependência de desenvolvimento de terceiros (ex. Print, parceiro, outra empresa de telefonia, etc)
<Informar, caso haja, a participação de terceiros no desenvolvimento da solução. Listar os terceiros envolvidos e o motivo de sua participação.>
Classificação da Demanda Complexidade
Alta Média Baixa
Escopo
Novo Sistema Alteração em Sistemas Existentes
Produtos/Documentação:
<Nesta seção devem ser descritos os produtos que serão gerados e/ou a documentação prevista para o sistema.>
Documento Contemplado?
Especificação Funcional Sim Especificação Técnica Sim Plano de Testes Sim
40
Evidência de Testes Sim
Termo de aceite de Projeto Sim
RunBook Sim
Manuais de Treinamento Sim
Manuais de Usuário Sim
Manuais Técnicos Sim
Estimativas de Custo
OG
<Ordem de grandeza referente ao custo do desenvolvimento - em todos os sistemas impactados. Informar número de horas.>
a) Sistema X
- HW ......= valor
- SW ......= valor
- Serviço = Número de horas
Prazo
< Definir a data esperada para a conclusão do projeto e justificar essa expectativa ou necessidade.>
< (xxx Meses) – O tempo é contado a partir da aprovação financeira.>
Data para conclusão do projeto:
Classificação do projeto:
<Capex ou Opex>
41
ANEXO 3
Modelo de especificação funcional
Número do Projeto
Nome do Projeto
Nome do Sistema
Controle de Mudança
Versão Data Mudança Responsável Revisor
Especificação Funcional
42
Índice
1. ÍNDICE............................................................................................................................................................... 42
2. VISÃO GERAL DO PROJETO .......................................................................................................................... 43
2.1. Objetivo e Justificativa ........................................................................................................................... 43 2.2. Escopo do Projeto .................................................................................................................................. 43 2.3. Participantes do projeto ......................................................................................................................... 43 2.4. Premissas ............................................................................................................................................... 43 2.5. Restrições ............................................................................................................................................... 43 2.6. Riscos ..................................................................................................................................................... 44 2.7. Características não contempladas ........................................................................................................ 44 2.8. Sistemas Impactados ............................................................................................................................. 44 2.9. Referências: ............................................................................................................................................ 44
3. DETALHAMENTO DO ESCOPO ....................................................................................................................... 45
3.1. Descrição do Processo .......................................................................................................................... 45 3.2. Descrição do Problema .......................................................................................................................... 45 3.3. Necessidades do usuário (requisitos do usuário) ............................................................................... 46 3.4. Capacidades do Sistema ....................................................................................................................... 46
4. DESCRIÇÃO FUNCIONAL DAS MUDANÇAS................................................................................................... 46
4.1. Lista e Descrição de Atores ................................................................................................................... 46 4.2. Lista de Casos de Uso impactados ....................................................................................................... 47 4.3. Nome do caso de Uso <Remova o texto do capítulo ao lado “Nome do caso de Uso” pelo nome de caso de uso a ser documentado> ..................................................................................................................................... 47
5. REQUISITOS SUPLEMENTARES DA DEMANDA ............................................................................................ 50
5.1. Usabilidade ............................................................................................................................................. 50 5.2. Confiabilidade ......................................................................................................................................... 50 5.3. Desempenho ........................................................................................................................................... 50 5.4. Portabilidade ........................................................................................................................................... 50 5.5. Segurança ............................................................................................................................................... 51 5.6. Interfaces ................................................................................................................................................ 51 5.7. Outros ..................................................................................................................................................... 55
6. CONSIDERAÇÕES DE TESTES ....................................................................................................................... 55
7. PENDÊNCIAS.................................................................................................................................................... 55
8. ANEXOS ............................................................................................................................................................ 55
43
< O texto entre os sinais < e > e apresentados em azul foram incluídos neste documento template para auxiliar o processo de documentação funcional. Para o uso efetivo do template, estes comentários deverão ser excluídos. Todos os procedimentos e padrões para o correto preenchimento deste documento poderão ser obtidos nos Livros de Princípios de Governança (Aplicações e Dados-3Ps).>
Visão Geral do Projeto
Objetivo e Justificativa
<Esta seção deve ser escrita com base no Estudo de TI.>
Escopo do Projeto
<Esta seção deve ser escrita com base no Estudo de TI.>
Participantes do projeto
<Esta seção deve ser escrita com base no Estudo de TI.>
Equipe participante Nome Papel
Premissas
<Lista de Premissas que fazem parte do escopo preliminar da demanda (descrita no Estudo) a serem detalhados e/ou suprimidos nessa fase de escopo Premissa: Aspectos que são assumidos como verdadeiros e que caso não ocorram, gerarão conseqüências negativas para o projeto. EX:: Ambiente de Teste de aceitação do usuário deverá estar disponível no início da fase de codificação>
Restrições
44
<Lista de Restrições que fazem parte do escopo preliminar da demanda a serem detalhados e/ou suprimidos nessa fase de escopo Restrições: restringem as opções que estão disponíveis para o desenvolvedor no projeto e construção do sistema. São imposições. EX: Só poderão ser contratados recursos do fornecedor XPTO para esse projeto>
Riscos <Os riscos podem ser de várias naturezas: Riscos na não execução do projeto. Riscos relacionados ao não cumprimento de datas, multas, penalidades relacionadas. Riscos conhecidos do projeto, que se não forem mitigados poderão comprometer a entrega. Detalhar todos os riscos possíveis nesta seção.>
Características não contempladas
< Características ou capacidades que não são planejadas serem contempladas no projeto. Importante notar que este campo serve para que registremos aquelas características que já sabemos que embora desejadas pelos usuários, não poderão ser contempladas, seja por uma razão técnica ou por problemas de restrição financeira ou de planejamento.>
Sistemas Impactados <Descrever nesta seção todos os sistemas impactados. >
Sistemas Módulo
Tipo do Impacto
(*)
Detalhes do Impacto
Tipo de Interface (**)
(*) Classificar entre Desenvolvimento, Leitura de Dados ou Atualização de Dados. Em caso de outro, especificar; Consultar documento lista de sistema/módulos. (**) Interface Síncrona = SYNC , Interface Assíncrona = ASYNC;
Referências:
45
<Incluir a relação de documentos e outras fontes utilizadas ou referenciadas no levantamento dos requisitos do produto. Identificar cada documento pelo título, localização (quando aplicável), data (quando aplicável) e organização que o publicou.>
Documento Data da última versão Fonte de Origem
Ex: Estudo do projeto ABC 12/02/2007 Icatu Hartford
Detalhamento do Escopo
Descrição do Processo
Atual
<Descrever a situação atual do processo do usuário, ou seja, o processo que é atingido com o problema/necessidade do requerimento em questão.Se possível escrever passo a passo na forma de tópicos.>
Futura
<Descrever como ficará o processo do usuário após a entrada da demanda em produção. Se possível escrever passo a passo na forma de tópicos.>
Descrição do Problema
<Descrição detalhada do problema a ser atendido ou a ser sanado.
EX: Usuário do Call Center ao atender um cliente de serviço móvel, não possui visibilidade dos serviços contratados pelo cliente, seja este pessoa física ou jurídica na rede de Telefonia Fixa do Grupo, na execução das atividades de retenção>.
46
Necessidades do usuário (requisitos do usuário)
<Identificar as necessidades em termos de funcionalidades ou pelos benefícios qualitativos alcançados pelo projeto. O procedimento, o padrão para a obtenção e a descrição dos requisitos de usuário podem ser obtidos consultando o livro de Princípios de Governança (3Ps-Aplicações).
NEC1: Necessidades de ....
EX: NEC1: Necessidade de consultar as informações dos serviços contratados pelo cliente.>
Capacidades do Sistema
<As capacidades que o sistema deve possuir para atender as necessidades do usuário ou do negócio. As capacidades podem ser divididas em funcionais e não funcionais. Exemplo de uma capacidade funcional:
CAP01 – Capacidade de permitir a pesquisa das faturas a serem abonadas por número específico. O detalhe deverá ser representado pelos casos de uso e suas regras de negócio específicas
As capacidades não-funcionais são as que devem ser suportadas pelos Requisitos Suplementares e que normalmente atendem a necessidades técnicas e/ou de qualidade do sistema e não podem ser representadas por casos de uso. Exemplo de uma capacidade não-funcional:
CAP02 – Capacidade de permitir que a troca de informações entre os ambientes Icatu Seguros e de Parceiros seja criptografada.
Em caso de dúvida, consulte o livro de Princípios de Governança (3Ps- Aplicações) >
Descrição Funcional das Mudanças
< Os subcapítulos abaixo descrevem as modificações/implementações a serem realizadas nos sistemas, através da notação de casos de uso>
Lista e Descrição de Atores
< Descreva a lista de atores do caso de uso referido >
Atores Descrição
47
Lista de Casos de Uso impactados
<Os subcapítulos abaixo descrevem as modificações/implementações a serem realizadas nos sistemas, através da notação de casos de uso>
Código Nome dos Casos de Uso Classificação (*)
UC_XXX1
(*) N=Novo, R=Reutilizado, A=Alterado
Tabela 4.2 – Lista de Casos de Uso Novos/Alterados/Reutilizados
<A próxima seção (o item 4.3) deverá conter o detalhamento de todos os casos de uso listados acima. Para tanto, todos os casos de uso deverão ser copiados dos templates dos casos de uso> unitários. Cada novo casos de uso deverá criar um novo
sub capítulo (4.3, 4.4, 4.5, ...) Nome do caso de Uso <Remova o texto do capítulo ao lado “Nome do caso de
Uso” pelo nome de caso de uso a ser documentado>
<Nesta seção, deverão ser descritos detalhadamente os requisitos funcionais que fazem parte da solução da demanda, na notação de casos de uso. Estes requisitos deverão ser os mesmos apresentados na lista e no modelo de casos de uso do documento; assim como, os requisitos especiais e as regras de negócio que o suportam. Um caso de uso deve representar uma seqüência de ações solicitadas por um ou mais atores, a um sistema ou subsistema, sendo que estas ações deverão obrigatoriamente retornar um valor em benefício de pelo menos um de seus atores. <
48
Para maiores detalhes, consulte o Livro de Princípios de Governança – (3Ps -Aplicações) >
<Definir nomes que expressem corretamente o objetivo do caso de uso, ou seja, o que é produzido de valor para o ator. O nome deve estar coerente com o comportamento descrito; Regras para a definição do nome: ü Verbo Infinitivo + Objeto (Transferir Valores entre Contas, Pagar Título).
Utilizar verbos que denotem a ação sob o ponto de vista do ator e não do sistema. Verbos como Atualizar, Processar ou Exibir, geralmente, indicam ações sob o ponto de vista do sistema e devem ser evitados; >
Descrição
<Incluir um breve texto expressando o propósito do caso de uso e uma visão geral das funcionalidades envolvidas>.
Atores
<Relacionar os atores que participam da interação descrita pelo caso de uso.>
Pré-condições
<Incluir nesta seção condições que caso não sejam respeitadas ou impedirão o início do caso de uso. Os estados expressos na pré-condição devem ser observáveis pelo ator.>
Fluxo de Eventos
<Temos 3 tipos de fluxos de eventos que devem descrever todos os possíveis comportamentos do caso de uso, a interação entre os atores e o sistema. Estes devem detalhar passo a passo, o funcionamento do sistema, a interação com os atores e quais informações são trocadas entre a funcionalidadeeles. Não deverá ser utilizado domínio de valores na descrição dos fluxos de eventos do caso de uso. Se estes valores não influenciam no fluxo de eventos devem ser evitados, pois, se o domínio se modificar o caso de uso não poderá ser reutilizado e deverá pela razão deste impacto, também ser alterado. Exemplo: A aplicação tem um domínio de valores contendo todos os nomes de fabricantes de tomadas. >
49
Fluxo Básico
<Incluir nesta seção os eventos que normalmente acontecem quando o caso de uso é executado. Ao final, algum resultado de valor é gerado para o ator. No fluxo básico nenhuma situação de erro é descrita.>
Fluxo Alternativo
<Variações no comportamento normal da funcionalidade descrita no caso de uso. Os fluxos alternativos devem ter seu início e fim claramente descritos. Ao final dos mesmos, deverá ser indicada a sua continuidade no fluxo principal como por exemplo, o retorno para o ponto de chamada, o desvio para outro fluxo ou o encerramento do caso de uso. O fluxo alternativo deve ser referenciado nos passos em que pode ser chamado no fluxo principal.>
Fluxo de Exceção
<Situações em que a seqüência normal de transações não pode prosseguir. Os fluxos de exceção devem descrever situações que impedem a continuação do fluxo normal de eventos do caso de uso. Devem ter seu início e fim claramente descritos. Ao final dos mesmos, deve ser indicado o ponto de chamada ou o encerramento do caso de uso.
O fluxo de exceção deve ser referenciado nos passos em que ele pode ser chamado no fluxo principal e/ou alternativo.>
Regras de Negócio
<O propósito desta seção é listar as Regras de Negócio do sistema que são utilizadas pelo caso de uso, a fim de sustentar sua funcionalidade e o negócio que representa.>
Pós-condições
<A pós-condição é uma lista de possíveis estados que o sistema pode apresentar imediatamente após a finalização do caso de uso. Os estados devem ser observáveis pelos atores.>
50
Requisitos Especiais <Remova o texto do capítulo ao lado “Requisitos Especiais” pelo nome dos requisitos especiais >
<O propósito desta seção é listar os Requisitos não-funcionais que irão complementar individualmente as funcionalidades representadas pelo caso de uso. Estes requisitos não poderão ser de uso geral do sistema.
Os Requisitos Especiais são similares aos requisitos Suplementares mas suportam diretamente o caso de uso. Se houver mais de um caso de uso um novo requisito especial >
Requisitos Suplementares da Demanda
<Incluir nesta seção os requisitos não funcionais do sistema, que complementam a visão das alterações a serem realizadas no projeto.>
Usabilidade
<Questões de usabilidade devem incluir itens relativos a padrões de mercado ou já existentes na empresa (utilização de cores, logotipos e mensagens institucionais da empresa), facilidade de uso (necessidade de digitação de grandes volumes de dados) e aprendizado (público alvo e necessidade de treinamento).
Além disso, deverão aqui ser descritas todas as trocas de mensagens entre o sistema e o usuário.
O idioma utilizado deverá ser obrigatoriamente o português brasileiro e descrevendo em linguagem textual de negócio, as possíveis ocorrências internas de fracasso do sistema. >
Confiabilidade
<Questões de confiabilidade devem incluir itens relativos à disponibilidade requerida para o sistema (dias da semana e horário) e taxa de defeitos e de recuperação aceitáveis devido ao tipo de negócio relacionado ao sistema (finanças, credibilidade junto ao público alvo, tomada de decisão).>
Desempenho
<Questões de performance devem incluir itens relativos a volume de acesso, precisão, tempo de resposta de várias condições, limitações de recursos e capacidade de comunicação>.
Portabilidade <Portabilidade é a característica de o software ser facilmente modificado para acomodar melhorias e reparos. Questões de portabilidade devem incluir itens relativos
51
à necessidade de parametrização do sistema e portabilidade em relação a outros sistemas, hardware e softwares>.
Segurança
<Questões de segurança devem incluir itens relativos à necessidade de controle de acesso ao sistema, transferência de informações para outros sistemas e acesso externo a informações do sistema de forma segura>.
Interfaces
<Questões de Interface, devem incluir itens relativos a protótipo ou layout sugerido de telas, relatórios e/ou arquivos de saída. Para cada tela, deverá ser incluída uma descrição textual que represente a navegação ou exemplificar o direcionamento tomado pela interface com a camada de apresentação gráfica.>
As tabelas a seguir deverão ser utilizadas:
52
PROTÓTIPO DE TELA Sistema: <Sigla e nome do sistema>
Módulo: <Nome do módulo>
(Desenhar ou Anexar Protótipo de Tela)
53
PROTÓTIPO DE RELATÓRIO
Sistema: <Sigla e nome do sistema>
Módulo: <Nome do Módulo>
(Desenhar ou Anexar Protótipo de Relatórios)
54
LAYOUT DE ARQUIVOS
Sistema: <Sigla e nome do sistema>
Módulo: <Nome do Módulo>
(Anexar Layout de Arquivos)
55
Outros
<Descrever nesta seção itens que não se enquadram a nenhuma outra seção dos requisitos suplementares aqui descritos.
Em caso de dúvida, consulte o Livro de Princípios de Governança – Aplicações (3Ps).>
Considerações de Testes
<Deverão ser registrados aqui, os possíveis cenários macros dos testes de Sistemas, Integrados e de UAT, conforme a característica da demanda>
Pendências
<Detalhar nesta seção as pendências existentes com o cliente. Descrever as dependências desta demanda com outras ou requerimentos>.
O seguinte formato pode ser utilizado:
# Data
Ident. Responsável Dúvida Resposta Rubrica
Anexos
A. Matriz de Rastreabilidade
B. Glossário C. Outros
56
ANEXO 4
Modelo de especificação técnica
Número do Projeto
Nome do Projeto
Nome do Sistema 1) Inserir o número ( identificação) e o nome do projeto; 2) Inserir o nome do sistema que receberá a informação produto da integração.
Controle de Mudança
Versão Data Mudança Responsável Revisor
ET de Integração
57
Índice
1. ÍNDICE.................................................................................................................................................................................. 57
2. VISÃO GERAL DO PROJETO ............................................................................................................................................. 58
2.1. Objetivo e Justificativa ........................................................................................................................... 58
2.2. Escopo do Projeto .................................................................................................................................. 58
2.3. Participantes do projeto ......................................................................................................................... 58
2.4. Sistemas Impactados ............................................................................................................................. 58
3. ESPECIFICAÇÃO TÉCNICA ................................................................................................................................................ 59
3.1. Especificação dos Mapas de Integração .............................................................................................. 59
4. DETALHAMENTO DO PROCESSO ..................................................................................................................................... 61
5. MATRIZ SOURCE/TARGET ................................................................................................................................................. 61
6. ANEXO A .............................................................................................................................................................................. 61
58
< O texto entre os sinais < e > e apresentados em azul foram incluídos neste documento template para auxiliar o processo de documentação técnica. Para o uso efetivo do template, estes comentários deverão ser excluídos. Todos os procedimentos e padrões para o correto preenchimento deste documento poderão ser obtidos nos Livros de Princípios de Governança (Aplicações e Dados -3Ps).>
Visão Geral do Projeto
Objetivo e Justificativa
<Esta seção deve ser escrita com base no documento EF de Integração.> <Descrição detalhada do problema a ser atendido ou a ser sanado.
Escopo do Projeto <Esta seção deve ser escrita com base no documento EF de Integração. Deve ser descrito como as informações disponibilizadas serão preparadas. >
Participantes do projeto
Equipe participante Nome Papel
Sistemas Impactados
<Descrever nesta seção todos os sistemas impactados. >
Sistemas Módulo
Tipo do Impacto
(*)
Detalhes do Impacto
Tipo de Interface (**)
(*) Classificar entre Desenvolvimento, Leitura de Dados ou Atualização de Dados. Em caso de outro, especificar; Consultar documento lista de sistema/módulos. (**) Interface Síncrona = SYNC , Interface Assíncrona = ASYNC;
59
Especificação Técnica
Especificação dos Mapas de Integração <Detalhar os mapas de integração do Powercenter. Veja exemplo abaixo>
MAPA 1
Nome do Mapa <Nome físico do mapa no Powercenter>
Sistema Origem <Sistema(s) de Origem>
Sistema Destino <Sistema(s) de Destino>
Qtd Inicial de registros
<# registros inicial> Registros / Carga <# registros por execução>
Descrição
Freqüência execução <Diário, Semanal, Mensal, Horas>
Pré-processamento <Atividades necessárias no pré-processamento do mapa. Ex. Truncar tabela XX, etc..>
Pós-processamento <Atividades necessárias no pré-processamento do mapa. Ex. Criar indices, etc..>
Estratégia para erro <O que fazer em caso de erro. Logar os registros e prosseguir, abortar o job, d>
Estratégia de recarga <Pode reinicializar, deve seguir outra cadeia de processos, etc..>
Campos únicos (PKs) <PKs a serem tratadas no mapa>
Objetos dependentes <Objetos dependents que devem ser tratados no mapa, FKs, outros>
SOURCES
<Lista as fontes de dados de acordo com os seus tipos. Maiores documentações estão presentes no metadado da ferramenta.>
Tabelas
Nome System/Schema/Owner Filtros / Critério seleção
Arquivos
Nome Localização Fixo/delimitado Observação
60
TARGETS <Lista o alvos de dados de acordo com os seus tipos. Maiores documentações estão presentes no metadado da ferramenta.> Tabelas
Nome System/Schema/Owner Filtros / Critério seleção
Arquivos
Nome Localização Fixo/delimitado Observação
LOOKUPS
Nome <Nome>
Tabela <Tabela base> Local <Base>
Condições <Condições necessárias para a lookup. Ver exemplo abaixo: DimGeography.City = Address.City DimGeography.StateProvinceCode = StateProvince.StateProvinceCode DimGeography.CountryRegionCode = StateProvince.CountryRegionCode>
Persistente / Dinamica <Indica se a mesma deve manter os arquivos de consulta no servidor ou descartá-los ao fim do processamento>
Filter/SQL Override <SQL de filtro>
DIAGRAMA DE ALTO NÍVEL DO PROCESSO <Desenho de alto nível do mapa.>
DimCustomer
Person
Customer
EmailAddress
Address
PersonPhone
StateProvince
Joiner XMLParser
Joiner
Joiner
Joiner
Joiner
Joiner Lookup
BusinessEntityAddress
Sequence Generator
61
DETALHAMENTO DO PROCESSO
<Pseudo-código que detalha o funcionamento do processo como um todo. Algumas especificações de implementação estão descritas aqui. Ver exemplo abaixo:
Este processo tem como principal origem a tabela Sales.Customer. O processo deverá obter somente os clientes pessoas físicas (Customer.StoreID nulo). Alguns dos dados a serem carregados estão em outras tabelas, abaixo estão as regras de junção entre as tabelas relacionadas no processo:
Customer.PersonID = Person.BusinessEntityID(Normal Join).
Este joiner retornará alguns campos para serem carregados na dimensão customer, porém um campo específico Person.Demographics está em um formato XML e deverá ser utilizado um XMLParser para retornar os valores como novos campos. Abaixo no Anexo A temos o formato do XML.
Customer.PersonID = EmailAddress.BusinessEntityID (Normal Join).
Customer.PersonID = PersonPhone.BusinessEntityID (Normal Join).
Abaixo estão especificados os joiners para retorno dos dados de endereço do cliente. Iremos selecionar na tabela BusinessEntityAddress apenas os endereços residenciais. (AddressTypeID = 2)
Customer.PersonID = BusinessEntityAddress.BusinessEntityID (Normal Join).
BusinessEntityAddress.AddressID = Address.AddressID (Normal Join).
Address.StateProvinceID = StateProvince.StateProvinceID (Normal Join
Matriz source/target
<Matriz que indica a correspondência entre origem e destino. Podem ser feitas tantas quantas forem necessárias para o mapa.
ANEXO A
62
ANEXO 5
Modelo de plano de teste
Plano de Teste
Informações
Número da Demanda Nome da Demanda
Envolvidos
Usuário Usuário(s)/Departamento(s) requisitante(s)
Líder Técnico Líder Técnico -
Planejamento de Teste
# ID Caso de Uso/Funcionalidade
do sistema
# Caso de teste
Descrição do Caso de Teste Ação(ões) Dados de
entrada
Descrição do Resultado Esperado Detalhado
ID do Caso de Uso ou Funcionalidade
associada ao cenário de testes
Nº do Caso de
Teste que está
sendo testado
Descreve um caso de teste de um
determinado caso de uso
Passos utilizados
para executar o
caso de teste
Dados utilizados para
executar o caso de teste
Descreve o resultado que se espera obter
do caso de teste executado.
63
ANEXO 6 - Modelo de EAP
64
ANEXO 7
Modelo de plano de projeto
Como este documento é muito extenso, estou colocando apenas o
índice, que traz todas as atividades.
Plano do Projeto
Título do projeto
Desenvolvido por: nome
Data: xx/xx/xxxx
Informação do documento
Nome do Projeto: XXXXXX
Gerente do Projeto: XXXXXX Versão do documento:
Patrocinador do Projeto: XXXXXX Data versão do documento:
XXXXXXX
Preparado por: XXXXXX Data de preparação:
Revisado por: Data de revisão:
Lista de Distribuição
De Data Telefone/Fax
Fulano xx/xx/xxxx (xx) xxxx-xxxx – R: xxxx
Para Ação* Vencimento Telefone/Fax
Ciclano Aprovar
* Tipos de Ação: Aprovar, Revisar, Informar, Arquivar, Requisição de Ação, Attend Meeting, Outros (favor especificar)
Histórico de Revisão
Ver. No. Ver. Data Revisado por Descrição
66
Indíce
OBJETIVO DO DOCUMENTO ERRO! INDICADOR NÃO DEFINIDO.
1 INTRODUÇÃO ERRO! INDICADOR NÃO DEFINIDO. 1.1 OBJETIVO DO PROJETO .................................................................................. Erro! Indicador não definido. TIME DO PROJETO ......................................................................................................... Erro! Indicador não definido. FATORES CRÍTICOS DE SUCESSO .................................................................................... Erro! Indicador não definido. PREMISSAS E DEPENDÊNCIAS ........................................................................................ Erro! Indicador não definido. 1.2 DEFINIÇÃO DE TERMOS .................................................................................. Erro! Indicador não definido.
2 EAP ERRO! INDICADOR NÃO DEFINIDO. 2.1 EAP DO PROJETO ......................................................................................... Erro! Indicador não definido. 2.2 ENTREGAS .................................................................................................... Erro! Indicador não definido. 2.2.1 OBJETIVO ..................................................................................................... Erro! Indicador não definido. 2.2.2 ENTREGAS DO PLANEJAMENTO ....................................................................... Erro! Indicador não definido. 2.2.2.1 - DLV: Plano de Projeto ................................................................................... Erro! Indicador não definido. 2.2.2.2 - DLV: Plano de Migração ................................................................................ Erro! Indicador não definido. 2.2.2.3 - DLV: Plano de Gerenciamento de Ambiente ................................................. Erro! Indicador não definido. 2.2.3 ENTREGAS DO CONTROLE .............................................................................. Erro! Indicador não definido. 2.2.3.1 - Reunião de Status Report TI ......................................................................... Erro! Indicador não definido. 2.2.3.2 - Reunião de Status Report Gerencial ............................................................. Erro! Indicador não definido. 2.2.3.3 – Relatório de Acompanhamento TI ................................................................ Erro! Indicador não definido. 2.3.3.4 – Relatório de Acompanhamento Gerencial..................................................... Erro! Indicador não definido. 2.2.4 ENTREGAS DA EXECUÇÃO .............................................................................. Erro! Indicador não definido. 2.2.4.1 - Detalhamento de GAPs ................................................................................. Erro! Indicador não definido. 2.2.4.3 - Documentação de testes funcionais/homologação ........................................ Erro! Indicador não definido. 2.2.4.3.1 - DLV: Plano de Homologação ..................................................................... Erro! Indicador não definido. 2.2.4.3.1.1 - DLV: Plano de Homologação de Negócio ................................................ Erro! Indicador não definido. 2.2.4.3.1.2 - DLV: Plano de Homologação de Migração .............................................. Erro! Indicador não definido. 2.2.4.3.2 - DLV: Plano de Testes Funcionais .............................................................. Erro! Indicador não definido. 2.2.4.4 - Desenho de Processos ................................................................................. Erro! Indicador não definido. 2.2.4.4.1 - DLV: Novos Processos .............................................................................. Erro! Indicador não definido. 2.2.4.4.2 - DLV: Alteração de Processos ..................................................................... Erro! Indicador não definido. 2.2.4.6 - Migração de dados ........................................................................................ Erro! Indicador não definido. 2.2.4.7 - Documentos Procarta .................................................................................... Erro! Indicador não definido. 2.2.4.8 - DLV: Perfil de Acesso ................................................................................... Erro! Indicador não definido. 2.2.4.9 - DLV: Ambiente ajustado de Produção ........................................................... Erro! Indicador não definido. 2.2.4.10 - DLV: Ambiente ajustado de Homologação .................................................. Erro! Indicador não definido. 2.2.4.11 - DLV: Ambiente ajustado de Desenvolvimento ............................................. Erro! Indicador não definido. 2.2.4.12 - DLV: Execução do Teste de Performance ................................................... Erro! Indicador não definido. 2.2.4.13 - DLV: Jobs de Fechamento diário e mensal em Produção ........................... Erro! Indicador não definido. 2.2.4.12.1 - DLV: Runbooks ........................................................................................ Erro! Indicador não definido. 2.2.4.13.2 - DLV: Diagrama de processos do Control-M .............................................. Erro! Indicador não definido. 2.2.4.14 - DLV: Implantação ........................................................................................ Erro! Indicador não definido.
3 CRONOGRAMA ERRO! INDICADOR NÃO DEFINIDO.
4 GERENCIAMENTO DE RECURSOS HUMANOS ERRO! INDICADOR NÃO DEFINIDO. 4.1 TIME DO PROJETO ......................................................................................... Erro! Indicador não definido. 4.2 RELAÇÃO DE PARTES INTERESSADAS .............................................................. Erro! Indicador não definido. 4.3 FUNÇÕES E RESPONSABILIDADES ................................................................... Erro! Indicador não definido. 4.4 TREINAMENTO ............................................................................................... Erro! Indicador não definido.
5 GERENCIAMENTO DE MUDANÇAS ERRO! INDICADOR NÃO DEFINIDO. 5.1 VISÃO GERAL ................................................................................................ Erro! Indicador não definido. 5.2 SOLICITAÇÃO DE MUDANÇA ............................................................................ Erro! Indicador não definido. 5.3 INÍCIO DE MUDANÇA ....................................................................................... Erro! Indicador não definido. 5.4 AVALIAÇÃO DE MUDANÇA ............................................................................... Erro! Indicador não definido. 5.5 APROVAÇÃO DE MUDANÇA ............................................................................. Erro! Indicador não definido. 5.6 IMPLEMENTAÇÃO DA MUDANÇA ....................................................................... Erro! Indicador não definido. 5.7 ACEITAÇÃO DA MUDANÇA ............................................................................... Erro! Indicador não definido. 5.8 REGISTRO ..................................................................................................... Erro! Indicador não definido.
6 GERENCIAMENTO DA COMUNICAÇÃO ERRO! INDICADOR NÃO DEFINIDO. 6.1 DISTRIBUIÇÃO ............................................................................................... Erro! Indicador não definido.
676.2 RETENÇÃO .................................................................................................... Erro! Indicador não definido.
6.3 REGISTRO ..................................................................................................... Erro! Indicador não definido.
7 GERENCIAMENTO DA RISCOS ERRO! INDICADOR NÃO DEFINIDO.
8 TEMPLATES DE ARQUIVOS ERRO! INDICADOR NÃO DEFINIDO.
9 ACEITAÇÃO DO PLANO DO PROJETO ERRO! INDICADOR NÃO DEFINIDO.
10 ANEXOS ERRO! INDICADOR NÃO DEFINIDO.
10.1 ANEXO III - CRONOGRAMA DO PROJETO ........................................................ Erro! Indicador não definido.
68
ANEXO 8 - Modelo de cronograma
Id Id Task Name %concluída
Duração Início Término
3500 3500 PTI00068585 - migração 58% 296 dias Qua 10/02/10 Qua 13/04/11
3501 3501 Iniciação 100% 41.5 dias Qua 10/02/10 Ter 13/04/10
3508 3508 Plano 100% 62.5 dias Ter 13/04/10 Seg 12/07/10
3526 3526 Análise 100% 22 dias Ter 13/07/10 Qua 11/08/10
3541 3541 Desenho 100% 108 dias Qui 12/08/10 Seg 17/01/11
3554 3554 Construção 17% 27 dias Ter 18/01/11 Qua 23/02/11
3562 3562 Teste 0% 31 dias Qui 24/02/11 Qui 07/04/11
3572 3572 Implantação 0% 4 dias Sex 08/04/11 Qua 13/04/11
Qua 10/Fev 8
69
ANEXO 9
Modelo de ata
LOGOMARCA ATA DE REUNIÃO
xxxxxxxxxxxxxxxxxxx
Data:
Horário:
No:
P AR T I C I P AN T E S
NOME Ausentes
ASSUNTOS TRATADOS
DECISÕES / DELIBERAÇÕES
AÇÕES
DESCRIÇÃO RESPONSÁVEL PRAZO ATÉ
ELABORADA POR: NOME LISTA DE DISTRIBUIÇÃO: Todos os participantes presentes e ausentes da reunião.
70
ANEXO 10 - Modelo de planilha de controle
ID Data Inicial Descrição da Atividade / Pendência Status Comentários IcatuComentários Kiman
Área Responsável
Responsável
71
ANEXO 11 - Modelo de fluxo
Extração, Validação e Correção dos
dados do PGBL
Saneamentos Automáticos
e Manuais na Base Intermediária
Geração e Impressão dos PDFs
Leitura dos códigos 2D, Digitação e
Validação dos Dados no Kiprev
Tratamento Diário dos Erros
Manutenção dos Dados no KIPREV
1ª Etapa - Migração dos Dados
O saneamento manual dos dados do PGBL é predecessor para o início da extração (Data de aposentadoria , datas de 1900, percentual diferente de 100% para os beneficiários , unificação de matrícula )
Para as novas vendas ocorridas neste período, será realizado o mesmo processo de migração dos dados
Saneamentos no sistema do PGBL
72
BIBLIOGRAFIA CONSULTADA
Manual de Gerenciamento de Projetos da Icatu Seguros. Guia das normas
e técnicas de gerenciamento de projetos Icatu Seguros. Rio de Janeiro, 2011.
Histórico do projeto de migração de sistemas da Icatu Seguros. Consulta
aos documentos anexados na ferramenta clear quest, da IBM, utilizada pela
empresa Icatu Seguros. Rio de Janeiro, 2011.
PMBOK. Um guia do Conjunto de Conhecimentos em Gerenciamento de
Projetos, PMI. Pennsylvania, 2008.
XAVIER, CARLOS MAGNO. VIVACQUA, CARLOS RIBEIRO. MACEDO,
OTUALP SARMENTO. Metodologia de gerenciamento de projetos –
Methodware. Gestão de projetos, 2005.
73
REFERÊNCIA DE SITES
http://www.gerenciarprojetos.com.br
http://www.microsoft.com.
http://www.labceo.com.br
http://www.hsm.com.br
http://www.gerprojetos.blogspot.com
http://www.avellareduarte.com.br
http://www.ogerente.com.br
http://www.wiquipedia.com.br
74
FOLHA DE AVALIAÇÃO
Nome da Instituição: Universidade Cândido Mendes – Instituto a Vez do
Mestre.
Título da Monografia: As Principais Dificuldades de Implantar
Metodologia de Gerenciamento de Projeto nas Empresas.
Autor: Aline da Silva Miled
Data da entrega: 02/04/2011
Avaliado por: Luiz Cláudio Lopes Alves Conceito: