Introdução - ISO-IEC 14598-3 PDF

Qualidade de Produto de Software
Ana Cervigni Guerra

Regina Maria Thienne Colombo
Sobre as autoras
Ana Cervigni Guerra
engenheira eltrica e doutora em Engenharia Mecnica pela Unicamp. pesquisadora em Qualidade
de Software no Centro de Tecnologia da Informao Renato Archer CTI/MCT, e participante da
ABNT/CB-21 Computadores e processamento de dados. Tem experincia na rea de automao, com
nfase em anlise numrica e modelos matemticos, em Cincia da Computao, qualidade de produto
de software, atuando principalmente nos seguintes temas: qualidade de software, qualidade de
processos, Engenharia de Software, sistema de gesto, mtodos de avaliao de processos de software,
aquisio de produtos de TI.
Regina M. Thienne Colombo

graduada em Cincia da Computao pela UFSCAR, mestre em Engenharia Mecnica pela Unicamp
na rea de qualidade e doutoranda na Poli-USP. Com vasta experincia em Engenharia e Qualidade de
Software, trabalha como pesquisadora e coordenadora da Diviso de Qualificao em Software, no
Centro de Tecnologia da Informao Renato Archer CTI/MCT. participante da ABNT/CB-21
Computadores e processamento de dados e da ISO/IEC SC7/WG6 (Engenharia de Software).
Agradecimentos
Este trabalho no poderia ter sido realizado sem o apoio do Centro de Tecnologia da Informao Renato
Archer - CTI, que nos possibilitou a oportunidade de aprofundar nossos conhecimentos tericos e
prticos na rea de Qualidade de Software. Alm das contribuies tcnicas dos profissionais dessa
instituio, algumas pessoas ajudaram, indiretamente, na elaborao deste trabalho, s quais prestamos
homenagem:
Ao Sr. Romildo Monte, que iniciou o programa de Qualidade de Software no CTI (antigo CenPRA),
agradecemos pela boa vontade, pacincia e presteza que sempre dedica a todos que o procuram.
Em especial, agradecemos grande equipe de profissionais que passaram pelo CTI e que tm
desenvolvido trabalhos nessa rea desde 1994. A essa equipe agradecemos pelo apoio tcnico deixado
como legado na nossa instituio. Sem ela no nos teria sido possvel tanto conhecimento a ser
disseminado. Reunimos esse material valioso, para que no se tornasse mais um documento tcnico
interno e para que seja acessvel a quem interessar. Tudo isso resultado de pesquisas da instituio, de
interao com empresas, outras instituies de Pesquisa e Desenvolvimento - P&D e Universidades, e de
trabalhos acadmicos em cooperao com a Unicamp - trabalhos que garantiram o ttulo de mestre a
algumas pessoas da equipe, entre elas uma das autoras.
Ao Sr. Kival Chaves Weber, um cone no pas, quando falamos em Qualidade de Software,
agradecemos pelo incentivo constante ao nosso trabalho, por todas as vezes que nos motivou na
pesquisa e aplicao do conhecimento.
Aos revisores do livro, pelas sugestes to apropriadas e pertinentes e pela pacincia. Ainda
agradecemos em especial o Sr. Danilo Scalet, a Sra. Denise Carneiro, a Sra. Diva da Silva Marinho e o
Prof. Gilberto Cludio P. Balthazar.
A todos o nosso carinho.
Sumrio
Introduo ............................................................................................................................................. 10
Captulo 1........................................................................................................................ 13
Panorama tecnolgico ........................................................................................................................... 13
Captulo 2........................................................................................................................ 17
Qualidade de Software.......................................................................................................................... 17
2.1 Qualidade de produto.................................................................................................................................... 17
2.2 Qualidade de produto de software ................................................................................................................ 19
2.2.1 Aspectos gerais e evoluo do software ............................................................................................... 20
2.2.2 Software e suas caractersticas como produto ....................................................................................... 23
2.2.3 Iniciativas para a qualidade de produto de software ............................................................................. 25
2.3 Qualidade de processo de software ............................................................................................................... 27
2.3.1 Aspectos gerais ..................................................................................................................................... 28
2.3.2 Iniciativas para a qualidade de processo de software ............................................................................ 30
2.3.3 Comparao entre os modelos .............................................................................................................. 39
Captulo 3........................................................................................................................ 42
Categorias de produtos de software e avaliao................................................................................. 42
3.1 Categorias segundo Pressman....................................................................................................................... 42
3.2 Caracterizaes da norma IEEE 1062 .......................................................................................................... 43
3.3 Categorias para prmios de software ............................................................................................................ 44
3.4 Avaliao de produto de software ................................................................................................................ 47
3.4.1 Mtodo de avaliao genrico (MEDE-PROS) ................................................................................. 48
3.4.2 Mtodo de avaliao especialista .......................................................................................................... 51
3.5 Avaliao e certificao de produto de software .......................................................................................... 54
3.6 Avaliao e teste de software ....................................................................................................................... 58
Captulo 4........................................................................................................................ 60
Modelos de qualidade ........................................................................................................................... 60
4.1 Modelo de McCall ........................................................................................................................................ 61
4.2 O modelo da norma NBR ISO/IEC 9126-1 .................................................................................................. 64
4.2.1 Diretrizes para uso da norma NBR ISO/IEC 9126-1 ............................................................................ 65
4.2.2 Caractersticas e subcaractersticas de qualidade de software............................................................... 65
4.3 A srie ISO/IEC 25000 ................................................................................................................................. 70
4.4 O modelo de qualidade do MEDE-PROS.................................................................................................. 77
4.5 Modelo de qualidade do PNAFM ................................................................................................................. 81
4.6 Modelo de qualidade de componentes de software ...................................................................................... 83
4.6.1 Descrio do componente ..................................................................................................................... 86
4.6.2 Documentao do usurio ..................................................................................................................... 89
4.6.3 Componentes no DBC .......................................................................................................................... 91
4.6.4 Componente integrado no SBC ............................................................................................................ 94
Captulo 5........................................................................................................................ 98
4
Requisitos e avaliao da qualidade de software ............................................................................... 98

5.1 Processo de avaliao da qualidade de produto de software ........................................................................ 98
5.1.1 Norma NBR ISO/IEC 14598-1 e NBR ISO/IEC 14598-5 .................................................................. 102
5.2 Especificao da avaliao ......................................................................................................................... 107
5.3 Requisitos para pacotes de software ........................................................................................................... 111
5.3.1 Requisitos de qualidade para pacotes.................................................................................................. 113
5.3.2 Requisitos para documentao de teste ............................................................................................... 116
5.3.3 Instrues para avaliao de conformidade ........................................................................................ 116
5.4 Outros requisitos de qualidade.................................................................................................................... 117
5.4.1 Requisitos de usabilidade na interface ................................................................................................ 117
5.4.2 Requisitos para documentao de usurio .......................................................................................... 120
Captulo 6...................................................................................................................... 125

Metodologia do processo de avaliao .............................................................................................. 125
6.1 Estabelecer requisitos de avaliao ............................................................................................................ 126
6.1.1 Estabelecer o propsito da avaliao .................................................................................................. 127
6.1.2 Identificar o tipo de produto a ser avaliado ......................................................................................... 128
6.1.3 Especificar o modelo de qualidade ..................................................................................................... 129
6.2 Especificar a avaliao ............................................................................................................................... 130
6.2.1 Selecionar medidas ............................................................................................................................. 130
6.2.2 Estabelecer nveis de pontuao para as medidas ............................................................................... 141
6.2.3 Estabelecer critrios para julgamento ................................................................................................. 144
6.3 Projetar a avaliao ..................................................................................................................................... 146
6.3.1 Mtodo de avaliao ........................................................................................................................... 146
6.3.2 Instrues ao avaliador ....................................................................................................................... 147
6.3.3 Recursos e cronograma ....................................................................................................................... 148
6.4 Executar a avaliao ................................................................................................................................... 148
6.4.1 Obter as medidas ................................................................................................................................. 148
6.4.2 Comparar com critrios ...................................................................................................................... 149
6.4.3 Julgar os resultados ............................................................................................................................. 149
6.5 Concluso da avaliao .............................................................................................................................. 149
6.6 Processo de avaliao para componentes de software ................................................................................ 151
6.6.1 Estabelecer os requisitos da avaliao ................................................................................................ 151
6.6.2 Especificao da avaliao ................................................................................................................. 152
6.6.3 Projeto da Avaliao ........................................................................................................................... 153
6.6.4 Execuo da Avaliao ....................................................................................................................... 153
6.6.5 Concluso da Avaliao ...................................................................................................................... 153
Captulo 7...................................................................................................................... 155

Avaliao de um software................................................................................................................... 155
7.1 Apresentao do software ........................................................................................................................... 155
7.2 Processo de avaliao ................................................................................................................................. 155
7.2.1 Estabelecer requisitos de avaliao ..................................................................................................... 155
7.2.2 Especificar a avaliao ........................................................................................................................ 158
7.2.3 Projetar a avaliao ............................................................................................................................. 159
7.2.4 Executar a avaliao ........................................................................................................................... 160
7.2.5 Concluso da avaliao ....................................................................................................................... 161
Consideraes finais............................................................................................................................ 163
Apndice A
Guia de Avaliao da Qualidade de Produto de Software
Apndice B
Modelo da identificao da avaliao
Apndice C
Modelo de relatrio de avaliao
Apndice D
Conceitos de qualidade para produtos de software uma sntese
Apndice E
Relatrio de Avaliao do Software: Easy Learn
Apndice F
Glossrio
Referncias Bibliogrficas
NDICE DE FIGURAS
FIGURA 2.1 ASPECTOS GERAIS DO SOFTWARE: A EVOLUO DOS SISTEMAS DE SOFTWARE. ...................................... 20
FIGURA 2.2 DEFINIO DE PROCESSO DE SOFTWARE. FONTE: CMMI (2002)............................................................. 28
FIGURA 2.3 SITUAO DE MUITAS ORGANIZAES DE SOFTWARE. FONTE: MAGNANI (1998). ............................... 29
FIGURA 2.4 RELAO DA NORMA NBR ISO/IEC 15504 COM OS MODELOS DE PROCESSO. ........................................ 34
FIGURA 3.1 ESTRUTURA DA LISTA DE VERIFICAO DE UM MTODO DE AVALIAO (MEDE-PROS) ................... 49
FIGURA 3.2 ESTRUTURA A SER DESENVOLVIDA NUMA AVALIAO ESPECIALISTA. .................................................... 53
FIGURA 3.3 QUALIDADE DE SOFTWARE DURANTE SEU DESENVOLVIMENTO (FONTE:NBR ISO/IEC 9126-1)............. 57
FIGURA 3.4 CICLO DE VIDA CLSSICO PARA DESENVOLVIMENTO DE SOFTWARE........................................................ 59
FIGURA 4.1 MODELO DE QUALIDADE DE MCCALL, ORGANIZADO EM FUNO DE TRS TIPOS DE CARACTERSTICAS DA
QUALIDADE. ........................................................................................................................................................ 61
FIGURA 4.2 MODELO BSICO DE QUALIDADE............................................................................................................. 66
FIGURA 4.3 CARACTERSTICAS E SUBCARACTERSTICAS DE QUALIDADE. .................................................................. 67
FIGURA 4.4 ARQUITETURA ATUAL DA SRIE ISO/IEC 25000.(2009) ......................................................................... 71
FIGURA 4.5 DIVISO DE GESTO DA QUALIDADE DA SRIE ISO/IEC 25000. ............................................................ 72
FIGURA 4.6 DIVISO MODELO DE QUALIDADE DA SRIE ISO/IEC 25000.................................................................. 73
FIGURA 4.7 DIVISO DE MEDIO DE QUALIDADE DA SRIE ISO/IEC 25000. .......................................................... 74
FIGURA 4.8 DIVISO REQUISITOS DE QUALIDADE DA SRIE ISO/IEC 25000. ............................................................ 74
FIGURA 4.9 DIVISO DE AVALIAO DA QUALIDADE DA SRIE ISO/IEC 25000. ...................................................... 74
FIGURA 4.10 COMPONENTES DE SOFTWARE. ............................................................................................................... 79
FIGURA 4.11 ETAPAS DE AVALIAO. ........................................................................................................................ 80
FIGURA 4.12 MODELO DE QUALIDADE NUMA VISO MAIS DETALHADA. .................................................................... 81
FIGURA 4.13 CONJUNTO DE SISTEMAS APLICATIVOS DO PNAFM ............................................................................. 82
FIGURA 4.14 MODELO DE QUALIDADE DO PNAFM ................................................................................................... 83
FIGURA 4.15 MODELO DE QUALIDADE PARA COMPONENTES DE SOFTWARE COTS.................................................... 86
FIGURA 5.1 RELACIONAMENTO ENTRE AS PARTES DA SRIE ISO/IEC 14598. .......................................................... 100
FIGURA 5.2 RELACIONAMENTO ENTRE AS SRIES 9126 E 14598. ............................................................................. 101
FIGURA 5.3 PROCESSO DE AVALIAO SEGUNDO NORMA NBR ISO/IEC 14598-1. ................................................. 104
FIGURA 5.5 CONCEITOS NUM PROCESSO DE AVALIAO. ......................................................................................... 108
FIGURA 5.6 NVEIS DE PONTUAO PARA AS MEDIDAS FONTE: ISO/IEC 14598-1 (2002)....................................... 109
FIGURA 5.7 VALOR MEDIDO E NVEL DE PONTUAO (NBR ISO/IEC 9126-1, 2001). .............................................. 110
FIGURA 5.8 ESTRUTURA DA NORMA NBR ISO/IEC 25051. ..................................................................................... 113
FIGURA 6.2 ESTRUTURA DO MODELO DE QUALIDADE. ............................................................................................. 130
FIGURA 7.1 CRITRIOS DE ACEITAO ..................................................................................................................... 159
FIGURA 7.2 NOTAS OBTIDAS DO EASY LEARN ........................................................................................................ 161
NDICE DE TABELA
TABELA 2.1 PESQUISA DE UTILIZAO DE MTODOS DE ENGENHARIA DE SOFTWARE (MCT, 2001) ......................... 24
TABELA 2.2 NVEIS DE CAPACIDADE E ATRIBUTOS DE PROCESSO............................................................................... 33
TABELA 2.3 CATEGORIAS E PROCESSOS DA SRIE NBR ISO/IEC 15504 (WEBER, 2001) ......................................... 34
TABELA 2.4 CATEGORIAS E REAS DE PROCESSO DO MODELO CMMI ... ................................................................... 37
TABELA 2.5 COMPARAO ENTRE OS MODELOS PARA PROCESSO DE SOFTWARE ....................................................... 40
TABELA 3.1 CARACTERSTICAS DE PRODUTOS DE SOFTWARE SEGUNDO A IEEE 1062 ............................................... 44
TABELA 4.1 CARACTERSTICAS DE QUALIDADE EM USO (NBR ISO/IEC 9126-1, 2001) ............................................ 66
TABELA 4.2 CARACTERSTICAS DE QUALIDADE INTERNA E EXTERNA (NBR ISO/IEC 9126-1, 2001) ........................ 68
TABELA 4.3 SUBCARACTERSTICAS DE QUALIDADE DE SOFTWARE ............................................................................ 68
TABELA 4.4 NORMAS DA SRIE ISO/IEC 9126: STATUS EM 2009 .......................................................................... 70
TABELA 4.5 ETAPAS DE PROJETO E DOCUMENTOS ASSOCIADOS ................................................................................. 75
TABELA 4.6 SQUARE STATUS: 2009 ......................................................................................................................... 76
TABELA 5.1 NORMAS DA SRIE ISO/IEC 14598: STATUS EM 2009. ...................................................................... 100
TABELA 5.2 REQUISITOS DE QUALIDADE PARA A DESCRIO DO PRODUTO. ............................................................ 114
TABELA 5.3 REQUISITOS DE QUALIDADE PARA A DOCUMENTAO DO USURIO. .................................................... 115
TABELA 5.4 REQUISITOS DE QUALIDADE PARA SOFTWARE ...................................................................................... 115
TABELA 5.5 REQUISITOS DA DOCUMENTAO DE TESTE ......................................................................................... 116
TABELA 5.6 INSTRUES PARA AVALIAO DE CONFORMIDADE ............................................................................. 116
TABELA 5.7 REQUISITOS BSICOS DE INCLUSO DE UM DOCUMENTO DE USURIO DO SOFTWARE. ........................ 120
TABELA 5.8 ITENS DE INFORMAO RECOMENDADOS PARA UM DOCUMENTO DE USURIO .................................... 122
TABELA 5.9 ITENS DE INFORMAO RECOMENDADOS PARA O CONTEDO DA INFORMAO DE CAPA ..................... 123
TABELA 6.1 SUBCONJUNTO DO MODELO DE QUALIDADE ......................................................................................... 132
TABELA 6.2 TIPO DE QUESTO 01 ............................................................................................................................ 142
TABELA C.1 CONFIGURAO DO EQUIPAMENTO UTILIZADO NA AVALIAO......... ERRO! INDICADOR NO DEFINIDO.
Introduo
O contedo deste livro aborda conceitos, teorias e, principalmente, normas de qualidade de produto de
software, j publicadas em mbito nacional. Adicionalmente apresenta os resultados da experincia do
desenvolvimento e da utilizao de uma metodologia para avaliao da qualidade de produto de
software. direcionado a alunos, gestores, implementadores, avaliadores e outros interessados no tema
qualidade de software.
As possibilidades abertas pelo computador, para a realizao de servios, mostram consumidores
deslumbrados, mas sem o mnimo de conhecimento necessrio para distinguir as mais elementares
caractersticas da qualidade de produto na rea de TI - Tecnologia da Informao. Assim, a questo da
discusso da qualidade de software, num mercado composto de milhares de pequenos produtores, o
grande desafio, o qual vem sendo trabalhado por vrias frentes, e as autoras fazem parte de uma dessas
iniciativas. Com a inteno de popularizar os resultados, descrevem-se aqui os potenciais benefcios da
atividade de avaliar produto de software:
o desenvolvedor pode utilizar os resultados da avaliao de seu produto, para identificar aes
corretivas, com o objetivo de melhor-lo ou de tomar decises sobre a estratgia de evoluo do
produto;
o fornecedor de software pode obter confiana no valor do produto, alm de lhe ser possvel o uso
do resultado da avaliao com finalidades comerciais;
o adquirente de produto de software pode conhecer o nvel de qualidade do software, para ajud-lo
na tomada de deciso para aquisio;
nos negcios em geral, por meio da disseminao da qualidade de produto de software, pode-se
ajudar no marketing, nas vendas e na satisfao do cliente.
O objetivo principal de uma avaliao de produto de software fornecer resultados qualitativos e

quantitativos sobre a qualidade desse produto, resultados que sejam compreensveis, aceitveis a
quaisquer das partes interessadas, e confiveis.
Em vrias regies do mundo, existem centros de desenvolvimento tecnolgico em software, com o
objetivo de acompanhar a rea de Qualidade de Software, empenhados em repassar para organizaes
interessadas o estado da prtica empregado com sucesso em projetos reais.
Alguns exemplos do que esses centros tm declarado, em suas respectivas misses, so citados a
seguir:
Software Engineering Institute SEI, localizado em Pittsburg, EUA, e mantido pelo DoD (US
Department of Defense, ou Departamento de Defesa Americano). Faz parte de sua misso "assegurar o
10
desenvolvimento e a operao dos sistemas com o custo, o cronograma e a qualidade melhores e

previsveis".
European Software Institute ESI, localizado na Espanha e mantido com verbas da Comunidade
Europia e receita prpria, cuja misso "contribuir para o desenvolvimento da sociedade de
informao e aumentar a competitividade da indstria, por meio do conhecimento, da inovao, da
melhoria contnua e a promoo e a disseminao da tecnologia de informao".
No Brasil, desde 1993 de modo mais intenso, tm surgido vrias iniciativas na rea de qualidade de
produto de software, tanto por parte do governo, como de centros de pesquisas, universidades,
associaes de classes e organismos normatizadores, com objetivos semelhantes aos j citados.
O setor de software uma das prioridades governamentais na rea de informtica. Nesse setor, o
governo brasileiro vem incentivando a criao de novas empresas e a capacitao das j existentes.
Algumas das iniciativas so: o SOFTEX, com o Programa Nacional para a Excelncia em Software,
desde 2002, tem o objetivo de apoiar as empresas de software para que aumentem sua competitividade
no mercado internacional e nacional (SOFTEX, 2009); o PBQP Software Programa Brasileiro de
Qualidade e Produtividade, com o objetivo de estimular a adoo de normas, mtodos, tcnicas e
ferramentas da qualidade e da Engenharia de Software, promovendo a melhoria da qualidade dos
processos, produtos e servios de software brasileiro, de modo a tornar as empresas mais capacitadas a
competir em um mercado globalizado. Especificamente, busca-se a melhoria contnua do grau de
satisfao dos clientes, da qualidade de vida no trabalho e no pas, e da lucratividade e competitividade
das empresas brasileiras de software. Deve ser citada tambm a SEPIN Secretaria de Poltica de
Informtica do Ministrio da Cincia e Tecnologia (MCT), que tem conduzido periodicamente pesquisas
sobre qualidade e produtividade entre as empresas de software no pas.
O organismo normatizador brasileiro, Associao Brasileira de Normas Tcnicas ABNT, criou em
1993 o Subcomit de Software, para elaborar normas nessa rea, com o objetivo de gerar normas
brasileiras relacionadas Qualidade de Software.
De 1993 at o presente momento, vrias normas sobre qualidade de produto de software foram
publicadas no Brasil, acompanhando a evoluo das normas internacionais. O contedo dessas normas
ser abordado neste livro.
Entidades de classes, como a Associao de Empresas de Software ASSESPRO, com seu prmio
Melhor Software do Ano (ROCHA, 2001); programas de mestrado e doutorado em diversas
Universidades Brasileiras e Institutos de Pesquisas, como o Centro de Tecnologia da Informao Renato
Archer CTI/MCT tm realizado pesquisas e aplicaes prticas na rea de qualidade de software,
gerando teses e publicaes com reconhecimento nacional e internacional.
As experincias adquiridas com as avaliaes de produto de software e a metodologia desenvolvida
no CTI, que aqui apresentada, trazem conhecimento para novos pesquisadores na rea de qualidade
de produto de software darem continuidade ao assunto.
11
O MEDE-PROS Mtodo de Avaliao de Qualidade de Produto de Software foi desenvolvido para

avaliar a Qualidade de Produto de Software, tendo como referncia as normas nacionais e internacionais.
Esse mtodo se encontra registrado na Fundao Biblioteca Nacional, sob nmero 135.620, livro 216,
folha 84, e com o registro de marca no INPI sob nmero 820166243. Encontra-se na verso 2006 e
propriedade do CTI.
O MEDE-PROS um exemplo de aplicao das normas, sendo que outras metodologias podem
ser desenvolvidas para este contexto. Aqui ser citado apenas esse mtodo, como um exemplo para
melhorar produtos de software, sob o ponto de vista do usurio final.
Este trabalho foi realizado numa fase de reestruturao das normas de qualidade de produto de
software. Assim, as nomenclaturas que se encontram em ajustes nos rgos normatizadores foram aqui
tratadas apresentando, muitas vezes, os nomes e conceitos das normas anteriores. Procura-se minimizar
problemas dessa transio, mencionando os nomes das normas reiteradamente.
Este livro est organizado da seguinte forma: No captulo 1 apresentado, rapidamente, um
panorama tecnolgico, sendo que a ideia de qualidade como um aporte bsico e se estendendo para
qualidade de produto e processo de software est no captulo 2. As categorias de produtos de software e
como trat-las para uma avaliao esto no captulo 3. Os modelos de qualidade se apresentam no
captulo 4. Outros requisitos de qualidade e o processo de avaliao sugeridos nas normas esto no
captulo 5. Uma sugesto de metodologia do processo de avaliao de software e um processo de
avaliao especfico para componentes de software esto apresentados no captulo 6. Um exemplo de
avaliao de software est no captulo 7. As consideraes finais fazem uma reflexo sobre os assuntos
abordados. No apndice A est o Guia de Avaliao da Qualidade de Produto de Software originado da
metodologia do MEDE-PROS, em sua formatao especial, que se apresenta de forma auto explicativa.
No apndice B se apresenta um modelo de formulrio para identificao da avaliao. No apndice C,
uma sugesto de modelo de relatrio de avaliao. O apndice D apresenta uma sntese dos conceitos
de qualidade para produtos de software, sendo til para uma consulta rpida e familiarizao desses
conceitos. O apndice E mostra o relatrio de um produto avaliado. O apndice F contm um glossrio e
finalmente, as referncias bibliogrficas.
12
CAPTULO 1
Panorama tecnolgico
Nos ltimos anos, tem ocorrido um crescimento sem precedentes na rea de TI Tecnologia da
Informao. Com a globalizao e a internet facilitando ainda mais a abertura de mercado, a produo de
software escoada independentemente das fronteiras nacionais.
A realidade mundial, nos ltimos 20 anos, mostra que a utilizao de sistemas computacionais
comandados por software tem tido uma abrangncia crescente, integrando-se no dia a dia de todos os
setores de atividades da sociedade, atingindo um grande e diversificado nmero de usurios. No meio
cientfico, v-se ainda uma busca de como produzir software com qualidade. Em 1993, o projeto SCOPE
Software CertificatiOn Programme in Europe foi exemplo de uma iniciativa internacional para melhorar
a qualidade do produto de software, que gerou os primeiros trabalhos para elaborao de normas na
rea de Qualidade de Software (SCOPE, 2009). No meio industrial existe, por parte dos desenvolvedores
e empresrios de software, uma boa vontade em atender bem o mercado; mas, com a demanda cada
vez mais crescente, o produto de software se apresenta sem os nveis de qualidade em conformidade
com as normas, at os dias de hoje.
Qualidade de software constitui uma rea cuja demanda est crescendo significativamente, pois os
usurios exigem cada vez mais eficincia, eficcia, dentre outras caractersticas de qualidade importantes
para um produto to especial como o software. Paralelamente demanda do mercado, existe um
movimento nacional e internacional, no sentido de estabelecer normas na rea de Engenharia de
Software, como o caso da ISO Organizao Internacional de Normalizao, no Subcomit de
Engenharia de Software, e da ABNT Associao Brasileira de Normas Tcnicas.
Denomina-se ISO International Organization for Standardization a organizao internacional para
a padronizao. Ela foi estabelecida em 1947, como uma organizao mundial no governamental e
conta atualmente com mais de 100 organizaes nacionais de padronizaes, representando mais de
130 pases, responsveis por mais de 95% da produo industrial mundial. Com sede em Genebra,
Sua, tem como principal atividade a elaborao de padres para especificaes e mtodos de trabalho
nas mais variadas reas. O principal objetivo da ISO o desenvolvimento de padres mundiais, com
vistas a facilitar o intercmbio internacional de produtos e servios e a criar uma cooperao intelectual,
cientfica, econmica e tcnica.
A IEC International Electrotechnical Commission, fundada em 1906, a organizao mundial que
publica normas internacionais relacionadas com eletricidade, eletrnica e reas afins, tendo a
participao de mais de 50 pases.
13
A ISO, em conjunto com a IEC, elaborou um conjunto de normas que tratam, especificamente, da
atual padronizao mundial para a qualidade dos produtos de software.
No Brasil, a ABNT foi fundada em 1940. Reconhecida como Foro Nacional de Normalizao, o nico
rgo responsvel pela normalizao tcnica no pas, fornecendo a base necessria ao desenvolvimento
tecnolgico brasileiro. uma entidade privada, sem fins lucrativos, e representa o Brasil nas entidades de
normalizao internacional, como a ISO e a IEC.
As normas recomendam modelos de qualidade e processos de avaliao da qualidade de software
que se tm firmado como valioso auxlio obteno de produtos de software com qualidade aprimorada e
mais confivel. Por um lado, surge a oportunidade do desenvolvimento de metodologias para avaliar a
qualidade de produto de software, com base em atributos de qualidade das normas reconhecidas
internacionalmente, dando subsdios para que compradores e usurios adquiram produtos com
caractersticas mais prximas de suas necessidades. Por outro, surge para produtores de software a
possibilidade de fornecer produtos de melhor qualidade.
A avaliao de produto de software tem sido uma das formas empregadas por organizaes que
produzem ou adquirem software para obteno de melhor qualidade nesses produtos, sejam eles
completos ou partes a serem integradas a um sistema computacional mais amplo. Para que a avaliao
seja mais efetiva, importante utilizar um modelo de qualidade que permita estabelecer e avaliar
requisitos de qualidade. necessrio que o processo de avaliao seja bem definido e estruturado. Os
conjuntos de normas ISO/IEC JTC1/SC7 9126 e ISO/IEC 14598, atualmente sendo reestruturadas na
srie ISO/IEC 25000 - Software Engineering - Software product Quality Requirements and Evaluation
(SQuaRE), descrevem um modelo de qualidade, um processo de avaliao, uma diretriz para requisitos
de qualidade e um conjunto de medidas de qualidade. Alguns exemplos de medidas so encontrados
nessas normas e podem ser utilizados por organizaes que pretendam fazer avaliao de produto de
software. A norma NBR ISO/IEC 25051 (2008) estabelece requisitos de qualidade para pacotes de
software e instrues para avaliao da conformidade de software. Pacotes de software, denominados
COTS Commercial Off-The-Shelf , so produtos de software definidos por uma necessidade orientada
pelo mercado, disponveis comercialmente, cuja adequao para uso foi demonstrada por um grande
nmero de usurios.
As organizaes produtoras de software devem procurar solues compatveis com seu porte e
objetivos de negcio. Um exemplo disso pode ser visto em Pivka (1995), que prope a certificao do
1
produto de software baseada na norma ISO/IEC 12119 como alternativa para a garantia da qualidade de
software produzido por pequenas empresas produtoras de software. Esse tipo de certificao, no
concretizado ainda, tema de estudo e esforos individuais.
O autor Pivka, na poca, referia-se norma ISO/IEC 12119
14
Deve-se, ainda, considerar que, diante de um mercado consumidor imaturo, a pessoa ou entidade que
se coloca no papel de avaliador deve assumir uma responsabilidade adicional: primeiro identificar os
desejos j expressos por esse mercado; em seguida, antecipar outras necessidades importantes ainda
no definidas e, finalmente, influir no mercado, para que tanto o produtor como o consumidor possam
evoluir.
As organizaes nacionais de software devem repensar as premissas fundamentais que norteiam
uma disputa de mercado e enfrentar o grande desafio de oferecer preos competitivos, menores prazos
de desenvolvimento, menos defeitos e maior satisfao dos clientes e usurios. Esses so alguns dos
requisitos de mercado para um software de qualidade.
As organizaes se tm deparado com projetos de software cada vez maiores, mais complexos e de
grande impacto na sociedade. O software faz parte do dia a dia de toda a sociedade. Ele transfere fundos
entre instituies financeiras, pilota avies, controla equipamentos em centros mdicos, diverte as
crianas, torna possvel pesquisa cientfica de grande complexidade aritmtica e muito mais. O grande
problema que, em geral, a qualidade do software no satisfatria, por no atender as necessidades
dos usurios e apresentar falhas.
A comunidade cientfica, o governo e as prprias organizaes, em resposta a essas necessidades,
cad vez mais esto buscando a qualidade de software, por meio de abordagens voltadas tanto para o
produto final quanto para o processo de desenvolvimento e manuteno de software.
Estudos sobre a qualidade, no setor de software brasileiro, mostraram a necessidade de um esforo
significativo capaz de aumentar a maturidade dos processos de software das empresas brasileiras e
deram incio ao Programa MPS.Br Melhoria de Processo do Software Brasileiro. uma iniciativa que
envolve universidades, grupos de pesquisa e empresas, sob a coordenao da Sociedade Softex
(Associao para Promoo da Excelncia do Software Brasileiro). O programa tem como premissa a
definio e disseminao de um Modelo de Referncia e um Modelo de Negcio para melhoria de
processo de software MR-MPS e MN-MPS, respectivamente.
A qualidade de software continua, no entanto, requerendo melhorias. Um processo de qualidade no
garante a produo de um produto de software de qualidade. Percebe-se, nesse ponto, uma lacuna nos
esforos que vm sendo realizados na busca pela qualidade de software. O processo, que ir resultar no
produto de software, concentra seus esforos na busca pela qualidade do modo de produo e
manuteno do software, ao passo que a qualidade do produto de software focada com mais
intensidade apenas quando ele j est pronto, por meio da avaliao de sua performance.
As iniciativas pela busca da qualidade de software descritas anteriormente, denominadas,
respectivamente, abordagem de processo e abordagem de produto, so de grande valor e tratam seus
objetivos de forma exemplar, mas agem de forma isolada. H uma expectativa de que o programa
MPS.BR da Softex (www.softex.br), que teve incio em 2003, no Brasil, tenha outro resultado e consolide
a ideia de que um processo bem definido ajuda muito a qualidade do produto.
15
A qualidade do produto de software precisa fazer parte, de maneira intensa e formal, das
preocupaes do processo de desenvolvimento e manuteno. As caractersticas de qualidade de um
produto de software precisam ser alocadas e verificadas tambm nos produtos de software
intermedirios, ao longo do processo, e no apenas no produto j acabado. Tal procedimento permite
que desvios no produto sejam detectados durante seu processo de desenvolvimento e manuteno,
originando aes necessrias ao processo para direcion-lo produo de um produto de software de
qualidade.
O software um produto complexo, que depende em parte da interpretao das necessidades do
usurio que iro se converter nos requisitos do produto para o seu desenvolvimento; dessa forma,
necessita de tcnicas verificao e validao durante o ciclo de desenvolvimento do produto e tcnicas
de avaliao do produto intermedirio e final que garantam que o produto correto e seguro, entre outros
atributos de qualidade.
16
CAPTULO 2
Qualidade de Software
A Engenharia de software tem uma de suas reas, a Qualidade de software, que objetiva garantir que
especificaes explcitas e necessidades implcitas estejam presentes no produto, por meio da definio
e normatizao de processos de desenvolvimento. Apesar de os modelos aplicados na garantia da
qualidade de software atuarem, em especial, no processo, o principal objetivo garantir um produto final
que satisfaa s expectativas do cliente, dentro daquilo que foi acordado inicialmente.
2.1 Qualidade de produto

Existem vrias propostas de definio para qualidade de produto. Crosby (1979) afirma: Qualidade
conformidade com os requisitos. Essa definio foi utilizada na manufatura, porm serve para
engenharia de software. Alm disso, menciona que preciso definir qualidade dessa forma,
principalmente porque a qualidade deve ser gerenciada. Para entender o significado de qualidade em
termos prticos, necessrio conhecer os cinco principais erros, En, cometidos por gerentes e saber
como eles devem ser tratados, Sn, de acordo com esse autor:
E1
Qualidade significa timo, ou luxo, ou brilhante, ou de grande valor.
S1
A palavra qualidade, muitas vezes, usada em expresses do tipo: boa qualidade, m

qualidade e at qualidade de vida. Mas, cada um que a ouve atribui um significado para o que
seja qualidade de vida; por exemplo, um sentido que no corresponde ao que um falante deseje,
realmente, dizer com a referida expresso. preciso definir qualidade de vida em termos
especficos, tais como: renda familiar; sade; controle de poluio; programas polticos e quaisquer
outros itens que possam ser medidos.
E2
Qualidade intangvel, portanto no mensurvel.
S2
Na verdade, qualidade precisamente mensurvel por meio da mais antiga e respeitada medida, o
dinheiro. Ignorar esse fato tem levado gerentes a perder muito dinheiro. A qualidade medida pelo
custo da qualidade, que a despesa, ou custo da no conformidade, que o custo de fazer
coisas erradas.
E3
As desculpas dos gerentes para no fazer nada, em relao qualidade de seus produtos, que
seu negcio diferente e que a cincia da qualidade no os ajudaria a fazer o que j fazem, e de
forma ainda melhor.
S3
Eles ainda no compreenderam o real significado de qualidade e continuam acreditando que ela
significa luxo. Nesses casos, importante explicar o real significado de qualidade e que sempre
mais barato fazer certo na primeira vez.
17
E4
Os problemas de qualidade so originados por trabalhadores, principalmente aqueles que

trabalham diretamente na rea de produo.
S4
Os funcionrios da produo de uma fbrica so acusados de provocar os problemas. Na realidade

eles pouco contribuem para a preveno, ou no, de defeitos, pois todo planejamento e criao
foram definidos previamente, e eles so apenas seus executores.
E5
Qualidade responsabilidade do departamento da qualidade.
S5
O departamento da qualidade tem como atribuio: medir a conformidade de acordo com o que foi
previamente determinado; reportar os resultados das medidas de forma clara e objetiva; liderar uma
atitude positiva da empresa, na busca da melhoria da qualidade; prover e capacitar os funcionrios
com ferramentas que podem auxiliar na melhoria da qualidade. Porm, o departamento da
qualidade no deve executar o trabalho, pois, caso o faa, a empresa nunca mudar sua conduta.
Resumidamente, qualidade conformidade com requisitos, e estes devem estar definidos para
permitir que sejam gerenciados com o uso de medidas, de forma a reduzir o retrabalho e aumentar a
produtividade. A melhoria da qualidade deve estar focada nos processos, e no nas pessoas;
certamente, responsabilidade de todos os envolvidos no processo.
A satisfao com o produto est relacionada com seu desempenho e com a ausncia de defeitos,
erros ou falhas. Portanto, a satisfao com o produto alcanada quando as necessidades do cliente so
supridas, e o produto se comporta como esperado. Os requisitos representam as necessidades
explcitas dos clientes e devem procurar cobrir a maior parte das necessidades por eles declaradas em
relao ao produto.
Sobre as necessidades do cliente, algumas no esto na especificao dos requisitos, mas tambm
so de fundamental importncia. Trata-se das necessidades implcitas, definidas por Joseph Juran
(1988), e que sero explicadas a seguir.
Necessidades explcitas nada mais so do que a definio dos requisitos, as condies e os objetivos
propostos para o produto. Quanto s necessidades implcitas, tm foco na viso subjetiva do
consumidor/usurio com relao ao produto, tais como: as necessidades razoveis; implicaes
estticas; itens de segurana, entre outras. As necessidades explcitas para um carro popular podem ser,
por exemplo: ser econmico, fazendo 20 km com 1 litro de combustvel, e custar no mximo R$ 25 mil.
Como necessidades implcitas poderiam constar: ser confortvel; ter um design sofisticado; possuir itens
de segurana e seu motor funcionar.
Dessa forma, o melhor a fazer definir muito bem os requisitos de um produto e gerenciar seu
processo, para que as necessidades implcitas e os defeitos possam ser reduzidos ao mnimo. Tudo isso
sem deixar de monitorar a satisfao do cliente com o produto, o que ir orientar os esforos na busca
pela qualidade.
18
Nessa busca pela qualidade, as organizaes procuram basear-se em conceitos e diretrizes

reconhecidos internacionalmente como normas, que so elaboradas e revisadas por rgos responsveis
por normalizaes tcnicas.
2
A norma NBR ISO 9000 sobre terminologias de gesto e garantia da qualidade define qualidade
como: A totalidade das caractersticas de uma entidade que lhe confere a capacidade de satisfazer s
necessidades explcitas e implcitas.
Essa definio abrangente o bastante para incorporar toda a viso de qualidade, basicamente
relacionada a produtos manufaturados, transmitida por Crosby (1979) e Juran (1988), e pode tambm
orientar as atividades para obteno e avaliao da qualidade de software. O termo totalidade das
caractersticas indica que tanto aspectos funcionais quanto os no funcionais devem ser considerados; o
termo satisfazer necessidades implcitas e explcitas, por sua vez, ressalta a importncia da
conformidade, tanto com os requisitos necessidades explcitas como com a satisfao daquelas
necessidades que no necessariamente esto descritas nos requisitos as necessidades implcitas,
mencionadas anteriormente.
Na prxima seo, o software ser abordado quanto aos aspectos gerais e suas caractersticas como
produto, alm de serem apresentadas as iniciativas e abordagens na busca por sua qualidade.
2.2 Qualidade de produto de software

Pode-se definir qualidade de produto de software como a conformidade a requisitos funcionais e de
desempenho declarados explicitamente, padres de desenvolvimento claramente documentados e as
caractersticas implcitas que so esperadas de todo software desenvolvido profissionalmente. Por
necessidades explcitas, pode-se entender requisitos do usurio; necessidades implcitas relacionam-se,
por exemplo, com a performance de execuo do sistema ou at mesmo com o cumprimento do
cronograma e o oramento do desenvolvimento do produto. As definies de qualidade podem variar em
alguns aspectos, porm o aspecto que se refere satisfao do cliente ou usurio no deve ser
esquecido.
A ISO, que objetiva promover o desenvolvimento de padronizao, no sentido de facilitar o
intercmbio de bens e servios entre os povos, foi criada em razo da necessidade das empresas de
exportarem seus produtos, por causa da chamada barreira tcnica. Os padres da ISO estabelecem
especificaes tcnicas e definem caractersticas para garantir que produtos, servios ou processos
sejam adequados a seus propsitos. A vantagem maior fica para o cliente que, ao adquirir um produto ou
contratar um servio, tem a garantia e tambm a segurana de que o produto que est adquirindo tem
padres internacionais conhecidos e familiares no mundo inteiro. A norma NBR ISO/IEC 9126-1, futura
2
A famlia de normas NBR ISO 9000:1994 (9001, 9002 e 9003) foi cancelada e substituda pela srie de normas
ABNT NBR ISO 9000:2000.
19
ISO/IEC 25010 Quality Model, faz parte desse conjunto de normas ISO. Essa norma prope
caractersticas que um software deve possuir, bem como subcaractersticas, para incentivar o uso na
prtica dessa padronizao de qualidade de produto de software.
2.2.1 Aspectos gerais e evoluo do software
Os produtos de software esto presentes nas mais diversas reas de atuao da vida cotidiana das
pessoas. Algumas vezes, simplesmente so usados sem grande nfase; outras vezes, so a ferramenta
de trabalho; e ainda, em outras, vidas so colocadas sob sua influncia. Algumas dessas reas so:
educao, entretenimento, transporte, comunicao, sistema financeiro, meio ambiente, indstria,
comrcio, medicina, pesquisa e muitas outras de igual ou maior importncia.
Um pouco da histria do desenvolvimento de software relata os problemas e a busca pela qualidade
dos produtos. Os sistemas de software tiveram uma evoluo muito densa e rpida. Os primeiros
sistemas surgiram na dcada de 1950, e desde ento existe uma evoluo contnua. Pode-se classificlos em quatro eras, como mostra a Figura 2.1.
Figura 2.1 Aspectos gerais do software: a evoluo dos sistemas de software.
Inicialmente, nos anos 1950, a maioria dos produtos de software eram especficos, com distribuio
limitada e orientados a batch, ou seja, eram executados em lotes. As excees a esse quadro eram o
sistema interativo da American Airlines e o sistema em tempo real do Departamento de Defesa
Americano - DoD, em funo da necessidade que esses sistemas tinham de prover informaes para
possibilitar a tomada de deciso no exato momento em que determinadas situaes ocorriam.
20
Nos anos 1960 surgiu a demanda por novas aplicaes e com nveis de sofisticao maiores. Foi
nesse perodo que apareceram os produtos de software multiusurios, o processamento em tempo real, o
banco de dados e os pacotes de software, que so software que atendem a uma gama de usurios com
necessidades semelhantes. Com toda essa demanda, era natural o surgimento de empresas de
desenvolvimento de software, chamadas software-houses.
Problemas comearam a partir desse momento. Quando era necessria uma adaptao em um
software que fora comprado ou quando era detectada uma falha, muitas linhas de cdigo precisavam ser
introduzidas, revisadas, corrigidas e testadas. O tempo envolvido nessas atividades comeou a aumentar
de forma descontrolada, e sua eficcia no podia ser garantida.
Todos esses fatos provocaram a chamada Crise do software e, para combat-la, foi intensificado o
desenvolvimento de mtodos, ferramentas e procedimentos destinados ao desenvolvimento de software
e integrados na disciplina Engenharia de software.
A Engenharia de software, segundo Pressman (2002), ... uma disciplina que pode ser vista, de
forma objetiva, como o estabelecimento e o uso dos princpios bsicos da engenharia, com a finalidade
de desenvolver software de maneira sistemtica e econmica, resultando em um produto confivel e
eficiente. Ou seja, ela uma disciplina que auxilia na melhoria da qualidade de software.
Nos anos 1970, os computadores pessoais, chamados PC, tornaram-se, com seus preos acessveis,
uma grande comodidade aos usurios de informtica, que comearam a comprar software em grande
escala. Iniciou-se, tambm nessa dcada, o desenvolvimento de software para serem acoplados em
automveis, aparelhos de microondas e outros equipamentos.
Em meados dos anos 1980, novas tecnologias tomaram o lugar das convencionais. Nesse perodo,
surgiu a inteligncia artificial, com os sistemas especialistas saindo dos laboratrios; despontou a da
tecnologia de programao Orientada a objetos, que parecia ser um caminho para a soluo dos
problemas de manuteno. Nessa dcada, surgiu a primeira grande necessidade identificada pelas
exigncias do DoD. Uma das suas maiores dificuldades era adquirir software junto aos fornecedores,
visto que sucessivos problemas de erros, prazo de entrega e custos variavam muito entre si. Como eram
grandes projetos, com muitos recursos investidos, arriscar com um ou outro fornecedor poderia colocar
em risco vrios objetivos. Para suprir essas necessidades, era preciso qualificar, de alguma maneira, o
potencial dos fornecedores quanto aos produtos fornecidos.
A partir dessa demanda, foi criado, em 1984, o SEI Software Engineering Institute, um centro de
pesquisa e desenvolvimento, mantido com verbas do governo americano, instalado na Universidade de
Carnegie Mellon, com a misso de prover liderana para o avano do estado da prtica da Engenharia de
software, melhorando a qualidade dos sistemas que dependem de software.
Apesar de todos os esforos, muitos problemas continuam ocorrendo. Isso acontece principalmente
por causa de alguns aspectos bastante conhecidos pelas organizaes:
21
a habilidade de construir software no acompanha o potencial do desenvolvimento de novo

hardware, que cada vez mais rpido e elevado;
a capacidade de manter os projetos de software existentes est ameaada por projetos
malplanejados e por recursos inadequados; e
os projetos de software esto ficando cada vez mais complexos.
Com isso, a quantidade de defeitos e a insatisfao dos usurios so crescentes. A visibilidade
desses fatos fica por conta dos acidentes areos em que no se consegue a comprovao de falha
humana como causa; por conta do controle, ou falta dele, sobre plantas petrolferas e qumicas; da
complexidade das redes eltricas e de telecomunicaes, alm de inmeros outros exemplos que
poderiam ser citados.
A sofisticao do hardware ultrapassou a habilidade de construir software que explore o total potencial
do hardware; a habilidade de manter os projetos de software existentes foi ameaada por projetos pobres
e por recursos inadequados; a quantidade de defeitos e a insatisfao dos usurios tornaram-se visveis,
e a possibilidade de desastres aumenta cada vez mais. Duas ocorrncias foram muito comentadas pela
mdia: o software dos sistemas computacionais utilizados na Olimpada de Atlanta, EUA, em 1996, de
responsabilidade da IBM, teve de ser retirado de operao, sendo que a IBM reconheceu a falha; outro
fato foi que o software implantado no aeroporto de Denver, EUA, para manipulao de bagagens com
mais de 100 computadores interligados, atrasou a inaugurao do aeroporto em mais de sete meses.
Alm dessa evoluo rpida e desses problemas, o produto de software diferente de outros tipos de
produtos, como os manufaturados. Algumas caractersticas de um produto de software sero
apresentadas no item 2.2.2 e mostram que grande parte das dificuldades para obter um produto de
qualidade decorre da necessidade de que essas caractersticas sejam satisfatoriamente atendidas.
A importncia de sistemas de software no mundo moderno no pode ser subestimada. Setores
econmicos, como manufatura, finanas, comunicaes, sade, energia, transportes, educao e gesto
pblica dependem do uso de software para a conduo de suas operaes dirias, utilizando desde
aplicaes em computadores pessoais at grandes sistemas em redes de complexidade gigantesca. No
exagero dizer que o software se tornou um recurso mundial, vital para o bem-estar e a competitividade.
A importncia e os problemas relacionados a software deixam clara a relevncia da busca pela
melhoria de sua qualidade. Na prxima seo, o software ser analisado em suas caractersticas
particulares e diferenas em relao ao produto manufaturado.
22
2.2.2 Software e suas caractersticas como produto

Existem diferenas importantes entre produtos de software e produtos manufaturados que no podem
deixar de ser notadas. As caractersticas inerentes essncia do software e diferenas em relao aos
produtos manufaturados so (CAPOVILLA, 1999):
Complexidade: normalmente, um produto de software tem muitas regras a serem cumpridas;

muitas linhas de cdigo a serem implementadas; e, frequentemente, diversos desenvolvedores
envolvidos, que no s tm ideias diferentes, e algumas vezes divergentes, mas que podem levar
mesma soluo;
Invisibilidade e intangibilidade: o software invisvel para o usurio. O que se v so as

consequncias da execuo do software, diferentemente de um produto manufaturado. Os prprios
desenvolvedores necessitam utilizar modelos para representar o sistema de software. Essa
intangibilidade causa grandes dificuldades de comunicao, tanto entre os elementos da equipe de
desenvolvimento como entre a equipe e o cliente, podendo acarretar problemas no produto de
software;
Conformidade e modificabilidade: o software a interface entre diversas entidades do meio no qual

ser utilizado: equipamentos, outros produtos de software, usurios e cultura organizacional, entre
outras. Sendo o componente mais malevel e adaptvel do sistema, frequentes adaptaes so
realizadas no software, para adequ-lo a essas entidades;
Produo sob medida: para software no existe produo em srie, cada usurio um cliente, que
usa o software sua maneira, com nfase em partes diferentes;
No se desgasta com o uso: em software os componentes lgicos so durveis. A falha de

software resulta de erros de projeto ou de implementao, e os defeitos permanecem no sistema
at serem percebidos devido ocorrncia de um erro quando uma determinada entrada acontece.
Os defeitos de projeto e fabricao provocam um grande nmero de falhas logo no incio, mas
depois se comportam de maneira estvel at sua obsolescncia. O no desgaste diferencia o
software da quase totalidade dos produtos modernos. Apenas a msica e o cinema, por exemplo,
aproximam-se do software sob esse aspecto.
No tem prazo de validade: o software no sensvel a problemas ambientais e nem sofre

qualquer tipo de defeito devido a efeito cumulativo de seu uso. O software se torna obsoleto devido
evoluo do hardware e, consequentemente, da tecnologia. Empresas produtoras de software
proprietrio, com uma base grande de usurios costumam planejar a obsolescncia de seus
produtos, para aumentarem as suas vendas.
O custo final do software basicamente o custo do projeto e do desenvolvimento: cpias do

software podem ser reproduzidas em segundos e distribudas a vrios clientes, com o custo
unitrio do projeto e do desenvolvimento.
23
Software o nico produto que, quando apresenta erro, o cliente paga para corrigir: no caso de
uma nova verso licenciada, esta pode ter apenas os erros corrigidos.
Diante dessas diferenas, difcil imaginar, de forma direta no desenvolvimento de software, o

aproveitamento de toda a experincia e maturidade existentes no processo de fabricao de um produto
manufaturado. A Engenharia de software, no entanto, foi criada com o objetivo de estabelecer o uso de
princpios bsicos da engenharia clssica, ou seja, tornar um produto invisvel, intangvel e complexo em
um produto confivel e eficiente. As organizaes de software que se preocupam com a qualidade vm
utilizando a Engenharia de software.
A Secretaria de Poltica de Informtica do Ministrio da Cincia e Tecnologia SEPIN vem
conduzindo periodicamente pesquisas diretas com organizaes de software, visando acompanhar a
evoluo da gesto da qualidade nesse setor. Conforme a Tabela 2.1, reproduzida com base nos dados
das trs ltimas edies desse tipo de pesquisa, possvel constatar a utilizao de mtodos de
Engenharia de software, o que indica a credibilidade em seu potencial. Observe-se, tambm, que j em
2001 os dados eram favorveis adoo dessas metodologias. Nessa tabela pode-se observar a
variabilidade da utilizao de mtodos de Engenharia de software.
Tabela 2.1 Pesquisa de utilizao de mtodos de Engenharia de Software (MCT, 2001)
Mtodos de Engenharia de Software
Resultados (N de Empresas / %)
1995 (445 empresas)
1997 (589 empresas)
1999 (426 empresas)
Empresas que adotam mtodos de preveno de defeitos

Auditorias
...
102 / 17%
88 / 21%
Gerncia de configurao
...
40 / 7%
63 / 15%
Joint Application Design
...
46 / 8%
36 / 9%
45 / 10%
48 / 8%
52 / 12%
Prototipao
207 / 46%
259 / 44%
187 / 44%
Reso
166 / 37%
110 / 19%
104 / 24%
Verificao independente
...
81 / 14%
155 / 36%
100 / 17%
87 / 20%
Medies da qualidade (medidas)
Empresas que adotam mtodos de deteco/remoo de defeitos

Inspees formais
45 / 10%
Revises estruturadas
...
113 / 19%
66 / 16%
Testes de aceitao
212 / 48%
278 / 47%
205 / 48%
Testes de sistema
277 / 62%
392 / 67%
199 / 47%
Testes de unidade
105 / 24%
137 / 23%
130 / 31%
Validao
...
250 / 42%
192 / 45%
24
Empresas que adotam outras prticas de Engenharia de Software

Gesto de mudana
...
32 / 5%
31 / 7%
Mtodos estruturados
...
210 / 36%
146 / 34%
Mtodos orientados a objetos
193 / 43%
216 / 37%
186 / 44%
Projetos interface com o usurio
...
207 / 35%
215 / 51%
Observao: O smbolo ... indica dado indisponvel.
Infelizmente, a realidade das empresas, tanto as mundiais como as nacionais, est distante do ideal.
A realidade das empresas de software do pas, sendo 36% do tipo microempresa e 33% do tipo pequena
empresa, segundo a fora de trabalho, com equipe e faturamento reduzidos, explica uma situao e
indica a necessidade que as empresas tm de receber auxlio externo para superar seus altos ndices de
desconhecimento e capacidade de aplicao dessas normas e modelos.
Apesar de todos os esforos da Engenharia de software, os problemas de qualidade nos produtos
persistem. Na prxima seo sero analisadas outras iniciativas que vm sendo realizadas na busca pela
qualidade do produto software.
2.2.3 Iniciativas para a qualidade de produto de software
Diante do que foi apresentado nas sees anteriores, o produto de software, h algum tempo, necessita e
busca solues para a melhoria na sua qualidade tanto em funo de seu grau de importncia e
integrao na sociedade quanto pelas falhas frequentes e com possibilidade de consequncias
desastrosas. Tudo isso sem deixar de mencionar, tambm, o alto custo e elevado tempo de
desenvolvimento e manuteno.
Qualidade de software pode ser vista, e definida nas normas relacionadas a essa rea, como um
conjunto de caractersticas que devem ser alcanadas em um determinado grau, para que o produto
atenda s necessidades de seu usurio, cuja participao fundamental no processo. por meio desse
conjunto de caractersticas que a qualidade de um produto de software pode ser descrita e avaliada.
Analisando essa afirmao, percebe-se a necessidade de respostas para algumas questes bsicas
sobre como atingir a qualidade num produto de software a ser desenvolvido:
A determinao do conjunto de caractersticas que atende s necessidades de seus usurios.
A forma de avaliar se tais caractersticas foram alcanadas num grau que satisfaa seus usurios.
Diversas iniciativas surgiram para buscar as respostas a essas questes. De acordo com o livro
Qualidade de Software Teoria e Prtica (ROCHA, 2001), diversos modelos foram desenvolvidos,
detalhando as caractersticas de qualidade de um produto de software em subcaractersticas, e estas em
25
atributos. Alguns desses trabalhos so encontrados nos livros: Factors in software quality (1977) de
McCALL, Characteristics of software quality (1978) de B. Boehm e Cornering the chimera (1996) de R. G.
Dromey.
O Subcomit de Software SC7 do Comit Tcnico Conjunto JTC1 da ISO e IEC vm trabalhando
desde a dcada de 1990, na elaborao de normas e relatrios tcnicos que permitam especificar e
avaliar a qualidade de produtos de software, consolidando as diferentes vises de qualidade. Para
auxiliar no processo de avaliao da qualidade de produtos de software, a ISO e a IEC estabeleceram o
3
seguinte conjunto de normas na srie 14598 , que j foram publicadas pela ABNT, com os seguintes
assuntos:
Viso geral do processo de avaliao;
Processo de avaliao para desenvolvedores;
Processo para adquirentes;
Processo para avaliadores;
Planejamento e gesto do processo;
Documentao de mdulos de avaliao.
A norma brasileira NBR ISO/IEC 9126-1 uma traduo da norma ISO/IEC 9126-1, contendo modelo
de qualidade com as caractersticas e subcaractersticas de um produto de software.
Atualmente, a srie de normas ISO/IEC 25000, que trata da definio da qualidade de produto de
software, composta por um conjunto de documentos contendo abordagens sobre o modelo de
qualidade, medidas externas, medidas internas e medidas da qualidade em uso. O assunto ser tratado
com detalhes no captulo 4.
Para se obter um produto de software de qualidade, preciso verificar seu processo de
desenvolvimento e tambm as caractersticas do produto em produo. Na prxima seo, sero
abordados aspectos gerais de um processo de software, iniciativas e modelos para sua qualidade.
Weber cita, em Qualidade e Produtividade em Software, publicado em 2001, que a base para o
reconhecimento da qualidade do software brasileiro e a chave para alcanar crescentes nveis de
competitividade nas empresas brasileiras de software encontram-se:
na adoo da norma ISO 9001 e do CMMI como modelos complementares para a melhoria dos
processos de software;
Atualmente em reviso na srie 25000.
26
na adoo da srie ISO/IEC 9126, srie ISO/IEC 14598 e ISO/IEC 12119 para avaliao dos
produtos de software.
Essas abordagens podem ser adotadas separadamente ou em conjunto, como foi tratado, por
exemplo, na proposta para qualidade de software com a aplicao integrada de modelo de capacidade
de processo e norma de produto, em Santana (2002). Procurou-se analisar atividades, metas e produtos
de trabalho das reas de processo, verificando instncias em que as definies, diretrizes e
caractersticas de qualidade de produto de software, possam ser utilizadas. Tambm essas abordagens
podem ser escolhidas em conformidade com os objetivos de negcio das empresas e da capacitao de
seu pessoal.
2.3 Qualidade de processo de software

O motivador deste assunto a busca pela qualidade de software, ou seja, qualidade tanto do produto
como do processo de software. A ideia atual de que se deve atuar na qualidade do processo, para se
atingir a qualidade do produto de software, no pode ser vista isoladamente, mas em composio com
outras abordagens.
Processo de software est definido como um conjunto de atividades, mtodos, prticas e
transformaes que as pessoas empregam para desenvolver e manter software e os produtos
associados. Especificao de requisitos, gerncia de configurao, desenvolvimento de software so
exemplos de processos que podem ser formalizados e documentados para desenvolver um produto. A
Figura 2.2 representa a definio de processo de software.
O autor, na poca se referia norma ISO/IEC 12119
27
Figura 2.2 Definio de processo de software. Fonte: CMMI (2002).
2.3.1 Aspectos gerais

A flexibilidade na adaptao e definio de processos equilibrada assegurando a consistncia
apropriada dos processos em cada organizao. Essa flexibilidade necessria para tratar as variveis
de contexto, por exemplo: domnio de atuao, tipo de cliente, limitaes de custo, cronograma e
qualidade, dificuldades tcnicas do trabalho e experincia das pessoas que esto implementando o
processo.
Os padres dentro da organizao tm que atingir padres organizacionais, objetivos e estratgias
que sejam apropriadamente tratados, alm de dados e lies aprendidas dos processos, para que
possam ser compartilhados. Essa afirmao relaciona processo a aes e acontecimentos realizados por
pessoas, para o desenvolvimento e para a manuteno tanto do software como de outros produtos
associados a ele, por exemplo: os manuais de usurio.
Tanto o produto de software como o produto manufaturado tm como requisito, para um processo de
qualidade, a necessidade de ser uma atividade sistemtica e passvel de repetio, independentemente
de quem a execute.
A Figura 2.3 mostra a situao de muitas organizaes de software. Existe um grande acmulo de
trabalho, que acarreta o abandono de planos e procedimentos, quando estes esto definidos. As
consequncias so produtos de software que, s vezes, funcionam, mas os prazos e custos so
frequentemente maiores do que os previstos.
28
Figura 2.3 Situao de muitas organizaes de software. Fonte: MAGNANI (1998).
As organizaes percebem a situao catica, mas encontram dificuldades em mudar esse quadro
em funo de uma srie de fatores, dentre os quais:
As organizaes esto reagindo a crises constantes;
A ausncia de guias, da mesma forma que existe nas demais engenharias, de mtodos testados e
comprovados sobre como desenvolver e fazer manuteno de software. Boas prticas esto sendo
utilizadas, mas so pouco disseminadas;
A maioria dos problemas nas organizaes de software de natureza gerencial, e no tcnica. A

tecnologia e a capacitao dos profissionais que essas organizaes j possuem, poderiam gerar
melhor qualidade;
A alta velocidade de mudanas tecnolgicas envolvidas, como o prprio hardware;
O baixo estmulo participao do usurio no processo de software, o que conduz a uma

especificao incompleta de suas necessidades;
A crescente demanda por novos processos de automao e pela manuteno dos j desenvolvidos
acarreta problemas, como mostrado na Figura 2.3;
29
A falta de conhecimento sobre como mudar essa realidade e a dificuldade em aplicar os princpios
da qualidade ao software.
Apesar da demanda por qualidade, os avanos da Engenharia de software no conseguem

acompanhar e solucionar os problemas, sendo necessrios outros esforos nesse sentido. Tais esforos
sero tratados nas prximas sees.
Tendo como referncia a Figura 2.3, fica clara a dependncia existente entre a qualidade do produto
de software e seu processo, mas s trabalhar essa dependncia no garante um produto de qualidade. A
avaliao e a melhoria da qualidade podem ser tratadas em duas abordagens diferentes: processo e
produto. A viso de processo procura estabelecer prticas que propiciem uma reduo na variabilidade
dos resultados e maior confiana na obteno do produto final. Procura-se uma maturidade do processo
pela sua definio explcita, gerenciamento, controle e efetividade.
A viso de produto prope a avaliao de produtos intermedirios e do produto final, verificando o
atendimento s necessidades a que o produto se destina.
As duas abordagens so necessrias e complementares, pois, se o processo gera uma expectativa de
reduo na variabilidade na qualidade dos produtos gerados, no se tem, como decorrncia direta, a
garantia da qualidade do produto, porque sempre h fatores imponderveis, que escapam ao controle do
processo de produo e podem afetar o resultado final. Mais ainda, sendo o desenvolvimento de software
concentrado em atividades de projeto, est mais sujeito a erros e desvios imprevisveis. Dessa forma,
qualquer esforo no sentido de melhorar a qualidade de produto de software, deve estar engajado na
melhoria da qualidade de processo da organizao e focado intrinsecamente no produto.
2.3.2 Iniciativas para a qualidade de processo de software
Na dcada de 1990, houve uma grande preocupao com a modelagem e a melhoria do processo para a
produo de software de qualidade, dentro do prazo e com oramentos confiveis.
Algumas normas e modelos desenvolvidos na busca pela qualidade de processo de software so:
5
NBR ISO 9000-3 aplicada ao desenvolvimento, fornecimento e manuteno de software;
NBR ISO/IEC 12207 que define os processos de ciclo de vida do software;
5 Esta norma foi cancelada, e ainda no possui substituio na ABNT.

Na ISO existe a ISO/IEC 90003:2004 Software engineering -- Guidelines for the application of ISO 9001:2000 to
computer software.
30
NBR ISO/IEC 15504 sobre avaliao de processo de software, em que um modelo para
avaliao descrito na norma ISO/IEC 15504-5, e um modelo-referncia de processo
apresentado na norma ISO/IEC 15504-2;
CMMI (CHRISSIS, 2003) desenvolvido nos EUA, substituiu o CMM;
TRILLIUM modelo desenvolvido no Canad, pela Bell Canada (UHCL, 2007), em parceria com a
Bell Northern Research e Northern Telecom, com o objetivo de avaliar o desenvolvimento de
produtos e a capacidade de produo de fornecedores de produtos para telecomunicaes. Pode
ser usado tambm para melhoria de processos de desenvolvimento de software, e inclui
orientaes para sua implementao e referncias cruzadas com outros modelos, como o CMM,
no qual foi baseado o documento de descrio do Trillium.
MPS modelo de processo do software, baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC
15504 e na realidade do mercado brasileiro (www.softex.br).
No Brasil, desde 2003, existe um modelo de referncia para melhoria de processo de software
denominado MPS, o qual, entre outros propsitos, prope-se a aumentar a competitividade da indstria
brasileira de software, por meio de programas de qualificao de profissionais na rea e de melhoria e
avaliao de processos e produtos de software. Apenas a srie de normas NBR ISO/IEC 15504, o
modelo CMMI e o MPS tero um breve resumo, a seguir.
A melhoria da qualidade de processo de software deve ser o dia a dia de uma organizao de
software. Com o sucesso dessa empreitada, a previso para o incio da prxima dcada um esforo
concentrado na reduo substancial dos prazos para a entrega de produtos pelas organizaes e a
exportao do software brasileiro. A presso dos concorrentes ser intensa. Organizaes que forem
capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento e manuteno de
software tero a primazia do mercado.
2.3.2.1 NBR ISO/IEC 15504

A srie ISO/IEC 15504 - Information Tecnology Process Assessment define um modelo para avaliao
de processo e pode ser utilizada, tambm, como uma referncia para a melhoria de processo de
software. A verso nacional publicada em 2008 denominada norma NBR ISO/IEC 15504 Tecnologia da
Informao Avaliao de Processos, e composta por:
NBR ISO/IEC 15504-1 - Conceitos e vocabulrio.
NBR ISO/IEC 15504-2 - Executando uma avaliao.
NBR ISO/IEC 15504-3 - Guia executando uma avaliao.
NBR ISO/IEC 15504-4 - Guia sobre a utilizao de resultados de avaliao.
31
NBR ISO/IEC 15504-5 - Exemplo de modelo de avaliao.
Observao: As futuras normas NBR ISO/IEC 15504-6 Tecnologia da informao - Avaliao de

processo Parte 6: Exemplo de modelo de avaliao de processo de ciclo de vida de sistema e NBR
ISO/IEC 15504-7 - Tecnologia da informao - Avaliao de processo Parte 7: Avaliao de Maturidade
Organizacional esto em estudo na ABNT.
O modelo da norma NBR ISO/IEC 15504 possui uma arquitetura denominada contnua, com duas
dimenses: 1-dimenso de processos, na qual so definidos processos com as melhores prticas
especficas de cada um; esses processos so definidos por nome, propsito, objetivos, resultados
esperados, prticas e artefatos. 2- dimenso de capacidade de processo, em que so definidos os nveis
de capacidade genricos. Em cada nvel de capacidade, os processos podem estar em diferentes nveis
de maturidade. O conjunto de reas de processo, com um nvel de capacidade para cada processo,
compe um sistema.
A dimenso de capacidade de processo composta por seis nveis sequenciais e cumulativos. Cada
nvel de capacidade descrito na norma NBR ISO/IEC 15504, conforme apresentado a seguir:
Nvel 0 Incompleto: os produtos de trabalho ou os resultados dos processos so dificilmente

identificados ou no so produzidos adequadamente. O propsito do processo no satisfeito ou
no implementado.
Nvel 1 Executado: o propsito do processo normalmente atingido, embora isso no tenha,

necessariamente, sido planejado e acompanhado rigorosamente. Existe uma conscincia geral e
informal de que uma ao deve ser executada e quando isso deve acontecer. As pessoas da
organizao reconhecem que aes devem ser executadas. Os produtos de trabalho so gerados,
e existem evidncias do propsito do processo.
Nvel 2 Gerenciado: a execuo do processo planejada e acompanhada; os produtos de

trabalho so gerados conforme os procedimentos e requisitos especificados. A principal distino
em relao ao nvel Executado que a execuo do processo planejada e gerenciada, e os
produtos de trabalho satisfazem os requisitos de qualidade especificados, os prazos e recursos
necessrios.
Nvel 3 Estabelecido: o processo executado e gerenciado com base em um processo-padro

da organizao, baseado em princpios da Engenharia de software. As prticas bsicas so
executadas utilizando-se uma verso adaptada e aprovada de um processo-padro documentado.
A principal distino deste nvel relativamente ao nvel Gerenciado que o processo utiliza um
processo-padro capaz de satisfazer os resultados definidos.
Nvel 4 Previsvel: neste nvel o processo executado dentro de limites de controle definidos, de
forma consistente, para atingir os objetivos. A execuo gerenciada quantitativamente. Medies
32
detalhadas de desempenho so coletadas e analisadas, levando a um entendimento quantitativo

da capacidade do processo. A principal distino deste nvel em relao ao nvel Estabelecido
que o processo passa a ser executado consistentemente, dentro de limites definidos, para atingir
seus resultados.
Nvel 5 Em Otimizao: so estabelecidas metas de eficcia e eficincia para o desempenho do

processo, baseadas nos objetivos de negcio da organizao. Melhorias contnuas so
implementadas para satisfazer os objetivos de negcio, requerendo experincias de ideias e novas
tecnologias para satisfazer objetivos e metas definidos. A principal distino deste nvel
relativamente ao nvel Previsvel que o processo padro e o processo definido e padro passa a
ser alterado e adaptado, para atingir os objetivos de negcio da organizao. A capacidade de um
processo definida em uma escala ordinria de seis pontos, que permite a avaliao da
capacidade desde o fundo da escala (Incompleto) at seu extremo (em otimizao).
A medida da capacidade dos processos est baseada em um conjunto de Atributos de Processos (PA
Process Attributes), os quais so utilizados para determinar se um processo atingiu uma dada
capacidade. Com exceo do Nvel 0, que no possui atributos de processo, todos os demais possuem.
Os nveis de capacidade e seus atributos de processo esto apresentados na Tabela 2.2.
Tabela 2.2 Nveis de capacidade e atributos de processo
Nvel 0
Nvel 1
Nvel 2
Nvel 3
Nvel 4
Nvel 5
Processo Incompleto (no possui atributos)

Processo Executado
PA 1.1: Atributo de Execuo de Processo
Processo Gerenciado
PA 2.1: Atributo de Gerncia de Execuo
PA 2.2: Atributo de Gerncia de Produto de Trabalho
Processo Estabelecido
PA 3.1: Atributo de Definio de Processo
PA 3.2: Atributo de Implementao de Processo
Processo Previsvel
PA 4.1: Atributo de Medio de Processo
PA 4.2: Atributo de Controle de Processo
Processo em Otimizao
PA 5.1: Atributo de Inovao de Processo
PA 5.2: Atributo de Otimizao de Processo
Durante uma avaliao, as prticas genricas, agrupadas de acordo com as caractersticas comuns e
com os nveis de capacidade, so utilizadas para determinar a capacidade de um processo.
Para atribuir o nvel ao processo, um valor tem de ser fornecido a cada atributo do processo, cujos
valores esto representados na escala de medio a seguir:
33
N Not adequate (no atingido): o atributo no foi satisfeito pelo processo.
P Partially adequate (parcialmente): o atributo foi parcialmente satisfeito pelo processo.
L Largely adequate (largamente): o atributo foi amplamente satisfeito pelo processo.
F Fully adequate (completamente): o atributo foi completamente satisfeito.
A srie NBR ISO/IEC 15504 vem sendo aplicada com resultados proveitosos para as organizaes
que a utilizaram para avaliao e melhoria dos seus processos. A relao dessa norma com os modelos
de processo pode ser verificada na Figura 2.4, em que est representada sua paridade com as demais
normas e sua predominncia em relao aos modelos, que devem ser compatveis com os requisitos
dessa norma.
Figura 2.4 Relao da norma NBR ISO/IEC 15504 com os modelos de processo.
A avaliao e a melhoria dos processos fundamentais so orientadas pelos objetivos de negcio da

organizao e envolvem o planejar, gerenciar, executar, controlar e melhorar os aspectos de software
quanto a adquirir, fornecer, desenvolver, operar, efetuar manuteno e fornecer suporte.
O modelo de referncia da srie NBR ISO/IEC 15504 estabelece um conjunto universal de 40
processos fundamentais para a Engenharia de software, divididos em categorias, conforme mostra a, e
um roteiro racional para a determinao da capacidade, por meio de uma avaliao, e tambm para a
melhoria de cada processo.
Tabela 2.3 Categorias e processos da srie NBR ISO/IEC 15504 (WEBER, 2001)
Categorias
Cliente-fornecedor
Siglas
CUS.1
CUS.1.1
Processos fundamentais
Aquisio
Preparao da aquisio
34
Engenharia
Gerncia
Organizao
Suporte
CUS.1.2
CUS.1.3
CUS.1.4
CUS.2
CUS.3
CUS.4
CUS.4.1
CUS.4.2
ENG.1
ENG.1.1
ENG.1.2
ENG.1.3
ENG.1.4
ENG.1.5
ENG.1.6
ENG.1.7
ENG.2
MAN.1
MAN.2
MAN.3
MAN.4
ORG.1
ORG.2
ORG.2.1
ORG.2.2
ORG.2.3
ORG.3
ORG.4
ORG.5
ORG.6
SUP.1
SUP.2
SUP.3
SUP.4
SUP.5
SUP.6
SUP.7
SUP.8
Seleo de fornecedor
Acompanhamento do fornecimento
Aceitao pelo cliente
Fornecimento
Elicitao de requisitos
Operao
Uso operacional
Suporte ao cliente
Desenvolvimento
Anlise de requisitos e projeto de sistema
Anlise de requisitos de software
Projeto de software
Construo de software
Integrao de software
Teste de software
Integrao e teste de sistema
Manuteno de sistema e software
Gerncia
Gerncia de projeto
Gerncia da qualidade
Gerncia de riscos
Alinhamento organizacional
Melhoria
Estabelecimento do processo
Avaliao de processo
Melhoria de processo
Gerncia de recursos humanos
Infraestrutura
Medio
Reso
Documentao
Gerncia de configurao
Garantia da qualidade
Verificao
Validao
Revises conjuntas
Auditorias
Resoluo de problema
2.3.2.2 Modelo CMMI

Numa deciso entre amadurecer a verso do modelo CMM ou idealizar outro modelo adaptado, o SEI
publicou, em 2001, o CMMI Capability Maturity Model Integration, modelo que visou harmonizar alguns
componentes da famlia CMM e da srie ISO/IEC 15504, que so:
35
SW-CMM ou CMM (Capability Maturity Model for Software) Descreve os elementos importantes
de um processo de desenvolvimento de software para melhoria contnua nas empresas.
SE-CMM (Systems Engineering Capability Maturity Model) Descreve os elementos essenciais

dos processos de uma organizao, que devem existir para garantir uma boa prtica de
Engenharia de Sistemas.
IPD-CMM (Integrated Product Development) Prov um guia sistemtico para o desenvolvimento

de produtos ao longo do ciclo de vida, para melhor satisfazer as necessidades dos clientes.
A verso 1.0 do CMMI, patrocinada pelo DoD e pela NDIA National Defense Industrial Association,
foi lanada em agosto de 2000. Seu desenvolvimento foi uma integrao da indstria, do governo
americano e do SEI. As metas para o desenvolvimento do CMMI eram, alm de integrar os modelos,
eliminar inconsistncias, reduzir o custo de implementao do modelo, melhorar o entendimento do
modelo e assegurar a consistncia com a srie ISO/IEC 15504. O modelo est em melhoria contnua,
sendo as mais recentes verses:
"CMMI
for
Development"
(CMMI-DEV)
publicado
http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html
"CMMI for Acquisition" (CMMI-ACQ) publicado em

http://www.sei.cmu.edu/publications/documents/07.reports/07tr017.html
"CMMI for Services" (CMMI-SER) disponibilizada

http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html
em
em
26/08/2006,
em
novembro
de
2007,
em
fevereiro
de
2009,
em
Com o modelo CMMI, a organizao pode promover a melhoria do processo de software, por meio do
aprimoramento da capacidade dos processos ou da maturidade da organizao. O CMMI suporta essas
duas abordagens por meio, respectivamente, das representaes contnua, da mesma forma que a
norma ISO/IEC 15504, e por estgio, da mesma forma que o modelo CMM.
A representao por estgio classifica a organizao em cinco nveis de maturidade quanto ao seu
processo de software, ao passo que a representao contnua classifica os processos, e no a
organizao, em seis nveis de capacidade, a saber:
0 Incompleto
1 Realizado
2 Gerenciado
3 Definido
4 Gerenciado quantitativamente
36
5 Otimizando (sempre em otimizao)
As principais diferenas entre os modelos CMM e CMMI so:

O CMM estabelece 18 reas-chave de processo, ou KPA Key Process Areas (reas chave), e a
representao por estgio.
O CMMI estabelece 22 reas de processo, ou PA Process Areas (reas de processo), que so
classificadas em quatro categorias, listadas na Tabela 2.4.
Tabela 2.4 Categorias e reas de processo do modelo CMMI

Categorias
Gerenciamento de processo
Gerenciamento de projeto
Engenharia
Suporte
reas de Processo PA
Foco no processo organizacional
Definio do processo organizacional
Treinamento organizacional
Desempenho do processo organizacional
Inovao e melhoria organizacional
Planejamento de projeto
Acompanhamento e controle de projeto
Gerenciamento de aceite do fornecedor
Gerenciamento integrado de projeto
Gerenciamento de risco
Gerenciamento quantitativo de projeto
Gerenciamento de requisitos
Desenvolvimento de requisitos
Solues tcnicas
Integrao de produto
Verificao
Validao
Gerenciamento de configurao
Garantia da qualidade de processo e de produto
Medies e anlise
Anlise de causa e resoluo
Anlise de deciso e resoluo
A principal contribuio do modelo CMMI e da norma ISO/IEC 15504 a liberdade que se adquire,
com a representao contnua, de escolher quais processos devem ser trabalhados naquele momento,
respeitando as necessidades prioritrias e particularidades existentes em cada organizao.
37
2.3.2.3 Programa MPS.BR

No Brasil, uma iniciativa da Softex (www.softex.br), desde 2003, vem obtendo resultados positivos, no
sentido de melhorar os processos de software nas organizaes. O objetivo do programa MPS.BR a
Melhoria de Processo do Software Brasileiro, com duas metas a alcanar no mdio e longo prazos: i)
meta tcnica visando criao e aprimoramento do modelo MPS; ii) meta de mercado visando
disseminao e adoo do modelo MPS, em todas as regies do pas, em um intervalo de tempo justo, a
um custo razovel, tanto em PME Pequenas e Mdias Empresas (foco principal) quanto em grandes
organizaes pblicas e privadas. O modelo MPS possui trs componentes:
1. Modelo de Referncia para Melhoria de Processo de Software MR-MPS, que fornece uma viso
geral sobre os demais guias que apoiam os processos de avaliao e de aquisio.
2. Mtodo de Avaliao para Melhoria de Processo de Software MA-MPS, cujo propsito verificar
a maturidade da unidade organizacional na execuo de seus processos de software.
3. Modelo de Negcio para Melhoria de Processo de Software MN-MPS, um resumo executivo que
estabelece as regras de negcio e relacionamentos jurdicos dos envolvidos.
O Modelo MPS descrito nos seguintes guias, disponveis no portal www.softex.br/mpsbr:
Guia de Aquisio descreve um processo de aquisio de software e servios correlatos,

baseado na norma internacional ISO/IEC 12207: 2008, e tambm aborda relacionamentos desse
processo com o Modelo de Referncia MR-MPS.
Guia Geral contm a descrio geral do MPS e detalha o Modelo de Referncia MR-MPS e as
definies comuns necessrias para seu entendimento e aplicao.
Guia de Implementao contm orientaes para a implementao dos sete nveis do Modelo de
Referncia MR-MPS.
Guia de Avaliao descreve o processo e o Mtodo de Avaliao MA-MPS, tendo como base a
norma internacional ISO/IEC 15504.
O Guia Geral tem como base as normas ISO/IEC 12207:2008 e ISO/IEC 15504, e como complemento
o Modelo CMMI. O MR-MPS define sete nveis de maturidade:
A (Em Otimizao)
B (Gerenciado Quantitativamente)
C (Definido)
D (Largamente Definido)
38
E (Parcialmente Definido)
F (Gerenciado)
G (Parcialmente Gerenciado)
Esses nveis com menor contedo de implementao do ao modelo maior facilidade para as
empresas que desejam melhorar seus processos. A escala de maturidade se inicia no nvel G e progride
at o nvel A. Para cada um desses sete nveis de maturidade atribudo um perfil de processos os quais
indicam em que lugar a organizao deve colocar o esforo para melhoria. Obtm-se o progresso e o
alcance de um determinado nvel de maturidade MPS, quando so atendidos os propsitos e todos os
resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele
nvel. Esse material pblico, e a ele tm acesso todas as pessoas interessadas no assunto.
A motivao da Softex foi a de incluir, agregar valor ao processo das empresas, pois as empresas
brasileiras, depois dessa iniciativa, ainda esto sendo impedidas de aderir aos padres internacionais,
em funo dos altos custos praticados. Uma empresa avaliada MPS tem maiores possibilidades de obter
o nvel CMMI correspondente. O modelo MPS possui um maior nmero de nveis, o que contribui para
implementaes mais rpidas, avaliaes com menor periodicidade, resultados em menores prazos e de
modo incremental, e custos mais baixos.
A avaliao MPS tem validade de trs anos, o que garante segurana adicional a quem compra
software, pois a empresa tem de se manter atenta qualidade; caso contrrio, perde o nvel de
maturidade que havia conseguido.
Os custos da adeso ao modelo MPS so mais baixos e ainda podem ser parcialmente subsidiados.
Esse modelo est desenvolvendo no somente as empresas, mas tambm o capital humano, formando
implementadores e avaliadores, ministrando cursos com provas de capacitao, o que aumenta o nvel
das discusses sobre Engenharia de software no pas. Os resultados desse programa esto muito acima
do esperado, como pode ser visto em Resultados de desempenho de organizaes que adotaram o
modelo MPS cujos autores Guilherme H. Travassos e Marcos Kalinowski em 2008 (www.softex.br)
relatam nesse documento.
2.3.3 Comparao entre os modelos
Quanto abordagem da qualidade de software, considerando os processos de software, isto ,
processos de produzir software, existem normas e modelos para definio, avaliao e melhoria de
processos de software. A srie NBR ISO/IEC 15504 trata da avaliao de processos de software. O
modelo CMMI Capability Maturity Model Integration, desenvolvido nos Estados Unidos, define um
modelo de maturidade para empresas desenvolvedoras de software e possui seu prprio mtodo de
avaliao Standard CMMI Appraisal Method for Process Improvement SCAMPI. A norma NBR ISO/IEC
12207 define processos do ciclo de vida de software.
39
O modelo MPS, assim como o Capability Maturity Model Integration, possui seu prprio mtodo de
avaliao: MA-MPS Mtodo de Avaliao para Melhoria do Processo de Software. O guia de avaliao
descreve o processo e o mtodo de avaliao MA-MPS, com base na norma internacional ISO/IEC
15504-2: 2003. Esses modelos disponibilizam os materiais para utilizao dos interessados e propem a
avaliao da capacidade e maturidade de uma organizao, alm de indicarem diretrizes para a melhoria.
As organizaes de software so enquadradas em nveis de maturidade definidos pelos modelos.
A norma NBR ISO/IEC 12207 estabelece processos, atividades e tarefas a serem aplicados durante a
aquisio, o fornecimento, o desenvolvimento, a operao e a manuteno de software. Ela apresenta
uma definio abrangente em relao aos processos e orienta a adaptao para sua utilizao nos
projetos de software implementados em uma organizao.
Tabela 2.5 Comparao entre os modelos para processo de software
Aspectos
abordados
NBR ISO/IEC 12207
CMMI
NBR ISO/IEC 15504
MPS
Estabelecer uma terminologia e Determinar a capacitao da Conhecer e avaliar os

Melhorar os processos de software
um entendimento comum para organizao e apoiar sua processos da organizao,
nas micro, pequenas e mdias
Objetivo
os processos entre todos os evoluo de acordo com os determinar a capacitao e
empresas (PMEs), a um custo
envolvidos com software
nveis estabelecidos
promover a melhoria
acessvel, em diversos locais do pas
Definio dos processos para Avaliao dos processos e
Avaliao dos processos
aquisio, fornecimento,
enquadramento da
Avaliao dos processos da
Abordagem
da organizao em relao
desenvolvimento, operao e
organizao em um dos
organizao e
a nveis de capacitao
manuteno de software
nveis de maturidade
Organizaes que
Organizaes-alvo
Organizaes em geral
necessitam de comprovao Organizaes em geral
Organizaes em geral
formal de sua capacidade
Estabelece 22 reas de
Estabelece 43 processos,
Definio de
processos, organizados em 5
organizados em 7 reas de
organizados em 5
organizados em 7 nveis crescentes
processos
nveis crescentes de
processo
categorias
de maturidade
maturidade
Nveis com menor contedo de
Nveis e reas-chave de
Permite a definio de
Flexibilidade nos Classificao de processos pode
implementao para facilitaras
processo so a base do
perfis de processo e
aspectos definidos
ser utilizada conforme os
empresas e motivar a adeso ao
modelo e no podem ser prticas de acordo com os
pelo modelo
objetivos da organizao
modelo para as empresas que
alterados
objetivos da organizao
desejam melhorar seus processos
A srie NBR ISO/IEC 15504 pode ser utilizada por organizaes envolvidas em planejar, gerenciar,
monitorar, controlar e melhorar a aquisio, o fornecimento, o desenvolvimento, a operao, a evoluo e
o suporte de software.
Uma anlise comparativa desses modelos e normas apresentada na Tabela 2.5. Essa anlise
considera o objetivo de cada modelo e norma, o resumo de suas abordagens, o tipo de organizao a
40
que melhor se adaptam os processos de software considerados e a flexibilidade de aplicao de cada

modelo e norma.
O foco em qualidade de produto de software reporta-se ao prximo captulo, que trata das categorias
de produtos de software mais conhecidas, que ajudam na especificao e na avaliao da qualidade do
software.
41
CAPTULO 3
Categorias de produtos de software e avaliao
A evoluo da tecnologia, a abrangncia das aplicaes e a complexidade existente na produo de
produtos de software tornam a tarefa de classificar software em categorias um desafio. possvel
classificar pelo domnio de aplicao, pelo modelo de negcio, pelas mesmas caractersticas
construtivas, mesma disponibilidade de dados, entre outros critrios. Aqui esto descritas: a classificao
tradicional e classificao terica de Pressman (2002), a classificao da norma IEEE 1062 (1998), esta
ltima adotada para explicar como avaliar esse tipo de produto, e uma classificao utilizada na prtica, a
qual pode ser utilizada em eventos - por exemplo, numa premiao.
3.1 Categorias segundo Pressman

Numa pesquisa sobre classificao de produto de software, a viso de Roger Pressman (2002) ainda nos
oferece uma classificao que atende as necessidades atuais. Assim sendo, sete categorias so
apresentadas para aplicaes de software.
Software bsico caracteriza um conjunto de programas necessrios para dar apoio a outros
programas. So suas principais caractersticas: forte interao com o hardware e compartilhamento
de recursos; uso constante de processamento concorrente, que exige o escalonamento; e
estruturas de dados muito complexas. Exemplos: compiladores, editores de texto, sistemas
operacionais.
Software de tempo real caracterizado por monitorar, analisar e controlar eventos do mundo real.
Coleta dados de um ambiente externo e transforma as informaes, dependendo do tipo de
aplicao e de acordo com a necessidade do sistema; muitas vezes, ainda devolve ao ambiente
externo controles e sadas. Um software de tempo real caracteriza-se por responder dentro de
pequenos espaos de tempo. Quando esse tempo no obedecido, pode causar pssimos
resultados. So exemplos desse tipo de software: controle de navegao, controle de voo, sistema
de injeo eletrnica, sistema de direo, jogos de computador e sinalizaes.
Software comercial desenvolvido por empresas com o objetivo de lucrar com sua
comercializao. a categoria que tem a maior demanda de mercado, pois realiza a maior parte
das automaes da sociedade, oferecendo solues para as mais diversificadas prticas. Neste
software, dados so organizados de forma a facilitar as operaes comerciais e as decises
administrativas, utilizando tambm tcnicas de computao interativa. So exemplos: controle de
estoque, folha de pagamento, contas a pagar e a receber.
42
Software cientfico e de engenharia so caracterizados por algoritmos de processamento

numrico. So exemplos: sistemas de astronomia, controle da dinmica orbital de naves espaciais,
sistemas de manufatura automatizada.
Software embarcado produto usado para controlar outros produtos e sistemas, no podendo ser
tratado ou utilizado separadamente. Caracteriza-se por utilizar uma memria de leitura e usar
rotinas limitadas e particulares, sendo responsvel por toda a inteligncia instalada em alguns
equipamentos. So exemplos: controle de teclados em microondas, controle de sistemas digitais
em automveis, como painel de controle de combustvel ou sistemas de freio.
Software de computador pessoal so os programas de software utilizados em computadores de

uso pessoal. Exemplos: editores de texto, planilhas eletrnicas, gerenciamento de dados, acesso a
banco de dados, entre outros.
Software de inteligncia artificial utilizado para uso de algoritmos no numricos, para resolver
problemas complexos. Outra questo interessante da Inteligncia artificial so os sistemas
baseados no conhecimento e tambm os sistemas de reconhecimento de padres, tais como
imagem ou voz. So exemplos: sistemas com entrada pelo reconhecimento de voz do usurio,
sistemas de reconhecimento de imagens, como: digitais, foto, entre outras.
Nos termos dessas caractersticas, considera-se que os produtos tratados neste livro so os que
Pressman chamou de software comercial, o software desenvolvido por uma empresa com o objetivo de
lucrar com sua utilizao.
3.2 Caracterizaes da norma IEEE 1062

Essa norma perfeitamente aplicada para a categoria de software comercial de Pressman. uma norma
especfica para a aquisio de S&SC Software e Servios Correlatos, e est em conformidade com a
norma NBR ISO/IEC 12207. Determinar a caracterizao ou a classificao do software, entre outros
aspectos, serve para construo do modelo de qualidade e para determinar os respectivos itens de uma
avaliao.
A classificao adotada pela IEEE STD 1062 (1998), para os produtos de software, definida
conforme o grau de liberdade que tem o usurio para definir e especificar suas funcionalidades. Segundo
a norma, a Tabela 3.1 mostra que h trs tipos de produtos de software:
COTS (Commercial Off-The-Shelf-Software). Esse tipo de software desenvolvido pelo fabricante,
com os requisitos pelos quais muitos usurios podem ser beneficiados. No apresenta nada de
particular ou especfico para um cliente: todos os clientes fazem uso do mesmo produto.
MOTS (Modified Off-The-Shelf-Software). Existe um produto-padro e, a partir desse padro, sero
desenvolvidas particularidades para clientes, diferenciando o produto ao longo do tempo.
43
CUSTOMIZADO ou FD (Fully Developed Software). Neste tipo, o software totalmente

desenvolvido para o cliente. H necessidade de projeto, especificao de requisitos, entre outras
etapas do ciclo de vida de um software. Evidentemente, o produto que precisa de mais tempo
para ser desenvolvido, sendo o mais complexo em termos de aquisio, controle e aceitao pelo
cliente.
Tabela 3.1 Caractersticas de produtos de software segundo a IEEE 1062
Caractersticas
Escopo
Adequao ao uso
COTS
Fixo
Demonstrado
Manuteno
Prazo de entrega
Custo de aquisio
Qualidade (ISO/IEC 9126-1)
Sem controle
Imediato
Baixo mdio
No controlada
[1] Parcialmente ou
MOTS
Parcialmente customizado
Demonstrado em aplicaes
similares
Controle parcial
Pequeno grande
Mdio alto
Parcialmente controlada
CUSTOMIZADO ou FD[1]
Totalmente customizado
Sem precedentes
Controle total
Grande
Alto
Controlada em sua maior
parte
completamente terceirizado
Cada um desses grupos, como descrito na Tabela 3.1, tem as caractersticas de qualidade bem
determinadas. Assim, um produto chamado COTS pode ter um modelo de qualidade e ser avaliado
segundo os critrios genricos baseados nas normas. Esse modelo de qualidade e o mtodo de
avaliao sero descritos nos prximos captulos e podem ser utilizados em processos de aquisio de
software.
Um aspecto do uso de software que ilustra a diferena entre COTS e MOTS a necessidade do
MOTS de estar em constante manuteno ou evoluo. Toda falha de software indica um erro no projeto
ou no processo por meio do qual o projeto foi traduzido em cdigo executvel. Portanto, a manuteno ou
a evoluo do software envolve consideravelmente mais complexidade do que a manuteno pura e
simples. Sendo assim, esse tipo de produto pode tambm ser avaliado segundo os critrios de
manutenibilidade apresentados nas normas.
Para o software desenvolvido especificamente para um cliente, como o caso dos FDs, existe a
necessidade de montar seu modelo de qualidade, para desenvolver o produto e avaliar seu desempenho
segundo as caractersticas de qualidade tratadas nas normas, juntamente com todas as caractersticas
especficas da aplicao e do domnio ao qual pertence.
3.3 Categorias para prmios de software

Numa aplicao prtica, tratando-se de software comercial do tipo COTS, pode ser mencionado o
exemplo do PRMIO ASSESPRO (ROCHA, 2001), que foi realizado em nvel nacional, de 1990 a 1999,
44
perodo em que mais de 60 empresas e produtos das mais diversas reas de aplicao foram premiados,
tendo-se utilizado a seguinte classificao:
Categoria 1. Suporte documentao e ao planejamento: Compreende sistemas destinados
composio de documentos, organizao e manipulao de dados (valores, palavras, textos,
imagens, tabelas) e gerenciamento de atividades de planejamento. Alguns exemplos: editores de
textos, planilhas, dicionrios, gerenciadores de projeto, programas de editorao, formatadores de
relatrios, agendas eletrnicas, processadores de imagens, OCR - Optical Character Recognition e
digitalizao de documentos.
Categoria 2. Software bsico e de apoio ao desenvolvimento: Compreende sistemas que apresentam
funes de controle bsico do computador, de seus perifricos e sistemas destinados ao suporte e
desenvolvimento de programas aplicativos. Exemplos: sistemas operacionais, compiladores, redes,
servidores, geradores de aplicativos, ferramentas CASE - Computer-Aided Software Engineering,
gerenciadores de atividades computacionais, gerenciadores de arquivos e banco de dados.
Categoria 3. Sistemas de engenharia e ferramentas grficas: Sistemas que utilizam clculos de
engenharia ou clculos complexos; sistemas que renem ferramentas grficas na execuo de
suas funes; sistemas de automao industrial, monitorao e controle de processos. Exemplos:
CAD's - Computer-Aided Design, geradores de desenhos e grficos, bibliotecas de funes
grficas; programas de clculo de edificaes, pacotes estatsticos; sistemas de apoio
programao de CLP (Controlador Lgico Programvel) ou CN (Controle Numrico); sistemas de
controle de trfego, sistema de controle de processo industrial.
Categoria 4. Sistemas de informao especficos: Compreende sistemas especficos destinados
realizao da atividade-fim do usurio nas reas administrativa, comercial e financeira, em
organizaes e diversos ramos de atividades. Exemplos: folha de pagamento, controle de estoque,
vendas, contabilidade, faturamento, controle fiscal, sistemas especficos para escolas, bancos,
sade, setor jurdico, comrcio.
Essa categoria pode ser subdividida em outras categorias de domnios especficos como:
Categoria 4.1. Software de Infraestrutura: Compreende sistemas integrados destinados
infraestrutura e segurana das transaes e desenvolvimento de sistemas. Exemplos:
segurana da informao e gesto de riscos, gesto de contedo, ferramentas de apoio,
ferramentas de desenvolvimento de aplicativos, linguagens, sistemas colaborativos.
Categoria 4.2. Varejo: Compreende os sistemas de gesto de varejo. Exemplos: ponto de
vendas, emisso de cupo fiscal, nota fiscal eletrnica, sistemas de radiofrequncia, gesto
de armazm/depsito.
45
Categoria 4.3. Sade: Compreendem sistemas integrados destinados gesto hospitalar,

centros de sade e laboratrios de anlise. Exemplos: pronturio eletrnico, gesto de
centro cirrgico, administrao do paciente, sade do trabalho.
Categoria 4.4. Agropecuria: Compreende sistemas integrados destinados gesto das
atividades de agronegcio. Exemplos: gesto da plantao, gesto da colheita, gesto da
pecuria, gesto de frigorficos, controle de frotas, folha de pagamento.
Categoria 4.5. Comrcio Exterior: Compreende sistemas integrados destinados gesto do
comrcio exterior. Exemplos: gesto de processos de exportao e importao, gesto de
ptio, sistemas logsticos, gesto de armazns, gesto alfandegria.
Categoria 4.6. Sistemas Destinados Gesto Pblica: Compreende sistemas integrados
destinados gesto da administrao pblica: Exemplos: folha de pagamento, sistema
contbil, ponto eletrnico, gesto de RH.
Categoria 4.7. Sistemas Destinados a Concessionrias de Servios Pblicos: Compreende
sistemas integrados destinados gesto dos servios pblicos. Exemplos: controle de
consumo de energia eltrica, sistemas de bilhetagem, sistemas de cobrana.
Categoria 4.8. Sistemas Destinados ao Setor de Indstria: Compreende sistemas especficos do
setor de indstria. Exemplos: automao, controle da produo, modelagem e simulao,
otimizao de processos.
Categoria 5. Sistemas de informao integrados: Compreende sistemas integrados destinados
realizao da atividade fim do usurio nas suas reas de atividades e que permitam a troca
automatizada de dados com o ambiente. Exemplos: controle de ponto e/ou acesso integrado com
outros sistemas, sistemas integrados, tais como faturamento, controle financeiro, estoque, contas a
pagar.
Categoria 6. Educao e entretenimento: Compreende sistemas que visam disseminar conhecimento,
como cultura geral ou especfica e programas de entretenimento, que fornecem informaes de
forma organizada. Exemplos: cursos, jogos, enciclopdias, programas de alfabetizao e
documentrios.
Categoria 7. Software especfico para internet e intranet: Compreende sistemas que englobam
ferramentas de desenvolvimento especficas para utilizao de internet e intranet. Exemplos:
software de comunicao, segurana, construo de home page, WEB.
importante categorizar produtos de software para que se possa avaliar a qualidade do produto,
considerando o custo-benefcio de uma avaliao.
46
3.4 Avaliao de produto de software

Avaliao pode ser vista como o exame sistemtico para determinar at que ponto uma entidade capaz
de atender os requisitos especificados. Avaliar um produto de software atribuir certo valor a esse
produto, com base em requisitos pr-estabelecidos e sob demanda de um patrocinador.
Os requisitos so derivados dos modelos de qualidade definidos nas normas de produto de software,
e o patrocinador pode ser um usurio, um comprador e at mesmo o prprio desenvolvedor ou fabricante.
Os requisitos devem ser, sempre que possvel, objetivos. Se a avaliao do software for do ponto de vista
de um desenvolvedor, as caractersticas do software sero avaliadas, provavelmente, em relao a suas
qualidades intrnsecas, como por exemplo: elegncia do design, correo lgica, desempenho, robustez,
conciso, tolerncia a falhas, portabilidade. Neste caso, esses requisitos devem ser explicitados de forma
objetiva.
Se a avaliao de software for do ponto de vista de um usurio, em que as caractersticas a serem
avaliadas esto relacionadas sua aplicabilidade, utilidade, facilidade de uso, etc. A tarefa de avaliao
no deve tratar apenas das questes complexas relacionadas cincia da computao e engenharia de
software; deve, tambm, responder a questes como:
O produto satisfaz as necessidades de quem vai us-lo?
fcil de usar?
Como o seu nvel de desempenho e a quantidade de recursos utilizados?
Faz o que foi proposto de forma certa?
Est de acordo com as normas, leis do pas onde vai ser utilizado?
fcil de ser modificado?
H riscos quando se fazem alteraes no cdigo?
imune a falhas?
capaz de recuperar dados em caso de falha?
Est de acordo com padres de portabilidade?
Tais tipos de pergunta podem ser respondidos de forma sistemtica e sem a interferncia do
avaliador, ou seja, eliminando a subjetividade do processo de avaliao. Para que isso acontea, os
resultados da avaliao devem ser baseados em fatos, e no influenciados pelas opinies do avaliador.
Para software da categoria COTS, numa avaliao genrica, podem ser utilizadas as seguintes
normas aplicadas qualidade de software:
47
NBR ISO/IEC 9126-1, 2003;
NBR ISO/IEC 25051, 2008 e
A srie de normas NBR ISO/IEC 14598.
3.4.1 Mtodo de avaliao genrico (MEDE-PROS)

Um mtodo de avaliao genrico independe da categoria do software que se deseja avaliar, tratando
apenas do modelo de qualidade, explcito nas normas, de forma equalizada. Ou seja, todos os aspectos
de qualidade so avaliados tendo o mesmo valor agregado.
O MEDE-PROS Mtodo de Avaliao de Qualidade de Produto de Software foi desenvolvido para
avaliar a qualidade de produto de software, tendo como referncia as normas NBR ISO/IEC 9126 e NBR
6
ISO/IEC 12119 . Este mtodo no est especializado para nenhuma rea de domnio, sendo um exemplo
de mtodo de avaliao genrico.
O estabelecimento de normas para a avaliao da qualidade de produto de software abre a
possibilidade de existir uma base conceitual comum, que pode levar aceitao universal de avaliaes
e certificaes de produtos. Um mtodo de avaliao genrico pode ser formado por trs componentes:
1-Lista de Verificao, 2-Manual do Avaliador, 3-Modelo de Relatrio de Avaliao.
1- A Lista de Verificao uma ferramenta de avaliao que ajuda os avaliadores, durante o processo
de avaliao da qualidade de produtos de software, a realizar uma inspeo sistemtica da qualidade. A
qualidade do produto de software, decomposta hierarquicamente em um modelo que contempla as
caractersticas e subcaractersticas do produto, pode ser usada como uma lista de verificao de tpicos
relacionados com a qualidade. Pode ser elaborada tomando-se como base as normas de qualidade
citadas anteriormente. Outras normas, tais como a srie de normas ISO 9241 (1996), ANSI/IEEE 1063
(1987) e o mtodo ERGOLIST (2008) tambm ajudaram na criao dessa Lista de Verificao.
Essa lista pode ser composta por um conjunto de atributos; e esses, por um conjunto de questes. Em
um processo de avaliao de software, os seguintes elementos que compem um software podero ser
avaliados: embalagem, descrio do produto, documentao do usurio, interface e software. Entretanto,
nem sempre os produtos submetidos a um processo de avaliao apresentam todos esses elementos.
Exemplo desse fato so os produtos fornecidos pela internet: no apresentam embalagem, uma vez que
os compradores os obtm realizando um simples download. Cada um desses elementos pode ser
descrito conforme segue:
A embalagem um meio fsico que acondiciona a mdia e documentos impressos.
O MEDE-PROS foi concebido com a NBR ISO/IEC 12119, e sua ltima verso de 2006.
48
A descrio do produto um documento expondo as propriedades do software, com o objetivo de

auxiliar potenciais compradores na avaliao de adequao, antes da aquisio.
A documentao do usurio o conjunto completo de documentos. Est disponvel ao usurio na

forma impressa ou no, sendo fornecida para auxiliar na utilizao dos produtos de software.
A interface permite que as informaes sejam transferidas entre o usurio e os componentes de

hardware ou software de um sistema computacional.
O software propriamente dito so as instrues (programas de computador) que, quando

executadas pelo usurio, produzem a funo e o resultado esperados.
A Figura 3.1 mostra a estrutura bsica de uma lista de verificao e onde as normas de qualidade
contriburam para sua construo, permitindo que os elementos dos produtos de software considerados
pudessem ser avaliados adequadamente. Cada um desses componentes se subdivide pelas
caractersticas de qualidade, pelas subcaractersticas, pelos atributos, at que se obtenham questes
objetivas.
Figura 3.1 Estrutura da lista de verificao de um mtodo de avaliao (MEDE-PROS)
A srie de normas NBR ISO/IEC 14598 no aparece na figura porque ela fornece orientaes para a
realizao do processo de avaliao, e esse processo ser apresentado posteriormente, em um captulo
dedicado exclusivamente ao assunto. Como a avaliao do produto de software se baseia na
49
comparao do produto com alguns requisitos, ou ainda com necessidades explcitas e implcitas dos
usurios, o trabalho realizado durante a elaborao de um mtodo o de transformar o modelo de
qualidade, presente nas normas, em atributos; e os atributos, em um conjunto de questes, de tal forma
que, avaliando o atributo por meio do conjunto de questes associadas, seja possvel julgar o
atendimento ou no atendimento do atributo.
2- O Manual do Avaliador deve conter um conjunto de informaes para a utilizao da lista de
verificao, durante a avaliao da qualidade de um produto de software, e fornecer diretrizes e
recomendaes para a execuo do processo de avaliao. Nesse manual so encontrados: explicaes
e exemplos de alguns atributos presentes na lista de verificao, para uma melhor compreenso do
aspecto a ser avaliado; as convenes utilizadas na lista de verificao; as diretrizes para a execuo da
avaliao; regras e obrigaes dos avaliadores se for o caso de uma avaliao profissional; informaes
sobre o preenchimento da lista de verificao; o material utilizado na avaliao; o procedimento da
avaliao, com sugesto de uma sequncia de passos adequada ao processo; orientaes para a
elaborao do relatrio de avaliao e um glossrio contendo explicaes dos termos utilizados na lista
de verificao.
3- Para apresentar o resultado obtido durante o processo da avaliao, pode existir um terceiro
componente o modelo de relatrio da avaliao (Apndice C). O relatrio da avaliao nada mais do
que um laudo tcnico sobre a qualidade do produto de software avaliado, do ponto de vista de um
usurio final. Ele apresenta o resultado da avaliao, de acordo com a especificao estabelecida entre o
solicitante e o responsvel pela avaliao. Esse relatrio destaca os aspectos do produto de software que
atendem as normas de qualidade de software e os aspectos a serem revistos, originados das no
conformidades encontradas durante a avaliao. Um conjunto de sugestes fornecido, no final desse
relatrio, ao solicitante da avaliao, visando adequao do produto s normas de qualidade de
software, aos requisitos especificados e consequente melhoria do produto de software a ser fornecido ao
mercado.
Alm das informaes sobre a qualidade do produto de software avaliado, outras informaes podem
ser apresentadas no incio do relatrio, com o objetivo de fornecer ao solicitante da avaliao uma viso
genrica do processo realizado, tais como:
o escopo da avaliao, que foi definido durante a fase de Especificao da avaliao, como
recomendado pela norma NBR ISO/IEC 14598-5;
a base terica utilizada, ou seja, as normas de modelo de qualidade de produto de software;
o processo de avaliao, executado de acordo com as fases recomendadas pela norma NBR
ISO/IEC 14598-5 Anlise de requisitos da avaliao, especificao da avaliao, projeto da
avaliao, execuo da avaliao e concluso da avaliao;
os elementos do produto de software que foram avaliados;
50
a quantidade de horas e de avaliadores envolvidos no processo;

o ambiente computacional utilizado na realizao da avaliao, comparado com o sugerido pelo
solicitante.
Essa metodologia seguiu a abordagem de uma lista de verificao, sendo possvel o desenvolvimento
de outros tipos de metodologias para avaliar produtos de software. O importante que se preserve a
repetibilidade, a reprodutibilidade, a imparcialidade e a objetividade, sendo que uma das dificuldades de
uma avaliao de produto de software eliminar a subjetividade dessa avaliao.
Uma prtica adotada no ciclo de evoluo do MEDE- PROS o que se denomina meta-avaliao.
Consiste basicamente na comparao das avaliaes realizadas pelos pares de avaliadores, no sentido
de analisar estatisticamente se as respostas da avaliao do mesmo produto so consistentes. Com essa
anlise estatstica, feita uma reviso da lista de verificao, com a ajuda dos avaliadores, no sentido de
torn-la mais clara e objetiva. Essa prtica se mostra til, no sentido de tornar o mtodo cada vez mais
prximo das caractersticas citadas no pargrafo anterior.
3.4.2 Mtodo de avaliao especialista
Segundo Rocha, 2001, sistemas especialistas so sistemas cujo objetivo a resoluo de problemas em
um domnio especfico, por meio da explorao de uma base de conhecimento e de um mecanismo de
raciocnio. Para sistemas especialistas ou produto de software pertencente a um domnio especfico
CUSTOMIZADOS/FDs, ou seja, produtos que possuem certas caractersticas, como escopo totalmente
customizvel, desenvolvido um mtodo de avaliao a partir de suas especificaes de requisitos
funcionais e no-funcionais.
Para elaborao de um mtodo dessa natureza, necessrio apresentar a base terica das normas
de qualidade existentes para produtos de software genrico e, alm disso, contemplar toda a
especificao de requisitos do software em questo.
Um mtodo de avaliao chamado de especialista quando tem por objetivo avaliar um produto de
software desenvolvido para uma rea de domnio especfico. Uma das atividades realizadas durante a
elaborao de um mtodo de avaliao especialista consiste em entrevistas com os provveis usurios
do sistema e com especialistas da rea. Essa atividade uma das mais importantes e visa verificar se o
sistema a ser desenvolvido, ou aquele que j est concludo, atende as necessidades explcitas e
implcitas dos usurios do sistema, de tal forma que suas expectativas sejam atingidas. Esse processo de
entrevistas denomina-se explorao da base de conhecimento.
Um mtodo de avaliao especialista pode ser desenvolvido para diversos fins, estando o momento
adequado para sua elaborao diretamente vinculado ao objetivo da avaliao. Existem dois tipos de
avaliao para o software: a avaliao realizada ao longo do processo de desenvolvimento do software,
51
em que podero ser avaliados os artefatos gerados (ou produtos intermedirios) e/ou a avaliao do
produto final, sendo esta ltima a mais comum.
Para a criao de um mtodo de avaliao especialista, devem ser considerados, alm das
caractersticas de qualidade, os aspectos inerentes ao domnio da aplicao, as tecnologias especficas
utilizadas no desenvolvimento do produto e o ambiente no qual o produto de software ser inserido.
Para a criao de um mtodo de avaliao para produtos de software, seja ele genrico ou
especialista, devem sempre ser considerados os requisitos funcionais e os requisitos no funcionais
especificados para o desenvolvimento do produto de software.
Um mtodo de avaliao especialista trata as caractersticas de qualidade de forma geral, ficando
muitas vezes a cargo da experincia do avaliador a realizao de algumas avaliaes especficas,
principalmente aquelas relacionadas com as funcionalidades do sistema, o que torna a avaliao
bastante subjetiva, no contexto de requisitos funcionais do software. A Figura 3.2 mostra uma estrutura
contendo os elementos considerados para um produto de software, as caractersticas de qualidade
verificadas nesses componentes e destaca as partes a serem desenvolvidas em um mtodo de avaliao
especialista, a fim de tornar uma avaliao menos subjetiva e menos dependente da experincia do
avaliador. O mtodo aqui apresentado derivado do mtodo genrico; entretanto, o desenvolvimento dos
detalhes da funcionalidade em todos os componentes do mtodo proveniente do domnio de aplicao.
52
Figura 3.2 Estrutura a ser desenvolvida numa avaliao especialista.
O mtodo de avaliao de software aplicativo, do tipo CUSTOMIZADO/FDs, nos diferentes domnios

de aplicao, deve contar com o apoio de especialistas, seja em informtica, seja no respectivo domnio,
trabalhando conjuntamente. Avaliaes de domnio especfico apresentam uma proposta para a
construo de um mtodo de avaliao especialista, para produtos de software, baseado na
especificao de requisitos encontrada, por exemplo, no contedo de editais. Esse tipo de mtodo visa
avaliar o produto de software na sua totalidade, considerando-se tanto os requisitos funcionais como os
requisitos no funcionais.
Para o contexto do mtodo especialista, foram utilizados os conceitos existentes para qualidade de
software presentes:
7
Nas normas NBR ISO/IEC 9126-1, NBR ISO/IEC 12119 e NBR ISO/IEC 14598-5;
No MEDE-PROS, considerando-se sua estrutura, base terica e vasta utilizao;
A NBR ISO/IEC 12119 foi substituda pela NBR ISO/IEC 25051, em 2008.
53
Na experincia do projeto especfico denominado PNAFM Programa Nacional de Apoio Gesto

Administrativa e Fiscal dos Municpios Brasileiros, que continha um processo de avaliao regido
por um edital, em conjunto com a Lei N 8.666 (MAITINGUER, 2004).
As contribuies do projeto citado abrangem a divulgao dos conceitos existentes para qualidade de
software, a utilizao desses conceitos na elaborao de um edital e de um mtodo de avaliao
especialista para produtos de software.
3.5 Avaliao e certificao de produto de software

Quando se fala em qualidade de software, importante abordar as seguintes questes: Como avaliar a
qualidade de software? e Existe certificado de qualidade de software? Para esclarecer essas questes,
importante ressaltar as definies: Avaliao da qualidade exame sistemtico de quanto uma
entidade capaz de atender os requisitos especificados. Certificao de software emisso de um
certificado de conformidade de um software a certo conjunto de normas ou especificaes. Para obter
uma certificao necessria a realizao de uma avaliao, atendendo a conformidade de requisitos, e
emitido um laudo ou certificado.
A sociedade est comeando a exigir que o software usado em sistemas crticos tenha padres
mnimos de segurana e de confiabilidade. Os fabricantes desses sistemas esto em posio no
confortvel, por no existir um guia a respeito do que pode ser considerado como padres aceitveis
nessas situaes. Mesmo nos lugares em que os sistemas no so de misso crtica, os produtores do
software e seus clientes esto se tornando interessados nos mtodos para assegurar a qualidade que
possam resultar no software fornecido com as respectivas garantias. Em agosto de 2006 houve, na
McMaster University, em Hamilton ON, Canad, o International Workshop on Software Certification
(Certsoft, 2006), para tratar do assunto.
No Japo, o interesse em certificao de software est aumentando, principalmente em trs reas da
indstria de software: a indstria de equipamento de controle de segurana, a indstria automotriz e a
indstria de instrumentos de medio. Outra dimenso carente de certificao o DBC desenvolvimento de software baseado em componentes. Essa tecnologia de desenvolver software tenta
dinamizar suas tarefas no desenvolvimento das aplicaes que contm invariavelmente sistemas de
terceira parte, chamados Commercial Off-The-Shelf (COTS), com funcionalidade de caixa preta. Quando
integradas, as aplicaes requerem a certificao de segurana. Os componentes COTS, quando
individualmente certificados, ainda assim podem introduzir vulnerabilidades no sistema, se seus
mecanismos de segurana estiverem malcombinados (CERTSOFT, 2006).
Para certificao de produtos de software, podem-se adotar as normas NBR ISO/IEC 14598-1 e, mais
especificamente para Pacotes de Software, pode-se utilizar a norma NBR ISO/IEC 25051. Porm ainda
no existe um certificado para produto de software, ou seja, no existe um rgo que seja um laboratrio
54
de avaliao credenciado pelo INMETRO Instituto Nacional de Metrologia, Normalizao e Qualidade

Industrial, ou por outras instituies semelhantes, para emitir um certificado de qualidade de produto de
software. Essa situao semelhante em outros pases; pode-se encontrar certificao de software para
algum domnio especfico em que se exigem requisitos criteriosos especficos da rea, como, por
exemplo, na rea aeroespacial.
Algumas iniciativas para as questes de certificao de software no Brasil j esto sendo realizadas.
Como exemplo, o Painel Setorial - Acompanhamento de Mercado por Agentes Externos no Programa
8
Nacional de Certificao de software e servios -, organizado pelo Inmetro em 31 de maio de 2007 .
Na prtica, alguns projetos foram realizados com o intuito de impulsionar a evoluo do assunto.
Assim, podem ser citadas as seguintes realizaes:
O projeto SCOPE Software CertificatiOn Programme in Europe (SCOPE, 2009), como j foi citado, e
o livro de Bache e Bazzana foram os que mais influenciaram na elaborao de normas na rea de
qualidade de software, motivando toda a comunidade a estabelecer um padro consensual sobre a
questo da qualidade de produto de software (BACHE, 1994).
O Projeto SQUAD Software Quality Abroad Different regions (SQUAD, 2009), que teve uma durao
de trs anos, entre 1998 e 2001, uniu-se a instituies que pesquisam e aplicam a qualidade de software
na Europa e na Amrica Latina, com o objetivo de trocar experincia e divulgar o trabalho e os resultados
em cada regio dos participantes. Esse projeto pde avaliar a experincia da aplicao das normas de
Qualidade de Produto de Software e do Modelo CMM em casos reais.
No Brasil, uma experincia de aplicao das normas de qualidade de produto de software foi realizada
na avaliao de software no prmio Melhor software do ano, pelo qual o Centro de Tecnologia da
Informao Renato Archer CTI/MCT e a ASSESPRO Associao das Empresas Brasileiras de
Tecnologia da Informao, Software e Internet foram os responsveis. As informaes detalhadas
sobre este caso prtico foram publicadas no Captulo 13 do livro Qualidade de Software Teoria e
Prtica (ROCHA, 2001). Esse trabalho teve cinco edies, nos anos de 1993, 1994, 1995, 1996 e 1998,
com aproximadamente um total de 180 avaliaes de produtos de software, os quais foram distribudos
em seis categorias de software: Sistemas de suporte documentao e ao planejamento, Software
bsico e de apoio ao desenvolvimento, Sistemas de engenharia e ferramentas grficas, Sistemas de
informao especficos, Sistemas de informao integrados e Educao e entretenimento. Tal trabalho
tambm propiciou o desenvolvimento e a evoluo do mtodo de avaliao da qualidade de produtos de
software MEDE-PROS e tambm uma grande difuso, entre as empresas de software participantes
do evento, dos conceitos e requisitos definidos nas normas de qualidade de software.
http://www.inmetro.gov.br/noticias/conteudo/programaSoftware.htm
55
Com essa experincia prtica de avaliao de produto, o assunto evoluiu para que os processos de
produo de software fossem trabalhados com maior sistematizao, mostrando a interdependncia da
qualidade do produto durante sua produo.
A avaliao do processo de desenvolvimento de software consiste no exame dos procedimentos
operacionais e gerenciais, mtodos e tcnicas utilizados nas fases de desenvolvimento de um produto de
software, com o objetivo de identificar prticas que possam provocar problemas na qualidade do produto
e de estabelecer novas prticas que evitem esses problemas. Procura-se avaliar como est sendo
desenvolvido o software, por meio das seguintes disposies: verificao de gerenciamento de
configurao e controle de verses (manutenibilidade); adequada organizao de testes e procedimentos
para controle de mudanas (confiabilidade); cuidadosa e correta elaborao de testes internos, que
possam auxiliar no processo de reviso das funes (funcionalidade).
A avaliao do processo proporciona uma expectativa de gerao de produtos melhores; entretanto,
no garante a qualidade do produto final. Os dois tipos de avaliao so necessrios e complementares
e, embora distintos, com tcnicas e mtodos especficos, objetivam garantir a qualidade do produto final.
As propostas de avaliao do processo de desenvolvimento e dos produtos finais e intermedirios tm
o objetivo final de melhorar a qualidade do produto em uso, ou seja, o grau em que o produto pode ser
usado por usurios especficos, para alcanar objetivos especificados com eficcia, eficincia e
satisfao, em um contexto especfico de uso. A qualidade em uso pode ser medida por meio da
operao do produto final em condies de uso normal ou simuladas, com o objetivo de verificar a
existncia e o nvel das caractersticas de qualidade de um produto de software, conforme definidas na
norma NBR ISO/IEC 9126-1.
A avaliao do produto de software consiste no exame de um produto final resultante de um processo
de desenvolvimento de software, ou de produtos resultantes de atividades de fases intermedirias desse
processo. Dentre muitas razes, deve-se avaliar a qualidade do produto final para:
a) identificar e entender as razes tcnicas para as deficincias e limitaes do produto, que podem
manifestar-se na ocorrncia de problemas operacionais ou de manuteno;
b) comparar um produto com outro, mesmo que indiretamente;
c) formular um plano de ao sobre como fazer o produto de software evoluir.
O processo de avaliao da qualidade de um produto de software contm os procedimentos para
medies em uso, que incluem mtodos de anlise sobre artefatos estticos por exemplo, verificao
da documentao do usurio e de anlise de produtos em operao na qual a avaliao obtida por
meio de teste de integrao, teste de desempenho, teste de aceitao e a execuo dos programas, por
exemplo.
56
Dessa forma, a qualidade de um produto de software resultante das atividades realizadas no

processo de seu desenvolvimento. Avaliar a qualidade de um produto de software verificar, por meio de
tcnicas e atividades operacionais, o quanto os requisitos so atendidos. Tais requisitos, de maneira
geral, so a expresso das necessidades, explicitadas em termos quantitativos ou qualitativos, e tm por
objetivo definir as caractersticas de um software, a fim de permitir o exame de seu atendimento.
O tema tem sido tratado de forma mais especfica, motivando vrias iniciativas para o
desenvolvimento de mtodos e ferramentas para sua avaliao, dentro das respectivas vises do
usurio, do desenvolvedor e do comprador. consenso que tais vises so consideradas
complementares tanto quanto a viso da Qualidade de Processo e Qualidade de Produto de Software.
A qualidade de software deve ser avaliada durante seu processo de desenvolvimento. Em seguida,
deve ser avaliado o produto gerado e, finalmente, o produto em uso, pois a qualidade do processo
influencia a qualidade do produto e, da mesma forma, a qualidade do processo pode ser aprimorada a
partir da medio da qualidade do produto, como mostra a Figura 3.3.
Figura 3.3 Qualidade de software durante seu desenvolvimento (Fonte:NBR ISO/IEC 9126-1)
Medidas no processo de desenvolvimento devem ser obtidas de acordo com requisitos exigidos na
norma NBR ISO 9001, ou nos processos definidos no modelo CMMI, na norma NBR ISO/IEC12207, na
norma NBR ISO/IEC 15504 e no modelo MPS.
Medidas no produto de software podem ser classificadas como medidas internas, externas ou em uso:
Medidas internas Medem atributos internos pela anlise das propriedades estticas dos produtos
de software intermedirios ou preparados para entrega. Medidas internas podem ser aplicadas a
um produto de software no-executvel, tais como uma especificao ou cdigo-fonte,
respectivamente, durante o projeto e a codificao alguns exemplos esto descritos na norma
ISO/IEC 9126-3. Exemplo: o nmero de linhas de cdigo, as medidas de complexidade e o nmero
de defeitos encontrados em uma reviso, so todas medidas de qualidade interna de software
executadas no prprio produto.
57
Medidas externas Medem o comportamento do sistema do qual o software uma das partes,
pela realizao de teste, operao e observao do software executvel ou do sistema. Alguns
exemplos dessas medidas esto descritos na norma ISO/IEC 9126-2. Esse documento define
exemplos de medidas externas que se associam a atributos de qualidade e que podem ser uma
referncia inicial, facilitando a tarefa de definir atributos.
Medidas de qualidade em uso Medem quanto um produto atende s necessidades de usurios

especificados, para que estes atinjam metas especificadas com eficcia, produtividade, segurana
e satisfao, em um contexto de uso especificado. A avaliao de qualidade em uso valida a
qualidade do produto de software em cenrios de uso especficos. Mostram a viso do usurio
sobre qualidade, em um ambiente contendo software, e so medidas por meio dos resultados do
uso do software em ambientes, e no pelas propriedades do software. Exemplos de medidas de
qualidade em uso so apresentados no relatrio tcnico ISO/IEC 9126-4.
3.6 Avaliao e teste de software

Durante a produo de um software, necessrio saber se o produto est de acordo com os requisitos
especificados e tambm se obedece s normas sobre qualidade. Teste de software a atividade de
executar um software com o objetivo de encontrar diferenas entre os resultados obtidos e os resultados
esperados. O ciclo de vida clssico de um software tem as fases representadas na Figura 3.4, e uma
dessas fases Teste.
58
Figura 3.4 Ciclo de vida clssico para desenvolvimento de software.
O processo de testes de software apresenta uma estruturao em etapas, atividades, artefatos,

papis e responsabilidades que buscam a sistematizao dos procedimentos e controle dos projetos de
testes. Existem vrios tipos de testes, entre eles: Teste de Unidade - testa os mdulos do software; Teste
de Integrao - testa a integrao dos mdulos; Teste de Validao - testa a validao do produto em
relao aos requisitos; Teste de Sistema - testa o sistema como um todo; Teste de Regresso - testa o
sistema aps modificaes. No ser tratado em detalhes aqui, pois existem muitos autores trabalhando
nesse assunto. Teste feito durante o desenvolvimento do produto.
Avaliao tem outro propsito, que observar, com a viso do usurio, o quanto aquele produto de
software atende suas expectativas.
As atividades de teste e de avaliao de software devem ser aplicadas nos projetos de
desenvolvimento de software, cada uma com sua especificidade e momento adequado.
Modelos de qualidade tericos e prticos - e as normas de qualidade de produto sero assuntos do
prximo captulo.
59
CAPTULO 4
Modelos de qualidade
Este captulo apresenta modelos de qualidade para produtos de software advindos de pesquisa terica e
da prpria aplicao desses modelos em projetos e objetivos especficos originrios da demanda do
mercado.
Em relao aos modelos tericos, um dos primeiros o modelo da qualidade apresentado por Jim
McCall et al, conhecido tambm como o modelo da General Electric, de 1977.
Outro modelo especfico surgiu da elaborao da norma ISO/IEC 9126-1, que envolveu cerca de duas
dezenas de profissionais especializados de empresas, universidades e centros de pesquisa do mundo
todo, que j aplicavam os conceitos em suas atividades profissionais, antes mesmo de o texto final ser
aprovado como projeto de norma.
A integrao crescente da economia mundial est uniformizando os conceitos de qualidade e, em
consequncia, tem exigido a utilizao de textos normativos comuns a todos os pases. Esse foi um dos
motivos que levaram a Comisso de Estudo de Qualidade de Software a estabelecer como norma NBR
ISO/IEC 9126-1, 2001 a traduo do texto-base da norma ISO/IEC 9126-1, 1996 Information technology
Software product quality, em vez de criar uma nova norma.
Uma reviso e uma nova abordagem das normas para qualidade de produto de software esto sendo
trabalhadas no projeto SQuaRE Software Quality Requirements and Evaluation (Requisitos e Avaliao
da Qualidade do Software). O trabalho ocorre no mbito do ncleo e extenso das normas, de 1999 a
2002, com a proposta aprovao na ISO, que em 2005 teve a primeira norma da srie publicada: a
norma ISO/IEC 25000 Guide to SQUARE: 2005 e no Brasil a respectiva NBR ISO/IEC 25000
Engenharia de Software - Requisitos e Avaliao da Qualidade de Produtos de Software (SQuaRE)
Guia do SQuaRE, em 2008.
Em relao aos modelos advindos das aplicaes prticas desenvolvidas no mbito do CTI, que foram
baseados nos modelos tericos citados, sero apresentados o modelo de qualidade do MEDE-PROS e
outros como sua derivao: modelo de qualidade do PNAFM e modelo de qualidade de componentes de
software.
60
4.1 Modelo de McCall

Este modelo, assim como outros modelos contemporneos, teve origem nos meios militares americanos
e foi utilizado, primeiramente, pelos seus desenvolvedores, para o processo do desenvolvimento de seus
sistemas. O modelo McCall da qualidade tenta estabelecer uma ligao entre usurios e
desenvolvedores, focalizando nos fatores de qualidade do software que refletem as opinies dos usurios
e as prioridades dos desenvolvedores. O modelo da qualidade de McCall tem, como mostra a Figura 4.1,
trs perspectivas principais para definir e identificar a qualidade de um produto de software: reviso do
produto (habilidade de se submeter a mudanas), transio do produto (adaptabilidade a novos
ambientes) e operao do produto (suas caractersticas da operao).
Figura 4.1 Modelo de qualidade de McCall, organizado em funo de trs tipos de caractersticas da
qualidade.
MacCall define um modelo de qualidade de forma hierrquica, com 11 fatores de qualidade. Cada um
dos fatores se subdivide em 23 critrios de qualidade, que ainda podem ser subdivididos em medidas de
controle, as quais no esto definidas nesse modelo. Os fatores descrevem a viso externa do software,
com a viso do usurio.
Para reviso do produto:
Manutenibilidade esforo exigido para localizar e reparar erros em um programa. O software

fcil de ser corrigido?
61
Flexibilidade esforo exigido para modificar um programa j em utilizao. O software

facilmente altervel?
Testabilidade esforo exigido para testar um programa frente a suas pretensas funes. O
software pode ser testado facilmente? (a facilidade de testar o software, para se assegurar de que
seja isento de erros e de acordo com sua especificao).
Para transio do produto para outra plataforma:
Portabilidade esforo exigido para transferir um software de um ambiente (software e hardware

ou arquitetura tecnolgica) para outro. O software pode ser utilizado facilmente em outro ambiente?
Reusabilidade medida na qual um programa facilmente reusado em um contexto diferente. O

software pode ser reaproveitado facilmente?
Interoperabilidade esforo requerido para acoplar o software a outro sistema. O software

facilmente acoplvel?
Para operao do produto:
Exatido ou Correo medida na qual o software cumpre sua especificao e objetivos previstos
pelo cliente. O software faz aquilo que o usurio deseja?
Confiabilidade medida na qual o programa executa a funo pretendida com a preciso exigida.
O software preciso?
Eficincia quantidade de recursos de hardware e cdigo exigidos para que um programa execute
sua funo (eficincia da execuo e do armazenamento, e geralmente em fazer uso dos recursos;
por exemplo: tempo de processador, armazenamento). Ele roda bem em seu ambiente? Ele
funciona rapidamente nas especificaes recomendadas?
Integridade medida na qual o acesso ao software ou aos dados por pessoas no autorizadas
pode ser controlado. Existe proteo do software para acesso sem autorizao? Os dados podem
ser modificados por pessoas no autorizadas?
Usabilidade esforo do usurio para aprender a operar, preparar a entrada e interpretar a sada
de um programa de software. O software foi projetado para o usurio?
Os fatores de qualidade descrevem tipos diferentes de caractersticas comportamentais do software, e

os critrios de qualidade so atributos a um ou mais dos fatores de qualidade. A ideia do modelo de
qualidade de McCall que os fatores de qualidade sintetizados devem fornecer um retrato completo da
qualidade do software.
Os 11 fatores de qualidade resumidamente so: exatido, confiabilidade, eficincia, integridade,
usabilidade, manutenibilidade, testabilidade, flexibilidade, portabilidade, reusabilidade, interoperabilidade.
62
Os fatores de qualidade so subdivididos nos seguintes critrios de qualidade de software segundo

McCall:
Auditabilidade medida da facilidade com que se pode verificar a conformidade a padres.
Acurcia medida da preciso dos tratamentos e do controle.
Padres de comunicao medida em que padres de interfaces de mquina, protocolos e

larguras de banda so usados.
Inteireza medida de quanto a implementao total da funo pretendida foi conseguida.
Conciso medida da compactao do programa, em termos de linhas de cdigo por funo.
Consistncia medida do uso de tcnicas de projeto e documentao uniformes ao longo do ciclo

de desenvolvimento do software.
Padres de dados medida do uso de padres de estruturas e tipos de dados.
Tolerncia a erros medida dos danos que ocorrem quando o programa executa um erro.
Eficincia de execuo medida do desempenho de um programa, em tempo de operao.
Expansibilidade medida da possibilidade de o projeto ser estendido.
Generalidade medida da amplitude da aplicabilidade dos componentes de um programa.
Independncia de hardware medida de quanto o software desvinculado do hardware em que

opera.
Instrumentao medida de quanto o programa monitora sua prpria operao e identifica os

erros que venham a ocorrer.
Modularidade medida da independncia funcional dos componentes de um programa.
Operabilidade medida da facilidade de operao de um programa.
Segurana medida da disponibilidade de mecanismos que controlem ou protejam programas e

dados.
Autodocumentao medida de quanto o cdigo-fonte apresenta documentao significativa.
Simplicidade medida de quo facilmente o programa entendido.
Independncia do software bsico medida de quanto o programa independente de

particularidades no padronizadas da linguagem de programao, de sistemas operacionais e de
ambientes.
63
Rastreabilidade medida da possibilidade de rastrear as decises de projeto, desde sua anlise

como requisito at sua implementao como componente.
Treinamento medida da capacidade do software de auxiliar novos usurios na utilizao do

sistema.
Eficincia de armazenamento medida relacionada ao armazenamento dos dados.
Controle de acesso barreiras de segurana apropriadas.
Outro modelo, similar ao de McCall, surgiu em 1978, com o nome de Modelo de Boehm. Apresenta
um modelo hierrquico de qualidade, estruturado em torno de caractersticas de alto nvel, de
caractersticas de nvel intermedirio e de caractersticas primitivas - cada uma dessas caractersticas
contribuindo para a qualidade do produto de software.
Embora os modelos de McCall e de Boehm possam parecer muito similares, existem diferenas com
relao hierarquia das caractersticas. Entretanto, pode-se afirmar que foram esses modelos que
inspiraram os atuais modelos de qualidade apresentados na norma e foram o incio dos estudos aqui
apresentados.
4.2 O modelo da norma NBR ISO/IEC 9126-1

O objetivo do Total Quality Management - TQM, que o de prover as necessidades dos clientes agora e
no futuro, e com a definio da norma NBR ISO/IEC 9126-1 sobre qualidade de software como sendo a
totalidade das caractersticas de um produto de software, que lhe confere a capacidade de satisfazer s
necessidades explcitas e implcitas, possvel visualizar a relao existente entre o TQM e a norma
NBR ISO/IEC 9126-1.
Se, por um lado, desde o inicio do modelo CMM, a partir dos conceitos do TQM, procura garantir a
qualidade do insumo, ou entradas, e do processo de software, por outro, a norma NBR ISO/IEC 9126-1
est preocupada em garantir que as necessidades dos clientes, em relao ao produto de software,
sejam providas. Esta norma define quais so as caractersticas que um produto de software deve ter e
fornece um modelo para ser utilizado em uma avaliao de verificao da presena de tais
caractersticas. Isso significa que, a partir de uma entidade de software, disponvel a um usurio,
possvel utilizar a norma para verificar a qualidade dessa entidade.
As sries de normas NBR ISO/IEC 9126 NBR ISO/IEC 14598 e a norma NBR ISO/IEC 25051 tratam
de trs assuntos importantes: modelo de qualidade, processo de avaliao, avaliao de pacotes de
software.
64
A seguir, a norma que trata modelo de qualidade ser apresentada por meio de sua prpria estrutura,
ou seja, sero apresentadas suas diretrizes de uso, as caractersticas de qualidade de produto de
software e o modelo sugerido para avaliao.
4.2.1 Diretrizes para uso da norma NBR ISO/IEC 9126-1
Esta norma pode ser aplicada nos seguintes momentos:
Definio dos requisitos de qualidade de um produto de software.
Avaliao da especificao de software para verificar se ele ir satisfazer aos requisitos de

qualidade durante o desenvolvimento.
Descrio de particularidades e atributos do software implementado, por exemplo, em manuais de

usurio.
Avaliao do software desenvolvido, antes da entrega.
Avaliao do software desenvolvido, antes da aceitao.
A seguir, so apresentadas as caractersticas de qualidade de software que devem ser consideradas

em cada um dos momentos citados anteriormente.
4.2.2 Caractersticas e subcaractersticas de qualidade de software
O modelo de qualidade apresenta uma estrutura hierrquica, definindo caractersticas, subcaractersticas
de qualidade e atributos, como mostra a Figura 4.2, de uma forma genrica.
65
Figura 4.2 Modelo bsico de qualidade.
Sabe-se, no entanto, que as caractersticas da qualidade definidas por essa norma no so

diretamente mensurveis. necessrio um desdobramento das caractersticas em nveis mais
especficos, at chegar a um ponto em que se consiga obter uma medida objetiva.
O modelo de qualidade apresentado na Figura 4.2 pode ser aplicvel na fase de definio de
requisitos de qualidade de um software a ser desenvolvido, e tambm na fase de aceitao de produtos
avaliando produtos intermedirios e o produto final.
Os modelos de qualidade geralmente representam a totalidade dos atributos do software classificados
em uma estrutura de rvore hierrquica de caractersticas e subcaractersticas. O nvel mais alto dessa
estrutura composto pelas caractersticas de qualidade, e o nvel mais baixo composto pelos atributos
de qualidade do software. Esta norma fornece um modelo de propsito geral, o qual define seis amplas
categorias de caractersticas de qualidade de software: funcionalidade, confiabilidade, usabilidade,
eficincia, manutenibilidade e portabilidade. Estas podem ser subdivididas em subcaractersticas que
possuem atributos mensurveis. O efeito combinado das caractersticas de qualidade em uma situao
particular de uso definido como qualidade em uso; tambm devem ser consideradas a qualidade
externa e a qualidade interna:
Qualidade em uso satisfazer as necessidades reais de usurios ao utilizar o produto de

software, para atingir metas especificadas em contextos de uso especificados, ou seja, o efeito da
utilizao do produto, medido com relao s necessidades dos usurios.
Qualidade externa influenciar o comportamento de um sistema, para satisfazer necessidades

explcitas e implcitas, quando o sistema que o inclui for utilizado sob condies especificadas, ou
seja, o efeito da execuo das funes, medido com relao aos requisitos externos.
Qualidade interna atributos estticos do produto de software para satisfazer necessidades

explcitas e implcitas, quando o software for utilizado em condies especificadas, ou seja, o
efeito das propriedades de produtos intermedirios, medidos com relao aos requisitos internos
projeto e cdigo.
A norma NBR ISO/IEC 9126-1, publicada em 2001, estabeleceu dois modelos de qualidade. Um
modelo para qualidade externa e interna contendo um conjunto de seis caractersticas da qualidade de
produto de software e suas respectivas subcaractersticas, como mostra a Figura 4.3. O outro modelo
para qualidade em uso e contm quatro caractersticas de qualidade: Eficcia, Produtividade, Segurana
e Satisfao, como mostra a Tabela 4.1. Esse modelo ainda requer estudos para sua aplicao.
Tabela 4.1 Caractersticas de qualidade em uso (NBR ISO/IEC 9126-1, 2001)
Caractersticas
Eficcia
Definies
O software deve permitir que os usurios especificados atinjam metas especificadas com acurcia e
66
completitude, no contexto de uso especificado.

Produtividade
Segurana
Satisfao
O software deve permitir que seus usurios diretos e indiretos empreguem quantidade apropriada de
recursos em relao eficcia obtida, no contexto de uso especificado.
O software deve apresentar nveis aceitveis de riscos de danos a pessoas, negcios, software,
propriedades ou ao ambiente, no contexto de uso especificado
O software deve satisfazer usurios, no contexto de uso especificado.
Os requisitos para a escolha dessas caractersticas foram os seguintes:
cobrir conjuntamente todos os aspectos de qualidade de software resultantes da definio de

qualidade da ISO;
descrever a qualidade do produto com um mnimo de sobreposio;
ficar o mais prximo possvel da terminologia estabelecida;
formar um conjunto entre seis e oito caractersticas, por questes de clareza e manuseio; e
identificar reas de atributos de produtos de software para posterior refinamento.
Figura 4.3 Caractersticas e subcaractersticas de qualidade.
O modelo de qualidade de produto de software foi definido para apoiar o objetivo de aplicar as seis
caractersticas de qualidade em uma avaliao de produto de software. A utilizao do modelo
67
apresentado no obrigatria; outros modelos podem ser utilizados, mas importante perceber a
necessidade de seguir um modelo tanto para desenvolvimento do software quanto para uma avaliao. O
modelo apresentado baseado na definio das caractersticas de qualidade de software e das
subcaractersticas.
As seis caractersticas de qualidade de software esto apresentadas na Tabela 4.2. Uma preocupao da
norma foi definir caractersticas com um mnimo de sobreposio de conceitos entre elas.
Tabela 4.2 Caractersticas de qualidade interna e externa (NBR ISO/IEC 9126-1, 2001)
Caractersticas
Funcionalidade
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
Definies
Conjunto de atributos que evidencia a existncia de um conjunto de funes e suas propriedades
especificadas. As funes so as que satisfazem s necessidades explcitas ou implcitas.
Conjunto de atributos que evidencia a capacidade do software de manter seu nvel de desempenho sob
condies estabelecidas durante um perodo de tempo definido.
Conjunto de atributos que evidencia o esforo necessrio para se poder utilizar o software, bem como o
julgamento individual desse uso por um conjunto explcito ou implcito de usurios. Entende-se por usurios
aqueles que utilizam software interativo, ou seja, operadores, usurio final e usurios indiretos, que esto
sob influncia ou dependncia do uso do software.
Conjunto de atributos que evidencia o relacionamento entre o nvel de desempenho do software e a
quantidade de recursos usados, sob condies estabelecidas.
Conjunto de atributos que evidencia o esforo necessrio para fazer modificaes especificadas no
software.
Conjunto de atributos que evidencia a capacidade do software de ser transferido de um ambiente para outro.
Alm de definir as caractersticas de qualidade de software e orientar quando devem ser utilizadas, a
norma se preocupou, tambm, em apresentar um modelo de qualidade de produto de software. Sua
publicao teve o grande mrito de estabelecer um modelo bsico de qualidade de produto de software,
transformado em referncia conhecida por grande parte da comunidade.
Desde sua publicao, desenvolve-se uma opinio generalizada de que, apesar do grande benefcio
trazido por essa norma, ao definir um modelo de qualidade propiciando um vocabulrio comum, h uma
grande dificuldade em adequar sua aplicao para a avaliao prtica de produtos de software. A srie
de normas NBR ISO/IEC 14598, complementares norma NBR ISO/IEC 9126, procura oferecer
diretrizes para essa questo.
Na Tabela 4.3, so apresentadas, para cada caracterstica, as subcaractersticas e suas definies.
Tabela 4.3 Subcaractersticas de qualidade de software
Caractersticas
Subcaractersticas
Descries
68
Funcionalidade
Confiabilidade
Adequao
Presena de um conjunto de funes e sua apropriao para as tarefas

especificadas
Acurcia
Gerao de resultados ou efeitos corretos
Interoperabilidade
Capacidade de interagir com outros sistemas especificados
Conformidade
Estar de acordo com normas, convenes e regulamentaes
Segurana de acesso
Capacidade de evitar acesso no autorizado a programas e dados
Maturidade
Frequncia de falhas
Tolerncia a falhas
Capacidade de manter o nvel de desempenho em caso de falha ou violao nas

interfaces
Recuperabilidade
Capacidade de restabelecer seu desempenho e restaurar dados aps falha
Conformidade
Inteligibilidade
Apreensibilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
Operacionalidade
Atributos do software que evidenciam o esforo do usurio para reconhecer o

conceito lgico e sua aplicabilidade
Atributos do software que evidenciam o esforo do usurio para apreender sua
aplicao
Atributos do software que evidenciam o esforo do usurio para sua operao e
controle desta
Atratividade
A capacidade do software de ser atrativo ao usurio
Conformidade
Comportamento em relao ao
Tempo de resposta, de processamento e velocidade na execuo de funes
tempo
Comportamento em relao aos
Quantidade de recursos utilizados
recursos
Conformidade
Analisabilidade
Esforo necessrio para diagnosticar deficincia e causas de falhas
Modificabilidade
Esforo necessrio para realizar modificaes e remoo de defeitos
Estabilidade
Ausncia de riscos de efeitos inesperados ocasionados por modificaes
Conformidade
Testabilidade
Facilidade de ser testado
Adaptabilidade
Capacidade de ser adaptado a ambientes diferentes
Capacidade para ser instalado
Esforo necessrio para a instalao
Coexistncia
Capacidade do software de coexistir com outros produtos independentes, em um

ambiente comum, compartilhando os mesmos recursos
Conformidade
Consonncia com padres ou convenes de portabilidade
Capacidade para substituir
Capacidade e esforo necessrio para substituir outro software
A elaborao dessa srie de normas consolidou-se na estrutura mostrada na Tabela 4.4. Estudos e
revises continuam sendo desenvolvidos em termos dessa estrutura.
69
Tabela 4.4 Normas da srie ISO/IEC 9126: Status em 2009

Norma
9126-1
9126-2
9126-3
9126-4
Ttulo
Engenharia de software
Qualidade de Produto
Modelo de Qualidade
Medidas externas
Medidas internas
Medidas qualidade em uso
Assunto
Estado Internacional
Definio das caractersticas

e subcaractersticas da
Norma, publicada em 2001
qualidade
Estado Nacional
Exemplos de medidas
externas
Relatrio tcnico, publicado

Relatrio tcnico a ser publicado
em 2003
Exemplos de medidas
internas

em 2003
Exemplos de medidas de
qualidade em uso

em 2004
No Apndice D, esto resumidos os conceitos de qualidade para produtos de software.

Esta srie de normas est sendo reestruturada numa nova srie, que ser apresentada na prxima
seo.
4.3 A srie ISO/IEC 25000

O processo de transio na ISO entre as normas ISO/IEC 9126, ISO/IEC 14598 foi longo e muito
trabalhado para construo da nova srie ISO/IEC 25000 SQuaRE Software Quality Requirements
and Evaluation (Requisitos e Avaliao da Qualidade de Software).
A necessidade de um conjunto harmnico de documentos foi verificada quando especialistas do
mundo todo concordaram que faltava clareza na utilizao das normas de qualidade de produto. Assim,
as sries 9126 e 14598 existentes levaram a uma lista de melhorias que foram implementadas na nova
srie.
Foi construda uma nova estrutura, um primeiro ajuste e a construo da estrutura necessria foram
aprovados pela ISO/IEC, a verso foi revisada, e um ndice detalhado foi definido. Seguiu-se, ento, a
escolha dos novos nmeros que foram atribudos aos documentos SQuaRE. Em maio de 2002, a
numerao final da srie foi aprovada e aplicada. A arquitetura SQuaRE mostrada na Figura 4.4.
70
Figura 4.4 Arquitetura atual da srie ISO/IEC 25000.(2009)
A srie ISO/IEC 25000 composta pelas seguintes divises: Gesto da Qualidade, Modelo de
Qualidade, Medio, Requisitos e Avaliao. Uma representao dessas divises mostrada nas Figuras
4.5 a 4.9, conforme as seguintes denominaes: ISO/IEC 2500n Diviso Gesto da Qualidade; ISO/IEC
2501n Diviso Modelo de Qualidade; ISO/IEC 2502n Diviso Medio da Qualidade; ISO/IEC 2503n
Diviso Requisitos de Qualidade; ISO/IEC 2504n Diviso Avaliao da Qualidade.
O objetivo das normas SQuaRE obter uma srie logicamente organizada, unificada com
abrangncia de dois processos principais: especificao de requisitos e avaliao da qualidade de
software, apoiados por um processo de medio. Essas normas podem auxiliar desenvolvedores e
adquirentes de produtos de software durante os processos de especificao de requisitos e avaliao da
qualidade, estabelecendo critrios de especificao dos requisitos de qualidade, para medio e
avaliao.
Os computadores so utilizados para automatizar uma variedade de reas de aplicao, e seu uso
crtico para o sucesso dos negcios. A especificao e a avaliao da qualidade de produto de software
so fatores para assegurar a qualidade adequada, muitas vezes difcil de ser estabelecida. Isso pode ser
alcanado, definindo-se caractersticas de qualidade apropriadas ao uso pretendido do produto de
software. essencial que todas as caractersticas de qualidade importantes do produto de software
sejam especificadas e avaliadas, utilizando medidas validadas ou internacionalmente aceitas.
As caractersticas de qualidade e suas medidas associadas podem ser utilizadas tanto para avaliar um
produto de software quanto para definir requisitos de qualidade. A nova srie estabelece critrios para a
especificao dos requisitos de qualidade de produto de software, para medio e avaliao.
71
Est includo nessa nova srie um modelo de qualidade composto por duas partes, para alinhar as
definies de qualidade do usurio aos atributos relacionados ao processo de desenvolvimento. Alm
disso, a srie recomenda medidas para atributos de qualidade que podem ser utilizadas por
desenvolvedores, adquirentes e avaliadores.
A diviso SQuaRE ISO/IEC 2500n Gesto da Qualidade fornece orientaes sobre o uso da srie
SQuaRE, dando uma viso geral do seu contedo, de seus modelos de referncia, definies, o
relacionamento entre todos os documentos da srie, como tambm orientaes para planejamento e
gesto para especificao de requisitos e avaliao de produto. Ela apresentada na Figura 4.5.
As normas que compem a diviso Gesto da Qualidade definem todos os modelos e termos
referidos por todas as outras normas da srie 25000. Tal diviso fornece requisitos e orientaes para
uma funo de apoio, que responsvel pela gesto da especificao de requisitos e avaliao de
produto de software.
Figura 4.5 Diviso de Gesto da Qualidade da srie ISO/IEC 25000.
A norma que compe a diviso Modelo de Qualidade, apresentada na Figura 4.6, prope dois
modelos de Qualidade. Um modelo que inclui caractersticas para qualidade interna e externa de software
e qualidade em uso, alm disso, as caractersticas internas e externas de software so decompostas em
subcaractersticas. O outro modelo define qualidade para os dados pertencentes a um sistema
computacional, num formato estruturado. Tambm so fornecidas orientaes prticas para o uso de
modelos de qualidade.
72
Figura 4.6 Diviso Modelo de Qualidade da srie ISO/IEC 25000.
As normas que compem a diviso Medio da Qualidade contm um modelo de referncia para
medio da qualidade do produto de software, algumas definies analticas para medidas da qualidade
de software e orientaes prticas para aplicao. A Figura 4.7 apresenta a estrutura que contm
elementos de medidas de qualidade, medio de qualidade interna, medio de qualidade externa de
software e medio de qualidade em uso de software.
73
Figura 4.7 Diviso de Medio de Qualidade da srie ISO/IEC 25000.
A norma que compe a diviso Requisitos de Qualidade auxilia na especificao de requisitos de

qualidade, os quais podem ser utilizados no processo de elicitao de requisitos para um produto que
ser desenvolvido, isto , no incio do seu ciclo de vida ou posteriormente, como entrada para um
processo de avaliao. Tal diviso est representada esquematicamente na Figura 4.8.
Figura 4.8 Diviso Requisitos de Qualidade da srie ISO/IEC 25000.
As normas que compem a diviso de Avaliao da Qualidade, representada na Figura 4.9, fornecem
requisitos, recomendaes e orientaes para o processo de avaliao de produto de software.
Figura 4.9 Diviso de Avaliao da Qualidade da srie ISO/IEC 25000.
Apresenta tambm uma maneira formal de documentar uma medida, utilizando um mdulo de
avaliao. Alm disso, ela apresenta uma estrutura para a avaliao da qualidade de produto de
74
software. Essas estruturas so provenientes das normas ISO/IEC 9126-1 e 14598-1, 14598-3, 14598-4,
14598-5 e 14598-6.
As normas anteriores que tratam de qualidade de produto continuam sendo utilizadas at que as da
nova srie SQuaRE sejam publicadas. As principais diferenas entre as sries ISO/IEC 9126, ISO/IEC
14598 e SQuaRE so:
introduo do novo modelo de referncia geral;
introduo de guias detalhados e direcionados para cada diviso da norma;
introduo de elementos de medidas de qualidade dentro da diviso Medio da Qualidade;
introduo da diviso Requisitos de Qualidade;
incorporao e reviso dos processos de avaliao;
introduo de orientaes para uso prtico em forma de exemplos;
coordenao e harmonizao do contedo com a norma NBR ISO/IEC 15939 Engenharia de
Sistemas e de Software Processo de Medio, publicada em janeiro de 2009.
Alm dessas divises, existe uma extenso dessa srie; a sequncia ISO/IEC 25050 at 25099 est
reservada para ser utilizada por normas ou relatrios tcnicos que estendem o SQuaRE.
A norma 25051 diz respeito a: requisitos para COTS Commercial Off-The-Shelf, produtos de
software de prateleira disponveis comercialmente; requisitos para a documentao de teste, quando em
desenvolvimento desses produtos, incluindo requisitos de teste, casos de teste e relatrio de teste; e
tambm instrues para avaliao de conformidade. Essa norma substitui a ISO/IEC 12119.
A norma 25062 se refere Usabilidade. Fornece instrues para relatrios de teste de usabilidade,
especificando como descrever os resultados de um teste de usabilidade num contexto de uso especfico.
A Tabela 4.5 mostra a nomenclatura das siglas utilizadas unicamente na ISO, onde foram mantidas as
palavras em Ingls para facilitar o entendimento das siglas; a sequncia de etapas de projetos por meio
dos quais o trabalho desenvolvido; o nome do documento associado a cada etapa.
Tabela 4.5 Etapas de projeto e documentos associados
Etapas de projeto
Documentos associados
Nome
Abreviatura
0 Estgio preliminar
Preliminary work item
PWI
1 Estgio de Proposta
New work item proposal
NP
2 Estgio preparatrio
Working draft(s)
WD
3 Estgio Comit
Committee draft(s)
CD
75
4 Estgio de consulta
Draft International Standard
DIS
5 Estgio de aprovao
Final Draft International Standard
FDIS
6 Estgio de publicao
International Standard
ISO/IEC
Os trabalhos na ISO so organizados de acordo com as reas de especializao; ento so criados

os Grupos de Trabalho, numerados sequencialmente na ordem em que foram estabelecidos. Os
trabalhos dos grupos so chamados de projetos e so classificados conforme a etapa de
desenvolvimento em que se encontram. Por isso, a Tabela 4.5 contm algumas siglas em ingls que se
referem etapa do projeto em que a norma se encontra.
A Tabela 4.6 apresenta o status das normas de qualidade de produtos de software at 2009.
Tabela 4.6 SQuaRE Status: 2009
2500n
Norma
Ttulo resumido
Diviso Gesto da Qualidade
25000
25001 (ex - 14598-2)
Guia para SQuaRE

Planejamento e Gesto
Publicada em 2005
Publicada em 2007
2501n
25010 (ex - 9126-1)
25012
Diviso Modelo de Qualidade

Modelo de Qualidade
Modelo de Qualidade de Dados
Em reviso
Em reviso
2502n
25020
25021
25022 (ex - 9126-3)
25023 (ex - 9126-2)
25024 (ex - 9126-4)
Diviso Medio da Qualidade

Guia e Modelo de Referncia
Elementos de Medida de Qualidade
Medio de Qualidade Interna
Medio de Qualidade Externa
Medio de Qualidade em Uso
Publicada em 2007
Publicada em 2007
Em reviso
Em reviso
Em reviso
Publicada em 2009
2503n
25030
Diviso Requisitos de Qualidade

Requisitos de Qualidade
Publicada em 2007
Publicada em 2008
2504n
25040 (ex - 14598-1)
25041 (ex - 14598-6)
Diviso Avaliao de Qualidade

Guia e Modelo de Referncia
Mdulos de Avaliao
Extenso da srie
Requisitos de Qualidade para COTS
25051
25062
Estado internacional
Estado nacional
Publicada em 2008
Publicada em 2009
Em reviso
Em reviso
Publicada em 2006
Publicada em 2008
Formato Comum da Indstria para Relatrios Publicada em 2006

de Usabilidade
76
A seguir sero apresentados modelos de qualidade baseados nas normas e advindos de aplicaes
prticas.
4.4 O modelo de qualidade do MEDE-PROS

Este modelo de qualidade foi baseado na norma NBR ISO/IEC 9126-1, que padronizou uma linguagem
universal para um modelo de qualidade de produto de software e um exemplo de como aplicar os
conceitos definidos nesta norma. Este modelo foi amplamente utilizado nas avaliaes de qualidade de
produto de software, em diversas ocasies em que o CTI desenvolveu atividades sob demanda.
Este modelo adequado para avaliar produto de software, pode-se dizer que um modelo genrico
para avaliar software de qualquer domnio de aplicao.
Os requisitos de qualidade para software do tipo pacote, podem ser baseados, principalmente, na
9
norma NBR ISO/IEC 12119 , que define requisitos para essa categoria de software, a qual trouxe uma
definio universal do que um pacote de software deve possuir para ter um mnimo de qualidade e
profissionalismo.
Adicionalmente, foram utilizados outros requisitos baseados nas normas de documentao de usurio
e de requisitos de usabilidade na interface homem-mquina, IEEE e ISO, respectivamente. Esse assunto
ser detalhado no prximo captulo.
Uma estrutura inicial de um modelo de qualidade de software pode ser desdobrada a partir dos seus
componentes at os seus atributos a serem avaliados.
O modelo de qualidade sugerido neste livro tem incio com os trs componentes definidos na norma
NBR ISO/IEC 12119, que so: Descrio do Produto, Documentao do usurio, Programas e dados.
Alm desses componentes, sero acrescentados outros componentes, considerados importantes numa
avaliao dessa natureza. A seguir, algumas consideraes so expostas, com o objetivo de desdobrar
esses componentes, para obter uma avaliao mais objetiva.
Pode-se considerar Programas e dados como sendo o software propriamente dito, ou seja, na
linguagem de Engenharia de software, o que executvel em uma mquina tipo computador;
assim, este componente passa a ser chamado simplesmente de software.
O software, quando requer interatividade, requer dados de entrada e opes a serem escolhidas
pelo usurio; apresenta uma interface, que geralmente composta por janelas e campos a serem
preenchidos pelo usurio. Dessa maneira, importante estar avaliando a interface como um
componente especfico em produtos de software.
O MEDE-PROS foi desenvolvido com a norma NBR ISO/IEC 12119 e sua ltima verso data de 2006.
77
No caso de pacote de software, este pode ser comercializado em algum tipo de embalagem;
atualmente tem sido comercializado tambm pela internet. Nesse caso, existe uma pgina na
internet onde o software apresentado. Em ambos os casos, interessante avaliar sua
embalagem ou informaes a ele relacionadas, localizadas no site do fornecedor do produto.
Considerando a norma NBR ISO/IEC 25051 e a forma como um software normalmente se apresenta,
os componentes de um software propostos neste modelo podem ser:
Descrio do Produto
Embalagem
Documentao de usurio
Software e Interface
Identificando cada um desses componentes, tem-se, segundo a norma NBR ISO/IEC 25051, a
Descrio do Produto, que um documento expondo as propriedades de um pacote de software, com o
objetivo de auxiliar os potenciais compradores, na avaliao da adequao do produto antes da compra.
Essa descrio pode estar disponvel em um catlogo prprio, na embalagem, em mdia digital de
apresentao ou qualquer outro meio disponvel ao usurio, independentemente da aquisio do produto.
O produto deve possuir um documento nico e de fcil localizao.
Por Embalagem, entende-se o meio fsico que acondiciona a mdia e documentos impressos.
Exemplos de embalagem: caixa de papelo tipo cartolina, caixa de papelo resistente e com abas tipo
encaixe, caixa plstica para CD, caixa de papelo com capa dura e com encaixe sobreposto, se for o
caso.
Documentao de usurio o conjunto completo de documentos, disponvel na forma impressa, ou
no; fornecida para utilizao de um produto, sendo tambm uma parte integrante do produto. Por
exemplo: manual, complementos de manuais, atualizaes, mdia digital de demonstrao, selo de
identificao. Documentao on-line toda documentao em mdia e pode ser consultada por meio de
qualquer meio eletrnico.
As Funes do software so representadas na Interface por meio de menus, botes, caixas de
dilogo, janelas, teclas aceleradoras e outros meios.
Esses componentes de software podem ser visualizados na Figura 4.10, em que se apresentam os
cinco componentes conceituais do modelo de qualidade e a indicao de normas que sero utilizadas. Os
componentes software e interface so provenientes de normas diferentes, mas fisicamente um nico
componente.
78
Figura 4.10 Componentes de software.
Para avaliar a Descrio do Produto e a Embalagem, podem ser considerados os requisitos de

qualidade especificados nas normas NBR ISO/IEC 25051 e ISO 9127 (ISO 9127, 1988). Para avaliar a
Documentao de Usurio, foram considerados os requisitos de qualidade especificados nas normas
NBR ISO/IEC 25051, ANSI/IEEE 1063, NBR ISO/IEC 9126-1 e ISO 9127. Para avaliar o Software, foram
considerados os requisitos de qualidade especificados na norma NBR ISO/IEC 9126-1. Para avaliar a
Interface, foram considerados os requisitos de qualidade especificados nas normas NBR ISO/IEC 9126-1
e ISO 9241 partes 10, 11 e 12.
Alm das consideraes expostas anteriormente, mais uma constatao que deve ser referenciada
que, para utilizar um software, deve-se instalar o software em um sistema computacional; em seguida,
executar o software por meio de sua interface; finalmente, em algum momento, dever ser possvel, ou
mesmo necessrio, fazer sua desinstalao do ambiente computacional.
Assim, sugerido que sejam avaliados os componentes de um software nestas trs etapas de
utilizao do software: Instalao, Execuo e Desinstalao, como mostra a Figura 4.11.
79
Figura 4.11 Etapas de avaliao.
Durante a instalao, a execuo e mesmo na desinstalao do produto, o avaliador poder estar

medindo alguns atributos dos componentes do software Software, Interface, Documentao, Descrio
do produto e Embalagem.
Finalmente, sugere-se a definio do modelo de qualidade para avaliao de software, estruturado
pelos seus sete componentes, e cada um desses componentes com suas respectivas caractersticas de
qualidade.
Cada um dos componentes avaliado segundo as caractersticas definidas pela norma NBR ISO/IEC
9126-1. As que esto sendo utilizadas aqui so: Portabilidade, Usabilidade, Funcionalidade, Eficincia e
10
Confiabilidade, segundo o requisito Completitude , definido pela norma NBR ISO/IEC 12119. A
caracterstica Manutenibilidade no se aplica neste modelo, pois esta avaliao no tem o objetivo de
avaliar o esforo necessrio para fazer modificaes no software, assim como no h necessidade de
acesso a programas-fontes e produtos intermedirios gerados durante o desenvolvimento do produto de
software.
Uma viso detalhada desta estrutura do modelo de qualidade mostrada na Figura 4.12. Nela esto
includas, tambm, as subcaractersticas de qualidade da norma NBR ISO/IEC 9126-1, que o
desdobramento de cada uma das caractersticas, mais os requisitos do conceito completitude, definido na
norma NBR ISO/IEC 12119.
10
O requisito Completitude na norma NBR ISO/IEC 25051, tem o nome de Completeza.
80
Figura 4.12 Modelo de qualidade numa viso mais detalhada.
Este modelo de qualidade pode ser visto como um modelo genrico para avaliar qualquer categoria de
software, independente da sua rea de aplicao.
4.5 Modelo de qualidade do PNAFM

Este modelo de qualidade foi baseado no modelo de qualidade do MEDE-PROS, que j foi aplicado a
centenas (aproximadamente 430) de avaliaes de produtos de software. O mtodo foi desenvolvido pela
Diviso de Qualificao em Software do CTI, para atender ao Programa Nacional de Apoio Gesto
Administrativa e Fiscal dos Municpios Brasileiros - PNAFM, coordenado pela UCP/MF - Unidade de
Coordenao de Programas do Ministrio da Fazenda, com apoio tcnico do PNUD - Programa das
Naes Unidas para o Desenvolvimento. O financiamento foi feito pelo BID - Banco Interamericano de
Desenvolvimento, no processo de qualificao de empresas e instituies e seus Conjuntos de Sistemas
Aplicativos CSA, que compem a soluo de tecnologia da informao para os projetos simplificados
deste programa.
Cada CSA constitudo por 8 (oito) sistemas aplicativos, como mostra a Figura 4.13: Tributrio,
Financeiro, Compras, Recursos Humanos, Informaes gerenciais, Legislativo, Protocolo e Ouvidoria. O
objetivo do mtodo de avaliao PNAFM verificar se cada sistema aplicativo do CSA atende os
requisitos obrigatrios, desejveis e recomendados, mencionados no Edital 01/2001 e adendo
agosto/2002, convocando empresas e instituies para pr-qualificao, com base na viso do usurio
final. Neste mtodo so avaliados comandos, integrao entre sistemas, estabilidade do sistema e, como
81
foco principal, a verificao da conformidade dos requisitos funcionais, isto , o atendimento

preestabelecido no Edital.
Editais so de uso obrigatrio para qualquer tipo de aquisio realizada por rgos do governo, nos
mbitos federais, estaduais e municipais, tanto na aquisio de bens como para servios. So
instrumentos que do ao processo de aquisio o carter legal, tornando-o transparente e,
consequentemente, imparcial.
Figura 4.13 Conjunto de Sistemas Aplicativos do PNAFM
Este mtodo de avaliao, criado para atender ao PNAFM, trouxe caractersticas inovadoras, podendo
derivar novas iniciativas, como o estabelecimento de um padro mnimo (bsico) da qualidade dos
sistemas aplicativos utilizados na Gesto Pblica Municipal Brasileira. Propondo-se a ser uma iniciativa
precursora na busca da qualidade nas solues de tecnologia da informao pblica.
Quanto a sua representatividade no meio cientfico como pesquisa inovadora, o mtodo se caracteriza
por ter sido desenvolvido utilizando como base terica as normas de qualidade de software que tratam de
modelo de qualidade de produto e medidas, de requisitos de usabilidade de interfaces, documentao e
testes e requisitos de qualidade para pacote de software entre outros, e considerando os requisitos
funcionais pr-estabelecidos. Este o primeiro mtodo de avaliao de aplicativos desenvolvido, testado
e aplicado tanto no contexto nacional.
82
Assim o modelo de qualidade pode ser representado, esquematicamente, como na Figura 4.14, onde
se v o modelo de qualidade do MEDE-PROS, aplicado e adaptado para cada um dos sistemas
aplicativos, com as exigncias estabelecidas no Edital.
Figura 4.14 Modelo de Qualidade do PNAFM
O modelo de qualidade de cada CSA dos sistemas aplicativos contempla os requisitos especficos
contidos e publicados no Edital.
4.6 Modelo de qualidade de componentes de software

Nas sees anteriores, foram apresentados desde o modelo de qualidade de McCall, proposto em 1977,
at o modelo prtico e genrico proposto na Figura 4.12. Esta seo apresenta a proposta de um modelo
de qualidade para componentes de software como exemplo da utilidade do modelo de qualidade para
software. Esse tipo de software pode ser utilizado no Desenvolvimento Baseado em Componentes DBC
e obedece a uma definio do que se entende por componente de software.
Componentes de software So artefatos autocontidos, claramente identificveis, que descrevem

ou realizam uma funo especfica e tm interfaces claras, em conformidade com um dado modelo
de arquitetura de software, documentao apropriada e um grau de reutilizao definido
(VILLELA, 2000).
83
Para melhor entendimento da definio apresentada por Villela, alguns termos foram detalhados por
Sametinger (SAMETINGER,1997) de forma mais profunda:
Autocontido caracterstica dos componentes de poderem ser reusveis sem a necessidade de

incluir/depender de outros componentes. Caso exista alguma dependncia, todo o conjunto deve
ser visto como o componente reutilizvel.
Identificao componentes devem ser facilmente identificados, ou seja, devem estar contidos em
um nico lugar, ao invs de espalhados e misturados com outros artefatos de software ou
documentao.
Funcionalidade componentes tm uma funcionalidade clara e especfica que realizam e/ou

descrevem. Componentes podem realizar funes ou podem ser simplesmente descries de
funcionalidades, por exemplo, artefatos do ciclo de vida.
Interface componentes devem ter interfaces claras, que indicam como podem ser reusados e
conectados a outros componentes, e devem ocultar os detalhes que no so necessrios para o
reso.
Documentao a existncia de documentao indispensvel para o reso. O tipo de

componente e sua complexidade iro indicar a convenincia do tipo de documentao.
Condio de reso componentes devem ser mantidos de modo a preservar o reso sistemtico,
e a condio de reso compreende diferentes informaes: por exemplo, quem o proprietrio,
quem deve ser contatado em caso de problema, qual a situao de qualidade, entre outras.
Prope-se uma estrutura de qualidade de componentes que assegure um rigoroso fundamento terico
para derivao e definio das caractersticas, subcaractersticas, atributos e medies da qualidade,
considerando, assim, diferentes abordagens (GUERRA, 2007). Dessa forma apresentado o modelo de
qualidade externa para componentes de software, na
Figura 4.15. Os atributos externos so divididos em dois grupos: Aqueles que influenciam no DBC e
Aqueles que influenciam na execuo do Sistema Baseado em Componentes - SBC.
Para os atributos externos do DBC, considera-se que o componente deve apresentar:
84
Um documento de descrio de componente, o qual deve conter as informaes que permitam avaliar
a adequao do componente. Esse documento deve seguir uma adaptao dos requisitos do
documento de descrio de produto de software, da norma NBR ISO/IEC 25051.
Uma documentao para o DBC, que deve conter todas as informaes necessrias, e com o grau de
detalhamento adequado. Foco principal dessa documentao devem ser as informaes para a
adaptao e integrao do componente no sistema, nas quais so descritas suas caractersticas e
funcionalidades, por exemplo: interfaces de gerncia, interfaces providas e requeridas, eventos
recebidos e enviados, bem como as propriedades e as interfaces de acesso s propriedades,
quando estas sejam internas. Caso o componente tenha funes de interface com o usurio, estas
tambm devem estar descritas. A documentao ser avaliada com base nos requisitos de
qualidade das normas NBR ISO/IEC 25051 e IEEE 1063.
A qualidade externa do componente no DBC, que contm informaes de qualidade do componente
que so relevantes para sua utilizao no DBC. Essas informaes englobam tanto caractersticas
funcionais quanto no funcionais, mas que so observveis ou medidas durante o ciclo de vida do
desenvolvimento do componente.
Modelo da Qualidade para Componente de Software

Modelo da Qualidade
de Componentes de Software
Atributos externos que influenciam

no DBC
Descrio do Componente
(busca e avaliao)
( ISO/IEC12119)
Completitude
Identificador
Declaraes
Decl. Funcionalidade
Decl. Confiabilidade
Decl. Usabilidade
Decl. Eficincia
Decl. Manutenibilidade
Decl. Portabilidade
Decl. Qualid. Uso
Documentao para DBC

( ISO/IEC12119 e IEEE1063)
Funcionalidade
Completitude
Usabilidade
Inteligibilidade
Correo
Apresentao e
Consistncia
Organizao
Atributos externos que influenciam

na execuo do SBC
Componente no DBC
(adaptao e integrao)
( ISO/IEC9126-1 e 3)
Funcionalidade
Adequao
Interoperabilidade
Conformidade
(ISO/IEC9126-1 e 2)
Funcionalidade
Acurcia
Segur. Acesso
Confiabilidade
Confiabilidade
Recuperabilidade
Maturidade
Eficincia
Usabilidade
Contedo
Operacionalidade
Aval. Adequao
Consistncia
Termos Tcnicos
Decl. Corretas
Decl. Testveis
Componente integrado no
SBC
Adaptado de
Bertoa et ali
e do MEDE-PROS
pelo CTI
Rel. Tempo
Rel. Recursos
Manutenibilidade
Modificabilidade
Testabilidade
Portabilidade
Cap. p/substituir
85
Figura 4.15 Modelo de qualidade para componentes de software COTS.
Para os atributos externos no Sistema SBC, considera-se que o componente deve apresentar
atributos da qualidade externa influenciando no SBC, que tambm contm informaes de qualidade do
componente, mas que influenciam na execuo do sistema.
A seguir sero apresentados os atributos de qualidade a serem avaliados neste modelo.
4.6.1 Descrio do componente
Para descrio do componente, o modelo de qualidade se decompe em: Completitude e Contedo.
Como Completitude, entende-se a capacidade de verificar quo completa a descrio do
componente. O atributo Completitude se decompe nos seguintes requisitos:
Identificador capacidade de verificar se a descrio do componente contm identificaes

importantes do componente.
As seguintes identificaes devem ser declaradas:
Identificao do Componente - por exemplo, nome do componente, verso e data;
Descrio do modelo de componente adotado;
Produtor/fornecedor do componente;
Descrio dos servios do componente, ou seja, interfaces fornecidas;
Especificao das dependncias, ou seja, Interfaces requeridas;
Artefatos que fazem parte do componente (caso o componente possua).
Declaraes capacidade de verificar se a descrio do componente contm declaraes

sobre suporte e manuteno.
As declaraes devem ser seguintes:
Suporte declaraes de suporte do componente;
Manuteno declaraes de manuteno do componente.
86
Declarao da Funcionalidade capacidade de verificar se, na descrio do componente,

existem declaraes sobre as funes, valores-limites, grau de preciso, interoperabilidade e
segurana de acesso do componente.
Os atributos avaliados so:
Declarao dos servios declaraes dos servios que o componente oferece por meio de
suas interfaces;
Grau de preciso declaraes do grau de preciso dos resultados obtidos por meio da
execuo do componente;
Interoperabilidade declaraes sobre a interoperabilidade do componente, ou seja, da

compatibilidade dos dados tratados pelo componente;
Conformidade declaraes de conformidade das funcionalidades do componente com

padres, normas e convenes;
Valores-limites declaraes de valores limites, caso o uso do componente seja limitado por
eles;
Segurana de acesso declaraes de maneiras (se fornecidas) de evitar o acesso no

autorizado ao componente e a seus dados.
Declarao da Confiabilidade capacidade de verificar se a descrio do componente contm

informaes sobre procedimentos para a preservao dos dados.
Cpia de segurana declaraes sobre a realizao de cpias de segurana;
Verificao de entradas declaraes sobre entradas aceitveis;
Recuperao de erros declaraes sobre a capacidade do componente de se recuperar de

erros ocorridos.
Declarao da Usabilidade capacidade de verificar se, na descrio do componente, existem

declaraes sobre o conhecimento especfico requerido do usurio do componente, adaptaes
que podem ser feitas pelo usurio e se protees contra infraes a direitos autorais podem
interferir na usabilidade.
Interfaces declarao dos tipos de interfaces do componente;
87
Conhecimento necessrio declarao sobre conhecimentos requeridos pelo usurio do

componente;
Adaptao declaraes sobre ferramentas, caso existam, interfaces de gerncias ou

propriedades do componente para configuraes do componente s necessidades do
usurio;
Proteo tcnica declaraes sobre proteo contra infraes a direitos autorais, caso
estes dificultem a usabilidade.
Declarao da Eficincia capacidade de verificar se a descrio do componente inclui dados

sobre o comportamento do componente em relao ao tempo. Por exemplo: tempo de resposta.
Tempo declaraes sobre o comportamento do componente em relao ao tempo;
Recursos declaraes sobre o comportamento do componente em relao aos recursos.
Declarao da Manutenibilidade capacidade de verificar se, na descrio do componente,

existem declaraes sobre manutenibilidade.
Anlises declaraes sobre a analisabilidade do componente, ou seja, declaraes sobre

possveis diagnsticos que podem ser realizados no componente;
Modificaes declaraes sobre a capacidade de modificar o componente;
Testes declaraes da capacidade de realizar testes para validar o componente aps

modificaes.
Declarao da Portabilidade capacidade de verificar se, na descrio do componente, existem

declaraes sobre portabilidade.
Adaptaes declaraes sobre a capacidade de realizar adaptaes no componente para

diferentes ambientes;
Reso declaraes sobre a capacidade de o componente ser utilizado em diferentes

contextos e domnios.
Declarao da Qualidade em Uso capacidade de verificar se a descrio do componente

inclui declaraes de qualidade sob a perspectiva do desenvolvedor, projetista, arquiteto de
88
software. Ou seja, se h uma declarao de usos anteriores do componente com respeito a

eficcia, produtividade, segurana e satisfao.
Eficcia no DBC declaraes sobre a eficcia atingida com a utilizao do componente em

contextos de usos especificados;
Produtividade no DBC declaraes sobre a produtividade atingida com a utilizao do

componente em contextos de usos especificados;
Segurana no DBC declaraes sobre nveis aceitveis de riscos com a utilizao do

componente em contextos de usos especificados;
Satisfao no DBC declaraes sobre a satisfao dos usurios (desenvolvedores e

integradores) com a utilizao do componente em contextos de usos especificados.
Como Contedo, entende-se a capacidade de verificar se o contedo da descrio do componente

suficientemente adequado, livre de inconsistncias internas, e se cada declarao da descrio do
componente est correta e passvel de teste. O atributo Contedo se decompe nos seguintes
requisitos:
Avaliao da adequao avaliar se o contedo da descrio do componente inteligvel,

completa e possui boa organizao e apresentao;
Consistncia avaliar se o contedo da descrio do componente livre de inconsistncias

internas;
Termos tcnicos avaliar se os termos tcnicos possuem significados nicos;
Declaraes corretas avaliar se a descrio do componente possui declaraes corretas;
Declaraes testveis avaliar se a descrio do componente possui declaraes passveis de

serem testadas.
4.6.2 Documentao do usurio

Para a documentao do usurio do Desenvolvimento Baseado em Componentes - DBC, o modelo de
qualidade se decompe nas seguintes caractersticas e suas respectivas subcaractersticas:
Funcionalidade essa caracterstica diz respeito s descries das funcionalidades do

componente na documentao para o DBC. Exemplo de funcionalidades do componente: servios
oferecidos e requeridos, documento de implantao, valores-limites etc.
89
Completitude capacidade de verificar quo completa a documentao das funcionalidades

do componente. Para isso, avaliada a descrio dos servios oferecidos e requeridos do
componente, verificado se os valores-limites citados na descrio do componente so
informados tambm na documentao e, tambm, se est includo na documentao o manual
de implantao do componente.
Descrio dos servios verificar a completitude da descrio dos servios oferecidos e

requeridos do componente por meio de suas interfaces providas e requeridas;
Valores-limites verificar se os valores-limites citados na descrio do componente esto

declarados tambm na documentao;
Manual de adaptao e integrao verificar se est includo na documentao o manual de

implantao do componente.
Usabilidade essa caracterstica diz respeito usabilidade das informaes contidas na

documentao. Para isso, verificado se as informaes so corretas, consistentes, de fcil
compreenso pela classe de usurios da documentao. Tambm so verificadas a apresentao
e a organizao das informaes.
Correo capacidade de verificar se as informaes na documentao para DBC esto

corretas, sem ambiguidades nem erros. Para isso verificado, nas informaes do documento,
se h termos ambguos ou incorretos dentro do contexto indicado.
O atributo avaliado :
Informaes corretas verificar se, nas informaes da documentao, h termos ambguos

ou incorretos dentro do contexto indicado.
Consistncia capacidade de verificar se o documento para DBC no apresenta contradies

internas ou e com a descrio do componente. Para isso, avaliada a consistncia dos termos
que devem ter um significado nico em toda a documentao, e tambm a consistncia entre
as informaes da documentao e as da descrio do componente.
Consistncia dos termos verificar se os termos apresentam um significado nico em toda a

documentao;
Consistncia com a descrio do componente verificar a consistncia entre as informaes

da documentao e as da descrio do componente.
90
Inteligibilidade capacidade de verificar se o documento para DBC de boa compreenso pela

classe de usurios que normalmente utilizam o componente em suas tarefas, como projetistas,
desenvolvedores, arquitetos de software etc. Para verificar a inteligibilidade, utiliza-se uma
seleo apropriada de termos, exibies grficas e explicaes detalhadas.
Termos adequados verificar se os termos utilizados so apropriados para o contexto do

componente;
Exibies grficas verificar se o documento possui exibies grficas, como ilustraes,

figuras, para facilitar a compreenso;
Explicaes detalhadas verificar se o documento possui explicaes em um nvel de

detalhes que facilite a compreenso;
Clareza verificar se as informaes apresentadas na documentao so claras, de fcil

entendimento.
Apresentao e Organizao capacidade de verificar se a documentao possui uma boa

apresentao e organizao, de tal modo que quaisquer relacionamentos sejam facilmente
identificados. Para isso, verificado se h presena de ndices analticos e remissivos e se
possui uma boa apresentao visual e de layout.
Presena de ndices verificar se h presena de ndices analticos e remissivos na

documentao;
Apresentao visual verificar se h uma boa apresentao visual; por exemplo, tamanhos
e tipos de fontes, cores e layout.
4.6.3 Componentes no DBC

Para o Componente em si, o modelo de qualidade se decompe nas seguintes caractersticas e suas
respectivas subcaractersticas:
Funcionalidade capacidade do componente de prover servios que satisfaam as necessidades

especificadas, quando o componente for usado sob condies especficas.
Adequao capacidade do componente de prover um conjunto apropriado de servios para

tarefas e objetivos do usurio especificados. Para isso, verificada sua adequao com uma
determinada arquitetura, se a implementao cobriu os servios oferecidos pelas interfaces do
91
componente, se h excesso de interfaces para desempenhar os servios oferecidos pelo

componente e se o componente autocontido.
Adequao arquitetural verificar a adequao do componente com a arquitetura

especificada;
Cobertura verificar se a implementao do componente cobriu os servios oferecidos pelas

suas interfaces;
Excesso verificar se h excesso de interfaces no componente, para desempenhar os

servios oferecidos por ele;
Autocontido verificar se o componente realiza, de forma completa, a funo que ele

desempenha, ou seja, as funcionalidades devem estar adequadas para o componente
atender seu prprio propsito.
Interoperabilidade capacidade do componente de interagir com um ou mais componentes ou

sistemas especificados. Para isso, verificada a compatibilidade dos dados controlados pelo
componente: se est em conformidade com padres ou convenes (ex.: ASNI, XML etc.).
Compatibilidade de dados verificar se os dados controlados pelo componente esto em

conformidade com padres ou convenes.
Conformidade capacidade do componente de estar de acordo com padres, convenes ou

regulamentaes previstas em leis e prescries similares relacionadas sua funcionalidade.
Para avaliar a conformidade, verificado se o componente est de acordo com padres
internacionais ou regulamentaes previstas em leis.
Padronizao verificar se o componente est de acordo com padres internacionais ou

regulamentaes previstas em leis.
Confiabilidade capacidade do componente de manter um nvel de desempenho especificado,

quando usado em condies especificadas.
Maturidade capacidade do componente de evitar falhas decorrentes de defeitos no software.

Para avaliar a maturidade, verificada a volatilidade das verses, ou seja, o tempo de vida de
uma verso no mercado, a evoluo do componente de acordo com o nmero de suas verses
que tm sido comercializadas e pelo nmero de remoo de falhas de uma verso para outra.
92
Volatilidade verificar qual o tempo de vida de uma verso no mercado;
Evoluo entre verses verificar a evoluo do componente de acordo com o nmero de

suas verses que tm sido comercializadas;
Remoo de falhas verificar o nmero de remoo de falhas de uma verso para outra.
Usabilidade capacidade do componente de ser compreendido, aprendido, utilizado e atrativo para

o usurio, quando usado sob condies especificadas.
Operacionalidade capacidade do componente de possibilitar ao usurio oper-lo e control-lo.

Para isso, avaliada a clareza com que as interfaces so declaradas, a taxa de complexidade
para utilizar suas interfaces e o esforo necessrio para operar o componente por meio da
configurao de seus parmetros. Os componentes so operados e controlados pelas suas
interfaces (por exemplo, interfaces de gerncia, providas, requeridas e interfaces de controle).
Clareza das interfaces verificar o nvel de clareza com que as interfaces so declaradas;
Complexidade verificar a taxa de complexidade para utilizar as interfaces do componente;
Esforo de operao esforo necessrio para operar o componente por meio da

configurao de seus parmetros.
Manutenibilidade capacidade do componente de ser modificado. As modificaes podem incluir

correes, melhorias ou adaptaes do componente, devido a mudanas no ambiente e nos seus
requisitos ou especificaes funcionais.
Modificabilidade capacidade do componente de permitir que uma modificao especificada

seja implementada. Para isso, verificada nesta subcaracterstica a adaptabilidade do
componente, ou seja, o nmero de parmetros customizveis que o componente oferece,
esforo de customizao, ou seja, a quantidade de parmetros que o componente oferece para
customiz-lo com relao s suas interfaces oferecidas; tambm a habilidade de controle de
mudana, ou seja, a facilidade do usurio de identificar a verso atual do componente.
Adaptabilidade verificar o nmero de parmetros customizveis que o componente

oferece;
Taxa de adaptabilidade verificar a quantidade de parmetros que o componente oferece

para customiz-lo com relao s suas interfaces oferecidas;
93
Capacidade de controle de mudana verificar a facilidade com que o usurio identifica a

verso atual do componente e suas verses compatveis.
Testabilidade capacidade do componente de permitir que ele possa ser validado quando
modificado. Para avaliar a testabilidade, verificado se o componente permite a execuo de
testes de inicializao, e tambm se o componente possui conjunto de casos de testes para
validar sua funcionalidade.
Teste de inicializao verificar se o componente permite a execuo de testes de

inicializao;
Pacotes de teste verificar se o componente possui um conjunto de casos de testes para

validar sua funcionalidade.
Portabilidade capacidade do componente de ser transferido de um ambiente para outro. O

ambiente pode ser organizacional, de hardware ou de software.
Capacidade para substituir outro componente capacidade do componente para ser usado em
substituio a outro componente especificado, com o mesmo propsito e mesmo ambiente. A
compatibilidade entre as verses do componente o atributo verificado para avaliar esta
subcaracterstica.
Compatibilidade entre verses verificar se o componente possui verses compatveis com

sua verso original.
4.6.4 Componente integrado no SBC

Para o Componente integrado no Sistema Baseado em Componentes - SBC, o modelo de qualidade
se decompe nas seguintes caractersticas e suas respectivas subcaractersticas:
Funcionalidade capacidade do componente de prover servios que satisfaam as necessidades

especificadas, quando o componente for usado sob condies especficas.
Acurcia capacidade do componente de prover, com o grau de preciso necessrio,

resultados ou efeitos corretos, ou conforme acordados. Para verificar a acurcia, avaliada,
nos componentes, a preciso dos resultados obtidos com o que foi especificado pelo requisito
do usurio.
94
Preciso verificar a preciso dos resultados obtidos com o que foi especificado pelo
requisito do usurio.
Segurana de acesso capacidade do componente de proteger informaes e dados, de forma

que pessoas, componentes ou sistemas no autorizados no possam l-los nem modific-los, e
que no seja negado o acesso s pessoas, ou componentes, ou sistemas autorizados. Para
isso, avaliada a capacidade do componente de criptografar suas informaes, controlar o
acesso aos seus servios providos e verificar se o componente implementa algum mecanismo
de auditoria, com capacidade para registrar os acessos dos usurios em suas funcionalidades e
em seus dados.
Criptografia dos dados verificar a capacidade do componente de criptografar suas

informaes;
Capacidade de controle verificar se o componente capaz de controlar o acesso aos seus

servios providos;
Capacidade para auditar verificar se o componente implementa algum mecanismo de

auditoria, com capacidade para registrar os acessos dos usurios em suas funcionalidades e
em seus dados.
Confiabilidade capacidade do componente de manter um nvel de desempenho especificado,

quando usado em condies especificadas.
Recuperabilidade capacidade do componente de restabelecer seu nvel de desempenho

especificado e recuperar os dados diretamente afetados, no caso de uma falha. Para isso,
avaliada a habilidade do componente em serializar seus dados e estado; assim, ele pode ser
transferido para uma mquina diferente ou armazenado para persistncia. avaliada, tambm,
a capacidade do componente de armazenar seu estado para uma futura recuperao; tambm
se o componente prov qualquer interface para implementar transaes com suas operaes, e
se o componente pode controlar situaes de erros, por meio de mecanismos implementados,
como, por exemplo: excees.
Serializabilidade verificar se o componente capaz de serializar seus dados e estado de

modo que ele possa ser transferido para diferentes mquinas ou armazenado para
persistncia;
Persistncia verificar se o componente possui a capacidade de armazenar seu estado para

uma futura recuperao;
95
Transacionalidade verificar se o componente prov qualquer interface para implementar

transaes com suas operaes;
Tratamento de erros verificar se o componente pode controlar situaes de erros por meio
de mecanismos implementados, por exemplo: excees.
Eficincia capacidade do componente de apresentar desempenho apropriado, relativo

quantidade de recursos usados, sob condies especificadas (recurso diz respeito configurao
de hardware e software).
Em relao ao tempo capacidade do componente de fornecer tempos de resposta e de

processamento, alm de taxas de transferncia, apropriados, quando o componente executa
suas funes, sob condies estabelecidas. Para isso, avaliado o tempo de resposta que o
componente gasta, desde a requisio que recebida at a resposta que ele envia. Tambm
avaliada a sada que pode ser produzida com sucesso, em um dado perodo de tempo, e
tambm medida a soma de entrada de informao que pode ser processada com sucesso,
pelo componente, em um dado perodo de tempo.
Tempo de resposta verificar o tempo que o componente gasta, desde a requisio que
recebida at a resposta que ele envia;
Capacidade de emisso verificar a sada que pode ser produzida com sucesso, pelo
componente, em um dado perodo de tempo;
Capacidade de recepo verificar a soma de entrada de informao que pode ser

processada com sucesso, pelo componente, em um dado perodo de tempo.
Em relao utilizao de recursos capacidade do componente de usar tipos e quantidades

apropriados de recursos, quando o componente executa suas funes sob condies
estabelecidas. Para isso, avaliada a soma de memria necessria para o componente operar,
e o espao em disco utilizado pelo componente, incluindo o espao utilizado para armazenar
seu cdigo e partes constituintes e o espao utilizado, temporria ou permanentemente, durante
a execuo.
Memria requerida verificar a soma de memria necessria para o componente operar;
Utilizao de disco verificar o espao em disco utilizado pelo componente, incluindo o

espao utilizado para armazenar seu cdigo e partes constituintes e o espao utilizado,
temporariamente ou permanentemente, durante a execuo.
96
O modelo de qualidade para componente de software foi objeto de um projeto FINEP - Financiadora
de Estudos e Projetos -, desenvolvido pela equipe do CTI, e dever ser aplicado em ambiente produtivo
para consolidao da sua adequao.
Requisitos de qualidade e o processo de avaliao da qualidade sero assuntos do prximo captulo.
Os requisitos de qualidade sero abordados para COTS, usabilidade na interface e documentao de
usurio.
97
CAPTULO 5
Requisitos e avaliao da qualidade de software
Com estudos e pesquisas bibliogrficas sobre o tema qualidade de produto de software e a identificao
e explorao da necessidade de mercado, surge uma viso abrangente e profunda sobre o que deve ser
a avaliao da qualidade de produto de software.
Assim, em busca de experincia de organizaes nacionais e internacionais e de contatos com
entidades nacionais representativas de desenvolvedores de software, tais como: ASSESPRO
Associao das Empresas Brasileiras de Tecnologia da Informao, Software e Internet e SOFTEX
Associao para Promoo da Excelncia do Software Brasileiro, surge uma viso de como implementar
e aplicar um processo de avaliao da qualidade de produto de software, com o objetivo de verificar a
qualidade deste em relao a requisitos de padres reconhecidos internacionalmente.
Este captulo apresenta normas especficas para executar uma avaliao. Essas normas so
relativamente recentes; a mais antiga, internacionalmente, de 1998, e as nacionais esto disponveis
desde 2002. Apresenta, tambm, normas especficas para ajudar na especificao de requisitos de
qualidade, sendo elas para documentao de usurio, pacotes de software e usabilidade na interface.
Existem ainda poucos trabalhos prticos de avaliao de produto de software de mbito internacional,
mas indicam uma tendncia na rea e mostram a utilizao das normas abordadas neste trabalho. uma
rea de atuao muito recente, tanto da pesquisa como da aplicao.
5.1 Processo de avaliao da qualidade de produto de software

Um exame sistemtico exige um processo de avaliao que seja responsvel por fornecer passos a
serem seguidos por quem for avaliar a qualidade do produto de software. Um processo de avaliao para
esse exame sistemtico pode ser encontrado na srie NBR ISO/IEC 14598, que est inclusa na srie
25000 e em reviso na parte 2504n Diviso de Avaliao da Qualidade.
Essa srie de normas oferece uma viso geral dos processos de avaliao de produtos de software e
fornece guias e requisitos para avaliao. Nessa srie existe um processo de avaliao genrico, definido
na parte 1, e pode ser particularizado em outras trs situaes diferentes, para a avaliao da qualidade
de produto, focando os processos para desenvolvedores, compradores e avaliadores, respectivamente as
partes 3, 4 e 5 dessa srie.
98
O pblico-alvo da srie NBR ISO/IEC 14598 so desenvolvedores, adquirentes e avaliadores

independentes, particularmente aqueles que so responsveis por avaliaes de produtos de software.
Os resultados de avaliaes obtidos a partir da aplicao da srie NBR ISO/IEC 14598 podem ser
utilizados por gerentes, desenvolvedores e mantenedores, para medir a aderncia aos requisitos e para
fazer melhorias onde necessrias. Esses resultados tambm podem ser utilizados por analistas, para
estabelecer o relacionamento entre medidas internas e externas.
Resumidamente, a srie 14598 est organizada da seguinte forma:
Parte 1 Viso geral do processo de avaliao de produto em geral. Tambm explica o

relacionamento entre a srie NBR ISO/IEC 14598 e o modelo de qualidade apresentado na norma
NBR ISO/IEC 9126-1. Esta parte define os termos tcnicos utilizados nas demais partes, contm
requisitos gerais para especificao e avaliao de qualidade de software e esclarece os conceitos
gerais. Adicionalmente, ela tambm fornece uma estrutura para avaliar a qualidade de quaisquer
produtos de software e estabelece os requisitos para mtodos de medio e avaliao de produtos
de software.
Partes 2 e 6 Apoio ao processo de avaliao de produto. Esto relacionadas ao suporte e gesto

da avaliao corporativa ou departamental. Fornecem exemplos de medidas que correspondem a
uma subcaracterstica. difcil utilizar essas medidas de maneira consistente em uma organizao,
podendo ser necessrio desenvolver novas medidas para uso especfico. Entretanto, necessrio
que uma funo de apoio na organizao especifique cada medida para o uso correto e
consistente dentro da organizao. Convm que se estabelea o formato para documentar uma
medida e mtodos associados, assim como guias para uso. O conceito para um mdulo de
avaliao fornece uma soluo para essa necessidade. A parte 6 trata da documentao de
mdulos de avaliao.
Partes 3, 4 e 5 Requisitos e orientaes para o processo de avaliao de projeto, em trs

situaes: desenvolvimento; aquisio e avaliao independente, incluindo avaliao de terceira
parte.
A relao entre as normas dessa srie pode ser visualizada na Figura 5.1. Cada processo de
avaliao (partes 3, 4 e 5) pode ser usado em conjunto com o suporte avaliao (partes 2 e 6).
Esta figura se refere srie 14598, que est em processo de reviso para a nova srie. Todas as
partes estaro compondo a diviso 2504n, sendo que especificamente a norma NBR ISO/IEC 14598-2
Planejamento e Gesto da Avaliao ir compor a diviso 2500n Diviso de Gesto da Qualidade.
99
Figura 5.1 Relacionamento entre as partes da ISO/IEC 14598.
A elaborao da srie de normas NBR ISO/IEC14598 consolidou-se na estrutura mostrada na Tabela

5.1. Estudos e revises continuam sendo desenvolvidos de forma sistemtica, e as normas so revisadas
e evoludas.
Tabela 5.1 Normas da srie ISO/IEC 14598: Status em 2009.
Norma
14598-1
14598-2
14598-3
14598-4
14598-5
14598-6
Ttulo resumido
Assunto
Estado Internacional
Viso geral da estruturao dessa

Avaliao de Produto de Software
srie de Normas e dos processos Norma, publicada em 1999
Parte 1: Viso Geral
de avaliao
Avaliao de Produto de Software Atividades de planejamento e
Parte 2: Planejamento e
gerenciamento do processo de Norma, publicada em 2000
Gerenciamento
avaliao.
Avaliao de Produto de Software Atividades de avaliao durante o
Parte 3: Processo para a equipe processo de desenvolvimento de Norma, publicada em 2000
de desenvolvimento
software.
Avaliao de Produto de Software Atividades de avaliao no
Parte 4: Processo para o
processo de seleo para
comprador
aquisio de software.
Processo de avaliao, com
Avaliao de Produto de Software
definio das atividades, incluindo
Parte 5: Processo para o
relaes entre avaliador e
Avaliador
requisitante.
Avaliao de Produto de Software Definio da estrutura de Mdulos
Parte 6: Mdulos de Avaliao de Avaliao
Estado Nacional
100
As normas das sries 9126 e 14598 podem ser utilizadas em complementao, umas s outras, de
acordo com o objetivo da avaliao.
A norma NBR ISO/IEC 14598-1 contm conceitos de como avaliar a qualidade de software e define
um modelo de processo de avaliao genrico; junto com as normas NBR ISO/IEC 14598-2 e NBR
ISO/IEC 14598-6, estabelecem itens necessrios para o suporte avaliao; e junto com as normas NBR
ISO/IEC 14598-3, NBR ISO/IEC 14598-4 e NBR ISO/IEC 14598-5, estabelecem processo de avaliao
especfico para desenvolvedores, adquirentes e avaliadores de software, respectivamente. O
relacionamento entre elas pode ser visto na Figura 5.2.
Figura 5.2 Relacionamento entre as sries 9126 e 14598.
A norma NBR ISO/IEC 14598-3, que trata do processo de avaliao para desenvolvedores de
software, aplica-se a todo software e em todas as fases do ciclo de vida de desenvolvimento. Enfoca a
seleo de indicadores, para prever a qualidade do produto final pela medio da qualidade de produtos
intermedirios. Tambm enfoca a medio da qualidade do produto final. Uma organizao deve rever
todos os requisitos e recomendaes indicados na norma:
Requisitos organizacionais infraestrutura que permita a obteno de dados e modificaes nos

processos baseados na anlise dos dados.
Requisitos de projeto processo de desenvolvimento disciplinado, que permita o planejamento e a

conduo das medies do software e sua avaliao; coordenar as atividades de avaliao com
101
suporte; modelo de desenvolvimento similar a projetos anteriores, na sua organizao de

desenvolvimento com mesmo conjunto de atributos, deve tambm ser aplicado nos projetos, para
permitir a anlise dos dados.
Retroalimentao para a organizao muitos mtodos de anlise de dados requerem dados de

projetos desenvolvidos anteriormente, sob condies similares e com requisitos de qualidade
comparveis. A utilizao de dados obtidos em outras experincias recurso para melhorar o
processo de avaliao e os mdulos de avaliao.
O desenvolvedor deve:
tornar os dados coletados disponveis para a organizao, para seu uso em outros projetos de
desenvolvimento;
rever os resultados da avaliao e a validade do processo de avaliao, indicadores e medidas

aplicadas;
melhorar os mdulos de avaliao, incluir a coleta de dados sobre indicadores extras, de maneira a
valid-los para uso posterior, quando necessrio.
Convm que seja aplicado um modelo de desenvolvimento similar ao que foi utilizado em projetos
anteriores, na sua organizao; o mesmo conjunto de atributos seja aplicado nos projetos, de maneira a
permitir a anlise dos dados.
A norma NBR ISO/IEC 14598-4, que trata do processo de avaliao para Adquirentes de software,
deve ser usada na aceitao ou seleo de um produto. A norma contm requisitos e orientaes para
avaliao da qualidade de produto durante a aquisio de produtos de prateleira, produtos de software de
uso geral ou modificaes em produtos de software existentes.
O processo de avaliao nela descrito tambm auxilia a estabelecer regras de deciso sobre a
aceitao de um nico produto, ou selecionar um produto entre produtos alternativos.
A seguir ser abordado especificamente o processo de avaliao de qualidade para produto de
software genrico; em seguida, o processo de avaliao contendo diretrizes sugeridas para avaliadores
de qualidade de produto de software.
5.1.1 Norma NBR ISO/IEC 14598-1 e NBR ISO/IEC 14598-5
A norma NBR ISO/IEC 14598-1 fornece requisitos e recomendaes para implementao prtica da
avaliao de produto de software. O processo de avaliao proposto pode ser usado para avaliar
produtos j existentes ou produtos intermedirios, isto , em desenvolvimento. Pode ser utilizada por
laboratrios de avaliao, fornecedores de software, compradores de software, usurios e entidades
certificadoras, cada qual com seu objetivo.
102
Em termos de caractersticas de qualidade, pode ser usada a norma NBR ISO/IEC 9126-1, por ser
uma norma reconhecida internacionalmente. Entretanto, o processo de mensurar diretamente essas
caractersticas no prtico; necessrio o desdobramento dessas caractersticas em atributos que
possam ser medidos e pontuados. Os atributos devem ser os mais objetivos possveis, para que a
avaliao no sofra interferncia da opinio do avaliador.
Para que a subjetividade da avaliao seja mnima, necessrio que o processo de avaliao seja
repetvel, reproduzvel, imparcial e objetivo. Essas caractersticas so apresentadas na norma NBR
ISO/IEC 14598-5, como caractersticas fundamentais esperadas do processo de avaliao, e so
detalhadas a seguir:
Repetvel a avaliao repetida de um mesmo produto, com mesma especificao de avaliao,

realizada pelo mesmo avaliador, deve produzir resultados que podem ser aceitos como idnticos;
Reproduzvel a avaliao do mesmo produto, com mesma especificao de avaliao, realizada

por um avaliador diferente, deve produzir resultados que podem ser aceitos como idnticos;
Imparcial a avaliao no deve ser influenciada frente a nenhum resultado particular;
Objetiva os resultados da avaliao devem ser factuais, ou seja, no influenciados pelos

sentimentos ou opinies do avaliador.
O processo de avaliao proposto pela norma NBR ISO/IEC 14598-1 inclui quatro etapas de
avaliao, contendo dez atividades, como mostra a Figura 5.3.
103
Figura 5.3 Processo de avaliao segundo a norma NBR ISO/IEC 14598-1.
O processo de avaliao proposto pela norma NBR ISO/IEC 14598-5 semelhante ao da parte 1,
incluindo uma etapa a mais para as etapas da avaliao, a saber: anlise de requisitos da avaliao,
especificao da avaliao, projeto da avaliao, execuo da avaliao e concluso da avaliao, como
pode ser visto na Figura 5.4. Nessa figura, so mostradas, adicionalmente, quais as entradas e sadas de
cada etapa da avaliao.
104
Figura 5.4 Processo de avaliao segundo a norma NBR ISO/IEC 14598-5.
A seguir, detalhada cada uma das atividades:

a) Estabelecimento dos requisitos da avaliao
Nesta etapa, deve-se descrever os objetivos da avaliao. Vrios pontos de vista podem ser
considerados, dependendo dos diferentes usurios do produto, tais como comprador, fornecedor,
desenvolvedor e operador; devem ser descritos os objetivos e os requisitos da avaliao que
dependem da necessidade do solicitante da avaliao, ou seja, do objetivo final da avaliao.
Os solicitantes de uma avaliao podem ser:
1) Equipes de desenvolvimento, que usam o resultado da avaliao para identificar aes
corretivas e determinar estratgias de evoluo;
2) Vendedores, que usam a qualidade como marketing;
3) Compradores, para avaliar os produtos que esto competindo no mercado;
4) Usurios, para obter confiana no produto;
105
5) Comunidade de software, para identificar e validar os mtodos mais adequados de avaliao e,

assim, aumentar a credibilidade das tcnicas;
6) Laboratrios de avaliao, para desenvolver uma abordagem de avaliao mais consistente.
A anlise de requisitos visa definir os requisitos de qualidade do produto. Deve partir dos objetivos
da avaliao que traduzem diretamente o interesse do requisitante da avaliao. A anlise define a
profundidade, a abrangncia, o relacionamento da presente avaliao com outras, e os objetos a
serem avaliados.
b) Especificao da avaliao
Nesta etapa, deve-se definir o escopo da avaliao e as medidas a serem executadas no produto
submetido avaliao, nos seus vrios componentes. O nvel de detalhes na especificao da
avaliao dever ser tal que, na sua base, a avaliao seja repetvel e reprodutvel.
c) Projeto da avaliao
Nesta etapa, devem ser documentados os procedimentos a serem usados pelo avaliador, para
executar as medidas especificadas na fase anterior. O avaliador deve produzir um Plano de
Avaliao, que descreve os recursos necessrios para executar a avaliao especificada, assim
como a distribuio desses recursos nas vrias aes a serem executadas.
d) Execuo da avaliao
Nesta etapa, devem ser obtidos resultados da execuo de aes para medir e verificar o produto
de software, de acordo com os requisitos de avaliao, como descrito na especificao da
avaliao e como planejado no plano de avaliao. Ao executar essas aes, tem-se o rascunho
do relatrio de avaliao e os registros da avaliao.
e) Concluso da avaliao
Nesta etapa, deve-se revisar o relatrio da avaliao e disponibilizar os dados resultantes da
mesma para o requisitante da avaliao.
Para uma avaliao profissional, esses dados so sigilosos e exclusivos ao requisitante da avaliao,
qualquer publicao deles de sua inteira responsabilidade.
No processo de avaliao, a identificao do produto a ser avaliado ainda preliminar. No decorrer
das etapas do processo, mais informaes so obtidas, o que contribui para uma melhor identificao do
produto a ser avaliado. Dvidas que podero ocorrer, dependendo da fase em que se encontrar a
avaliao:
Quando se trata de produto final, de acordo com o escopo da avaliao, poder ser selecionado
todo o produto de software, ou eventualmente apenas alguns de seus componentes. A definio
106
ocorrer quando, no mnimo, os requisitos bsicos de qualidade estiverem definidos. Ser ento
necessrio voltar a esta fase de definio de produtos para a sua complementao.
Um fator que pode ser determinante na seleo dos componentes a serem avaliados a
disponibilidade de mtodos de avaliao na organizao que ir realizar a avaliao. Por exemplo,
suponha-se que um propsito de avaliao seja a escolha entre alguns produtos de mercado e que
um dos requisitos de qualidade para essa escolha seja segurana de acesso a dados. Suponha-se,
tambm, que a organizao no disponha de mtodos de avaliao desse requisito de qualidade.
A no disponibilidade poder determinar que os componentes do produto que tratam
especificamente de segurana de acesso sejam desconsiderados para efeito de avaliao, ou que
esse requisito, caso seja muito importante, tenha que ser avaliado por outra organizao.
Para o produto intermedirio, a definio de qual produto intermedirio ser avaliado mais
complexa, pois depende, em primeiro, lugar do ciclo de vida de desenvolvimento adotado pela
organizao e do estgio em que se encontram seus respectivos produtos. Alm disso, deve-se
considerar que as medidas internas devem ser escolhidas de modo a refletir a futura qualidade
externa do produto. Assim sendo, necessrio conhecer os requisitos externos, para ento definir
que medidas internas so aplicveis aos produtos intermedirios, de modo a obter uma avaliao
efetiva.
As primeiras vezes que essas definies de produtos intermedirios para avaliao so feitas, no se
constituem em um trabalho simples. Porm, em termos prticos, a partir da existncia de um histrico de
medidas aplicadas na organizao, provvel que exista uma referncia emprica a ser considerada,
tanto para a seleo de medidas como para identificao dos produtos a serem avaliados. E, conforme j
mencionado, a escolha inicial tende a ser refinada nas demais fases de avaliao.
5.2 Especificao da avaliao

A fase de especificao da avaliao de um produto de software, neste contexto, traz consigo trs
importantes conceitos: medio, pontuao e julgamento, como mostra a Figura 5.5.
107
Figura 5.5 Conceitos num processo de avaliao.
Medio a ao de aplicar uma medida de qualidade de software a um produto de software

especfico.
Pontuao a ao de transformar a medida obtida em um sistema numrico preestabelecido.
Julgamento a emisso de um juzo sobre a qualidade do produto de software.
Por meio da medio de um produto de software, possvel conhecer qualitativamente o nvel de

qualidade; aps a pontuao, possvel conhecer quantitativamente o nvel de qualidade. Assim, com a
aplicao dos critrios de julgamento, possvel fazer o julgamento da qualidade.
Para fazer medio em produto de software, necessria a utilizao de medida de qualidade de
software. Esta, por sua vez, precisa de um Mtodo de avaliao e de uma Escala, previamente
escolhidos, que podem ser usados para determinar o valor que uma particularidade recebe em um
produto de software especfico.
O Mtodo de avaliao um procedimento com que se descrevem as aes a serem realizadas por
um avaliador, para obter o resultado da medio ou verificao especificadas, quando aplicadas num
produto ou em componentes especificados de um produto de software.
A Escala atribui rtulos numricos aos atributos de uma entidade, resultando a representao da
fidedignidade do atributo. Ela um conjunto de valores com propriedades definidas.
Exemplos de tipos de escalas so:
Escala nominal que corresponde a um conjunto de categorias;
Escala ordinal que corresponde a um conjunto ordenado de pontos de escala;
108
Escala de intervalos que corresponde a uma escala ordenada, com pontos de escala
equidistantes;
Escala de proporo que tem pontos de escala equidistantes e tambm um zero absoluto.
Medidas usando escalas ordinais ou nominais produzem dados qualitativos, e medidas usando
escalas de intervalos ou de proporo produzem dados quantitativos.
De acordo com a norma NBR ISO/IEC 14598-1, uma escala pode assumir diferentes nveis de
pontuao, como mostra a Figura 5.6. O nvel de pontuao deve ter um valor-limite entre o que seja
satisfatrio e insatisfatrio.
Figura 5.6 Nveis de pontuao para as medidas Fonte: NBR ISO/IEC 14598-1 (2002).
A qualidade de uma escala nominal, em sentido abrangente, descreve sua habilidade de refletir
veridicamente uma medida obtida. Uma parte significativa desta construo envolve a semntica da
escala os adjetivos, palavras, frases e construo das sentenas, que iro trazer tona a resposta
correta sobre o assunto.
Ao avaliar um produto de software, o avaliador sempre sofre influncias, sejam elas advindas de
preferncias pessoais, de experincias anteriores, do conhecimento da rea de aplicao do software.
Desse modo, necessrio que as medidas a serem feitas estejam claras e objetivas ao avaliador. A
questo da subjetividade do avaliador deve ser eliminada na medida do possvel, procurando executar
109
uma avaliao que seja imparcial e objetiva, com a utilizao das diretrizes especificadas na norma NBR
ISO/IEC 14598-5.
Para realizar uma avaliao, no basta ter o modelo de qualidade definido por meio das
caractersticas at os atributos ainda preciso estabelecer quais sero os critrios de aceitao, as
medidas e os nveis de pontuao.
Critrio de Aceitao predeterminao dos nveis de pontuaes considerados satisfatrios, ou

no satisfatrios, para um atributo de uma entidade, de acordo com a norma NBR ISO/IEC145981, Medida e Nvel de Pontuao.
Medida Compreende um mtodo e uma escala de medio. Por escala entende-se: um conjunto
de valores com propriedades definidas; por medio, a determinao de um valor (que pode ser
um nmero ou uma categoria) para um atributo de uma entidade.
Nvel de pontuao pontuaes de uma escala ordinal, que utilizada para categorizar uma
escala de medio.
A norma NBR ISO/IEC 9126-1 lembra a necessidade do uso de medidas e nveis de pontuao, alm
de mostrar a relao existente entre eles, conforme mostra a Figura 5.7. No entanto, a norma no os
define, pois eles podem variar de acordo com a organizao e/ou com a aplicao.
Figura 5.7 Valor medido e nvel de pontuao (NBR ISO/IEC 9126-1, 2001).
Dois outros fatores devem ser considerados numa avaliao: o grau de importncia de cada
caracterstica de qualidade e o ponto de vista sob o qual o produto de software est sendo analisado.
Esses fatores podem ser apontados como bastante subjetivos, mas possvel, numa avaliao
comparativa de diferentes aplicaes de software, ponderar as caractersticas de qualidade utilizando um
sistema de pesos proporcionais a sua importncia na rea de aplicao do software.
110
O grau de importncia de cada caracterstica de qualidade varia de software para software. Alguns
exemplos atestam a variao: a confiabilidade mais importante para software de um sistema de misso
crtica; a eficincia mais importante para software de sistema em tempo real; a usabilidade mais
importante para software interativo.
A norma aponta trs pontos de vista a serem considerados em uma avaliao da qualidade de
software: do usurio, da equipe de desenvolvimento e do gerente. Cada um deles tem foco de interesse
prprio:
O usurio est interessado no uso do software, e no nos seus aspectos internos. Ele quer saber
se as funes requeridas esto disponveis no software e quo eficiente, confivel e fcil de usar
o produto.
A equipe de desenvolvimento est interessada tanto na qualidade dos produtos intermedirios

como na qualidade do produto final. O processo de desenvolvimento requer que o usurio e a
equipe de desenvolvimento utilizem as mesmas caractersticas de qualidade de software, uma vez
que elas se aplicam tanto para os requisitos como para a aceitao.
A viso do gerente comercial. Ele est interessado na qualidade de forma geral, e no em

caractersticas especficas de qualidade. Sua responsabilidade otimizar a qualidade, dentro das
limitaes de custo, recursos humanos e prazos.
Resumidamente, a norma ISO/IEC 9126-1 apresenta um modelo para avaliao da qualidade de

produto de software, baseado no desmembramento das seis caractersticas de qualidade. Alm disso,
alerta para a necessidade de se definir, caso a caso, as medidas, nveis de pontuao, critrios de
aceitao, grau de importncia de cada caracterstica e do ponto de vista a ser considerado na avaliao.
Essa abertura permite a aplicao desse modelo nas diversas organizaes de software, em diferentes
necessidades.
As prximas sees trazem requisitos de qualidade que podem ser medidos e avaliados.
5.3 Requisitos para pacotes de software

Entende-se por pacote de software o conjunto completo e documentado de programas fornecidos a
diversos usurios para uma aplicao ou funo genrica. So exemplos de Pacotes de Software:
processadores de texto, planilhas eletrnicas, bancos de dados, software grficos, programas para
funes tcnicas ou cientficas e programas utilitrios, entre outros.
essa classe especfica de produtos de software que conhecida como pacotes de software, e
internacionalmente estabeleceu-se a sigla COTS Commercial Off-The-Shelf, ou seja,produto de
software comercial de prateleira.
111
A norma NBR ISO/IEC 25051 aplicvel avaliao de pacotes de software na forma em que so
oferecidos e liberados para uso no mercado COTS. Incluem-se como possveis usurios dessa norma:
fornecedores que estejam especificando os requisitos para um pacote de software; projetando um

modelo para descrever produtos; julgando seus prprios produtos; emitindo declaraes de
conformidade; submetendo produtos certificao ou obteno de marcas de conformidade;
entidades de certificao que pretendam estabelecer um esquema de certificao por terceira

parte;
laboratrios de teste, que tero de seguir as instrues durante a execuo de testes para
certificao ou para emisso de marca de conformidade;
laboratrios de avaliao, que executam medio e pontuao de requisitos de qualidade de

software;
entidades de credenciamento que credenciam entidades de certificao e laboratrios de testes e

de avaliao;
auditores, quando julgam a competncia de laboratrios de teste e de avaliao;
compradores que pretendam comparar seus prprios requisitos com os aqui descritos; comparar
os requisitos necessrios para executar uma determinada tarefa com a informao presente nas
descries de produtos existentes; procurar por produtos certificados; verificar se os requisitos
foram atendidos;
usurios que se pretendam beneficiar com produtos melhores.
Essa norma estabelece os requisitos para pacotes de software, requisitos de documentao de teste,
instrues para avaliao de conformidade de um pacote de software com relao aos requisitos
preestabelecidos. Alguns produtos de software necessitam de requisitos adicionais: por exemplo,
software em que o requisito de segurana seja um fator crtico; por exemplo, software com diferentes
nveis de acesso de usurios. Nesses casos, devem ser includos outros requisitos importantes para sua
determinada classe de aplicao.
Os requisitos de qualidade estabelecidos nessa norma podem tambm ser utilizados para produtos de
software que no sejam especificamente COTS. Isso pode ser feito verificando, entre os requisitos
estabelecidos na norma, aqueles que podem ser aplicados para quaisquer produtos de software.
A Figura 5.8 mostra a estrutura bsica do contedo da norma, relacionando os requisitos de qualidade
para pacotes, para documentao de teste e avaliao de conformidade e tambm as atividades de
avaliao de conformidade para um pacote de software.
112
Figura 5.8 Estrutura da norma NBR ISO/IEC 25051.
A seguir, ser apresentado cada um dos elementos dessa estrutura.

5.3.1 Requisitos de qualidade para pacotes
importante ressaltar que os requisitos estabelecidos na norma podem ou devem estar presentes no
pacote de software. As formas verbais pode e deve so explicitadas a cada requisito estabelecido, as
quais podem ser Mandatrias (termo deve) ou Recomendveis (termo pode). importante observar
que o uso de um requisito como recomendvel est diretamente relacionado com o tipo do produto, ou
seja, para alguns tipos de produtos esses requisitos podem ser mandatrios. Por exemplo, um sistema de
reserva de passagens areas tem como um dos requisitos mandatrios a Confiabilidade; em um sistema
de entretenimento, a Confiabilidade no Mandatria, e sim Recomendvel.
Um pacote de software deve possuir toda a documentao do pacote, que composta pela Descrio
de Produto, Documentao do Usurio e Software. A seguir so descritos os requisitos de qualidade de
cada um desses componentes.
a) Descrio de produto
A descrio de produto um documento que expe as principais propriedades de um pacote de
software, com os objetivos de:
Auxiliar o usurio ou os potenciais compradores desse produto, na avaliao da adequao do

produto s suas reais necessidades; e
113
Servir como base para testes.
Este documento deve estar disponvel ao usurio, independentemente da aquisio do produto,

por meio de um catlogo, de uma mdia digital e de apresentao ou qualquer outro meio
disponvel que alcance esse objetivo. A descrio deve ser clara, compreensvel e harmnica com
os outros documentos associados. A norma prope aspectos prticos e diretos, indicando o que
deve conter a descrio. Na Tabela 5.2, esto os itens que compem os requisitos do documento
Descrio de produto; nos requisitos propriamente ditos, h uma descrio observando quais so
os mandatrios e os recomendveis, segundo a norma.
Tabela 5.2 Requisitos de qualidade para a descrio do produto.
Item
Disponibilidade
Contedo
Identificao e indicaes
Declaraes sobre funcionalidade
Declaraes sobre confiabilidade
Declaraes sobre usabilidade
Declaraes sobre eficincia

Declaraes sobre manutenibilidade
Declaraes sobre portabilidade
Declaraes sobre qualidade em uso
Requisitos
Deve estar disponvel para adquirentes.
Deve conter as informaes necessrias, no deve conter inconsistncias internas, e as
informaes devem poder ser testadas ou verificadas.
Deve apresentar uma identificao nica; o COTS deve ser indicado pelo nome, verso e
data; deve conter nome e endereo do fornecedor; deve identificar as tarefas e servios
que podem ser realizados; deve indicar o uso de vrios usurios ou para um nico usurio
em um sistema; devem ser identificadas as interfaces, ou software, se houver referncia;
deve indicar se o produto COTS depende de um software e/ou hardware; deve indicar se
oferecido suporte; e deve indicar se oferecida manuteno.
Deve conter informaes sobre as subcaractersticas; deve apresentar uma viso geral
das funes disponveis, os valores-limite, se existirem, e os dispositivos de segurana de
acesso ao produto, quando necessrios.
Deve conter informaes sobre as subcaractersticas ; deve indicar a capacidade do
software de permanecer em operao e deve apresentar as informaes sobre os
procedimentos para salvar e recuperar dados.
Deve conter informaes sobre as subcaractersticas; deve apresentar o tipo de interface
com o usurio; se necessrio algum conhecimento tcnico especfico para o seu uso;
se o produto pode ser adaptado s necessidades do usurio; se h proteo tcnica
contra infrao e se h indicaes de acessibilidade.
Deve conter informaes sobre as subcaractersticas; pode incluir informaes sobre
configuraes do sistema.
Deve conter informaes sobre as subcaractersticas; deve conter declaraes sobre a
manutenibilidade do produto.
Deve conter informaes sobre as subcaractersticas; deve especificar as configuraes
de hardware e software e deve fornecer informaes sobre instalao.
Deve conter informaes sobre as caractersticas e deve disponibilizar o relatrio de
testes.
b) Documentao de usurio
114
A documentao de usurio o conjunto completo de documentos, disponveis na forma impressa

ou no, fornecidos para utilizao de um produto. Essa documentao deve incluir todos os dados
para a instalao, para o uso da aplicao e para a manuteno do produto de software. A norma
ISO 9127 pode ser utilizada para auxiliar nessa documentao. Os principais requisitos da
documentao de usurio esto descritos na Tabela 5.3, com a mesma estrutura da tabela
anterior. Os requisitos obrigatrios prevalecem nesse tipo de documentao.
Tabela 5.3 Requisitos de qualidade para a documentao do usurio.
Item
Requisitos
Completeza
Deve conter todas as informaes necessrias para o uso do produto, tais como estabelecer
todas as funes do pacote, procedimentos de instalao, de backup e os valores-limite.
Correo
A informao apresentada deve estar correta e sem ambiguidade.
Consistncia
Inteligibilidade
Apreensibilidade
Operacionalidade
Deve haver plena coerncia entre a documentao e a descrio do produto. Cada termo
deve ter um nico significado.
Deve ser compreensvel pela classe de usurios que desenvolve atividades com o produto,
utilizando termos apropriados, exibies grficas e explicaes detalhadas.
Deve ser apresentada de forma que facilite uma viso geral, por meio de ndices e tabelas
de contedo.
Deve indicar como imprimir a documentao, se necessrio; deve conter sumrio e deve
definir termos que no sejam comuns.
c) Software
O ltimo componente dos requisitos de qualidade referente ao software; para isso utiliza as
mesmas definies das caractersticas de qualidade da norma NBR ISO/IEC 9126-1. As
caractersticas de Funcionalidade, Confiabilidade e Usabilidade so destacadas e devem ser
verificadas com o uso do produto. No h requisitos especficos para os aspectos de Eficincia,
Manutenibilidade, Portabilidade e Qualidade em uso. Qualquer requisito declarado na
documentao do pacote, referente s caractersticas citadas, deve estar em conformidade. Os
principais requisitos para o software esto descritos na Tabela 5.4.
Tabela 5.4 Requisitos de qualidade para software
Item
Funcionalidade
Confiabilidade
Usabilidade
Requisitos
Devem ser verificados os procedimentos para instalao do produto; a presena de todas as funes
mencionadas; a execuo correta dessas funes; a ausncia de contradies entre a descrio do produto
e a documentao do usurio.
O usurio deve manter o controle do produto, sem corromper ou perder dados, mesmo que a capacidade
declarada seja explorada at os limites ou fora deles, se uma entrada incorreta efetuada, ou ainda se
instrues explcitas na documentao so violadas.
A comunicao entre o programa e o usurio deve ser de fcil entendimento, por meio das entradas de
dados, mensagens e apresentao dos resultados, utilizando um vocabulrio apropriado, representaes
grficas e funes de auxlio (help), entre outras; o programa tambm deve proporcionar uma apresentao
115
e organizao que facilitem uma viso geral das informaes, alm de procedimentos operacionais que o
auxiliem: por exemplo, a reverso de uma funo executada e o uso de recursos de hipertexto em funes
de auxlio, entre outros.
Eficincia
Deve estar em conformidade com as declaraes na descrio do produto.
Manutenibilidade Deve estar em conformidade com as declaraes na descrio do produto.

Portabilidade
O software deve poder ser instalado; a instalao e a operao devem ser verificadas em todas as
plataformas e deve fornecer meios de desinstalao.
Qualidade em uso Deve estar em conformidade com as declaraes na descrio do produto.
5.3.2 Requisitos para documentao de teste

O objetivo da documentao de teste demonstrar a conformidade do software em relao aos requisitos
de qualidade para o software. A documentao de teste deve incluir: plano de teste, descrio do teste e
resultados dos testes, conforme descritos na Tabela 5.5.
Tabela 5.5 Requisitos da documentao de teste
Item
Requisitos
As informaes contidas na documentao de teste devem ser verificveis e corretas e no devem

apresentar contradies. A documentao de teste deve conter o plano, a descrio e os resultados de
testes; deve conter a lista de todos os documentos, e cada documento deve estar completo.
Todas as caractersticas de qualidade devem estar sujeitas a casos de teste e devem ser objetivo de
pelo menos um caso de teste. Todas as funes descritas devem estar sujeitas a casos de teste e
devem ser objetivo de pelo menos um caso de teste. Os casos de teste devem demonstrar a
Plano de teste
conformidade do software. Caso os documentos de requisitos sejam mencionados na descrio de
produto, devem estar sujeitos a pelo menos um caso de teste. O nvel de decomposio funcional, o
mtodo do projeto do caso de teste, os procedimentos de instalao, os limites operacionais, possveis
violaes, exemplos indicados na documentao de usurio devem ser casos de teste.
O objetivo do teste, identificador nico, dados de entrada e limites, detalhamento dos passos, sada
Descrio do teste
esperada para cada caso de teste e critrios para interpretao do resultado.
Relatrio da execuo dos casos de teste, relatrio de no conformidade e julgamento dos resultados do
Resultados dos testes
teste.
Requisitos gerais
5.3.3 Instrues para avaliao de conformidade

A avaliao da conformidade de pacotes de software pode ser vista como uma avaliao de terceiraparte. Sendo a terceira-parte um laboratrio com estruturas de certificao ou um laboratrio de avaliao
interno, que seja independente do desenvolvedor.
Este item especifica como um produto deve ser avaliado em relao aos requisitos de qualidade. Na
Tabela 5.6, so mostradas essas especificaes, dividindo as instrues em fases e recomendaes.
Tabela 5.6 Instrues para avaliao de conformidade
116
Fases
Recomendaes
Pr-requisitos
Todos os itens descritos devem estar presentes e conformes
Atividades
Requisitos especificados na descrio, requisitos especificados na documentao e requisitos

especificados no software devem ser avaliados.
Processo de avaliao
Relatrio
Avaliao na fase de
acompanhamento
O fornecedor deve prover subsdios para avaliao de terceira-parte, obedecendo s atividades do

item anterior.
O relatrio deve conter: identificao do produto, data de encerramento da avaliao, descrio dos
sistemas computacionais utilizados, documentos utilizados, resumo das atividades de avaliao,
resumo dos resultados de avaliao de conformidade, resultado detalhado da avaliao de
conformidade e relao de no conformidades. Esse documento deve ter suas pginas numeradas e
o nmero total de pginas
As partes alteradas nos documentos e software, as partes inalteradas, as que devem ser
influenciadas e as que podem influenciar pelas partes alteradas ou pelas alteraes em um
determinado sistema devem ser avaliadas como se fosse um novo software.
5.4 Outros requisitos de qualidade

Produtos de software geralmente so destinados para um grande nmero de usurios e um diversificado
tipo de usurios. V-se como importante que o produto fornea uma interface, isto , uma interao
homem-mquina, adequada ao uso e uma documentao completa do usurio, para ser consultada.
Assim, apresenta-se a seguir um conjunto de requisitos para a usabilidade na interface e um conjunto
de requisitos para a documentao de usurio.
5.4.1 Requisitos de usabilidade na interface
Projetos de interfaces com usurios e servio ao cliente geraro provavelmente mais valor agregado s
empresas de computadores que a manufatura de hardware; e interfaces com usurios refletem um
caminho para diferenciao de produtos, num mercado dominado pela tendncia dos sistemas abertos.
H um tempo a interao entre o homem e o computador recebeu a designao de user friendly,
porm este termo no o mais adequado, uma vez que:
Usurios no precisam que as mquinas sejam amigveis, precisam de mquinas que no

interfiram nos seus mtodos, quando eles tentam realizar suas tarefas.
As necessidades do usurio podem ser descritas ao longo de uma nica dimenso, por sistemas
que so mais ou menos amigveis. Na realidade, diferentes usurios tm diferentes necessidades,
e um sistema que amigvel para um pode parecer muito tedioso para outro.
Segundo Nielsen (1993), em certo grau, usabilidade um conceito restrito, comparado com a ampla
questo de aceitabilidade de sistema. Tal conceito basicamente, a constatao de que o sistema
117
suficiente para satisfazer todas as necessidades e requisitos dos usurios e outros potenciais
stakeholders, tais como clientes e gerentes. Grande parte da aceitabilidade de um sistema de
computador uma combinao da aceitabilidade social e da aceitabilidade prtica.
Existe, atualmente, uma procura por regulamentao com relao usabilidade. Algumas voltadas
para ergonomia em hardware, que tambm inclui usabilidade de software. Existem normas que esto
sendo criadas, sero oficializadas em alguns pases e, certamente, tero grande impacto em outros.
Pode-se utilizar usabilidade com a seguinte definio:
Usabilidade medida na qual um produto pode ser usado por usurios especficos a fim de atingir
objetivos especficos, como eficcia, eficincia e satisfao, em um determinado contexto de uso.
Usabilidade deve ser considerada como fator importante no projeto de produtos de software porque
diz respeito a quanto os usurios dos produtos so capazes de trabalhar eficazmente, eficientemente e
satisfeitos.
A seguir sero apresentados alguns requisitos que auxiliam na especificao de uma interface,
definidos no conjunto de normas da srie ISO 9241 (1996 e 1997). Assim, sero explicitadas trs
orientaes, abordando: Princpios de dilogo, Orientaes sobre a usabilidade e Organizao da
informao numa interface. Esses assuntos so tratados nas partes 10, 11, 12, respectivamente.
a) Princpios de dilogo
A norma ISO 9241-10, que define princpios de dilogo, estabelece sete princpios importantes para o
projeto e avaliao de um dilogo com computador, ou seja, interface. So eles:
Adequao tarefa um dilogo adequado para uma tarefa quando ele apoia o usurio
na concluso efetiva e eficiente da tarefa;
Autodescrio um dilogo autodescrito quando cada passo imediatamente

compreensvel por meio da resposta do sistema ou explicado ao usurio, quando
solicitado;
Controlabilidade um dilogo controlvel quando o usurio pode iniciar e controlar a

direo e ritmo da interao, at que seu objetivo tenha sido atingido;
Conformidade com expectativas do usurio um dilogo est em conformidade com as

expectativas do usurio, quando consistente e corresponde s caractersticas do usurio,
tais como: conhecimento da tarefa, educao e experincia, e s convenes comumente
aceitas;
Tolerncia a erro um dilogo tolerante a erros se, apesar de erros de entrada evidentes,
o resultado esperado pode ser obtido com pouca ou nenhuma ao corretiva do usurio;
118
Adequao individualizao um dilogo capaz de individualizao quando a interface

pode ser modificada, para se adequar s necessidades da tarefa, preferncias individuais e
habilidades do usurio;
Adequao ao aprendizado um dilogo adequado para aprendizado quando auxilia e

orienta o usurio a usar o sistema.
Com esses sete princpios, a interface de um produto de software ficar mais adequada ao usurio,
permitindo melhor utilizao do produto.
b) Orientaes sobre a usabilidade
A norma ISO 9241-11 estabelece orientaes sobre a usabilidade, atributos de usabilidade e objetivos
dos testes de usabilidade.
Esta norma trata dos benefcios de medir a usabilidade em termos de performance e satisfao do
usurio, que so medidas pela extenso com que as metas pretendidas so alcanadas, pelos recursos a
serem gastos para alcanar as metas, e pela extenso com que os usurios avaliam o produto como
aceitvel.
Esta norma enfatiza que a usabilidade dos computadores depende do contexto de uso, e o nvel de
Usabilidade alcanada depender de circunstncias especficas em que o produto usado.
O contexto de uso consiste em usurios, tarefas, equipamentos, tais como hardware, software e
materiais; ambiente fsico e social, que podem influenciar a Usabilidade de um produto num sistema de
trabalho. Medidas de performance e satisfao do usurio avaliam o sistema de trabalho como um todo.
Quando um produto o foco de interesse, essas medidas fornecem informaes sobre a usabilidade
daquele produto num contexto de uso particular, fornecido pelo resto do sistema de trabalho. Esses
efeitos de mudanas em outros componentes do sistema de trabalho, tais como a quantidade de
treinamento ao usurio, ou melhoria da iluminao, podem ser medidos pela satisfao e performance do
usurio.
A usabilidade dos produtos pode ser melhorada com a incorporao de caractersticas e atributos
conhecidos, para beneficiar os usurios em um contexto de uso particular. Para determinar o nvel de
usabilidade obtida, necessrio medir a performance e a satisfao dos usurios que trabalham com o
produto. Medida de usabilidade particularmente importante do ponto de vista da complexidade das
interaes entre o usurio, os objetivos, as caractersticas das tarefas e os outros elementos do contexto
de uso. Um produto pode ter significativamente diferentes nveis de usabilidade, quando usado em
diferentes contextos.
c) Organizao da informao
A norma ISO 9241-12 estabelece a organizao da informao distribuda numa interface.
119
A apresentao da informao deve permitir ao usurio realizar tarefas de maneira eficiente, eficaz e
com satisfao. Para atingir esse objetivo, os seguintes atributos devem ser considerados:
Clareza o contedo da informao passado rpida e corretamente;
Descrio a informao apresentada pode ser corretamente distinguida;
Conciso os usurios no so sobrecarregados com informaes fora do contexto;
Consistncia design nico, em conformidade com a expectativa do usurio;
Deteco a ateno do usurio direcionada para a informao requerida;
Legibilidade a informao fcil de ser lida;
Compreensibilidade o significado claramente compreendido, sem ambiguidade,

interpretvel e reconhecido.
As orientaes apresentadas nessas trs normas podem ser consideradas na elaborao de medidas
de usabilidade de interface, num produto de software; so orientaes em que existe consenso na rea.
5.4.2 Requisitos para documentao de usurio
A documentao de software um produto fundamental, gerado no processo de desenvolvimento de
software. importante que o documento retrate fielmente o software, de modo que as atividades como
avaliao e modificao do software possam ser realizadas sem maiores transtornos, possibilitando
facilidade e maior eficincia no manuseio do software por parte dos usurios.
A seguir apresentam-se duas normas sobre documentos de usurio. Uma norma a ANSI/IEEE 1063
(1987), que especifica os requisitos mnimos sobre a estrutura e o contedo da informao de um
documento do usurio de software; a outra a norma ISO 9127 (1988), sobre documentao de usurio
e informao de capa para compradores de produtos de software.
5.4.2.1 Documento do usurio de software

Segundo a norma ANSI/IEEE 1063, documento do usurio de software o corpo do material que fornece
informaes aos usurios; tipicamente na forma de material impresso ou armazenado em algum outro
meio, no formato de um documento impresso. Os requisitos bsicos de documentao de usurio esto
apresentados na Tabela 5.7
Tabela 5.7 Requisitos bsicos de Incluso de um Documento de Usurio do Software.
120
Volume nico
Componente
Multivolumes
8 Pginas ou Menos
Mais que 8 Pginas
Primeiro Volume
Demais Volumes
Pgina de Ttulo
Restries
Garantias
ndice
Lista de ilustraes
R
M
R
R
R
M
R
M
M
M
M
R
M
M
M
M
M
M
R*
M
M
R
M
R
R
R
R
R
1
1
1
1
1
1
Condies de erro
1
1
R
Anexos
Bibliografia
M**
M**
Glossrio
M**
M**
ndice remissivo
M**
M**
Introduo
Descrio do Pblico-alvo
Aplicabilidade
Objetivo
Uso do Documento
Documentos relacionados
Convenes
Relato de problemas
Corpo do Documento
Modo Instrutivo
Modo de Referncia
Legenda da Tabela 5.7
M Obrigatrio: deve ser includo quando a informao existe.
O Opcional.
R Referncia: includo numa seo ou referenciado onde a informao pode ser encontrada
dentro do conjunto de documentos.
* deve mostrar o relacionamento com os outros volumes do conjunto de documentos.
** Obrigatrio em pelo menos um dos volumes do conjunto de documentos, e referncia a
informaes, nos demais volumes.
1 Todo documento tem um corpo; cada conjunto de documentos dever apontar as necessidades
de modo instrutivo e de referncia do pblico-alvo.
121
2 Para documentos com 40 ou mais pginas, obrigatrio um ndice, sendo opcional para
documentos com menos de 40 pginas.
Essa norma se aplica documentao que direciona o usurio na instalao, operao e

gerenciamento do software.
O documento do usurio de software deve identificar o produto de software, suas aplicaes e o
pblico-alvo que ir utilizar o produto; deve determinar o conjunto de documentos para cada pblico-alvo
e o modo de uso de cada documento. O modo de uso pode ser para aprender sobre o software, ou seja,
o seu uso Modo Instrutivo; ou para ajudar em uma busca rpida sobre algum ponto especfico do
software: ento, seu uso Modo de Referncia.
A norma fornece os requisitos para incluso de informao; alguns requisitos so mandatrios, outros
so opcionais. Esses requisitos podem variar, dependendo de que a documentao esteja includa num
nico volume ou em mais volumes, e foram sumariamente apresentados na Tabela 5.7.
Alm dos requisitos de contedo, a norma descreve como apresentar o material na documentao de
modo que os documentos sejam fceis de ler e compreender.
5.4.2.2 Documentao de usurio e Informao de capa para compradores de pacotes

de software
A norma ISO 9127 descreve a documentao do usurio e a informao de capa fornecida para
compradores de pacotes de software.
Segundo a norma, a documentao do usurio fornece ao usurio final toda a informao necessria
para instalar e executar o software. Tipicamente, essa documentao, em forma impressa ou eletrnica,
vem includa dentro do pacote de software; ela s estar disponvel ao usurio aps a compra do pacote
de software. A informao de capa est disponvel para o possvel comprador, externamente ao produto,
para que ele possa decidir sobre a aplicabilidade do software, mediante suas necessidades.
Uma lista de itens recomendados para o contedo de uma documentao de usurio apresentada
na Tabela 5.8.
Tabela 5.8 Itens de informao recomendados para um Documento de Usurio
Item da informao
Categoria
Identificao do pacote
ESS
Contedo do pacote
ESS
Descrio funcional do software
ESS
Instalao do software
ESS
122
Utilizao do software
ESS
Informao tcnica do software
CON
Teste
OPT
Informao contratual
ESS
Glossrio
CON
ndice
CON
Comentrios de usurios
OPT
Legenda da Tabela 5.8:
ESS Informao essencial.
OPT Informao opcional.
CON Informao condicional, se necessria.
O objetivo da documentao do usurio fornecer, ao usurio final, informao suficiente para um

claro entendimento dos seguintes assuntos: objetivo, funes e caractersticas do software; como instalar
usar o software; e direitos e responsabilidades contratuais.
Uma lista de itens recomendados para o contedo de uma informao de capa apresentada na
Tabela 5.9.
Alm da documentao de usurio, a norma sugere outro documento, denominado informao de
capa, com o objetivo de permitir que potenciais compradores possam avaliar a aplicabilidade do software
quanto s suas necessidades.
Tabela 5.9 Itens de informao recomendados para o contedo da Informao de capa.
Item da informao
Categoria
Identificao do pacote
ESS
Propsito e campo de aplicao
ESS
Ambiente
ESS
Entrada
OPT
Sada
OPT
Restries
CON
Instrues para uso
OPT
Informao suplementar
OPT
Informao contratual
ESS
Contatos do fornecedor
OPT
123
Itens fornecidos
ESS
Padres e leis
OPT
Certificao independente
OPT
Cdigo do produto
ESS
Preo
OPT
Marca registrada
OPT
Legenda da Tabela 5.9:
ESS Informao essencial.
OPT Informao opcional.
CON Informao condicional, se necessria.
O objetivo deste captulo foi relatar as normas existentes para avaliao e requisitos de qualidade e
mostrar como um produto de software pode ser avaliado, de acordo com requisitos estabelecidos em
normas internacionais de qualidade.
No Captulo 6, ser apresentada a metodologia de avaliao de produto de software, de acordo com
os requisitos de qualidade e processo de avaliao definidos nas normas de qualidade apresentadas at
aqui.
124
CAPTULO 6
Metodologia do processo de avaliao
Descritas as normas reconhecidas internacionalmente com modelos e processos da rea de qualidade de
produto de software, o prximo passo apresentar um mtodo sistemtico para avaliao. Essa
metodologia est de acordo com o processo de avaliao estabelecido pela norma NBR ISO/IEC 14598-1
e 14598-5, com o foco de viso do usurio; foi desenvolvida no mbito do CTI e demonstrou ser uma
metodologia til para avaliar produtos de software.
No processo de avaliao, existem vrios agentes atuantes, ou pessoas com diferentes funes a
serem exercidas em determinadas atividades desse processo, tais como:
Requisitante da avaliao a pessoa ou entidade que tem interesse na avaliao; ela

especificar o objetivo da avaliao e, finalmente, receber o resultado.
Coordenador da avaliao a pessoa responsvel por conduzir o processo de avaliao como

um todo.
Avaliador a pessoa responsvel pela medio do processo.
Profissional estatstico a pessoa de apoio estatstico, no momento de estabelecer a pontuao

das medidas e a classificao dos dados resultantes da avaliao.
Comit de julgamento em alguns casos de avaliao, pode ser necessrio montar um comit de
profissionais (com conhecimento especfico na rea de aplicao do produto de software), para
auxiliar na fase de pontuao e na fase de especificao dos critrios de julgamento, ajudando a
estabelecer os juzos de valores das medidas.
Essas funes podem ser executadas por diferentes pessoas ou, em alguns casos, o coordenador da
avaliao e o avaliador podem ser uma s pessoa.
O processo de avaliao descrito neste capitulo composto de cinco fases, que apresentam uma
estrutura bem definida:
Estabelecer requisitos de avaliao,
Especificar a avaliao,
Projetar a avaliao e
Executar a avaliao.
125
Concluso da avaliao.
Cada uma delas apresenta passos bem determinados, que podem garantir o resultado esperado do
processo. A Figura 6.1 apresenta, de forma esquemtica, as atividades de um processo de avaliao
genrico, que esto descritas na norma NBR ISO/IEC 14598-1, sendo que a concluso da avaliao
uma sugesto de atividade proposta na parte 5. Esta figura mostra a importncia da existncia de um
patrocinador e de um produto executvel para avaliao.
Figura 6.1 Processo de Avaliao segundo a norma NBR ISO/IEC 14598-1.
A seguir, ser apresentada cada uma das fases do processo de avaliao, com sugestes para
programar as dez atividades nele definidas.
6.1 Estabelecer requisitos de avaliao

O objetivo desta fase estabelecer o que se quer avaliar e o que se quer como resultado da avaliao. O
requisitante da avaliao e o coordenador da avaliao tm atuao essencial nesta fase, para que,
juntos, possam consolidar os requisitos da avaliao e esclarecer o resultado da avaliao a ser obtido.
126
Nesta fase do processo de avaliao, esto previstas as seguintes atividades:
Estabelecer o propsito da avaliao;
Identificar o tipo de produto a ser avaliado e
Especificar o modelo de qualidade.
6.1.1 Estabelecer o propsito da avaliao

Para que o objetivo da avaliao seja bem claro, importante que o requisitante da avaliao identifique
o software e a verso a ser avaliada. O seguinte questionrio sugerido:
Nome do produto:
Verso do produto:
1.
Qual o domnio da aplicao do produto?
2.
Qual seu objetivo em relao avaliao?
Assegurar a qualidade do produto?

Indicar pontos para melhoria no produto?
Adequar o produto s normas de qualidade para produto de software?
Comparar com outros produtos similares?
Obter um laudo tcnico da sua qualidade?
Classificar e premiar um conjunto de produtos de software?
Pr-qualificar produtos de software numa licitao?
Outros. Quais? Resp.:
3.
Quais os aspectos de qualidade do produto que o requisitante da avaliao pretende que sejam
avaliados e com que nfase?
Funcionalidade. nfase (1 a 5): ________________________________

Confiabilidade. nfase (1 a 5): ________________________________
Usabilidade. nfase (1 a 5): __________________________________
127
Portabilidade. nfase (1 a 5): _________________________________

Eficincia. nfase (1 a 5): ___________________________________
Completitude. nfase (1 a 5): ________________________________
nfase varia de 1 a 5 da seguinte maneira:
1 nenhum interesse
2 baixo interesse
3 mdio interesse
4 largo interesse
5 grande interesse
6.1.2 Identificar o tipo de produto a ser avaliado
A norma NBR ISO/IEC 25051 estabelece que, para ser um pacote de software, este deve conter:
descrio do produto, documentao de usurio e software. Esta afirmao serve tambm para avaliao
de software de diferentes categorias, como as citadas no Captulo 3. Em casos especficos, algumas
adaptaes no processo de avaliao so necessrias para adequao ao produto a ser avaliado. A
seguir, apresentam-se algumas questes para identificar o produto a ser avaliado e identificar as
caractersticas do produto a ser avaliado, com relao ao seu porte, documentos que o produto oferece, e
requisitos de hardware e software necessrios para executar o produto.
Para que seja possvel identificar o produto a ser avaliado, sugerido que o requisitante da avaliao
identifique o software e a verso a ser avaliada. O seguinte questionrio sugerido:
Nome do produto:
Verso do produto:
1.
Descrio geral do produto:
De quantas funes o produto composto? (Obs.: Funes o nmero completo de funes da

interface do usurio) Resp.:
Quais so as principais tarefas do produto?
Quais funes merecem maior dedicao durante a avaliao?
Resp.:
Quantas janelas de interao de dados com o usurio o produto possui?
Resp.:
Resp.:
128
Quem so os principais usurios do produto?
2.
Como o ambiente no qual o produto ser inserido?
Nvel de conhecimento exigido dos usurios em relao informtica. Resp.:
Nvel de conhecimento exigido dos usurios em relao ao domnio da aplicao em si. Resp.:
3.
Quais so os principais componentes do produto que sero submetidos avaliao?

Documento
Resp.:
Impresso (no de pgs.)
On Line (no de janelas)
Manual do Usurio
Manual de Operao
Procedimentos para Instalao
Descrio do Produto (folder, catlogo, site, etc.)
Outros. Quais?
4.
Existe massa de dados disponvel para a avaliao, ou seja, dados-exemplos para agilizar a
avaliao?
Resp.:
5.
Especificar os requisitos de hardware e software para executar o produto de software.

Rede (S/N):
Quais:
Processador:
Clock MHz:
Espao necessrio em Disco Mb:
Memria Mb:
Monitor:
Unidade de Drive:
Ambiente Operacional:
Hardware Adicionais (impressora, scanner, hardlock..) :
Software Adicionais:
Multiplataforma (S/N):
Quais:
6.1.3 Especificar o modelo de qualidade

O modelo de qualidade adotado foi o definido pela norma NBR ISO/IEC 9126-1. A sugesto a definio
do modelo de qualidade para avaliao de software, apresentado na seo 4.4, o qual estruturado por
sete componentes, e cada um desses componentes com suas respectivas caractersticas de qualidade,
como mostra a Figura 6.2:
129
Figura 6.2 Estrutura do modelo de qualidade.
Este modelo de qualidade pode ser visto como um modelo genrico para avaliar software,
independente da sua rea de aplicao. Em determinados casos ele pode ser adaptado ao contexto do
software a ser avaliado, dependendo do objetivo da avaliao explicitado pelo requisitante. Por exemplo,
se o software no tiver embalagem ou descrio do usurio esses componentes podem ser
desconsiderados.
6.2 Especificar a avaliao

O objetivo desta fase definir as medidas a serem utilizadas na avaliao e estabelecer suas respectivas
pontuaes, para serem representadas como resultado da avaliao. O coordenador da avaliao e o
profissional com conhecimentos estatsticos tm atuao essencial nesta fase, pois ser necessrio
converter as medidas obtidas numa escala numrica normalizada.
Nesta fase do processo de avaliao, esto previstas as seguintes atividades:
Selecionar medidas;
Estabelecer nveis de pontuao para as medidas e
Estabelecer critrios para julgamento.
6.2.1 Selecionar medidas

De acordo com o modelo de qualidade definido na Seo 6.1.3, o prximo passo desdobrar as
subcaractersticas de qualidade em atributos que possam ser medidos e pontuados.
A metodologia adotada aqui foi a elaborao de uma lista de verificao, onde cada componente do
software foi desdobrado em questes e itens que possam ser verificados e respondidos pelo avaliador. O
desdobramento em itens tem o objetivo de criar uma escala adequada, facilitando o uso pelos
130
avaliadores, pois os itens so usados como guias. Devem ser, portanto, os mais completos e
abrangentes possveis, expressando corretamente o significado do atributo, do ponto de vista da
avaliao. A soma desses itens fornecer o escore do atributo; os valores possveis dessa soma
formaro a escala.
A proposta ter um conjunto de itens que mais se relacione com a ideia expressa no atributo, visando
obter um conjunto de questes, definindo uma escala diferente para cada assunto expresso no atributo.
Assim, aqueles assuntos mais complexos tero escalas mais detalhadas, e aqueles mais simples tero
escalas mais reduzidas, facilitando o uso pelos avaliadores e posicionando-os adequadamente frente a
cada situao.
O nmero de itens do atributo depende da complexidade e do grau de subjetividade dele; assim, o
nmero de itens varia de acordo com cada atributo.
Quando solicitado ao avaliador que avalie um produto por meio de um conjunto de atributos, dado
a ele um conjunto de opes, ou conceitos, cuja situao relativamente ao produto o avaliador deve
relatar. O conjunto de conceitos utilizados para um atributo reflete uma escala de respostas que sero
usadas, numericamente, por meio de escores. O conjunto total de atributos vlidos ser, ento, usado
para avaliar o produto.
Usando somente os itens vlidos, por meio de um algoritmo simples, pode-se determinar o escore
final do atributo. Observa-se que no o conceito dado a um simples item que determina o valor do
escore, mas sim o conjunto de itens que o atributo possui.
Em relao s questes que fazem parte dessa lista de verificao, o avaliador deve considerar que
as questes so proposies lgicas sobre um atributo a ser verificado em uma avaliao. Cada
proposio dever ser o mais objetiva possvel, envolvendo apenas um aspecto a ser medido.
Algumas respostas possveis para as questes so:
S (Sim): para proposies verdadeiras;
N (No): para proposies falsas;
NA (No se Aplica): para proposies que fazem referncia a um aspecto que no se enquadra
no produto em avaliao.
O avaliador deve estar atento para o fato de que ausncia daquilo que est sendo avaliado nem
sempre significa que a atribuio ser N (No). O avaliador deve verificar se a proposio se aplica ao
produto de software. Exemplo: se para colocar um produto de software em uso, no existe a necessidade
de utilizar nenhum dispositivo de entrada de dados, ento o avaliador dever optar pela alternativa NA
(No se Aplica).
131
AP (Avaliao Prejudicada): para proposies que o avaliador no est em condies de avaliar,

ou por falta de recursos, por falta de informaes, ou mesmo por falta de conhecimento especfico
sobre o assunto abordado.
A atribuio dessa alternativa pouco desejvel, pois significa que os recursos de que se dispe so
insuficientes. Exemplo: se a avaliao estiver sendo executada com um equipamento cuja resoluo
grfica diferente da exigida, ento o avaliador dever optar pela alternativa AP (Avaliao
Prejudicada).
Podem existir outros tipos de respostas, dependendo da proposio lgica feita. H situaes em que
a medida pode ser quantificada em faixas de valores, tais como:
A (Algumas vezes), N (Nunca) ou
M (Muitas), P (Poucas) ou
M (Muitos), N (Nenhum), P (Poucos) ou
A (Alguns), N (Nenhum), T (Todos).
A Tabela 6.1 mostra os sete componentes do modelo de qualidade e para cada componente, os
atributos a serem avaliados.
Tabela 6.1 Subconjunto do modelo de qualidade
Componente
Instalao
Caracterstica
Atributo
Completitude
Especificao dos requisitos de Hardware na Documentao do usurio
Portabilidade
Instrues para Instalao
Completitude
Identificao do produto
Usabilidade
Apresentao visual
Funcionalidade
Acurcia
Usabilidade
Clareza
Funcionalidade
Padres Internos
Funcionalidade
Acesso Seletivo
Eficincia
Interao com perifricos
Confiabilidade
Backup
Portabilidade
Ambiente de Software
Descrio do Produto
Completitude
Identificao do Produtor
Embalagem
Completitude
Identificaes
Usabilidade
Aspectos prticos
Documentao do usurio
Interface
Software
132
Desinstalao
Funcionalidade
Aspectos de robustez
Portabilidade
Instrues
Exemplos de medidas podem ser baseados nos relatrios tcnicos ISO/IEC 9126-2, 9126-3 e 9126-4.
Esta metodologia utilizou medidas com resultados qualitativos. A seguir so apresentados exemplos de
medidas para cada atributo de qualidade da Tabela 6.1.
Componente: Instalao
Primeiramente, na fase da Instalao, mostra-se o atributo Especificao dos requisitos de hardware na
Documentao do Usurio, com as seguintes medidas, em forma de proposies:
Na documentao do usurio:
(_____) .1.
est especificado o tipo de processador necessrio para colocar o produto em uso.

S=Sim; N=No.
(_____) .2.
est especificada a memria RAM necessria para colocar o produto em uso;

S=Sim; N=No.
(_____) .3.
esto especificados os dispositivos de entrada de dados necessrios para colocar o

produto em uso. Ex.: CD-Rom, microfone, placa de som, teclado, scanner etc.;
T=Todos; A=Alguns; N=Nenhum.
(_____) .4.
esto especificados os dispositivos de sada de dados necessrios para colocar o produto

em uso. Ex.: CD e DVD, alto-falante, fones de ouvido, placa de som, impressoras, plotters
etc.;
(_____) .5.
est especificado o tamanho do perifrico de armazenamento necessrio para colocar o

produto em uso.
S=Sim; N=No.
(_____) .6.
esto especificadas as placas de expanso necessrias para colocar o produto em uso.

Ex.: placa de acelerao grfica;
S=Sim; N=No.
Em outra medida, na fase da Instalao, mostra-se o atributo Instrues para Instalao, com as
seguintes medidas em forma de proposies:
133
Se a instalao pode ser conduzida pelo usurio, a documentao do usurio:

(_____) .1.
apresenta instrues para instalao, disponveis antes de realiz-la.

S=Sim; N=No.
Apresentando, as instrues de instalao:

(_____) .2.
orientam passo a passo como executar as aes da instalao;

S=Sim; N=No.
(_____) .3.
esto claras quanto ao que deve ser realizado;

T=Todas; A=Algumas; N=Nenhuma.
(_____) .4.
fornecem as informaes necessrias para instalar o software.

S=Sim; N=No.
Componente: Documentao do usurio

No componente do produto de software Documentao do Usurio Impressa e/ou On-line, mostra-se
o atributo Identificao do Produto, com as seguintes medidas, em forma de proposies:
Os documentos do usurio impressos esto identificados na capa com:
(_____) .1.
o nome do produto;
(_____) .2.
a verso ou data de criao do produto;

A documentao do usurio on-line est identificada com:

(_____) .3.
o nome do produto;
S=Sim; N=No.
(_____) .4.

S=Sim; N=No.
Em outro exemplo de medida, no componente do produto de software Documentao do Usurio

Impressa e/ou On-line, mostra-se o atributo Apresentao Visual, com as seguintes medidas, em
forma de proposies:
134
A documentao do usurio impressa:

(_____) .1.
possui tamanhos de letra de fcil leitura;

T=Todos; Q=Quase todos; A=Alguns; N=Nenhum.
(_____) .2.
possui tipos de letra de fcil leitura;

(_____) .3.
apresenta textos, tabelas e grficos com uma diagramao bem distribuda;

S=Sempre; A=Algumas vezes; N=Nunca.
A documentao do usurio on-line:

(_____) .4.
possui tamanhos de letra de fcil leitura;

(_____) .5.
possui tipos de letra de fcil leitura;

(_____) .6.
apresenta textos, tabelas e grficos com uma diagramao bem distribuda.

Em outro exemplo de medida, no componente do produto de software Documentao do Usurio

Impressa e/ou On-line, mostra-se o atributo Acurcia, com as seguintes medidas, em forma de
proposies:
Na documentao do usurio impressa:
(_____) .1.
foram encontradas evidncias de informaes incorretas. Por exemplo: informaes sobre

convenes: unidades de medida, nome da moeda corrente, nmero de casas decimais,
notao etc.
M=Muitas; P=Poucas; N=Nenhuma.
Na documentao do usurio on-line:

(_____) .2.
foram encontradas evidncias de informaes incorretas. Ex.: informaes sobre

convenes: unidades de medida, nome da moeda corrente, nmero de casas decimais,
notao etc.
135
Componente: Interface
No componente do produto de software Interface de Usurio, mostra-se o atributo Clareza, com as
seguintes medidas, em forma de proposies:
A interface:
(_____) .1.
apresenta erros gramaticais;

M=Muitos; P=Poucos; N=Nenhum.
(_____) .2.
apresenta erros ortogrficos;

M=Muitos; P=Poucos; N=Nenhum.
A interface:
(_____) .3.
destaca as palavras em outro idioma. Exemplos: entre aspas, itlico etc;

T=Todas; A=Algumas; N=Nenhuma.
(_____) .4.
utiliza cdigos e terminologias no significativas.

S=Sim; N=No.
O texto apresentado na interface:

(_____) .5.
d margem a interpretaes ambguas.

Em outro exemplo de medida, no componente do produto de software Interface de Usurio, mostrase o atributo Padres Internos, com as seguintes medidas, em forma de proposies:
A interface mantm uma padronizao prpria em relao:
(_____) .1.
ao idioma do mercado a que se destina o produto;

S=Sim; N=No.
(_____) .2.
configurao de janelas;
S=Sim; N=No.
(_____) .3.
formatao de cones;
S=Sim; N=No.
(_____) .4.
s mensagens;
136
S=Sim; N=No.
(_____) .5.
apresentao de resultados ao usurio;

S=Sim; N=No.
(_____) .6.
posio de um determinado boto que executa uma mesma funo em caixas de dilogo
distintas. Ex.: boto Cancelar, Imprimir, OK etc.;
S=Sim; N=No.
(_____) .7.
aos formatos dos campos de entrada de dados;

S=Sim; N=No.
(_____) .8.
ao formato do cursor para uma mesma situao;

S=Sim; N=No.
Componente: Software
No componente Software, mostra-se o atributo Acesso Seletivo, com as seguintes medidas, em forma
de proposies:
O software:
(_____) .1.
tem implementado o recurso para acesso seletivo. Ex.: permite acesso de usurios a
determinadas tarefas por meio de senhas.
S=Sim; N=No.
Possuindo o recurso para acesso seletivo:

(_____) .2.
compatvel com o tipo de informao que manipula;

S=Sim; N=No.
(_____) .3.
possui o recurso de controle de nmero de tentativas para a digitao de senhas;

S=Sim; N=No.
(_____) .4.
permite que cada usurio altere sua prpria senha;

S=Sim; N=No.
(_____) .5.
impede a entrada de usurios no autorizados.

S=Sim; N=No.
137
Em outro exemplo de medida, no componente Software, mostra-se o atributo Interao com

perifricos, com as seguintes medidas, em forma de proposies:
Quando o software est interagindo com os perifricos (modem, impressora, scanner etc.):
(_____) .1.
o tempo de resposta compatvel com o perifrico;

(_____) .2.
isso impede o uso de outras funes.

Em outro exemplo de medida, no componente Software, mostra-se o atributo Backup, com as

seguintes medidas, em forma de proposies:
O software:
(_____) .1.
possui recursos para backup dos dados.

S=Sim; N=No.
Possuindo recurso de backup, ele oferece flexibilidade para determinar:

(_____) .2.
o intervalo de tempo entre backups;

S=Sim; N=No.
(_____) .3.
aps qual operao deve ser feito o backup dos dados.

S=Sim; N=No.
Finalmente, em outro exemplo de medida, no componente Software, mostra-se o atributo Ambiente

de Software, com as seguintes medidas, em forma de proposies:
O software:
(_____) .1.
pode ser instalado em outro ambiente operacional de software especificado na

documentao do usurio (Ex.: Windows NT, MAC OS, Unix, etc.). Qual (is):
S=Sim; N=No.
(_____) .2.
pode ser instalado em ambiente de rede.

S=Sim; N=No.
Quando instalado em outro ambiente operacional de software especificado, o software:
138
(_____) .3.
executa do mesmo modo, tanto num ambiente quanto no outro, sem que o usurio possa
perceber diferenas.
Componente: Descrio do Produto

No componente Descrio do Produto, mostra-se o atributo Identificao do Produtor, com as
seguintes medidas em forma de proposies:
No documento de descrio do produto est indicado:
(_____) .1.
o nome do produtor. Pode ser carimbo ou etiqueta impressa;

S=Sim; N=No.
(_____) .2.
o endereo do produtor. Pode ser carimbo ou etiqueta impressa;

S=Sim; N=No.
(_____) .3.
o telefone, fax, e-mail, site ou outra forma de contato com o produtor.

S=Sim; N=No.
Componente: Embalagem
No componente Embalagem, mostra-se o atributo Identificaes, com as seguintes medidas, em
forma de proposies:
A embalagem possui corretamente:
(_____) .1.
o nome do produto;
S=Sim; N=No.
(_____) .2.

S=Sim; N=No.
(_____) .3.
o nome do produtor;
S=Sim; N=No.
(_____) .4.
os requisitos de hardware necessrios para colocar o produto em uso;

S=Sim; N=No.
(_____) .5.
os requisitos de software necessrios para colocar o produto em uso;
139
S=Sim; N=No.
(_____) .6.
identificao das tarefas ou funes que podem ser executadas, utilizando-se o software;
S=Sim; N=No.
Em outro exemplo de medida, no componente Embalagem, mostra-se o atributo Aspectos Prticos,

com as seguintes medidas, em forma de proposies:
A embalagem:
(_____) .1.
possui um encaixe prtico e simples para abrir e fechar;

S=Sim; N=No.
(_____) .2.
dificulta o manuseio da mdia;

S=Sim; N=No.
(_____) .3.
dificulta o manuseio da documentao do usurio impressa;

S=Sim; N=No.
(_____) .4.
acondiciona os outros componentes, de forma a dificultar seu manuseio. Ex.: hardlock,

cabos etc.
S=Sim; N=No.
Em outro exemplo de medida, no componente Embalagem, mostra-se o atributo Aspectos de

Robustez, com as seguintes medidas, em forma de proposies:
A embalagem:
(_____) .1.
quebra ou rasga com facilidade;

S=Sim; N=No.
(_____) .2.
acondiciona os componentes, de forma a proteg-los contra choques, umidade. Ex.:

apresenta, no seu interior, materiais, tais como: plstico de bolhas, espuma, isopor,
papelo etc.;
S=Sim; N=No.
(_____) .3.
contm a mdia embalada;

S=Sim; N=No.
140
(_____) .4.
contm os manuais embalados separadamente dos outros componentes. Ex.: envelope,

invlucro plstico etc.;
S=Sim; N=No.
Componente: Desinstalao
Finalmente, na fase de Desinstalao, mostra-se o atributo Instrues para Desinstalao na
Documentao do Usurio, com as seguintes medidas em forma de proposies:
A documentao do usurio:
(_____) .1.
apresenta instrues para realizar sua desinstalao.

S=Sim; N=No.
Apresentando, as instrues de desinstalao:

(_____) .2.
orientam, passo a passo, como executar as aes da desinstalao;

S=Sim; N=No.
(_____) .3.
fornecem as informaes necessrias para desinstalar o software com sucesso.

S=Sim; N=No.
Dessa maneira, outras medidas podem ser definidas, desdobrando os atributos do modelo de
qualidade.
O Apndice A apresenta outros exemplos de medidas que esto agrupadas em forma de lista de
verificao, seguindo este modelo de qualidade.
6.2.2 Estabelecer nveis de pontuao para as medidas
Depois da seleo de medidas, o prximo passo estabelecer nveis de pontuao para os resultados
obtidos pelas medidas. Tais resultados so do tipo nominal e, para que seja possvel sua pontuao, ser
necessrio fazer um mapeamento das respostas tipo Nominal para valores numricos.
Nesta metodologia, as medidas so questes que tm vrios tipos de resposta; para poder pontuar
essas respostas, feito um mapeamento de cada tipo de resposta em um valor numrico.
Cada atributo deve ter como resultado um valor numrico; esse valor deve ser normalizado, ou seja, a
mdia obtida entre os resultados deve estar entre zero (0) e um (1). Isso importante, pois todos os
atributos devem ter pesos iguais, mesmo que eles tenham um nmero de itens variveis. normal isso
acontecer, pois cada atributo desdobrado em itens, para que se possa verific-lo de forma mais objetiva
141
e clara. Assim, num atributo que tem dois, trs, ou quatro itens, os valores numricos desses itens vo
assumir valores proporcionais e estaro entre zero (0) e um (1), dependendo de quantos itens o atributo
for composto. necessrio que a mdia desses itens, isto , que os valores numricos estejam entre
zero (0) e um (1).
Os itens que receberem como tipo de resposta NA ou AP devem ter um tratamento diferente, pois
esse tipo de resposta no pode prejudicar a avaliao do produto. Nesse caso, atribudo um valor
chamado missing, e no se atribui um valor numrico a tais itens.
A seguir, relacionam-se alguns exemplos de tipos de respostas para cada tipo de questo, com seus
valores numricos associados.
Nas medidas em que as opes de respostas sejam S e N, e S seja uma proposio
VERDADEIRA, e N seja uma proposio FALSA, os valores numricos so estabelecidos como na
Tabela 6.2:
Tabela 6.2 Tipo de questo 01

Tipo de resposta
Valores numricos
AP
00,00
NA
01,00
Significado do tipo de resposta

Avaliao prejudicada
No
No se aplica
Sim
Outro exemplo: nas medidas em que as opes de respostas sejam S e N, e S seja uma
proposio FALSA, e N seja uma proposio VERDADEIRA, os valores numricos so estabelecidos
como na Tabela 6.3:
Tipo de resposta
Valores numricos
AP
01,00
NA
00,00

Avaliao prejudicada
No
No se aplica
Sim
Nas medidas em que as opes de respostas sejam S, de SEMPRE; N, de NUNCA; e A, de

ALGUMAS VEZES, os valores numricos so estabelecidos como na Tabela 6.4:
142

Tipo de resposta
Valores numricos
00,50
AP
00,00
NA
01,00

Algumas vezes
Avaliao prejudicada
Nunca
No se aplica
Sempre
Em outro exemplo de medida, em que as opes de respostas sejam M, de MUITAS; N, de

NENHUMA; e P, de POUCA, os valores numricos so estabelecidos como na Tabela 6.5:

Tipo de resposta
Valores numricos
AP
01,00
Muitas
00,00
Nenhuma
NA
00,50
Avaliao prejudicada
No se aplica
Poucas
Em outro exemplo em que as opes de respostas sejam A, de ALGUNS; N, de NENHUM; Q de

QUASE TODOS; e T, de TODOS, os valores numricos so estabelecidos como na Tabela 6.6:
Tipo de resposta
Valores numricos
00,33
AP
00,00
NA
No se aplica
00,66
Quase todos
01,00
Todos
Alguns
Avaliao prejudicada
Nenhum
143
Esses exemplos mostram como transformar a resposta de cada questo tipo Nominal para um valor
numrico. Na Seo 6.2.3, explicado como obter a nota do Atributo; em seguida, a nota da
Caracterstica e, finalmente, a nota do Componente, possibilitando quantificar a qualidade do software.
6.2.3 Estabelecer critrios para julgamento
Julgar a qualidade significa, em essncia, interpretar os resultados das medies. O primeiro passo
nesse sentido j foi realizado na Seo 6.2.2, quando se estabeleceram nveis de pontuao para as
medidas. Em prosseguimento, seria desejvel obter concluses sobre qualidade, a partir do conjunto de
valores obtidos da aplicao de medidas.
A seguir, apresenta-se uma sugesto de procedimento para obter resultados sintticos de avaliao,
descrito em algumas etapas:
Etapa 1 mapear todos os resultados de medidas para uma escala [0, 1], em que 0 significa o
pior resultado possvel, enquanto 1 representa o melhor. As medidas sugeridas nesta
metodologia seguiram esse padro.
Etapa 2 estabelecer pesos para as caractersticas de qualidade de software. Os pesos devem

representar a importncia relativa de cada item, no julgamento global de qualidade do produto. Os
valores devem ser obtidos, principalmente, a partir do requisitante da avaliao quem, em
ltima instncia, deve dizer o que importante e o que no importante, na sua viso, sobre a
qualidade do produto; e tambm a partir de profissionais especialistas na rea de aplicao do
software.
Etapa 3 calcular mdias ponderadas, usando os valores das medidas e os pesos das respectivas
caractersticas. sugerido, aqui, usar os valores (de 1 a 5) atribudos para cada caracterstica, na
questo 3 da seo 6.1.1. No se recomenda atribuir pesos aos atributos, uma vez que:
i) os atributos no esto rigorosamente definidos na norma NBR ISO/IEC 9126-1;
ii) um mesmo atributo pode ser utilizado para avaliar vrias subcaractersticas.
possvel, assim, calcular mdias agrupando as medidas de cada caracterstica de qualidade. Por
exemplo, calcular a mdia para usabilidade, dadas as medidas relacionadas com os atributos de
usabilidade. O mesmo pode ser feito com cada caracterstica, separadamente.
Etapa 4 finalmente, o processo pode ser repetido no nvel de Componente do software,

permitindo que se calcule um ndice ou nota, representando a qualidade do software.
O clculo de notas deve ser feito seguindo abordagem bottom-up do modelo de qualidade adotado na
Figura 6.2, isto , primeiro obtendo o valor da nota para cada Item (que depende da resposta atribuda
144
ao produto, dada por cada avaliador); em seguida, a nota do Atributo; depois a nota da
Subcaracterstica, da Caracterstica, do Componente e, finalmente, a nota do Produto de software.
A seguir, apresenta-se uma descrio do algoritmo de clculo das notas, com suas respectivas
frmulas matemticas, as definies e os clculos das notas, nos diferentes nveis do modelo de
qualidade, conforme a Figura 6.2:
a) Nota do Item
klm
jklm
Para i = 1...Ij , seja Ai

a nota do item i, que pertence ao atributo j, da subcaracterstica k, da
caracterstica l, do componente m.
b) Nota do Atributo
lm
Para j = 1...Jk , definimos a nota do atributo j, da subcaracterstica k, da caracterstica l, do

componente m:
I klm
j
Ai jklm
B klm
j
i 1
I klm
j
c) Nota da Subcaracterstica
m
Para k = 1...Kl , definimos a nota da subcaracterstica k, da caracterstica l, do componente m:

J klm
Cklm
B klm
j
j 1
J klm
d) Nota da Caracterstica
Para l = 1...Lm, definimos a nota da caracterstica l, do componente m:
K lm
Dlm
Cklm
k 1
K lm
e) Nota do Componente
m
Para l = 1...Lm, seja pl o peso da caracterstica l, do componente m.

Para m = 1...M, definimos a nota do componente m:
145
Lm
Em
plm Dlm
l 1
Lm
plm
l 1
f)
Nota do Produto
Para m = 1...M, seja qm o peso do componente m.
Definimos a nota do produto:
M
qm Em
P
m 1
M
qm
m 1
Com a utilizao desse procedimento, consegue-se obter um valor quantitativo da qualidade, isto ,
uma nota para a qualidade do software. Dessa forma, o procedimento permite tambm:
1) confrontar diretamente produtos, no caso de avaliaes comparativas, visando seleo para
posterior aquisio;
2) examinar os resultados da avaliao em diferentes nveis de detalhe: desde o resultado nico e
sinttico, at os resultados colhidos individualmente pelas medidas, passando por mdias
ponderadas para cada caracterstica.
A comparao s possvel quando a avaliao utilizada sobre os produtos for idntica, ou seja:
utilizar as mesmas medidas e mesmos pesos, alm de mesmo ambiente de avaliao, hardware,
usurios e outros parmetros que possam influenciar na avaliao.
6.3 Projetar a avaliao

O objetivo nesta fase produzir o plano de avaliao. Esse plano informa qual mtodo de avaliao ser
utilizado, com instrues de como utiliz-lo, e especifica os recursos necessrios, juntamente com o
cronograma das aes, para o avaliador. O plano de avaliao deve conter, explicar e definir o mtodo de
avaliao, para que o avaliador possa executar a avaliao completamente.
6.3.1 Mtodo de avaliao
O mtodo de avaliao, aqui apresentado, composto por uma lista de verificao, como do Apndice A,
que contm, tambm, um conjunto de instrues a serem dadas ao avaliador, e por um modelo de
146
relatrio que o avaliador pode redigir como o exemplo do Apndice C, relatando os pontos a serem
melhorados e os pontos que esto atendendo os requisitos de qualidade, de acordo com as respostas s
questes da lista de verificao.
6.3.2 Instrues ao avaliador
O avaliador deve ser uma pessoa treinada no mtodo, conhecer todos os seus atributos. interessante,
tambm, que o avaliador seja uma pessoa que tenha o seguinte perfil: conhecedor de informtica, seja
uma pessoa detalhista, disciplinada e organizada. desejvel que conhea o domnio de aplicao do
software, porm, caso isso no seja possvel, deve haver um treinamento especfico com especialistas da
rea de aplicao.
A seguir, so sugeridas algumas instrues ao avaliador:
Cada atributo composto por itens de atributo, que variam em termos de quantidade.
Todos os itens de todos os atributos devem ser verificados e respondidos.
As respostas sero atribudas aos itens.
Todos os itens com respostas desfavorveis (i.e. aspectos a serem melhorados) para o produto, ou
com respostas NA ou AP, devem ser justificados por escrito. A justificativa dever estar
identificada com o nmero do atributo e do item, para ajudar na elaborao do relatrio de
avaliao.
Algumas questes necessitam de anotaes do avaliador como complemento da resposta dada;

essas anotaes devero ser documentadas, logo em seguida da questo.
Caso o produto de software apresente erros e/ou falhas durante sua avaliao, o avaliador dever
anotar os passos realizados que tiveram como conseqncia o erro ou a falha ocorrida, alm de
anotar o procedimento adotado para solucion-los, caso o tenha identificado. Isso possibilitar a
reproduo posterior do erro ou da falha. conveniente imprimir as telas com mensagens de erro.
Caso o avaliador no se sinta seguro para avaliar uma questo, anotar e prosseguir a avaliao,
avaliando somente quando sentir segurana da resposta a ser atribuda na questo.
Algumas questes, para serem avaliadas, requerem um conhecimento maior do produto. Para isso,
importante o avaliador manipular o produto, ler a documentao, executar as funes que o
produto possui, navegar pelas janelas, enfim, criar familiaridade com o produto.
147
6.3.3 Recursos e cronograma

O avaliador dever ter um computador exclusivo para executar a avaliao do produto, com os requisitos
de hardware e software necessrios para tal execuo. Alm desse recurso, ele dever ter um
cronograma para fazer a avaliao; de preferncia, de maneira contnua e conclusiva, do incio ao fim,
para no perder o foco da avaliao.
6.4 Executar a avaliao

Nesta fase do processo de avaliao, o avaliador utilizar tudo o que foi preparado nas fases anteriores,
e esto previstas as seguintes atividades:
Obter as medidas;
Comparar com critrios e
Julgar os resultados.
6.4.1 Obter as medidas

Para medio, as medidas selecionadas so aplicadas ao produto de software pelo avaliador. Como
resultado, obtm-se a lista de verificao, preenchida com as notas de cada questo; posteriormente ser
calculada a pontuao das medidas, como sugerido na seo 6.2.2.
Nesta fase importante que o avaliador siga um procedimento de avaliao estabelecido, para no se
perder, e que consiga obter as medidas de forma correta. Assim, so sugeridas as seguintes aes:
A) Aes iniciais da avaliao:
Com o produto em mos, identificar os folhetos e documentos que vieram dentro e fora da
embalagem, ou que foram obtidos no site.
Ler atentamente as informaes referentes aos requisitos mnimos de hardware e software,

constantes em folhetos, embalagem, documentos e site, caso existam.
Com os requisitos mnimos de hardware e software claros, verificar se o equipamento a ser

utilizado para a avaliao atende a essas exigncias.
Finalizar as atividades, preenchendo o formulrio de Identificao da Avaliao com as

seguintes informaes: Data inicial da avaliao, Avaliador, Produtor, Produto, Verso
do produto, Descrio resumida do produto, Material apresentado, Condies de Instalao
e Operao, conforme documentao e dados disponveis do equipamento utilizado na
avaliao. Esse formulrio est apresentado no Apndice B.
148
B) Elaborao do relatrio da avaliao
Elaborar o relatrio de avaliao como sugerido no Apndice C.
As observaes e justificativas das atribuies que foram anotadas na lista de verificao so

muito importantes para a elaborao do relatrio de avaliao, pois nela devero ser
registrados:
aspectos considerados positivos.
aspectos a serem revistos, com recomendaes.
C) Aes finais da avaliao
O Avaliador dever checar se os campos do Apndice B Identificao da Avaliao: nome do

Produto, Verso e nome do Produtor, que foram previamente preenchidos, correspondem
realidade apresentada pelo produto; caso tenha havido alguma inconsistncia, atualizar esses
campos.
Preencher, no formulrio Identificao da Avaliao, a data final da avaliao.
6.4.2 Comparar com critrios

Na etapa de pontuao, os valores medidos so comparados com critrios pr-determinados. Para isso,
til utilizar um programa como o Excel da Microsoft, ou algum outro programa de software estatstico,
como, por exemplo, o SAS Statistical Analysis System ou o SPSS Statistical Package for the
Social Sciences, para que se possam transformar em grficos os valores medidos, para melhor
visualizao e interpretao dos resultados obtidos, fazendo uma anlise estatstica descritiva.
6.4.3 Julgar os resultados
O julgamento a etapa final da fase de execuo do processo de avaliao. O resultado o relatrio da
avaliao, como apresentado no Apndice C, e uma declarao de quanto o produto atendeu aos
requisitos de qualidade especificados no modelo de qualidade. No julgamento, outros fatores como, por
exemplo, tempo, esforo e custo da avaliao, podem ser considerados, caso sejam importantes para o
requisitante da avaliao.
6.5 Concluso da avaliao

Esta fase foi includa aqui, seguindo a definio do processo de avaliao da norma NBR ISO/IEC 145985. O objetivo nesta fase disponibilizar o resultado da avaliao para o requisitante da avaliao. O
coordenador da avaliao dever finalizar a avaliao com as seguintes atividades:
149
Arquivar os itens utilizados durante a avaliao:
Relatrio de avaliao do produto de software;
Lista de verificao completamente preenchida;
Finalizar essa tarefa, entregando ao requisitante da avaliao:
Produto de software nas mesmas condies recebidas, incluindo folhetos e anexos impressos;
Cpia do relatrio de avaliao do produto de software;
Declarao do resultado da avaliao.
Esta concluso finaliza as cinco fases do processo de avaliao de produto de software, sendo que
esta metodologia um exemplo de como avaliar sistematicamente e no se limita a criatividade ou
necessidade de pessoas envolvidas em avaliaes. Cada demanda pode desenvolver seu prprio
mtodo de avaliao, o que no pode acontecer a avaliao ser conduzida sem uma sistemtica
documentada.
Essa metodologia composta de uma lista de verificao, um manual para o avaliador e um modelo
de relatrio de avaliao. A lista de verificao tem medidas que so obtidas por meio de um conjunto de
alternativas, isto , ela utiliza escalas nominais como explicado no item 5.2 deste livro. Assim o resultado
de uma avaliao um relatrio com resultados qualitativos sobre o nvel de qualidade do produto.
Adicionalmente uma anlise estatstica pode ser efetuada atribuindo notas geradas pela transformao
da escala nominal em valores numricos normalizados, podendo ser obtida uma nota de acordo com o
item 6.2.3. A questo de associar escala nominal a valores numricos para que se executem operaes
matemticas tem sido polmica na literatura, assim como o modelo de qualidade e as medidas da norma
ISO/IEC 9126 (AL-KILIDAR, 2005). Exemplos de medidas para avaliar a qualidade de produto de
software so encontrados nos relatrios tcnicos da ISO/IEC 9126 nas partes 2, 3 e 4. A parte 2 contm
exemplos de medidas externas do software, a parte 3 contm exemplos de medidas internas e a parte 4
exemplos de medidas de qualidade em uso.
A metodologia aqui exposta no pretende dar nfase apenas a medidas para produtos de software e
sim apresentar uma viso geral do estagio em que se encontra o produto. A partir dessa avaliao,
melhorar o produto para satisfao e conforto do usurio. Isso pode ser obtido no relatrio de avaliao
quando se considera os pontos fortes e os pontos a serem melhorados em cada uma das caractersticas
associadas aos componentes do software. Isso pode ser visto no apndice E Relatrio de avaliao do
software Easy Learn.
Em casos onde existe apenas um produto a ser avaliado, no h comparao a ser feita, portanto no
h necessidade de notas, pois o objetivo conhecer qualidade do produto de forma global. Em casos
onde existe a necessidade de uma comparao entre produtos conveniente fazer uma pontuao das
150
notas dos produtos para facilitar a classificao dos produtos, um exemplo disso foi efetuado no prmio
Assespro (ROCHA, 2001).
6.6 Processo de avaliao para componentes de software

Este item apresenta uma metodologia de processo de avaliao para componentes de software seguindo
os passos do processo de avaliao da norma NBR ISO/IEC 14598-1 e 14598-5. O modelo de qualidade
utilizado neste processo de avaliao foi definido no item 4.6.
6.6.1 Estabelecer os requisitos da avaliao
A.
Propsito da avaliao
O propsito da avaliao avaliar quanto o componente de software est em conformidade com os

requisitos especificados, permitindo sua admisso em um possvel repositrio.
Vrios pontos de vista podem ser considerados, dependendo dos diferentes usurios do produto, tais
como: comprador, integrador, arquiteto de software, fornecedor, desenvolvedor e operador. Devem ser
descritos os objetivos e os requisitos da avaliao, que dependem da necessidade do solicitante, ou seja,
do objetivo final da avaliao.
Os solicitantes de uma avaliao podem ser: 1) Equipes de desenvolvimento, que usam o resultado
da avaliao para identificar aes corretivas e determinar estratgias de evoluo; 2) Vendedores, que
usam a qualidade como marketing; 3) Compradores, para avaliar os produtos que esto competindo no
mercado; 4) Usurios, para obter confiana no produto; 5) Comunidade de software, para identificar e
validar os mtodos mais adequados de avaliao e, assim, aumentar a credibilidade das tcnicas; 6)
Laboratrios de avaliao, para desenvolver uma abordagem de avaliao mais consistente.
A anlise de requisitos da avaliao visa definir os requisitos de qualidade do produto. Deve partir dos
objetivos da avaliao que traduzem diretamente o interesse do requisitante da avaliao. A anlise
define profundidade, abrangncia, relacionamento da presente avaliao com outras e objetos a serem
avaliados.
B.
Tipos de produtos a serem avaliados:

Foram identificados trs tipos de produtos a serem avaliados:
Componentes de software artefatos autocontidos, claramente identificveis, que descrevem ou

realizam uma funo especfica e tm interfaces claras, em conformidade com um dado modelo de
arquitetura de software, documentao apropriada e um grau de reutilizao definido. Por se tratar de
componentes de software a serem disponibilizados em um repositrio, tero as caractersticas comerciais
151
dos produtos COTS; portanto, devem ser acompanhados pelos seguintes artefatos: documento de
descrio do componente e documentao para sua utilizao.
Descrio de Componente A descrio de componente que define o produto faz parte do conjunto
de documentao do componente. Ela fornece informaes sobre a documentao para sua utilizao e
sobre o componente propriamente dito. Os principais objetivos da descrio de componente so: Ajudar o
integrador em potencial, na avaliao da adequao do componente s suas necessidades de utilizao.
Por extenso, ela tambm fornece informaes para venda; Servir como base para testes. A descrio de
componente deve estar disponvel para pessoas interessadas no componente, antes da aquisio do
mesmo, e deve seguir todos os requisitos aplicveis para descrio de produto da norma NBR ISO/IEC
25051.
Documentao para uso A documentao para uso deve conter as informaes necessrias e
subsdios para a construo da documentao do sistema a ser construdo. Devem ser completamente
descritos nessa documentao os seguintes itens:
C.
todos os servios e as funes de negcio estabelecidos na descrio de componente;
todas as caractersticas e elementos do modelo de componentes presentes no componente,

a saber: interfaces providas, interfaces requeridas, interfaces de gerncia, eventos
recebidos, eventos enviados, propriedades internas ou externas, e interface de acesso;
todas as facilidades oferecidas pelo componente, as variveis de configurao ou

customizao e a manipulao das propriedades que permitem a configurao do estado
dos componentes;
todas as funes do componente a que os usurios tiverem acesso devem ser

completamente descritas na documentao.
Definio do modelo de qualidade

O modelo de qualidade a ser adotado pode ser o apresentado na Figura 4.15, no Captulo 4.
6.6.2 Especificao da avaliao

Nesta etapa, deve-se definir o escopo da avaliao e as medidas a serem executadas no produto
submetido avaliao. O nvel de detalhes na especificao da avaliao deve ser tal que a avaliao
seja repetvel e reprodutvel.
A.
Medidas:
As medidas devem ser desdobradas a partir dos atributos da qualidade externa de componentes de
software; devem considerar o contexto de uso do sistema, lembrando que a avaliao deve ser em
laboratrio com ambiente adequado de execuo.
152
B.
Estabelecer nveis de pontuao
Os nveis de pontuao dependem dos tipos de medidas a serem adotadas. Exemplo disso j foi
abordado na seo 6.2.2.
C.
Critrios de julgamento
O critrio de julgamento a admisso ou no do componente no repositrio. Por exemplo, pode-se definir

que o componente avaliado atenda, a 70% dos requisitos de qualidade especificados. Este critrio pode
ser reavaliado nas avaliaes-piloto do projeto.
6.6.3 Projeto da Avaliao
Dever ser produzido um plano de avaliao, que descreva o mtodo de avaliao da qualidade de
componentes de software. O Plano poder ser composto de:
Lista de verificao, que um conjunto de medidas baseadas no modelo de qualidade da Figura
4.15;
Modelo de relatrio, que deve ser gerado para cada avaliao executada, relatando os pontos
fortes e pontos a serem melhorados do produto avaliado.
As instrues para o avaliador devem estar, por exemplo, em um documento do tipo Manual do avaliador.
Os recursos necessrios para executar a avaliao especificada devem ser alocados e disponibilizados
de forma a atender o cronograma da avaliao.
6.6.4 Execuo da Avaliao
Para obter as medidas da execuo de atividades de avaliao, verificar o componente de software de
acordo com os requisitos de avaliao, como descrito na especificao da avaliao e como planejado no
plano de avaliao. De posse dessas medidas, elas devem ser analisadas estatisticamente com os
critrios de julgamento, e assim obter o resultado da avaliao. Nesta fase tem incio a primeira verso do
relatrio de avaliao e os registros da avaliao.
6.6.5 Concluso da Avaliao
Nesta etapa, deve-se revisar o relatrio da avaliao e disponibilizar os dados resultantes da mesma
para o requisitante da avaliao. Esta etapa tem como objetivos:
Concluso do relatrio de avaliao e arquivamento dos dados da avaliao.
Reviso conjunta pelo desenvolvedor e avaliador.
153
Destino dos dados e documentos de avaliao: Para uma avaliao profissional, esses dados so
sigilosos e exclusivos ao requisitante da avaliao, sendo qualquer publicao deles de sua
inteira responsabilidade.
Relatrio de avaliao entregue formalmente:
os documentos submetidos avaliao devem retornar ao requisitante, ou ser arquivados

por um tempo determinado, ou devem ser destrudos de maneira segura;
o relatrio de avaliao e os registros de avaliao devem ser arquivados por um tempo

determinado;
todos os outros dados devem ser arquivados por um tempo determinado ou destrudos de
maneira segura.
O objetivo foi mostrar um processo de avaliao especfico para componentes de software. Dessa
forma, outros exemplos de avaliao poderiam ser apresentados: um deles a avaliao especfica da
caracterstica de qualidade usabilidade; outro exemplo seria a avaliao focada por categorias de
produtos ou por domnios de aplicao.
Este captulo procurou ressaltar a importncia de executar avaliao e produto de software seguindo
um processo definido e de forma sistemtica, para garantir a repetibilidade, a reprodutibilidade, a
imparcialidade e a objetividade, caractersticas estas fundamentais para esse processo.
154
CAPTULO 7
Avaliao de um software
11
Este captulo apresenta a avaliao de um software do tipo pacote (COTS) o Easy Learn - e seguiu
como metodologia o processo de avaliao proposto no Captulo 6 deste livro. Inicialmente apresentada
uma descrio desse software; e em seguida, so descritas todas as atividades realizadas na aplicao
da metodologia.
7.1 Apresentao do software

O software Easy Learn foi comprado no mercado nacional sem nenhum objetivo especfico. um
dicionrio Ingls-Portugus, Portugus-Ingls e dicionrio poliglota, em seis idiomas: alemo, espanhol,
ingls, francs, italiano e portugus. Possui, tambm, vrias funcionalidades, como um laboratrio de
pronncia; apresentam-se situaes de viagem, jogo da forca, associao de figuras e de palavras,
ditado, traduo de frases, tabelas de gramtica, filtro de lista - onde se possibilita filtrar um grupo de
palavras de uma determinada categoria. Podem ser feitas, tambm, tradues de palavras em
praticamente todos os programas compatveis com Windows, desde textos at planilhas eletrnicas,
banco de dados ou browser da internet. O usurio poder, tambm, incluir palavras e at mesmo utilizar
dicionrios extras.
7.2 Processo de avaliao

O processo de avaliao aplicado no Easy Learn foi realizado seguindo-se as mesmas etapas
recomendadas pela norma NBR ISO/IEC 14598-1 e 14598-5 (NBR ISO/IEC 14598-1 e 14598-5, 2002),
como detalhadas a seguir:
7.2.1 Estabelecer requisitos de avaliao
Foi levantado o objetivo e a expectativa com relao avaliao. O objetivo foi conhecer um software
adquirido comercialmente; a expectativa foi avaliar o quanto esse software est em conformidade com as
normas de qualidade. O requisitante foi o gerente do projeto de avaliao, que gostaria de ter um
exemplo disponibilizado publicamente.
A) Estabelecer o propsito da avaliao
11
O nome fictcio Easy Learn foi usado para preservar a integridade do software.
155
Apresenta-se, a seguir, o formulrio preenchido pelo requisitante da avaliao, que tem como objetivo
esclarecer o objetivo da avaliao para ambas as partes: o requisitante da avaliao e o avaliador.
Nome do Produto: Easy Learn
Verso: 2.0
1. Qual domnio da aplicao do produto?
Software educacional para ensino e aperfeioamento do idioma ingls. O Software composto dos
seguintes mdulos: Easy Learn, Poliglota e o Tradutor.
2. Qual o seu objetivo em relao avaliao?
Assegurar a qualidade do produto?

Indicar pontos para melhoria no produto?
Adequar o produto s Normas de Qualidade para produto de software?
Comparar com outros produtos similares?
Obter um Laudo tcnico da sua qualidade?
Classificar e premiar um conjunto de Produtos de Software?
Pr-qualificar Produtos de software numa licitao?
Outros. Quais?
3. Quais os aspectos do produto que o requisitante pretende que sejam avaliados e com que nfase?
Funcionalidade. nfase (1 a 5): 4

Confiabilidade. nfase (1 a 5): 3
Usabilidade. nfase (1 a 5): 5
Portabilidade. nfase (1 a 5): 1
Eficincia. nfase (1 a 5): 3
Completitude. nfase (1 a 5): 3
B) Identificar tipos de produtos a serem avaliados
A seguir apresenta-se o formulrio preenchido pelo requisitante da avaliao, para poder especificar o
tamanho do software a ser avaliado.
Nome do Produto: Easy Learn
Verso: 2.0
1. Descrio geral do produto:
De quantas funes o produto composto?
Resp.: Aproximadamente 70 funes, que so acessadas pelo usurio por meio da interface.
Quais so as principais tarefas do produto?
156
Resp.: Realiza tradues; treina a pronncia das palavras; realiza exerccios; inclui palavras no
dicionrio e/ou utiliza dicionrios extras; fornece dicas de utilizao de gramtica, com tabelas de
gramticas; fornece sinnimo das palavras selecionadas; procura palavras, mesmo sem saber como
escrev-las, por meio de rimas; ditado; anagramas.
Quais funes merecem maior dedicao durante a avaliao?
Resp. As funes do mdulo Easy Learn.
Quantas janelas de interao com o usurio o produto possui?
Resp.: Aproximadamente 80 janelas.
Quem so os principais usurios do produto?
Resp.: Indivduos ou grupos de pessoas que queiram aprender o idioma ingls.
2. Como o ambiente no qual o produto ser inserido
Nvel de conhecimento exigido dos usurios em relao informtica.
Resp.: Conhecimento bsico de operao do sistema operacional Microsoft Windows.
Nvel de conhecimento exigido dos usurios em relao ao domnio da aplicao em si.
Resp.: No exigido nenhum requisito do domnio de aplicao.
3. Quais sero os principais componentes do produto que sero submetidos avaliao? Marque-os.
(Informar o tamanho - nmero de pginas ou de janelas, caso seja a documentao on-line)
Documento
Manual do Usurio
Manual de Operao
Procedimentos para Instalao
Descrio do Produto (folder,
catlogo, site,...)
Outros. Quais?
Guia de Referncia Rpida
Impresso
(no de pgs.)
50
X
1
Os dados esto na
prpria embalagem
04
On Line
(no de janelas)
80
X
1
X
X
4. Existe massa de teste para a avaliao? (so dados exemplos para agilizar a avaliao?)
Resp.: No necessrio, o prprio usurio insere dados durante a utilizao e avaliao do produto.
5. Especificar os requisitos de hardware e software para executar o produto?
Rede (S/N): N
Quais:
Processador: disponvel no mercado
Ambiente Operacional: Windows NT ou superior
Hardware Adicionais (impressora, scanner, hardlock..) : Microfone e
placa de som (opcional)
157
Software Adicionais: Browser para internet

Multiplataforma (S/N): N
Quais:
C) Especificar modelo de qualidade
O modelo de qualidade utilizado o estabelecido na Figura 4.12 do Captulo 4, e o produto contm a
mdia com o software, documentao de usurio, descrio do produto e a embalagem.
Este software possui todos os componentes previstos no modelo de qualidade. Caso no
apresentasse algum componente, este poderia ser excludo do modelo ou poderia ser mantido e, na fase
de executar a avaliao, na atividade de obter as medidas, seria registrada a ausncia daquele
componente.
7.2.2 Especificar a avaliao
O objeto avaliado foi o software escolhido e adquirido comercialmente, e o mtodo utilizado foi o
apresentado no Apndice A.
A) Selecionar medidas
As medidas selecionadas para esta avaliao so as contidas na lista de verificao do Apndice A.
B) Estabelecer nveis de pontuao para as medidas

A lista de verificao composta pelos componentes do software, e nela cada componente com seus
respectivos atributos foram desdobrados em questes e itens que possam ser verificados e respondidos
pelo avaliador, obtendo-se as medidas a serem contabilizadas.
Em relao s medidas que fazem parte dessa lista de verificao, o avaliador deve considerar que
so questes do tipo proposies lgicas sobre um atributo a ser verificado em uma avaliao.
As respostas possveis para as questes so:
"S" (Sim) para proposies verdadeiras;
"N" (No) para proposies falsas;
"NA" (No se Aplica) para sentenas que fazem referncia a um aspecto que no se enquadra no
produto em avaliao.
"AP" (Avaliao Prejudicada) para sentenas que o avaliador no est em condies de avaliar, ou
por falta de recursos, por falta de informaes, ou mesmo por falta de conhecimento especfico no
assunto abordado.
Assim, para obter os nveis de pontuao das medidas, foram utilizados os valores numricos
estabelecidos nas Tabelas 6.2 e 6.3 do Captulo 6.
C) Estabelecer critrios para julgamento

158
Como critrio de julgamento para este software foi considerado um levantamento feito pelo CTI, que
possui um banco de dados com avaliaes de aproximadamente 300 produtos de software (MARTINEZ,
1999), e desse levantamento pode-se considerar como critrio de julgamento o seguinte:
Para um software obter o nvel Alto, ele deve estar de acordo com pelo menos 70% dos requisitos
das normas internacionais. Isso significa que a nota pode variar de 10,0 a 7,0, numa escala de 0 a
10;
para um software obter o nvel Mdio, ele deve estar de acordo com pelo menos 50% dos requisitos
das normas internacionais. Isso significa que a nota pode variar de 7,0 a 5,0;
para um software obter o nvel Baixo, a nota pode variar de 5,0 a 0,0.
Se a nota do software estiver no intervalo do nvel alto, isso significa um nvel bom de qualidade; se a
nota estiver no nvel mdio, significa que ele ainda precisa de alguns ajustes; finalmente, se a nota est
no nvel baixo, significa que tero que ser implementadas correes e o software deve voltar a ser
avaliado. Em todos os casos, gerado um relatrio qualitativo do resultado da avaliao, no qual
constaro os pontos a serem melhorados.
A seguir mostrado, na Figura 7.1, o grfico com os critrios de aceitao.
10
Nvel
Alto
Software OK!
7
Nvel
Mdio
Precisa de Ajustes
5
Nvel
Baixo
Inaceitvel
Figura 7.1 Critrios de aceitao
7.2.3 Projetar a avaliao

Foi definido o plano de avaliao:
159
a) o mtodo utilizado: lista de verificao do Apndice A; b) a equipe de avaliao foi composta por
uma pessoa conhecedora das normas e do mtodo. O tempo de avaliao foi estimado em 20
horas, durante um perodo de cinco dias.
O resultado da avaliao foi uma lista de observaes referentes aos atributos avaliados. Esse
resultado foi apresentado no relatrio da avaliao do Easy Learn, como no Apndice E
7.2.4 Executar a avaliao
O avaliador instalou o produto e, seguindo rigorosamente as instrues constantes na documentao
impressa ou on line do produto, exercitou todas as funes disponveis na verso e finalmente
desinstalou.
A) Obter as medidas
Para esta atividade foi seguido o procedimento de avaliao sugerido na metodologia. Como resultado,
tem-se a Identificao da Avaliao, de acordo com o modelo apresentado no Apndice B. Concluda a
obteno das medidas, o avaliador elaborou o relatrio da avaliao do produto, como sugerido no
modelo de relatrio de avaliao apresentado no Apndice E.
B) Comparar com critrios

Aps a avaliao, interessante que se faa a classificao grfica dos resultados da avaliao, para ter
uma viso geral do comportamento do produto. Isso foi feito por meio da metodologia estatstica Anlise
Descritiva, que verifica e mostra a proporo dos itens atendidos em relao ao conjunto total dos itens
das medidas estabelecidas na lista de verificao, em forma de nota entre 0,0 e 100,0, de cada
componente do software. O grfico foi gerado pelo software Excel, do Windows 98 da Microsoft. O
grfico mostrado na Figura 7.2.
160
Figura 7.2 Notas obtidas do Easy Learn
C) Julgar os resultados
Como pde ser observado, o desempenho do software teve a seguinte pontuao: Embalagem atingiu o
nvel Alto, com nota 75. Os componentes documentao e interface obtiveram as notas 60 e 57.6,
respectivamente, atingindo o nvel mdio da escala da Figura 7.1. Os componentes descrio do
produto e software obtiveram as notas 45.5 e 36.7, respectivamente, atingindo o nvel baixo. A nota
final, como um todo, foi de 55; essa nota, de acordo com o critrio de aceitao, atingiu o nvel mdio.
Isso significa que o software precisa de ajustes, ainda no pode considerar-se que esteja de acordo com
os requisitos mnimos exigidos pelas normas de qualidade.
7.2.5 Concluso da avaliao
Nesta fase so arquivados a lista de verificao, preenchida pelo avaliador, e o relatrio da avaliao.
Com relao ao resultado da avaliao de qualidade do Easy Learn, fortemente sugerido que
sejam implementados os aspectos a serem revistos, documentados no relatrio de avaliao
apresentado a seguir.
Comparando a nota dos componentes do Easy Learn da Figura 7.2 com os aspectos de destaque
positivo e aspectos a serem revistos do relatrio de avaliao, pode-se constatar:
161
O componente Embalagem, que alcanou a nota 75, obteve vrios destaques positivos e
apresentou poucos aspectos a serem revistos;
Os componentes Documentao do usurio e Interface obtiveram as notas 60 e 57.6,
respectivamente, e no Relatrio de avaliao podem ser observados vrios aspectos a serem
melhorados;
O componente Descrio do Produto obteve a nota 45.5; apesar de o produto apresentar a maioria
das identificaes e declaraes exigidas pela norma, ainda faltaram algumas, consideradas
importantes;
O componente Software obteve a nota 36.7; primeira vista, parece ser um valor baixo
principalmente por este software j ser comercializado. Pelo Relatrio de avaliao, pode-se
constatar que ele possui todas as funes declaradas, porm ainda apresenta falhas durante a
execuo das funes.
Infelizmente, ainda no se tem uma referncia pblica na qual seria possvel fazer uma comparao
entre produtos de software. Poucas so as empresas desenvolvedoras de software que conhecem e
aplicam os requisitos de qualidade definidos nas normas. Entretanto, os esforos governamentais e de
associaes tm incentivado e patrocinado as empresas nacionais a melhorarem seus produtos para
atender a competitividade dos mercados nacional e internacional.
162
Consideraes finais
O objetivo deste livro foi apresentar, principalmente, as normas de qualidade de produto de software e as
experincias de aplicaes dessas normas. Adicionalmente, o livro tem a sutil pretenso de tratar dos
seguintes assuntos: i) ressaltar a importncia da qualidade de produto de software mediante o atual
movimento para a melhoria da qualidade de processos; ii) divulgar os modelos para qualidade de produto
de software; iii) conscientizar as pessoas envolvidas, como fornecedores e desenvolvedores, para
melhorar o software brasileiro e para compradores e usurios de software saberem exigir seus produtos
com o mnino de qualidade em relao padres reconhecidos internacionalmente.
A qualidade de produto de software um assunto trabalhoso, fica difcil explicitar por meio de
requisitos de qualidade as necessidades implcitas e explcitas do usurio. Nesse sentido, o grande
benefcio da norma NBR ISO/IEC 9126-1 apresentar um modelo de qualidade bsico e genrico para a
qualidade de produtos de software. O modelo pode ser desdobrado em atributos de qualidade para as
caractersticas especficas correspondentes a cada produto, caso necessrio. Esse assunto de difcil
compreenso e os modelos prticos aqui apresentados mostram exemplos de como tratar dessa
questo.
O livro apresenta a ideia de qualidade genericamente, qualidade de produto de software, produto esse
com caractersticas to especiais que se tenta classific-los para melhor estud-los. Essa prtica facilita a
construo de modelos de qualidade com caractersticas especficas para cada categoria. Modelos de
qualidade so ferramentas teis que surgiram para ajudar e entender um produto com caractersticas to
peculiares, num mercado onde a demanda grande e os envolvidos muitas vezes no sabem como
descrever o que necessitam e desejam. Algumas normas at sugerem modelos de qualidade, outros
modelos so criados especificamente para alguns tipos de produtos e necessrio e til que se
pratiquem a construo de novos modelos de qualidade para produtos de software.
O modelo de qualidade ajuda a especificar requisitos de qualidade que sero implementados e
supervisionados durante o ciclo de vida de desenvolvimento do produto. O modelo ajuda tambm nas
atividades de avaliao dos produtos intermedirios e finais.
Aqui foram ressaltadas as atividades de avaliao da qualidade de produtos de software, entretanto
as atividades de implementao de requisitos de qualidade, durante o desenvolvimento do produto ainda
uma rea carente de experincias prticas.
As comunidades que pesquisam e praticam qualidade de processo e produto de software se mantm
separadamente nas suas atividades, sendo uma das intenes aqui colocadas que essas comunidades
olhem juntas para um s objetivo que a qualidade de software como um todo, tanto do ponto de vista
da gesto do desenvolvimento quanto do ponto de vista do usurio.
As fbricas de software, com tanta demanda, trabalham numa produo no sistemtica, e
dependente de pessoas. Isso chamou a ateno de pesquisadores para que houvesse uma
163
sistematizao (organizao) nos processos de produo de software. O produto gerado acabou ficando
sem a devida ateno no que se refere qualidade e padronizao. As normas de qualidade de produto
tratam desses aspectos, no entanto no so ainda devidamente conhecidas pelos produtores, nem pelo
mercado.
As avaliaes da qualidade de produto de software tratadas no livro so do ponto de vista do usurio
final, o que necessita de um produto j em fase final de produo ou num processo diferenciado de
produo que contemple a qualidade de produto. Avaliao pode ser realizada do ponto de vista do
usurio final, como o assunto em questo, mas tambm pode ser do ponto de vista do desenvolvedor,
do fabricante, do comprador, entre outros.
A metodologia MEDE-PROS que composta de um modelo de qualidade e de um mtodo de
avaliao, faz avaliaes da qualidade de produtos de software e serve de base para avaliaes de
outros tipos de software. evidente que adaptaes so necessrias para cada caso em particular, onde,
por exemplo, documentao do usurio e descrio do produto so partes importantes de qualquer tipo
de software e podem ser consideradas ou no. No caso de software do tipo pacote (COTS) esses
componentes citados so obrigatrios de acordo com a norma NBR ISO/IEC 25051.
Um processo sistemtico de avaliao da qualidade de produto de software mostrado no captulo 6
com detalhes, que tem como base a norma NBR ISO/IEC 14598, partes 1 e 5. Para sua execuo
necessrio especificar os requisitos de avaliao de acordo com um modelo de qualidade e a utilizao
de medidas que devem ser oriundas do mesmo modelo de qualidade. Da a importncia do modelo de
qualidade que est sendo revisto na nova srie ISO/IEC 25000 ser um dos motivos dessa reviso. Esta
srie enfatiza a utilizao do modelo de qualidade para a especificao de requisitos e avaliao.
O MEDE-PROS utiliza as normas de qualidade para especificar os requisitos e avaliar produtos de
software, sendo uma metodologia genrica e que serve para avaliar qualquer produto de software de
domnios diversos. A experincia prtica apresentada mostrou-se til e proveitosa para todos os
envolvidos e demonstrou grandes benefcios aos produtos avaliados.
Com o auxlio da norma NBR ISO/IEC 9126-1, pode-se especificar e avaliar requisitos de qualidade,
de forma objetiva, tanto a qualidade do produto de software quanto a qualidade do processo de seu
desenvolvimento e sua manuteno.
No modelo CMMI e tambm no MPS, a organizao deve trabalhar em parceria com o cliente,
entendendo suas necessidades e promovendo um desenvolvimento ou manuteno de produtos de
software, que estabelece os requisitos do cliente de forma documentada e garante a alocao desses
requisitos aos componentes do software.
Portanto, o CMMI, o MPS e a norma NBR ISO/IEC 9126-1 reconhecem o fato de que a qualidade de
um software altamente influenciada pela qualidade do seu processo. Assim, qualquer iniciativa no
sentido de melhorar a qualidade de produto de software deve estar engajada na melhoria da qualidade
164
de processo de software da organizao. Nesse contexto, possvel dizer que qualidade de software a
integrao entre qualidade de processo e qualidade de produto, isto : uma das modalidades
isoladamente no ser privilegiada.
Isso vem ao encontro da proposta de integrao das abordagens de qualidade de software: processo
e produto, em benefcio do prprio software e da sua utilizao. Com essa iniciativa, o foco estar na
qualidade do software, e no s no processo, ou s no produto final. Ou seja, devem ser executadas as
melhores prticas no processo para desenvolver e manter um produto que possua as caractersticas de
qualidade reconhecidas internacionalmente.
Todas as reas de processo distribudas nos nveis de maturidade do modelo de processo CMMI ou
MPS possuem instncias apontadas aqui, com potencial oportunidade de envolver e utilizar os conceitos
da norma NBR ISO/IEC 9126-1. Isso reflete que independentemente do nvel de maturidade da
organizao, a oportunidade de utilizar os conceitos, os modelos e o processo de avaliao da qualidade
de produto sempre possvel, aplicvel e recomendvel. Esse assunto tambm deve ser pesquisado,
debatido e exercitado na prtica, para que se obtenha resultados concretos.
Na tomada de deciso de avaliar um produto de software ou no, deve ser analisada a relao custobenefcio. Ou seja, alguns aspectos devem ser observados: a execuo de um processo de avaliao
para produtos de software demanda tempo e recursos financeiros tanto para a preparao dos recursos
materiais e humanos necessrios ao processo, quanto dos artefatos a serem gerados (atas de reunies e
relatrio de avaliao). Portanto, a experincia mostra que necessrio analisar a viabilidade desse tipo
de processo ser executado na sua totalidade. Em muitos casos suficiente aplicar parte desse processo
de avaliao para se garantir a qualidade esperada a custo reduzido. Dividir a metodologia em fases
uma boa prtica. A existncia do atributo ou no, pode ser observada j numa fase inicial, sendo que a
sua correta execuo pode ser analisada em uma segunda fase.
165

Introdução - ISO-IEC 14598-3 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Introdução - ISO-IEC 14598-3 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Qualidade de Produto de Software

Ana Cervigni Guerra

Regina M. Thienne Colombo

Requisitos e avaliao da qualidade de software ............................................................................... 98

Captulo 6...................................................................................................................... 125

Captulo 7...................................................................................................................... 155

Consideraes finais............................................................................................................................ 163

O objetivo principal de uma avaliao de produto de software fornecer resultados qualitativos e

desenvolvimento e a operao dos sistemas com o custo, o cronograma e a qualidade melhores e

O MEDE-PROS Mtodo de Avaliao de Qualidade de Produto de Software foi desenvolvido para

O autor Pivka, na poca, referia-se norma ISO/IEC 12119

2.1 Qualidade de produto

Qualidade significa timo, ou luxo, ou brilhante, ou de grande valor.

A palavra qualidade, muitas vezes, usada em expresses do tipo: boa qualidade, m

Qualidade intangvel, portanto no mensurvel.

Os problemas de qualidade so originados por trabalhadores, principalmente aqueles que

Os funcionrios da produo de uma fbrica so acusados de provocar os problemas. Na realidade

Qualidade responsabilidade do departamento da qualidade.

Nessa busca pela qualidade, as organizaes procuram basear-se em conceitos e diretrizes

2.2 Qualidade de produto de software

Figura 2.1 Aspectos gerais do software: a evoluo dos sistemas de software.

a habilidade de construir software no acompanha o potencial do desenvolvimento de novo

2.2.2 Software e suas caractersticas como produto

Complexidade: normalmente, um produto de software tem muitas regras a serem cumpridas;

Invisibilidade e intangibilidade: o software invisvel para o usurio. O que se v so as

Conformidade e modificabilidade: o software a interface entre diversas entidades do meio no qual

No se desgasta com o uso: em software os componentes lgicos so durveis. A falha de

No tem prazo de validade: o software no sensvel a problemas ambientais e nem sofre

O custo final do software basicamente o custo do projeto e do desenvolvimento: cpias do

Diante dessas diferenas, difcil imaginar, de forma direta no desenvolvimento de software, o

1997 (589 empresas)

1999 (426 empresas)

Empresas que adotam mtodos de preveno de defeitos

Joint Application Design

Medies da qualidade (medidas)

Empresas que adotam mtodos de deteco/remoo de defeitos

Empresas que adotam outras prticas de Engenharia de Software

Mtodos orientados a objetos

Projetos interface com o usurio

Observao: O smbolo ... indica dado indisponvel.

A determinao do conjunto de caractersticas que atende s necessidades de seus usurios.

Viso geral do processo de avaliao;

Processo de avaliao para desenvolvedores;

Processo para adquirentes;

Processo para avaliadores;

Planejamento e gesto do processo;

Documentao de mdulos de avaliao.

Atualmente em reviso na srie 25000.

2.3 Qualidade de processo de software

O autor, na poca se referia norma ISO/IEC 12119

Figura 2.2 Definio de processo de software. Fonte: CMMI (2002).

2.3.1 Aspectos gerais

Figura 2.3 Situao de muitas organizaes de software. Fonte: MAGNANI (1998).

As organizaes esto reagindo a crises constantes;

A maioria dos problemas nas organizaes de software de natureza gerencial, e no tcnica. A

A alta velocidade de mudanas tecnolgicas envolvidas, como o prprio hardware;

O baixo estmulo participao do usurio no processo de software, o que conduz a uma

Apesar da demanda por qualidade, os avanos da Engenharia de software no conseguem

NBR ISO 9000-3 aplicada ao desenvolvimento, fornecimento e manuteno de software;

NBR ISO/IEC 12207 que define os processos de ciclo de vida do software;

5 Esta norma foi cancelada, e ainda no possui substituio na ABNT.

CMMI (CHRISSIS, 2003) desenvolvido nos EUA, substituiu o CMM;

2.3.2.1 NBR ISO/IEC 15504