CMMI – Representações - Introdução

Queridos leitores, passados os conceitos iniciais do CMMI, vamos agora entrar a fundo neste modelo que visa à qualidade do desenvolvimento de software. Para medir a qualidade, o CMMI criou duas formas de avaliar as organizações (ou partes dela), a saber: a Contínua e a por Estágios.

A representação Contínua possui níveis de capacidade (grave este conceito para não confundir depois) por área de processo, ou seja, a avaliação é feita de forma independente entre as áreas de processos, conforme mostra o exemplo da figura abaixo.

Utilizando esta forma de avaliação, a empresa tem mais flexibilidade, pois a escolha de qual área de processo será avaliada e melhorada é definida levando em consideração os objetivos de negócio da organização. Além disso, é possível se fazer comparações intra e interorganizações em relação a uma determinada área de processo ou ainda fazer uma comparação de resultados por equivalência (com a representação por Estágios – Não se preocupem que veremos isso nas próximas postagens).

Já a representação por Estágios possui níveis de maturidade (ML – Maturity Levels), onde a organização é medida como um todo. Cada estágio de maturidade engloba uma série de áreas de processos (na figura identificado como PA – Process Area) que são avaliadas em conjunto, fazendo que a organização evolua como um todo, como se cada nível fosse base para o próximo, formando assim uma pirâmide, como mostra o exemplo da figura abaixo.

Utilizando esta forma de representação, a organização não precisa reinventar a roda, pois o próprio modelo já define uma sequência comprovada de melhorias que vão sendo agregadas a cada nível. Além disso, é possível, da mesma forma que na representação Contínua, fazer comparações intra e interorganizações, mas desta vez, por meio de níveis de maturidade, ou seja, em relação a um conjunto de áreas de processos que estão inter-relacionadas.

Bem pessoal, visto de forma introdutória as duas formas de avaliação do CMMI, iremos, a partir da próxima postagem, adentrarmos em cada uma delas. Vamos juntos?

... então...

... Sigam-me os bons!!

CMMI – Componentes

Dando continuidade ao assunto CMMI, faremos, nesta postagem, a identificação dos principais componentes deste modelo. Esta identificação será primordial para o entendimento das formas de representação do CMMI. Estão prontos? Então vamos lá!

O primeiro componente básico do CMMI chama-se Área de Processo. Mas o que seria isso? Uma Área de Processo é um conjunto de práticas relacionadas a uma determinada área. Também conhecida apenas como Processo, uma Área de Processo busca satisfazer uma série de metas importantes na tentativa de implantar melhorias significativas naquela área. No CMMI Versão 1.2, que estamos estudando, existem 22 Áreas de Processo, conforme veremos nas postagens futuras.

Ficou meio nebuloso? Não se preocupem! Vejam no parágrafo abaixo que uma Área de Processo está diretamente relacionada aos outros componentes do CMMI, conforme negritamos acima. Entendendo-os, facilitará a compreensão sobre Área de Processo!

Assim sendo, os outros componentes básicos do CMMI são as Metas e as Práticas. Essas metas e práticas dividem-se em metas e práticas específicas e em metas e práticas genéricas. Para facilitar o entendimento, vamos conceituar a seguir cada uma delas:

• Metas Específicas: As metas específicas são aplicadas para cada uma das 22 Áreas de Processo de forma individual e descrevem os resultados que devem ser alcançados para satisfazer cada uma das áreas.

• Práticas Específicas: Assim como as metas específicas, as Práticas Específicas são aplicadas para cada uma das 22 Áreas de Processo individualmente e definem as atividades que são consideradas importantes para alcançar as metas específicas de uma determinada Área de Processo.

 

• Metas Genéricas: São consideradas genéricas porque valem para todas as Áreas de Processo de uma forma única, ou seja, uma mesma afirmação de meta vale para todas as Áreas de Processos.

• Práticas Genéricas: São as atividades genéricas que garantem que os processos sejam efetivos, repetíveis e duradouros.

Os componentes do CMMI podem, ainda, ser classificados da seguinte forma, para a avaliação de uma determinada organização:

• Componentes Requeridos: São os componentes obrigatórios em uma avaliação de uma determinada organização. Dentre os componentes existentes, são considerados obrigatórios as Metas Específicas e as Metas Genéricas. O alcance destas metas define a capacidade das Áreas de Processo e a maturidade organizacional.

 

• Componentes Esperados: São os componentes desejados. Dentre os componentes existentes, são considerados esperados as Práticas Específicas e as Práticas Genéricas. Em uma avaliação, espera-se que as práticas, ou algo equivalente que seja praticado pela organização, estejam presentes para que as metas possam ser alcançadas.

 

• Componentes Informativos: São os componentes sem valor para a avaliação, mas que servem para detalhar o trabalho da organização em relação às Áreas de Processo.

É importante lembrar que, para o CMMI, o termo avaliar a organização não necessariamente refere-se a toda a organização. Como veremos em postagens futuras a determinação do nível de capacidade ou de maturidade de uma organização pode estar restrita a uma determinada área desta organização, ou seja, posso avaliar apenas uma parte da empresa e classifica-la de acordo com as regras do CMMI.

Ufa! são muitos conceitos e classificações, certo? Para facilitar a memorização, coloquei o esquema acima que mostra a relação entre os componentes do modelo, além dos outros conceitos já tratados anteriormente. Percebam que existe o conceito de Nível de Capacidade que ainda não falamos. Não se preocupem, pois este termo será explicado nas próximas postagens!! Percebam, ainda, que cada Nível de Capacidade está relacionado a uma única Meta Genérica. Isto também será alvo das próximas postangens...

... por hora, esses conceitos devem estar “no sangue” para que possamos avançar... 

... Aguardem os próximos capítulos e...

Sigam-me os bons!!!

CMMI – Introdução – Disciplinas e Constelações

O CMMI possui uma série de disciplinas, que vieram, conforme vimos na postagem anterior, da evolução histórica deste modelo. As principais disciplinas são as seguintes:

• Engenharia de Software (SW) – Esta disciplina cobre a parte de desenvolvimento de software.
• Engenharia de Sistemas (SE) – É importante não confundir com o item anterior. Esta disciplina cobre o desenvolvimento de sistemas completos, ou seja, a parte de software e hardware. Aliás, na verdade, sob esta ótica, os sistemas podem ou não incluir softwares, uma vez que esta disciplina preza pela transformação das necessidades e expectativas do cliente em soluções de produtos, que não obrigatoriamente são softwares.
• Desenvolvimento Integrado de Produto e Processo (IPPD) – É uma disciplina que preza pela colaboração entre a equipe de desenvolvimento e de produção para satisfazer as expectativas dos clientes.
• Gestão de Fornecedores (SS) – Disciplina que cobre a parte de contratações críticas para o desenvolvimento de um determinado software.

Na versão 1.2, O CMMI foi montado a partir do conceito de “constelação”. Antes que alguém se confunda com o termo, é relevante esclarecer que uma constelação, na visão do CMMI, é o conjunto de áreas ou componentes relacionados entre si. Ainda não ficou claro? Não tem problema, vamos ver se fica mais claro com a exemplificação!

No CMMI versão 1.2 existem três diferentes constelações, a saber:

1 – CMMI para desenvolvimento (CMMI-Dev) – Conjunto das seguintes disciplinas relacionadas: Engenharia de Software (SW), Engenharia de Sistemas (SE) e Gestão de Fornecedores (SS). Opcionalmente, também teríamos o CMMI-Dev + IPPD.

2 – CMMI para Aquisições (CMMI-Acq) – Adaptação do CMMI-Dev para empresas que contratam o desenvolvimento de software.

3 – CMMI para Serviços (CMMI-Svc) – Conjunto de disciplinas que vão além do desenvolvimento, gerenciando o fornecimento de serviços de qualquer natureza e não apenas de TI (por isso, não configura como um concorrente do ITIL).

Ficou mais claro agora? Espero que sim... a partir das próximas postagens focaremos o nosso estudo no CMMI-Dev, pois é este que mais nos interessa na busca por uma Gestão de TI Intelitgente...

... e aí? Vamos juntos?

CMMI – Introdução - Origem

Queridos leitores, nesta postagem daremos início a um novo assunto em nosso blog. A busca por uma TI inteligente passa, também, por metodologias que estejam preocupadas com a qualidade dos softwares que são desenvolvidos e utilizados pelas organizações e/ou pessoas em suas mais diversas atividades. Apesar de ser um clichê, atualmente, não podemos negar que em quase todas as coisas que fazemos durante o dia há, de alguma forma, direta ou indiretamente, uma interação com um software. Vocês duvidam? Então vamos exemplificar! Se preciso tirar dinheiro da minha conta em um banco, de forma lícita obviamente, e independentemente do canal de comunicação que eu escolha (dentro da agência ou em um caixa eletrônico), terei que passar por um software que fará todo o processo de débito na minha conta, verificação de saldo, etc,etc,etc.

Agora, já imaginaram se não houvesse um método que pudesse garantir a qualidade do software que é desenvolvido para controlar algo tão significativo quanto o seu suado dinheirinho? É meus amigos... diante desta constatação, surge uma outra discussão, que não pretendo me estender, pois daria um livro, mas que é importante salientarmos, qual seja: Como consumidores de software, exigimos que os sistemas que interagimos sejam seguros, inteligentes, intuitivos quanto a navegabilidade, etc, etc. Por que será que ainda ouvimos falar que os sistemas que nós construímos para as nossas empresas, em grande parte, são vítimas de constantes reclamações, que o pessoal da TI obriga a empresa a utilizar um software que é ruim, etc, etc? Será que isso só acontece lá na Suiça, Bélgica, Noruega? Será que estamos dando aos nossos softwares os devidos cuidados?

Soltada a bomba, vem o remédio. Existe no mercado uma série de metodologias que tratam da qualidade do software. Uma das mais famosas e importantes é o CMMI – Capability Maturity Model Integration. Esta metodologia foi criada pela SEI – Software Engineering Institute da Carnegie Mellon University. O CMMI está, atualmente, na versão 1.3, mas a sua primeira versão foi criada em 2000 e é uma integração de vários outros modelos que já existiam e que foram lançados desde 1993, como por exemplo:

• SW-CMM – Capability Maturity Model for Software (1993)
• SE – CMM – System Engineering CMM (1995)
• EIA 731 SECM – System Engineering Capability Model (muito utilizado na parte de construção de harwares) (1998).

Não podemos negar que estes modelos, utilizados de forma isolada, eram muito uteis, mas a implementação de vários modelos dentro de uma organização gerava um certo descontrole e desequilíbrio, uma vez que as diferenças entre eles limitavam, de forma significativa, a possibilidade das empresas focarem nas melhorias destes modelos. Por isso, um modelo integrado (CMMI) que pudesse abarcar várias disciplinas, com suporte para treinamento, avaliação e medição de resultados, poderia ter um efeito melhor na qualidade dos softwares desenvolvidos nas organizações.

O projeto do CMMI foi criado com dois objetivos distintos. O primeiro, de curto prazo, focava na integração de três modelos específicos: SW-CMM, SE-CMM e IPD-CMM. Este último modelo não foi listado anteriormente, mas refere-se a metodologia chamada de Integrated Product Development. O segundo objetivo, de mais longo prazo, focava na criação de uma base onde fosse possível agregar novas disciplinas ao CMMI.

Bem, visto a origem deste importante modelo, a partir da próxima postagem entraremos mais a fundo nos conceitos iniciais e nos principais componentes do CMMI...

Vocês não perdem por esperar!!!