Centro Universitário UNA

Pós-Graduação em Gestão de Tecnologia da Informação

CMMI
Capability Maturity Model Integration

Professor: Julio Vilela da Silva Neto

Eduardo Fernandes Catrinck RA: 0623787

Belo Horizonte
2009
 Eduardo Fernandes Catrinck

CMMI
Capability Maturity Model Integration

Artigo de pesquisa apresentado

como requisito para obtenção de
certificação do curso de Pós
Graduação em Gestão de
Tecnologia da Informação, da
Faculdade UNA, sob a orientação
do professor Julio Vilela da Silva
Neto.

Belo Horizonte
2009

2
 CMMI
Capability Maturity Model Integration

Autor
EDUARDO FERNANDES CATRINCK
Centro Universitário UMA
JULIO VILELA DA SILVA NETO
Centro Universitário UNA

RESUMO

O CMMI é um modelo de melhores práticas na área de engenharia de software que tem

por objetivo aumentar a qualidade dos processos e consequentemente dos projetos
desenvolvidos pela organização, tornando-as mais maduras e eficientes, permitindo
assim, uma diminuição gradativa do custo associado aos mesmos. O CMMI divide a
organização em 22 áreas de processo que permitem uma maior facilidade, tanto na
compreensão, quanto na implementação das metodologias de qualidade sugeridas pelo
modelo, permitindo assim, que seus resultados já sejam identificados desde o inicio de
sua implantação. Apesar de aparentemente caro, o CMMI pode seguir uma abordagem
continua, diminuindo seu custo inicial e permitindo a implantação em qualquer empresa.

Palavras-chave: CMMI, Qualidade de Software, Maturidade.

INTRODUÇÃO

A qualidade é algo que desde os primórdios do desenvolvimento de software é deixada

de lado em prol de entregas mais rápidas, em vista disto, este estudo propõe a
implantação do modelo CMMI com o intuito de aumentar a qualidade nos processos e
consequentemente nos softwares desenvolvidos, bem como diminuindo o custo
associado aos mesmos (LEITE, 2001).

O CMMI é um modelo de melhores práticas na área de engenharia de software e foi

criado para ajudar as organizações a aprimorar seus processos e consequentemente

3
se tornarem mais maduras e eficientes com um visível aumento da qualidade dos
softwares desenvolvidos pelas mesmas (FERNANDES, 2008).

O objetivo deste estudo é explicar o funcionamento do CMMI de maneira mais didática,

detalhando suas divisões por áreas de processo e apresentando suas abordagens de
implementação (contínua e por estágios), bem como a equivalência encontrada entre
elas, desta forma, possibilitando demonstrar a aplicabilidade e os benefícios do modelo.

REFERENCIAL TEÓRICO

O conceito de qualidade é algo extremamente subjetivo e difícil de ser definido,

segundo a Infopédia (2009), qualidade é uma “propriedade ou condição natural de uma
pessoa ou coisa que a distingue das outras”.

No início do século 20, o controle de qualidade se resumia à inspeção e detecção de

erros e era medida de forma artesanal, onde cada tarefa a ser executada era controlada
individualmente. Em seguida, 1918, a Ford Motor Company cria a primeira linha de
montagem e juntamente com ela cresce a demanda por uma verificação de qualidade
um pouco mais apurada, porém ainda artesanal. (ROCHA, 2005)

Entre a década de 1940 e 1980, se inicia o controle estatístico da qualidade, impedindo

a entrega de produtos defeituosos a clientes, bem como conseguindo uniformidade no
serviço prestado. Em paralelo a esta metodologia de controle de qualidade, no Japão
(1940-1970), surge o conceito da qualidade total juntamente com as teorias defendidas
por Deming, Ishikawa, Juran e Crosby. (ROCHA, 2005)

A partir da década de 1980, com o mercado cada vez mais competitivo, alguns modelos
de qualidade começam a surgir. Este é o caso da ISO 9000 que foi lançada em 1987 e
foi baseada em normas britânicas de qualidade. Além da ISO 9000 também foram
criados o modelo EFQM (1988) e alguns prêmios referentes a qualidade passaram a
ser conferidos aos que se destacam nesta área. (ROCHA, 2005)

4
Apesar da crescente evolução no controle de qualidade dentro das empresas, e da real
necessidade do mesmo, a área de desenvolvimento de softwares sempre deixava a
qualidade em segundo plano e quando a mesma era tratada, normalmente se focava
apenas na qualidade do produto final desenvolvido, dando ênfase nos testes do mesmo
e deixando de lado o processo no qual o software em questão estava sendo
desenvolvido. (LEITE, 2001)

Porém, com a crescente demanda por sistemas cada vez mais complexos e integrados
diretamente ao funcionamento das organizações, segundo Duarte e Falbo (2000), “a
qualidade desponta como fator essencial no desenvolvimento de software”. Esta linha
de pensamento fez com que várias empresas de software entrassem neste século
focadas em ajustar seus processos, visando produzir softwares com maior qualidade,
dentro de prazos e orçamentos confiáveis.

Mas qual a definição de qualidade de software? Segundo Pressman (1995), "é a

conformidade a requerimentos e a características implícitas que são esperadas de
[qualquer] software profissionalmente desenvolvido". Um software de qualidade não
pode conter defeitos e deve fazer o que as pessoas querem que ele faça, ou seja, deve
estar condizente com o que foi previamente especificado.

Baseando-se nas definições supracitadas, percebe-se que para um software ser

considerado de qualidade, deve-se focar, não apenas no produto, mas principalmente
no processo como o mesmo é feito. Segundo Machado e Souza (2004), “a qualidade do
processo contribui para a melhoria da qualidade do produto, que por sua vez, contribui
para a melhoria da qualidade em uso”. Em suma a qualidade do software esta
diretamente ligada a qualidade do processo de desenvolvimento do mesmo.

Quando se coloca o foco no processo, garanti-se que a qualidade do software a ser

desenvolvido começa logo no princípio da criação do mesmo, pois além de se controlar
a qualidade do produto final, controla-se também a sua fabricação passo a passo,

5
medindo-se a qualidade antes mesmo do software ficar pronto. Esta medição prévia da
qualidade do processo vai influenciar diretamente na qualidade final do produto que
será entregue, reduzindo-se assim as incertezas oriundas aos resultados esperados
pelo software em questão. (MSW, [2000?])

Para se iniciar a produção de um software com qualidade, sugeri-se que um modelo de

qualidade seja adotado pela organização, e este estudo se foca na adoção do CMMI,
que é um modelo de melhores práticas na área de engenharia de software, mantido
pelo SEI e criado para ajudar as organizações a aprimorar seus processos, aumentar a
qualidade dos projetos, e se tornarem mais maduras e eficientes (FERNANDES, 2008).

PROCEDIMENTOS METODOLÓGICOS

Este estudo tem como meta demonstrar o funcionamento do CMMI, bem como os prós
e contras da implantação do mesmo, detalhando suas divisões por áreas de processo e
demonstrando a aplicabilidade e os benefícios disponibilizados por tal modelo de
qualidade.

Para tal, serão apresentados, de maneira detalhada, os tipos de abordagem

apregoados pelo modelo em questão (por estágios e contínua), bem como, as regras
que permitem que seja definida uma forma de equivalência entre os mesmos.

Para que fosse possível o cumprimento de tais metas, foi necessária a coleta de dados
a partir de várias fontes de pesquisa, enfatizando, em primeiro plano, alguns livros, em
especial o manual oficial da versão 1.2 do CMMI, o que permitiu uma maior
credibilidade aos dados coletados para montagem deste estudo.

Além dos livros supracitados, também foram fontes deste estudo, dissertações de
mestrado, apresentações feitas por profissionais de renome no mercado, além de
artigos publicados em sites especializados no assunto abordado.

6
ANÁLISE DOS DADOS

Histórico do Modelo

No início da década de 1980 o DoD se encontrava em meio a uma crise de qualidade e

custo na criação de softwares. Em vista disto, na CMU, foi criado o SEI (SÓRIA, 2006).
Que em 1988 inicia o desenvolvimento de um novo modelo de engenharia de software
que culminou no lançamento da primeira versão do SW-CMM em 1991. Em seguida a
EPIC se integra ao projeto e desenvolve o SE-CMM. A partir deste ponto outras
organizações se integram ao projeto e trazem uma evolução perceptível ao mesmo,
agregando várias disciplinas ao CMM (SÓRIA, 2006). Além dos CMMs associados a
Engenharia de Software (SW-CMM) e Sistemas (SE-CMM) outros modelos muito
conhecidos foram criados nesta época: Aquisição de Software (AS-CMM), Gestão e
Desenvolvimento de Força de Trabalho (P-CMM) e Desenvolvimento Integrado de
Processo e Produto (IPPD) (CARNEGIEMELLON, 2006; FERNANDES, 2008).

Diante deste cenário de modelos adaptados a realidades específicas, o SEI reuniu os

mesmos e em dezembro de 2001 propôs o lançamento do CMMI (SÓRIA, 2006) como
um modelo evolutivo aos vários CMMs que estavam sendo criados, visando assim
combinar os mesmos em uma estrutura flexível, única e componentizada, que pudesse
ser usada de maneira integrada por quaisquer organizações que demandassem
processos de melhoria em âmbito corporativo (FERNANDES, 2008).

Em agosto de 2006, a versão 1.2 do CMMI é publicada pelo SEI incorporando uma
série de melhorias e simplificações. Dentre estas mudanças estão às seguintes:
• Adoção de uma nova arquitetura (constelações) que permitisse ao modelo uma
expansão para outros focos, como aquisições e entregas de serviços.
• “Unificação do tratamento das disciplinas de engenharia de software, engenharia
de sistemas, desenvolvimento integrado de produto e processo e terceirização
em um só documento” (FERNANDES, 2008).

7
Visão Geral do Modelo

O CMMI foi criado para ajudar as organizações a se tornarem mais maduras e

eficientes aprimorando seus processos e aumentando a qualidade dos projetos
(FERNANDES, 2008). O mesmo pode ser implementado nestas organizações,
independente do tamanho delas, através de dois métodos distintos:
• Abordagem contínua de implementação
• Abordagem de implementação por estágio

Com o lançamento da versão 1.2 do CMMI surge o conceito de constelações, que

segundo Carnegiemellon (2006), são um ”conjunto de componentes de componentes
CMMI utilizados para construir modelos, materiais de treinamento e documentos de
avaliação”. Estas constelações são apresentadas logo abaixo (FERNANDES, 2008):
• CMMI-DEV (CMMI para Desenvolvimento) – Orientações para medir,
monitorar e gerenciar o processo de desenvolvimento de software.
• CMMI-SVC (CMMI para Serviços) – Orientações de como se devem fazer as
entregas de serviços às organizações e/ou aos clientes externos.
• CMMI-ACQ (CMMI para Aquisições) – Orientações de como efetuar o
gerenciamento de aquisições de serviços e produtos.

Este estudo é focado na CMMI-DEV e seus componentes são (FERNANDES, 2008):

• Área de Processo (PA) – Grupo de práticas executadas coletivamente que
satisfazem metas importantes na melhoria da área em questão.
• Metas Específicas – Metas associadas unicamente a uma PA.
• Práticas Específicas – Todas as atividades associadas ao atendimento das
metas específicas da PA em questão.
• Metas Genéricas – São metas comuns a mais de uma PA;
• Práticas Genéricas – Todas as atividades associadas ao atendimento das
metas genéricas;

8
Áreas do Processo (PA)

O CMMI é dividido em 22 áreas de processos (PA’s) que são agrupadas em quatro

categorias de afinidade que visam suportar a abordagem contínua de implementação.
Estas categorias são apresentadas em detalhes logo abaixo (FERNANDES, 2008):
• Gerenciamento de Processos – Categoria contendo as PA’s relativas à
definição, planejamento, distribuição de recursos, aplicação, controle,
implementação, monitoramento, avaliação, medição e melhoria de processos:
• OPF (Foco no Processo Organizacional) – Planejar, implementar e melhorar
o processo organizacional.
• OPD (Definição do Processo Organizacional) – Manter uma biblioteca com
modelos de ciclo de vida e diretrizes de adaptação dos processos.
• OT (Treinamento Organizacional) – Desenvolver as habilidades e o
conhecimento das pessoas.
• OPP (Desempenho do Processo Organizacional) – Estabelecer e manter
uma visão quantitativa do processo, melhorando a gestão dos projetos.
• OID (Inovação e Desenvolvimento Organizacional) – Selecionar e implantar
melhorias visando o cumprimento dos objetivos de desenvolvimento.
• Gerenciamento de Projetos – Categoria contendo as PA’s relativas ao
planejamento, monitoramento e controle do projeto:
• PP (Planejamento de Projetos) – Estabelecer e manter os planos de
atividades relacionados aos projetos.
• PMC (Monitoramento e Controle de Projetos) – Permitir a visualização do
progresso e dos desvios significativos em relação ao que foi planejado.
• SAM (Gerência de Acordos com Fornecedores) – Gerenciar a aquisição de
produtos de fornecedores externos.
• IPM (Gerência Integrada de Projetos) – Planejar e gerenciar projetos, além
do envolvimento dos grupos interessados no mesmo.
• RSKM (Gerência de Riscos) – Identificação prévia de problemas potenciais.
• QPM (Gerência Quantitativa de Projetos) – Gerenciar o processo definido no
projeto de forma quantitativa através de métricas.
9
 • Engenharia – Categoria contendo as PA’s relativas a manutenção e
desenvolvimento associados a engenharia de sistemas e de software:
• RD (Desenvolvimento de Requisitos) – Gerar, analisar, definir e validar
requisitos em conformidade com as solicitações dos grupos interessados.
• REQM (Gerência de Requisitos) – Identificar e gerenciar inconsistências nos
planos e produtos oriundos dos requisitos identificados para o projeto.
• TS (Solução Técnica) – Identificar soluções para atendimento aos requisitos.
• PI (Integração de Produtos) – Montar e entregar o produto ao cliente, com
garantia de funcionamento do mesmo.
• VER (Verificação) – Garantir que o produto satisfaça todos os requisitos.
• VAL (Validação) – Demonstrar que o produto irá atingir os resultados
esperados depois que o mesmo for entregue.
• Suporte – Categoria contendo as PA’s relativas a manutenção e
desenvolvimento de produtos, bem como na execução de outros processos:
• CM (Gerência de Configuração) – Garantir a integridade dos produtos por
meio do controle, verificação e monitoramento de sua configuração.
• PPQA (Garantia da Qualidade do Processo e do Produto) – Identificar as
não-conformidades, bem como acompanhar suas ações corretivas.
• MA (Medição e Análise) – Garantir, através de medições, informações
gerenciais referentes a conceitos, técnicas e mecanismos de execução.
• DAR (Análise de Decisões e Resoluções) – Analisar, através de processos
formais, a tomada de possíveis decisões.
• CAR (Análise de Causas e Resoluções) – Identificar problemas e possíveis
defeitos visando tomar ações corretivas previamente.

A Abordagem de Implementação por Estágios

Esta é a abordagem mais conhecida do CMMI (SÓRIA, 2006), sendo considerada uma
evolução direta do CMM (FERNANDES, 2008). A medida que um estágio é concluído,
assegura-se que a infra-estrutura adequada a evolução para o próximo estágio foi
adquirida (CARNEGIEMELLON, 2006).
10
Cada estágio é associado diretamente a um determinado nível de maturidade, sendo
que os mesmos consistem em práticas específicas e genéricas usadas para integrar um
conjunto definido de PA’s. O cumprimento destas práticas são um pré-requisito para se
atingir o nível de maturidade associado a elas (FERNANDES, 2008).

Além da melhoria incremental e duradoura (CARNEGIEMELLON, 2006) que esta

abordagem oferece, a conquista de maturidade pela organização pode ser usada como
argumento para, segundo Sória (2006), “mostrar ao mercado que seus produtos e
processos têm qualidade, podendo atrair novos clientes e novos negócios”. Os níveis
de maturidade associados à esta abordagem são os seguintes (SOTILLE, 2004):
1. Inicial – Fase inicial caracterizada pela completa falta de planejamento e
controle dos processos, ocasionalmente podendo chegar ao caos.
2. Gerenciado – São estabelecidos processos básicos de gerenciamento de
projeto para controlar custos, cronograma e funcionalidades. Todos os
compromissos firmados devem ser gerenciados.
3. Definido – As atividades de gerenciamento básico, bem como de Engenharia de
Software são documentadas, padronizadas e integradas em processos padrão.
4. Gerenciado Quantitativamente – Medições detalhadas do processo de
software e da qualidade do produto são coletadas e quantitativamente
compreendidas, avaliadas e controladas.
5. Otimizado – A melhoria contínua do processo é feita através de sua avaliação
quantitativa e da implementação planejada e controlada de tecnologias e idéias.

A Abordagem Contínua de Implementação

Esta abordagem oferece maior flexibilidade na utilização do CMMI para a melhoria de

processos, permitindo que cada uma de suas PA’s seja implementada de maneira
gradual e independente (FERNANDES, 2008). Permitindo, desta forma, um enfoque na
melhoria de um processo isolado ou ainda no trabalho em várias áreas fortemente
ligadas aos objetivos estratégicos da organização (CARNEGIEMELLON, 2006).

11
A abordagem continua não é divida em níveis de maturidade, mas sim em categorias
que agrupam as PA’s por assuntos comuns (item 4.2.2 deste documento). Estas PA’s,
por sua vez, se dividem em seis níveis de capacitação (FERNANDES, 2008):
0. Incompleto – O processo é executado parcialmente ou não é executado.
1. Executado – Todas as metas específicas do processo estão satisfeitas.
2. Gerenciado – O processo é planejado e executado de acordo com as políticas
organizacionais definidas, gerando saídas de forma controlada e permitindo o
monitoramento, o controle, a revisão e a avaliação quanto a conformidade de
sua descrição e ao desempenho previsto nos seus planos.
3. Definido – O processo é gerenciado e adaptado tomando por base um conjunto
de processos padronizados que evoluem continuamente.
4. Gerenciado Quantitativamente – O processo é definido e controlado por meio
de técnicas estatísticas e outros métodos quantitativos.
5. Otimizado – Gerenciado quantitativamente, sendo focado na melhoria continua
de seus processos por meio de inovações tecnológicas e melhorias
incrementais.

Equivalência entre as Abordagens de Implementação

A adoção da abordagem contínua não elimina a possibilidade de se utilizar a

abordagem por estágios para definir o grau de maturidade da empresa (FERNANDES,
2008). Para tal, deve-se efetuar a equiparação entre elas através de metodologias que
permitam que os níveis de capacidade possam ser convertidos em níveis de
maturidade (CARNEGIEMELLON, 2006). Sendo que a forma mais comum de se
retratar tal equivalência é o estabelecimento de perfis-alvo para se atingir o nível de
maturidade desejado (FERNANDES, 2008).

A figura 1 apresenta um resumo dos perfis-alvo que necessitam ser alcançados pela
organização para que a mesma possa atingir um determinado nível de maturidade
(FERNANDES, 2008). Cada área pintada na figura representa um perfil-alvo baseado

12
nos níveis de capacidade que a organização precisa atingir para mudar seu nível de
maturidade (CARNEGIEMELLON, 2006).
Nome Abrev. NM NC NC NC NC NC
1 2 3 4 5
Gestão de Requisitos REQM 2
Planejamento de Projeto PP 2
Monitoramento e Controle de Projeto PMC 2 Perfil-alvo
Gestão de Contrato com Fornecedores SAM 2
Medição e Análise MA 2
2
Garantia da Qualidade de Processo e Produto PPQA 2
Gestão de Configuração CM 2
Desenvolvimento de Requisitos RD 3
Solução Técnica TS 3
Integração de Produto PI 3
Verificação VER 3
Validação VAL 3
Foco nos Processos da Organização OPF 3 Perfil-alvo 3
Definição dos Processos da Organização +IPPD OPD +IPPD 3
Treinamento na Organização OT 3
Gestão Integrada de Projeto +IPPD IPM +IPPD 3
Gestão de Riscos RSKM 3
Análise e Tomada de Decisões DAR 3
Desempenho dos Processos da Organização OPP 4 Perfil-alvo 4
Gestão Quantitativa de Projeto QPM 4
Implantação de Inovações na Organização OID 5 Perfil-alvo 5
Análise e Resolução de Causas CAR 5
Figura 1 – Perfis-alvo e Equivalência com a Representação por Estágios.
Fonte: Adaptado de CARNEGIEMELLON (2006).

Abaixo é detalhado como se dá esta equivalência (CARNEGIEMELLON, 2006):

• Para se obter o nível de maturidade 2, todas as PA’s associadas a este nível de
maturidade devem alcançar, no mínimo, o nível de capacidade 2.
• Para se obter o nível de maturidade 3, todas as PA’s associadas aos níveis de
maturidade 2 e 3 devem alcançar, no mínimo, o nível de capacidade 3.
• Para se obter o nível de maturidade 4, todas as PA’s associadas aos níveis de
maturidade 2, 3 e 4 devem alcançar, no mínimo, o nível de capacidade 3.
• Para se obter o nível de maturidade 5, todas as PA’s devem alcançar, no mínimo,
o nível de capacidade 3.

Aplicabilidade do Modelo

A implantação do CMMI é realizada com base em uma das abordagens supracitadas,

sendo que a escolha de qual melhor se adapta a uma determinada organização
depende de alguns fatores que são apresentados abaixo (FERNANDES, 2008):

13
 • Abordagem de Implementação por Estágios – Recomendada para empresas
que já possuem alguma experiência na inserção de melhorias em seus
processos organizacionais ou que podem fazer grandes investimentos em
qualidade para obtenção de níveis de maturidade.
• Abordagem Contínua de Implementação – Recomendada para empresas
que preferem uma evolução gradual em sua capacitação ou empresas menores
que desejam agregar qualidade em seus processos, porém a um custo menor.

Benefícios do Modelo

O CMMI tem como principal benefício a melhoria nas estimativas/previsibilidade das

entregas dos projetos (VOLPE, 2003), porém existem inúmeros outros benefícios, e os
mesmos serão detalhados abaixo (FERNANDES, 2008):
• Aderência do processo – Definição adequada dos processos e
implementação de mecanismos de gerenciamento para seus produtos.
• Custo – Redução no custo dos produtos intermediários e/ou finais, além da
redução nos custos atribuídos a melhoria de processos baseadas no modelo.
• Prazo – Melhoria nas estimativas de tempo, além da redução no tempo
necessário para realizar as tarefas.
• Produtividade – Fazer mais trabalhos com menos tempo e custo, através de
melhores processos de produção e da utilização das tecnologias disponíveis.
• Qualidade – Redução no número de defeitos, não só no produto final, como
também em diferentes pontos do processo, tornando o software mais confiável.
• Satisfação do cliente (Consumidor) – Medir de forma qualitativa, através de
questionários e de retornos diretos, a satisfação do cliente com o produto final.

Tomando-se por base a abordagem por estágios podem-se associar outros benefícios a
cada nível de maturidade (FERNANDES, 2008; VOLPE, 2003):
• Gerenciado (Nível 2) – Maior previsibilidade para os projetos com melhor
controle dos acordos com fornecedores e maior segurança nas análises e
avaliações obtidas através da criação de uma base de medições operacional.

14
 • Definido (Nível 3) – Maior integração da equipe de trabalho e um melhor
gerenciamento integrado de suprimentos. Além disto, através do uso de
métodos formais de análise, há uma melhora na tomada de decisões, pois os
requisitos de desenvolvimento e as verificações/validações ganham robustez.
• Gerenciado Quantitativamente (Nível 4) – Melhor performance organizacional
do processo através do gerenciamento quantitativo de projetos.
• Otimizado (Nível 5) – Melhoria contínua do processo com base em um
entendimento quantitativo, onde a variação de um processo resiste às
interações entre seus componentes.

CONSIDERAÇÕES FINAIS

Com a crescente necessidade de softwares cada vez mais complexos e diretamente

integrados ao funcionamento das organizações a qualidade se torna fator essencial no
desenvolvimento dos mesmos. E para se iniciar a produção de um software com
qualidade este estudo focou-se na adoção do CMMI, que apresenta um modelo usual e
palpável de melhores práticas na melhoria dos processos, que são a espinha dorsal do
desenvolvimento de qualquer software.

Apesar de o CMMI nos apresentar um modelo do que seguir para alcançar a tão
almejada qualidade, o processo de implantação do mesmo, por vezes se torna caro e
dispendioso, o que acaba por afastar pequenas empresas deste caminho. Porém, na
contramão desta afirmação, o CMMI sugere a implementação de sua abordagem
contínua, que além de diluir o custo inicial desta implantação, permite, de forma clara,
que grande parte de seus processos possam ser controlados sem grandes gastos com
softwares de suporte ao mesmo. O problema encontrado em tal abordagem, esta
diretamente ligado a falta de informação referente a mesma, que no material de apoio a
esta pesquisa se mostrou muito pouco explorado.

Com base em todos os dados coletados por este estudo é factível concluir que o foco
na qualidade é algo que tende a aumentar, tornando-se um diferencial no momento da

15
contratação de um software e/ou empresa para desenvolver o mesmo. Para auxiliar a
mensuração do nível de qualidade apresentado pelas empresas, o CMMI se mostrou
maduro, coerente e democrático, demonstrando que mesmo pequenas empresas
podem desenvolver softwares com qualidade, custo reduzido e entrega nos prazos,
sem que para isto tenham que desembolsar fortunas logo no inicio de sua implantação.

LISTA DE SIGLAS

CMMI – Capability Maturity Model Integration

CMU – Carnegie Mellon University
DoD – Department of Defense of US – Departamento de Defesa Norte Americano
EFQM – European Foundation for Quality Management
EPIC – Enterprise Process Improvement Collaboration
SE-CMM – System Engineering CMM
SEI – Software Engineering Institute
SW-CMM – Software CMM

REFERÊNCIAS

CARNEGIEMELLON. CMMI para Desenvolvimento – Versão 1.2 (CMMI-DEV, V1.2) –

Melhoria de processos visando melhores produtos. Pittsburgh, PA: Software
Engineering Institute, 2006.

DUARTE, Kátia Cristina; FALBO, Ricardo de Almeida. Uma Ontologia de Qualidade de

Software, 2000. Disponível em: http://www.cefetrn.br/~placido/disciplina/pgp/material/W
qs2000.pdf. Acessado em: 16 de novembro de 2009.

FERNANDES, Aguinaldo Aragon, et al. Implantando a Governança de TI. São Paulo:

Brasport, 2008. cap. 8.

16
INFOPÉDIA. Enciclopédia e Dicionários, 2009. Disponível em: http://www.infopedia.pt/p
esquisa-global/qualidade. Acessado em: 16 de novembro de 2009.

LEITE, Júlio C. S. P. Gerenciando a Qualidade de Software com Base em Requisitos.

Qualidade de Software: Teoria e Prática, 2001. Disponível em: http://www-di.inf.puc-
rio.br/~julio/Slct-pub/Livro-qualidade.pdf. Acessado em: 16 de novembro de 2009.

MACHADO, Márcio P.; SOUZA, Sotério F. Métricas e Qualidade de Software, 2004.

Disponível em: http://fattocs.com.br/download/qualidade-sw.pdf. Acessado em: 16 de
novembro de 2009.

MSW, Métricas e Software. Qualidade de Software, [2000?]. Disponível em:

http://www.mswconsult.com.br/qualidade.html. Acessado em: 16 de novembro de 2009.

PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron Books, 1995. 1056p.

ROCHA, Álvaro. Qualidade de Software, 2005. Disponível em: http://www2.ufp.pt/~amro

cha/mq/Qualidade%20de%20Software.pdf. Acessado em: 16 de novembro de 2009.

SÓRIA, Felipe Grando. Implantação do CMMI: Metodologia baseada na abordagem por

processos. Curitiba: Pontifícia Universidade Católica do Paraná, 2006.

SOTILLE, M. A. PMBok & CMM + CMMI – Resumo, 2004. Disponível em: http://www.p
mtech.com.br/artigos/PMBOK&CMM+CMMI.pdf. Acessado em: 2 de outubro de 2009.

VOLPE, Renato Luiz Della, et al. CMM-CMMI – Principais Conceitos, Diferenças e

Correlações, 2003 - Disponível em: http://www.asrconsultoria.com.br/docs/SPIN_BH_
CMMI.pdf. Acessado em: 08 de outubro de 2009.

17