QUALIDADE E AUDITORIA DE TECNOLOGIA

DA INFORMAÇÃO
DOUGLAS DELA GIUSTINA
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 2

SUMÁRIO
INTRODUÇÃO3 ISO/IEC 15504 e a norma SPICE 68
QUALIDADE DE SOFTWARE 4 Histórico68
Eras da Qualidade 5 Square: ISO/IEC 25000 75
Gestão estratégica da Qualidade 8 MPS BR 85
Gurus da Qualidade 8 PSP e TSP 91
Porque precisamos pensar em qualidade de software?9 Síntese102
Qualidade de software 12 TESTE DE SOFTWARE 105
Qualidade do Produto e Qualidade do Processo 13 Fundamentos de Teste 106
Processo de Garantia da Qualidade 14 Processo de Teste 109
Custos da Qualidade 17 Verificação e Validação (V&V) 110 CENTRO UNIVERSITÁRIO UNIFTEC
Síntese20 Documentação no Teste 118 Rua Gustavo Ramos Sehbe n.º 107.
Caxias do Sul/ RS
FERRAMENTAS DA QUALIDADE 22 O Teste nos Ciclos de Vida 122
Fluxograma23 Níveis, Tipos e Técnicas de Teste 124
Diagrama de Causa e Efeito 26 Níveis de Teste (Quando testar) 125 REITOR
Folhas de Verificação 28 Tipos de Teste (O que testar?) 130 Claudino José Meneguzzi Júnior
Técnicas de Teste (Como testar?) 132 PRÓ-REITORA ACADÊMICA
Gráfico de Pareto 31
Débora Frizzo
Diagrama de Dispersão 34 Caminhos independentes de programa: 135
PRÓ-REITOR ADMINISTRATIVO
Histograma37 Síntese145 Altair Ruzzarin
Cartas de Controle 40 AUDITORIA DA TECNOLOGIA DA INFORMAÇÃO147 DIRETORA DE EDUCAÇÃO A DISTÂNCIA (EAD)
Síntese44 Fundamentos de auditoria de sistemas de informações Lígia Futterleib

MÉTRICAS DA QUALIDADE DE SOFTWARE 46 148

Por que medimos software ? (alguns motivos)  47 Pontos de Controle da Auditoria 151 Desenvolvido pela equipe de Criações para o
Terminologias de Métricas 47 Organização da Auditoria 153 ensino a distância (CREAD)
Metodologia Goal/Question/Metric – GQM  51 Padrões e Código de Ética 156 Coordenadora e Designer Instrucional
Ferramentas de apoio à auditoria 158 Sabrina Maciel
Dimensões para Medição de Software  53
Diagramação, Ilustração e Alteração de Imagem
Síntese54 Técnicas de Auditoria 160
Jaqueline Boeira
NORMAS E MODELOS DA QUALIDADE 56 Síntese163 Revisora
ISO/IEC 9126 57 REFERÊNCIAS167 Luana dos Reis

ISO/IEC 12207 60
 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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 4

QUALIDADE DE
SOFTWARE
Qualidade: Quem é você?
Antes de entrarmos em detalhes sobre a qualidade do
software, é importante iniciarmos com uma reflexã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

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.
Fonte: Autor
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 5
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.

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 6
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.

Para refletir: Somente podemos controlar o que medimos.
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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 7
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.

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 8
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.

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 9
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????
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.

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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 10
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 flutuante
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

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 11
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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 12

Qualidade de software Como exemplo de tentativa de enquadramento do software

com qualidade, apresentamos as dimensões de qualidade de
Agora que já conhecemos um pouco sobre qualidade e Garvin abaixo:
já tomamos consciência dos impactos que erros de software
podem causar, entramos no primeiro tema de nossos estudos, Questões referentes a empresas de software
a famosa Qualidade de Software.
Podemos definir a qualidade de software como uma gestão Não é somente devido a falhas em testes ou levantamentos
de qualidade efetiva aplicada de modo a criar um produto útil de requisitos ineficientes que residem os problemas. Observa-
que forneça valor mensurável para aqueles que o produzem e mos que as próprias empresas de software possuem modelos
para aqueles que o utilizam. Devemos ter em mente que um imaturos de desenvolvimento, e outros problemas internos
grande conjunto de fatores definirá se obteremos ou não sof- gerando softwares com baixa percepção de qualidade e de
tware de qualidade. manutenção custosa.
PROCESSO DE SOFTWARE Dentre os principais problemas podemos citar:
USUÁRIO • acúmulo de trabalho;
PROCESSO DE
DESENVOLVEDOR REQUISITOS DESENVOLVIMENTO PADRÕES • produto as vezes funciona, mas o prazo e custo para
ORGANIZAÇÃO construí-lo são maiores do que o planejado;
• sucesso depende muito do esforço heroico das pessoas;
REQUISITOS ATENDIDOS SOFTWARE PRODUTO PADRÕES ATENDIDOS • os clientes e funcionários ficam insatisfeitos.
Os problemas listados anteriormente e outros tantos, le-
SOFTWARE COM QUALIDADE
Fonte: Autor
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 13

varam as organizações desenvolvedoras de software a atuar Quem é o cliente?

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.
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

Qualidade do Produto e Qualidade do Processo de Software consiste em um conjunto de ferra-

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.
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.

OBJETIVOS
ENTRADAS SAÍDAS
ATIVIDADES
RECURSOS E INSFRAESTRUTURA
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-
fluenciada 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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 14
produto de software possuirá ou não qualidade.
Além da influê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
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 15

todas as etapas do desenvolvimento dos produtos. Planejamento da Qualidade

Garantia da Qualidade em todo o ciclo de desenvolvimento
Consiste na identificação de quais padrões de qualidade
PROSPECÇÃO DO PROJETO
CLIENTE REQUISITOS ANÁLISE IMPLEMENTAÇÃO ENTREGA serão utilizados no projeto de software, através da verificação
(DESIGN()
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

TEMPO
Fonte: Bartié 2002
selecionados.

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.
Adaptado de Bartié 2002
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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 16

Controle da Qualidade Garantia da Qualidade Controle da Qualidade

Foco:
O objetivo aqui é acompanhar os resultados do projeto Quando utilizamos, temos Quando utilizamos, temos por
por objetivo evitar defeitos no objetivo identificar e corrigir
e identificar se os mesmos encontram-se em conformidade
processo usado para fazer o defeitos no produto final.
com os padrões de qualidades definidos. Este processo deve produto. Com isso, concluímos Com isso, percebemos que o
ser executado de forma contínua e em todas as fases do de- que este é um processo controle da qualidade é um
senvolvimento. Identificado uma inconsistência, esta deve ter proativo de qualidade. processo reativo.
a causa raiz encontrada e tratada de forma correta, a fim de Objetivo:
evitar a repetição. O objetivo do QA é melhorar O objetivo do controle de
o desenvolvimento e testar qualidade é identificar
processos para que não defeitos depois que o produto
Garantia x Controle da Qualidade surjam defeitos quando é fabricado e antes de ser
o produto está sendo lançado.
Pessoal!!! Vamos resumir o que vimos sobre Garantia e desenvolvido.
Controle da Qualidade através da tabela a seguir, onde com- Como?
paramos os dois processos.
Estabelecendo um bom Encontrando e eliminando
sistema de gestão da fontes de problemas de
qualidade e avaliação da sua qualidade através de
adequação com auditorias ferramentas e equipamentos
periódicas da conformidade para que as demandas do
das operações do sistema. cliente sejam continuamente
atendidas e superadas.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 17

O quê? Como Ferramenta:

Prevenção de problemas As atividades ou técnicas Garantia da qualidade é uma Controle da qualidade é uma
de qualidade por meio utilizadas para atingir e ferramenta de gestão. ferramenta corretiva.
de atividades planejadas manter a qualidade do Metodologia:
e sistemáticas, incluindo produto, processo e serviço.
A garantia da qualidade é O controle da qualidade é
documentação.
voltada ao processo. voltado ao produto.
Responsáveis:
Custos da Qualidade
Todos os membros das O controle da qualidade é
equipes envolvidas no geralmente responsabilidade
desenvolvimento do produto. de uma equipe específica, que A qualidade não é totalmente algo que podemos obter de
testa o produto para ver se forma gratuita. Para tanto, investimentos financeiros, treina-
existem defeitos. mentos, softwares e outras iniciativas precisam ser realizadas
Exemplo: adicionalmente para a busca da qualidade de software como
Temos a verificação e Validação / Teste de Software.
um todo.
inspeção prévia.
Segundo Bartié (2002), “Um dos maiores desafios a ser
Técnicas Estatísticas
considerado é estabelecer um modelo de custos relacionados
Ferramentas e técnicas Quando as ferramentas e
estatísticas quando aplicadas técnicas estatísticas são a implantação de um processo de garantia da qualidade de
a processos (entradas de aplicadas aos produtos software.”
processo e parâmetros acabados (saídas do A figura mostra um modelo de custo de qualidade de
operacionais), eles são processo), eles são chamados
software proposto por Bartié:
chamados Controle Estatístico de Controle da Qualidade
de Processos (CEP). Estatística (CQE).
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 18

Custo do Projeto

Custo do
Custo da Qualidade
Desenvolvimento

Custo de Produção do
Software

Custo da Conformidade

Custo da Não-
Conformidade
Custo da Prevenção de Custo da Prevenção de
Defeitos • Re-revisões;
Defeitos • Retestes;
Revisões: • Metodologias; • Correções:
• Problema; • Treinamento; • Código Fonte;
• Requisitos; • Ferramentas; • Documentação;
• Modelagem; • Políticas; • Reestruturação;
• Planos de Teste; • Procedimentos; • Redistribuição de
• Scripts de Teste; • Planejamento; Versões;
Inspeções de Código; • Análises; • Atrasos no
Teste (1a Execução); • Métricas; Cronograma;
Auditorias. • Relatório da • Falhas de Existe uma correlação entre os custos da
Qualidade; Produção; não conformidade com os investimentos
• Projetos de em prevenção de defeitos. Quanto maiores
• ETC.
Inovação. estes investimentos, menor a incidência de
Modelo de Custo de Qualidade de Software, adaptado de Bartié 2002. não-conformidades.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 19

No modelo apresentado, é proposta a criação de duas categorias dade, ou seja, o foco está exatamente no processo. As atividades aqui
separadas para os custos relacionados a conformidade e o custo da realizadas são orientadas ao processo, e estas incluem:
não-conformidade: • Definição de Metodologias;
• Treinamentos;
Custo da Detecção de Defeitos • Ferramentas de apoio ao processo de desenvolvimento;
• Definição de Políticas;
Podemos fazer referências para o termo controle da qualidade, ou • Procedimentos;
seja, o foco está exatamente no produto. As atividades aqui realizaremos • Padrões;
aqui serão orientadas ao produto desenvolvido, e estas incluem: • Especificações e convenções;
• Revisões de requisitos; • Planejamento do SQA;
• Revisões de Modelagem; • Relatórios de Qualidade para melhoria de processo.
• Revisões de Planos de Teste;
• Inspeções de código; Custo da Não-Conformidade
• Testes de Software.
Por outro lado, o custo da não-conformidade está relacionado às
Custo da Prevenção de Defeitos perdas que o projeto terá, não optando pela detecção e prevenção de
defeitos:
Assim como detecção de defeitos está associada ao controle da • Re-reviões;
qualidade, a prevenção de defeitos está associada a garantia da quali- • Retestes;

• 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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 20
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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 22

FERRAMENTAS
DA QUALIDADE
As ferramentas tradicionais da qualidade
são 100% aplicáveis ao desenvolvimento de
software. Vamos estudá-las?
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.
Foco na Identificação do Problema Foco na Análise do Problema

GRÁFICO HISTOGRAMA
FLUXOGRAMA DE PARETO DIAGRAMA
DE DISPERSÃO
FOLHAS DE VERIFICAÇÃO DIAGRAMA DE
CAUSA E EFEITO CARTAS
DE CONTROLE
Fonte: Autor
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 23

Fluxograma Relatórios,
formulários,
Documento
documentos,
A finalidade desta ferramenta é identificar o caminho real
fichas, etc.
e ideal para um produto ou serviço com o objetivo de identi- Possibilidade de
ficar os desvios. O fluxograma é uma ilustração sequencial de Decisão alternativas (sim/
todas as etapas de um processo, mostrando como cada etapa não, +/-, etc.).
é relacionada. Ele utiliza símbolos facilmente reconhecidos Indica o fluxo de
Fluxo do processo informações e de
para denotar os diferentes tipos de operações em um processo.
operações.
Sempre possui um início, um sentido de leitura (ou fluxo) e
Conexão do fluxo
um fim. Conector de fluxo
na mesma página.
Os principais símbolos aceitos serão apresentados na tabela
Conexão de fluxo
a seguir:
Conector de página de uma página
para outra página.
O que representa Observações,
Título Símbolo Informações
no fluxo explicações ou
adicionais
algo inserido no
Ponto de início e processo.
Terminal
término do fluxo.
Antes de iniciarmos a preparação de um fluxograma de
Operações
Processamento processo temos que conhecer muito bem a rotina do processo.
manuais.

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 fluxograma. 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 fluxogramas.
Os fluxogramas também podem ser elaborados para qual-
quer sequência de eventos de natureza administrativa, tais
como: trajeto de uma fatura, fluxo 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 fluxo deve partir ou chegar a um
terminador ou conector.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 24
4. O símbolo de processo admite mais de uma linha de
entrada de fluxo e apenas uma linha de saída.
5. O símbolo de decisão admite mais de uma linha de en-
trada de fluxo (alguns autores recomendam apenas uma
linha de entrada de fluxo) e várias linhas de saída.
6. O símbolo de documento (impressão ou leitura) deve
possuir uma linha de fluxo 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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 25

Processamento sequencial: decisão com base no valor lógico de uma expressão.

• No entanto, executaremos repetidamente a mesma sequ-
• Processamos um conjunto de passos (ações) em série. ência de ações enquanto o resultado da expressão lógica
• Não há qualquer possibilidade de alterar a ordem de se mantiver verdadeiro.
processamento das ações. Exemplo completo: Acompanhamento de um setor de
• Após processarmos o 1º passo, processamos o 2º e assim produção
sucessivamente. INÍCIO
ORDENS DE SERVIÇO
PLANOS DE CONTROLE
DAR UMA VOLTA RELATÓRIOS DE INSPEÇÃO
COMPLETA EM TODO
REGISTROS
Processamento por seleção: SETOR, MÁQUINA POR
MÁQUINA, 4 X AO DIA
DAR UM 1
EM T
POR MÁ

VERIFICAR DOCUMENTAÇÃO

• Utilizamos o símbolo de decisão para escolhermos um

INSPECIONAR LINHA
DE PRODUÇÃO

caminho de processamento a ser seguido. EM ORDEM?

NÃO
VERIFICAR ERROS
VERIFICAR
CONTROLE SIM
A

• O fluxo de processamento segue por uma das vias, de-

HÁ NÃO
CONFORMIDADE
IDENTIFICAR
SIM TOMAR AS AÇÕES
NECESSÁRIAS EMITIR
NÃO
pendendo do valor da expressão avaliada no início da
RELATÓRIO
TOMAR AS AÇÕES
1 NECESSÁRIAS
FIM
estrutura.

Processamento por repetição: Vantagens

• Neste caso, também há a necessidade de tomarmos uma Como ferramenta de análise de processos, o fluxograma

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 influenciar ou ser influenciados 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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 26
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.

3. Desenhamos o eixo central:
• É uma flecha 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 flechas 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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 27
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.

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 28
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

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 forma de ocorrência.
• Verificar as causas dos defeitos ou das não conformidade.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 29
• 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:
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 30

tamanho da amostra. Que eventos estão ocorrendo?

• Coletar os dados dentro de um tempo específico: decidir
o tipo de folha de verificação a ser usada, decidir qual o Por exemplo, tipo de defeito: ortografia, pontuação, man-
formato dos dados, serão números, valores ou símbolos? chas, parágrafos, números errados e alinhamento.
• Fazer um modelo de folha de verificação.
Quando ou quantas vezes ocorrem os eventos
Exemplo de folha de verificação:
Por exemplo, frequência dos defeitos: ortografia: 5; pon-
Erro de tuação: 13; manchas: 4; parágrafos: 12; números errados: 2;
Jan Fev Mar Abr Total
Digitação
alinhamento: 20.
Ortografia | || | | 5
Pontuação ||| |||| || |||| 13
Onde estão ocorrendo os eventos?
Números
| | 2
errados
Manchas | | | | 4 Por exemplo, localização do defeito: No local onde foram
Parágrafos || ||| ||||| || 12 colhidas as informações.
Alinhamento |||| |||||| |||| |||||| 20
TOTAL 11 17 14 14 56 Análise:

• Os eventos em questão estão ocorrendo junto com outras


mudanças ou eventos? (Ex.: outros fatores de influência).
• A lterações de profissional, equipamento etc.
• Depois pergunte: Esqueci de alguma coisa? Então faça
uma reflexã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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 31
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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 32

• Exemplo: A partir da coleta dos dados, obteve-se as Razões Número de Ocorrências

seguintes ocorrências para cada categoria: Atraso na entrega 140
Razões Número de Ocorrências Atraso da transportadora 125
Separação errada 45 Produto danificado 65
Faturamento incorreto 60 Faturamento incorreto 60
Atraso da transportadora 125 Separação errada 45
Pedido errado 30 Pedido errado 30
Atraso na entrega 140 Preço errado 20
Preço errado 20 Outros 15
Produto danificado 65 Total 500
Outros 15
Total 500 4. Calculamos o número de ocorrências acumulado:
• Incluiremos uma nova coluna na tabela com os casos
3. Listamos as categorias em ordem decrescente: acumulados.
• Vamos listar as categorias em ordem decrescente de nú- • E xemplo: Para o exemplo anterior, a nova tabela é:
mero de ocorrências.
• E xemplo: Para o exemplo anterior, a nova tabela é:
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 33

Número de Ocorrências Número de Ocorrências Frequência Frequência

Razões Razões
Ocorrências Acumuladas Relativa Acumulada
Ocorrências Acumuladas
Atraso na entrega 140 140 Atraso na entrega 140 140 28 28
Atraso da
Atraso da 125 265 25 53
125 265 transportadora
transportadora
Produto danificado 65 330 13 66
Produto danificado 65 330 Faturamento
60 390 12 78
Faturamento incorreto
60 390
incorreto Separação errada 45 435 9 87
Separação errada 45 435 Pedido errado 30 465 6 93

Pedido errado 30 465 Preço errado 20 485 4 97

Outros 15 500 3 100
Preço errado 20 485
Total 500 100
Outros 15 500
Total 500 6. Construamos um gráfico de colunas:
• Para cada categoria definida no eixo horizontal, cons-
5. Calculamos a frequência relativa (%) e acumulada (%) truiremos uma coluna com altura proporcional ao seu
para cada categoria: número de ocorrências.
• Frequência relativa = (número de ocorrência na categoria • No lado esquerdo ficarão aquelas que contribuem, mais
/ número total de ocorrências) x 100. fortemente, para o problema analisado.
• Frequência acumulada = (casos acumulados até a categoria 7. Construamos um gráfico de linhas:
/ número total de ocorrências) x 100. Exemplo: • Iremos mostrar a contribuição acumulativa das categorias

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 34
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

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 35
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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 36

Tempo de
cozimento Potência
Diagrama de Dispersão correspondente: ingeridas.
(segundos)
Possível correlação positiva
180 957
172 975
Se houver um aumento em X, Y sofrerá algum
164 993 aumento, mas Y parece ter outras causas além de
178 961
X, exemplo: chuva x trânsito.
168 985
167 987
Nenhuma correlação.
178 966 Acréscimos ou decréscimos em x não alteram
176 974
Interpretação dos Diagramas de Dispersão y, exemplo: seca no Nordeste x colheita de uvas
169 982
183 955
no Sudeste.
171 971 Para que os diagramas de dispersão sejam fer- Possível correlação negativa
178 960
ramentas úteis, a adoção de medidas apropriadas Um aumento em X causará uma tendência
170 977
185 953
depende da interpretação correta. Apresentamos de decréscimo em Y. Exemplo: treinamento X
170 978 abaixo alguns exemplos dos diagramas de disper- erros cometidos.
171 981
são mais comuns: Correlação negativa
191 949
170 976
Um aumento em X causará um decréscimo
182 968 Correlação positiva em Y, portanto, se X for controlado, Y será con-
176 981
Um aumento em Y depende de um aumento trolado, exemplo: temperatura de conservação
187 951
166 988
de X. Se X estiver controlado, Y estará natu- de alimento x prazo de validade. (Verdadeiro
177 972 ralmente controlado, exemplo: peso x calorias em uma faixa).
187 952

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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 37
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.

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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 38
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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 39

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.
Amostras do Produto
40,9 43,6 41,3 39,9 40,6 39,8 44,2 37,9
Assim, ele pode perceber que as saídas estavam seguindo
40,8 36,6 42,3 43,5 41 39,6 41,3 43,5
o padrão normal de variação. As amostras do produto analisa-
41,5 43,7 39,9 41 41,8 42,3 40,2 39,1
das ficaram dispostas próximas do centro em (torno de 80%),
43,2 38,4 41,9 39,2 38 40,4 40,1 39,4
e que alguns frascos (em torno de 20%) apresentam concen-
38,7 41,3 41,4 40,9 40,3 39,2 39 40,7
tração próxima dos valores mínimos. Ou seja, nessa amostra
42,3 40,6 41,2 40,2 40,4 39,5 45 39,9
coletada a maior parte dos produtos estão em conformidade
43,4 40,4 41,6 40,6 40,2 42,8 43,7 39,7
com o esperado.
41,5 40,1 41,7 41,8 42,9 43,4 43,3 41,9
Entretanto, se o valor entre 35,4 a 36,8 fossem considerados
43,4 41,7 40 38,3 42,1 39,3 37,2 43,8
não conformes, por exemplo, teríamos uma pequena quanti-
39,6 41 42,3 39,2 40,4 35,4 39,2 42,6
dade de produtos fora das especificações planejadas, e a partir
de então, poderíamos aplicar ações corretivas nesse processo.

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!
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 40
• 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.
• E xistem 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.

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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 41
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 influê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.

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,
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 42
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ê
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 43

suporte para as melhorias sugeridas pelo uso do CEP. a equipe responsável.

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.
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

Produção Existem dois tipos básicos de gráficos de Controle:

• Gráficos por variáveis:
As pessoas envolvidas na produção estão diretamente relaciona- * Gráficos e R (média e amplitude)
das ao processo e a efetividade da variação do processo. Elas devem: * Gráficos e S (média e desvio padrão)
1. Estar treinadas na aplicação do programa de CEP para resolver * Gráficos e R (mediana e amplitude)
problemas. * Gráficos para ou Valores Individuais (X ou I) e
2. Ter entendimento da variação e estabilidade em relação aos Amplitude Móvel (MR)
dados e as informações que estarão sendo usadas no programa • Gráficos por atributos:
de CEP. * Gráfico p (proporções não conforme)
3. Estar alertas! A comunicação entre a equipe é importante * Gráfico np (unidades não conforme)
quando a situação muda. * Gráfico c (número de não conformidade por unidade)
4. Atualizar, manter e disponibilizar as cartas de controle com * Gráfico u (taxa de não conformidade por unidade)

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:
• F luxograma: 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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 44
• 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 real causa e elabore um plano de ação, para que este ponto
não se repita.
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. Neste cená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

 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 46

MÉTRICAS DA
QUALIDADE DE
SOFTWARE
O que não é medido não é gerenciado.
(William Edwards Deming). Então, vamos
assumir o controle?
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
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 47

nossos projetos, projetos e produtos sem rumo. Primeiramente • Para melhorar a exatidão das estimativas (Formar uma
vamos listar alguns motivos que justificam esse estudo. linha de base para estimativas).

Por que medimos software ? (alguns motivos) Terminologias de Métricas

• Precisamos entender e aperfeiçoar o processo de desen- Na engenharia de software, utilizamos com frequência
volvimento. os termos Medida, Métrica e Medição. Acreditamos que os
• Queremos melhorar a gerência de projetos e o relacio- termos são plenamente intercambiáveis, porém eles apresentam
namento com clientes. diferenças sutis que iremos abordar durante este capítulo.
• Para reduzir frustrações e pressões de cronograma. Inicialmente ilustrarei a primeira diferença que é em quais
• Para gerenciar contratos de software. níveis gerenciais aplicaremos os termos:
• Atestar a qualidade de um produto de software.
• Avaliar a produtividade do processo. Definimos aqui os objetivos
• Avaliar os benefícios (em termos de produtividade e qua- estratégicos e metas.
METAS
(NÍVEL ESTRATÉGICO)
lidade) de novos métodos e ferramentas de engenharia
de software. Aqui acompanhamos se
INDICADORES atingiremos as metas definidas.
• Embasar solicitações de novas ferramentas e treinamento. (NÍVEL TÁTICO)

• Avaliar o impacto da variação de um ou mais atributos do Neste nível utilizamos a medida em

produto ou do processo na qualidade e/ou produtividade. sua composição simples, pois dessa
MÉTRICAS
(NÍVEL OPERACIONAL) forma será melhor utilizada para as
decisões operacionais.

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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 48
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.

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.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 49
• 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
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 50

software ou do próprio projeto. Processo de Medição

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
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
IMPLEMENTAMOS MEDIMOS
AS DECISÕES

Agora que já conseguimos diferenciar melhor os termos,

TOMAMOS DECISÕES ANALISAMOS OS
podemos concluir que as Metas, Indicadores e Métricas, BASEADAS NA ANÁLISE DADOS
são os componentes chave da Medição, sendo assim a base de
sustentação da medição de desempenho.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 51

Quando estabelecemos um processo de medição devemos: Metodologia Goal/Question/Metric – GQM

• Fornecer uma base para melhoria contínua do processo.
• Quantificar a qualidade e produtividade. Se buscarmos referências a respeito de medidas para software,
• Integrar o processo no ciclo de vida de desenvolvimento do poderemos constatar que existem muitas medidas diferentes e apli-
produto. cáveis a contextos distintos. Por isso, é importante que saibamos
• Medir o impacto de vários métodos, ferramentas e técnicas de escolher quais são aplicáveis ao nosso projeto em particular.
melhoria. O método GQM (Goal – Question – Metric) é uma boa escolha
• Medições não devem ser usadas para medir pessoas. para planejarmos o trabalho de medição nos projetos.
• Este método possibilita que organizemos o planejamento de
Para entendermos o processo como um todo, é importante uma medição de software em etapas A cada etapa devemos definir
observarmos que as métricas desempenham 4 papéis nesse um elemento conforme descrito a seguir:
ciclo, conforme ilustrado e explicado a seguir. • Objetivos (Goal): São estabelecidos de acordo com as ne-
Controlar cessidades dos stakeholders. Os objetivos de medição devem
Entender
Métricas ajudam a entender Métricas podem
ser fixados em função dos requisitos do software. Em par-
o comportamento e Processos,
ser utilizadas para
funcionamento de processos, produtos e
controlar processos,
ticular, uma análise de importância de cada requisito é útil
produtos e serviços de serviços de produtos e serviços de
software. software software.
para controlar os custos da avaliação. Aos requisitos mais
importantes podemos alocar mais recursos, tais como tempo
Avaliar
Prever
Métricas podem ser utilizadas
e quantidade de usuários contratados para teste. Trata-se
para tomar decisões e Métricas podem ser
determinar o estabelecimento utilizadas para prever
então de um nível conceitual.
de padrões e metas. valores de atributos.

• 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
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 52
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.

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-
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 53
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

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 fluxo 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:
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 54
• 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.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 56

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?
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

em algum grau, além de objetivar a melhor estruturação do
processo produtivo. Mesmo estando divididas em normas e
modelos, veremos os conceitos de forma conjunta, uma vez
que os objetivos são comuns.
Normas e modelos são ótimas referências. Porém, cada empresa
deverá construir o seu processo.
ISO/IEC 9126
No ano de 2003 a ABNT (Associação Brasileira de Nor-
mas Técnicas) publicou (tradução) a norma NBR ISO/IEC
9126 – “Engenharia de Software – Qualidade do Produto”,
composta de 4 partes:
• Parte 1: Modelo de Qualidade.
• Parte 2: Métricas Externas.
• Parte 3: Métricas Internas.
• Parte 4: Métricas de Qualidade em Uso.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 57
Estudaremos aqui a Parte 1, referente ao modelo de quali-
dade. Utilizamos este modelo como referência para o processo
de avaliação de qualidade de produtos de software.
Dividimos o modelo em duas subpartes:
1. Modelos de Qualidade para características externas e
internas.
2. Modelo de Qualidade para qualidade em uso.
Podemos utilizar o modelo durante o estabelecimento de
metas de qualidade para produtos de software finais e inter-
mediários.
Decompomos o modelo hierarquicamente por meio de
características e subcaracterísticas que podemos usar como
uma lista de verificação.
Características com relação à Qualidade Geral do Software
Categorizamos os atributos de qualidade geral do software
do modelo em 6 características:
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 58

1. Funcionalidade: Satisfaz as necessidades? 3. Usabilidade: É fácil de usar?

Subcaracterística Pergunta-Chave Subcaracterística Pergunta-Chave
Propõe-se a fazer o que foi Propõe-se a fazer o que foi
Adequação Inteligibilidade
pedido? pedido?
Faz o que foi proposto de forma Apreensibilidade É fácil de aprender a utilizar?
Acurácia
correta? Operacionalidade É fácil operar e controlar?
É capaz de interagir com os Está de acordo com normas, leis,
Interoperabilidade Conformidade
demais sistemas existentes? etc. relacionadas à usabilidade?
Está de acordo com normas, Atratividade É atrativo ao usuário?
Conformidade leis, etc. relacionadas à
funcionalidade? 4. Eficiência: É rápido e enxuto?
Evita acesso não autorizado a
Segurança de Acesso
programas e dados? Subcaracterística Pergunta-Chave
2. Confiabilidade: É imune a falhas? Qual o tempo de resposta, tempo
Comportamento em relação ao
de processamento e velocidade na
Subcaracterística Pergunta-Chave tempo
execução de suas funções?
Com que frequência apresenta Comportamento em relação aos Quanto recurso usa? Durante
Maturidade
falhas por defeitos no software? recursos quanto tempo?
Ocorrendo falhas, como ele Está de acordo com normas, leis,
Tolerância a Falhas Conformidade
reage? etc. relacionadas à eficiência?
É capaz de recuperar dados em
Recuperabilidade
caso de falhas?
Está de acordo com normas, leis,
Conformidade
etc. relacionadas à confiabilidade?
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 59

5. Manutenibilidade: É fácil de modificar? Podemos medir as subcaracterísticas por meio de métricas

externas e internas, sendo que encontraremos exemplos de
Subcaracterística Pergunta-Chave
É fácil de encontrar uma falha, métricas externas na ISO/IEC 9126-2 e exemplos de métricas
Analisabilidade
quando ocorre? internas na ISO/IEC 9126-3.
Modificabilidade É fácil modificar e adaptar?
Existe risco de efeitos inesperados Características com relação à Qualidade do Software em um
Estabilidade
quando se faz alterações?
É fácil validar o software
ambiente específico
Testabilidade
modificado?
Está de acordo com as normas, Se observarmos o conteúdo da norma ela nos traz também
Conformidade leis, etc. relacionadas à
outra subdivisão em 4 características, agora referentes ao uso
manutenibilidade?
do software em um ambiente específico:
6. Portabilidade: É fácil de usar em outro ambiente?
1. Eficácia
Subcaracterística Pergunta-Chave
Definimos como eficácia, a capacidade do produto de sof-
É fácil adaptar a ambientes
Adaptabilidade
diferentes? tware de permitir que usuários atinjam metas especificadas com
Capacidade para ser instalado É fácil instalar? acurácia e completitude, em um contexto de uso especificado.
Capacidade para substituir É fácil usar para substituir outro? 2. Produtividade
Pode coexistir com outros
Definimos como produtividade, a capacidade do produto
Coexistência produtos independentes
compartilhando recursos? de software de permitir que seus usuários empreguem quan-
Está de acordo com as normas, leis, tidade apropriada de recursos em relação à eficácia obtida, em
Conformidade
etc. relacionadas à portabilidade?

um contexto de uso especificado.
3. Segurança
Definimos como segurança, a capacidade do produto de
software de apresentar níveis aceitáveis de riscos de danos a
pessoas, negócios, software, propriedade ou ao ambiente, em
um contexto de uso especificado.
4. Satisfação
Definimos como satisfação, a capacidade do produto de
software de satisfazer usuários, em um contexto de uso espe-
cificado.
Principais utilidades
Normalmente priorizamos a aplicação da norma ISO 9126
quando precisamos:
• Definir requisitos da qualidade de um produto de sof-
tware.
• Avaliar as especificações do software durante o desen-
volvimento.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 60
• Descrever as características e atributos de software (por
exemplo em manuais).
• Avaliar o software antes da entrega e antes da aceitação;
• Avaliar produtos de software de terceiros.
ISO/IEC 12207
Histórico
• Em 1989 o JTC1 iniciou o desenvolvimento da ISO 12207,
com o objetivo de identificar os Processos do Ciclo de Vida
de Software.
• Foi desenvolvida com a participação de vários países e pu-
blicada em 1995.
• Nova revisão para alinhamento com a ISO 15288 (Engenha-
ria de Sistemas – Processos de Ciclo de Vida de Sistemas):
12207R WD3 (Junho de 2006).
• Sofreu duas emendas em 2002 e 2004, para aperfeiçoamento.

Características Principais
• Estabelece uma estrutura comum para os processos de
ciclo de vida de software, com terminologia bem definida,
que pode ser referenciada pela indústria de software.
• Aplica-se à aquisição de sistemas, produtos e serviços
de software, para o fornecimento, o desenvolvimento,
a operação e a manutenção de produtos de software,
quer sejam executados interna ou externamente a uma
organização.
• Contém um conjunto de processos, atividades e tarefas
projetado para ser adaptado de acordo com cada projeto
de software.
• A estrutura cobre o ciclo de vida do software desde a
concepção de ideias até a descontinuação do software;
• O processo de adaptação consiste na supressão de pro-
cessos, atividades e tarefas não aplicáveis.
• Descreve a arquitetura dos processos de ciclo de vida
de software, mas não especifica os detalhes de como
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 61
implementar ou executar as atividades e tarefas incluídas
nos processos.
• Não pretende prescrever o nome, formato ou conteúdo
explícito da documentação a ser produzida nem prescrever
um modelo específico de ciclo de vida ou métodos de
desenvolvimento de software.
• As partes envolvidas são responsáveis pela seleção de um
modelo de ciclo de vida para o projeto e pelo mapeamento
dos processos, atividades e tarefas dentro desse modelo
e também são responsáveis pela seleção e aplicação dos
métodos e pela execução das atividades e tarefas adequa-
das ao projeto.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 62

0.. n
Estrutura macro da norma
PROCESSO
Processos possuem propósito e resultado (s). Todos 1
os processos possuem pelo menos uma atividade. Os
1
processos, junto com suas declarações de propósito e
resultados, constituem um Modelo de Referência de
Processo. 1.. n

Atividades são unidades de construção usadas para ATIVIDADE

agrupar tarefas relacionadas. A partir da Emenda 1, se
uma atividade é coesiva o suficiente, ela é convertida em
um subprocesso por meio da definição de propósito e 1
resultados.
1.. n
Uma tarefa é uma cláusula detalhada para a
implementação de um processo. Pode ser um requisito
(deve - “shall”), uma recomendação (deveria - “should”) ou TAREFA
uma permissão (pode- “may”).
1
Notas são usadas quando uma informação explanatória
é necessária para melhor descrever a intenção ou os 0.. n
mecanismos de um processo. Notas proveem uma
orientação considerando potenciais implementações ou
áreas de aplicabilidade, tais como listas, exemplos e outras NOTA
considerações.

Emenda 1 da Norma (2002)
Propósito do Processo: O principal objetivo da execução
do processo. Convém que a implementação do processo forneça
benefícios tangíveis aos envolvidos.
Resultado do Processo: Um resultado observável da rea-
lização com sucesso do propósito do processo.
Um resultado pode ser:
• Um artefato produzido.
• Uma mudança significativa de estado.
• O atendimento das especificações, como por exemplo:
requisitos, metas etc.
Uma lista com os principais resultados do processo faz
parte da descrição de cada processo no Modelo de Referência
de Processo (alinhamento com a ISO 15504).
O Propósito e os Resultados fornecidos são uma declaração
das metas da execução de cada processo.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 63
Conformidade com a Norma
Definimos a conformidade a essa norma como a execução
de todos os processos, atividades e tarefas, selecionados no
processo de adaptação para o projeto de software.
Deve ser demonstrado que a implementação de qualquer
processo do conjunto declarado pela organização resulta na
realização do propósito e dos resultados correspondentes.
Categorias de Processos
Os processos da ISO/IEC 12207 são agrupados em três
categorias:
• Fundamentais: constituem um conjunto de processos que
atendem às partes fundamentais (pessoa ou organização
/ adquirente, fornecedora, desenvolvedora, operadora ou
mantenedora do software).
• De Apoio: auxiliam um outro processo e contribuem para
o sucesso e qualidade do projeto, podendo ser realizados,
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 64

quando necessário, por outro processo.

• Organizacionais: empregados por uma organização
para estabelecer e implementar uma estrutura subjacen-
te, constituída de processos de ciclo de vida e pessoal
associados, e melhorar continuamente a estrutura e os
processos. Normalmente empregamos eles fora do do-
mínio de projetos e contratos específicos.
Importante observarmos, caros alunos, que ainda temos
o processo de adaptação, no qual definiremos as atividades
básicas necessárias para executar as adaptações.

Classificação dos Processos quanto à categoria

(segue tabela abaixo)

 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 65

Processos Fundamentais Processos de Apoio

Aquisição Documentação
Fornecimento Gerência de Configuração
Garantia da Qualidade
Verificação
Operação
Validação
Revisão Conjunta

Processo de Adaptação
Auditoria
Desenvolvimento Usabilidade

Gerência de Resolução de Problemas

Manutenção

Gerência de Solicitação de Mudanças

Avaliação do Produto
Processos Organizacionais
Gerência Engenharia de Domínio

Gestão de Ativos Infraestrutura Melhoria

Gestão do programa de
Recursos Humanos
reuso

Processos e seus Propósitos
• Aquisição: Objetivamos obter um produto e/ou serviço
que satisfaça a necessidade expressa pelo cliente.
• Fornecimento: Precisamos fornecer um produto ou
serviço ao cliente que atenda aos requisitos acordados.
• Desenvolvimento: Nossa meta é transformar um con-
junto de requisitos em um produto de software ou um
sistema baseado em software que atenda às necessidades
explicitadas pelo cliente.
• Operação: Necessitamos operar o produto de software
no seu ambiente e fornece suporte aos clientes desse
produto.
• Manutenção: Devemos contemplar a habilidade de mo-
dificar um produto de software/sistema após sua entrega
para corrigir falhas, melhorar o desempenho ou outros
atributos, ou adaptá-lo a mudanças no ambiente.
• Documentação: Precisamos conseguir desenvolver e
manter registradas as informações do software produzidas
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 66
por um processo.
• Gerência de Configuração: Devemos estabelecer e
manter a integridade de todos os produtos de trabalho
de um processo ou projeto e disponibilizá-los a todos os
envolvidos.
• Garantia da Qualidade: Precisamos fornecer garantia
de que os produtos de trabalho e processos estão em
conformidade com os planos e condições pré-definidos.
• Verificação: É importante confirmarmos que cada pro-
duto de trabalho de software e/ou serviço de um processo
ou projeto reflete apropriadamente os requisitos especi-
ficados.
• Validação: É importante confirmarmos que são atendi-
dos os requisitos de um uso específico pretendido para
o produto de trabalho de software.
• Revisão Conjunta: Quando estamos desenvolvendo um
produto ou serviço devemos manter um entendimento
comum com os envolvidos (stakeholders) a respeito do
progresso obtido em relação aos objetivos acordados e ao

que deveria ser feito. Pessoal! Esta revisão é importante
para gerar engajamento das partes interessadas no projeto
com o projeto em si.
• Auditoria: determinar, de forma independente, a con-
formidade dos produtos e processos selecionados com os
requisitos, planos e contratos, quando apropriado.
• Resolução de Problema: assegurar que todos os pro-
blemas identificados são analisados e resolvidos e que
as tendências são identificadas.
• Usabilidade: garantir que sejam considerados os interes-
ses e necessidades dos envolvidos de forma a proporcionar
otimização do suporte e do treinamento, aumento da
produtividade e da qualidade do trabalho, melhoria das
condições para o trabalho humano e redução das chances
de rejeição do sistema por parte do usuário.
• Avaliação de Produto: garantir, através de exame e me-
dição sistemáticos, que o produto atende às necessidades
especificadas e implícitas dos seus usuários.
• Gerência: organizar, monitorar e controlar a iniciação
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 67
e a execução de qualquer processo de forma a atingir
as suas metas de acordo com as metas de negócio da
organização. É estabelecido por uma organização para
garantir aplicação consistente de práticas por parte da
organização e dos projetos.
• Infraestrutura: manter uma infraestrutura estável e
confiável, necessária para apoiar a execução de qualquer
outro processo. A infraestrutura pode incluir hardwa-
re, software, métodos, ferramentas, técnicas, padrões
e instalações para o desenvolvimento, a operação ou a
manutenção.
• Melhoria: estabelecer, avaliar, medir, controlar e me-
lhorar um processo de ciclo de vida de software.
• Recursos Humanos: fornecer à organização, os recur-
sos humanos adequados e manter as suas competências
consistentes com as necessidades do negócio.
• Gestão de Ativos: gerenciar a vida dos ativos reutilizáveis
desde a sua concepção até a sua descontinuação.
• Gestão do Programa de Reuso: planejar, estabelecer,
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 68

gerenciar, controlar e monitorar esse programa em uma produtos.

organização e sistematicamente explorar as oportunidades PROCESSO
IDENTIFICA
de reuso. IDENTIFICA É EXAMINADO CAPACIDADES E
MUDANÇAS NO PELA RISCO DO
• Engenharia de Domínio: desenvolver e manter modelos,
LEVA A AVALIAÇÃO DO LEVA A
arquiteturas e ativos de domínio. PROCESSO
MELHORIA DO CAPACITAÇÃO
PROCESSO MOTIVA DO PROCESSO
ISO/IEC 15504 e a norma SPICE
Histórico

Nos apresenta uma estrutura para a realização de avaliações

• 1991: Estudo sobre a necessidade de uma norma para
(e melhorias) de processos em empresas.
avaliação de processos de software.
• 1993: Início do Projeto SPICE (Software Process Im-
Contextos de Utilização:
provement and Capability dEtermination).
• 1998: Versão Inicial da “norma SPICE” (publicada como
• Melhoria Contínua: avaliação que identifica oportu-
Relatório Técnico - TR).
nidades de melhoria feita por organizações que buscam
• 2 003: Encerramento do Projeto SPICE e publicação da
melhorias internas.
parte 2.
• Determinação da Capacidade: avaliação identifica ris-
• 2 004: Publicação das partes 1, 3 e 4.
cos com o fornecedor. Feita por terceiros ao realizarem
contratos de prestação de serviços ou fornecimento de
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 69

Categoria de SUP.1 Desenvolver documentação.

Sigla Processos
Processo SUP.2 Desempenhar a gerência de configuração.
SUP.3 Executar a garantia da qualidade.
CUS.1 Adquirir software. Executar a verificação dos produtos de
SUP.4
Cliente- Apoio trabalho.
Fornecedor (Support) Executar a validação dos produtos de
CUS.2 Gerenciar necessidades do cliente. SUP.5
(Customer- trabalho.
Supplier) CUS.3 Fornecer software. SUP.6 Executar revisões conjuntas.
CUS.4 Operar o software. SUP.7 Executar auditorias.
CUS.5 Prover serviço ao cliente. SUP.8 Executar resolução do problema.
Desenvolver requisitos e processos do MAN.1 Gerenciar o projeto.
ENG.1
sistema.
Gerência MAN.2 Gerenciar a qualidade.
ENG.2 Desenvolver requisitos do software.
(Management) MAN.3 Gerenciar riscos.
ENG.3 Desenvolver projeto do software.
Engenharia MAN.4 Gerenciar subcontratantes.
ENG.4 Implementar o projeto do software.
ORG.1 Construir o negócio.
ENG.5 Integrar e testar o software.
ORG.2 Definir o processo.
ENG.6 Integrar e testar o sistema.
Organização ORG.3 Melhorar o processo.
ENG.7 Manter o sistema e o software.
ORG.4 Prover recursos treinados.
ORG.5 Prover infraestrutura organizacional.

A “Norma SPICE”
• É focada exclusivamente em software.
• É um modelo para avaliação de processos de software.
• Possui um modelo de referência que é a base da Avaliação
dos Processos.
• Dá suporte a todo o ciclo de vida do software.
• Dividida em 9 partes.
• É apenas um Relatório Técnico e não uma norma inter-
nacional.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 70
Processos da norma SPICE (Referentes à Parte 7)
ISO/IEC 15504
• É uma norma internacional.
• É genérica, não sendo mais dedicada exclusivamente a
software.
• Introduz o conceito de Modelo de Referência de Processo,
que é externo à norma (antiga parte 2).
• Para ser aplicada à software, deve ser complementada
pela ISO/IEC 12207, considerando suas emendas 1 e 2.
Estrutura macro da norma 15504
A norma nos é apresentada em 5 partes, cujos nomes e
relacionamento são apresentados na figura a seguir:
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 71

medição define nove atributos de processo, agrupados

em seis níveis de capacidade de processo.
• Parte 3 – Nos apresenta um guia para a realização de
avaliações (informativa): provê orientações para inter-
pretar os requisitos para a realização de uma avaliação.
• Parte 4 - Guia para uso na melhoria de processo e na
determinação da capacidade de processo (informati-
va): provê orientações para a utilização de avaliação de
processo para propósitos de melhoria de processo e de
determinação da capacidade.
Detalhamento das partes:
• Parte 5 - Um Exemplo de modelo de avaliação de pro-
cesso baseado na ISO/IEC 12207 e suas Emendas 1 e 2
• Parte 1 - Conceitos e vocabulário (informativa): provê uma
(informativa): contém um exemplo de modelo de avalia-
introdução geral aos conceitos de avaliação de processos
ção de processo que é baseado no modelo de processo de
e um glossário de termos relacionados à avaliação.
referência definido na ISO/IEC 12207 e suas emendas
• Parte 2 - Realização de uma avaliação (normativa): de-
1 e 2.
fine os requisitos normativos para a realização de uma
avaliação de processo e para modelos de processo em uma
avaliação, e define uma infraestrutura de medição para
avaliar a capacidade de processo. Essa infraestrutura de
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 72

Dimensões O processo é
implementado de
forma controlada
2 Gerenciado
• Dimensão de Processo: se limita à verificação da execução (planejado,
monitorado e
ou não dos processos.
ajustado).
• Dimensão de Capacidade: permite uma avaliação de- O processo é
talhada dos processos executados por uma organização. implementado de
3 Estabelecido
forma sistemática e
Trabalha com:
consistente.
O processo é
Níveis de capacidade executado e existe um
controle que permite
verificar se ele se
4 Previsível
Nível Nome Descrição encontra dentro dos
O processo não é limites estabelecidos
implementado ou para atingir os
0 Incompleto resultados.
falha em atingir seus
objetivos. O processo
O processo é adaptado
essencialmente atinge continuamente para,
1 Executado os objetivos, mesmo 5 Otimizado de uma forma mais
se de forma pouco eficiente, atingir os
planejada ou rigorosa. objetivos de negócio
definidos e projetados.

Atributos de Processo
Antes de analisarmos os níveis a serem avaliados na es-
trutura de atributos de processo, explicarei como devemos
interpretar o que segue.
O primeiro número (por exemplo o 2 do item 2.1) indica o
nível de capacidade e o segundo número (no exemplo anterior
o 1 de 2.1) indica o subnível de capacidade.
Níveis a serem avaliados:
1.1 Execução: O processo atinge os objetivos esperados.
2.1 Administração do processo: Objetivos do processo são
identificados e sua execução é planejada. Responsabilidades são
atribuídas, a infraestrutura é fornecida e a comunicação entre
os envolvidos é gerenciada.
2.2 Administração do produto: Produtos do processo são
identificados e documentados, requisitos para eles são definidos
e revisões e ajustes são efetuados conforme necessário.
3.1 Definição: Um processo padrão é definido para a
organização.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 73
3.2 Implementação: Os elementos identificados em 3.1
são postos em prática.
4.1 Medição: Estabelecem-se objetivos quantitativos, bem
como as medições a serem realizadas e a frequência de sua
aplicação. Os resultados são coletados, analisados e publicados
na organização.
4.2 Controle: Estabelecem-se limites de variação para as
medidas e ações corretivas para tratar as causas de desvios em
relação a esses limites.
5.1 Inovação: Objetivos de melhoria são estabelecidos.
Oportunidades de melhoria são identificadas.
5.2 Otimização: O desempenho do processo é medido e
o impacto das melhorias propostas é comparado com os obje-
tivos esperados. A implementação de mudanças é gerenciada.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 74

Avaliação dos Atributos de Processo possíveis valores para cada atributo temos a tabela a seguir

Resultado para o Índice de onde trago a vocês os requisitos para que uma empresa esteja
Descrição do Status
atributo avaliado conformidade em um determinado nível de maturidade.
Existe pouca ou Nível de Capacidade
nenhuma evidência
N - Não Atingido 0 a 15% 1 2 3 4 5
de que o atributo de
processo seja atingido. 1.1 L ou T T T T T
Existe evidência de 2.1 L ou T T T T
uma abordagem
2.2 L ou T T T T
significativa para
P - Parcialmente 3.1 L ou T T T
16 a 50% atingir o atributo, mas
Atingido
alguns aspectos (tais 3.2 L ou T T T
como resultados) são 4.1 L ou T T
ainda imprevisíveis.
4.2 L ou T T
O desempenho do
L - Largamente 5.1 L ou T
51 a 75% processo pode variar
Atingido 5.2 L ou T
em algumas áreas.
Não há nenhuma ISO 15504 e ISO 12207
T - Totalmente
76 a 100% falha ou falta
Atingido
significativa.
Podemos utilizar a norma ISO 12207 como o Modelo de
Níveis Exigidos de Capacidade de Processo x Avaliação
referência de processo, quando aplicarmos a norma ISO 15504
à software.
Após estudarmos os possíveis atributos de processo e os
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 75

Square: ISO/IEC 25000 • ISO/IEC 25062: provê um método padrão para reportar
os resultados dos testes de usabilidade.
É a sigla para Software product Quality Requirements and
Evaluation e constitui a evolução e reorganização das séries Arquitetura
de normas 9216 e 14598 que vimos anteriormente. Por este
REQUISITOS REQUISITOS DE QUALIDADE
motivo, apresentaremos a mesma de forma resumida, iniciando
DE AVALIAÇÃO
pelo histórico: REQUISITOS DE QUALIDADE
QUALIDADE 2504n
• A proposta inicial para esta norma foi dada em 1999 na
reunião de Kanazawa. 2503n REQUISITOS DE QUALIDADE

• Foi aprovada pelo comitê de normas da ISO em 2000

A ISO/IEC reservou o limite de 25050 a 25099 no caso
na reunião de Madri.
de ser utilizado para os padrões internacionais de extensão do
• Em agosto de 2005 foi lançada a primeira versão da
SQuaRE e/ou para os relatórios técnicos.
norma SQuaRE Norma ISO/IEC 25000.
Nos documentos pertecentes a esta norma, destacamos os
guias:
Evolução
• 25000 – Guia Geral da Norma Square que utiliza ter-
minologia da 14598-1.
Em 2006, foram acrescentadas à norma mais duas extensões:
• 25001 – Guia de Planejamento e Gerenciamento, que
• ISO/IEC 25051: define requisitos de qualidade para
substitui a 14598-2.
COTS.
• 25010 – Guia do modelo de Qualidade que é baseado

na 9126-1.
• 25012 – Guia para a qualidade dos dados que é novo em
relação às normas predecessoras.
• 25020 – Guia e Modelo geral para medições de software
que incorpora a terminologia das guias 9126-1,2,3 e 4.
• 25021 – Guia para elementos de medição que é novo em
relação às normas predecessoras.
• 25022 – Guia de Medidas externas que substitui o guia
9126-3.
• 25023 – Guia de Medidas internas que substitui o guia
9126-2.
• 25024 – Guia de Qualidade na medição que substitui a
guia 9126-4.
• 25040 – Guia para o processo de avaliação de software,
que inclui grandes revisões sobre a guia 14598-1.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 76
Principais diferenças para as normas 9126 e 14598
As principais diferenças da SQuaRE em relação às normas
9126, 14598 são:
• Introdução de um novo modelo de referência geral.
• Introdução de guias detalhados para cada divisão.
• Introdução de elementos de medida de qualidade dentro
da divisão de medida de qualidade.
• Introdução da divisão de requisitos de qualidade.
• Incorporação e revisão dos processos de avaliação.
• A linhamento do conteúdo com a norma ISO/IEC 15939
(processos de medição).
CMMI
O CMMi é um modelo de referência que define práticas
necessárias para o desenvolvimento e avaliação de maturidade
de software em uma organização. Não podemos considerá-lo
como uma metodologia, pois não nos orienta COMO deve ser
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 77

feito e sim o QUE deve ser feito. zar algum modelo de maturidade por estágios, quando deseja
Surgiu durante a década de 1980 como um modelo para utilizar o nível de maturidade alcançado para comparação com
avaliação de risco na contratação de empresas de software pelo outras empresas ou quando pretende usar o nível de conheci-
Departamento de Defesa dos Estados Unidos que desejava ser mento obtido por outros para sua área de atuação.
capaz de avaliar os processos de desenvolvimento utilizados É dividida em 5 níveis, sendo:
pelas empresas que concorriam em licitações como indicação 5
da previsibilidade da qualidade, custos e prazos nos projetos Foco contínuo na melho- OTIMIZAÇÃO
ria dos processos.
contratados. 4
GERENCIADO
Foi desenvolvido e é mantido pelo SEI (Software Enginee- Processos são medidos e
QUANTITATIVAMENTE
controlados.
ring Institute) da Universidade Carnegie Mellon e possui duas 3
Processos são caracteri-
formas de implementação, que são a representação por estágios zados para Organização DEFINIDO
e são pró-ativos.
e a representação contínua, que veremos em detalhes a seguir. 2
Processos são caracterizados
para Projeto e as ações são GERENCIADO
frequentemente reativas.
Representação por Estágios 1
Processos são imprevisíveis, INICIAL
pouco controlados e reativos.
Esta representação fornece um caminho pré-definido para
melhoria por meio de implementação sequencial, onde cada Nesta representação, a maturidade é medida por um con-
nível é base para o próximo. junto de processos. Assim é necessário que todos os processos
Indicaremos esta representação quando a empresa já utili- atinjam o nível de maturidade dois para que a empresa seja

certificada com nível dois. Se quase todos os processos forem
nível três, mas apenas um deles estiver no nível dois, a empresa
não irá conseguir obter o nível de maturidade três.
Detalhamento dos níveis:
• Nível 1 (Inicial) – Neste nível, os processos não estão
documentados nem padronizados e o sucesso depende
muito mais da competência e do “heroísmo” de pessoas
da organização. Neste cenário, é comum os projetos ul-
trapassarem o orçamento previsto e os prazos acordados,
além de não serem capazes de repetirem experiências de
sucesso de forma estruturada.
»» Quantidade de Áreas de Processos = 0 (Zero). Con-
sidera-se de nível 1, todas as organizações que não
atendam a todos os requisitos do nível 2, ou seja,
se uma determinada organização consegue cumprir
quase todas as metas do nível 2, ainda sim ela será
considerada de Nível 1 (complicado não?).
• Nível 2 (Gerenciado) – As Áreas de processo pré-defi-
nidas para este nível devem atender as metas genéricas e
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 78
específicas de nível 2. Quando a organização está neste
nível de maturidade, os projetos possuem requisitos que
são gerenciados e os processos são planejados, realizados,
medidos e controlados.
»» Quantidade de Áreas de Processos = 7 (sete). As
Áreas de processo têm maior foco no gerenciamento
de projetos e de requisitos, conforme veremos em
postagens mais para frente.
• Nível 3 (Definido) – Neste nível, as Áreas de processo
do nível anterior e aquelas escolhidas para este nível
atendem às metas específicas e genéricas associadas aos
níveis 2 e 3. A expressão chave deste nível é “padroni-
zação de processo”. No nível 3, os processos são bem
caracterizados, sendo descritos por padrões estabelecidos
e melhorados ao longo do tempo (melhorados mesmo
sem ter uma base quantitativa, alvo do nível 4).
»» Quantidade de Áreas de Processos = 11 (onze). As
Áreas de processo têm maior foco no desenvolvimento
organizacional.

• Nível 4 (Gerenciado Quantitativamente) – Neste nível,
todas as Áreas de processo dos níveis anteriores mais
aquelas específicas deste nível devem atender as metas
específicas dos níveis 2, 3 e 4 e as metas genéricas dos
níveis 2 e 3. Os subprocessos mais importantes são con-
trolados com técnicas estatísticas, ou seja, por meio de
indicadores. Vejam que não são todos os processos, uma
vez que é bastante trabalhoso o processo de gerenciar
quantitativamente. Além disso, a prática mostra que
só se consegue medir de forma efetiva os processos que
estiverem padronizados, ou seja, que já estejam no nível
3 de maturidade. Outra observação interessante, já que
as organizações irão escolher os subprocessos a terem
indicadores coletados, é que não há a necessidade de
se atingir as metas genéricas de nível 4, senão todas as
outras Áreas de Processo teriam que obrigatoriamente
também atingir este nível.
»» Quantidade de Áreas de Processos = 2 (dois). As
Áreas de processo têm maior foco no desempenho
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 79
quantitativo dos processos, conforme veremos em
postagens mais para frente.
• Nível 5 (Em Otimização) – Todas as Áreas de processo
dos níveis anteriores mais aquelas específicas deste nível
devem atender as metas específicas dos níveis 2, 3, 4 e
5 e as metas genéricas dos níveis 2 e 3. Neste nível, os
processos são melhorados continuamente, baseados na
avaliação quantitativa do nível anterior.
»» Quantidade de Áreas de Processos = 2 (dois). As
Áreas de processo têm maior foco na inovação e na
obtenção de previsibilidade para a melhoria sistemática
dos processos.
Representação Contínua
Esta representação possibilita à organização, utilizar a
ordem de melhoria que melhor atende os seus objetivos de
negócio.
A representação contínua é indicada quando a empresa

deseja tornar apenas alguns processos mais maduros, quando
já utiliza algum modelo de maturidade contínua ou quando
não pretende usar a maturidade alcançada como modelo de
comparação com outras empresas.
5- Otimizado
4- Gerenciado Quantitativamente
3 - Definido
2 - Gerenciado
1 - Executado
0 - Incompleto
É dividido em 6 níveis, sendo eles:
Nesta representação a capacidade é medida por processos
separadamente, onde é possível ter um processo com nível
um e outro processo com nível cinco, variando de acordo com
os interesses da empresa.
Detalhamento dos níveis:
• Nível 0 (Incompleto) – Neste nível de capacidade, a Área
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 80
de Processo não alcança uma ou mais metas específicas.
Como já dissemos, no CMMI a coisa é binária. Não
adianta fazer o quase. É tudo ou nada. Assim sendo, a
Área de negócio classificada no nível zero significa que a
mesma não é executada ou é executada de forma parcial.
• Nível 1 (Executado) – Neste nível, a Área de Processo
satisfaz todas as suas metas específicas, o que garante
que o trabalho necessário é feito a fim de transformar
entradas bem definidas em saídas adequadas para aquela
Área de processo.
• Nível 2 (Gerenciado) – Neste nível, a Área de processo
é planejada e executada de acordo com uma política e
há o emprego adequado de recursos e pessoas. Além
disso, a Área de processo produz resultados controlados
uma vez que é monitorado e revisado. Cabe aqui uma
observação importante, apesar da Área de processo ser
executada de acordo com uma política, não significa dizer
que seja algo padronizado, pois esta é uma característica
específica do próximo nível. Se pudermos exprimir em

palavras a diferença entre Política e Padrão diria que este
(padrão) envolve ferramentas, procedimentos, métodos
de trabalho definidos para os projetos da organização,
enquanto aquele (Política) representa princípios gerais,
diretrizes a serem seguidas pela Área de processo.
• Nível 3 (Definido) – Neste nível, a Área de processo,
além de fazer tudo dos níveis anteriores, é uma adaptação
do processo padrão da organização. A Área de processo
fornece informações para sua melhoria. Diferentemente
do que se possa pensar, é neste nível de capacidade que
uma Área de processo começa a fazer uma melhoria
em seu próprio processo e não apenas nos níveis 4 e 5.
No nível 3, a melhoria está baseada na identificação de
pontos fortes e pontos fracos da Área de processo;
• Nível 4 (Gerenciado Quantitativamente) – Neste nível,
a Área de processo é controlada com base em indicadores,
usando técnicas estatísticas e outros métodos quantita-
tivos. É de extrema importância notar que o gerencia-
mento quantitativo só consegue ser implementado em
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 81
sua plenitude quando se tem um padrão, por isso este
nível vem após o nível 3. Em processos padronizados é
mais fácil identificar indicadores que meçam de forma
mais efetiva o seu comportamento e seus resultados;
• Nível 5 (Otimização) – Este nível é o sonho de qualquer
Gerente de Processos! A Área de processo é modificada e
adaptada para corresponder aos objetivos do negócio uma
vez que é baseada em métricas e indicadores definidos.
O foco aqui é na melhoria contínua feita por meio de
melhorias incrementais e também por inovações.
Pessoal, sei que fica um pouco confuso entender se uma
determinada melhoria que é feita em uma Área de processo
o coloca no nível 3, 4 ou 5. Para facilitar, podemos fazer a
analogia da melhoria dos níveis 3, 4 e 5 com o processo de
afinamento de um violão.
Querem ver?
• Nível 3 – Afinar o violão de ouvido (melhoria empírica).
• Nível 4 – Colocar um aparelho que possa medir (uso de
indicadores).
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 82

• Nível 5 – Afinar o violão baseado no aparelho específico Categorias\

para esta função. Níveis Nível 2 Nível 3 Nível 4 Nível 5
Percebem a diferença? Eu espero que sim!

- Desenvolvimento
Categorias de Processos de Requisitos.
- Solução técnica
-
Integração do
Após passarmos pelas representações do CMMI, chegou o Engenharia Gerenciamento
produto.
de requisitos.
momento de falarmos dos processos que compõem este modelo. - Verificação.
- Validação.
Para que possamos facilitar o entendimento, estaremos expli-
cando inicialmente, o que o CMMI chama de Categorias de -
Processos. Segundo este modelo, as Áreas de processos (também Planejamento
do projeto. - Gerenciamento
chamadas de Processos) são divididas em categorias e estão - Controle e integrado do -
distribuídas pelos Níveis de maturidade da representação por Gerência monitoramento projeto. Gerenciamento
estágio (do nível 2 ao nível 5, uma vez que não faz sentido
de Projetos do projeto. - Gerenciamento quantitativo do
- Contratação de riscos. projeto.
ter processos relacionados ao nível 1, conforme já vimos). e gestão de
O quadro abaixo (Níveis de maturidade X Categorias X fornecedores.

Áreas de processos) nos mostra exatamente quais são os Pro-

cessos de cada Nível.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 83

- Foco no processo Vamos observar o quadro acima para podermos identificar

organizacional.
- Definição e compreender as seguintes Categorias de Processos:
Gerência - Desempenho - Inovação e
do processo • Engenharia – Áreas de processos que estão diretamente
de organizacional.
do processo implantação
Processos organizacional. organizacional. ligadas à Engenharia de Software.
- Treinamento
organizacional. • Gerência de Projetos – Processos que estão ligados aos
passos necessários para que sejam executados projetos
- Medição e
com sucesso.
análise.
- Garantia de • Gerência de Processos – Processos que estão ligados a
qualidade do questões institucionais e na quantificação dos resultados.
- Análise de - Análise e
processo e
Suporte produto.
decisão e resolução de • Suporte – Áreas de processos que auxiliam outros pro-
resolução. causas.
- cessos nos mais diversos níveis.
Gerenciamento
de
configuração. Finalmente, podemos verificar que os Níveis de maturi-
Quadro Níveis de maturidade X Categorias X Áreas de Processos dade, de forma genérica e mais simplória, buscam os seguintes
objetivos, levando-se em consideração a divisão dos processos
no quadro “Níveis de maturidade X Categorias X Áreas de
Processos”:
• Nível 2 – Foco no Gerenciamento de Projetos.
• Nível 3 – Foco na Padronização e na Engenharia de

Software.
• Nível 4 – Foco na quantificação dos processos.
• Nível 5 – Foco na melhoria e na inovação.
Vantagens do CMMI:
O modelo de qualidade CMMI é reconhecido interna-
cionalmente e se tornou uma referência no mercado, buscando
obter um diferencial competitivo. O conjunto de práticas do
CMMI contribui para o aprimoramento dos processos de uma
organização tornando-a mais madura e eficiente.
O CMMI ajuda a organização a conhecer os seus processos
e o seu desempenho, melhorando a precisão do planejamento.
Permite um melhor monitoramento dos processos, possibili-
tando que o gerente de projetos saiba se o projeto dará certo
ou não.
Com o tempo, adquirindo maturidade, a empresa vai iden-
tificando o que realmente tem valor, sendo este o foco, otimi-
zando cada vez mais os processos, o que justifica o CMMI,
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 84
que é um modelo que possibilita uma melhoria contínua nos
processos, amadurecendo as organizações e tornando-as mais
competitivas.
Desvantagens do CMMI
Para certificação CMMI é necessário a realização de ava-
liações e este processo além de demorado, possui alto custo.
Além disso, é necessário investir tempo, geralmente, para
se chegar aos níveis de maturidade mais altos leva-se em média
de 4 a 8 anos. Essas dificuldades contrastam com a realidade
de muitas empresas que não podem realizar um investimento
tão alto na obtenção da certificação.
Muitas empresas tratam o CMMI como um processo e
não como um modelo, e relatam que nem todas as práticas são
realmente necessárias na maioria dos casos. Por isso, muito
trabalho poderia ser evitado, principalmente em projetos pe-
quenos. Frases como: “O CMMI engessa o processo”, “O custo

de desenvolvimento fica alto devido ao CMMI”, “O CMMI
vai contra um processo ágil” são emitidas frequentemente por
profissionais que seguem essa linha de pensamento. Para eles,
a qualidade gerada pelo CMMI possui um preço muito alto a
se pagar e não agrega muito valor à organização.
MPS BR
Conceito e Objetivo
O MPS.BR (Melhoria de Processo do Software Brasileiro)
é, ao mesmo tempo, um modelo de referência de qualidade de
processo e um programa com intuito de melhorar a eficiência
das empresas brasileiras de desenvolvimento de software.
Embora seja um modelo brasileiro, ele é apoiado em práticas
mundiais e podemos utilizá-lo em qualquer país.
Como sempre, é importante conhecermos um pouco da
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 85
história. A iniciativa foi promovida em dezembro de 2003,
pela Associação para Promoção da Excelência do Software
Brasileiro (SOFTEX) e conta com o apoio do Ministério da
Ciência, Tecnologia e Inovação (MCT), da Financiadora de
Estudos e Projetos (FI-NEP), do Serviço Brasileiro de Apoio
às Micro e Pequenas Empresas (SEBRAE) e do Banco Inte-
ramericano de Desenvolvimento (BID).
O MPS.BR tem como foco principal atender a mi-
cro, pequenas e médias empresas de software brasileiras, com
poucos recursos e que desejem obter melhorias significativas
nos seus processos de software. Busca-se que o modelo MPS
seja adequado ao perfil de empresas com diferentes tamanhos
e características, públicas e privadas, seja compatível com os
padrões de qualidade aceitos internacionalmente e que tenha
como pressuposto o aproveitamento de toda a competência
existente nos padrões e modelos de melhoria de processo já
disponíveis.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 86

O modelo MPS.BR possui quatro componentes: Modelo de Referência MPS para Software (MR-MPS-SW)
• Modelo de Referência MPS para Software (MR-MP-
S-SW).
• Modelo de Referência MPS para Serviços (MR-MPS- Temos 3 guias que compõem o MPS-BR: O Guia Geral
-SV). MPS de Software, o Guia de Aquisição e os Guias de Imple-
• Método de Avaliação (MA-MPS). mentação.
• Modelo de Negócio (MN-MPS). O Modelo de Referência MPS para Software (MR-MPS-
Todos esses componentes são descritos por guias de forma -SW) contém as definições dos níveis de maturidade, processos
individual, podendo possuir mais de um guia para cada um. e atributos do processo que as unidades organizacionais devem
Atenção: Esta figura atender para estar em conformidade.
representa a hierarquia e
as bases do Modelo MPS!!!
Ela é importante para Estudamos anteriormente as normas ISO/IEC 15504, ISO/IEC
a nossa compreensão 12207 e o modelo CMMi. Estas foram utilizadas como base para o
e busca de referências
detalhadas! MPS.BR.

Modelo de Referência MPS para Software (MR-MPS-SW) - Guia

de Aquisição

O Guia de Aquisição é destinado a organizações que pre-
tendam adquirir software e/ou serviços, sendo complementar
aos guias do MR-MPSSW e MR-MPS-SV. Este guia não
contém nenhum requisito destes guias principais. Consiste
apenas em um documento descrevendo as boas práticas para
à aquisição de software e serviços.
Modelo de Referência MPS para Software (MR-MPS-SW) - Guia
de Implementação
Se observarmos o guia de implementação podemos ve-
rificar que o mesmo é composto por 11 partes, cujo conteúdo
não é considerado requisito do modelo MPS.BR, possuindo
apenas caráter informativo. Nas partes de 1 a 7, são sugeridas
formas para implementação dos níveis do MR-MPS-SW. Na
parte 8, formas de como uma organização que faz aquisição de
produtos pode implementar o MR-MPS-SW são apresentadas.
Nas partes 9 e 10, são sugeridas formas de como Fábri-
cas de software e Fábricas de testes, podem implementar o
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 87
MR-MPS-SW. Na última parte, a 11, um mapeamento do
MR-MPS-SW e do CMMIDEV é apresentado, de forma a
auxiliar as organizações, tanto no âmbito das implementações
quanto no das avaliações de processos, nas iniciativas de me-
lhoria de processos de software.
Modelo de Referência MPS para Serviços (MR-MPS-SV)
É composto pelo Guia Geral MPS de Serviços. O Modelo
de Referência MPS para Serviços (MR-MPS-SV) contém as
definições dos níveis de maturidade, processos e atributos do
processo que as unidades organizacionais devem atender para
estar em conformidade. Tem como base as normas ISO/IEC
15504 e ISO/IEC 20000.
A criação do MR-MPS-SV também levou em consideração
outras normas e modelos internacionalmente reconhecidos, além
de boas práticas da engenharia de software, como o ITIL e o
modelo CMMI-SVC e as necessidades de negócio da indústria
de software nacional.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 88

Método de Avaliação (MA-MPS) Estrutura

Níveis de Maturi-
dade
Encontra-se no guia de avaliação. O Guia de Avaliação (MA-
Processo Capacitação
-MPS) consiste no método e processo de avaliação, além de todos
os requisitos necessários aos avaliadores líderes, avaliadores adjuntos
e Instituições Avaliadoras (IA). Proposito Atributo

O conteúdo deste guia de avaliação MA-MPS, está em con-

formidade com norma ISO/IEC 15504.
Resultados Resultado

Modelo de Negócio (MN-MPS)
O Modelo de Negócio (MN-MPS) descreve, através de regras
de negócio, como as Instituições Implementadoras (II) devem im-
plementar o MR-MPS-SW e MR-MPS-SV, como as Instituições
Avaliadoras (IA) devem fazer a avaliação seguindo o MA-MPS,
como será feita a organização de grupos de empresas pelas Instituições
Organizadoras de Grupos de Empresas (IOGE) para a realização
dos itens anteriores, como certificar os consultores de Aquisição
(CA) e criar os programas anuais de treinamento do MPS.BR.
Veremos uma base de cada um dos itens da figura acima nos
itens a seguir. Poderemos encontrar maiores detalhes a respeito da
norma, bem como os guias de referência no endereço: http://www.
softex.br/mpsbr/guias/
Níveis de Maturidade no MPS.BR
Alunos!!! No MPS.BR não temos o conceito de “representação
contínua” como no CMMI.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 89

Desenvolvimento de
O modelo está estruturado em uma única representação, através requisitos.
de níveis de maturidade (a exemplo da representação por estágios Solução técnica.
do CMMI). Integração de
D Largamente definido produto.
Outra diferença que encontramos no modelo MPS.BR é que
Instalação de produto.
existem 7 níveis de maturidade designados pelas letras: G (nível
Liberação de produto.
mais baixo), F, E, D, C, B e A (nível mais alto) ao invés dos 5 níveis
Verificação.
tradicionais do CMMI. Validação.
Nível Descrição do Nível Processos do Nível Treinamento.
Inovação e Avaliação e melhoria
implantação na do processo
A Em otimização organização. organizacional.
Análise de causas e E Parcialmente definido Definição do processo
resolução. organizacional.
Desempenho Adaptação do
do processo processo para
Gerenciado organizacional. gerência de projeto.
B
quantitativamente
Gerência quantitativa Medição.
do projeto. Gerência de
Análise de decisão e F Gerenciado configuração.
C Definido resolução. Aquisição.
Gerência de Riscos. Garantia da Qualidade.
Parcialmente Gerência de requisitos.
G
gerenciado Gerência de projeto.

Processo
Descrevemos os processos no MR-MPS-SW são descritos
em termos de propósito e resultados, e estão detalhados na
seção 9. O propósito descreve o objetivo geral a ser atingido
durante a execução do processo. Os resultados esperados do
processo estabelecem os resultados a serem obtidos com a efe-
tiva implementação do processo. Estes resultados podem ser
evidenciados por um produto de trabalho produzido ou uma
mudança significativa de estado ao se executar o processo.
Capacidade do processo
Representamos a capacidade do processo por um conjun-
to de atributos de processo descrito em termos de resultados
esperados. A capacidade do processo expressa o grau de refi-
namento e institucionalização com que o processo é executado
na organização/unidade organizacional. No MR-MPS-SW,
à medida que a organização/unidade organizacional evolui
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 90
nos níveis de maturidade, um maior nível de capacidade para
desempenhar o processo deve ser atingido.
O atendimento aos atributos do processo (AP), pelo atendi-
mento aos resultados esperados dos atributos do processo (RAP),
é requerido para todos os processos no nível correspondente ao
nível de maturidade, embora eles não sejam detalhados dentro
de cada processo.
Os níveis são acumulativos, ou seja, se a organização está
no nível F, esta possui o nível de capacidade do nível F que
inclui os atributos de processo dos níveis G e F para todos os
processos relacionados no nível de maturidade F (que também
inclui os processos de nível G). Isto significa que, ao passar do
nível G para o nível F, os processos do nível de maturidade G
passam a ser executados no nível de capacidade correspondente
ao nível F. Em outras palavras, na passagem para um nível de
maturidade superior, os processos anteriormente implementados
devem passar a ser executados no nível de capacidade exigido
neste nível superior.
Os diferentes níveis de capacidade dos processos são des-

critos por nove atributos de processo (AP). O alcance de cada
atributo de processo é avaliado utilizando os respectivos re-
sultados esperados de atributo de processo (RAP).
PSP e TSP
Vimos até agora, processos focados na melhoria da pro-
dutividade da empresa como um todo. Porém, sabemos que
algumas pessoas possuem certa dificuldade em se organizar,
por mais que tenham a técnica e o conhecimento necessários
para desempenhar bem as suas funções.
Tendo isto em vista, foram criados dois processos: Um
focado na melhoria da produtividade e efetividade individual
(PSP – Personal Software Process) e outro com o mesmo ob-
jetivo macro, porém voltado aos times (ou equipes) de trabalho
(TSP – Team Software Process).
Guardem bem estas siglas, pois utilizaremos elas durante
este tópico.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 91
Vamos iniciar o estudo pelo PSP, então os tópicos seguintes
farão referência a este assunto.
Observando a teoria a respeito do tema, podemos verificar
que o PSP é estruturado em níveis, de forma semelhante ao
CMMI e ao MPS.BR. No PSP temos 4 níveis conforme a
seguir:
• Nível 0: fundamentos de medidas e formatos de relatórios.
• Nível 1: planejamento e estimativas de tamanho e tempo.
• Nível 2: controle pessoal de qualidade de projeto.
• Nível 3: extensão a projetos grandes.
Nobres alunos!! O PSP é baseado em princípios simples,
dos quais podemos citar como principais:
Cada indivíduo é diferente, então o planejamento do tra-
balho por parte do gerente de projetos deve levar em conta
as variações de produtividade (mínima e máxima) de cada
integrante da equipe. Devemos obter estes indicadores de
produtividade de outros projetos que a pessoa já participou.
Outro ponto importante é que tenhamos em mente que
a melhoria do desempenho individual deve ser baseada em
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 92

processos bem definidos e medidos. Pela medição individual, os princípios de unicidade de cada pessoa ainda são válidos.
A pessoa é responsável pela qualidade de seu trabalho, assumindo assim a responsabilidade por erros e atrasos decorrentes
de suas atividades no projeto.
O desenvolvedor de software precisa realizar um bom planejamento prévio de suas atividades, antes de iniciar o desenvol-
vimento, medindo os tempos de cada etapa e desvios (erros) encontrados e corrigidos.

Estrutura

A figura a seguir resume a estrutura macro de processos do PSP. Conforme vimos no princípio 4, para cada etapa o desen-
volvedor deve relatar os tempos utilizados, defeitos encontrados e corrigidos e outros desvios ou fatos que julgar importante.
Utilizaremos todos os dados no final do projeto para melhorar o processo como um todo, em um ciclo virtuoso de melhoria.
REQUISITOS SCRIPTS

PLANEJAR PROJETAR REVISÃO DO CODIFICAR REVISÃO DO COMPILAR E TESTAR PÓS-PROJE-

PROJETO CÓDIGO CORRIGIR TO

REGISTROS REGISTRO SUMÁRIO

DE TEMPOS DE DEFEITOS DO PLANO

Scripts
Quando elaboramos um projeto no PSP realizamos uma
sequência de tarefas claramente determinadas. Conseguimos
desta forma, que mesmo um desenvolvedor inexperiente realize
uma abordagem estruturada e organizada para o problema que
ele irá resolver.
Devemos quebrar as atividades macro em subatividades
até que as mesmas consigam ser expressas formalmente, de
forma que o desenvolvedor consiga medir os tempos e computar
eventuais desvios da atividade.
Os modelos de scripts sugeridos pelo processo, bem como
o script completo, poderão ser verificados em www.sei.cmu.
edu/reports/00tr022.pdf .
Plano do Projeto
Já vimos que o planejamento eficiente é a chave do PSP,
então vamos entrar em alguns detalhes do plano de projeto,
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 93
para entender seus principais componentes e podermos elaborar
o nosso próprio plano quando necessário.
Importante iniciarmos com a definição de um formulário
padrão, que será utilizado por todos os projetos. Neste docu-
mento iremos definir o que será feito e como realizaremos o
trabalho.
A cada nível do PSP, o formulário será mais detalhado, ou
seja, teremos mais informações a serem preenchidas. A prin-
cípio isso pode nos fazer rejeitar os níveis superiores, porém a
prática mostra que a cada nível nos tornamos mais eficientes,
e esta burocracia adicional acaba acarretando pouco tempo a
mais nos projetos.
A seguir trago um exemplo de formulário, simplificado
para fins de entendermos ele mais facilmente, visto que este
é provavelmente o primeiro contado de muitos de vocês com
a metodologia.
Importante deixar claro que as medições podem ser rea-
lizadas em minutos ou linhas de código (LOC) ou mil linhas
de código (KLOC).
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 94

Planejado Realizado Até o Codificação

momento Revisão do
Resumo Código
Minutos/LOC Compilação
LOC/hora Teste
Defeitos / KLOC Pós-Projeto
Yeld Total
A/F-R Tempo total
mínimo
Tamanho do Programa
Tempo total
Novo e alterado
máximo
Tamanho Defeitos inseridos
máximo
Planejamento
Tamanho
mínimo Projeto
Quadro 1 do plano de projeto Codificação
Revisão
Planejado Realizado Até o % Até o Compilação
momento momento
Teste
Tempo (minutos)
Total
Planejamento
Defeitos removidos
Projeto
Planejamento

Projeto
Codificação
Revisão
Compilação
Teste
Total
Quadro 2 do plano de projeto
Iniciamos o preenchimento através da coluna planejado,
que nada mais é do que as estimativas que realizamos antes
de iniciar a codificação. Assim que terminarmos o programa
e já tivermos realizado todas as medições iremos preencher a
coluna. Já a coluna “até o momento” será preenchida conforme
o desenvolvedor for evoluindo em seu trabalho no projeto.
Devemos realizar todas as medidas de tempo em minutos.
Fundamental termos claro que a contagem de erros não
poderá desabonar um desenvolvedor, pois correremos o risco do
mesmo não registrar as informações de forma real. Estes núme-
ros devem ser utilizados para a melhoria pessoal e localização
de eventuais treinamentos necessários para este desenvolvedor.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 95
No quadro 2 do plano, utilizaremos a coluna “% até o
momento” para contabilizar proporções em relação a valores
históricos. Exemplificando, em um programa A, a fase de
levantamento de requisitos foi responsável por 15% dos erros,
enquanto em um programa B, a mesma fase conteve 25% dos
erros. Ao fazermos o planejamento de um programa futuro
com base nesses dados, um desenvolvedor irá concluir que his-
toricamente 20% de seus erros estão nos requisitos. Este valor
será utilizado na coluna % até o momento. De forma análoga
temos a coluna “até o momento” que ao invés do percentual
irá conter o número de ocorrências até o momento.
Com a informação de número de linhas de código pro-
duzidas e o tempo gasto, conseguimos preencher as colunas
referentes a estas informações no plano (quadro 1).
Ponto de atenção pessoal!!!! As linguagens modernas de desen-
volvimento podem dificultar a contagem de linhas de código, pois
temos muitos arquivos para um mesmo programa. Por este motivo
é fundamental que padronizemos a forma de escrita de código.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 96

Informações sobre registro de defeitos: lise e melhoria de nosso desempenho enquanto desenvolvedores.

Sobre os defeitos, o PSP nos orienta a dividi-los em cate- Controle de Qualidade

gorias conforme exemplifica o quadro abaixo:
Código Nome Exemplos Já deve ter ficado claro para nós que o controle de qualida-
Requisitos, diagramas, de no PSP é baseado na questão dos defeitos, seja no número
10 Documentação
etc.
deles ou nas razões dos mesmos.
Erros de sintaxe no
20 Sintaxe Podemos utilizar diversas medidas para tabular estes nú-
código.
Versões de meros:
30 Construção (build)
bibliotecas. • Densidade: defeitos por KLOC.
Omissões, falhas de • Taxas: defeitos por minuto.
50 Interface
projeto.
• Yeld: percentual de erros corrigidos por atividade. Exem-
Outra questão que devemos levar em conta é o log de de- plo: Se até a fase de revisão do projeto encontramos um
feitos que deve seguir um formato conforme abaixo: total de 27 erros identificados e 11 foram eliminados na

Data Número Tipo Inserido Removido Tempo Origem revisão teremos um valor de 40% para o Yeld (11 dividido
Remoção por 27 X 100).
Utilizamos como base para estas medidas do processo de
Descrição: revisão, onde iremos coletar os indicadores e calcular os nú-
meros finais através de listas de verificação.
Poderemos utilizar este log de defeitos como entrada para aná-
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 97

Lembrete: padronizem as listas de verificação! • Comunicação livre e frequente.

Processo para Times: TSP Estrutura do TSP:

Vimos de forma macro, o processo de PSP, que é aplicável Primeiramente devemos treinar os membros do time no PSP
somente a indivíduos. Porém, sabemos que a meta de produzir e que o PSP tenha sido adotado pelos mesmos.
projetos com qualidade deve pertencer ao time e não aos indi- Com base nestas habilidades treinadas, são agregadas ativi-
víduos de forma isolada, como forma de produzir um ambiente dades para que a coordenação do trabalho do time seja possível,
colaborativo. conforme a figura abaixo nos explica:
Para isto foi proposto um modelo que visa auxiliar os times • A equipe é proprietária dos seus processos e pode mu-
de trabalho, que já utilizam o PSP de forma individual, a terem dá-los sempre que necessário.
um desempenho melhor e a padronizar o processo de trabalho. • Os processos da equipe são baseados em sua:
Como qualquer método formal, o TSP requer que sejam »» experiência;
definidos: »» conhecimento;
• Objetivos e papéis comuns ao time. »» maturidade.
• Definição de um processo comum de trabalho. O TSP provê um conjunto de:
• Envolvimento de todos na produção do plano. • scripts de processos;
• Negociação do plano entre o time e a gerência. • formulários;
• Revisão e aceite final pela gerência. • métodos;
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 98

• métricas. Em cada ciclo os desenvolvedores repetem os mesmos passos

Estes elementos guiam os desenvolvedores em: como mostrado na Figura e aumentam o produto construído
• criar equipes eficazes; no ciclo anterior
• estabelecer metas e planos para a equipe; Cada ciclo de desenvolvimento do TSP é composto por oito
• acompanhar e reportar o trabalho. fases, mas este número pode variar dependendo da necessidade
da equipe. Estas fases são lançamento, desenvolvimento de
Desenvolvimento em ciclos estratégia, planejamento, requisitos, projeto, implementação,
testes e avaliação.
Além disso, a metodologia TSP conduz o desenvolvimento
de software através de vários ciclos rápidos até atingir o produto Estratégia
final. Cada ciclo guia a equipe através de sete passos:
• lançamento; Busca-se estratégia para realizar os trabalhos durante o
• estratégia; ciclo. Cria-se um modelo conceitual, estimativas de tamanho
• planejamento; e tempo de desenvolvimento do produto.
• requisitos; Se o tempo ultrapassar o que foi previsto para o ciclo, a
• projeto; estratégia deverá ser revista e um novo módulo funcional do
• implementação; produto deverá ser definido para ser desenvolvido durante o
• teste; ciclo.
• pós-projeto. A fase de estratégia é realizada antes que o planejamento,

pois nesta fase serão gerados artefatos que serão úteis na fase
de planejamento. Nesta fase, a equipe começa a produzir o
plano de gerência de configuração. Este plano é fundamental
para o controle da versão do produto.
Planejamento
É necessário um plano detalhado, com ele sabe-se com
exatidão o que deve ser feito e quando será feito.
Quando não usamos o planejamento, a equipe leva muito
tempo para desenvolver o projeto. O planejamento é uma fase
que requer tempo e paciência.
Entretanto, como o TSP utiliza-se da estratégia de de-
senvolvimento cíclico e são desenvolvidas pequenas versões,
os planos são simples.
Um dos problemas do cumprimento de tarefas é o traba-
lho não balanceado. Em uma equipe sincronizada, todos os
membros terminam suas tarefas em uma ordem correta e no
mesmo tempo. No TSP, a equipe desenvolve o planejamento,
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 99
distribuindo as tarefas de forma balanceada. Este balancea-
mento sempre é verificado nas fases de avaliação dos ciclos
de desenvolvimento. Na fase de estratégia, gerou-se o modelo
conceitual do projeto.
Requisitos
Na fase de requisitos, desenvolvemos a especificação de
requisitos do software. Este artefato prevê exatamente o que
o produto será. Através dele, faremos a avaliação final do
produto e constataremos se o produto final é realmente o que
o cliente desejava.
Entre os tipos principais de requisitos estão:
• Requisitos funcionais: entradas, saídas, cálculos e casos
de uso.
• Requisitos de Interface Externa: usuário, hardware, sof-
tware, comunicações.
• Restrições de Projeto: formato de arquivos, linguagens,
padrões, compatibilidade e etc.

• Requisitos Não-Funcionais: segurança, conversão, ras-
treabilidade, usabilidade e etc.
• Outros requisitos: banco de dados, instalação etc. No
TSP, o objetivo principal do documento de requisitos é
documentar os acordos da equipe em relação às funcio-
nalidades e interfaces externas.
Projeto
O projeto trata-se de uma fase onde a equipe irá decidir
como construir o produto. Não somente descrever ideias gerais,
mas produzir uma especificação completa e precisa de como o
produto será construído.
No TSP, a construção do projeto consiste dos seguintes
passos:
• Decidir a estrutura do produto como um todo.
• A locar as funcionalidades do produto em componentes. • padrões de codificação.
Produzir a especificação externa dos componentes e.
• Decidir quais os componentes e as funcionalidades que
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 100
serão desenvolvidas em cada ciclo.
Implementação
A fase de implementação é a geração do código fonte do
produto. Esta implementação deve seguir o que foi proposto
na fase de projeto.
Os principais passos na fase de implementação são: pla-
nejamento de implementação, projeto detalhado, inspeção do
projeto detalhado, codificação, inspeção de código, unidade de
testes, revisão da qualidade dos componentes e lançamento dos
componentes. Uma das características da fase de implementação
no TSP é a utilização de padrões.
Os padrões de implementação utilizados são:
• padrões de revisão.
• padrões de nomeação, interface e mensagens.
• padrões de tamanho.
• padrões de defeitos.

• prevenção de defeitos.
Integração e Testes
Os módulos desenvolvidos no ciclo são testados e integra-
dos para formar o produto final. O objetivo é verificar se tais
módulos produzirão um produto de qualidade.
As principais atividades de testes no TSP são:
• Utilizar as partes desenvolvidas e testadas para construir
o produto final.
• Utilizar a integração e testes no produto, para verificar
se este está apropriadamente construído, que todos os
módulos estão presentes e que funcionam perfeitamente
juntos.
• Testar o produto para avaliar se ele atende aos requisitos.
Durante estas atividades, também é desejado:
* Identificar módulos com baixa qualidade e enviá-los
para o gerente de qualidade/processo para revisão
e correção.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 101
* Identificar módulos que já foram enviados para o
gerente de qualidade/processo, que ainda possuem
baixa qualidade e reenvia-los novamente para ve-
rificação e correção.
Revisão
A revisão é a fase final do TSP. Nela todo o trabalho da
equipe é revisto para garantir que tudo o que foi planejado foi
realmente cumprido. Também é verificado se todos os dados
foram registrados pelos membros da equipe. Analisamos o
que foi desenvolvido no ciclo e quais são as melhorias para o
próximo ciclo ou para o próximo produto.
Através da análise, definimos melhorias tanto no processo
de desenvolvimento quanto no processo gerencial da equipe.
Com este trabalho conseguiremos prover um método para
avaliar todo o processo de desenvolvimento e implementar
melhorias.

Síntese
Neste capítulo, vimos que existem diversos modelos e nor-
mas que orientam tanto a avaliação de um produto de software
pronto, quanto nos auxiliam a criar processos e metodologias
para a construção e alteração de produtos de software.
Vimos no total 6 normas ou modelos. É importante termos
em mente que esta lista não é exaustiva e está em constante
mudança, pois a todo momento, novos aperfeiçoamentos e
versões das normas são lançadas. A seguir, listo o essencial de
cada item visto.
A ISO 9126 é utilizada quando precisamos avaliar pro-
dutos de software prontos ou auditar as especificações de um
software durante o seu desenvolvimento. Isso é feito através
de descrição de características e atributos de software e sua
consequente comparação com padrões pré-estabelecidos.
Já a ISO/IEC 12207, nos apoia na difícil missão de es-
tabelecer uma estrutura comum para os processos de ciclo de
vida de software, com terminologia bem definida, que pode
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 102
ser referenciada pela indústria de software, sendo normalmente
aplicada tanto à aquisição de sistemas prontos ou de desenvol-
vimentos de novos sistemas.
Enquanto a ISO/IEC 15504 não é mais focada exclusi-
vamente em software, temos uma variante desta norma deno-
minada SPICE que cobre especificamente a área de software.
Estas duas normas complementares podem ser aplicadas prio-
ritariamente em:
• Melhoria Contínua: avaliação que identifica oportuni-
dades de melhoria feita por organizações que buscam
melhorias internas
• Determinação da Capacidade: avaliação que identifica
riscos com o fornecedor. Feita por terceiros ao realizarem
contratos de prestação de serviços ou fornecimento de
produtos.
Vimos também, brevemente a norma Square: ISO/IEC
25000 que é a sigla para Software product Quality Require-
ments and Evaluation e constitui a evolução e reorganização
das séries de normas 9216 e 14598. Mesmo que possuindo
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 103

algumas diferenças com as normas, podemos aplicar esta nova São metodologias baseadas em níveis e formulários padrões,
norma em todos os pontos onde aplicávamos as normas 9216 sendo muito úteis como complemento às demais normas ISO
e a 14598. e às metodologias CMMI e MPS.BR.
Após estudarmos as principais normas ISO, vimos alguns
modelos de referência, sendo que o primeiro deles foi o CMMI.
Este é um modelo de referência que define uma estrutura de
práticas necessárias para desenvolvimento e avaliação da ma-
turidade de software. Importante que este modelo não define
o “COMO” e sim “O QUE” deve ser feito.
O MPS.BR é a versão brasileira do CMMI, possuindo
diversas similaridades e como principal diferença, a questão
dos níveis iniciais possuírem uma maior subdivisão, fazendo
a implementação do modelo, focando principalmente em em-
presas de pequeno e médio portes.
Por fim, vimos dois processos baseados na produtividade
da equipe de desenvolvimento de software. Estes dois processos
são o PSP (focado na produtividade pessoal) e o TSP (focado na
produtividade de times de desenvolvimento). Aqui é dito como
devemos executar cada etapa da codificação e testes unitários.
Exercícios BR. Eles são complementares, concorrentes ou indiferentes?
Justifique, dando exemplos práticos de processos.
1. Monte um quadro resumo com um comparativo entre PSP,
TSP e CMMI.

2. O SEI provê um método para avaliação de capacidade de

processos, chamado SCAMPI (Standard CMMI Appraisal Method
for Process Improvement). O método, assim como as demais
metodologias produzidas pelo SEI, encontra-se documentado
e pode ser obtido gratuitamente no site do SEI. Obtenha a
documentação do SCAMPI e compare-a com a norma ISO/IEC
15504. Utilize também artigos da internet.

3. Crie um formulário padrão de plano de projeto para o PSP:

4. Revise o modelo CMMI, e responda o que é necessário para

que uma empresa seja certificada no nível 4 da mesma.

5. Reflita entre as normas ISO e os modelos CMMI e MPS.

 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 105

TESTE DE
SOFTWARE
Quem imagina que os testes são feitos
somente ao final do processo terá uma grata
surpresa. Duvidam? Então venham comigo!!!
Teste de Software? O que é isso? Se consultarmos o glos-
sário da ISTQB - Associação Internacional de Testes de
Software (em http://www.istqb.org/component/jdownloads/
send/20-istqb-glossary/186-glossary-all-terms.html) encontra-
remos a seguinte definição: “O processo que consiste em todas
as atividades do ciclo de vida, tanto estáticas quanto dinâmicas,
preocupado com a preparação, planejamento e avaliação de
produtos de software e produtos de trabalho relacionados para
determinar que eles atendem os requisitos especificados, para
demonstrar que eles cumprem sua finalidade e para detectar
defeitos.”

Neste capítulo, teremos uma introdução a este vasto mundo
que é o teste de software. Perceberemos que ele é muito mais
do que testar o software, sendo composto de muitas técnicas
científicas e métodos estruturados.
Fundamentos de Teste
Histórico
“No princípio havia o caos” (durante as décadas de 60, 70
e 80).
Nesta época, iríamos realizar os testes somente no fim do
ciclo de desenvolvimento. Como programadores nós mesmos
iríamos executar os testes dos programas que desenvolvemos.
O nosso foco era provar que o desenvolvimento estava 100%
e o nosso querido programa funcionava!!! Que ironia não???
Por que testar?
Pode nos parecer um tanto óbvio que devemos testar o
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 106
software, mas nem sempre estamos cientes de todas as razões
para fazê-lo.
Então para refrescar a nossa memória, listo algumas razões:
• Para assegurar que as necessidades dos usuários estejam
sendo atendidas.
• Porque é provável que o software possua defeitos.
• Porque falhas podem custar muito caro.
• Para avaliar a qualidade do software.
• Desenvolvedor já alocado em outro projeto teria que
corrigir muitos defeitos de projetos anteriores já em pro-
dução.
Conceito de Erros, Defeitos e Falhas
Conceitos que nos parecem iguais, mas olhando mais de perto....
são bem diferentes!!!
Erro: Ação humana que produz um resultado incorreto.
Defeito: Defeito é uma imperfeição de um produto. O
defeito faz parte do produto e, enquanto usarmos este termo,

devemos fazer referência a algo que está implementado no
código de maneira incorreta. A palavra “defeito” não significa
apenas um problema que faz um programa não funcionar. Um
programa defeituoso é também um programa “que não funciona
como deve” (não faz algo que deveria fazer ou faz algo que não
deveria ser feito).
Falha: é o resultado errado provocado por um defeito ou
condição inesperada.
Os defeitos podem existir, mas nem sempre ser visíveis.
Falhas também podem ocorrer por fatores externos ao progra-
ma, como corrupção de bases de dados ou invasões de memória
por outros programas.
... que pode
... que cria um causar uma
Uma pessoa co-
defeito no sof- falha na opera-
mete um erro...
tware ... ção.
Agora falando em história, em 1979, Glenford Myers
publicou o livro “The Art of Software Testing” onde corri-
giu-se o maior defeito na orientação de testes, que era o foco
em provar que o sistema funcionava... o que eles disseram foi:
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 107
“Testar é procurar defeitos e não provar que o software está
funcionando.”
Muito bem!! Sabemos agora que testar é encontrar erros.
Agora, como fazemos isso? Por tentativa e erro? Vamos testando
conforme nossa experiência ou vontade? De forma alguma...
Em 1988, David Gelperin e Bill Hetzel publicaram o artigo
“The Growth of Software Testing”. Desde essa época temos
o conceito de Plano de Testes, que deveria ser escrito a partir
dos requisitos do sistema. Sem dúvida, isso nos dá um bom
ponto de partida!!!
Princípios do Teste de Software
Princípio 1 – Teste demonstra a presença de defeitos.
Testes conseguem identificar a existência de defeitos, mas
não podem garantir a ausência deles. Mesmo se nenhum de-
feito for identificado em uma bateria de testes, não podemos
afirmar que o software está livre de defeitos. Alguns chegam
a aparecer tardiamente, quando o software já foi entregue e já

passou o período de garantia. Isso pode ocorrer, por exemplo,
pelo uso sazonal de uma funcionalidade (por exemplo, no início
do ano o índice de pagamentos de IPTU é mais alto do que no
resto do ano). Outros defeitos podem inclusive jamais serem
descobertos. Mas não se iluda. Eles podem estar lá.
Princípio 2 – Teste exaustivo é impossível.
A menos que a aplicação sendo testada tenha uma estru-
tura lógica muito simples e valores de entrada limitados, teste
exaustivo é inviável pois seria extremamente custoso cobrir
todos os cenários possíveis. Deve-se calcular o esforço dos
testes baseando-se nos riscos e prioridades.
Princípio 3 – Teste antecipado.
Ao desenvolver um software, as atividades de teste devem
começar o quanto antes. Assim que os requisitos ou modelagem
do sistema estiverem prontos, é possível começar o trabalho
de modelagem do plano de testes. O quanto antes um defeito
for identificado no ciclo de vida de um software, mais barata
e mais simples será a correção.
Princípio 4 – Agrupamento de defeitos.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 108
Um número pequeno de módulos contém a maioria dos
defeitos descobertos durante o teste. A experiência nos mostra
que os bugs são extremamente sociais e gostam de andar em
bando.
Princípio 5 – Paradoxo do Pesticida.
Um conjunto de testes, se executado várias vezes, pode não
mais detectar novos defeitos.
Para contornar esse problema, os casos de teste devem ser
frequentemente revisados e atualizados. Eles devem ser refor-
mulados para abordar novas áreas do sistema e assim aumentar
a chance de detectar novos defeitos.
Princípio 6 – Teste depende do contexto.
Com qual ferramenta você abriria o seu note para trocar o
HD? Um martelo, uma chave de fenda ou um alicate? Qualquer
uma serve? Os testes devem ser elaborados de acordo com o
tipo do software. Você não pode testar um software crítico,
como o lançamento de um foguete com tripulantes, como se
testa um joguinho de celular. Ambos devem ser testados, ambos
têm seus próprios riscos, mas o foco é diferente, a cobertura

será diferente, a abordagem, etc.
Princípio 7 – A ilusão da ausência de erros.
Identificar e corrigir os problemas de um software não
garantem que ele está pronto. Os testes foram elaborados para
identificar todos os possíveis defeitos? O sistema atende as ne-
cessidades e expectativas dos usuários? Ou seja, existem outros
fatores que devem ser considerados para garantir a qualidade
do software.
Processo de Teste
O teste de software é uma das atividades de validação e
verificação e consiste na execução de um produto de forma
controlada para avaliar se ele se comporta ou não conforme o
especificado. O seu principal objetivo é encontrar defeitos
no produto, para que estes possam ser corrigidos pela equipe
de desenvolvimento antes da entrega final.
Devido a esta característica, o teste de software é considera-
do uma atividade de natureza “destrutiva”, e não “construtiva”,
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 109
pois visa o aumento da confiança de um produto através da
exposição de seus problemas.
Os testes podem mostrar que o software tem erros, mas
não que está livre deles. Mesmo que nenhum defeito tenha sido
encontrado durante o teste, não significa que eles não existam.
Em algum momento, um teste ignorado pode descobrir mais
problemas no sistema.
Portanto, o objetivo da equipe é projetar testes que reve-
lem o maior número possível de defeitos com uma quantidade
mínima de tempo e de esforço. É consenso que um bom caso
de teste é aquele que tem alta probabilidade de encontrar um
erro ainda não descoberto.
Um processo de teste de software tem o propósito de estru-
turar as etapas, atividades, artefatos, papéis e responsabilidades
do teste, permitindo organização e controle de todo o ciclo de
teste, minimizando os riscos e agregando valor ao software.
Este processo deve ser estruturado de forma que ele e o
processo de desenvolvimento possam ser executados em para-
lelo, desde o início do ciclo de vida do software.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 110

As principais etapas do ciclo de vida do processo de teste de seus resultados.

são apresentadas abaixo: Entregar: avaliação final dos resultados dos testes para
Planejar: esta etapa trata da definição das atividades de verificar se o sistema está apto para a entrega.

ENTREGAR PLANEJAR Verificação e Validação (V&V)

Consistem em técnicas fundamentais para identificar se um

software possui defeitos e está de acordo com o especificado.
O processo de V&V engloba todo o ciclo de vida do sof-

PROJETAR tware e deve ser aplicado em cada estágio no processo de de-

EXECUTAR
senvolvimento.
Tem dois objetivos principais:
teste, das estimativas de esforço e dos recursos necessários
• Descobrir defeitos em um sistema.
para realizá-las, dos objetivos, estratégias e técnicas de teste
• Avaliar se o sistema é útil e usável ou não em uma situ-
a serem adotadas e dos critérios para determinar quando uma
ação operacional.
atividade de teste está completa.
Verificação e validação devem estabelecer confiança de
Projetar: consiste na elaboração dos casos, scripts e pro-
que o software é adequado ao seu propósito. Não podemos nos
cedimentos de teste, bem como, na preparação do ambiente e
iludir que isto signifique um software completamente livre de
da massa de teste.
defeitos.
Executar: consiste na execução dos casos de teste e registro

Ao invés disso, devemos garantir que o software seja bom
o suficiente para seu uso pretendido.
Uma orientação a vocês!! O tipo de uso do nosso softwa-
re determinará o grau de confiança necessário. Quanto mais
crítico o software for, maior a confiança necessária.
Conceito de Verificação e Validação
Verificação: Estamos construindo o produto corretamente?
O software deve estar de acordo com a sua especificação.
Validação: Estamos construindo o produto certo? O sof-
tware deve fazer o que o usuário realmente deseja.
V&V Estática e Dinâmica
Estática: Não envolve a execução propriamente dita do pro-
duto (ou seja, do código). Pode e deve ser aplicada em qualquer
artefato intermediário. Exemplo: revisões técnicas e inspeções.
Dinâmica: Envolve a execução do produto (ou seja, do
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 111
código). Exemplo: testes.
V&V nos Modelos de Qualidade
Veremos a seguir as práticas relacionadas a teste de sof-
tware nos modelos CMMi para desenvolvimento versão 1.3 e
MPS.BR de 2012.
O MPS.BR possui uma escada de níveis mais suave que
a do CMMi. O nível 2 do CMMi foca em atividades geren-
ciais, assim como os níveis F e G do MPS.BR. Com algumas
práticas de gerenciamento, a empresa já pode aplicar o nível
G, enquanto que o nível 2 do CMMi demanda mais esforço.
O nível 3 do CMMi é o mais inchado. O MPS.BR o suaviza
em 3 níveis distintos. Os processos de Verificação e Validação
encontram-se no nível 3 do CMMi e no nível D do MPS.BR.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 112

Níveis de A verificação é um processo incremental, pois começa

Níveis de
Processos Maturidade MPS. desde o início do ciclo com a verificação dos requisitos, con-
Maturidade CMMI
Br.
tinua durante a evolução do produto e é realizada também no
5 – Otimizado (...) A – Em otimização.
produto completo.
B – Gerenciado
4 – Gerenciado (...)
Quantitativamente.
3 – Definido (...) C - Definido. Validação
Verificação e D – Largamente
Validação Definido.
Ao executarmos atividades de validação procuramos aferir
E – Parcialmente
(...) se estamos construindo um produto que está de acordo com o
Definido.
2 - Repetível (...) F – Gerenciado. que o usuário deseja:
G – Parcialmente Estamos construindo o produto certo? Verificação e va-
(...)
Gerenciado.
lidação são similares, mas a validação deve demonstrar que o
Verificação produto, como entregue (ou como será entregue), vai cumprir
a sua finalidade, enquanto que a verificação endereça se o
Ao executarmos atividades de atividades de verificação produto reflete corretamente os requisitos especificados.
procuramos aferir se estamos construindo um produto corre- Em outras palavras, a verificação assegura que “você cons-
tamente, de acordo com as suas especificações: truiu direito” e a validação assegura que “você construiu a coisa
• Estamos construindo certo o produto? certa”.
• O software cumpre com suas especificações?
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 113

Revisões Técnicas • Programação em pares.

A revisão de software é um dos métodos mais eficientes
de encontrar defeitos e, além disso, permite que esses defeitos
sejam encontrados na fase em que foram inseridos, sem que o
problema siga adiante e o custo da sua correção seja cada vez
mais caro.
As revisões devem ser aplicadas nos diversos artefatos ge-
rados ao longo do processo de desenvolvimento do software
(não somente no código). Além disso, devem contar com pelo
menos uma segunda pessoa, diferente do autor do artefato,
para trazer um olhar novo e, assim, encontrar defeitos.
• Revisão por pares.
• Passaround.
Inspeção de Fagan
Michael Fagan desenvolveu um processo de inspeção formal
quando trabalhava na IBM em meados de 1970. Constante-
mente misturamos os termos revisão e inspeção, mas para que
uma revisão seja qualificada como uma inspeção (de Fagan)
é necessário que siga um processo bem definido com papéis
estabelecidos.

Métodos de Revisão Papéis em uma inspeção de Fagan

Vamos abordar os seguintes métodos de revisão: Um time de inspeção consiste de 3 a 8 participantes nos
• Inspeção. seguintes papéis:
• Revisão em Time. • Moderador: lidera a inspeção, agenda as reuniões, re-
• Walkthrough. porta os resultados da inspeção, acompanha a correção
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 114

dos erros apontados e modera a reunião. Deve ser uma qualidade que vão atentar para os padrões do artefato. Ou
pessoa treinada no processo de inspeção e em como ge- ainda, clientes podem ser convidados para inspecionar
renciar conflitos. definições de requisitos.
• Autor: é o criador do artefato, ou o responsável por ele.
Ele pode responder perguntas sobre o artefato durante Processo da Inspeção de Fagan
a inspeção e pode também revisar o produto apontando
PLANEJAMENTO OVERVIEW PREPARAÇÃO REUNIÃO CORREÇÕES ACOMPANHAMENTO
erros. O autor não pode ser moderador, leitor ou escritor.
• Leitor: descreve as seções do artefato enquanto a reunião
No planejamento, o moderador seleciona o time de inspe-
é conduzida.
ção, pega com o autor o material que será revisado e distribui
• Escritor: classifica e registra os defeitos levantados du-
ele e outros documentos relevantes para o time de inspeção.
rante a inspeção. Em times pequenos o moderador pode
Os materiais devem ser entregues com antecedência para que
fazer esse papel também.
seja possível preparar-se para a reunião. A responsabilidade de
• Inspetor: inspecionam o artefato em busca de defeitos.
chamar uma inspeção é do autor, mas o moderador deve avaliar
Todos os envolvidos na inspeção fazem esse papel. É
se os critérios de entrada foram atingidos. Por exemplo, para a
interessante convidar para esse papel o autor do artefato
inspeção de um código ele deve estar minimamente compilando.
base para o artefato que está sendo inspecionado. Por
A reunião de overview é uma oportunidade que o autor tem
exemplo, convidar o analista de requisitos para verificar
de descrever o seu artefato para o time de inspeção. Não é uma
a arquitetura, ou o arquiteto para uma inspeção de có-
atividade obrigatória no processo uma vez que os participantes
digo. Também é recomendado que tenham pessoas de
podem conhecer bem o artefato.

Os participantes devem então se preparar para a inspeção
avaliando individualmente o artefato, anotando os defeitos e
dúvidas. Caso haja algum Checklist de defeitos comumente
encontrados nesse tipo de artefato, ele deve ser utilizado para
ajudar a verificar os erros.
A reunião de inspeção ocorre em data e local agendados pelo
moderador. Ela é conduzida em conjunto pelo moderador e o
leitor. A reunião não deve durar mais que 2 horas. Caso passe
disso, deve ser agendada outra reunião para continuação. No
fim da reunião, o grupo deve decidir se aceita o produto como
está, se o aceita com pequenas modificações, se são necessárias
grandes mudanças e uma nova reunião de inspeção deve ser
realizada ou se o produto deve ser refeito.
Durante a reunião podem ser identificadas as causas dos
defeitos encontrados. Essa análise retroalimenta o processo
promovendo melhorias que podem evitar a inserção de outros
defeitos futuramente, mas esse não deve ser o foco da reunião.
As causas podem também ser apontadas pelo autor durante o
processo de correção.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 115
Encerrada a reunião, o autor é responsável por resolver os
defeitos levantados durante a pauta. Talvez nem todos os de-
feitos sejam corrigidos, mas essa decisão deve ser comunicada
e aprovada.
O moderador então faz um acompanhamento com o autor
para verificar se as correções foram feitas. Caso haja muitas
mudanças e o artefato tenha sido consideravelmente modifi-
cado, uma inspeção adicional pode ser necessária.
Parece bastante trabalho, mas as inspeções formais de
Fagan tem se mostrado de grande valia na detecção defeitos.
Há outros tipos de revisão menos formais que veremos mais
à frente.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 116

Revisão em Time se há algum comentário que os participantes querem fazer.

PLANEJAMENTO PREPARAÇÃO REUNIÃO CORREÇÃO

Walkthrough
AUTOR INSPETOR

MODERADOR MODERADOR
LEITOR ESCRITOR
Podemos dizer que a revisão em time é uma inspeção re-
alizada de maneira mais informal. Elas devem ser planejadas
e também tem uma estrutura, mas são menos rígidas.
Os participantes recebem o material a ser examinado e o
estudam individualmente e então realizam uma reunião onde
são coletados os esforços e os defeitos.
As atividades de overview e acompanhamento podem ser
omitidas ou simplificadas e alguns papéis podem ser combi-
nados.
O autor pode liderar a reunião, mas ainda assim não pode
ser o moderador. O papel do leitor deixa de existir e ao invés de
passar o artefato pedaço por pedaço, o líder da reunião pergunta
Walkthrough significa passo a passo. É um tipo menos
formal de revisão, um dos poucos em que o autor participa
ativamente. Nele, o autor apresenta o seu produto e os demais
participantes o avaliam.
Não intencionalmente essa apresentação pode ser conduzida
de forma tendenciosa, afinal de contas, o autor provavelmente
não encontrou mais defeitos no seu produto antes de submetê-lo
ao walkthrough, e a forma de conduzir a apresentação pode
esconder alguns defeitos.
Programação em Pares
Programação em pares é uma prática ágil e pode ser con-
siderada uma constante revisão. Dois programadores sentam
juntos (não necessariamente no mesmo computador) e enquanto

um codifica, o outro provê feedbacks e informações sobre o
trabalho que estão realizando.
Essa prática pode gerar alguns tabus de início como o caso
de um gerente pensar que “dois programadores só vão produzir
por um”, ou um programador ter uma resistência dizendo que
faz seu trabalho melhor quando não é interrompido e além
disso, uma histórica relação de posse entre o programador e
o código é quebrada. Ao implementar esse tipo de prática é
preciso avaliar primeiro a cultura organizacional e preparar
todos os recursos envolvidos mostrando como esses e outros
medos são sem fundamento.
Além de promover o conhecimento entre os membros da
equipe, a programação em pares tende a gerar produtos mais
aderentes a padrões, já que os colegas estarão prestando atenção
nesses fatores durante a codificação e quanto antes um defeito
for eliminado, melhor.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 117
Revisão por Pares
Na revisão por pares há apenas uma pessoa revisando o
produto e a revisão depende completamente do conhecimento
dessa pessoa, suas habilidades e disciplina, portanto pode-se
esperar uma grande variação em tempo de preparação e defeitos
encontrados entre as revisões.
Essa revisão pode ser um pouco mais formal e utilizar
Checklist ou métodos de análise e formulários para coletar
os dados da revisão. Ao final da revisão, o revisor entrega ao
autor uma lista de defeitos para correção.
Esse método é mais recomendado para produtos com baixo
risco ou quando há pessoas altamente qualificadas para realizar
esse trabalho. É mais barato e rápido que outros métodos de
revisão, mas fica completamente dependente do ponto de vista
de uma pessoa apenas.

Passaround
Uma revisão Passaround pode ser vista como múltiplas
revisões por pares (Peer Deskcheck). Nela, o autor envia o
artefato para todos os revisores que ele gostaria que provessem
feedback sobre o produto. Os revisores fazem comentários e
enviam de volta para o autor que filtra os apontamentos e re-
aliza as modificações.
Como escolher que método aplicar?
Uma maneira de escolher qual método aplicar a um arte-
fato pode ser o baseado em risco. Quanto maior o risco de um
artefato, mais formal deve ser a revisão.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 118
Documentação no Teste
O processo de modelagem do teste pode ser informar
ou formal. O nível de formalidade depende do contexto do
teste, o que inclui a cultura da organização, a maturidade dos
processos de teste e desenvolvimento, restrições de tempo e as
pessoas envolvidas.
A norma ou padrão IEEE 829 define a documentação
mínima necessária para que o processo de teste de software
funcione adequadamente. São propostos oito documentos e
um padrão de conteúdo para cada um deles. Estes documentos
cobrem as tarefas de planejamento, especificação e relato dos
testes, são aderentes a qualquer processo de teste e podem ser
utilizados nos testes de qualquer tipo de software.
Planos de Teste
Este documento é elaborado a partir da documentação
do projeto e do desenvolvimento do software, apresenta o

planejamento para a execução dos testes e serve de base para
a monitoração e controle do projeto de teste.
Em casos em que o escopo do software a ser testado é
muito grande, pode-se elaborar um plano de teste raiz que irá
apontar para outros planos de teste mais específicos, conforme
a necessidade.
O Plano de teste deve conter os seguintes campos:
• Identificador (código único que identifica o plano de
teste).
• Introdução (visão geral do projeto, objetivos do teste e
metas).
• Itens de teste (listagem dos itens a serem testados ou
usados no teste).
• Funcionalidades a serem testadas.
• Abordagem do teste (tipos de teste, ferramentas, técnicas,
responsáveis, etc.).
• Critérios de liberação dos itens testados (indica se algum
nível de falha pode ser aceito.
• Requisitos de suspensão e retomada (definição dos cri-
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 119
térios).
• Entregas do teste (identificação dos documentos a serem
produzidos no teste, tais como: procedimentos, relatórios,
etc.).
• Tarefas do teste (listagem das atividades necessárias para
preparar e executar os testes, bem como as dependências
entre elas).
• Necessidades de ambiente (ambiente necessário para a
execução dos testes).
• Responsabilidades (identificação dos grupos responsáveis
pelas atividades no projeto de teste).
• Necessidades de equipe e de treinamento.
• Cronograma (listagem das atividades com indicação do
esforço e prazo).
• R iscos (riscos do projeto de testes com os respectivos
planos de mitigação e de contingência).
• Aprovações (nome e espaço para assinatura das pessoas
responsáveis).

Projeto de Teste
Este documento tem como objetivo refinar a abordagem
apresentada no Plano de Teste e identificar as características
e funcionalidades que devem ser testadas e os tipos de teste
que devem ser usados.
Em projetos pequenos, este documento pode ser incorpo-
rado ao Plano de Teste e, em outros casos, pode ser coberto
pelos Casos de Teste e pelos Procedimentos de Teste.
Em projetos extensos, o Plano de Teste pode ser desdobrado
em vários Projetos de Teste para facilitar o seu entendimento
e acompanhamento.
O Projeto de Teste deve conter os seguintes campos:
• Identificador (código único que identifica o projeto de
teste).
• Funcionalidades a serem testadas.
• Abordagem refinada (detalhamento da abordagem apre-
sentada no plano).
• Identificação de teste (identificação dos casos ou proce-
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 120
dimentos de teste).
• Critérios de passagem e de falha para cada funcionalidade
(ou grupo).
Casos de Teste
Segundo Sommerville (2007, p. 356) “Casos de teste são
especificações de entradas para o teste e as saídas esperadas do
sistema mais a declaração do que está sendo testado”.
Lembrar que o padrão IEEE 829 é apenas um guia. Nas
empresas, os casos de teste podem ter mais ou menos infor-
mações do que as aqui apresentadas.
O Caso de Teste deve conter os seguintes campos:
• Identificador (código único que identifica o caso de teste).
• Itens de teste (listagem dos itens de teste ou funciona-
lidades a serem testadas pelo caso de teste).
• Especificações de entrada (entradas necessárias para
executar o teste).
• Especificações de saída (saídas necessárias para verificar

o caso de teste).
• Necessidades de ambiente.
• Requisitos especiais (qualquer procedimento especial
necessário).
• Dependências entre casos de teste.
Procedimento de Teste
Este documento especifica os passos necessários para exe-
cutar um conjunto de casos de teste e deve conter os seguintes
campos:
• Identificador (código único que identifica o procedimento
de teste).
• Propósito (listagem dos casos de teste abrangidos pelo
procedimento e a descrição dos passos necessários para
executar estes casos de teste).
• Requisitos especiais (descrição de qualquer procedimento
especial necessário para a execução do procedimento de
teste).
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 121
• Passos (listagem das atividades relacionadas ao procedi-
mento de teste, tais como: configurações a serem feitas,
ações a serem executadas antes do início do procedimen-
to, ações a serem executadas durante o procedimento,
medições de teste a serem feitas, ações para finalização
dos testes, registro dos resultados da execução do teste,
etc.).
Relatórios de Teste
Existem inúmeros tipos de relatórios de teste e cada empresa
poderá adotar os seus próprios relatórios, desde que os mesmos
contribuam com a melhoria da qualidade. Então a lista abaixo
não é exaustiva e sim uma compilação dos relatórios mais comuns.
Relatório de Passagem de Itens de Teste: O propósito
deste documento é identificar os itens de teste, ou seja, todos os
artefatos entregues para o teste. Ele é fundamental quando as
tarefas de desenvolvimento e de teste do software são realizadas
por equipes diferentes.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 122

Relatório de Log de Teste: Este documento fornece um Modelo Cascata

registro cronológico das ocorrências na execução dos testes. Definição
dos
Requisitos

Relatório de Incidentes de Teste: Também conhecido Projeto do

Sistema

como Relatório de Defeitos, este documento tem como objetivo Implementação

documentar todos os incidentes (defeitos) que ocorreram durante Teste do Sistema

a execução dos testes e que necessitam de alguma análise ou

Manutenção

correção posterior.
Relatório de Sumário de Teste: Este documento tem como
objetivo apresentar, de forma resumida, os resultados das ati-
vidades de teste executadas e prover avaliações baseadas nesses
resultados. É o documento final do processo de teste e apre-
senta, se o que foi acordado no Plano de Teste, foi realmente
realizado ou não.
O Teste nos Ciclos de Vida
Neste modelo de ciclo de vida, os produtos de trabalho
relacionados a cada fase devem ser completamente desenvol-
vidos antes de passarem para a fase seguinte. Os passos são
executados em sequência e todos os requisitos do cliente são
refinados progressivamente até o ponto onde a codificação se
inicia.
O teste é uma fase que só acontece após a implementação
de todo código. Um problema bastante comum que o uso desse
modelo acarreta é o “enforcamento” da fase de testes. Muitas
vezes, a análise se estica um pouco mais, o design começa
atrasado, termina mais tarde e cada fase vai “comendo” um
pedaço da fase subsequente até que o tempo do teste é mínimo

ou mesmo inexistente.
Modelo Iterativo
Este modelo de ciclo de vida divide o desenvolvimento
de um produto de software em ciclos ou iterações. Em cada
ciclo de desenvolvimento podem ser identificadas as fases de
elicitação ou definição dos requisitos, projeto, implementação,
testes e integração.
Essa característica contrasta com a abordagem cascata, na
qual as fases são realizadas uma única vez.
Modelo V
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 123
Este modelo de ciclo de vida define níveis de teste corres-
pondente a cada nível de desenvolvimento do software.
O lado esquerdo do modelo foca as atividades de desen-
volvimento do software.
A parte central do modelo mostra que o planejamento das
atividades de teste deve ser iniciado a partir de cada fase do
desenvolvimento do software.
O lado direito foca as atividades de teste, apresentando
quando elas serão realizadas. Os artefatos produzidos no pro-
cesso de desenvolvimento são a referência para o processo do
teste. Por exemplo, no mesmo momento em que os requisitos
estão sendo refinados em um projeto, o planejamento da acei-
tação já pode ser realizado.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 124

Níveis, Tipos e Técnicas de Teste

Dimensões da Qualidade

Técnica Nível Funcionalidade Confiabilidade Usabilidade Desempenho Suportabilidade

Tipos de Teste (alguns exemplos)

Caixa Teste de
Branca Unidade
Caixa Teste de
Segurança Integridade Carga Configuração
Cinza integração
Teste de
Funcional Regressão Usabilidade
Sistema
Caixa
Preta
Aceitação Volume Maturidade Estresse Instalação

Como Testar Quando Testar O que testar


Níveis de Teste (Quando testar)
Os níveis de teste fornecem a indicação sobre o foco do teste
e os tipos de problemas a serem encontrados, dependendo do
nível em que o teste será realizado. O teste pode ser dividido
em: unitário, de sistema, de integração e, por fim, de aceitação.
O conceito “níveis de teste” está relacionado com o Mode-
lo V, que representa quando as atividades de teste acontecem
em decorrência do ciclo de vida do software. No entanto, este
conceito também pode ser aplicado ao desenvolvimento itera-
tivo. Quando o teste é realizado no momento da codificação
e desenvolvimento do sistema, consideramos o nível de teste
unitário. Já, quando o teste é realizado no momento da inte-
gração de componentes previamente desenvolvidos, estamos
falando do teste de integração.
Após o desenvolvimento do sistema, no momento em que
os analistas de teste validam o produto com base nos requisitos,
podemos considerar que estamos tratando do teste de sistema.
Já no ambiente do cliente, considera-se teste de aceitação
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 125
aquele que é realizado pelo usuário da aplicação ou por tercei-
ros designados, cujo objetivo é de aprovar ou não o software.
Testes Unitários (ou teste de unidade)
Teste realizado em um componente (ou unidade) para ve-
rificar sua corretude e o próprio desenvolvedor que codificou
o componente será o responsável pela execução do teste.
Neste nível não há necessidade de formalismos na execu-
ção do teste, pois no momento da identificação do problema,
o mesmo é corrigido.
Testes de Integração
Teste realizado na interface entre componentes (ou unida-
des) e ocorre em paralelo à atividade de integração do sistema.
Realizado pela equipe de desenvolvimento do software.
Pode haver mais de um nível de teste de integração, a serem
utilizados em objetos de tamanho variado. Exemplos:

• Teste de integração de componente: testa interações
entre componentes de software e é realizado após o teste
unitário.
• Teste de integração de sistemas: testa interações entre
diferentes sistemas e pode ser realizado após o teste de
sistema.
A integração dos módulos deve ser feita de forma incre-
mental. Para o teste, devem ser construídos módulos de apoio,
chamados de drivers e stubs.
Drivers: módulo que chama outro módulo sendo testado,
tendo em seu corpo apenas inicializações de variáveis, chamadas
de rotinas e inicializações de parâmetros.
Stubs: módulo que é chamado pelo módulo sendo testado,
contendo em seu corpo apenas as atribuições de valores que
serão retornados.
Temos duas estratégias de integração:
• Integração Descendente (Top-Down).
• Integração Ascendente (Bottom-Up).
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 126
Integração Descendente (Top-Down)
Os módulos são integrados movimentando-se de cima
para baixo, através da hierarquia de controle, começando pelo
módulo de controle principal (programa principal).
Os módulos subordinados ao módulo de controle principal
são incorporados à estrutura de uma maneira: depth-first (pri-
meiro em profundidade) ou breadth-first (primeiro em largura).
O processo de integração é executado nos seguintes passos:
1. O módulo de controle principal é utilizado como um dri-
ver e todos os componentes diretamente subordinados ao
módulo de controle principal são substituídos por stubs.
2. Dependendo da abordagem de integração selecionada (isto
é, depth-first ou breadth-first), os stubs subordinados são
substituídos, um de cada vez, pelos componentes reais.
3. Os testes são feitos à medida que cada componente é
integrado.
4. Ao fim de cada conjunto de testes, outro stub substitui
o componente real.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 127

5. O teste de regressão pode ser executado para garantir Vantagens

que não tenham sido introduzidos novos erros.
O processo continua a partir do passo 2 até que toda a
estrutura do programa esteja concluída.
Exemplo:
• Permite a verificação antecipada do comportamento de
alto nível.
• Um único driver é necessário.
• Módulos podem ser adicionados, um por vez, em cada
passo, se desejado.

Desvantagens
• Retarda a verificação do componente de baixo nível.
• Stubs são necessários para suprir elementos ainda ine-
xistentes.
• Entradas de casos de teste podem ser difíceis de formular.

Exemplo: Integração Ascendente (Bottom-up)

Depth-first:
M2,M5,M8 Componentes de nível inferior são integrados e testados
Breadth-first: antes que os componentes de nível superior tenham sido de-
M2,M3,M4 senvolvidos.
O processo de integração é executado nos seguintes passos:
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 128

1. Componentes de baixo nível são combinados em agre- Integração Ascendente (Bottom-up)

gados.
2. Para cada combinação é criado um driver que coordena
as entradas e saídas dos casos de teste.
3. O agregado é testado.
4. O driver é substituído pela combinação de módulos cor-
respondentes, que passam a interagir com os módulos
do nível superior.
5. E xemplo:
Vantagens
• Permite a verificação antecipada do comportamento de
baixo nível.
• Stubs nem sempre são necessários.
• Mais fácil para formular dados de entrada para algumas
sub-árvores.
Desvantagens
• Retarda a verificação do componente de alto nível.
• Drivers são necessários para suprir elementos ainda ine-
xistentes.
• Como sub-árvores são combinadas, um grande número
de elementos deve ser integrado de uma só vez.

Testes de Sistema

Teste de sistema se refere ao comportamento de todo o

sistema, ou seja, produto definido pelo escopo de um projeto
ou programa em desenvolvimento. Tem por objetivo verificar
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 129

se o sistema está em conformidade com a especificação de anotando problemas de uso, erros e problemas com
requisitos. relação à percepção do usuário sobre o sistema.
Neste nível, recomenda-se que o teste seja realizado por b. Teste Beta:
uma equipe independente do desenvolvimento (equipe de teste). • Usuário utiliza as suas próprias instalações.
Os testes geralmente são baseados em roteiros de teste criados • O usuário registra todos os problemas encontrados e
a partir da especificação. Neste nível encontramos a maior repassa-os para os responsáveis.
parte dos tipos de teste que veremos a seguir.
Quadro Comparativo entre diferentes tipos de teste
Testes de Aceitação
Testes
Atributos Testes Testes de Testes de
• Testes funcionais, realizados pelo usuário, objetivando de
Unitários Integração Sistema
Aceitação
demonstrar a conformidade com os requisitos do software.
Conjunto de
• Nesse nível é decidido se o software pode ou não ser Sistema Sistema
Escopo Unidades unidades
Todo todo
colocado em produção. agrupadas
• Envolve treinamento e documentação. Analista
Desenvolvedores Analista de de Testes,
• O teste realizado pelo usuário pode ser: Equipe Desenvolvedores e Analistas de Testes e Testadores
a. Teste Alfa: Sistema Testadores e
Usuários
• Usuário utiliza as instalações do desenvolvedor.
Criação
• Os responsáveis acompanham o teste do usuário, Origem Dados
Criação manual Criação manual automática/
dos dados reais
dados reais
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 130

Volume a) teste de performance, teste de usabilidade, teste de porta-

Pequeno Pequeno Grande Grande
dos Dados bilidade etc.
Testes/
Ambientes Desenvolvimento Desenvolvimento Testes
Produção
Esse tipo verifica “como” o sistema opera. A norma ISO
9126 especifica essas características.
Tipos de Teste (O que testar?)

Testes de Estrutura

Testes Funcionais
Teste de estrutura (caixa-branca) verifica a estrutura in-
terna do software.
O Teste Funcional verifica a consistência entre o software
Esses testes são geralmente aplicados nos níveis de compo-
implementado e os seus requisitos funcionais (ou seja, “o que”
nente e integração e deve ser baseado na arquitetura do sistema.
ele deveria fazer).
Pode ser realizado em todos os níveis de teste.
Testes de Recuperação
Está relacionado com o comportamento externo do sof-
tware (caixa preta).
Teste de recuperação é um teste de sistema que força o
software a falhar de diversos modos e verifica se a recuperação
Testes não funcionais
é adequadamente realizada.
Se a recuperação é automática (realizada pelo próprio sis-
O Teste não funcional é executado para medir as caracte-
tema), a reinicialização, os mecanismos de verificação, a recu-
rísticas não funcionais do software. Inclui (mas não se limita

peração dos dados e o reinício são avaliados quanto à correção.
Se a recuperação requer intervenção humana, o tempo médio
para reparo é avaliado para determinar se está dentro de limites
aceitáveis.
Testes de Estresse
Teste de estresse avalia o comportamento do software sob
condições críticas, tais como restrições significativas de memória,
espaço em disco, etc., ou seja, coloca o software sob condições
mínimas de operação.
Teste de Segurança
Teste de segurança verifica se os mecanismos de proteção incor-
porados a um sistema vão de fato protegê-lo de invasão imprópria.
Durante o teste de segurança, o testador desempenha o papel
do indivíduo que deseja invadir o sistema. Vale tudo! O testador
pode tentar obter senhas de funcionários externos; pode atacar o
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 131
sistema com software projetado sob medida para destruir quais-
quer defesas que tenham sido construídas; pode tomar o sistema
negando consequentemente serviço a outros; pode causar erros no
sistema de propósito, esperando invadi-lo durante a recuperação;
pode percorrer dados inseguros, esperando descobrir a chave para
entrada no sistema.
Teste de Desempenho (ou Teste de Performance)
O Teste de desempenho é projetado para verificar se o desem-
penho do software durante a execução está de acordo com seus
requisitos especificados. É fundamental para sistemas de tempo real.
Pressman sugere que muitas vezes o teste de desempenho
pode ser feito combinado com o teste de estresse. Nestas situa-
ções, software e hardware são controlados, a fim de observar seu
comportamento perante às situações nas quais foram colocados,
durante estas fases de teste.

Teste de Configuração (ou Teste de Portabilidade)
Teste de configuração tem como objetivo testar se a aplicação
funciona corretamente em diferentes ambientes de hardware ou
de software (portabilidade).
Testes de Regressão
Teste de regressão é a re-execução do teste após uma modifi-
cação no software com o intuito de verificar se a modificação não
inseriu novos defeitos ou mesmo revelou outros que já estavam lá.
Pode ser realizado em todos os níveis de teste.
Técnicas de Teste (Como testar?)
Testes Caixa-Branca
O Teste caixa-branca, também chamado de teste estrutural
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 132
ou teste da caixa de vidro, avalia o comportamento interno do
componente de software. Essa técnica trabalha diretamente sobre
o código fonte do componente de software para avaliar aspectos
tais como: teste de condição, teste de fluxo de dados, teste de ca-
minhos lógicos, códigos nunca executados.
Principais técnicas:
• Teste de Caminho Básico.
• Teste de Estrutura de Controle.
Estas são técnicas baseadas na estrutura e que comparti-
lham uma característica: baseiam-se no conceito de Grafo de
Fluxo de Controle (GFC).
Usando métodos de teste Caixa-Branca, podemos derivar
casos de teste que:
• Garantam que todos os caminhos independentes de um
módulo sejam executados pelo menos uma vez.
• Exercitem todas as decisões lógicas de seu lado verda-
deiro e falso.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 133

• Executem todos os ciclos (loops) nos seus limites e dentro Notação: As construções estruturadas no grafo de fluxo
de seus intervalos operacionais. formam:
• Exercitem as estruturas de dados internas para assegurar
a sua validade.

Grafo de Fluxo de Controle

Grafo de Fluxo de Controle (GFC) é um grafo dirigido Onde cada círculo representa uma ou mais instruções
(dígrafo), com um único nó de entrada e um único nó de saída. no código fonte!!!
Para sua criação é necessário decompor o programa em blocos
de comando, ligando-os através de arcos. Lógica composta:
Definições:
• Nós: são os círculos e cada um representa um bloco de Uma condição composta ocorre quando um ou mais opera-
comandos. dores booleanos estão presentes em um comando condicional.
• Arestas ou ligações: são as setas e indicam o fluxo de Note que é criado um nó separado para cada uma das condições
controle entre os nós. a e b no comando (nó predicado).
• Caminho: sequência finita de nós (n1, n2, n3, etc.) desde
que haja uma aresta ligando os mesmos.
• Regiões: são as áreas delimitadas por arestas e nós.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 134

SE a E b Exemplo de Fluxograma para Grafo de Fluxo de Controle:

ENTÃO procedimento
x
SENÃO procedimento
y
FIM-SE

SE a OU b
ENTÃO procedimento
x Teste de Caminho Básico
SENÃO procedimento
y O teste de caminho básico permite ao projetista de casos de
teste derivar uma medida quantitativa da complexidade lógica
FIM-SE
de um programa (essa medida é chamada de complexidade
ciclomática):
• Essa medida é usada como guia para definir um conjunto
básico de caminhos de execução.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 135

• Casos de teste criados para exercitar o conjunto básico garantem que:

executam com certeza todas as instruções de um programa • Todo comando do programa terá sido executado pelo
pelo menos uma vez durante o teste. menos uma vez.
• Cada condição terá sido executada no seu lado verdadeiro
Caminhos independentes de programa e no seu lado falso.

Um caminho independente é qualquer caminho através Caminhos independentes de programa:

do programa que introduz pelo menos um novo conjunto de Process(clock,reset,line1,line2)
1. if reset = ‘1’ then
instruções de processamento ou uma nova condição. 2. state := a;
3. output <= ‘0’;
4. overflow <=’0’;
Quando definido em termos de um grafo de fluxo, um ca- 5. elsif clock’event and clock =
‘1’ then
minho independente deve incluir pelo menos uma aresta nova. 6. case state is
7. when a =>
8. if line1 =’1’ and line2 =’1’
Por exemplo, um conjunto de caminhos independentes then
9. state := f;
10. else
para o grafo da figura: 11. state := b;
12. end if;
• Caminho 1: 1 – 11. 13. output <= line1 xor line2;
14. overflow <= ‘0’;
15. when e =>
• Caminho 2: 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11. 16. if line1 =’1’ and line2 =’1’
then
17. state := f;
• Caminho 3: 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11. 18. else
19. state := b;

• Caminho 4: 1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11.
20. end if;
21. output <= line1 xor line2;
22. overflow <=’1’
Os caminhos de 1 a 4 constituem um conjunto base, isto 23. when b =>

é, os testes projetados para forçar a execução desses caminhos

Outro exemplo: Caminho A: Linhas 1- 2-3-4

Este trecho de código ainda apresenta outros caminhos.
Que tal vocês desenharem os grafos correspondentes???
Caminhos:
• B: Linhas 1-5-6-7-8-9-12-13-14.
• C: Linhas 1-5-6-7-8-10-11-12-13-14-15.
• D: Linhas 1-5-6-15-16-17-20-21-22.
• E: Linhas 1-5-6-15-16-18-19-20-21-22.
• F: Linhas 1-5-6-15-23.
Complexidade Ciclomática:
Como sabemos quantos caminhos independentes procurar?
O cálculo da complexidade ciclomática fornece a resposta.
Complexidade ciclomática é uma métrica de software
que fornece uma medida quantitativa da complexidade ló-
gica de um programa. Desta forma, o valor computado para
a complexidade ciclomática define o número de caminhos
independentes no conjunto base de um programa, fornecendo
um limite superior para a quantidade de testes que devem ser
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 136
realizados para garantir que todos os comandos tenham sido
executados pelo menos uma vez.
Cálculo da Complexidade Ciclomática:
Pode ser calculada de três maneiras equivalentes:
1. V(G) = R onde R é o número de regiões do grafo G.
2. V(G) = E – N + 2 onde E é o número de arestas e N é
o número de nós do grafo G.
3. V(G) = P + 1 onde P é o número de nós predicados
contidos no grafo G (só funciona se os nós predicados
tiverem no máximo duas arestas saindo).
Exemplo: Vamos calcular a complexidade cliclomática
para o grafo da figura abaixo:
1) V(G) = R
V(G) = 4, pois o grafo de fluxo tem 4 regiões.
2) V(G) = E – N + 2
V(G) = 11 arestas – 9 nós + 2 = 4
3) V(G) = P+1
V(G) = 3 nós predicado + 1 = 4.

Derivação de Casos de Teste:
Os seguintes passos devem ser seguidos para elaborar casos
de teste a partir do método de teste de caminho básico:
1. Desenhar o grafo de fluxo correspondente ao código-
-fonte.
2. Determinar a complexidade ciclomática do grafo de fluxo
resultante.
3. Determinar um conjunto base de caminhos independen-
tes.
4. Preparar casos de teste que vão forçar a execução de cada
caminho do conjunto base.
Testes Caixa-Preta
O Teste caixa-preta, também chamado de teste funcional
ou teste comportamental, focaliza os requisitos funcionais do
software.
O objetivo é efetuar operações sobre as diversas funcio-
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 137
nalidades e verificar se o resultado gerado está de acordo com
o esperado (pouca preocupação em relação à estrutura lógica
interna do software).
Para este tipo de teste temos como principais técnicas:
• Partição por equivalência.
• Análise do valor limite.
• Grafo de causa e efeito.
• Tabela de decisão.
• Teste de transição de estados.
Testes Caixa-Cinza
Como sabemos, o Teste caixa-Branca tem acesso direto
ao código fonte do programa, validando assim sua estrutura
interna. Porém, no Teste caixa-Preta, não conhecemos sua es-
trutura interna, sabemos apenas quais são as entradas e saídas
esperadas, sem conhecer o que é feito com a entrada.
No Teste caixa-Cinza, também chamado de teste híbri-
do, juntamos estas duas estratégias: conhecimento interno do
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 138

produto e saídas esperadas. Não pode ser confundido com o equivalência (válidas e inválidas).
Teste caixa-Branca, que cobre com testes a estrutura interna 4. Especificar os casos de teste:
do programa. • Eliminar as classes impossíveis ou os casos desinteres-
Importante Turma: Essas são técnicas baseadas na especificação santes.
do produto!!! • Selecionar casos de teste cobrindo as classes válidas das
diferentes variáveis.
Partição por Equivalência • Para cada classe inválida, escolha um caso de teste que
cubra um e somente um de cada vez.
Princípio: Dividir o domínio de entrada em subconjuntos
– classes de equivalência – de maneira que o comportamento Determinação das classes de equivalência:
de um dos membros do conjunto seja representativo do com-
portamento de todos os membros do conjunto.
Definição da variável de Classes de equivalência
entrada
Ideia de completude: Elegendo-se um representante evi-
Intervalo a) Uma classe válida para valores
ta-se a necessidade de testes exaustivos que não irão agregar pertencentes ao intervalo.
conhecimento sobre o comportamento do sistema. b) Uma classe inválida para
valores menores que o limite
1. Decompor o programa em funções. inferior.
2. Identificar as variáveis que determinam o comportamento c) Uma classe inválida para
valores maiores que o limite
de cada função. superior.
3. Particionar os valores de cada variável em classes de
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 139

Lista de valores válidos a) Uma classe válida para os Variável Classes Válidas Classes Inválidas
valores incluídos na lista. C1: 4 <= nro_entradas C3: nro_entradas < 4
b) Uma classe inválida para todos Nro_entradas
<= 6 C4: nro_entradas > 6
os outros valores. C5: valor < 10
a) Uma classe válida para número Valor C2: 10 <= valor <= 99
Número de valores válidos C6: valor > 99
de valores igual ao número
previsto. Determinação dos casos de teste para classes válidas:
b) Uma classe inválida para
número de valores = 0.
c) Uma classe inválida para Para as classes válidas vamos definir, um caso de teste que
número de valores maior ou cubra as entradas válidas. Utilizando a nossa tabela de classes
menor que o valor previsto.
de equivalência teremos 1 caso de teste, ou seja, que cobrirá
Restrições (expressão lógica; a) Uma classe válida para os
sintaxe; valor específico; valores que satisfazem as as C1 e C2.
compatibilidade com outras restrições.
C1 C2 C3 C4 C5 C6
b) Uma classe inválida para os
variáveis) outros valores. n_ro_
entradas X
Exemplo: Considere uma função que aceita como entra- 4..6
das de 4 a 6 valores inteiros de 2 dígitos maiores do que 10. Valor 10..99 X
Identificação das variáveis de entrada e das condições que estas
Classes C1 e C2 - Dados escolhidos:
devem satisfazer: nro_entradas ∈ [ 4, 6 ] valor ∈ [ 10, 99 ]
• Variável nro_entradas = 5.
• Determinação das classes de equivalência:
• Variável valores = 11,12,45,78,95.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 140

Determinação dos casos de teste para classes inválidas: Classe C6 - Dados escolhidos:
Para cada classe inválida, vamos definir um caso de teste »» Variável nro_entradas = 5.
que cubra 1 e somente 1 classe de cada vez. Utilizando a nossa »» Variável valores = 110,45,78,340,95.
tabela de classes de equivalência teremos 4 casos de teste, ou
seja, das classes C3 à C6. Análise do Valor Limite
C1 C2 C3 C4 C5 C6
n_ro_ A análise do valor limite é uma técnica de projeto de casos
entradas de teste que complementa o particionamento por equivalên-
4..6 cia. Em vez de selecionar qualquer elemento de uma classe de
Valor 10..99 equivalência, esta técnica conduz à seleção de elementos que
Classe C3 - Dados escolhidos: estão nas “bordas” da classe para determinar os casos de teste.
»» Variável nro_entradas = 3. Em vez de focalizar somente condições de entrada, também
»» Variável valores = 11,12,45. considera o domínio de saída no projeto dos casos de teste.
Classe C4 - Dados escolhidos: Parte do princípio de que os erros costumam ocorrer perto
»» Variável nro_entradas = 8. dos valores limites das variáveis de entrada. Assume que as
»» Variável valores = 11,12,45,78,95,67,77,54. variáveis de entrada são independentes.
Classe C5 - Dados escolhidos:
»» Variável nro_entradas = 5.
»» Variável valores = 5,11,12,45,6.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 141

Técnica básica: Limitações:

Usam-se os valores próximos dos extremos, mais algum • Testes baseados em partições de equivalência ou análise
valor médio: de valores limites: consideram cada valor de entrada
»» MIN - : Valor ligeiramente abaixo do mínimo possível. isoladamente.
»» MIN: Valor mínimo possível. • E se existirem combinações de valores que constituam
»» MIN+: Valor ligeiramente superior ao mínimo pos- situações interessantes a serem testadas?
sível. Vamos determinar os casos de testes para o exemplo dado
»» NOM: Valor exato da entrada solicitada. na técnica de Partição por Equivalência?
»» MAX-: Valor ligeiramente inferior ao máximo pos- C1 C2 C3 C4 C5 C6
sível. NRO_
entradas 3 4 5 6 7
»» MAX: Valor máximo possível.
4..6
»» MAX+: Valor ligeiramente superior ao máximo pos- Valor 9,10,11,45, 9,10,11,45, 9,10,11,45, 9,10,11,45, 9,10,11,45, 9,10,11,45,
sível. 10..99 98,99,100 98,99,100 98,99,100 98,99,100 98,99,100 98,99,100

Grafo de Causa e Efeito

O grafo de causa e efeito é um método baseado em espe-

cificações de entradas (causas) e saídas (efeitos). Representa a
combinação de entradas em saídas de forma bastante repre-
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 142

sentativa e não redundante. Além disso, aponta ambiguidade à esquerda no grafo.

e incompletude nas especificações. 2. Identificamos os efeitos: são as saídas do programa. Co-
locá-los à direita no grafo.
Definições Iniciais 3. Relacionamos as causas com os efeitos através da notação
a seguir.
• Causa: condições de entrada (valor lógico).
• Efeito: Ações realizadas em resposta às diferentes con- Notação:
dições de entrada.

Exemplo

• Causa: preço >= 50 e 1 <= quantidade <= 99.

• Efeito: forneceremos 5% de desconto.

Passos
Exemplo

1. Identificamos as causas: são as entradas do programa.

Um programa lê dois caracteres e, de acordo com seus va-
Tomar o cuidado de não identificar causas complemen-
lores, mensagens são impressas. O caractere na coluna 1 deve
tares, como por exemplo “x > 60” e “x <= 60”. Colocá-las
ser “A” ou “B”. O caractere na coluna 2 deve ser um dígito. Se
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 143

isto ocorrer, um arquivo é atualizado. Se o primeiro caractere

estiver incorreto, então o sistema deve enviar a mensagem X.
Se o segundo caractere estiver incorreto, então o sistema deve
enviar a mensagem Y.
• Causas identificadas: São as entradas possíveis do pro-
grama:
1. Caractere na coluna 1 é “A”. Tabelas de Decisão
2. Caractere na coluna 1 é “B”.
3. Caractere na coluna 2 é um dígito. Uma tabela de decisão mostra todos os efeitos (ações) que
• Observe que não colocamos, por exemplo, a causa “ca- ocorrem para todas as combinações de causas (condições).
ractere na coluna 2 não é um dígito”, pois esta causa é Podemos construir as tabelas de decisão a partir do grafo
complementar à causa 3, sendo obtida por negação desta. de causa e efeito.
• Efeitos identificados: Obtemos o número de regras a partir da potência de 2
• 70 – Atualiza Arquivo. elevado ao número de causas e geramos um caso de testes para
• 71 – Mensagem X. cada regra (coluna).
• 72 – Mensagem Y.
• Grafo de causa e efeito resultante: Passo a passo para elaboração:

1. Escolher um efeito como ação a ser executada, isto é,

 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 144

marcar um “x” na regra correspondente a este efeito. Efeitos (ações)

2. Rastrear no grafo quais as combinações de causas que 70 –
Atualiza V V V F F F F F
levam a esse efeito e marcar um “V” ou “F” na posição Arquivo
correspondente na tabela. 71 –
3. Para cada combinação criada, verificar se ocorrem ou Mensagem F F F F V F F V
X
não os outros efeitos.
72 –
Vamos elaborar as tabelas de decisão para o exemplo do Mensagem F F F V F V V V
Grafo de Causa e efeito? Olhe abaixo a tabela resultante Y
Ou seja, elaboraremos 8 casos de teste, um para cada combinação
para o efeito 70.
de entradas (regra) para os efeitos possíveis. O resultado do teste de
Regra Regra Regra Regra Regra Regra Regra Regra
1 2 3 4 5 6 7 8 cada regra no programa deverá ser o resultado da regra para os efeitos
Condições apontados pelo grafo de causa e efeito.
Caractere
na coluna Sim Não Sim Sim Não Não Sim Não Teste de Transição de Estados
1 é “A”
Caractere
na coluna Sim Sim Não Sim Não Sim Não Não A técnica de transição de estados é utilizada quando algum as-
1 é “B” pecto da aplicação pode ser representado através de uma máquina de
Caractere
estados finita.
na coluna
Sim Sim Sim Não Sim Não Não Não
2 é um Por exemplo, as tentativas de acesso a uma conta por meio do
dígito caixa eletrônico. Na terceira tentativa incorreta, a senha do usuário

fica bloqueada. Temos então:
• Primeira tentativa OK -> Conta acessada.
• Primeira tentativa NOK -> Segunda tentativa OK -> Conta
acessada.
• Primeira tentativa NOK -> Segunda tentativa NOK -> Terceira
Tentativa OK -> Conta acessada.
• Primeira tentativa NOK -> Segunda tentativa NOK -> Terceira
Tentativa NOK -> Senha Bloqueada.
Síntese
Neste capítulo vimos os principais conceitos relacionados à área
de testes de software. A primeira e principal definição que gostaria
que vocês lembrassem é que “Testar é procurar defeitos e não provar
que o software está funcionando.”
Os testes estão baseados em 3 etapas principais, que são as etapas
de planejamento (definição de todo o projeto do teste, do que precisa-
remos para testar, como testaremos, etc.), Projeto de teste (preparação
para o teste, com definição de casos, procedimentos, scripts, etc.),
Execução propriamente dita (execução do que projetamos) e Entrega
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 145
dos resultados da execução.
Vimos também que existem diversos métodos de revisão. Os
detalhes de cada método foram vistos anteriormente... mas.... é im-
portante guardarmos os nomes dos métodos: Inspeção, Revisão em
Time, Walkthrough, Programação em pares, Revisão por pares e
Passaround.
Sabemos agora que existem diversos documentos importan-
tes que são construídos ao longo do processo de teste. Os principais
documentos são os planos de teste, o projeto de teste, os casos de
teste e os procedimentos de teste. Importantíssimo lembrarmos que
devemos ter uma padronização de cada documento, a fim de evitarmos
que cada pessoa tenha suas interpretações e nos conduza a resultados
indesejados.
A terminologia de testes é bem ampla e foi coberta no decorrer do
capítulo. O importante é guardarmos os principais conceitos que são:
• Níveis de Teste: Definem o momento que o teste será realizado.
• Tipos de Teste: Definem o que será testado especificamente.
• Técnicas de Teste: Definem como testaremos, o passo a passo,
etapas.
Exercícios Agora:

1) Tendo por base o conceito de erro, defeito e falha. Crie um 2) Identifique as causas e os efeitos:
exemplo de cada um, dentro de um mesmo contexto.
Cenário para os exercícios 2, 3, 4 e 5: 3) Elabore o grafo de causa e efeito:

• Supor um sistema bancário que trate somente duas tran- 4) Elabore a tabela de decisão:
sações:
»» Depósito número da conta quantia 5) Elabore os casos de teste:
»» S aque número da conta quantia

• Requisitos do cenário:
»» S e o comando é depósito e o número da conta é válido,
então a quantia é depositada.
»» Se o comando é saque e o número da conta é válido e a
quantia é válida (0 < quantia <= saldo), então a quantia é
sacada.
»» Se o comando ou número da conta ou a quantia for inválido,
então exibir mensagem de erro apropriada.
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 147

AUDITORIA DA
TECNOLOGIA DA
INFORMAÇÃO
Por que auditar? A prática nos mostra
que não adianta termos o melhor
processo, a norma mais completa, se não
acompanharmos o que está havendo...
Durante nossa jornada vimos a definição de qualidade,
seus principais gurus, diversas ferramentas da qualidade, assim
como normas e modelos mundialmente aceitos e chegamos a
ver algumas técnicas para teste.
O destino final desta viagem não poderia ser mais oportuno:
Um estudo sobre a auditoria em Tecnologia da Informação.
Tudo o que vimos pode e deve ser utilizado como insumo para
a auditoria.
Como eu disse a vocês no chamamento deste capítulo, pre-

cisamos auditar se o que planejamos está sendo feito da forma
que foi definida e segundo as normas e padrões da metodologia
de desenvolvimento que estivermos utilizando no projeto.
Fundamentos de auditoria de sistemas de
informações
Qual o objetivo de realizarmos auditorias em sistemas? O
porquê já ficou claro na introdução... Mas quanto ao objeti-
vo... Vamos lá pessoal!!! O principal objetivo da auditoria de
sistemas é verificar se as informações armazenadas em meio
eletrônico atendem aos requisitos de confiança e segurança, se
os controles internos foram implementados e principalmente
se são efetivos.
Importante termos em mente que a auditoria de sistemas
deve atuar em todos os sistemas da organização, seja no nível
operacional, tático ou estratégico.
Para tanto, devemos observar alguns princípios:
• Integridade: Confiança nas transações processadas pelo
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 148
sistema. O sistema garante a consistência das transações.
Os elementos de correção e completude das transações
são evidentes. Os usuários tomam decisões baseadas nas
informações sem receio.
• Confidencialidade: As informações são reveladas somente
às pessoas que necessitam conhecê-las.
• Privacidade: As funções incompatíveis nos sistemas são
segregadas. No processo de autorização os usuários en-
xergam apenas as informações necessárias à execução de
suas tarefas.
• Acuidade: As transações processadas podem ser validadas.
Um módulo de consistência de entrada de dados pode
auxiliar na verificação dos dados fonte, atentando para
sua veracidade. Isso é fundamental para evitar que dados
não qualificados sejam colocados nos sistemas, gerando
transações indevidas ou inválidas.
• Disponibilidade: O sistema precisa estar disponível para
o cumprimento dos objetivos empresariais; Uma vez que
sua falta pode resultar em perda financeira ou gerar pro-

blemas de continuidade do negócio. E também questões
de saúde... lembram-se do caso Ariane ou Therac no
início deste ebook?
• Auditabilidade: Os sistemas devem documentar logs
operacionais que permitam trilhas de auditoria.
• Versatilidade: O sistema deve ser amigável, fácil de se
adaptar ao workf low operacional da empresa, utilizar
recursos de importação e exportação de dados de forma
simples, etc.
• Manutenibilidade: Políticas e procedimentos operacionais
devem contemplar controles quanto a teste, conversão,
implantação e documentação de sistemas novos ou modi-
ficados. Quando da manutenção do sistema os riscos de
contaminação dos ambientes de teste e produção devem
ser eliminados. Não há risco de os sistemas virarem col-
chas de retalhos por falta de uma metodologia apropriada
para a manutenção.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 149
Importância
Não podemos negar a fundamental importância da audi-
toria. Abaixo veremos alguns pontos que por si só já justificam
o investimento e a nossa atenção a este aspecto:
• Altos investimentos das organizações em sistemas com-
putadorizados.
• Necessidade de garantir a segurança dos computadores
e seus sistemas.
• Garantia do alcance da qualidade dos sistemas compu-
tadorizados.
• Auxiliar a organização a avaliar e validar o ciclo admi-
nistrativo.
Tipos de Auditoria
Temos basicamente dois tipos de auditoria:
• Interna: Realizada por funcionários da própria organi-
zação. Em empresas de grande porte, existe um depar-

tamento específico para auditoria interna;
• Externa: Realizada por profissionais devidamente certi-
ficados e totalmente independentes da empresa auditada.
Abordagens
Ao redor do computador
• Trabalha a partir de documentos de E/S.
• Não envolve muita T.I..
• Não se preocupa muito com as funções de processamento;
• Apropriada para pequenas empresas.
Vantagens: Ela não exige muito conhecimento de T.I. e
possui baixo custo.
Desvantagens: Considerada incompleta, com poucos parâ-
metros de auditoria, onde os documentos ficam desatualizados
e as decisões são baseadas em relatórios e documentos podendo
ser distorcidas.
Através do computador
• Além de envolver a confrontação de documentos, alerta
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 150
quanto ao manuseio dos dados, aprovação e registro de
transações comerciais, mas não constrói controles de
programas junto aos sistemas.
• Utiliza técnicas de verificação, pois instiga como os dados
são processados e os resultados intermediários, através
de simulações.
Vantagens: Consegue capacitar melhor o auditor a respeito
de habilidade profissional no que tange ao conhecimento de
processamento eletrônico de dados.
Desvantagens: Necessidade de treinamento de auditores,
aquisição e manutenção de pacotes de software, há risco de
que os programas de testes estejam incorretos ou “viciados” e
ignora as tarefas executadas manualmente.
Com o computador:
• Utiliza o computador para verificar se os cálculos e tran-
sações econômicas e financeiras são feitos corretamente.
• Utiliza cálculos estatísticos e de geração de amostras
que facilitam a confirmação dos dados e a aferição da
integridade dos mesmos.

• Utiliza capacidade de edição e classificação do sistema
computadorizado, a fim de ordenar e selecionar registros;
• Inclui a verificação dos procedimentos computadorizados
e dos procedimentos manuais.
Vantagens: Mais completa.
Desvantagens: É mais cara e mais demorada.
Momentos
• Auditoria durante o desenvolvimento do sistema: Com-
preender e auditar todo o processo de construção do
sistema de informação, da fase de requisitos até a sua
implantação, bem como o próprio processo ou metodo-
logia de desenvolvimento.
• Auditoria de sistemas em produção: Preocupa-se com os
procedimentos e resultados dos sistemas já implantados,
sua segurança, corretude e tolerância a falhas.
• Auditoria no ambiente tecnológico: Compreende a aná-
lise do ambiente de informática em termos de estrutura
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 151
organizacional, contratos, normas técnicas, custos, nível
de utilização de equipamentos e planos de segurança e
de contingência.
• Auditoria em eventos específicos: Compreende a análise
das causas, consequências e ações corretivas cabíveis em
eventos não cobertos pelas auditorias anteriores.
Pontos de Controle da Auditoria
Conceito
São as situações do ambiente computacional que são can-
didatas para escolha para a realização da validação e avaliação
dentro da auditoria e podem ser, entre outras:
• Módulo de um sistema.
• Processo de um sistema.
• Banco de dados.
• Tabela de um banco de dados (arquivo).

• Coluna de uma tabela (campo).
• Linhas na tabela (registros).
Após os testes de validação, se o Ponto de controle apre-
senta fraqueza, então ele passa a ser denominado como Ponto
de auditoria.
Tipos
• Processo: Constituído de rotinas operacionais, rotinas de
controle, etapas do ciclo de desenvolvimento de softwa-
res, etapas de manutenção de sistemas, procedimentos
administrativos, etc. Exemplos:
»» Rotina para cálculo de dígito verificador.
»» Rotina para cálculo de salário líquido.
»» Procedimento de entrada de dados.
»» Procedimentos de conferência de relatórios.
»» Procedimentos de backup.
»» Procedimentos de atualização de versão de software,
etc.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 152
• Resultado: Constituído de documentos, relatórios, ar-
quivos, pontos de integração, estrutura lógica do sistema,
estrutura física do sistema, modelo conceitual de base de
dados, etc. Exemplos:
»» Informações de relatórios de saída.
»» Consistência das informações de bancos de dados.
»» Interface com o usuário.
»» Interface com outros sistemas.
»» Tempo de processamento, etc.
Fraqueza
Uma fraqueza é uma vulnerabilidade, ou seja, um ponto
sujeito a falha. Podemos utilizar este conceito para classificar
os pontos de controle. A escala exata de valores depende do
tipo de negócio e seu grau de tolerância às falhas através das
vulnerabilidades encontradas. Por exemplo: Para uma vulne-
rabilidade em um sistema de saúde podemos ter como muito
forte ( < fraqueza) uma fraqueza com 10% de chances de ocor-
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 153

rer. Já em um sistema de vendas de balcão, uma fraqueza com gência das ações, o enfoque que se deseja, bem como o
50% de chances de ocorrer já poderia ser considerada como quantitativo de sistemas a serem auditados. Recomenda-se
de menor impacto. formar uma equipe de trabalho com dois grupos, sendo
Escalas de fraquezas sugeridas: um de coordenação e outro de execução.
1. Muito Fraco ( > fraqueza). 2. Levantamento do sistema a ser auditado: Uma vez
2. Fraco. delimitado o escopo de trabalho, ou seja, o sistema a ser
3. Regular. auditado, inicia-se o processo de levantamento das infor-
4. Forte. mações relevantes sobre o sistema. A fim de otimizar os
5. Muito forte (< fraqueza). recursos envolvidos, este levantamento deve ser feito de
maneira abrangente, de forma que seja possível o enten-
Organização da Auditoria dimento macro das características do sistema. Podemos
utilizar técnicas de entrevista e análise de documentação
existente, colocando as informações de forma gráfica ou
Etapas da Auditoria descritiva. Ferramentas como diagramas de f luxos de
dados, modelos entidade-relacionamento, dicionário
1. Planejamento e controle do projeto: De acordo com as de dados, casos de uso, diagramas de classe e sequên-
diretrizes da alta administração, estabelece-se o plane- cia, diagramas de integração de sistemas, são poderosos
jamento inicial das ações e recursos necessários para a aliados nesta fase, pois explicam o comportamento do
execução da auditoria. Leva-se em consideração a abran- sistema e seus relacionamentos.

3. Identificação dos Pontos de Controle: Nesta etapa
busca-se identificar os diversos pontos de controle que
merecem ser validados no contexto do sistema escolhido.
A esse processo denominamos inventário de pontos de
controle. Os pontos de controle podem ser encontrados
nos documentos de entrada, relatórios de saída, telas,
arquivos, bancos de dados, pontos de integração e de-
mais elementos relevantes para o sistema. Cada ponto de
controle deve ser relacionado, e seus objetivos descritos
em termos de controle interno, assim como as funções
que eles exercem no sistema como um todo. Devem
ser identificados os seus parâmetros, suas fraquezas e
técnicas de auditoria mais adequadas à sua validação. O
resultado deste levantamento deve ser encaminhado ao
grupo de coordenação para uma validação de pertinência
e eventual triagem.
4. Priorização dos Pontos de Controle: Essa etapa con-
siste na seleção e priorização dos pontos de controle que
foram inventariados na etapa anterior, que devem fazer
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 154
parte do trabalho a ser realizado. A seleção dos pontos
de controle pode ser efetuada com base em:
• Grau de risco existente no ponto: a análise do risco
consiste na verificação dos prejuízos que poderão ser
acarretados pelo sistema a curto, médio e longo prazo;
• Existência de ameaças: podemos auditar primeiramente
os pontos que se encontram sob forte ameaça, e depois,
aqueles sob menos pressão.
• Disponibilidade de recursos: escolha dos pontos que
possam ser auditados com os recursos destinados.
• Esta priorização deverá ser revisada ao longo do trabalho,
para verificar sua pertinência em relação ao desenrolar
das atividades da auditoria.
5. Avaliação dos Pontos de Controle: Esta etapa consiste
em realizar os testes de validação dos pontos de controle,
segundo as especificações e parâmetros determinados
nas etapas anteriores. É a auditoria propriamente dita!
Devemos aplicar técnicas de auditoria que evidenciem
falhas ou fraquezas do controle interno. O emprego de

ferramentas adequadas à verificação em questão pode
ser necessário para atingir o resultado satisfatório. Para
cada objetivo e característica do ponto de controle existe
uma técnica de auditoria e ferramenta mais eficiente.
6. Conclusão da Auditoria: Ao finalizarmos a execução
dos testes de validação dos pontos de controle, devemos
elaborar um relatório de auditoria contendo o resultado
encontrado, qualquer que seja ele. Este relatório deve
conter o diagnóstico da situação atual dos pontos de
controle e, se encontrarmos, as fraquezas do contro-
le interno segundo as especificações determinadas nas
etapas anteriores. O fato de um determinado ponto de
controle apresentar fraqueza transforma-o em Ponto de
auditoria, fazendo-se necessário apontar no relatório de
auditoria recomendações para solução ou mitigação dessa
fraqueza. Cada ponto de auditoria deverá sofrer revisão a
avaliação por parte de analistas e usuários responsáveis.
7. Acompanhamento da Auditoria: O acompanhamento
da auditoria (follow-up) deve ser efetuado até que todas
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 155
as recomendações tenham sido executadas e as fraquezas
tenham sido eliminadas ou atinjam um nível tolerável
pela organização.
Produtos Gerados
É importante termos em mente que podemos gerar muitos
outros produtos a partir da realização de uma auditoria. Abai-
xo, listo os principais artefatos que deverão compor o nosso
portfólio de produtos:
• Relatório de fraquezas de controle interno: Este rela-
tório deverá conter no mínimo as seguintes informações:
»» Nome do ponto auditado.
»» Descrição sucinta do ponto de controle.
»» Problemas detectados.
»» Impacto.
»» Recomendações.
• Certificado de controle interno: Certificado que contém
o grau de fraqueza dos pontos de controle auditados.

• Relatório de redução de custos: Onde apresentaremos
uma estimativa de redução de custos consequentes da
auditoria realizada. Normalmente os empresários gostam
muito deste item em particular...=)
• Manual de auditoria do ambiente auditado: Docu-
mento contendo os pontos de controle do ambiente a ser
auditado e previsão de recursos e prazos para execução
dos trabalhos.
• Pastas contendo a documentação obtida pela auditoria
de sistemas: Todos os documentos obtidos e gerados du-
rante o trabalho de auditoria (relatórios, atas de reunião,
etc) deverão ser arquivados em uma pasta da auditoria.
Padrões e Código de Ética
Padrões
São recomendações sobre o trabalho do auditor de tec-
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 156
nologia da informação fornecidas pelo Comitê de Padrões da
Associação de Controle e Auditoria de Tecnologia de Infor-
mação dos Estados Unidos.
Desta forma temos:
• Responsabilidade, autoridade e prestação de contas:
A responsabilidade, a autoridade e a prestação de contas
sobre a função de auditor devem ser apropriadamente
documentadas numa carta proposta ou de aderência ao
escopo;.
• Independência profissional: O auditor deve ser indepen-
dente da área sob auditoria para permitir uma conclusão
objetiva da auditoria.
• Ética profissional e padrões: O auditor de TI deve aderir
ao código de ética profissional da Associação de Controle
e Auditoria de Tecnologia de Informação, atentando para
o cumprimento do zelo profissional.
• Competência: O auditor de TI, no uso de suas habilida-
des e conhecimentos, deve ser competente tecnicamente
e deve manter essa competência através de educação

continuada.
• Planejamento: O auditor de TI deve planejar suas tarefas
e supervisionar apropriadamente a equipe para assegurar
que os objetivos da auditoria sejam alcançados e que os
padrões profissionais de auditoria sejam respeitados.
• Emissão de relatório: O auditor de TI deve prover um
relatório para os destinatários quando a auditoria esti-
ver concluída. Esse relatório deve conter: identificação
da organização, usuários envolvidos, escopo, objetivos,
período de abrangência, natureza, extensão do trabalho
executado, observações, conclusões, recomendações e
quaisquer ressalvas ou conceitos que o auditor possua a
respeito da auditoria.
• Atividades de Follow-Up: O auditor de TI deve re-
quisitar e avaliar informações apropriadas sobre pontos,
conclusões e recomendações anteriores e relevantes para
determinar se ações apropriadas foram implementadas
em tempo hábil.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 157
Código de Ética
É definido pela Associação de Auditores de Sistemas e
Controles (ISACA) e tem como principal objetivo apoiar a
implementação e encorajar o cumprimento dos padrões suge-
ridos para controles de sistemas de informações.
Podemos observar que o auditor deve:
• Exercer suas funções com objetividade, diligência e zelo
profissional, de acordo com os padrões profissionais e as
melhores práticas. Servir aos interesses dos stakeholders
de forma legal e honesta, atentando para a manutenção
de alto padrão de conduta e caráter profissional, e não
encorajar atos de descrédito à profissão.
• Manter privacidade e confidencialidade das informações
obtidas no decurso de suas funções, exceto quando exigido
legalmente. Tais informações não devem ser utilizadas em
vantagem própria ou entregue a pessoas desautorizadas.
• Manter competência nas respectivas especialidades e
assegurar que somente atua nas atividades que tem ra-

zoável habilidade.
• Informar partes envolvidas sobre os resultados de seus
trabalhos, expondo todos os fatos significativos ocorridos.
• Apoiar a conscientização profissional dos stakeholders
para auxiliar sua compreensão dos sistemas de informa-
ções, segurança e controle.
Ferramentas de apoio à auditoria
Ferramentas Generalistas
Conceito: Softwares, de uso em ambiente batch, que podem
processar, simular, analisar amostras, gerar dados estatísticos,
sumarizar, apontar duplicidade e outras funções que o auditor
desejar.
Exemplos:
• ACL (Audit Command Language): é um software de
extração e análise de dados desenvolvido no Canadá.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 158
• IDEA (Interactiva Data Extraction & Analysis): é um
software para extração e análise de dados também de-
senvolvido no Canadá.
• Audimation: é a versão norte-americana do IDEA, da
Caseware-IDEA, que desenvolve consultoria e dá suporte
para o produto.
• Galileo: software integrado de gestão de auditoria. Inclui
gestão de riscos de auditoria, documentação e emissão
de relatórios para auditoria interna.
• Pentana: software de planejamento estratégico de audi-
toria, com planejamento e monitoramento de recursos,
controle de horas, registro de checklists e programas de
auditoria, inclusive de desenho e gerenciamento de plano
de ação.
Vantagens:
• Pode processar vários arquivos ao mesmo tempo.
• Pode processar vários tipos de arquivos com formatos
diferentes, por exemplo ASCII.
• Poderia também fazer uma integração sistêmica com

vários tipos de softwares e hardwares.
• Reduz a dependência do auditor do especialista de in-
formática para desenvolver aplicativos específicos para
todos os auditores de sistemas de informação.
Desvantagens:
• Como o processamento das aplicações envolve gravação
de dados (arquivos) em separado para serem analisados,
poucas aplicações podem ser feitas em ambiente on-line.
• O software não consegue processar cálculos complexos,
pois como se trata de um sistema generalista, não apro-
funda na lógica e na matemática muito complexas.
Ferramentas Especializadas
São softwares desenvolvidos especificamente para execu-
tarem certas tarefas numa circunstância definida.
Vantagens:
• Pode atender sistemas ou transações não contempladas
por softwares generalistas.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 159
• O auditor, quando consegue desenvolver softwares es-
pecíficos numa área muito complexa, pode utilizar isso
como vantagem competitiva.
Desvantagens:
• Pode ser muito caro, pois terá uso limitado e normalmente
restrito a determinado cliente.
• Atualização pode ser complicada devido à falta de re-
cursos que acompanhem as novas tecnologias.
Utilitários em Geral
São os softwares utilitários para executar funções muito
comuns de processamento, como ordenar um arquivo, conca-
tenar textos, sumarizar, gerar relatórios. Podemos utilizar um
EXCEL, ou recursos de bancos de dados como o SQL, etc.
Vantagem:
• Pode ser utilizado como alternativa na ausência de outros
recursos.
Desvantagem:

• Sempre necessitará do auxílio do funcionário da empresa
auditada para operar a ferramenta (no caso de ferramentas
complexas, como bancos de dados).
Técnicas de Auditoria
Dados de Teste
• Também conhecido como “test data” ou “testdeck”, envol-
ve o uso de um conjunto de dados especialmente projetado
e preparado com o objetivo de testar as funcionalidades
de entrada de dados do sistema. Após o processamento
do arquivo deve-se verificar os resultados obtidos com
os planejados. Esta técnica pressupõe que os dados sejam
abrangentes e verifiquem principalmente os limites de
cada intervalo permitido para as variáveis.
• Quanto mais combinações de transações puderem ser
feitas no arquivo de carga, maior será a cobertura do teste.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 160
• Normalmente aplicada no ambiente batch.
Vantagens:
• Os dados podem ser elaborados por pessoas que possuem
um mínimo conhecimento técnico de informática.
• Existem softwares que auxiliam na geração de dados e
tornam a tarefa bastante simples.
Desvantagens:
• Dificuldade em planejar e antecipar todas as combina-
ções de transações que podem acontecer em ambiente
de negócios das empresas.
Facilidade de Teste Integrado
Também conhecido como Integrated Test Facility (ITF), é
melhor aplicado em ambientes on-line. Os dados de testes são
introduzidos nos ambientes reais de processamento (ambiente
de produção).
O teste envolve a aplicação de entidades fictícias, tais como
funcionários fantasmas na folha de pagamento ou cliente ine-

xistente no contas a receber. Os dados no processamento de
transações reais são confrontados com os dados fictícios.
Vantagens:
• Não acarreta custo adicional ou ambiente de processa-
mento exclusivo, pois funciona no ambiente de produção
das empresas.
Desvantagens:
• Os efeitos das transações precisam ser estornados, dando
trabalhos adicionais e operacionais quando são misturados
com dados reais.
• Existe possibilidade de ser contaminar dados reais com
dados fictícios no ambiente de produção da empresa,
causando grande transtorno para a organização.
Simulação Paralela
Envolve o uso de um programa especialmente desenvolvido
que, comprovadamente, atenda a todas as lógicas necessárias
para o teste, simulando as funcionalidades do programa em
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 161
produção. Faz-se o processamento das transações e/ou dados nos
dois programas e compara-se os resultados. É possível utilizar
a técnica para rotinas que apresentam resultados recorrentes
que são incoerentes.
Vantagens:
• Custos relacionados com a preparação de massa de dados
ou dados fictícios não existem, visto que o programa
opera em ambiente real. Pode-se processar um grande
volume de dados.
Desvantagens:
• Esforço para desenvolver o programa utilizado na técnica.
Lógica de Auditoria Embutida nos Sistemas
Significa incluir a lógica de auditoria nos sistemas na fase
de desenvolvimento. Relatórios de auditoria e logs do sistema
podem ser impressos periodicamente para revisão e acompa-
nhamento dos procedimentos operacionais.

Vantagens:
• Todas as atividades do sistema podem ser monitoradas
permanentemente com simples acesso do auditor.
• Não apresenta restrições quanto à entrada de dados que
podem ser incluídos.
• Um dos métodos mais eficientes e eficazes de fazer au-
ditoria.
Desvantagens:
• Implantação da lógica de auditoria embutida nos sistemas
exige custo adicional no desenvolvimento do sistema, na
utilização dos recursos de máquinas e, até mesmo, perda
de desempenho.
Análise da Lógica de Programação
Consiste, basicamente, na verificação da lógica de progra-
mação para certificar que as instruções dadas ao computador
são as mesmas já identificadas das documentações dos sistemas
aplicativos.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 162
Essa técnica pode ser feita manualmente nos principais
programas do sistema ou nos mais críticos para o negócio.
Rastreamento e Mapeamento
Também conhecida como accontability, consiste em imple-
mentar uma trilha de auditoria para acompanhar os principais
pontos da lógica do processamento das transações críticas, re-
gistrando seu comportamento e resultados para análise futura
(ou seja, é uma listagem da sequência de instruções executadas.
Vantagens:
Ajuda na avaliação dos controles internos que devem ser
seguidos. Pode ser utilizado tanto em ambiente de teste como
no ambiente de produção.
Desvantagens:
Exige que o auditor tenha habilidade avançada de TI para
que possa interpretar as lógicas de programação. Aumenta o
tempo de processamento das transações.

Questionário
Corresponde à elaboração de um conjunto de perguntas
com o objetivo de verificação de determinado ponto de controle
do ambiente computacional. Essas questões buscam verificar
a adequação do ponto de controle aos parâmetros do controle
interno (segurança lógica, segurança física, obediência à legis-
lação, eficácia, eficiência, etc.).
Entrevista
Corresponde à realização de reunião entre o auditor e os
auditados - profissionais e usuários envolvidos com o ambiente
ou o sistema de informação sob auditoria. As questões buscam
verificar a adequação do ponto de controle aos parâmetros do
controle interno (segurança lógica, segurança física, obediência
à legislação, eficácia, eficiência, etc.).
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 163
Análise de Relatórios e Telas
Implica a análise de documentos, relatórios e telas do sis-
tema sob auditoria no tocante a:
• Nível de utilização pelo usuário.
• Esquema de distribuição e número de vias emitido.
• Grau de confiabilidade do seu conteúdo.
• Forma de utilização e integração entre relatórios/telas/
documentos.
• Distribuição das informações segundo o leiaute vigente.
Síntese
Vimos neste capítulo que o principal objetivo da auditoria
de sistemas deve ser verificar se as informações armazenadas
em meio eletrônico atendem aos requisitos de confiança e
segurança, se os controles internos foram implementados e
principalmente se são efetivos.
Em um mundo conectado, com inúmeros sistemas in-

terligados, com investimentos significativos em tecnologia a
auditoria é algo de que não podemos abrir mão.
Temos que gravar os principais princípios de uma auditoria
séria e confiável:
• Integridade, Confidencialidade, Privacidade, Acui-
dade, Disponibilidade, Auditabilidade, Versatilidade
e Manutenibilidade.
A auditoria pode ser desempenhada tanto por recursos
internos ou externos. O tipo mais indicado depende do nível
de auditoria desejado e se existem recursos preparados dentro
da empresa para tal atividade.
Outra questão importante é que a auditoria mais efetiva é
aquela realizada em conjunto com o computador, onde utilizare-
mos efetivamente os recursos para darmos o parecer adequado.
Além disso a auditoria mais efetiva é aquela que ocorre
em todos os momentos, a cada etapa e entre etapas do desen-
volvimento. Desta forma, os desvios são identificados mais
rapidamente e ações corretivas são implementadas de forma
mais efetiva.
QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 164
Uma auditoria bem estruturada segue os seguintes passos
básicos: planejamento e controle do projeto, levantamento do
sistema a ser auditado, identificação dos pontos de controle,
priorização dos pontos de controle, avaliação dos pontos
de controle, conclusão da auditoria e acompanhamento da
auditoria.
A auditoria gera diversos produtos que serão utilizados pelas
empresas para melhorar os seus pontos fracos, norteando assim
as ações preventivas e corretivas. Dentre os principais produ-
tos gerados podemos citar: Relatório de fraquezas de controle
interno, Certificado de controle interno, Relatório de redução
de custos, Manual de auditoria do ambiente auditado e Pastas
contendo a documentação obtida pela Auditoria de Sistemas.
Pessoal!!! A segunda parte deste capítulo, nos trouxe um
ponto extremamente importante que são os padrões e código de
ética para o exercício das atividades de auditoria. A confiança
depositada em nosso trabalho como auditores e o respeito da
profissão são totalmente baseados na credibilidade de nosso tra-
balho. Portanto, vamos respeitar integralmente estes princípios!!!
 QUALIDADE E AUDITORIA DE
TECNOLOGIA DA INFORMAÇÃO 165

• Responsabilidade, Autoridade e Prestação de Contas; Técnicas Ferramentas

• Independência Profissional. Dados de Teste Ferramentas Generalistas
Facilidade de Teste Integrado Ferramentas Especializadas
• Ética Profissional e Padrões (código de ética da associa-
Simulação Paralela Utilitários em Geral
ção de auditores).
Lógica de Auditoria Embutida nos
• Competência. Sistemas
• Planejamento. Análise da Lógica de Programação
• Emissão de relatório. Rastreamento e Mapeamento
• Atividades de Follow-Up. Questionário
Como forma de apoiar a atividade do auditor, facilitando Entrevista
Análise de Relatórios e Telas
assim o nosso trabalho temos uma série de técnicas e ferra-
mentas que podemos utilizar. A lista estudada não é exaustiva,
ou seja, podemos e devemos sempre buscar o aperfeiçoamento
de nossas habilidades para prestar um serviço de qualidade.
Dentre as principais técnicas e ferramentas citamos:
Exercícios
1. A auditoria é uma técnica utilizada para monitorar o estado
de segurança de uma rede. Os logs de sistemas e aplicações
são alvos da auditoria. Baseado nessas informações faça um
breve comentário de como a auditoria pode auxiliar o admi-
nistrador de sistemas na manutenção do estado de segurança
de uma empresa.
2. Tomando como ponto de partida uma das ferramentas de
auditoria citadas, realize a instalação e teste ao menos uma
delas, descrevendo como foi o processo e que teste foi realizado.
Situação para as questões 3,4 e 5:
pessoas que desempenham esta atividade de estoque dentro
de alguma empresa.
3. Sendo assim, elabore um plano de auditoria contemplando
as fases vistas neste capítulo.
4. Agora, faça um questionário para avaliar se a teoria se con-
firma em prática. Que perguntas você faria? Quais os critérios
que selecionaria? Com quem falaria?
5. Por fim, monte um protótipo de apresentação referente ao
resultado da auditoria. Que pontos você destacaria?

Suponha que você está auditando um sistema de controle

de estoques em uma empresa. Essa empresa teoricamente
já possui um sistema confiável, totalmente implantado e as
pessoas teoricamente já foram treinadas e sabem operar
o sistema. Dica: Faça pesquisas na internet e converse com
REFERÊNCIAS
GARVIN, DAVID A., GERENCIANDO A QUALIDADE: A VISÃO ESTRATÉGICA E COMPETITIVA. QUALIMARK 2002.

IMONIANA, JOSHUA ONOME. AUDITORIA DE SISTEMAS DE INFORMAÇÃO. EDITORA ATLAS, 2008 – SÃO

PAULO

KOSCIANSKI, ANDRÉ; SOARES, MICHEL DOS SANTOS. QUALIDADE DE SOFTWARE: APRENDA AS METODOLOGIAS E TÉCNICAS MAIS MODERNAS PARA O
DESENVOLVIMENTO DE SOFTWARE. SÃO PAULO. NOVATEC, 2007.

MELLO, M.S. “MELHORIA DE PROCESSO DE SOFTWARE MULTI-MODELOS BASEADA NOS MODELOS MPS E CMMI-DEV”. DISSERTAÇÃO, COPPE-UFRJ, 2004.

PRESSMAN, ROGER S. ENGENHARIA DE SOFTWARE. 7. ED. SÃO PAULO: MCGRAW-HILL,2011. 780 P.

ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C.. QUALIDADE DE SOFTWARE: TEORIA E PRÁTICA. 1 ED. SÃO PAULO: PRENTICE HALL, 2001.

SHIBA, SHOJI; GRAHAM, ALAN & WALDEN, DAVID. TQM: QUATRO REVOLUÇÕES NA GESTÃO DA QUALIDADE. PORTO ALEGRE, ARTES MÉDICAS, 1997.

SOFTEX. MPS.BR. ACESSO EM 12 DE SETEMBRO DE 2017. DISPONÍVEL EM: http://www.softex.br/mpsbr/

SOMMERVILLE, IAN. ENGENHARIA DE SOFTWARE, 9ª EDIÇÃO. PEARSON EDUCATION, 2011.

TAYLOR, FREDERICK W. SHOP MANAGEMENT. NEW YORK, HARPER & BROTHERS, 1919.

VIRTUARTE, INFORMÁTICA. ACESSO EM 12 DE SETEMBRO DE 2017. DISPONÍVEL EM

WWW.ISDBRASIL.COM.BR/O-QUE-E-CMMI.PHP