Representação contínua

Ao escolher a representação contínua para a organização, o modelo CMMI:

• Permite selecionar a ordem e melhoria que mais se adéqua aos objetivos de negócios da organização e diminui as áreas de risco.
• Habilita que haja comparações em uma empresa e entre empresas por área de processo ou pela comparação de resultados em estágio equivalentes.

Há quatro níveis de capacidade, numerados de 0 até 3 (veja a Tabela 1). Cada nível de capacidade corresponde a metas genéricas e a um conjunto de práticas genéricas e específicas, conforme ilustra a Figura.

Representação contínua do CMMI. Fonte: adaptado de SEI (2010, p. 34)

Representação por estágio

Ao escolher a representação por estágio para a organização, o modelo CMMI:

• fornece uma sequência de melhorias, começando com práticas básicas de gerenciamento, progredindo através de um caminho de níveis sucessivos, cada um servindo como um fundamento para o seguinte.
• permite comparações entre organizações pelo uso de níveis de maturidade.
• fornece um valor simples que sumariza resultados avaliados e permite comparações entre organizações.

Há cinco níveis de maturidade, numerados de 1 a 5 (ver Tabela 1). A obtenção de um nível de maturidade permite assegurar que os fundamentos adequados de melhoria foram estabelecidos para o próximo nível de maturidade, permitindo a melhoria incremental dos processos na organização. Esta representação indica a ordem de implementação de cada área de processo, de acordo com o nível de maturidade, que define o caminho associado à melhoria dos processos de uma organização (desde o nível de maturidade inicial até ao nível de maturidade em otimização), conforme ilustra a Figura.

Representação contínua do CMMI. Fonte: baseado em SEI (2010, p. 34)

Representações do CMMI

O CMMI possui duas representações: contínua ou por estágios. Estas representações permitem à organização utilizar diferentes caminhos para a melhoria de seus processos de acordo com seu interesse. O CMMI divide cada estágio em áreas de processo e para cada uma delas são definidos dois conjuntos de metas: as específicas (specific goals) e as genéricas (generic goals). A essas metas, a definição do modelo recomenda práticas genéricas divididas em um conjunto de características comuns.

As metas específicas na maioria das vezes estão focadas no negócio da empresa e buscam alinhar o método CMMI às necessidades próprias. As metas genéricas focam em aspectos inerentes a qualquer empresa e devem ser consideradas para uma melhor implementação da metodologia, de forma a garantir a maximização dos resultados.

O método CMMI não é um processo simples de ser realizado. Exige uma mudança de cultura voltada para o planejamento, a qualidade e o controle dos processos de desenvolvimento de software.

Seleção de uma representação do modelo CMMI

O propósito do CMMI é fornecer um guia para melhorar processos de organizações e sua habilidade de gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços de software. O CMMI, através de sua estrutura, ajuda a organização a avaliar sua maturidade organizacional ou sua capacidade na área de processos, estabelecendo prioridades para melhoramentos e sua implementação.

Como vimos, o modelo CMMI apresenta dois caminhos a serem seguidos:

• Contínuo: permite que a organização evolua de forma incremental os processos correspondentes a uma PA (individual) ou a um grupo de área de processos selecionado pela empresa.
• Por estágios (estagiado): a evolução é feita em um grupo deprocessos relacionados que são endereçados ao se implementar grupos de áreas de processo pré-determinados sucessivos.

As representações são importantes, pois são elas que vão determinar o tipo de nível que será usado na organização.

“As duas representações estão associadas com dois tipos de níveis de melhoria: níveis de capacidade e níveis de maturidade. A representação contínua habilita a organização a alcançar níveis de capacidade. A representação por estágios habilita a organização a alcançar níveis de maturidade.”

Fonte: SEI (2010, p. 34, tradução nossa)

Para alcançar um nível em particular, a organização deve satisfazer todas as metas da PA ou todas as metas do conjunto de PAs que estão definidas para serem aprimoradas, independentemente do nível ser de capacidade ou de maturidade. Ambas as representações fornecem maneiras de aprimorar os processos para se alcançar os objetivos corporativos e ambas proveem o mesmo conteúdo em sua essência e usam o mesmo modelo de componentes.

Assim, caro aluno, é importante frisar que são duas formas de se chegar aos mesmos objetivos. Independentemente da representação adotada, os níveis caracterizam a melhoria e a evolução de um estado desorganizado ou imaturo até um estado que usa informações quantitativas para determinar e gerenciar as melhorias a serem implementadas e que irão satisfazer as necessidades de negócios da organização.

Há muitas razões para se selecionar uma representação ou outra. Talvez a organização escolha usar a representação com a qual é mais familiarizada. Se usadas para melhoria de processos ou avaliações, ambas as representações são projetadas para oferecer resultados equivalentes. Vamos listar os critérios de escolha com algumas das possíveis vantagens e desvantagens de como selecionar a adoção de uma entre as duas representações. Para este comparativo, a Tabela deve ser consultada.

Tabela - Níveis de capacidade x Níveis de maturidade do CMMI

Level	Continuous Representation Capability Levels	Staged Representation Maturity Levels
Level 0	Incomplete
Level 1	Performed	Initial
Level 2	Managed	Managed
Level 3	Defined	Defined
Level 4		Quantitatively Managed
Level 5		Optimizing

Fonte: adaptado de SEI (2010, p. 35).

Componentes do modelo CMMI

O modelo (ou constelação) CMMI apresenta conceitos e práticas do CMMI e outros serviços com foco em padrões e modelos consagrados como:

• ITIL - Information Technology Infrastructure Library
• ISO/IEC 20000: Information Technology Service Management
• CobiT - Control Objectives for Information and related Technology
• ITSCMM - Information Technology Services Capability Maturity Model

 

 

 

 

Componentes do modelo CMMI

Fonte: Profit_Image / shutterstock.com

De acordo com SEI (2010, p. 20), o CMMI-SVC cobre as atividades para estabelecer, entregar e gerenciar serviços. Neste contexto, serviço é um produto intangível e que não pode ser armazenado. As práticas e metas do modelo são relevantes para organizações que atuam na entrega de serviços, incluindo a área de TI, defesa, saúde, finanças e transportes.

“Embora as PAs e os processos do modelo descrevam comportamentos considerados como melhores práticas para a maior parte dos provedores de serviços, estes devem ser interpretados e adaptados às restrições e ao ambiente da organização que os utilizam.”

Fonte: SEI (2010, p. 20, tradução nossa)

Conforme ilustra a Figura, o CMMI-SVC, da mesma maneira que os outros modelos CMMI, reúne os componentes:

Componentes do modelo CMMI. Fonte: baseado em SEI (2010, p. 22)

• Áreas de processos (process areas – PAs): é um cluster de práticas relacionadas de uma área que, quando implementadas coletivamente, satisfazem um conjunto de metas consideradas importantes para a melhoria desta área.
• Objetivo da PA (purpose statement): descreve o propósito da PA, sendo um componente informativo.
• Notas introdutórias (introductory notes): seção da PA que descreve os principais conceitos cobertos pela PA, sendo um componente informativo.
• Áreas de processos relacionadas (related process areas): seção da PA que lista referências às PAs relacionadas e reflete os relacionamentos entre as PAs, sendo um componente informativo.
• Metas genéricas (generic goals - GG): são chamadas genéricas porque a mesma meta pode ser aplicada a múltiplas PAs. Descrevem as características que devem estar presentes nos processos institucionalizados que implementam uma PA.
• Prática genérica (generic practice - GP): é chamada genérica porque a mesma prática pode ser aplicada a múltiplas PAs. É associada com uma meta genérica e descreve as atividades que são consideradas importantes para que se possa atingir uma meta genérica de uma PA, contribuindo para a institucionalização dos processos associados à PA.

• Metas específicas (specific goals - SG): ou objetivos específicos, descrevem as características únicas que devem estar presentes para satisfazer a PA.
• Prática específica (specific practice - SP): é a descrição de uma atividade que é considerada importante para que se possa atingir uma meta específica de uma PA.
  • Subprática (subpractice): é uma descrição detalhada que provê diretrizes para que se possa interpretar e implementar uma prática específica ou genérica, sendo um componente informativo.

Visão geral do modelo CMMI

O CMMI (Capability Maturity Model Integration), como outros modelos CMM, fornece um guia a ser usado para o desenvolvimento de processos. Os processos usados em uma organização dependem de muitos fatores, incluindo domínios de aplicação e estrutura e tamanho da organização. O CMMI está organizado em três modelos chamados de constelação, cada um contendo práticas para áreas de desenvolvimento (CMMI-DEV), serviços (CMMI-SVC) e de aquisição (CMMI-ACQ):

• CMMI for development (CMMI-DEV): voltado ao processo de desenvolvimento de produtos e serviços.
• CMMI for acquisition (CMMI-ACQ): voltado aos processos de aquisição e terceirização de bens e serviços.
• CMMI for services (CMMI-SVC): voltado aos processos de empresas prestadoras de serviços.

 

 

 

 

CMMI - Capability Maturity Model Integration

Fonte: <cmmiinstitute.com>

A organização pode usar os modelos CMMI para ajudar a estabelecer objetivos e prioridades do melhoramento de processos, obtendo um guia para garantir estabilidade, processos estáveis e maduros.

O CMMI trabalha com process areas (PAs), por isso é importante fazermos uma distinção entre processos e PAs. Um processo individual é realizado através de atividades distintas e instruções que especificam como o produto de uma atividade é obtido. Um PA especifica metas e práticas comprovadas para que atividades profissionais possam ser executadas, sem especificar como isso deva ser feito. Além disso, o produto da atividade é especificado apenas pelas suas características (PLAYS-IN-BUSINESS.COM, 2010).

Todos os modelos do CMMI 1.3 definem um conjunto de PAs. Um PA especifica metas e práticas comprovadas para que uma atividade profissional possa ser realizada.

Como mostra a figura, o modelo CMMI 1.3 contém 23 PAs, das quais dezesseis são core process areas, comuns a todas as constelações. O modelo CMMI-SVC possui sete PAs específicas e tanto o CMMI-ACQ quanto o CMMI-DEV possuem seis PAs específicas cada.

Constelações CMMI e as PAs. Fonte: Plays-in-business.com (2010).

Saiba mais

Implantação integrada do CMMI-DEV com o CMMI-SVC: desenvolvendo software como serviço

“Os modelos CMMI dividem as práticas em áreas de processo organizadas em 5 níveis. Os níveis servem como um roadmap para melhoria contínua.São 22 áreas de processo no CMMI-DEV, 24 áreas de processo no CMMI-SVC e 22 áreas de processo no CMMI-ACQ.O CMMI-DEV e CMMI-SVC podem ser usados por empresas prestadoras de serviços de desenvolvimento de software e sistemas. O CMMI-ACQ pode ser usado por empresas que contratam serviços de desenvolvimento de software e sistemas.”

Benefícios com a implantação integrada

Fonte: Promove (2016).

“No Brasil, existem 86 empresas avaliadas no CMMI-DEV e 18 no CMMI-SVC (consulta feita em janeiro/2016).”

Fonte: PROMOVE. O que é CMMI? 7 fev. 2016. Disponível em: <http://www.promovesolucoes.com/cmmi>. Acesso em 8 jun. 2017.

CMMI

Trataremos do modelo CMMI (Capability Maturity Model Integration), apresentando o modelos CMM, seus antecedentes históricos, e detalhando seu modelo de maturidade e representações.

 

Modelos CMM para qualidade de processo de software

Fonte: Profit_Image / shutterstock.com

Antecedentes históricos: modelos CMM para qualidade de processo de software

Os modelos CMM (Capability Maturity Model) são construídos a partir do conceito de processo e focam na melhoria dos processos de uma organização. Eles contêm os elementos essenciais de processos efetivos para uma ou mais disciplinas e descrevem uma abordagem evolucionária a partir de processos ad hoc, imaturos, até processos disciplinados e maduros, com melhoria na qualidade e efetividade. Assim, na medida em que a maturidade dos processos evolui em uma empresa, estes passam a ser mais definidos e efetivos.

SEI – Software Enginnering Institute. Fonte: <cmu-sei.github.io>.

O CMM é uma marca registrada do SEI (Software Engineering Institute), sediado na Universidade Carnegie Mellon, em Pittsburgh, EUA. O SEI é um centro de pesquisa e desenvolvimento patrocinado pelo Departamento de Defesa dos Estados Unidos. O SEI realiza pesquisas em software e problemas ligados à cybersecurity, cria e realiza testes com base em tecnologias inovativas e focaliza a transição para soluções maduras para uso global. De acordo com SEI (2010, p. 17), o instituto criou o primeiro modelo CMM destinado para organizações de software em 1995 e o publicou no livro “The Capability Maturity Model: guidelines for improving the software process”.

De acordo com Royce (2002), o modelo inicial CMM desenvolvido pela SEI era especificamente destinado à maturação de processo de software. No entanto, com sua bem sucedida adoção e uso em diferentes domínios, outros modelos CMM foram desenvolvidos para disciplinas e funções mais específicas como engenharia de sistemas, pessoas, desenvolvimento de produto integrado, aquisição de software, dentre outras. Apesar de muitas organizações considerarem estes modelos úteis, eles também apresentavam problemas como sobreposições, inconsistências e dificuldades de integração. Muitas organizações também encontraram conflitos em processos de auditoria e programas de melhoria de software entre os modelos CMM e as normas ISO 9001.

Além destes problemas, alguns casos de práticas CMM apresentaram semelhanças com o modelo tradicional em cascata, com processos excessivamente baseados em gerenciamento. Isto acabou associando organizações que adotavam modelos CMM aos princípios da mentalidade do modelo cascata, dando-lhes uma conotação negativa.

Em função destes problemas, das implicações econômicas a eles associados e com a disseminação de técnicas de desenvolvimento iterativo e de melhores práticas utilizadas na indústria de software, as organizações foram motivadas a adotar uma abordagem baseada em resultados. Todo este cenário impulsionou o início do projeto CMMI.

O projeto CMMI foi formado para solucionar todos estes problemas, notadamente os resultantes do uso de múltiplos modelos CMM. O CMMI buscou integrar muitas das melhores práticas da indústria, desencorajando padrões de alinhamento com a mentalidade do modelo cascata, fazendo deste um melhor padrão a ser seguido. Mas o projeto não se limitou a reunir diferentes modelos em um único. O time que trabalhou no projeto CMMI construiu um framework que acomodou diversas constelações. A Figura ilustra os modelos que foram criados até se chegar à versão 1.3.

História dos modelos CMM. Fonte: SEI (2010, p. 18).

A versão 1.3 iniciou-se em 2008 e em 2010 foram lançados: CMMI for Acquisition, CMMI for Development e CMMI for Services.

A norma ISO/IEC 15504

O início da norma 15504 remonta ao início da década de 1990, quando a ISO iniciou o projeto Spice (Software Process Improvement and Capability Determination) como resultado de um estudo chamado “Necessidades e exigências para uma norma de avaliação de processos de software”. Esse estudo concluiu que era necessária a elaboração de uma norma que fosse aplicável à melhoria de processos e à determinação da capacidade, que culminou com a norma 15504.

A ISO/IEC 15504 presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional. Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar uma avaliação com o objetivo de gerar um perfil dos processos que serão usados para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de decisão de contratá-lo ou não (SOFTEX, 2016).

Uma das vantagens desta norma é que ela integra padrões existentes de forma muito flexível. Mas sua aplicação na prática requer muito esforço, tempo e experiência consideráveis, o que complica sua aplicação em micro e pequenas empresas de software.

Os principais benefícios de uma organização com a adoção da norma são:

• Determinação da capacidade dos processos: esta norma é uma ferramenta que permite às empresas avaliar o estado dos seus processos em comparação com as melhores práticas, através da identificação das suas forças, fraquezas e riscos. Com base nesta avaliação, poderão decidir se têm a capacidade para empreender um determinado projeto.
• Melhoria dos processos: as empresas poderão identificar quais os processos que devem melhorar, o que deverá ser feito para este fim e deduzir onde devem investir em primeiro lugar, com vista à obtenção de retornos rápidos e significativos. De uma forma simplificada, podemos afirmar que com o resultado desta avaliação uma organização saberá onde se encontra, para onde se deve dirigir e como deve fazer.

A norma ISO/IEC 12207

O objetivo da norma ISO/IEC 12207 é estabelecer uma estrutura comum para os processos de ciclo de vida de software, com uma terminologia bem definida, que pode ser referenciada pela indústria de software. Koscianski e Soares (2009, p. 164) afirmam que a norma não define um ciclo de vida, pois foi concebida como um modelo que aponta uma meta de ciclo de vida, a partir do qual cada organização define seus próprios processos.

O escopo da ISO/IEC 12207 abrange todo o ciclo de vida de software, desde sua concepção até a sua descontinuidade, incluindo todos os envolvidos com produção, manutenção e operação do software. Os processos da ISO/IEC 12207 são agrupados de acordo com o seu objetivo principal no ciclo de vida de software, resultando em três classes de processos: processos fundamentais ou primários, processos de apoio e processos organizacionais.

Processos da norma ISO/IEC 12207. Fonte: <slideplayer.com.br>

Processos fundamentais (primários)

Os processos fundamentais (ou primários) da norma são os seguintes:

1. Processo de aquisição - define as atividades de aquisição da organização (a organização que adquire um sistema, produto de software ou serviço).
2. Processo de fornecimento - define as atividades do fornecedor da organização (a organização que fornece o sistema, o produto de software ou o serviço do software ao cliente).
3. Processo de desenvolvimento - define as atividades da equipe de desenvolvimento da organização (a organização que define e desenvolve o produto de software).
4. Processo de operação - define as atividades de operação da organização (a organização que fornece o serviço de operar um sistema).
5. Processo de manutenção - define as atividades de manutenção do software da organização (a organização que fornece o serviço de manter o produto de software; isto é, gerir as modificações do produto de software para mantê-lo atualizado e operacional).

Processos de apoio

Os processos de suporte da norma são:

1. Processo de documentação - define as atividades para registrar a informação produzida por um processo do ciclo de vida.
2. Processo de gestão de configurações - define as atividades de gestão de configuração.
3. Processo de garantia da qualidade - define as atividades para assegurar de forma objetiva que os produtos e os processos de software estão em conformidade com os requisitos especificados e conforme o planejado. As revisões conjuntas, as auditorias, a verificação e a validação podem ser usadas como técnicas da garantia de qualidade.
4. Processo de verificação - define as atividades (para o cliente, o fornecedor ou outro stakeholder) para verificar os produtos de software.
5. Processo de validação - define as atividades (para o cliente, o fornecedor ou outro stakeholder) para validar os produtos de software.
6. Processo de revisão - define as atividades para avaliar o estado e os produtos de uma atividade.
7. Processo de auditoria - define as atividades para determinar a conformidade com os requisitos, planejamento e contrato.
8. Processo de resolução de problemas - define um processo para analisar e resolver problemas (incluindo não conformidades), qualquer que seja a sua natureza ou fonte detectadas no decorrer do desenvolvimento, operação, manutenção ou outro processo. 

Processos de apoio. Fonte: Flat Design / shutterstock.com

Processos organizacionais

São quatro os processos organizacionais da norma:

1. Processo de gestão - define as atividades básicas de gestão, incluindo a gestão de projeto, durante o ciclo de vida.
2. Processo de infraestrutura - define as atividades básicas para estabelecer a infraestrutura.
3. Processo de melhoria - define as atividades básicas ligadas ao desempenho da organização (quer seja cliente, fornecedor, equipes de desenvolvimento e manutenção ou gestor de outro processo) para estabelecer a medição, controle e melhoria do ciclo de vida.
4. Processo de formação - define as atividades para proporcionar a formação adequada aos colaboradores.

A implementação da norma consiste na definição ou seleção de um modelo de ciclo de vida de software apropriado ao escopo, magnitude e complexidade do projeto e nas seguintes atividades:

1. execução de documentação dos resultados, de acordo com o processo de documentação;
2. colocação dos resultados sob o processo de gerência de configuração;
3. execução do controle de alterações;
4. documentação e resolução de não-conformidades e problemas encontrados nos produtos de software e tarefas, de acordo com o processo de resolução de problema;
5. execução dos processos de apoio, conforme especificado no contrato;
6. seleção, adaptação e utilização de padrões, métodos, ferramentas e linguagens de programação de computador;
7. desenvolvimento dos planos para conduzir as atividades do processo de desenvolvimento.