Upload
internet
View
107
Download
0
Embed Size (px)
Citation preview
Qualidade de Processo de SoftwareMPS.BR
Ricardo de Almeida Falbo
Tópicos Especiais – Qualidade de Software 2008/2
Departamento de InformáticaUniversidade Federal do Espírito Santo
Tópicos Especiais - Qualidade de Software 2008/2 2
Agenda
Motivação Histórico Estrutura do MPS.BR O Modelo de Referência (MR-MPS) O Método de Avaliação (MA-MPS) O Modelo de Negócio (MN-MPS) Diferenciais do MPS.BR
Tópicos Especiais - Qualidade de Software 2008/2 3
Motivação Em 2003, dados da Secretaria de Política de Informática do
MCT apontavam que apenas 30 empresas no Brasil possuíam avaliação CMM e 214 possuíam certificação ISO 9001.
Claramente, as empresas locais favoreceram a ISO 9000. Dados de uma pesquisa do MIT 1, apontavam que até
2003, na Índia 32 empresas atingiram o nível 5 do CMM, enquanto a China tinha apenas uma e o Brasil nenhuma.
Em relação ao CMM, a maioria das empresas chinesas e brasileiras não estava em um nível suficientemente alto de maturidade do processo para competir com as empresas indianas.
1 Ref: Slicing the Knowledge-based Economy in Brazil, China and India: a tale of 3 software industries [MIT, 2003]
Tópicos Especiais - Qualidade de Software 2008/2 4
1997 1999 2001 2003
Certificação ISO 9000
102 206 167 214
Avaliação CMM (total)
1 2 6 30
Nível 5 - - - -
Nível 4 - - - 1
Nível 3 1 1 4 5
Nível 2 - 1 2 24
Motivação: Processo de Software no BrasilEmpresas com ISO 9000 e CMM
Tópicos Especiais - Qualidade de Software 2008/2 5
Problema da Excelência: Como atingir níveis de maturidade CMMI no Brasil?
No topo da pirâmide estão as empresas exportadoras de software e outras grandes empresas que desejam atingir níveis mais altos de maturidade (CMMI níveis 4 e 5) e serem formalmente certificadas pelo SEI, em um processo de longo prazo. O fator custo não é crítico.
O processo como um todo pode levar de 4 a 10 anos e custar centenas de milhares de dólares.
A melhoria de processo é baseada na oferta de serviços personalizados para cada empresa (Modelo de Negócio Específico).
Tópicos Especiais - Qualidade de Software 2008/2 6
Problema da Excelência: Como atingir níveis de maturidade CMMI no Brasil?
Empresas exportadoras
e grandes
Empresas exportadoras
e grandes
Níveis de maturidade CMMI 4 e 5
Custo não é crítico – 4 a 10 anos
Níveis de maturidade CMMI 4 e 5
Custo não é crítico – 4 a 10 anos
Tópicos Especiais - Qualidade de Software 2008/2 7
Problema da Excelência: Como atingir níveis de maturidade CMMI no Brasil?
Na base da pirâmide encontra-se a grande massa de micro, pequenas e médias empresas (PMEs) que desenvolvem software no Brasil e que necessitam melhorar radicalmente os seus processos de software, em conformidade com normas internacionais (como ISO/IEC 12207 e 15504) e em compatibilidade com outros modelos (como CMMI níveis 2 e 3). O fator custo é crítico.
Esse processo pode levar de 2 a 4 anos e custar dezenas de milhares de dólares.
A melhoria de processo deve ser baseada na oferta de pacotes de serviços para grupos de empresas (Modelo de Negócio Cooperado).
Tópicos Especiais - Qualidade de Software 2008/2 8
Problema da Excelência: Como atingir níveis de maturidade CMMI no Brasil?
Empresas exportadoras
e grandes
Empresas exportadoras
e grandes
Pequenas e médiasPequenas e médias
Níveis de maturidade 2 e 3
Custo é crítico – 2 a 3 anos
Níveis de maturidade 2 e 3
Custo é crítico – 2 a 3 anos
Níveis de maturidade CMMI 4 e 5
Custo não é crítico – 4 a 10 anos
Níveis de maturidade CMMI 4 e 5
Custo não é crítico – 4 a 10 anos
Tópicos Especiais - Qualidade de Software 2008/2 9
MPS.BR: Objetivo e Metas Objetivo: Melhoria de processos de software nas
micros, pequenas e médias empresas (PMEs), a um custo acessível, em diversos locais do país.
Como?
Desenvolvimento e Aprimoramento do Modelo MPS.BR.
Implementação e Avaliação do Modelo MPS.BR em empresas, com foco em grupos de empresas.
Tópicos Especiais - Qualidade de Software 2008/2 10
MPS.BR
Realidade das Empresas Brasileiras
ISO /IEC 12207ISO /IEC 12207
ISO /IEC 15504ISO /IEC 15504
CMMICMMI
SOFTEX
Governo
Universidades
SOFTEX
Governo
Universidades
Base Técnica
MPS.BR: Desenvolvimento e Aprimoramento
Tópicos Especiais - Qualidade de Software 2008/2 11
Base Técnica do MPS.BR
MPS.BRMPS.BR
CMMI
Complementação de Processos
CMMI
Complementação de Processos
ISO/IEC 12207
Definição de Processos
Propósitos e Resultados
ISO/IEC 12207
Definição de Processos
Propósitos e Resultados
ISO/IEC 15504
Definição da Capacidade de Processos
Requisitos de Avaliação
ISO/IEC 15504
Definição da Capacidade de Processos
Requisitos de Avaliação
Tópicos Especiais - Qualidade de Software 2008/2 12
Histórico Dezembro de 2003: Início do programa
mobilizador para a Melhoria do Processo de Software Brasileiro, coordenado pela Softex (Associação para Promoção da Excelência do Software Brasileiro), com apoio do Ministério da Ciência e Tecnologia (MCT) e do Banco Interamericano de Desenvolvimento (BID).
Abril de 2005: Versão 1.0 Maio de 2006: Versão 1.1 Junho de 2007: Versão 1.2
Tópicos Especiais - Qualidade de Software 2008/2 13
Estrutura do Modelo MPS.BR
ProgramaMPS.BR
Modelo de Negócio
(MN-MPS)
Método de Avaliação (MA-MPS)
Guia de Aquisição Guia Geral
Modelo de Referência (MR-MPS)
Guia de Avaliação Documento do Programa
ISO/IEC 12207
Guias de Implementação
ISO/IEC 15504CMMI-DEV
Tópicos Especiais - Qualidade de Software 2008/2 14
Estrutura do Modelo MPS.BR
ProgramaMPS.BR
Modelo de Negócio
(MN-MPS)
Método de Avaliação (MA-MPS)
Guia de Aquisição Guia Geral
Modelo de Referência (MR-MPS)
Guia de Avaliação Documento do Programa
ISO/IEC 12207
Guias de Implementação
ISO/IEC 15504CMMI-DEV
Tópicos Especiais - Qualidade de Software 2008/2 15
MPS.BR: Guia Geral Descreve o Modelo de Referência para Melhoria
do Processo de Software (MR-MPS) e fornece uma visão geral sobre os demais guias que apóiam os processos de avaliação e de aquisição.
Público-alvo: Instituições interessadas em aplicar o MR-MPS para
melhoria de seus processos de software. Instituições Implementadoras (IIs) e avaliadoras (IAs)
segundo o MR-MPS outros interessados em processos de software e que
pretendam conhecer e utilizar o MR-MPS como referência técnica.
Tópicos Especiais - Qualidade de Software 2008/2 16
MPS.BR Guia Geral – Versão 1.2 Referências:
Básicas: ISO/IEC 12207:1995/Amd 1:2002/Amd 2:2004 e ISO/IEC 15504-2
Complementar: CMMI-Dev 1.2 (2006)
Tópicos Especiais - Qualidade de Software 2008/2 17
Modelo de Referência: MR-MPS Contém os requisitos que os processos das
unidades organizacionais devem atender para estar em conformidade com o MR-MPS.
Está em conformidade com os requisitos de Modelos de Referência de Processo da norma ISO/IEC 15504-2.
Tópicos Especiais - Qualidade de Software 2008/2 18
Modelo de Referência: MR-MPS Contém as definições dos níveis de maturidade,
processos (com propósitos e resultados esperados) e atributos do processo (com resultados esperados).
As atividades e tarefas necessárias para atender ao propósito e aos resultados esperados de um processo não são definidas, ficando a cargo dos usuários do MR-MPS.
Tópicos Especiais - Qualidade de Software 2008/2 19
Estrutura do MR-MPS
Níveis de Maturidade
CapacidadeProcesso
ResultadosResultados
Propósito Atributos
Tópicos Especiais - Qualidade de Software 2008/2 20
Níveis de Maturidade
São uma combinação entre processos e sua capacidade.
O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível.
Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização.
Tópicos Especiais - Qualidade de Software 2008/2 21
Níveis de Maturidade
O MR-MPS define sete níveis de maturidade: A. Em Otimização B. Gerenciado Quantitativamente C. Definido D. Largamente Definido E. Parcialmente Definido F. Gerenciado G. Parcialmente Gerenciado
Tópicos Especiais - Qualidade de Software 2008/2 22
Equivalência com CMMINível MPS.BR Nível CMMI
G2
F
E
3D
C
B 4
A 5
Tópicos Especiais - Qualidade de Software 2008/2 23
Equivalência com CMMI A divisão em estágios, embora baseada nos
níveis de maturidade do CMMI-DEV, tem uma graduação diferente, com o objetivo de possibilitar uma implementação e avaliação mais adequada às micros, pequenas e médias empresas.
A possibilidade de se realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos.
Tópicos Especiais - Qualidade de Software 2008/2 24
Processo
Os processos no MR-MPS são descritos em termos de propósito e resultados.
Propósito: descreve o objetivo geral a ser atingido durante a execução do processo.
Resultados Esperados: estabelecem os resultados a serem obtidos com a efetiva implementação do processo. Esses resultados podem ser evidenciados por um artefato produzido ou uma mudança significativa de estado ao se executar o processo.
Tópicos Especiais - Qualidade de Software 2008/2 25
Níveis de Maturidade e Processos
Garantia da Qualidade / MediçãoAquisição / Gerência de Configuração
Avaliação e Melhoria do Processo Organizacional / Definição do Processo Organizacional / Gerência de Recursos Humanos / Gerência de Reutilização / Gerência de Projetos (evolução)
Desenvolvimento de Requisitos / Integração do Produto/ Projeto e Construção do Produto / Verificação / Validação
Análise de Decisão e Resolução / Gerência de Reutilização (evolução) / Desenvolvimento para Reutilização / Gerência de Riscos
G
F
E
D
C
Gerência de RequisitosGerência de Projeto
Gerência de Projeto (evolução)
Análise de Causas de Problemas e ResoluçãoA
B
Parcialmente Gerenciado
Gerenciado
Parcialmente Definido
Largamente Definido
Definido
Gerenciado Quantitativamente
Em Otimização
Tópicos Especiais - Qualidade de Software 2008/2 26
Estrutura do MR-MPS
Níveis de Maturidade
CapacidadeProcesso
ResultadosResultados
Propósito Atributos
Tópicos Especiais - Qualidade de Software 2008/2 27
Capacidade do Processo
Expressa o grau de refinamento e institucionalização com que o processo é executado na organização / unidade organizacional.
Está relacionada com o atendimento aos atributos de processo associados aos processos de cada nível de maturidade.
À medida que a organização / unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela organização.
Tópicos Especiais - Qualidade de Software 2008/2 28
Capacidade e Atributos de Processo
Atributos de Processo (AP): AP 1.1 – O processo é executado AP 2.1 – O processo é gerenciado AP 2.2 – Os produtos de trabalho do processo são gerenciados AP 3.1 – O processo é definido AP 3.2 – O processo está implementado AP 4.1 – O processo é medido AP 4.2 – O processo é controlado AP 5.1 – O processo é objeto de inovações AP 5.2 – O processo é otimizado continuamente
Introduzidos na Versão 1.2
Tópicos Especiais - Qualidade de Software 2008/2 29
Atributos de Processo do Nível G AP 1.1 – O processo é executado.
Este atributo é uma medida do quanto o processo atinge seu propósito.
RAP 1. O processo atinge seus resultados definidos.
AP 2.1 – O processo é gerenciado. Este atributo é uma medida do quanto a execução do
processo é gerenciada. RAP 2. Existe uma política organizacional estabelecida
e mantida para o processo. RAP 3. A execução do processo é planejada.
Tópicos Especiais - Qualidade de Software 2008/2 30
Atributos de Processo do Nível G RAP 4 (para o nível G). A execução do processo é
monitorada e ajustes são realizados para atender aos planos.
RAP 5. Os recursos necessários para a execução do processo são identificados e disponibilizados.
RAP 6. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência.
RAP 7. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto.
RAP 8. Métodos adequados para monitorar a eficácia e adequação do processo são determinados.
Tópicos Especiais - Qualidade de Software 2008/2 31
Níveis de Maturidade e Capacidade
Tópicos Especiais - Qualidade de Software 2008/2 32
Estrutura do MR-MPS
Níveis de Maturidade
CapacidadeProcesso
ResultadosResultados
Propósito Atributos
Tópicos Especiais - Qualidade de Software 2008/2 33
Nível G – Parcialmente Gerenciado
Nível Processos Capacidade
G
Gerência de ProjetosResultados: GPR 1 a GPR 17
GPR 4, 10 e 13 (até o Nível F)
AP 1.1 e AP 2.1Resultados:
RAP 1 a RAP 8sendo RAP 4 (G)
Gerência de RequisitosResultados: GRE 1 a GRE 5
Tópicos Especiais - Qualidade de Software 2008/2 34
Nível G: Gerência de Projetos
Propósito: 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 (nos níveis E e B).
Tópicos Especiais - Qualidade de Software 2008/2 35
Nível G: Gerência de Projetos
Resultados Esperados (GPR 1 a GPR 8):
1. O escopo do trabalho para o projeto é definido.2. As tarefas e os produtos de trabalho do projeto são
dimensionados utilizando métodos apropriados.3. O modelo e as fases do ciclo de vida do projeto são definidas. 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.
5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos.
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.
7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo.
8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados.
Tópicos Especiais - Qualidade de Software 2008/2 36
Nível G: Gerência de Projetos Resultados Esperados (GPR 9 a GPR 15):
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.
10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto.
11. 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.
12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido.
13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados.
14. O envolvimento das partes interessadas no projeto é gerenciado.15. Revisões são realizadas em marcos do projeto e conforme
estabelecido no planejamento.
Tópicos Especiais - Qualidade de Software 2008/2 37
Nível G: Gerência de Projetos
Resultados Esperados (GPR 16 e GPR 17): 16. 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.
17. 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.
Tópicos Especiais - Qualidade de Software 2008/2 38
Nível G: Gerência de Requisitos
Propósito: Gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
Tópicos Especiais - Qualidade de Software 2008/2 39
Nível G: Gerência de Requisitos
Resultados Esperados (GRE 1 a GRE 5): 1. O entendimento dos requisitos é obtido junto aos
fornecedores de requisitos;;.2. Os requisitos de software são aprovados utilizando critérios
objetivos;3. A rastreabilidade bidirecional entre os requisitos e os
produtos de trabalho é estabelecida e mantida;;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.
5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
Tópicos Especiais - Qualidade de Software 2008/2 40
Nível F: Processo e Propósitos Aquisição: gerenciar a aquisição de produtos e/ou serviços
que satisfaçam a necessidade expressa pelo adquirente. Gerência de Configuração: estabelecer e manter a
integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos.
Garantia da Qualidade: assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos e recursos predefinidos.
Medição: coletar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais.
Tópicos Especiais - Qualidade de Software 2008/2 41
Nível E: Processo e Propósitos Avaliação e Melhoria do Processo Organizacional: determinar
o quanto os processos padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização a planejar, realizar e implantar melhorias contínuas nos processos com base no entendimento de seus pontos fortes e fracos.
Definição do Processo Organizacional: estabelecer e manter um conjunto de ativos de processo organizacional e padrões do ambiente de trabalho usáveis e aplicáveis às necessidades de negócio da organização.
Gerência de Recursos Humanos: prover a organização e os projetos com os recursos humanos necessários e manter suas competências consistentes com as necessidades do negócio.
Gerência de Reutilização: gerenciar o ciclo de vida dos ativos reutilizáveis.
Tópicos Especiais - Qualidade de Software 2008/2 42
Nível D: Processo e Propósitos Desenvolvimento de Requisitos: estabelecer os requisitos
dos componentes do produto, do produto e do cliente. Projeto e Construção do Produto: projetar, desenvolver e
implementar soluções para atender aos requisitos. Integração do Produto: compor os componentes do
produto, produzindo um produto integrado consistente com o projeto, e demonstrar que os requisitos funcionais e não-funcionais são satisfeitos para o ambiente alvo ou equivalente.
Verificação: confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente aos requisitos especificados.
Validação: confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.
Tópicos Especiais - Qualidade de Software 2008/2 43
Nível C: Processo e Propósitos Análise de Decisão e Resolução: analisar possíveis
decisões usando um processo formal, com critérios estabelecidos, para avaliação das alternativas identificadas.
Desenvolvimento para Reutilização: identificar oportunidades de reutilização sistemática na organização e, se possível, estabelecer um programa de reutilização para desenvolver ativos a partir de engenharia de domínios de aplicação.
Gerência de Riscos: identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto.
Tópicos Especiais - Qualidade de Software 2008/2 44
Níveis A e B: Processo e Propósitos
Nível B: não possui processos específicos. Nível A:
Análise de Causas de Problemas e Resolução: identificar causas de defeitos e de outros problemas e tomar ações para prevenir suas ocorrências no futuro.
Tópicos Especiais - Qualidade de Software 2008/2 45
Estrutura do Modelo MPS.BR
ProgramaMPS.BR
Modelo de Negócio
(MN-MPS)
Método de Avaliação (MA-MPS)
Guia de Aquisição Guia Geral
Modelo de Referência (MR-MPS)
Guia de Avaliação Documento do Programa
ISO/IEC 12207
Guias de Implementação
ISO/IEC 15504CMMI-DEV
Tópicos Especiais - Qualidade de Software 2008/2 46
Guia de Avaliação Descreve o processo e o Método de Avaliação do
MPS.BR definidos em conformidade com a norma ISO/IEC 15504-2:2003.
O processo e o Método de Avaliação MA-MPS foram definidos de forma a:
permitir a avaliação objetiva dos processos de software de uma organização / unidade organizacional;
permitir a atribuição de um nível de maturidade do MR-MPS com base no resultado da avaliação;
ser aplicável a qualquer domínio de aplicação na indústria de software;
ser aplicável a organizações /unidades organizacionais de qualquer tamanho.
Tópicos Especiais - Qualidade de Software 2008/2 47
Guia de Avaliação Público alvo: Destinado, mas não está limitado,
às Instituições Avaliadoras (IAs), às empresas de software que desejam ser avaliadas seguindo o MA-MPS e às Instituições Implementadoras (IIs) do MR-MPS.
Validade: Uma avaliação seguindo o MA-MPS tem validade de 3 (três) anos a contar da data em que a avaliação final foi concluída na unidade organizacional avaliada.
Tópicos Especiais - Qualidade de Software 2008/2 48
O Processo de Avaliação MPS.BR
Tópicos Especiais - Qualidade de Software 2008/2 49
Subprocesso: Contratar a avaliação
Propósito: estabelecer um contrato para realização de uma avaliação MPS, solicitada por uma organização / UO que queira avaliar seus processos ou os processos de outra.
Tópicos Especiais - Qualidade de Software 2008/2 50
Subprocesso: Preparar a Realização da Avaliação
Propósito: planejar a avaliação, preparar a documentação necessária e fazer uma avaliação inicial que permita verificar se a UO está pronta para a avaliação no nível de maturidade pretendido.
Tópicos Especiais - Qualidade de Software 2008/2 51
Viabilizar a Avaliação
Participar à SOFTEX a contratação da IA para uma avaliação MPS.BR e obter aprovação para a sua realização.
A equipe de avaliação é composta por membros internos e externos à UO.
Tópicos Especiais - Qualidade de Software 2008/2 52
Equipe de Avaliação No mínimo 3 pessoas:
1 Avaliador Líder 1 ou mais Avaliadores Adjuntos 1 ou mais Representante da Unidade Organizacional
Deve ter assistido ao Curso Oficial de Introdução ao MPS.BR.
Deve ter experiência em desenvolvimento de software, preferencialmente em gerência de projetos
Não pode ser superior hierárquico dos participantes da avaliação
Não pode ter tido participação significativa em nenhum dos projetos que serão avaliados
Tópicos Especiais - Qualidade de Software 2008/2 53
Tamanho da Equipe de Avaliação
Níveis No min – No max
A e B 8 - 9
C e D 6 - 7
E e F 4 - 5
G 3 - 4
Tópicos Especiais - Qualidade de Software 2008/2 54
Planejar Avaliação
Elaborar o plano de avaliação a ser seguido para se realizar a avaliação na unidade organizacional.
Documentos Base: Modelo de Plano de avaliação (template SOFTEX) e Acordo de Confidencialidade
Planejar Avaliação Inicial Preencher Modelo de Plano de Avaliação
(definir cronograma, equipe e projetos) e Acordo de Confidencialidade
Tópicos Especiais - Qualidade de Software 2008/2 55
Estimativa de Tempo
Níveis Duração (em dias)
Avaliação Inicial Avaliação Final
A e B 2 - 3 4 - 5
C e D 2 - 3 3 - 5
E 2 3 - 4
F 1 - 2 2 - 3
G 1 1 - 2
Tópicos Especiais - Qualidade de Software 2008/2 56
Seleção de Projetos Projetos devem ser representativos tanto em termos de
processos quanto em termos de negócio da unidade organizacional.
Uma avaliação MPS considera uma amostra composta, normalmente, de dois (2) a quatro (4) projetos.
Nível G: pelo menos 1 projeto concluído e 1 em andamento a partir da implementação do MR-MPS na UO definida no escopo da avaliação.
Para os níveis F e superiores: pelo menos 2 projetos concluídos e 2 em andamento a partir da implementação do MR-MPS na UO definida no escopo da avaliação.
Caso necessário, podem ser incluídos mais um ou dois projetos para evidenciar algum resultado ou para ter uma amostragem mais adequada da UO avaliada.
Tópicos Especiais - Qualidade de Software 2008/2 57
Preparar a Avaliação Preenchimento de Planilha de Indicadores
(template SOFTEX) Indicadores de implementação evidenciam que
os resultados foram alcançados e que as atividades foram realizadas. Podem ser de três tipos:
Indicadores Diretos: São o objetivo de uma atividade. Tipicamente artefatos produzidos no processo.
Indicadores Indiretos: São utilizados para confirmar que a organização tem condições de implementar um resultado. Tipicamente são documentos que indicam que a atividade pode ser realizada. Ex.: Um modelo de documento.
Afirmações: São obtidas de entrevistas ou apresentações e confirmam a implementação do processo, seus resultados e atributos.
Tópicos Especiais - Qualidade de Software 2008/2 58
Preparar a Avaliação Para cada resultado esperado de um processo ou
atributo de processo a ser avaliado, em cada projeto, deve existir pelo menos um indicador direto e um indireto (ou afirmação) que comprovem que o resultado foi alcançado.
Tópicos Especiais - Qualidade de Software 2008/2 59
Participantes – Definição de Entrevistados
Entrevistados: Gerentes e Líderes de Projeto Desenvolvedores Grupo de Qualidade, Grupo de Métricas, Grupo de
Gerência de Configuração (a partir do nível F) Grupo de Processos (a partir do nível E)
A seleção das pessoas a serem entrevistadas é realizada ao se elaborar o plano de avaliação e deve estar concluída ao se finalizar a avaliação inicial.
Tópicos Especiais - Qualidade de Software 2008/2 60
Exclusão de Processos e Resultados
É permitido a uma unidade organizacional excluir do escopo da avaliação o processo de Aquisição e determinados resultados esperados de processo, por não serem aplicáveis ao seu negócio.
Cada exclusão deve ser justificada. A aceitação das exclusões e suas justificativas é responsabilidade do avaliador líder e deve ser feita durante a avaliação inicial.
São permitidas exclusões de resultados esperados de acordo com o definido no modelo da planilha de indicadores SOFTEX.
Tópicos Especiais - Qualidade de Software 2008/2 61
Avaliação Inicial Mini-equipes: verificam os indicadores. As mini-
equipes formadas, cada uma por 2 membros da equipe, devem ser definidas de acordo com a sua experiência e perfil.
O avaliador líder pode fazer parte de uma das mini-equipes de avaliação ou verificar um ou mais processos sozinho. Pode, também, não avaliar nenhum processo, dedicando o seu tempo a apoiar as mini-equipes.
Tópicos Especiais - Qualidade de Software 2008/2 62
Avaliação Inicial Um Relatório de Avaliação Inicial é produzido,
indicando os ajustes requeridos. Com o relatório, o avaliador líder completa o
Plano de Avaliação que será assinado pelo patrocinador e pelo coordenador local, formalizando o comprometimento.
A data da avaliação poderá ser até 6 meses após a avaliação inicial. Durante esse período, a UO deve realizar os ajustes obrigatórios indicados.
Tópicos Especiais - Qualidade de Software 2008/2 63
Subprocesso: Realizar a Avaliação Final
Propósito: treinar a equipe para a avaliação final, conduzir a avaliação final, comunicar seus resultados à UO avaliada e avaliar a execução do processo de avaliação na UO.
Tópicos Especiais - Qualidade de Software 2008/2 64
Conduzir a Avaliação Realizar reunião de abertura Assinar comprometimento com o plano de avaliação Completar assinaturas do acordo de confidencialidade Treinar equipe para a avaliação final Apresentar os processos da UO Verificar evidências Registrar afirmações na planilha de indicadores Realizar entrevistas Caracterizar o grau de implementação de cada resultado nos
projetos Caracterizar inicialmente o grau de cada resultado na UO Caracterizar inicialmente o grau de cada atributo de processo
na UO Caracterizar o grau de implementação, na UO, de cada
resultado esperado do processo, de cada resultado esperado de atributo do processo e de cada atributo do processo em reunião de consenso
Tópicos Especiais - Qualidade de Software 2008/2 65
Conduzir a Avaliação Caracterizar o grau de implementação dos processos na UO Apresentar pontos fortes, pontos fracos e oportunidades de
melhoria Rever caracterização e finalizar redação de pontos fortes,
pontos fracos e oportunidades de melhoria. Atribuir nível do MR-MPS Comunicar resultado da avaliação ao patrocinador Comunicar resultado da avaliação aos colaboradores da UO
Tópicos Especiais - Qualidade de Software 2008/2 66
Verificação de Evidências Avaliação é feita com base nos indicadores (diretos,
indiretos e afirmações). Decisão para cada projeto e processo:
Não implementado (N) Parcialmente implementado (P) Largamente implementado (L) Totalmente implementado (T) Não avaliado (NA) Fora do escopo (F)
A equipe de avaliação pode solicitar mais documentos quando:
Um entrevistado menciona um documento não disponível para a equipe de avaliação
A equipe nota a falta de uma evidência direta necessária à avaliação.
Tópicos Especiais - Qualidade de Software 2008/2 67
Entrevistas São um dos mais importantes componentes de
uma avaliação MPS. Mostram o grau em que os colaboradores da
organização entendem e usam os processos. Podem ser individuais ou em grupo. Se guarda rigorosa confidencialidade das
entrevistas: Nenhuma informação é atribuída a uma pessoa individualmente.
Tópicos Especiais - Qualidade de Software 2008/2 68
Passos para a Caracterização do Nível MPS.BR de uma UO
1. Caracterizar o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo de processo em cada projeto (Base: Escala)
Tópicos Especiais - Qualidade de Software 2008/2 69
Escala para Caracterização do Grau de Implementação de um Resultado
Tópicos Especiais - Qualidade de Software 2008/2 70
Passos para a Caracterização do Nível MPS.BR de uma UO
1. Caracterizar o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo de processo em cada projeto (Base: Escala)
2. Caracterizar, inicialmente, o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo do processo na UO.
Tópicos Especiais - Qualidade de Software 2008/2 71
Caracterização do Nível de Resultados para Organização: Regras para Agregação
Tópicos Especiais - Qualidade de Software 2008/2 72
Caracterização do Nível de Resultados para Organização: Regras para Agregação
Tópicos Especiais - Qualidade de Software 2008/2 73
Passos para a Caracterização do Nível MPS.BR de uma UO
1. Caracterizar o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo de processo em cada projeto (Base: Escala)
2. Caracterizar inicialmente o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo do processo na UO.
3. Caracterizar inicialmente o grau de implementação de cada atributo de processo na UO.
Tópicos Especiais - Qualidade de Software 2008/2 74
Regras para caracterizar o Grau de Implementação dos Atributos de Processo na UO
Tópicos Especiais - Qualidade de Software 2008/2 75
Passos para a Caracterização do Nível MPS.BR de uma UO
1. Caracterizar o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo de processo em cada projeto (Base: Escala)
2. Caracterizar inicialmente o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo do processo na UO.
3. Caracterizar inicialmente o grau de implementação de cada atributo de processo na UO.
4. Caracterizar o grau de implementação dos processos na UO.
Tópicos Especiais - Qualidade de Software 2008/2 76
Caracterização do grau de implementação de cada um dos processos
Um processo está SATISFEITO quando: Todos os resultados esperados para o processo foram
caracterizados como T (Totalmente Implementado) ou L (Largamente Implementado).
Tem-se resultados para os atributos do processo, conforme a tabela a seguir.
Em qualquer outra situação o processo é caracterizado como NÃO SATISFEITO.
Tópicos Especiais - Qualidade de Software 2008/2 77
Caracterização de atributos do processo para satisfazer aos níveis MPS.BR
Tópicos Especiais - Qualidade de Software 2008/2 78
Passos para a Caracterização do Nível MPS.BR de uma UO
1. Caracterizar o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo de processo em cada projeto (Base: Escala)
2. Caracterizar inicialmente o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo do processo na UO.
3. Caracterizar inicialmente o grau de implementação de cada atributo de processo na UO.
4. Caracterizar o grau de implementação dos processos na UO.
5. Atribuir nível MPS.BR.
Tópicos Especiais - Qualidade de Software 2008/2 79
Atribuição de Nível MPS.BR A atribuição do nível de maturidade é feita a
uma UO se cada processo pertencente àquele nível e incluído no escopo da avaliação tiver sido caracterizado como SATISFEITO.
A UO pode ter solicitado um Nível MR-MPS e lhe ser atribuído um nível inferior.
Tópicos Especiais - Qualidade de Software 2008/2 80
Estrutura do Modelo MPS.BR
ProgramaMPS.BR
Modelo de Negócio
(MN-MPS)
Método de Avaliação (MA-MPS)
Guia de Aquisição Guia Geral
Modelo de Referência (MR-MPS)
Guia de Avaliação Documento do Programa
ISO/IEC 12207
Guias de Implementação
ISO/IEC 15504CMMI-DEV
Tópicos Especiais - Qualidade de Software 2008/2 81
ProgramaMPS.BR
(SOFTEX)
II & IA
MNEMNC
Contrato Contrato
Convênio
Convênio, se pertinente
LEGENDA:
II – Instituição Implementadora
IA – Instituição Avaliadora
MNE – Modelo de Negócio Específico para cada empresa (personalizado)
MNC – Modelo de Negócio Cooperado em grupo de empresas (pacote)
MN-MPS: Modelo de Negócio
Tópicos Especiais - Qualidade de Software 2008/2 82
C1 - CursoIntrodução ao MPS.BR
P1 - ProvaIntrodução ao MPS.BR
C2 – Curso Implementadores MR-MPS
P2 - Prova Implementadores MR-MPS
C3 - Curso Avaliadores MA-MPS
P3 - Prova Avaliadores MA-MPS
C4 - CursoGuia de Aquisição
P4 - Prova Guia de Aquisição
Implementador MR-MPS Avaliador Adjunto MA-MPS Consultor em Aquisição, após projeto assistido
Capacitação MPS.BR16h
24h 16h24h
Workshops:W1 – de IntroduçãoW2 – de ImplementadoresW3 – de AvaliadoresW4 – de AquisiçãoW5 – de Organização de Grupos de Empresas
Tópicos Especiais - Qualidade de Software 2008/2 83
Diferenciais do MPS.BR 7 níveis de maturidade, o que possibilita uma
implantação mais gradual e uma maior visibilidade dos resultados de melhoria de processo, com prazos mais curtos.
Compatibilidade com CMMI, conformidade com as normas ISO/IEC 15504 e 12207.
Adaptado para a realidade brasileira (foco em micro, pequenas e médias empresas).
Custo acessível (em R$)
Tópicos Especiais - Qualidade de Software 2008/2 84
Custos MPS.BR Modelo Cooperado (Implementação+ Avaliação): 50%
SOFTEX, 50% Empresa (aproximadamente) Nível G: aproximadamente R$ 44.000,00 (Total) Nível F: aproximadamente R$ 82.000,00 (Total) Muitas vezes o Agente SOFTEX local arca com parte dos
custos. Ex.: TecVitória: Grupo de 5 Empresas, Nível G:
Implementação: R$ 35.353,40 Avaliação: R$ 9.984,00 Total: R$ 45.337,40 SOFTEX: R$ 22.000,00 TecVitória: R$ 8.800,00 Empresas: R$ 14.537,40
Por exemplo, só a avaliação CMM Nível 2 (SCAMPI) é cerca de US$18,000, fora despesas com passagens e hospedagens dos avaliadores.
Tópicos Especiais - Qualidade de Software 2008/2 85
Situação Atual Empresas certificadas no triênio 2006-2008: 105
19 Instituições Implementadoras 9 Instituições Avaliadoras 18 Implementações em Grupos de Empresas Fonte: www.softex.br/mpsbr em 09.11.2008.
A B C D E F G
2006 2 0 0 1 1 1 7
2007 1 0 0 0 1 12 41
2008 1 0 0 0 1 8 28
Total 4 0 0 1 3 21 76
Tópicos Especiais - Qualidade de Software 2008/2 86
Metas e Desafios Aprimorar os Guias do MPS.BR anualmente. Reforçar a capacitação de pessoas por meio de cursos,
provas e workshops MPS.BR. Criar novos grupos de empresas para Implementação e
Avaliação MPS, com apoio de instituições organizadoras de grupos de empresas (IOGE) e IIs.
Disseminar o Modelo MPS em todas as regiões do Brasil. Disseminar o Modelo MPS em 2 países latino-americanos,
com apoio do BID (Argentina e Chile) Missões de divulgação e exploração em outros países
latino-americanos (Peru e Uruguai)
Tópicos Especiais - Qualidade de Software 2008/2 87
Referências Softex, MPS.BR - Melhoria de Processo do
Software Brasileiro – Guia Geral, Versão 1.2, Junho 2007.
Softex, MPS.BR - Melhoria de Processo do Software Brasileiro – Guia de Avaliação, Versão 1.1, Junho 2007.