O documento discute a definição de maturidade e capacidade de processo de software, o Modelo MPS.BR e seu objetivo de melhorar os processos de software em empresas brasileiras. Também descreve os níveis iniciais do modelo, incluindo os processos e resultados esperados no Nível G.

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.”

11.  CMM

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

13.  CMM

14.  CMMI

15.  CMM

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.