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.

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.