CMM ( Capability Maturity Model for Software)

1. Introdução CMM (CapabilityMaturityModel for Software)

2. Introdução • Na globalização do mercado de software, cada vez mais competitivo, terá mais chance de sobreviver quem for organizado e eficiente no seu processo de produção, disponibilização e evolução de software. Esse cenário faz com que o processo de melhoria de qualidade de produtos e serviços relativos à informação seja vital para as empresas desse ramo. Além dos benefícios naturais, como produtividade e qualidade comercialmente acreditam-se que, em curto prazo, a certificação dos processos fabris será um pré-requisito básico para as contratações de produtos de software. Por esses motivos, o CMM (CapabilityMaturityModel for Software), tornou-se ao longo de uma década o modelo de qualidade mais conhecido, usado e respeitado pela comunidade de engenharia de software. Refletindo o acervo de experiência de profissionais e organizações de renome internacional, o CMM é entendido como um modelo de capacitação de arquitetura em estágios, que serve de referência para avaliar a maturidade dos processos de uma organização. O fato de ser um modelo baseado nas experiências reais de organizações bem sucedidas no desenvolvimento de software faz com que as práticas que recomenda, sejam eficientes e eficazes e reflitam “o melhor do estado da arte”, não se constituindo, portanto, em um modelo meramente “teórico”.

3. O CMMI • Tendo sido aplicado na prática por mais de uma década, era natural que o modelo CMM fosse atualizado para refletir melhorias sugeridas por aqueles que o implementaram. As sugestões de melhoria foram agrupadas no que viria a ser o SW-CMM modelo 2.0. No entanto, uma série de fatores levou a SEI (Fundação Software EngineeringInstitute da Universidade de CarnegieMellon) a modificar um pouco a forma pela qual esta atualização seria feita. O primeiro fator é o fato de que o sucesso do SW-CMM levou à criação de uma série de outros “CMMs”. Na verdade, quando falamos em “CMM”, estamos nos referindo especificamente ao SW-CMM (CMM para software), o modelo mais antigo e conhecido. Na esteira de seu sucesso, foram criados, entre outros, o SE-CMM (Systems Engineering CMM – para desenvolvimento de sistemas completos, não apenas o software), o SA-CMM (SoftwaremAcquisition CMM – para seleção, compra e instalação de software desenvolvido por terceiros) e o P-CMM (People CMM, para medir a maturidade dos processos de gestão de Recursos Humanos em organizações de software). Estes vários CMMs, porém, acabaram por ser desenvolvidos de modo distinto.

4. O CMMI • O resultado foi que surgiram diversas inconsistências entre eles, em termos de nomenclatura, processo de avaliação e modo de implementação. Organizações que implementaram mais de um CMM tiveram problemas com a confusão de termos e conceitos, altos custos de treinamento e avaliação, já que, embora com inspiração comum, os modelos eram independentes. Assim, uma empresa que implantasse o SW-CMM e o P-CMM, por exemplo, era obrigada a realizar processos de avaliação separados. Outro fator importante foi à necessidade, em parte política, de compatibilizar o SW-CMM com a norma ISO 15.504, desenvolvida pelo projeto SPICE. Novamente, inconsistências de método e terminologia exigiram que algo fosse feito. Estes fatores levaram o SEI a abandonar a abordagem de lançar o SWCMM 2.0, estabelecendo em seu lugar um projeto de integração dos CMMs e compatibilização com a norma ISO. Daí o nome CMMI, que nada mais é do que CMM-Integrated. No CMMI uma organização pode optar por dois enfoques para melhorar os seus processos: capacitação de uma determinada área de processo ou maturidade da organização como um todo. O suporte para tais enfoques é feito através da representação por estágio e da representação contínua, respectivamente.

5. Certificação versus Avaliação Uma organização pode ser aferida ou avaliada comparando-se suas práticas reais com aquelas que o modelo de maturidade de capacitação prescreve ou recomenda. Essa aferição produz um diagnóstico da organização quanto aos seus processos. O diagnóstico serve de base para recomendações de melhoria de processos, e estas recomendações podem ser consolidadas em um plano de melhoria. É importante observar, que tanto o CMMI como o CMM, não se caracterizam como um padrão de direito. Não se aplica a eles o conceito de certificação. O termo correto é avaliação (“appraisal”). Nesse sentido, não existe o formalismo encontrado nos procedimentos de certificação, como os utilizados, por exemplo, para a certificação ISO 9001. Portanto, por não serem baseados em procedimentos de certificação, não há exigência de reavaliações e nem há validade para o laudo, ou seja, o prazo é indeterminado. Isto significa que a organização pode obter um laudo oficial de maturidade como válido, ter descontinuado o processo de desenvolvimento e mesmo assim continuar a ter o laudo como válido, e vai poder utilizá-lo em processos licitatórios, por exemplo.

6. Certificação versus Avaliação O SEI licencia e autoriza os avaliadores oficiais a conduzirem as avaliações, tendo por responsabilidade a gerência, a guarda e a manutenção dos laudos e relatórios encaminhados pelos avaliadores, e finalmente realiza análises sobre os resultados. É importante ressaltar que o SEI não confirma a acurácia dos laudos que são reportados, ou seja, o SEI não assume nenhuma responsabilidade pelos laudos que são emitidos. A relação das organizações que possuem avaliações oficiais catalogadas “MaturityProfile” do SEI pode ser obtida no endereço: http://seir.sei.cmu.edu. As aferições focalizam as práticas de uma organização, que pode ser uma companhia, uma divisão de uma companhia, um órgão de governo ou uma ramificação de qualquer uma dessas entidades: grandes empresas geralmente não são avaliadas como um todo, mas sim em nível de laboratório ou divisão.

7. CMM e Gerência de Projetos A partir do lançamento e divulgação da versão 1.1 em 1993, o tema da maturidade de processo foi ganhando força na comunidade de engenharia de software. Esta força foi conseqüência dos resultados práticos obtidos pelas organizações que realizaram programas de maturidade com o CMM como modelo de referência. O CMM organizou parte do conhecimento da engenharia de software em um modelo baseado em algumas premissas, incluindo uma sobre: “os maiores problemas nas organizações de software são gerenciais e não técnicos”. Estas premissas apontavam para soluções que, em um primeiro momento, focassem na utilização de princípios básicos de gerência de projeto para “arrumar a casa”, gerar resultados imediatos e preparar a organização para as próximas etapas da maturidade. Sem uma gerência de projetos bem estabelecida, o risco de qualquer outra iniciativa não produzir os resultados esperados é muito grande. O CMM define cinco níveis incrementais de maturidade do processo de desenvolvimento e manutenção de software, dos quais o primeiro é apenas um ponto de referência. O nível 2, que é a primeira referência a ser buscada nas empresas, é focado exatamente no estabelecimento de uma gerência de projetos.

8. CMM e Gerência de Projetos Para este nível o CMM define seis áreas chave de processo, nas quais são estabelecidas metas de maturidade a serem atingidas e são sugeridas práticas que podem ser implementadas para ajudar o atendimento destas metas. As principais metas da maturidade de processo do nível 2 são: • definir e gerenciar requisitos do projeto, incluindo as mudanças destes requisitos; • comprometer-se apenas com o trabalho estimado e planejado; • acompanhar a execução do trabalho aferido em relação ao planejado; • garantir que o trabalho satisfaça os padrões de qualidade estabelecidos; • manter um controle rigoroso dos produtos, incluindo as mudanças destes produtos; • garantir que todos os fornecedores sigam estes padrões. Uma das grandes contribuições do CMM foi consolidar a importância da gerência de projetos para a engenharia de software.

9. CMMI e Gerência de Projetos O modelo CMMI (CapabilityMaturityModelIntegrated) é uma evolução do SW-CMM; foi lançado com duas representações, uma por estágio (como o SW-CMM) e outra contínua (como a ISO 15.504). No CMMI está definida uma área de gerência de projeto no nível 2, composta por seis áreas de processo: planejamento de projeto, acompanhamento e controle de projeto, gerenciamento de acordos com fornecedores, gerenciamento integrado de projeto, gerenciamento de risco, e gerenciamento quantitativo de projeto. Além disso, são definidos seis níveis de capacidade para qualquer processo, das quais o nível 2 também está relacionado com a gerência de projeto. Conclusão do Tópico Gerência de Projeto O relacionamento entre as disciplinas de melhoria de processo e gerência de projeto representa uma grande oportunidade para a melhoria necessária e viável das organizações de desenvolvimento de software.

10. CMMI e Gerência de Projetos Estrutura Tanto para o CMMI como para o CMM, a implantação de processos de qualidade em empresa segue um amadurecimento gradativo em patamares de cinco níveis de maturidade, que determina qual é a capacitação do processo e a maturidade que a organização possui para desenvolver software: nível inicial, repetível, definido, gerenciado e otimizado. O nível 2 é o primeiro degrau a ser galgado. Sua implantação consiste, basicamente, em mecanismos de gerenciamento de projeto e deve trazer, para a alta administração, uma expectativa de cumprimento das metas de esforço, prazo e custo.É importante observar que “o maior desafio que as organizações enfrentam para alcançar este nível de maturidade, está relacionado com a mudança cultural e não com a implantação dos novos processos propriamente dito. Implementar mudanças no meio do projeto, sem que os novos processos estejam estáveis e sem que já tenha havido na organização uma sensibilização e comprometimento por parte da alta direção e do corpo gerencial, pode ser muito arriscado e comprometer o sucesso do projeto”.

11. CMMI e Gerência de Projetos No nível 3 a empresa adquire à visão de que o processo de desenvolvimento de software é um patrimônio da organização e, portanto, deve ser estudado, aperfeiçoado e melhorado. Sua implementação na empresa deve criar um processo de desenvolvimento bem definido no qual todo projeto é derivado de uma sistemática da organização. Existe também uma preocupação com a institucionalização, ou seja, garantia de que o processo é disseminado, compreendido e praticado por todos em caráter permanente. O conhecimento adquirido passa a ser da organização e não das pessoas que nela atuam. Cabe salientar aqui que estes dois níveis, ou seja, nível 2 e nível 3 são os que trazem maior retorno imediato e são os que estabelecem quase total correspondência com as cláusulas do conjunto de normas ISO9000 quando aplicadas ao software. O nível 4 traz para a empresa o conceito de gerenciamento quantitativo, ou seja, todas as decisões referentes ao gerenciamento do projeto de desenvolvimento devem ser feitas em bases quantitativas, através da consulta à base de dados do processo. Nessa base de dados estão armazenadas as informações sobre comportamento do processo em projetos realizados anteriormente, dando subsídios aos gerentes para tomarem decisões mais precisas.

12. CMMI e Gerência de Projetos No nível 5, a empresa obtém o conceito de melhoria contínua, permitindo a introdução de novas tecnologias e aperfeiçoamento no processo de desenvolvimento sem causar impactos nos produtos criados. Outro aspecto relevante a colocar é que embora o CMMI e o CMM tenham sido concebidos, primeiramente, para grandes projetos em organizações, nada impede, a adoção de seus princípios também por pequenas empresas, assim como pequenos projetos, mediante um trabalho cuidadoso de interpretação e adequação à realidade da empresa. Essa adequação foi prevista na própria concepção do modelo, conforme descrito nos relatórios técnicos do SEI. Para obter mais detalhes a esse respeito, visite o site http://www.sei.cmu.edu. “Para que a indústria de software contribua de forma construtiva para a sociedade, precisamos aprender a entregar produtos com qualidade, no prazo estabelecido e com os custos planejados. E isto não é impossível. Outras indústrias, à medida em que amadureceram, atingiram este nível de desempenho. Não há razão para que isto não seja possível para o software. As questões-chaves são: (I) qual é a atual cultura de software? (II) quais são os problemas causados por esta cultura? (III) como deve ser a nova cultura? (IV) como podemos chegar lá? Watts S. Humphrey

13. Níveis do CMMI CMMI Nível 1 Antes de mais nada, não existe avaliação CMMI nível 1, mas esta é uma classificação que pode ser dada a toda empresa que não foi avaliada em um nível de maturidade CMMI. É o que é feito na maioria das empresas, requisitos entram e o produto sai, mas não se sabe ao certo como ele saiu e o que foi necessário para conseguir isto.

14. Níveis do CMMI CMMI Nível 2 O CMMI nível 2 implementa a Gestão (PMI pode ajudar muito nesta fase). Neste ponto, cria-se o plano de projeto e os projetos são tocados de forma organizada e sistematizada. Você começa a medir as coisas e analisar o desempenho, assim as decisões são tomadas com mais embasamento. Gestão é a palavra chave do CMMI nível 2.

15. Níveis do CMMI CMMI Nível 3 Agora que você já gerencia seus projetos é preciso melhorar a engenharia, processos e suporte ao desenvolvimento. No nível 3 você aprende a conhecer mais profundamente seus processos e o que tem dentro deles, suas caixinhas pretas diminuem e você consegue gerenciar melhor seus projetos. Além do desempenho geral você começa a medir e analisar outros fatores dentro de seus projeto se da própria organização. Existem várias áreas de processo que dão um retorno bem interessante como “gerencia de riscos”, “Treinamento Organizacional”, “Foco no processo” e outras.

16. Níveis do CMMI CMMI Nível 4 Neste ponto você deve conhecer os fatores que realmente influenciam no desempenho de seus processos e atendimento dos objetivos de negócio. Aqui você cria modelos para predizer o que vai acontecer de acordo com o desempenho atual de seus processos. As caixinhas pretas agora são conhecidas e você sabe o real desempenho de cada uma.

17. Níveis do CMMI CMMI Nível 5 Bom, se você chegou até aqui, isso quer dizer que a melhoria continua se tornou o modo de vida da organização. Neste ponto você conhece o que realmente influencia o desempenho de seus processos e cria projetos para melhorar ainda mais os mesmos. Estatística (de verdade) é o ponto chave nos níveis 4 e 5. Bom, como as imagens mostraram, você começa com uma “caixa preta” e vai Bom, como as imagens mostraram, você começa com uma “caixa preta” e vai conhecendo-a melhor. O objetivo final é conhecer cada pedacinho daquela caixa preta inicial para que você possa saber onde mexer para conseguir atingir os objetivos dos projetos.

18. Áreas de Processo (PA`s) PA`s do CMMI Nível 2 • CM – Gerência de Configuração • MA– Medição e Análise • PP – Planejamento de Projetos • PMC – Acompanhamento de Projetos • PPQA – Garantia de Qualidade do Processo e Produto • REQM – Gerenciamento de Requisitos • SAM – Gerenciamento de Acordos com Fornecedores

19. Áreas de Processo (PA`s) PA`s do CMMI Nível 3 • PI – Integração de produto • RD – Desenvolvimento de requisitos • TS – Solução técnica • VAL – Validação • VER – Verificação • OPD – Definição do processo organizacional • OPF – Foco no processo organizacional • OT – Treinamento organizacional • IPM – Gerenciamento integrado de projeto • DAR – Decisão formal • RSKM – Gerenciamento de riscos

20. Áreas de Processo (PA`s) PA`s do CMMI Nível 4 • QPM – Gerenciamento quantitativo de projeto • OPP – Desempenho do processo organizacional

21. Áreas de Processo (PA`s) PA`s do CMMI Nível 5 • CAR – Análise de Causa • OID – Inovação Organizacional

22. Quanto tempo é necessárioparaconseguir o CMMI?

23. Quanto tempo é necessárioparaconseguir o CMMI? Estes dados foram obtidos do ultimo comunicado da SEI sobre o assunto. Vamos entender o gráfico. Cada barra mostra o mínimo e máximo de tempo e a linha no meio representa a média, então se pegarmos o nível 2 veremos que você pode levar de 15 à 40 meses para se conseguir obter o CMMI nível 2, porém, o mais provável (média) é que você consiga em 19 meses. Uma coisa interessante é que o nível mais demorado é o nível 4 (24 meses) e isto se dá porque muitas empresas não implementam a área de medições corretamente ou não possui um processo definido (algo básico desde o 3) e quando chegam no nível 4, ou fazem de verdade ou não tem como prosseguir. Vale lembrar que estes dados contemplam mais de 8 anos e a realidade hoje pode ter mudado.

24. Quanto tempo é necessárioparaconseguir o CMMI? O tempo de implementação de um nível CMMI vai depender muito mais da estrutura da empresa do que da consultoria que vai ajudar. É mais ou menos assim, se a empresa quer “de fato”, vai ser mais rápido, mas, todos devem remar para o mesmo lado. Se você esta implementando CMMI na sua empresa e tem resistências internas no seu corpo gerencial, saiba que você vai demorar mais (e gastar mais também). Outra coisa que você deve ter em mente é a questão da maturidade , o CMMI tem os níveis 2, 3 4 e 5 por uma razão, não adianta querer dividi-lo em 3 e 5, isto não existe e não é bem visto na SEI.

25. CMMI AjudaouAtrapalha? De uma forma bem sucinta, o CMMI (CapabilityMaturityModelIntegration – Modelo Integrado de Capacitação e Maturidade) é um modelo bastante aceito e de alta credibilidade no que se refere a medir a maturidade do processo de uma organização. Quanto mais madura o seu processo, maior a qualidade do produto final oriundo do processo. Pelo menos é o que pensa o SEI (Software EngineeringInstitute), órgão da Universidade CarnegieMellon, patrocinado pelo Departamento de Defesa dos Estados Unidos, e responsável pela elaboração e manutenção do modelo CMMI. O SEI acredita que a maturação do processo da organização é diretamente proporcional à qualidade do produto final obtido, mas não é só isso. O SEI acredita que o modelo CMMI também facilita para que a organização consiga elaborar o produto final do seu projeto com meios para que o custo, esforço real, e qualquer outra variável relevante ao processo, não se desvie muito do estimado e que tenha a melhor produtividade possível. E tudo isso aplicando as melhores práticas existentes dos processos.

26. CMMI AjudaouAtrapalha? As melhores práticas de gerenciamento de projetos, por exemplo, que estão publicadas hoje no PMBoK (Project Management BodyofKnowledge – Corpo de Conhecimento da Gerência de Projetos), estão, de certa forma, descritas no modelo. Em outro exemplo mais aplicável para nossa área, ou seja, no caso de processos de desenvolvimento de software, estão contidas no modelo as melhores práticas da engenharia de software. Para muitos, um processo de desenvolvimento de software baseado no CMMI é muito burocrático e o custo do produto final termina aumentando. Afinal, segundo eles, nem todas as práticas são realmente necessárias na maioria dos casos e muito trabalho poderia ser evitado, principalmente em projetos pequenos. Frases como “O CMMI engessa o processo”, “O custo de desenvolvimento fica alto devido ao CMMI”, “O CMMI vai contra um processo ágil” são emitidas freqüentemente por profissionais que seguem essa linha de pensamento. Para eles, a qualidade gerada pelo CMMI possui um preço muito alto a se pagar e não agrega muito valor à organização.

27. CMMI AjudaouAtrapalha? Mas, a meu ver, eles estão cometendo um erro terrível: o CMMI não é um processo, é somente um modelo. Como vai ser aplicado o modelo dentro do seu processo, aí depende exclusivamente da organização. Ela pode fazer tanto um processo bem “engessado” ou um processo mais ágil. O tal processo “engessado”, muitas vezes, está ligado ao estudo ou compreensão inadequada que se fez do modelo. Muitas vezes quando não se estuda a fundo o modelo, ele tende a ser aplicado da forma mais complexa e generalista possível. Quando não se tem a devida compreensão do modelo, as organizações costumam seguir os exemplos descritos lá, e a implementam de forma literal e, porque não dizer também, de forma burra! Esquecem que a maioria dos exemplos fornecidos no modelo tende a ser o mais detalhado possível, até para fornecer um melhor entendimento das práticas e/ou tentar contemplar um maior número de casos. Então, os não-estudiosos do modelo se apegam a estes exemplos e querem aplicá-los com todos os seus detalhes, porque fazendo dessa maneira “não tem erro”, dizem, e a prática será implementada corretamente e passaremos na avaliação.

28. CMMI AjudaouAtrapalha? Certamente ela será implementada de acordo com o modelo, mas dificilmente será da melhor maneira para a organização. Pode ser de uma maneira que não retrate o modo de trabalhar da empresa e/ou que esteja fora da realidade da mesma. Nesse caso tenham certeza que o processo, todo ou em parte, não vai durar muito tempo para cair em desuso. Vai ser o famoso “fazer para inglês ver”, até que não se faça mais. O processo tem que ser único e particular para cada organização. Deve procurar retratar como a organização trabalha e deve-se buscar no modelo como melhorar as atividades da organização, tornando-as mais produtiva e mensurável, e não ao contrário. Só assim a implantação do modelo terá sucesso e o processo definido será tão enxuto quanto é a organização que o implementa. No começo do processo de implantação até que o pessoal se acostume ao modusoperandi vai demorar um pouco, como em qualquer implantação de processo (seja ele qual for) ou em qualquer mudança. Toda mudança é traumática, não importa onde e nem o motivo. Sempre há resistência. É inerente ao ser humano.

29. CMMI AjudaouAtrapalha? Por isso, é óbvio que no começo deste processo de implantação, ele parecerá muito rígido, burocrático, inadequado até. Principalmente para o pessoal que está acostumado a desenvolver sistemas sem nenhum método (a “migué”, como dizemos por aqui) ou de forma bastante informal, na base do “deixa comigo” ou do “sempre fiz assim e deu certo”. Empresas grandes ou que querem crescer não podem se cercar de heróis assim (ninguém duvida que sejam), pois ficariam muito dependente deles, do estado de espírito, visão e disposição de trabalhar dessas pessoas. Isso não existe hoje em uma empresa madura. Toda empresa hoje tem que depender de um processo eficiente a que se propõe, que diga quem deve fazer o que e quando, e até o como. Finalizando, não devemos esquecer que o modelo CMMI é apenas um modelo. Não é um trilho, e sim, uma trilha a ser seguida. E para isso, o estudo e entendimento profundo do modelo são essenciais.

30. Síntese CMMI – CapabilityMaturityModelIntegrated é um modelo de qualidade mantido pelo SEI – Software EngineeringInstitute. Podemos dizer que o CMMI é um framework para melhoria de processos de software. Suas PA’s abrangem todo processo de desenvolvimento e melhoram drasticamente a qualidade dos projetos. Ele diz o que fazer mas não o como. O CMMI não é uma metodologia ou ciclo de vida de projetos. Os processos (negócio) e o desenvolvimento de soluções com engenharia de software são o foco do CMMI. Pela sua estrutura e abrangência poderíamos até dizer que o CMMI “poderia” ser utilizado para outros negócios que não “Software”. Ou seja, várias de suas práticas podem ser utilizadas para projetos de construção civil, administração, marketing e diversos outros. O CMMI ajuda a organização aprimorar seus processos e se tornar mais madura e eficiente. Os modelos de capacidade e maturidade atingidos em seus níveis ajudam a prever o comportamento de um determinado processo diante do cenário ao qual o projeto se encontra. Em resumo, da pra saber se o projeto vai ou não dar certo. Para a organização, ele ajuda a mesma a conhecer a sí própria e sua performance. Muitas vezes, a realidade dói um pouco, mas, vamos lá… pelo menos você já sabe  como está e pode montar um plano de ação para atingir as metas da organização. Quando entendido e conhecido, o CMMI ajuda as pessoas a identificar o que realmente tem valor e focar. Com isso, otimiza-se os processos e melhora-se a rentabilidade da organização. Em resumo, o CMMI é um modelo para a melhoria contínua de processos que “amadurece” as organizações e torna-as mais competitivas.