Departamento de Computação
Trabalho de Conclusão de Curso
CIBELE CRISTINA PELIZER SODRÉ
Norma ISO/IEC 9126:
Avaliação de Qualidade de Produtos de Software
Londrina
2006
CIBELE CRISTINA PELIZER SODRÉ
Norma ISO/IEC 9126:
Avaliação de Qualidade de Produtos de Software
Trabalho de Conclusão de Curso
desenvolvido durante o 4º ano do Curso
de
Graduação
em
Ciência
de
Computação como requisito parcial à
obtenção do título de Bacharel.
Orientadora: Katia Romero Felizardo
Londrina
2006
COMISSÃO EXAMINADORA
____________________________________
Profa. Ms. Katia Romero Felizardo
UEL
____________________________________
Prof. Dr. Rodolfo Miranda de Barros
UEL
____________________________________
Profa. Helen Cristina de Mattos Senefonte
UEL
14
DEDICATÓRIA
À minha mãe, que sempre esteve presente
nas horas em que eu precisei e não precisei.
AGRADECIMENTOS
Agradeço a toda a minha família pela estrutura que me foi dada, sendo assim
possível minha formação de vida.
Agradeço à professora Katia Romero Felizardo por todo apoio, incentivo e paciência
dados no decorrer deste trabalho, possibilitando o desenvolvimento do mesmo da
melhor maneira possível.
Agradeço aos professores do Departamento de Computação da UEL e de outros
departamentos pela formação acadêmica proporcionada.
Agradeço aos amigos. Àqueles poucos, porém verdadeiros. Especialmente aos que
estiveram comigo durante este curso e entendem tudo que passei. Como já diz uma
conhecida frase, amigos são a família que podemos escolher.
Agradeço ao meu namorado, amigo e companheiro, que nos últimos três anos
compartilhou comigo as alegrias e tristezas. E que sempre suporta os meus
momentos mais nervosos e estressantes com uma calma impressionante. E está
sempre ao meu lado, independente das escolhas que eu faça.
Agradeço, enfim, a todos aqueles que direta ou indiretamente prestaram apoio,
amizade e confiança e contribuíram para esse momento de vida pelo qual estou
passando.
E à minha Mãe (com M maiúsculo), novamente. Porque sem seu amor incondicional,
as coisas seriam bem mais difíceis.
LISTA DE TABELAS
Tabela 1 – Métricas Externas de Adequação............................................................36
Tabela 2 – Métrica Externa de Acurácia ...................................................................36
Tabela 3 – Métricas Externas de Interoperabilidade .................................................37
Tabela 4 – Métricas Internas de Adequação .............................................................38
Tabela 5 – Métricas Internas de Acurácia .................................................................39
Tabela 6 – Métricas Internas de Interoperabilidade ..................................................40
Tabela 7 – Métricas de Efetividade ...........................................................................41
Tabela 8 – Métricas de Produtividade .......................................................................42
Tabela 9 – Métricas de Segurança............................................................................43
LISTA DE SIGLAS E ABREVIATURAS
ABNT: Associação Brasileira de Normas Técnicas
CMM: Capability Maturity Model
CMMI: Capability Maturity Model Integrated
IEC: International Electrotechnical Comission
ISO: International Organization for Standardization
SEI: Software Engineering Institute
SPICE: Software Process Improvement and Capability dEtermination
TI: Tecnologia da Informação
LISTA DE FIGURAS
Figura 1 – Nível 1 do CMM........................................................................................16
Figura 2 – Nível 2 do CMM........................................................................................16
Figura 3 – Nível 3 do CMM........................................................................................17
Figura 4 – Nível 4 do CMM........................................................................................17
Figura 5 – Nível 5 do CMM........................................................................................18
Figura 6 – Representação da norma ISO/IEC 14598................................................24
Figura 7 – Representação da norma ISO/IEC 9126 e suas representações.............27
Figura 8 – Características e Subcaracterísticas de Qualidade Externa e Interna .....28
Figura 9 – Divisão das Características......................................................................32
Figura 10 – Características de Qualidade em Uso....................................................33
Figura 11 – Relação entre Métricas Internas, Externas e de Qualidade em Uso......35
Figura 12 – Valor satisfatório.....................................................................................46
SUMÁRIO
INTRODUÇÃO ..........................................................................................................11
1 Introdução à Qualidade ..........................................................................................12
1.1 Histórico de Qualidade.....................................................................................12
2 Qualidade de Processo de Software ......................................................................15
2.1 CMM ................................................................................................................15
2.2 ISO/IEC 12207.................................................................................................18
2.3 SPICE ..............................................................................................................19
2.4 Família ISO/IEC 9000 ......................................................................................21
3 Qualidade de Produto de Software ........................................................................23
3.1 ISO/IEC 14598.................................................................................................23
3.2 ISO/IEC 12119.................................................................................................25
4 A Norma ISO/IEC 9126 ..........................................................................................26
4.1 ISO/IEC 9126-1: Modelo de Qualidade............................................................27
4.1.1 Modelo de Qualidade para Qualidade Interna e Externa ..........................28
4.1.2 Modelo de Qualidade para Qualidade em Uso .........................................33
4.2 Métricas ...........................................................................................................34
4.2.1 ISO/IEC 9126-2: Métricas Externas ..........................................................35
4.2.2 ISO/IEC 9126-3: Métricas Internas............................................................37
4.2.3 ISO/IEC 9126-4: Métricas de Qualidade em Uso......................................40
5 Processo de Avaliação ...........................................................................................45
5.1 Definição de Requisitos de Qualidade .............................................................45
5.2 Preparação da Avaliação.................................................................................45
5.3 Procedimento da Avaliação .............................................................................46
5.4 Um Exemplo de Aplicação...............................................................................47
CONCLUSÃO............................................................................................................49
REFERÊNCIAS BIBLIOGRÁFICAS ..........................................................................50
RESUMO
Este trabalho aborda a Qualidade de Software,detalhando normas e padrões de
Qualidade de Processo de Software e Qualidade de Produto de Software. O foco do
trabalho é a descrição da norma ISO/IEC 9126, que é uma norma de Qualidade de
Produto de Software, e suas divisões.
Palavras-chave: Qualidade de Software, ISO/IEC 9126.
ABSTRACT
This work approaches the Software Quality, detailing norms and standards of
Software Process Quality and Software Product Quality. The focus of the work is the
description of norm ISO/IEC 9126, which is a norm of Software Product Quality, and
its divisions.
Keywords: Software Quality, ISO/IEC 9126.
INTRODUÇÃO
A área de TI se torna ampla e abrangente a passos largos. Tendo
isso em vista, espera-se que os produtos resultantes dessa área atendam aos mais
diversos tipos de usuários. Para que as necessidades de tais usuários sejam
satisfeitas, é imprescindível que os produtos tenham qualidade.
Para satisfazer os usuários de software, foram criadas algumas
normas. Para assegurar qualidade no desenvolvimento de software, há as normas
de Qualidade de Processo de Software, como por exemplo, a ISO/IEC 9000, a
ISO/IEC 12207, o modelo de maturidade CMM e o SPICE. Existem também as
normas que avaliam a Qualidade do Produto de Software, que são a ISO/IEC 9126,
ISO/IEC 14598 e a ISO/IEC 12207, para avaliar os produtos já finalizados.
Este trabalho abordará o tema Qualidade de Software de maneira
abrangente e, ao final, será focada a norma de Qualidade de Produto de Software
ISO/IEC 9126.
No Capítulo 1, será feita uma breve introdução acerca de Qualidade
e também será apresentado um histórico para um melhor entendimento sobre a
importância da Qualidade de produtos no decorrer das décadas, apresentando
assim, a evolução desse conceito, até a maneira como isso é abordado atualmente.
No Capítulo 2, são detalhadas algumas normas de melhoria de
Qualidade de Processo de Software. No Capítulo 3, é feita a descrição de normas
que baseiam a avaliação de Qualidade de Produto de Software.
O Capítulo 4 é o foco principal deste trabalho e descreve a norma
ISO/IEC 9126 e suas divisões.
No Capítulo 5, o Processo de Avaliação de um software é explicado
e é dado um exemplo de uso da norma ISO/IEC 9126.
1 INTRODUÇÃO À QUALIDADE
A Qualidade de Software é um tema amplamente discutido da
Engenharia de Software. Para um maior entendimento da importância disso, a
seguir, será feita uma breve introdução sobre Qualidade.
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 envolvidas1”
[28] ou “a totalidade das características de uma entidade que lhe confere a
capacidade de satisfazer necessidades explícitas e implícitas do cliente” [22].
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.
1.1 Histórico de Qualidade
O primeiro grande marco da história da qualidade nos tempos
modernos foi a Revolução Industrial. Nessa época houve um grande crescimento no
número de indústrias, o que criou a concorrência entre elas e fez nascer um
processo de melhoria contínua de produtos.
A partir da década de 20, a produção industrial passou a ter um
processo de qualidade, com a finalidade de impedir que chegassem produtos com
_____________
1
Pessoas envolvidas ou partes interessadas: indivíduo ou grupo interessado ou afetado pelo
desempenho ambiental de um sistema de produto ou pelos resultados da avaliação do ciclo de vida
defeito às mãos dos clientes. Como as fábricas já produziam em grande
quantidade, era impossível verificar a qualidade individual de cada peça, como é
feito no produto artesanal. Esse novo processo de qualidade consistia em controle
estatístico da produção, que analisava algumas peças aleatoriamente e fazia a
medição estatística dessas peças. Quanto mais parecidas e aproximadas do padrão
ideal estivessem as medições, maior qualidade possuía aquela linha de produção.
Na década de 40, os principais órgãos ligados à qualidade foram
criados, como a ABNT e a ISO. Durante a Segunda Guerra Mundial, as técnicas de
produção foram melhoradas para a fabricação de materiais bélicos, pois é esperado
que este tipo de material apresente taxa de defeito zero2.
O impulso recebido pelas indústrias manteve-se no pós-guerra e foi
criado um controle de processos envolvendo a produção desde o projeto até o
acabamento. A partir do controle de processos foi criado um novo conceito, a
garantia de qualidade, que é a demonstração de que os produtos e serviços
possuem qualidade perante clientes e público. Nessa época, as indústrias que mais
estavam se desenvolvendo eram a automobilística e aeronáutica. Já havia também
computadores digitais para uso restrito a meios militares e acadêmicos.
Nos anos 60, houve uma mudança no ambiente de negócios devido
à saturação dos mercados, a demanda por produtos diferenciados, adoção da alta
tecnologia nos processos produtivos, redução das barreiras do comércio
internacional e a intensificação da competição internacional. Como conseqüência,
empresas com produtos diferenciados e preços competitivos e acessíveis
assumiram a liderança do mercado.[28] Nessa época, os computadores se
tornaram mais acessíveis e cada vez mais pessoas passaram a usá-los. Com isso
começou a se pensar em Qualidade de Software.
Atualmente a satisfação do cliente e a gestão empresarial moderna
são as bases da qualidade, mas os bons resultados ainda dependem do uso correto
das metodologias pelos desenvolvedores.
_____________
2
Defeito Zero: Atitude de prevenção de defeitos através da compreensão e correspondência às
exigências de um trabalho ou tarefa o tempo todo. Padrão de desempenho proposto por Philip B.
Crosby em que o lema é "fazer certo desde a primeira vez"; sua meta é buscar a excelência pela
prevenção de defeitos. Significa que a qualquer momento, a mais alta prioridade é eliminar os erros
antes de escrever qualquer código novo.
13
O conceito de Qualidade de Software surgiu devido à necessidade
de organização e padronização do desenvolvimento de softwares, que não tinham
planejamento nem norma de qualidade estabelecidos. A única forma de obter um
sistema eficiente3 era através do planejamento feito pelo próprio programador,
entretanto esses sistemas tinham manutenção complicada quando realizada por
outra pessoa e não eram completamente confiáveis. Em conseqüência disso, foram
criados a engenharia de software e os primeiros padrões de qualidade.
A Engenharia de Software busca otimizar a construção do software
e avaliar os produtos de software procurando facilitar o desenvolvimento, o uso, a
adaptação e manutenção, mas também tornando o produto acessível e com custo
reduzido.
A melhoria da Qualidade de Software pode ser dividida em melhoria
de qualidade de processo de software e melhoria de qualidade de produto de
software. As normas para obtenção de qualidade de processo de software fazem
um estudo dos requisitos necessários ao cliente, cria um ciclo de vida para os
processos e, por final, realiza a instalação e manutenção do mesmo. Já as normas
para qualidade de produto de software possuem características que um produto
com qualidade deve ter, modo de medir essas características de qualidade e
descrições para se fazer a avaliação do produto.
_____________
3
Eficiente: os objetivos são obtidos com economia de meios.
14
2 QUALIDADE DE PROCESSO DE SOFTWARE
“Processo de software é um conjunto de atividades e resultados
associados que levam à produção de um produto de software. Esse processo pode
envolver o desenvolvimento de software desde o início, embora, cada vez mais,
ocorra o caso de um software novo ser desenvolvido mediante a expansão e a
modificação de sistemas já existentes”.[21]
O processo de software pode ser dividido em 3 partes: definição,
desenvolvimento e manutenção. A fase da definição busca definir o que o sistema
vai fazer, sua interface e restrições. Já a fase de desenvolvimento define a
arquitetura do sistema, a linguagem de programação a ser usada e como serão
realizados os testes. Por fim, na fase da manutenção, podem ocorrer correções,
mudanças e adaptações do sistema dependendo da necessidade do cliente.
Normas e padrões de qualidade de processo de software foram
criados para auxiliar na obtenção de qualidade do produto de software, pois é
através da melhoria do processo de software que é obtida a qualidade do produto.
Algumas das principais normas serão descritas a seguir.
2.1 CMM
O CMM (Capability Maturiry Model) foi criado em 1991 e procurava
padronizar a qualidade dos softwares desenvolvidos pela força aérea americana
quando foi criado pela SEI.[2] [24] [25]
O modelo é baseado nos princípios de qualidade total e no
amadurecimento gradativo do processo de desenvolvimento do software dentro da
empresa. Cada instituição é avaliada em um dos cinco níveis de maturidade, que
estão divididos em áreas-chave dos temas que são abordados.
As empresas que estão no nível 1, que é chamado de Inicial,
podem obter softwares de alta qualidade dependendo do desempenho dos
desenvolvedores, mas a substituição da equipe pode prejudicar a qualidade. Os
problemas maiores são gerenciais pois o processo é como uma caixa preta na visão
do gerente, onde entram os requisitos e sai o sistema pronto, como ilustrado na
15
Figura 1. Neste nível não há área-chave.
Figura 1 – Nível 1 do CMM
Fonte: [7]
As empresas do nível 2, nível Repetitivo, acompanham e
documentam os métodos de gerenciamento para assegurar o cumprimento de
prazos e custos. As práticas bem-sucedidas em outros projetos podem ser
reaproveitadas. Nessa etapa, é possível visualizar o processo em certos pontos
entre pequenas “caixas-pretas”, como visto na Figura 2. As áreas-chave são:
•
Gerenciamento de requisitos;
•
Planejamento de projeto de software;
•
Acompanhamento de projeto de software;
•
Gerenciamento de subcontrato de software;
•
Garantia de qualidade de software;
•
Gerenciamento da configuração de software.
Figura 2 – Nível 2 do CMM
Fonte: [7]
No nível 3 ou nível Definido, o processo de software é
documentado, integrado e padronizado em processos padrão para a empresa e
todos os projetos usam uma versão aprovada e adaptada para o seu
16
desenvolvimento e manutenção. A Figura 3 mostra que neste nível já é possível
enxergar o que há dentro das “caixas-pretas”. Há sete áreas-chave:
•
Enfoque no processo da organização;
•
Definição do processo da organização;
•
Programa de treinamento;
•
Gerenciamento integrado de software;
•
Engenharia de produto de software;
•
Coordenação intergrupos;
•
Revisão.
Figura 3 – Nível 3 do CMM
Fonte: [7]
No nível 4, também conhecido como nível Gerenciado, tanto o
processo quanto o produto de software são avaliados quantitativamente e avaliados
por medições detalhadas, portanto o gerente tem bases para tomar decisões. As
medições fornecem subsídios para atuar no próprio processo, como pode ser
observado na Figura 4. Suas áreas-chave são:
•
Gerenciamento quantitativo do processo;
•
Gerenciamento da qualidade de software.
Figura 4 – Nível 4 do CMM
Fonte: [7]
17
A melhoria contínua do processo pertence ao nível 5 ou nível
Otimizado. Essa melhoria pode ocorrer devido à realimentação quantitativa do
processo e a partir de idéias e tecnologias novas, como mostra a Figura 5. As três
áreas-chave do nível 5 são:
•
Prevenção de defeito;
•
Gerenciamento de mudanças tecnológicas;
•
Gerenciamento de mudanças no processo.
Figura 5 – Nível 5 do CMM
Fonte: [7]
Em 2001, foi lançada uma evolução do CMM, o CMMI, que pode ter
duas representações: em estágio e contínua. A representação em estágio é similar
à usada no CMM: define um conjunto de áreas de processo para melhoria,
distribuídos em níveis de maturidade. A representação contínua permite que uma
área de processo específica seja selecionada e a empresa melhore em relação a
ela, usando níveis de capacidade para caracterizar a melhoria relacionada a essa
área.
2.2 ISO/IEC 12207
A ISO/IEC 12207 teve seu processo de desenvolvimento iniciado
em 1989, mas só foi aprovado em 1995. Seu objetivo é ajudar na definição dos
papéis dos desenvolvedores de software, de forma a obter uma visão aperfeiçoada
18
para o usuário das operações realizadas. Essa norma propõe processos de ciclo de
vida do software organizados em três classes[20]:
•
Processos fundamentais: atendem desde a contratação do
sistema até a manutenção do produto, passando por
desenvolvimento e operação do mesmo. O ciclo de vida
desses processos é composto por processo de aquisição,
processo de fornecimento, processo de desenvolvimento,
processo de operação e processo de manutenção;
•
Processos de apoio: são empregados para auxiliar na
obtenção de qualidade de outros projetos. São eles:
processo de documentação, processo de gerência de
configuração, processo de garantia de qualidade, processo
de verificação, processo de validação, processo de revisão
conjunta, processo de auditoria e processo de resolução de
problemas;
•
Processos organizacionais: são utilizados fora do domínio do
projeto normalmente para a melhoria da organização. Esses
processos são processo de gerência, processe de infraestrutura, processo de melhoria e processo de treinamento.
2.3 SPICE
O
SPICE
(Software
Process
Improvement
and
Capability
dEtermination) ou ISO/IEC 15504 tem como objetivo gerar normas para avaliar
processos, com o intuito de melhorar o processo continuamente e determinar sua
capacitação.[25] O SPICE foi criado de forma que pudesse ser utilizado por
especialistas que trabalham com as normas já existentes, mas sendo mais
abrangente que elas.
Há duas dimensões definidas nesse modelo: a dimensão de
processo e a dimensão de capacidade. A primeira consiste em uma disposição de
processos essenciais para a prática da engenharia de software, enquanto a
segunda define um modelo de medição que obtenha a capacidade de um processo
19
de atingir seu objetivo.
O SPICE tem como base o conceito de níveis de maturidade de
processos do CMM e a arquitetura dos processos do ciclo de vida de um software
da ISO/IEC 12207.
O modelo define seis níveis de capacitação:
•
Nível 0 – Incompleto: há uma falha geral em realizar o
objetivo do processo. Não existem produtos de trabalho nem
saídas do processo facilmente identificáveis;
•
Nível 1 – Executado: o objetivo do processo em geral é
atingido, embora não necessariamente de forma planejada e
controlada. Há um consenso na organização de que as
ações devem ser realizadas e quando são necessárias.
Existem produtos de trabalho para o processo e eles são
utilizados para atestar o atendimento dos objetivos;
•
Nível 2 – Gerenciado: o processo produz os produtos de
trabalho com qualidade aceitável e dentro do prazo. Isto é
feito de forma planejada e controlada. Os produtos de
trabalho estão de acordo com padrões e requisitos;
•
Nível 3 – Estabelecido: o processo é realizado e gerenciado
usando um processo definido, baseado em princípios de
Engenharia de Software. As pessoas que implementam o
processo usam processos aprovados, que são versões
adaptadas do processo padrão documentado;
•
Nível 4 – Previsível: o processo é realizado de forma
consistente, dentro dos limites de controle, para atingir os
objetivos. Medidas da realização do processo são coletadas
e analisadas. Isto leva a um entendimento quantitativo da
capacitação do processo a uma habilidade de prever a
realização;
•
Nível 5 – Otimizado: a realização do processo é otimizada
para atender às necessidades atuais e futuras do negócio. O
20
processo atinge seus objetivos de negócio e consegue ser
repetido. São estabelecidos objetivos quantitativos de
eficácia e eficiência para o processo, segundo os objetivos
da organização. A monitoração constante do processo
segundo estes objetivos é conseguida obtendo feedback
quantitativo e o melhoramento é conseguido pela análise dos
resultados. A otimização do processo envolve o uso piloto de
idéias e tecnologias inovadoras, além da mudança de
processos ineficientes para atingir os objetivos definidos.
2.4 Família ISO/IEC 9000
Na década de 80, as empresas utilizam TI em seus processos
internos apenas para ter controle de qualidade dos produtos. A partir da década de
90, as instituições passaram a usar a TI em seus processos de negócios, com a
finalidade de obter garantia de qualidade de processos.
Em vista disso, foram lançadas as normas ISO 9001, 9002 e 9003
em 1987 com o objetivo de garantia de qualidade como requisitos entre clientes e
fornecedores. Um ponto forte nessas normas é a flexibilidade, pois elas podem ser
adaptadas ou complementadas para atender os requisitos específicos de cada setor
produtivo.
A ISO 9001 é a norma que abrange o ciclo de vida completo de um
produto ou serviço, sendo que na mesma constam os requisitos para garantia de
qualidade de produtos e serviços.
A ISO 9000-3 foi publicada em 1994 e contém orientações para a
aplicação da ISO 9001 em projeto, desenvolvimento, fornecimento, instalação e
manutenção de softwares. Ela é dividida em três partes: Estrutura, Atividades do
Ciclo de Vida e Atividade de Suporte.
A Estrutura apresenta os aspectos organizacionais em relação ao
sistema de qualidade. São eles: responsabilidade gerencial, sistema de qualidade,
auditoria interna de sistema de qualidade e ação corretiva.
As Atividades do Ciclo de Vida são as próprias atividades relativas
21
ao desenvolvimento que são: revisão do contrato, especificação dos requisitos do
cliente, planejamento de desenvolvimento, planejamento da qualidade, projeto e
implementação, testes e validação, aceitação, reprodução, entrega, instalação e
manutenção.
Já a Atividade de Suporte dão apoio às atividades de
desenvolvimento e são: gerência da configuração, controle da documentação,
registros da qualidade, medições, regras, práticas e convenções, ferramentas e
técnicas, compras, software produto incluso e treinamento.
22
3 QUALIDADE DE PRODUTO DE SOFTWARE
A qualidade de produto de software é baseada em normas que
avaliam se o produto satisfaz o cliente e tem fácil manutenção. É o resultado direto
das atividades realizadas no processo de desenvolvimento do software.
Alguns exemplos de normas de qualidade de produto são as
normas ISO/IEC 14598, 12119 e 9126. Essas normas serão expostas na seqüência,
destacando-se a norma ISO/IEC 9126, enfoque desse trabalho.
3.1 ISO/IEC 14598
A ISO/IEC 14598 possui um conjunto de guias para orientar e
planejar o processo de avaliação de um produto de software, como descrito a seguir
e ilustrado na Figura 6:
•
ISO/IEC 14598-1 – Visão Geral: contém a estrutura de
funcionamento das normas para avaliação da qualidade de
produto de software e a definição dos termos técnicos desse
modelo. Possui também os conceitos e funcionamento de
processo de avaliação de qualquer tipo de software para
utilização de pessoas envolvidas em desenvolvimento e uso
de tecnologia de avaliação e padronização;
•
ISO/IEC 14598-2 – Planejamento e Gerenciamento: são
requisitos e guias para suportar funções de avaliação dos
produtos
de
software,
desenvolvimento,
que
aquisição,
estão
relacionados
padronização,
ao
controle,
transferência e realimentação do uso de tecnologias de
avaliação;
•
ISO/IEC
14598-3
–
Processo
para
Equipe
de
Desenvolvedores: norma para ser usada durante o
desenvolvimento
e manutenção
do
software.
Fornece
critérios para seleção de indicadores de qualidade, guia para
avaliar dados de medição e guia para melhoria do processo
23
de medição;
•
ISO/IEC 14598-4 – Processo para Compradores: norma
para avaliação de produtos tipo pacote com objetivo de
ajudar na aceitação de um produto ou selecionar entre
diversos produtos tendo como base as características de
qualidade da norma ISO/IEC 9126;
•
ISO/IEC 14598-5 – Processo para Avaliadores: possui
orientações para a prática da avaliação do produto, definindo
as atividades necessárias para analisar os requisitos de
avaliação;
•
ISO/IEC 14598-6 – Módulo de Avaliação: define a estrutura
e o conteúdo da documentação que será usada na descrição
dos Módulos de Avaliação. Descreve e desenvolvimento e a
validação dos módulos.
Figura 6 – Representação da norma ISO/IEC 14598
Fonte: [5]
24
3.2 ISO/IEC 12119
A norma ISO/IEC 12119 avalia produtos de software que estão
disponíveis no mercado, conhecidos como Pacotes de Software ou Software de
Prateleira.
Essa norma estabelece os requisitos de qualidade e teste dos
Pacotes de Software. O pacote que será testado deve possuir:
•
Descrição
do
propriedades
Produto:
do
produto
documento
com
o
que
define
objetivo
as
orientar
compradores na avaliação de adequação do produto antes
da aquisição do mesmo;
•
Manual do Usuário: conjunto de documentos fornecidos
como parte integrante do produto e para a aplicação do
mesmo;
•
Programa e Dados: conjunto completo de programas e dados
necessários para a aplicação do produto de software e
também como parte integrante do mesmo.
25
4 A NORMA ISO/IEC 9126
Em 1991, foi publicada a norma ISO/IEC 9126 contendo
características e subcaracterísticas que definem um produto de qualidade. Em
1996, foi lançada sua tradução para o Brasil, chamada NBR 13596. Após as
revisões e sucessivas melhorias foram criadas divisões dessa norma:
•
ISO/IEC 9126-1: Modelo de Qualidade;
•
ISO/IEC 9126-2: Métricas Externas;
•
ISO/IEC 9126-3: Métricas Internas;
•
ISO/IEC 9126-4: Métricas de Qualidade em Uso.
A norma ISO/IEC 9126-1 apresenta um conjunto de características
que definem um modelo de qualidade e podem ser aplicadas a qualquer produto de
software. Esse modelo de qualidade é formado por duas partes: o Modelo de
Qualidade Interna e Externa (Figura 7a) e o Modelo de Qualidade em Uso (Figura
7b).
Para realizar a avaliação das características de qualidade externa
são utilizadas as métricas externas, ou seja, medições baseadas nas necessidades
do usuário, descritas na ISO/IEC 9126-2 (Figura 7c). Para a avaliação das
características de qualidade interna são utilizadas as métricas internas, descritas na
ISO/IEC 9126-3 (Figura 7d) e a norma ISO/IEC 9126-4 define métricas para a
avaliação das características de qualidade em uso (Figura 7e).
26
Figura 7 – Representação da norma ISO/IEC 9126 e suas representações
Fonte: Adaptação de [6]
Na seqüência serão detalhados o Modelo de Qualidade, as Métricas
Externas, Internas e de Qualidade em Uso, citados acima.
4.1 ISO/IEC 9126-1: Modelo de Qualidade
Como descrito anteriormente, a norma ISO/IEC 9126-1 é formada
por dois Modelos de Qualidade: o Modelo de Qualidade Interna e Externa e o
Modelo de Qualidade em Uso. Esses dois modelos e suas respectivas
características serão detalhados a seguir.
27
4.1.1 Modelo de Qualidade para Qualidade Interna e Externa
Qualidade interna é a totalidade de características do produto de
software na visão interna.[6] Ela é usada para especificar as propriedades do
produto de software intermediário.
Analogamente, a qualidade externa é a totalidade de características
do produto de software do ponto de vista externo. É a qualidade que normalmente é
avaliada quando o produto de software final está sendo testado.
Como é possível visualizar na Figura 8, o modelo de qualidade para
qualidade interna e externa possui definições de seis características básicas que
um produto de software deve ter para ser considerado um software de qualidade:
funcionalidade,
confiabilidade,
usabilidade,
eficiência,
manutenibilidade
e
portabilidade.
Figura 8 – Características e Subcaracterísticas de Qualidade Externa e Interna
Fonte: [6]
A primeira publicação da norma, em 1991, possuía apenas as
características e subcaracterísticas de qualidade para avaliar um produto de
software. Cada característica e subcaracterística está detalhada na seqüência,
28
sendo que o texto em itálico foi extraído da própria norma e representa a definição
de cada uma das subcaracterísticas.[9]
A funcionalidade descreve um conjunto de atributos que evidenciam
a existência de um conjunto de funções, que satisfazem as necessidades explícitas
ou implícitas, e suas propriedades especificadas. Suas subcaracterísticas são:
•
Adequação: “Atributos do software que evidenciam a
presença de um conjunto de funções e sua apropriação para
as tarefas especificadas”;
•
Acurácia: “Atributos do software que evidenciam a geração
de resultados ou efeitos corretos ou conforme acordados”;
•
Interoperabilidade: “Atributos do software que evidenciam
sua capacidade de interagir com sistemas específicos”;
•
Conformidade: “Atributos do software que fazem com que ele
esteja
de
acordo
com
as
normas,
convenções
ou
regulamentações previstas em leis e descrições similares,
relacionadas à aplicação”;
•
Segurança de acesso: “Atributos do software que evidenciam
sua capacidade de evitar o acesso não autorizado, acidental
ou deliberado, a programas e dados”.
A confiabilidade possui um conjunto de atributos que evidenciam a
capacidade do software de manter seu nível de desempenho sob condições
estabelecidas
durante
um
período
de
tempo
estabelecido.
As
suas
subcaracterísticas básicas são:
•
Maturidade: “Atributos do software que evidenciam a
freqüência de falhas ou defeitos no software”;
•
Tolerância a falhas: “Atributos do software que evidenciam
sua capacidade em manter um nível de desempenho
especificado nos casos de falhas no software ou de violação
nas interfaces especificadas”;
•
Recuperabilidade: “Atributos do software que evidenciam sua
29
capacidade de restabelecer seu nível de desempenho e
recuperar os dados diretamente afetados, em caso de falha,
e no tempo e esforço necessários para tal”.
O conjunto de atributos de usabilidade ou capacidade para uso
evidencia o esforço necessário para poder-se utilizar o software, bem como o
julgamento individual deste uso, por um implícito ou explícito de usuários. As
subcaracterísticas são:
•
Inteligibilidade: “Atributos do software que evidenciam o
esforço do usuário para reconhecer o conceito lógico e sua
aplicabilidade”;
•
Apreensibilidade: “Atributos do software que evidenciam o
esforço do usuário para aprender sua aplicação (por
exemplo: controle de operações, entradas, saídas)”;
•
Operacionalidade: “Atributos do software que evidenciam o
esforço do usuário para sua operação e controle da
operação”.
A característica da eficiência é constituída por um conjunto de
atributos que verifica o relacionamento entre o nível de desempenho do software e
a quantidade de recursos usados, mediante condições estabelecidas. Suas
subcaracterísticas são:
•
Comportamento em relação ao tempo: “Atributos do software
que
evidenciam
seu
tempo
de
resposta,
tempo
de
processamento e velocidade na execução de suas funções”;
•
Comportamento em relação aos recursos: “Atributos do
software que evidenciam a quantidade de recursos usados e
a duração de seu uso na execução de suas funções”.
A manutenabilidade mostra os atributos que avaliam o esforço
necessário
para
fazer
modificações
especificadas
no
software.
Suas
subcaracterísticas são:
•
Analisabilidade: “Atributos do software que evidenciam o
esforço necessário para diagnosticar deficiências ou causas
30
de falhas, ou para identificar partes a serem modificadas”;
•
Modificabilidade: “Atributos do software que evidenciam o
esforço necessário para modificá-lo, remover seus defeitos
ou adaptá-lo a mudanças ambientais”;
•
Estabilidade: “Atributos do software que evidenciam o risco
de efeitos inesperados, ocasionados por modificações”;
•
Testabilidade: “Atributos do software que evidenciam o
esforço necessário para validar o software modificado”.
A portabilidade é a capacidade do software de ser transferido em
um ambiente para outro. As subcaracterísticas são:
•
Adaptabilidade: “Atributos do software que evidenciam sua
capacidade
de
ser
adaptado
a
ambientes
diferentes
especificados, sem a necessidade de aplicação de outras
ações ou meios além daqueles fornecidos para essa
finalidade pelo software considerado”;
•
Capacidade para ser instalado: “Atributos do software que o
tornam
consonante
com
padrões
ou
convenções
relacionadas à portabilidade”;
•
Capacidade para substituir: “Atributos do software que
evidenciam sua capacidade e esforço necessário para
substituir um outro software, no ambiente estabelecido para
este outro software”.
Uma revisão da norma foi feita anos mais tarde e novas
subcaracterísticas foram incluídas a ela. Na característica usabilidade foi
acrescentada a subcaracterística atratividade, que é a capacidade do produto de
ser atraente para o usuário. Outra inclusão foi realizada na característica
portabilidade, com a adição da subcaracterística de coexistência, que é a
capacidade que o software tem de coexistir com outro software independente em
um ambiente comum, compartilhando recursos comuns.
A última modificação feita foi que em todas as características
principais está presente a subcaracterística conformidade. Isso acontece pois em
31
todas as características é possível ser observada a aderência à legislação, padrões
internos e normas diversas associadas a elas.
Assim como as características principais, as subcaracterísticas não
podem ser mensuradas diretamente, portanto elas são divididas em atributos
mensuráveis selecionados pelo avaliador, como é exibido na Figura 9.
Figura 9 – Divisão das Características
Fonte: [27]
É possível que um atributo tenha influência direta sobre mais de
uma característica ou subcaracterística, porém elas não podem se sobrepor umas
às outras. Por exemplo, o número de linhas de código pode ser usado como atributo
tanto de analisabilidade quanto de adaptabilidade. Entretanto, a definição da
característica
de
confiabilidade
não
permite
que
fatores
próprios
de
manutenibilidade sejam considerados.
Na aplicação da norma, deve-se definir quais características e
subcaracterísticas serão mais importantes para o cliente e aplicá-los dando pesos
maiores às mais relevantes. A norma ISO/IEC 9126 define bem as características e
subcaracterísticas que podem ser utilizadas, entretanto os atributos mais
específicos são definidos dependendo do interesse do usuário no produto de
32
software.
4.1.2 Modelo de Qualidade para Qualidade em Uso
Qualidade em uso é a visão de qualidade sob a perspectiva do
usuário e é medido pelo efeito do uso do software. O modelo de Qualidade para
Qualidade em Uso faz a avaliação de quanto o usuário pode atingir seus objetivos
em um ambiente, sem medir as propriedades do produto de software. Esse modelo
possui quatro características de qualidade: Efetividade, Produtividade, Segurança e
Satisfação, como destacado na Figura 10.
Figura 10 – Características de Qualidade em Uso
Fonte: [27]
Cada uma das quatro características de Qualidade em Uso será
descrita a seguir:
•
Efetividade: capacidade do produto de software de permitir
ao usuário atingir metas específicas com acurácia e
completude, em um contexto de uso específico;
•
Produtividade: capacidade do produto de software de permitir
que seus usuários empreguem quantidade adequada de
33
recursos em relação à efetividade alcançada em um contexto
de uso específico;
•
Segurança:
capacidade
do
produto
de
software
de
apresentar níveis aceitáveis de riscos de danos a pessoas,
negócios, software, propriedade ou ambiente em um
contexto de uso específico;
•
Satisfação: capacidade do produto de software de satisfazer
usuários em um contexto de uso específico.
4.2 Métricas
Para avaliar qualidade, é necessário que haja uma maneira de
medí-la. Por isso, é preciso que se estabeleçam métricas. Para saber o valor de
uma determinada característica de qualidade, tem que se criar uma métrica para
quantificá-la e fazer uma medição para determinar a medida, que é o resultado da
aplicação na métrica.[4] As métricas devem resultar em um valor matemático que
verifique se o produto de software tem qualidade.
Uma métrica pode ser definida como sendo toda particularidade
quantificável do software que esteja relacionada a uma característica. Dependendo
do produto analisado, diferentes métricas podem ser aplicadas. Porém essas
métricas devem ser pertinentes ao paradigma e à tecnologia adotada no
desenvolvimento.
Sob o ponto de vista de medição, as métricas de software podem
ser de dois tipos: diretas ou indiretas. As métricas diretas são realizadas em função
dos atributos observados, normalmente determinados por contagem, como o custo,
número de linhas de código, número de páginas e capacidade de memória, entre
outros. As métricas indiretas são obtidas através de outras métricas, e entre seus
exemplos estão funcionalidade, confiabilidade e complexidade.
As métricas usadas pela norma ISO/IEC 9126 são consideradas
métricas indiretas e são classificadas em três tipos: métricas externas, internas e de
qualidade de uso.
34
Para obter qualidade em uso é preciso ter qualidade externa, que
por sua vez é dependente de qualidade interna, como se observa na Figura
11.
Figura 11 – Relação entre Métricas Internas, Externas e de Qualidade em Uso
Fonte: [6]
4.2.1 ISO/IEC 9126-2: Métricas Externas
As métricas externas são usadas para avaliar o produto de software
através de medições baseadas nas necessidades do usuário. Essas métricas usam
medidas de um produto de software derivadas de medidas do comportamento do
sistema do qual faz parte.
As Tabelas 1, 2 e 3 exemplificam algumas métricas externas
descritas na norma ISO/IEC 9126-2.[10]
35
Nome da
métrica
Cobertura de
implementação
funcional
Propósito da
métrica
Identificar a
quantidade de
funções que
estão de
acordo com a
especificação
Medida e
fórmula
X=A/B
A = número de
funções
corretamente
implementadas,
confirmadas
através de
execução de
testes
Tipo de
escala
Interpretação
Tipo de
medida
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Absoluta
B=quantidade
X=quantidade/
quantidade
B = número de
funções
descritas na
especificação
X = 1 - (A / B)
Especificação
de estabilidade
funcional
(volatilidade)
Identificar a
estabilidade da
especificação
funcional de
um sistema
correto depois
de entrar em
produção
A = número de
funções
mudadas
depois de ter
sido colocado
em operação
durante um
período
específico
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Absoluta
B=quantidade
X=quantidade/
quantidade
B = número de
funções
especificadas
Tabela 1 – Métricas Externas de Adequação
Nome da
métrica
Propósito da
métrica
Acurácia
computacional
Qual a
freqüência em
que o usuário
encontra
inacurácia em
resultados que
especificou
Medida e
fórmula
X=A/T
A = número de
inacurácias de
usuário
encontradas
Interpretação
Tipo de
escala
A=quantidade
X >= 0
Quanto mais
próximo de 0,
melhor.
T = Tempo de
operação
Tipo de
medida
Absoluta
T = tempo
X=quantidade/
tempo
Tabela 2 – Métrica Externa de Acurácia
36
Nome da
métrica
Propósito da
métrica
Medida e fórmula
Interpretaçã
o
Tipo de
escala
Tipo de
medida
X=A/B
Troca de
dados
(baseado no
formato de
dado)
Quão
completas são
as interfaces
de função
jusantes?
A = número de
formatos de dados
que estão aprovados
para ser trocado com
outro software ou
sistema durante teste
em dados para troca
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Taxa
B=quantidade
X=quantidade/
quantidade
B = total de formatos
de dados para troca
X = 1 - (A / B)
Troca de
dados
(baseado em
tentativas
bem
sucedidas do
usuário)
Quão bem
sucedidas são
as
transferências
de dados de
informação?
A = número de vezes
que o usuário não
conseguiu trocar
tipos de dados com
outro software ou
sistema por motivos
de falha
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Taxa
B=quantidade
X=quantidade/
quantidade
B = número de vezes
que o usuário tentou
trocar dados
X=A/B
Consistência
de interface
padrão
intersistema
O padrão para
projeto de
interface
identificado na
especificação
segue
consistenteme
nte?
A = número de
“checagem” de itens
da interface de
intersistema que
estão aprovadas por
teste, os quais são
consistentes com
padrões/regras do
intersistema
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Taxa
B=quantidade
X=quantidade/
quantidade
B = total de número
de “checagem” de
itens de interface de
intersistema
Tabela 3 – Métricas Externas de Interoperabilidade
4.2.2 ISO/IEC 9126-3: Métricas Internas
As métricas internas avaliam a especificação ou o código fonte de
um produto de software. Podem ser usadas também em partes intermediárias do
produto em desenvolvimento para garantir qualidade final. O principal objetivo das
métricas internas é assegurar a qualidade externa e qualidade de uso.
37
As Tabelas 4, 5 e 6 exibem algumas métricas internas descritas na
norma ISO/IEC 9126-2.[11]
Nome da
métrica
Cobertura de
implementação
funcional
Propósito da
métrica
Proporção de
implementação
funcional na
revisão
Medida e
fórmula
X=A/B
A = número de
funções
implementadas
confirmadas
na revisão
B = número de
funções
descritas na
especificação
X=A/B
Adequação da
implementação
funcional
Proporção de
adequação da
implementação
funcional na
revisão
A = número de
funções com
problemas que
foram
detectadas na
revisão
Tipo de
escala
Interpretação
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
mais completo.
Absoluta
B=quantidade
X=quantidade/
quantidade
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
mais adequado.
Tipo de
medida
Absoluta
B=quantidade
X=quantidade/
quantidade
B = número de
funções
revisadas
Tabela 4 – Métricas Internas de Adequação
38
Nome da
métrica
Acurácia
computacional
Propósito da
métrica
Proporção de
figuras
significantes
que se
combinam
Medida e
fórmula
X=A/B
A = número de
itens de dados
que
implementam
figuras
significantes
especificadas
confirmados na
revisão
Interpretação
Tipo de
escala
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
mais completo.
Tipo de
medida
Absoluta
B=quantidade
X=quantidade/
quantidade
B = número de
itens de dados
que são
especificados
como figuras
significantes
X=A/B
Precisão da
acurácia
Proporção de
precisão
requerida para
implementação
A = número de
itens de dados
que
implementam o
nível de
precisão de
acurácia
especificada,
confirmados
pela revisão
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Absoluta
B=quantidade
X=quantidade/
quantidade
B = número de
itens de dados
especificados
que requerem
precisão de
acurácia
Tabela 5 – Métricas Internas de Acurácia
39
Nome da
métrica
Propósito da
métrica
Medida e fórmula
Interpretaçã
o
Tipo de
escala
Tipo de
medida
X=A/B
Capacidade
de troca de
dados
(formatos
básicos de
dados)
Proporção de
dados em
formato
compatível
A = número de
formatos de dados
que implementam
consistência de
formato confirmados
pela revisão
0 <= X <= 1
Quanto mais
próximo de 1,
mais
consistente.
A=quantidade
Taxa
B=quantidade
X=quantidade/
quantidade
B = total de formatos
de dados para troca
X=A/B
Consistência
de interfaces
(formatos
básicos de
interfaces)
Proporção de
interfaces em
formato
compatível
A = número de
formatos de
interfaces que
implementam
consistência de
formato confirmados
pela revisão
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Taxa
B=quantidade
X=quantidade/
quantidade
B = número de
formatos de interface
para troca
X=A/B
Consistência
de padrões
intersistema
Proporção de
padrões
compatíveis
A = número de itens
que implementam
consistência com
regras e padrões
confirmados pela
revisão
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Taxa
B=quantidade
X=quantidade/
quantidade
B = total de itens que
são consistentes com
regras e padrões
Tabela 6 – Métricas Internas de Interoperabilidade
4.2.3 ISO/IEC 9126-4: Métricas de Qualidade em Uso
Métricas de qualidade de uso medem quanto um produto de
software atende às necessidades de um usuário específico. As medidas são obtidas
pela observação do uso do produto ou por uma simulação de um ambiente real.
Através das tabelas 7, 8, 9, e 10 serão descritos alguns exemplos
40
de métricas de qualidade em uso segundo a ISO/IEC 9126-4, e as perguntas feitas
para obter um valor.[12]
Nome da
Métrica
Propósito da
Métrica
Medida e Fórmula
Interpretação
Tipo de
Escala
Tipo de
Medida
-
A=?
M1=|1-ΣAi|
Efetividade
da tarefa
Completude
da tarefa
Que proporção da
tarefa é
completada
corretamente?
Que proporção de
tarefas é
completada?
0 <= M1 <= 1
A = valor
proporcional de
cada item perdido
ou incorreto no
resultado da tarefa
X=A / B
A = número de
tarefas
completadas
B = total de tarefas
testadas
X=A / T
Freqüência
de erro
Qual a freqüência
de erros?
A = número de
erros tomados pelo
usuário
T = tempo ou
número de tarefas
Quanto mais
próximo de 1,
melhor.
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Taxa
B=quantidade
X=quantidade/
quantidade
0 <= X
Quanto mais
próximo de 0,
melhor.
Absoluta
A=quantidade
Tabela 7 – Métricas de Efetividade
41
Nome da
Métrica
Propósito da
Métrica
Medida e Fórmula
Interpretação
Tipo de Tipo de Medida
Escala
X = Ta / Tb
Tempo da
tarefa
Quanto tempo
demora-se para
completar uma
tarefa?
Ta = tempo ocioso
do usuário
Tb = tempo da
tarefa
X = M1 / T
X >= 0
Quanto menor,
melhor.
Intervalo
X >= 0
Eficiência da
tarefa
Quão eficientes
são os usuários?
M1 = efetividade da
tarefa
Quanto maior,
melhor.
T = tempo
T = tempo
X=
T = tempo da tarefa
X = M1 / C
Custo efetivo
M1 = efetividade da
tarefa
Qual o custo
efetivo do
usuário?
C = custo total da
tarefa
X = Ta / Tb
Proporção
produtiva
Que proporção do
tempo o usuário
está realizando
ações produtivas?
Grau de
eficiência do
usuário
Quão eficiente é
um usuário
comparado a um
especialista?
Grau de
produtividade
do usuário
Quão produtivo é
um usuário
comparado a um
especialista?
X >= 0
Quanto maior,
melhor.
T = tempo
Absoluta
X=
Ta = tempo
0 <= X <= 1
Ta = tempo
produtivo
Tb = tempo da
tarefa
X=A/B
A = eficiência de um
usuário comum
B = eficiência de um
usuário
especializado
X=A/B
A = produtividade
de um usuário
comum
B = produtividade
de um usuário
especializado
Quanto mais
próximo de 1,
melhor.
Absoluta
Tb = tempo
X = tempo/
tempo
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Absoluta
X=A/B
Absoluta
X=A/B
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Tabela 8 – Métricas de Produtividade
42
Nome da
Métrica
Propósito da
Métrica
Bem-estar
do usuário
Qual é a
incidência de
problemas de
saúde entre os
usuários do
produto?
Medida e Fórmula
Interpretação
Tipo de
Escala
Tipo de
Medida
X= A / B
A = número de
usuários com LER,
fadiga ou dor-decabeça
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 0,
melhor.
Absoluta
B=quantidade
X=quantidade/
quantidade
B = total de usuários
X= A / B
Segurança
das pessoas
afetadas
pelo sistema
Segurança
dos
pacientes
Danos
econômicos
Qual o nível de
A = número de
perigo incidente
pessoas colocadas
às pessoas
em perigo
afetadas pelo uso
B = total de pessoas
do sistema?
afetadas pelo
sistema
X= A / B
Qual a incidência
A = número de
pacientes com
de perigo para o
tratamento prescrito
paciente que
recebe tratamento
incorretamente
pelo sistema?
B = total de
pacientes
X= A / B
Qual a incidência
de danos
econômicos?
A = número de
ocorrências de
danos econômicos
B = total de
situações medidas
X= A / B
Danos no
software
Qual a incidência
de danos no
software?
A = número de
ocorrências de
danos no software
B = total de
situações medidas
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 0,
melhor.
Absoluta
X=quantidade/
quantidade
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 0,
melhor.
Absoluta
A=quantidade
Absoluta
B=quantidade
X=quantidade/
quantidade
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 0,
melhor.
B=quantidade
X=quantidade/
quantidade
0 <= X <= 1
Quanto mais
próximo de 0,
melhor.
B=quantidade
Absoluta
B=quantidade
X=quantidade/
quantidade
Tabela 9 – Métricas de Segurança
43
Nome da
Métrica
Propósito da
Métrica
Medida e Fórmula
Interpretação
Tipo de
Escala
Tipo de
Medida
X= A / B
Escala de
satisfação
Qual o nível de
satisfação do
usuário?
A = questionário
com escala
psicométrica
X>0
Quanto maior,
melhor.
A=quantidade
Taxa
X=quantidade
B = média da
população
Pesquisa de
satisfação
Qual o nível de
satisfação do
usuário em
funções
específicas?
X =A
A = resultado da
pesquisa
Comparação
com valores
anteriores ou
com a média
da população.
A=quantidade
Ordinal
X=quantidade
X= A / B
Uso discreto
do produto
A = número de
Qual proporção vezes que a função,
dos usuários
aplicação ou
potenciais optou
sistema é usado
pelo sistema?
B = número que o
usuário teve a
intenção de usar
A=quantidade
0 <= X <= 1
Quanto mais
próximo de 1,
melhor.
Taxa
B=quantidade
X=quantidade/
quantidade
Tabela 10 – Métricas de Satisfação
44
5 PROCESSO DE AVALIAÇÃO
A avaliação de um software pode ser realizada para aquisição,
fornecimento, desenvolvimento, operação ou manutenção de produtos finais ou
intermediários.
O processo de avaliação de um produto de software é dividido em
três partes: definição de requisitos de qualidade, preparação da avaliação e
procedimento da avaliação.[26]
5.1 Definição de Requisitos de Qualidade
Esse estágio do processo de avaliação consiste em definir as
características e possíveis subcaracterísticas que serão usadas na avaliação.
O modelo da ISO/IEC 9126-1 é o mais utilizado conjuntamente com
o processo de avaliação da ISO/IEC 14598.[16]
5.2 Preparação da Avaliação
Este estágio busca preparar as bases para realizar a avaliação. É
dividido em três fases: seleção de métricas, estabelecimento dos níveis de
pontuação e definição dos critérios de julgamento.
A fase de seleção de métricas depende da parte interessada na
avaliação, que pode ser:
•
Desenvolvedor: procura uma visão de atributos de qualidade
interna e externa para a aplicação aos produtos de software,
onde os atributos internos devem representar a qualidade
externa ao longo do desenvolvimento;
•
Adquirente: avalia o produto através das métricas externas e
de qualidade em uso, podendo haver avaliações preliminares
informais, como observação de usuários e documentação.
45
•
Avaliação por terceira parte: analisa a descrição do produto,
especifica as medições que devem ser executadas no
produto e seus componentes e verificar a especificação
produzida em relação aos requisitos de avaliação.
No estabelecimento dos níveis de pontuação são estabelecidas as
metas para cada métrica, como na Figura 12.
Figura 12 – Valor satisfatório
Na fase de definição dos critérios de julgamento, são mapeados os
resultados das métricas para uma escala, definidos os pesos para as características
e subcaracterísticas avaliadas e calculadas médias ponderadas usando os valores
das métricas e os pesos das respectivas características e subcaracterísticas.
5.3 Procedimento da Avaliação
Este último estágio da avaliação também possui três fases:
obtenção das medidas, comparação dos critérios e julgamento dos resultados.
Na obtenção das medidas, aplicam-se as métricas selecionadas ao
produto de software, obtendo como resultado os valores nas escalas das métricas.
Na comparação de critérios, o valor medido é comparado aos
critérios predeterminados.
Por fim, na fase de julgamento de resultados, um conjunto de níveis
46
de pontuação é sintetizado e comparado com outros aspectos como tempo e custo.
O resultado permitirá a decisão gerencial quanto à aceitação ou rejeição, ou quanto
à liberação ou não-liberação do produto de software.
5.4 Um Exemplo de Aplicação
Para exemplificar o Processo de Avaliação descrito será feita uma
avaliação de qualidade em sites de Instituições de Ensino Superior sob o ponto de
vista do usuário. Para realizar a medição, serão usados os critérios descritos na
norma ISO/IEC 9126-1, com as características de qualidade em uso: efetividade,
produtividade, satisfação e segurança.
As métricas usadas serão algumas das descritas na norma ISO/IEC
9126-4, que medem os efeitos do uso do software em um contexto específico de
uso. Para cada característica, será avaliada apenas uma métrica.
O objetivo do usuário é obter informações sobre os cursos de
graduação: cursos oferecidos, ementas, estrutura curricular e corpo docente.
O resultado da avaliação é mostrado no Quadro 1. Os níveis de
pontuação foram definidos como satisfatório ou insatisfatório. Para um produto ser
considerado aceitável, é necessário que ele tenha pelo menos 80% de resultados
satisfatórios nas avaliações, proporção que é definida pelo avaliador dependendo
das suas necessidades.
47
Definição de
Requisitos
de
Qualidade
Característica
Preparação da Avaliação
Seleção
de métrica
Níveis de
pontuação
Critérios
de
julgamento
Procedimento da Avaliação
Obtenção das
medidas
UEL
Efetividade
Freqüência
de erros
S - Satisfatório
(sem erros)
I - Insatisfatório
(um ou mais
erros)
Aceitável
(80% S)
UNOPAR
Rejeitado
IESB
UEL
Produtividade
Tempo das
tarefas
S - Satisfatório
(tempo <= 10 s)
I - Insatisfatório
(tempo > 10 s)
Aceitável
(80% S)
UNOPAR
Rejeitado
IESB
UEL
Segurança
Danos no
software
S - Satisfatório
(sempre
disponíveis)
I - Insatisfatório
(alguma vez
indisponível)
Aceitável
(80% S)
UNOPAR
Rejeitado
IESB
UEL
Satisfação
Escala de
Satisfação
S - Satisfatório
(todas as
informações)
I - Insatisfatório
(falta alguma
informação)
Aceitável
(80% S)
UNOPAR
Rejeitado
IESB
9S
1I
8S
2I
8S
2I
7S
3I
6S
4I
9S
1I
10 S
0I
10 S
0I
10 S
0I
9S
1I
5S
5I
5S
5I
Comparação
dos critérios
Julgamento
dos
resultados
80%
Aceitável
80%
Aceitável
80%
Aceitável
70%
Rejeitado
60%
Rejeitado
90%
Aceitável
100%
Aceitável
100%
Aceitável
100%
Aceitável
90%
Aceitável
50%
Rejeitado
50%
Rejeitado
Quadro1 – Avaliação de sites Institucionais
48
CONCLUSÃO
Este trabalho teve o objetivo de expor as normas e padrões que
proporcionam Qualidade de Software na fase de desenvolvimento através das
normas de Qualidade de Processo, assim como as normas e padrões que avaliam a
qualidade do produto já finalizado, através das normas de Qualidade de Produto.
O detalhamento ocorreu na norma de Qualidade de Produto de
Software ISO/IEC 9126, onde suas divisões foram mostradas. Com isso, foi
possível perceber que há maneiras efetivas de verificar se um produto de software é
adequado aos diferentes tipos de usuário e suas respectivas necessidades, pois a
norma
possibilita,
através
da
utilização
de
métricas,
avaliar
diferentes
características de um mesmo produto.
49
REFERÊNCIAS BIBLIOGRÁFICAS
[1] KOSCIANSKI, A.; VILLAS-BOAS, A.; REGO, C. M.; ASANOME, C.; SCALET, D.;
ROMERO, D.; CIESLAK, J. M.; PALUDO, M.; FROSSARD, R. S.; VOSTOUPAL, T.
M. Guia para Utilização das Normas Sobre Avaliação de Qualidade de Produto de
Software – ISO/IEC 9126 e ISO/IEC 14598.
[2] TSUKUMO, A. N.; REGO, C. M.; SALVIANO, C. F.; AZEVEDO, G. F.;
MENEGHETTI, L. K.; COSTA, M. C. C.; CARVALHO, M. B.; COLOMBO, R. M. T.
Qualidade de Software: Visões de Produto e Processo de Software. Publicado na II
Escola Regional de Informática da Sociedade Brasileira de Computação Regional de
São Paulo – Piracicaba, SP. Junho de 1997.
[3] VOLPE, R. L. D.; JOMORI, S. M.; ZABEU, A. C. P. CMM – CMMI: Principais
conceitos, diferenças e correlações. Spin-BH, 30 de outubro de 2003.
[4] DUARTE, K. C.; FALBO, R. A. Uma Ontologia de Qualidade de Software.
[5] TELES, F. S. Um Processo para Análise de Desempenho de Produtos de
Software. Recife, 11 de março de 2005.
[6] MACHADO, M. P.; SOUZA, S. F. Métricas e Qualidade de Software.
[7] ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software. 1a
Edição. São Paulo: Prentice Hall, 2001.
[8] PRESSMAN, R. S. Engenharia de software, Tradução da 5a Edição. São Paulo:
Mc Graw Hill, 2002
[9] ISO/IEC 9126-1: 2000. Software engineering– Software product quality- Part 1:
Quality Model.
50
[10] ISO/IEC 9126-2: 2000. Software engineering– Software product quality- Part 2:
External Metrics.
[11] ISO/IEC 9126-3: 2000. Software engineering– Software product quality- Part 3:
Internal Metrics.
[12] ISO/IEC 9126-4: 2000. Software engineering– Software product quality- Part 4:
Quality in Use Metrics.
[13] WINTER, L. A.; CORDENONZI, W. Avaliação de Qualidade de Software
Educacional.
[14] SCALET, D. O Modelo da ISO/IEC JTC1/SC7 para a Avaliação de Produto de
Software. Disponível em <http://www.pr.gov.br/celepar/celepar/
batebyte/edições/1994/bb36/modelo.htm>. Acesso em Maio de 2006.
[15] BEVAN, N. ISO and Industry Standards for User Centred Design. Outubro de
2000. Disponível em <http://www.usability.serco.com/trump>.
[16] Seminário de Qualidade de Software do Subcomitê de Software da ABNT.
Modelo de Qualidade e Usabilidade de Software. Agosto de 2001.
[17] CORDEIRO, M. A. Métricas de Software. – Bate byte 101 – Setembro de 2000.
[18] VASCONCELOS, A. Introdução a Métricas de Software. 2005
[19] KOSCIANSKI, A.; SOARES, M. S. Qualidade de Software. 1a Edição. Editora
Novatec.
[20] WEBER, K. Qualidade e Produtividade em Software. 3a Edição. Editora Makron.
51
[21] SOMMERVILLE, I. Engenharia de Software. 6ª Edição. Addison Wesley, 2004.
[22] ISO 8402. Quality Vocabulary, 1994.
[23] ISO 9000. Normas de Gestão da Qualidade e Garantia de Qualidade –
Diretrizes para Seleção e Uso.
[24] BARRETO, J. Qualidade de Software.
[25] LODI, S.; CORDENONZI, W. Aplicação de Produtos de Software Utilizando a
ISO/IEC 9126.
[26] UNICAMP. Universidade de Campinas – Instituto de Computação –
Publicações. Disponível em <http://www.ic.unicamp.br/~cortes/mc726/cap3.pdf>.
Acesso em Julho de 2006.
[27] PALUDO, M. Qualidade de Produto de Software.
[28] SEBRAE. Disponível em <http://www.sebrae.com.br>.
52