Qualidade e Autoria em TI-REVISÃO FEITA

Prévia do material em texto

QUALIDADE E AUDITORIA DE TECNOLOGIA 
DA INFORMAÇÃO
DOUGLAS DELA GIUSTINA
2QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
SUMÁRIO
CENTRO UNIVERSITÁRIO UNIFTEC
Rua Gustavo Ramos Sehbe n.º 107. 
Caxias do Sul/ RS 
REITOR
Claudino José Meneguzzi Júnior
PRÓ-REITORA ACADÊMICA
Débora Frizzo
PRÓ-REITOR ADMINISTRATIVO
Altair Ruzzarin
DIRETORA DE EDUCAÇÃO A DISTÂNCIA (EAD)
Lígia Futterleib
Desenvolvido pela equipe de Criações para o 
ensino a distância (CREAD)
Coordenadora e Designer Instrucional 
Sabrina Maciel
Diagramação, Ilustração e Alteração de Imagem
Jaqueline Boeira
Revisora
Luana dos Reis
INTRODUÇÃO 3
QUALIDADE DE SOFTWARE 4
Eras da Qualidade 5
Gestão estratégica da Qualidade 8
Gurus da Qualidade 8
Porque precisamos pensar em qualidade de software? 9
Qualidade de software 12
Qualidade do Produto e Qualidade do Processo 13
Processo de Garantia da Qualidade 14
Custos da Qualidade 17
Síntese 20
FERRAMENTAS DA QUALIDADE 22
Fluxograma 23
Diagrama de Causa e Efeito 26
Folhas de Verificação 28
Gráfico de Pareto 31
Diagrama de Dispersão 34
Histograma 37
Cartas de Controle 40
Síntese 44
MÉTRICAS DA QUALIDADE DE SOFTWARE 46
Por que medimos software ? (alguns motivos) 47
Terminologias de Métricas 47
Metodologia Goal/Question/Metric – GQM 51
Dimensões para Medição de Software 53
Síntese 54
NORMAS E MODELOS DA QUALIDADE 56
ISO/IEC 9126 57
ISO/IEC 12207 60
ISO/IEC 15504 e a norma SPICE 68
Histórico 68
Square: ISO/IEC 25000 75
MPS BR 85
PSP e TSP 91
Síntese 102
TESTE DE SOFTWARE 105
Fundamentos de Teste 106
Processo de Teste 109
Verificação e Validação (V&V) 110
Documentação no Teste 118
O Teste nos Ciclos de Vida 122
Níveis, Tipos e Técnicas de Teste 124
Níveis de Teste (Quando testar) 125
Tipos de Teste (O que testar?) 130
Técnicas de Teste (Como testar?) 132
Caminhos independentes de programa: 135
Síntese 145
AUDITORIA DA TECNOLOGIA DA INFORMAÇÃO 147
Fundamentos de auditoria de sistemas de informações
 148
Pontos de Controle da Auditoria 151
Organização da Auditoria 153
Padrões e Código de Ética 156
Ferramentas de apoio à auditoria 158
Técnicas de Auditoria 160
Síntese 163
REFERÊNCIAS 167
INTRODUÇÃO
Caro companheiro de jornada: A nossa disciplina de Qualidade e Auditoria de Tecnologia da Informação fornece uma base para 
implementarmos uma cultura de busca pela qualidade de software e políticas para monitorar o cumprimento destas políticas, através de 
auditorias. Nela, estudaremos desde os conceitos mais básicos da qualidade e auditoria, até técnicas de teste de software e normas que 
norteiam o desenvolvimento do mesmo, entre outros assuntos relevantes para a completa formação de um profissional nesta área.
Nosso conteúdo está dividido em 6 capítulos, onde o primeiro refere-se à “Introdução à qualidade de software”, o segundo a “Ferra-
mentas da Qualidade”, o terceiro a “Métricas da Qualidade de Software”, o quarto a “Normas e Modelos da Qualidade”, o quinto a “Teste 
de Software” e, por último, a “Auditoria da Tecnologia da Informação”.
Ao final desta disciplina seremos capazes de reconhecer a importância e a necessidade de buscar, avaliar e empregar as melhores práticas 
no desenvolvimento de software, embasados nas abordagens estudadas, com a aplicação de técnicas e ferramentas tanto de teste quanto de 
auditoria de software e contribuírem com a melhoria do nível do software desenvolvido.
4QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
QUALIDADE DE 
SOFTWARE
Qualidade: Quem é você? 
Antes de entrarmos em detalhes sobre a qualidade do 
software, é importante iniciarmos com uma ref lexão: O que é 
qualidade? Conversando com nossos pares, ouvindo especia-
listas ou consultando livros de diversos autores, chegaremos à 
conclusão de que qualidade é algo um tanto quanto relativo, 
onde na percepção de um grupo de interessados algo pode 
ser definido como tendo qualidade, e na percepção de outro 
grupo, o mesmo produto ou serviço poderá ser definido como 
não possuindo qualidade.
Este aparente impasse nos leva a uma necessidade de estru-
turar uma série de requisitos que consigam determinar se algo 
tem ou não qualidade, eliminando ou reduzindo ao máximo o 
fator da percepção ou de valores individuais.
A estruturação passa tanto pelo conhecimento das reais 
5QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
necessidades do cliente, quanto pela definição de requisitos 
internos de qualidade, a fim de garantir a sobrevivência da 
empresa fornecedora.
Eras da Qualidade
A fim de entendermos melhor os porquês de algumas falhas 
atuais é necessário estudarmos um pouco de história. Esta no-
ção é importante para atingirmos os objetivos do capítulo dois, 
onde serão detalhadas as principais ferramentas da qualidade.
A figura mostra a sequência das eras da qualidade, com 
a era subsequente englobando as características da era prede-
cessora e ampliando o escopo de atuação.
Inspeção
Quando a industrialização teve início até meados do século 
XIX, quase tudo era fabricado por artesãos, onde a produção 
era realizada em pequena quantidade. O trabalhador partici-
pava de praticamente todo o ciclo do produto e as inspeções 
eram realizadas conforme critérios do artesão, sendo assim um 
procedimento natural e corriqueiro.
A inspeção formal só passou a ser necessária com o sur-
gimento da produção em massa e a necessidade de peças in-
tercambiáveis.
No início do século XX, Frederick W. Taylor, conhecido 
como o criador da “administração científica”, atribuiu maior 
legitimidade à atividade de inspeção, separando-a do processo 
de fabricação e atribuindo-a a profissionais especializados.
A partir desta separação, as atividades de inspeção foram 
se transformando rapidamente em um processo independente 
e associada ao controle de qualidade.
Fonte: Autor
6QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Nessa era a inspeção era realizada em 100% dos produtos.
A grande chave para identificar esta Era é que a etapa de 
resolução de problemas verificados durante a inspeção, não era 
de responsabilidade do departamento de inspeção.
Controle Estatístico da Qualidade
O início desta era foi a publicação, em 1931, da obra Eco-
nomic control of quality of manufactured product que atribuiu 
um caráter mais científico à pratica da busca da qualidade. 
Nessa obra encontram-se os fundamentos, os procedimentos 
e as técnicas para tornar a qualidade mais efetiva, uma vez que 
nesta fase são utilizados controles da qualidade via processos 
estatísticos.
Destes processos estatísticos destacam-se o Controle de 
processo e a Amostragem. O primeiro caracteriza-se pela de-
finição de um processo padrão e seu monitoramento, enquanto 
o segundo é caracterizado por definição de métricas estatísticas 
para a determinação de uma amostra aceitável para a inspeção, 
uma vez que inspecionar todos produtos era inviável.
7QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Garantia da Qualidade
Nesta era a principal diferença é que o enfoque saiu da 
detecção de falhas em processos e produtos para a prevenção 
dos defeitos.
É desta época o conceito de TQC (total quality control), 
onde devemos abordar a qualidade desde a fase de projeto até o 
final do ciclo de vida do produto, envolvendo todas as pessoas 
participantes deste processo, sem esquecer de aprimorarmos 
as técnicas tradicionais da qualidade já existentes.
O principal marco desta era foi o TQC (total quality control)
Os principais movimentos desta era são: a atenção aos 
Custos da Qualidade, ao Controle Total da Qualidade, a En-
genharia da Qualidade e o Zero Defeito. O primeiro atenta-se 
aos custos de não termos qualidade, o segundo caracterizou-se 
por envolver todos os departamentos da empresa na busca 
pela qualidade, o terceiro trata da expansão da qualidade para 
fora da fronteira da organização (incluindo o uso pelo cliente, 
durabilidade, entre outros) e por fim, o quarto baseou-se no 
princípio de “fazer certo da primeira vez”, para obtermos o 
menor custo.
Para refletir: Somente podemos controlar o que medimos.
8QUALIDADEE AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Gestão estratégica da Qualidade
Observamos que esta era se caracterizou pelo entendimento 
que a qualidade era muito mais do que um emaranhado de 
normas, modelos, procedimentos, enfim, questões técnicas. 
Desta forma, devemos considerá-la uma área de cunho prio-
ritariamente estratégico, ligada diretamente ao sucesso ou ao 
fracasso de uma empresa.
Gurus da Qualidade
A história nos brinda com diversos gurus da qualidade, que 
contribuíram com diversas ferramentas, técnicas e métodos para 
melhorar a qualidade em todas as áreas. Para o nosso estudo, o 
principal guru foi Kaoru Ishikawa, para o qual apresentamos 
abaixo um resumo de sua história e contribuições.
Ishikawa 
Seu nome completo é Kaoru Ishikawa (13 de julho de 
1915 – 16 de abril de 1989) e foi um engenheiro de controle de 
qualidade, teórico da administração das companhias japonesas. 
Aprendeu os princípios de controle estatístico da qualidade 
desenvolvido pelos americanos. Com base nesse aprendiza-
do, expandiu os conceitos de gerenciamento do Dr. William 
Eduards Deming e do Dr. Joseph Moses Juran para o sistema 
japonês contribuindo, desta forma, no desenvolvimento de uma 
estratégia de qualidade especificamente japonesa.
O legado deixado por Kaoru Ishikawa para a gestão da 
qualidade é o conceito de Círculo de Controle da Qualidade 
(CCQ ) e sete ferramentas da qualidade que são: Gráfico de 
Pareto, Diagrama de Causa e Efeito, Histograma, Folhas de 
Verificação, Gráficos de Dispersão, Fluxogramas e Cartas 
de Controle. Veremos em maiores detalhes estas importantes 
ferramentas mais adiante em nosso estudo.
9QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Porque precisamos pensar em qualidade de 
software?
Estamos cercados por softwares em todos os lugares e somos 
lembrados disso o tempo todo. Por exemplo, os smartphones 
nos auxiliam, facilitando a nossa vida e algumas vezes nos 
dando a impressão de estarmos sendo vigiados. 
Desta forma, o software se tornou um componente essencial 
em nossas vidas como já era nas empresas estando embutido 
em sistemas de todas as naturezas: de transportes, médicos, 
militares, de telecomunicações, de processos industriais, etc.
Agora, vamos fazer um exercício de imaginação, onde se 
por um problema qualquer, em nosso dia a dia, ficarmos im-
possibilitados de usar o nosso smartphone, o caixa eletrônico 
do banco, ou outro item “indispensável”. Vocês não sentiram 
uma certa insegurança? Eu senti.
Se o cenário descrito anteriormente já nos deu um certo 
medo, sabemos que outros problemas de software podem ser 
bem mais graves. Podem representar o completo fracasso co-
mercial do produto, ou causar prejuízos milionários e no pior 
cenário, a perda de vidas humanas.
Aproveitemos esta conversa para analisarmos duas situa-
ções, onde erros aparentemente inocentes de software geraram 
consequências dramáticas. Nestes relatos falaremos a respeito 
do Projeto Ariane 5 e o Caso Therac-25.
Pensemos no nosso grau de dependência de softwares em nosso dia a dia. 
Então .... vamos imaginar que tudo parou.... o que faremos agora????
10QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Projeto Ariane 501
Em 4 de junho de 1996, foi lançado o primeiro foguete 
Ariane 5. Decorridos 40 segundos da sequência de lançamento 
e a uma altitude de 3.700 metros, o foguete desviou-se de sua 
trajetória e se autodestruiu com uma explosão. O custo des-
se desastre foi avaliado em mais de 300 milhões de dólares, 
quantia suficiente para pagar um salário de 2,5 mil dólares a 
100 programadores que trabalhassem durante um século.
Relato da análise do acidente: “O foguete começou a desin-
tegrar-se a 39 segundos, em razão a uma carga aerodinâmica 
excessiva: a pressão do ar contra o veículo estava muito elevada. 
O motivo foi o ângulo de ataque muito pronunciado, ou seja, em 
vez de “cortar” o ar na vertical, o foguete estava em um ângulo 
de 20 graus. O ângulo exagerado de ataque foi causado por 
um comando de direcionamento dos motores. Esse comando 
foi enviado pelo computador com base nos dados fornecidos 
pelo SRI-2. Entre esses dados havia um padrão de bits signi-
ficando um código de erro, incorretamente interpretado como 
informação de voo.
O SRI-2 não forneceu dados corretos, mas um código de 
erro, em virtude de uma exceção de software. O sistema de 
reserva (SRI-1) não pôde ser utilizado porque ele próprio já 
havia reportado a mesma falha, 72 milissegundos antes.
Mas, o que causou, de fato, o problema? Uma exceção 
proveniente de um cálculo: um número em ponto f lutuante 
representado com 64 bits foi convertido para um inteiro com 
sinal de 16 bits. O número era demasiado grande para ser 
representado com 16 bits e isso causou uma falha. Existiam 
outros pontos do mesmo código com conversões semelhantes, 
mas que eram protegidos por testes. O trecho do software havia 
sido copiado do Ariane 4, onde funcionava corretamente; no 
Ariane 5, o cálculo se tornava defeituoso em razão do com-
portamento diferente do foguete. Pior do que isso, tal cálculo 
sequer era necessário. ”
Este exemplo nos mostra alguns aspectos que cercam a 
qualidade de software:
• a importância e o papel determinante dos requisitos sobre 
11QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
os resultados;
• a dificuldade de garantir que requisitos sejam consistentes 
em projetos complexos;
• a lei de Dijkstra, segundo a qual testes não garantem 
a ausência de erros devido à dificuldade de verificar e 
validar programas completamente.
Caso Therac-25
 O Therac-25 era uma máquina utilizada em terapia 
radiológica. Diferente de suas versões anteriores, era totalmen-
te controlado por um computador, um PDP-11. Enquanto as 
versões anteriores possuíam travas mecânicas para impedir 
erros de operação, no Therac-25 toda segurança ficou a cargo 
do software. As mensagens de erro não eram claras: algumas 
se limitavam a palavra malfunction, seguida de um número 
entre 1 e 64. A ocorrência de falhas era bastante comum; não 
obstante, os operadores teriam recebido a informação de que 
não era preciso se preocupar.
Em 26 de julho de 1985, na Ontario Cancer Foundation, em 
Ontário, Canadá, um operador acionou a máquina e decorridos 
5 segundos ela parou de funcionar. O display mostrava uma 
mensagem de que nenhuma radiação teria sido emitida e que a 
máquina estava em simples pausa aguardando para continuar a 
operação. Como se tratava de mensagens comuns, o operador 
simplesmente ativou outra vez o Therac-25. A máquina des-
ligou-se novamente com as mesmas mensagens. O operador 
insistiu um total de 5 vezes, quando, então, o Therac-25 entrou 
em um modo de suspensão que obrigava uma reinicialização 
do computador. Um técnico do hospital foi chamado e não 
verificou nada de anormal com o equipamento; não seria a 
primeira vez que isso teria acontecido.
A paciente faleceu em 3 de novembro. Uma autópsia reve-
lou que a superexposição à radiação causou tantos danos que, 
se ela tivesse sobrevivido, seria preciso receber uma prótese 
para a cabeça do fêmur praticamente destruída pela radiação. 
No total, seis pacientes foram vítimas dos erros de projeto do 
Therac-25.
12QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Qualidade de software
Agora que já conhecemos um pouco sobre qualidade e 
já tomamos consciência dos impactos que erros de software 
podem causar, entramos no primeiro tema de nossos estudos, 
a famosa Qualidade de Software.
Podemos definir a qualidade de software como uma gestão 
de qualidade efetiva aplicada de modo a criar um produto útil 
que forneça valor mensurável para aqueles que o produzem e 
para aqueles que o utilizam. Devemos ter em mente que um 
grande conjunto de fatores definirá se obteremos ou não sof-
tware de qualidade.
Como exemplo de tentativa de enquadramento do software 
com qualidade, apresentamos as dimensões de qualidade de 
Garvin abaixo: 
Questões referentes a empresas de software
Não é somente devido a falhas em testes ou levantamentosde requisitos ineficientes que residem os problemas. Observa-
mos que as próprias empresas de software possuem modelos 
imaturos de desenvolvimento, e outros problemas internos 
gerando softwares com baixa percepção de qualidade e de 
manutenção custosa.
Dentre os principais problemas podemos citar:
• acúmulo de trabalho;
• produto as vezes funciona, mas o prazo e custo para 
construí-lo são maiores do que o planejado;
• sucesso depende muito do esforço heroico das pessoas;
• os clientes e funcionários ficam insatisfeitos.
Os problemas listados anteriormente e outros tantos, le-
PROCESSO DE SOFTWARE
PROCESSO DE 
DESENVOLVIMENTO
SOFTWARE PRODUTO
SOFTWARE COM QUALIDADE
USUÁRIO
DESENVOLVEDOR
ORGANIZAÇÃO
PADRÕES ATENDIDOSREQUISITOS ATENDIDOS
REQUISITOS PADRÕES
Fonte: Autor
13QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
varam as organizações desenvolvedoras de software a atuar 
fortemente na qualidade de seus produtos e processos. As 
normas representadas pelas figuras abaixo, são exemplos de 
esforços para sumarizar boas práticas no desenvolvimento de 
software, fornecendo insumos para que as empresas constru-
am suas metodologias para o desenvolvimento, manutenção e 
evolução de suas aplicações.
Qualidade do Produto e Qualidade do 
Processo
O título nos traz as duas dimensões principais da quali-
dade, que estão intimamente ligadas e são descritas a seguir.
Quem é o cliente?
Cliente é todo aquele que recebe o resultado de um conjunto 
de atividades, podendo ser:
• Interno: recebe os resultados do trabalho que nós fa-
zemos.
• Externo: recebe os resultados do trabalho que a orga-
nização faz.
Qualidade do Processo
Processo de Software consiste em um conjunto de ferra-
mentas, métodos e práticas utilizadas por pessoas para produzir 
e manter sistemas de software.
O processo é como um livro de receitas, que informa ao 
cozinheiro o procedimento de preparo e os ingredientes ne-
cessários. Cada receita define o modelo de um prato.
14QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Então é fundamental que o processo seja estabelecido e se-
guido para que possamos ter um processo produtivo controlado. 
Além disso, é fundamental que este processo seja aprimorado 
constantemente, pois as necessidades mudam, o cenário do 
mercado muda e novas metodologias/tecnologias surgem.
Qualidade do Produto
A qualidade de um produto de software é altamente in-
f luenciada pela qualidade do processo utilizado em seu desen-
volvimento e manutenção.
Um processo de maior qualidade irá levantar os requisitos 
de uma forma mais correta e completa, determinando se um 
produto de software possuirá ou não qualidade.
Além da inf luência inegável do processo, os testes são um 
instrumento extremamente valioso para aumentar o grau de 
qualidade de um produto. As atividades de teste englobam não 
somente o produto pronto, mas também auditorias e inspeções 
em todos os pontos do desenvolvimento, desde a definição de 
estratégias para um produto de software. 
Processo de Garantia da Qualidade
Serve para garantir que os processos e produtos de software, 
no ciclo de vida do projeto, estejam em conformidade com os 
requisitos especificados e referenciados aos planos estabelecidos.
Os erros em software são gerados durante todo o processo 
de desenvolvimento, embora mais da metade seja ocasionada 
nas fases iniciais do desenvolvimento. O antigo modelo para 
garantia da qualidade pregava que o software somente ia ser 
verificado nas fases de testes, porém este modelo deve ser evi-
tado a todo custo, através do planejamento da qualidade em 
ATIVIDADES
OBJETIVOS
RECURSOS E INSFRAESTRUTURA
ENTRADAS SAÍDAS
15QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
todas as etapas do desenvolvimento dos produtos.
Este tópico nos leva diretamente aos estudos realizados 
pelo PMI (Project Management Institute) que no seu guia 
PMBOK subdivide a garantia da qualidade em três pilares, 
conforme a figura a seguir.
Planejamento da Qualidade
Consiste na identificação de quais padrões de qualidade 
serão utilizados no projeto de software, através da verificação 
de quais são importantes para o projeto em questão, além de 
estabelecer o plano de execução para satisfação dos padrões 
selecionados.
Garantia da Qualidade
Com os padrões selecionados e o plano definido, neste pilar 
executamos as atividades para garantir a qualidade. Importante 
avaliar desde já se o que está sendo gerado pelo projeto está 
em conformidade com o que foi solicitado e se os processos 
definidos estão sendo efetivos neste caminho. 
Utilizando este processo corretamente, conseguiremos 
identificar melhorias tanto no produto quanto nos processos 
envolvidos para produzi-lo.
PROSPECÇÃO DO 
CLIENTE REQUISITOS ENTREGAIMPLEMENTAÇÃOANÁLISE
PROJETO 
(DESIGN()
TEMPO
Garantia da Qualidade em todo o ciclo de desenvolvimento
Fonte: Bartié 2002
Adaptado de Bartié 2002
16QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Controle da Qualidade
O objetivo aqui é acompanhar os resultados do projeto 
e identificar se os mesmos encontram-se em conformidade 
com os padrões de qualidades definidos. Este processo deve 
ser executado de forma contínua e em todas as fases do de-
senvolvimento. Identificado uma inconsistência, esta deve ter 
a causa raiz encontrada e tratada de forma correta, a fim de 
evitar a repetição.
Garantia x Controle da Qualidade
Pessoal!!! Vamos resumir o que vimos sobre Garantia e 
Controle da Qualidade através da tabela a seguir, onde com-
paramos os dois processos.
Garantia da Qualidade Controle da Qualidade
Foco:
Quando utilizamos, temos 
por objetivo evitar defeitos no 
processo usado para fazer o 
produto. Com isso, concluímos 
que este é um processo 
proativo de qualidade.
Quando utilizamos, temos por 
objetivo identificar e corrigir 
defeitos no produto final. 
Com isso, percebemos que o 
controle da qualidade é um 
processo reativo.
Objetivo:
O objetivo do QA é melhorar 
o desenvolvimento e testar 
processos para que não 
surjam defeitos quando 
o produto está sendo 
desenvolvido.
O objetivo do controle de 
qualidade é identificar 
defeitos depois que o produto 
é fabricado e antes de ser 
lançado.
Como?
Estabelecendo um bom 
sistema de gestão da 
qualidade e avaliação da sua 
adequação com auditorias 
periódicas da conformidade 
das operações do sistema.
Encontrando e eliminando 
fontes de problemas de 
qualidade através de 
ferramentas e equipamentos 
para que as demandas do 
cliente sejam continuamente 
atendidas e superadas.
17QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
O quê?
Prevenção de problemas 
de qualidade por meio 
de atividades planejadas 
e sistemáticas, incluindo 
documentação.
As atividades ou técnicas 
utilizadas para atingir e 
manter a qualidade do 
produto, processo e serviço.
Responsáveis:
Todos os membros das 
equipes envolvidas no 
desenvolvimento do produto.
O controle da qualidade é 
geralmente responsabilidade 
de uma equipe específica, que 
testa o produto para ver se 
existem defeitos.
Exemplo:
Temos a verificação e 
inspeção prévia.
Validação / Teste de Software.
Técnicas Estatísticas
Ferramentas e técnicas 
estatísticas quando aplicadas 
a processos (entradas de 
processo e parâmetros 
operacionais), eles são 
chamados Controle Estatístico 
de Processos (CEP).
Quando as ferramentas e 
técnicas estatísticas são 
aplicadas aos produtos 
acabados (saídas do 
processo), eles são chamados 
de Controle da Qualidade 
Estatística (CQE).
Como Ferramenta:
Garantia da qualidade é uma 
ferramenta de gestão.
Controle da qualidade é uma 
ferramenta corretiva.
Metodologia:
A garantia da qualidade é 
voltada ao processo.
O controle da qualidade é 
voltado ao produto.
Custos da Qualidade
A qualidade não é totalmente algo que podemos obter de 
forma gratuita. Para tanto, investimentos financeiros, treina-
mentos, softwares e outras iniciativas precisam ser realizadas 
adicionalmente para a busca da qualidade de software como 
um todo. 
Segundo Bartié(2002), “Um dos maiores desafios a ser 
considerado é estabelecer um modelo de custos relacionados 
a implantação de um processo de garantia da qualidade de 
software.” 
A figura mostra um modelo de custo de qualidade de 
software proposto por Bartié:
18QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Custo do Projeto
Custo da Qualidade
Custo do 
Desenvolvimento
Custo da Não-
Conformidade
Custo da Prevenção de 
Defeitos
Custo da Conformidade
Custo de Produção do 
Software
• Re-revisões;
• Retestes;
• Correções:
• Código Fonte;
• Documentação;
• Reestruturação;
• Redistribuição de 
Versões;
• Atrasos no 
Cronograma;
• Falhas de 
Produção;
• ETC.
• Metodologias;
• Treinamento;
• Ferramentas;
• Políticas;
• Procedimentos;
• Planejamento;
• Análises;
• Métricas;
• Relatório da 
Qualidade;
• Projetos de 
Inovação.
Custo da Prevenção de 
Defeitos
Revisões:
• Problema;
• Requisitos;
• Modelagem;
• Planos de Teste;
• Scripts de Teste;
Inspeções de Código;
Teste (1a Execução);
Auditorias. Existe uma correlação entre os custos da 
não conformidade com os investimentos 
em prevenção de defeitos. Quanto maiores 
estes investimentos, menor a incidência de 
não-conformidades.Modelo de Custo de Qualidade de Software, adaptado de Bartié 2002.
19QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
No modelo apresentado, é proposta a criação de duas categorias 
separadas para os custos relacionados a conformidade e o custo da 
não-conformidade: 
Custo da Detecção de Defeitos
Podemos fazer referências para o termo controle da qualidade, ou 
seja, o foco está exatamente no produto. As atividades aqui realizaremos 
aqui serão orientadas ao produto desenvolvido, e estas incluem: 
• Revisões de requisitos; 
• Revisões de Modelagem; 
• Revisões de Planos de Teste; 
• Inspeções de código; 
• Testes de Software. 
Custo da Prevenção de Defeitos
Assim como detecção de defeitos está associada ao controle da 
qualidade, a prevenção de defeitos está associada a garantia da quali-
dade, ou seja, o foco está exatamente no processo. As atividades aqui 
realizadas são orientadas ao processo, e estas incluem: 
• Definição de Metodologias; 
• Treinamentos; 
• Ferramentas de apoio ao processo de desenvolvimento; 
• Definição de Políticas; 
• Procedimentos; 
• Padrões; 
• Especificações e convenções; 
• Planejamento do SQA; 
• Relatórios de Qualidade para melhoria de processo. 
Custo da Não-Conformidade
Por outro lado, o custo da não-conformidade está relacionado às 
perdas que o projeto terá, não optando pela detecção e prevenção de 
defeitos: 
• Re-reviões; 
• Retestes; 
20QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
• Correções de código-fonte e documentação muito constantes; 
• Reestruturação; 
• Redistribuição das versões do software; 
• Atrasos no cronograma; 
• Falhas na produção. 
Deveremos associar a estrutura de custos apresentada a todas as 
atividades de um processo de engenharia de software. Em todos os 
projetos a serem construídos ou modificados, devemos ter uma política 
de distribuição de custos semelhante ao modelo apresentado para todas 
as atividades.
Síntese
Neste capítulo vimos que a qualidade de software é um tema muito 
importante, superando as fronteiras somente do software e interferin-
do fortemente na vida das pessoas usuárias dos mesmos, inclusive em 
questões de saúde.
Também observamos que o tema qualidade de software baseia-se 
nos princípios e gurus da qualidade padrão, tendo evoluído juntamente e 
constantemente com as práticas utilizadas em outros setores da economia.
Vimos também que a qualidade depende de um processo bem 
estabelecido, que seja seguido e que evolua conforme evoluem as ne-
cessidades do negócio, tanto da parte do usuário quanto da parte da 
empresa fornecedora. 
Além disso, sabemos agora que somente um processo não garante 
a qualidade do produto, precisamos prestar muita atenção ao que está 
na parte interna do software, ou seja, a forma que o mesmo está sendo 
construído, mesmo que o que apareça ao usuário funcione perfeitamente, 
seja bonito e tenha uma usabilidade surpreendente.
Podemos observar que existem entidades dedicadas a buscar a maior 
padronização possível nos processos de software e oferecer garantias de 
que a empresa está alinhada com os padrões (através das certificações).
Por fim, conseguimos agora dimensionar os custos que um controle 
de qualidade eficiente pode evitar, custos esses que podem ser financeiros 
ou não. Também neste tema sabemos que deve haver uma conscientização 
de todos os níveis hierárquicos da empresa sobre os impactos que uma 
suposta falta de qualidade ou retrabalho podem causar, gerando assim 
engajamento e comprometimento com a melhoria contínua.
Exercícios
1. O que os gurus da qualidade estudados neste capítulo têm 
em comum? Explique.
2. Tendo em vista o que estudamos, qual o primeiro passo para 
a implantação de um sistema de qualidade de software em uma 
empresa que desenvolve sistemas?
3. Pesquise sobre novos gurus da qualidade, que prosseguiram 
com o trabalho dos vistos neste capítulo. Quem são eles? O que 
cada um defende? Quais as evoluções que estão nos trazendo?
4. Faça uma pesquisa para identificar as principais normas 
aplicadas para qualidade em desenvolvimento de software.
5. A partir da pesquisa do item 4, escolha a principal para fazer 
um resumo de 1 página sobre ela.
22QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
As ferramentas apresentadas a seguir foram propostas por 
Kaoru Ishikawa e são utilizadas para coleta, processamento e/ou 
disposição das informações sobre a variabilidade dos processos. 
Todas visam a melhoria dos processos analisados.
 Mas quais são as principais ferramentas? A lista está na 
figura a seguir, pessoal!!! Importante notarmos que nem todas 
as ferramentas possuem o mesmo foco.
FERRAMENTAS 
DA QUALIDADE
As ferramentas tradicionais da qualidade 
são 100% aplicáveis ao desenvolvimento de 
software. Vamos estudá-las?
FLUXOGRAMA
HISTOGRAMA
FOLHAS DE VERIFICAÇÃO
GRÁFICO
DE PARETO
DIAGRAMA DE
CAUSA E EFEITO
DIAGRAMA
DE DISPERSÃO
CARTAS
DE CONTROLE
Foco na Identificação do Problema Foco na Análise do Problema
Fonte: Autor
23QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Fluxograma
A finalidade desta ferramenta é identificar o caminho real 
e ideal para um produto ou serviço com o objetivo de identi-
ficar os desvios. O f luxograma é uma ilustração sequencial de 
todas as etapas de um processo, mostrando como cada etapa 
é relacionada. Ele utiliza símbolos facilmente reconhecidos 
para denotar os diferentes tipos de operações em um processo. 
Sempre possui um início, um sentido de leitura (ou f luxo) e 
um fim.
Os principais símbolos aceitos serão apresentados na tabela 
a seguir:
Antes de iniciarmos a preparação de um f luxograma de 
processo temos que conhecer muito bem a rotina do processo. 
Título Símbolo
O que representa 
no fluxo
Terminal
Ponto de início e 
término do fluxo.
Processamento
Operações 
manuais.
Documento
Relatórios, 
formulários, 
documentos, 
fichas, etc.
Decisão
Possibilidade de 
alternativas (sim/
não, +/-, etc.).
Fluxo do processo
Indica o fluxo de 
informações e de
operações.
Conector de fluxo
Conexão do fluxo 
na mesma página.
Conector de página
Conexão de fluxo 
de uma página 
para outra página.
Informações
adicionais
Observações, 
explicações ou 
algo inserido no 
processo.
24QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Devemos nos familiarizar bem com o processo e coletar infor-
mações de todos os envolvidos (do operador, supervisor, equipe 
de compras, setor financeiro, etc.). Também é indicado que a 
pessoa detentora do maior conhecimento no processo partici-
pe da elaboração do f luxograma. Descubra o que puder sobre 
as atividades. Trabalhe com fatos e dados não com opiniões. 
Organize as informações em um ou mais f luxogramas.
Os f luxogramas também podem ser elaborados para qual-
quer sequência de eventos de natureza administrativa, tais 
como: trajeto deuma fatura, f luxo de materiais, etapas em um 
processo de alteração técnica, liberação de cota, colocação de 
pessoal, venda ou assistência técnica de um produto.
Regras básicas dos f luxogramas:
1. O texto de cada símbolo deve se limitar a instrução a 
ser executada.
2. O texto do símbolo processo deve iniciar com um verbo 
na voz ativa.
3. Apenas uma linha de f luxo deve partir ou chegar a um 
terminador ou conector.
4. O símbolo de processo admite mais de uma linha de 
entrada de f luxo e apenas uma linha de saída.
5. O símbolo de decisão admite mais de uma linha de en-
trada de f luxo (alguns autores recomendam apenas uma 
linha de entrada de f luxo) e várias linhas de saída.
6. O símbolo de documento (impressão ou leitura) deve 
possuir uma linha de f luxo chegando e uma outra saindo.
Regras para processamento de fluxo de execução:
O fluxograma permite três ordens distintas de execução:
• Sequencial: as atividades são executadas uma após a outra.
• Por seleção: ocorre quando uma via de processamento 
é escolhida em um ponto de bifurcação, de forma que 
cada via conduz a um processamento distinto.
• Por repetição: faz com que a execução ocorra em ciclos de 
processamento até atingirem uma condição de finalização.
25QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Processamento sequencial:
• Processamos um conjunto de passos (ações) em série.
• Não há qualquer possibilidade de alterar a ordem de 
processamento das ações.
• Após processarmos o 1º passo, processamos o 2º e assim 
sucessivamente.
Processamento por seleção:
• Utilizamos o símbolo de decisão para escolhermos um 
caminho de processamento a ser seguido.
• O fluxo de processamento segue por uma das vias, de-
pendendo do valor da expressão avaliada no início da 
estrutura. 
Processamento por repetição:
• Neste caso, também há a necessidade de tomarmos uma 
decisão com base no valor lógico de uma expressão.
• No entanto, executaremos repetidamente a mesma sequ-
ência de ações enquanto o resultado da expressão lógica 
se mantiver verdadeiro.
Exemplo completo: Acompanhamento de um setor de 
produção
Vantagens
Como ferramenta de análise de processos, o f luxograma 
DAR UM
EM T
POR MÁ
A
INÍCIO
FIM
VERIFICAR DOCUMENTAÇÃO
IDENTIFICAR
VERIFICAR
CONTROLE
EMITIR
RELATÓRIO
VERIFICAR ERROS
TOMAR AS AÇÕES
NECESSÁRIAS
TOMAR AS AÇÕES
NECESSÁRIAS
HÁ NÃO
CONFORMIDADE
EM ORDEM?
SIM
SIM
NÃO
NÃO
1
1
ORDENS DE SERVIÇO
PLANOS DE CONTROLE
RELATÓRIOS DE INSPEÇÃO
REGISTROS
DAR UMA VOLTA 
COMPLETA EM TODO 
SETOR, MÁQUINA POR 
MÁQUINA, 4 X AO DIA
INSPECIONAR LINHA 
DE PRODUÇÃO
26QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
apresenta vantagens que o qualificam como eficaz no trabalho 
a que se propõe:
• É uma ferramenta gráfica, um retrato, quadro ou dese-
nho, sendo muito mais representativo do que centenas 
de palavras escritas.
• Permite uma visão global de todo o processo analisado. 
Os integrantes de cada atividade passam a se ver como 
componentes do processo e conseguem enxergar como 
podem inf luenciar ou ser inf luenciados pelas atividades 
antecedentes ou subsequentes.
• Mostra com clareza oportunidades de aperfeiçoamento 
no processo.
• Define exatamente o pessoal envolvido nas atividades 
do processo, identificando muitas vezes clientes negli-
genciados em análises anteriores.
• As informações sobre o processo são mais claras, per-
mitindo explicá-lo com facilidade para os profissionais 
que não tomam parte dele.
• Permite fixar limites com uma maior facilidade.
Diagrama de Causa e Efeito
A finalidade desta ferramenta é explorar e indicar todas as 
causas possíveis de uma condição ou um problema específico. 
Podemos encontrar este diagrama como sendo chamado de 
“Diagrama de Ishikawa”. Ele é um método utilizado para lo-
calizar a causa original ou raiz de um problema e sua estrutura 
macro está desenhada na figura a seguir.
Passo a passo de como construiremos o diagrama:
1. Definimos o cabeçalho:
• Pode conter o título, data e autor (ou grupo de trabalho).
2. Definimos o efeito:
• Vamos utilizar uma definição objetiva (em uma frase 
para o problema a ser analisado). Normalmente é escrito 
no lado direito e ao centro da folha.
27QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
3. Desenhamos o eixo central:
• É uma f lecha horizontal que aponta para o efeito. Usu-
almente desenhada no meio da folha.
4. Indicamos as categorias das possíveis causas:
• Cada categoria representa os principais grupos de fato-
res relacionados com efeito. As f lechas são desenhadas 
inclinadas, as pontas convergindo para o eixo central.
• Para cada efeito existem, seguramente, inúmeras causas 
que podem ser agrupadas em seis categorias conhecidas 
como “6 M”: Método, Mão de Obra, Matéria-prima, 
Meio Ambiente, Medida e Máquina.
• Nas áreas de serviços e processos transacionais utilizam-se 
como categorias básicas: Procedimentos, Pessoas, Ponto, 
Políticas, Medição e Meio Ambiente.
5. Identificaremos as possíveis causas e subcausas (itens 5 
e 6 da figura):
• Causa: é uma causa potencial pertencente a uma cate-
goria que pode colaborar com o efeito (as f lechas são 
desenhadas em linhas horizontais, apontando para o 
ramo da categoria).
• Subcausa: é uma causa potencial que pode contribuir com 
uma causa específica (são ramificações de uma causa).
• Realize um brainstorming que permita a geração do 
maior número de causas em curto intervalo de tempo. 
Faça, repetidamente a pergunta: Quais as causas que, 
provavelmente, provocaram esse efeito?
6. Revisamos todo o diagrama:
• É aconselhável que seja feita uma investigação para frente, 
a partir de cada subcausa ou causa até o efeito. Faça, re-
petidamente, a pergunta: Esta causa, realmente, provoca 
este efeito?
Exemplo de diagrama para o problema a seguir: Imagine 
que você está tentando monitorar falhas de seu próprio com-
portamento e determinou que seu principal problema é falar 
demais em momentos impróprios.
28QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Principais razões para utilizarmos o Diagrama de Ishikawa
• Para identificar as informações a respeito das causas de 
um problema.
• Para organizar e documentar as causas potenciais de um 
efeito ou de uma característica da qualidade.
• Para indicar o relacionamento de cada causa e subcausa 
as demais, e, ao efeito ou característica da qualidade.
• Reduzir a tendência de deixar de procurar a causa ver-
dadeira, ou parar cedo demais, devido à complexidade 
do conjunto de informações.
Benefícios do Diagrama de Ishikawa
• Ajuda o aperfeiçoamento do processo.
• Documenta de forma visual as causas potenciais, que 
podem ser revistas e atualizadas com facilidade poste-
riormente.
• Provê urna estrutura para o brainstorming.
• Ajuda no envolvimento de todos.
Folhas de Verificação
As folhas de verificação são tabelas ou planilhas simples, 
usadas para facilitar a coleta e análise de dados. O uso das folhas 
de verificação economiza tempo, eliminando o trabalho de se 
desenhar figuras ou escrever números repetitivos.
São formulários planejados, nos quais os dados coletados 
são preenchidos de forma fácil e concisa. Registram os dados 
dos itens a serem verificados, permitindo uma rápida percepção 
da realidade e uma imediata interpretação da situação, ajudando 
29QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
a diminuir erros e confusões.
Dica: O tempo da coleta não pode ser muito extenso. Deve-se 
definir um tempo mínimo e um tempo máximo!
Folha de Verificação – Quando usamos?
As folhas de verificação são ferramentas que questionam 
o processo e são relevantes para alcançar a qualidade. 
Usamos para:
• Dispor os dados de uma forma organizada, facilitando 
a utilização.
• Verificar a distribuição do processo: coleta de dados de 
amostra da produção ou de processos administrativos;
• Verificar itens defeituosos ou não conformidades: saber 
o tipo de defeito e sua porcentagem.
• Verificar a localização do defeito ou da não conformidade: 
mostrar o local e a formade ocorrência.
• Verificar as causas dos defeitos ou das não conformidade.
• Fazer comparação de uma amostra real com os limites 
de especificação.
• Investigar aspectos do defeito.
• Obter dados de amostras específicas.
• Determinar o turno, dia, hora, mês e ano, período em 
que ocorre o problema.
• Fornecer dados para várias ferramentas, tais como: dia-
grama de Pareto, diagrama de dispersão, diagrama de 
controle, histograma, etc.
Pré-requisitos para Construção da Folha de Verificação:
• Identificar claramente o objetivo da coleta de dados: 
quais são os dados a serem coletados e porquê?
• Decidir como coletar os dados: Como serão coletados os 
dados? Quem irá coletar os dados? Quando serão cole-
tados os dados? Qual método será utilizado para coleta 
dos dados?
• Estipular a quantidade de dados que serão coletados: 
30QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
tamanho da amostra.
• Coletar os dados dentro de um tempo específico: decidir 
o tipo de folha de verificação a ser usada, decidir qual o 
formato dos dados, serão números, valores ou símbolos?
• Fazer um modelo de folha de verificação.
Exemplo de folha de verificação:
Que eventos estão ocorrendo?
Por exemplo, tipo de defeito: ortografia, pontuação, man-
chas, parágrafos, números errados e alinhamento.
Quando ou quantas vezes ocorrem os eventos
Por exemplo, frequência dos defeitos: ortografia: 5; pon-
tuação: 13; manchas: 4; parágrafos: 12; números errados: 2; 
alinhamento: 20.
Onde estão ocorrendo os eventos?
Por exemplo, localização do defeito: No local onde foram 
colhidas as informações.
Análise:
• Os eventos em questão estão ocorrendo junto com outras 
Erro de 
Digitação
Jan Fev Mar Abr Total
Ortografia | || | | 5
Pontuação ||| |||| || |||| 13
Números 
errados
| | 2
Manchas | | | | 4
Parágrafos || ||| ||||| || 12
Alinhamento |||| |||||| |||| |||||| 20
TOTAL 11 17 14 14 56
31QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
mudanças ou eventos? (Ex.: outros fatores de influência).
• Alterações de profissional, equipamento etc.
• Depois pergunte: Esqueci de alguma coisa? Então faça 
uma ref lexão.
• Em resumo, lembre-se da finalidade da coleta de dados 
e tente elaborar uma lista de verificação apropriada e de 
fácil utilização, para atender as suas necessidades.
Gráfico de Pareto
O gráfico de Pareto é um diagrama que apresenta os itens 
e a classe na ordem dos números de ocorrências, apresentando 
a soma total acumulada.
Permite-nos visualizar diversos elementos de um problema 
auxiliando na determinação da sua prioridade. É representado 
por barras dispostas em ordem decrescente, com a causa prin-
cipal vista do lado esquerdo do diagrama, e as causas menores 
são mostradas em ordem decrescente ao lado direito. Cada 
barra representa uma causa exibindo a relevante causa com a 
contribuição de cada uma em relação à total. É uma das fer-
ramentas mais eficientes para encontrar problemas. Priorizar 
os poucos, mas vitais.
Como faremos um gráfico de Pareto:
1. Identificamos o problema:
• Identificamos o problema a ser investigado e separamos 
por categorias aspectos como: não conformidades, causas, 
entre outras.
• Exemplo: Uma empresa fabrica e entrega seus produtos 
para várias lojas de varejo e quer diminuir o número de 
devoluções. Decidiu-se investigar as seguintes razões para 
a devolução da entrega: separação errada, faturamento 
incorreto, atraso da transportadora, pedido errado, atraso 
na entrega, preço errado, produto danificado e outras.
2. Quantificaremos os valores para cada categoria:
• Coletamos dados para quantificar a extensão do problema, 
evidenciando a contribuição de cada categoria.
32QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
• Exemplo: A partir da coleta dos dados, obteve-se as 
seguintes ocorrências para cada categoria:
3. Listamos as categorias em ordem decrescente:
• Vamos listar as categorias em ordem decrescente de nú-
mero de ocorrências.
• Exemplo: Para o exemplo anterior, a nova tabela é:
4. Calculamos o número de ocorrências acumulado:
• Incluiremos uma nova coluna na tabela com os casos 
acumulados.
• Exemplo: Para o exemplo anterior, a nova tabela é:
Razões Número de Ocorrências
Separação errada 45
Faturamento incorreto 60
Atraso da transportadora 125
Pedido errado 30
Atraso na entrega 140
Preço errado 20
Produto danificado 65
Outros 15
Total 500
Razões Número de Ocorrências
Atraso na entrega 140
Atraso da transportadora 125
Produto danificado 65
Faturamento incorreto 60
Separação errada 45
Pedido errado 30
Preço errado 20
Outros 15
Total 500
33QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
5. Calculamos a frequência relativa (%) e acumulada (%) 
para cada categoria:
• Frequência relativa = (número de ocorrência na categoria 
/ número total de ocorrências) x 100.
• Frequência acumulada = (casos acumulados até a categoria 
/ número total de ocorrências) x 100. Exemplo:
6. Construamos um gráfico de colunas:
• Para cada categoria definida no eixo horizontal, cons-
truiremos uma coluna com altura proporcional ao seu 
número de ocorrências.
• No lado esquerdo ficarão aquelas que contribuem, mais 
fortemente, para o problema analisado.
7. Construamos um gráfico de linhas:
• Iremos mostrar a contribuição acumulativa das categorias 
Razões
Número de 
Ocorrências
Ocorrências 
Acumuladas
Atraso na entrega 140 140
Atraso da 
transportadora
125 265
Produto danificado 65 330
Faturamento 
incorreto
60 390
Separação errada 45 435
Pedido errado 30 465
Preço errado 20 485
Outros 15 500
Total 500
Razões
Número de 
Ocorrências
Ocorrências 
Acumuladas
Frequência 
Relativa
Frequência 
Acumulada
Atraso na entrega 140 140 28 28
Atraso da 
transportadora
125 265 25 53
Produto danificado 65 330 13 66
Faturamento 
incorreto
60 390 12 78
Separação errada 45 435 9 87
Pedido errado 30 465 6 93
Preço errado 20 485 4 97
Outros 15 500 3 100
Total 500 100
34QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
no eixo vertical direito, no qual constará, por exemplo: 
participação acumulada (%). Exemplo:
Sem um Plano de Ação para resolver a causa dos problemas, 
nossa análise não servirá para nada! Pense nisso!!
Para diminuirmos o problema de devolução de produtos, 
teremos que criar um plano de ação para a empresa diminuir os 
atrasos de entrega da fábrica e da transportadora. Observando 
o gráfico anterior, resolveremos em torno de 53% do problema.
Diagrama de Dispersão
O objetivo é mostrar o que acontece com uma variável 
quando a outra muda, para testar possíveis relações de causa 
e efeito.
Elaboramos diagramas de causa e efeito (Ishikawa) quando 
precisamos enumerar todas as causas possíveis relacionadas a 
uma situação específica. Com o diagrama de dispersão deve-
mos então estudar a relação entre as causas e os efeitos, agin-
do naquelas relacionadas e deixando as não relacionadas. Se 
for encontrada uma nova causa devemos adicioná-la na lista. 
Somente através deste processo o trabalho de elaboração do 
diagrama de dispersão terá um impacto real.
O diagrama de dispersão é um gráfico onde pontos no 
espaço cartesiano XY são usados para representar simultane-
amente os valores de duas variáveis quantitativas, medidas em 
cada elemento do conjunto de dados.
Um diagrama de dispersão não pode provar que uma va-
riável causa outra, mas mostra se existe uma relação e a sua 
35QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
intensidade ou natureza.
Em um diagrama de dispersão o eixo horizontal (X) repre-
senta os valores medidos de uma variável e o eixo (Y) representa 
os valores da segunda variável.
Observemos nas figuras como os pontos marcados formam 
um padrão de agrupamento. A direção e a proximidade dos 
pontos nos indicam a intensidade da relação entre as variáveis.
Quanto mais o padrão tender a uma linha reta mais forte 
fica a relação entre as variáveis. Uma linha reta significaria que 
cada vez que uma variável se modificasse, a outra também se 
modificaria na mesma proporção.Como elaboramos um Diagrama de Dispersão:
1. Coletamos o maior número de pares de amostras de 
dados que julgarmos relacionados entre si e incluiremos 
eles na planilha.
2. Desenhamos os eixos horizontal e vertical do diagrama. 
Colocaremos os valores mais altos na parte superior do 
eixo vertical e à direita no eixo horizontal. Normalmen-
te colocamos a variável “causa “ no eixo horizontal e a 
variável ”efeito “, no eixo vertical.
3. Marcamos os dados no diagrama. Se houver valores 
repetidos, circularemos o ponto tantas vezes quantas 
forem necessárias.
Exemplo de Diagrama de Dispersão
Observemos atentamente o diagrama de dispersão a seguir, 
onde poderemos visualizar a relação entre a potência de um 
micro-ondas e o tempo de cozimento dos alimentos.
36QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Diagrama de Dispersão correspondente:
Interpretação dos Diagramas de Dispersão
Para que os diagramas de dispersão sejam fer-
ramentas úteis, a adoção de medidas apropriadas 
depende da interpretação correta. Apresentamos 
abaixo alguns exemplos dos diagramas de disper-
são mais comuns:
Correlação positiva
Um aumento em Y depende de um aumento 
de X. Se X estiver controlado, Y estará natu-
ralmente controlado, exemplo: peso x calorias 
ingeridas.
Possível correlação positiva
Se houver um aumento em X, Y sofrerá algum 
aumento, mas Y parece ter outras causas além de 
X, exemplo: chuva x trânsito.
Nenhuma correlação.
Acréscimos ou decréscimos em x não alteram 
y, exemplo: seca no Nordeste x colheita de uvas 
no Sudeste.
Possível correlação negativa
Um aumento em X causará uma tendência 
de decréscimo em Y. Exemplo: treinamento X 
erros cometidos.
Correlação negativa
Um aumento em X causará um decréscimo 
em Y, portanto, se X for controlado, Y será con-
trolado, exemplo: temperatura de conservação 
de alimento x prazo de validade. (Verdadeiro 
em uma faixa).
Tempo de 
cozimento 
(segundos)
Potência 
180 957
172 975
164 993
178 961
168 985
167 987
178 966
176 974
169 982
183 955
171 971
178 960
170 977
185 953
170 978
171 981
191 949
170 976
182 968
176 981
187 951
166 988
177 972
187 952
37QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Em resumo, nos diagramas de dispersão vamos nos lem-
brar dos seguintes pontos:
1. As relações positivas e negativas são igualmente impor-
tantes;
2. Podemos somente afirmar que X e Y estão relacionados 
e em que grau, não que um é causa do outro;
3. No caso de investigarmos a relação de mais de duas vari-
áveis há diversos métodos de correlação, mas estão além 
do escopo deste curso. Poderemos encontrar também 
testes estatísticos para calcular o grau exato de correlação, 
conhecido como coeficiente de correlação, mas que não 
será tratado nesta disciplina; entretanto, devemos estar 
cientes de sua existência.
Histograma
Usamos os histogramas para mostrar a frequência com que 
algo acontece. Por exemplo, em um caso onde fosse necessário 
mostrar de forma gráfica a distribuição de altura de estudantes 
de uma escola, uma das maneiras mais adequadas para isso 
seria fazê-lo por meio de um histograma.
O histograma é uma variação do gráfico de barras. Enquan-
to o gráfico de barras descreve os dados em barras e categorias 
separadas, o histograma representa os dados da mesma categoria 
no intervalo analisado, por isso, sem espaço entre as barras.
Alunos!! Ponto importante sobre a interpretação do histogra-
ma, considerando o formato do gráfico resultante! Analisemos as 
informações a seguir com atenção!!
Histograma simétrico ou normal: acontece 
quando o processo é padronizado e os dados são 
estáveis, permitindo variações pequenas. O pico 
dos dados fica ao centro do gráfico, e suas variações vão de-
crescendo de maneira simétrica dos dois lados.
Histograma assimétrico: acontece geralmente 
quando os dados são tolerados até um número 
limite, não podendo ultrapassar este limite. Seu 
pico é concentrado em um dos lados, e os dados fora de padrão 
decrescem para o lado oposto.
38QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Histograma com dois picos: acontece quando 
são apresentadas duas coletas de dados diferentes 
para comparação. A análise deve ser feita separa-
damente, observando ao desenho dos dois gráficos.
Histograma “platô”: acontece geralmente quando 
há anormalidade nos dados decorrentes de falhas. 
As barras têm praticamente os mesmos tamanhos.
Histograma aleatório: acontece quando os dados 
analisados não apresentam nenhum padrão. As 
barras sobem e descem sem critério.
Quando utilizamos o Histograma?
Utilizamos o histograma para analisar a frequência de vezes 
que as saídas de um processo estão padronizadas, atendendo 
aos requisitos estabelecidos e qual a variação que elas sofrem.
Com os dados dispostos graficamente, o Histograma per-
mite a visualização de resultados históricos e a análise de evi-
dências para a tomada de decisão da variação de frequências 
de maneira visual facilmente
Como faremos um histograma?
• Coletamos a amostra com um número significativo de 
dados, usando uma folha de verificação.
• Organizamos os dados em uma planilha.
• Determinamos o número de categorias e o intervalo en-
tre as categorias (caso façamos no Excel, esse valor será 
calculado automaticamente, porém precisamos lembrar 
de colocar os dados em uma única coluna, pois caso 
contrário o Excel irá fazer o gráfico incorretamente).
• Organize os dados, colando-os dentro das categorias, de 
acordo com o intervalo.
• Coloque os dados no gráfico, com as categorias no eixo 
horizontal e a frequência de ocorrência no eixo vertical.
• Verifique e analise a forma do gráfico.
39QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Exemplo de Histograma
O responsável de uma linha de produção queria saber se 
a densidade do produto metálico estava conforme o esperado. 
Ele coletou 80 amostras do produto.
Assim, ele pode perceber que as saídas estavam seguindo 
o padrão normal de variação. As amostras do produto analisa-
das ficaram dispostas próximas do centro em (torno de 80%), 
e que alguns frascos (em torno de 20%) apresentam concen-
tração próxima dos valores mínimos. Ou seja, nessa amostra 
coletada a maior parte dos produtos estão em conformidade 
com o esperado.
Entretanto, se o valor entre 35,4 a 36,8 fossem considerados 
não conformes, por exemplo, teríamos uma pequena quanti-
dade de produtos fora das especificações planejadas, e a partir 
de então, poderíamos aplicar ações corretivas nesse processo.
Amostras do Produto
40,9 43,6 41,3 39,9 40,6 39,8 44,2 37,9
40,8 36,6 42,3 43,5 41 39,6 41,3 43,5
41,5 43,7 39,9 41 41,8 42,3 40,2 39,1
43,2 38,4 41,9 39,2 38 40,4 40,1 39,4
38,7 41,3 41,4 40,9 40,3 39,2 39 40,7
42,3 40,6 41,2 40,2 40,4 39,5 45 39,9
43,4 40,4 41,6 40,6 40,2 42,8 43,7 39,7
41,5 40,1 41,7 41,8 42,9 43,4 43,3 41,9
43,4 41,7 40 38,3 42,1 39,3 37,2 43,8
39,6 41 42,3 39,2 40,4 35,4 39,2 42,6
40QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Cartas de Controle
Os gráficos de controle nos fornecem uma regra de decisão 
muito simples: pontos dispostos fora dos limites de controle 
indicam que o processo está “fora de controle”. Se todos os 
pontos dispostos estão dentro dos limites e dispostos de forma 
aleatória, consideramos que “não existem evidências de que o 
processo esteja fora de controle”.
Podemos observar no primeiro gráfico que os dados estão 
dispostos entre os limites do intervalo, exceto uma observação. 
Observe também que há indícios de falta de aleatoriedade no 
gráfico (os últimos 8 pontos estão abaixo da linha central), 
entretanto, o gráfico da Amplitude apresenta um comporta-
mento supostamente aleatório.
Para analisar o gráfico gerado, questionaremos sempre os 
dados!
Reflexões que podemos realizar:
• Quantos itens estão acima ou abaixo dos limites? Se houver, 
saberemos que tem alguma coisa bem errada acontecendo! 
• Existem muitos itens do mesmo lado da média? Sete itens 
do mesmo lado da média representam um problema de 
processo, nãoé normal acontecer isso.
• Quão próximos os itens estão da média? Se estiverem muito 
próximos, significa que seu processo está indo muito bem, 
talvez seja melhor reduzir os limites, é uma espécie de zoom.
• Existem várias outras análises possíveis, para tornar-se 
um especialista sugiro que procure um curso de Controle 
Estatístico de Processos.
E não esqueça, apenas olhar os dados não serve para muita 
coisa, se houver desvios, é preciso tomar ações corretivas. Para 
isso, nada mais útil que fazer uma análise de causa e efeito e, 
posteriormente, um plano de ação.
41QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Benefícios dos gráficos de controle
Os gráficos de controle, ao distinguir as causas comuns das 
causas especiais de variação e indicar se o problema é local ou 
merece atenção gerencial, evita frustrações e o custo de erros 
no direcionamento da solução de problemas.
Ao melhorar o processo, os gráficos de controle produzem:
• Um aumento na porcentagem de produtos capazes de 
satisfazer aos requisitos do cliente.
• Uma diminuição do retrabalho e sucata, diminuindo, 
consequentemente, os custos de fabricação.
• Aumenta a probabilidade geral de produtos aceitáveis.
• Informações para melhoria do processo.
Para que possamos atingir os benefícios da aplicação do 
CEP, a organização precisa se preparar:
Filosofia da gerência
As decisões da gerência da empresa podem afetar diretamente 
os programas de CEP em:
1. Focar a organização da empresa na diminuição da variação.
2. Estabelecer um ambiente aberto que minimize as competições 
internas e de suporte para o trabalho em equipe.
3. Dar suporte e favorecer os treinamentos necessários.
4. Aplicar o CEP para promover um melhor entendimento das 
variações da engenharia de processo.
5. Aplicar o CEP para gerenciar os dados e usar a informação 
obtida nas decisões do dia a dia.
Filosofia da engenharia
Como a engenharia usa a informação para poder planejar o 
desenvolvimento que podem e irão ter inf luência no nível de varia-
ção do produto final, apresentamos algumas maneiras de como a 
engenharia pode mostrar o uso efetivo do CEP:
1. Focar a organização na redução da variação através do plane-
jamento do processo, ou seja, número de mudanças no design, 
planejamento da manufatura e montagem.
42QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
2. Estabelecer um ambiente aberto que minimize a competição 
interna e prevaleça o trabalho em equipe.
3. Dar suporte para que os funcionários envolvidos no processo 
façam treinamentos adequados.
4. Aplicar o CEP para promover um melhor entendimento das 
variações da engenharia de processo.
5. Exigir um melhor entendimento da variação e estabilidade 
em relação aos dados que são usados no desenvolvimento do 
projeto.
6. Favorecer as mudanças na engenharia do produto que foram 
fruto das análises do CEP que podem ajudar na diminuição 
da variação.
Manufatura
Como a manufatura desenvolve e opera máquinas e os sistemas 
de transferência que podem impactar o nível e o tipo de variação 
no produto final.
1. Focar a organização da manufatura na redução da variação, 
isto é, controlar o número de diferentes processos, o impacto 
dos processos multi-ferramentais, ferramentas e máquinas de 
manutenção, etc.
2. Estabelecer um ambiente de engenharia aberto que possa 
minimizar a competição interna e dar suporte para o trabalho 
de equipe.
3. Incentivar, manter e treinar os funcionários no uso do CEP;
4. Aplicar o CEP para entender a variação e estabilidade dos 
dados que serão usados no desenvolvimento do processo.
5. Usar as análises do CEP para promover melhorias no processo.
6. Não passar a responsabilidade pelas cartas de controle para os 
operadores até que o processo esteja sob controle. A transfe-
rência de responsabilidade do processo só deve ocorrer quando 
o processo estiver sob controle.
Controle da qualidade
O controle da qualidade é um componente crítico que provê 
43QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
suporte para as melhorias sugeridas pelo uso do CEP.
1. Dar suporte ao treinamento para manutenção do CEP.
2. Focar as pessoas na aplicação do CEP.
3. Ajudar na identificação das causas de variação do processo;
4. Assegurar que os usos corretos das informações provenientes 
do programa de CEP estejam sendo corretamente utilizadas.
Produção
As pessoas envolvidas na produção estão diretamente relaciona-
das ao processo e a efetividade da variação do processo. Elas devem:
1. Estar treinadas na aplicação do programa de CEP para resolver 
problemas.
2. Ter entendimento da variação e estabilidade em relação aos 
dados e as informações que estarão sendo usadas no programa 
de CEP.
3. Estar alertas! A comunicação entre a equipe é importante 
quando a situação muda.
4. Atualizar, manter e disponibilizar as cartas de controle com 
a equipe responsável.
5. Aprender com as informações coletadas do processo.
A seguir, apresentamos os gráficos mais simples e utilizados 
nas organizações.
Tipos de gráficos de controle
Existem dois tipos básicos de gráficos de Controle:
• Gráficos por variáveis:
* Gráficos e R (média e amplitude)
* Gráficos e S (média e desvio padrão)
* Gráficos e R (mediana e amplitude)
* Gráficos para ou Valores Individuais (X ou I) e 
Amplitude Móvel (MR)
• Gráficos por atributos:
* Gráfico p (proporções não conforme)
* Gráfico np (unidades não conforme)
* Gráfico c (número de não conformidade por unidade)
* Gráfico u (taxa de não conformidade por unidade)
44QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Síntese
Neste capítulo vimos 7 ferramentas muito úteis na nossa 
busca pela qualidade. No início do capítulo aprendemos que 
nem todas têm o mesmo objetivo, ou seja, são aplicadas em 
diferentes contextos.
De forma resumida, as 7 ferramentas vistas são:
• Fluxograma: O objetivo principal é termos mapeada a 
sequencia de eventos e passos que definem o comporta-
mento de cada processo.
• Diagrama de Causa e Efeito: O principal objetivo aqui é 
rastrearmos as causas que levaram à ocorrência de algum 
problema específico (efeito).
• Folhas de Verificação: Basicamente é uma ferramenta 
de acompanhamento, de apoio à medição.
• Gráfico de Pareto: Importante ferramenta de priorização 
dos itens a serem tratados em uma resolução de proble-
mas. Famosa regra 20-80... onde 20% das ocorrências de 
causas estão relacionadas a 80% dos defeitos.
• Diagrama de Dispersão: Ferramenta fundamental para 
definirmos as relações entre causas e efeitos. Aqui con-
seguimos realizar uma verificação mais apurada, onde 
vamos variando os valores das variáveis de causa e acom-
panhando a variação dos valores das variáveis relacionadas 
aos efeitos.
• Histograma: Trata-se de uma ferramenta fundamental 
para mapearmos a distribuição de ocorrências de resultados 
em uma escala dos valores possíveis para um processo.
• Cartas de Controle: Ferramenta de acompanhamento 
do comportamento dos resultados das medições em um 
processo. Valores acima ou abaixo de uma variação pré-
-definida (fora da curva) indicam que o processo saiu do 
controle.
Por fim, é fundamental termos em mente que as ferramen-
tas devem ser utilizadas em conjunto para a implementação de 
processos e políticas de qualidade, normalmente atuando em 
conjunto com as métricas de software (que veremos no próximo 
capítulo) , operacionalizando-as.
Exercícios
1) Desenhe um fluxograma detalhado do processo para dar 
partida no carro e sair dirigindo. Neste fluxograma indique:
• As ações do motorista.
• As decisões que devem ser tomadas para o motorista colocar 
o automóvel em movimento.
2) Escolha um tipo e um subtipo de gráfico de controle e estude 
mais a respeito, empregando o mesmo em um exemplo prático.
3) Pesquise sobre este assunto e explique mais duas ferra-
mentas que podem ser utilizadas na qualidade de software.
4) Com base no fluxograma definido na questão 1, vamos supor 
que o automóvel teve uma parada súbita. Nestecenário monte 
um diagrama de causa-efeito, para mapear este problema.
5) Por fim, escolha um ponto que seja mais provável de ser a 
real causa e elabore um plano de ação, para que este ponto 
não se repita.
46QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
A frase título deste capítulo nos desafia a desbravar uma 
nova fronteira na qualidade de software, que é a definição, 
acompanhamento e melhoria de indicadores de desempenho. 
Em muitas empresas, conduzimos o projeto de software 
de uma forma artesanal, onde as ações para resolução de pro-
blemas são tomadas tendo por base opiniões, sentimentos ou 
percepções. Isto nos leva a erros graves, atrasos sem fim e o 
sentimento de que estamos no método de tentativa e erro.
Neste capítulo, estudaremos a base teórico-prática que nos 
permitirá definir e acompanhar indicadores para não deixar os 
MÉTRICAS DA 
QUALIDADE DE 
SOFTWARE
O que não é medido não é gerenciado. 
(William Edwards Deming). Então, vamos 
assumir o controle?
47QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
nossos projetos, projetos e produtos sem rumo. Primeiramente 
vamos listar alguns motivos que justificam esse estudo.
Por que medimos software ? (alguns motivos) 
• Precisamos entender e aperfeiçoar o processo de desen-
volvimento.
• Queremos melhorar a gerência de projetos e o relacio-
namento com clientes.
• Para reduzir frustrações e pressões de cronograma.
• Para gerenciar contratos de software.
• Atestar a qualidade de um produto de software.
• Avaliar a produtividade do processo.
• Avaliar os benefícios (em termos de produtividade e qua-
lidade) de novos métodos e ferramentas de engenharia 
de software.
• Embasar solicitações de novas ferramentas e treinamento.
• Avaliar o impacto da variação de um ou mais atributos do 
produto ou do processo na qualidade e/ou produtividade.
• Para melhorar a exatidão das estimativas (Formar uma 
linha de base para estimativas).
Terminologias de Métricas
Na engenharia de software, utilizamos com frequência 
os termos Medida, Métrica e Medição. Acreditamos que os 
termos são plenamente intercambiáveis, porém eles apresentam 
diferenças sutis que iremos abordar durante este capítulo.
Inicialmente ilustrarei a primeira diferença que é em quais 
níveis gerenciais aplicaremos os termos:
METAS
(NÍVEL ESTRATÉGICO)
INDICADORES
(NÍVEL TÁTICO)
MÉTRICAS
(NÍVEL OPERACIONAL)
Definimos aqui os objetivos 
estratégicos e metas.
Aqui acompanhamos se 
atingiremos as metas definidas.
Neste nível utilizamos a medida em 
sua composição simples, pois dessa 
forma será melhor utilizada para as 
decisões operacionais.
48QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Medida
Quando coletamos um único ponto de dado (por exemplo, o 
número de erros descobertos em um componente de software), 
estabelecemos uma medida. 
Para software os grupos mais comuns de medida são:
• Tamanho: 
* Considera a dimensão do produto de software que es-
tamos entregando.
* Não é simples de obter pois software é intangível.
* Normalmente utilizamos o número de linhas de código 
para dimensionar o tamanho de um software, porém 
existem outras medidas aceitas no mercado.
• Duração:
* Intervalo de tempo entre o início e o final de alguma 
atividade do projeto.
• Esforço:
* Trabalho para realizar alguma atividade do projeto.
* Expresso em horas, podendo ter algumas variações 
como homem/hora ou horas produtivas.
• Custos:
* Medida financeira expressa em moeda referente ao custo 
de cada etapa/atividade/recurso do projeto do software.
• Defeitos:
* Quantidade de não conformidades do software com os 
requisitos do cliente.
Métrica
Quando pensamos em métricas, na verdade estamos rela-
cionando duas ou mais medidas básicas fornecendo informação 
significativa sobre o produto ou processo. Por este motivo, as 
chamamos também de métricas indiretas ou derivadas.
Observemos alguns exemplos de métricas:
• Tamanho / Esforço = produtividade da equipe.
• Custo do projeto / Esforço = custo médio por hora.
• Número médio de erros encontrados por revisão.
• Número médio de erros encontrados por teste de unidade.
49QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Propriedades desejáveis em Métricas
Desde que começamos a nos preocupar com a medição de 
desempenho em software, diversas métricas foram propostas, 
porém nem todas foram efetivas. Tendo isto em vista, quando 
definirmos métricas devemos observar algumas propriedades 
básicas:
• Simples e computáveis: Deverá ser relativamente fácil 
aprender a derivar a métrica, e sua computação não deve 
demandar esforço ou tempo fora do normal.
• Empiricamente e intuitivamente persuasiva: A métrica 
deverá satisfazer as ideias do engenheiro sobre o atributo 
do produto considerado (por exemplo, uma métrica que 
mede coesão de um módulo no sistema deverá crescer 
em valor na medida em que aumenta o nível de coesão).
• Consistente e objetiva: A métrica deverá sempre pro-
duzir resultados que não sejam ambíguos. Um terceiro 
deverá ser capaz de ter o mesmo valor da métrica usando 
as mesmas informações sobre o software.
• Consistente no seu uso das unidades e dimensões: Na 
computação matemática da métrica deveremos utilizar 
medidas que não resultem em combinações bizarras de 
unidades. Por exemplo: multiplicar número de pessoas 
nas equipes de projeto pelas variáveis da linguagem de 
programação no programa resulta em uma mistura du-
vidosa de unidades que não é possível de ser entendida.
• Independente da linguagem de programação: Não 
devemos criar métricas dependentes das linguagens de 
programação.
• Devemos criar métricas que possam ser repetíveis e que 
estejam alinhadas com as metas e objetivos estratégicos 
da organização.
Indicador
Para definirmos um indicador, é fundamental pensarmos 
em uma ou mais métricas que nos indiquem informações a res-
peito do processo de desenvolvimento de software, do próprio 
50QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
software ou do próprio projeto.
Isto é importante, pois tomaremos ações importantes com 
base nos valores obtidos através destes indicadores.
Principais características de um bom indicador:
• Custo de operação adequado.
• É Simples, Fácil de entender.
• Passível de auditoria.
• Ter fonte de dados e processo de coleta e análise confi-
áveis;
Exemplo de indicador: Percentual de vendas de um pro-
duto X sobre as vendas totais, nos indicam o quanto um produto 
em particular representa sobre tudo o que vendemos.
Medição
Agora que já conseguimos diferenciar melhor os termos, 
podemos concluir que as Metas, Indicadores e Métricas, 
são os componentes chave da Medição, sendo assim a base de 
sustentação da medição de desempenho.
Processo de Medição
Já definimos as diferenças entre termos importantes, en-
tendemos onde cada um é utilizado e agora, de forma simples e 
objetiva, iremos explorar o processo de medição, ou seja, como 
obtemos corretamente os dados.
Tratamos o processo de medição de forma contínua, como 
um ciclo repetitivo, ilustrado pela figura.
PLANEJAMOS
MEDIMOSIMPLEMENTAMOS 
AS DECISÕES
ANALISAMOS OS 
DADOS
TOMAMOS DECISÕES 
BASEADAS NA ANÁLISE
51QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Quando estabelecemos um processo de medição devemos:
• Fornecer uma base para melhoria contínua do processo.
• Quantificar a qualidade e produtividade.
• Integrar o processo no ciclo de vida de desenvolvimento do 
produto.
• Medir o impacto de vários métodos, ferramentas e técnicas de 
melhoria.
• Medições não devem ser usadas para medir pessoas.
• 
Para entendermos o processo como um todo, é importante 
observarmos que as métricas desempenham 4 papéis nesse 
ciclo, conforme ilustrado e explicado a seguir.
Metodologia Goal/Question/Metric – GQM 
Se buscarmos referências a respeito de medidas para software, 
poderemos constatar que existem muitas medidas diferentes e apli-
cáveis a contextos distintos. Por isso, é importante que saibamos 
escolher quais são aplicáveis ao nossoprojeto em particular.
O método GQM (Goal – Question – Metric) é uma boa escolha 
para planejarmos o trabalho de medição nos projetos. 
Este método possibilita que organizemos o planejamento de 
uma medição de software em etapas A cada etapa devemos definir 
um elemento conforme descrito a seguir:
• Objetivos (Goal): São estabelecidos de acordo com as ne-
cessidades dos stakeholders. Os objetivos de medição devem 
ser fixados em função dos requisitos do software. Em par-
ticular, uma análise de importância de cada requisito é útil 
para controlar os custos da avaliação. Aos requisitos mais 
importantes podemos alocar mais recursos, tais como tempo 
e quantidade de usuários contratados para teste. Trata-se 
então de um nível conceitual.
Processos, 
produtos e 
serviços de
software
ControlarEntender
Prever
Avaliar
Métr icas podem 
ser utilizadas para 
controlar processos, 
produtos e serviços de 
software.
Métricas ajudam a entender 
o compor tament o e 
funcionamento de processos, 
produtos e serviços de 
software.
Métricas podem ser utilizadas 
para tomar decisões e 
determinar o estabelecimento 
de padrões e metas.
Métricas podem ser
utilizadas para prever
valores de atributos.
52QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
• Perguntas (Question): Definimos questões para realizar o 
trabalho de medição. São as perguntas que esperamos respon-
der com o estudo para atingirmos os objetivos relacionados. 
As respostas obtidas com a medição devem trazer informação 
útil para melhorar o produto. Por exemplo: “Que aspectos do 
projeto (design) da interface afetam a facilidade de uso? ”. As 
questões estabelecem uma ponte entre os objetivos planejados 
e as métricas que devem trazer evidência sobre o sucesso ou 
não da implementação. Aqui já temos um nível operacional.
• Categorias (Continuação da Question): Particionam o con-
junto de dados obtidos. As perguntas criadas no passo anterior 
podem trazer à tona diferentes categorias de informação. No 
exemplo citado de avaliação de uma interface, pode-se pensar 
em vários aspectos que correspondam a diferentes categorias 
de informação, como quantidade de janelas, distribuição das 
informações, linguagem utilizada etc.
• Formulários (Continuação da Question): conduzem o 
trabalho dos avaliadores. A vantagem de definirmos os do-
cumentos para anotação dos dados é evitarmos que cada 
avaliador utilize um formulário próprio, o que, além de di-
ficultar a tarefa de analisar as informações, pode induzir a 
erros como coleta de dados diferentes.
• Métricas (Metric): Definimos métricas que ajudem a res-
ponder às perguntas definidas. Alguns exemplos: Que dados 
serão necessários? Quais os formatos? Como coletar (fórmula 
e processo)? Onde armazenar e como utilizar? Este já é um 
nível quantitativo.
Se observarmos a figura a seguir teremos um exemplo que 
resume a relação entre os elementos citados acima. Neste exemplo 
temos dois objetivos que estão relacionados a 4 questões, cujas 
respostas geraram 5 métricas.
53QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Dimensões para Medição de Software 
No desenvolvimento de software observamos 3 dimensões 
passíveis de medição: produto, processo e projeto. Cada uma 
dessas dimensões irá atuar de forma complementar, interagindo e 
construindo um caminho de informações, onde a correta leitura irá 
nortear as melhorias necessárias a todo o contexto de desenvolvi-
mento de software da empresa. 
Inclusive, a própria obrigatoriedade dessas medições deverá ser 
um de nossos objetivos. Não adianta termos indicadores que não são 
fiéis a realidade. Desta forma além da medição ocorrer, ela deverá 
ser mais exata possível, sempre avaliando o custo desta medição, 
para que fique dentro de uma realidade plausível.
Medição a nível de Métricas de Produto
É fundamental medirmos o software. Ainda encontramos de-
fensores da ideia de que software não pode ser medido ou que esse 
trabalho seria infinito. O que posso afirmar a vocês é que precisa-
mos definir e acompanhar métricas referentes à complexidade do 
software que estamos liberando ao mercado. Desta forma, temos as 
métricas de produto como medidas de atributos internos do produto 
e que nos fornecem uma indicação em tempo real da eficácia dos 
modelos de requisitos, projeto e código; a eficácia dos casos de teste 
e de outros atributos. Portanto, são medidas que podemos utilizar 
para avaliar a qualidade do produto enquanto está sendo projetado.
Exemplos:
• Erros por KLOC (por mil linhas de código).
• Páginas de documentação por KLOC.
• Use Case Points (UCPs).
• Function Points (FPs).
Medição a nível de Métricas de Processo
Métricas de processo permitem à organização de engenharia 
de software ter ideia da eficácia de um processo existente. Devemos 
coletá-las ao longo de todos os projetos e durante o maior período 
de tempo possível. O nosso objetivo é fornecer indicadores que 
54QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
levem à melhoria incremental do processo de software. 
Exemplos:
• Percentual de requisitos aprovados pelo cliente.
• Número médio de defeitos encontrados na revisão por pares 
dos requisitos.
• Percentual de não conformidades encontradas em cada etapa 
do processo.
Medição a nível de Métricas de Projeto
Métricas de projeto permitem ao gerente de projeto: (1) avaliar 
o estado de um projeto em andamento. (2) rastrear os riscos em 
potencial. (3) descobrir áreas problemáticas antes que elas se tor-
nem críticas. (4) ajustar o f luxo de trabalho ou tarefas. (5) avaliar 
a habilidade da equipe de projeto para controlar a qualidade dos 
produtos finais de software.
Diferentemente das métricas de processo que são usadas para 
fins estratégicos, as medidas de projeto são táticas.
Exemplos:
• Produtividade do time no projeto.
• Percentual de funcionalidades entregues.
• Número de defeitos encontrados no produto pelo cliente;
• Índice de retrabalho.
Síntese
Neste capítulo, vimos a importância crucial da definição e 
acompanhamento de métricas tanto para o processo quanto para o 
projeto e produto de software que estamos liberando ao mercado.
Aprendemos que existem métricas de nível estratégico, tático 
e operacional, cada uma atendendo a um grupo específico de in-
teressados.
Vimos também a forma sugerida para a definição e implanta-
ção de indicadores para o ciclo de vida de nosso software, através 
da metodologia GQM (GOAL -QUESTION-METRIC). Esta 
metodologia prega a definição de objetivos que serão verificados 
através de questões, cujas respostas resultarão em métricas que 
serão acompanhadas.
Exercícios
1) Defina duas medidas para avaliar um carro. Explique as 
medidas definidas.
2) Agora defina mais uma métrica para o item 1. Explique a 
métrica definida.
3) E por fim defina um indicador para avaliar o item 2. Explique 
o indicador definido.
4) Vimos uma metodologia para criação de métricas, a GQM, 
porém existem outras tais como PSM - PRACTICAL SOFTWARE 
MEASUREMENT e GOAL-DRIVEN SOFTWARE MEASUREMENT. 
Pesquise sobre estas duas metodologias alternativas e realize 
uma comparação delas coma GQM vista na disciplina. 
5) Defina uma métrica de produto, uma de processo e uma de 
projeto.
56QUALIDADE E AUDITORIA DETECNOLOGIA DA INFORMAÇÃO
Neste capítulo, veremos uma introdução a alguns modelos 
e normas que visam aprimorar os processos de desenvolvimen-
to de software, tanto do ponto de vista da empresa quanto 
nos processos referentes às pessoas e equipes. Não será nosso 
objetivo ver os conteúdos na sua totalidade, porém veremos o 
que realmente é considerado essencial para o entendimento do 
conteúdo e para que possamos aprofundar os estudos conforme 
nosso desejo e/ou necessidade.
Durante este estudo, observaremos que existem muitas 
semelhanças entre as propostas pois todas possuem inspeção 
NORMAS E MO-
DELOS DA QUALI-
DADE
A melhor forma de colocar ordem no Caos é 
através do estabelecimento e implantação de 
padrões. Prontos para o desafio?
57QUALIDADE E