apostila Qualidade do Software_final

Prévia do material em texto

Brasília-DF. 
Qualidade de Software
Elaboração
Andreza de Sousa Vieira
Produção
Equipe Técnica de Avaliação, Revisão Linguística e Editoração
Sumário
APRESENTAÇÃO ................................................................................................................................. 5
ORGANIZAÇÃO DO CADERNO DE ESTUDOS E PESQUISA .................................................................... 6
INTRODUÇÃO.................................................................................................................................... 8
UNIDADE I
INTRODUÇÃO À QUALIDADE DE SOFTWARE ......................................................................................... 11
CAPÍTULO 1
DEFINIÇÃO DE QUALIDADE DE SOFTWARE .............................................................................. 11
CAPÍTULO 2
QUALIDADE DE PROCESSO E DE PRODUTO DE SOFTWARE ...................................................... 17
CAPÍTULO 3
MÉTRICAS DE SOFTWARE ........................................................................................................ 23
UNIDADE II
QUALIDADE DO PROCESSO DE SOFTWARE .......................................................................................... 30
CAPÍTULO 1
NORMAS ISO 9000 ................................................................................................................ 31
CAPÍTULO 2
NORMA ISO 12207 ................................................................................................................ 36
CAPÍTULO 3
NORMA ISO 15504 ................................................................................................................ 40
CAPÍTULO 4
CMMI – CAPABILITY MATURITY MODEL INTEGRATION ............................................................... 44
CAPÍTULO 5
MELHORIA DE PROCESSO DO SOFTWARE BRASILEIRO – MPS.BR .............................................. 49
UNIDADE III
QUALIDADE DO PRODUTO DE SOFTWARE ............................................................................................ 56
CAPÍTULO 1
NORMA ISO/IEC 9126 ............................................................................................................ 57
CAPÍTULO 2
NORMA ISO/IEC 14598 .......................................................................................................... 61
UNIDADE IV
GARANTIA E CONTROLE DE QUALIDADE .............................................................................................. 72
CAPÍTULO 1
GARANTIA DE QUALIDADE DE SOFTWARE ................................................................................ 73
CAPÍTULO 2
CONTROLE DE QUALIDADE .................................................................................................... 78
REFERÊNCIAS .................................................................................................................................. 82
5
Apresentação
Caro aluno
A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se 
entendem necessários para o desenvolvimento do estudo com segurança e qualidade. 
Caracteriza-se pela atualidade, dinâmica e pertinência de seu conteúdo, bem como pela 
interatividade e modernidade de sua estrutura formal, adequadas à metodologia da 
Educação a Distância – EaD.
Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade 
dos conhecimentos a serem oferecidos, possibilitando-lhe ampliar conceitos 
específicos da área e atuar de forma competente e conscienciosa, como convém 
ao profissional que busca a formação continuada para vencer os desafios que a 
evolução científico-tecnológica impõe ao mundo contemporâneo.
Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo 
a facilitar sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na 
profissional. Utilize-a como instrumento para seu sucesso na carreira.
Conselho Editorial
6
Organização do Caderno 
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em 
capítulos, de forma didática, objetiva e coerente. Eles serão abordados por meio de textos 
básicos, com questões para reflexão, entre outros recursos editoriais que visam a tornar 
sua leitura mais agradável. Ao final, serão indicadas, também, fontes de consulta, para 
aprofundar os estudos com leituras e pesquisas complementares.
A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de 
Estudos e Pesquisa.
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita 
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante 
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As 
reflexões são o ponto de partida para a construção de suas conclusões.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Praticando
Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer 
o processo de aprendizagem do aluno.
7
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Para (não) finalizar
Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem 
ou estimula ponderações complementares sobre o módulo estudado.
8
Introdução
Atualmente, a qualidade é o principal item que o consumidor considera quando 
busca por um produto ou serviço. Ela pode ser entendida como o atendimento das 
necessidades do usuário, seja ele uma pessoa ou uma empresa. Portanto, qualidade 
não significa somente excelência ou um outro atributo de um certo produto final. A 
qualidade dever ser perseguida dentro da organização, pois, certamente, é isto o que os 
usuários esperam de um produto. Podemos perceber que a qualidade de um software é 
um fator crítico para a sobrevivência e o sucesso de qualquer empresa ou organização 
que faz uso dele. 
No intuito de contribuir para a qualidade de um software, o processo de desenvolvimento 
adotado deve ser bem definido e estruturado. Além disso, é importante que ele siga 
alguma norma ou modelo para gestão da qualidade, tais como as normas estabelecidas 
pela ISO. Com o crescimento do setor de software, várias normas e modelos de qualidade 
têm sido propostos ao longo dos últimos anos, as quais têm sido fortemente adotadas 
por organizações em todo o mundo. Um processo de software de qualidade pode reduzir 
o retrabalho, obtendo maior produtividade e diminuindo o tempo de desenvolvimento. 
O processo de desenvolvimento do software irá resultar no produto final do software, 
portanto, a qualidade de um produto de software é o resultado das atividades realizadas 
dentro do processo de desenvolvimento deste. Avaliar a qualidade de um produto de 
software significa verificar, por meio de técnicas e atividades operacionais, o quanto os 
requisitos são atendidos. A avaliação de produto de software tem sido uma das formas 
empregadas por organizações que produzem ou adquirem software para obtenção de 
maior qualidade nestes produtos. Para que a avaliação seja mais efetiva, é importante 
o uso de um modelo de qualidade que permita estabelecer e avaliar requisitos de 
qualidade. São duas as principais normas estabelecidas para a avaliação da qualidade 
do produto de software: ISO/IEC 9126 e ISO/IEC 14598.
Os elementos do sistema de qualidade devem estar estruturadospara estabelecer um 
controle adequado e uma garantia sobre todos os processos operacionais que afetam 
a qualidade do produto ou serviço. O controle de qualidade tem como foco detectar 
e corrigir defeitos antes mesmo do envio dos produtos, enquanto que a garantia de 
qualidade foca na prevenção desses defeitos.
O controle da qualidade é um modelo gerencial que tem como meta a satisfação das 
necessidades das pessoas. Trata-se de um processo e métodos usados para monitorar o 
trabalho e observar se os requisitos estão sendo satisfeitos.
9
Já a garantia da qualidade é um processo sistemático de verificação para certificar-se de 
que a inspeção da qualidade e as operações de controle estão sendo conduzidas de forma 
correta, além de verificar também se os setores de projeto, produção e vendas estão 
trabalhando em conjunto, alinhados a um mesmo objetivo (MALDONADO, 2001).
Objetivos
 » Apresentar definições e conceitos sobre qualidade de software. 
 » Apresentar o que é a qualidade de um processo de software e as principais 
normas e modelos existentes que podem ser adotados no processo. 
 » Apresentar o que é a qualidade de um produto de software e as principais 
normas que podem ser adotadas para avaliar a qualidade deste. 
 » Diferenciar os conceitos de “garantia de qualidade” e “controle de 
qualidade” de um software e entender seus objetivos
10
11
UNIDADE I
INTRODUÇÃO À 
QUALIDADE DE 
SOFTWARE
CAPÍTULO 1
Definição de qualidade de software
O desenvolvimento de software é uma atividade complexa devido a vários motivos, 
principalmente, à demanda pela construção de projetos que combinam múltiplos 
requisitos, envolvendo várias equipes de trabalho. O engenheiro de software deve 
promover a qualidade de seus produtos de software, no entanto, a consolidação das 
práticas de engenharia de software ainda depende dos seguintes fatores:
 » Entendimento do processo de desenvolvimento de software. 
 » Desenvolvimento de uma tecnologia de reuso robusta. 
 » Larga utilização de ferramentas de software. 
 » Estabilidade no gerenciamento de software (métricas).
Não é possível garantir, na prática, o desenvolvimento de um software perfeito para 
resolver um problema complexo. Um software pode conter erros mesmo que atenda 
a suas especificações satisfatoriamente, dado que estas especificações podem estar 
incorretas ou mal definidas. A grande questão é em que momento tornar o software 
operacional e como resguardar seus usuários de erros que poderiam ser evitados. Neste 
contexto, o software difere de outros produtos, em vários aspectos críticos, vejamos 
alguns:
 » Erros graves podem permanecer no software, mesmo depois de testes 
rigorosos, em virtude de sua complexidade lógica. 
 » Estabelecer padrões uniformes de software que possam ser matéria de 
regulamentação e inspeção não é uma tarefa trivial. 
12
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
 » Devido a sua fácil reprodução e usabilidade, o software pode afetar um 
grande e crescente número de indivíduos. 
 » Um software pode ser produzido com uma equipe pequena e com baixo 
custo financeiro, levando não somente à proliferação de fornecedores de 
software, como também a produtos de qualidade inferior.
O software está cada vez mais integrado a nossa vida, nos aplicativos que 
usamos, nos aparelhos eletrônicos, máquinas, dispositivos médicos, carros 
etc. Os softwares nos trazem benefícios e facilitam nossa vida, porém, podem 
apresentar defeitos e causar sérios prejuízos, como por exemplo:
 » Segundo Kiper (2014), uma falha que fez o Facebook ficar fora do ar 
cerca de 20 minutos causa prejuízo de US$ 500 milhões. 
 » Segundo Harada (2014), um bug no Dropbox causa perda de dados 
armazenados na nuvem. 
 » Segundo Gazzarrrini (2014), por conta de um defeito de programação 
no sistema dos seus veículos, a Honda foi obrigada a realizar o recall de 
2,5 milhões de automóveis. 
 » Segundo Gazzarrrini (2014), os hospitais dos EUA utilizavam uma 
máquina chamada Therac-25 para o tratamento com radiação contra 
o câncer (do ano de 1985 até o ano de 1987). Este modelo apresentou 
um problema de programação no seu software, expondo os pacientes 
a uma intensidade de radiação 100 vezes maior do que a recomendada, 
causando a morte de 6 pessoas.
Qual a possível causa desses defeitos? Por que eles, e muitos outros, aconteceram 
e continuam a acontecer? Para responder essas questões, vamos voltar um pouco 
ao passado: houve uma conferência (NATO – North Atlantic Treaty Organization 
– Organização do Tratado do Atlântico Norte) que discutiu sobre os problemas 
que causaram a conhecida “Crise do Software”, na década de 1970. Dentre 
esses problemas, destacamos alguns: cronogramas não cumpridos, projetos 
abandonados, módulos que não operam corretamente quando combinados, 
programas que não fazem exatamente o que era esperado, sistemas tão difíceis 
de usar que eram descartados, sistemas que simplesmente param de funcionar. 
Passados mais de 40 anos, o que mudou? O aspecto não repetitivo do 
desenvolvimento de software torna essa atividade difícil e imprevisível. Delimitar 
o escopo (funcionalidades) de um sistema não é trivial. Além disso, é muito 
13
INTRODUÇÃO À QUALIDADE DE SOFTWARE│ UNIDADE I
comum que os requisitos mudem durante o desenvolvimento de software. Tais 
aspectos afetam diretamente o cronograma (tempo), os custos e a qualidade, 
resultando em falhas e desperdícios que poderiam ser evitados. Pressman (2006), 
estima que os custos relativos para encontrar e reparar um defeito aumentam 
significativamente durante o desenvolvimento do software, ou seja, à medida 
que migramos dos custos de prevenção para os de detecção de falhas internas 
até os de falhas externas. A figura a seguir ilustra esse fenômeno:
Figura 1. Custo relativo para corrigir um erro. 
Fonte: (PRESSMAN, 2006).
Como podemos observar na Figura 1, o custo de corrigir falhas detectadas já na 
fase de requisitos é o mais baixo ao longo de todo o processo de desenvolvimento 
do software. Por outro lado, se uma falha for detectada apenas durante a fase de 
código do projeto, o custo de sua correção é dez vezes maior. Portanto, quanto 
mais cedo as falhas de software forem detectadas, menores são os custos para 
corrigi-las. 
Com estes pontos levantados, podemos perceber que a qualidade de um software é 
um fator crítico para a sobrevivência e o sucesso de qualquer empresa ou organização 
que faz uso dele. Porém, vale ressaltar que qualidade não é sinônimo de perfeição. A 
qualidade é algo factível, relativo, substancialmente dinâmico e evolutivo, ajustando-se 
à granularidade dos objetivos a serem atingidos. Portanto, a qualidade não é absoluta, 
mas depende da perspectiva do avaliador.
Qualidade é um conceito bem complexo, pois tem significados variados para diferentes 
pessoas, em um contexto muito dependente. Portanto, não é trivial haver medidas 
simples de qualidade aceitáveis para todas as pessoas. Para estimar ou melhorar a 
qualidade de um software numa organização é preciso definir as características de 
qualidade que se está interessado e, então, decidir como serão medidas.
14
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
Na literatura, há várias definições para Qualidade de Software sob diferentes 
pontos de vista. Vejamos a seguir a definição dada pelos principais autores da 
área:
A qualidade de software é avaliada em termos de atributos de alto 
nível chamados fatores, que são medidos em relação a atributos 
de baixo nível chamados de critérios (PETERS; e PEDRYCZ, 2001).
Um produto de software apresenta qualidade dependendo do 
grau de satisfação das necessidades dos clientes sob todos os 
aspectos do produto (SANDERS; e CURRAN, 1994).
A qualidade de software é a 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 desenvolvido porprofissionais (PRESSMAN, 2006).
O conceito de qualidade está no equilíbrio de um conjunto de fatores, como 
seguem (CAMPOS, 1990): 
 » Qualidade intrínseca do produto ou serviço: pode ser atestada por 
estar em conformidade com as normas, ou avaliada pela ausência ou 
presença de certos critérios. 
 » Custo: corresponde ao preço, pelo qual o usuário se dispõe a pagar. 
 » Atendimento: pode ser entendido como a satisfação do usuário 
quanto a tempo, espaço e quantidade.
Em resumo, qualidade de software pode ser definida como um conjunto de 
características a serem satisfeitas em um determinado grau, de modo que o software 
satisfaça às necessidades de seus usuários. Para que um software tenha qualidade 
é preciso atender alguns requisitos. Alguns deles são mais visíveis para o usuário 
(são os chamados Requisitos Explícitos), já outros são mais perceptíveis para os 
desenvolvedores (são os chamados Requisitos Implícitos). 
Os requisitos explícitos correspondem a:
 » Boa usabilidade, que expressa a facilidade de uso do software. 
 » Alto grau de confiabilidade, que corresponde à probabilidade que o 
sistema não apresentará falha durante um determinado tempo. Quanto 
maior o tempo médio entre as falhas, maior a confiabilidade do software. 
15
INTRODUÇÃO À QUALIDADE DE SOFTWARE│ UNIDADE I
 » Integridade, que controla o acesso ao sistema. 
 » Cumprimento do prazo de entrega. 
 » Prover informações sobre o progresso, sobre o andamento. 
 » Tempo de atendimento, gasto nas manutenções. 
 » Retorno do Investimento, em forma de benefícios.
Já os requisitos implícitos correspondem a:
 » Flexibilidade, software projetado de forma que seja flexível a mudanças. 
 » Manutenabilidade, software fácil de manter. 
 » Testabilidade, software desenvolvido de forma que seja fácil adicionar e 
executar testes, sem precisar de grandes esforços. 
 » Eficiência, software que executa suas atividades de forma rápida. 
 » Interoperabilidade, que corresponde à facilidade de integração com 
outras partes do sistema. 
 » Reusabilidade, que expressa a capacidade de reaproveitamento do 
software ou partes deste. 
 » Portabilidade, corresponde à possibilidade de poder usar várias 
plataformas. 
 » Exatidão nas estimativas de custo, prazo e esforço.
Um software quando desenvolvido com qualidade tende a oferecer uma série de 
benefícios tanto ao fornecedor do software quanto ao próprio cliente. Vejamos a seguir 
alguns dos benefícios oferecidos ao fornecedor:
 » Aumento da produtividade. 
 » Aumento da precisão nas estimativas. 
 » Redução de defeitos no produto. 
 » Aumento da confiabilidade do produto. 
 » Redução do esforço de retrabalho. 
16
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
 » Redução das horas extras de trabalho. 
 » Redução do tempo para atender o mercado. 
 » Redução de custo de desenvolvimento e manutenção. 
 » Aumento da competitividade. 
 » Aumento do índice de satisfação do cliente/usuário final.
Vejamos agora alguns benefícios oferecidos ao cliente:
 » Auxílio na definição de critérios para seleção e descredenciamento de 
fornecedores. 
 » Auxílio na definição de processos de acompanhamento do progresso e 
desempenho dos fornecedores nas etapas de desenvolvimento, entrega e 
pós-entrega dos produtos. 
 » Auxílio na definição de critérios para avaliação e aceitação dos produtos 
entregues pelo fornecedor.
17
CAPÍTULO 2
Qualidade de processo e de produto 
de software
Com o objetivo de atingir os requisitos de qualidade, surgem duas perspectivas da 
qualidade de software: (1) a qualidade do produto, é o que buscamos; e (2) a qualidade do 
processo, que corresponde à forma utilizada para se conseguir o produto de qualidade. 
A busca por qualidade e produtividade no desenvolvimento de software tem sido intensa 
nesses últimos anos. Porém, ainda não está bem definido como se desenvolver um 
software de qualidade. Com o tempo foi-se percebendo que a avaliação da qualidade e 
a tentativa de corrigir erros no produto, por si só, é insuficiente e limitada para garantir 
a qualidade do software. Atualmente, tem-se percebido que a qualidade do produto 
depende, fortemente, da qualidade e adequação de seu processo de desenvolvimento. 
Portanto, a qualidade do processo passou a ser vista como um pré-requisito e 
condicionante da qualidade do produto de software.
Um aspecto interessante da qualidade de um software é que não basta que ela exista, 
ela deve ser reconhecida pelo cliente. Por causa disso, é necessário que exista algum 
tipo de certificação oficial, emitida com base em um padrão. Hoje em dia, você pode 
consultar normas e padrões tanto para produtos quanto para processos. Obviamente, 
vale ressaltar que os certificados mais valiosos são aqueles que certificam o processo 
de produção de um produto e não aqueles que simplesmente certificam o produto. 
Entretanto, é comum encontrar organizações que adotam os dois tipos de padrão de 
qualidade.
Organismos normativos
Como neste capítulo falaremos de qualidade tanto de processo quanto de 
produto de software, temos que entender o que são os padrões da ISO que tanto 
ouvimos falar quando o assunto é “qualidade”.
A sigla ISO foi criada em 1947 em Genebra, na Suíça, e significa International 
Organization for Standardization (em português: Organização Internacional 
para Padronização). A ISO nada mais é do que uma entidade de padronização 
e normatização. Como podemos notar, a sigla deveria ser IOS ao invés de ISO. 
Contudo, como em cada país existiria uma sigla diferente dependendo da língua 
de origem, os fundadores decidiram escolher uma única sigla para todos os 
18
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
países: ISO. Esta sigla foi escolhida porque do grego a palavra isos significa igual, 
que é exatamente o propósito da padronização e normatização.
Outra sigla que comumente ouvimos falar juntamente com a ISO é a IEC 
(International Electrotechnical Commission), em português, Organização 
internacional de padronização de tecnologias elétricas, eletrônicas e 
relacionadas. Tanto a IEC quanto a ISO são organismos organizados com 
importância internacionalmente reconhecida no setor de softwares, e se uniram 
para editar normas internacionais conjuntas. 
Os padrões da ISO definem especificações técnicas e características para 
garantir que produtos, serviços ou processos estejam em conformidade com 
seus propósitos. Dessa forma, os clientes têm a grande vantagem de adquirir um 
produto (ou contratar um serviço) com a garantia e segurança de que o produto 
adquirido (ou serviço contratado) tem padrões internacionais conhecidos e 
familiares no mundo inteiro.
A ISO tem como objetivos:
 » Organizar a coordenação e unificação das normas1 nacionais e orientar 
os países membros sobre o assunto. 
 » Estabelecer normas internacionais. 
 » Incentivar e facilitar o desenvolvimento de novas normas que sejam 
usadas tanto no domínio nacional quanto internacional. 
 » Organizar o intercâmbio de informações relativas aos trabalhos dos 
países membros e seus comitês técnicos. 
 » Cooperar com organismos internacionais interessados pela 
normalização.
Além da ISO, outros exemplos de organismos normativos que podemos citar 
são: COPANT (Comissão Pan-americana de Normas Técnicas, criada no Brasil), 
ABNT (Associação Brasileira de Normas Técnicas, criada no Brasil), dentre outros. 
A ABNT é o órgão responsável pela normatização técnica no Brasil, fornecendo 
a base necessária ao desenvolvimento tecnológico. Além disso, ela é membro 
fundador da ISO e da COPANT, sendo representante oficial no Brasil de tais 
instituições.
1 Uma norma é um documento elaborado e aprovado de acordo com procedimentos preestabelecidos, resultante do consenso dos interessados.
19
INTRODUÇÃO À QUALIDADE DE SOFTWARE│ UNIDADE I
Qualidade de processo de software
Um processo de software consiste em um conjunto de atividades, métodos, práticas 
e tecnologias que as pessoas utilizam para desenvolvere manter software e produtos 
relacionados. O interesse pelo processo de software está baseado em duas premissas: (1) 
a qualidade do produto de software é fortemente dependente da qualidade do processo 
pelo qual ele é construído e mantido; (2) o processo de software pode ser definido, 
gerenciado, medido e melhorado. 
Um processo bem definido deve estar descrito em detalhes de modo a poder ser usado 
de forma consistente, pois mesmo as melhores pessoas não conseguem trabalhar 
de forma eficiente se o processo é problemático ou mal compreendido. Além disso, 
investimentos em tecnologia sem um guia que defina como utilizá-lo é um desperdício 
de recursos, o processo precisa fazer com que pessoas trabalhem com a tecnologia de 
forma eficaz e eficiente. Sem processos claros e eficientes uma empresa não consegue 
crescer. Neste curso, os processos de software são estudados com mais detalhes na 
disciplina Metodologias de Desenvolvimento de Software. 
A qualidade está presente em um software se ele for desenvolvido em conformidade com 
os requisitos funcionais e não funcionais que devem ser claramente documentados. Para 
que isso seja possível, as fases do processo devem ser bem elaboradas e trabalhadas, 
realizando devidas revisões para uma contínua melhoria e amadurecimento do processo 
e de seus artefatos.
Outra característica importante de um processo de software é que ele vise à diminuição 
de falhas. Portanto, é primordial a elaboração sistemática de casos de teste a fim 
de identificar e corrigir erros já na fase inicial do projeto. Como já mencionamos 
anteriormente, corrigir erros no início do projeto é bem mais barato do que depois de 
entregue. Em outras palavras, entregar um produto de software sem falhas garante a 
confiabilidade, eficiência e integridade do produto.
O número de defeitos presentes no software quando entregue para testes é 
função direta da qualidade do processo usado para a construção do software. 
Porém, um bom processo reduz a presença de defeitos no produto. Sendo assim, 
como identificar se o processo não é bom? Seguem alguns sintomas de falha no 
processo:
 » Compromissos não cumpridos
 › Entregas atrasadas. 
20
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
 › Cortes de última hora. 
 › Custos não planejados. 
 » Falta de visibilidade de gerenciamento em progresso
 › Você está sempre sendo surpreendido. 
 » Problemas de qualidade
 › Muito retrabalho. 
 › Produto não funciona corretamente. 
 › Cliente reclama depois da entrega. 
 » Pouca motivação
 › Pessoas frustradas. 
 › Quem é o responsável?
Muitas organizações buscam uma melhoria contínua e progressiva da qualidade de 
seus processos, atenuando os problemas com o desenvolvimento de seus produtos de 
software. Nesse sentido, o padrão internacional de qualidade ISO 9000 tem despertado 
um grande interesse das organizações, pois é através desse padrão que elas podem 
conquistar sua certificação de qualidade. Essa certificação significa alcançar um padrão 
internacional em seus processos. Da mesma forma, os clientes que adquirem produtos 
e serviços veem nessa certificação um indicador que assegura a qualidade de seus 
fornecedores. ISO 9000 é um grupo de normas técnicas que estabelecem um modelo 
de gestão da qualidade para organizações em geral, de qualquer tipo ou dimensão. 
Além da ISO 9000, há também outras normas e modelos para auxiliar na qualidade do 
processo de software, como por exemplo: ISO/IEC 15504 (SPICE - Software Process 
Improvement and Capability determination), ISO 12207 (Processos do Ciclo de Vida 
do Software), CMMI (Capability Maturity Model Integration), MPS.BR (Melhoria 
de Processo do Software Brasileiro), PSP (Personal Software Process), TSP (Team 
Software Process), TMM (Test Maturity Model).
Qualidade de produto de software
A qualidade do produto é um objetivo do processo de desenvolvimento. Portanto, ao 
desenvolver um produto é necessário ter previamente estabelecidas, como perspectiva, 
21
INTRODUÇÃO À QUALIDADE DE SOFTWARE│ UNIDADE I
as características de qualidade que se deseja alcançar. Para a avaliação da qualidade, as 
organizações internacionais de normalização ISO/IEC definiram as seguintes normas:
 » Características de qualidade e métricas: compreendendo as características 
e subcaracterísticas da qualidade, as métricas externas e as métricas 
internas. 
 » Avaliação dos produtos de software: isto envolve (I) a visão geral do 
produto, (II) o planejamento e o gerenciamento, (III) o processo para 
equipe de desenvolvimento, (IV) o processo para clientes, (V) o processo 
para avaliadores, e (VI) os módulos de avaliação. 
 » Requisitos de qualidade e teste de pacote de software.
O termo “Qualidade de Software” tem sido introduzido ao longo de todo o processo 
de desenvolvimento por meio das atividades de V&V – Verificação e Validação, com o 
objetivo de minimizar a ocorrência de defeitos e riscos associados. Dentre as técnicas 
de verificação e validação, a atividade de teste é uma das mais utilizadas, constituindo-
se em um dos elementos para fornecer evidências da confiabilidade do software em 
complemento a outras atividades.
Mais sobre V&V - Verificação e Validação
Para um estudo mais aprofundado sobre este assunto, sugiro fortemente que 
consulte os seguintes sites: 
<http://www.tmtestes.com.br/uploads/conteudo/49/Artigo2-VVT.pdf>
<http://www.linhadecodigo.com.br/artigo/492/tecnicas-de-vvampt-validacao-
verificacao-e-teste.aspx>
<http://www.revistabw.com.br/concursos/verificacao-e-validacao-de-
software>
Testar um software significa verificar através de uma execução controlada se o seu 
comportamento corresponde ao especificado. O objetivo principal desta tarefa é revelar 
o número máximo de falhas dispondo do mínimo de esforço, ou seja, mostrar aos que 
desenvolvem se os resultados estão ou não de acordo com os padrões/características/
requisitos estabelecidos. O IEEE tem realizado vários esforços de padronização, entre 
eles para padronizar a terminologia utilizada no contexto de Engenharia de Software. O 
padrão IEEE número 610.12 (IEEE, 1990) diferencia os termos básicos utilizados nesta 
22
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
área. Todo o vocabulário da área de testes utilizado neste curso segue a terminologia 
IEEE, portanto, é importante entendermos alguns conceitos principais: 
 » Defeito (fault) – significa passo, processo ou definição de dados incorreta, 
como por exemplo, uma instrução ou comando incorreto. 
 » Engano (mistake) – ação humana que produz um resultado incorreto, 
como por exemplo, uma ação incorreta tomada pelo programador. 
 » Erro (error) – diferença entre o valor obtido e o valor esperado, ou seja, 
qualquer estado intermediário incorreto ou resultado inesperado na 
execução do programa constitui um erro. 
 » Falha (failure) – produção de uma saída incorreta com relação à 
especificação. Neste texto, os termos engano, defeito e erro serão 
referenciados como erro (causa) e o termo falha (consequência) a um 
comportamento incorreto do programa.
Apesar de não ser possível provar a corretude de um programa (se ele está correto) 
por meio de testes, eles contribuem para aumentar a confiança de que o software 
desempenha as funções especificadas e evidenciar algumas características mínimas do 
ponto de vista da qualidade do produto, se forem conduzidos de forma sistemática e 
criteriosa.
Sem um conjunto bem definido de requisitos de qualidade, os projetos de software 
tornam-se vulneráveis a falhas. Para a análise e a robustez de novos projetos de 
software, uma boa dica é a reutilização de requisitos de qualidade de projetos anteriores 
já concluídos, com características semelhantes.
A avaliação de um produto de software tem sido uma das formas empregadas pelas 
organizações que produzem ou adquirem software para obter maior qualidade nestes 
produtos. Para que a avaliação seja mais efetiva é importante a utilização de um modelo 
de qualidade que permita estabelecer e avaliar requisitosde qualidade e também que o 
processo de avaliação seja bem definido e estruturado. 
Existem várias normas de qualidade de produto de software, como por exemplo: ISO/IEC 
9126 (Qualidade de Produto de Software), ISO/IEC 14598 (Guias para Avaliação de Produto 
de Software), ISO/IEC 12119 (Requisitos de Qualidade e Testes de Pacotes de Software) etc.
 
23
CAPÍTULO 3
Métricas de software
Conceitos
Para Pressman (2006), as engenharias precisam de uma maneira de descrever 
objetivamente um objeto e, para tanto, utilizam métricas. Uma métrica fornece 
a indicação quantitativa da extensão, dimensão, capacidade, tamanho ou o 
quanto um objeto possui de um determinado atributo.
O termo “métrica de software” pode ser definido como: (I) uma forma padrão de medir 
um atributo do processo de desenvolvimento de software, segundo Boehm (1981); ou 
(II) uma medida quantitativa do grau que um sistema, componente, ou processo possui 
de um determinado atributo, conforme IEEE Standard 610.12 (1990). Em resumo, uma 
métrica consiste na medição de um atributo (propriedades ou características) de uma 
determinada entidade (produto, processo, recurso etc.). Seguem alguns exemplos de 
atributo: 
 » Tamanho do produto de software (ex.: número de linhas de código). 
 » Número de defeitos encontrados por fase de desenvolvimento. 
 » Esforço para a realização de uma tarefa. 
 » Tempo para a realização de uma tarefa. 
 » Custo para a realização de uma tarefa. 
 » Grau de satisfação do cliente (ex.: adequação do produto ao propósito, 
conformidade do produto com a especificação).
Boehm, Brown e Lipow (1976) definem uma árvore de atributos de qualidade de software 
bem definidos e bem diferenciados (como mostra a Figura 2), em que as direções das 
setas indicam implicações lógicas. Por exemplo, um programa que é fácil de ser mantido 
deve também ser facilmente testado, entendido e modificado.
24
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
Figura 2. Atributos de qualidade definidos por Boehm, Brown e Lipow (1976).
Fonte: <https://www.google.com.br/search?q=As+duas+representa%C3%A7%C3%B5es+do+CMMI&biw=1600&bih=799&so
urce=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMIzveB3eHGxwIVxoKQCh3xwgKR#tbm=isch&q=arvore+de+Atributos+
de+qualidade+definidos+por+Boehm%2C+Brown+e+Lipow+&imgrc=6RPGxsEoaAuH9M%3A>
Por que medir?
Se não soubermos onde estamos, então não conseguiremos saber para onde estamos 
indo e muito menos o que fazer. É preciso saber o que temos, o que somos e onde 
estamos, para poder saber o que fazer hoje e em que direção seguir. No contexto de 
software, queremos medir por vários motivos, dentre os quais podemos destacar:
 » Obter vários indicadores de desempenho consistentes (exemplos: 
produtividade, qualidade do código etc.). 
 » Melhorar a capacidade de estimar projetos, estabelecendo uma base de 
dados para futuras estimativas. 
 » Melhorar a capacidade de gerenciar projetos: (I) estabelecendo orçamento 
para projetos de software; (II) fornecendo meios de controlar os custos 
do projeto; e (III) controlando o progresso do trabalho pela comparação 
do estimado com o realizado. 
 » Melhorar a comunicação com o cliente. 
 » Permitir a comparação com as práticas do mercado. 
25
INTRODUÇÃO À QUALIDADE DE SOFTWARE│ UNIDADE I
 » Avaliar o impacto da introdução de novas tecnologias. 
 » Minimizar o prazo de desenvolvimento. 
 » Medir e quantificar a qualidade do software como produto. 
 » Avaliar a produtividade da equipe envolvida no desenvolvimento do 
software. 
 » Avaliar os benefícios derivados de novos métodos e ferramentas da 
engenharia de software para desenvolver software.
Medição, medida, métrica e indicador. Qual 
a diferença?
Medição: é o ato de medir, de determinar uma medida. Está diretamente ligada 
à quantificação de dados, ou conjunto de dados, relacionada com dimensões de 
qualidade (exemplos: medir exatidão, plenitude e consistência).
Medida: é um valor real, quantidade, dimensão, capacidade ou tamanho de 
algum atributo. Por exemplo, “50” pode ser um exemplo de medida resultante 
do atributo “número de erros encontrados no software”. 
Métrica: é um atributo (propriedade ou característica) mensurável de uma 
entidade (produto ou processo). No caso de um projeto, uma métrica pode ser, 
por exemplo, o seu tamanho, uma vez que pode ser medido. 
Indicador: é a informação relacionada a uma medida, métrica ou combinação de 
métricas, que pode ser utilizada para compreender a entidade que está sendo 
medida. Um engenheiro de software coleta medidas e desenvolve métricas de 
modo que indicadores sejam obtidos para fornecer uma visão ampliada que o 
permita ajustar o processo, projeto ou produto de software visando melhorias. 
Por exemplo, comparando duas métricas, chega-se a uma conclusão que permite 
embasar uma tomada de decisão.
Em resumo, quando um atributo é coletado (por exemplo, o número de erros 
encontrados em um componente do software), uma medida é estabelecida. 
A medição ocorre como resultado da junção de um ou mais atributos (por 
exemplo, um certo número de revisões de componente e testes de unidade 
são investigados para coletar medidas do número de erros em cada um). Uma 
métrica de software relaciona as medidas individuais de alguma forma (por 
exemplo, o número médio de erros encontrados por revisão ou o número médio 
26
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
de erros encontrados por teste de unidade). Um indicador pode ser usado, por 
exemplo, para verificar se o número médio de erros encontrados por revisão 
do componente de software está dentro do limite máximo aceitável. Caso não 
esteja, uma decisão pode ser tomada de forma a melhorar o resultado.
Características desejáveis para uma métrica
Centenas de métricas de software têm sido propostas, mas nem todas elas fornecem 
apoio prático ao engenheiro de software. Algumas exigem medições que são muito 
complexas, e outras são tão restritas que poucos profissionais conseguem entender. Não 
se pode medir um software de qualquer maneira, é preciso que as métricas possuam 
características que ajudem a obter resultados interessantes. Para isso, é importante que 
uma métrica seja:
 » Analisável: facilmente calculada, entendida e testada. 
 » Válida: as medidas devem verificar o modelo funcional. 
 » Robusta: as medidas não devem ser sensíveis a alterações que não afetam 
os atributos. 
 » Simples: devem-se obter medidas de fácil interpretação. 
 » Prescritiva: a métrica deve ser útil para orientar a gestão dos projetos de 
desenvolvimento, sendo passível de estudos estatísticos. 
 » Expressa em alguma unidade. 
 » Passível de automação. 
 » Repetível e independente do observador.
Em resumo, uma métrica deve ser: (I) válida, isto é, ela quantifica o que queremos medir; 
(II) confiável, isto é, ela produz os mesmos resultados dadas as mesmas condições; e 
(III) prática, barata, fácil de computar e fácil de interpretar. Nos contextos de medição 
de software, uma métrica para o processo de desenvolvimento de um software seria a 
produtividade, e uma métrica para produto seria a qualidade deste.
É importante destacar que os resultados produzidos pelas métricas precisam ser 
interpretados no contexto da medição. Além de atender a uma série de características 
desejáveis, é importante que o engenheiro de software esteja atento a possíveis 
problemas que podem estar presentes nas métricas por ele definidas. Por exemplo, se a 
27
INTRODUÇÃO À QUALIDADE DE SOFTWARE│ UNIDADE I
métrica tem por objetivo comparar a produtividade de engenheiros em termos de linha 
de código, então é importante responder as seguintes questões:
 » Está sendo adotada a mesma unidade de medida?
 › O que é uma linha de código válida? 
 » O contexto considerado é o mesmo?
 › Todos os engenheiros são familiarizados com a linguagem de 
programação?
 » O que se quer realmente é o tamanho do código?
 › E a qualidade do código?
 » Como o resultado será interpretado?
 › Produtividade médiade um engenheiro?
 » O que se quer com o resultado?
 › Comparar a produtividade dentro do processo de software?
Tipos de métricas
Segundo a ISO e a maioria dos autores da área, como Pressman e Sommerville, 
as métricas de software são divididas como mostra a Figura 3. Cada uma dessas 
classificações é explicada a seguir:
Figura 3. Classificação das métricas de software. 
.
Fonte: Figura adaptada da NORMA ISO.
28
UNIDADE I │ INTRODUÇÃO À QUALIDADE DE SOFTWARE
 » Métricas de processo: avaliam se o que está sendo feito segue o planejado, 
ou seja, se o processo está sendo executado como deveria e qual a qualidade 
que está sendo mantida em sua execução. As métricas de processo se 
subdividem em três tipos de métricas, como seguem.
 › Métricas de produtividade: concentram-se na saída do processo de 
desenvolvimento com o objetivo de avaliá-lo. Exemplo: número de 
casos de uso/iteração. 
 › Métricas de qualidade: oferecem uma indicação de quão próximo o 
software está em conformidade com as exigências implícitas e explícitas 
do cliente. Exemplo: erros por fase de desenvolvimento. 
 › Métricas técnicas: concentram-se nas características do software e 
não no processo por meio do qual este foi desenvolvido. Exemplos: 
complexidade lógica e grau de manutenibilidade.
 » Métricas de produto: avaliam o produto, verificando se ele foi feito 
conforme deveria, ou seja, com a qualidade desejada. Dessa forma, os 
gerentes de projeto podem se utilizar dessas métricas para adaptar o 
processo de desenvolvimento de software e as atividades técnicas de 
acordo com os requisitos do projeto.
Quanto à forma de medição, as métricas de produto podem ser classificadas em duas 
categorias: 
 › Métricas diretas: medida realizada em termos de atributos observados 
(usualmente determinada pela contagem). Exemplos: custo, esforço, 
número de linhas de código (LOC), tamanho de memória ocupado, 
velocidade de execução, número de erros registrados em um dado 
período de tempo etc.
 › Métricas indiretas: medidas obtidas a partir de outras métricas. 
Exemplos: permitem quantificar aspectos como funcionalidade, 
complexidade, eficiência, confiabilidade, manutenibilidade etc.
Quanto à fase, as métricas de produto podem ser classificadas em duas categorias: 
 › Métricas internas: são aplicadas ao produto não executável, durante 
as fases de arquitetura e codificação do projeto. O objetivo primário 
dessas métricas é garantir que a qualidade seja alcançada já nas fases 
iniciais do projeto, antes do produto de software estar pronto. 
29
INTRODUÇÃO À QUALIDADE DE SOFTWARE│ UNIDADE I
 › Métricas externas: medem o produto de software por meio do seu 
comportamento, com o objetivo de informar aos usuários, avaliadores 
e desenvolvedores que a qualidade que eles buscam no software é 
alcançada durante a execução.
Além desta classificação, as métricas de software ainda podem ser organizadas em 
outras classes, como:
 › Métricas orientadas ao tamanho: são medidas diretas do tamanho 
dos artefatos de software associados ao processo por meio do qual o 
software é desenvolvido. Exemplos: esforço, custo, número de linha 
de código (KLOC), número páginas de documentação, número e erros. 
 › Métricas orientadas à função: são baseadas em medidas indiretas do 
software e no processo utilizado para obtê-lo, onde são considerados 
os aspectos como a funcionalidade e a utilidade do programa como 
pontos de função (function points) e pontos de particularidade (feature 
points). 
 › Métricas orientadas às pessoas: indicam a forma como as pessoas 
desenvolvem os sistemas de computador e também medidas da 
percepção humana sobre a eficiência de ferramentas e métodos de 
desenvolvimento.
Aprenda mais detalhes sobre os tipos de métricas de software no seguinte site:
<http://www.linhadecodigo.com.br/artigo/102/metricas-e-estimativas-de-
software-o-inicio-de-um-rally-de-regularidade.aspx>
30
UNIDADE II
QUALIDADE DO 
PROCESSO DE 
SOFTWARE
Um processo de software bem definido é de extrema importância, pois a partir dele 
é possível estabelecer um plano para o desenvolvimento do projeto. Um processo 
de software de qualidade pode reduzir o retrabalho, obtendo maior produtividade 
e diminuindo o tempo de desenvolvimento. Dessa forma, há um aumento da 
competitividade entre companhias que obtêm maior precisão nas estimativas de 
planejamento. Um dos benefícios indiretos da qualidade está relacionado à melhoria 
da satisfação do cliente e condições de trabalho.
O processo, que irá resultar no produto de software, concentra seus esforços na busca 
pela qualidade do “modo de produção e manutenção” deste, enquanto que a qualidade 
deste produto é focada no produto final, através da constatação de sua qualidade por 
avaliações no software já acabado.
Com o crescimento do setor de software, várias normas e modelos de qualidade têm 
sido propostos ao longo dos últimos anos. Essas normas e modelos têm sido fortemente 
adotados por organizações em todo o mundo. Esta unidade abordará as principais e 
mais importantes normas e modelos para processos de software.
31
CAPÍTULO 1
Normas ISO 9000
Nos dias de hoje é necessário que as empresas adotem um sistema de gestão de 
qualidade, pois a empresa que atua sob um sistema deste tipo fornece aos seus clientes 
uma evidência tangível da sua preocupação com a qualidade, principalmente, quando 
se deseja manter a qualidade já alcançada.
Dentro desse sistema de gestão de qualidade, os clientes e fornecedores de todo o mundo 
devem usar o mesmo vocabulário. Caso contrário, ocorreriam problemas do tipo: 
uma empresa fornecedora do México possui um tipo de gestão de qualidade próprio 
que, além disso, utiliza um vocabulário diferente do utilizado pela possível empresa 
compradora inglesa que tem conhecimento somente das normas de gestão da qualidade 
britânicas BS5750. Portanto, o cliente inglês tem de se inteirar do sistema de gestão da 
qualidade do fornecedor mexicano em questão, o que significa uma perda de tempo e 
de dinheiro. Para evitar esse tipo de conflito, foram estabelecidas as normas ISO, que 
são normas internacionais sobre sistemas de gestão da qualidade. A abordagem da ISO 
para qualidade é considerada uma das mais antigas e estabelecidas para a indústria em 
geral e tem aceitação nas empresas de software.
Que são normas ISO 9000?
As normas ISO 9000 são um conjunto de normas da ISO que define padrões para 
garantia e gerenciamento da qualidade. Em sua abrangência máxima, a série ISO 
9000 engloba pontos referentes à garantia da qualidade em projeto, desenvolvimento, 
produção, instalação e serviços associados. O objetivo é a satisfação do cliente pela 
prevenção de não conformidades em todos os estágios envolvidos no ciclo da qualidade 
da empresa.
Os princípios básicos das normas da série ISO 9000 são: (I) organização com 
documentação acessível; (II) agilidade; (III) equipamentos limpos e em bom estado. 
Um dos aspectos mais importantes é o da auditoria interna. A empresa deve ser 
constantemente auditada para descobrir defeitos e promover as ações preventivas e 
corretivas para que eles não se repitam. Enfim, vai montar um sistema de qualidade 
que faça com que o empregado não se perca dentro da sua própria função. Dessa forma, 
a empresa terá condições de atender à demanda, sabe onde estão as coisas, tem tudo 
documentado e, acima de tudo, tem uma administração que está comprometida com a 
qualidade.
32
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
A procura pela certificação da série ISO 9000 é um dos pontos que mais motiva o 
atual movimento em relação à qualidade em todas as áreas de atividades econômicas, 
incluindo o software. Ela incentivou praticamente todas as iniciativas em qualidade de 
software.
É importante saber que as normas da série ISO 9000 não dizem respeito apenas 
ao sistema de gestão da qualidade de uma empresa, e não às especificações 
dos produtos fabricados por ela. Portanto, mesmo que um produto tenha sido 
fabricado de acordo com umprocesso certificado segundo as normas ISO 9000, 
isso não significa que este produto terá maior ou menor qualidade que um outro 
similar. Isto significa apenas que todos os produtos fabricados de acordo com 
este processo apresentarão as mesmas características e o mesmo padrão de 
qualidade. 
Portanto, as normas ISO não conferem qualidade extra a um produto/serviço, 
mas garantem apenas que o produto/serviço apresentará sempre as mesmas 
características. Ter a certificação ISO 9000 não significa que o seu produto é 
o melhor do mundo, significa que você tem uma empresa bem organizada e 
voltada à qualidade.
As empresas que adotam os regulamentos da ISO 9000 têm mais credibilidade 
em relação a outras empresas e aos seus clientes, uma vez que suas normas 
foram elaboradas por representantes de diversos países do mundo inteiro. Se 
a empresa adotar as normas ISO série 9000 e dispuser de documentação que 
comprove isto, ela demonstrará que administra com qualidade e, portanto, 
garante qualidade de seus produtos e serviços.
Vejamos algumas das normas da série ISO 9000 no quadro 1 a seguir:
Quadro 1. Normas ISO 9000.
Norma: Trata de:
ISO 9001 Modelo para garantia da qualidade em projeto, desenvolvimento, produção, instalação e assistência técnica.
ISO 9002 Modelo para garantia da qualidade em produção e instalação.
ISO 9003 Modelo para garantia da qualidade em inspeção e ensaios finais.
ISO 9000-1 Diretrizes para escolher entre as normas ISO 9001, 9002 e 9003.
ISO 9000-3 Orientação para a aplicação da ISO 9001 em software.
Fonte: (BARRETO, 2015).
As normas ISO 9001, 9002 e 9003 se aplicam em situações contratuais, que exijam 
demonstração de que a empresa fornecedora é administrada com qualidade. Dentre 
as normas 9001, 9002 e 9003, a primeira é a mais adequada ao desenvolvimento e 
33
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
manutenção de software. Como toda norma da ISO, ela é usada para garantir que um 
fornecedor atenda aos requisitos especificados nos diversos estados do desenvolvimento, 
que incluem projeto, desenvolvimento, produção, instalação e suporte. 
A norma ISO 9000-1 funciona como um mapa de orientação para toda a série ISO 9000. 
A ISO 9000-1 explica o papel de cada uma das normas da série ISO 9000 e discute 
conceitos básicos para toda a série. Esta norma é aplicada no intuito de qualificar os 
softwares produzidos e utilizados nas empresas, se eles são qualificados para produzirem 
determinados produtos solicitados pelos seus clientes, se eles realmente atendem todos 
os requisitos apresentados para se obter a sua certificação. Alguns dos seus requisitos 
para a gerência da empresa são: padronização, redução de custos, resultados, eficácia 
dos procedimentos, envolvimento de pessoas, maior organização e qualidade de seus 
produtos.
A norma ISO 9000-3 (não confunda com a ISO 9003) estabelece diretrizes para aplicar 
a ISO 9001 especificamente na área de desenvolvimento, fornecimento e manutenção 
de software. A ISO 9001 é um padrão internacional que especifica requisitos para um 
sistema gerencial de qualidade de uma organização, o que dificulta a adaptação da 
norma para o contexto de software, pois é aplicada a qualquer organização. A ISO 9001 
é aplicável a empresas em geral que atuam em projeto, desenvolvimento, produção, 
instalação e assistência técnica. Como os documentos da série ISO 9000 são genéricos, 
então foi necessária a elaboração de um documento complementar que abordasse 
aspectos importantes e específicos no contexto de software. Por este motivo que foi 
criada a ISO 9000-3.
As diretrizes estabelecidas ISO 9000-3 englobam questões como o entendimento 
comum entre as partes (contratante e contratado) de requisitos funcionais e o uso de 
metodologias consistentes para o desenvolvimento de software e gerenciamento de 
projeto como um todo, da concepção até a manutenção. Veja no quadro 2 os grupos de 
processos e atividades definidas na ISO 9000-3:
34
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
Quadro 2. Grupos de processos e atividades da Norma ISO 9000-3. 
Grupo: Atividade:
Estrutura do Sistema de Qualidade
 » Responsabilidade do fornecedor.
 » Responsabilidade do comprador.
 » Análise crítica conjunta.
Atividades do Ciclo de Vida
 » Análise crítica do contrato.
 » Especificação dos requisitos do comprador.
 » Planejamento do desenvolvimento.
 » Projeto e implementação.
 » Testes e validação.
 » Aceitação.
 » Cópia, entrega e instalação.
 » Manutenção.
Atividades de Apoio
 » Gerenciamento de configuração.
 » Controle de documentos.
 » Registros da qualidade.
 » Medição.
 » Regras, convenções.
 » Aquisição.
 » Produto de software incluído.
 » Treinamento.
Fonte: (BARRETO, 2015).
O processo de certificação de uma empresa de software, de acordo com as normas ISO 
9001/9000-3, segue um conjunto de passos bem definidos como apresentados a seguir 
(BARRETO, 2015):
 » A empresa estabelece o seu sistem a de qualidade. 
 » A empresa faz uma solicitação formal a um órgão certificador, incluindo 
detalhes do negócio da empresa, escopo da certificação solicitada e cópia 
do manual de qualidade. 
 » O órgão certificador faz uma visita à empresa, colhe mais dados e explica 
o processo de certificação. 
 » O órgão certificador verifica se a documentação do sistema de qualidade 
está de acordo com a norma ISO. 
 » O órgão certificador envia uma equipe à empresa com fins de auditoria. 
Nesta visita, será verificado se todos na empresa cumprem o que está 
documentado no manual de qualidade. 
 » O órgão certificador emite o certificado de qualidade. 
35
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
 » O órgão certificador realiza visitas periódicas à empresa para assegurar 
que o sistema continua sendo efetivo.
Características principais
A série ISO 9000 incorpora as seguintes características:
 » Envolve a alta administração: é muito comum perceber que, nas empresas, 
o esforço da qualidade é colocado nas mãos de uma chefia de controle da 
qualidade ou similar. Desta forma, a alta administração abre mão das 
suas responsabilidades em relação ao assunto. A ISO 9000 as obriga a 
participar do Sistema da Qualidade. 
 » O sistema é realimentado: a ISO 9000 exige que o sistema da qualidade se 
aperfeiçoe constantemente por meio de ações corretivas sobre problemas 
detectados pelo próprio sistema (p.ex., com auditorias internas). 
 » O sistema é formalizado: a ISO 9000 obriga que as atividades pertencentes 
ao sistema da qualidade sejam documentadas como forma de sedimentá-
lo em bases sólidas e passíveis de verificação. Este aspecto é extremamente 
importante para fins de uma auditoria de certificação por uma entidade 
ou por um cliente.
36
CAPÍTULO 2
Norma ISO 12207
Sob o título de Tecnologia da Informação - Processos de Ciclo de Vida de Software, a ISO 
12207 foi criada para estabelecer uma estrutura comum de processos, sendo utilizada 
como referência em negócios relacionados a produtos de software. Ela estabelece os 
processos, atividades e tarefas a serem aplicadas durante a aquisição, fornecimento, 
desenvolvimento, operação e manutenção do software. Ela apresenta uma definição 
abrangente em relação aos processos, e orienta a adaptação para sua utilização nos 
projetos de software implementados numa organização.
Esta norma possui mais de 60 páginas e detalha os diversos processos envolvidos no 
ciclo de vida do software. Estes processos estão divididos em três classes: Processos 
fundamentais, Processos de apoio e Processos organizacionais. A norma detalha cada 
um destes processos. Ela define ainda como eles podem ser usados de diferentes 
maneiras por diferentes organizações (ou parte destas), representando diversos pontos 
de vista para esta utilização. Cada uma destas visões representa a forma como uma 
organização emprega estes processos, agrupando-os de acordo com suas necessidades 
e objetivos. A Figura 4 mostra esses processos com seus possíveis usuários. Vejamos 
detalhes de cada um dos processosnas próximas seções.
Figura 4. Visão geral dos processos – ISO 12207. 
Fonte: (TSUKUMO et al., 1997).
37
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
A principal finalidade da Norma 12207 é servir de referência para os demais 
padrões que venham a surgir. Lançada em agosto de 1995, ela é citada em quase 
todos os trabalhos relacionados à Engenharia de Software desde então, inclusive 
aqueles relativos à qualidade. A futura norma ISO 15504 (SPICE), por exemplo, 
organiza seu trabalho de acordo com o que está descrito na Norma 12207.
Processos fundamentais
Os processos fundamentais da Norma 12207 marcam o início e execução do 
desenvolvimento, operação ou manutenção de um software durante o seu ciclo de vida 
(SALGUEIRO; e ARTE, 2005). Vejamos a seguir:
 » Processo de aquisição: define atividades de quem adquire um software. 
Inclui a definição da necessidade de adquirir um software (produto ou 
serviço), o pedido de proposta, a seleção de fornecedor, a gerência da 
aquisição e a aceitação do software ou serviço de software. 
 » Processo de fornecimento: define as atividades do fornecedor de software, 
ou seja, organização que provê o produto de software ao comprador. 
Inclui preparar uma proposta, a assinatura de contrato, determinação 
de recursos necessários, o desenvolvimento e a execução dos planos de 
projeto, até a entrega do software. 
 » Processo de desenvolvimento: define as atividades do desenvolvedor 
de software. Inclui a análise de requisitos, o projeto, a codificação, a 
integração, os testes, a instalação e a aceitação do software. 
 » Processo de operação: define as atividades do operador. Inclui a operação 
de um sistema computacional para os usuários, assim como também o 
suporte operacional. 
 » Processo de manutenção: define as atividades do mantenedor do 
software, isto é, gerenciamento de modificações no software para mantê-
lo atualizado e em perfeita operação. Quando um sistema necessita de 
alterações relativas à melhoria, adaptação, ou qualquer alteração no 
código, esse processo é ativado. Em qualquer situação, sua integridade 
deve ser preservada.
38
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
Processos de apoio
Os processos de apoio da Norma 12207 auxiliam um outro processo e contribuem para 
o sucesso e qualidade do projeto de software. São empregados e executados, quando 
necessário por outros processos (SALGUEIRO; ARTE, 2005). Vejamos a seguir:
 » Processo de documentação: define as atividades para registrar informações 
produzidas por um processo ou atividade do ciclo de vida. O processo 
contém o conjunto de atividades que planeja, projeta, desenvolve, 
produz, edita, distribui e mantém os documentos necessários a todos os 
interessados, tais como gerentes, engenheiros e usuários do sistema ou 
produto de software. 
 » Processo de gerência de configuração: define atividades que identificam 
e controlam os itens do software. Inclui o controle de armazenamento, 
liberações, manipulação, distribuição e modificação de cada um dos itens 
que compõem o software, estabelecendo suas linhas básicas. Além disso, 
garante a completeza, a consistência e a correção dos itens. Também 
controla o armazenamento, a manipulação e a distribuição dos itens. 
 » Processo de garantia da qualidade: define as atividades para garantir que 
os processos e produtos de software estejam em conformidade com os 
requisitos e os planos estabelecidos. 
 » Processo de verificação: define as atividades para verificação dos produtos 
de software, se estes estão atendendo aos requisitos especificados e às 
condições impostas a eles. 
 » Processo de revisão conjunta: define as atividades para avaliar a situação 
e os produtos de uma atividade de um projeto, se apropriadas. Estas 
avaliações ou revisões são realizadas nos níveis gerenciais do projeto e 
nos níveis técnicos, durante o contrato do projeto. 
 » Processo de auditoria: define as atividades para determinar adequação 
aos requisitos, planos e contrato, quando for apropriado. 
 » Processo de resolução de problemas: define um processo para 
analisar e resolver os problemas descobertos durante a execução do 
desenvolvimento, operação, manutenção ou outros processos.
39
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
Processos organizacionais
Os processos organizacionais da Norma 12207 são utilizados com o intuito de melhorar, 
continuamente, a estrutura e os processos do ciclo de vida do software (SALGUEIRO ; 
ARTE, 2005). Vejamos a seguir:
 » Processo de gerência: define as atividades que podem ser empregadas por 
quaisquer das partes que têm que gerenciar seu respectivo processo. Inclui 
gerenciamento de produto, gerenciamento de projeto e gerenciamento 
de tarefa do processo de apoio. 
 » Processo de infraestrutura: atividades que visam estabelecer o fornecimento 
de recursos necessários para outros processos. Inclui hardware, software, 
ferramentas, técnicas, padrões de desenvolvimento, operação ou 
manutenção. 
 » Processo de melhoria: define as atividades para estabelecer, avaliar, 
medir, controlar e melhorar um processo de ciclo de vida de software. 
 » Processo de treinamento: define um conjunto de atividades para prover 
e manter o pessoal treinado. Inclui planejamento e implementação de 
programas de treinamento.
40
CAPÍTULO 3
Norma ISO 15504
A Norma ISO 15504, também conhecida como SPICE (Software Process Improvement 
and Capability dEtermination), é um padrão para a avaliação do processo de software, 
visando determinar a capacitação de uma organização. A norma visa ainda orientar a 
organização para uma melhoria contínua do processo. Ela cobre todos os aspectos da 
Qualidade do Processo de Software.
O SPICE pode ser adotado em organizações envolvidas em planejar, gerenciar, 
monitorar, controlar e melhorar a aquisição, fornecimento, desenvolvimento, operação, 
evolução e suporte de software. Dentro da visão do SPICE, como mostra a Figura 5, a 
avaliação de processos de software tem como objetivos (TSUKUMO et al., 1997):
 » Entender o estado dos processos de uma organização para sua melhoria. 
 » Determinar a adequação dos processos de uma organização para um 
requisito particular ou uma classe de requisitos. 
 » Determinar a adequação dos processos de uma outra organização para 
um determinado contrato ou para uma classe de contratos.
Figura 5. Avaliação de processo de software – SPICE (TSUKUMO et al., 1997).
Fonte: <https://www.google.com.br/search?q=As+duas+representa%C3%A7%C3%B5es+do+CMMI&biw=1600&bih=
799&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMIzveB3eHGxwIVxoKQCh3xwgKR#tbm=isch&q=Vis
%C3%A3o+geral+dos+processos+%E2%80%93+ISO+12207+(TSUKUMO+et+al.%2C+1997).&imgrc=OKVYoVew0cHn
dM%3A>
41
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
No contexto de melhoria de processos, avaliar significa caracterizar as práticas atuais 
de uma empresa ou organização. A análise dos resultados é feita considerando as 
necessidades de negócio da empresa/organização, identificando aspectos positivos 
e negativos, bem como os riscos associados aos processos. Dessa forma, é possível 
determinar se os processos estão atingindo efetivamente seus objetivos e também 
é possível identificar as causas da baixa qualidade, alto custo ou tempo excessivo, 
indicando a priorização na melhoria dos processos.
Categorias e processos
O SPICE estabelece um modelo de referência, que serve de base para o processo de 
avaliação. Trata-se de um conjunto padronizado de processos fundamentais, que 
orientam para uma boa engenharia de software. Este modelo de referência é dividido 
em cinco grandes categorias de processo: 
 » Cliente-fornecedor: processos que impactam diretamente os produtos e 
serviços de software no fornecedor para o cliente. 
 » Engenharia: processos que especificam, implementam ou mantêm um 
sistema ou produto de software e sua documentação. 
 » Suporte: processos que podem ser empregados por qualquer um dos 
outros processos. 
 » Gerência: processos que contêm práticas de naturezagenérica que podem 
ser usados por quem gerencia projetos ou processos dentro de um ciclo 
de vida de software. 
 » Organização: processos que estabelecem os objetivos de negócios da 
organização.
Cada categoria é detalhada em processos mais específicos. Tudo isso é descrito em 
detalhes pela norma. Observe no quadro 3 a estrutura completa das categorias e dos 
processos de cada categoria.
42
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
Quadro 3. Modelo de referência de processos do SPICE – Norma ISO 15504 .
Categorias de Processo: Sigla: Processos:
Cliente-Fornecedor
CUS.1 Adquirir software.
CUS.2 Gerenciar necessidades do cliente.
CUS.3 Fornecer software.
CUS.4 Operar software.
CUS.5 Prover serviço ao cliente.
Engenharia
ENG. 1 Desenvolver requisitos e o projeto do sistema.
ENG. 2 Desenvolver requisitos de software.
ENG. 3 Desenvolver o projeto do software.
ENG. 4 Implementar o projeto do software.
ENG. 5 Integrar e testar o software.
ENG. 6 Integrar e testar o sistema.
ENG. 7 Manter o sistema e o software.
Suporte
SUP. 1 Desenvolver a documentação.
SUP. 2 Desempenhar a gerência de configuração.
SUP. 3 Executar a garantia da qualidade.
SUP. 4 Executar a verificação dos produtos de trabalho.
SUP. 5 Executar a validação dos produtos de trabalho.
SUP. 6 Executar revisões conjuntas.
SUP. 7 Executar auditorias.
SUP. 8 Executar resolução de problemas.
Gerência (Management)
MAN. 1 Gerenciar o projeto.
MAN. 2 Gerenciar a qualidade.
MAN. 3 Gerenciar riscos.
MAN. 4 Gerenciar subcontratantes.
Organização
ORG. 1 Construir o negócio.
ORG. 2 Definir o processo.
ORG. 3 Melhorar o processo.
ORG. 4 Prover recursos de treinamento.
ORG. 5 Prover infraestrutura organizacional.
Fonte: (TSUKUMO et al., 1997)
Níveis de capacitação
Além dos processos, o SPICE define os seis níveis de capacitação de cada processo, 
que são: incompleto, executado, gerenciado, estabelecido, previsível e otimizado. Na 
avaliação de uma organização, são selecionados os processos relevantes e para cada 
um deles é atribuído um perfil formado pela porcentagem de adequação a cada um dos 
níveis de capacitação. Vejamos no quadro 4 cada um destes níveis.
43
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
Quadro 4. Níveis de capacitação do SPICE – Norma ISO 15504.
Nível: Nome: Descrição:
0 Incompleto O processo não está implementado. Ele falha na tentativa de atingir os seus objetivos. 
1 Executado O processo implementado atinge os seus objetivos definidos. 
2 Gerenciado
O processo executado entrega produtos de trabalho de definida qualidade dentro de cronogramas e recursos 
definidos. 
3 Estabelecido
O processo gerenciado é executado usando um processo definido baseado em bons princípios de engenharia 
de software. 
4 Previsível
O processo estabelecido é executado, consistentemente, dentro de limites definidos de controle para atingir 
seus objetivos. 
5 Otimizado
O processo previsível otimiza o seu desempenho para atender às necessidades de negócio atuais e futuras, e 
consegue, repetidamente, atender seus objetivos definidos de negócio.
Fonte: (TSUKUMO et al., 1997)
O projeto SPICE é interessante devido a seu direcionamento e flexibilidade. Ele está 
disponível para que organizações o adotem de acordo com suas necessidades e planos 
de negócio, medindo a capacitação de cada um de seus processos objetivando promover 
melhorias contínuas nestes.
44
CAPÍTULO 4
CMMI – Capability Maturity Model 
Integration
Visão geral
O CMMI (em português, Modelo Integrado de Maturidade da Capacidade), criado em 
2002, é um modelo adotado para definir e melhorar a capacidade e a maturidade dos 
processos das empresas/organizações que produzem software. Através de sua estrutura, 
o CMMI ajuda a empresa/organização a avaliar sua maturidade organizacional ou 
capacidade em área de processo, estabelecendo prioridades para melhoramento e 
implementação desses melhoramentos.
No contexto de software, a maturidade da capacidade está relacionada ao processo de 
desenvolvimento do software. Já a palavra “integrado” está associada ao fato do CMMI 
ter o objetivo de integrar os modelos do antigo CMM (Capability Maturity Model) em 
uma estrutura coerente e alinhada.
O antigo modelo CMM foi desenvolvido pelo SEI (Software Engineering Institute), que 
consiste em uma organização ligada à universidade Carnegie Mellon. O desenvolvimento 
desse modelo foi financiado pelo Departamento de Defesa Americano com a finalidade 
de se estabelecer um padrão de qualidade para software desenvolvido para as forças 
armadas.
CMMI é um dos tópicos mais citados quando o assunto é qualidade de software. 
Portanto, sugiro fortemente que você faça uma leitura adicional sobre este 
assunto para entender detalhadamente os seus conceitos. Veja algumas 
indicações de leitura a seguir:
 » <http://www.diegomacedo.com.br/qualidade-de-processo-de-
software>
 » <https://msdn.microsoft.com/pt-br/library/hh765978.aspx>
Os objetivos do CMMI são, praticamente, voltados para a redução do custo da 
implementação de melhoria de processo. Vejamos a seguir:
 » Eliminação de inconsistências e redução de duplicidades. 
45
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
 » Melhoria da clareza e entendimento. 
 » Utilização de terminologia comum e estilo consistente. 
 » Estabelecimento de regras de construção uniformes. 
 » Manutenção de componentes comuns. 
 » Consistência com a futura norma ISO 15504. 
 » Sensibilidade às implicações dos esforços legados.
As empresas que investem no CMMI têm como principais benefícios o aumento 
da qualidade dos processos de software e o reconhecimento internacional 
dessa qualidade. Também têm uma maior e mais efetiva gerência de projetos de 
software, no que diz respeito a custo, tempo e recursos utilizados. Esse modelo 
possibilita uma redução significativa de defeitos nos serviços gerados e maior 
qualificação do pessoal no atendimento ao cliente, além da customização dos 
processos de acordo com as necessidades. Com isso, as empresas reduzem o 
retrabalho, baixam seus custos e agilizam suas soluções, agregando valor para o 
cliente (SALGUEIRO e ARTE, 2005).
Representação do modelo
Existem múltiplos modelos CMMI disponíveis. Como consequência, é necessária 
uma preparação para decidir qual modelo melhor se adéqua a uma organização, de 
acordo com as necessidades de melhoria de processo desta. Deve ser selecionada a 
representação, contínua ou em estágios, e quais corpos de conhecimento serão incluídos 
no modelo que a organização usará. A possibilidade de utilização dessas duas diferentes 
formas de representação (contínua e em estágios) para a melhoria de processos é a 
principal mudança do CMMI em relação ao CMM. Vejamos na Figura 6 a ilustração 
dessas representações e, a seguir, algumas vantagens e desvantagens de selecionar cada 
uma delas (SALGUEIRO; ARTE, 2005):
46
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
Figura 6. As duas representações do CMMI (PÊSSOA, 2005).
Fonte: <https://www.google.com.br/search?q=As+duas+representa%C3%A7%C3%B5es+do+CMMI&biw=1600&bih=799&so
urce=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMIzveB3eHGxwIVxoKQCh3xwgKR#imgrc=KPx3030tTehu6M%3A>
 » Representação contínua: permite que se selecione a sequência de 
melhorias que melhor atende aos objetivos de negócios e reduz as áreas 
de risco de uma organização. Também possibilita comparações dentro e 
entre organizações em uma área de processo. 
 » Representação em estágios: oferece uma sequência comprovada 
de melhorias, começando com práticas básicas de gerenciamento e 
progredindo por um caminho pré-definido e comprovado de níveis 
sucessivos, cada um servindo como base para o próximo.
Uma representação contínua usa níveis de capacidade para medir a melhoria de processo, 
enquanto que uma representação em estágio usa níveis de maturidade. A principal 
diferença entre níveis de maturidade e níveis de capacidade é qual representação a que 
pertence e como são aplicadas.
De acordo com Pêssoa (2005), paraentender o significado do termo capacidade devemos 
pensar na capacidade que alguém possui para realizar um trabalho: quanto maior a 
capacidade do processo, melhor deve ser o resultado obtido. Quando uma organização 
é avaliada levando-se em consideração a capacidade de seu processo (isto é, com uma 
representação contínua), o resultado será seu perfil de capacidade conforme mostra a 
Figura 7.
47
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
Figura 7. Exemplo de perfil de capacidade de uma organização (PÊSSOA, 2005).
Fonte: <http://www.isdbrasil.com.br/o-que-e-cmmi.php>
No exemplo da Figura 9, o perfil da capacidade da organização foi avaliado e o resultado 
foi o seguinte: o Processo 1 está no nível 3; o Processo 2 está no nível 4; e o Processo 3 
no nível 2. Como podemos ver na Figura 9, os níveis de capacidade do processo variam 
entre 0 a 5. Vejamos a seguir a descrição sobre o que representa cada nível no modelo 
contínuo, são eles (PÊSSOA, 2005):
 » Nível 0 – incompleto: o processo não é executado ou é executado 
parcialmente. 
 » Nível 1 – executado: o processo satisfaz as metas específicas da área de 
processo. 
 » Nível 2 – gerenciado: o processo é executado e também planejado, 
monitorado e controlado para atingir um objetivo (em projetos 
individuais, grupos ou processos isolados). 
 » Nível 3 – definido: o processo é gerenciado, adaptado de um conjunto de 
processos padrão da organização. 
 » Nível 4 – gerenciado quantitativamente: o processo é definido, controlado 
utilizando estatística ou outras técnicas quantitativas. 
 » Nível 5 – otimização: o processo é gerenciado quantitativamente para a 
melhoria contínua do desempenho do processo.
Como vimos, na representação em estágios uma organização deve implementar os 
processos de acordo com uma sequência pré-estabelecida. Portanto, a organização 
é avaliada por um conjunto de processos de acordo com o nível que ela estiver 
48
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
pleiteando. No modelo de representação em estágios, os níveis são denominados níveis 
de maturidade. Como ilustrado na Figura 8, eles variam de 1 a 5, onde cada nível é base 
para melhoramento de processo. Um nível de maturidade é um patamar evolutivo de 
processo de melhoramento. Cada nível de maturidade estabelece uma parte importante 
dos processos da organização. 
Figura 8. Os cinco níveis de maturidade do CMMI.
Fonte: <http://www.isdbrasil.com.br/o-que-e-cmmi.php>
 » Nível 1 – Inicial: os processos normalmente estão envoltos num caos 
decorrente da não obediência ou ainda, inexistência de padrões. 
 » Nível 2 – Gerenciado: os projetos têm seus requisitos gerenciados 
neste ponto. Além disso, há o planejamento, a medição e o controle dos 
diferentes processos. 
 » Nível 3 – Definido: os processos já estão claramente definidos e são 
compreendidos dentro da organização. Os procedimentos se encontram 
padronizados, além de ser preciso prever sua aplicação em diferentes 
projetos. 
 » Nível 4 – Gerenciado quantitativamente: ocorre o aumento da 
previsibilidade do desempenho de diferentes processos, uma vez que 
estes já são controlados quantitativamente. 
 » Nível 5 – Otimizado: existe uma melhoria contínua dos processos.
49
CAPÍTULO 5
Melhoria de Processo do Software 
Brasileiro – MPS.BR
O MPS.BR é um modelo de melhoria de processos de software criado em 2003 de 
acordo com a realidade de empresas brasileiras e com o objetivo de propor um modelo 
de processo para alcançar a Melhoria do Processo de Software Brasileiro. O MPS.BR 
também estabelece um processo e um método de avaliação, o qual dá sustentação e 
garante que o MPS.BR está sendo empregado de forma coerente com as suas definições.
O MPS.BR foi criado como uma iniciativa do Ministério de Ciência e Tecnologia (MCT) e 
da Associação para a Promoção da Excelência do Software Brasileiro (Softex), visando à 
definição de um modelo de referência e certificação baseado nas seguintes normas: ISO 
12207 (Ciclo de Vida de Processos de Software); ISO 15504 (SPICE) e CMMI (Modelo 
de Maturidade mantido pela Software Engineering Institute).
Pode-se considerar ainda o MPS-BR como uma importante alternativa ao CMMI em 
organizações de médio e pequeno porte. Isto se justifica em virtude do alto investimento 
financeiro que o CMMI representa, o que o torna mais indicado às grandes empresas de 
desenvolvimento.
O MPS-BR foi criado com o objetivo de ser um modelo de processo em que as empresas 
conseguem atingir os níveis de maturidade mais rápidos. Este é mais adequado à 
realidade brasileira, além de ser mais acessível do que o modelo de projeto CMMI. 
Além dessas vantagens em se adotar o MPS.BR, pode-se citar: 
 » Maior número de níveis: possui sete níveis de maturidade, onde a 
implantação é mais gradual e adequada a pequenas e médias empresas. 
 » Compatibilidade com CMMI: o que facilita a obtenção do certificado. 
 » Avaliação periódica: as empresas são avaliadas a cada dois anos para 
manter o certificado ou tentar evoluir para um próximo nível. 
 » Aceite em licitações: o MPS.BR passou a ser exigido no processo de 
licitações.
O MPS.BR se baseia nos conceitos de maturidade e capacidade de processo para a 
avaliação e melhoria da qualidade e produtividade de produtos de software e serviços 
correlatos. Dentro desse contexto, o MPS.BR é divido em três componentes, como 
50
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
mostra a Figura 9. Além dos componentes do MPS.BR, podemos observar na Figura 
10 os documentos utilizados para a descrição de cada um deles. Veremos mais detalhes 
nas seções a seguir.
Figura 9. Componentes do MPS.BR.
Fonte: <http://slideplayer.com.br/slide/44839>
O MPS.BR é um dos modelos de qualidade de processo mais importantes quando 
se trata de qualidade de software. Portanto, sugiro fortemente que você faça 
uma leitura mais aprofundada neste assunto nos livros indicados nas referências 
deste material e nos seguintes links:
<http://www.softex.br/mpsbr>
<http://homepages.dcc.ufmg.br/~rodolfo/GPS1-Turma11/MPS.BR_Guia[1].pdf>
Modelo de referência (MR-MPS)
O MR-MPS contém os requisitos que as organizações precisam atender para estar 
em conformidade com o modelo MPS.BR. Ele contém as definições dos níveis de 
maturidade, dos processos em si e da capacidade dos processos. Isso permite avaliar 
e atribuir graus de efetividade na execução dos processos. Em outras palavras, este 
modelo contém os requisitos que os processos das empresas devem atender para estar 
51
QUALIDADE DO PROCESSO DE SOFTWARE│ UNIDADE II
em conformidade com o modelo. Foi baseado nas normas ISO/IEC 12207 e ISO/IEC 
15504 e é adequado ao CMMI.
Este modelo, como podemos ver na Figura 9, está descrito no Guia Geral. Já o Guia 
de Aquisição é um documento complementar para empresas que pretendem adquirir 
software. Ele não contém requisitos do MR-MPS, mas sim boas práticas para aquisição 
de software ou serviços correlatos. Os Guias de Implementação, por outro lado, sugerem 
formas de implementar o MPS.BR nas organizações.
Níveis de maturidade
O Modelo de Referência MR-MPS define 7 níveis de maturidade de uma organização (que 
é uma combinação entre seus processos e sua capacidade) como ilustra a Figura 10.
Figura 10. Níveis de maturidade do MR-MPS.
Fonte: <http://www.pdcase.com/mps-br>.
A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um 
destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde 
a organização deve colocar o esforço de melhoria. O progresso e o alcance de um 
determinado nível de maturidade MPS.BR se obtêm quando são atendidos os propósitos 
52
UNIDADE II │QUALIDADE DO PROCESSO DE SOFTWARE
e todos os resultados esperados dos respectivos processos e dos atributos de processo 
estabelecidos para aquele nível.
Processo
Os processos no MR-MPS são descritos em termos de:
 » Propósito: que descreve o objetivo geral a ser atingido durante a execução 
do processo. 
 » Resultados: que estabelecem