MONOGRAFIA - MODELO CMMI

Prévia do material em texto

MICHELE DE SOUZA LIMA 
 
 
 
 
 
 
 
 
 
 O IMPACTO DO MODELO CMMI NA QUALIDADE DO 
 SOFTWARE: UM ESTUDO SOBRE A MELHORIA DOS PROCESSOS 
 
 
 
 
 
 
 
 
 
 
 
 CATAGUASES 
 FACULDADES UNIFICADAS DE CATAGUASES 
 BACHARELADO EM SISTEMAS DE INFORMAÇÃO 
 2016 
 
 
 
 MICHELE DE SOUZA LIMA 
 
 
 
 
 
 
 O IMPACTO DO MODELO CMMI NA QUALIDADE DO 
 SOFTWARE: UM ESTUDO SOBRE A MELHORIA DOS PROCESSOS 
 
 
 
 
Projeto de Monografia apresentado ao Curso de 
Sistemas de Informação do Instituto Doctum de 
Educação e Tecnologia, como requisito parcial à 
obtenção do título de Bacharel em Sistemas de 
Informação. 
Área de Concentração: Engenharia de Software 
Orientador: Prof.Matheus Botarro. 
 
 
 
 
 
 
 
CATAGUASES 
FACULDADES UNIFICADAS DE CATAGUASES 
BACHARELADO EM SISTEMAS DE INFORMAÇÃO 
2016 
 
 
 FACULDADES UNIFICADAS DE CATAGUASES 
CATAGUASES 
 2016 
 
 
 
 MICHELE DE SOUZA LIMA 
 
 
 
O IMPACTO DO MODELO CMMI NA QUALIDADE DO 
SOFTWARE: UM ESTUDO SOBRE A MELHORIA DOS PROCESSOS 
 
 
 
Trabalho de Conclusão de Curso apresentado ao 
Curso de Sistemas de Informação das Faculdades 
Unificadas de Cataguases, como requisito parcial à 
obtenção do título de Bacharel em Sistemas de 
Informação. 
 
 
BANCA EXAMINADORA 
 
_____________________________________________ 
Prof. Matheus Botarro – Orientador 
Faculdades Unificadas de Cataguases 
 
_____________________________________________ 
Prof. Xxxxxxx 
Faculdades Unificadas de Cataguases 
 
_____________________________________________ 
Prof. Xxxxxxx 
Faculdades Unificadas de Cataguases 
 
 
RESUMO 
 
O presente trabalho trata os conceitos relativos à qualidade do software e 
modelos de maturidades. Dentro dessa proposta, foram abordadas as principais 
atividades do processo de garantia de qualidade, segundo o modelo de melhoria de 
processo CMMI. O projeto iniciou-se com a realização de um questionário que 
indicaram quais metas e benefícios às empresas esperam com a implantação do 
modelo CMMI, onde serviu como estudo de caso para o presente projeto. Foram 
identificadas as demandas de processos que deveriam ser avaliados e melhorados, 
a fim de se alcançar as metas e objetivos estabelecidos no questionário, passou-se 
a fase de estudos dos modelos, dentre os existentes se adaptariam melhor as metas 
e objetivos da organização. 
PALAVRAS-CHAVE: Qualidade, Software, Qualidade de Software, Garantia da 
Qualidade de Software. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 SUMÁRIO 
 
INTRODUÇÂO ....................................................................................................................... 12 
CAPÍTULO 1 – VISÃO GERAL DA ENGENHARIA DE SOFTWARE ......................... 14 
CAPÍTULO 2 – QUALIDADE DE SOFTWARE ............................................................... 16 
2.1 SQA (Garantia da Qualidade de Software) ........................................................... .18 
2.2 SEPG (Software Engineering Process Group) ...................................................... 20 
CAPÍTULO 3 – MODELOS DE MATURIDADE ............................................................... 22 
3.1 CMM (CAPABILITY MATURITY MODEL) ................................................................. 23 
3.2 CMMI (CAPABILITY MATURITY MODEL INTEGRATION) ................................... 25 
3.2.1 Representação dos Modelos .................................................................................. 28 
3.2.1.1 Representação por Estágio ................................................................................. 28 
3.2.1.2 Representação Contínua ...................................................................................... 30 
3.2.2 Áreas-chave de processo (Key Process Areas ou KPAs) .............................. 32 
3.2.3 Características Comuns e Práticas-chave .......................................................... 33 
3.3 MPS-BR (MELHORIA DO PROCESSO DE SOFTWARE) .................................... 34 
3.3.1 Níveis de maturidade ................................................................................................ 35 
CAPÍTULO 4 – APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE 
CASO COM MODELO CMMI .................................................................................. 37 
4.1 Tipo de pesquisa ............................................................................................... 37 
4.2 Processos metodológicos ................................................................................ 37 
4.3 Etapas do questionário ..................................................................................... 38 
4.4 Elaboração do plano de ação .................................................................................... 43 
4.5 Soluções encontradas ...................................................................................... 43 
4.6 Resultados esperados com a implantação do CMMI ..................................... 44 
CONSIDERAÇÕES FINAIS ...................................................................................... 46 
REFERÊNCIAS ......................................................................................................... 47 
ANEXO A .................................................................................................................. 51 
 
 
 
 
 
 DEDICATÓRIA 
Primeiramente a Deus, por tudo que me proporcionou na vida, por me dar 
forças para alcançar meus objetivos, por me cercar de pessoas maravilhosas sem as 
quais minha caminhada não teria sentido e por todas as oportunidades a mim 
proporcionadas. 
A minha mãe Marilucia de Souza Lima, pelo esforço empreendido, por 
sempre me apoiar, e pelo exemplo de vida e luta. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 AGRADECIMENTOS 
Agradeço a Deus por tudo o quanto tem feito e por sua misericórdia infinita. 
Aos meus pais, por terem me ajudado financeiramente quando eu mais precisei. Aos 
meus professores e as pessoas que de alguma maneira contribuíram para a 
realização desse trabalho. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 “Para se ter sucesso, é necessário amar de 
verdade o que se faz. Caso contrário, levando em conta 
apenas o lado racional, você simplesmente desiste. É o 
que acontece com a maioria das pessoas”. 
(Steve Jobs) 
 
 
LISTA DE FIGURAS 
 
Figura 1: Camadas de engenharia de software ..................................................... ...15 
Figura 2: Modelo de Maturidade de Capacitação do SEI ......................................... 24 
Figura 3: Estrutura de representação por estágio .................................................... 30 
Figura 4: Estrutura de representação contínua ........................................................ 31 
Figura 5: Pergunta número 04 do questionário ao usuário ...................................... 38 
Figura 6: Pergunta número 05 do questionário ao usuário ...................................... 39 
Figura 7: Pergunta número 06 do questionário ao usuário ...................................... 39 
Figura 8: Pergunta número 07 do questionárioao usuário ...................................... 40 
Figura 9: Pergunta número 08 do questionário ao usuário ...................................... 40 
Figura 10: Pergunta número 09 do questionário ao usuário .................................... 41 
Figura 11: Pergunta número 10 do questionário ao usuário .................................... 41 
Figura 12: Pergunta número 11 do questionário ao usuário .................................... 42 
Figura 13: Pergunta número 12 do questionário ao usuário .................................... 42 
 
 
 
 
 
 
 
 
 
 
LISTA DE TABELAS 
 
Tabela 1: Áreas de processos .................................................................................. 33 
Tabela 2: Resultados do desempenho CMMI ........................................................... 45 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABREVIATURAS E SIGLAS 
DOD - Departamento de Defesa dos Estados Unidos 
CMM - Capability Maturity Model 
CMM - Capability Maturity Model Integration 
KPA - Key Process Areas 
MPS.BR - Melhoria do Processo de Software Brasileiro 
ROI - Retorno de Investimento 
SEI - Software Engineering Institute 
SGQ - Sistema de gestão da qualidade. 
SQA - Software Quality Assurance 
QA - Quality Assurance 
 
 
12 
 
 
 
INTRODUÇÃO 
A busca pela qualidade é um dos assuntos mais discutidos nas organizações 
desenvolvedoras de software. Nos dias de hoje, não são mais permitidos entregar 
produtos com baixa qualidade e corrigir os erros e falhas depois que o produto é 
fornecido aos clientes. 
Para PRESSMAN (1995)1, “os problemas que afligem o desenvolvimento de 
software podem ser caracterizados a partir de uma série de perspectivas diferentes”, 
mas, em muitos casos, ocorre uma grande frustração por parte dos clientes pelo não 
atendimento dos requisitos e prazos de entrega. 
Para dar soluções aos desafios e aumentar o grau de maturidade das 
empresas, vários modelos de melhoria de qualidade foram propostos, dentre eles, 
destacam-se os baseados em processos como o CMMI (Capability Maturity Model 
Integration) e MPS.BR (Melhoria do Processo de Software Brasileiro). 
Segundo SOMMERVILLE (2003)2, “a melhoria do processo significa 
compreender os processos existentes e modificá-los, a fim de melhorar a qualidade 
do produto e/ou reduzir custos e o tempo de desenvolvimento”. Conforme o autor é 
necessário seguir uma sequência de atividades denominada de estágios que 
envolvem: Análise de processos, identificação de melhoria, introdução de mudanças 
nos processos, treinamento de mudanças e ajustes. Diante disso, é essencial que os 
desenvolvedores coloquem eficiência e eficácia nos seus processos, garantindo a 
melhoria conforme os padrões de qualidade internacionais. 
Sobre o conceito de organizações que desenvolvem software, o presente 
trabalho tem como foco principal retratar a importância de qualidade de software, a 
partir da utilização de modelos de melhoria de processos e atividades de garantia 
qualidade. 
O trabalho é iniciado com base na engenharia de software e se dirige a um 
mercado que só há pouco tempo vêm revelando o seu interesse em certificações de 
qualidade em seus processos. 
Para melhor abordar o assunto, o presente trabalho questiona alguns 
problemas que a engenharia de software se propõe a resolver como: falta de 
qualidade, insatisfação dos clientes e custo. Para esses problemas, a causa mais 
 
1
 PRESSMAN, 1995, p. 23. 
2 
SOMMERVILLE, 2003, p.477. 
13 
 
 
 
relevante e a falta de experiência de profissionais durante o desenvolvimento, a falta 
de treinamento em relação aos modelos e técnicas, a atenção aos requisitos 
implícitos pelos clientes, e as mudanças no ramo (novas técnicas de 
desenvolvimento). 
Este trabalho está definido em uma sequência que auxilia no entendimento e 
desenvolvimento. A parte inicial disserta os conceitos básicos de engenharia de 
software e as principais questões relacionadas à crise de software. No segundo 
capítulo são apresentados teorias, conceitos e fatores sobre a qualidade do 
software, assim como, o gerenciamento e equipe de produção. No terceiro capítulo 
são apresentados os modelos de melhorias criados pelo SEI: CMM e CMMI, como 
também o modelo MPS.BR. Ambos possuem a mesma terminologia e o mesmo 
objetivo, garantir a melhoria dos processos. Para tanto, foi feito um estudo sobre os 
níveis e componentes sobre os dois Modelos de Maturidade. 
O quarto capítulo consiste na aplicação de um estudo de caso, com a 
finalidade de colher informações for meio de um questionário que foi aplicado em 
algumas empresas no setor de desenvolvimento de software e por profissionais na 
área de tecnologia da informação. 
Todo o referencial teórico, bem como o estudo realizado, se deu através de 
artigos publicados, sites de desenvolvedores e livros de engenharia de software 
baseado em teorias tecnológicas de PRESSMAN, SOFTEX, SOMMERVILLE, dentre 
outros que deram sustento a concretização da pesquisa. 
Abaixo, surgem as considerações finais, onde relata uma conclusão geral do 
trabalho realizado, as dificuldades encontradas e as recomendações. Por fim, as 
referências bibliográficas, de onde foi retirada toda a teoria expressa. 
 
 
 
 
 
 
14 
 
 
 
1 VISÃO GERAL DA ENGENHARIA DE SOFTWARE 
A engenharia de software é uma disciplina que está presente em todo o ciclo 
de vida do software, desde o inicio de criação, até a entrega e a manutenção. 
Segundo HIRAMA (2012)3, o termo engenharia de software foi nomeado a 
primeira vez em 1969, devido a um conjunto de problemas encontrados na 
produtividade dos softwares em meio à famosa ‘crise de software’. A crise se referia 
aos softwares desenvolvidos naquela época que apresentavam uma grande 
quantidade de defeitos, custos excessivos, qualidade do produto inadequada e 
prazos elevados. Sua implementação era iniciada a partir de uma simples definição. 
Não eram utilizados metodologias, métricas, processos, planejamento e 
cronogramas, o que trazia grandes problemas aos projetos. 
Para PRESSMAN (1995)4, os problemas relacionados à crise foram 
provocados pelo próprio software e por falhas de pessoas responsáveis pelo seu 
desenvolvimento. Além disto, na tentativa de se consertar os erros, muitas vezes as 
pessoas introduziam mais erros no código. Contudo, tanto o desenvolvimento como 
as correções eram trabalhosas e requeria muito tempo, sem contar que a linguagem 
utilizada era de baixo nível. 
 SOMMERVILLE (2003)5, afirma que novas técnicas e métodos foram 
necessários para controlar as dificuldades dos grandes sistemas da época. Diante 
disso, surgiu o termo Engenharia de Software, que se refere ao desenvolvimento de 
software por pessoas qualificadas, englobando aspectos técnicos e não-técnicos, de 
forma a produzir software de qualidade, eficiente e dentro de custos aceitáveis. 
Os fundamentos científicos para a engenharia de software envolvem o uso de 
modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, 
implementar e manter sistemas de software, avaliando e garantindo suas 
qualidades. 
A engenharia de software é abrangida por um conjunto de três elementos que 
envolvem métodos, ferramentas e procedimentos. Esses elementos são focados na 
busca pela qualidade e melhoria dos processos, como demonstra a figura 1. 
 
 
3
 HIRAMA, 2012, p. 7-8. 
4
 PRESSMAN, 1995, p.24. 
5
 SOMMERVILLE, 2003, p.4 
15Figura 1: Camadas de engenharia de software 
 Fonte: PRESSMAN e MAXIM, 2016, p.16. 
 
Segundo PRESSMAN (1995)6, os três elementos possibilita aos gerentes e 
engenheiros um controle sobre o processo de desenvolvimento, e assegura uma 
base para a elaboração de software de boa qualidade. 
A qualidade de um software pode ser vista no processo utilizado na produção 
dele. Muitas vezes os processos não são tomados devido à falta de qualificação da 
equipe, por ausência de ferramentas e por pressão de prazos que levam os gerentes 
a eliminar fases da garantia de qualidade (FILHO, 2008)7. 
Devido a isso, a engenharia de software foi desenvolvida para se ocupar de 
buscar fórmulas e regras para o desenvolvimento do software e determinar essas 
regras da melhor forma possível a todos os envolvidos no projeto. Para construção 
de um software de boa qualidade, é necessário que o conceito seja aplicado por 
toda equipe, começando pelo os gerentes, engenheiros, diretores, analistas, 
programadores, e usuários do sistema (RODRIGUES, 2008)8. Obter esse conceito 
não é uma tarefa muito fácil para uma organização. 
Contudo, a engenharia de software surgiu em meio aos problemas 
encontrados no desenvolvimento, sucedendo em práticas, soluções e melhorias que 
são utilizadas por todas as organizações até os dias de hoje. 
 
 
 
 
6
 PRESSMAN, 1995, p.31. 
7
 FILHO, 2008, p.19. 
8
 RODRIGUES, 2008, p.8. 
16 
 
 
 
2 QUALIDADE DE SOFTWARE 
 
Criar um software de qualidade é o objetivo de todas as organizações 
desenvolvedoras de software. A maior parte da literatura relacionada a esse assunto 
acredita que a qualidade pode ser vista quando um produto final é aceito pelo cliente 
dentro do prazo estabelecido, conforme as funcionalidades em perfeito 
funcionamento. 
 Entretanto, para assegurar a qualidade do produto, é preciso seguir todas as 
fases de desenvolvimento que vem desde a coleta de requisitos. A partir do 
momento que os requisitos são atendidos, é atribuída a qualidade no software. 
Em um produto de software de má qualidade, muitos dos requisitos não são 
atendidos completamente, devido à falta de qualificações das pessoas, deficiências 
de ferramentas ou porque pressões de prazo que levam os gerentes de projeto a 
eliminar etapas relacionadas ao controle de qualidade. 
Para atingir a qualidade do software, é necessário um planejamento, 
utilizando procedimentos, modelo e padrões, seguindo todas as etapas do ciclo de 
vida do software com atividades que asseguram garantir a qualidade do processo, e 
qualidade do produto desenvolvido. 
Segundo PFLEEGER (2004)9 a qualidade pode é atendida por três modos 
diferentes: “qualidade do produto, qualidade do processo que resulta o produto e 
qualidade do produto no contexto do ambiente de negócios em que ele será 
desenvolvido. 
Geralmente a qualidade de um produto, decorre diretamente da qualidade do 
processo utilizado na produção dele. No entanto, há de se considerar que diferentes 
usuários têm intenções diferentes para o mesmo produto. 
Persiste agravante no mercado nacional, em que, em virtude da má qualidade 
dos processos de desenvolvimento, há necessidade de retrabalho. Mesmo assim, 
empresas entregam produtos com erros, fazendo com que elas não consigam atingir 
níveis de qualidade internacional, o que afeta a exportação de produtos de software. 
 
 
9
 PFLEEGER, 2004,8. 
17 
 
 
 
A partir disso, existem vários conceitos de diferentes autores sobre o que é a 
qualidade de um produto de software. Conforme Pressman (1995)10, a qualidade 
pode ser entendida como: 
 
Conformidade a requisitos funcionais e de desempenho 
explicitamente declarados, a padrões de desenvolvimento 
claramente documentados e a características implícitas que são 
esperadas de todo software profissionalmente desenvolvido. 
Nessa definição o autor enfatiza três pontos importantes: 
 Os requistos de softwares que são avaliados para assegurar a 
qualidade. 
 Aos padrões que estabelecem a maneira como o software é 
desenvolvido. 
 Aos requisitos implícitos que não são documentados 
Conforme as indústrias cada vez mais competitivas, a procura pela qualidade 
tem sido uma grande aflição para as organizações. Um software pode ser 
desenvolvido ou não com técnicas de engenharia de software. 
Para RODRIGUES (2008)11, os perigos em desenvolver software sem 
técnicas de engenharia de software, são as resultados adquiridos depois que o 
projeto é finalizado. Um software sem as técnicas de engenharia pode acometer a 
qualidade do produto levando ao insucesso e fracassos no desenvolvimento, 
consequentemente trazendo pontos negativos para a empresa. 
Hoje em dia não é mais permitido entregar produtos com baixa qualidade e 
corrigir erros e falhas após o produto ser fornecido ao cliente, quanto mais tarde os 
erros são encontrados, mais cara e a correção do produto. SOMMERVILLE (2003)12 
constata que: 
Atingir um alto nível de qualidade de produto e serviço é o objetivo da 
maioria das organizações desenvolvedoras. Atualmente não e mais 
aceitável entregar produtos com baixa qualidade e reparar os 
problemas e as deficiências depois que os produtos foram entregue. 
A esse respeito, o software é igual a qualquer outro produto 
manufaturado, como carros, televisão e computadores. 
 
 
10
 PRESSMAN, 1995, p.724. 
11
 RODRIGUES, 2008, p.10. 
12
 SOMMERVILLE, 2003, p.458. 
18 
 
 
 
É necessário tomar precauções para que ao construir o produto sejam 
estabelecidos testes, práticas e procedimentos, visando assegurar que o perfil do 
produto seja de total qualidade e aceito pelo o cliente. 
 Diante disso SOMMERVILLE (2003)13 afirma que é da responsabilidade dos 
gerentes em uma organização assegurar que o grau de qualidade do software seja 
alcançado. Eles precisam elaborar, programar e conferir os trabalhos para garantir 
que estejam sendo desenvolvidos conforme os critérios requeridos. 
Uma forma de validar a qualidade no processo de desenvolvimento é a 
conquista do certificado de qualidade. Certificações de qualidade são concedidas 
por organizações respeitadas no mercado e representa um grande diferencial para a 
empresa certificada dado o alto crescimento da concorrência no setor. 
 Organizações que desenvolvem software de boa qualidade podem quase 
sempre oferecer um melhor produto a um preço mais elevado, devido ao 
investimento e as revisões feitas durante o processo de desenvolvimento. A 
melhoria dos processos de software é de suma importância para que erros sejam 
evitados, assim melhorando a qualidade dos produtos. Diante disso, é necessária a 
implantação de processos bem estabelecidos e seguidos por modelos de melhorias. 
HIRAMA (2012)14 acrescenta que para garantir a qualidade de um software, 
são necessário técnicas como verificação, validação, gerenciamento de 
configuração e qualidade. 
 Para essas afirmações pode-se observar que a qualidade é um arranjo de 
fatores que altera de acordo com aplicações e requisitos de clientes. Um produto de 
software com boa qualidade pode garantir uma segurança na rede, disponibilidade 
nos serviços, grande rendimento e satisfação e confiança dos clientes. 
 
2.1 SQA (Garantia da qualidade de Software) 
Um dos problemas encontrados durante o desenvolvimento do software são 
as revisões dos serviços. Encontrar pessoas experientes e comprometidas com o 
projeto é uma tarefa muito difícil. Os gerentes do projeto querem os melhores 
programadores para desenvolver seusprodutos, diante disso surgiu o SQA. 
 
13
 SOMMERVILLE, 2003, p.458. 
14
 HIRAMA, 2012, p.3. 
19 
 
 
 
Garantia de qualidade de software ou Software Quality Assurance (SQA), é 
um grupo formado por diferentes atividades e ações que objetivam qualidade no 
desenvolvimento do software. O SQA integra todo o processo de desenvolvimento 
do software, verificando se os padrões e processos estão seguidos corretamente, 
assim prevenindo que nenhum erro seja encontrado no final do projeto. 
Segundo PRESSMAN (1995)15 o grupo SQA atua como um representante do 
cliente. Isto é, os envolvidos no grupo observam o software sobre o mesmo ponto de 
vista do cliente. 
Existem algumas vantagens que um processo de software garante ao ser 
implantado por um grupo SQA: 
 Melhoria na qualidade do processo. 
 Remoção de defeitos no processo. 
 Uma criação de um banco de dados com técnicas como: revisão, 
medição, auditorias e fatores de qualidade, etc. 
 Monitoração e melhora de todo o processo em ação. 
 Atividades de melhoria desde o inicio do projeto do software. 
 
Conforme PRESSMAN (1995)16 o SQA integra um conjunto de tarefas 
relacionadas a sete atividades: aplicação de métodos técnicos, revisões técnicas 
formais, afazeres de teste, aplicação de padrões, domínio de mudanças, medições e 
manutenção de documento e reportagem. Todas as atividades são ações que 
acontecem no decorrer do software, podendo ser representada por um conjunto de 
alteração de um serviço pra outro, combinação de dados ou modificação de 
localização. Com isso, o SQA estabelece métodos, técnicas e ferramentas que 
ajudam os programadores a desenvolver um software de total qualidade. Sendo 
assim, a principal função de um SQA, é averiguar se estão usando os métodos e 
padrões conforme os conhecimentos requeridos. 
PRESSMAN (1995)17 afirma “se existirem padrões formais (escritos), uma 
atividade SQA deve ser estabelecida para garantir que eles sejam seguidos”. 
 
15
 PRESSSMAN, 1995, p.734. 
16
 ibidem, idem, p.734. 
17
 ibidem, idem, p.734. 
20 
 
 
 
Os padrões são incluídos nos procedimentos ou aplicados durante o processo 
de desenvolvimento. Conforme SOMMERVILLE (2003)18 existem dois tipos de 
padrões que englobam o processo de garantia de qualidade de software: 
1- Padrões de produto: São padrões que se aplicam ao produto 
de software em desenvolvimento. Eles incluem padrões de 
documentos, como a estrutura de requisitos a ser 
desenvolvido de requisitos a ser produzido; padrões de 
documentação, como um cabeçalho-padrão de comentário 
para uma definição de classe de objeto, e padrões de 
codificação, que definem como uma linguagem de 
programação deve ser utilizada. 
 
2- Padrões de processo: São padrões que definem os processos 
a serem seguidos durante o desenvolvimento de software. 
Eles podem incluir definições de especificação, processos de 
projeto e validação, e uma descrição dos documentos que 
devem ser gerados no curso desses processos. 
Os padrões concedem uma estrutura em torno do qual o processo de garantia 
de qualidade pode ser implantado. Eles ajudam em termo de continuidade, quando 
um projeto é começado por uma pessoa e assumido e seguido por outra. Eles 
abrangem as melhores práticas de controle de qualidade, que simplesmente 
assegura a capacidade e valor no produto de software da organização. Segundo os 
autores PRESSMAN e MAXIM (2016)19, os padrões do CMMI e ISSO 9000, são os 
mais usados. Cada um propõe uma sintaxe e uma semântica, que leva as práticas 
de engenharia de software que melhoram a qualidade do produto. 
Por fim, todas as etapas do software devem ser agregadas com atividades 
que propõe atingir qualidade dos requisitos, qualidade do projeto, qualidade do 
código e eficácia do controle de qualidade. 
2.2 SEPG (Software Engineering Process Group) 
O SEPG (Software Engineering Process Group) estabelece um grupo que 
planeja e acompanha todas as tarefas do projeto de melhoria de capacidade, com 
apoio da alta administração. Esses indivíduos são responsáveis por garantir que 
todo o processo de implantação do modelo flua de maneira adequada, envolvendo 
as pessoas para o entendimento dos benefícios de trabalhar com qualidade, 
alocando os recursos necessários para a melhoria dos processos. Eles realizam 
 
18
 SOMMERVILLE, 2003, p.460-461. 
19
 PRESSMAN e MAXIM, 2016, p.452. 
21 
 
 
 
avaliações da capacidade, desenvolvem planos para implementar melhorias 
necessárias, coordenam a implementação desses planos e medem a eficácia 
desses esforços. 
O grupo de processos de engenharia de software é uma força central para a 
melhoria de processos. O grupo mantém a visão geral dos esforços atuais e 
geralmente se concentra na definição de prioridade, aprovação, desenvolvimento, 
implantação e acompanhamento do conjunto de técnicas e processos utilizados pela 
organização. 
Os membros do SEPG são desenvolvedores de software e têm o seu 
comprometimento assegurado através de autorização do gerente responsável, que 
aloca no mínimo 2 horas semanal para o trabalho com processo. Os membros 
promovem a colaboração entre todos na organização que estejam envolvidos com a 
melhoria do processo. 
O SEPG é envolvido com algumas atividades de melhoria de processos 
CMMI, tais como: 
 
 Planejamento das atividades de melhoria de processos. 
 Desenvolvimento e valorização do SGQ (Sistema de gestão da 
qualidade). 
 Avaliação e sugestões de melhoria de processo da organização ou das 
entidades externas. 
 Preparação e atualização do tamanho e equipe de projeto. 
 O grupo estabelece metas organizacionais de qualidade. 
 Facilita a criação e manutenção de definições de processo, em 
colaboração com os gerentes e pessoal de engenharia. 
 Mantém um banco de dados processo. 
 
O grupo SEPG tem enfoque de atuação em organizar treinamentos, 
acompanhar, monitorar e relatar esforços de melhoria de processos. Todos os 
métodos devem estar definidos na organização, e deve ser monitorado, gerenciado 
e atualizado pela alta direção. 
 
 
22 
 
 
 
Dentre suas principais funções e atividades, podem-se destacar: 
 
 Fornecer orientação para uso de dados históricos 
 Identificação de um conjunto de padrão de produtos de trabalho de 
software das áreas envolvidas. 
 Medir, informar e divulgar as atividades de desenvolvimento e de 
melhoria de processo de software no âmbito da organização. 
 
Em resumo, o SEPG contribui para varias funções e atuações e mantém e 
favorece todo controle das melhores ações de melhoria das áreas envolvidas. 
 
3 MODELOS DE MATURIDADE 
Devido ao insucesso dos projetos, as organizações desenvolvedoras vêm 
originando procedimentos, ferramentas e paradigmas para garantir a melhoria da 
qualidade nos processos organizacionais. Os paradigmas são utilizados para 
habilitar a capacidade dos processos, localizar oportunidades de melhoria de 
produtividade e monitorar as ações de qualidade e redução de custo. 
Um processo de desenvolvimento de software envolve um conjunto de 
atividades, práticas e métodos que uma equipe utiliza para manter o software e 
produtos associados. O grau de maturidade e adquirido quando uma empresa utiliza 
as metodologias de processos nos modelos implantados. Esses modelos fornecem 
um framework de soluções para analise, definição, implantação e melhoria de 
processos. 
Segundo a Associação para Promoção da Excelência do Software Brasileiro – 
SOFTEX (2012)20, para produzir um softwareconcorrido a nível nacional e 
internacional, é importante que as organizações coloquem competência nos seus 
processos e um grupo de qualidade que tomem decisões estratégicas conforme os 
padrões de qualidade internacional. A melhoria nos processos fornece a 
organização uma mudança no modo de desenvolvimento conforme o mundo em 
grande concorrência. 
 
20
 SOFLEX, 2012, p.6. 
23 
 
 
 
São feitas avaliações de qualidade como forma de aprimorar os processos, 
avaliando a qualidade do produto e a aquisição para escolha de software de melhor 
qualidade. 
A avaliação de verificação envolve: 
Capacidade: Uma avaliação feita para analisar a capacidade de um 
processo, comparando a qualidade de uso com as exigências do produto. Permite 
determinar resultado para os futuros projetos. 
Desempenho: Avaliação feita para analisar o desempenho do processo de 
acordo com o tempo de uso. 
Maturidade: Uma avaliação feita para testar a qualidade de crescimento de 
um processo, avaliando o mesmo para verificar se está de acordo com os objetivos 
da organização. 
Em uma organização, os modelos de maturidade e capacidade medem a 
habilidade técnica, gerencial e a competência que a organização possui em 
desenvolver software de boa qualidade, dentro do prazo e custos razoáveis (FILHO, 
2000)21. A identificação de um modelo para uma organização se baseia nos 
procedimentos de cada modelo de acordo com os objetivos procurados. 
Com isso, a existência dos modelos é fundamental para organizações 
alcançar um resultado positivo na produção do software. 
 
3.1 CMM (CAPABILITY MATURITY MODEL) 
O CMM trata-se de um modelo de maturidade e capacidade composto por 
elementos básicos de processos para garantia de qualidade, e descreve um 
caminho evolutivo de processos imaturos a processos maduros. Foi desenvolvido 
pelo SEI (Software Engineering Institute)22 da Universidade Carnegie Mellon. A 
principal missão do modelo foi atender o DOD (Departamento de Defesa dos 
Estados Unidos) com ferramentas de capacitação para avaliar seus grandes 
fornecedores. Publicado em 1992, o CMM dispõe das melhores práticas de 
maturidade e capacidade e fornece uma estrutura para a organização estabelecer as 
 
21
 FILHO, 2000, p.22 
22
 Instituto fundado pelo Departamento de defesa dos Estados Unidos, cuja missão é a transferência 
de tecnologia de software (SOMMERVILLE, 2003, p.485). 
24 
 
 
 
preferências de melhorias dentro dos padrões de qualidade (SOMMERVILLE, 
2003)23. 
O modelo CMM pode ser aplicado por dois métodos diferentes: pelos clientes 
para poder identificar o nível de qualidade de seus fornecedores e pelos 
desenvolvedores para analisar a sua capacidade de esclarecer e definir melhorias. 
Através da avaliação da maturidade é possível realizar mudanças, auxiliar o 
gerenciamento e melhorar a qualidade do software (PFLEEGER, 2004)24. 
Nas organizações desenvolvedoras, existe uma grande procura pela 
qualidade e com isso ocorre alto investimento financeiro para melhorar seus 
processos. A implantação do modelo assegura benefícios no desenvolvimento do 
código, controle de prazos, quitação de custos e melhoria de redução de riscos. 
Segundo SCHACH (2010)25, o aperfeiçoamento do processo induz mudanças 
incrementais associado em cinco níveis de maturidade, que vai aumentando 
conforme os processos vão se melhorando em pequenos passos revolucionários, 
garantindo o aumento dos níveis mais alto do modelo. 
 A figura 2 apresenta os níveis oferecidos no modelo CMM, onde os cinco 
níveis estabelecem um conjunto de ações que permitem a empresa subir no 
patamar de melhoria dos processos. 
 
 Figura 2: Modelo de Maturidade de Capacitação do SEI 
 Fonte: SOMMERVILLE, 2003, p.486 
 
 
23
 SOMMERVILLE, 2003, p. 485. 
24
 PFLEEGER, 2004, p.444. 
25
 SCHACH, 2010, p.92. 
25 
 
 
 
Como demonstra a figura 2, o nível mais alto corresponde o maior rendimento 
e qualidade da empresa. Cada nível de maturidade, com exceção do primeiro, 
agrupa um conjunto de áreas-chave de processo, chamados de KPA – Key Process 
Areas. Cada área-chave é baseada em práticas-chave (Key Practices), que são 
incluídas no modelo para alcance de melhorias e metas. Conforme SOMMERVILLE 
(2003)26, a melhoria dos processos deve se apropriar de estabelecer os processos-
chave e não atingir outro nível do modelo. Para que uma organização atinja um nível 
de maturidade satisfatório é necessário seguir as práticas do processo para subir a 
um determinado nível de maturidade. 
 
3.2 CMMI (CAPABILITY MATURITY MODEL INTEGRATION) 
 
Segundo SOMMERVILLE (2003)27, com base na experiência adquirida com o 
modelo CMM, o SEI desenvolveu um novo modelo de maturidade e capacitação 
chamado CMMI. O modelo integra todos os aspectos de processo de software, de 
engenharia de sistemas e definição de produtos. 
O CMMI surgiu como forma de estabelecer diferentes modelos, em um único 
e completo modelo, preservando investimentos, e reduzindo custos de treinamento 
de melhorias. Sua principal qualidade é assegurar a melhoria contínua dos 
processos em duas versões diferentes – contínua e estagiada. 
Dentre dos modelos existentes da SEI, os que mais atribuíram valor são: 
 Software Acquisition CMM (AS-CMM) 
 Systems Enginnering CMM (SE-CMM) 
 Integrated Product Development CMM (IPD-CMM) 
 People CMM (P-CMM) 
O CMMI foi baseado nas melhores práticas para desenvolvimento, aquisição 
e manutenção de softwares, além disso, dispõe de ações apropriadas para todos os 
envolvidos no projeto. A versão atual do modelo é a (versão 1.3) que apresenta três 
atuações: 
 
26
 SOMERVILLE, 2003, p.487. 
27
 ibidem, 2003, p.489. 
26 
 
 
 
 CMMI-ACQ- Voltado para as atividades de aquisição de produtos e prestação 
de serviços. Fornece uma aplicação para atender as necessidades dos 
clientes e usuários finais. 
 CMMI-DEV- Modelo voltado para desenvolver produtos. Contém práticas de 
Gestão de processos, engenharia de sistemas, engenharia de softwares e 
entre outros. 
 CMMI-SVC- Modelo voltado para conferir a qualidade dos processos e 
prestação de serviços. Contém práticas de engenharia de aquisição, gestão 
de processos e serviços. 
 
O CMMI é uma grande ferramenta que fornece estrutura para a motivação, 
reconhecimento, padronização e melhorias. Foi desenvolvido para avaliar a 
capacitação de empresas de grande porte, de longo tempo de duração, com 
complexas interfaces com o hardware e outros sistemas de softwares. O modelo 
mede a maturidade e a capacitação dos processos de acordo com cada nível. À 
medida que o nível evolui, a capacidade de melhorias dos processos é percebida 
pela organização (SOMMERVILLE, 2003)28. 
Segundo HIRAMA (2012)29 “o CMMI tem reconhecimento mundial, e no Brasil 
existem muitas empresas que possuem certificações baseadas nesse modelo”. 
Utilizando-se do modelo CMMI, uma organização observa melhora logo no nível 2, e 
neste que são apresentados práticas em gerenciamento de requisitos e controle do 
progresso do software. No entanto, pode se perceber que nos dias de hoje a 
melhoria de processos com a utilização do CMMI é vista como um diferencial 
competitivo. 
 
a) Objetivos do modelo 
Além de garantir a melhoria nos processos de softwares, o CMMI apresenta 
os seguintes objetivos: 
 Reduzir repetição de processos. 
 Disponibilidade de recursos.28
 SOMMERVILLE, 2003, p.487. 
29
 HIRAMA, 2012, p.4. 
27 
 
 
 
 Aumentar o foco das atividades dentro das organizações. 
 Auxiliar no gerenciamento de mudanças. 
 Associar os processos existentes. 
 Atingir as metas estipuladas pela empresa. 
 Garantir que os processos sejam seguidos conforme a norma ISO 15504. 
 Aumentar a capacitação dos softwares. 
 Assegurar ferramentas de qualidade para o Departamento de Defesa dos 
Estados Unidos. 
 
b) Vantagens do modelo 
 O CMMI é um modelo de certificado internacional e a cada ano vem se 
tornando uma marca de registro no mercado. Empresas como a Microsoft utiliza o 
modelo como forma de obter ganhos, de maneira estratégica para exportações para 
outros países. 
Uma das principais vantagens do modelo CMMI, e a possibilidade de 
monitoramento dos processos, ou seja, a organização consegue controlar seus 
processos, verificar melhorias, e possíveis conclusões sobre o projeto. 
 
c) Desvantagens do modelo 
O modelo possui alto custo com a implantação e manutenção do processo, 
além da demora. Dependendo do nível de complexidade de uma organização, o 
custo visa em torno de duzentos mil reais e leva em média 18 meses a 3 anos. 
Diante disso, SCHACH (2010)30 afirma que uma organização pode levar em média 3 
a 5 anos para elevar o 1º nível para o 2° nível . Ainda segundo o autor, isso é reflexo 
da grande dificuldade que é adicionar uma abordagem metódica em uma 
organização que até então funcionou puramente em termos de medidas relativas e 
sem planejamento. Desse modo, empresas de pequeno porte possuem uma 
dificuldade em adotar o CMMI de acordo com o valor de investimento alto. 
Uma das desvantagens desse modelo é em relação às praticas utilizadas. 
Muitas dessas práticas são utilizadas sem necessidade, principalmente em projetos 
menores, que na maioria dos casos não possuiria custo para a implantação. 
 
30
 SCHACH, 2010, p.94 e 95. 
28 
 
 
 
3.2.1 Representação dos Modelos 
A arquitetura do modelo CMMI pode ser representada por duas diferentes 
versões: estagiada (como o antigo modelo CMM) e contínua (classifica cada área de 
processo segundo a norma ISO/IEC 15504). Estas duas versões proporcionam a 
organização aplicar diversas maneiras para melhoria conforme sua necessidade. 
Os níveis de maturidade estabelecem um meio de indicar a evolução dos 
processos da organização, caracterizando estágios de melhoria conforme a 
qualidade é obtida. “O nível de maturidade em que uma organização se encontra, 
permite prever o seu desempenho futuro ao executar um ou mais processos” 
(SOFLEX, 2012)31. 
3.2.1.1 Representação por Estágio 
 Essa representação se afigura bastante ao CMM com cinco níveis de 
maturidade direcionados aos negócios da organização. 
Na representação em níveis, as práticas são caracterizadas pelos atributos: 
 Compromisso para execução (práticas que garantem que o processo seja 
estabelecido e apoiado); 
 Habilidade para execução (práticas que criam condições para que o processo 
seja estabelecido completamente); 
 Atividade para execução (práticas que implementam diretamente o 
processo), controle e verificação de implementação. 
 
A ordem de melhoria é seguida em dependência aos anteriores, sendo assim, 
o aprimoramento de cada nível serve como base para o outro nível. 
Cada nível de maturidade serve como base para o próximo nível, em uma 
sequência bem detalhada de melhorias de processos, que facilita a comparação de 
processos entre diferentes organizações. A implantação em estágios garante à 
organização um grande investimento financeiro, visando assegurar uma mudança na 
figura organizacional. 
 
31
 SOFLEX, 2012, p.17. 
29 
 
 
 
1- Inicial: A organização não oferece um ambiente para desenvolvimento. 
Esse nível e visto como negativo, pois não imaturidade no setor produtivo. 
2- Gerenciado: Os processos são repedidos conforme os anteriores. São 
empregados nesse nível sete áreas-chave como: controle de requisitos, 
revisões de processos, medição e análises. Os stakeholders32 são 
envolvidos durante o desenvolvimento para melhorar e satisfazer os 
requisitos dos clientes. Conforme PFLEEGER (2004)33, a melhoria dos 
processos gerenciados levam a melhorias dos processos definidos, “em 
que atividades de gerenciamento e de engenharia, são documentadas, 
padronizadas e integradas, o resultado é um processo padrão para todos 
na organização”. 
3- Definido: Os processos são repedidos por todos os projetos de software da 
organização. São empregados nesse nível: ações de integração, 
Validação e Verificação de produto; 
4- Quantitativamente Gerenciado: Nesse nível, a coleta de dados do 
processo é feita de forma quantitativa. São empregados nesse nível duas 
áreas-chave de processo: gerenciamento e desempenho do processo. 
5- Otimizado: Ações de melhoria, com implantações de mudanças no 
processo da organização. Conforme PFLEEGER (2004)34, “o nível mais 
desejado é o otimizado, em que o feedback35 quantitativo é incorporado no 
processo para produzir melhorias contínuas no processo [...]”. 
A razão da divisão em estágios, está em possibilitar as organizações 
implementar e avaliar de forma mais apropriada os processos desenvolvidos. A 
facilidade de se efetuar avaliações considerando mais níveis de maturidade, é a 
garantia da transparência qualidade dos processos em tempos mais curtos. 
Uma empresa no primeiro nível, não dá garantia de prazo, custo ou 
funcionalidade. No segundo nível, a empresa já consegue produzir bons softwares, 
com custo previsível e prazo estimado. No terceiro, a empresa já garante um 
excelente nível de qualidade, tanto no produto quanto no processo de 
 
32
 Conjunto de pessoas que de alguma influencia no sucesso do projeto. 
33
 PFLEEGER, 2004, p.446. 
34
 Ibidem, 2004, p.446. 
35
 Resultados baseados em números. 
30 
 
 
 
desenvolvimento como um todo. Atualmente, no mundo, não há muitas empresas 
que tenham chegado aos níveis 4 e 5. 
A estrutura do modelo CMMI representação por estágio é apresentado na 
figura abaixo: 
 
 
 Figura 3: Estrutura de representação por estágio 
 Fonte: O autor 
 
Como ilustrado na figura 3, os níveis maturidade organizam as áreas de 
processo. Dentro das áreas de processo existem objetos genéricos e específicos, 
assim como praticas genéricas e especificas. 
Essa representação foca as melhores práticas que a organização poderá 
utilizar, para melhorar os processos das áreas de processo que se encontram no 
nível de maturidade, escolhido para alcançar. 
3.2.1.2 Representação contínua 
 
Define uma sequência de melhorias para atender os objetivos de negócio da 
organização, podendo classificar a capacidade a cada nível de processo. O perfil da 
capacidade dos processos é seguido por cada nível – Capability Levels. 
Com isso, uma organização pode trabalhar em outras áreas de atuação de 
acordo com sua estratégia de negócio. 
A estrutura do modelo CMMI representação contínua é representada na figura 
abaixo: 
31 
 
 
 
 
 Figura 4: Estrutura de representação contínua 
 Fonte: O autor 
 
Como ilustrado na figura 4, os objetivos específicos organizam praticas 
especificas e os objetivos genéricos organizam praticas genéricas. Cada pratica 
especifica e genérica corresponde a um nível de capacidade. O nível 1 tem a ver 
com a implementação dos objetivos e práticas especificas da área de processo em 
trabalho. Os objetivose as praticas especificas aplicam-se individualmente as áreas 
de processo, enquanto, os objetivos e as praticas genéricas se aplicam a todas as 
áreas de processo em análise. 
Os objetivos e as praticas genéricas definem a sequencia dos níveis de 
capacidade que representam melhorias na implementação e efetividade de todos os 
processos que foram escolhidos para melhoria. 
Essa representação apresenta 25 áreas de processos, que são inseridas em 
4 grupos distintos, que são estabelecidos em seis níveis de capacidade e são 
medidos pelo atendimento de metas específicas e genéricas: 
0- Incompleto - Ad-hoc36: Processo não executado ou realizado. 
1- Executado: O projeto é planejado e executado de acordo com cada projeto. 
Engloba ações de inovação, desempenho e treinamento da organização. 
2- Gerenciado: A área de processo é executada de acordo com as metas 
especificas. Envolve ferramentas, métodos e procedimentos. São incluídas 
ações de planejamento, monitoração e gerenciamento do projeto. 
3- Definido: O processo fornece informações de melhoria, de acordo com o 
processo padrão da organização. 
 
36
 Processo de software em construção. 
32 
 
 
 
4- Gerenciado quantitativamente37: Os processos são baseados em 
indicadores e outros métodos quantitativos. 
5- Otimizado: Adaptado para atender os objetivos atuais de negócios. O foco 
nesse nível e a melhoria dos processos, com ações baseadas em métricas e 
ferramentas inovadoras. 
O modelo de representação contínua é indicado, quando se deseja 
comparação com processos de outras organizações assegurando máxima 
flexibilidade e processos mais maduros. Através do nível de maturidade, as 
empresas garantem certificação e reconhecimento de maturidade a nível 
internacional. 
O modelo de maturidade é uma importante contribuição, mais não deve ser 
tomado como um modelo definitivo para capacitação de todos os processos. Esse 
modelo foi desenvolvido para capacitar os processos de empresas que desenvolvem 
software de defesa. O modelo vem se transformando em um padrão mundial para 
avaliação de melhoria de processos e se tornando uma grande ferramenta de 
competitividade entre diferentes organizações (SOMMERVILLE, 2003)38. 
3.2.2 Áreas-chave de processo (Key Process Areas ou KPAs) 
Os níveis de maturidade segue um estágio de melhoria nos processos, ou 
seja, a partir de um caminho evolutivo a qualidade nos processos organizacionais e 
alcançada. Todo nível de maturidade é formado por um conjunto de áreas de 
processos onde são explorados os processos essenciais. A capacidade de cada 
processo é interpretada por uma soma de atributos conforme os resultados 
alcançados. 
Cada nível de maturidade, exceto o nível 1, é composto por varias áreas-
chave de processo que instrui quais áreas que uma organização deve focalizar para 
melhorar seu processo de software. 
A tabela abaixo apresenta todas as áreas de processo organizadas nos cinco 
níveis de maturidade e capacidade do CMMI: 
 
 
 
37
 Questionários alternativos com resultados numéricos. 
38
 SOMMERVILLE, 2003, p.487- 490. 
33 
 
 
 
Nível de Maturidade Áreas-Chave de Processo 
1. Nível Inicial: Não contém áreas-chave de processo. 
2. Nível Repetível: 
Gerenciamento de 
projeto básico 
Gerenciamento das necessidades, Gerenciamento de 
projeto de software, Acompanhamento e supervisão de 
projetos de software, Gerenciamento terceirizado de 
software e Garantia de Qualidade de Software (SQA) 
3. Nível Definido: 
Definição de 
processos 
Foco nos Processos Organizacionais, Definição dos 
Processos da Organização, Gerenciamento de 
Software Integrado, Engenharia de Projeto de 
Software, Coordenação entre os grupos e Revisões 
pontuais. 
4. Nível Gerenciado: 
Medição de 
processos 
Gerenciamento de processos quantitativos e 
Gerenciamento da qualidade do software. 
5. Nível Otimizado: 
Controle de 
processos 
Prevenção de Defeito, Gerenciamento de Mudança de 
Tecnologia e Gerenciamento de Mudança de 
Processos. 
Tabela 1: Áreas de processo. 
 Fonte: SCHACH, 2010, p.92 
 
Esses cinco níveis de maturidades são sintetizados na tabela 1, apresenta as 
áreas fundamentais associadas a cada nível de maturidade. Todas as áreas de 
processo são comuns nas duas representações do modelo CMMI. Para que uma 
empresa possa qualificar em um determinado nível de maturidade, ela precisa estar 
realizando os processos relacionados às áreas-chave daquele determinado nível. 
A forma de atingir as metas de uma área-chave de processo pode diferir entre 
projetos, de acordo com as diferenças de domínios de aplicação ou de ambientes. 
Todavia, todas as metas de uma área-chave de processo devem ser atingidas para 
que uma organização satisfaça essa área-chave. Quando as metas de uma área-
chave são cumpridas de maneira continuada em um projeto, a organização pode ser 
considerada como tendo institucionalizado a capacidade do processo caracterizada 
por essa área-chave. 
3.2.3 Características Comuns e Práticas-chave 
 
As características comuns são itens a serem observados para que se possa 
verificar a implementação e institucionalização de cada área-chave de processo. 
Elas podem indicar se a área-chave de processo é eficiente, repetível e duradoura. 
34 
 
 
 
Toda área-chave de processo (KPA) é constituída por um grupo de atividades 
relacionadas à área, que quando executadas coletivamente, atingem um conjunto de 
objetivos e metas consideradas importantes para a melhoria significativa do 
processo. Cada área é composta por práticas genéricas e específicas, que são 
essenciais para a implantação do modelo. 
As práticas especificam o que deve ser cumprido, exigindo documentos, 
treinamentos ou políticas definidas para as atividades, mas nunca especificam como 
elas devem ser implementadas. 
No geral, a avaliação oficial do SEI é bastante abrangente, cara, e certamente 
a mais traumática. Por isto dificilmente deve ser utilizada como pontapé inicial da 
implantação do modelo. O primeiro ciclo de análise/planejamento/ação tem algumas 
características especiais. É nele que se cometem mais erros e se criam mais 
soluções. Um método abrangente, mas ao mesmo tempo flexível pode reduzir os 
traumas e liberar a criatividade, e maximizar os resultados obtidos no trabalho. 
 
 3.3 MPS.BR (MELHORIA DO PROCESSO DE SOFTWARE) 
Conforme o guia SOFTEX (2012)39, o MPS. BR é um modelo direcionado 
para o ramo de qualidade de software, coordenado pela Associação para Promoção 
da Excelência do Software Brasileiro – SOFTEX, iniciado em dezembro de 2003. 
O modelo foi desenvolvido com intuito de diminuir o retrabalho, atender as 
necessidades de negócio e para garantir a qualidade nos processos de software das 
pequenas e médias empresas Brasileiras. Uma de suas características é poder 
disponibilizar mais níveis de maturidade para as organizações, e seu valor de 
certificação se comparado a outros modelos de qualidade. Isto se justifica, devido 
ao custo financeiro que o CMMI exerce o que torna o modelo mais indicado às 
grandes organizações. 
O apoio técnico para a o desenvolvimento do MPS. BR foi descrito segundo 
as normas ISO/IEC 12207 e ISO/IEC 15504, e o modelo CMMI. Dessa forma, todos 
os processos em desenvolvimento serão seguidos conforme as normas. 
O MPS. BR baseia-se nos conceitos de maturidade e capacidade de processo 
para avaliação e melhoria de produtividade de software. 
 
39
 SOFLEX, 2012, p. 4. 
35 
 
 
 
Dentrodesse contexto, atualmente o modelo está dividido em cinco 
elementos: 
 (MR-MPS-SW) - Modelo de referência MPS para melhoria de processo de 
software. 
 (MR-MPS-SV) - Modelo de referência MPS para serviços. 
 (MA-MPS) - Método de avaliação de requisitos para melhoria do modelo. 
 (MRMPS-RH) - Modelo de referência MPS para gestão de pessoas. 
 (MN-MPS) - Modelo com regras de negócios, para atender as empresas de 
grande porte40. 
Todos esses modelos são divididos em níveis de maturidade garantem 
capacidade nos processos organizacionais. 
3.3.1 Níveis de Maturidade 
O modelo é dividido por uma representação por estágio, em sete níveis 
maturidade, que visa analise sobre as pequenas empresas, bem como melhorias 
nos processos organizacionais. 
 A - Em Otimização 
 B - Gerenciado Quantitativamente 
 C - Definido 
 D - Largamente Definido 
 E - Parcialmente Definido 
 F – Gerenciado 
 G - Parcialmente Gerenciado 
A sequência começa no nível G de pior qualidade e finaliza no nível A, onde 
se obtém a melhor qualidade no processo. 
Para cada um desses níveis é atribuído um conjunto de processos que 
indicam onde a organização deve colocar total empenho de melhoria. O crescimento 
de cada nível no modelo MPS se obtêm, quando são atendidos os objetivos dos 
processos e dos atributos de processo estabelecidos para um determinado nível. 
Os modelos CMMI e MPS.BR possui diversos aspectos em comum durante 
as fases de implantação, porem o foco de atuação dos modelos são diferentes um 
 
40
 SOFLEX, 2012, p.6. 
36 
 
 
 
do outro. O MPS.BR foi criado em função das pequenas empresas, já o CMMI tem o 
foco as empresas de grande porte. 
Contudo, apesar das diferenças, ambos requerem que procedimentos da 
parte alta das empresas, alem de que as organizações precisam estar dispostas a 
investir tempo, dinheiro e infra-estrutura para melhorias dos produtos e serviços. 
Para alcance das metas e necessário um treinamento para os profissionais, e 
reformulação e adequação as mudanças conforme os processos internos e 
externos. 
As médias e pequenas empresas adotam o MPS.BR com o objetivo de 
conseguir alcançar uma padronização e qualidade no processo com mais velocidade 
e de baixo custo. 
No geral, os modelos de melhoria de processo de software, atende as 
necessidades das organizações com modelos baseados em níveis de habilidade e 
capacidade, visando alcançar os objetivos atuais e futuros. A representação por 
estágios fornece melhorias de processos baseando-se em um roteiro por vez. Nesse 
sentido, o uso de modelos ajuda o processo de construção de softwares garantindo 
a qualidade no produto e no serviço. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
37 
 
 
 
CAPÍTULO 4 – APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE 
CASO COM MODELO CMMI 
 
4.1 Tipo de pesquisa 
Nessa parte, será apresentado o estudo de caso e as principais atividades 
que foram utilizadas para conseguir reunir todos os dados obtidos no questionário. 
Do ponto de vista da forma de abordagem, o método de pesquisa 
denominado nesse trabalho, e visto como pesquisa qualitativa, pois as dificuldades 
apresentada pelas empresas de aplicação da qualidade em seus processos não 
pode ser descrita em números, por ser de caráter descritivo (problema não é 
quantificado, mas definido). 
4.2 Processos metodológicos 
 A pesquisa foi realiza nos meses de Novembro e Dezembro de 2016. 
Foi elaborado um questionário com perguntas que apresentavam a finalidade 
de identificar os resultados esperados na melhoria do processo de acordo com o 
modelo CMMI, conforme (Anexo A). O questionário foi formado de acordo com 
dados obtidos em links que abordam o tema e monografias que já foram publicadas. 
Com base nesses dados, foi possível comparar as opiniões que as empresas 
apresentam em relação ao modelo. O questionário de maturidade não foi projetado 
para ser usado para ser usado como instrumento de avaliação para conhecimento 
da organização alvo. 
A primeira pergunta do questionário visou identificar dados sobre o 
entrevistado e a empresa que ele atua. Em seguida, dados sobre quantidade de 
funcionários dentro da empresa. 
Conforme as perguntas o entrevistado poderia obter um melhor entendimento 
em relação ao modelo, pois 3 perguntas avaliava a importância do modelo na 
melhoria dos processos de software. 
Para realizar o estudo proposto foram acompanhados e investigados os 
seguintes procedimentos: 
 - realização de diagnóstico da empresa para a elaboração do planejamento 
das atividades e identificação do estado atual da empresa. 
38 
 
 
 
 - elaboração de um Plano de Ação, onde foram descritas as atividades para a 
execução do projeto, a estimativa de duração e um cronograma. 
- O questionário foi encaminhado aos responsáveis nas empresas pelo setor 
de Engenharia e Gerência de Software e de Qualidade. 
- Para desenvolvimento do instrumento de coleta e da coleta de dados usou-
se uma ferramenta web gratuita de formulários disponibilizada pela organização 
Google. 
 
4.3 Etapas do questionário 
De acordo com os dados coletados foram gerados gráficos para melhor 
exposição da pesquisa, sendo que o questionário começa perguntando dados como 
nome, email e nome da empresa do entrevistado. 
Em relação ao tamanho da empresa, 75% dos entrevistados disseram que a 
empresa possui pequeno porte, enquanto 25% assinalaram que a empresa e de 
médio porte, conforme Figura 5. 
 
 Figura 5: Pergunta número 04 do questionário ao usuário 
Fonte: O autor. 
 
 Como mostra a Figura 5, no total de quatro empresas pesquisadas, três são 
de pequeno porte. 
Em relação ao tempo de existência da empresa: 
 50% dos usuários disseram que a empresa possui menos de 5 anos de 
existência. 25% opinaram que a empresa possui entre 5 a 10 anos e outros 25% 
disseram maior que 10 anos, como demonstrado da Figura 6. 
39 
 
 
 
 
 
 Figura 6: Pergunta número 05 do questionário ao usuário 
Fonte: O autor. 
 
Levando em consideração ao número de clientes: 
Devido à forte presença de clientes, 50% disseram entre 100 a 300, enquanto 
houve um empate entre menor que 100 e 50 a 100, de acordo com a Figura 7. 
 
 Figura 7: Pergunta número 06 do questionário ao usuário 
Fonte: O autor. 
 
 Levando em consideração a posição do cargo do entrevistado: 
70% disseram que não trabalham em nenhum dos cargos informados no 
questionário e outros 25% disseram desenvolvedor ou analista de suporte, conforme 
Figura 8. 
40 
 
 
 
 
Figura 8: Pergunta número 07 do questionário ao usuário 
Fonte: O autor. 
 
Em relação ao relacionamento do entrevistado aos membros da empresa: 
75% dos usuários entrevistados acreditam que o relacionamento com os 
membros é bom, enquanto os 25% considera regular, como amostrado na Figura 9. 
 
Figura 9: Pergunta número 08 do questionário ao usuário 
Fonte: O autor 
 
A empresa já adotou algum modelo ou padrão de qualidade? 
Quanto ao modelo de melhoria de processos, 75% dos entrevistados 
alegaram que as empresas não adotam nenhum e 25% disseram que sim, como 
demonstrado na Figura 10. 
 
41 
 
 
 
 
Figura 10: Pergunta número 09 do questionário ao usuário 
Fonte: O autor. 
 
 Em relação ao CMMI: 
 Foi questionado aos usuários se havia interesse pelas empresas em adotar o 
modelo CMMI futuramente, e 50% alegaram que sim, e 50% não possuam interesse, 
como apresentado na Figura 11. 
 
 
Figura 11: Pergunta número 10 do questionário ao usuário 
 Fonte: O autor.Em relação aos benefícios com a implantação do CMMI: 
Ao questionar a respeito do modelo CMMI, e as benefícios que se esperam 
em optar em implantar um modelo de melhoria nos processos organizacionais, 50% 
disseram que esperam por todas as opções, 25% afirmaram integração de sistemas 
e 25% projetos dentro do prazo, conforme apresentado na Figura 12. 
 
42 
 
 
 
 
Figura 12: Pergunta número 11 do questionário ao usuário 
Fonte: O autor. 
 
 
Em relação aos desempenhos esperados pelo modelo CMMI: 
75% dos entrevistados disseram que o modelo é muito importante, pois seu 
reconhecimento é reconhecido internacionalmente e outros 25% disseram que 
baixa, pois o principal objetivo é apenas a melhoria dos processos, apresentado no 
gráfico da Figura 13. 
 
 Figura 13: Pergunta número 12 do questionário ao usuário 
Fonte: O autor. 
 
 
 
43 
 
 
 
4.4 Elaboração do plano de ação 
Com base nos resultados encontrados no questionário e visando uma melhor 
condução das atividades relacionadas ao modelo CMMI, foi elaborado um plano de 
ação, ou seja, uma estratégia, para preparar a organização. 
O plano de ação identifica quais as ações específicas e os recursos 
necessários para a implantação das melhorias do processo de software. 
Geralmente, é incluída na definição do escopo, dando inicio a documentação do 
software. 
Foram identificados os seguintes problemas: 
 Falta de comunicação entre os membros da equipe; 
 Resistência à mudança na cultura organizacional da empresa; 
 Procedimentos e práticas que ainda não eram documentadas; 
 Falta de conhecimento em relação ao modelo CMMI. 
Para melhor alcançar sucesso no plano, é preciso boas políticas e 
procedimentos. A organização deve estar segura dos benefícios esperados com o 
modelo, especialmente no inicio devido aos custos. 
O problema é encontrar técnicas e métodos de acordo com os níveis de 
maturidade dos processos, diferente expectativa da gerencia e treinamento. 
4.5 Soluções encontradas 
 Para melhor solucionar os problemas em adequação ao modelo nas 
organizações, seria importante a colaboração das empresas em contratar uma 
equipe adequada, como SEPG, para garantir o controle nos processos de software e 
reestruturar as equipes em busca de melhor formação. 
 É necessário garantir integração aos procedimentos. Um dos defeitos de se 
possuir diversas iniciativas de melhoria e a geração de um conjunto de 
procedimentos incompatíveis. 
 Outras soluções encontradas: 
 Programas de medição; 
 Programas de treinamentos. 
 
44 
 
 
 
4.6 Resultados esperados com a Implantação do CMMI 
 Existe a necessidade de modelar um plano de melhoria de qualidade de 
processo de desenvolvimento de software. Dentre os planos existentes, foi escolhido 
o CMMI por se tratar de um dos melhores modelos do mercado. 
 Segundo PRESSMAN (1995)41, o software tornou-se elemento chave de 
evolução, mais durante as ultimas quatro décadas, com a história da ‘programação’, 
criaram um conjunto de problemas que persistem ate os dias de hoje. 
A falta de definição de seus processos de desenvolvimento de software, e 
também a falta de uso de uma padronização de documentação e metodologia de 
controle, ocasionou um quadro considerado preocupante: 
 
 Aumento na manutenção de projetos finalizados; 
 Novos projetos entravam em produção sem nenhum controle do escopo; 
 Dificuldade no cumprimento de contratos com os clientes, devido aos 
contratos serem mal definidos; 
 Dificuldade em realizar orçamento de novos; 
 Projetos, devido à grande variação de custos; 
 Dificuldade na definição e cumprimento de cronogramas; 
 Dificuldade em controlar versões de sistemas e manter versões estáveis; 
 Mudanças nos requisitos sem controle e gerenciamento; 
 Falta de padronização e organização dos documentos. 
A análise realizada nos processos existentes nas empresas, comparando com 
os padrões de desenvolvimento propostos pelo modelo internacional CMMI, poderá 
contribuir para a tomada de decisão, no que diz respeito à implantação completa do 
projeto de melhoria de processos de software na empresa. 
Segundo todo o estudo realizado e com base no ROI (Return on Investiment – 
Retorno de Investimento), foi utilizado uma comparação usando um percentual, 
dando inicio as iniciativas do modelo de melhorias de processos CMMI. 
Segue os dados na tabela abaixo: 
 
41
 PRESSMAN, 1995, 48. 
45 
 
 
 
Desempenho Média de melhoria 
Custo 34% 
Cronograma 50% 
Produtividade 61% 
Qualidade 48% 
Satisfação 14% 
ROI 4,0 :1 
 
 Tabela 2: Resultados do desempenho CMMI 
 Fonte: O autor 
 
Estes questionamentos buscam compreender quais dados precisos sobre a 
implantação do modelo utilizado pelas empresas. Foi gerada uma tabela exposição 
dos resultados. 
Segundo os dados, uma organização apresenta 61% de produtividade nos 
seus processos, e dependendo do nível financeiro da empresa, uma empresa faz 
um investimento de 34% com a espera de receber 40% em cima do valor investido. 
Com isso, pode-se concretizar que o intuito do modelo, e ajudar em todas as 
decisões das empresas, com garantia de um retornou percentual ao que foi 
investido, e que se espera para os próximos anos muitas organizações com 
certificação do modelo pelo o Brasil. 
 
 
 
 
 
 
 
 
 
 
46 
 
 
 
CONSIDERAÇÕES FINAIS 
 
A qualidade é a principal finalidade das empresas desenvolvedoras de 
software nos dias de hoje. A maturidade é uma meta que só é atingida de forma 
sucessiva e pode significar também, que a organização está perfeitamente bem para 
gerenciar seus projetos, isto é, fazê-la de forma regulamentada. 
Essa dissertação visou uma pesquisa das diferentes metodologias existentes 
na área de qualidade dos processos de desenvolvimento de software. Com isso, foi 
realizada uma análise das empresas através de um questionário para saber sobre o 
posicionamento dentro das empresas, para que então, fosse possível descobrir suas 
principais características, como visão estratégica e atividades importantes. Diante 
disso, iniciou-se uma avaliação das empresas, o que permitiu um diagnóstico sobre 
a situação gradativa, o que serviu como base para elaboração do plano proposto. 
Particularmente para empresas onde o produto principal e o desenvolvimento 
de software seriam necessários à implantação do CMMI, e o conhecimento sobre o 
modelo. A não aplicação torna-se uma limitação para o resultado deste trabalho, 
pois não é possível afirmar a sua aplicabilidade. 
Apesar da dificuldade de se obter um numero maior de empresas, pode se ter 
mostrado um método mais formal, tirando a conclusão sobre a qualidade e a 
necessidade das mesmas. 
Contudo, a presente dissertação pretendeu dar a conhecer de uma forma 
detalhada e especifica as características, e os principais benefícios e limitações que 
esse modelo CMMI oferece, para as soluções dos objetivos da empresa. 
 A produção deste trabalho pôde proporcionar o conhecimento da prática do 
modelo. As empresas, no geral, demonstram bastante interesse em qualidade de 
processos de software para garantir concorrência no mercado e mostram-se 
dedicadas de alguma forma na busca de uma certificação em qualidade. Umas das 
grandes dificuldades constatadas destas organizações são de como implantar certos 
quesitos de qualidade e adaptá-los a sua empresa 
Pode-se concluir que os modelos de qualidade propõem as melhores ações 
de garantia de qualidade, e que através douso as organizações desenvolvem os 
melhores processos a fim de atingir um melhor produto do mercado. 
47 
 
 
 
REFERÊNCIAS 
 
CAMPOS, Fábio Martinho. Qualidade, qualidade de software e garantia da 
qualidade de software são as mesmas coisas? 2013. Disponível em: < 
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-
garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx > Acesso em: 21 
Nov. 2016. 
 
FERNANDES, Ana Carla, VALLS, Carmem, SAVOINE, Márcia Maria. Análise da 
qualidade de software utilizando as normas 12207,15504, ISO 9000-3 e os 
modelos CMM/CMMI e MPS.BR. Revista Científica do ITPAC. Araguaína, v.4, n º 4, 
Pub 5, Outubro de 2011. Disponível em < 
http://www.itpac.br/arquivos/Revista/44/5.pdf>. Acesso em: 15 Nov. 2016. 
 
FILHO, Wilson de Pádua Paula. Manual do Engenheiro de software. Belo 
Horizonte: UFMG, 2000. Disponível em: < 
https://pt.scribd.com/doc/7570545/MAnualEngSW > Acesso em: 24 Nov. 2016. 
 
FRANCISCANI, Juliana de Fátima. PESTILI, Ligia Cristina. CMMI e MPS.BR: Um 
Estudo Comparativo CMMI and MPS.BR: A Comparative Study. Unicerp. 
Patrocínio, MG. Disponível em: < 
http://www.unicerp.edu.br/images/revistascientificas/3%20-
%20CMMI%20e%20MPS.BR%20Um%20Estudo%20Comparativo1.pdf > Acesso 
em: 28 Set. 2016. 
 
HIRAMA, Kechi. Engenharia de Software. Rio de Janeiro: Elsevler Editora Ltda, 
2012.p.232. Disponível em: < 
https://books.google.com.br/books?id=tYhQYH2yiiYC&printsec=frontcover&dq#v=on
epage&q&f=false> Acesso em: 24 Nov. 2016. 
48 
 
 
 
JANUZZI, Glauter. Metodologia da Qualidade em TI. 2007. Disponível em:< 
http://imasters.com.br/artigo/5269/ > Acesso em: 10 Nov. 2016. 
 
NUNES, Breno O. CMMI – Representação Contínua - Níveis de Capacidade. 2013. 
Disponível em: < http://tiinteligente.blogspot.com.br/2013/05/cmmi-representacao-
continua-niveis-de.html > Acesso em: 10 Nov. 2016. 
 
PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2. ed. São 
Paulo: Prentice Hall, 2004.p.560. 
 
PRESSMAN, Roger S. Engenharia de software. 5 ed. São Paulo: Editora Makron 
Books, 1995.p.1056. 
 
PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de software. Uma 
abordagem profissional. 8 ed. São Paulo: AMGH Editora Ltda, 2016.p.16. 
 
RODRIGUES, Ana N; MOURA, Mirtes; RODRIGUES, Paula; SANTOS, Vanusa. 
Qualidade de Software. Disponível em: < http://www.devmedia.com.br/qualidade-
de-software-parte-01/9408 > Acesso em: 29 Out. 2016. 
 
RODRIGUES, Edson Junior Lobo. Curso de Engenharia de Software. São Paulo: 
Universo dos Livros Editora Ltda, 2008.p.111. Disponível em: < 
https://books.google.com.br/books?id=ZJznA9UrtVAC&printsec=frontcover&d#v=one
page&q&f=false > Acesso em: 04 mai. 2016. 
 
SALVI, WAGNER. CMMI – Áreas de processo. Blog tecnologia da informação. 
2012. Disponível em: < http://www.wagnersalvi.com.br/index.php/cmmi-areas-de-
processos/ > Acesso em: 04 Out. 2016. 
49 
 
 
 
 
SIMPROS. Tutorial SEPG Software Engineering Process Group. 2003. 
Disponível em < http://asrconsultoria.com.br/wp-
content/uploads/2016/04/Tutorial_SEPG_ASR_2slides.pdf > Acesso em: 01 Dez. 
2016. 
 
SCHACH, Stephen R. Os Paradigmas Clássico e Orientado a Objetos. São 
Paulo: AMGH Editora Ltda, 2010. P.92. Disponível em: < 
https://books.google.com.br/books?id=Mkk7MriAp_wC&pg=PA92&lpg=PA92&dq=mo
delos+de+maturidade+e+capacidade&source=bl&ots=q3W6O8BYs-
&sig=vbE5mQhezEBidop7YaOVsPfpwjM&hl=pt-BR&sa=X&ved=0ahUKEwj8p-
iLm7nMAhUFkZAKHbaTAqo4ChDoAQhOMAk#v=onepage&q=modelos%20de%20m
aturidade%20e%20capacidade&f=false> Acesso em: 19 Out. 2016. 
 
SILVEIRA, Artur Rafael. O que é o MPS.BR? 2012. Disponível em: < 
https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-de-processos-do-
software-brasileiro--mpsbr > Acesso em: 03 jun. 2016. 
 
SOFTEX - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE 
BRASILEIRO. MPS. BR. Melhoria de Processo do Software Brasileiro. 2012. 
Disponível em: < http://www.softex.br/mps>. Acesso em: 05 de maio de 2016. 
 
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Pearson Addison 
Wesley, 2003.p.592. 
 
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson Addison 
Wesley, 2007.p.552. Disponível em: < 
http://www.ebah.com.br/content/ABAAAgMuQAG/sommerville-engenharia-software-
8-edicao> Acesso em: 28 Set. 2016. 
50 
 
 
 
 
VASCONCELOS, Audrey, MORAES, Lenildo. Modelos de Maturidade para 
Processos de Software: CMMI e MPS. BR. Centro de Informática – UFPE. 
Disponível em < http://www.cin.ufpe.br/~processos/TAES3/Livro/00-LIVRO/08-
CMMI_MPSBR_v6_CORRIGIDO.pdf > Acesso em: 29 Set.2016. 
 
VASCONCELOS, Alexandre Marcos Lins, ROUILLER, Ana Cristina, MACHADO, 
Cristina Ângela Filipak, MEDEIROS, Teresa Maria Maciel. Introdução à Engenharia 
de software e à qualidade de software. Universidade Federal de Lavras – UFLA. 
Lavras – MG. 2006. Disponível em: < 
http://www.cin.ufpe.br/~if720/downloads/Mod.01.MPS_Engenharia%26QualidadeSoft
ware_V.28.09.06.pdf> Acesso em: 18 Out.2016 
 
VOLPE, Renato Luiz Della. Visão Geral do SW-CMM. 2002. Disponível em: < 
http://www.asrconsultoria.com.br/docs/cmm_vg_ppt.pdf>Acesso em: 29 Set. 2016. 
 
WIKIPÉDIA, CMMI. Disponível em: < https://pt.wikipedia.org/wiki/CMMI > Acesso 
em: 10 Out. 2016. 
 
WIKIPÉDIA, Grupo de Processo de engenharia de software. Disponível em: < 
https://en.wikipedia.org/wiki/Software_Engineering_Process_Group > Acesso em: 13 
Nov. 2016. 
 
 
 
 
 
51 
 
 
 
Anexo A 
 
52 
 
 
 
53