Resumo-Qualidade-de Software

Prévia do material em texto

Resumo sobre Qualidade e Teste de Software 
Qualidade: 
 
O termo Qualidade vem do latim “Qualitas”, e é utilizado em diversas situações, 
mas o seu significado nem sempre é de definição clara e objetiva. 
Há várias definições para qualidade, do ponto de vista de diferentes pessoas, 
como: 
• Produto(s) e/ou serviço(s) com constatada efetividade; 
• Valor que produtos similares não possuem; 
• Fazer correto da primeira vez; 
• Maior relação custo versus benefício; 
• Em conformidade com as exigências do(s) cliente(s); 
• Adequação ao uso”. 
Enfim, o referido termo é geralmente empregado para significar excelência de um 
produto e/ou serviço. 
 
A qualidade de um produto pode ser vista por duas ópticas, como a: 
 
• Do produtor – a qualidade associa-se à concepção e produção de um 
produto que vá ao encontro das necessidades do cliente.; 
 
• Do cliente –. a qualidade está associada ao valor e à utilidade 
reconhecida ao produto, estando, em alguns casos, ligada ao preço 
 
Dessa forma, quando s fala em qualidade sob viés da Tecnologia da Informação, 
observa-se alguns conceitos, como: 
 
Gerência da qualidade – processo de controlar e gerenciar o processo da 
qualidade na fabricação ou manutenção de um produto ou serviço; 
 
Garantia da qualidade – ações tomadas para redução de defeitos; 
 
Controle da qualidade – ações relacionadas à medição da qualidade, para 
diagnosticar se o resultado está sendo atingido. 
 
O que é m produto de software – artefato? 
 
Artefato – são resultados tangíveis possuindo qualidade controlada e 
resultantes do desenvolvimento ou da manutenção 
É um conceito recursivo, pois artefatos podem ser compostos por artefatos 
Artefato forma uma estrutura de relacionamentos: 
Ex: artefato A depende de artefatos B, C, ... formando um grafo dirigido acíclico 
 
❖ A qualidade de um artefato é um conjunto de propriedades a serem 
satisfeitas em determinado grau, de modo que o artefato satisfaça as necessidades 
explícitas e implícitas de todos os seus interessados 
 
Interessados = Usuários x Clientes 
 
• Usuário (user) pode ser: 
 
– Pessoa interessada no serviço prestado pelo artefato sob teste; 
– Pessoa interessada em manter o artefato sob teste; 
– Pessoa interessada em por em operação o artefato sob teste; 
– Pessoa interessada em compor o artefato sob teste com outros 
– Outro artefato (software) com o qual o artefato sob teste interagirá 
– Equipamento (máquina) com o qual o artefato sob teste interagirá 
 
• Cliente (customer) é a pessoa ou organização que: 
 
– Disponibiliza recursos para a aquisição, desenvolvimento ou manutenção do 
artefato; 
– Seja interessada na redução de custos e riscos incorridos pelos processos; 
– Seja interessada na viabilização de um serviço impossível de ser realizado sem 
o emprego de sistemas intensivos em software 
 
Em software, as medições podem ser utilizadas de maneira semelhante. Antes 
mesmo de o produto existir, determina-se durante a análise de requisitos como deverá 
funcionar. (KOSCIANSKI, André, SOARES, Michel dos Santos, 2007) 
De acordo com (KOSCIANSKI, André, SOARES, Michel dos Santos, 2007), 
pode-se, por exemplo, estabelecer qual o tempo máximo que o programa poderá demorar 
para fornecer uma certa resposta. Com base nessa informação, os projetistas e 
programadores deverão definir os algoritmos mais adequados, a forma de acesso e 
indexação de arquivos, requisitos de hardware e outros fatores que influenciam o 
resultado. 
Segundo (Boehm,Brown e Lipow, 1976) definem uma árvore de atributos de 
qualidade de software bem definidos e bem diferenciados (figura 1), onde 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. 
 
Figura 1 - Árvore de Características de Qualidade de Software (Boehm,Brown e Lipow, 1976) 
A estrutura de mais alto nível reflete o uso de avaliação da qualidade de software. 
De acordo com (Boehm,Brown e Lipow, 1976), destacam a aquisição do pacote 
de software, o qual deve ter as seguintes características de nível médio na estrutura 
hierárquica: portabilidade, confiabilidade, eficiência, engenharia humana e facilidades de 
teste, uso e modificação. 
Conforme (Davis, A. et al.,1993) também propõem uma lista de características 
que podem ser usadas para avaliar a qualidade do modelo de análise e da correspondente 
especificação de requisitos como: falta de ambiguidade, completude, corretude, facilidade 
de entendimento, verificabilidade, consistência interna e externa, concisão, facilidade de 
rastreamento, facilidade de modificação, precisão e reusabilidade. 
A Norma NBR ISO/IEC 9126, divide a qualidade em dois modelos, são eles: 
 
 
 
 
Qualidade Interna e Externa – conjunto de seis características 
resultantes de atributos internos do software. 
 
Medidas Internas x Externas 
 
Medidas Internas são tipicamente medidas estáticas de produtos intermediários. 
 
Exemplo: Tempo de resposta a uma requisição de usuário. 
 
Medidas Externas são tipicamente obtidas pela medição do comportamento do 
código quando executado 
 
Exemplos: 
• As funções especificadas estão disponíveis? 
• Qual é a confiabilidade do software e sua eficiência? 
• É fácil de usar? 
• É fácil para transferir para outro ambiente operacional? 
 
 
 
As Características de qualidade segundo a norma ISO 9126 
 
Figura 2 - Modelo de qualidade da ISSO/IEC 9126. A subcaracterística conformidade não está ilustrada. 
(KOSCIANSKI, André, SOARES, Michel dos Santos, 2007) 
Funcionalidade – é aquilo que o software faz quando solicitado pelo 
usuário. 
 
Exemplos: 
 
• Imprimir um relatório; 
• Apresentar dados na tela; 
• Registrar uma informação em uma base de dados. 
 
A característica se refere à capacidade para o cumprimento de tarefas, em outros 
termos, se uma dada função foi implementada ou não no programa. 
A maneira como essa função é executada é algo que pode ser avaliado em função 
de outras características. (KOSCIANSKI, André, SOARES, Michel dos Santos, 2007) 
Pode-se dizer que esta característica é idêntica aos “requisitos funcionais” 
❖ “Os requisitos funcionais para um sistema descrevem a 
funcionalidade ou os serviços que se espera que o sistema forneça.” (Sommerville, 
2003) 
As sub características da Funcionalidade são: 
• Adequação: é a capacidade do software de fornecer um grupo de 
funcionalidades adequadas para tarefas especificas e para os objetivos dos usuários. 
• Acurácia: é a capacidade do software fornecer resultados corretos e 
acordados com os necessários graus de precisão. 
• Interoperabilidade: é a capacidade do software de interagir com um ou 
mais sistemas específicos. 
• Segurança: é a capacidade do software de proteger informações e dados, 
de tal modo que pessoas ou sistema não autorizados não consigam acessá-las. Por outro 
lado, aqueles que estão autorizados poderão acessar essas informações ou dados. 
• Conformidade com a funcionalidade: é a capacidade do software de 
aderir aos padrões, convenções, regras, regulamentações e leis relacionadas à 
funcionalidade. 
Confiabilidade – um produto é confiável quando não falha. 
 
Em software, a ocorrência de falhas é sempre uma possibilidade. 
 
Em primeiro lugar, como foi feito com a característica “funcionalidade”, aqui 
também é preciso definir um escopo. 
A confiabilidade de um programa se traduz com a capacidade de manter um certo 
nível de desempenho quando operando em um certo contexto de uso. 
As sub características da Confiabilidade de acordo com (ISSO/IEC 9126-1): 
• Maturidade: é a capacidade do software de evitarfalhas decorrentes de 
falhas de software. 
• Tolerância a falhas: é a capacidade do software de manter um nível 
específico de performance em caso de falhas ou de violações em sua interface específica. 
• Recuperabilidade: é a capacidade do software de restabelecer um nível 
específico de performance em caso de falhas ou violações em sua interface específica. 
• Conformidade com a funcionalidade: é a capacidade do software de 
aderir a padrões, regras, regulamentações e leis relacionadas à conformidade. 
Usabilidade – representa basicamente o quão é fácil usar o produto. 
 
Esta é provavelmente a característica mais difícil de tratar, tanto durante a 
definição de requisitos quanto durante os estágios posteriores do ciclo de vida, na 
verificação e validação do produto. (KOSCIANSKI, André, SOARES, Michel dos 
Santos, 2007) 
 
As sub características da Usabilidade de acordo com (ISSO/IEC 9126-1): 
• Inteligibilidade: é a capacidade do software de permitir ao usuário 
entender se o programa é amigável e como ele pode ser usado para tarefas particulares e 
outras condições de uso. 
• Apreensibilidade: é a capacidade do software de permitir ao usuário 
aprender com sua aplicação. 
• Operabilidade: é a capacidade do software de permitir o usuário operá-lo 
e controlá-lo. 
• Atratividade: é a capacidade do software de ser atrativo para o usuário. 
• Conformidade com a usabilidade: é a capacidade do software de aderir 
aos padrões, convenções, regras, regulamentações e leis relacionadas à usabilidade. 
Eficiência – é quando o tempo de execução e os recursos envolvidos são 
compatíveis com o nível de desempenho do software. 
 
A velocidade de operação de um software pode ser afetada por inúmeros fatores: 
• Velocidade da CPU; 
• Quantidade de memória cache e memória RAM; 
• Desempenho de disco rígido; 
• Volume de tráfego de rede; 
• Interação com outros softwares e com o sistema operacional; 
• Configurações do Sistema Operacional. 
 
As sub características da Eficiência de acordo com (ISSO/IEC 9126-1): 
• Comportamento em relação ao tempo: é a capacidade do software de 
fornecer tempos apropriados de resposta e de processamento, relativos à soma de recursos 
e sob condições preestabelecidas. 
• Comportamento em relação aos recursos: é a capacidade do software 
de utilizar a soma e os tipos de recurso quando executar suas funcionalidades sob 
condições preestabelecidas. 
• Conformidade com a eficiência: é a capacidade do software de aderir aos 
padrões, convenções, regras, regulamentações e leis relacionadas à eficiência. 
Manutenibilidade – é a capacidade do software ser mantido. 
 
A característica de manutenibilidade está relacionada à facilidade de modificação 
de um produto de software. (KOSCIANSKI, André, SOARES, Michel dos Santos, 2007) 
Segundo (KOSCIANSKI, André, SOARES, Michel dos Santos, 2007), esta 
característica é de interesse especialmente para desenvolvedores e não deve ser 
confundida com a possibilidade de configurar o software. 
 
Uma modificação consiste, por exemplo, em uma correção do produto ou da 
adaptação a mudanças de requisitos, como mudanças de legislação. 
 
As sub características da Manutenibilidade são: 
• Analisabilidade: é a capacidade do software de passar por diagnósticos 
em busca de deficiências ou origens de falhas, ou para a identificação de pares que devem 
ser alteradas. 
• Modificabilidade: é a capacidade do software de permitir que uma 
alteração específica seja implementada. 
• Estabilidade: é a capacidade do software de evitar efeitos inesperados em 
decorrência de alterações. 
• Testabilidade: é a capacidade do software de ser testado após alterações. 
• Conformidade com a manutenibilidade: é a capacidade do software de 
aderir aos padrões, convenções, regras, regulamentações e leis relacionadas à 
manutenibilidade. 
Portabilidade – é a capacidade do software ser transferido de um ambiente 
para outro. 
 
A palavra “portabilidade” é utilizada geralmente para indicar a possibilidade de 
um código-fonte ser utilizado em diferentes plataformas de execução. 
 
Na norma 9126, a definição foi estendida para abranger a ideia de portar 
aplicações entre organizações diferentes. 
 
Em tese, supõe-se que um programa possa, então, ser elaborado para operar em 
ambientes com características diferentes. (KOSCIANSKI, André, SOARES, Michel dos 
Santos, 2007) 
 
As sub características da Portabilidade são: 
• Adaptabilidade: é a capacidade do software de ser adaptado a ambientes 
diferentes sem a aplicação de ações ou outros meios que não aqueles previamente 
estabelecidos. 
• Facilidade de instalação: é a capacidade do software de ser instalado num 
ambiente específico. 
• Coexistência: é a capacidade do software de coexistir com outro software 
no mesmo ambiente e compartilhar recursos. 
• Capacidade para substituir: é a capacidade do software de substituir um 
outro software no mesmo ambiente para o mesmo propósito. 
• Conformidade com a portabilidade: é a capacidade do software de aderir 
aos padrões, convenções, regras, regulamentações e leis relacionadas à portabilidade. 
Qualidade em Uso – é, para o usuário, o efeito combinado das seis 
características de qualidade interna e externa do produto de software. 
 
 
 
 
Eficácia – capacidade do produto de software de permitir que usuários atinjam 
metas especificadas com acurácia e completitude, em um contexto de uso especificado. 
 
Produtividade – capacidade do produto de software de permitir que seus 
usuários empreguem quantidade apropriada de recursos em relação à eficácia obtida, em 
um contexto de uso especificado. 
 
Segurança – capacidade do produto de software de apresentar níveis 
aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao mbiente, 
em um contexto de uso especificado. 
 
Satisfação – capacidade do produto de software de satisfazer usuários, em 
um contexto de uso especificado. 
 
Processo de Medição 
 
 
Uma abordagem para escolher as medições é o GQM (Goal-Question-Metric) 
 
• As questões são formuladas para atender um objetivo 
• As métricas são escolhidas para responderem as questões 
 
Objetivos 
 
– Definem o que a organização quer melhorar (exemplo: 
produtividade) 
 
Questões 
 
– Refinamento dos objetivos em áreas de incertezas 
(exemplo: linhas de código produzidas podem ser aumentadas?) 
 
Métricas 
 
– Medições necessárias para responder as questões 
(exemplo: LOC por desenvolvedor) 
 
Métricas de Produto – quantificam atributos internos do software 
 
Exemplos de atributos 
• Tamanho 
• Acoplamento dentre componentes 
• Coesão de um componente etc. 
 
Métricas Dinâmicas 
– São coletadas por medições realizadas durante a execução do programa. 
– Ajudam a avaliar atributos de qualidade como eficiência e confiabilidade. 
– São medidas após o sistema ter sido implementado 
 
Métricas Estáticas 
– São coletadas por medições realizadas na documentação de projeto ou código 
fonte do programa. 
– Ajudam a avaliar atributos como complexidade e facilidade de manutenção. 
– Podem ser medidas na fase de projeto. 
 
Algumas Métricas Estáticas 
 
Fan-in 
 
– Conta o número de funções que chama uma determinada 
função. 
– Valor alto significa grande impacto em mudanças 
(propagação). 
 
Fan-out 
 
– Conta o número de funções chamadas pela função. 
– Valor algo significa grande complexidade da função. 
 
Tamanho 
 
– Tamanho tem se mostrado como métricas mais confiáveis e úteis. 
– Em geral, quanto maior, mais complexo e propenso a erros será o componente. 
 
Complexidade Ciclomática– Mede a complexidade de controle do programa (if, while, for, etc.) 
– Está relacionada a facilidade de compreensão. 
Tamanho do Vocabulário 
 
– Conta a quantidade de identificadores (exemplo, nome de classes) do 
programa. 
– Mais identificadores podem significar que eles são mais significativos. 
 
Profundidade de Aninhamento 
 
– Conta estruturas internas como if e while aninhados. 
– Estruturas aninhadas são mais difíceis de se compreender. 
 
Teste 
 
Validação: Assegurar que o produto final corresponda aos requisitos do usuário. 
– Estamos construindo o produto certo? 
 
Verificação: Assegurar consistência, completitude e corretitude do produto em 
cada fase e entre fases consecutivas do ciclo de vida do software. 
– Estamos construindo corretamente o produto? 
 
Teste: Examina o comportamento do produto por meio de sua execução (análise 
dinâmica) 
 
Os testes são realizados com a intenção de descobrir erros e defeitos em um 
sistema. [Myres, 2004] 
 
Os testes de software podem ser usados para mostrar a presença de defeitos, mas 
nunca para mostrar a ausência deles [Dijkstra, 1972] 
 
Atividade essencial para ascensão ao nível 3 do Modelo CMMI/SEI 
 
Atividade relevante para avaliação da característica funcionalidade (ISO 9126, 
ISO 25010, ISO 25041) 
 
 
❖ Os testes de software servem para medir a confiabilidade de um 
sistema. 
 
❖ À medida que poucos defeitos são encontrados em um determinado 
tempo, o software é considerado mais confiável. 
 
Objetivo do Teste 
 
Reduzir a probabilidade de incidência de erro no cliente 
+ 
Minimizar riscos ao negócio do cliente 
+ 
Atender as necessidades do cliente (negócio, contratual, legal, etc.) 
= 
Maior satisfação do cliente 
 
 
Engano x Defeito x Erro x Falha 
 
– Um engano introduz um defeito no software. 
– O defeito, quando ativado, pode produzir um erro. 
– O erro, se propagado até a saída do software, constitui 
uma falha. 
 
 
 
 
Defeito Erro Falha 
 
• Defeito: deficiência mecânica ou algorítmica que, se ativada, pode levar a 
uma falha; 
‒ Instrução ou comando incorreto 
‒ A maior parte é de origem humana. 
 
• Erro: item de informação ou estado de execução inconsistente; 
 
• Falha: evento notável em que o sistema viola suas especificações; 
 
 
 
 
❖ Quanto antes a presença dos defeitos for revelada, menor o custo de 
correção do defeito e maior a probabilidade de corrigi-lo 
corretamente. 
 
Solução: introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento. 
 
Conceitos Básicos de Testes 
 
• Latência do erro é o tempo decorrido entre o momento em que o erro é 
gerado e o momento em que é observado; 
 
• Dano é a consequência externa conhecida (prejuízo observado) provocada 
por uma falha; 
 
• Lesão é a consequência externa desconhecida provocada por um erro ainda 
não observado; 
 
 
 
 
Defeitos e erros não revelados 
 
– Falhas se manifestam durante a utilização pelos usuários 
– Erros devem ser corrigidos durante a manutenção 
 
Alto custo 
 
Falhas graves 
 
– Qualidade e confiabilidade suspeitas 
– Modificação do projeto 
– Novos testes 
 
Erros de fácil correção 
 
– Funções aparentemente funcionam bem. 
– Qualidade e confiabilidade aceitáveis. 
– Testes inadequados para revelar a presença de erros graves. 
Princípios de Teste de Software 
 
1. Teste demonstra presença de defeitos; 
2. Teste exaustivo é impossível; 
3. Teste antecipado; 
4. Agrupamento de defeitos; 
5. Paradoxo do pesticida; 
6. Teste depende do contexto; 
7. A ilusão da ausência de erro. 
 
Processo de Teste PDCA 
 
 
Principais funções de um processo de teste: 
 
– Gestor da Qualidade: responsável por garantir o cumprimento dos processos; 
– Gerente de Teste: responsável em definir e acompanhar os projetos de testes; 
– Líder de Teste: responsável por auxiliar tecnicamente e coordenar as atividades 
de testes; 
– Arquiteto de Teste: responsável pela disponibilidade de todo ambiente de teste; 
– Analista de Teste: responsável em modelar os cenários de testes e gerar os scripts 
de testes automatizados quando necessário; 
– Testador: responsável em executar os testes e reportar os resultados obtidos; 
– Usuário: responsável pelos testes de aceitação (cliente). 
 
Fases de Teste 
 
Teste de Unidade 
 
‒ Identificar erros de lógica e de implementação em cada módulo do software, 
separadamente. 
 
 
Teste de Integração 
 
‒ Identificar erros associados às interfaces entre os módulos do software. 
 
Teste de Sistema 
 
‒ Verificar se as funções estão de acordo com a especificação e se todos os 
elementos do sistema se combinam adequadamente. 
 
Auditoria 
 
 
 
 
➢ O estabelecimento dos requisitos é fundamental para efetuar a auditoria, 
pois constituem a base para o entendimento de como este processo de auditoria da 
qualidade será aplicado. 
 
Estabelecer os requisitos da auditoria implica nas seguintes fases: 
 
• Estabelecer o propósito da auditoria; 
• Identificar o(s) produto(s) a ser(em) avaliado(s); 
• Especificar o modelo de auditoria da qualidade. 
 
➢ Estabelecer o propósito da auditoria 
 
Quando uma auditoria é solicitada, normalmente o requisitante descreve os 
requisitos que ele deseja que sejam auditados. 
 
Geralmente, solicitante e auditor entram em acordo quanto à especificação da 
auditoria como um todo. 
Os solicitantes de auditoria da qualidade de software são potencialmente: 
 
• Desenvolvedores; 
• Fornecedores; 
• Adquirentes; 
• Usuários de softwares. 
 
Os desenvolvedores de softwares, muitas vezes, estão diretamente envolvidos na 
auditoria, mesmo que não sejam os solicitantes da auditoria. 
 
Os resultados podem contribuir para corrigirem falhas, principalmente se o 
software que está sendo avaliado encontra-se em fase de desenvolvimento. Nesse caso, o 
propósito da avaliação pode ser: 
 
• Para prevenir e estimar a qualidade do produto final; 
• Colher informações sobre o produto em desenvolvimento; 
• Para inspecionar e administrar o processo; 
• Confirmar o término do estágio do desenvolvimento, para iniciar um novo 
estágio. 
 
➢ Identificar tipo(s) de produto(s) a ser(em) avaliado(s) - Se a auditoria 
for feita no estágio do desenvolvimento do software, a possibilidade do produto satisfazer 
aos quesitos considerados no processo de avaliação aumenta substancialmente, assim 
como minimiza o risco de falhas graves, o que pode acarretar custos extras e inesperados. 
 
No entanto, um software pode ser submetido à auditoria em qualquer momento, 
bem como em qualquer um dos processos de seu ciclo de vida 
 
Se quem deseja auditar é o usuário ou adquirente do software, a avaliação será 
feita no produto final, fornecendo ao auditor e à organização um feedback, com relação 
ao atendimento às suas necessidades. 
 
➢ Especificar o modelo de auditoria da qualidade – implica mostrar os 
procedimentos a serem usados pelo auditor para realizar as medições que foram 
solicitadas na especificação da avaliação. 
 
Se o solicitante for o desenvolvedor, poderá estar solicitando a auditoria da 
qualidade a cada nova versão que estiver sendo lançada, checando se todas as 
características relevantes continuam a desempenhar suas funções de forma adequada, sem 
prejuízo nenhum à qualidade do software. Se o requisitante for o adquirente, a avaliação 
poderá estar sendo solicitada apenas para escolher o software, ou então, a qualquer tempo 
que deseje verificar a qualidade do software. 
 
➢ Especificação da auditoria consiste na etapa em que devemser elencadas 
as quantificações para as características e subcaracterísticas da qualidade de software. As 
quantificações podem ser obtidas através do estabelecimento de critérios de mensuração, 
determinando pesos aos requisitos que foram definidos na fase de especificação do 
modelo, por meio dos quais será possível a avaliação da qualidade do software. 
➢ Selecionar métricas – O resultado da avaliação da qualidade de softwares 
está relacionado às métricas selecionadas, que aumentam a sua confiabilidade. O 
estabelecimento das métricas que podem 
 
O estabelecimento das métricas baseadas na NBR ISO/IEC 9126- 1, define as seis 
características que descrevem a qualidade de softwares e fornecem base de refinamento 
para a avaliação da qualidade. 
Dependendo do software que estiver sendo avaliado e da relevância da avaliação, 
as subcaracterísticas poderão ser diferentes, ou poderão ter pesos diferentes, o que alterará 
os resultados da avaliação da característica. 
 
 
 
➢ Estabelecer níveis de pontuação para as métricas 
 
Busca-se representar a qualidade de forma numérica, de maneira que possa ser 
quantificável. 
Cabe ao auditor estabelecer métodos que possam diminuir a subjetividade. Uma 
das formas é determinar que a avaliação seja feita por vários auditores. Uma outra 
alternativa é estabelecer graus de relevância para as subcaracterísticas, atribuindo-lhes 
pesos. assim, a característica terá seu peso máximo de acordo com a soma das suas 
subcaracterísticas. 
 
 
➢ Grau de relevância 
 
Normalmente, é o solicitante (desenvolvedor, adquirente ou usuário) quem define 
a respectiva pontuação, juntamente com o auditor. 
 
O grau ou nível de pontuação pode ser formatado a partir de uma medida 
qualitativa, através de termos que expressem esta medida, como, relevância: alta, média 
ou baixa. 
 
Exemplo de proposta: 
 
 
 
É necessário também estabelecer medidas quantitativas, atribuindo pesos a esta 
relevância, determinadas em conjunto pelo solicitante e pelo auditor. Os pesos 
representam a importância daquela subcaracterística perante a característica. Desta 
maneira, terão um valor numérico que viabilizará a avaliação.