CENTRO UNIVERSITRIO DA FUNDAO INSTITUTO

DE ENSINO PARA OSASCO

6 SEMESTRE DE ENGENHARIA DE COMPUTAO ENGENHARIA DE
SOFTWARE I








QUALIDADE DE SOFTWARE MTODOS E MTRICAS

derson Ramalho
Guthierry Marques
Princes Johny Farias Figueiredo
Thales Batista Pereira
Victor Luque Zorzete
Professor: Artur Pinto Carneiro
OSASCO
10/2013
Introduo
Nos dias de hoje difcil pensar em qualquer produto ou servio que no possua um
mtodo ou forma de medio que busque garantir sua eficincia diante de seu propsito.
Dependendo do setor, o leque de opes de fornecedores to grande que, para ser
competitivo crucial utilizar e melhorar continuamente as formas de gesto da
qualidade. Com o produto software no diferente. Por exemplo, quando pensamos em
segurana da informao j vem em nossa mente acreditar em uma forma de garantir
que dados particulares de pessoas, empresas e instituies em geral estejam protegidas
confidencialmente quando trafegadas atravs da rede. Dessa forma, imaginamos o uso
de softwares que garantam essa proteo. Infelizmente, vemos constantemente casos em
que dados particulares so interceptados devido vulnerabilidade desses sistemas.
David Chappell nos lembra em seu artigo de 2012 O valor do negcio da qualidade de
software [Cha12] da falha de segurana da Sony Playstation Network, rede para jogos
online onde, cerca de 70 milhes de pessoas tiveram seus dados roubados por hackers.
E no s de segurana 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 no cumpriam com
suas funcionalidades. A CIO Magazine, importante revista mundial de gesto e
estratgias de negcio em TI, estampou [Lev01] em sua capa da edio de 15 de
Outubro de 2001 que 78 bilhes de dlares eram desperdiados todos os anos em
softwares com essas caractersticas. 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 so devidos a cdigos mal elaborados e custaram cerca
de 100 bilhes de dlares s empresas de TI americanas com manuteno e reduo 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 indispensvel.
Uma vez que a tarefa de desenvolvimento de software no algo repetitivo o que a
torna difcil e de certa forma imprevisvel, 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 produo de um software, levando em conta
parmetros que visam uma maior qualidade do produto, percebe-se que os problemas
acontecem em todas as etapas de produo, desde a elaborao do escopo e anlise dos
requisitos at a fase de testes e implantao. Dessa forma, considerando tambm a
exigncia de usurios e clientes, criou-se um estmulo para que a comunidade de
software elaborasse modelos de desenvolvimento, mtodos e mtricas que visassem
garantia de qualidade do produto. Mas pensando bem, o que seria em essncia essa
qualidade de software? Segundo Pressman, Qualidade de software a conformidade
de requisitos funcionais e de desempenho que foram explicitamente declarados, a
padres de desenvolvimento claramente documentados, e a caractersticas implcitas
que so 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
acadmico da rea de computao, disse em outras palavras que se perde ao produzir
um software de baixa qualidade porque no ter clientes para compr-lo. Alm disso,
produzir um software absolutamente perfeito demandaria muito tempo, dinheiro e
esforo tcnico e, em consequncia, a falncia de seus produtores. Tal fenmeno
considerado o grande dilema da qualidade de software [Pre01b]. Dessa forma,
necessria uma anlise ponderada de diversas caractersticas do produto, seu ambiente
de aplicao e os prazos para seu desenvolvimento. No basta somente considerar a
qualidade do produto final, mas sim de todo o seu processo de criao, fabricao e
testes. Analisar de forma prvia os requisitos, os riscos, o investimento envolvido e os
prazos a serem cumpridos so formas de minimizar futuros transtornos que possam
gerar retrabalhos, atrasos e, em casos extremos, at mesmo inviabilizar o negcio.
Outro ponto a ser considerado a diferena que um software como produto apresenta
em relao a outros bens de produo. muito clara toda a abstrao envolvida quando
pensamos na produo de software se comparada produo seriada de uma pea
qualquer, por exemplo. Dessa maneira, determinadas formas de controle de qualidade
so necessrias para atender as caractersticas especficas que a produo de software
demanda. Alguns institutos de normatizao criam ao longo do tempo e de acordo com
a necessidade do mercado normas e padres para que empresas possam ter um guia de
desenvolvimento e mtrica de qualidade a seguir. Podemos citar entre estes institutos o
IEEE (Institute of Electrical and Electronics Engineers), responsvel pela criao do
padro IEEE730 que define um Plano de Garantia de Qualidade para Software, e
tambm a ISO (International Organization for Standardization) e o IEC (International
Eletrotechinical Commission) que juntas criaram as normas ISO/IEC 9126 que
especifica modelos e mtricas para a qualidade do produto de software e a ISO/IEC
14598 que apresenta formas de avaliao do produto de software. Mais tarde, a ISO e
IEC desenvolveram a norma ISO/IEC 25000, tambm conhecido por SQuaRE
(Software Product Quality Requirements and Evaluation), com um contedo mais
completo que aos poucos vem substituindo as normas ISO/IEC 9126 e ISO/IEC 14598.
As normas ISO e IEC so as normas adotadas no Brasil pela ABNT (Associao
Brasileira de Normas Tcnicas) que levam o mesmo nome, porm, com a sigla NBR no
incio de todas elas.
O resultado da qualidade de software fruto de um conjunto de aes que auxiliam uma
equipe de projeto a atingir um alto nvel de qualidade no produto final. O intuito desse
artigo transcorrer sobre os mtodos e mtricas de qualidade baseados na norma NBR
ISO/IEC 9126 e, a partir dela, traarmos uma conexo com a norma NBR ISO/IEC
25000, uma vez que esta alm de apresentar um conjunto de qualidades necessrias ao
produto, tambm mostra toda uma forma de garantia e avaliao da qualidade. Esse
modelo pode ser aplicvel 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 caractersticas de todo
produto e servio ou relao planejada, praticada e verificada, visando superar as
expectativas de satisfao das pessoas envolvidas [SEBRAE] ou a totalidade das
caractersticas de uma entidade que lhe confere a capacidade de satisfazer necessidades
explcitas e implcitas do cliente [ISO8402].
Entende-se por entidade tanto o produto como o servio. Necessidades explcitas so as
condies e objetivos pelo produto expressos na definio de requisitos, que definem as
condies em que o produto deve ser utilizado, seus objetivos, funes e o desempenho
esperado. Entende-se por necessidades implcitas aquelas que no esto expressas nos
documentos do produtor, mas que so necessrias para o usurio, entre elas as
diferenas entre os usurios, a evoluo no tempo, as implicaes ticas e questes de
segurana.
Qualidade um termo associado definio de conformidade s especificaes e
viso de satisfao do cliente, sendo que prazos, pontualidade de entrega e flexibilidade
tambm so fatores relevantes para avaliao. Para isso, a ABNT (Associao Brasileira
de Normas Tcnicas), junto ISO (Organizao Internacional de Padronizao),
promovem a normalizao de produtos e servios, utilizando determinadas normas, para
que a qualidade dos produtos seja melhorada continuamente.
Dessa forma, a ISO estipula alguns procedimentos para que seja feita a verificao
correta dos produtos ou processos:
1. Padronizao de Processos;
2. Monitoramento e Aferio de Processos;
3. Rastreabilidade de Processos;
4. Inspeo de Qualidade;
5. Reviso Sistemtica 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
desnecessrios para as empresas e fabricantes que os desenvolveu, no s pela marca,
mas coloca acima de tudo, seus lucros e resultados finais. Isso acontece devido
presso competitiva para desenvolver estes produtos resulta em ciclos de vida mais
curtos, e a complexidade se une a desafios de manter um padro nico de qualidade.
Por esse motivo, algumas empresas prestam servio de consultoria e anlise 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 ttulo geral Engenharia de software Qualidade de
software, que tem como principais mtodos:
1 - Modelo de Qualidade
2 - Mtricas Externas
3 - Mtricas Internas
4 - Mtricas de Qualidades em uso
A ISO/EIC 9126 uma reviso da NBR 13596, que visa avaliao de produtos de
software, onde foram implantadas algumas melhorias, tais como:
- Incluses das sub-caractersticas em carter normativo, baseadas, em sua maioria, no
anexo informativo da NBR 13596, que contm as sub-caractersticas de qualidade;
- Especificao de um modelo de qualidade;
- Introduo de qualidade em uso;
- Remoo do processo de avaliao (agora especificado na NBR ISO/IEC 14598);
- Coordenao de seu contedo 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 aquisio,
requisitos, desenvolvimento, uso, avaliao, apoio, manuteno, garantia de qualidade e
auditoria de software.
As metas propostas para que haja uma boa avaliao so as seguintes:
- Validar a completitude de uma definio de requisitos;
- Identificar os requisitos do software;
- Identificar objetivos de projeto do software;
- Identificar objetivos para testes de software;
- Identificar critrios para garantia de qualidade;
- Identificar critrios de aceitao para produtos finais de software.
1.2. Mtricas Externas
As mtricas externas podem ser usadas para medir a qualidade do produto de software
atravs da medio de seu comportamento em um sistema do qual ele faa parte.
Mtricas externas podem ser usadas apenas durante os estgios de teste do processo de
ciclo de vida ou durante qualquer estgio 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 caractersticas 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 mtricas externas. Durante os testes, convm que a maioria dos
defeitos seja descoberta e eliminada. Entretanto, alguns defeitos podem permanecer
aps o teste. Como difcil corrigir a arquitetura do software ou outro aspecto bsico
do projeto do software, a base do projeto usualmente permanece inalterada ao longo
do teste.
1.3. Mtricas Internas
As mtricas internas podem ser aplicadas a um produto de software no executvel,
durante os seus estgios de desenvolvimento. Elas proporcionam ao usurio a
habilidade de medir a qualidade nas fases intermedirias e, assim, predizer a qualidade
final do produto. Isso permite ao usurio detectar falhas e tomar as aes corretivas
durante os estgios iniciais de desenvolvimento.
Segundo a ABNT:
Qualidade Interna a totalidade das caractersticas do produto de software do ponto
de vista interno. A qualidade interna medida e avaliada com relao aos requisitos de
qualidade interna. Detalhes da qualidade do produto de software podem ser
melhorados durante a implementao do cdigo, reviso e teste, mas a natureza
fundamental da qualidade do produto de software representada pela qualidade interna
mantm-se inalterada, a menos que seja re-projetada.
1.4. Mtricas de Qualidade em Uso
As mtricas de Qualidade em uso se resumem em qual ser a reao, duvidas,
aceitabilidade do usurio ao usufruir do software quando pronto. Nesse caso, o
desenvolvedor deve pensar em todo e qualquer problema ou dificuldade que o usurio
pode ter. Para melhor entendimento, o esquema abaixo pode melhorar a interpretao
das etapas deste processo:

Fig.1. Caractersticas de qualidade de uso (Fonte: [3]).


Eficcia: Capacidade que o produto de software possui capaz de permitir que o
usurio atinja metas determinadas com eficcia e completeza, em um contexto de uso
especificado.
Produtividade: Capacidade que o produto de software possui capaz de permitir que
os usurios utilizem uma quantidade adequada de recursos em relao eficcia
alcanada em um contexto de uso especificado.
Segurana: Capacidade que o produto de software possui capaz de oferecer nveis
aceitveis de risco de danos a pessoas, negcios, software, propriedade ou ao ambiente,
em um contexto de uso especificado.
Satisfao: Capacidade que o produto de software possui de satisfazer usurios em
um contexto de uso especificado.

Usando como referncia o padro imposto pela ABNT, o relacionamento da qualidade
em uso com as outras caractersticas de qualidade depende do usurio:
- O usurio final, para quem qualidade em uso , principalmente, resultante de
funcionalidade, confiabilidade, usabilidade e eficincia;
- A pessoa que mantm 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 Avaliao de Produtos de Software).
Ela uma das normas mais importantes a respeito de caracterizao e medio de
qualidade de produto de software, sendo a evoluo das sries de normas ISO/IEC 9126
e ISO/IEC 14598.
A tabela abaixo apresenta um comparativo da migrao 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: Diviso de Gesto da Qualidade
1. Mtricas de Qualidade 25000: Guia do SQuaRE (NP)
2. Mtricas externas 25001: Planejamento e Gesto
3. Mtricas internas 25010: Diviso de modelo de qualidade
4. Mtricas de qualidade em uso 25010: Modelo de Qualidade (Rev.)
25020: Diviso de Medio Qualidade
Nova Proposta
25020: Guia e modelo de referncia para
medio (NP)
Guia para usar 9126 & 14598 25021: Elementos de medio de qualidade
Medidas bsicas 25022: Medio de Qualidade interna
Requisitos de qualidade 25023: Medio de Qualidade externa
25024: Medio de Qualidade em uso
14598: Avaliao de Produto 25030: Diviso de requisitos de qualidade
1. Viso Geral 25030: Requisitos de Qualidade (NP)
2. Planejamento e gesto 25040: Diviso de avaliao de qualidade
3. Processo para de desenvolvedores

25040: Guia e modelo de referncia para
avaliao
4. Processo para compradores 25041: mdulos de avaliao
5. Processo para avaliadores 25041: Processo para desenvolvedores
6. Documentos de mdulos de avaliao 25043: Processo para compradores
25044: Processo para avaliadores
Tab.1. Comparativo ISO9126, ISO14598 com ISO25000 (Fonte: [4]).
2.1. A Criao da SquaRE
Criao da SquaRE possibilitou uma melhor organizao das normas, pois uniu as das
antigas sries ISO/IEC 9126 e ISO/IEC14598, que eram bastante inter-relacionadas,
mas tinham conflitos. Foi importante a introduo orientao coordenada quanto
avaliao e medio da qualidade de produto de software. A introduo de orientaes
para uso prtico em forma de exemplos facilitou o entendimento para a utilizao da
norma.
Da Origem: ISO/IEC 9126 e 14598
So compostas por 10 documentos, sendo eles:
9126-1 Modelo de qualidade de software
9126-2 Mtricas externas
9126-3 Mtricas Internas
9126-4 Mtricas para qualidade em uso
14598-1 Guia de avaliao viso geral
14598-2 Planejamento e gerenciamento de avaliaes
14598-3 Processo de avaliao para desenvolvedores
14598-4 Processo de avaliao para adquirentes
14598-5 Processo de avaliao para avaliadores
14589-6 Documentao de mdulos de avaliao
Na reorganizao da Norma ISO/IEC 25000 houve uma diviso do assunto em cinco
tpicos, cada diviso composta por um conjunto de documentos e trata de um assunto
em particular sendo eles:





Fig.2. Caractersticas de qualidade de uso (Fonte: [4]).

A reorganizao da Norma ISO/IEC 25000 funciona da seguinte forma:
Gerenciamento: Os documentos desta diviso esto voltados a todos possveis usurios,
como gerente, programadores, avaliadores, compradores. Aqui so definidos os termos
utilizados em todos os demais documentos e so feitas recomendaes e sugestes de
carter geral sobre como utilizar o SQuaRE. [4]
Modelo de qualidade: definido um modelo hierrquico de caractersticas de qualidade,
descrevendo o que se espera de um produto. So definidos tambm os conceitos de
qualidade externa, interna e em uso, que permitem orientar diferentes perspectivas de
avaliao. [4]
Requisitos de
qualidade

Medies
Modelo de qualidade
Gerenciamento de qualidade
Avaliao
Medio: Define a padronizao matemtica das mtricas de qualidade internas,
externas e de uso, junto a um modelo de qualidade e tambm um guia prtico para
implementao do modelo. [4]
Requisitos de qualidade: Abrange as normas destinadas a especificao de requisitos de
qualidade, que podem ser orientados tanto para um produto de software que ser
desenvolvido, quanto para um produto final. [4]
Avaliao: Incluem os requisitos, recomendaes e diretrizes para a avaliao 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 cdigo ou como funciona. A realizao 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 organizao do cdigo ou a complexidade algortmica so exemplos de
critrios que podem indicar, respectivamente, provveis custos de manuteno e
provvel velocidade de execuo. [4]
2.3. Tabelas de Mtricas
Mtricas de processo e de projeto de software so medidas quantitativas que permitem
ao pessoal de software ter ideia da eficcia do processo de software e dos projetos que
so conduzidos usando o processo como arcabouo [PRESSMAN]. Portanto, para
mostrar como certas caractersticas podem ser mensuradas, sero apresentadas nesta
seo quatro tabelas com exemplos de mtricas aplicveis a cada uma das caractersticas
do modelo de qualidade em uso de produtos de software.
Mtricas de Efetividade
Nome da
Mtrica
Propsito da
Tarefa
Mtodo
de
Aplicao
Medida e
Frmula
Interpretao
Tipo de
Escala
Tipo de
Medida
Entrada
Referncia
ISO 12207
Pblico-
Alvo
Efetividade
da Tarefa
Que proporo
da tarefa
completada
corretamente?
Teste com
usurio
M1 = |1 - Ai|1
A = valor
proporcional
de cada item
perdido ou
incorreto no
resultado da
tarefa.
0 <=M1 <=1

Quanto mais
prximo de 1,
melhor.
- A = ?
Resultado do
roteiro de teste

Monitoramento
do Usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Completude
da Tarefa
Que proporo
das tarefas
completada?
Teste com
usurio
X = A/B
A = nmero de
tarefas
completadas
B = Total de
tarefas
completadas
0<=X<=1
Quanto mais
prximo de 1,
melhor.
Taxa
A=quantidade

B=quantidade

X=quantidade/
quantidade
Resultado do
roteiro de teste

Monitoramento
do usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Frequncia
de Erro
Qual a
freqncia de
erros?
Teste com
usurio
X = A/T
A = nmero de
erros tomados
pelo usurio
T = tempo ou
nmero de
tarefas
0 <= X
Quanto mais
prximo de 0,
melhor.
Absoluta
A =
quantidade
Resultado do
roteiro de teste

Monitoramento
do usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Tab.2. Mtricas Efetividade (Fonte: [1]).

Mtricas de Produtividade
Nome da
Mtrica
Propsito da
Tarefa
Mtodo
de
Aplicao
Medida e
Frmula
Interpretao
Tipo de
Escala
Tipo de
Medida
Entrada
Referncia
ISO 12207
Pblico-
Alvo
Tempo de
tarefa
Quanto tempo
demora-se
para
completar
uma tarefa?
Teste com
usurio
X = Ta/Tb
Ta = tempo ocioso
do usurio
Tb = tempo da
tarefa
X>=0
Quanto menor,
melhor
Intervalo T=tempo
Resultado do
roteiro de teste

Monitoramento
do Usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Eficincia da
Tarefa
Quo
eficientes so
os usurios?
Teste com
usurio
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 usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Custo Efetivo
Qual o custo
efetivo do
usurio?
Teste com
usurio
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 usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Proporo
Produtiva
Que
proporo o
tempo o
usurio est
realizando
aes
produtivas?
Teste com
usurio
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
prximo de 1,
melhor.
Absoluta
Ta=tempo
Tb=tempo
X=tempo/
tempo
Resultado do
roteiro de teste

Monitoramento
do Usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Grau de
eficincia do
usurio
Quo eficiente
um usurio
comparado
com um
especialista?
Teste com
usurio
X = A/B
A = eficincia de
um usurio comum
B = eficincia de
um usurio
especializado
0<=X<=1
Quanto mais
prximo de 1,
melhor.
Absoluta X = A/B
Resultado do
roteiro de teste

Monitoramento
do usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Grau de
produtividade
do usurio
Quo
produtivo
um usurio
comparado
com um
especialista?
Teste com
usurio
X = A/B
A = produtividade
de um usurio
comum
B = produtividade
de um usurio
especializado
0<=X<=1
Quanto mais
prximo de 1,
melhor.
Absoluta X = A/B
Resultado do
roteiro de teste

Monitoramento
do usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas
de
interface
com
usurio
Tab.3. Mtricas produtividade (Fonte: [1]).


Mtricas de Segurana
Nome da
Mtrica
Propsito da
Tarefa
Mtodo de
Aplicao
Medida e
Frmula
Interpretao
Tipo de
Escala
Tipo de
Medida
Entrada
Referncia
ISO 12207
Pblico-Alvo
Bem-estar
do usurio
Qual a
incidncia de
problemas de
sade entre
os usurios
do produto?
Estatsticas
X = A/B
A=nmero de
usurios com
LER, fadiga ou
dor de cabea
B=Total de
usurios
0<=X<=1
Quanto mais
prximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usurio
5.4
Operao
Usurios

Projetistas de
interface com
usurio
Segurana
das pessoas
afetadas
pelo uso do
sistema
Qual o nvel
de perigo
incidente s
pessoas
afetadas pelo
uso do
sistema?
Estatsticas
X=A/B
A=nmero de
pessoas
colocadas em
perigo
B=Total de
pessoas
afetadas pelo
sistema
0<=X<=1
Quanto mais
prximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usurio
5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas de
interface com
usurio

Desenvolvedor
Segurana
dos
pacientes
Qual a
incidncia de
perigo para o
paciente que
recebe
tratamento
pelo sistema?
Estatsticas
X=A/B
A=nmero de
pacientes com
tratamento
prescrito
incorretamente
B=Total de
pacientes
0<=X<=1
Quanto mais
prximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usurio
5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas de
interface com
usurio

Desenvolvedor
Danos
econmicos
Qual a
incidncia de
danos
econmicos?
Estatsticas
X=A/B
A=nmero de
ocorrncias de
danos
econmicos
B=Total de
situaes
medidas
0<=X<=1
Quanto mais
prximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usurio
5.4Operao
Usurios

Projetistas de
interface com
usurio

Desenvolvedor
Danos do
software
Qual a
incidncia de
danos do
software?
Estatsticas
X=A/B
A=nmero de
ocorrncias de
danos no
software
B=Total de
situaes
medidas
0<=X<=1
Quanto mais
prximo de 0,
melhor.
Absoluta
A=quantidade

B=quantidade

X=quantidade/
quantidade
Monitoramento
do Usurio
5.4Operao
Usurios

Projetistas de
interface com
usurio

Desenvolvedor
Tab.4. Mtricas Segurana (Fonte: [1]).
Mtricas de Satisfao
Nome da
Mtrica
Propsito
da Tarefa
Mtodo de
Aplicao
Medida e
Frmula
Interpretao
Tipo
de
Escala
Tipo de
Medida
Entrada
Referncia
ISO 12207
Pblico-Alvo
Escala de
Satisfao
Qual o nvel
de
Satisfao
do usurio?
Teste com
o usurio
X = A/B
A=questionrio
com escala
psicomtrica
B=mdia da
populao
X > 0
Quanto maior,
melhor
Taxa
A =
quantidade
X =
quantidade
Resultado do
roteiro de teste

Monitoramento
do Usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas de
interface com
usurio

Desenvolvedor

Pesquisa
de
Satisfao
Qual o nvel
de
Satisfao
do usurio
em funes
especficas?
Teste com
o usurio
X = A
A=resultado da
pesquisa
Comparao
com valores
anteriores ou
com a mdia da
populao
Ordinal
A= quantidade
X= quantidade
Resultado do
roteiro de teste

Monitoramento
do Usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas de
interface com
usurio

Desenvolvedor

Uso
discreto
do
produto
Qual a
proporo
dos usurios
potenciais
optou pelo
sistema?
Observao
da
utilizao
X = A/B
A = nmero de
vezes que a
funo,
aplicao ou
sistema usado
B = Nmero
que o usurio
teve a inteno
de usar
0<=X<=1
Quanto mais
prximo de 1,
melhor.
Taxa
A=quantidade

B=quantidade

X=quantidade/
quantidade
Resultado do
roteiro de teste

Monitoramento
do usurio
6.5Validao

5.3Teste de
qualificao

5.4Operao
Usurios

Projetistas de
interface com
usurio
Tab.5. Mtricas Satisfao (Fonte: [1]).




3. Qualidade de Produto e o Ciclo de Vida
As vises de qualidade interna, qualidade externa e qualidade em uso mudam durante o
ciclo de vida do software. Como exemplo, os requisitos de qualidade no incio do ciclo
de vida so normalmente vistos do ponto de vista do usurio (externo), e difere da
qualidade do produto intermedirio, tal como a qualidade do projeto, que geralmente
vista do ponto de vista do desenvolvedor (interno). As tecnologias usadas para alcanar
o nvel de qualidade necessrio, assim como especificaes e avaliaes de qualidade,
precisam apoiar tanto o ponto de vista dos usurios quanto o dos desenvolvedores.
necessrio definir estas perspectivas e as tecnologias associadas qualidade para
gerenciar a qualidade em cada estgio do ciclo de vida.
O objetivo alcanar a qualidade necessria e suficiente para atingir as reais
necessidades dos usurios. A ISO 8402 define qualidade em termos da habilidade de
satisfazer necessidades explcitas e implcitas. Entretanto, as necessidades especificadas
por um usurio nem sempre refletem as suas reais necessidades, pois um usurio
normalmente no est ciente de suas necessidades, necessidades podem mudar aps
serem especificadas. Usurios diferentes podem ter ambientes operacionais diferentes, e
pode ser impossvel consultar todos os possveis tipos de usurio. Por causa disso,
requisitos de qualidade no podem ser completamente definidos antes do incio do
projeto. Alm disso, preciso entender as necessidades reais dos usurios da forma
mais detalhada possvel, e represent-las em requisitos. O objetivo no ,
necessariamente, alcanar a qualidade perfeita, mas sim a qualidade necessria e
suficiente para cada contexto de uso especificado quando o produto entregue e
realmente utilizado pelos usurios.
Escalas de medidas para as mtricas usadas em requisitos de qualidade podem ser
divididas entre as categorias correspondentes para os diferentes graus de satisfao dos
requisitos. Como exemplo, a escala poderia ser dividida em duas categorias: satisfatrio
e insatisfatrio, ou em quatro categorias: excedeu os requisitos, atingiu requisitos
suficientemente aceitos e inaceitveis.
Basta apenas que as categorias sejam especificadas de forma que o usurio e o
desenvolvedor possam evitar o excesso de custo e planejamento desnecessrio.
A figura abaixo ilustra diferentes vises de qualidade do produto e mtricas associadas
em diferentes estgios do ciclo de vida do software.

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













Concluso
O produto software, diferentemente de uma pea manufaturada em uma fbrica, algo
que j demanda certo grau de abstrao pela essncia do que .Aplicar mtodos e
mtricas para garantir a qualidade em uma pea, que pela prpria natureza abstrata
ser nica e diferente mesmo se produzida diversas vezes, no uma tarefa simples e
pode mesmo se tornar um desafio dependendo da importncia que se d a qualidade a
pea. 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 mquina de radioterapia, por intuio sabemos que o primeiro software no
precisa de um controle de qualidade to rigoroso quanto o segundo, levando se em
considerao que a funo 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 sade
de alguns pacientes ou at lev-los a morte como mostra o caso real do Therac-25,
mquina 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 radiao, 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 possvel,
no s do ponto de vista do cliente, mas tambm deve ser vivel de ser produzido e
implementado de forma satisfatria, definido o grau de qualidade que o software deve
atingir, usamos as normas e mtricas 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 contedo, as funes e os recursos que o usurio final deseja,
alm disso, e no menos importante deve fornecer confiabilidade e iseno de erros. Um
produto til sempre satisfaz s exigncias definidas explicitamente pelos interessados.
Alm disso, ele satisfaz a um conjunto de requisitos implcitos (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 padres de qualidade propostos, seu software um produto bem concebido
por um processo satisfatrio de engenharia de software.






















Referncias Bibliogrficas
[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., Lets 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, disponvel 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 Edio.
Novatec, 2007.
[PRESSMAN] PRESSMAN, R.; Engenharia de Software. Stima Edio. So Paulo
McGraw-Hill, 2011.
[Pre01a] PRESSMAN, R.; Engenharia de Software. Stima Edio. So Paulo
McGraw-Hill, 2011 Cap. 14.3 (O dilema da Qualidade de Software).
[Pre01b] PRESSMAN, R.; Engenharia de Software. Stima Edio. So Paulo
McGraw-Hill, 2011 Cap. 14.3 (O dilema da Qualidade de Software).
[Pre01c] PRESSMAN, R.; Engenharia de Software. Stima Edio. So Paulo
McGraw-Hill, 2011 Cap. 14.2 (O dilema da Qualidade de Software).
IEEE 730-2002, Standard For Software Quality Assurance Plans.
[SEBRAE] SEBRAE. Disponvel 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.