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
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
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)
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,
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.
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).
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
Á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
• 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
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).
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
nos níveis de capacidade que a organização precisa atingir para mudar seu nível de maturidade (CARNEGIEMELLON, 2006). Nome Abrev. NM NC 1 NC 2 NC 3 NC 4 NC 5
Gestão de Requisitos REQM 2
Perfil-alvo 2
Planejamento de Projeto PP 2
Monitoramento e Controle de Projeto PMC 2 Gestão de Contrato com Fornecedores SAM 2
Medição e Análise MA 2
Garantia da Qualidade de Processo e Produto PPQA 2
Gestão de Configuração CM 2 Desenvolvimento de Requisitos RD 3 Perfil-alvo 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 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):
• 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
• 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
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.
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_
