|
CMMIO CMMI (Capability Maturity Model Integration ou Modelo Integrado de Maturidade em Capacitação) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE - Engenharia de Sistemas), Software Engineering (SW - Engenharia de Software), Integrated Product and Process Development (IPPD - Desenvolvimento Integrado de Processo e Produto), Supplier Sourcing (SS - Seleção de Fornecedores)). O modelo é gerenciado pelo Instituto CMMI, uma organização da ISACA. Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI é um conjunto comprovado de práticas globais recomendadas que impulsiona o desempenho dos negócios por meio da criação e do benchmarking(avaliação comparativa) de recursos-chave[1] serna. O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção. Ele está dividido em 5 níveis de maturidade que atestam, o grau de evolução em que uma organização se encontra. Além disso, tem por objetivo principal funcionar como um guia para a melhoria dos processos da organização, considerando para isto atividades como o gerenciamento do desenvolvimento de software, prazos e custos previamente estabelecidos. O objetivo maior, considerando o CMMI e seus diferentes conceitos, está justamente na produção de software com maior qualidade e menos propenso a erros.[2] A versão do CMMI (versão 1.3) foi publicada em 27 de outubro de 2010 e apresenta três modelos:
Uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de uma empresa". A versão atual do modelo é o CMMI V2.0, liberado em Março de 2018. O objetivo final do CMMI é integrar processos para melhorar produtos.[3] Evolução HistóricaNa década de 1930, Walter Shewhart começou a trabalhar na melhoria de processos com os seus princípios de controle estatístico da qualidade [Shewhart 1931]. Esses princípios foram refinados por W. Edwards Deming [Deming 1986], Philip Crosby [Crosby 1979], e Joseph Juran [Juran 1988]. Watts Humphrey, Ron Radice, e outros estenderam esses princípios ainda mais e começaram a aplicá-los aos softwares em seus trabalhos na IBM e do SEI [Humphrey 1989]. O livro de Humphrey, Gerenciando o Processo de Software, fornece uma descrição dos princípios e conceitos básicos sobre os quais muitos dos CMMs se baseiam.[4] O CMMI surgiu durante a década de 1980 como um modelo para avaliação de risco na contratação de empresas de software pelo Departamento de Defesa dos Estados Unidos que desejava ser capaz de avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados. Para desenvolver esse processo, o DOD constituiu junto a Carnegie-Mellon University o SEI (Software Engineering Institute), o qual além de ser responsável pela evolução da família CMM, realiza diversas outras pesquisas em engenharia de software. A partir de 1991, foram desenvolvidos CMMs® para várias disciplinas (Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gerência e Desenvolvimento da Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto). Embora estes modelos tenham mostrado sua utilidade, o uso de múltiplos modelos se mostrou problemático. O CMMI® surgiu para resolver o problema de utilização de vários modelos e é o resultado da evolução do SW-CMM®, SECM® (System Engineering Capability Model) e IPD-CMM® (Integrated Product Development Capability Maturity Model).[5] Os processos de melhoria nasceram de estudos realizados por Deming (Out of the Crisis), Crosby (Quality is Free: The Art of Making Quality Certain) e Juran, cujo objetivo principal era a melhoria da capacidade dos processos. Entende-se por capacidade de um processo a habilidade com que este alcança o resultado desejado. Um modelo tem como objetivo estabelecer - com base em estudos, históricos e conhecimento operacional - um conjunto de "melhores práticas" que devem ser utilizadas para um fim específico. O CMMI tem como origens em três outros modelos de maturidade - SW-CMM (SEI Software CMM), EIA SECM (Electronic Industries Alliances's Systems Engineer Capability Model) e IPD-CMM (Integrated Product Development CMM). Resumindo, o CMMI é o sucessor do modelo de maturidade de capacidade (CMM) ou Software CMM. O CMM foi desenvolvido de 1987 até 1997. Em 2002, a versão 1.1 foi lançada, a versão 1.2 foi seguida em agosto de 2006 e a versão 1.3 em novembro de 2010. Algumas mudanças importantes no CMMI V1.3[6] são o suporte ao desenvolvimento ágil de software[7] melhorias nas práticas de alta maturidade[8] e alinhamento da representação (encenada e contínua).[9] O CMMI ajuda a "integrar funções organizacionais tradicionalmente separadas, definir metas e prioridades de melhoria de processos, fornecer orientação para processos de qualidade e fornecer um ponto de referência para avaliar processos atuais".[10] Em março de 2016, o Instituto CMMI foi adquirido pela ISACA. Em março de 2018, o CMMI 2.0 foi introduzido, não pela primeira vez na história do CMMI: a opção mais barata era o acesso de 1 semana à versão online por US $ 150,00. Sobre o CMMUm Capability Maturity Model, incluindo o CMMI, é uma representação simplificada do mundo. CMMs contêm os elementos essenciais dos processos eficazes. Esses elementos são baseados nos conceitos desenvolvidos por Crosby, Deming, Juran, e Humphrey.[4] O SEI adotou a premissa de gestão de processos, "a qualidade de um sistema ou o produto é altamente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo", e definiu CMMs que incorporaram essa premissa.[4] DimensõesO CMMI foi construído considerando três dimensões principais: pessoas, ferramentas e procedimentos. O processo serve para unir essas dimensões. DisciplinasO processo inclui três disciplinas ou corpos de conhecimento (body of knowledges), sendo elas:
A engenharia de software é similar à engenharia de sistemas em relação às áreas de processo, apenas com enfoque diferente nos processos. As áreas de processo requeridas para engenharia de sistemas são as mesmas para engenharia de software, mas o nível de maturidade que é diferente. RepresentaçõesO CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem à organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.  Representação ContínuaDefine uma sequência para melhoria de uma área de processos e ao mesmo tempo permite uma flexibilidade na escolha das áreas de processo a serem melhoradas, possibilitando a organização direcionar seus esforços de melhoria nas áreas que julgar mais relevante. É caracterizado por: Níveis de Capacidade (Capability Levels):
Nesta representação a capacidade é medida por processos separadamente, onde é possível ter um processo com nível um e outro processo com nível cinco, variando de acordo com os interesses da empresa. No nível 1(um) o processo é executado de modo a completar o trabalho necessário para a execução de um processo.
A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando já utiliza algum modelo de maturidade contínua ou quando não pretende usar a maturidade alcançada como modelo de comparação com outras empresas.  Representação Por EstágiosDisponibiliza uma sequência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):
Nesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos os processos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase todos os processos forem nível três, mas apenas um deles estiver no nível dois a empresa não irá conseguir obter o nível de maturidade três. Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios, quando deseja utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando pretende usar o nível de conhecimento obtido por outros para sua área de atuação. Representação Contínua vs Representação por EstágioNa representação contínua o nível de capacidade é medido para uma área ou um conjunto de áreas de processos definido pela organização. Já na representação por estágio, o nível de maturidade é medido para um conjunto de áreas de processos definido previamente no modelo. Modelo de estrutura (v2.0)Na versão 2.0, a separação de representação acima foi cancelada e agora existe apenas um modelo coeso. O modelo é dividido em 4 categorias, 12 capacidades e 25 áreas de processo (com iniciais entre parênteses e os mais altos níveis de maturidade atingíveis entre colchetes):
Modelo de estrutura (v1.3)Dependendo das áreas de interesse (aquisição, serviços, desenvolvimento) usadas, as áreas de processo que ele contém irão variar. As áreas de processo são as áreas que serão cobertas pelos processos da organização. A tabela abaixo lista as dezessete áreas principais de processo do CMMI que estão presentes para todas as áreas de interesse do CMMI na versão 1.3.[11]
Áreas de ProcessoO modelo CMMI v1.3 (CMMI-DEV) contém 32 áreas de processo. Em sua representação por estágios, as áreas são divididas da seguinte forma: Nível 1: Inicial (Ad-hoc) Não possui áreas de processo. Nível 2: Gerenciado / Gerido
Nível 3: Definido:
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
Nível 5: Em otimização
Modelos e áreas de processoAs áreas de processo variam com base no modelo escolhido, não sendo as mesmas áreas para todos os modelos (CMMI-DEV, CMMI-ACQ ou CMMI-SVC). O CMMI-DEV divide os processos em quatro categorias: 1 - Gestão de Processos (5 processos) 2 - Gestão de projetos (8 processos) 3 - Engenharia (6 processos) 4 - Suporte (6 processos) 1. Gestão de Processo 1.1 - Foco no Processo Organizacional - (OPF - Organizational Process Focus) - (SE/SW) 1.2 - Definição do Processo Organizacional - (OPD - Organizational Process Definition) - (SE/SW) 1.3 - Treinamento Organizacional - (OT - Organizational Training) - (SE/SW) 1.4 - Desempenho de Processo Organizacional - (OPP - Organizational Process Performance) - (SE/SW) 1.5 - Inovação e Implementação Organizacional - (OID - Organizational Innovation and Deployment) - (SE/SW) 2. Gestão de Projeto 2.1 - Planejamento de Projeto - (PP - Project Planning) - (SE/SW) 2.2 - Monitoramento e Controle de Projeto - (PMC - Project Monitoring and Control) - (SE/SW) 2.3 - Gestão de Acordo com o Fornecedor - (SAM - Supplier Agreement Management) - (SE/SW) 2.4 - Gestão Integrada do Projeto - (IPM - Integrated Project Management) - (SE/SW) 2.5 - Gestão de Risco - (RSKM - Risk Management) - (SE/SW) 2.6 - Integração de Equipes - (IPPD) 2.7 - Gestão Integrada de Fornecedores - (SS) 2.8 -Gestão Quantitativa do Projeto - (QPM - Quantitative Project Management) - (SE/SW) 3. Engenharia 3.1 - Gestão de Requisitos - (REQM - Requirements Management) - (SE/SW) 3.2 - Desenvolvimento de Requisitos - (RD - Requirements Development) - (SE/SW) 3.3 - Solução Técnica - (TS - Technical Solution) - (SE/SW) 3.4 - Integração do Produto - (PI - Product Integration) - (SE/SW) 3.5 - Verificação - (VER - Verification) - (SE/SW) 3.6 - Validação - (VAL - Validation) - (SE/SW) 4. Suporte 4.1 - Gestão de Configurações (CM - Configuration Management) - (SE/SW) 4.2 - Garantia da Qualidade do Processo e do Produto - (CM - Configuration Management) - (SE/SW) 4.3 - Medição e Análise - (MA - Measurement and Analysis) - (SE/SW) 4.4 - Análise e Solução das Decisões - (DAR - Decision Analysis and Resolution) - (SE/SW) 4.5 - Ambiente Organizacional para Integração - (IPPD) 4.6 - Análise e Solução de Causas - (CAR - Causal Analysis and Resolution) - (SE/SW) ISO/IEC 15504A ISO/IEC 15504, também conhecida como SPICE, define um "processo para relatórios técnicos no assessoramento em desenvolvimento de software", e similarmente ao CMMI possui níveis de maturidade para cada processo. O CMMI não é baseado nesta norma, mas sim compatível. AvaliaçõesUma organização não pode ser certificada no CMMI, entretanto é avaliada. Dependendo do tipo de avaliação, a organização pode receber uma classificação de nível de maturidade (1-5) ou um perfil de realização de nível de capacidade. Muitas organizações encontram valor em medir seu progresso realizando uma avaliação. As avaliações são geralmente conduzidas por um ou mais dos seguintes motivos:
E as avaliações dessas organizações usando um modelo CMMI precisam estar em conformidade com os requisitos definidos no documento de Requisitos para o CMMI (ARC).[12] SegurançaPara abordar as preocupações de segurança do usuário, estão disponíveis dois guias de segurança não oficiais. Considerando o caso do conteúdo de segurança no CMMI para Serviços, há uma área de processo, o Gerenciamento de segurança. Segurança por Design com o CMMI para Desenvolvimento,[13] a versão 1.3 tem as seguintes áreas de processo: . OPSD - Preparação Organizacional para o Desenvolvimento Seguro . SMP - Gerenciamento Seguro em Projetos . SRTS - Requisitos de segurança e solução técnica . SVV - Verificação e validação de segurança Embora não afetem os níveis de maturidade ou capacidade, essas áreas de processo podem ser relatadas em resultados de avaliação.[14] AplicaçõesO modelo CMMI lida principalmente com os processos que devem ser implementados, e não tanto com a forma como eles podem ser implementados. E nada garante que a aplicação do CMMI numa organização aumentará o desempenho e qualidade nos seus processos. Turner & Jain (2002) argumentam que, embora seja óbvio que existem grandes diferenças entre o CMMI e o desenvolvimento de software ágil, ambas as abordagens têm muito em comum. Eles acreditam que nenhuma das maneiras é o caminho "certo" para desenvolver software, mas que existem fases em um projeto em que uma das duas é mais adequada. Eles sugerem que se deve combinar os diferentes fragmentos dos métodos em um novo método híbrido. Sutherland et al. (2007) afirmam que uma combinação de Scrum e CMMI traz mais adaptabilidade e previsibilidade do que qualquer um sozinho. David J. Anderson (2005) dá dicas sobre como interpretar o CMMI de maneira ágil. O CMMI pode ser avaliado usando duas abordagens diferentes: encenada e contínua. A abordagem em etapas produz os resultados da avaliação como um dos cinco níveis de maturidade. A abordagem contínua produz um dos quatro níveis de capacidade. As diferenças nessas abordagens são sentidas apenas na avaliação; as melhores práticas são equivalentes e resultam em resultados de melhoria de processos equivalentes. Referências
Ver tambémLigações externas
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
