Boas práticas para implementação Mps.br utilizando a ferramenta Channel

Boas práticas para
implementação do MPS.Br
níveis G e F utilizando a
Plataforma Channel

Boas Práticas – MPS.Br Níveis G e F
• Nível G – Parcialmente Gerenciado
o GPR – Gerência de projetos
o GRE – Gerência de requisitos
• Nível F – Gerenciado
o AQU – Aquisição
o GCO - Gerência de configuração
o GQA – Garantia da qualidade
o MED - Medição

MPS.Br G – Gerência de Projetos - GPR
• Propósito:
o O propósito do processo Gerência de Projetos é
estabelecer e manter planos que definem as
atividades,
recursos
e
responsabilidades
do
projeto, bem como prover informações sobre o
andamento do projeto que permitam a realização de
correções quando houver desvios significativos no
desempenho do projeto. O propósito deste processo
evolui à medida que a organização cresce em
maturidade.

GPR 1. O escopo do trabalho para o projeto está
definido
• Estabeleça um processo que auxilie sua equipe na
definição do escopo de trabalho para o
projeto, identificando as necessidades do cliente e
promovendo a rastreabilidade entre o requisito de
negócio e o pacote de trabalho na EAP do projeto

Boa prática - GPR 1: Defina um processo e suas
atividades

Boa prática - GPR 1: Para apoiar o processo, crie
formulários para mapeamento das necessidades do
cliente e definição do escopo do projeto

GPR 2. As tarefas e os produtos de trabalho do projeto
são dimensionados utilizando métodos apropriados
• Defina um método de estimativa objetivo e
institucional. Estabeleça instrumentos para
auxiliar sua equipe durante esta atividade de
estimativa e garanta que esse método esteja
mapeado em seu processo;
• É importante que o histórico de mudanças das
estimativas bem como a rastreabilidade entre os
R.N. e os produtos de trabalho seja garantido.

GPR 3. O modelo e as fases do ciclo de vida do projeto
são definidos
• Defina um template padrão de EAP para os
projetos da sua empresa e certifique-se que ele
contenha as fases do ciclo de vida definidas em
seus processo institucional
• Sugestão: O processo de definição do escopo do
projeto, apresentado anteriormente, pode fazer
parte do ciclo de vida. Normalmente ele
implementa as atividades contidas na fase de
iniciação de um ciclo de vida tradicional de um
projeto.

GPR 4. O esforço e o custo para a execução das
tarefas e dos produtos de trabalho são estimados com
base em dados históricos ou referências técnicas

• Utilize um método baseado em dados históricos
ou referências técnicas para estimar o esforço e o
custo das atividades/tarefas do seu projeto. A
base de cálculo deve ser anexada a atividade para
análises futuras

GPR 5. O orçamento e o cronograma do
projeto, incluindo a definição de marcos e pontos de
controle, são estabelecidos e mantidos

• Defina o cronograma do projeto, evidenciando as
fases, os marcos, os pacotes de trabalho, as
atividades e tarefas com suas respectivas
datas, duração e orçamento (valor planejado).

GPR 6. Os riscos do projeto são identificados e o seu
impacto, probabilidade de ocorrência e prioridade de
tratamento são determinados e documentados

• Os riscos do projeto devem ser identificados e
monitorados durante toda a execução do projeto.
As ações para tratar o risco também deve ser
mapeada e mantida.

GPR 7. Os recursos humanos para o projeto são
planejados considerando o perfil e o conhecimento
necessários para executá-lo

• Defina um plano de gerenciamento de RH e
garanta que este plano seja evidenciado no
projeto e conhecido/seguido por todos da equipe.

GPR 8. Os recursos e o ambiente de trabalho
necessários para executar o projeto são planejados

• Defina um plano de gerenciamento dos recursos e
do ambiente de trabalho e garanta que este plano
seja evidenciado no projeto e conhecido/seguido
por todos da equipe.

GPR 9. Os dados relevantes do projeto são
identificados e planejados quanto à forma de
coleta, armazenamento e distribuição. Um mecanismo é
estabelecido
para
acessá-los,
incluindo,
se
pertinente, questões de privacidade e segurança

• Os dados relevantes do projeto devem ser
organizados em um repositório de forma que
fiquem disponíveis para as pessoas corretas
obedecendo as políticas de privacidade e
segurança

GPR 10. Um plano geral para a execução do projeto é
estabelecido com a integração de planos específicos

• Faça a geração do plano do projeto que integre
todos os planos do projeto em um único plano.
Além disso, sempre que uma nova linha de base é
gerada, uma versão do plano do projeto é
congelada e pode ser usada como referência para
consulta posterior.

Boa prática – GPR 10
IMPORTANTE: Garanta que todos os planos sejam criados
durante a fase de planejamento e que suas evidências sejam
armazenadas junto ao projeto

GPR 11. A viabilidade de atingir as metas do projeto é
explicitamente avaliada considerando restrições e
recursos disponíveis. Se necessário, ajustes são
realizados

• A análise de viabilidade do projeto deve ser
realizada e sua evidência anexada ao processo.
Durante a execução do projeto a análise pode ser
reavaliada e o histórico de reavaliação deve ser
mantido.

GPR 12. O Plano do Projeto é revisado com todos os
interessados e o compromisso com ele é obtido e
mantido

• O plano do projeto deve ser revisado com toda
equipe e o comprometimento da equipe com o
projeto deve ser registrado. Faça uma reunião de
kickoff do projeto e registre uma ata, tanto da
revisão do planejamento do projeto, quanto do
comprometimento da equipe com a execução do
mesmo.

Boa prática – GPR 12
IMPORTANTE:
• (a) Como item da ata, deixe evidenciado
claramente: “O plano do projeto foi revisado
com todos os membros da equipe do projeto e
os mesmos se comprometeram com o
desenvolvimento do escopo do projeto e com
os prazos apresentados”.
• (b) Todos os participantes da reunião devem
apontar horas no respectivo item de escopo
(ex. Reunião de kickoff do projeto)

GPR 13. O escopo, as tarefas, as estimativas, o
orçamento e o cronograma do projeto são monitorados
em relação ao planejado

• O gerente do projeto deverá utilizar de relatórios
e gráficos para auxiliá-lo no monitoramento do
projeto (gráfico de gantt, relatórios previsto x
real, relatório de status do projeto). Através
desses relatórios é possível monitorar o
planejado, o realizado e a variação entre ambos.
IMPORTANTE: O gerente do projeto deve evidenciar este
monitoramento através de apontamentos de horas sobre um
atividade do projeto (ex.: Monitoramento e controle do
projeto)

GPR 14, 15, 16 e 17. Os recursos materiais e humanos
bem como os dados relevantes do projeto são monitorados
em relação ao planejado; Os riscos são monitorados em
relação ao planejado; O envolvimento das partes
interessadas no projeto é planejado, monitorado e mantido;
Revisões são realizadas em marcos do projeto e conforme
estabelecido no planejamento

• O monitoramento e controle de recursos, riscos,
comunicação e revisões pode ser feito através de
status report periódicos (semanal, quinzenal...).
Outra prática é o registro e acompanhamento de
problemas (issues).

Boa prática – GPR 14, 15, 16 e 17

Boa prática: Gere um status reporte semanal e
armazene o mesmo na base de documentos do
projeto. Desta forma é possível armazenar o
histórico do projeto.

O gerente do projeto deve evidenciar este
acompanhamento através de apontamentos de horas
sobre um atividade do projeto (ex.: Monitoramento e
controle do projeto ou geração de status report)

Boa prática – GPR 14, 15, 16 e 17

GPR 18 e 19. Registros de problemas identificados e o
resultado da análise de questões pertinentes, incluindo
dependências críticas, são estabelecidos e tratados com as
partes interessadas; Ações para corrigir desvios em relação
ao planejado e para prevenir a repetição dos problemas
identificados
são
estabelecidas,
implementadas
e
acompanhadas até a sua conclusão

• Para estes dois itens, é necessário fazer o registro
dos problemas das ações corretivas necessárias
para a correção do problema.

MPS.Br G – Gerência de Requisitos - GRE
• Propósito:
o O propósito do processo Gerência de Requisitos é
gerenciar os requisitos do produto e dos componentes
do produto do projeto e identificar inconsistências
entre os requisitos, os planos do projeto e os produtos
de trabalho do projeto.

GRE 1. O entendimento dos requisitos é obtido junto
aos fornecedores de requisitos
• Utilize uma ferramenta case (ex.: Enterprise
Architect) para especificação dos requisitos do
projeto e encaminhe para seu cliente as referidas
especificações para validação.
• Boa prática: Envie o documento de especificação
através de um e-mail e obtenha, de maneira
formal, a validação/entendimento dos requisitos
por parte do fornecedor de requisitos

Boa prática - GRE 1: Defina e explicite no projeto
quem será o fornecedor de requisitos

Boa prática - GRE 1: Encaminhe o documento de
requisitos para o Fornecedor fazer a validação. Não
esqueça de obter a validação formalizada em um e-mail

Boa prática - GRE 1: Anexe o documento de
especificação e o e-mail de validação como uma
evidencia do projeto na base de documentos

GRE 2. Os requisitos são avaliados com base em
critérios objetivos e um comprometimento da equipe
técnica com estes requisitos é obtido
• Faça uma reunião entre o analista de requisitos e
a equipe do projeto. Nesta reunião é feita a
apresentação do documento de requisitos, a
equipe faz o entendimento e se compromete
formalmente com o desenvolvimento dos mesmos
• Anexe o conteúdo desta reunião junto ao projeto
como uma evidência

Boa prática - GRE 2: Reunião de apresentação de
avaliação dos requisitos junto a equipe do projeto

Sugestão de texto para evidenciar o entendimento e o
comprometimento da equipe: “A equipe do projeto fez o
entendimento e a validação dos requisitos apresentados e se
comprometeram com o desenvolvimento dos mesmos e com os
prazos apresentados no cronograma."
É importante registrar o entendimento e o comprometimento da
equipe bem como garantir que todos os participantes da reunião
façam o apontamento de horas sobre a atividade correspondente
no cronograma do projeto

Boa prática - GRE 2: Use critérios objetivos para
avaliar os requisitos junto a equipe
• Critérios objetivos:
• Checklist de validação
o O requisito está claro ?
o O requisito é atômico ?
o O requisito é contraditório ?

• Revisão aos pares
• Análise de complexidade (usando
Delphi,
por
exemplo
http://pt.wikipedia.org/wiki/M%C3%A9todo_Delphi)

método
-

GRE 2 - IMPORTANTE: Solicitação de mudanças
• Sempre que uma mudança nos requisitos é feita
pelo fornecedor de requisitos, um processo de
solicitação de mudanças deve ser executado e as
práticas do GRE 2 devem ser refeitas sobre
aqueles requisitos que sofreram a mudança (ou
sobre aqueles requisitos que foram adicionados
no projeto).

Boa prática - GRE 2: Processo de Solicitação de
Mudanças
• Estabeleça um processo que auxilie sua equipe na
definição do escopo de trabalho para o
projeto, identificando as necessidades do cliente e
promovendo a rastreabilidade entre o requisito de
negócio e o pacote de trabalho na EAP do projeto
• Garante que as horas investidas neste processo
sejam devidamente registradas no cronograma do
projeto em uma atividade correspondente (ex.:
Gestão e controle de mudanças do projeto)

Boa prática - GRE 2: Processo de Solicitação de
Mudanças

Boa prática - GRE 2: Para apoiar o processo, crie um
formulário para registro das necessidades do cliente e
definição da mudança

Boa prática - GRE 2: Linha de base do projeto
• Após a aprovação e a aplicação da mudança no
projetos (atualização da especificação, atualização
do cronograma, execução das devidas reuniões
de apresentação da mudança para equipe), é
fundamental que uma nova linha de base seja
gerada para o projeto.

Boa prática - GRE 2: Linha de base do projeto

GRE 3. A rastreabilidade bidirecional entre os
requisitos e os produtos de trabalho é estabelecida e
mantida
• Utilize uma ferramenta case (ex.: Enterprise
Architect) que disponibilize algum instrumento de
rastreabilidade entre os elementos utilizados para
especificação dos requisitos (e: Matriz de
rastreabilidade)
• A rastreabilidade deverá ser promovida desde o
registro da nova demanda até o código gerado
para desenvolvimento desta demanda.

Boa prática - GRE 3: Promovendo a rastreabilidade
entre o registro da demanda e o código-fonte.
No cronograma do projeto, as atividades (e tarefas)
também conterão um prefixo que promova a
rastreabilidade: “AT.001.1.1 – Nome da atividade”
Os requisitos funcionais e os não Neste caso o código 001.1 indica que essa é uma
funcionais
atividade ligada ao requisito funcional 1 do
gerados a partir dos requisitos de negócio podem
requisito de
Especificação dos
ter o prefixo: RF.001.1 – Nome do requisito não negócio 001.
requisitos
funcional (RNF.001.1 para os requisitos não
Processo de registro
funcionais). Neste caso o código 001 indica que
da nova demanda
esse requisito funcional é um requisito derivado do
A rastreabilidade entre o código-fonte e os
requisito de negócio 001.
requisito dar-se-á pelo nome Utilize um prefixo no nome do requisito de negócio
da classe na
ferramenta IDE (e: Eclipse) e o nome da classe no
para que seja possível promover a rastreabilidade.
modelo de classes da especificação do RN.001 – Nome do requisito de negócio
Ex.: requisito na
ferramenta case (e: EA)

Projeto

Código Fonte

GRE 4. Revisões em planos e produtos de trabalho do
projeto são realizadas visando identificar e corrigir
inconsistências em relação aos requisitos
• Garanta que os planos e produtos de trabalho do
projeto sejam revisados
e quando alguma
inconsistência é encontrada, registre a mesma e
promova ações para resolver tais problemas.

Boa prática – GRE 4:
•

Armazene a ata de reunião de kickoff do projeto, onde a
equipe validou os requisitos e se comprometeu com o
desenvolvimento dos mesmos

•

Registre toda solicitação de mudança e garanta que o
projeto reflita essa mudança caso aprovada

•

Registre no projeto todos os problemas e as ações para
resolver esses problemas (com datas e responsáveis)

•

Garanta que os envolvidos, tanto na reunião de kickoff,
quanto no processo de mudança de requisitos façam os
apontamentos de horas nas respectivas atividades do
projeto.

GRE 5. Mudanças nos requisitos são gerenciadas ao
longo do projeto
•

Garanta que toda mudança siga o processo de solicitação
de mudanças e que, após a atualização do projeto em
função da mudança, uma nova linha de base seja gerada.

•

É importante guardar a evidência que mostra a validação
e aceitação do fornecedor de requisitos para cada
solicitação de mudança realizada no projeto.

•

Importante: Os envolvidos neste processo devem apontar
horas nas respectivas atividades do projeto.

MPS.Br Nível G – Capacidade do Processo
•

CAPACIDADE DO PROCESSO

o A capacidade do processo é representada por um
conjunto de atributos de processo descrito em termos
de resultados esperados;
o Os diferentes níveis de capacidade dos processos são
descritos por nove atributos de processo (AP);
o O alcance de cada atributo de processo é avaliado
utilizando os respectivos resultados esperados de
atributo de processo (RAP).

• AP 1.1 O processo é executado
• Este atributo evidencia o quanto o processo atinge o
seu propósito.
• Resultado esperado:
• RAP 1. O processo atinge seus resultados definidos.

Todas as evidências apresentadas anteriormente asseguram
que o processo transforma produtos de trabalho de entrada
identificáveis em produtos de trabalho de saída, também
identificáveis.

• AP 2.1 O processo é gerenciado
• Este atributo evidencia o quanto a execução do
processo é gerenciada.
• RAP 2. Existe uma política organizacional estabelecida
e mantida para o processo
A política organizacional deve ser definida, mantida e
disponibilizada para todos da empresa. Crie um plano de
comunicação da política para todos os colaboradores da
empresa e evidencie que esse plano foi executado (crie um
plano com ações no Channel, por exemplo) e garanta que
todos apontaram horas para evidenciar sua participação
neste plano.

• RAP 3. A execução do processo é planejada
Documente
os
processos
organizacionais
(nova
demanda, solicitação de mudança, gestão de projetos...) e
depois demostre que os processos são implementados e
executados através dos artefatos produzidos no Channel
(processos, formulários, cronograma do projeto, marcos de
controle, planos e apontamentos de horas da equipe)

• RAP 4. A execução do processo é monitorada e ajustes
são realizados
Demostre, através dos status reports gerados e armazenados
no projeto dentro do Channel, bem como o apontamento de
horas na atividade de “Monitoramento e Controle do Projeto”
que a execução do processo é monitorada. Os ajustes
podem ser demonstrados através de questões pendentes e
suas ações. Apresente também o cronograma com o número
de horas realizadas e o percentual de conclusão do projeto.

• RAP 5. As informações e os recursos necessários para
a execução do processo são identificados e
disponibilizados
• Crie um inventário de hardware e software institucional;
• Crie uma planilha com todos os papéis e competências disponíveis na
empresa;
• Disponibilize esses documentos para todos da empresa e
demostre, no cronograma do projeto, que os recursos contendo os
papéis definidos nos documentos institucionais estão alocados no
projeto

IMPORTANTE: Sobre RAP 5
• Todos os documentos institucionais criados para atender
ao MPS.Br podem ser disponibilizados no Channel

IMPORTANTE: Sobre RAP 5
• Garanta que todos os hardwares, softwares e os papéis e
competências utilizados nos projetos estão catalogados no
documento institucional

• RAP 6. As responsabilidades e a autoridade para
executar o processo são definidas, atribuídas e
comunicadas
Apresentar o termo de abertura do projeto, a relação dos papéis e
atribuições do projeto e a ata da reunião de kickoff que poderá constar
que “Todos os membros da equipe conhecem e concordam com o
organograma do projeto, apresentado durante a reunião de kickoff”

• RAP 7. As pessoas que executam o processo são
competentes em termos de formação, treinamento e
experiência
Crie um projeto no Channel para treinamento de todos os colaboradores a
respeito dos processos institucionais relacionados ao MPS.Br. Todos
devem apontar horas neste projeto para evidenciar a participação neste
treinamento. Além disso, disponibilize o currículo de todos os
colaboradores da base de documentos institucionais, dentro do Channel e
certifique-se que os currículos dos colaboradores estejam alinhados aos
seus papéis e suas competências do respectivo documento institucional.

• RAP 8. A comunicação entre as partes interessadas no
processo é planejada e executada de forma a garantir o
seu envolvimento
Apresente o plano de comunicação do projeto, a evidência das trocas de
e-mails com os fornecedores de requisitos e com demais stakeholders e
os status reports.

• RAP 9. Os resultados do processo são revistos com a
gerência de alto nível para fornecer visibilidade sobre a
sua situação na organização
Faça reuniões periódicas entre os gerentes de projetos e a direção da
empresa para discutir melhorias e evoluções do processo. Registre as
ações e decisões decorrentes destas reuniões e garanta que os
participantes apontem horas para evidenciar a participação na reunião
Além disso, crie um projeto de implantação do MPS.Br no Channel e faça
que todos os participantes apontem horas para evidenciar a execução do
projeto

• RAP 10. O processo planejado para o projeto é
executado.
Apresente as atividades de Planejamento, Monitoramento e
Controle do cronograma do projeto e seus respectivos
apontamentos de horas (feito pelo gerente). Além dos
apontamentos, apresente o número de horas realizadas e o
percentual concluído do projeto

Boas práticas para implementação Mps.br utilizando a ferramenta Channel

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Boas práticas para implementação Mps.br utilizando a ferramenta Channel

Similaire à Boas práticas para implementação Mps.br utilizando a ferramenta Channel (20)

Boas práticas para implementação Mps.br utilizando a ferramenta Channel