Page 1

&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

Capability Maturity Model Integration (CMMI)

4

Introdução Este capítulo tem como objetivo mostrar um modelo de processo desenvolvido 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 disciplinas, 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 desenvolvimento 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 influência no convencimento da comunidade de engenharia de software em considerar seriamente o aprimoramento de processos. O CMM para software foi seguido por uma variedade de outros modelos de maturidade 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íficos 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

81,7,16‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡ž3(5Ì2'2

GEST_QUALI_SOFTWARE.indd 33

33

5/1/2010 07:51:02


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

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. $ "

#

&

'

% 1SPDFEJNFOUPTFNÏUPEPT EFmOJOEPPSFMBDJPOBNFOUP FOUSFBTUBSFGBT

1FTTPBTDPN IBCJMJEBEFT  USFJOBNFOUPTF NPUJWBÎÍP

'FSSBNFOUBTF FRVJQBNFOUPT

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.

34

ž3(5Ì2'2‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡81,7,16

TADS_5oP.indb 34

12/30/aaaa 15:48:38


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

Um processo imaturo é aquele (PESSÔA, 2004, p. 12): t Ad hoc; improvisado por profissionais e gestores. t Não é rigorosamente seguido e o seu cumprimento não é controlado. t Altamente dependente dos profissionais atuais. t Com baixa visão do progresso e da qualidade. t Cujas funcionalidades e qualidade do produto podem ficar comprometidas para que os prazos sejam cumpridos. t Arriscado do ponto de vista do uso de novas tecnologias. t Com custos de manutenção excessivos. t Com qualidade difícil de se prever. Já um processo maduro, conforme Pessôa (2004, p. 13) é aquele: t É compreendido. t É utilizado. t Vivo e ativo. t Possui o apoio visível da alta administração e outras gerências. t É bem controlado e a fidelidade ao processo é objeto de auditoria e de controle. t Possui medições do produto e do processo. t Permite o uso disciplinado da tecnologia. t É 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 características de um processo institucionalizado são (PESSÔA, 2004, p. 14): t é construída uma infraestrutura com processos eficazes, utilizáveis e consistentemente aplicada em toda organização; t a cultura organizacional deve conduzir e transmitir o processo; t a alta administração deve alimentar a cultura; t se ninguém se importa, todos se esquecem; t cultura é conduzida/transmitida através de modelos e recompensas; t 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.

81,7,16‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡ž3(5Ì2'2

GEST_QUALI_SOFTWARE.indd 35



5/1/2010 07:54:30


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

4.2 CMMI Capability Maturity Model Integration ou CMMI é um modelo de maturidade 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 desenvolvimento 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: t Serviços: projetado para organizações provedoras de serviços que querem melhorar sua capacidade de criar, gerenciar e prestar serviços. t Aquisição: modelo projetado para organizações de aquisição que querem melhorar sua capacidade de adquirir produtos e serviços. t Desenvolvimento: modelo projetado para organizações de desenvolvimento 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 maturidade 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: t á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; t objetivos: os objetivos são descrições abstratas de um estado desejado 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; t 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

36

ž3(5Ì2'2‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡81,7,16

TADS_5oP.indb 36

12/30/aaaa 15:48:38


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

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 Definição de processo organizacional

Foco no processo organizacional Gerenciamento de Treinamento organizacional processo Desempenho de processo organizacional Inovação e implantação organizacional Planejamento de projeto Monitoração e controle de projeto Gerenciamento de acordo com fornecedores Gerenciamento de Gerenciamento de projeto integrado projeto Gerenciamento de riscos Integração de equipes Gerenciamento quantitativo de projeto Gerenciamento de requisitos Desenvolvimento de requisitos Engenharia

Solução técnica Integração de produto Verificação Validação Gerenciamento de configuração Gerenciamento de qualidade processo e produto

Apoio

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).

81,7,16‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡ž3(5Ì2'2

TADS_5oP.indb 37

37

12/30/aaaa 15:48:38


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

Tabela 2

Exemplos de Objetivos no CMMI. OBJETIVO

ÁREA DE PROCESSO

Ações corretivas são gerenciadas até a conclusão Objetivo específico na monitoquando o desempenho do projeto ou os resultados ração e controle do projeto. desviam significativamente do plano. Desempenho real e o progresso do projeto são moni- Objetivo específico na monitoração e controle do projeto. torados contra o plano do projeto. Objetivo específico no desenvolOs requisitos são analisados e validados e uma defivimento de requisitos. nição da funcionalidade necessária é desenvolvida. O processo é institucionalizado como um processo Objetivo genérico. definido. 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 Os requisitos são analisão necessários e suficientes. sados e validados, e uma definição de funciona-Validar requisitos para assegurar que os produtos resullidade necessária é desentantes serão executados conforme esperado no ambiente do volvida. usuário usando várias técnicas quando apropriado. Causas principais de defeitos e outros probleExecutar análise causal de defeitos selecionados e outros mas são sistematicamente problemas e ações propostas para resolvê-los. determinados. Selecionar defeitos e outros problemas para análise.

Estabelecer e manter uma política organizacional para O processo é institucionaplanejamento e execução do processo de desenvolvimento lizado como um processo de requisitos. definido. Atribuir responsabilidade e autoridade para executar o processo, desenvolvendo produtos de trabalho e fornecendo os serviços do processo de desenvolvimento de requisitos. 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.

38

ž3(5Ì2'2‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡81,7,16

TADS_5oP.indb 38

12/30/aaaa 15:48:39


&$3ĂŒ78/2‡*(67ÂŽ2'$48$/,'$'('(SOFTWARE

Figura 1

Componentes do Modelo CMMI e seus Relacionamentos. ÂŤSFBEF QSPDFTTP 1SPQĂ˜TJUPEB ĂˆSFB

/PUBT JOUSPEVUĂ˜SJBT

1SPDFTTPT SFMBDJPOBEPT

0CKFUJWPT FTQFDĂ“mDPT

0CKFUJWPT HFOĂ?SJDPT

1SĂˆUJDBT FTQFDĂ“mDBT

1SĂˆUJDBT HFOĂ?SJDBT

"SUFGBUPT UĂ“QJDPT -FHFOEB

4VCQSĂˆUJDBT

3FRVFSJEP

&MBCPSBĂŽĂ?PEF QSĂˆUJDBTHFOĂ?SJDBT

4VCQSĂˆUJDBT &TQFSBEP

*OGPSNBUJWP

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 disponibilizadas 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 representaçþ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.

81,7,16Â&#x2021;$1Ă&#x2030;/,6(('(6(192/9,0(172'(6,67(0$6Â&#x2021;Â&#x17E;3(5Ă&#x152;2'2

GEST_QUALI_SOFTWARE.indd 39

39

5/1/2010 07:57:03


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

Antes de vermos cada uma em detalhes vamos a um quadro comparativo 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- Propicia às organizações uma cionar a ordem de melhoria que abordagem de melhoria provada melhor adapta-se aos objetivos do e predefinida. negócio da organização, reduzindo as áreas de risco. Propicia melhor visibilidade da capacidade alcançada, individualmente, 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 Resume os resultados da melhoria processos aplicando-se taxas de de processo em um formulário melhorias diferentes. 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 relacionamento com o retorno dos investimentos.

Construído sobre um histórico relativamente 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 representações, descritas em seus níveis na figura 2.

40

ž3(5Ì2'2‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡81,7,16

GEST_QUALI_SOFTWARE.indd 40

1/5/aaaa 19:47:22


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

Figura 2

As duas representações do CMMI. /ÓWFM /ÓWFM

$BQBDJEBEF

/ÓWFM /ÓWFM /ÓWFM /ÓWFM /ÓWFM

/ÓWFM /ÓWFM /ÓWFM /ÓWFM

1SPDFTTP $POUÓOVP

1PSFTUÈHJPT

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): t Nível 0 – incompleto: o processo não é executado ou é executado parcialmente. t Nível 1 – executado: o processo satisfaz as metas específicas da área de processo. t Nível 2 – gerenciado: o processo é executado e também planejado, monitorado e controlado para atingir um objetivo (em projetos individuais, grupos ou processos isolados). t Nível 3 – definido: o processo é gerenciado, adaptado de um conjunto de processos padrão da organização. t Nível 4 – gerenciado quantitativamente: o processo é definido, controlado utilizando estatística ou outras técnicas quantitativas. t 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.

81,7,16‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡ž3(5Ì2'2

GEST_QUALI_SOFTWARE.indd 41

41

1/5/aaaa 19:23:58


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

Figura 3

Níveis de Maturidade do CMMI no modelo Estagiado.

5 Foco na melhoria de processo

Otimização Gerenciado quantitativamente

4 Processo medido e controlado 3 Processo caracterizado para a organização e proativo

Definido

2 Processo caracterizado por projeto e frequentemente reativo 1 Processo imprevisível pobremente controlado e reativo

Gerenciado Inicial

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

Interessante qualificar 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 desenvolvimento e implantação do CMMI, para que possamos alcançar um nível alto de maturidade. Antes de finalizarmos 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. t O aprimoramento de processos envolve a análise de processo, padronização, medição e mudança. O treinamento é essencial para a eficiência do aprimoramento de processos. t Os processos podem ser classificados como informais, gerenciados, metódicos e de aprimoramento. Essa classificação pode ser usada para identificar o apoio de ferramentas aos processos. t O ciclo de aprimoramento de processos envolve medição, análise e modelagem, e mudança de processos. t As medições devem ser usadas para responder a questões específicas sobre o processo de software usado. Essas questões devem basear-se nos objetivos de aprimoramento organizacionais. t 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. t Modelos de processos incluem descrições de atividades, subprocessos, papéis, exceções, comunicações, entregas e outros processos. t O modelo de maturidade de processo CMMI é um modelo de aprimoramento de processos que apoia tanto os aprimoramentos de processo por estágios quanto os contínuos.

42

ž3(5Ì2'2‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡81,7,16

GEST_QUALI_SOFTWARE.indd 42

5/1/2010 08:00:29


&$3Ì78/2‡*(67®2'$48$/,'$'('(SOFTWARE

t O aprimoramento de processos no modelo CMMI baseia-se no alcance de um conjunto de objetivos relacionados às boas práticas de engenharia 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 melhoramento 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

81,7,16‡$1É/,6(('(6(192/9,0(172'(6,67(0$6‡ž3(5Ì2'2

TADS_5oP.indb 43

43

12/30/aaaa 15:48:39

Apostila referente a aula 4  

Teste testando agora mais um teste para testar

Read more
Read more
Similar to
Popular now
Just for you