Escolar Documentos
Profissional Documentos
Cultura Documentos
Qs Ap2 9126 PDF
Qs Ap2 9126 PDF
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.
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
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.4 PROCESSO DE AVALIAO SEGUNDO NORMA NBR ISO/IEC 14598-5. ................................................. 105
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.1 PROCESSO DE AVALIAO SEGUNDO NORMA NBR ISO/IEC 14598-1. ................................................. 126
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 6.3 TIPO DE QUESTO 02 ............................................................................................................................ 142
TABELA 6.4 TIPO DE QUESTO 03 ............................................................................................................................ 143
TABELA 6.5 TIPO DE QUESTO 04 ............................................................................................................................ 143
TABELA 6.6 TIPO DE QUESTO 05 ............................................................................................................................ 143
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.
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
11
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.
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.
S1
E2
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
S4
E5
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
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.
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.
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
22
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;
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.
Resultados (N de Empresas / %)
1995 (445 empresas)
...
102 / 17%
88 / 21%
Gerncia de configurao
...
40 / 7%
63 / 15%
...
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%
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
...
32 / 5%
31 / 7%
Mtodos estruturados
...
210 / 36%
146 / 34%
193 / 43%
216 / 37%
186 / 44%
...
207 / 35%
215 / 51%
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 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:
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;
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.
27
28
As organizaes percebem a situao catica, mas encontram dificuldades em mudar esse quadro
em funo de uma srie de fatores, dentre os quais:
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 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.
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;
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.
31
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
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
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
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.
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
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.
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
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
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
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
CMMI
MPS
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
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.
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 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 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.
43
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.
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
46
47
O MEDE-PROS foi concebido com a NBR ISO/IEC 12119, e sua ltima verso de 2006.
48
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.
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
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
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
54
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
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.
58
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
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:
61
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).
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?
62
Tolerncia a erros medida dos danos que ocorrem quando o programa executa um erro.
63
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.
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:
65
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
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.
formar um conjunto entre seis e oito caractersticas, por questes de clareza e manuseio; e
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
Acurcia
Interoperabilidade
Conformidade
Segurana de acesso
Maturidade
Frequncia de falhas
Tolerncia a falhas
Recuperabilidade
Conformidade
Inteligibilidade
Apreensibilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
Operacionalidade
Atratividade
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
Modificabilidade
Estabilidade
Conformidade
Testabilidade
Adaptabilidade
Coexistncia
Conformidade
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
9126-2
9126-3
9126-4
Ttulo
Engenharia de software
Qualidade de Produto
Modelo de Qualidade
Engenharia de software
Qualidade de Produto
Medidas externas
Engenharia de software
Qualidade de Produto
Medidas internas
Engenharia de software
Qualidade de Produto
Medidas qualidade em uso
Assunto
Estado Internacional
Estado Nacional
Norma, publicada em 2003
Exemplos de medidas
externas
Exemplos de medidas
internas
Exemplos de medidas de
qualidade em uso
70
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.
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
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
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.
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
PWI
1 Estgio de Proposta
NP
2 Estgio preparatrio
Working draft(s)
WD
3 Estgio Comit
Committee draft(s)
CD
75
4 Estgio de consulta
DIS
5 Estgio de aprovao
FDIS
6 Estgio de publicao
International Standard
ISO/IEC
Norma
Ttulo resumido
Diviso Gesto da Qualidade
25000
25001 (ex - 14598-2)
Publicada em 2005
Publicada em 2007
2501n
25010 (ex - 9126-1)
25012
Em reviso
Em reviso
2502n
25020
25021
25022 (ex - 9126-3)
25023 (ex - 9126-2)
25024 (ex - 9126-4)
Publicada em 2007
Publicada em 2007
Em reviso
Em reviso
Em reviso
Publicada em 2009
2503n
25030
Publicada em 2007
Publicada em 2008
2504n
25040 (ex - 14598-1)
25041 (ex - 14598-6)
25051
25062
Estado internacional
Estado nacional
Publicada em 2008
Publicada em 2009
Em reviso
Em reviso
Publicada em 2006
Publicada em 2008
76
A seguir sero apresentados modelos de qualidade baseados nas normas e advindos de aplicaes
prticas.
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
79
10
80
Este modelo de qualidade pode ser visto como um modelo genrico para avaliar qualquer categoria de
software, independente da sua rea de aplicao.
81
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.
O modelo de qualidade de cada CSA dos sistemas aplicativos contempla os requisitos especficos
contidos e publicados no Edital.
83
Para melhor entendimento da definio apresentada por Villela, alguns termos foram detalhados por
Sametinger (SAMETINGER,1997) de forma mais profunda:
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.
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.
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.
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
Funcionalidade
Completitude
Usabilidade
Inteligibilidade
Correo
Apresentao e
Consistncia
Organizao
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
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:
Produtor/fornecedor do componente;
86
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;
Valores-limites declaraes de valores limites, caso o uso do componente seja limitado por
eles;
87
Proteo tcnica declaraes sobre proteo contra infraes a direitos autorais, caso
estes dificultem a usabilidade.
88
89
90
Apresentao visual verificar se h uma boa apresentao visual; por exemplo, tamanhos
e tipos de fontes, cores e layout.
91
92
Remoo de falhas verificar o nmero de remoo de falhas de uma verso para outra.
Clareza das interfaces verificar o nvel de clareza com que as interfaces so declaradas;
93
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.
Os atributos avaliados so:
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.
O atributo avaliado :
94
Preciso verificar a preciso dos resultados obtidos com o que foi especificado pelo
requisito do usurio.
95
Tratamento de erros verificar se o componente pode controlar situaes de erros por meio
de mecanismos implementados, por exemplo: excees.
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;
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.
98
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
14598-2
14598-3
14598-4
14598-5
14598-6
Ttulo resumido
Assunto
Estado Internacional
Estado Nacional
Norma, publicada em 2002
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.
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:
101
O desenvolvedor deve:
tornar os dados coletados disponveis para a organizao, para seu uso em outros projetos de
desenvolvimento;
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:
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
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
105
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.
107
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.
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.
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:
laboratrios de teste, que tero de seguir as instrues durante a execuo de testes para
certificao ou para emisso de marca de conformidade;
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;
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
113
Identificao e indicaes
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
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
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
O software deve poder ser instalado; a instalao e a operao devem ser verificadas em todas as
plataformas e deve fornecer meios de desinstalao.
Requisitos
116
Fases
Recomendaes
Pr-requisitos
Atividades
Processo de avaliao
Relatrio
Avaliao na fase de
acompanhamento
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;
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
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:
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.
120
Volume nico
Componente
Multivolumes
8 Pginas ou Menos
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
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.
Categoria
Identificao do pacote
ESS
Contedo do pacote
ESS
ESS
Instalao do software
ESS
122
Utilizao do software
ESS
CON
Teste
OPT
Informao contratual
ESS
Glossrio
CON
ndice
CON
Comentrios de usurios
OPT
Categoria
Identificao do pacote
ESS
ESS
Ambiente
ESS
Entrada
OPT
Sada
OPT
Restries
CON
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
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:
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:
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.
A seguir, ser apresentada cada uma das fases do processo de avaliao, com sugestes para
programar as dez atividades nele definidas.
126
2.
Quais os aspectos de qualidade do produto que o requisitante da avaliao pretende que sejam
avaliados e com que nfase?
Resp.:
Resp.:
Resp.:
128
2.
Nvel de conhecimento exigido dos usurios em relao ao domnio da aplicao em si. Resp.:
3.
Resp.:
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.
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:
129
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.
Selecionar medidas;
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:
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
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:
M (Muitas), P (Poucas) ou
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
Portabilidade
Completitude
Identificao do produto
Usabilidade
Apresentao visual
Funcionalidade
Acurcia
Usabilidade
Clareza
Funcionalidade
Padres Internos
Funcionalidade
Acesso Seletivo
Eficincia
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.
(_____) .2.
(_____) .3.
(_____) .4.
(_____) .5.
(_____) .6.
Em outra medida, na fase da Instalao, mostra-se o atributo Instrues para Instalao, com as
seguintes medidas em forma de proposies:
133
(_____) .3.
(_____) .4.
o nome do produto;
T=Todos; A=Alguns; N=Nenhum.
(_____) .2.
o nome do produto;
S=Sim; N=No.
(_____) .4.
134
(_____) .2.
(_____) .3.
(_____) .5.
(_____) .6.
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.
(_____) .2.
A interface:
(_____) .3.
(_____) .4.
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.
(_____) .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.
(_____) .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.
(_____) .8.
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.
(_____) .3.
(_____) .4.
(_____) .5.
137
(_____) .2.
(_____) .3.
(_____) .2.
138
(_____) .3.
executa do mesmo modo, tanto num ambiente quanto no outro, sem que o usurio possa
perceber diferenas.
S=Sempre; A=Algumas vezes; N=Nunca.
(_____) .2.
(_____) .3.
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.
(_____) .3.
o nome do produtor;
S=Sim; N=No.
(_____) .4.
(_____) .5.
139
S=Sim; N=No.
(_____) .6.
identificao das tarefas ou funes que podem ser executadas, utilizando-se o software;
S=Sim; N=No.
(_____) .2.
(_____) .3.
(_____) .4.
(_____) .2.
(_____) .3.
140
(_____) .4.
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.
(_____) .3.
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:
Valores numricos
AP
00,00
NA
01,00
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:
Tabela 6.3 Tipo de questo 02
Tipo de resposta
Valores numricos
AP
01,00
NA
00,00
142
Valores numricos
00,50
AP
00,00
NA
01,00
Valores numricos
AP
01,00
Muitas
00,00
Nenhuma
NA
00,50
Avaliao prejudicada
No se aplica
Poucas
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 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.
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
Ai jklm
B klm
j
i 1
I klm
j
c) Nota da Subcaracterstica
m
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
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.
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 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.
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
Obter as medidas;
Julgar os resultados.
Com o produto em mos, identificar os folhetos e documentos que vieram dentro e fora da
embalagem, ou que foram obtidos no site.
148
149
Produto de software nas mesmas condies recebidas, incluindo folhetos e anexos impressos;
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).
A.
Propsito da avaliao
B.
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.
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.
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
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:
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.
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?
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
A) Selecionar medidas
As medidas selecionadas para esta avaliao so as contidas na lista de verificao do Apndice A.
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
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.
160
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