Modelo CMM - Uma visão geral

Autores:
Lilia Pinheiro Cristaldi Silva - GPS
Luiz Carlos de Almeida Oliveira - GPS


O modelo CMM – Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo de profissionais de software, sendo a 1ª versão lançada em ago/1991.

Surgiu da necessidade de atender a uma demanda do governo federal dos EUA, de criação de um método para avaliar a capacitação de seus fornecedores de software. Em set/87 o SEI lançou uma breve descrição de um ambiente de maturidade de processo de software e desenvolveu dois métodos (1 - avaliação do processo de software, e 2 - avaliação da capacidade de software) e um questionário de maturidade para avaliar a maturidade do processo de software. A "Avaliação do processo de software" tem o objetivo de determinar o nível do processo atual de desenvolvimento de software de uma organização, e a "Avaliação da capacidade de software" objetiva identificar fornecedores qualificados para o desenvolvimento de software.

Após quatros anos de experiência com o ambiente de maturidade do processo de software e o questionário de maturidade, o SEI evoluiu esse ambiente de maturidade para o CMM – Modelo de Maturidade da Capacitação.

Para se entender esse conceito trazido pelo CMM da maturidade do processo de software, é preciso entender alguns conceitos básicos que são usados para descrever uma organização madura.

Segundo o IEEE, "Processo" é uma seqüência de passos realizados para atingir um determinado objetivo, e pelo CMM, um "Processo de Software" é um conjunto de atividades, métodos, práticas e transformações que as pessoas usam para desenvolver e manter o software e seus produtos associados. O CMM tem seu foco no processo de software por entender que a qualidade de um sistema de software é fortemente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo. Portanto, uma premissa do CMM é o foco no "processo" da mesma forma que no "produto", pois enfocando apenas o "produto" se perde o conhecimento de como produzí-lo melhor por não se ter desenhado, conhecido e, constantemente, melhorado o processo utilizado para desenvolver o produto.

A "capacidade do processo de software" descreve o conjunto de resultados esperados que pode ser atingido quando se segue o processo de software estabelecido. Já a "maturidade do processo de software" é o quanto um processo específico é explicitamente definido, gerenciado, medido, controlado e efetivo. Maturidade implica num potencial de crescimento da capacidade e indica tanto a riqueza do processo de software de uma organização, quanto a consistência na qual o processo é aplicado nos projetos de toda a organização.

Conforme as empresas de software vão evoluindo, seus processos de software se tornam melhores, mais bem definidos e são implementados mais consistentemente em toda a organização. Esse foco do CMM no "processo" é uma forma de potencializar as pessoas que desenvolvem e participam do processo de desenvolvimento do software. Um processo de software efetivo significa que pessoas, métodos e tecnologia formam um todo integrado.

Quando o processo de desenvolvimento de software de uma organização é imaturo, o processo é improvisado pelos técnicos e gerentes, não sendo, portanto, rigorosamente seguido; existe uma dependência grande dos técnicos atualmente responsáveis pelo projeto; é difícil de se perceber o andamento e qualidade do projeto; o uso de novas tecnologias é um risco; o custo da manutenção é alto e é difícil de se prever a qualidade final do produto. Muitas organizações com essas características estão constantemente "apagando incêndio", portanto reagindo, sem tempo para analisar e propor melhorias no processo de desenvolvimento do software.

Numa empresa de software que tem um processo maduro existe uma consistência na forma que o trabalho é feito, definido, documentado e constantemente melhorado. O processo é conhecido, utilizado e dinâmico, uma vez que é continuamente otimizado. Nessas empresas o desenvolvimento dos projetos é visível, a utilização do processo é controlada e medida, a inserção de novas tecnologias é feita de forma disciplinada, e as pessoas desenvolvem seu potencial mais plenamente, sendo mais produtivas para a organização.

É importante ressaltar que para que um processo seja institucionalizado é imprescindível o comprometimento da administração em todos os seus níveis e a implementação de uma infra-estrutura que comporte o uso efetivo de todos os processos. Um processo institucionalizado se torna independente das pessoas e perdura mesmo depois que as pessoas que originariamente o definiram tenham se afastado da empresa e/ou atividade.

Entendendo que a melhoria contínua do processo se baseia mais em pequenos passos evolutivos do que em inovações revolucionárias, o CMM estabelece esses passos evolutivos em 5 níveis de maturidade, que formam bases sucessivas para a melhoria contínua do processo. Esses níveis de maturidade definem uma escala para medir a maturidade do processo de software de uma organização e para avaliar a capacidade de seu processo de software. Definir um nível de maturidade significa estabelecer diferentes componentes do processo de software, que resultam num crescimento da capacidade do processo de uma organização.

wpe2.jpg (24724 bytes)

O CMM identifica os níveis através dos quais uma organização deve evoluir para estabelecer uma cultura de excelência na engenharia de software. Como cada nível de maturidade do CMM forma a base necessária sobre a qual o próximo nível será construído, normalmente tentar pular níveis é improdutivo, porque não haverá estabilidade na melhoria do processo, justamente pela falta da base que a sustentaria.

Através de todos os cinco níveis, a capacidade do processo interage com pessoas e tecnologias, conforme a organização vai amadurecendo.

Implicações do avanço através dos níveis do CMM:

Processos:

Nível 1:

  • existem poucos processos estáveis ou que estejam em uso;

  • "faça acontecer!"

Nível 2:

  • a nível do projeto, existem estimativas e planejamentos estáveis e documentados;

  • os problemas são percebidos e corrigidos conforme ocorrem.

Nível 3:

  • processos integrados de gerenciamento e engenharia de software são utilizados em toda a empresa;

  • os problemas são antecipados e prevenidos, ou seus impactos são minimizados.

Nível 4:

  • os processos são entendidos por todos e são estáveis;

  • fontes de problemas individuais são percebidos e eliminados.

Nível 5:

  • os processos são contínua e sistematicamente melhorados;

  • fontes comuns de problemas são percebidas e eliminadas.

Pessoas:

Nível 1:

  • o sucesso depende de talentos individuais;

  • "apagar incêndios" é um estilo de vida;

  • relacionamentos entre áreas são sem coordenação, as vezes até como se fossem adversários.

Nível 2:

  • o sucesso depende das pessoas, com o suporte do sistema de gerenciamento;

  • acordos são fechados e gerenciados;

  • as pessoas recebem treinamento necessário.

Nível 3:

  • grupos de projetos trabalham juntos, talvez como uma equipe integrada;

  • o treinamento é planejado e realizado de acordo com os perfis dos profissionais.

Nível 4:

  • forte sentido de equipe existe em cada projeto.

Nível 5:

  • forte sentido de equipe existe em toda a organização;

  • todos estão envolvidos no processo de melhoria.

Cada nível de maturidade é composto de algumas "áreas-chave de processo" (exceção feita ao Nível 1) consideradas como requisitos para se atingir um nível de maturidade. Portanto, para se atingir um determinado nível de maturidade, as áreas-chave de processo daquele nível (e dos níveis inferiores) devem estar atendidas e o processo institucionalizado.

O diagrama a seguir apresenta as áreas chaves de processo de cada nível de maturidade.

Inicial

- Não possui áreas-chave de processo.

Repetível

  • Gerenciamento de Requisitos;

  • Planejamento do Software;

  • Acompanhamento do Software;

  • Gerenciamento de Subcontratos de Software;

  • Garantia de Qualidade de Software;

  • Gerenciamento de Configuração de Software.

Definido

  • Foco do processo da organização;

  • Definição do processo da organização;

  • Programa de treinamento;

  • Gerenciamento integrado de software;

  • Coordenação entre grupos;

  • Ponto de Revisão.

Gerenciado

  • Gerenciamento quantitativo do processo;

  • Gerenciamento da qualidade de software.

Otimizado

  • Prevenção de defeitos;

  • Gerenciamento das mudanças tecnológicas;

  • Gerenciamento do processo de mudança.

As áreas-chave de processo do Nível 2 estão focadas nas questões do projeto de software relacionadas ao estabelecimento de controles básicos de gerenciamento do projeto, e têm os seguintes objetivos:

  • Gerenciamento de Requisitos:

Estabelecer um entendimento comum entre o cliente e os requisitos (desejos, necessidades) do cliente que serão atendidos pela solução a ser desenvolvida.

  • Planejamento do Projeto de Software:

Estabelecer planos coerentes para realizar a engenharia de software e o gerenciamento do projeto.

  • Acompanhamento do Projeto de Software:

Estabelecer uma adequada visibilidade do andamento (progresso) do software, de forma que o gerenciamento possa tomar ações corretivas se o planejamento original não estiver sendo seguido.

  • Gerenciamento de subcontrato de software:

Selecionar fornecedores qualificados e gerenciá-los de forma eficiente.

  • Garantia da Qualidade de Software:

Fornecer ao gerenciamento visibilidade do processo em uso e dos produtos em construção.

  • Gerenciamento de configuração de software:

Estabelecer e manter a integridade dos produtos durante todo o ciclo de vida do software.

As áreas-chave do Nível 3 estão focadas tanto nas questões do projeto, quanto da organização, conforme a organização estabelece uma infra-estrutura que efetivamente institucionaliza os processos de engenharia de software e de gerenciamento de todos os projetos.

As áreas-chave do Nível 4 estão focadas no estabelecimento quantitativo tanto do processo de software, quanto dos produtos em construção.

As áreas-chave do Nível 5 cobrem questões que tanto a organização, quanto os projetos devem considerar para implementar melhorias no processo de software que sejam contínuas e mensuráveis.

Na CELEPAR:

Temos utilizado na CELEPAR o modelo CMM como uma referência para a melhoria do nosso processo de desenvolvimento de software. O modelo tem nos auxiliado bastante na condução desta melhoria, indicando quais áreas-chave devem ser tratadas de forma prioritária.

A nossa Metodologia de Desenvolvimento de Serviços, a MDS-CELEPAR, vem sendo desenvolvida e aperfeiçoada a partir de duas referências básicas:

A Norma ISO/IEC 12207 – Processo de Ciclo de Vida de Software. Esta norma tem servido de referência para a definição da estrutura metodológica, identificando os processos que devem fazer parte do Ciclo de Vida de Software.

O Modelo CMM – Em conjunto com a norma ISO/IEC 12207, o modelo CMM tem servido de referência para a definição de quais os processos, identificados na norma, devem ser implementados a cada momento, em cada estágio. A norma apresenta uma estrutura de processos que seria a prática "ideal", enquanto o Modelo CMM apresenta uma referência para a condução da melhoria do processo rumo a esta prática ideal, ou seja, apresenta uma referência dos passos a serem seguidos.

Os processos descritos na atual versão da MDS-CELEPAR, estão focados nas áreas-chave do nível 2 do modelo CMM, de forma customizada à realidade da nossa Empresa.

O Modelo CMM tem nos sido muito útil, é uma referência de grande valia na condução da melhoria do processo de desenvolvimento de software. A sua utilização de forma combinada com outras normas também tem apresentado bons resultados, uma vez que cada norma/modelo foca aspectos diferentes, porém complementares, relacionados à melhoria da qualidade dos processos e produtos de software.

REFERÊNCIA BIBLIOGRÁFICA

SOFTWARE ENGINEERING INSTITUTE. The capability maturity model : guides for improving the software process. Reading : Addison Wesley, 1997.