SlideShare a Scribd company logo
1 of 49
Download to read offline
Mpsbr
 Maturidade e Capabilidade do Processo de
Software: Definição
 Modelo: Definição
 MPS.BR: O Modelo
 MPS.BR: Capacidade do Processo
 Processos do Nível G, primeiro nível do modelo
 Método de Avaliação (MA-MPS) para o Nível G
Mpsbr
 Processo – um conjunto de atividades inter-relacionadas,
que transforma entradas em saídas (ABNT, 1998)
 Processo de Software – um conjunto de atividades,
métodos, práticas e transformações que as pessoas
utilizam para desenvolver e manter software e seus
produtos relacionados (CMMI)
 A qualidade do sistema de software é altamente
influenciada pela qualidade do processo ou maturidade
utilizado para seu desenvolvimento e sua manutenção.
 Esta premissa implica em um foco no processo,
bem como no produto.
 Focando somente no produto são perdidos:
◦ O conhecimento de como executar da melhor forma.
◦ A ideia de tamanho e complexidade (de projeto, de
problemas, de esforços, etc.).
 Focando no processo são previsíveis:
◦ Repetibilidade dos resultados.
◦ Tendências dos projetos.
◦ Características do produto (custo, qualidade, esforço e
tempo).
Modelo é uma representação
simplificada do mundo real.
 Estabelece uma linguagem comum.
 Estabelece uma visão em níveis.
 Provê uma estrutura para priorização de ações.
 Agrega as melhores práticas de uma ampla comunidade
de software.
 Provê uma estrutura para desempenhar diagnósticos
(appraisals) consistentes e confiáveis.
 Suporta as organizações (reativa → pró-ativa)
 Modelos são simplificações do mundo real.
 Modelos não são completos / abrangentes.
 Sua interpretação e adaptação (CMMI-tailoring) devem
estar alinhadas com os objetivos (estratégia) dos
negócios da organização.
 Análises e Julgamentos são necessários para utilizar os
modelos corretamente e com perspicácia.
 O modelo não deve ser considerado como uma “bíblia”.
 “Toda empresa ou indivíduo que desenvolve software já faz isso
por meio de algum processo. Esse processo pode ser caótico,
obscuro e até mudar constantemente, mas não deixa de ser um
processo. E isso nada mais é do que uma sequencia de atividades.
Mesmo que você não se dê conta disto, tudo que você faz no
trabalho de desenvolvimento de software segue uma sequencia de
atividades. Às vezes essa sequencia não é fixa. Às vezes essa
sequencia não segue uma ordem lógica. Às vezes essa sequencia
provoca algum retrabalho. Mas perceba que sempre existirá uma
sequencia. Às vezes essa sequencia já é eficiente, mas ninguém
mais além de você sabe como funciona. Um modelo de maturidade
de processos serve para corrigir esses e muitos outros problemas.”
 CMM
 CMM
Processo continuamente
melhorado
Processo previsível e controlado
Processo consistente e padronizado
Processo disciplinado
1- Inicial
2- Repetível
3- Definido
4- Gerenciado
5- Otimizado
Processo imprevisível e sem controle
 CMM
 CMMI
 CMM
Mpsbr
 Visa a melhoria de processos de software em
empresas brasileiras, a um custo acessível,
especialmente na grande massa de micro,
pequenas e médias empresas.
 Micro e Pequenas Empresas (MPEs)
Tipo Receita Bruta Anual
Microempresa
Igual ou inferior a R$ 240.000,00
(duzentos e quarenta mil reais)
Empresa de Pequeno Porte
Superior a R$ 240.000,00 (duzentos e quarenta mil
reais) e igual ou inferior a R$ 2.400.000,00 (dois
milhões e quatrocentos mil reais).
Tipo Receita Bruta Anual
Microempresa
Igual ou inferior a R$ 360.000,00
(trezentos e sessenta mil reais)
Empresa de Pequeno Porte
Superior a R$ 360.000,00 (trezentos e sessenta mil
reais) e igual ou inferior a R$ 3.600.000,00 (três milhões
e seiscentos mil reais).
Reajuste em
10/11/2011
Valerá em
01/01/2012
 “Define e aprimora um modelo de melhoria e
avaliação de processo de software, visando
preferencialmente as micro, pequenas e médias
empresas, de forma a atender as suas
necessidades de negócio e ser reconhecido
nacional e internacionalmente como um modelo
aplicável à indústria de software.”
 MPS.BR também estabelece um processo e
um método de avaliação, o qual dá
sustentação e garante que o MPS.BR está sendo
empregado de forma coerente com as suas
definições.
 O propósito do Programa MPS.BR é a Melhoria de Processo do
Software Brasileiro, compreendendo 2 processos:
◦ Desenvolvimento e aprimoramento do Modelo MPS:
 Baseado nas melhores práticas da Engenharia de Software
 Em conformidade com as normas ISO/IEC 12207 E ISO/IEC 15504
 Compatível com o modelo CMMI, do SEI/CMU
 Adequado à realidade das empresas brasileiras
◦ Disseminação e adoção do Modelo MPS, a um custo razoável, em
todas as regiões do país
 Tanto em pequenas e médias empresas (PME)
 Como em grandes organizações públicas e privadas
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Níveis de maturidade
Processo Capacidade
Propósito
Atributo de
Processo
AP
Resultados Resultados
Práticas
Atributo de
Processo é uma
característica
mensurável da
capacidade do
processo
aplicável a
qualquer
processo
[ISO/IEC 15504-
1, 2003] RAP – Resultado do
Atributo do Processo
Cada AP está
detalhado em
termos dos
resultados para
alcance completo do
atributo (RAP)
Em OtimizaçãoEm Otimização
Gerenciado QuantitativamenteGerenciado Quantitativamente
DefinidoDefinido
Largamente DefinidoLargamente Definido
Parcialmente DefinidoParcialmente Definido
GerenciadoGerenciado
Parcialmente GerenciadoParcialmente Gerenciado
AA
BB
CC
DD
EE
FF
G
2
3
4
5
Relacionamento
com o CMMI
MR-MPS
Mpsbr
Mpsbr
Mpsbr
 Processos básicos de gerenciamento de projetos são estabelecidos para
monitoramento de custo, prazo e funcionalidade.
 É necessário uma disciplina do processo que seja adequada para repetir
sucessos anteriores em projetos com aplicações similares.
 Principais características:
◦ Garantia que os requisitos são gerenciados
◦ Processos são planejados, desempenhados, medidos e controlados
◦ As práticas são mantidas em período de crise
◦ Projetos são desempenhados e gerenciados conforme planos documentados
◦ O controle gerencial permite a visibilidade em ocasiões definidas (“milestones”)
◦ Compromissos estabelecidos e revisados com stakeholders relevantes
◦ Produtos de trabalhos apropriadamente controlados
 O propósito da GRE é gerenciar os requisitos dos produtos do
projeto e componentes do produto e identificar inconsistências entre
estes requisitos e os planos de projeto e produtos de trabalho.
 Envolve:
◦ Obtenção e entendimento dos requisitos;
◦ Obter os compromissos para atendimento dos requisitos;
◦ Gerenciar mudanças de requisitos;
◦ Manter rastreabilidade bidirecional dos requisitos (da origem dos
requisitos para o nível mais baixo de detalhamento e vice-versa)
◦ Identificar inconsistência entre produtos de trabalho e requisitos.
 Existência de uma gerência adequada dos conjuntos de requisitos para
suportar o planejamento e necessidades de execução do projeto.
 Os requisitos são analisados criticamente com o provedor dos requisitos
(requirements provider) para solucionar questões e mal entendimentos
antes de sua incorporação nos planos de projeto.
 Obtenção dos compromissos sobre os requisitos dos participantes do
projeto.
 Gerência nas mudanças dos requisitos quando envolvem ou são
identificadas inconsistências ocorridas nos planos, produtos de trabalho
e requisitos.
 Os requisitos alocados, a engenharia de software por exemplo,
devem ser documentados.
 A documentação, dependendo do tamanho e complexidade do
projeto, pode ser de forma simples (memorando) ou elaborada
(vários documentos do cliente).
 Se os requisitos mudam, estas mudanças devem ser documentadas
e os documentos relacionados também, devendo ser
acompanhados e verificados.
Mpsbr
 O processo é executado
◦ Medida do quanto o processo atinge seu propósito.
 Resultado esperado:
◦ RAP 1. O processo atinge seus resultados definidos.
 O processo é gerenciado
◦ Medida do quanto a execução do processo é gerenciada.
 Resultados esperados:
◦ RAP 2. Existe uma política organizacional estabelecida e mantida para
o processo;
◦ RAP 3. A execução do processo é planejada;
◦ RAP 4 (Para o Nível G). A execução do processo é monitorada e
ajustes são realizados;
◦ RAP 5. (Até o Nível F) As informações e os recursos necessários para
a execução do processo são identificados e disponibilizados;
◦ RAP 6. (Até o Nível F) As responsabilidades e a autoridade para
executar o processo são definidas, atribuídas e comunicadas.
 Resultados esperados (cont.):
◦ RAP 7. (Até o Nível F) As pessoas que executam o processo são
competentes em termos de formação, treinamento e experiência;
◦ RAP 8. A comunicação entre as partes interessadas no processo
é gerenciada de forma a garantir o seu envolvimento;
◦ RAP 9. (Até o Nível F) 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.
◦ RAP 10 (Para o Nível G). O processo planejado para o projeto é
executado.
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Mpsbr
Mpsbr

More Related Content

What's hot

Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Luís Fernando Richter
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Elaine Cecília Gatto
 
MPS Br Nível F - Gerência de Configuração - GCO
MPS Br Nível F - Gerência de Configuração - GCO MPS Br Nível F - Gerência de Configuração - GCO
MPS Br Nível F - Gerência de Configuração - GCO Vanilton Pinheiro
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de SoftwareCapgemini
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de softwareRondinelli Mesquita
 
Introdução a Gerência de Configuração
Introdução a Gerência de ConfiguraçãoIntrodução a Gerência de Configuração
Introdução a Gerência de ConfiguraçãoIgor Takenami
 
Trabalho sobre a ISO/IEC 15504
Trabalho sobre a ISO/IEC 15504Trabalho sobre a ISO/IEC 15504
Trabalho sobre a ISO/IEC 15504Ricardo Zalla
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de RequisitosPaulo Furtado
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitosMailson Queiroz
 
Métricas de Software
Métricas de SoftwareMétricas de Software
Métricas de Softwareelliando dias
 
Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3Elaine Cecília Gatto
 
Introdução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de SoftwareIntrodução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de SoftwareCamilo Almendra
 

What's hot (20)

Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
MPS Br Nível F - Gerência de Configuração - GCO
MPS Br Nível F - Gerência de Configuração - GCO MPS Br Nível F - Gerência de Configuração - GCO
MPS Br Nível F - Gerência de Configuração - GCO
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Introdução a Gerência de Configuração
Introdução a Gerência de ConfiguraçãoIntrodução a Gerência de Configuração
Introdução a Gerência de Configuração
 
Trabalho sobre a ISO/IEC 15504
Trabalho sobre a ISO/IEC 15504Trabalho sobre a ISO/IEC 15504
Trabalho sobre a ISO/IEC 15504
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Conhecendo o Django
Conhecendo o DjangoConhecendo o Django
Conhecendo o Django
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
 
Introdução ao Teste de Software
Introdução ao Teste de SoftwareIntrodução ao Teste de Software
Introdução ao Teste de Software
 
Introdução à sistemas distribuídos
Introdução à sistemas distribuídosIntrodução à sistemas distribuídos
Introdução à sistemas distribuídos
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Métricas de Software
Métricas de SoftwareMétricas de Software
Métricas de Software
 
Mps.br
Mps.brMps.br
Mps.br
 
Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3
 
Introdução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de SoftwareIntrodução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de Software
 

Similar to Mpsbr

Mps br final - mps
Mps br final - mpsMps br final - mps
Mps br final - mpsEdvaldo Cruz
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Fernando Vargas
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL Gjrnavarro
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiroingrid_fatec
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxRoberto Nunes
 
FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010nathan85
 
Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001elliando dias
 
Gerência de Projetos de Software com RUP, CMM e ISO 9001
Gerência de Projetos de Software com RUP, CMM e ISO 9001Gerência de Projetos de Software com RUP, CMM e ISO 9001
Gerência de Projetos de Software com RUP, CMM e ISO 9001elliando dias
 
Indicadores de políticas públicas e métricas de software: uma visão em paralelo
Indicadores de políticas públicas e métricas de software: uma visão em paraleloIndicadores de políticas públicas e métricas de software: uma visão em paralelo
Indicadores de políticas públicas e métricas de software: uma visão em paraleloRoberto de Pinho
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraqualityquality
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraqualityquality
 
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
Artigo   asap - metodologia de gestão de projetos para implementação de pacot...Artigo   asap - metodologia de gestão de projetos para implementação de pacot...
Artigo asap - metodologia de gestão de projetos para implementação de pacot...Garage Criativa | Garage Hub
 
Adoção do CMMI e Metodologias Ágeis em Empresas Brasileiras
Adoção do CMMI e Metodologias Ágeis em Empresas BrasileirasAdoção do CMMI e Metodologias Ágeis em Empresas Brasileiras
Adoção do CMMI e Metodologias Ágeis em Empresas BrasileirasWildtech
 
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...Adson Wendel
 
GCS - Aula 08 - GCS x MPSBr
GCS - Aula 08 - GCS x MPSBrGCS - Aula 08 - GCS x MPSBr
GCS - Aula 08 - GCS x MPSBrMisael Santos
 
12 13 experiencias extraídas en dos décadas de mejor
12 13 experiencias extraídas en dos décadas de mejor12 13 experiencias extraídas en dos décadas de mejor
12 13 experiencias extraídas en dos décadas de mejorSoftware Guru
 

Similar to Mpsbr (20)

Mps br final - mps
Mps br final - mpsMps br final - mps
Mps br final - mps
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptx
 
FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010
 
Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001
 
Gerência de Projetos de Software com RUP, CMM e ISO 9001
Gerência de Projetos de Software com RUP, CMM e ISO 9001Gerência de Projetos de Software com RUP, CMM e ISO 9001
Gerência de Projetos de Software com RUP, CMM e ISO 9001
 
Qualidade do Software
Qualidade do SoftwareQualidade do Software
Qualidade do Software
 
Indicadores de políticas públicas e métricas de software: uma visão em paralelo
Indicadores de políticas públicas e métricas de software: uma visão em paraleloIndicadores de políticas públicas e métricas de software: uma visão em paralelo
Indicadores de políticas públicas e métricas de software: uma visão em paralelo
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação para
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação para
 
Cmmi e mps.Br
Cmmi e mps.BrCmmi e mps.Br
Cmmi e mps.Br
 
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
Artigo   asap - metodologia de gestão de projetos para implementação de pacot...Artigo   asap - metodologia de gestão de projetos para implementação de pacot...
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
 
Adoção do CMMI e Metodologias Ágeis em Empresas Brasileiras
Adoção do CMMI e Metodologias Ágeis em Empresas BrasileirasAdoção do CMMI e Metodologias Ágeis em Empresas Brasileiras
Adoção do CMMI e Metodologias Ágeis em Empresas Brasileiras
 
QUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWAREQUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWARE
 
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
 
GCS - Aula 08 - GCS x MPSBr
GCS - Aula 08 - GCS x MPSBrGCS - Aula 08 - GCS x MPSBr
GCS - Aula 08 - GCS x MPSBr
 
Aula 07 qs - cmmi
Aula 07   qs - cmmiAula 07   qs - cmmi
Aula 07 qs - cmmi
 
12 13 experiencias extraídas en dos décadas de mejor
12 13 experiencias extraídas en dos décadas de mejor12 13 experiencias extraídas en dos décadas de mejor
12 13 experiencias extraídas en dos décadas de mejor
 

Mpsbr

  • 2.  Maturidade e Capabilidade do Processo de Software: Definição  Modelo: Definição  MPS.BR: O Modelo  MPS.BR: Capacidade do Processo  Processos do Nível G, primeiro nível do modelo  Método de Avaliação (MA-MPS) para o Nível G
  • 4.  Processo – um conjunto de atividades inter-relacionadas, que transforma entradas em saídas (ABNT, 1998)  Processo de Software – um conjunto de atividades, métodos, práticas e transformações que as pessoas utilizam para desenvolver e manter software e seus produtos relacionados (CMMI)
  • 5.  A qualidade do sistema de software é altamente influenciada pela qualidade do processo ou maturidade utilizado para seu desenvolvimento e sua manutenção.  Esta premissa implica em um foco no processo, bem como no produto.
  • 6.  Focando somente no produto são perdidos: ◦ O conhecimento de como executar da melhor forma. ◦ A ideia de tamanho e complexidade (de projeto, de problemas, de esforços, etc.).  Focando no processo são previsíveis: ◦ Repetibilidade dos resultados. ◦ Tendências dos projetos. ◦ Características do produto (custo, qualidade, esforço e tempo).
  • 7. Modelo é uma representação simplificada do mundo real.
  • 8.  Estabelece uma linguagem comum.  Estabelece uma visão em níveis.  Provê uma estrutura para priorização de ações.  Agrega as melhores práticas de uma ampla comunidade de software.  Provê uma estrutura para desempenhar diagnósticos (appraisals) consistentes e confiáveis.  Suporta as organizações (reativa → pró-ativa)
  • 9.  Modelos são simplificações do mundo real.  Modelos não são completos / abrangentes.  Sua interpretação e adaptação (CMMI-tailoring) devem estar alinhadas com os objetivos (estratégia) dos negócios da organização.  Análises e Julgamentos são necessários para utilizar os modelos corretamente e com perspicácia.  O modelo não deve ser considerado como uma “bíblia”.
  • 10.  “Toda empresa ou indivíduo que desenvolve software já faz isso por meio de algum processo. Esse processo pode ser caótico, obscuro e até mudar constantemente, mas não deixa de ser um processo. E isso nada mais é do que uma sequencia de atividades. Mesmo que você não se dê conta disto, tudo que você faz no trabalho de desenvolvimento de software segue uma sequencia de atividades. Às vezes essa sequencia não é fixa. Às vezes essa sequencia não segue uma ordem lógica. Às vezes essa sequencia provoca algum retrabalho. Mas perceba que sempre existirá uma sequencia. Às vezes essa sequencia já é eficiente, mas ninguém mais além de você sabe como funciona. Um modelo de maturidade de processos serve para corrigir esses e muitos outros problemas.”
  • 12.  CMM Processo continuamente melhorado Processo previsível e controlado Processo consistente e padronizado Processo disciplinado 1- Inicial 2- Repetível 3- Definido 4- Gerenciado 5- Otimizado Processo imprevisível e sem controle
  • 17.  Visa a melhoria de processos de software em empresas brasileiras, a um custo acessível, especialmente na grande massa de micro, pequenas e médias empresas.
  • 18.  Micro e Pequenas Empresas (MPEs) Tipo Receita Bruta Anual Microempresa Igual ou inferior a R$ 240.000,00 (duzentos e quarenta mil reais) Empresa de Pequeno Porte Superior a R$ 240.000,00 (duzentos e quarenta mil reais) e igual ou inferior a R$ 2.400.000,00 (dois milhões e quatrocentos mil reais). Tipo Receita Bruta Anual Microempresa Igual ou inferior a R$ 360.000,00 (trezentos e sessenta mil reais) Empresa de Pequeno Porte Superior a R$ 360.000,00 (trezentos e sessenta mil reais) e igual ou inferior a R$ 3.600.000,00 (três milhões e seiscentos mil reais). Reajuste em 10/11/2011 Valerá em 01/01/2012
  • 19.  “Define e aprimora um modelo de melhoria e avaliação de processo de software, visando preferencialmente as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software.”
  • 20.  MPS.BR também estabelece um processo e um método de avaliação, o qual dá sustentação e garante que o MPS.BR está sendo empregado de forma coerente com as suas definições.
  • 21.  O propósito do Programa MPS.BR é a Melhoria de Processo do Software Brasileiro, compreendendo 2 processos: ◦ Desenvolvimento e aprimoramento do Modelo MPS:  Baseado nas melhores práticas da Engenharia de Software  Em conformidade com as normas ISO/IEC 12207 E ISO/IEC 15504  Compatível com o modelo CMMI, do SEI/CMU  Adequado à realidade das empresas brasileiras ◦ Disseminação e adoção do Modelo MPS, a um custo razoável, em todas as regiões do país  Tanto em pequenas e médias empresas (PME)  Como em grandes organizações públicas e privadas
  • 27. Níveis de maturidade Processo Capacidade Propósito Atributo de Processo AP Resultados Resultados Práticas Atributo de Processo é uma característica mensurável da capacidade do processo aplicável a qualquer processo [ISO/IEC 15504- 1, 2003] RAP – Resultado do Atributo do Processo Cada AP está detalhado em termos dos resultados para alcance completo do atributo (RAP)
  • 28. Em OtimizaçãoEm Otimização Gerenciado QuantitativamenteGerenciado Quantitativamente DefinidoDefinido Largamente DefinidoLargamente Definido Parcialmente DefinidoParcialmente Definido GerenciadoGerenciado Parcialmente GerenciadoParcialmente Gerenciado AA BB CC DD EE FF G 2 3 4 5 Relacionamento com o CMMI MR-MPS
  • 32.  Processos básicos de gerenciamento de projetos são estabelecidos para monitoramento de custo, prazo e funcionalidade.  É necessário uma disciplina do processo que seja adequada para repetir sucessos anteriores em projetos com aplicações similares.  Principais características: ◦ Garantia que os requisitos são gerenciados ◦ Processos são planejados, desempenhados, medidos e controlados ◦ As práticas são mantidas em período de crise ◦ Projetos são desempenhados e gerenciados conforme planos documentados ◦ O controle gerencial permite a visibilidade em ocasiões definidas (“milestones”) ◦ Compromissos estabelecidos e revisados com stakeholders relevantes ◦ Produtos de trabalhos apropriadamente controlados
  • 33.  O propósito da GRE é gerenciar os requisitos dos produtos do projeto e componentes do produto e identificar inconsistências entre estes requisitos e os planos de projeto e produtos de trabalho.  Envolve: ◦ Obtenção e entendimento dos requisitos; ◦ Obter os compromissos para atendimento dos requisitos; ◦ Gerenciar mudanças de requisitos; ◦ Manter rastreabilidade bidirecional dos requisitos (da origem dos requisitos para o nível mais baixo de detalhamento e vice-versa) ◦ Identificar inconsistência entre produtos de trabalho e requisitos.
  • 34.  Existência de uma gerência adequada dos conjuntos de requisitos para suportar o planejamento e necessidades de execução do projeto.  Os requisitos são analisados criticamente com o provedor dos requisitos (requirements provider) para solucionar questões e mal entendimentos antes de sua incorporação nos planos de projeto.  Obtenção dos compromissos sobre os requisitos dos participantes do projeto.  Gerência nas mudanças dos requisitos quando envolvem ou são identificadas inconsistências ocorridas nos planos, produtos de trabalho e requisitos.
  • 35.  Os requisitos alocados, a engenharia de software por exemplo, devem ser documentados.  A documentação, dependendo do tamanho e complexidade do projeto, pode ser de forma simples (memorando) ou elaborada (vários documentos do cliente).  Se os requisitos mudam, estas mudanças devem ser documentadas e os documentos relacionados também, devendo ser acompanhados e verificados.
  • 37.  O processo é executado ◦ Medida do quanto o processo atinge seu propósito.  Resultado esperado: ◦ RAP 1. O processo atinge seus resultados definidos.
  • 38.  O processo é gerenciado ◦ Medida do quanto a execução do processo é gerenciada.  Resultados esperados: ◦ RAP 2. Existe uma política organizacional estabelecida e mantida para o processo; ◦ RAP 3. A execução do processo é planejada; ◦ RAP 4 (Para o Nível G). A execução do processo é monitorada e ajustes são realizados; ◦ RAP 5. (Até o Nível F) As informações e os recursos necessários para a execução do processo são identificados e disponibilizados; ◦ RAP 6. (Até o Nível F) As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas.
  • 39.  Resultados esperados (cont.): ◦ RAP 7. (Até o Nível F) As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; ◦ RAP 8. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento; ◦ RAP 9. (Até o Nível F) 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. ◦ RAP 10 (Para o Nível G). O processo planejado para o projeto é executado.

Editor's Notes

  1. Os modelos CMMI e MPS.BR não são processos. Um modelo é uma representação simplificada do mundo real. Os modelos de maturidade de capacitação (Capability Maturity Models - CMMs) contêm os elementos essenciais de processos eficientes para uma ou mais áreas de conhecimento. Os modelos integrados de maturidade de capacitação (Capability Maturity Model Integration - CMMI) fornecem direcionamentos a serem utilizados no desenvolvimento de processos. Um processo é um ponto de apoio da melhoria sustentada de uma organização. O objetivo do CMM Integration é fornecer direcionamentos para melhorar os processos de sua organização e sua capacidade de gerenciar o desenvolvimento, aquisição e manutenção de produtos e serviços.
  2. http://longhigh.wordpress.com/2008/05/15/principais-diferencas-entre-o-mps-br-e-o-cmmi/
  3. http://www.gizmodo.com.br/conteudo/a-120-metros-do-chao-pouso-de-um-aviao-e-abortado-porque-o-piloto-estava-mexendo-no-celular/
  4. Existem no mercado brasileiro hoje, cerca de 8.520 empresas envolvidas com desenvolvimento, produção e distribuição de software e prestação de serviços, sendo que 94% são classificadas como micro e pequenas empresas. Para Laporte et al (2008) essas empresas podem ser definidas como “qualquer serviço de TI, organização e projeto que possua de 1 a 25 empregados”. No mercado atual, essas organizações têm ocupado uma posição de destaque. Na Europa, por exemplo, 85% das companhias do setor de TI possuem entre 1 a 10 empregados, no Canadá 78% possuem menos que 25 funcionários (Laporte et al, 2008). Recentemente o Projeto de Lei Complementar 77/2011 que prevê, entre outras mudanças, o reajuste de 50%, nas tabelas de enquadramento das micro e pequenas empresas no Simples Nacional (Supersimples) a partir de 1º de janeiro de 2012, foi sancionado sem alterações pela presidente no dia 10 de novembro de 2011. Com esse reajuste, os valores da receita bruta anual foram alterados. A tabela 2 ilustra os novos valores.
  5. MR-MPS: Contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade MR-MPS. Contém as definições dos níveis de maturidade, processos e atributos do processo. MA-MPS: Contém o processo e o método de avaliação MA-MPS, os requisitos para os avaliadores líderes, avaliadores adjuntos e instituições avaliadoras. MN-MPS: Descreve regras de negócio para: implementação e avaliação do MPS, organização de grupos de empresas para implementação e avaliação do MPS, certificação de consultores de aquisição e programas anuais de treinamento por meio de cursos, provas e workshops. Guia Geral: Contém a descrição do modelo MPS e detalha o Modelo de Referência MPS para Software (MR-MPS-SW); Guia de Aquisição: Descreve o processo de aquisição do software e serviços correlatos, com foco na satisfação da necessidade do cliente; Guia de Implementação: Serie de documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no modelo de referência MR-MPS-SW;
  6. MR-MPS: Contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade MR-MPS. Contém as definições dos níveis de maturidade, processos e atributos do processo. MA-MPS: Contém o processo e o método de avaliação MA-MPS, os requisitos para os avaliadores líderes, avaliadores adjuntos e instituições avaliadoras. MN-MPS: Descreve regras de negócio para: implementação e avaliação do MPS, organização de grupos de empresas para implementação e avaliação do MPS, certificação de consultores de aquisição e programas anuais de treinamento por meio de cursos, provas e workshops. Guia Geral: Contém a descrição do modelo MPS e detalha o Modelo de Referência MPS para Software (MR-MPS-SW); Guia de Aquisição: Descreve o processo de aquisição do software e serviços correlatos, com foco na satisfação da necessidade do cliente; Guia de Implementação: Serie de documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no modelo de referência MR-MPS-SW;
  7. http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-mps-br-no-brasil
  8. http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-mps-br-no-brasil http://www.blogcmmi.com.br/avaliacao/infografico-das-empresas-mps-br-no-brasil
  9. http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-mps-br-no-brasil