You are on page 1of 20

CENTRO UNIVERSITÁRIO DA FUNDAÇÃO INSTITUTO

DE ENSINO PARA OSASCO
6º SEMESTRE DE ENGENHARIA DE COMPUTAÇÃO – ENGENHARIA DE
SOFTWARE I








QUALIDADE DE SOFTWARE – MÉTODOS E MÉTRICAS

Éderson Ramalho
Guthierry Marques
Princes Johny Farias Figueiredo
Thales Batista Pereira
Victor Luque Zorzete
Professor: Artur Pinto Carneiro
OSASCO
10/2013
Introdução
Nos dias de hoje é difícil pensar em qualquer produto ou serviço que não possua um
método ou forma de medição que busque garantir sua eficiência diante de seu propósito.
Dependendo do setor, o leque de opções de fornecedores é tão grande que, para ser
competitivo é crucial utilizar e melhorar continuamente as formas de gestão da
qualidade. Com o produto software não é diferente. Por exemplo, quando pensamos em
segurança da informação já vem em nossa mente acreditar em uma forma de garantir
que dados particulares de pessoas, empresas e instituições em geral estejam protegidas
confidencialmente quando trafegadas através da rede. Dessa forma, imaginamos o uso
de softwares que garantam essa proteção. Infelizmente, vemos constantemente casos em
que dados particulares são interceptados devido à vulnerabilidade desses sistemas.
David Chappell nos lembra em seu artigo de 2012 “O valor do negócio da qualidade de
software” [Cha12] da falha de segurança da Sony Playstation Network, rede para jogos
online onde, cerca de 70 milhões de pessoas tiveram seus dados roubados por hackers.
E não é só de segurança que vive um software, se voltarmos alguns anos no tempo,
veremos que as principais empresas de desenvolvimento de software perceberam que
quantias exorbitantes em dinheiro eram gastas com softwares que não cumpriam com
suas funcionalidades. A CIO Magazine, importante revista mundial de gestão e
estratégias de negócio em TI, estampou [Lev01] em sua capa da edição de 15 de
Outubro de 2001 que 78 bilhões de dólares eram desperdiçados todos os anos em
softwares com essas características. Já a Informationweek, outra revista do segmento,
publicou [Ric01] em 21 de Maio de 2001 um levantamento realizado pela Standish
Group, empresa de pesquisa de mercado, que afirma que 45% do tempo que sistemas
computacionais ficam inativos são devidos a códigos mal elaborados e custaram cerca
de 100 bilhões de dólares às empresas de TI americanas com manutenção e redução de
produtividade no ano 2000. Em um mundo onde cada vez mais os sistemas
informatizados controlam as coisas ao nosso redor, garantir a qualidade do produto
tornou-se um quesito indispensável.
Uma vez que a tarefa de desenvolvimento de software não é algo repetitivo o que a
torna difícil e de certa forma imprevisível, conforme elucida André Koscianski em seu
livro Qualidade de Software, a garantia de qualidade desse tipo de produto torna-se uma
tarefa árdua. Ao longo do processo de produção de um software, levando em conta
parâmetros que visam uma maior qualidade do produto, percebe-se que os problemas
acontecem em todas as etapas de produção, desde a elaboração do escopo e análise dos
requisitos até a fase de testes e implantação. Dessa forma, considerando também a
exigência de usuários e clientes, criou-se um estímulo para que a comunidade de
software elaborasse modelos de desenvolvimento, métodos e métricas que visassem à
garantia de qualidade do produto. Mas pensando bem, o que seria em essência essa
qualidade de software? Segundo Pressman, “Qualidade de software é a conformidade
de requisitos funcionais e de desempenho que foram explicitamente declarados, a
padrões de desenvolvimento claramente documentados, e a características implícitas
que são esperadas de todo software desenvolvido por profissionais”. Entretanto,
quando pensamos em qualidade de software devemos tomar cuidado em até que ponto
ela deve ser priorizada em um projeto de um sistema computacional [Pre01a]. Certa vez
em uma entrevista [Ven03] publicada na internet, Bertrand Meyer, consultor e
acadêmico da área de computação, disse em outras palavras que se perde ao produzir
um software de baixa qualidade porque não terá clientes para comprá-lo. Além disso,
produzir um software absolutamente perfeito demandaria muito tempo, dinheiro e
esforço técnico e, em consequência, a falência de seus produtores. Tal fenômeno é
considerado o grande dilema da qualidade de software [Pre01b]. Dessa forma, é
necessária uma análise ponderada de diversas características do produto, seu ambiente
de aplicação e os prazos para seu desenvolvimento. Não basta somente considerar a
qualidade do produto final, mas sim de todo o seu processo de criação, fabricação e
testes. Analisar de forma prévia os requisitos, os riscos, o investimento envolvido e os
prazos a serem cumpridos são formas de minimizar futuros transtornos que possam
gerar retrabalhos, atrasos e, em casos extremos, até mesmo inviabilizar o negócio.
Outro ponto a ser considerado é a diferença que um software como produto apresenta
em relação a outros bens de produção. É muito clara toda a abstração envolvida quando
pensamos na produção de software se comparada à produção seriada de uma peça
qualquer, por exemplo. Dessa maneira, determinadas formas de controle de qualidade
são necessárias para atender as características específicas que a produção de software
demanda. Alguns institutos de normatização criam ao longo do tempo e de acordo com
a necessidade do mercado normas e padrões para que empresas possam ter um guia de
desenvolvimento e métrica de qualidade a seguir. Podemos citar entre estes institutos o
IEEE (Institute of Electrical and Electronics Engineers), responsável pela criação do
padrão IEEE730 que define um Plano de Garantia de Qualidade para Software, e
também a ISO (International Organization for Standardization) e o IEC (International
Eletrotechinical Commission) que juntas criaram as normas ISO/IEC 9126 que
especifica modelos e métricas para a qualidade do produto de software e a ISO/IEC
14598 que apresenta formas de avaliação do produto de software. Mais tarde, a ISO e
IEC desenvolveram a norma ISO/IEC 25000, também conhecido por SQuaRE
(Software Product Quality Requirements and Evaluation), com um conteúdo mais
completo que aos poucos vem substituindo as normas ISO/IEC 9126 e ISO/IEC 14598.
As normas ISO e IEC são as normas adotadas no Brasil pela ABNT (Associação
Brasileira de Normas Técnicas) que levam o mesmo nome, porém, com a sigla NBR no
início de todas elas.
O resultado da qualidade de software é fruto de um conjunto de ações que auxiliam uma
equipe de projeto a atingir um alto nível de qualidade no produto final. O intuito desse
artigo é transcorrer sobre os métodos e métricas de qualidade baseados na norma NBR
ISO/IEC 9126 e, a partir dela, traçarmos uma conexão com a norma NBR ISO/IEC
25000, uma vez que esta além de apresentar um conjunto de qualidades necessárias ao
produto, também mostra toda uma forma de garantia e avaliação da qualidade. Esse
modelo pode ser aplicável a todo o tipo de software, sejam programas de computadores
ou dados contidos em firmware.

1. Conceito de Qualidade de Software
O conceito de qualidade é definido como sendo “um conjunto de características de todo
produto e serviço ou relação planejada, praticada e verificada, visando superar as
expectativas de satisfação das pessoas envolvidas” [SEBRAE] ou “a totalidade das
características de uma entidade que lhe confere a capacidade de satisfazer necessidades
explícitas e implícitas do cliente” [ISO8402].
Entende-se por entidade tanto o produto como o serviço. Necessidades explícitas são as
condições e objetivos pelo produto expressos na definição de requisitos, que definem as
condições em que o produto deve ser utilizado, seus objetivos, funções e o desempenho
esperado. Entende-se por necessidades implícitas aquelas que não estão expressas nos
documentos do produtor, mas que são necessárias para o usuário, entre elas as
diferenças entre os usuários, a evolução no tempo, as implicações éticas e questões de
segurança.
Qualidade é um termo associado à definição de conformidade às especificações e à
visão de satisfação do cliente, sendo que prazos, pontualidade de entrega e flexibilidade
também são fatores relevantes para avaliação. Para isso, a ABNT (Associação Brasileira
de Normas Técnicas), junto à ISO (Organização Internacional de Padronização),
promovem a normalização de produtos e serviços, utilizando determinadas normas, para
que a qualidade dos produtos seja melhorada continuamente.
Dessa forma, a ISO estipula alguns procedimentos para que seja feita a verificação
correta dos produtos ou processos:
1. Padronização de Processos;
2. Monitoramento e Aferição de Processos;
3. Rastreabilidade de Processos;
4. Inspeção de Qualidade;
5. Revisão Sistemática dos Processos.
Segundo Mark Lefebvre, diretor de Marketing do Sistema de Software da Rational
Software (EUA), “em uma pesquisa feita no mercado, cerca de 66% dos projetos de
softwares fracassam assim que chegam ao mercado, gerando gastos e riscos
desnecessários para as empresas e fabricantes que os desenvolveu, não só pela marca,
mas coloca acima de tudo, seus lucros e resultados finais. Isso acontece devido à
pressão competitiva para desenvolver estes produtos resulta em ciclos de vida mais
curtos, e a complexidade se une a desafios de manter um padrão único de qualidade”.
Por esse motivo, algumas empresas prestam serviço de consultoria e análise de
softwares e produtos, como por exemplo, a IBM com o “IBM Ensure Quality”, que
promove o software de “Ponta-a-Ponta” e enfatiza o gerenciamento de qualidade ao
longo do seu ciclo de vida.
Explanaremos a seguir um pouco mais sobre as normas ISO, usando a ISO/EIC 9126 e
SQuaRE ISO/EIC 25000 como exemplo.
A norma ISO/EIC 9126, sobre o título geral “Engenharia de software – Qualidade de
software”, que tem como principais métodos:
1º - Modelo de Qualidade
2º - Métricas Externas
3º - Métricas Internas
4º - Métricas de Qualidades em uso
A ISO/EIC 9126 é uma revisão da NBR 13596, que visa à avaliação de produtos de
software, onde foram implantadas algumas melhorias, tais como:
- Inclusões das sub-características em caráter normativo, baseadas, em sua maioria, no
anexo informativo da NBR 13596, que contém as sub-características de qualidade;
- Especificação de um modelo de qualidade;
- Introdução de qualidade em uso;
- Remoção do processo de avaliação (agora especificado na NBR ISO/IEC 14598);
- Coordenação de seu conteúdo com a NBR ISO/IEC 14598-1.



1.1. Modelo de Qualidade
Esta parte da norma ISO/EIC 9126 tem como objetivo a qualidade do software, visando
que seja especificada e avaliada de diferentes formas e pontos de vista, com aquisição,
requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia de qualidade e
auditoria de software.
As metas propostas para que haja uma boa avaliação são as seguintes:
- Validar a completitude de uma definição de requisitos;
- Identificar os requisitos do software;
- Identificar objetivos de projeto do software;
- Identificar objetivos para testes de software;
- Identificar critérios para garantia de qualidade;
- Identificar critérios de aceitação para produtos finais de software.
1.2. Métricas Externas
As métricas externas podem ser usadas para medir a qualidade do produto de software
através da medição de seu comportamento em um sistema do qual ele faça parte.
Métricas externas podem ser usadas apenas durante os estágios de teste do processo de
ciclo de vida ou durante qualquer estágio operacional. Consegue-se isso executando o
software no ambiente de sistema ao qual ele pretende se encaixar.
Segundo a ABNT:
“Qualidade Externa é a totalidade das características do produto de software do ponto
de vista externo. É a qualidade quando o software é executado, o qual é tipicamente
medido e avaliado enquanto está sendo testado num ambiente simulado, com dados
simulados e usando métricas externas. Durante os testes, convém que a maioria dos
defeitos seja descoberta e eliminada. Entretanto, alguns defeitos podem permanecer
após o teste. Como é difícil corrigir a arquitetura do software ou outro aspecto básico
do projeto do software, a base do projeto usualmente permanece inalterada ao longo
do teste”.
1.3. Métricas Internas
As métricas internas podem ser aplicadas a um produto de software não executável,
durante os seus estágios de desenvolvimento. Elas proporcionam ao usuário a
habilidade de medir a qualidade nas fases intermediárias e, assim, predizer a qualidade
final do produto. Isso permite ao usuário detectar falhas e tomar as ações corretivas
durante os estágios iniciais de desenvolvimento.
Segundo a ABNT:
“Qualidade Interna é a totalidade das características do produto de software do ponto
de vista interno. A qualidade interna é medida e avaliada com relação aos requisitos de
qualidade interna. Detalhes da qualidade do produto de software podem ser
melhorados durante a implementação do código, revisão e teste, mas a natureza
fundamental da qualidade do produto de software representada pela qualidade interna
mantém-se inalterada, a menos que seja re-projetada.”
1.4. Métricas de Qualidade em Uso
As métricas de Qualidade em uso se resumem em qual será a reação, duvidas,
aceitabilidade do usuário ao usufruir do software quando pronto. Nesse caso, o
desenvolvedor deve pensar em todo e qualquer problema ou dificuldade que o usuário
pode ter. Para melhor entendimento, o esquema abaixo pode melhorar a interpretação
das etapas deste processo:

Fig.1. Características de qualidade de uso (Fonte: [3]).


• Eficácia: Capacidade que o produto de software possui capaz de permitir que o
usuário atinja metas determinadas com eficácia e completeza, em um contexto de uso
especificado.
• Produtividade: Capacidade que o produto de software possui capaz de permitir que
os usuários utilizem uma quantidade adequada de recursos em relação à eficácia
alcançada em um contexto de uso especificado.
• Segurança: Capacidade que o produto de software possui capaz de oferecer níveis
aceitáveis de risco de danos a pessoas, negócios, software, propriedade ou ao ambiente,
em um contexto de uso especificado.
• Satisfação: Capacidade que o produto de software possui de satisfazer usuários em
um contexto de uso especificado.

Usando como referência o padrão imposto pela ABNT, o relacionamento da qualidade
em uso com as outras características de qualidade depende do usuário:
- O usuário final, para quem qualidade em uso é, principalmente, resultante de
funcionalidade, confiabilidade, usabilidade e eficiência;
- A pessoa que mantém o software, para quem qualidade em uso é resultante de
manutencibilidade;
- A pessoa encarregada de portar o software, para quem qualidade em uso é resultante
de portabilidade.








2. A SquaRE: Norma ISO/ IEC 25000
SquaRE “Software Product Quality Requirements and Evaluation (Requisitos de
qualidade e Avaliação de Produtos de Software).
Ela é uma das normas mais importantes a respeito de caracterização e medição de
qualidade de produto de software, sendo a evolução das séries de normas ISO/IEC 9126
e ISO/IEC 14598.
A tabela abaixo apresenta um comparativo da migração entre as normas ISO/IEC 9126
e ISO/IEC 14598 com a ISO 25000:
ISO/IEC 9126, 14598 ISO25000, SQuaRE
9126: Qualidade do Produto 25000: Divisão de Gestão da Qualidade
1. Métricas de Qualidade 25000: Guia do SQuaRE (NP)
2. Métricas externas 25001: Planejamento e Gestão
3. Métricas internas 25010: Divisão de modelo de qualidade
4. Métricas de qualidade em uso 25010: Modelo de Qualidade (Rev.)
25020: Divisão de Medição Qualidade
Nova Proposta
25020: Guia e modelo de referência para
medição (NP)
Guia para usar 9126 & 14598 25021: Elementos de medição de qualidade
Medidas básicas 25022: Medição de Qualidade interna
Requisitos de qualidade 25023: Medição de Qualidade externa
25024: Medição de Qualidade em uso
14598: Avaliação de Produto 25030: Divisão de requisitos de qualidade
1. Visão Geral 25030: Requisitos de Qualidade (NP)
2. Planejamento e gestão 25040: Divisão de avaliação de qualidade
3. Processo para de desenvolvedores

25040: Guia e modelo de referência para
avaliação
4. Processo para compradores 25041: módulos de avaliação
5. Processo para avaliadores 25041: Processo para desenvolvedores
6. Documentos de módulos de avaliação 25043: Processo para compradores
25044: Processo para avaliadores
Tab.1. Comparativo ISO9126, ISO14598 com ISO25000 (Fonte: [4]).
2.1. A Criação da SquaRE
Criação da SquaRE possibilitou uma melhor organização das normas, pois uniu as das
antigas séries ISO/IEC 9126 e ISO/IEC14598, que eram bastante inter-relacionadas,
mas tinham conflitos. Foi importante a introdução à orientação coordenada quanto à
avaliação e à medição da qualidade de produto de software. A introdução de orientações
para uso prático em forma de exemplos facilitou o entendimento para a utilização da
norma.
Da Origem: ISO/IEC 9126 e 14598
São compostas por 10 documentos, sendo eles:
9126-1 Modelo de qualidade de software
9126-2 Métricas externas
9126-3 Métricas Internas
9126-4 Métricas para qualidade em uso
14598-1 Guia de avaliação – visão geral
14598-2 Planejamento e gerenciamento de avaliações
14598-3 Processo de avaliação para desenvolvedores
14598-4 Processo de avaliação para adquirentes
14598-5 Processo de avaliação para avaliadores
14589-6 Documentação de módulos de avaliação
Na reorganização da Norma ISO/IEC 25000 houve uma divisão do assunto em cinco
tópicos, cada divisão é composta por um conjunto de documentos e trata de um assunto
em particular sendo eles:





Fig.2. Características de qualidade de uso (Fonte: [4]).

A reorganização da Norma ISO/IEC 25000 funciona da seguinte forma:
Gerenciamento: Os documentos desta divisão estão voltados a todos possíveis usuários,
como gerente, programadores, avaliadores, compradores. Aqui são definidos os termos
utilizados em todos os demais documentos e são feitas recomendações e sugestões de
caráter geral sobre como utilizar o SQuaRE. [4]
Modelo de qualidade: É definido um modelo hierárquico de características de qualidade,
descrevendo o que se espera de um produto. São definidos também os conceitos de
qualidade externa, interna e em uso, que permitem orientar diferentes perspectivas de
avaliação. [4]
Requisitos de
qualidade

Medições
Modelo de qualidade
Gerenciamento de qualidade
Avaliação
Medição: Define a padronização matemática das métricas de qualidade internas,
externas e de uso, junto a um modelo de qualidade e também é um guia prático para
implementação do modelo. [4]
Requisitos de qualidade: Abrange as normas destinadas a especificação de requisitos de
qualidade, que podem ser orientados tanto para um produto de software que será
desenvolvido, quanto para um produto final. [4]
Avaliação: Incluem os requisitos, recomendações e diretrizes para a avaliação da
qualidade de um produto de software para clientes e desenvolvedores. [4]
2.2. Modelo de Qualidade

Fig.3. Modelo de Qualidade para Qualidade externa e interna (Fonte: [2]).


Qualidade externa: Considera o produto como uma caixa-preta: nada se conhece sobre
sua arquitetura, sobre o código ou como funciona. A realização de testes de
funcionamento de um produto corresponde a verificar a qualidade externa. [4]
Qualidade interna: é exatamente a arquitetura interna que é levada em conta. A
qualidade da organização do código ou a complexidade algorítmica são exemplos de
critérios que podem indicar, respectivamente, prováveis custos de manutenção e
provável velocidade de execução. [4]
2.3. Tabelas de Métricas
Métricas de processo e de projeto de software são medidas quantitativas que permitem
ao pessoal de software ter ideia da eficácia do processo de software e dos projetos que
são conduzidos usando o processo como arcabouço [PRESSMAN]. Portanto, para
mostrar como certas características podem ser mensuradas, serão apresentadas nesta
seção quatro tabelas com exemplos de métricas aplicáveis a cada uma das características
do modelo de qualidade em uso de produtos de software.
Métricas de Efetividade
Nome da
Métrica
Propósito da
Tarefa
Método
de
Aplicação
Medida e
Fórmula
Interpretação
Tipo de
Escala
Tipo de
Medida
Entrada
Referência
ISO 12207
Público-
Alvo
Efetividade
da Tarefa
Que proporção
da tarefa é
completada
corretamente?
Teste com
usuário
M1 = |1 - ∑Ai|1
A = valor
proporcional
de cada item
perdido ou
incorreto no
resultado da
tarefa.
0 <=M1 <=1

Quanto mais
próximo de 1,
melhor.
- A = ?
Resultado do
roteiro de teste

Monitoramento
do Usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Completude
da Tarefa
Que proporção
das tarefas é
completada?
Teste com
usuário
X = A/B
A = número de
tarefas
completadas
B = Total de
tarefas
completadas
0<=X<=1
Quanto mais
próximo de 1,
melhor.
Taxa
A=quantidade

B=quantidade

X=quantidade/
quantidade
Resultado do
roteiro de teste

Monitoramento
do usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Frequência
de Erro
Qual é a
freqüência de
erros?
Teste com
usuário
X = A/T
A = número de
erros tomados
pelo usuário
T = tempo ou
número de
tarefas
0 <= X
Quanto mais
próximo de 0,
melhor.
Absoluta
A =
quantidade
Resultado do
roteiro de teste

Monitoramento
do usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Tab.2. Métricas Efetividade (Fonte: [1]).

Métricas de Produtividade
Nome da
Métrica
Propósito da
Tarefa
Método
de
Aplicação
Medida e
Fórmula
Interpretação
Tipo de
Escala
Tipo de
Medida
Entrada
Referência
ISO 12207
Público-
Alvo
Tempo de
tarefa
Quanto tempo
demora-se
para
completar
uma tarefa?
Teste com
usuário
X = Ta/Tb
Ta = tempo ocioso
do usuário
Tb = tempo da
tarefa
X>=0
Quanto menor,
melhor
Intervalo T=tempo
Resultado do
roteiro de teste

Monitoramento
do Usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Eficiência da
Tarefa
Quão
eficientes são
os usuários?
Teste com
usuário
X = M1/T
M1=efetividade da
tarefa
T = Tempo da
tarefa
X>=0
Quanto maior,
melhor
-
T=tempo
X =
Resultado do
roteiro de teste

Monitoramento
do usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Custo Efetivo
Qual o custo
efetivo do
usuário?
Teste com
usuário
X = M1/C
M1=efetividade da
tarefa
C = Custo total da
tarefa
X>=0
Quanto maior,
melhor
Absoluta
T=tempo
X =
Resultado do
roteiro de teste

Monitoramento
do usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Proporção
Produtiva
Que
proporção o
tempo o
usuário está
realizando
ações
produtivas?
Teste com
usuário
X = Ta/Tb
Ta = tempo
produtivo = tempo
da tarefa – tempo
de ajuda – tempo
perdido com erro –
tempo de pesquisa
Tb = tempo da
tarefa
0<=X<=1
Quanto mais
próximo de 1,
melhor.
Absoluta
Ta=tempo
Tb=tempo
X=tempo/
tempo
Resultado do
roteiro de teste

Monitoramento
do Usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Grau de
eficiência do
usuário
Quão eficiente
é um usuário
comparado
com um
especialista?
Teste com
usuário
X = A/B
A = eficiência de
um usuário comum
B = eficiência de
um usuário
especializado
0<=X<=1
Quanto mais
próximo de 1,
melhor.
Absoluta X = A/B
Resultado do
roteiro de teste

Monitoramento
do usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Grau de
produtividade
do usuário
Quão
produtivo é
um usuário
comparado
com um
especialista?
Teste com
usuário
X = A/B
A = produtividade
de um usuário
comum
B = produtividade
de um usuário
especializado
0<=X<=1
Quanto mais
próximo de 1,
melhor.
Absoluta X = A/B
Resultado do
roteiro de teste

Monitoramento
do usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas
de
interface
com
usuário
Tab.3. Métricas produtividade (Fonte: [1]).


Métricas de Segurança
Nome da
Métrica
Propósito da
Tarefa
Método de
Aplicação
Medida e
Fórmula
Interpretação
Tipo de
Escala
Tipo de
Medida
Entrada
Referência
ISO 12207
Público-Alvo
Bem-estar
do usuário
Qual a
incidência de
problemas de
saúde entre
os usuários
do produto?
Estatísticas
X = A/B
A=número de
usuários com
LER, fadiga ou
dor de cabeça
B=Total de
usuários
0<=X<=1
Quanto mais
próximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usuário
5.4
Operação
Usuários

Projetistas de
interface com
usuário
Segurança
das pessoas
afetadas
pelo uso do
sistema
Qual o nível
de perigo
incidente às
pessoas
afetadas pelo
uso do
sistema?
Estatísticas
X=A/B
A=número de
pessoas
colocadas em
perigo
B=Total de
pessoas
afetadas pelo
sistema
0<=X<=1
Quanto mais
próximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usuário
5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas de
interface com
usuário

Desenvolvedor
Segurança
dos
pacientes
Qual a
incidência de
perigo para o
paciente que
recebe
tratamento
pelo sistema?
Estatísticas
X=A/B
A=número de
pacientes com
tratamento
prescrito
incorretamente
B=Total de
pacientes
0<=X<=1
Quanto mais
próximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usuário
5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas de
interface com
usuário

Desenvolvedor
Danos
econômicos
Qual a
incidência de
danos
econômicos?
Estatísticas
X=A/B
A=número de
ocorrências de
danos
econômicos
B=Total de
situações
medidas
0<=X<=1
Quanto mais
próximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usuário
5.4Operação
Usuários

Projetistas de
interface com
usuário

Desenvolvedor
Danos do
software
Qual a
incidência de
danos do
software?
Estatísticas
X=A/B
A=número de
ocorrências de
danos no
software
B=Total de
situações
medidas
0<=X<=1
Quanto mais
próximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usuário
5.4Operação
Usuários

Projetistas de
interface com
usuário

Desenvolvedor
Tab.4. Métricas Segurança (Fonte: [1]).
Métricas de Satisfação
Nome da
Métrica
Propósito
da Tarefa
Método de
Aplicação
Medida e
Fórmula
Interpretação
Tipo
de
Escala
Tipo de
Medida
Entrada
Referência
ISO 12207
Público-Alvo
Escala de
Satisfação
Qual o nível
de
Satisfação
do usuário?
Teste com
o usuário
X = A/B
A=questionário
com escala
psicométrica
B=média da
população
X > 0
Quanto maior,
melhor
Taxa
A =
quantidade
X =
quantidade
Resultado do
roteiro de teste

Monitoramento
do Usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas de
interface com
usuário

Desenvolvedor

Pesquisa
de
Satisfação
Qual o nível
de
Satisfação
do usuário
em funções
específicas?
Teste com
o usuário
X = A
A=resultado da
pesquisa
Comparação
com valores
anteriores ou
com a média da
população
Ordinal
A= quantidade
X= quantidade
Resultado do
roteiro de teste

Monitoramento
do Usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas de
interface com
usuário

Desenvolvedor

Uso
discreto
do
produto
Qual a
proporção
dos usuários
potenciais
optou pelo
sistema?
Observação
da
utilização
X = A/B
A = número de
vezes que a
função,
aplicação ou
sistema é usado
B = Número
que o usuário
teve a intenção
de usar
0<=X<=1
Quanto mais
próximo de 1,
melhor.
Taxa
A=quantidade

B=quantidade

X=quantidade/
quantidade
Resultado do
roteiro de teste

Monitoramento
do usuário
6.5Validação

5.3Teste de
qualificação

5.4Operação
Usuários

Projetistas de
interface com
usuário
Tab.5. Métricas Satisfação (Fonte: [1]).




3. Qualidade de Produto e o Ciclo de Vida
As visões de qualidade interna, qualidade externa e qualidade em uso mudam durante o
ciclo de vida do software. Como exemplo, os requisitos de qualidade no início do ciclo
de vida são normalmente vistos do ponto de vista do usuário (externo), e difere da
qualidade do produto intermediário, tal como a qualidade do projeto, que é geralmente
vista do ponto de vista do desenvolvedor (interno). As tecnologias usadas para alcançar
o nível de qualidade necessário, assim como especificações e avaliações de qualidade,
precisam apoiar tanto o ponto de vista dos usuários quanto o dos desenvolvedores. É
necessário definir estas perspectivas e as tecnologias associadas à qualidade para
gerenciar a qualidade em cada estágio do ciclo de vida.
O objetivo é alcançar a qualidade necessária e suficiente para atingir as reais
necessidades dos usuários. A ISO 8402 define qualidade em termos da habilidade de
satisfazer necessidades explícitas e implícitas. Entretanto, as necessidades especificadas
por um usuário nem sempre refletem as suas reais necessidades, pois um usuário
normalmente não está ciente de suas necessidades, necessidades podem mudar após
serem especificadas. Usuários diferentes podem ter ambientes operacionais diferentes, e
pode ser impossível consultar todos os possíveis tipos de usuário. Por causa disso,
requisitos de qualidade não podem ser completamente definidos antes do início do
projeto. Além disso, é preciso entender as necessidades reais dos usuários da forma
mais detalhada possível, e representá-las em requisitos. O objetivo não é,
necessariamente, alcançar a qualidade perfeita, mas sim a qualidade necessária e
suficiente para cada contexto de uso especificado quando o produto é entregue e
realmente utilizado pelos usuários.
Escalas de medidas para as métricas usadas em requisitos de qualidade podem ser
divididas entre as categorias correspondentes para os diferentes graus de satisfação dos
requisitos. Como exemplo, a escala poderia ser dividida em duas categorias: satisfatório
e insatisfatório, ou em quatro categorias: excedeu os requisitos, atingiu requisitos
suficientemente aceitos e inaceitáveis.
Basta apenas que as categorias sejam especificadas de forma que o usuário e o
desenvolvedor possam evitar o excesso de custo e planejamento desnecessário.
A figura abaixo ilustra diferentes visões de qualidade do produto e métricas associadas
em diferentes estágios do ciclo de vida do software.

Fig.4. Qualidade no ciclo de vida do software. (Fonte: [3]).













Conclusão
O produto software, diferentemente de uma peça manufaturada em uma fábrica, é algo
que já demanda certo grau de abstração pela essência do que é.Aplicar métodos e
métricas para garantir a qualidade em uma “peça”, que pela própria natureza abstrata
será única e diferente mesmo se produzida diversas vezes, não é uma tarefa simples e
pode mesmo se tornar um desafio dependendo da importância que se dá a qualidade a
peça. Por exemplo, uma mesma equipe foi contratada para produzir dois softwares
distintos, o primeiro destinado ao controle de uma cortina e o segundo será usado para
operar uma máquina de radioterapia, por intuição sabemos que o primeiro software não
precisa de um controle de qualidade tão rigoroso quanto o segundo, levando se em
consideração que a função do primeiro pode ser resumida ao abrir e fechar de uma
cortina. No entanto a falta de qualidade do segundo pode agravar os problemas de saúde
de alguns pacientes ou até levá-los a morte como mostra o caso real do Therac-25,
máquina criada pela empresa AECL (Atomic Energy of Canada Limited), que entre
junho de 1985 e janeiro de 1987 ocasionou a morte de quatro pacientes e deixou outros
dois com graves problemas devido a doses exageradas de radiação, segundo Nancy G.
Leveson publicou em um estudo sobre o caso [NanCla01], o problema do Therac-25,
apesar de envolver erros por parte do operador, foi causado basicamente pela má
qualidade no software desenvolvido pela empresa.
É fundamental produzir um software que atenda a demanda da melhor forma possível,
não só do ponto de vista do cliente, mas também deve ser viável de ser produzido e
implementado de forma satisfatória, definido o grau de qualidade que o software deve
atingir, usamos as normas e métricas que citamos neste artigo para obtermos tal produto
e termos a garantia que este produto é de qualidade suficiente para cumprir o papel ao
qual foi proposto, ou seja, deve ser um produto útil, como afirma Pressman, “Um
produto útil fornece o conteúdo, as funções e os recursos que o usuário final deseja,
além disso, e não menos importante deve fornecer confiabilidade e isenção de erros. Um
produto útil sempre satisfaz às exigências definidas explicitamente pelos interessados.
Além disso, ele satisfaz a um conjunto de requisitos implícitos (por exemplo, facilidade
de uso) que se espera de todo software de alta qualidade” [Pre01c]. Todo software é
desenvolvido para um determinado fim, atender uma demanda, entretenimento,
educativo e etc. Se ele é útil para todas as partes interessadas em seu desenvolvimento e
atende aos padrões de qualidade propostos, seu software é um produto bem concebido
por um processo satisfatório de engenharia de software.






















Referências Bibliográficas
[Cha01] CHAPPELL, D., The Business Value of Software Quality:
http://davidchappell.com/writing/white_papers/The_Business_Value_of_Software_Qual
ity-v1.0-Chappell.pdf.
[Lev01] LEVINSON, M., “Let’s Stopping wasting $78 billion a year”, CIO Magazine,
15 de Outubro de 2001:
www.cio.com/article/30599/SOFTWARE_DEVELOPMENT_Let_s_Stop_Wasting_78
_Billion_a_Year.
[NanCla01] NANCY G. L., CLARK S. T., “An investigation of the Therac-25
accidents” IEEE Computer, 26(7):18-41, 1993.
[Ric01] RICADELA, A.; “The State of Software Quality”, Information Week, 21 de
Maio de 2001, disponível em: www.informationweek.com/838/quality.htm.
[Ven03] VENNERS, B.; “Design by contract: A conversation with Bertrand Meyer”,
Artima Developer, 08 de Dezembro de 2003: www.artima.com/intv/contracts.html.
KOSCIANSKI, A.; SOARES M. S., Qualidade de Software – Segunda Edição.
Novatec, 2007.
[PRESSMAN] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo
McGraw-Hill, 2011.
[Pre01a] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo
McGraw-Hill, 2011 Cap. 14.3 (O dilema da Qualidade de Software).
[Pre01b] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo
McGraw-Hill, 2011 Cap. 14.3 (O dilema da Qualidade de Software).
[Pre01c] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo
McGraw-Hill, 2011 Cap. 14.2 (O dilema da Qualidade de Software).
IEEE 730-2002, Standard For Software Quality Assurance Plans.
[SEBRAE] SEBRAE. Disponível em <http://www.sebrae.com.br>.
[ISO8402] ISO 8402. Quality Vocabulary, 1994.
[1] ISO/IEC 9126-2, 3: 2002. Software engineering– Software product quality- Part 2:
External Metrics e ISO/IEC 9126-3: 2002. Software engineering– Software product
quality- Part 3: Internal Metrics.
[2] ISO/IEC 9126-1: 2000. Software engineering– Software product quality- Part 1:
Quality model.
[3] ISO/IEC 9126-4: 2000. Software engineering– Software product quality- Part 4:
Quality in use metrics.
[4] ISO/IEC 25000:2004. Software engineering – Software product Quality
Requirements and Evaluation (SQuaRE) – Guide to SQuaRE.