Mostrando postagens com marcador Modelos de Maturidade. Mostrar todas as postagens
Mostrando postagens com marcador Modelos de Maturidade. Mostrar todas as postagens

quarta-feira, 10 de março de 2010

MPT.BR - Modelo de maturidade em teste de software

Assim como existem modelos para medir a maturidade de uma empresa no desenvolvimento de software, tais como MPS.BR e CMMI, existem também modelos para medir a maturidade da organização no processo de teste do software.

Aqui no Brasil está sendo desenvolvido o modelo MPT.BR - Melhoria de Processo de Teste de Software Brasileiro.

Duas entidades trabalham em conjunto no seu desenvolvimento:

  • ALATS – Associação Latino Americana de Teste de Software
  • RIOSOFT – Sociedade Núcleo de Apoio à Produção e a Exportação de Software

O conceito do modelo de maturidade no teste é o mesmo do modelo de maturidade no desenvolvimento de software. Ambos procuram determinar em que estágio de maturidade a organização se encontra naquele assunto e classifica os diversos estágios em diferentes graus de maturidade.

Segundo a ALATS, o MPT.BR foi criado com o objetivo de manter a compatibilidade com o MPS.BR e com o CMMI e permitir que empresas que implementaram um dos dois na sua área de desenvolvimento, possam, com um pequeno esforço adicional, aumentar o nível de maturidade da sua área de teste de software. Entende-se que a melhoria da área de desenvolvimento, por si só, é insuficiente para que os resultados melhorem substancialmente. Acredita-se que seja necessária uma melhoria de maturidade também da área de teste de software.

O MPT.BR é leve e passível de ser adotado por áreas de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos operacionais.

Os critérios usados pelas duas entidades na estruturação do modelo foram:

  • Definir critérios que garantam a qualidade do processo de teste de software
  • Não criar nada novo, logo a base é um modelo de melhoria do processo de desenvolvimento de software, no caso o MPS.BR (ou CMMI), já existente no mercado
  • Poder ser usado por áreas de teste de software de empresas pequenas, médias e grandes
  • Permitir a evolução das áreas de testes atingindo níveis mais altos de maturidade e, conseqüentemente, níveis mais altos de qualidade

Os níveis de maturidade definidos no modelo são:

  • Nível 1 Gerência de Projetos de Teste - GPT
  • Nível 2 Gerência de Requisitos de Teste - GRT
  • Nível 3 Aquisição – AQU (opcional); Gerência de Configuração – GCO; Garantia da Qualidade - GQA; Medição - MED
  • Nível 4 Gerência de Recursos Humanos - GRH; Gerência de Reutilização - GRU (opcional)
  • Nível 5 Desenvolvimento de Requisitos - DRE; Integração do Produto - ITP; Validação - VAL (opcional); Verificação
  • Nível 6 Análise de Decisão e Resolução - ADR; Desenvolvimento para Reutilização - DRU (opcional); Gerência de Riscos - GRI
  • Nível 7 Análise de Causas e Resolução de Problemas

Abaixo, estão listados alguns outros modelos de maturidade de teste existentes no mercado:

  • Testability Suport Model (TSM)
  • Testing Maturity Model (TMM)
  • Test Process Improvement (TPI)
  • Test Organization Maturity (TOMtm)
  • Testing Assessement Program (TAP)
  • Testing Improvement Model (TIM)
  • Outros (Ex.: MMT)

Porém, os diversos modelos existentes apresentam alguns problemas que acabaram por levar à definição do modelo MPT.BR:

  • Não existe uma entidade no Brasil responsável pela manutenção dos modelos
  • Foram elaborados por entidades privadas
  • Não são fáceis e nem baratos de serem implementados

Comparação entre os níveis de maturidade do CMMI, MPS.BR e MPT.BR:

  • MPT: Nível 1 - MPS: Sem correspondência - CMMI: Sem correspondência
  • MPT: Nível 2 - MPS: Nível G - CMMI: Sem correspondência
  • MPT: Nível 3 - MPS: Nível F - CMMI: Level 2
  • MPT: Nível 4 - MPS: Nível E - CMMI: Sem correspondência
  • MPT: Nível 5 - MPS: Nível D - CMMI: Sem correspondência
  • MPT: Nível 6 - MPS: Nível C - CMMI: Level 3
  • MPT: Nível 7 - MPS: Nível A - CMMI: Level 4, 5


sábado, 6 de dezembro de 2008

Por que optar pelo modelo de maturidade MPS.BR

O modelo de maturidade para desenvolvimento de software mais conhecido internacionalmente é o CMMI.

Ele vem sendo adotado por diversas empresas de software que estão buscando melhorar os seus processos de desenvolvimento e a qualidade do produto final, além de se posicionarem melhor no mercado como empresas que oferecem um diferencial de qualidade.

No Brasil, surgiu uma iniciativa do SOFTEX, apoiada pelo governo, por empresas e por universidades, que criou o modelo de maturidade MPS.BR, que é declaradamente inspirado no CMMI.

Então, o que leva as empresas deixarem de optar por um modelo de reconhecimento internacional, como o CMMI e passarem a usar um modelo que é reconhecido quase exclusivamente no Brasil e apenas recentemente está começando a ter alguma penetração na América Latina?

Existem razões muito boas que justificam esta opção. Eu vou elencar as principais:

  • Existem empresas que não estão objetivando o mercado internacional.

Para empresas de atuação local, não é necessária uma certificação de reconhecimento internacional. Se a empresa obtiver uma certificação que é bem conceituada no Brasil, isto é suficiente para cumprir os seus objetivos internos, como melhoria dos processos, e os externos, como o reconhecimento do mercado.

  • Compatibilidade plena com o CMMI e com a norma ISO/IEC 15504.

A norma ISO/IEC 15504, que trata da avaliação de processos de software, serviu de base para o CMMI, que por sua vez, serviu de base para o MPS.BR. Ou seja, uma certificação em MPS.BR, garante que a empresa está cumprido plenamente o modelo proposto pelas outras duas entidades.

  • Criado para a realidade brasileira, onde a maioria das empresas que desenvolvem software são micro, pequenas ou médias.

O MPS.BR foi criado com o objetivo principal de atender a realidade brasileira, onde a maioria das empresas desenvolvedoras são pequenas. Por isso, ele propõe a divisão da certificação em mais níveis, com custos mais baixos e a possibilidade de se criar grupos de empresas para se certificarem.

  • A divisão em mais níveis, o que permite uma implementação mais gradual.

Enquanto o CMMI possui 4 níveis de maturidade avaliados (já que o nível 1 não é avaliado), o MPS.BR possui 7 níveis de avaliação. Com isso, a implantação pode ser feita de forma mais gradual, com passos menores e os resultados no produto final começam a aparecer mais rapidamente.

  • A possibilidade de montar grupos de empresas.

O modelo de negócios do MPS.BR, prevê a existência de Instituições Organizadoras de Grupo de Empresas (IOGE), que são instituições autorizadas pela SOFTEX, como organizadoras de grupos de empresas para implementação do modelo em conjunto. O que possibilita a redução dos custos de implementação.

  • O custo do processo de certificação e das consultorias.

Para implementar um modelo de maturidade, inevitavelmente, a empresa terá que contratar uma consultoria especializada, além disso, existe o custo da certificação, que precisa ser feita por instituições credenciadas. Enquanto no CMMI, quem presta este tipo de serviço são grandes consultorias multinacionais, que cobram preços além da realidade de uma pequena empresa e, também, prestam serviços normalmente para outras organizações internacionais. No MPS.BR, tanto a consultoria quanto a certificação são feitas por empresas de atuação regional, que tem custos bem mais próximos da realidade de empresas de pequeno porte.

  • Avaliação bienal das empresas.

No MPS.BR a certificação tem que ser revalidada a cada dois anos, o que garante a manutenção dos níveis de qualidade.

  • Integração com o meio acadêmico.

Como o MPS.BR é mantido em parte por instituições de ensino, isto garante uma integração permanente do modelo com o meio acadêmico, possibilitando a absorção dos avanços obtidos em pesquisas.

Em resumo, razões não faltam para que determinados tipos de organização optem pelo MPS.BR.

Maiores informações em: http://www.softex.br/mpsbr/

segunda-feira, 6 de outubro de 2008

Modelos de maturidade em gestão de projetos - OPM3

Os profissionais da área de TI já estão habituados há algum tempo a lidar com modelos de maturidade no desenvolvimento de software, onde os mais conhecidos no Brasil são o CMMI e o MPS.BR. Estes modelos procuram determinar quanto uma organização está madura no processo de desenvolvimento de softwares. Quanto maior o nível de maturidade da organização, melhor é a qualidade do produto final.

Porém, começa a ficar mais comum no mercado se falar em “modelo de maturidade em gestão de projetos”. O princípio é o mesmo dos modelos de software: eles procuram medir a maturidade da organização no gerenciamento de seus projetos, portfólios e programas. Quanto maior o nível de maturidade, melhor a qualidade dos projetos tratados pela organização.

Os modelos de maturidade de gestão projetos mais comuns no mercado são:

· ESI – International’s Project Framework

· PMMM – Project Management Maturity Model

Criado por Harold Kerzner em 2001 e descrito no livro “Strategic Planning for Project Management using a Project Management Maturity Model”. John Wiley & Sons. Composto de cinco níveis de maturidade, a exemplo do CMMI.

· Prado-MMGP (Modelo de Maturidade em Gerenciamento de Projetos) – veja detalhes no blog PontoGP.

Está descrito no livro “Maturidade em Gerenciamento de Projetos”, Darci Prado. Não chega a ser um modelo muito popular, mas, é um exemplo de um modelo desenvolvido no Brasil.

Porém, neste post, eu vou me concentrar no modelo OPM3 do PMI. Depois eu entro em mais detalhes sobre os modelos acima.

· OPM3 – Organizational Project Management Maturiry Model

É um modelo desenvolvido pelo PMI (Project Management Institute), que é responsável também pelo PMBOK, o guia de referência em gerenciamento de projetos mais conhecido no mundo. Por isso, o OPM3 é 100% compatível com o PMBOK. Ele foi desenvolvido de forma virtual em 35 países, com o apoio de mais de 800 voluntários com experiência em gerenciamento de projetos na identificação das melhores práticas.

Ele é estruturado a partir de um conjunto de Melhores Práticas (Best Practices), que são formadas a partir de um agrupamento de Capacidades (Capabilities):

Melhores Práticas (Best Practices)

Uma Melhor Prática é um caminho ótimo atualmente reconhecido pela indústria para se alcançar um objetivo. Para o gerenciamento de projetos organizacional, isto inclui a habilidade para entregar projetos consistentemente e com sucesso para implementar estratégias organizacionais. Existem aproximadamente 702 Melhores Práticas documentadas.

Elas são categorizadas de acordo com os domínios de Gerenciamento Organizacional de Projetos: Projeto, Programa e Portfólio. E também pelos níveis de maturidade de melhoria de processos: Padronizar, Medir, Controlar, Continuar melhorando:

Capacidades (Capabilities)

Um conjunto de Capacidades é que dão a possibilidade de alcance de uma Melhor Prática. São passos incrementais rumo a níveis superiores de maturidade. A existência de uma capacidade é demonstrada pela existência de seus Resultados (Outcomes) correspondentes.

As Capacidades são categorizadas por grupos de processos: Iniciar, Planejar, Executar, Controlar e Concluir.

Resultados (Outcomes)

É o resultado tangível ou intangível da aplicação ou demonstração de uma capacidade.

KPI (Key Performance Indicators)

Representa a medição de um Outcome através de uma métrica.

A estrutura geral do modelo é:

O modelo contempla um “Diretório de Melhores Práticas”, onde elas são documentadas e um “Diretório de Capacidades” associadas a uma dada Melhor Prática.

O modelo é baseado em um ciclo constituído de: Conhecimento, Avaliação e Aperfeiçoamento. Portanto, para se fazer a avaliação da maturidade da organização, é preciso seguir os passos abaixo:

  1. Estudar o modelo

Ler e obter o conhecimento básico do OPM3, seus componentes e operação.

  1. Realizar a Avaliação

Determinar o ambiente geral no “continuum” da maturidade organizacional de gerenciamento de projetos.

  1. Determinar o foco de melhoria

Identificar as áreas de Melhores Práticas mais carentes de melhoria.

  1. Determinar o caminho de melhoria

Identificar as Capacidades necessárias para executar as melhorias com base nas Melhores Práticas.

  1. Avaliar as Capacidades atuais

Determinar quais Capacidades identificadas no passo anterior já existem na organização e quais devem ser desenvolvidas.

  1. Plano para Melhorias

Criar plano para o desenvolvimento de Capacidades necessárias para executar as Melhores Práticas, priorizando conforme identificado anteriormente. Alinhar as necessidades da organização e recursos disponíveis. Aplicar processos descritos no guia PMBOK

  1. Implementar Melhorias

Pôr em prática o plano de melhorias. Reajustar o plano de acordo com o clima da organização.

  1. Repetir o processo

Reavaliar a organização para confirmar ou não o progresso. Continuar trabalhando em Melhores Práticas identificadas anteriormente.

O PMI oferece duas ferramentas para realizar a avaliação da organização: “OPM3 Self Assessment” permite uma avaliação mais superficial da organização e “OPM3 ProductSuite” onde a avaliação é conduzida por um consultor certificado. Ambas são cobradas.

A avaliação é feita a partir de um questionário com 151 questões, veja o início do questionário:

O resultado é dado de forma a mostrar o nível de maturidade da organização em relação às várias categorias analisadas e às Melhores Práticas que devem ser melhoradas: