A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Qualidade de Processo de Software MPS.BR

Apresentações semelhantes


Apresentação em tema: "Qualidade de Processo de Software MPS.BR"— Transcrição da apresentação:

1 Qualidade de Processo de Software MPS.BR
Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do Espírito Santo

2 Tópicos Especiais - Qualidade de Software 2008/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 Tópicos Especiais - Qualidade de Software 2008/2
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 Motivação: Processo de Software no Brasil Empresas com ISO 9000 e CMM
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 Nível 3 4 5 Nível 2 24 Tópicos Especiais - Qualidade de Software 2008/2

5 Tópicos Especiais - Qualidade de Software 2008/2
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). 1) O Projeto Qualificação de Profissionais no Modelo CMMI pretende atingir, no prazo de 2 anos ( ), os seguintes resultados: i)  a consolidação de uma entidade brasileira como parceira do SEI (transient partner); ii) a formação de avaliadores-líder no método SCAMPI/CMMI (SCAMPI Lead Appraiser), credenciados pelo SEI; iii) a  formação de instrutores de cursos sobre CMMI, credenciados pelo SEI; iv) a implementação de  um curso de especialização Lato-Sensu, à distância, em melhoria de processo com CMMI; v) a formação de especialistas em várias partes do País com o curso de especialização Lato-Sensu, à distância, em melhoria de processo com CMMI. 2) Em complemento ao Projeto mpsB, dentre outras oportunidades com apoio deste outro projeto, foi levantada a necessidade de Cursos de Especialização em Qualidade de Software (processo e produto), com ementas-padrão,  mediante convênio da Sociedade SOFTEX com as instituições envolvidas (p.ex.: MBA SOFTEX-CESAR, MBA SOFTEX-CENPRA, MBA SOFTEX-COPPE UFRJ, MBA SOFTEX-UCB). Ana Regina observou que há necessidade de formar seja Avaliadores de Processos e Produtos de Software seja Gestores da Qualidade (QA-Quality Assurance) para trabalhar nas empresas. Tópicos Especiais - Qualidade de Software 2008/2

6 Empresas exportadoras e grandes
Problema da Excelência: Como atingir níveis de maturidade CMMI no Brasil? Níveis de maturidade CMMI 4 e 5 Custo não é crítico – 4 a 10 anos Empresas exportadoras e grandes 1) O Projeto Qualificação de Profissionais no Modelo CMMI pretende atingir, no prazo de 2 anos ( ), os seguintes resultados: i)  a consolidação de uma entidade brasileira como parceira do SEI (transient partner); ii) a formação de avaliadores-líder no método SCAMPI/CMMI (SCAMPI Lead Appraiser), credenciados pelo SEI; iii) a  formação de instrutores de cursos sobre CMMI, credenciados pelo SEI; iv) a implementação de  um curso de especialização Lato-Sensu, à distância, em melhoria de processo com CMMI; v) a formação de especialistas em várias partes do País com o curso de especialização Lato-Sensu, à distância, em melhoria de processo com CMMI. 2) Em complemento ao Projeto mpsB, dentre outras oportunidades com apoio deste outro projeto, foi levantada a necessidade de Cursos de Especialização em Qualidade de Software (processo e produto), com ementas-padrão,  mediante convênio da Sociedade SOFTEX com as instituições envolvidas (p.ex.: MBA SOFTEX-CESAR, MBA SOFTEX-CENPRA, MBA SOFTEX-COPPE UFRJ, MBA SOFTEX-UCB). Ana Regina observou que há necessidade de formar seja Avaliadores de Processos e Produtos de Software seja Gestores da Qualidade (QA-Quality Assurance) para trabalhar nas empresas. Tópicos Especiais - Qualidade de Software 2008/2

7 Tópicos Especiais - Qualidade de Software 2008/2
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 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). Prezados Petit e Kival: Uma das providências mais urgentes de nosso Projeto mpsB – melhoria de processo do software Brasileiro será preparar um *elenco de argumentos (para os leigos, para a mídia e para nós mesmos)* que o justifiquem. Esse tipo de pergunta é novo, porém, já ouvimos coisas como: Para quê se existe o CMM? Reinventaremos a roda? Temos capacidade para isso? É reserva de mercado? Como fazer valer depois de pronto? Poderá ser usado nas licitações públicas? Com essas justificativas, iremos à imprensa, aos órgãos públicos e às nossas empresas. Iremos também ao CNPq para que incentive bolsas que tratem do assunto. Iremos também ao MP para que se estude a sua inclusão na nova lei de licitações.Temos que divulgá-lo bem e desde já. Se possível, gerar uma apresentação formal. Abs Márcio Girão. Tópicos Especiais - Qualidade de Software 2008/2

8 Empresas exportadoras e grandes
Problema da Excelência: Como atingir níveis de maturidade CMMI no Brasil? Níveis de maturidade CMMI 4 e 5 Custo não é crítico – 4 a 10 anos Empresas exportadoras e grandes 1) O Projeto Qualificação de Profissionais no Modelo CMMI pretende atingir, no prazo de 2 anos ( ), os seguintes resultados: i)  a consolidação de uma entidade brasileira como parceira do SEI (transient partner); ii) a formação de avaliadores-líder no método SCAMPI/CMMI (SCAMPI Lead Appraiser), credenciados pelo SEI; iii) a  formação de instrutores de cursos sobre CMMI, credenciados pelo SEI; iv) a implementação de  um curso de especialização Lato-Sensu, à distância, em melhoria de processo com CMMI; v) a formação de especialistas em várias partes do País com o curso de especialização Lato-Sensu, à distância, em melhoria de processo com CMMI. 2) Em complemento ao Projeto mpsB, dentre outras oportunidades com apoio deste outro projeto, foi levantada a necessidade de Cursos de Especialização em Qualidade de Software (processo e produto), com ementas-padrão,  mediante convênio da Sociedade SOFTEX com as instituições envolvidas (p.ex.: MBA SOFTEX-CESAR, MBA SOFTEX-CENPRA, MBA SOFTEX-COPPE UFRJ, MBA SOFTEX-UCB). Ana Regina observou que há necessidade de formar seja Avaliadores de Processos e Produtos de Software seja Gestores da Qualidade (QA-Quality Assurance) para trabalhar nas empresas. Níveis de maturidade 2 e 3 Custo é crítico – 2 a 3 anos Pequenas e médias 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: Desenvolvimento e Aprimoramento
Realidade das Empresas Brasileiras ISO /IEC 12207 ISO /IEC 15504 CMMI SOFTEX Governo Universidades Base Técnica Tópicos Especiais - Qualidade de Software 2008/2

11 Base Técnica do MPS.BR ISO/IEC 12207 Definição de Processos
Propósitos e Resultados ISO/IEC 15504 Definição da Capacidade de Processos Requisitos de Avaliação MPS.BR CMMI Complementação de Processos Tópicos Especiais - Qualidade de Software 2008/2

12 Tópicos Especiais - Qualidade de Software 2008/2
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
ISO/IEC 12207 CMMI-DEV ISO/IEC 15504 Programa MPS.BR Modelo de Referência (MR-MPS) Método de Avaliação (MA-MPS) Modelo de Negócio (MN-MPS) Guia Geral Guia de Aquisição Guia de Avaliação Documento do Programa Guias de Implementação Tópicos Especiais - Qualidade de Software 2008/2

14 Estrutura do Modelo MPS.BR
ISO/IEC 12207 CMMI-DEV ISO/IEC 15504 Programa MPS.BR Modelo de Referência (MR-MPS) Método de Avaliação (MA-MPS) Modelo de Negócio (MN-MPS) Guia Geral Guia de Aquisição Guia de Avaliação Documento do Programa Guias de Implementação Tópicos Especiais - Qualidade de Software 2008/2

15 Tópicos Especiais - Qualidade de Software 2008/2
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 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 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 Tópicos Especiais - Qualidade de Software 2008/2
Estrutura do MR-MPS Níveis de Maturidade Processo Capacidade Propósito Atributos Resultados Resultados Tópicos Especiais - Qualidade de Software 2008/2

20 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
Equivalência com CMMI Nível MPS.BR Nível CMMI G 2 F E 3 D C B 4 A 5 Tópicos Especiais - Qualidade de Software 2008/2

23 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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ção Aquisiçã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 Requisitos Gerência de Projeto Gerência de Projeto (evolução) Análise de Causas de Problemas e Resolução A B Parcialmente Gerenciado Gerenciado Parcialmente Definido Largamente Definido Definido Gerenciado Quantitativamente Em Otimização Tópicos Especiais - Qualidade de Software 2008/2

26 Tópicos Especiais - Qualidade de Software 2008/2
Estrutura do MR-MPS Níveis de Maturidade Processo Capacidade Propósito Atributos Resultados Resultados 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 Tópicos Especiais - Qualidade de Software 2008/2
Estrutura do MR-MPS Níveis de Maturidade Processo Capacidade Propósito Atributos Resultados Resultados Tópicos Especiais - Qualidade de Software 2008/2

33 Nível G – Parcialmente Gerenciado
Processos Capacidade G Gerência de Projetos Resultados: GPR 1 a GPR 17 GPR 4, 10 e 13 (até o Nível F) AP 1.1 e AP 2.1 Resultados: RAP 1 a RAP 8 sendo RAP 4 (G) Gerência de Requisitos Resultados: 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): O escopo do trabalho para o projeto é definido. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados. O modelo e as fases do ciclo de vida do projeto são definidas. 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. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos. 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 recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo. 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): 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. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto. 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. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados. O envolvimento das partes interessadas no projeto é gerenciado. 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): 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. 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): O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;;. Os requisitos de software são aprovados utilizando critérios objetivos; A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;; Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. 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
ISO/IEC 12207 CMMI-DEV ISO/IEC 15504 Programa MPS.BR Modelo de Referência (MR-MPS) Método de Avaliação (MA-MPS) Modelo de Negócio (MN-MPS) Guia Geral Guia de Aquisição Guia de Avaliação Documento do Programa Guias de Implementação Tópicos Especiais - Qualidade de Software 2008/2

46 Tópicos Especiais - Qualidade de Software 2008/2
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 :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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 3 - 5 E 2 3 - 4 F 1 - 2 G 1 Tópicos Especiais - Qualidade de Software 2008/2

56 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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
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
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) 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 Tópicos Especiais - Qualidade de Software 2008/2
Caracterização do Nível de Resultados para Organização: Regras para Agregação Tópicos Especiais - Qualidade de Software 2008/2

72 Tópicos Especiais - Qualidade de Software 2008/2
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
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) Caracterizar inicialmente o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo do processo na UO. Caracterizar inicialmente o grau de implementação de cada atributo de processo na UO. Tópicos Especiais - Qualidade de Software 2008/2

74 Tópicos Especiais - Qualidade de Software 2008/2
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
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) Caracterizar inicialmente o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo do processo na UO. Caracterizar inicialmente o grau de implementação de cada atributo de processo na UO. 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 Tópicos Especiais - Qualidade de Software 2008/2
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
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) Caracterizar inicialmente o grau de implementação de cada resultado esperado do processo e de cada resultado de atributo do processo na UO. Caracterizar inicialmente o grau de implementação de cada atributo de processo na UO. Caracterizar o grau de implementação dos processos na UO. 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
ISO/IEC 12207 CMMI-DEV ISO/IEC 15504 Programa MPS.BR Modelo de Referência (MR-MPS) Método de Avaliação (MA-MPS) Modelo de Negócio (MN-MPS) Guia Geral Guia de Aquisição Guia de Avaliação Documento do Programa Guias de Implementação Tópicos Especiais - Qualidade de Software 2008/2

81 MN-MPS: Modelo de Negócio
II & IA Programa MPS.BR (SOFTEX) Convênio Contrato Contrato MNC MNE 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) Tópicos Especiais - Qualidade de Software 2008/2

82 Capacitação MPS.BR 16h Workshops: W1 – de Introdução
C1 - Curso Introdução ao MPS.BR 16h Workshops: W1 – de Introdução W2 – de Implementadores W3 – de Avaliadores W4 – de Aquisição W5 – de Organização de Grupos de Empresas P1 - Prova Introdução ao MPS.BR C2 – Curso Implementadores MR-MPS C3 - Curso Avaliadores MA-MPS C4 - Curso Guia de Aquisição 24h 24h 16h P2 - Prova Implementadores MR-MPS P3 - Prova Avaliadores MA-MPS P4 - Prova Guia de Aquisição Implementador MR-MPS Avaliador Adjunto MA-MPS Consultor em Aquisição, após projeto assistido Tópicos Especiais - Qualidade de Software 2008/2

83 Tópicos Especiais - Qualidade de Software 2008/2
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 e 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 Tópicos Especiais - Qualidade de Software 2008/2
Custos MPS.BR Modelo Cooperado (Implementação+ Avaliação): 50% SOFTEX, 50% Empresa (aproximadamente) Nível G: aproximadamente R$ ,00 (Total) Nível F: aproximadamente R$ ,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$ ,40 Avaliação: R$ 9.984,00 Total: R$ ,40 SOFTEX: R$ ,00 TecVitória: R$ 8.800,00 Empresas: R$ ,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 Tópicos Especiais - Qualidade de Software 2008/2
Situação Atual Empresas certificadas no triênio : 105 19 Instituições Implementadoras 9 Instituições Avaliadoras 18 Implementações em Grupos de Empresas Fonte: em A B C D E F G 2006 2 1 7 2007 12 41 2008 8 28 Total 4 3 21 76 Tópicos Especiais - Qualidade de Software 2008/2

86 Tópicos Especiais - Qualidade de Software 2008/2
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 Tópicos Especiais - Qualidade de Software 2008/2
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. Tópicos Especiais - Qualidade de Software 2008/2


Carregar ppt "Qualidade de Processo de Software MPS.BR"

Apresentações semelhantes


Anúncios Google