Qualidade e Testes de Software

Prévia do material em texto

Qualidade e 
testes de software
Sandro Lopes Bianchini
Qualidade e 
testes de software
Sandro Lopes Bianchini
Bianchini, Sandro Lopes
Qualidade e testes de software. Sorocaba/SP, 2020. 62 f. Ed. 1.
Validador: Iremar Nunes de Lima.
Instituto Cultural Newton Paiva Ferreira Ltda. | ED+ Content Hub, 2020.
Assuntos:
1. Computadores - Software;
2. Control de qualidade;
3. Engenharia de software.
Formato: digital.
Recurso: PDF e HTML.
Requisitos do sistema operacional:
• Windows 8.1 ou superior;
• Mac OSX 10.6 ou superior;
• Linux - ChromeOS.
Configurações técnicas:
• 2GB de memória RAM;
• 2.5GHz de processador;
• 10GB de espaço em disco.
Navegadores:
• Google Chrome – Versão mais atualizada;
• Mozilla Firefox – Versão mais atualizada.
Dispositivos móveis:
• iOS 10 ou superior;
• Android 5 ou superior.
Modo de acesso: área restrita - Ambiente Virtual de Aprendizagem.
Todos os direitos desta edição são reservados ao Centro Universitário Facens.
Rodovia Senador José Ermírio de Moraes, 1425, km 1,5 – Sorocaba/SP
CEP: 18.085-784 | tel.: 55 15 3238 1188
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização.
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
Todas as imagens, vetores e ilustrações são creditados ao Shutterstock Inc., salvo quando indicada a referência.
Conteúdo
Unidade 1
Introdução à qualidade de software ................................................ 6
Unidade 2
Processos de garantia de qualidade de software ......................... 19
Unidade 3
CMMI .................................................................................................. 32
Unidade 4
Modelo MPS.br .................................................................................. 47
Unidade 5
Introdução à atividade de teste de software ................................ 61
Unidade 6
Fases ou níveis do teste de software ............................................. 77
Unidade 7
Técnicas de teste de software ......................................................... 88
Unidade 8
Outros aspectos do teste de software ......................................... 109
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
5
PALAVRAS DO AUTOR
Ao iniciar a jornada por essa disciplina, gostaria que você refletisse sobre os produtos que você consome. 
Você já se irritou com um defeito em um carro? Em um aparelho tocador de vídeo ou música? Uma 
peça de roupa com costura frágil? Irritou-se por ter adquirido um produto sem qualidade? Além desses 
produtos citados, muito provavelmente você já deve ter utilizado um aplicativo em um smartphone ou 
computador que exibiu uma mensagem de erro sem motivo aparentemente (apesar de você ter usado 
conforme as instruções do fabricante) ou ainda sofreu com alguma lentidão utilizando esse software. Ou 
seja, qualidade é importante em tudo aquilo que utilizamos para o bem-estar e atividades do cotidiano, 
sejam elas de lazer ou profissionais. No caso do software que você utiliza, essa afirmação não é diferente.
Diante dessa realidade, você conhecerá, por meio da disciplina de Qualidade e teste de software, o 
significado do termo qualidade para o produto conhecido por software dentro do contexto da atividade 
de engenharia de software, bem como as motivações que levam à sua prática e técnicas, processos e 
conceitos utilizados para alcançar a qualidade de software. Entre esses itens, por exemplo, a atividade 
de teste de software é tida como essencial para alcançar esse objetivo.
Uma vez que você compreenda os conceitos apresentados, poderá aplicá-los para a construção de 
produtos de software (aplicativos, software comerciais, sistemas críticos, sistemas operacionais, entre 
outros) que satisfaçam as necessidades das pessoas e evitem exatamente algum tipo de aborrecimento 
ou irritação ao utilizar um produto sem qualidade.
Seja bem-vindo(a) ao mundo da engenharia de software, que você conhecerá nessa disciplina.
Bons estudos!
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
6
Unidade 1 Introdução à qualidade de software
Objetivo da aprendizagem:
• Esclarecer o que é qualidade em software e seus fundamentos, conceitos, termos e histórico.
Tópicos de estudo:
• Introdução à engenharia de software.
• O que é qualidade de software?
• Aspectos de qualidade de software.
Iniciando os estudos:
Você já reparou que, provavelmente, o dispositivo que esteja utilizando para ler este livro possua capa-
cidade computacional provida por um conjunto de hardware e software? Além desse dispositivo, outros 
equipamentos de seu cotidiano também utilizam recursos de hardware e software, seja sua televisão, 
seu telefone e até seu relógio? E especificamente, em relação ao software que os acompanha, ele foi 
projetado, desenvolvido e testado sob um processo rigoroso para enfim ser disponibilizado de forma 
comercial? Em vista disso, nessa unidade você verá um histórico da engenharia de software e como é 
possível conceituar o termo qualidade para um software.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
7
1 INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Considerando o mundo que nos cerca, você pode perceber a presença de sistemas computacionais 
controlados tanto por hardwares quanto por softwares capazes de executar diversas funções. Há 
sistemas que controlam uma planta fabril desde a entrada da matéria-prima ao produto final; há outros 
que controlam o próprio sistema financeiro. Você encontrará ainda exemplos na indústria de entreteni-
mento, seja no desenvolvimento de jogos de computador, cinema, televisão e música. Nesses sistemas 
o uso de software é intenso (SOMMERVILLE, 2011).
Dada a utilização de software nos mais variados nichos, pode-se dizer que o software possui um duplo 
papel: ele é um produto e ao mesmo tempo é o veículo para se distribuir um produto. Além disso, 
é possível também ressaltar que o software distribui o produto mais importante de nossos tempos: a 
informação. Ele transforma dados pessoais em informações úteis de modo que possam ser utilizadas em 
um determinado contexto; gerencia informações comerciais para aumentar competitividade; fornece 
um portal para redes mundiais de informação e ainda os meios para a obtenção dessas informações. 
Isso nos leva a procurar entender como o software é produzido. Desde o início do desenvolvimento de 
software, quando esses eram construídos por programadores solitários até os dias atuais onde tem-se 
equipes inteiras destinadas a esse fim, muitas questões acerca do desenvolvimento de software são as 
mesmas (PRESSMAN; MAXIM, 2016):
• Por que leva tanto tempo para concluir o desenvolvimento de software?
Figura 1 - O mundo está em constante contato com a presença 
de sistemas computacionais, controlados tanto por hardwares 
quanto por softwares capazes de executar diversas funções.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
8
• Por que os custos de desenvolvimento de um software são tão altos?
• Por que não conseguimos encontrar todos os erros antes de entregarmos o software 
aos clientes?
• Por que gastamos tanto tempo e esforço mantendo programas existentes?
• Por que se continua a ter dificuldade em medir o progresso tanto do desenvolvimento 
quanto a manutenção do software?
Essas e outras questões levam à prática da engenharia de software.
O termo engenharia de software foi proposto em 1969 em uma conferência da OTAN, justamente para 
a discussão de questões relacionadas ao desenvolvimento de software, como as citadas anteriormente, 
por exemplo (SOMMERVILLE, 2011). Procurando na literatura, você encontrará diversas definições para 
o termo engenharia de software. Uma delas é a da IEEE (1990): “(1) A aplicação de uma abordagem siste-
mática, disciplinada e quantificável no desenvolvimento, na operação e na manutenção de software. (2) 
O estudo de abordagenscomo definido em (1).”
Em linhas gerais, a engenharia de software tem por objetivo apoiar o desenvolvimento profissional 
de software. Ela inclui técnicas que apoiam a especificação, projeto e evolução de programas. É uma 
disciplina de engenharia cujo foco está em todos os aspectos da produção de software, desde os está-
gios iniciais da especificação do sistema até sua manutenção, quando o sistema já está em utilização.
A ciência da computação se preocupa com as teorias e métodos que sustentam 
sistemas computacionais e de software, ao passo que a engenharia de software 
se preocupa com os problemas práticos de produção de software. Algum 
conhecimento de ciência da computação é essencial para engenheiros de 
software, da mesma forma que algum conhecimento de física é essencial para 
engenheiros elétricos.
Reflita
Para compreender melhor a engenharia de software, Pressman e Maxim (2016, p. 39) a define como 
uma tecnologia em camadas, como você pode observar na figura 2.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
9
Como a pedra fundamental que sustenta a engenharia de software, tem-se o foco na qualidade, impres-
cindível em qualquer abordagem de engenharia inclusive. A próxima camada é o processo, que mantém 
as camadas de tecnologia coesas, possibilitando que o software seja produzido de forma racional e 
respeitando os prazos estabelecidos. O processo, em geral, deve definir uma metodologia para o uso 
efetivo da tecnologia de engenharia de software. Por meio do processo, encontram-se subsídios para 
o gerenciamento de projetos, que estabelecem um contexto no qual são utilizados métodos técnicos 
e artefatos são produzidos (documentação, diagramas, relatórios etc). Além disso, são estabelecidos 
marcos, que possibilitam a garantia da qualidade e ainda o controle sobre as mudanças que podem ser 
feitas durante o desenvolvimento do software.
Para saber mais sobre o conteúdo, você pode ver o vídeo abaixo.
Título: O que um engenheiro de software faz?
Acesso em: 08/10/2019.
Disponível em: https://www.youtube.com/watch?v=wdU9L3DqU2w
Aprofunde-se
Informações técnicas sobre como um software pode ser produzido são encontradas na camada método. 
Nessa camada, você encontrará tarefas que incluem comunicação, análise de requisitos, modelagem de 
projeto, codificação do programa, testes e suporte.
Figura 2 - Engenharia de software: uma tecnologia em camadas.
Fonte: adaptado de Pressman e Maxim (2016).
ED+ Content Hub © 2019
https://www.youtube.com/watch?v=wdU9L3DqU2w
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
10
Por fim, na camada ferramentas, existem utilidades que fornecem suporte automatizado ou semiauto-
matizado para o processo e para os métodos. Uma vez integradas, de modo que informações geradas 
por uma ferramenta possam ser utilizadas em outra, tem-se um sistema para o suporte ao desenvol-
vimento de software, denominado engenharia de software com o auxílio do computador (do inglês 
Computer-Aided Software Engineering, comumente conhecido como ferramentas CASE) (IEEE,1990).
Considerando a camada de processo, segundo Sommerville (2011, p. 5), existem muitos processos de 
software diferentes, porém todos devem possuir quatro atividades fundamentais:
1. Especificação de software: a funcionalidade do software e as restrições ao seu funcio-
namento devem ser definidas.
2. Projeto e implementação de software: o software deve ser produzido para atender 
às especificações.
3. Validação de software: o software deve ser validado para garantir que atenda às 
demandas do cliente.
4. Evolução de software: o software deve evoluir para atender às necessidades de 
mudança dos clientes.
Acesse na plataforma o vídeo: Atividades fundamentais de 
processos de engenharia de software.
Assista
Portanto, ao aplicar qualquer processo da engenharia de software que implemente essas atividades, de 
alguma maneira você garantirá qualidade. No próximo tópico será discutido sobre qualidade de software.
Para saber mais sobre o conteúdo, você pode ler o livro abaixo.
Título do livro: Guide to the Software Engineering Body of Knowledge (SWEBOK(R)) 
Local: Los Alamitos, CA.
Editora: IEEE Computer Society Press.
Data da publicação: 17/01/2014.
Aprofunde-se
2 O QUE É QUALIDADE DE SOFTWARE?
Como você viu no tópico anterior, a pedra fundamental da tecnologia da engenharia de software é o foco 
na qualidade. Todavia, antes de continuar, pense em um produto qualquer e reflita: o que é qualidade 
para você? Acredito que a definição exata para essa questão não deva ter sido encontrada facilmente. 
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
11
Se essa questão for lançada para um grupo de alunos, provavelmente haverá respostas baseadas nas 
percepções pessoais de cada um. Ao retornar para o contexto de software, encontrará possivelmente a 
mesma dificuldade.
O aumento do uso de software trouxe proble-
mas para seus desenvolvedores, como pressão 
por entregas, aumento dos custos, sistemas 
apresentando falhas e mal escritos.
Problemas
Aplicar princípios da engenharia clássica para 
o desenvolvimento de software, a fim de 
profissionalizar essa atividade, com foco na 
criação de um produto com qualidade.
Solução
Nos anos iniciais, software era desenvolvido 
por programadores solitários, focados apenas 
na codificação deles.
Início
Endereçar o desenvolvimento de software de modo que o produto atenda aos anseios dos usuá-
rios, tanto por meio de suas funcionalidades (um editor de texto deve permitir editar textos e 
salvá-los em disco) quanto por meio de outros atributos não funcionais (o software de navegação 
de um avião não pode travar, deve ser resiliente).
Qualidade
Com a adoção de computadores pessoais, 
software passou a ganhar importância para 
as pessoas e empresas.
Uso intenso
Software, como qualquer produto desenvolvido, requer qualidade para atingir os resultados esperados por 
seus usuários. Além de cumprir com as funcionalidades esperadas, precisa possuir características 
relacionadas a aspectos como segurança e proteção.
Infográfico 1 - A importância da qualidade no software.
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
12
Para chegar em um conceito mais formal sobre o que é qualidade de software, deve-se antes construir 
o conceito de qualidade.
Segundo Garvin (1984, p. 25), citado por Pressman e Maxim (2016, p. 359), o conceito de qualidade é 
complexo e possui várias faces, podendo ser descrito por cinco pontos de vista diferentes. Esses pontos 
de vista são:
• Visão transcendental: a qualidade é algo que é reconhecido de imediato, porém não 
se consegue definir explicitamente.
• Visão do usuário: a qualidade é vista em termos de metas específicas de um usuário final.
• Visão do fabricante: a qualidade é definida em termos da especificação original do 
produto. Significa que se um produto atender às especificações, ele apresenta qualidade.
• Visão do produto: sugere que a qualidade pode estar ligada às características intrín-
secas do produto, como funções e recursos.
• Visão baseada em valor: a qualidade é medida tomando-se por base o quanto um 
cliente estaria disposto a pagar por um produto.
Esse artigo explora a qualidade, sob a ótica dos autores relacionados a um 
software, como seus usuários, desenvolvedores e patrocinadores de um 
software.
Título: Uma introdução à qualidade de software
Link: https://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality/
Aprofunde-se
Na indústria, a definição de qualidade seguiu, em linhas gerais, a visão do fabricante mencionada ante-
riormente. De acordo com Crosby (1979, apud SOMMERVILLE, 2011, p. 456), a qualidade é baseada na 
conformidade de um produto em relação a uma especificação detalhada e na noção de tolerân-
cias. A partir disso, obteve-se o entendimento que produtos poderiam ser especificados por completo e 
procedimentospoderiam ser criados para avaliar se um produto estivesse de acordo com suas especi-
ficações. Naturalmente, os produtos nem sempre cumprirão com todas as suas especificações, por isso 
admitiu-se tolerância. Se um produto estivesse ‘quase certo’, era considerado aceitável.
Entretanto, qualidade de software não pode ser comparada diretamente à qualidade na indústria. Tole-
rância é um conceito não aplicável aos sistemas digitais e, considerando as razões listadas abaixo, talvez 
seja impossível concluir objetivamente se um sistema de software atende ou não suas especificações 
(SOMMERVILLE, 2011). As razões são as seguintes:
1. Clientes e desenvolvedores de software podem interpretar os requisitos de modo 
diferente. Chegar a um acordo sobre se o software cumpre suas especificações ou não 
pode ser impossível.
https://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality/
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
13
2. Em geral, as especificações integram requisitos de várias classes de stakeholders. 
Esses requisitos são um compromisso e podem não incluir os requisitos de todos os 
grupos de stakeholders. Os stakeholders excluídos podem perceber o sistema como um 
sistema de baixa qualidade, mesmo que esse implemente os requisitos acordados.
3. É impossível medir determinadas características de qualidade diretamente, por 
exemplo o quão facilitada é a manutenção de um software.
Acesse na plataforma o vídeo: Qualidade para softwares.
Assista
Tendo em vista essas razões, é possível considerar que a qualidade de software é um processo subjetivo, 
onde é necessário que uma equipe de gerenciamento de qualidade julgue se um software alcançou um 
nível aceitável de qualidade, considere se o software é adequado para sua finalidade ou não e também 
se responde às questões sobre características de um sistema, por exemplo:
• Durante o processo de desenvolvimento, os padrões de programação e documentação 
foram seguidos?
• O software foi devidamente testado?
• O software é suficientemente confiável para ser colocado em uso?
• O desempenho do software é aceitável para o uso normal?
• O software é útil?
• O software é bem estruturado e compreensível?
Esse artigo detalha o conceito de qualidade e sua evolução na história.
Título: Uma breve história da engenharia de qualidade
Link: https://www.dcce.ibilce.unesp.br/~adriana/ceq/Material%20
complementar/histquali.pdf
Aprofunde-se
Para cada uma das questões mencionadas, você encontrará aspectos que as permeiam. Esses aspectos 
serão discutidos no próximo tópico.
https://www.dcce.ibilce.unesp.br/~adriana/ceq/Material%20complementar/histquali.pdf
https://www.dcce.ibilce.unesp.br/~adriana/ceq/Material%20complementar/histquali.pdf
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
14
3 ASPECTOS DA QUALIDADE DE SOFTWARE
Como você viu anteriormente, a qualidade de um sistema de software é subjetiva. Mais do que simples-
mente considerar sua funcionalidade, ou seja, avaliar se um software foi implementado corretamente, o 
entendimento sobre qualidade de software deve considerar atributos não funcionais, relacionados com 
a percepção do sistema por parte dos usuários. Na tabela 1 é possível ver 15 atributos sugeridos por 
Boehm et al. (1978, apud SOMMERVILLE, 2011, p. 457):
Segurança Compreensibilidade Portabilidade
Proteção Testabilidade Usabilidade
Confiabilidade Adaptabilidade Reusabilidade
Resiliência Modularidade Eficiência
Robustez Complexidade Capacidade de aprendizado
Outro aspecto vital na qualidade de software é a medição. Na engenharia de software, toda medição é 
nomeada com uma métrica. Uma métrica é uma medida, como custo ou tamanho, que pode ser aplicada 
ao software (BELL, 2005). A proposta do uso de métricas incluem os seguintes tópicos:
• Predizer atributos de qualidade para o software que será construído;
• Julgar a qualidade sobre o software ou uma porção dele que foi desenvolvida;
• Monitorar e melhorar o processo de desenvolvimento de software;
• Comparar e avaliar diferente abordagem de desenvolvimento.
Entre as métricas existentes é possível relacionar as métricas básicas. A medida mais simples que você 
encontrará para um software é seu tamanho. Geralmente é medido por linhas de código ou pontos por 
função. O tamanho em bytes afeta a memória principal e os requisitos de armazenamento, que por sua 
vez impactam no desempenho.
Para saber mais sobre o conteúdo, você pode ver o vídeo abaixo.
Título: O que é a análise de pontos de função?
Acesso em: 09/10/2019.
Disponível em: https://www.youtube.com/watch?v=9N1FMXrB9Kk
Aprofunde-se
Tabela 1 - Atributos não funcionais da qualidade de software.
Fonte: adaptado de Sommerville (2011).
https://www.youtube.com/watch?v=9N1FMXrB9Kk
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
15
Outra métrica importante é a pessoas-mês, que pode ter um detalhamento maior, como pessoas-hora, 
uma medida do esforço de desenvolvimento. É uma métrica que impacta diretamente no custo do software. 
Essa informação pode ser utilizada por empresas para predizer o tempo de futuros desenvolvimentos.
A outra métrica básica é o número de bugs ou falhas. Essa métrica permitirá predizer quantos bugs 
podem permanecer ao final do desenvolvimento.
Esse artigo explora métricas para avaliação de qualidade.
Título: Métricas de Qualidade de Software
Link: https://www.tiespecialistas.com.br/metricas-de-qualidade-de-software/
Aprofunde-se
Existem também as métricas de complexidade, que se referem a quanto o código de um software é complexo. 
Uma métrica comumente utilizada nesse tipo é a análise de pontos por função. A ênfase aqui é que os 
programas sejam escritos de maneira clara e simples e, portanto, fáceis de checar, entender e modificar.
Acesse na plataforma o vídeo: Aspectos funcionais, não funcionais e 
estruturais: detalhando o conceito de qualidade de software.
Assista
https://www.tiespecialistas.com.br/metricas-de-qualidade-de-software/
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
16
CONSIDERAÇÕES FINAIS
Nesta unidade você pôde conhecer melhor o que é a engenharia de software, seu histórico e seus obje-
tivos enquanto disciplina para profissionais da área de desenvolvimento de software. Como parte dos 
objetivos dessa disciplina, você também aprendeu que qualidade é um requisito essencial para a enge-
nharia de software. Por fim, também pôde entender que para se alcançar qualidade em um software, 
mais do que implementar suas funcionalidades propostas, é necessário considerar outros aspectos não 
funcionais, como confiabilidade e robustez.
Você seguirá seus estudos, aprofundando o conceito de qualidade, visando entender processos que 
possam garanti-la em um projeto de software.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
17
GLOSSÁRIO
IEEE: Institute of Electrical and Electronic Engineers.
Stakeholders: termo utilizado para designar todas as pessoas, em diferentes níveis, que estejam interes-
sadas em um projeto de software. Poderia ser traduzido como interessados.
Bug: defeito, falha ou erro no código de um programa que provoca seu funcionamento incorreto.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
18
REFERÊNCIAS
BELL, D. Software Engineering for Students. 4. ed. Addison-Wesley, 2005. 424 p. ISBN 9780321261274.
IEEE Std. 610.12. IEEE Standard Glossary of Software Engineering Terminology. The Institute of Elec-
trical and Electronics Engineers, New York, 1990.
PRESSMAN, Roger S; MAXIM, Bruce R. Engenharia de Software - Uma Abordagem Profissional. 8. ed. 
Porto Alegre: Amgh Editora, 2016. 968 p.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011. 529 p.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
19
Unidade2 Processos de garantia de qualidade de software
Objetivo de aprendizagem:
• Apresentar ao aluno o processo que tem por objetivo controlar e garantir a qualidade dentro 
dos diversos processos de desenvolvimento de software.
Tópicos de estudo:
• Processos de garantia e de gestão da qualidade de software;
• Gestão da qualidade de produto;
• Gestão da qualidade de processo.
Iniciando os estudos:
Como você viu, a qualidade de software é um dos pilares da engenharia de software. A busca pela qualidade 
em um software representará a satisfação dos usuários por meio do fornecimento de um produto robusto, 
estável e que cumpre com a funcionalidade desejada desses usuários.
Para alcançar essa qualidade, no entanto, é necessário também que durante o processo de desenvolvimento 
haja algum elemento que determine e diga se a qualidade está em conformidade com aquilo que se espera. 
É necessário garantir que a qualidade no software esteja presente por meio de atividades que façam gestão e 
controle de todo o processo.
Nesta unidade, serão abordados processos de gestão e garantia da qualidade e você perceberá como eles 
apoiam o desenvolvimento de software.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
20
1 PROCESSOS DE GARANTIA E DE 
GESTÃO DA QUALIDADE DE SOFTWARE
Se você pudesse observar o comportamento de muitos desenvolvedores de software espalhados nas 
muitas empresas que desenvolvem software, perceberia que ainda hoje eles acreditam que qualidade 
de software é algo que só deve ser considerado após a codificação do software em si. Porém, esse 
pensamento não poderia estar mais distante da verdade. A garantia da qualidade de software (SQA, do 
inglês Software Quality Assurance, muitas vezes ainda denominada gestão da qualidade) é um processo 
universal e deve ser aplicado em todo processo no qual se deseja obter qualidade (PRESSMAN; MAXIM, 
2016, p. 387).
Na indústria de software, SQA pode ter diferentes interpretações. Por vezes, apenas pode significar a 
definição de processos, procedimentos e padrões que têm por objetivo reforçar que a qualidade de 
software seja atingida. Em outras vezes, sua interpretação também inclui todo o gerenciamento de confi-
guração, atividades de verificação e validação aplicadas após o produto ter sido entregue. Pode-se consi-
derar que o SQA possui três principais preocupações em diferentes níveis (SOMMERVILLE, 2011, p. 454):
1. No nível organizacional, a gestão de qualidade está preocupada com o estabelecimento 
de um arcabouço de processos organizacionais e padrões que levem a softwares de 
alta qualidade. A consequência disso é que uma equipe de gestão de qualidade deve 
assumir a responsabilidade de definir os processos de desenvolvimento do software 
que serão usados e os padrões que devem ser usados nele, que incluem a documen-
tação relacionada, os requisitos de sistema, projeto e código.
• No nível de projeto, a gestão de qualidade envolve a aplicação de processos específicos 
de qualidade, que checam se os processos planejados foram seguidos e garantem que 
as saídas de projeto estejam em conformidade com os padrões aplicáveis ao projeto.
• No nível de projeto ainda, a gestão de qualidade também está preocupada com o esta-
belecimento de um plano de qualidade, em que devem ser definidas as metas de quali-
dade para o projeto e quais processos e padrões devem ser utilizados.
Para saber mais sobre o conteúdo, você pode ver o vídeo abaixo.
Título: Qual a diferença entre controle da qualidade e garantia da qualidade?
Acesso em: 20/10/2019.
Disponível em: https://www.youtube.com/watch?v=qNGgcVaHiSc
Aprofunde-se
https://www.youtube.com/watch?v=qNGgcVaHiSc
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
21
A gestão de qualidade fornece uma verificação diferente do processo de desenvolvimento de software. 
Cada entregável do processo de desenvolvimento é verificado para garantir que sejam consistentes 
com os objetivos organizacionais. Na figura abaixo, você pode observar que cada entregável (E1, E2, E3 
e assim por diante) do processo de desenvolvimento de software passa para o processo de gestão de 
qualidade, que segue seu próprio caminho.
Processo de
desenvolvimento
de software Entregável 1
Padrões e
procedimentos
Relatórios de
revisão de
qualidade
………Plano dequalidade
Entregável 2 Entregável 3 Entregável 4
Processo de
gestão de
qualidade
Ressalta-se que, além de seguir com um processo complementar ao desenvolvimento de software, 
a equipe que tem como função o SQA deve desempenhar o papel do cliente, funcionando como um 
serviço de defesa desse mesmo cliente, examinando o software sob sua ótica (PRESSMAN; MAXIM, 2016).
Acesse na plataforma o vídeo: A busca pela qualidade passa 
por processos de gestão e garantia.
Assista
1.1 ELEMENTOS DA GARANTIA DA QUALIDADE DE SOFTWARE
No SQA, engloba-se um amplo aspecto de preocupações e atividades que podem ser relacionadas da 
seguinte maneira (HORSH, 2003 apud PRESSMAN; MAXIM, 2016):
• Padrões: o IEEE, a ISO e outras organizações desenvolveram um conjunto de padrões 
para a engenharia de software e seus documentos relacionados. Os padrões podem 
ser adotados voluntariamente por uma organização de engenharia de software ou 
impostos pelo cliente ou demais interessados. A função do SQA aqui é garantir que 
os padrões, que por ventura tenham sido adotados, sejam seguidos e que todos os 
produtos resultantes estejam em conformidade com eles.
Figura 1 - Gestão de qualidade vs Processo 
de desenvolvimento de software. 
Fonte: adaptado de Sommerville (2011).
ED+ Content Hub © 2019
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
22
• Revisões e auditorias: as revisões técnicas são uma atividade de controle de quali-
dade realizada por engenheiros de software para engenheiros de software. Seu propó-
sito é o de revelar erros. Auditorias são um tipo de revisão efetuadas pela equipe de 
SQA com o intuito de assegurar que as diretrizes de qualidade estejam sendo seguidas 
no trabalho de engenharia de software. Por exemplo, uma auditoria de processo 
de revisão pode ser realizada para garantir que as revisões estejam sendo feitas de 
maneira que conduza a maior probabilidade possível de alcançar seu objetivo primário.
• Testes: os testes de software são uma função de controle de qualidade com um obje-
tivo principal: descobrir erros. Aqui, a função do SQA é garantir que os testes sejam 
planejados apropriadamente e conduzidos eficientemente de modo que se tenha a 
maior chance possível de alcançar seu objetivo primário.
• Coleta e análise de erros/defeitos: para melhorar, medir o próprio desempenho é 
essencial. O SQA reúne e analisa dados de erros e defeitos para melhor compreender 
como os erros são introduzidos e quais atividades de engenharia de software melhor 
se adaptam para sua eliminação.
• Gerenciamento de mudanças: as mudanças são um dos aspectos mais negativos em 
qualquer projeto de software. Se não forem administradas, podem gerar confusão, 
o que pode levar a uma qualidade aquém da desejada. O SQA garante que práticas 
adequadas de gerenciamento de mudanças tenham sido instituídas.
• Educação: um fator fundamental para se aprimorar as práticas de engenharia de 
software é a educação de engenheiros, gerentes e demais interessados. A organização 
de SQA assume a liderança nesse processo de aperfeiçoamento do software e é um 
proponente e patrocinador de programas educacionais.
• Gerência de fornecedores: pode-se encontrar três categorias de software oferecidas 
por fornecedores externos: pacotes prontos/comerciais (conhecidos como software de 
prateleira, como o Microsoft Office, oferecidos em caixas); software customizado (possui 
um esqueleto básico, como o oferecido em caixas, porém personalizado de acordo com 
as necessidades do comprador); e software sob encomenda (projetado e construído 
desde o início, a partir de especificações fornecidaspela empresa-cliente). Aqui, a função 
do SQA é garantir a qualidade do software por meio da sugestão de práticas de garantia 
de qualidade que o fornecedor, em linhas gerais, deve seguir e incorporar exigências de 
qualidade como parte de qualquer contrato com um fornecedor externo.
• Administração da segurança: com o aumento de crimes cibernéticos e novas regula-
mentações referentes à privacidade, toda organização de software deve instituir polí-
ticas que protejam os dados em todos os níveis, desde firewalls até checar modificações 
não autorizadas. O SQA garante o emprego de processos e tecnologias apropriadas 
voltadas para a segurança.
• Proteção: como o software é um componente fundamental de sistemas que envolvem 
vidas humanas, o impacto de defeitos escondidos pode ser trágico. O SQA pode ser 
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
23
responsável por avaliar o impacto de falhas de software e por iniciar as etapas necessá-
rias para a redução de riscos.
• Administração de riscos: embora a análise e redução de riscos seja uma preocupação 
de engenheiros de software, o grupo de SQA garante que as atividades da gestão de 
riscos sejam conduzidas corretamente e que planos de contingência relacionados a 
riscos tenham sido estabelecidos.
Além de analisar diferentes abordagens de processos utilizados para o SQA, esse artigo 
analisa também os custos decorrentes dos processos envolvidos sob a ótica financeira.
Título: The economics of sotfware quality assurance
Link: https://pdfs.semanticscholar.org/2d91/50f879c44bc9ac82e59dcb4b51c2e83e211f.pdf
Aprofunde-se
Somadas a essas atividades e preocupações, você poderá ver ainda o SQA envolvida na garantia de que 
atividades de suporte ao software, como manutenção, suporte online, documentação e manuais, sejam 
produzidas tendo como foco a qualidade.
2 GESTÃO DA QUALIDADE DE PRODUTO
Como você viu, uma das preocupações do SQA é o uso de padrões em seus processos de gestão. Um 
desses padrões são as normas ISO 9000. Essas normas podem ser aplicadas a uma variedade de orga-
nizações, desde a produção até a indústria de serviços. Por exemplo, a mais geral dessas normas, a 
ISO 9001, pode ser aplicada às organizações que projetam, desenvolvem e mantêm produtos, inclu-
sive softwares (SOMMERVILLE, 2011). Todavia, especificamente para o desenvolvimento de software, em 
1991, foi criada a ISO/IEC 9216. Foi traduzida para o Brasil em 1996, sob o nome NBR 13596. Posterior-
mente, essa norma brasileira foi substituída pela NBR ISO/IEC 9126-1.
A ISO/IEC 9126 é dividida em quatro partes (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2003):
• ISO/IEC 9126-1 - Modelo de Qualidade;
• ISO/IEC 9126-2 - Métricas Externas;
• ISO/IEC 9126-3 - Métricas Internas;
• ISO/IEC 9126-4 - Métricas de Qualidade em Uso.
A parte 1 apresenta um modelo de qualidade para o produto de software que será discutido adiante. As 
partes 2, 3 e 4 contemplam um conjunto de métricas para avaliação de atributos de qualidade interna 
(características dos produtos intermediários dos processos de desenvolvimento de software), qualidade 
externa (características do produto final de software gerado) e qualidade em uso (características do 
produto final, porém sob a perspectiva do usuário).
https://pdfs.semanticscholar.org/2d91/50f879c44bc9ac82e59dcb4b51c2e83e211f.pdf
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
24
O texto aborda o conceito de qualidade total do produto e seus determinantes, 
bem como as dimensões que compõem essa qualidade.
Título: Qualidade total do produto
Link: https://bit.ly/2Wpo1mW
Aprofunde-se
2.1 MODELO DE QUALIDADE
A parte 1 apresenta um conjunto de características para a definição de um modelo de qualidade, 
podendo ser aplicada a qualquer produto de software. Esse modelo, por sua vez, é composto de duas 
partes. Umas delas é o Modelo de Qualidade Interna e Externa (veja na figura abaixo).
Qualidade
interna e externa
• Funcionalidade
- Adequação
- Acurácia
- Interoperabilidade
- Segurança de acesso
- Conformidade
• Confiabilidade
- Maturidade
- Tolerância a falhas
- Recurerabilidade
- Conformidade
• Usabilidade
- Inteligibilidade
- Apreensibilidade
- Operacionalidade
- Atratividade
- Conformidade
• Eficiência
- Comportamento em
relação ao tempo
- Utilização de recursos
- Conformidade
• Manutenibilidade
- Analisabilidade
- Modificabilidade
- Estabilidade
- Testabilidade
- Conformidade
• Portabilidade
- Adaptabilidade
- Capacidade para
ser instalado
- Coexistência
- Capacidade para
substituir
- Conformidade
Nesse modelo, qualidade interna e externa são definidas por um conjunto de seis características básicas 
que um software deve possuir para ser considerado um produto de software de qualidade. Cada carac-
terística é dividida em um conjunto de subcaracterísticas. As características são:
• Funcionalidade: relacionada à finalidade do produto;
• Confiabilidade: diz respeito à frequência de falhas e recuperabilidade do software;
• Usabilidade: relacionada ao esforço para se utilizar/aprender o produto;
• Eficiência: refere-se ao desempenho do produto de software;
Figura 2 - Modelo de Qualidade Interna e Externa com suas 
características e subcaracterísticas.
Fonte: adaptado de Associação Brasileira de Normas Técnicas (2003).
ED+ Content Hub © 2019
https://bit.ly/2Wpo1mW
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
25
• Manutenibilidade: relacionada ao esforço para se modificar o software;
• Portabilidade: diz respeito à capacidade de transferir o produto para outros ambientes.
Acesse na plataforma o vídeo: A busca pela qualidade passa 
por processos de gestão e garantia.
Assista
Esse artigo possui um estudo de caso, onde a norma ISO/IEC 9126 é adaptada 
para sua aplicação em um domínio específico, no caso, aplicações B2B.
Lembrando que, ao acessar o link, você precisa realizar gratuitamente o login 
para baixar o conteúdo.
Título: Customizing ISO 9126 quality model for evaluation of B2B applications
Link: https://bit.ly/2BWONcU
Aprofunde-se
A segunda parte do modelo é formada pelo Modelo de Qualidade em Uso, dividida por quatro caracte-
rísticas de qualidade. Em linhas gerais, qualidade em uso é, para o usuário, o efeito combinado das seis 
características de qualidade do produto de software apresentadas anteriormente.
As características do Modelo de Qualidade em Uso são:
• Eficácia: é a capacidade do produto de software de permitir que usuários atinjam obje-
tivos especificados com acurácia e completitude em um contexto de uso especificado.
• Produtividade: é a capacidade do produto de software de permitir que seus usuá-
rios utilizem quantidade apropriada de recursos em relação à eficácia obtida em um 
contexto de uso especificado. Ressalta-se que recursos relevantes podem incluir tempo 
para término da tarefa, esforço do usuário, materiais ou custos financeiros.
• Segurança: é a capacidade do produto de software de apresentar níveis aceitáveis de 
riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente em um 
contexto de uso especificado. De um modo geral, os riscos são decorrentes das defi-
ciências na funcionalidade (incluindo segurança de acesso), confiabilidade, usabilidade 
ou manutenibilidade.
• Satisfação: é a capacidade do produto de software de satisfazer usuários em um contexto 
de uso especificado. Em relação à satisfação, você deve considerar que é a resposta do 
usuário à interação com o produto e inclui atitudes relacionadas ao uso do produto.
https://bit.ly/2BWONcU
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
26
2.2 MÉTRICAS INTERNAS E EXTERNAS
Na parte 2 e 3 da ISO/IEC 9126 são apresentadas medições para a Qualidade Interna e a Externa. Quando 
os requisitos de qualidade do produto de software são definidos, as características de qualidade do 
produto que contribuem com os requisitos de qualidadesão listadas. Logo, as métricas externas compa-
tíveis com esses requisitos são especificadas para quantificar os critérios de qualidade que validam se o 
software atende às necessidades do usuário.
Os atributos de qualidade interna do software são definidos na sequência e especificados, com o obje-
tivo de atingir a qualidade externa e a qualidade em uso requeridas e considerá-las no produto durante 
seu desenvolvimento. Métricas internas compatíveis são especificadas para quantificar os atributos de 
qualidade interna, de modo que eles possam ser utilizados para verificar se os produtos intermediá-
rios resultantes do processo de desenvolvimento de software atendem às especificações de qualidade 
interna durante esse processo.
É importante levar em consideração que as métricas internas utilizadas tenham uma relação tão forte 
quanto possível com as métricas externas escolhidas, de modo que possam ser utilizadas para prever os 
valores de métricas externas. Entretanto, é difícil elaborar um modelo teórico rigoroso que estabeleça 
um relacionamento forte entre métricas internas e externas.
2.3 MÉTRICAS DA QUALIDADE EM USO
Na parte 4 da norma ISO/IEC 9126, estão reunidas métricas para avaliação das características de quali-
dade em uso do software.
Métricas de qualidade em uso medem o quanto um produto atende às necessidades de usuários para 
que atinjam objetivos especificados com eficácia, produtividade, segurança e satisfação em um contexto 
de uso especificado.
A avaliação de qualidade em uso valida a qualidade do produto de software em cenários de uso espe-
cífico. O relacionamento da qualidade em uso com as outras características de qualidade depende dos 
seguintes atores do processo de desenvolvimento de software:
• Do usuário final, para quem qualidade em uso é, principalmente, resultante de funcio-
nalidade, confiabilidade, usabilidade e eficiência;
• Da pessoa que mantém o software, para quem qualidade em uso é resultante de 
manutenibilidade;
• Da pessoa encarregada de portar o software, para quem qualidade em uso é resultante 
de portabilidade.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
27
ED+ Content Hub © 2019
3 GESTÃO DA QUALIDADE DE PROCESSO
A qualidade de um produto de software também pode ser definida pela qualidade dos processos utili-
zados para o seu desenvolvimento. A qualidade do processo de software é esperada desde a coleta dos 
requisitos de usuário até a entrega do produto final, passando por um ciclo de vida que oferece uma 
análise crítica do contrato e estende-se à sua instalação e manutenção (LODI; CORDENONZI, 2002).
Pode-se encontrar uma relação direta entre qualidade do processo 
e a qualidade desejada para um produto. Com isso, uma vez 
melhorando o processo de construção, melhora-se o produto em 
si. Portanto, como melhorá-lo?
Facilidade de
compreensão: 
Todos os membros da equipe 
devem ser capazes de entender o 
processo no qual atuam;
Confiabilidade: 
Erros devem ser evitados ou 
ainda antecipados;
Facilidade
de adaptação: 
Mudanças devem ser 
facilmente implementadas;
Agilidade na
entrega do produto:
Há ganho de tempo na entrega 
de um produto de software 
com qualidade;
• Medir: procura melhorar as medidas de acordo 
com os objetivos da organização envolvida na 
melhoria de processos.
• Analisar: o processo atual é avaliado e os 
gargalos e pontos fracos são identificados.
• Mudar: mudanças são propostas para 
resolver pontos fracos identificados no processo. 
Ciclos de
avaliação contínua: 
Melhoria do processo 
de desenvolvimento de 
software
Infográfico 1 - Melhoria do processo 
de desenvolvimento de software.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
28
Para tanto, encontram-se na literatura e na indústria modelos para definição, avaliação e melhoria de 
processos de software, entre eles:
• O CMM, também chamado de SW-CMM (Software CMM). Seu objetivo inicial foi estabelecer 
um padrão de qualidade para o software desenvolvido para as forças armadas americanas.
Esse artigo descreve os componentes do CMM e suas motivações.
Título: As características do CMM e o desenvolvimento de software com qualidade
Link: https://bit.ly/2WtSmk9
Aprofunde-se
• O SPICE, nome do projeto de elaboração da norma ISO/IEC 15504, que foi lançado 
em 1993, com o objetivo de gerar normas para a avaliação de processos, visando a 
melhoria contínua do processo e a determinação de sua capacitação.
• A ISO/IEC 12207, que foi aprovada em agosto de 1995 e estabelece os processos de 
atividades e tarefas a serem aplicados durante a aquisição, fornecimento, desenvolvi-
mento, operação e manutenção de software (ROCHA et al., 2001). Atualmente foi revi-
sada pela norma ISO/IEC/IEEE 12207:2017.
Acesse na plataforma o vídeo: Descrição da ISSO/IEC 12207.
Assista
https://bit.ly/2WtSmk9
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
29
CONSIDERAÇÕES FINAIS
Para que um produto atinja níveis aceitáveis de qualidade, você viu que diferentes aspectos e abor-
dagens devem ser considerados. A qualidade pode ser abordada analisando a qualidade do produto 
desenvolvido, considerando-se atributos como confiabilidade e usabilidade, por exemplo.
Outra abordagem vista é que a qualidade também deve ser atingida no que tange à qualidade dos 
processos envolvidos no próprio desenvolvimento de software.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
30
GLOSSÁRIO
B2B: Business-to-Business.
CMM: Capability Maturity Model.
Entregável: (deliverables) são documentos, protótipos e também todos os demais itens intangíveis (tais 
como treinamento e homologação) que um processo produz e deve ser entregue quando for completado.
IEEE: em português, Instituto de Engenheiros Eletricistas e Eletrônicos.
ISO: International Organization for Standardization.
SPICE: Software Process Improvement and Capability Determination.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
31
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 9126-1: Engenharia de Software - Qualidade do 
Produto. Rio de Janeiro, 2003.
PRESSMAN, Roger S; MAXIM, Bruce R. Engenharia de Software - uma abordagem profissional. 8.ed. 
Porto Alegre: Amgh Editora, 2016.
LODI, Silvanna; CORDENONZI, Walkiria. Aplicação de produto do software utilizando a ISO/IEC 9126. 
Disciplinarum Scientia|Ciências Naturais e Tecnológicas, v. 3, n. 1, p. 11-27, 2016.
ROCHA, Ana Regina Cavalcanti da et al. Qualidade de Software: teoria e prática. São Paulo: Prenttice 
Hall, 2001.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011.
Qualidade e testes de software | Unidade 3 - CMMI
32
Unidade 3 CMMI
Objetivo da aprendizagem:
• Apresentar o modelo CMMI, sua descrição e como ele auxilia na melhoria de processos de 
desenvolvimento de software.
Tópicos de estudo:
• Sobre o CMMI;
• Representações do CMMI;
• Áreas de processo do CMMI;
• Obtendo a certificação.
Iniciando os estudos:
Na constante busca por qualidade no desenvolvimento de software, com a finalidade de entregar aos 
clientes e usuários um produto de qualidade, é necessário também direcionar esforços para a promoção 
dos processos envolvidos.
Nesse sentido, você conhecerá em detalhes o modelo CMMI, ferramenta criada para auxiliar organizações 
desenvolvedoras de software na implementação da qualidade de processo até a qualidade do produto.
Qualidade e testes de software | Unidade 3 - CMMI
33
1 SOBRE O CMMI
O CMMI é um modelo de maturidade criado com o objetivo de proporcionar condições para a evolução 
das boas práticas de engenharia de software. Foi desenvolvido pelo Instituto de Engenharia de Software 
da Universidade de Carnegie Mellon (SEI/CMU), localizado em Pittsburg, nos Estados Unidos. O resul-
tado de uma série de estudosiniciais culminou na criação do CMM (Capability Maturity Model), Modelo 
de Capacidade e Maturidade (MACHADO, 2016).
No CMM, dependendo da área de aplicação, diferentes modelos foram criados, como o SW-CMM (CMM 
para Software) e SA-CMM (CMM para aquisição de Software). Procurando então evoluir e integrar esses 
modelos em um volume único, substituindo-os, o SEI criou o CMMI (Capability Maturity Model Integra-
tion) ou Integração de Modelos de Capacidade e Maturidade.
O objetivo do CMMI, em linhas gerais, é melhorar os processos de uma organização ao adotá-lo. 
Como um modelo de referência, serve como uma estruturação de práticas e abordagens de sucesso 
comprovado. Essas práticas procuram contribuir com a organização através da disponibilização de 
orientações sobre:
• Como avaliar a maturidade da organização e sua capacidade por área de processos;
• Como estabelecer atividades prioritárias para as melhores propostas;
• Como implementar as melhorias propostas.
O modelo de referência é composto por múltiplos modelos de processo em conjunto a seus manuais e 
material de treinamento e de avaliação. Esses modelos integram o gerenciamento de qualidade, utilizando 
as melhores práticas aplicadas a determinados domínios sobre as práticas de mudança da organização. 
Além disso, o CMMI fornece um mecanismo de avaliação bem estabelecido de maturidade de processo.
Acesse na plataforma o vídeo: Componentes do CMMI.
Assista
No CMMI você encontrará duas representações, por estágios e contínua. Nessas representações, encon-
tram-se os seguintes componentes (SOMMERVILLE, 2011):
1. Um conjunto de áreas de processo relacionadas às atividades de processos de software. 
O CMMI identifica áreas de processo relevantes para a melhoria e a capacidade de 
processo de software. Essas são organizadas em quatro grupos no modelo CMMI. Na 
representação contínua e na representação por estágios, aparecem em cada um deles.
2. Um número de metas, que são descrições abstratas de um estado desejável a ser atin-
gido por uma organização. O CMMI tem metas específicas, associadas a cada área de 
processo, e define o estado desejável para cada área. Ele também define metas gené-
ricas associadas com a institucionalização das boas práticas.
Qualidade e testes de software | Unidade 3 - CMMI
34
3. Um conjunto de boas práticas, que são as descrições das formas de como alcançar 
uma meta. Várias práticas específicas e genéricas podem ser associadas com cada 
meta dentro de uma área de processo. No entanto, o CMMI reconhece que o mais 
importante é a meta e não a maneira como ela é alcançada. As organizações podem 
usar quaisquer práticas adequadas para atingir qualquer uma das metas do CMMI, pois 
não precisam de fato adotar as práticas recomendadas no próprio CMMI.
Breve introdução ao CMMI, contendo conceitos, definições e motivações.
Título: CMMI: uma visão geral
Link: https://www.devmedia.com.br/cmmi-uma-visao-geral/25425
Aprofunde-se
Por fim, segundo Smith (apud MACHADO, 2016), o CMMI se tornou um veículo popular para a determina-
ção de maturidade de processo de desenvolvimento de software de organizações em diversos domínios.
Esse artigo foca nas razões por trás da adoção do CMMI e inclusive traz 
motivações existentes para o mercado brasileiro de software.
Título: Desmistificando o CMMI
Link: http://asrconsultoria.com.br/index.php/2016/06/22/desmistificando-o-cmmi/
Aprofunde-se
2 REPRESENTAÇÕES DO CMMI
Como você viu, o modelo CMMI possui duas representações: a representação por estágios e a repre-
sentação contínua. Na representação por estágios, o modelo é utilizado para avaliar a capacidade da 
organização como um todo. Na representação contínua, a medição é feita sobre a maturidade das áreas 
de processo específicas dentro da organização.
2.1 REPRESENTAÇÃO POR ESTÁGIOS
A representação por estágios se concentra nas melhores práticas que uma organização pode utilizar 
para melhorar processos das áreas do nível que se deseja atingir. Antes de iniciar a utilização do modelo 
CMMI, os processos da organização devem ser mapeados em relação aos processos e áreas de processo 
do CMMI. Esse mapeamento permitirá controlar a melhoria do processo da organização por meio da 
possibilidade de analisar o nível de conformidade da organização em relação ao modelo. Ressalta-se 
https://www.devmedia.com.br/cmmi-uma-visao-geral/25425
http://asrconsultoria.com.br/index.php/2016/06/22/desmistificando-o-cmmi/
Qualidade e testes de software | Unidade 3 - CMMI
35
que não é necessário que todas as áreas de processo do CMMI mapeiem exatamente um por um 
os processos de uma organização.
Na representação por estágios, há uma sequência de atividades e práticas que deve ser respeitada em 
cada estágio, uma vez que servem de base para se alcançar o estágio seguinte. Cada um dos estágios é 
conhecido por níveis de maturidade (Maturity Levels). Na figura abaixo, você encontrará os cinco níveis 
de maturidade propostos na representação por estágios do CMMI:
Você pode compreender os níveis da representação por estágios da seguinte maneira:
• Nível 1 – Inicial: os processos de uma organização são imprevisíveis, pouco contro-
lados e caóticos.
• Nível 2 – Gerenciado: os processos de uma organização são caracterizados por 
projeto e geralmente as ações são frequentemente reativas.
• Nível 3 – Definido: os processos de uma organização são bem caracterizados e 
compreendidos pela organização (envolvem toda a organização) e são proativos.
• Nível 4 – Gerenciado quantitativamente: aqui os processos de uma organização são 
medidos e controlados.
• Nível 5 – Otimizado: nesse nível, os processos de uma organização estão sob cons-
tante melhoria.
Figura 1 - Níveis de maturidade da 
representação por estágios do CMMI.
Fonte: adaptado de Sommerville (2011).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 3 - CMMI
36
Acesse na plataforma o vídeo: A representação por estágios do CMMI.
Assista
Título: 1 - ISD BRASIL - o que é o nível 1 de maturidade do CMMI
Acesso em: 28/10/2019.
Disponível em: https://youtu.be/kF8sxDDoRns
Aprofunde-se
Comumente, você encontrará organizações avaliadas nos níveis de maturidade do CMMI, sendo referen-
ciadas, por exemplo, como: “a organização X está no nível 3 do CMMI”.
Título: 2 - ISD BRASIL - implementando o CMMI nível 3 de maturidade
Acesso em: 28/10/2019.
Disponível em: https://youtu.be/PiQh_bzoJoc
Aprofunde-se
2.2 REPRESENTAÇÃO CONTÍNUA
Na representação contínua do CMMI, ou CMMI Contínuo, diferentemente da representação por estágios, 
não se tem a maturidade de uma organização medida por níveis preestabelecidos. Nessa representação, 
a maturidade é medida em cada processo individualmente. Para avaliação dos processos, são utilizados 
níveis de capacidade (Capability Levels) (MACHADO, 2016):
• Nível 0 - Incompleto (Ad hoc).
• Nível 1 - Executado (definido): o processo é executado de modo a completar somente 
o trabalho necessário demandado.
• Nível 2 - Gerenciado: é sobre planejar a execução e confrontar o executado contra o 
que foi planejado.
• Nível 3 - Definido: o processo é construído sobre as diretrizes do processo existente e 
é mantida uma descrição do processo.
• Nível 4 - Quantitativamente gerenciado/ Gerido quantitativamente: é quando o 
processo é gerenciado quantitativamente através de estatísticas e outras técnicas.
• Nível 5 - Em otimização (ou otimizado): o processo gerido quantitativamente é alte-
rado e adaptado para atender às necessidades negociais/estratégicas da empresa.
https://youtu.be/PiQh_bzoJoc
Qualidade e testes de software | Unidade 3 - CMMI
37
Acesse na plataforma o vídeo: A representação contínua do CMMI
Assista
Esse artigo se concentra especificamente na representação contínua 
e seus níveis de capacidade de maneira simplificada.
Título: CMMI - Representação Contínua - Níveis de Capacidade
Link: https://bit.ly/375B0z0
Aprofunde-se
Quando uma organização busca apenas melhorar processos específicos, a representaçãocontínua é 
indicada. Por exemplo, em uma organização você poderá encontrar processos tanto no nível de capaci-
dade 1 quanto no nível 4. Talvez por uma decisão interna ou qualquer outro fator, a organização queira 
melhorar apenas o processo que se encontra no nível 1. Na figura abaixo, há um possível perfil de 
avaliação de processo nos diferentes níveis de capacidade da representação contínua. Nessa figura, você 
pode observar que diferentes processos possuem diferentes níveis de capacidade atribuídos.
Figura 2 - Exemplo de um perfil de avaliação de 
processos em níveis de capacidade.
Fonte: adaptado de Sommerville (2011).
https://bit.ly/375B0z0
Qualidade e testes de software | Unidade 3 - CMMI
38
Esse artigo apresenta uma comparação entre as representações do CMMI 
em inglês.
Título: SEI CMMI Representations
Link: https://www.tutorialspoint.com/cmmi/cmmi-representations.htm
Aprofunde-se
3 ÁREAS DE PROCESSO DO CMMI
Acesse na plataforma o vídeo: Áreas de processo.
Assista
Em cada uma das representações do CMMI, existem áreas de processo distribuídas tanto nos níveis de 
maturidade (representação por estágios) quanto nos níveis de capacidade (representação contínua). Uma 
área de processo é o agrupamento de práticas relacionadas a determinado contexto que, quando execu-
tadas de forma coletiva, satisfazem uma série de metas consideradas importantes para alcançar uma 
melhora significativa naquele contexto (ou seja, atingir um certo nível de maturidade) (MACHADO, 2016).
Na tabela abaixo, você poderá visualizar as áreas de processo existentes na representação por estágios. 
Cada nível é composto por uma coleção de áreas de processo.
Nível de maturidade Áreas de processo
Nível 2 - Gerenciado
Gestão de requisitos; 
Planejamento de projeto; 
Monitorização e controle de projeto; 
Gestão do acordo com o fornecedor;
Medição e análise; 
Garantia da qualidade do processo e do produto; 
Gestão de configurações.
Nível 3 - Definido
Desenvolvimento de requisitos; 
Solução técnica; 
Integração do produto; 
Verificação; 
Validação; 
Enfoque no processo organizacional; 
Definição do processo organizacional;
Formação organizacional; 
Gestão integrada do projeto; 
Gestão de risco; 
Integração de equipes; 
Gestão integrada de fornecedores; 
Ambiente organizacional para integração; 
Análise das decisões e resolução.
Nível 4 - Gerenciado quantitativamente
Performance do processo; 
Organizacional;
Gestão quantitativa do projeto.
Nível 5 - Otimizado Inovação e desenvolvimento organizacional; Análise e resolução de causa.
Tabela 1 - Níveis de maturidade da representação por 
estágios do CMMI e suas respectivas áreas de processo.
Fonte: adaptado de Machado (2016).
https://www.tutorialspoint.com/cmmi/cmmi-representations.htm
Qualidade e testes de software | Unidade 3 - CMMI
39
Já em relação à representação contínua, as áreas de processo são divididas por categoria, como pode 
ser visto na tabela a seguir:
Categoria Áreas de processo
Gestão de processos
Enfoque no processo organizacional; 
Definição do processo organizacional; 
Formação organizacional;
Desempenho de processo organizacional; 
Inovação e implementação organizacional.
Gestão de projeto
Planejamento de projeto; 
Monitorização e controle de projeto; 
Gestão do acordo com o fornecedor; 
Gestão integrada do projeto;
Gestão de risco de integração de equipes; 
Gestão integrada de fornecedores; 
Gestão quantitativa do projeto.
Engenharia
Gestão de requisitos; 
Desenvolvimento de requisitos; 
Solução técnica;
Integração do produto; 
Verificação; 
Validação.
Suporte
Gestão de configurações; 
Garantia da qualidade do processo e do produto; 
Medição e análise;
Análise das decisões e resolução; 
Ambiente organizacional para integração; 
Análise e resolução causal.
Esse artigo apresenta uma descrição detalhada de práticas genéricas e 
específicas de cada área de processo do CMMI em inglês.
Título: CMMI - Key Process Areas
Link: https://www.tutorialspoint.com/cmmi/cmmi_process_areas.htm
Aprofunde-se
Por fim, para cada área de processo, como já mencionado, existem metas genéricas e específicas. Na 
tabela abaixo, você pode ver alguns exemplos de metas associadas às áreas de processo:
Meta Área de processo
Ações corretivas são gerenciadas até a conclusão, quando 
o desempenho ou os resultados do projeto se desviam 
significativamente do plano.
Monitoração e controle de projeto (meta específica).
O desempenho atual e o progresso do projeto são monitorados 
frente ao planejamento do próprio projeto.
Monitoração e controle de projeto (meta específica).
Os requisitos são analisados e validados e uma definição da 
funcionalidade requerida é desenvolvida.
Desenvolvimento de requisitos (meta específica).
Causas raiz de defeitos e outros problemas são sistematicamente 
determinados.
Análise causal e resolução (meta específica).
O processo é institucionalizado como um processo definido. Meta genérica.
Tabela 2 - Categorias da representação contínua do 
CMMI e suas áreas de processo associadas.
Fonte: adaptado de Machado (2016).
Tabela 3 - Exemplos de metas para algumas áreas de processo do CMMI.
Fonte: adaptado de Sommerville (2011).
https://www.tutorialspoint.com/cmmi/cmmi_process_areas.htm
Qualidade e testes de software | Unidade 3 - CMMI
40
Essa dissertação de mestrado apresenta um trabalho relevante ao 
mapear as áreas de processo do CMMI em relação a métodos ágeis de 
desenvolvimento em inglês.
Título: Mapping CMMI process areas to agile best practices
Link: https://run.unl.pt/bitstream/10362/60403/1/TGI0186_final.pdf
Aprofunde-se
4 OBTENDO A CERTIFICAÇÃO
A obtenção da certificação CMMI traz consigo uma série de benefícios para a organização que pretende 
adotá-la (PROMOVE, 2018):
• Maior controle produtivo: o objetivo principal da implantação desse modelo é a 
capacidade de monitorar e controlar os processos de desenvolvimento e entrega de 
softwares e serviços. Com isso, a organização que o obtiver terá uma visão geral do 
fluxo produtivo, desde seu planejamento até a execução. Com indicadores compara-
tivos relevantes, facilita o processo de compreensão de onde estão os pontos fortes 
e fracos da sua equipe e de seus projetos, adaptando o desenvolvimento às necessi-
dades encontradas.
• Mais produtividade: processos otimizados e um fluxo simplificado de trabalho vão se 
traduzir em aumento de produtividade no mundo corporativo. Somado a isso, a certifi-
cação CMMI permite a inclusão de uma estrutura inteligente de comunicação interna. 
A empresa tem mais ferramentas para produzir e mais integração para colaborar.
• Iteração constante: nos níveis mais altos do CMMI, o controle da produção é inte-
grado ao trabalho do gestor, facilitando seu trabalho em buscar constantemente a 
melhora de processos e o aumento da produtividade citada anteriormente. Além disso, 
ao mesmo tempo em que se busca otimizar o trabalho de uma equipe, essa mesma 
equipe possui as ferramentas necessárias para otimizar um código, refinar um produto 
ou aprimorar a entrega de um serviço. Por isso a iteração constante é uma vantagem 
competitiva importante para quem trabalha com produtos de softwares.
Em 2007, a empresa Ci&T, especializada em desenvolvimento e outsourcing de 
aplicações, obteve o nível CMMI 5. Para tanto, foi necessário o investimento do 
montante de aproximadamente US$1 milhão. Esse investimento foi necessário 
para um treinamento de quatro anos, com preparação e adequação de processos.
Fonte: https://www.baguete.com.br/noticias/software/13/04/2007/cit-investe-us-1-milhao-na-
conquista-do-cmmi5
Reflita
https://run.unl.pt/bitstream/10362/60403/1/TGI0186_final.pdf
https://www.baguete.com.br/noticias/software/13/04/2007/cit-investe-us-1-milhao-na-conquista-do-cmmi5
https://www.baguete.com.br/noticias/software/13/04/2007/cit-investe-us-1-milhao-na-conquista-do-cmmi5
Qualidade e testes de software | Unidade 3 - CMMI
41
• Agilidade para atender demandas: as demandas de clientes acompanham a velo-
cidadecom que a tecnologia avança. Portanto, as organizações que obtêm sucesso 
nesse mercado são aquelas que identificam e alcançam nichos antes de concorrentes, 
consolidando-se como uma referência entre aquela clientela. Para conseguir atingir 
esse ponto de agressividade, qualquer negócio precisa de uma TI organizada e pronta 
para responder a uma demanda o mais rápido possível. Nesse sentido, a certificação 
CMMI garante que você tenha a inteligência e a otimização de processos necessárias 
para conseguir esse feito.
• Menos riscos no planejamento: se há controle na capacidade produtiva de uma 
organização, os riscos no planejamento são menores. É possível mapear demandas e 
sugerir processos que atinjam seus objetivos gastando-se menos e com qualidade na 
entrega. Previsibilidade é uma das palavras-chave para organizações que buscam a 
certificação em CMMI.
• Maior satisfação do cliente: processos definidos e monitorados, agilidade na resposta 
às demandas e, principalmente, qualidade na entrega ao cliente são as características 
que levam sua organização a satisfazer sua clientela com sucesso. Em um mercado 
acirrado e volátil, essa satisfação significa entregar um produto ou serviço de qualidade 
com preço acessível e que supere expectativas. No caso das concorrências públicas, 
trata-se de uma forma de se destacar como uma solução prática, confiável e segura.
Acesse na plataforma o vídeo: Razões para a certificação.
Assista
Qualidade e testes de software | Unidade 3 - CMMI
42
Aspectos para obtenção
da certificação CMMI 
Há diversos aspectos que devem ser contemplados para a obtenção da certificação CMMI. Tais 
aspectos vão de encontro a um processo rigoroso de avaliação. 
O planejamento da avaliação 
dura em média 3 meses.
A condução da avaliação 
dura de 6 a 8 dias.
Resultado da avaliação: 
ocorre imediatamente após a 
condução da avaliação.
A avaliação tem duração de 3 
anos. Após esse período, é 
necessário realizar uma nova 
avaliação.
Deve ser definido por quem 
deseja obter a certificação de 
qual será o escopo organizacional.
Avaliação
• Coletar dados para entender os 
processos implementados;
• Determinar nível de aderência de um 
processo em relação aos componentes 
do CMMI;
• Determinar grau de satisfação das 
metas investigadas;
• Identificar pontos fortes e fracos do 
processo;
• Atribuir classificação.
1
A avaliação deve ser conduzida 
por um profissional capacitado 
chamado “lead appraiser”. 
2
34
5
6 7
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Infográfico 1 - Aspectos para obtenção da certificação CMMI.
Qualidade e testes de software | Unidade 3 - CMMI
43
Esse artigo apresenta o método SCAMPI em detalhes, método utilizado em 
avaliações do SEI para organizações que almejam a certificação CMMI.
Título: Standard CMMI® Appraisal Method for Process Improvement 
(SCAMPI) Version 1.3b
Link: https://cmmiinstitute.com/resources/standard-cmmi-appraisal-method-
process-improvement-scampi-version-13b-method-definition
Aprofunde-se
Em 2017, a DB1 Global Software, multinacional de tecnologia sediada em Maringá 
(PR), renovou a certificação CMMI Nível 3, emitida pelo CMMI Institute, que 
atesta aderência ao padrão internacional de qualidade de software. A primeira 
certificação foi concedida à DB1 em 2013 e, desde então, vem credenciando a 
empresa ao crescimento nos negócios e à participação em licitações oficiais.
Fonte: https://bit.ly/2q4l53B
Reflita
https://cmmiinstitute.com/resources/standard-cmmi-appraisal-method-process-improvement-scampi-version-13b-method-definition
https://cmmiinstitute.com/resources/standard-cmmi-appraisal-method-process-improvement-scampi-version-13b-method-definition
https://bit.ly/2q4l53B
Qualidade e testes de software | Unidade 3 - CMMI
44
CONSIDERAÇÕES FINAIS
Nesta unidade, você pôde conhecer o modelo CMMI, muito utilizado em organizações de desenvolvi-
mento de software, no intuito de melhorarem seus processos.
Uma vez melhorados seus processos, por consequência a organização ganha reconhecimento no 
mercado, facilitando a captação de novos clientes e solidifica sua marca.
Qualidade e testes de software | Unidade 3 - CMMI
45
GLOSSÁRIO
SEI/CMU: Software Engineering Institute/Carnegie Mellon University.
Qualidade e testes de software | Unidade 3 - CMMI
46
REFERÊNCIAS
MACHADO, Felipe Nery Rodrigues. Análise e Gestão de Requisitos de Software - Onde nascem os 
sistemas. 3. ed. São Paulo: Érica, 2015.
PROMOVE. Certificação CMMI: conheça os benefícios alcançados por empresas brasileiras, 2018. 
Disponível em: https://www.promovesolucoes.com/certificacao-cmmi-conheca-os-beneficios-alcancados-por-
-empresas-brasileiras/. Acesso em: 31 nov. 2019.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011.
https://www.promovesolucoes.com/certificacao-cmmi-conheca-os-beneficios-alcancados-por-empresas-bras
https://www.promovesolucoes.com/certificacao-cmmi-conheca-os-beneficios-alcancados-por-empresas-bras
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
47
Unidade 4 Modelo MPS.br
Objetivo da aprendizagem:
• Apresentar o modelo MPS.br.
Tópicos de estudo:
• O que é o MPS.br;
• Componentes do MPS.br;
• Comparação entre modelos.
Iniciando os estudos:
Seguindo seu estudo no mundo da engenharia de software, com foco na qualidade, você já percebeu que 
a qualidade de um produto de software só pode ser alcançada por meio do aperfeiçoamento e melhoria 
dos seus próprios processos de desenvolvimento.
Para atingir esse objetivo, você pode contar com frameworks, normas e modelos, que fornecem suges-
tões das melhores práticas para a melhoria de processos. Um desses modelos, focando o mercado 
nacional, é o MPS.br.
Nesta unidade, você conhecerá então o modelo MPS.br, seu histórico, motivações e sua estrutura.
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
48
1 O QUE É O MPS.BR
Como você já viu, um dos pilares da engenharia de software é a busca por qualidade. Por meio da 
melhoria dos processos de desenvolvimento, objetiva-se a construção de produtos de qualidade. 
No Brasil, desde 1993, com o Programa Brasileiro de Qualidade e Produtividade de Software (PBQP 
Software), o País tem investido na melhoria de qualidade de software. Porém, a partir de um estudo do 
MIT (Massachusetts Institute of Technology) foi constatado que empresas nacionais que seguiram com 
iniciativas para melhoria de processos de desenvolvimento de software, utilizaram a certificação ISO 
9000, ao invés de outros modelos específicos para software (WEBER, 2006).
De acordo com dados do Ministério da Ciência e Tecnologia, em 2003, 214 empresas que desenvolviam 
software no Brasil tinham certificação ISO 9000 e outras 30 empresas possuíam certificações CMM do 
SEI/CMU. Dessas últimas, a maioria era subsidiária de multinacionais. Em relação às suas certificações, 
24 empresas possuíam certificação nível 2, cinco no nível 3, uma no nível 4 e nenhuma no nível 5 até 
então (WEBER, 2005).
Para facilitar o uso de um modelo específico para software, a Associação para Promoção da Excelência 
do Software Brasileiro, Softex, propôs o projeto MPS.br – Melhoria de Processo de Software Brasileiro. 
O programa iniciou-se em 2003, sob coordenação da Softex, contando com a participação de universi-
dades, indústrias e do governo brasileiro. O principal objetivo do MPS.br é desenvolver e semear um 
modelo de melhoria de processos visando estabelecer um caminho economicamente viável para que 
organizações, incluindo as pequenas e médias empresas (PMEs), alcancem benefícios da melhoria de 
processos e da utilização de boas práticas da engenharia de software em um intervalo de tempo acei-
tável (KALINOWSKI et al., 2011).
Figura 1 - Em 2003, 214 empresas que desenvolviam 
software no Brasil tinham certificação ISO 9000.
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
49
Assim como outros modelos de referência, o MPS.br possui uma página 
web ondeexibe as atuais empresas que possuem níveis de maturidade 
atestados pelo modelo. Essas empresas e seus níveis podem ser vistas no 
endereço https://softex.br/mpsbr/avaliacoes/
Aprofunde-se
O programa tem duas metas a serem alcançadas a médio e longo prazo, a meta técnica e a meta de negó-
cios (SOFTEX, 2016). A meta técnica visa o aprimoramento do programa em si e é composta pelos itens:
A. Guias de modelos de maturidade do MPS;
B. Formação de Instituições Implementadoras (II), credenciadas para prestar serviço de 
consultoria dos modelos do MPS, sendo eles o modelo de referência para software 
(MR-MPS-SW), modelo de referência para serviços (MR-MPS-SV) e modelo de referência 
para gestão de pessoas (MR-MPS-RH);
C. Formação de Instituições Avaliadoras (IA), credenciadas para prestar serviços de 
avaliação, seguindo modelo proposto pelo MPS;
D. Formação de Instituições de Consultoria de Aquisição (ICA), credenciadas para prestar 
serviços de aquisição de software ou serviços relacionados.
Já a meta de negócios, tem por objetivo a disseminação e viabilização dos modelos MPS para a melhoria 
de competitividade das PMEs (como foco principal) e até de grandes organizações privadas e governa-
mentais. É composta por:
A. Criação e aprimoramento do modelo de negócio chamado de MN-MPS;
B. Realização de cursos, provas e workshops MPS;
C. Apoio para organizações que implementaram o modelo MPS;
D. Transparência para as organizações que realizaram a avaliação MPS.
Acesse na plataforma o vídeo: O que é o MPS.br.
Assista
https://softex.br/mpsbr/avaliacoes/
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
50
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Na figura abaixo, você pode ver que o programa MPS.br foi concebido por entidades que utilizaram 
modelos e normas preestabelecidos e também observaram a realidade das empresas brasileiras:
Modelos
e normas
(ISO/IEC, CMM)
Realidade das
empresas
brasileiras
Softex
Governo
Universidades
Este artigo apresenta os resultados de uma pesquisa realizada com o 
objetivo de identificar dificuldades e fatores de sucesso relacionados à 
implementação de processos de software utilizando o MR-MPS e o CMMI.
Título: Dificuldades e Fatores de Sucesso na Implementação de Processos 
de Software Utilizando o MR-MPS e o CMMI
Link: https://www2.unifap.br/furtado/files/2017/04/007.pdf
Aprofunde-se
2 COMPONENTES DO MPS.BR
O modelo MPS possui cinco componentes, como ilustrado na figura abaixo. Como já mencionado no 
tópico anterior, possui o modelo de referência MPS para software (MR-MPS-SW), o modelo de referência 
MPS para serviços (MR-MPS-SV), o modelo de referência MPS para gestão de pessoas (MR-MPS-RH), o 
método de avaliação (MA-MPS) e o modelo de negócio (MN-MPS).
Acesse na plataforma o vídeo: MPS.br e seus componentes.
Assista
Figura 2 -Síntese do MPS.br.
Fonte: adaptado de Weber (2011).
https://www2.unifap.br/furtado/files/2017/04/007.pdf
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
51
Na figura abaixo, você pode ver a composição do modelo MPS e a integração entre seus componentes:
Modelo MPS
ISO/IEC
15504
Modelo de Referência
para Software
MR-MPS-SW
Modelo de Referência
para Serviço
MR-MPS-SV
Guia Geral
de Serviço
Modelo de Referência
para Gestão de Pessoas
MR-MPS-RH
Guia Geral
de Gestão
de Pessoas
Método de Avaliação Modelo de Negócio
MN-MPSMA-MPS
Guia de
Avaliação
Guia Geral
de Software
Guia de
Aquisição
CMMI
ISO/IEC
12207
Documento
do Projeto
O Modelo de Referência para o Processo de Software do MPS (MR-MPS-SW) (SOFTEX, 2016) contém 
todos os requisitos que as organizações devem possuir para serem compatíveis com o modelo MPS. A 
estrutura do modelo é formada por níveis de maturidade que são a combinação entre os processos e 
sua capacidade.
O MR-MPS-SW segue definições contidas nas normas ISO/IEC 12207 e ISO/IEC 15504. Além disso, foi 
construído para ser compatível com o modelo do SEI/CMU CMMI.
O Guia de Aquisição é um documento adicional e complementar que fornece subsídios para organi-
zações que almejem adquirir software e serviços correlatos com base em normas internacionais e em 
práticas sugeridas internacionalmente. Em linhas gerais, esse guia não contém requisitos do MR-MPS, 
mas sim boas práticas de aquisição de software e serviços correlatos.
O Método de Avaliação descreve como seu próprio nome sugere um processo de avaliação. Esse processo 
de avaliação é composto por requisitos para os avaliadores se capacitarem na avaliação em si e também 
descreve os requisitos necessários para que organizações se tornem aderentes ao MR-MPS.
O Modelo de Negócio, por sua vez, contém a descrição das regras de negócio para três domínios: o 
domínio do projeto MPS.br, o domínio das instituições implementadoras do modelo e instituições avalia-
doras e, por fim, o domínio das empresas e organizações que queiram fazer uso do modelo MPS para 
melhorar seus processos de software.
Figura 3 - Modelo MPS.
Fonte: adaptado de Softex (2016).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
52
2.1 MODELO DE REFERÊNCIA MPS PARA SOFTWARE
Como já mencionado, o Modelo de Referência é composto por níveis de maturidade. São ao todo sete 
níveis de maturidade que são sequenciais e acumulativos. Em cada um desses níveis, você encontrará 
processos e suas capacidades.
O progresso nos níveis de maturidade é obtido quando são atendidos todos os resultados, propósitos 
e atributos dos processos relacionados a determinado nível. Na figura abaixo, você pode visualizar a 
estrutura do Modelo de Referência.
Os níveis do MR-MPS são:
• Nível A – Em otimização;
• Nível B – Gerenciado quantitativamente;
• Nível C – Definido;
• Nível D – Largamente definido;
• Nível E – Parcialmente definido;
• Nível F – Gerenciado;
• Nível G – Parcialmente gerenciado.
Figura 4 - Estrutura do MR-MPS.
Fonte: Weber (2011).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
53
Título: Introdução ao nível G do Modelo MPS de Software
Acesso em: 03/11/2019.
Disponível em: https://www.youtube.com/watch?v=TWwTk4Spcgc
Aprofunde-se
O nível inicial é o nível G, mais imaturo, enquanto o nível A é o mais maduro. A graduação em sete níveis 
permite uma implementação e reconhecimento mais gradual de melhoria de processo, facilitando a 
adequação de pequenas e médias empresas, com obtenção de resultados em prazos menores. Dentro 
de cada, tem-se caracterizadas as capacidades do processo que são representadas por um conjunto de 
atributos de processo (AP). A capacidade de processo expressa o grau de refinamento e institucionali-
zação com o processo que é executado na organização ou unidade organizacional.
No MPS.br temos os seguintes atributos de processo:
• AP 1.1 - O processo é executado: o processo realiza o que foi proposto para ele, produ-
zindo os resultados esperados.
• AP 2.1 - O processo é gerenciado: a execução do processo possui alguma gestão.
• AP 2.2 - Os produtos de trabalho são gerenciados: os produtos de trabalho originados 
pelo processo são gerenciados, isto é, produzidos, controlados e mantidos.
• AP 3.1 - O processo é definido: há um padrão a ser seguido e o mesmo apoia a imple-
mentação do processo.
• AP 3.2 - O processo está implementado: o processo, agora padronizado, é de fato 
implementado para atingir os seus objetivos.
• AP 4.1 - O processo é medido: algumas medições são usadas para garantir que o desem-
penho do processo ajude a alcançar os objetivos para o qual esse processo foi proposto.
• AP 4.2 - O processo é controlado: o processo é controlado estatisticamente, permitindo 
se ter previsibilidade, estabilidade e capacidade de execução.
• AP 5.1 - O processo é o objeto de inovações: as mudanças no processo são identificadas 
a partir da análise dos seus indicadores e da investigação de possíveis inovações.
• AP 5.2 - O processo é otimizado continuamente: significa que as mudanças no 
processo têm, de fato, impacto