Abordagem CMM (Capability Maturity Model)

Segundo refere Salviano (2003) as organizações estão sobrecarregadas reagindo a crises constantes (postura reactiva em detrimento de uma postura proactiva), deparam-se com problemas de gestão e técnicos (embora os primeiros sejam maiores). A qualidade do processo de desenvolvimento deve ser melhorada para que se consiga melhorias de qualidade ao nível do produto. O autor refere que a melhoria do processo implica uma maior previsibilidade dos resultados, um melhor ambiente de trabalho e satisfação das pessoas, uma maior capacidade na gestão da complexidade, uma maior visibilidade da execução dos projectos, uma maior produtividade e por fim uma maior qualidade do produto.

A análise de qualidade pode ser orientada quer ao processo quer ao produto e os modelos de qualidade de software podem estar orientados para qualquer uma destas visões complementares. O modelo CMM foi desenvolvido pelo SEI (Software Engineering Institute) e é orientado à melhoria do processo de desenvolvimento. O modelo CMM para software constitui um guia para as organizações em como controlar o processo de desenvolvimento e manutenção de software e de implementar uma cultura de engenharia de software e de excelência da gestão (Paulk et al. 1993b). Conforme refere Abreu (2000b) é um modelo de evolução que fornece um conjunto de

recomendações sobre a sequência das acções que se devem tomar para a organização transitar de nível de maturidade.

A maturidade é entendida como sendo o grau de capacidade segundo o qual uma organização desenvolve software de forma que este cumpra as expectativas dos clientes, tenha um número mínimo de defeitos, custo mínimo, seja construído no menor espaço de tempo e seja fácil de manter (Abreu 2000b). A avaliação de maturidade pode ser feita para determinar o perfil de uma organização (pontos fortes e fracos), para determinar acções necessárias à melhoria, ou para certificar o nível de maturidade.

É importante salientar que o modelo CMM não impõe uma escolha de um determinado ciclo de desenvolvimento. Paulk et al. (1993a) referem “the key practices are not meant to limit the choice of a software life cycle. People who have extensively used one particular software life cycle may perceive elements of that life cycle in the organization and structure of the key practices. However, there is no intent either to encourage or preclude the use of any particular software life cycle”.

O CMM evoluiu para o CMMI (Capability Maturity Model Integrated), uma variante com bases na arquitectura bidimensional da norma ISO/IEC 15504 que vem tentar resolver o problema da existência de múltiplos modelos. Tem como base os modelos SW-CMM (Software Capabibility Maturity Model), SECM (System Engineering Capability Model) e IPD-CMM (Integrated Product Development Capability Maturity Model). Em 2000 foi lançada a versão 1.0 do modelo CMMI, tendo evoluído para a versão 1.1 em 2002. O CMMI cobre actualmente (embora possam ser acrescentadas mais) 4 disciplinas: Engenharia de sistemas, engenharia de software, desenvolvimento

integrado de produtos e processos e contratação de fornecedores. Conforme referido pela CMMI Product Team (2002a) “developing a set of integrated models has involved more than simply adding existing model materials together. Using processes that promote consensus, the CMMI Product Team has built a framework that accommodates multiple disciplines and is flexible enough to support two different representations (staged and continuous)”.

O CMMI considera duas representações. A representação contínua coloca do lado da organização, a escolha dos processos que devem ser melhorados em primeiro lugar. A abordagem por fases define um caminho em termos da ordem dos processos que devem ser melhorados para que a organização possa subir de nível (maturidade). Conforme referido pelo CMMI Product Team (2002a) a representação contínua aproxima-se da norma ISO 15504, enquanto a representação por fases aproxima-se do SW-CMM. Conforme referido por estes, a representação contínua utiliza os níveis de capacidade para medir a melhoria do processo, enquanto a representação por fases utiliza níveis de maturidade.

O CMMI considera 6 níveis de capacidade: Incompleto, Executado, Gerido, Definido, Gerido Quantitativamente e Optimizado. As áreas-chave de processo não estão distribuídas por níveis, estas é que são medidas em relação ao seu grau de capacidade. A óptica da representação contínua considera que, tanto os processos como o objectivo de capacidade de cada um deles, deve ser seleccionado e trabalhado pela organização de acordo com os seus objectivos de negócio. Estes processos podem ser agrupados por categorias conforme Tabela 13.

Tabela 13 – Distribuição das áreas-chave de processo no CMMI

Categorias de processo Processos

Gestão do Processo  Foco no processo da organização

 Definição do processo da organização  Formação

 Desempenho do processo da organização  Inovação na organização e disseminação

Gestão de Projecto  Planeamento do projecto

 Monitoramento e controlo de projeto  Gestão de acordos de fornecimento  Gestão do projecto integrada  Gestão de risco

 Gestão quantitativa do projecto

Engenharia  Desenvolvimento de requisitos

 Gestão de requisitos  Solução técnica  Integração do produto  Verificação

 Validação

Processos de Apoio  Gestão de configuração

 Garantia de qualidade do processo e produto  Medição e análises

 Análise de decisão e resolução  Análises causais e resolução

Os níveis de maturidade referem-se à maturidade global da organização e cada nível de maturidade é composto por um conjunto de áreas de processo (abordagem por fases). São considerados 5 níveis de maturidade, sendo cada um deles composto por áreas- chave do processo (Tabela 14).

Tabela 14 - Níveis de maturidade (modelo por fases)

Níveis e características Áreas-Chave do processo

Nível 1: Inicial

O desenvolvimento de qualidade está dependente da competência das pessoas (processo ad hoc). Os maiores problemas são de gestão e não técnicos. A organização possui um controle de informal de processos.

Não existem áreas-chave.

Nível 2: Gerido

São definidos processos básicos de gestão de projecto para controlo de custos, prazos e funcionalidade. É possível repetir práticas bem sucedidas em novos projectos.

 Gestão de requisitos  Planeamento de projecto

 Monitorização e controlo de projecto  Gestão de acordos de fornecimento  Medições e análises

 Garantia de qualidade de processo e produto

 Gestão da configuração

Nível 3: Definido

A organização dispõe de um processo de desenvolvimento definido. Existe a preocupação com

 Análise de decisão e resolução  Gestão do risco

um processo padronizado para a organização e customizado para cada projecto. O processo é definido, documentado e compreendido.

 Formação

 Definição do processo da organização  Foco no processo da organização  Validação

 Verificação

 Integração do produto  Solução técnica

 Desenvolvimento de requisitos

Nível 4: Gerido Quantitativamente

O processo é gerido e medido. É possível prever o desempenho dentro de limites quantificados. O processo é medido de forma a que se possa actuar sobre ele.

 Gestão quantitativa do projecto

 Desempenho do processo da organização

Nível 5: Optimizado

Foco na melhoria contínua do processo, na qual a mudança de tecnologia e as mudanças no próprio processo são geridas de forma a não terem impacto na qualidade do produto final.

 Análises causais e resolução

 Inovação na organização e disseminação