SOFTWARE

33

Capability Maturity Model

Integration (CMMI) 4Introdução

Este capítulo tem como objetivo mostrar um modelo de processo desenvol-vido especialmente para a realização de projetos de engenharia, incluindo a de software. Além desta apresentação abordaremos o conceito de maturidade em produtos de software, como o próprio nome do modelo nos diz.

Ao falar de maturidade em projetos de software, impossível não ser pré-requisito para isto as disciplinas de engenharia de software. Além destas disci-plinas, vocês devem ter em mente todos os conceitos de qualidade vistos até aqui na disciplina. Com base nestas questões, com certeza você terá um ótimo desempenho dentro de mais esse capítulo.

Entender qualidade de software sem entender e dar maturidade a ele é bastante complicado e, portanto, devemos sempre entender que qualidade pode ser alcançada, dando maturidade aos processos que compõem o desenvolvi-mento de determinado produto, no nosso caso, de software.

O modelo CMMI foi criado pelo Instituto de Engenharia de Software (SEI – Software Engineering Institute) para aumentar as capacitações da indústria de software nos EUA. Em meados da década de 1980, o SEI iniciou um estudo de formas de avaliação de capacitação de fornecedores. O resultado desta avaliação de capacitação foi o Modelo de Maturidade de Capacitação (CMM). Esse modelo exerceu forte infl uência no convencimento da comunidade de enge-nharia de software em considerar seriamente o aprimoramento de processos. O CMM para software foi seguido por uma variedade de outros modelos de matu-ridade de capacitação, entre eles o Modelo de Maturidade de Capacitação de Pessoas (P-CMM – People Capability Maturity Model) (SOMMERVILLE, 2007).

Desde então, tomando como base o modelo CMM foram desenvolvidos vários modelos de maturidade específi cos para software. O modelo Spice e o Bootstrap são exemplos destes.

Sommerville (2007) então explica que em uma tentativa de integrar a grande quantidade de modelos que foram desenvolvidos, o SEI embarcou em um novo programa para desenvolver um modelo de capacitação integrada (CMMI). Este substitui os CMMs de Engenharia de Sistemas e o de Software e integra outro modelo de engenharia. Tem duas representações, por estágio e contínuo, e resolve alguns pontos fracos do modelo CMM para software. Com base nestes

GEST_QUALI_SOFTWARE.indd 33 5/1/2010 07:51:02

SOFTWARE

34

fatos, vamos tentar entender melhor o modelo CMMI nas nossas próximas seções, iniciando pelo entendimento de processos de software. Vamos lá. Bons estudos.

4.1 Processo de Software

Pessôa (2004, p. 11) define processo como sendo uma sequência de passos realizados para um determinado propósito. Já para software o conceito de processo é um pouco mais abrangente pois precisa explicitar as especificidades deste. Portanto, temos que processo de software é um conjunto de atividades, métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter software e seus produtos relacionados.

Figura 1 As três dimensões críticas das organizações.

Fonte: Costa e Resende (2008, p. 86).

Podemos ver como devem ser os processos dentro de uma organização, visualizando as três dimensões críticas que as organizações geralmente focam as pessoas. Na figura 1, podemos observar estas três dimensões.

O resultado de um processo será um produto ou serviço dentro de uma organização. Por isso, a qualidade desse processo influenciará de forma única a qualidade do produto. Como estamos falando em software, podemos afirmar que para termos software de qualidade precisamos ter processos maduros e de qualidade no desenvolvimento deste software.

Tendo como base estes aspectos, podemos ter processos em três níveis dentro de uma organização, que são: imaturo, maduro e institucionalizado. Com base nestes níveis, vamos tentar enumerar como devem estar os processos quando vocês estiverem implantando um nível de maturidade dentro da organização.

TADS_5oP.indb 34 12/30/aaaa 15:48:38

SOFTWARE

Um processo imaturo é aquele (PESSÔA, 2004, p. 12):

Ad hoc; improvisado por profissionais e gestores.

Não é rigorosamente seguido e o seu cumprimento não é controlado.

Altamente dependente dos profissionais atuais.

Com baixa visão do progresso e da qualidade.

Cujas funcionalidades e qualidade do produto podem ficar comprome-tidas para que os prazos sejam cumpridos.

Arriscado do ponto de vista do uso de novas tecnologias.

Com custos de manutenção excessivos.

Com qualidade difícil de se prever.

Já um processo maduro, conforme Pessôa (2004, p. 13) é aquele:

É compreendido.

É utilizado.

Vivo e ativo.

Possui o apoio visível da alta administração e outras gerências.

É bem controlado e a fidelidade ao processo é objeto de auditoria e de controle.

Possui medições do produto e do processo.

Permite o uso disciplinado da tecnologia.

É institucionalizado, ou seja, todos o praticam.

A definição de institucionalização de processos é basicamente como o processo é desenvolvido na organização de forma já madura. As diversas carac-terísticas de um processo institucionalizado são (PESSÔA, 2004, p. 14):

é construída uma infraestrutura com processos eficazes, utilizáveis e consistentemente aplicada em toda organização;

a cultura organizacional deve conduzir e transmitir o processo;

a alta administração deve alimentar a cultura;

se ninguém se importa, todos se esquecem;

cultura é conduzida/transmitida através de modelos e recompensas;

processos institucionalizados permanecem, mesmo depois que as pessoas que originalmente os definiram, deixam a organização.

Bom, já que definimos bem processos e em que nível podem estar dentro de uma organização, vamos passar para o estudo real do modelo proposto neste capítulo.

GEST_QUALI_SOFTWARE.indd 35 5/1/2010 07:54:30

SOFTWARE

36

4.2 CMMI

Capability Maturity Model Integration ou CMMI é um modelo de maturi-dade de melhoria de processo para o desenvolvimento de produtos e serviços. Ele consiste das melhores práticas para as atividades de manutenção e desen-volvimento que cobrem o ciclo de vida de um produto, abrangendo desde a concepção até a entrega e manutenção (COSTA; RESENDE, 2008, p. 84).

Atualmente o CMMI está na versão 1.2 e está dividido em CMMI para:

Serviços: projetado para organizações provedoras de serviços que querem melhorar sua capacidade de criar, gerenciar e pres- tar serviços.

Aquisição: modelo projetado para organizações de aquisição que querem melhorar sua capacidade de adquirir produtos e serviços.

Desenvolvimento: modelo projetado para organizações de desenvolvi-mento que querem melhorar sua capacidade de desenvolver produtos e serviços.

Ainda definindo este modelo de maturidade Sommerville (2007) afirma que o modelo CMMI tem a intenção de ser um framework de aprimoramento de processos que tem aplicabilidade ampla por meio de uma variedade de empresas. A versão por estágios é compatível com o CMM para Software e permite aos processos de desenvolvimento e gerenciamento de sistemas de uma organização ser avaliados e que lhe sejam atribuídos um nível de maturi-dade de 1 a 5. A versão contínua permite uma classificação mais fina e avalia 24 áreas de processos em uma escala de 1 a 6.

Como o modelo é muito complexo, Sommerville (2007) tenta dividir o modelo em três partes, bem definidas, que são:

áreas de processo: o CMMI identifica 24 áreas de processos relevantes para a capacitação e aprimoramento do processo de software. Elas estão organizadas em quatro grupos no modelo CMMI contínuo. Esses grupos e áreas de processos relacionados estão listados na tabela 1;

objetivos: os objetivos são descrições abstratas de um estado dese-jado que devem ser atingidos por uma organização. O CMMI possui objetivos específicos que estão associados a cada área de processo e que definem o estado desejável para cada área. O modelo também define objetivos genéricos associados com a institucionalização de boas práticas. A tabela 2 mostra alguns objetivos genéricos e especí-ficos do CMMI;

práticas: As práticas do CMMI são descrições de maneiras de se atingir um objetivo. Mais de sete práticas genéricas e específicas podem

TADS_5oP.indb 36 12/30/aaaa 15:48:38

SOFTWARE

37

ser associadas com cada objetivo dentro de cada área de processo. Exemplos de práticas recomendadas são mostrados na tabela 3. No entanto, o CMMI reconhece que o objetivo é mais importante do que a maneira como o objetivo é alcançado. As organizações podem usar quaisquer práticas apropriadas para se atingir qualquer um dos objetivos do CMMI – elas não têm de adotar as recomendações do CMMI.

Tabela 1 Áreas de processo do CMMI.

CATEGORIA ÁREA DE PROCESSO

Gerenciamento de processo

Definição de processo organizacional

Foco no processo organizacional

Treinamento organizacional

Desempenho de processo organizacional

Inovação e implantação organizacional

Gerenciamento de projeto

Planejamento de projeto

Monitoração e controle de projeto

Gerenciamento de acordo com fornecedores

Gerenciamento de projeto integrado

Gerenciamento de riscos

Integração de equipes

Gerenciamento quantitativo de projeto

Engenharia

Gerenciamento de requisitos

Desenvolvimento de requisitos

Solução técnica

Integração de produto

Verificação

Validação

Apoio

Gerenciamento de configuração

Gerenciamento de qualidade processo e produto

Medição e análise

Análise de decisão e resolução

Ambiente organizacional para integração

Análise casual e resolução

Fonte: Sommerville (2007, p. 449).

TADS_5oP.indb 37 12/30/aaaa 15:48:38

SOFTWARE

38

Tabela 2 Exemplos de Objetivos no CMMI.

OBJETIVO ÁREA DE PROCESSO

Ações corretivas são gerenciadas até a conclusão quando o desempenho do projeto ou os resultados desviam significativamente do plano.

Objetivo específico na monito-ração e controle do projeto.

Desempenho real e o progresso do projeto são moni-torados contra o plano do projeto.

Objetivo específico na monito-ração e controle do projeto.

Os requisitos são analisados e validados e uma defi-nição da funcionalidade necessária é desenvolvida.

Objetivo específico no desenvol-vimento de requisitos.

O processo é institucionalizado como um processo definido.

Objetivo genérico.

Fonte: Sommerville (2007, p. 450).

Tabela 3 Práticas e objetivos associados ao CMMI.

PRÁTICA OBJETIVO ASSOCIADO

Analisar os requisitos derivados para assegurar que eles são necessários e suficientes.

Validar requisitos para assegurar que os produtos resul-tantes serão executados conforme esperado no ambiente do usuário usando várias técnicas quando apropriado.

Os requisitos são anali-sados e validados, e uma definição de funciona-- lidade necessária é desen- volvida.

Selecionar defeitos e outros problemas para análise.

Executar análise causal de defeitos selecionados e outros problemas e ações propostas para resolvê-los.

Causas principais de defeitos e outros proble- mas são sistematicamente determinados.

Estabelecer e manter uma política organizacional para planejamento e execução do processo de desenvolvimento de requisitos.

Atribuir responsabilidade e autoridade para executar o processo, desenvolvendo produtos de trabalho e forne-cendo os serviços do processo de desenvolvimento de requisitos.

O processo é instituciona-lizado como um processo definido.

Fonte: Sommerville (2007, p. 450).

Depois de descrevermos bem como se comporta este modelo, com suas áreas de processos, objetivos e práticas, a figura 1 mostra de forma geral como é estruturado este modelo e seus relacionamentos. O grande foco na área de processos que podemos observar no modelo CMMI, deve-se ao fato de que o SEI utiliza a seguinte premissa de gerenciamento de processo: a qualidade de um sistema ou produto é altamente influenciada pela qualidade dos processos usados para desenvolver e mantê-los.

TADS_5oP.indb 38 12/30/aaaa 15:48:39

SOFTWARE

39

Figura 1 Componentes do Modelo CMMI e seus Relacionamentos.

Fonte: Costa e Resende (2008, p. 90).

Esta visão apresentada na figura 1 deixa bem mais claro como podemos chegar à maturidade de processos utilizando este modelo, com suas áreas de processo, objetivos e práticas, genéricas e específicas. Já que definimos bem como deve se comportar o modelo, agora partiremos para a representação dele.

Saiba mais

Uma descrição geral de como se comporta o CMMI, com todas as suas características pode ser encontrada no portal do SEI <http://www.sei.cmu.edu/cmmi>. Lá as descrições e novas versões do CMMI são disponibiliza-das para que o profissional possa ter uma noção melhor e mais atualizada do modelo.

4.3 Representações do modelo CMMI

Como já mencionamos neste capítulo o modelo CMMI tem duas represen-tações: por estágios e contínuo. A escolha de qual das duas será implantada dentro de uma organização é influenciada por vários fatores, dentre os quais, podemos citar como principais: negócio, cultura e legado.

GEST_QUALI_SOFTWARE.indd 39 5/1/2010 07:57:03

SOFTWARE

40

Antes de vermos cada uma em detalhes vamos a um quadro compa-rativo inicial, onde poderemos observar qual a vantagem de cada representação.

Tabela 4 Comparação das vantagens das representações contínuas e por estágio.

REPRESENTAÇÃO CONTÍNUA

REPRESENTAÇÃO POR ESTÁGIOS

Garante liberdade total para sele-cionar a ordem de melhoria que melhor adapta-se aos objetivos do negócio da organização, redu-zindo as áreas de risco.

Propicia às organizações uma abordagem de melhoria provada e predefinida.

Propicia melhor visibilidade da capacidade alcançada, indivi-dualmente, em cada área de processo.

Foca um conjunto de processos que provê uma reorganização com uma capacidade especifica, isto é, caracterizado em cada nível de maturidade.

Propicia melhorias em diferentes processos aplicando-se taxas de melhorias diferentes.

Resume os resultados da melhoria de processo em um formulário simples – uma simples linha com o número do nível de maturidade.

Representa a abordagem mais recente, e ainda não se possuem dados para demonstrar seu rela-cionamento com o retorno dos investimentos.

Construído sobre um histórico rela-tivamente longo que inclui estudos de caso e dados que demonstram retorno do investimento.

Fonte: Costa e Resende (2008, p. 89).

Na tabela 4, podemos observar as várias vantagens para uma melhor decisão a respeito de como constituir um modelo de representação do CMMI dentro da organização. Podemos destacar como uma das grandes vantagens da representação contínua, a primeira apresentada na tabela 4, pois esta liberdade de selecionar a ordem da que melhor adapta-se aos objetivos do negócio, traz ao gestor uma esplêndida ferramenta. Já na representação por estágio, a grande vantagem que podemos observar é caracterizar em cada nível de maturidade um conjunto de processos e como eles devem ser reorganizados. O que traz a esta representação uma grande qualidade em relação à outra.

Agora vamos tentar descrever melhor como se comportam as duas represen-tações, descritas em seus níveis na figura 2.

GEST_QUALI_SOFTWARE.indd 40 1/5/aaaa 19:47:22

SOFTWARE

41

Figura 2 As duas representações do CMMI.

Fonte: Pessôa (2004, p. 17).

A grande diferença entre as duas representações que podemos observar na figura 2 é que, a representação contínua tem um nível a mais definido, além do que, no contínuo você pode mensurar processos individuais, enquanto que na por estágios, você mede os processos como um todo.

Descrevendo melhor os níveis de maturidade do modelo contínuo temos (PESSÔA, 2004, p. 22):

Nível 0 – incompleto: o processo não é executado ou é executado parcialmente.

Nível 1 – executado: o processo satisfaz as metas específicas da área de processo.

Nível 2 – gerenciado: o processo é executado e também planejado, monitorado e controlado para atingir um objetivo (em projetos indivi-duais, grupos ou processos isolados).

Nível 3 – definido: o processo é gerenciado, adaptado de um conjunto de processos padrão da organização.

Nível 4 – gerenciado quantitativamente: o processo é definido, contro-lado utilizando estatística ou outras técnicas quantitativas.

Nível 5 – de otimização: o processo é gerenciado quantitativamente para a melhoria contínua do desempenho do processo.

Os níveis do modelo estagiado, podem ser definidos ainda, como mostrados na figura 3.

GEST_QUALI_SOFTWARE.indd 41 1/5/aaaa 19:23:58

SOFTWARE

42

Figura 3 Níveis de Maturidade do CMMI no modelo Estagiado.

Otimização

Gerenciadoquantitativamente

Defi nido

Gerenciado

InicialProcesso imprevisível pobremente controlado e reativo

Processo caracterizado por projeto e frequentemente reativo

Processo caracterizado para a organização e proativo

Processo medido e controlado

Foco na melhoria de processo5

4

3

2

1 InicialProcesso imprevisível pobremente controlado e reativoProcesso imprevisível pobremente controlado e reativoProcesso imprevisível pobremente 1

GerenciadoProcesso caracterizado por projeto e frequentemente reativoProcesso caracterizado por projeto e frequentemente reativoProcesso caracterizado por 2

Defi nidoProcesso caracterizado para a organização e proativo

3

GerenciadoquantitativamenteProcesso medido e controlado4

OtimizaçãoFoco na melhoria de processo5

Fonte: Pessôa (2004, p. 18)

Interessante qualifi car que qualquer um dos modelos de representação do CMMI, apresentam um alto grau de complexidade quando vamos implantá-los dentro de uma organização, por isso, devemos ter realmente foco no desenvol-vimento e implantação do CMMI, para que possamos alcançar um nível alto de maturidade.

Antes de fi nalizarmos nosso capítulo, vamos ver alguns pontos chaves que Sommerville (2007, p. 453) levanta e que devemos ter muito em mente quando vamos implantar um modelo de maturidade. Vamos a eles.

O aprimoramento de processos envolve a análise de processo, padroni-zação, medição e mudança. O treinamento é essencial para a efi ciên-cia do aprimoramento de processos.

Os processos podem ser classifi cados como informais, gerenciados, metódicos e de aprimoramento. Essa classifi cação pode ser usada para identifi car o apoio de ferramentas aos processos.

O ciclo de aprimoramento de processos envolve medição, análise e modelagem, e mudança de processos.

As medições devem ser usadas para responder a questões específi cas sobre o processo de software usado. Essas questões devem basear-se nos objetivos de aprimoramento organizacionais.

Os três tipos de métricas usadas no processo de medição são métricas de tempo, métricas de uso de recursos e métricas de eventos.

Modelos de processos incluem descrições de atividades, subprocessos, papéis, exceções, comunicações, entregas e outros processos.

O modelo de maturidade de processo CMMI é um modelo de aprimo-ramento de processos que apoia tanto os aprimoramentos de processo por estágios quanto os contínuos.

GEST_QUALI_SOFTWARE.indd 42 5/1/2010 08:00:29

SOFTWARE

43

O aprimoramento de processos no modelo CMMI baseia-se no alcance de um conjunto de objetivos relacionados às boas práticas de enge-nharia de software e na descrição, padronização e controle de práticas usadas para atingir esses objetivos. O modelo CMMI inclui práticas recomendadas que podem ser usadas, mas não são obrigatórias.

Chegamos aqui ao final de mais um capítulo onde abordamos um modelo bastante utilizado de maturidade em processos de desenvolvimento de software, o CMMI. Desenvolvemos neste capítulo a ideia de como podemos ter processos dentro das organizações, ou seja, suas classificações e demonstramos como o CMMI pode classificar uma organização, baseada na maturidade de seus processos. Vimos também as duas formas de representação do CMMI que são: por estágios e contínuo.

No próximo capítulo, vamos ver algo bem brasileiro. Uma norma de melho-ramento de processo de software baseada em padrões brasileiros e que se adequa à nossa cultura.

Referências

COSTA, Heitor Augusto Xavier; RESENDE, Antonio Maria Pereira de. Maturidade e Excelência em Softwares e Produtos de TI. Lavras: UFLA/FAEPE, 2008.

PESSÔA, M. S. P., Introdução ao CMMI – Modelo Integrado de Maturidade da Capacidade de Processo. Lavras: UFLA/FAEPE, 2004.

SOMMERVILEE, I. Engenharia de Software. São Paulo: Pearson Addison-Wesley, 2007.

Anotações

TADS_5oP.indb 43 12/30/aaaa 15:48:39