Treinamento Capacitação da equipe em mps.br

1. Treinamento MPS.Br
Nível G- Gerência de Projetos e Requisitos

2. Origem - MPS.Br

3. CMMI
● Criado pela SEI (Software Engineering
Institute)
● Modelo para melhoria de processos de
desenvolvimento de produtos e serviços
● 5 níveis de maturidade

4. CMMI - Níveis de Maturidade

5. ISO/IEC 12207
● Fornece uma arquitetura de alto nível
para ciclo de vida de software, desde a
concepção até sua descontinuidade.
○ Definido em processos, atividades e tarefas
para aquisição, fornecimento,
desenvolvimento, operação e manutenção
de software.

6. ISO/IEC 12207

7. ISO/IEC 15504
Framework para:
- Avaliação de Processo
- Melhoria de Processo
Contextos:
- Melhoria Contínia:
● avaliação identifica oportunidades de melhoria
- Determinação da Capacidade:
● avaliação identifica riscos com o fornecedor

8. ISO/IEC 15504
● Prover uma referência padronizada para
avaliação de processos
● Deve ser usada em conjunto com um
Modelo de Referência de processos.

9. Motivação - MPS.Br
Em 2003, dados do Ministério de Ciência e
Tecnologia apontaram:
- 30 empresas no Brasil possuíam avaliação
CMM.
● 24 no nível 2;
● 5 no nível 3;
● 1 no nível 4; e
● nenhuma no nível 5.

10. Problema
Como melhorar processo de software no
Brasil a um custo acessível?

11. Objetivos do MPS.Br
● Melhoria de Processo de Software em todo o
país, a um custo acessível
● Definir um modelo que esteja em
conformidade com normas e padrões
internacionais
● Definir um modelo de avaliação que seja mais
flexível e de acordo com a realidade brasileira

12. Por que o foco está no processo?
Porque problemas no processo
provavelmente geram defeitos no produto!

13. Motivação para o foco no
Processo de Software
● Qualidade do processo
- Aumento da qualidade do produto
- Diminuição do retrabalho
- Maior produtividade
- Redução do tempo para atender o mercado
- Maior competitividade
- Maior precisão nas estimativas

14. Características de Processo
Imaturo
● Características:
- Ad hoc - Improvisado
- Fortemente dependente dos profissionais
- Indisciplinado
● Consequências:
- Pouca produtividade
- Qualidade de difícil previsão
- Alto custo de manutenção
- Risco na adoção de novas tecnologias

15. Características de processo
Maduro
● Processo conhecido por todos
● Apoio visível da alta administração
● Auditagem da fidelidade ao processo
● Medidas do produto e do processo
● Adoção disciplinada de Tecnologias

16. Características de processo
Maduro
● Papéis e responsabilidades claramente
definidos
● Acompanhamento da qualidade do
produto e da satisfação do cliente
● Expectativas para custos, cronograma,
funcionalidades e qualidade do produto
são usualmente alcançadas.

17. O que é um processo?

18. Processo
"Conjunto de atividades inter-relacionadas
que transforma entradas em saídas" [ABNT,
1998]
Composto de:
- Propósito: o principal objetivo da execução do processo
e os prováveis resultados obtidos com sua efetiva
implementação.
- Resultados: resultado observável do sucesso do alcance
do propósito do processo [ISO/IEC 12207:2008]

19. Nível de maturidade - MPS.Br
● Grau de melhoria de processo para um pré-
determinado conjunto de processos no qual
todos os objetivos dentro do conjunto são
atendidos [ISO/IEC 15504-1, 2004]
● 7 Níveis:
A. Em otimização
B. Gerenciado quantitativamente
C. Definido
D. Parcialmente definido
F. Gerenciado
G. Parcialmente gerenciado

20. Níveis de Maturidade

21. CMMI x MPS.Br

22. Processo Requisito

23. Gerencia 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.

24. GPR1 - O escopo do trabalho para o projeto é
definido
● Escopo
● Não Escopo
● Restrições
● Objetivos
● Todos os produtos que serão entregues

25. GPR2 - As tarefas e o produtos de trabalho
do projeto são dimensionados utilizando
métodos apropriados
● Método de estimativa
● Detalhamento do Escopo ou não
● Tamanho do projeto

26. GPR3- O modelo e as fases do ciclo de vida do
projeto são definidos
● Incremental ou cascata, por exemplo
● Apresentar as fases e principais produtos
● Facilita a definição de marcos
importantes

27. GPR4 - O esforço e o custo para execução das
tarefas e dos produtos de trabalho são estimados
com base em dados históricos ou referências
técnicas (até nível F)
● Método de estimativa
● Gerência + Equipe

28. GPR5 - O orçamento e o cronograma do projeto,
incluindo marcos e/ou pontos de controle, são
estabelecidos e mantidos
● Definição das atividades com início,
duração e término.
● Recursos são alocados e o custo
contabilizado.
● Definir pontos de controle, nos quais o
orçamento e cronograma é revisto.

29. GPR6 - Os riscos do projeto são identificados e o seu
impacto, probabilidade de ocorrência e prioridade de
tratamento são determinados e documentos
● Riscos identificados, com impacto,
probabilidade e prioridade de
tratamento.
● O acompanhamento dos riscos deve ser
registrado, bem como as ações tomadas

30. GPR7 - Os recursos humanos para o projeto são
planejados considerando o perfil e conhecimento
necessários para executá-lo;
● Mapa de competências
● Currículos
● Identificação de treinamentos

31. GPR8 - As tarefas, os recursos e o ambiente de
trabalho necessários para executar o projeto são
planejados
● Recursos para execução de cada tarefa,
mesmos os já existentes;
● Recursos especiais;

32. GPR9 - 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
● Plano do projeto, Backlog do produto,
Ata de Reunião, artefatos, etc...
● Controle de acesso
● Identificar dados confidenciais
● Estabeler sistema

33. GPR10 - Um plano geral para a execução do
projeto é estabelecido com a integração de
planos específicos
Plano de projeto contendo escopo,
cronograma, viabilidade, recursos, etc..

34. GPR11 - A viabilidade de atingir as metas do projeto,
considerando as restrições e os
recursos disponíveis, é avaliada. Se necessário, ajustes
são realizados;
● Monitoramento da viabilidade em pontos
de controle
● Análise de viabilidade quando houver
mudança de escopo
● Definição de critérios para viabilidade
● Pontos para se fazer análise de
viabilidade (escopo, aspectos técnicos,
financeiros, humanos,restrições)

35. GPR - 12 O plano do projeto é revisado com
todos os interessados e o compromisso com ele
é obtido
● Envolvidos relevantes – Revisão
● Compromisso – Todos (custos,
cronograma e desempenho) – Kick off

36. GPR13 - O escopo, as tarefas, as estimativas, o
orçamento e o cronograma do projeto são
monitorados em relação ao planejado
● Previsto x realizado
● Cumprimento de marcos
● Esforço, cronograma, recursos,
orçamento, estimativas.

37. GPR14 - Os recursos materiais e humanos bem como os
dados relevantes do projeto são monitorados em
relação ao planejado
● Previsto x realizado
● Cumprimento de marcos
● Pessoas previstas
● Aumento de equipe
● Inclusão de dados relevantes

38. GPR15 - Os riscos são monitorados em relação
ao planejado
● Variação do mapa de riscos de acordo
com os relatórios de acompanhamento
● Ações devem ser planejadas (GPR18 e
GPR19) para corrigir os problemas.

39. GPR16 - O envolvimento das partes interessadas
no projeto é gerenciado
● Plano de comunicação
○ Comunicação envolve: Prazos, custos,
recursos, requisitos, comprometimento.
● Cronograma

40. GPR17 - Revisões são realizadas em marcos do
projeto e conforme estabelecido no
planejamento
● Não confundir com acompanhamento
GPR13
● Pode ocorrer no início ou fim de uma
fase
● Geralmente, analisa-se a viabilidade
● Presença de patrocionadores

41. GPR18 - Registros de problemas identificados e o
resultado da análise de questões pertinentes, incluindo
dependência críticas, são estabelecidos e tratados com
as partes interessadas
● Template para identificação de
problemas
● Dados do GPR13, 14, 15 e 17 são
analisados
● Problemas são identificados, analisados e
registrados

42. GPR19 - 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é sua conclusão
● Monitoramento das ações corretivas
● Avaliar a efetividade da ação corretiva

43. Gerência de Requisitos
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.
● 5 Resultados

44. GRE1 - O entendimento dos requisitos é
obtido junto aos fornecedores de requisitos
● Validação de requisitos com a origem
"Esse registro pode ser tratado como um marco do projeto
a partir do qual mudanças nos requisitos devem ser
tratadas formalmente para minimizar o impacto dessas
mudanças no projeto em termos de escopo, estimativas e
cronograma, bem como compromissos já estabelecidos"

45. GRE2 - os requisitos são avaliados com base em
critérios objetivos e um comprometimento da
equipe técnica com estes requisitos é obtido
● Requisitos apresentados a Equipe na
reunião de kick-off
● Novo comprometimento caso haja
mudança nos requisitos
"Além disso, um comprometimento formal da equipe
técnica com os requisitos deve ser obtido e registrado,
por exemplo, na forma de ata de reunião, e-mail ou
algum outro mecanismo."

46. GPR3 - A rastreabilidade bidirecional entre os
requisitos e os produtos de trabalho é
estabelecida e mantida
Rastreabilidade horizontal: requisito x requisito
Rastreabilidade vertical: requisito x artefatos
"Ter definida a rastreabilidade facilita a avaliação do
impacto das mudanças de requisitos que possam
ocorrer, por exemplo, nas estimativas do escopo, nos
produtos de trabalho ou nas tarefas do projeto descritas
no cronograma."

47. GRE4 - Revisões em planos e produtos de trabalho do
projeto são realizadas visando a identificar e corrigir
inconsistências em relação aos requisitos
● Identificar inconsistências
● Planejar ações corretivas
● Pode ser verificado no marco do projeto
"A consistência entre os requisitos e os produtos de
trabalho do projeto deve ser avaliada e os problemas
identificados devem ser corrigidos."

48. GRE5 - Mudanças nos requisitos são
gerenciadas ao longo do projeto
● Necessidades de mudanças devem ser
registradas
● Análise de impacto + Rastreabilidade
"Durante o projeto, os requisitos podem mudar por
uma série de motivos. Desta forma, requisitos
adicionais podem ser incorporados no projeto, requisitos
podem ser retirados do projeto e/ou mudanças podem
ser feitas nos requisitos já existentes. Ressalta-se
que, devido às mudanças, os requisitos podem ter
que ser revistos, conforme definido no GRE4."