Qualidade de Produto de Software

Ana Cervigni Guerra Regina Maria Thienne Colombo

Sobre as autoras Ana Cervigni Guerra

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

Regina M. Thienne Colombo

graduada em Cincia da Computao pela UFSCAR, mestre em Engenharia Mecnica pela Unicamp na rea de qualidade e doutoranda na Poli-USP. Com vasta experincia em Engenharia e Qualidade de Software, trabalha como pesquisadora e coordenadora da Diviso de Qualificao em Software, no Centro de Tecnologia da Informao Renato Archer CTI/MCT. participante da ABNT/CB-21 Computadores e processamento de dados e da ISO/IEC SC7/WG6 (Engenharia de Software).

Agradecimentos
Este trabalho no poderia ter sido realizado sem o apoio do Centro de Tecnologia da Informao Renato Archer - CTI, que nos possibilitou a oportunidade de aprofundar nossos conhecimentos tericos e prticos na rea de Qualidade de Software. Alm das contribuies tcnicas dos profissionais dessa instituio, algumas pessoas ajudaram, indiretamente, na elaborao deste trabalho, s quais prestamos homenagem: Ao Sr. Romildo Monte, que iniciou o programa de Qualidade de Software no CTI (antigo CenPRA), agradecemos pela boa vontade, pacincia e presteza que sempre dedica a todos que o procuram. Em especial, agradecemos grande equipe de profissionais que passaram pelo CTI e que tm desenvolvido trabalhos nessa rea desde 1994. A essa equipe agradecemos pelo apoio tcnico deixado como legado na nossa instituio. Sem ela no nos teria sido possvel tanto conhecimento a ser disseminado. Reunimos esse material valioso, para que no se tornasse mais um documento tcnico interno e para que seja acessvel a quem interessar. Tudo isso resultado de pesquisas da instituio, de interao com empresas, outras instituies de Pesquisa e Desenvolvimento - P&D e Universidades, e de trabalhos acadmicos em cooperao com a Unicamp - trabalhos que garantiram o ttulo de mestre a algumas pessoas da equipe, entre elas uma das autoras. Ao Sr. Kival Chaves Weber, um cone no pas, quando falamos em Qualidade de Software, agradecemos pelo incentivo constante ao nosso trabalho, por todas as vezes que nos motivou na pesquisa e aplicao do conhecimento. Aos revisores do livro, pelas sugestes to apropriadas e pertinentes e pela pacincia. Ainda agradecemos em especial o Sr. Danilo Scalet, a Sra. Denise Carneiro, a Sra. Diva da Silva Marinho e o Prof. Gilberto Cludio P. Balthazar. A todos o nosso carinho.

Sumrio
Introduo ............................................................................................................................................. 10

Captulo 1........................................................................................................................ 13
Panorama tecnolgico ........................................................................................................................... 13

Captulo 2........................................................................................................................ 17
Qualidade de Software.......................................................................................................................... 17
2.1 Qualidade de produto.................................................................................................................................... 17 2.2 Qualidade de produto de software ................................................................................................................ 19 2.2.1 Aspectos gerais e evoluo do software ............................................................................................... 20 2.2.2 Software e suas caractersticas como produto ....................................................................................... 23 2.2.3 Iniciativas para a qualidade de produto de software ............................................................................. 25 2.3 Qualidade de processo de software ............................................................................................................... 27 2.3.1 Aspectos gerais ..................................................................................................................................... 28 2.3.2 Iniciativas para a qualidade de processo de software ............................................................................ 30 2.3.3 Comparao entre os modelos .............................................................................................................. 39

Captulo 3........................................................................................................................ 42
Categorias de produtos de software e avaliao................................................................................. 42
3.1 Categorias segundo Pressman....................................................................................................................... 42 3.2 Caracterizaes da norma IEEE 1062 .......................................................................................................... 43 3.3 Categorias para prmios de software ............................................................................................................ 44 3.4 Avaliao de produto de software ................................................................................................................ 47 3.4.1 Mtodo de avaliao genrico (MEDE-PROS) ................................................................................. 48 3.4.2 Mtodo de avaliao especialista .......................................................................................................... 51 3.5 Avaliao e certificao de produto de software .......................................................................................... 54 3.6 Avaliao e teste de software ....................................................................................................................... 58

Captulo 4........................................................................................................................ 60
Modelos de qualidade ........................................................................................................................... 60
4.1 Modelo de McCall ........................................................................................................................................ 61 4.2 O modelo da norma NBR ISO/IEC 9126-1 .................................................................................................. 64 4.2.1 Diretrizes para uso da norma NBR ISO/IEC 9126-1 ............................................................................ 65 4.2.2 Caractersticas e subcaractersticas de qualidade de software............................................................... 65 4.3 A srie ISO/IEC 25000 ................................................................................................................................. 70 4.4 O modelo de qualidade do MEDE-PROS.................................................................................................. 77 4.5 Modelo de qualidade do PNAFM ................................................................................................................. 81 4.6 Modelo de qualidade de componentes de software ...................................................................................... 83 4.6.1 Descrio do componente ..................................................................................................................... 86 4.6.2 Documentao do usurio ..................................................................................................................... 89 4.6.3 Componentes no DBC .......................................................................................................................... 91 4.6.4 Componente integrado no SBC ............................................................................................................ 94

Captulo 5........................................................................................................................ 98 4

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

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

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

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

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

Avaliao de um software................................................................................................................... 155
7.1 Apresentao do software ........................................................................................................................... 155 7.2 Processo de avaliao ................................................................................................................................. 155 7.2.1 Estabelecer requisitos de avaliao ..................................................................................................... 155 7.2.2 Especificar a avaliao ........................................................................................................................ 158 7.2.3 Projetar a avaliao ............................................................................................................................. 159 7.2.4 Executar a avaliao ........................................................................................................................... 160 7.2.5 Concluso da avaliao ....................................................................................................................... 161

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

Apndice A
Guia de Avaliao da Qualidade de Produto de Software

Apndice B
Modelo da identificao da avaliao

Apndice C
Modelo de relatrio de avaliao

Apndice D
Conceitos de qualidade para produtos de software uma sntese

Apndice E
Relatrio de Avaliao do Software: Easy Learn

Apndice F
Glossrio

Referncias Bibliogrficas

NDICE DE FIGURAS FIGURA 2.1 ASPECTOS GERAIS DO SOFTWARE: A EVOLUO DOS SISTEMAS DE SOFTWARE. ...................................... 20 FIGURA 2.2 DEFINIO DE PROCESSO DE SOFTWARE. FONTE: CMMI (2002)............................................................. 28 FIGURA 2.3 SITUAO DE MUITAS ORGANIZAES DE SOFTWARE. FONTE: MAGNANI (1998). ............................... 29 FIGURA 2.4 RELAO DA NORMA NBR ISO/IEC 15504 COM OS MODELOS DE PROCESSO. ........................................ 34 FIGURA 3.1 ESTRUTURA DA LISTA DE VERIFICAO DE UM MTODO DE AVALIAO (MEDE-PROS) ................... 49 FIGURA 3.2 ESTRUTURA A SER DESENVOLVIDA NUMA AVALIAO ESPECIALISTA. .................................................... 53 FIGURA 3.3 QUALIDADE DE SOFTWARE DURANTE SEU DESENVOLVIMENTO (FONTE:NBR ISO/IEC 9126-1)............. 57 FIGURA 3.4 CICLO DE VIDA CLSSICO PARA DESENVOLVIMENTO DE SOFTWARE........................................................ 59 FIGURA 4.1 MODELO DE QUALIDADE DE MCCALL, ORGANIZADO EM FUNO DE TRS TIPOS DE CARACTERSTICAS DA QUALIDADE. ........................................................................................................................................................ 61 FIGURA 4.2 MODELO BSICO DE QUALIDADE............................................................................................................. 66 FIGURA 4.3 CARACTERSTICAS E SUBCARACTERSTICAS DE QUALIDADE. .................................................................. 67 FIGURA 4.4 ARQUITETURA ATUAL DA SRIE ISO/IEC 25000.(2009) ......................................................................... 71 FIGURA 4.5 DIVISO DE GESTO DA QUALIDADE DA SRIE ISO/IEC 25000. ............................................................ 72 FIGURA 4.6 DIVISO MODELO DE QUALIDADE DA SRIE ISO/IEC 25000.................................................................. 73 FIGURA 4.7 DIVISO DE MEDIO DE QUALIDADE DA SRIE ISO/IEC 25000. .......................................................... 74 FIGURA 4.8 DIVISO REQUISITOS DE QUALIDADE DA SRIE ISO/IEC 25000. ............................................................ 74 FIGURA 4.9 DIVISO DE AVALIAO DA QUALIDADE DA SRIE ISO/IEC 25000. ...................................................... 74 FIGURA 4.10 COMPONENTES DE SOFTWARE. ............................................................................................................... 79 FIGURA 4.11 ETAPAS DE AVALIAO. ........................................................................................................................ 80 FIGURA 4.12 MODELO DE QUALIDADE NUMA VISO MAIS DETALHADA. .................................................................... 81 FIGURA 4.13 CONJUNTO DE SISTEMAS APLICATIVOS DO PNAFM ............................................................................. 82 FIGURA 4.14 MODELO DE QUALIDADE DO PNAFM ................................................................................................... 83 FIGURA 4.15 MODELO DE QUALIDADE PARA COMPONENTES DE SOFTWARE COTS.................................................... 86 FIGURA 5.1 RELACIONAMENTO ENTRE AS PARTES DA SRIE ISO/IEC 14598. .......................................................... 100 FIGURA 5.2 RELACIONAMENTO ENTRE AS SRIES 9126 E 14598. ............................................................................. 101 FIGURA 5.3 PROCESSO DE AVALIAO SEGUNDO NORMA NBR ISO/IEC 14598-1. ................................................. 104 FIGURA 5.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.

O objetivo principal de uma avaliao de produto de software fornecer resultados qualitativos e quantitativos sobre a qualidade desse produto, resultados que sejam compreensveis, aceitveis a quaisquer das partes interessadas, e confiveis. Em vrias regies do mundo, existem centros de desenvolvimento tecnolgico em software, com o objetivo de acompanhar a rea de Qualidade de Software, empenhados em repassar para organizaes interessadas o estado da prtica empregado com sucesso em projetos reais. Alguns exemplos do que esses centros tm declarado, em suas respectivas misses, so citados a seguir:

Software Engineering Institute SEI, localizado em Pittsburg, EUA, e mantido pelo DoD (US
Department of Defense, ou Departamento de Defesa Americano). Faz parte de sua misso "assegurar o

10

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

11

O MEDE-PROS Mtodo de Avaliao de Qualidade de Produto de Software foi desenvolvido para avaliar a Qualidade de Produto de Software, tendo como referncia as normas nacionais e internacionais. Esse mtodo se encontra registrado na Fundao Biblioteca Nacional, sob nmero 135.620, livro 216, folha 84, e com o registro de marca no INPI sob nmero 820166243. Encontra-se na verso 2006 e propriedade do CTI. O MEDE-PROS um exemplo de aplicao das normas, sendo que outras metodologias podem ser desenvolvidas para este contexto. Aqui ser citado apenas esse mtodo, como um exemplo para melhorar produtos de software, sob o ponto de vista do usurio final. Este trabalho foi realizado numa fase de reestruturao das normas de qualidade de produto de software. Assim, as nomenclaturas que se encontram em ajustes nos rgos normatizadores foram aqui tratadas apresentando, muitas vezes, os nomes e conceitos das normas anteriores. Procura-se minimizar problemas dessa transio, mencionando os nomes das normas reiteradamente. Este livro est organizado da seguinte forma: No captulo 1 apresentado, rapidamente, um panorama tecnolgico, sendo que a ideia de qualidade como um aporte bsico e se estendendo para qualidade de produto e processo de software est no captulo 2. As categorias de produtos de software e como trat-las para uma avaliao esto no captulo 3. Os modelos de qualidade se apresentam no captulo 4. Outros requisitos de qualidade e o processo de avaliao sugeridos nas normas esto no captulo 5. Uma sugesto de metodologia do processo de avaliao de software e um processo de avaliao especfico para componentes de software esto apresentados no captulo 6. Um exemplo de avaliao de software est no captulo 7. As consideraes finais fazem uma reflexo sobre os assuntos abordados. No apndice A est o Guia de Avaliao da Qualidade de Produto de Software originado da metodologia do MEDE-PROS, em sua formatao especial, que se apresenta de forma auto explicativa. No apndice B se apresenta um modelo de formulrio para identificao da avaliao. No apndice C, uma sugesto de modelo de relatrio de avaliao. O apndice D apresenta uma sntese dos conceitos de qualidade para produtos de software, sendo til para uma consulta rpida e familiarizao desses conceitos. O apndice E mostra o relatrio de um produto avaliado. O apndice F contm um glossrio e finalmente, as referncias bibliogrficas.

12

CAPTULO 1 Panorama tecnolgico Nos ltimos anos, tem ocorrido um crescimento sem precedentes na rea de TI Tecnologia da Informao. Com a globalizao e a internet facilitando ainda mais a abertura de mercado, a produo de software escoada independentemente das fronteiras nacionais. A realidade mundial, nos ltimos 20 anos, mostra que a utilizao de sistemas computacionais comandados por software tem tido uma abrangncia crescente, integrando-se no dia a dia de todos os setores de atividades da sociedade, atingindo um grande e diversificado nmero de usurios. No meio cientfico, v-se ainda uma busca de como produzir software com qualidade. Em 1993, o projeto SCOPE Software CertificatiOn Programme in Europe foi exemplo de uma iniciativa internacional para melhorar a qualidade do produto de software, que gerou os primeiros trabalhos para elaborao de normas na rea de Qualidade de Software (SCOPE, 2009). No meio industrial existe, por parte dos desenvolvedores e empresrios de software, uma boa vontade em atender bem o mercado; mas, com a demanda cada vez mais crescente, o produto de software se apresenta sem os nveis de qualidade em conformidade com as normas, at os dias de hoje. Qualidade de software constitui uma rea cuja demanda est crescendo significativamente, pois os usurios exigem cada vez mais eficincia, eficcia, dentre outras caractersticas de qualidade importantes para um produto to especial como o software. Paralelamente demanda do mercado, existe um movimento nacional e internacional, no sentido de estabelecer normas na rea de Engenharia de Software, como o caso da ISO Organizao Internacional de Normalizao, no Subcomit de Engenharia de Software, e da ABNT Associao Brasileira de Normas Tcnicas. Denomina-se ISO International Organization for Standardization a organizao internacional para a padronizao. Ela foi estabelecida em 1947, como uma organizao mundial no governamental e conta atualmente com mais de 100 organizaes nacionais de padronizaes, representando mais de 130 pases, responsveis por mais de 95% da produo industrial mundial. Com sede em Genebra, Sua, tem como principal atividade a elaborao de padres para especificaes e mtodos de trabalho nas mais variadas reas. O principal objetivo da ISO o desenvolvimento de padres mundiais, com vistas a facilitar o intercmbio internacional de produtos e servios e a criar uma cooperao intelectual, cientfica, econmica e tcnica. A IEC International Electrotechnical Commission, fundada em 1906, a organizao mundial que publica normas internacionais relacionadas com eletricidade, eletrnica e reas afins, tendo a participao de mais de 50 pases.

13

A ISO, em conjunto com a IEC, elaborou um conjunto de normas que tratam, especificamente, da atual padronizao mundial para a qualidade dos produtos de software. No Brasil, a ABNT foi fundada em 1940. Reconhecida como Foro Nacional de Normalizao, o nico rgo responsvel pela normalizao tcnica no pas, fornecendo a base necessria ao desenvolvimento tecnolgico brasileiro. uma entidade privada, sem fins lucrativos, e representa o Brasil nas entidades de normalizao internacional, como a ISO e a IEC. As normas recomendam modelos de qualidade e processos de avaliao da qualidade de software que se tm firmado como valioso auxlio obteno de produtos de software com qualidade aprimorada e mais confivel. Por um lado, surge a oportunidade do desenvolvimento de metodologias para avaliar a qualidade de produto de software, com base em atributos de qualidade das normas reconhecidas internacionalmente, dando subsdios para que compradores e usurios adquiram produtos com caractersticas mais prximas de suas necessidades. Por outro, surge para produtores de software a possibilidade de fornecer produtos de melhor qualidade. A avaliao de produto de software tem sido uma das formas empregadas por organizaes que produzem ou adquirem software para obteno de melhor qualidade nesses produtos, sejam eles completos ou partes a serem integradas a um sistema computacional mais amplo. Para que a avaliao seja mais efetiva, importante utilizar um modelo de qualidade que permita estabelecer e avaliar requisitos de qualidade. necessrio que o processo de avaliao seja bem definido e estruturado. Os conjuntos de normas ISO/IEC JTC1/SC7 9126 e ISO/IEC 14598, atualmente sendo reestruturadas na srie ISO/IEC 25000 - Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE), descrevem um modelo de qualidade, um processo de avaliao, uma diretriz para requisitos de qualidade e um conjunto de medidas de qualidade. Alguns exemplos de medidas so encontrados nessas normas e podem ser utilizados por organizaes que pretendam fazer avaliao de produto de software. A norma NBR ISO/IEC 25051 (2008) estabelece requisitos de qualidade para pacotes de software e instrues para avaliao da conformidade de software. Pacotes de software, denominados COTS Commercial Off-The-Shelf , so produtos de software definidos por uma necessidade orientada pelo mercado, disponveis comercialmente, cuja adequao para uso foi demonstrada por um grande nmero de usurios. As organizaes produtoras de software devem procurar solues compatveis com seu porte e objetivos de negcio. Um exemplo disso pode ser visto em Pivka (1995), que prope a certificao do 1 produto de software baseada na norma ISO/IEC 12119 como alternativa para a garantia da qualidade de software produzido por pequenas empresas produtoras de software. Esse tipo de certificao, no concretizado ainda, tema de estudo e esforos individuais.

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

14

Deve-se, ainda, considerar que, diante de um mercado consumidor imaturo, a pessoa ou entidade que se coloca no papel de avaliador deve assumir uma responsabilidade adicional: primeiro identificar os desejos j expressos por esse mercado; em seguida, antecipar outras necessidades importantes ainda no definidas e, finalmente, influir no mercado, para que tanto o produtor como o consumidor possam evoluir. As organizaes nacionais de software devem repensar as premissas fundamentais que norteiam uma disputa de mercado e enfrentar o grande desafio de oferecer preos competitivos, menores prazos de desenvolvimento, menos defeitos e maior satisfao dos clientes e usurios. Esses so alguns dos requisitos de mercado para um software de qualidade. As organizaes se tm deparado com projetos de software cada vez maiores, mais complexos e de grande impacto na sociedade. O software faz parte do dia a dia de toda a sociedade. Ele transfere fundos entre instituies financeiras, pilota avies, controla equipamentos em centros mdicos, diverte as crianas, torna possvel pesquisa cientfica de grande complexidade aritmtica e muito mais. O grande problema que, em geral, a qualidade do software no satisfatria, por no atender as necessidades dos usurios e apresentar falhas. A comunidade cientfica, o governo e as prprias organizaes, em resposta a essas necessidades, cad vez mais esto buscando a qualidade de software, por meio de abordagens voltadas tanto para o produto final quanto para o processo de desenvolvimento e manuteno de software. Estudos sobre a qualidade, no setor de software brasileiro, mostraram a necessidade de um esforo significativo capaz de aumentar a maturidade dos processos de software das empresas brasileiras e deram incio ao Programa MPS.Br Melhoria de Processo do Software Brasileiro. uma iniciativa que envolve universidades, grupos de pesquisa e empresas, sob a coordenao da Sociedade Softex (Associao para Promoo da Excelncia do Software Brasileiro). O programa tem como premissa a definio e disseminao de um Modelo de Referncia e um Modelo de Negcio para melhoria de processo de software MR-MPS e MN-MPS, respectivamente. A qualidade de software continua, no entanto, requerendo melhorias. Um processo de qualidade no garante a produo de um produto de software de qualidade. Percebe-se, nesse ponto, uma lacuna nos esforos que vm sendo realizados na busca pela qualidade de software. O processo, que ir resultar no produto de software, concentra seus esforos na busca pela qualidade do modo de produo e manuteno do software, ao passo que a qualidade do produto de software focada com mais intensidade apenas quando ele j est pronto, por meio da avaliao de sua performance. As iniciativas pela busca da qualidade de software descritas anteriormente, denominadas, respectivamente, abordagem de processo e abordagem de produto, so de grande valor e tratam seus objetivos de forma exemplar, mas agem de forma isolada. H uma expectativa de que o programa MPS.BR da Softex (www.softex.br), que teve incio em 2003, no Brasil, tenha outro resultado e consolide a ideia de que um processo bem definido ajuda muito a qualidade do produto.

15

A qualidade do produto de software precisa fazer parte, de maneira intensa e formal, das preocupaes do processo de desenvolvimento e manuteno. As caractersticas de qualidade de um produto de software precisam ser alocadas e verificadas tambm nos produtos de software intermedirios, ao longo do processo, e no apenas no produto j acabado. Tal procedimento permite que desvios no produto sejam detectados durante seu processo de desenvolvimento e manuteno, originando aes necessrias ao processo para direcion-lo produo de um produto de software de qualidade. O software um produto complexo, que depende em parte da interpretao das necessidades do usurio que iro se converter nos requisitos do produto para o seu desenvolvimento; dessa forma, necessita de tcnicas verificao e validao durante o ciclo de desenvolvimento do produto e tcnicas de avaliao do produto intermedirio e final que garantam que o produto correto e seguro, entre outros atributos de qualidade.

16

CAPTULO 2 Qualidade de Software A Engenharia de software tem uma de suas reas, a Qualidade de software, que objetiva garantir que especificaes explcitas e necessidades implcitas estejam presentes no produto, por meio da definio e normatizao de processos de desenvolvimento. Apesar de os modelos aplicados na garantia da qualidade de software atuarem, em especial, no processo, o principal objetivo garantir um produto final que satisfaa s expectativas do cliente, dentro daquilo que foi acordado inicialmente.

2.1 Qualidade de produto Existem vrias propostas de definio para qualidade de produto. Crosby (1979) afirma: Qualidade conformidade com os requisitos. Essa definio foi utilizada na manufatura, porm serve para engenharia de software. Alm disso, menciona que preciso definir qualidade dessa forma, principalmente porque a qualidade deve ser gerenciada. Para entender o significado de qualidade em termos prticos, necessrio conhecer os cinco principais erros, En, cometidos por gerentes e saber como eles devem ser tratados, Sn, de acordo com esse autor:
E1 S1 Qualidade significa timo, ou luxo, ou brilhante, ou de grande valor. A palavra qualidade, muitas vezes, usada em expresses do tipo: boa qualidade, m qualidade e at qualidade de vida. Mas, cada um que a ouve atribui um significado para o que seja qualidade de vida; por exemplo, um sentido que no corresponde ao que um falante deseje, realmente, dizer com a referida expresso. preciso definir qualidade de vida em termos especficos, tais como: renda familiar; sade; controle de poluio; programas polticos e quaisquer outros itens que possam ser medidos. Qualidade intangvel, portanto no mensurvel. 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. 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. 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.

E2 S2

E3

S3

17

E4 S4

Os problemas de qualidade so originados por trabalhadores, principalmente aqueles que trabalham diretamente na rea de produo. Os funcionrios da produo de uma fbrica so acusados de provocar os problemas. Na realidade eles pouco contribuem para a preveno, ou no, de defeitos, pois todo planejamento e criao foram definidos previamente, e eles so apenas seus executores. Qualidade responsabilidade do departamento da qualidade. 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.

E5 S5

Resumidamente, qualidade conformidade com requisitos, e estes devem estar definidos para permitir que sejam gerenciados com o uso de medidas, de forma a reduzir o retrabalho e aumentar a produtividade. A melhoria da qualidade deve estar focada nos processos, e no nas pessoas; certamente, responsabilidade de todos os envolvidos no processo. A satisfao com o produto est relacionada com seu desempenho e com a ausncia de defeitos, erros ou falhas. Portanto, a satisfao com o produto alcanada quando as necessidades do cliente so supridas, e o produto se comporta como esperado. Os requisitos representam as necessidades explcitas dos clientes e devem procurar cobrir a maior parte das necessidades por eles declaradas em relao ao produto. Sobre as necessidades do cliente, algumas no esto na especificao dos requisitos, mas tambm so de fundamental importncia. Trata-se das necessidades implcitas, definidas por Joseph Juran (1988), e que sero explicadas a seguir. Necessidades explcitas nada mais so do que a definio dos requisitos, as condies e os objetivos propostos para o produto. Quanto s necessidades implcitas, tm foco na viso subjetiva do consumidor/usurio com relao ao produto, tais como: as necessidades razoveis; implicaes estticas; itens de segurana, entre outras. As necessidades explcitas para um carro popular podem ser, por exemplo: ser econmico, fazendo 20 km com 1 litro de combustvel, e custar no mximo R$ 25 mil. Como necessidades implcitas poderiam constar: ser confortvel; ter um design sofisticado; possuir itens de segurana e seu motor funcionar. Dessa forma, o melhor a fazer definir muito bem os requisitos de um produto e gerenciar seu processo, para que as necessidades implcitas e os defeitos possam ser reduzidos ao mnimo. Tudo isso sem deixar de monitorar a satisfao do cliente com o produto, o que ir orientar os esforos na busca pela qualidade.

18

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

2.2 Qualidade de produto de software Pode-se definir qualidade de produto de software como a conformidade a requisitos funcionais e de desempenho declarados explicitamente, padres de desenvolvimento claramente documentados e as caractersticas implcitas que so esperadas de todo software desenvolvido profissionalmente. Por necessidades explcitas, pode-se entender requisitos do usurio; necessidades implcitas relacionam-se, por exemplo, com a performance de execuo do sistema ou at mesmo com o cumprimento do cronograma e o oramento do desenvolvimento do produto. As definies de qualidade podem variar em alguns aspectos, porm o aspecto que se refere satisfao do cliente ou usurio no deve ser esquecido. A ISO, que objetiva promover o desenvolvimento de padronizao, no sentido de facilitar o intercmbio de bens e servios entre os povos, foi criada em razo da necessidade das empresas de exportarem seus produtos, por causa da chamada barreira tcnica. Os padres da ISO estabelecem especificaes tcnicas e definem caractersticas para garantir que produtos, servios ou processos sejam adequados a seus propsitos. A vantagem maior fica para o cliente que, ao adquirir um produto ou contratar um servio, tem a garantia e tambm a segurana de que o produto que est adquirindo tem padres internacionais conhecidos e familiares no mundo inteiro. A norma NBR ISO/IEC 9126-1, futura
2

A famlia de normas NBR ISO 9000:1994 (9001, 9002 e 9003) foi cancelada e substituda pela srie de normas ABNT NBR ISO 9000:2000.

19

ISO/IEC 25010 Quality Model, faz parte desse conjunto de normas ISO. Essa norma prope caractersticas que um software deve possuir, bem como subcaractersticas, para incentivar o uso na prtica dessa padronizao de qualidade de produto de software. 2.2.1 Aspectos gerais e evoluo do software Os produtos de software esto presentes nas mais diversas reas de atuao da vida cotidiana das pessoas. Algumas vezes, simplesmente so usados sem grande nfase; outras vezes, so a ferramenta de trabalho; e ainda, em outras, vidas so colocadas sob sua influncia. Algumas dessas reas so: educao, entretenimento, transporte, comunicao, sistema financeiro, meio ambiente, indstria, comrcio, medicina, pesquisa e muitas outras de igual ou maior importncia. Um pouco da histria do desenvolvimento de software relata os problemas e a busca pela qualidade dos produtos. Os sistemas de software tiveram uma evoluo muito densa e rpida. Os primeiros sistemas surgiram na dcada de 1950, e desde ento existe uma evoluo contnua. Pode-se classificlos em quatro eras, como mostra a Figura 2.1.

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

Inicialmente, nos anos 1950, a maioria dos produtos de software eram especficos, com distribuio limitada e orientados a batch, ou seja, eram executados em lotes. As excees a esse quadro eram o sistema interativo da American Airlines e o sistema em tempo real do Departamento de Defesa Americano - DoD, em funo da necessidade que esses sistemas tinham de prover informaes para possibilitar a tomada de deciso no exato momento em que determinadas situaes ocorriam.

20

Nos anos 1960 surgiu a demanda por novas aplicaes e com nveis de sofisticao maiores. Foi nesse perodo que apareceram os produtos de software multiusurios, o processamento em tempo real, o banco de dados e os pacotes de software, que so software que atendem a uma gama de usurios com necessidades semelhantes. Com toda essa demanda, era natural o surgimento de empresas de desenvolvimento de software, chamadas software-houses. Problemas comearam a partir desse momento. Quando era necessria uma adaptao em um software que fora comprado ou quando era detectada uma falha, muitas linhas de cdigo precisavam ser introduzidas, revisadas, corrigidas e testadas. O tempo envolvido nessas atividades comeou a aumentar de forma descontrolada, e sua eficcia no podia ser garantida. Todos esses fatos provocaram a chamada Crise do software e, para combat-la, foi intensificado o desenvolvimento de mtodos, ferramentas e procedimentos destinados ao desenvolvimento de software e integrados na disciplina Engenharia de software. A Engenharia de software, segundo Pressman (2002), ... uma disciplina que pode ser vista, de forma objetiva, como o estabelecimento e o uso dos princpios bsicos da engenharia, com a finalidade de desenvolver software de maneira sistemtica e econmica, resultando em um produto confivel e eficiente. Ou seja, ela uma disciplina que auxilia na melhoria da qualidade de software. Nos anos 1970, os computadores pessoais, chamados PC, tornaram-se, com seus preos acessveis, uma grande comodidade aos usurios de informtica, que comearam a comprar software em grande escala. Iniciou-se, tambm nessa dcada, o desenvolvimento de software para serem acoplados em automveis, aparelhos de microondas e outros equipamentos. Em meados dos anos 1980, novas tecnologias tomaram o lugar das convencionais. Nesse perodo, surgiu a inteligncia artificial, com os sistemas especialistas saindo dos laboratrios; despontou a da tecnologia de programao Orientada a objetos, que parecia ser um caminho para a soluo dos problemas de manuteno. Nessa dcada, surgiu a primeira grande necessidade identificada pelas exigncias do DoD. Uma das suas maiores dificuldades era adquirir software junto aos fornecedores, visto que sucessivos problemas de erros, prazo de entrega e custos variavam muito entre si. Como eram grandes projetos, com muitos recursos investidos, arriscar com um ou outro fornecedor poderia colocar em risco vrios objetivos. Para suprir essas necessidades, era preciso qualificar, de alguma maneira, o potencial dos fornecedores quanto aos produtos fornecidos. A partir dessa demanda, foi criado, em 1984, o SEI Software Engineering Institute, um centro de pesquisa e desenvolvimento, mantido com verbas do governo americano, instalado na Universidade de Carnegie Mellon, com a misso de prover liderana para o avano do estado da prtica da Engenharia de software, melhorando a qualidade dos sistemas que dependem de software. Apesar de todos os esforos, muitos problemas continuam ocorrendo. Isso acontece principalmente por causa de alguns aspectos bastante conhecidos pelas organizaes:

21

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

22

2.2.2 Software e suas caractersticas como produto Existem diferenas importantes entre produtos de software e produtos manufaturados que no podem deixar de ser notadas. As caractersticas inerentes essncia do software e diferenas em relao aos produtos manufaturados so (CAPOVILLA, 1999): Complexidade: normalmente, um produto de software tem muitas regras a serem cumpridas; muitas linhas de cdigo a serem implementadas; e, frequentemente, diversos desenvolvedores envolvidos, que no s tm ideias diferentes, e algumas vezes divergentes, mas que podem levar mesma soluo; Invisibilidade e intangibilidade: o software invisvel para o usurio. O que se v so as consequncias da execuo do software, diferentemente de um produto manufaturado. Os prprios desenvolvedores necessitam utilizar modelos para representar o sistema de software. Essa intangibilidade causa grandes dificuldades de comunicao, tanto entre os elementos da equipe de desenvolvimento como entre a equipe e o cliente, podendo acarretar problemas no produto de software; Conformidade e modificabilidade: o software a interface entre diversas entidades do meio no qual ser utilizado: equipamentos, outros produtos de software, usurios e cultura organizacional, entre outras. Sendo o componente mais malevel e adaptvel do sistema, frequentes adaptaes so realizadas no software, para adequ-lo a essas entidades; Produo sob medida: para software no existe produo em srie, cada usurio um cliente, que usa o software sua maneira, com nfase em partes diferentes; No se desgasta com o uso: em software os componentes lgicos so durveis. A falha de software resulta de erros de projeto ou de implementao, e os defeitos permanecem no sistema at serem percebidos devido ocorrncia de um erro quando uma determinada entrada acontece. Os defeitos de projeto e fabricao provocam um grande nmero de falhas logo no incio, mas depois se comportam de maneira estvel at sua obsolescncia. O no desgaste diferencia o software da quase totalidade dos produtos modernos. Apenas a msica e o cinema, por exemplo, aproximam-se do software sob esse aspecto. No tem prazo de validade: o software no sensvel a problemas ambientais e nem sofre qualquer tipo de defeito devido a efeito cumulativo de seu uso. O software se torna obsoleto devido evoluo do hardware e, consequentemente, da tecnologia. Empresas produtoras de software proprietrio, com uma base grande de usurios costumam planejar a obsolescncia de seus produtos, para aumentarem as suas vendas. O custo final do software basicamente o custo do projeto e do desenvolvimento: cpias do software podem ser reproduzidas em segundos e distribudas a vrios clientes, com o custo unitrio do projeto e do desenvolvimento.

23

Software o nico produto que, quando apresenta erro, o cliente paga para corrigir: no caso de uma nova verso licenciada, esta pode ter apenas os erros corrigidos.

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

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

Empresas que adotam mtodos de deteco/remoo de defeitos Inspees formais Revises estruturadas Testes de aceitao Testes de sistema Testes de unidade Validao 45 / 10% ... 212 / 48% 277 / 62% 105 / 24% ... 100 / 17% 113 / 19% 278 / 47% 392 / 67% 137 / 23% 250 / 42% 87 / 20% 66 / 16% 205 / 48% 199 / 47% 130 / 31% 192 / 45%

24

Empresas que adotam outras prticas de Engenharia de Software Gesto de mudana Mtodos estruturados Mtodos orientados a objetos Projetos interface com o usurio ... ... 193 / 43% ... 32 / 5% 210 / 36% 216 / 37% 207 / 35% 31 / 7% 146 / 34% 186 / 44% 215 / 51%

Observao: O smbolo ... indica dado indisponvel.

Infelizmente, a realidade das empresas, tanto as mundiais como as nacionais, est distante do ideal. A realidade das empresas de software do pas, sendo 36% do tipo microempresa e 33% do tipo pequena empresa, segundo a fora de trabalho, com equipe e faturamento reduzidos, explica uma situao e indica a necessidade que as empresas tm de receber auxlio externo para superar seus altos ndices de desconhecimento e capacidade de aplicao dessas normas e modelos. Apesar de todos os esforos da Engenharia de software, os problemas de qualidade nos produtos persistem. Na prxima seo sero analisadas outras iniciativas que vm sendo realizadas na busca pela qualidade do produto software. 2.2.3 Iniciativas para a qualidade de produto de software Diante do que foi apresentado nas sees anteriores, o produto de software, h algum tempo, necessita e busca solues para a melhoria na sua qualidade tanto em funo de seu grau de importncia e integrao na sociedade quanto pelas falhas frequentes e com possibilidade de consequncias desastrosas. Tudo isso sem deixar de mencionar, tambm, o alto custo e elevado tempo de desenvolvimento e manuteno. Qualidade de software pode ser vista, e definida nas normas relacionadas a essa rea, como um conjunto de caractersticas que devem ser alcanadas em um determinado grau, para que o produto atenda s necessidades de seu usurio, cuja participao fundamental no processo. por meio desse conjunto de caractersticas que a qualidade de um produto de software pode ser descrita e avaliada. Analisando essa afirmao, percebe-se a necessidade de respostas para algumas questes bsicas sobre como atingir a qualidade num produto de software a ser desenvolvido: A determinao do conjunto de caractersticas que atende s necessidades de seus usurios. A forma de avaliar se tais caractersticas foram alcanadas num grau que satisfaa seus usurios.

Diversas iniciativas surgiram para buscar as respostas a essas questes. De acordo com o livro Qualidade de Software Teoria e Prtica (ROCHA, 2001), diversos modelos foram desenvolvidos, detalhando as caractersticas de qualidade de um produto de software em subcaractersticas, e estas em

25

atributos. Alguns desses trabalhos so encontrados nos livros: Factors in software quality (1977) de McCALL, Characteristics of software quality (1978) de B. Boehm e Cornering the chimera (1996) de R. G. Dromey. O Subcomit de Software SC7 do Comit Tcnico Conjunto JTC1 da ISO e IEC vm trabalhando desde a dcada de 1990, na elaborao de normas e relatrios tcnicos que permitam especificar e avaliar a qualidade de produtos de software, consolidando as diferentes vises de qualidade. Para auxiliar no processo de avaliao da qualidade de produtos de software, a ISO e a IEC estabeleceram o 3 seguinte conjunto de normas na srie 14598 , que j foram publicadas pela ABNT, com os seguintes assuntos: Viso geral do processo de avaliao; Processo de avaliao para desenvolvedores; Processo para adquirentes; Processo para avaliadores; Planejamento e gesto do processo; Documentao de mdulos de avaliao.

A norma brasileira NBR ISO/IEC 9126-1 uma traduo da norma ISO/IEC 9126-1, contendo modelo de qualidade com as caractersticas e subcaractersticas de um produto de software. Atualmente, a srie de normas ISO/IEC 25000, que trata da definio da qualidade de produto de software, composta por um conjunto de documentos contendo abordagens sobre o modelo de qualidade, medidas externas, medidas internas e medidas da qualidade em uso. O assunto ser tratado com detalhes no captulo 4. Para se obter um produto de software de qualidade, preciso verificar seu processo de desenvolvimento e tambm as caractersticas do produto em produo. Na prxima seo, sero abordados aspectos gerais de um processo de software, iniciativas e modelos para sua qualidade. Weber cita, em Qualidade e Produtividade em Software, publicado em 2001, que a base para o reconhecimento da qualidade do software brasileiro e a chave para alcanar crescentes nveis de competitividade nas empresas brasileiras de software encontram-se: na adoo da norma ISO 9001 e do CMMI como modelos complementares para a melhoria dos processos de software;

Atualmente em reviso na srie 25000.

26

na adoo da srie ISO/IEC 9126, srie ISO/IEC 14598 e ISO/IEC 12119 para avaliao dos produtos de software.

Essas abordagens podem ser adotadas separadamente ou em conjunto, como foi tratado, por exemplo, na proposta para qualidade de software com a aplicao integrada de modelo de capacidade de processo e norma de produto, em Santana (2002). Procurou-se analisar atividades, metas e produtos de trabalho das reas de processo, verificando instncias em que as definies, diretrizes e caractersticas de qualidade de produto de software, possam ser utilizadas. Tambm essas abordagens podem ser escolhidas em conformidade com os objetivos de negcio das empresas e da capacitao de seu pessoal.

2.3 Qualidade de processo de software O motivador deste assunto a busca pela qualidade de software, ou seja, qualidade tanto do produto como do processo de software. A ideia atual de que se deve atuar na qualidade do processo, para se atingir a qualidade do produto de software, no pode ser vista isoladamente, mas em composio com outras abordagens. Processo de software est definido como um conjunto de atividades, mtodos, prticas e transformaes que as pessoas empregam para desenvolver e manter software e os produtos associados. Especificao de requisitos, gerncia de configurao, desenvolvimento de software so exemplos de processos que podem ser formalizados e documentados para desenvolver um produto. A Figura 2.2 representa a definio de processo de software.

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

27

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

2.3.1 Aspectos gerais A flexibilidade na adaptao e definio de processos equilibrada assegurando a consistncia apropriada dos processos em cada organizao. Essa flexibilidade necessria para tratar as variveis de contexto, por exemplo: domnio de atuao, tipo de cliente, limitaes de custo, cronograma e qualidade, dificuldades tcnicas do trabalho e experincia das pessoas que esto implementando o processo. Os padres dentro da organizao tm que atingir padres organizacionais, objetivos e estratgias que sejam apropriadamente tratados, alm de dados e lies aprendidas dos processos, para que possam ser compartilhados. Essa afirmao relaciona processo a aes e acontecimentos realizados por pessoas, para o desenvolvimento e para a manuteno tanto do software como de outros produtos associados a ele, por exemplo: os manuais de usurio. Tanto o produto de software como o produto manufaturado tm como requisito, para um processo de qualidade, a necessidade de ser uma atividade sistemtica e passvel de repetio, independentemente de quem a execute. A Figura 2.3 mostra a situao de muitas organizaes de software. Existe um grande acmulo de trabalho, que acarreta o abandono de planos e procedimentos, quando estes esto definidos. As consequncias so produtos de software que, s vezes, funcionam, mas os prazos e custos so frequentemente maiores do que os previstos.

28

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

As organizaes percebem a situao catica, mas encontram dificuldades em mudar esse quadro em funo de uma srie de fatores, dentre os quais: As organizaes esto reagindo a crises constantes; A ausncia de guias, da mesma forma que existe nas demais engenharias, de mtodos testados e comprovados sobre como desenvolver e fazer manuteno de software. Boas prticas esto sendo utilizadas, mas so pouco disseminadas; A maioria dos problemas nas organizaes de software de natureza gerencial, e no tcnica. A tecnologia e a capacitao dos profissionais que essas organizaes j possuem, poderiam gerar melhor qualidade; A alta velocidade de mudanas tecnolgicas envolvidas, como o prprio hardware; O baixo estmulo participao do usurio no processo de software, o que conduz a uma especificao incompleta de suas necessidades; A crescente demanda por novos processos de automao e pela manuteno dos j desenvolvidos acarreta problemas, como mostrado na Figura 2.3;

29

A falta de conhecimento sobre como mudar essa realidade e a dificuldade em aplicar os princpios da qualidade ao software.

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

5 Esta norma foi cancelada, e ainda no possui substituio na ABNT. Na ISO existe a ISO/IEC 90003:2004 Software engineering -- Guidelines for the application of ISO 9001:2000 to computer software.

30

NBR ISO/IEC 15504 sobre avaliao de processo de software, em que um modelo para avaliao descrito na norma ISO/IEC 15504-5, e um modelo-referncia de processo apresentado na norma ISO/IEC 15504-2; CMMI (CHRISSIS, 2003) desenvolvido nos EUA, substituiu o CMM; TRILLIUM modelo desenvolvido no Canad, pela Bell Canada (UHCL, 2007), em parceria com a Bell Northern Research e Northern Telecom, com o objetivo de avaliar o desenvolvimento de produtos e a capacidade de produo de fornecedores de produtos para telecomunicaes. Pode ser usado tambm para melhoria de processos de desenvolvimento de software, e inclui orientaes para sua implementao e referncias cruzadas com outros modelos, como o CMM, no qual foi baseado o documento de descrio do Trillium. MPS modelo de processo do software, baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro (www.softex.br).

No Brasil, desde 2003, existe um modelo de referncia para melhoria de processo de software denominado MPS, o qual, entre outros propsitos, prope-se a aumentar a competitividade da indstria brasileira de software, por meio de programas de qualificao de profissionais na rea e de melhoria e avaliao de processos e produtos de software. Apenas a srie de normas NBR ISO/IEC 15504, o modelo CMMI e o MPS tero um breve resumo, a seguir. A melhoria da qualidade de processo de software deve ser o dia a dia de uma organizao de software. Com o sucesso dessa empreitada, a previso para o incio da prxima dcada um esforo concentrado na reduo substancial dos prazos para a entrega de produtos pelas organizaes e a exportao do software brasileiro. A presso dos concorrentes ser intensa. Organizaes que forem capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento e manuteno de software tero a primazia do mercado.

2.3.2.1 NBR ISO/IEC 15504

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

31

NBR ISO/IEC 15504-5 - Exemplo de modelo de avaliao.

Observao: As futuras normas NBR ISO/IEC 15504-6 Tecnologia da informao - Avaliao de processo Parte 6: Exemplo de modelo de avaliao de processo de ciclo de vida de sistema e NBR ISO/IEC 15504-7 - Tecnologia da informao - Avaliao de processo Parte 7: Avaliao de Maturidade Organizacional esto em estudo na ABNT. O modelo da norma NBR ISO/IEC 15504 possui uma arquitetura denominada contnua, com duas dimenses: 1-dimenso de processos, na qual so definidos processos com as melhores prticas especficas de cada um; esses processos so definidos por nome, propsito, objetivos, resultados esperados, prticas e artefatos. 2- dimenso de capacidade de processo, em que so definidos os nveis de capacidade genricos. Em cada nvel de capacidade, os processos podem estar em diferentes nveis de maturidade. O conjunto de reas de processo, com um nvel de capacidade para cada processo, compe um sistema. A dimenso de capacidade de processo composta por seis nveis sequenciais e cumulativos. Cada nvel de capacidade descrito na norma NBR ISO/IEC 15504, conforme apresentado a seguir: Nvel 0 Incompleto: os produtos de trabalho ou os resultados dos processos so dificilmente identificados ou no so produzidos adequadamente. O propsito do processo no satisfeito ou no implementado. Nvel 1 Executado: o propsito do processo normalmente atingido, embora isso no tenha, necessariamente, sido planejado e acompanhado rigorosamente. Existe uma conscincia geral e informal de que uma ao deve ser executada e quando isso deve acontecer. As pessoas da organizao reconhecem que aes devem ser executadas. Os produtos de trabalho so gerados, e existem evidncias do propsito do processo. Nvel 2 Gerenciado: a execuo do processo planejada e acompanhada; os produtos de trabalho so gerados conforme os procedimentos e requisitos especificados. A principal distino em relao ao nvel Executado que a execuo do processo planejada e gerenciada, e os produtos de trabalho satisfazem os requisitos de qualidade especificados, os prazos e recursos necessrios. Nvel 3 Estabelecido: o processo executado e gerenciado com base em um processo-padro da organizao, baseado em princpios da Engenharia de software. As prticas bsicas so executadas utilizando-se uma verso adaptada e aprovada de um processo-padro documentado. A principal distino deste nvel relativamente ao nvel Gerenciado que o processo utiliza um processo-padro capaz de satisfazer os resultados definidos. Nvel 4 Previsvel: neste nvel o processo executado dentro de limites de controle definidos, de forma consistente, para atingir os objetivos. A execuo gerenciada quantitativamente. Medies

32

detalhadas de desempenho so coletadas e analisadas, levando a um entendimento quantitativo da capacidade do processo. A principal distino deste nvel em relao ao nvel Estabelecido que o processo passa a ser executado consistentemente, dentro de limites definidos, para atingir seus resultados. Nvel 5 Em Otimizao: so estabelecidas metas de eficcia e eficincia para o desempenho do processo, baseadas nos objetivos de negcio da organizao. Melhorias contnuas so implementadas para satisfazer os objetivos de negcio, requerendo experincias de ideias e novas tecnologias para satisfazer objetivos e metas definidos. A principal distino deste nvel relativamente ao nvel Previsvel que o processo padro e o processo definido e padro passa a ser alterado e adaptado, para atingir os objetivos de negcio da organizao. A capacidade de um processo definida em uma escala ordinria de seis pontos, que permite a avaliao da capacidade desde o fundo da escala (Incompleto) at seu extremo (em otimizao).

A medida da capacidade dos processos est baseada em um conjunto de Atributos de Processos (PA Process Attributes), os quais so utilizados para determinar se um processo atingiu uma dada capacidade. Com exceo do Nvel 0, que no possui atributos de processo, todos os demais possuem. Os nveis de capacidade e seus atributos de processo esto apresentados na Tabela 2.2.
Tabela 2.2 Nveis de capacidade e atributos de processo Nvel 0 Nvel 1 Nvel 2 Processo Incompleto (no possui atributos) Processo Executado PA 1.1: Atributo de Execuo de Processo Processo Gerenciado PA 2.1: Atributo de Gerncia de Execuo PA 2.2: Atributo de Gerncia de Produto de Trabalho Processo Estabelecido PA 3.1: Atributo de Definio de Processo PA 3.2: Atributo de Implementao de Processo Processo Previsvel PA 4.1: Atributo de Medio de Processo PA 4.2: Atributo de Controle de Processo Processo em Otimizao PA 5.1: Atributo de Inovao de Processo PA 5.2: Atributo de Otimizao de Processo

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

N Not adequate (no atingido): o atributo no foi satisfeito pelo processo. P Partially adequate (parcialmente): o atributo foi parcialmente satisfeito pelo processo. L Largely adequate (largamente): o atributo foi amplamente satisfeito pelo processo. F Fully adequate (completamente): o atributo foi completamente satisfeito.

A srie NBR ISO/IEC 15504 vem sendo aplicada com resultados proveitosos para as organizaes que a utilizaram para avaliao e melhoria dos seus processos. A relao dessa norma com os modelos de processo pode ser verificada na Figura 2.4, em que est representada sua paridade com as demais normas e sua predominncia em relao aos modelos, que devem ser compatveis com os requisitos dessa norma.

Figura 2.4 Relao da norma NBR ISO/IEC 15504 com os modelos de processo.

A avaliao e a melhoria dos processos fundamentais so orientadas pelos objetivos de negcio da organizao e envolvem o planejar, gerenciar, executar, controlar e melhorar os aspectos de software quanto a adquirir, fornecer, desenvolver, operar, efetuar manuteno e fornecer suporte. O modelo de referncia da srie NBR ISO/IEC 15504 estabelece um conjunto universal de 40 processos fundamentais para a Engenharia de software, divididos em categorias, conforme mostra a, e um roteiro racional para a determinao da capacidade, por meio de uma avaliao, e tambm para a melhoria de cada processo.
Tabela 2.3 Categorias e processos da srie NBR ISO/IEC 15504 (WEBER, 2001) Categorias Cliente-fornecedor Siglas CUS.1 CUS.1.1 Processos fundamentais Aquisio Preparao da aquisio

34

Engenharia

Gerncia

Organizao

Suporte

CUS.1.2 CUS.1.3 CUS.1.4 CUS.2 CUS.3 CUS.4 CUS.4.1 CUS.4.2 ENG.1 ENG.1.1 ENG.1.2 ENG.1.3 ENG.1.4 ENG.1.5 ENG.1.6 ENG.1.7 ENG.2 MAN.1 MAN.2 MAN.3 MAN.4 ORG.1 ORG.2 ORG.2.1 ORG.2.2 ORG.2.3 ORG.3 ORG.4 ORG.5 ORG.6 SUP.1 SUP.2 SUP.3 SUP.4 SUP.5 SUP.6 SUP.7 SUP.8

Seleo de fornecedor Acompanhamento do fornecimento Aceitao pelo cliente Fornecimento Elicitao de requisitos Operao Uso operacional Suporte ao cliente Desenvolvimento Anlise de requisitos e projeto de sistema Anlise de requisitos de software Projeto de software Construo de software Integrao de software Teste de software Integrao e teste de sistema Manuteno de sistema e software Gerncia Gerncia de projeto Gerncia da qualidade Gerncia de riscos Alinhamento organizacional Melhoria Estabelecimento do processo Avaliao de processo Melhoria de processo Gerncia de recursos humanos Infraestrutura Medio Reso Documentao Gerncia de configurao Garantia da qualidade Verificao Validao Revises conjuntas Auditorias Resoluo de problema

2.3.2.2 Modelo CMMI

Numa deciso entre amadurecer a verso do modelo CMM ou idealizar outro modelo adaptado, o SEI publicou, em 2001, o CMMI Capability Maturity Model Integration, modelo que visou harmonizar alguns componentes da famlia CMM e da srie ISO/IEC 15504, que so:

35

SW-CMM ou CMM (Capability Maturity Model for Software) Descreve os elementos importantes de um processo de desenvolvimento de software para melhoria contnua nas empresas. SE-CMM (Systems Engineering Capability Maturity Model) Descreve os elementos essenciais dos processos de uma organizao, que devem existir para garantir uma boa prtica de Engenharia de Sistemas. IPD-CMM (Integrated Product Development) Prov um guia sistemtico para o desenvolvimento de produtos ao longo do ciclo de vida, para melhor satisfazer as necessidades dos clientes.

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

novembro

de

2007,

em

fevereiro

de

2009,

em

Com o modelo CMMI, a organizao pode promover a melhoria do processo de software, por meio do aprimoramento da capacidade dos processos ou da maturidade da organizao. O CMMI suporta essas duas abordagens por meio, respectivamente, das representaes contnua, da mesma forma que a norma ISO/IEC 15504, e por estgio, da mesma forma que o modelo CMM. A representao por estgio classifica a organizao em cinco nveis de maturidade quanto ao seu processo de software, ao passo que a representao contnua classifica os processos, e no a organizao, em seis nveis de capacidade, a saber: 0 Incompleto 1 Realizado 2 Gerenciado 3 Definido 4 Gerenciado quantitativamente

36

5 Otimizando (sempre em otimizao)

As principais diferenas entre os modelos CMM e CMMI so: O CMM estabelece 18 reas-chave de processo, ou KPA Key Process Areas (reas chave), e a representao por estgio. O CMMI estabelece 22 reas de processo, ou PA Process Areas (reas de processo), que so classificadas em quatro categorias, listadas na Tabela 2.4.

Tabela 2.4 Categorias e reas de processo do modelo CMMI Categorias 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

Gerenciamento de processo

Gerenciamento de projeto

Engenharia

Suporte

A principal contribuio do modelo CMMI e da norma ISO/IEC 15504 a liberdade que se adquire, com a representao contnua, de escolher quais processos devem ser trabalhados naquele momento, respeitando as necessidades prioritrias e particularidades existentes em cada organizao.

37

2.3.2.3 Programa MPS.BR

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

O Guia Geral tem como base as normas ISO/IEC 12207:2008 e ISO/IEC 15504, e como complemento o Modelo CMMI. O MR-MPS define sete nveis de maturidade: A (Em Otimizao) B (Gerenciado Quantitativamente) C (Definido) D (Largamente Definido)

38

E (Parcialmente Definido) F (Gerenciado) G (Parcialmente Gerenciado) Esses nveis com menor contedo de implementao do ao modelo maior facilidade para as empresas que desejam melhorar seus processos. A escala de maturidade se inicia no nvel G e progride at o nvel A. Para cada um desses sete nveis de maturidade atribudo um perfil de processos os quais indicam em que lugar a organizao deve colocar o esforo para melhoria. Obtm-se o progresso e o alcance de um determinado nvel de maturidade MPS, quando so atendidos os propsitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nvel. Esse material pblico, e a ele tm acesso todas as pessoas interessadas no assunto. A motivao da Softex foi a de incluir, agregar valor ao processo das empresas, pois as empresas brasileiras, depois dessa iniciativa, ainda esto sendo impedidas de aderir aos padres internacionais, em funo dos altos custos praticados. Uma empresa avaliada MPS tem maiores possibilidades de obter o nvel CMMI correspondente. O modelo MPS possui um maior nmero de nveis, o que contribui para implementaes mais rpidas, avaliaes com menor periodicidade, resultados em menores prazos e de modo incremental, e custos mais baixos. A avaliao MPS tem validade de trs anos, o que garante segurana adicional a quem compra software, pois a empresa tem de se manter atenta qualidade; caso contrrio, perde o nvel de maturidade que havia conseguido. Os custos da adeso ao modelo MPS so mais baixos e ainda podem ser parcialmente subsidiados. Esse modelo est desenvolvendo no somente as empresas, mas tambm o capital humano, formando implementadores e avaliadores, ministrando cursos com provas de capacitao, o que aumenta o nvel das discusses sobre Engenharia de software no pas. Os resultados desse programa esto muito acima do esperado, como pode ser visto em Resultados de desempenho de organizaes que adotaram o modelo MPS cujos autores Guilherme H. Travassos e Marcos Kalinowski em 2008 (www.softex.br) relatam nesse documento. 2.3.3 Comparao entre os modelos Quanto abordagem da qualidade de software, considerando os processos de software, isto , processos de produzir software, existem normas e modelos para definio, avaliao e melhoria de processos de software. A srie NBR ISO/IEC 15504 trata da avaliao de processos de software. O modelo CMMI Capability Maturity Model Integration, desenvolvido nos Estados Unidos, define um modelo de maturidade para empresas desenvolvedoras de software e possui seu prprio mtodo de avaliao Standard CMMI Appraisal Method for Process Improvement SCAMPI. A norma NBR ISO/IEC 12207 define processos do ciclo de vida de software.

39

O modelo MPS, assim como o Capability Maturity Model Integration, possui seu prprio mtodo de avaliao: MA-MPS Mtodo de Avaliao para Melhoria do Processo de Software. O guia de avaliao descreve o processo e o mtodo de avaliao MA-MPS, com base na norma internacional ISO/IEC 15504-2: 2003. Esses modelos disponibilizam os materiais para utilizao dos interessados e propem a avaliao da capacidade e maturidade de uma organizao, alm de indicarem diretrizes para a melhoria. As organizaes de software so enquadradas em nveis de maturidade definidos pelos modelos. A norma NBR ISO/IEC 12207 estabelece processos, atividades e tarefas a serem aplicados durante a aquisio, o fornecimento, o desenvolvimento, a operao e a manuteno de software. Ela apresenta uma definio abrangente em relao aos processos e orienta a adaptao para sua utilizao nos projetos de software implementados em uma organizao.
Tabela 2.5 Comparao entre os modelos para processo de software Aspectos abordados NBR ISO/IEC 12207 CMMI NBR ISO/IEC 15504 MPS

Estabelecer uma terminologia e Determinar a capacitao da Conhecer e avaliar os Melhorar os processos de software um entendimento comum para organizao e apoiar sua processos da organizao, nas micro, pequenas e mdias Objetivo os processos entre todos os evoluo de acordo com os determinar a capacitao e empresas (PMEs), a um custo envolvidos com software nveis estabelecidos promover a melhoria acessvel, em diversos locais do pas Definio dos processos para Avaliao dos processos e Avaliao dos processos aquisio, fornecimento, enquadramento da Avaliao dos processos da Abordagem da organizao em relao desenvolvimento, operao e organizao em um dos organizao e a nveis de capacitao manuteno de software nveis de maturidade Organizaes que Organizaes-alvo Organizaes em geral necessitam de comprovao Organizaes em geral Organizaes em geral formal de sua capacidade Estabelece 22 reas de Estabelece 43 processos, Estabelece 35 processos, Estabelece 22 processos, Definio de processos, organizados em 5 organizados em 7 reas de organizados em 5 organizados em 7 nveis crescentes processos nveis crescentes de processo categorias de maturidade maturidade Nveis com menor contedo de Nveis e reas-chave de Permite a definio de Flexibilidade nos Classificao de processos pode implementao para facilitaras processo so a base do perfis de processo e aspectos definidos ser utilizada conforme os empresas e motivar a adeso ao modelo e no podem ser prticas de acordo com os pelo modelo objetivos da organizao modelo para as empresas que alterados objetivos da organizao desejam melhorar seus processos

A srie NBR ISO/IEC 15504 pode ser utilizada por organizaes envolvidas em planejar, gerenciar, monitorar, controlar e melhorar a aquisio, o fornecimento, o desenvolvimento, a operao, a evoluo e o suporte de software. Uma anlise comparativa desses modelos e normas apresentada na Tabela 2.5. Essa anlise considera o objetivo de cada modelo e norma, o resumo de suas abordagens, o tipo de organizao a

40

que melhor se adaptam os processos de software considerados e a flexibilidade de aplicao de cada modelo e norma. O foco em qualidade de produto de software reporta-se ao prximo captulo, que trata das categorias de produtos de software mais conhecidas, que ajudam na especificao e na avaliao da qualidade do software.

41

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

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

42

Software cientfico e de engenharia so caracterizados por algoritmos de processamento numrico. So exemplos: sistemas de astronomia, controle da dinmica orbital de naves espaciais, sistemas de manufatura automatizada. Software embarcado produto usado para controlar outros produtos e sistemas, no podendo ser tratado ou utilizado separadamente. Caracteriza-se por utilizar uma memria de leitura e usar rotinas limitadas e particulares, sendo responsvel por toda a inteligncia instalada em alguns equipamentos. So exemplos: controle de teclados em microondas, controle de sistemas digitais em automveis, como painel de controle de combustvel ou sistemas de freio. Software de computador pessoal so os programas de software utilizados em computadores de uso pessoal. Exemplos: editores de texto, planilhas eletrnicas, gerenciamento de dados, acesso a banco de dados, entre outros. Software de inteligncia artificial utilizado para uso de algoritmos no numricos, para resolver problemas complexos. Outra questo interessante da Inteligncia artificial so os sistemas baseados no conhecimento e tambm os sistemas de reconhecimento de padres, tais como imagem ou voz. So exemplos: sistemas com entrada pelo reconhecimento de voz do usurio, sistemas de reconhecimento de imagens, como: digitais, foto, entre outras.

Nos termos dessas caractersticas, considera-se que os produtos tratados neste livro so os que Pressman chamou de software comercial, o software desenvolvido por uma empresa com o objetivo de lucrar com sua utilizao.

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

43

CUSTOMIZADO ou FD (Fully Developed Software). Neste tipo, o software totalmente desenvolvido para o cliente. H necessidade de projeto, especificao de requisitos, entre outras etapas do ciclo de vida de um software. Evidentemente, o produto que precisa de mais tempo para ser desenvolvido, sendo o mais complexo em termos de aquisio, controle e aceitao pelo cliente.
Tabela 3.1 Caractersticas de produtos de software segundo a IEEE 1062 Caractersticas Escopo Adequao ao uso Manuteno Prazo de entrega Custo de aquisio Qualidade (ISO/IEC 9126-1)
[1] Parcialmente ou

COTS Fixo Demonstrado Sem controle Imediato Baixo mdio No controlada

MOTS Parcialmente customizado Demonstrado em aplicaes similares Controle parcial Pequeno grande Mdio alto Parcialmente controlada

CUSTOMIZADO ou FD[1] Totalmente customizado Sem precedentes Controle total Grande Alto Controlada em sua maior parte

completamente terceirizado

Cada um desses grupos, como descrito na Tabela 3.1, tem as caractersticas de qualidade bem determinadas. Assim, um produto chamado COTS pode ter um modelo de qualidade e ser avaliado segundo os critrios genricos baseados nas normas. Esse modelo de qualidade e o mtodo de avaliao sero descritos nos prximos captulos e podem ser utilizados em processos de aquisio de software. Um aspecto do uso de software que ilustra a diferena entre COTS e MOTS a necessidade do MOTS de estar em constante manuteno ou evoluo. Toda falha de software indica um erro no projeto ou no processo por meio do qual o projeto foi traduzido em cdigo executvel. Portanto, a manuteno ou a evoluo do software envolve consideravelmente mais complexidade do que a manuteno pura e simples. Sendo assim, esse tipo de produto pode tambm ser avaliado segundo os critrios de manutenibilidade apresentados nas normas. Para o software desenvolvido especificamente para um cliente, como o caso dos FDs, existe a necessidade de montar seu modelo de qualidade, para desenvolver o produto e avaliar seu desempenho segundo as caractersticas de qualidade tratadas nas normas, juntamente com todas as caractersticas especficas da aplicao e do domnio ao qual pertence.

3.3 Categorias para prmios de software Numa aplicao prtica, tratando-se de software comercial do tipo COTS, pode ser mencionado o exemplo do PRMIO ASSESPRO (ROCHA, 2001), que foi realizado em nvel nacional, de 1990 a 1999,

44

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

45

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

46

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

47

NBR ISO/IEC 9126-1, 2003; NBR ISO/IEC 25051, 2008 e A srie de normas NBR ISO/IEC 14598.

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

O MEDE-PROS foi concebido com a NBR ISO/IEC 12119, e sua ltima verso de 2006.

48

A descrio do produto um documento expondo as propriedades do software, com o objetivo de auxiliar potenciais compradores na avaliao de adequao, antes da aquisio. A documentao do usurio o conjunto completo de documentos. Est disponvel ao usurio na forma impressa ou no, sendo fornecida para auxiliar na utilizao dos produtos de software. A interface permite que as informaes sejam transferidas entre o usurio e os componentes de hardware ou software de um sistema computacional. O software propriamente dito so as instrues (programas de computador) que, quando executadas pelo usurio, produzem a funo e o resultado esperados.

A Figura 3.1 mostra a estrutura bsica de uma lista de verificao e onde as normas de qualidade contriburam para sua construo, permitindo que os elementos dos produtos de software considerados pudessem ser avaliados adequadamente. Cada um desses componentes se subdivide pelas caractersticas de qualidade, pelas subcaractersticas, pelos atributos, at que se obtenham questes objetivas.

Figura 3.1 Estrutura da lista de verificao de um mtodo de avaliao (MEDE-PROS)

A srie de normas NBR ISO/IEC 14598 no aparece na figura porque ela fornece orientaes para a realizao do processo de avaliao, e esse processo ser apresentado posteriormente, em um captulo dedicado exclusivamente ao assunto. Como a avaliao do produto de software se baseia na

49

comparao do produto com alguns requisitos, ou ainda com necessidades explcitas e implcitas dos usurios, o trabalho realizado durante a elaborao de um mtodo o de transformar o modelo de qualidade, presente nas normas, em atributos; e os atributos, em um conjunto de questes, de tal forma que, avaliando o atributo por meio do conjunto de questes associadas, seja possvel julgar o atendimento ou no atendimento do atributo. 2- O Manual do Avaliador deve conter um conjunto de informaes para a utilizao da lista de verificao, durante a avaliao da qualidade de um produto de software, e fornecer diretrizes e recomendaes para a execuo do processo de avaliao. Nesse manual so encontrados: explicaes e exemplos de alguns atributos presentes na lista de verificao, para uma melhor compreenso do aspecto a ser avaliado; as convenes utilizadas na lista de verificao; as diretrizes para a execuo da avaliao; regras e obrigaes dos avaliadores se for o caso de uma avaliao profissional; informaes sobre o preenchimento da lista de verificao; o material utilizado na avaliao; o procedimento da avaliao, com sugesto de uma sequncia de passos adequada ao processo; orientaes para a elaborao do relatrio de avaliao e um glossrio contendo explicaes dos termos utilizados na lista de verificao. 3- Para apresentar o resultado obtido durante o processo da avaliao, pode existir um terceiro componente o modelo de relatrio da avaliao (Apndice C). O relatrio da avaliao nada mais do que um laudo tcnico sobre a qualidade do produto de software avaliado, do ponto de vista de um usurio final. Ele apresenta o resultado da avaliao, de acordo com a especificao estabelecida entre o solicitante e o responsvel pela avaliao. Esse relatrio destaca os aspectos do produto de software que atendem as normas de qualidade de software e os aspectos a serem revistos, originados das no conformidades encontradas durante a avaliao. Um conjunto de sugestes fornecido, no final desse relatrio, ao solicitante da avaliao, visando adequao do produto s normas de qualidade de software, aos requisitos especificados e consequente melhoria do produto de software a ser fornecido ao mercado. Alm das informaes sobre a qualidade do produto de software avaliado, outras informaes podem ser apresentadas no incio do relatrio, com o objetivo de fornecer ao solicitante da avaliao uma viso genrica do processo realizado, tais como: o escopo da avaliao, que foi definido durante a fase de Especificao da avaliao, como recomendado pela norma NBR ISO/IEC 14598-5; a base terica utilizada, ou seja, as normas de modelo de qualidade de produto de software; o processo de avaliao, executado de acordo com as fases recomendadas pela norma NBR ISO/IEC 14598-5 Anlise de requisitos da avaliao, especificao da avaliao, projeto da avaliao, execuo da avaliao e concluso da avaliao; os elementos do produto de software que foram avaliados;

50

a quantidade de horas e de avaliadores envolvidos no processo; o ambiente computacional utilizado na realizao da avaliao, comparado com o sugerido pelo solicitante. Essa metodologia seguiu a abordagem de uma lista de verificao, sendo possvel o desenvolvimento de outros tipos de metodologias para avaliar produtos de software. O importante que se preserve a repetibilidade, a reprodutibilidade, a imparcialidade e a objetividade, sendo que uma das dificuldades de uma avaliao de produto de software eliminar a subjetividade dessa avaliao. Uma prtica adotada no ciclo de evoluo do MEDE- PROS o que se denomina meta-avaliao. Consiste basicamente na comparao das avaliaes realizadas pelos pares de avaliadores, no sentido de analisar estatisticamente se as respostas da avaliao do mesmo produto so consistentes. Com essa anlise estatstica, feita uma reviso da lista de verificao, com a ajuda dos avaliadores, no sentido de torn-la mais clara e objetiva. Essa prtica se mostra til, no sentido de tornar o mtodo cada vez mais prximo das caractersticas citadas no pargrafo anterior. 3.4.2 Mtodo de avaliao especialista Segundo Rocha, 2001, sistemas especialistas so sistemas cujo objetivo a resoluo de problemas em um domnio especfico, por meio da explorao de uma base de conhecimento e de um mecanismo de raciocnio. Para sistemas especialistas ou produto de software pertencente a um domnio especfico CUSTOMIZADOS/FDs, ou seja, produtos que possuem certas caractersticas, como escopo totalmente customizvel, desenvolvido um mtodo de avaliao a partir de suas especificaes de requisitos funcionais e no-funcionais. Para elaborao de um mtodo dessa natureza, necessrio apresentar a base terica das normas de qualidade existentes para produtos de software genrico e, alm disso, contemplar toda a especificao de requisitos do software em questo. Um mtodo de avaliao chamado de especialista quando tem por objetivo avaliar um produto de software desenvolvido para uma rea de domnio especfico. Uma das atividades realizadas durante a elaborao de um mtodo de avaliao especialista consiste em entrevistas com os provveis usurios do sistema e com especialistas da rea. Essa atividade uma das mais importantes e visa verificar se o sistema a ser desenvolvido, ou aquele que j est concludo, atende as necessidades explcitas e implcitas dos usurios do sistema, de tal forma que suas expectativas sejam atingidas. Esse processo de entrevistas denomina-se explorao da base de conhecimento. Um mtodo de avaliao especialista pode ser desenvolvido para diversos fins, estando o momento adequado para sua elaborao diretamente vinculado ao objetivo da avaliao. Existem dois tipos de avaliao para o software: a avaliao realizada ao longo do processo de desenvolvimento do software,

51

em que podero ser avaliados os artefatos gerados (ou produtos intermedirios) e/ou a avaliao do produto final, sendo esta ltima a mais comum. Para a criao de um mtodo de avaliao especialista, devem ser considerados, alm das caractersticas de qualidade, os aspectos inerentes ao domnio da aplicao, as tecnologias especficas utilizadas no desenvolvimento do produto e o ambiente no qual o produto de software ser inserido. Para a criao de um mtodo de avaliao para produtos de software, seja ele genrico ou especialista, devem sempre ser considerados os requisitos funcionais e os requisitos no funcionais especificados para o desenvolvimento do produto de software. Um mtodo de avaliao especialista trata as caractersticas de qualidade de forma geral, ficando muitas vezes a cargo da experincia do avaliador a realizao de algumas avaliaes especficas, principalmente aquelas relacionadas com as funcionalidades do sistema, o que torna a avaliao bastante subjetiva, no contexto de requisitos funcionais do software. A Figura 3.2 mostra uma estrutura contendo os elementos considerados para um produto de software, as caractersticas de qualidade verificadas nesses componentes e destaca as partes a serem desenvolvidas em um mtodo de avaliao especialista, a fim de tornar uma avaliao menos subjetiva e menos dependente da experincia do avaliador. O mtodo aqui apresentado derivado do mtodo genrico; entretanto, o desenvolvimento dos detalhes da funcionalidade em todos os componentes do mtodo proveniente do domnio de aplicao.

52

Figura 3.2 Estrutura a ser desenvolvida numa avaliao especialista.

O mtodo de avaliao de software aplicativo, do tipo CUSTOMIZADO/FDs, nos diferentes domnios de aplicao, deve contar com o apoio de especialistas, seja em informtica, seja no respectivo domnio, trabalhando conjuntamente. Avaliaes de domnio especfico apresentam uma proposta para a construo de um mtodo de avaliao especialista, para produtos de software, baseado na especificao de requisitos encontrada, por exemplo, no contedo de editais. Esse tipo de mtodo visa avaliar o produto de software na sua totalidade, considerando-se tanto os requisitos funcionais como os requisitos no funcionais. Para o contexto do mtodo especialista, foram utilizados os conceitos existentes para qualidade de software presentes: 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;
7

A NBR ISO/IEC 12119 foi substituda pela NBR ISO/IEC 25051, em 2008.

53

Na experincia do projeto especfico denominado PNAFM Programa Nacional de Apoio Gesto Administrativa e Fiscal dos Municpios Brasileiros, que continha um processo de avaliao regido por um edital, em conjunto com a Lei N 8.666 (MAITINGUER, 2004). As contribuies do projeto citado abrangem a divulgao dos conceitos existentes para qualidade de software, a utilizao desses conceitos na elaborao de um edital e de um mtodo de avaliao especialista para produtos de software.

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

54

de avaliao credenciado pelo INMETRO Instituto Nacional de Metrologia, Normalizao e Qualidade Industrial, ou por outras instituies semelhantes, para emitir um certificado de qualidade de produto de software. Essa situao semelhante em outros pases; pode-se encontrar certificao de software para algum domnio especfico em que se exigem requisitos criteriosos especficos da rea, como, por exemplo, na rea aeroespacial. Algumas iniciativas para as questes de certificao de software no Brasil j esto sendo realizadas. Como exemplo, o Painel Setorial - Acompanhamento de Mercado por Agentes Externos no Programa 8 Nacional de Certificao de software e servios -, organizado pelo Inmetro em 31 de maio de 2007 . Na prtica, alguns projetos foram realizados com o intuito de impulsionar a evoluo do assunto. Assim, podem ser citadas as seguintes realizaes: O projeto SCOPE Software CertificatiOn Programme in Europe (SCOPE, 2009), como j foi citado, e o livro de Bache e Bazzana foram os que mais influenciaram na elaborao de normas na rea de qualidade de software, motivando toda a comunidade a estabelecer um padro consensual sobre a questo da qualidade de produto de software (BACHE, 1994). O Projeto SQUAD Software Quality Abroad Different regions (SQUAD, 2009), que teve uma durao de trs anos, entre 1998 e 2001, uniu-se a instituies que pesquisam e aplicam a qualidade de software na Europa e na Amrica Latina, com o objetivo de trocar experincia e divulgar o trabalho e os resultados em cada regio dos participantes. Esse projeto pde avaliar a experincia da aplicao das normas de Qualidade de Produto de Software e do Modelo CMM em casos reais. No Brasil, uma experincia de aplicao das normas de qualidade de produto de software foi realizada na avaliao de software no prmio Melhor software do ano, pelo qual o Centro de Tecnologia da Informao Renato Archer CTI/MCT e a ASSESPRO Associao das Empresas Brasileiras de Tecnologia da Informao, Software e Internet foram os responsveis. As informaes detalhadas sobre este caso prtico foram publicadas no Captulo 13 do livro Qualidade de Software Teoria e Prtica (ROCHA, 2001). Esse trabalho teve cinco edies, nos anos de 1993, 1994, 1995, 1996 e 1998, com aproximadamente um total de 180 avaliaes de produtos de software, os quais foram distribudos em seis categorias de software: Sistemas de suporte documentao e ao planejamento, Software bsico e de apoio ao desenvolvimento, Sistemas de engenharia e ferramentas grficas, Sistemas de informao especficos, Sistemas de informao integrados e Educao e entretenimento. Tal trabalho tambm propiciou o desenvolvimento e a evoluo do mtodo de avaliao da qualidade de produtos de software MEDE-PROS e tambm uma grande difuso, entre as empresas de software participantes do evento, dos conceitos e requisitos definidos nas normas de qualidade de software.

http://www.inmetro.gov.br/noticias/conteudo/programaSoftware.htm

55

Com essa experincia prtica de avaliao de produto, o assunto evoluiu para que os processos de produo de software fossem trabalhados com maior sistematizao, mostrando a interdependncia da qualidade do produto durante sua produo. A avaliao do processo de desenvolvimento de software consiste no exame dos procedimentos operacionais e gerenciais, mtodos e tcnicas utilizados nas fases de desenvolvimento de um produto de software, com o objetivo de identificar prticas que possam provocar problemas na qualidade do produto e de estabelecer novas prticas que evitem esses problemas. Procura-se avaliar como est sendo desenvolvido o software, por meio das seguintes disposies: verificao de gerenciamento de configurao e controle de verses (manutenibilidade); adequada organizao de testes e procedimentos para controle de mudanas (confiabilidade); cuidadosa e correta elaborao de testes internos, que possam auxiliar no processo de reviso das funes (funcionalidade). A avaliao do processo proporciona uma expectativa de gerao de produtos melhores; entretanto, no garante a qualidade do produto final. Os dois tipos de avaliao so necessrios e complementares e, embora distintos, com tcnicas e mtodos especficos, objetivam garantir a qualidade do produto final. As propostas de avaliao do processo de desenvolvimento e dos produtos finais e intermedirios tm o objetivo final de melhorar a qualidade do produto em uso, ou seja, o grau em que o produto pode ser usado por usurios especficos, para alcanar objetivos especificados com eficcia, eficincia e satisfao, em um contexto especfico de uso. A qualidade em uso pode ser medida por meio da operao do produto final em condies de uso normal ou simuladas, com o objetivo de verificar a existncia e o nvel das caractersticas de qualidade de um produto de software, conforme definidas na norma NBR ISO/IEC 9126-1. A avaliao do produto de software consiste no exame de um produto final resultante de um processo de desenvolvimento de software, ou de produtos resultantes de atividades de fases intermedirias desse processo. Dentre muitas razes, deve-se avaliar a qualidade do produto final para: a) identificar e entender as razes tcnicas para as deficincias e limitaes do produto, que podem manifestar-se na ocorrncia de problemas operacionais ou de manuteno; b) comparar um produto com outro, mesmo que indiretamente; c) formular um plano de ao sobre como fazer o produto de software evoluir. O processo de avaliao da qualidade de um produto de software contm os procedimentos para medies em uso, que incluem mtodos de anlise sobre artefatos estticos por exemplo, verificao da documentao do usurio e de anlise de produtos em operao na qual a avaliao obtida por meio de teste de integrao, teste de desempenho, teste de aceitao e a execuo dos programas, por exemplo.

56

Dessa forma, a qualidade de um produto de software resultante das atividades realizadas no processo de seu desenvolvimento. Avaliar a qualidade de um produto de software verificar, por meio de tcnicas e atividades operacionais, o quanto os requisitos so atendidos. Tais requisitos, de maneira geral, so a expresso das necessidades, explicitadas em termos quantitativos ou qualitativos, e tm por objetivo definir as caractersticas de um software, a fim de permitir o exame de seu atendimento. O tema tem sido tratado de forma mais especfica, motivando vrias iniciativas para o desenvolvimento de mtodos e ferramentas para sua avaliao, dentro das respectivas vises do usurio, do desenvolvedor e do comprador. consenso que tais vises so consideradas complementares tanto quanto a viso da Qualidade de Processo e Qualidade de Produto de Software. A qualidade de software deve ser avaliada durante seu processo de desenvolvimento. Em seguida, deve ser avaliado o produto gerado e, finalmente, o produto em uso, pois a qualidade do processo influencia a qualidade do produto e, da mesma forma, a qualidade do processo pode ser aprimorada a partir da medio da qualidade do produto, como mostra a Figura 3.3.

Figura 3.3 Qualidade de software durante seu desenvolvimento (Fonte:NBR ISO/IEC 9126-1)

Medidas no processo de desenvolvimento devem ser obtidas de acordo com requisitos exigidos na norma NBR ISO 9001, ou nos processos definidos no modelo CMMI, na norma NBR ISO/IEC12207, na norma NBR ISO/IEC 15504 e no modelo MPS. Medidas no produto de software podem ser classificadas como medidas internas, externas ou em uso: Medidas internas Medem atributos internos pela anlise das propriedades estticas dos produtos de software intermedirios ou preparados para entrega. Medidas internas podem ser aplicadas a um produto de software no-executvel, tais como uma especificao ou cdigo-fonte, respectivamente, durante o projeto e a codificao alguns exemplos esto descritos na norma ISO/IEC 9126-3. Exemplo: o nmero de linhas de cdigo, as medidas de complexidade e o nmero de defeitos encontrados em uma reviso, so todas medidas de qualidade interna de software executadas no prprio produto.

57

Medidas externas Medem o comportamento do sistema do qual o software uma das partes, pela realizao de teste, operao e observao do software executvel ou do sistema. Alguns exemplos dessas medidas esto descritos na norma ISO/IEC 9126-2. Esse documento define exemplos de medidas externas que se associam a atributos de qualidade e que podem ser uma referncia inicial, facilitando a tarefa de definir atributos. Medidas de qualidade em uso Medem quanto um produto atende s necessidades de usurios especificados, para que estes atinjam metas especificadas com eficcia, produtividade, segurana e satisfao, em um contexto de uso especificado. A avaliao de qualidade em uso valida a qualidade do produto de software em cenrios de uso especficos. Mostram a viso do usurio sobre qualidade, em um ambiente contendo software, e so medidas por meio dos resultados do uso do software em ambientes, e no pelas propriedades do software. Exemplos de medidas de qualidade em uso so apresentados no relatrio tcnico ISO/IEC 9126-4.

3.6 Avaliao e teste de software Durante a produo de um software, necessrio saber se o produto est de acordo com os requisitos especificados e tambm se obedece s normas sobre qualidade. Teste de software a atividade de executar um software com o objetivo de encontrar diferenas entre os resultados obtidos e os resultados esperados. O ciclo de vida clssico de um software tem as fases representadas na Figura 3.4, e uma dessas fases Teste.

58

Figura 3.4 Ciclo de vida clssico para desenvolvimento de software.

O processo de testes de software apresenta uma estruturao em etapas, atividades, artefatos, papis e responsabilidades que buscam a sistematizao dos procedimentos e controle dos projetos de testes. Existem vrios tipos de testes, entre eles: Teste de Unidade - testa os mdulos do software; Teste de Integrao - testa a integrao dos mdulos; Teste de Validao - testa a validao do produto em relao aos requisitos; Teste de Sistema - testa o sistema como um todo; Teste de Regresso - testa o sistema aps modificaes. No ser tratado em detalhes aqui, pois existem muitos autores trabalhando nesse assunto. Teste feito durante o desenvolvimento do produto. Avaliao tem outro propsito, que observar, com a viso do usurio, o quanto aquele produto de software atende suas expectativas. As atividades de teste e de avaliao de software devem ser aplicadas nos projetos de desenvolvimento de software, cada uma com sua especificidade e momento adequado. Modelos de qualidade tericos e prticos - e as normas de qualidade de produto sero assuntos do prximo captulo.

59

CAPTULO 4 Modelos de qualidade Este captulo apresenta modelos de qualidade para produtos de software advindos de pesquisa terica e da prpria aplicao desses modelos em projetos e objetivos especficos originrios da demanda do mercado. Em relao aos modelos tericos, um dos primeiros o modelo da qualidade apresentado por Jim McCall et al, conhecido tambm como o modelo da General Electric, de 1977. Outro modelo especfico surgiu da elaborao da norma ISO/IEC 9126-1, que envolveu cerca de duas dezenas de profissionais especializados de empresas, universidades e centros de pesquisa do mundo todo, que j aplicavam os conceitos em suas atividades profissionais, antes mesmo de o texto final ser aprovado como projeto de norma. A integrao crescente da economia mundial est uniformizando os conceitos de qualidade e, em consequncia, tem exigido a utilizao de textos normativos comuns a todos os pases. Esse foi um dos motivos que levaram a Comisso de Estudo de Qualidade de Software a estabelecer como norma NBR ISO/IEC 9126-1, 2001 a traduo do texto-base da norma ISO/IEC 9126-1, 1996 Information technology Software product quality, em vez de criar uma nova norma. Uma reviso e uma nova abordagem das normas para qualidade de produto de software esto sendo trabalhadas no projeto SQuaRE Software Quality Requirements and Evaluation (Requisitos e Avaliao da Qualidade do Software). O trabalho ocorre no mbito do ncleo e extenso das normas, de 1999 a 2002, com a proposta aprovao na ISO, que em 2005 teve a primeira norma da srie publicada: a norma ISO/IEC 25000 Guide to SQUARE: 2005 e no Brasil a respectiva NBR ISO/IEC 25000 Engenharia de Software - Requisitos e Avaliao da Qualidade de Produtos de Software (SQuaRE) Guia do SQuaRE, em 2008. Em relao aos modelos advindos das aplicaes prticas desenvolvidas no mbito do CTI, que foram baseados nos modelos tericos citados, sero apresentados o modelo de qualidade do MEDE-PROS e outros como sua derivao: modelo de qualidade do PNAFM e modelo de qualidade de componentes de software.

60

4.1 Modelo de McCall Este modelo, assim como outros modelos contemporneos, teve origem nos meios militares americanos e foi utilizado, primeiramente, pelos seus desenvolvedores, para o processo do desenvolvimento de seus sistemas. O modelo McCall da qualidade tenta estabelecer uma ligao entre usurios e desenvolvedores, focalizando nos fatores de qualidade do software que refletem as opinies dos usurios e as prioridades dos desenvolvedores. O modelo da qualidade de McCall tem, como mostra a Figura 4.1, trs perspectivas principais para definir e identificar a qualidade de um produto de software: reviso do produto (habilidade de se submeter a mudanas), transio do produto (adaptabilidade a novos ambientes) e operao do produto (suas caractersticas da operao).

Figura 4.1 Modelo de qualidade de McCall, organizado em funo de trs tipos de caractersticas da qualidade.

MacCall define um modelo de qualidade de forma hierrquica, com 11 fatores de qualidade. Cada um dos fatores se subdivide em 23 critrios de qualidade, que ainda podem ser subdivididos em medidas de controle, as quais no esto definidas nesse modelo. Os fatores descrevem a viso externa do software, com a viso do usurio. Para reviso do produto: Manutenibilidade esforo exigido para localizar e reparar erros em um programa. O software fcil de ser corrigido?

61

Flexibilidade esforo exigido para modificar um programa j em utilizao. O software facilmente altervel? Testabilidade esforo exigido para testar um programa frente a suas pretensas funes. O software pode ser testado facilmente? (a facilidade de testar o software, para se assegurar de que seja isento de erros e de acordo com sua especificao).

Para transio do produto para outra plataforma: Portabilidade esforo exigido para transferir um software de um ambiente (software e hardware ou arquitetura tecnolgica) para outro. O software pode ser utilizado facilmente em outro ambiente? Reusabilidade medida na qual um programa facilmente reusado em um contexto diferente. O software pode ser reaproveitado facilmente? Interoperabilidade esforo requerido para acoplar o software a outro sistema. O software facilmente acoplvel?

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

Os fatores de qualidade descrevem tipos diferentes de caractersticas comportamentais do software, e os critrios de qualidade so atributos a um ou mais dos fatores de qualidade. A ideia do modelo de qualidade de McCall que os fatores de qualidade sintetizados devem fornecer um retrato completo da qualidade do software. Os 11 fatores de qualidade resumidamente so: exatido, confiabilidade, eficincia, integridade, usabilidade, manutenibilidade, testabilidade, flexibilidade, portabilidade, reusabilidade, interoperabilidade.

62

Os fatores de qualidade so subdivididos nos seguintes critrios de qualidade de software segundo McCall: Auditabilidade medida da facilidade com que se pode verificar a conformidade a padres. Acurcia medida da preciso dos tratamentos e do controle. Padres de comunicao medida em que padres de interfaces de mquina, protocolos e larguras de banda so usados. Inteireza medida de quanto a implementao total da funo pretendida foi conseguida. Conciso medida da compactao do programa, em termos de linhas de cdigo por funo. Consistncia medida do uso de tcnicas de projeto e documentao uniformes ao longo do ciclo de desenvolvimento do software. Padres de dados medida do uso de padres de estruturas e tipos de dados. Tolerncia a erros medida dos danos que ocorrem quando o programa executa um erro. Eficincia de execuo medida do desempenho de um programa, em tempo de operao. Expansibilidade medida da possibilidade de o projeto ser estendido. Generalidade medida da amplitude da aplicabilidade dos componentes de um programa. Independncia de hardware medida de quanto o software desvinculado do hardware em que opera. Instrumentao medida de quanto o programa monitora sua prpria operao e identifica os erros que venham a ocorrer. Modularidade medida da independncia funcional dos componentes de um programa. Operabilidade medida da facilidade de operao de um programa. Segurana medida da disponibilidade de mecanismos que controlem ou protejam programas e dados. Autodocumentao medida de quanto o cdigo-fonte apresenta documentao significativa. Simplicidade medida de quo facilmente o programa entendido. Independncia do software bsico medida de quanto o programa independente de particularidades no padronizadas da linguagem de programao, de sistemas operacionais e de ambientes.

63

Rastreabilidade medida da possibilidade de rastrear as decises de projeto, desde sua anlise como requisito at sua implementao como componente. Treinamento medida da capacidade do software de auxiliar novos usurios na utilizao do sistema. Eficincia de armazenamento medida relacionada ao armazenamento dos dados. Controle de acesso barreiras de segurana apropriadas.

Outro modelo, similar ao de McCall, surgiu em 1978, com o nome de Modelo de Boehm. Apresenta um modelo hierrquico de qualidade, estruturado em torno de caractersticas de alto nvel, de caractersticas de nvel intermedirio e de caractersticas primitivas - cada uma dessas caractersticas contribuindo para a qualidade do produto de software. Embora os modelos de McCall e de Boehm possam parecer muito similares, existem diferenas com relao hierarquia das caractersticas. Entretanto, pode-se afirmar que foram esses modelos que inspiraram os atuais modelos de qualidade apresentados na norma e foram o incio dos estudos aqui apresentados.

4.2 O modelo da norma NBR ISO/IEC 9126-1 O objetivo do Total Quality Management - TQM, que o de prover as necessidades dos clientes agora e no futuro, e com a definio da norma NBR ISO/IEC 9126-1 sobre qualidade de software como sendo a totalidade das caractersticas de um produto de software, que lhe confere a capacidade de satisfazer s necessidades explcitas e implcitas, possvel visualizar a relao existente entre o TQM e a norma NBR ISO/IEC 9126-1. Se, por um lado, desde o inicio do modelo CMM, a partir dos conceitos do TQM, procura garantir a qualidade do insumo, ou entradas, e do processo de software, por outro, a norma NBR ISO/IEC 9126-1 est preocupada em garantir que as necessidades dos clientes, em relao ao produto de software, sejam providas. Esta norma define quais so as caractersticas que um produto de software deve ter e fornece um modelo para ser utilizado em uma avaliao de verificao da presena de tais caractersticas. Isso significa que, a partir de uma entidade de software, disponvel a um usurio, possvel utilizar a norma para verificar a qualidade dessa entidade. As sries de normas NBR ISO/IEC 9126 NBR ISO/IEC 14598 e a norma NBR ISO/IEC 25051 tratam de trs assuntos importantes: modelo de qualidade, processo de avaliao, avaliao de pacotes de software.

64

A seguir, a norma que trata modelo de qualidade ser apresentada por meio de sua prpria estrutura, ou seja, sero apresentadas suas diretrizes de uso, as caractersticas de qualidade de produto de software e o modelo sugerido para avaliao. 4.2.1 Diretrizes para uso da norma NBR ISO/IEC 9126-1 Esta norma pode ser aplicada nos seguintes momentos: Definio dos requisitos de qualidade de um produto de software. Avaliao da especificao de software para verificar se ele ir satisfazer aos requisitos de qualidade durante o desenvolvimento. Descrio de particularidades e atributos do software implementado, por exemplo, em manuais de usurio. Avaliao do software desenvolvido, antes da entrega. Avaliao do software desenvolvido, antes da aceitao.

A seguir, so apresentadas as caractersticas de qualidade de software que devem ser consideradas em cada um dos momentos citados anteriormente. 4.2.2 Caractersticas e subcaractersticas de qualidade de software O modelo de qualidade apresenta uma estrutura hierrquica, definindo caractersticas, subcaractersticas de qualidade e atributos, como mostra a Figura 4.2, de uma forma genrica.

65

Figura 4.2 Modelo bsico de qualidade.

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

Qualidade em uso satisfazer as necessidades reais de usurios ao utilizar o produto de

software, para atingir metas especificadas em contextos de uso especificados, ou seja, o efeito da utilizao do produto, medido com relao s necessidades dos usurios.

Qualidade externa influenciar o comportamento de um sistema, para satisfazer necessidades

explcitas e implcitas, quando o sistema que o inclui for utilizado sob condies especificadas, ou seja, o efeito da execuo das funes, medido com relao aos requisitos externos.

Qualidade interna atributos estticos do produto de software para satisfazer necessidades

explcitas e implcitas, quando o software for utilizado em condies especificadas, ou seja, o efeito das propriedades de produtos intermedirios, medidos com relao aos requisitos internos projeto e cdigo.

A norma NBR ISO/IEC 9126-1, publicada em 2001, estabeleceu dois modelos de qualidade. Um modelo para qualidade externa e interna contendo um conjunto de seis caractersticas da qualidade de produto de software e suas respectivas subcaractersticas, como mostra a Figura 4.3. O outro modelo para qualidade em uso e contm quatro caractersticas de qualidade: Eficcia, Produtividade, Segurana e Satisfao, como mostra a Tabela 4.1. Esse modelo ainda requer estudos para sua aplicao.
Tabela 4.1 Caractersticas de qualidade em uso (NBR ISO/IEC 9126-1, 2001) Caractersticas Eficcia Definies O software deve permitir que os usurios especificados atinjam metas especificadas com acurcia e

66

completitude, no contexto de uso especificado. Produtividade Segurana Satisfao O software deve permitir que seus usurios diretos e indiretos empreguem quantidade apropriada de recursos em relao eficcia obtida, no contexto de uso especificado. O software deve apresentar nveis aceitveis de riscos de danos a pessoas, negcios, software, propriedades ou ao ambiente, no contexto de uso especificado O software deve satisfazer usurios, no contexto de uso especificado.

Os requisitos para a escolha dessas caractersticas foram os seguintes: cobrir conjuntamente todos os aspectos de qualidade de software resultantes da definio de qualidade da ISO; descrever a qualidade do produto com um mnimo de sobreposio; ficar o mais prximo possvel da terminologia estabelecida; formar um conjunto entre seis e oito caractersticas, por questes de clareza e manuseio; e identificar reas de atributos de produtos de software para posterior refinamento.

Figura 4.3 Caractersticas e subcaractersticas de qualidade.

O modelo de qualidade de produto de software foi definido para apoiar o objetivo de aplicar as seis caractersticas de qualidade em uma avaliao de produto de software. A utilizao do modelo

67

apresentado no obrigatria; outros modelos podem ser utilizados, mas importante perceber a necessidade de seguir um modelo tanto para desenvolvimento do software quanto para uma avaliao. O modelo apresentado baseado na definio das caractersticas de qualidade de software e das subcaractersticas. As seis caractersticas de qualidade de software esto apresentadas na Tabela 4.2. Uma preocupao da norma foi definir caractersticas com um mnimo de sobreposio de conceitos entre elas.
Tabela 4.2 Caractersticas de qualidade interna e externa (NBR ISO/IEC 9126-1, 2001) Caractersticas Funcionalidade Confiabilidade 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.

Usabilidade

Eficincia Manutenibilidade Portabilidade

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

Adequao Acurcia Funcionalidade Interoperabilidade Conformidade Segurana de acesso Maturidade Confiabilidade Tolerncia a falhas Recuperabilidade Conformidade Inteligibilidade Apreensibilidade Usabilidade Operacionalidade Atratividade Conformidade

Presena de um conjunto de funes e sua apropriao para as tarefas especificadas Gerao de resultados ou efeitos corretos Capacidade de interagir com outros sistemas especificados Estar de acordo com normas, convenes e regulamentaes Capacidade de evitar acesso no autorizado a programas e dados Frequncia de falhas Capacidade de manter o nvel de desempenho em caso de falha ou violao nas interfaces Capacidade de restabelecer seu desempenho e restaurar dados aps falha Estar de acordo com normas, convenes e regulamentaes Atributos do software que evidenciam o esforo do usurio para reconhecer o conceito lgico e sua aplicabilidade Atributos do software que evidenciam o esforo do usurio para apreender sua aplicao Atributos do software que evidenciam o esforo do usurio para sua operao e controle desta A capacidade do software de ser atrativo ao usurio Estar de acordo com normas, convenes e regulamentaes

Eficincia

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 Estar de acordo com normas, convenes e regulamentaes Esforo necessrio para diagnosticar deficincia e causas de falhas Esforo necessrio para realizar modificaes e remoo de defeitos Ausncia de riscos de efeitos inesperados ocasionados por modificaes Estar de acordo com normas, convenes e regulamentaes Facilidade de ser testado Capacidade de ser adaptado a ambientes diferentes Esforo necessrio para a instalao Capacidade do software de coexistir com outros produtos independentes, em um ambiente comum, compartilhando os mesmos recursos Consonncia com padres ou convenes de portabilidade Capacidade e esforo necessrio para substituir outro software

Manutenibilidade

Estabilidade Conformidade Testabilidade Adaptabilidade Capacidade para ser instalado

Portabilidade

Coexistncia Conformidade Capacidade para substituir

A elaborao dessa srie de normas consolidou-se na estrutura mostrada na Tabela 4.4. Estudos e revises continuam sendo desenvolvidos em termos dessa estrutura.

69

Tabela 4.4 Normas da srie ISO/IEC 9126: Status em 2009 Norma 9126-1 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

Definio das caractersticas e subcaractersticas da Norma, publicada em 2001 qualidade Exemplos de medidas externas Exemplos de medidas internas Exemplos de medidas de qualidade em uso

9126-2

Relatrio tcnico, publicado Relatrio tcnico a ser publicado em 2003 Relatrio tcnico, publicado Relatrio tcnico a ser publicado em 2003 Relatrio tcnico, publicado Relatrio tcnico a ser publicado em 2004

9126-3

9126-4

No Apndice D, esto resumidos os conceitos de qualidade para produtos de software. Esta srie de normas est sendo reestruturada numa nova srie, que ser apresentada na prxima seo.

4.3 A srie ISO/IEC 25000 O processo de transio na ISO entre as normas ISO/IEC 9126, ISO/IEC 14598 foi longo e muito trabalhado para construo da nova srie ISO/IEC 25000 SQuaRE Software Quality Requirements and Evaluation (Requisitos e Avaliao da Qualidade de Software). A necessidade de um conjunto harmnico de documentos foi verificada quando especialistas do mundo todo concordaram que faltava clareza na utilizao das normas de qualidade de produto. Assim, as sries 9126 e 14598 existentes levaram a uma lista de melhorias que foram implementadas na nova srie. Foi construda uma nova estrutura, um primeiro ajuste e a construo da estrutura necessria foram aprovados pela ISO/IEC, a verso foi revisada, e um ndice detalhado foi definido. Seguiu-se, ento, a escolha dos novos nmeros que foram atribudos aos documentos SQuaRE. Em maio de 2002, a numerao final da srie foi aprovada e aplicada. A arquitetura SQuaRE mostrada na Figura 4.4.

70

Figura 4.4 Arquitetura atual da srie ISO/IEC 25000.(2009)

A srie ISO/IEC 25000 composta pelas seguintes divises: Gesto da Qualidade, Modelo de Qualidade, Medio, Requisitos e Avaliao. Uma representao dessas divises mostrada nas Figuras 4.5 a 4.9, conforme as seguintes denominaes: ISO/IEC 2500n Diviso Gesto da Qualidade; ISO/IEC 2501n Diviso Modelo de Qualidade; ISO/IEC 2502n Diviso Medio da Qualidade; ISO/IEC 2503n Diviso Requisitos de Qualidade; ISO/IEC 2504n Diviso Avaliao da Qualidade. O objetivo das normas SQuaRE obter uma srie logicamente organizada, unificada com abrangncia de dois processos principais: especificao de requisitos e avaliao da qualidade de software, apoiados por um processo de medio. Essas normas podem auxiliar desenvolvedores e adquirentes de produtos de software durante os processos de especificao de requisitos e avaliao da qualidade, estabelecendo critrios de especificao dos requisitos de qualidade, para medio e avaliao. Os computadores so utilizados para automatizar uma variedade de reas de aplicao, e seu uso crtico para o sucesso dos negcios. A especificao e a avaliao da qualidade de produto de software so fatores para assegurar a qualidade adequada, muitas vezes difcil de ser estabelecida. Isso pode ser alcanado, definindo-se caractersticas de qualidade apropriadas ao uso pretendido do produto de software. essencial que todas as caractersticas de qualidade importantes do produto de software sejam especificadas e avaliadas, utilizando medidas validadas ou internacionalmente aceitas. As caractersticas de qualidade e suas medidas associadas podem ser utilizadas tanto para avaliar um produto de software quanto para definir requisitos de qualidade. A nova srie estabelece critrios para a especificao dos requisitos de qualidade de produto de software, para medio e avaliao.

71

Est includo nessa nova srie um modelo de qualidade composto por duas partes, para alinhar as definies de qualidade do usurio aos atributos relacionados ao processo de desenvolvimento. Alm disso, a srie recomenda medidas para atributos de qualidade que podem ser utilizadas por desenvolvedores, adquirentes e avaliadores. A diviso SQuaRE ISO/IEC 2500n Gesto da Qualidade fornece orientaes sobre o uso da srie SQuaRE, dando uma viso geral do seu contedo, de seus modelos de referncia, definies, o relacionamento entre todos os documentos da srie, como tambm orientaes para planejamento e gesto para especificao de requisitos e avaliao de produto. Ela apresentada na Figura 4.5. As normas que compem a diviso Gesto da Qualidade definem todos os modelos e termos referidos por todas as outras normas da srie 25000. Tal diviso fornece requisitos e orientaes para uma funo de apoio, que responsvel pela gesto da especificao de requisitos e avaliao de produto de software.

Figura 4.5 Diviso de Gesto da Qualidade da srie ISO/IEC 25000.

A norma que compe a diviso Modelo de Qualidade, apresentada na Figura 4.6, prope dois modelos de Qualidade. Um modelo que inclui caractersticas para qualidade interna e externa de software e qualidade em uso, alm disso, as caractersticas internas e externas de software so decompostas em subcaractersticas. O outro modelo define qualidade para os dados pertencentes a um sistema computacional, num formato estruturado. Tambm so fornecidas orientaes prticas para o uso de modelos de qualidade.

72

Figura 4.6 Diviso Modelo de Qualidade da srie ISO/IEC 25000.

As normas que compem a diviso Medio da Qualidade contm um modelo de referncia para medio da qualidade do produto de software, algumas definies analticas para medidas da qualidade de software e orientaes prticas para aplicao. A Figura 4.7 apresenta a estrutura que contm elementos de medidas de qualidade, medio de qualidade interna, medio de qualidade externa de software e medio de qualidade em uso de software.

73

Figura 4.7 Diviso de Medio de Qualidade da srie ISO/IEC 25000.

A norma que compe a diviso Requisitos de Qualidade auxilia na especificao de requisitos de qualidade, os quais podem ser utilizados no processo de elicitao de requisitos para um produto que ser desenvolvido, isto , no incio do seu ciclo de vida ou posteriormente, como entrada para um processo de avaliao. Tal diviso est representada esquematicamente na Figura 4.8.

Figura 4.8 Diviso Requisitos de Qualidade da srie ISO/IEC 25000.

As normas que compem a diviso de Avaliao da Qualidade, representada na Figura 4.9, fornecem requisitos, recomendaes e orientaes para o processo de avaliao de produto de software.

Figura 4.9 Diviso de Avaliao da Qualidade da srie ISO/IEC 25000.

Apresenta tambm uma maneira formal de documentar uma medida, utilizando um mdulo de avaliao. Alm disso, ela apresenta uma estrutura para a avaliao da qualidade de produto de

74

software. Essas estruturas so provenientes das normas ISO/IEC 9126-1 e 14598-1, 14598-3, 14598-4, 14598-5 e 14598-6. As normas anteriores que tratam de qualidade de produto continuam sendo utilizadas at que as da nova srie SQuaRE sejam publicadas. As principais diferenas entre as sries ISO/IEC 9126, ISO/IEC 14598 e SQuaRE so: introduo do novo modelo de referncia geral; introduo de guias detalhados e direcionados para cada diviso da norma; introduo de elementos de medidas de qualidade dentro da diviso Medio da Qualidade; introduo da diviso Requisitos de Qualidade; incorporao e reviso dos processos de avaliao; introduo de orientaes para uso prtico em forma de exemplos; coordenao e harmonizao do contedo com a norma NBR ISO/IEC 15939 Engenharia de Sistemas e de Software Processo de Medio, publicada em janeiro de 2009. Alm dessas divises, existe uma extenso dessa srie; a sequncia ISO/IEC 25050 at 25099 est reservada para ser utilizada por normas ou relatrios tcnicos que estendem o SQuaRE. A norma 25051 diz respeito a: requisitos para COTS Commercial Off-The-Shelf, produtos de software de prateleira disponveis comercialmente; requisitos para a documentao de teste, quando em desenvolvimento desses produtos, incluindo requisitos de teste, casos de teste e relatrio de teste; e tambm instrues para avaliao de conformidade. Essa norma substitui a ISO/IEC 12119. A norma 25062 se refere Usabilidade. Fornece instrues para relatrios de teste de usabilidade, especificando como descrever os resultados de um teste de usabilidade num contexto de uso especfico. A Tabela 4.5 mostra a nomenclatura das siglas utilizadas unicamente na ISO, onde foram mantidas as palavras em Ingls para facilitar o entendimento das siglas; a sequncia de etapas de projetos por meio dos quais o trabalho desenvolvido; o nome do documento associado a cada etapa.
Tabela 4.5 Etapas de projeto e documentos associados Etapas de projeto 0 Estgio preliminar 1 Estgio de Proposta 2 Estgio preparatrio 3 Estgio Comit Documentos associados Nome Preliminary work item New work item proposal Working draft(s) Committee draft(s) Abreviatura PWI NP WD CD

75

4 Estgio de consulta 5 Estgio de aprovao 6 Estgio de publicao

Draft International Standard Final Draft International Standard International Standard

DIS FDIS ISO/IEC

Os trabalhos na ISO so organizados de acordo com as reas de especializao; ento so criados os Grupos de Trabalho, numerados sequencialmente na ordem em que foram estabelecidos. Os trabalhos dos grupos so chamados de projetos e so classificados conforme a etapa de desenvolvimento em que se encontram. Por isso, a Tabela 4.5 contm algumas siglas em ingls que se referem etapa do projeto em que a norma se encontra. A Tabela 4.6 apresenta o status das normas de qualidade de produtos de software at 2009.
Tabela 4.6 SQuaRE Status: 2009 Norma 2500n 25000 25001 (ex - 14598-2) 2501n 25010 (ex - 9126-1) 25012 2502n 25020 25021 25022 (ex - 9126-3) 25023 (ex - 9126-2) 25024 (ex - 9126-4) 2503n 25030 2504n 25040 (ex - 14598-1) 25041 (ex - 14598-6) 25051 25062 Ttulo resumido Diviso Gesto da Qualidade Guia para SQuaRE Planejamento e Gesto Diviso Modelo de Qualidade Modelo de Qualidade Modelo de Qualidade de Dados Diviso Medio da Qualidade Guia e Modelo de Referncia Elementos de Medida de Qualidade Medio de Qualidade Interna Medio de Qualidade Externa Medio de Qualidade em Uso Diviso Requisitos de Qualidade Requisitos de Qualidade Diviso Avaliao de Qualidade Guia e Modelo de Referncia Mdulos de Avaliao Extenso da srie Requisitos de Qualidade para COTS Estado internacional Publicada em 2005 Publicada em 2007 Estado nacional Publicada em 2008 Publicada em 2009

Em reviso Em reviso

Publicada em 2007 Publicada em 2007 Em reviso Em reviso Em reviso

Publicada em 2009

Publicada em 2007

Publicada em 2008

Em reviso Em reviso Publicada em 2006 Publicada em 2008

Formato Comum da Indstria para Relatrios Publicada em 2006 de Usabilidade

76

A seguir sero apresentados modelos de qualidade baseados nas normas e advindos de aplicaes prticas.

4.4 O modelo de qualidade do MEDE-PROS Este modelo de qualidade foi baseado na norma NBR ISO/IEC 9126-1, que padronizou uma linguagem universal para um modelo de qualidade de produto de software e um exemplo de como aplicar os conceitos definidos nesta norma. Este modelo foi amplamente utilizado nas avaliaes de qualidade de produto de software, em diversas ocasies em que o CTI desenvolveu atividades sob demanda. Este modelo adequado para avaliar produto de software, pode-se dizer que um modelo genrico para avaliar software de qualquer domnio de aplicao. Os requisitos de qualidade para software do tipo pacote, podem ser baseados, principalmente, na 9 norma NBR ISO/IEC 12119 , que define requisitos para essa categoria de software, a qual trouxe uma definio universal do que um pacote de software deve possuir para ter um mnimo de qualidade e profissionalismo. Adicionalmente, foram utilizados outros requisitos baseados nas normas de documentao de usurio e de requisitos de usabilidade na interface homem-mquina, IEEE e ISO, respectivamente. Esse assunto ser detalhado no prximo captulo. Uma estrutura inicial de um modelo de qualidade de software pode ser desdobrada a partir dos seus componentes at os seus atributos a serem avaliados. O modelo de qualidade sugerido neste livro tem incio com os trs componentes definidos na norma NBR ISO/IEC 12119, que so: Descrio do Produto, Documentao do usurio, Programas e dados. Alm desses componentes, sero acrescentados outros componentes, considerados importantes numa avaliao dessa natureza. A seguir, algumas consideraes so expostas, com o objetivo de desdobrar esses componentes, para obter uma avaliao mais objetiva. Pode-se considerar Programas e dados como sendo o software propriamente dito, ou seja, na linguagem de Engenharia de software, o que executvel em uma mquina tipo computador; assim, este componente passa a ser chamado simplesmente de software. O software, quando requer interatividade, requer dados de entrada e opes a serem escolhidas pelo usurio; apresenta uma interface, que geralmente composta por janelas e campos a serem preenchidos pelo usurio. Dessa maneira, importante estar avaliando a interface como um componente especfico em produtos de software.

O MEDE-PROS foi desenvolvido com a norma NBR ISO/IEC 12119 e sua ltima verso data de 2006.

77

No caso de pacote de software, este pode ser comercializado em algum tipo de embalagem; atualmente tem sido comercializado tambm pela internet. Nesse caso, existe uma pgina na internet onde o software apresentado. Em ambos os casos, interessante avaliar sua embalagem ou informaes a ele relacionadas, localizadas no site do fornecedor do produto.

Considerando a norma NBR ISO/IEC 25051 e a forma como um software normalmente se apresenta, os componentes de um software propostos neste modelo podem ser: Descrio do Produto Embalagem Documentao de usurio Software e Interface

Identificando cada um desses componentes, tem-se, segundo a norma NBR ISO/IEC 25051, a Descrio do Produto, que um documento expondo as propriedades de um pacote de software, com o objetivo de auxiliar os potenciais compradores, na avaliao da adequao do produto antes da compra. Essa descrio pode estar disponvel em um catlogo prprio, na embalagem, em mdia digital de apresentao ou qualquer outro meio disponvel ao usurio, independentemente da aquisio do produto. O produto deve possuir um documento nico e de fcil localizao. Por Embalagem, entende-se o meio fsico que acondiciona a mdia e documentos impressos. Exemplos de embalagem: caixa de papelo tipo cartolina, caixa de papelo resistente e com abas tipo encaixe, caixa plstica para CD, caixa de papelo com capa dura e com encaixe sobreposto, se for o caso. Documentao de usurio o conjunto completo de documentos, disponvel na forma impressa, ou no; fornecida para utilizao de um produto, sendo tambm uma parte integrante do produto. Por exemplo: manual, complementos de manuais, atualizaes, mdia digital de demonstrao, selo de identificao. Documentao on-line toda documentao em mdia e pode ser consultada por meio de qualquer meio eletrnico. As Funes do software so representadas na Interface por meio de menus, botes, caixas de dilogo, janelas, teclas aceleradoras e outros meios. Esses componentes de software podem ser visualizados na Figura 4.10, em que se apresentam os cinco componentes conceituais do modelo de qualidade e a indicao de normas que sero utilizadas. Os componentes software e interface so provenientes de normas diferentes, mas fisicamente um nico componente.

78

Figura 4.10 Componentes de software.

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

79

Figura 4.11 Etapas de avaliao.

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

10

O requisito Completitude na norma NBR ISO/IEC 25051, tem o nome de Completeza.

80

Figura 4.12 Modelo de qualidade numa viso mais detalhada.

Este modelo de qualidade pode ser visto como um modelo genrico para avaliar qualquer categoria de software, independente da sua rea de aplicao.

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

81

foco principal, a verificao da conformidade dos requisitos funcionais, isto , o atendimento preestabelecido no Edital. Editais so de uso obrigatrio para qualquer tipo de aquisio realizada por rgos do governo, nos mbitos federais, estaduais e municipais, tanto na aquisio de bens como para servios. So instrumentos que do ao processo de aquisio o carter legal, tornando-o transparente e, consequentemente, imparcial.

Figura 4.13 Conjunto de Sistemas Aplicativos do PNAFM

Este mtodo de avaliao, criado para atender ao PNAFM, trouxe caractersticas inovadoras, podendo derivar novas iniciativas, como o estabelecimento de um padro mnimo (bsico) da qualidade dos sistemas aplicativos utilizados na Gesto Pblica Municipal Brasileira. Propondo-se a ser uma iniciativa precursora na busca da qualidade nas solues de tecnologia da informao pblica. Quanto a sua representatividade no meio cientfico como pesquisa inovadora, o mtodo se caracteriza por ter sido desenvolvido utilizando como base terica as normas de qualidade de software que tratam de modelo de qualidade de produto e medidas, de requisitos de usabilidade de interfaces, documentao e testes e requisitos de qualidade para pacote de software entre outros, e considerando os requisitos funcionais pr-estabelecidos. Este o primeiro mtodo de avaliao de aplicativos desenvolvido, testado e aplicado tanto no contexto nacional.

82

Assim o modelo de qualidade pode ser representado, esquematicamente, como na Figura 4.14, onde se v o modelo de qualidade do MEDE-PROS, aplicado e adaptado para cada um dos sistemas aplicativos, com as exigncias estabelecidas no Edital.

Figura 4.14 Modelo de Qualidade do PNAFM

O modelo de qualidade de cada CSA dos sistemas aplicativos contempla os requisitos especficos contidos e publicados no Edital.

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

Componentes de software So artefatos autocontidos, claramente identificveis, que descrevem

ou realizam uma funo especfica e tm interfaces claras, em conformidade com um dado modelo de arquitetura de software, documentao apropriada e um grau de reutilizao definido (VILLELA, 2000).

83

Para melhor entendimento da definio apresentada por Villela, alguns termos foram detalhados por Sametinger (SAMETINGER,1997) de forma mais profunda: Autocontido caracterstica dos componentes de poderem ser reusveis sem a necessidade de incluir/depender de outros componentes. Caso exista alguma dependncia, todo o conjunto deve ser visto como o componente reutilizvel. Identificao componentes devem ser facilmente identificados, ou seja, devem estar contidos em um nico lugar, ao invs de espalhados e misturados com outros artefatos de software ou documentao. Funcionalidade componentes tm uma funcionalidade clara e especfica que realizam e/ou descrevem. Componentes podem realizar funes ou podem ser simplesmente descries de funcionalidades, por exemplo, artefatos do ciclo de vida. Interface componentes devem ter interfaces claras, que indicam como podem ser reusados e conectados a outros componentes, e devem ocultar os detalhes que no so necessrios para o reso. Documentao a existncia de documentao indispensvel para o reso. O tipo de componente e sua complexidade iro indicar a convenincia do tipo de documentao. Condio de reso componentes devem ser mantidos de modo a preservar o reso sistemtico, e a condio de reso compreende diferentes informaes: por exemplo, quem o proprietrio, quem deve ser contatado em caso de problema, qual a situao de qualidade, entre outras.

Prope-se uma estrutura de qualidade de componentes que assegure um rigoroso fundamento terico para derivao e definio das caractersticas, subcaractersticas, atributos e medies da qualidade, considerando, assim, diferentes abordagens (GUERRA, 2007). Dessa forma apresentado o modelo de qualidade externa para componentes de software, na

Figura 4.15. Os atributos externos so divididos em dois grupos: Aqueles que influenciam no DBC e Aqueles que influenciam na execuo do Sistema Baseado em Componentes - SBC. Para os atributos externos do DBC, considera-se que o componente deve apresentar:

84

Um documento de descrio de componente, o qual deve conter as informaes que permitam avaliar a adequao do componente. Esse documento deve seguir uma adaptao dos requisitos do documento de descrio de produto de software, da norma NBR ISO/IEC 25051. Uma documentao para o DBC, que deve conter todas as informaes necessrias, e com o grau de detalhamento adequado. Foco principal dessa documentao devem ser as informaes para a adaptao e integrao do componente no sistema, nas quais so descritas suas caractersticas e funcionalidades, por exemplo: interfaces de gerncia, interfaces providas e requeridas, eventos recebidos e enviados, bem como as propriedades e as interfaces de acesso s propriedades, quando estas sejam internas. Caso o componente tenha funes de interface com o usurio, estas tambm devem estar descritas. A documentao ser avaliada com base nos requisitos de qualidade das normas NBR ISO/IEC 25051 e IEEE 1063. A qualidade externa do componente no DBC, que contm informaes de qualidade do componente que so relevantes para sua utilizao no DBC. Essas informaes englobam tanto caractersticas funcionais quanto no funcionais, mas que so observveis ou medidas durante o ciclo de vida do desenvolvimento do componente.

Modelo da Qualidade para Componente de Software

Modelo da Qualidade de Componentes de Software

Atributos externos que influenciam no DBC

Atributos externos que influenciam na execuo do SBC

Descrio do Componente (busca e avaliao)

( ISO/IEC12119)

Documentao para DBC

( ISO/IEC12119 e IEEE1063)

Componente no DBC (adaptao e integrao)

( ISO/IEC9126-1 e 3)

Componente integrado no SBC

(ISO/IEC9126-1 e 2)

Completitude Identificador Declaraes Decl. Funcionalidade Decl. Confiabilidade Decl. Usabilidade Decl. Eficincia Decl. Manutenibilidade Decl. Portabilidade Decl. Qualid. Uso Contedo

Funcionalidade Completitude Usabilidade Inteligibilidade Correo Apresentao e Consistncia Organizao

Funcionalidade Adequao Interoperabilidade Conformidade Confiabilidade

Funcionalidade Acurcia Segur. Acesso Confiabilidade Recuperabilidade

Maturidade Usabilidade Operacionalidade

Eficincia Rel. Tempo Rel. Recursos

Aval. Adequao Consistncia Termos Tcnicos Decl. Corretas Decl. Testveis

Adaptado de Bertoa et ali e do MEDE-PROS pelo CTI

Manutenibilidade Modificabilidade Testabilidade Portabilidade Cap. p/substituir

85

Figura 4.15 Modelo de qualidade para componentes de software COTS.

Para os atributos externos no Sistema SBC, considera-se que o componente deve apresentar atributos da qualidade externa influenciando no SBC, que tambm contm informaes de qualidade do componente, mas que influenciam na execuo do sistema. A seguir sero apresentados os atributos de qualidade a serem avaliados neste modelo. 4.6.1 Descrio do componente Para descrio do componente, o modelo de qualidade se decompe em: Completitude e Contedo. Como Completitude, entende-se a capacidade de verificar quo completa a descrio do componente. O atributo Completitude se decompe nos seguintes requisitos: Identificador capacidade de verificar se a descrio do componente contm identificaes importantes do componente.

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

Declaraes capacidade de verificar se a descrio do componente contm declaraes sobre suporte e manuteno. As declaraes devem ser seguintes: Suporte declaraes de suporte do componente; Manuteno declaraes de manuteno do componente.

86

Declarao da Funcionalidade capacidade de verificar se, na descrio do componente, existem declaraes sobre as funes, valores-limites, grau de preciso, interoperabilidade e segurana de acesso do componente. Os atributos avaliados so: Declarao dos servios declaraes dos servios que o componente oferece por meio de suas interfaces; Grau de preciso declaraes do grau de preciso dos resultados obtidos por meio da execuo do componente; Interoperabilidade declaraes sobre a interoperabilidade do componente, ou seja, da compatibilidade dos dados tratados pelo componente; Conformidade declaraes de conformidade das funcionalidades do componente com padres, normas e convenes; Valores-limites declaraes de valores limites, caso o uso do componente seja limitado por eles; Segurana de acesso declaraes de maneiras (se fornecidas) de evitar o acesso no autorizado ao componente e a seus dados.

Declarao da Confiabilidade capacidade de verificar se a descrio do componente contm informaes sobre procedimentos para a preservao dos dados. Os atributos avaliados so: Cpia de segurana declaraes sobre a realizao de cpias de segurana; Verificao de entradas declaraes sobre entradas aceitveis; Recuperao de erros declaraes sobre a capacidade do componente de se recuperar de erros ocorridos.

Declarao da Usabilidade capacidade de verificar se, na descrio do componente, existem declaraes sobre o conhecimento especfico requerido do usurio do componente, adaptaes que podem ser feitas pelo usurio e se protees contra infraes a direitos autorais podem interferir na usabilidade. Os atributos avaliados so: Interfaces declarao dos tipos de interfaces do componente;

87

Conhecimento necessrio declarao sobre conhecimentos requeridos pelo usurio do componente; Adaptao declaraes sobre ferramentas, caso existam, interfaces de gerncias ou propriedades do componente para configuraes do componente s necessidades do usurio; Proteo tcnica declaraes sobre proteo contra infraes a direitos autorais, caso estes dificultem a usabilidade.

Declarao da Eficincia capacidade de verificar se a descrio do componente inclui dados sobre o comportamento do componente em relao ao tempo. Por exemplo: tempo de resposta. Os atributos avaliados so: Tempo declaraes sobre o comportamento do componente em relao ao tempo; Recursos declaraes sobre o comportamento do componente em relao aos recursos.

Declarao da Manutenibilidade capacidade de verificar se, na descrio do componente, existem declaraes sobre manutenibilidade. Os atributos avaliados so: Anlises declaraes sobre a analisabilidade do componente, ou seja, declaraes sobre possveis diagnsticos que podem ser realizados no componente; Modificaes declaraes sobre a capacidade de modificar o componente; Testes declaraes da capacidade de realizar testes para validar o componente aps modificaes.

Declarao da Portabilidade capacidade de verificar se, na descrio do componente, existem declaraes sobre portabilidade. Os atributos avaliados so: Adaptaes declaraes sobre a capacidade de realizar adaptaes no componente para diferentes ambientes; Reso declaraes sobre a capacidade de o componente ser utilizado em diferentes contextos e domnios.

Declarao da Qualidade em Uso capacidade de verificar se a descrio do componente inclui declaraes de qualidade sob a perspectiva do desenvolvedor, projetista, arquiteto de

88

software. Ou seja, se h uma declarao de usos anteriores do componente com respeito a eficcia, produtividade, segurana e satisfao. Os atributos avaliados so: Eficcia no DBC declaraes sobre a eficcia atingida com a utilizao do componente em contextos de usos especificados; Produtividade no DBC declaraes sobre a produtividade atingida com a utilizao do componente em contextos de usos especificados; Segurana no DBC declaraes sobre nveis aceitveis de riscos com a utilizao do componente em contextos de usos especificados; Satisfao no DBC declaraes sobre a satisfao dos usurios (desenvolvedores e integradores) com a utilizao do componente em contextos de usos especificados.

Como Contedo, entende-se a capacidade de verificar se o contedo da descrio do componente suficientemente adequado, livre de inconsistncias internas, e se cada declarao da descrio do componente est correta e passvel de teste. O atributo Contedo se decompe nos seguintes requisitos: Avaliao da adequao avaliar se o contedo da descrio do componente inteligvel, completa e possui boa organizao e apresentao; Consistncia avaliar se o contedo da descrio do componente livre de inconsistncias internas; Termos tcnicos avaliar se os termos tcnicos possuem significados nicos; Declaraes corretas avaliar se a descrio do componente possui declaraes corretas; Declaraes testveis avaliar se a descrio do componente possui declaraes passveis de serem testadas.

4.6.2 Documentao do usurio Para a documentao do usurio do Desenvolvimento Baseado em Componentes - DBC, o modelo de qualidade se decompe nas seguintes caractersticas e suas respectivas subcaractersticas: Funcionalidade essa caracterstica diz respeito s descries das funcionalidades do componente na documentao para o DBC. Exemplo de funcionalidades do componente: servios oferecidos e requeridos, documento de implantao, valores-limites etc.

89

Completitude capacidade de verificar quo completa a documentao das funcionalidades do componente. Para isso, avaliada a descrio dos servios oferecidos e requeridos do componente, verificado se os valores-limites citados na descrio do componente so informados tambm na documentao e, tambm, se est includo na documentao o manual de implantao do componente. Os atributos avaliados so: Descrio dos servios verificar a completitude da descrio dos servios oferecidos e requeridos do componente por meio de suas interfaces providas e requeridas; Valores-limites verificar se os valores-limites citados na descrio do componente esto declarados tambm na documentao; Manual de adaptao e integrao verificar se est includo na documentao o manual de implantao do componente.

Usabilidade essa caracterstica diz respeito usabilidade das informaes contidas na documentao. Para isso, verificado se as informaes so corretas, consistentes, de fcil compreenso pela classe de usurios da documentao. Tambm so verificadas a apresentao e a organizao das informaes. Correo capacidade de verificar se as informaes na documentao para DBC esto corretas, sem ambiguidades nem erros. Para isso verificado, nas informaes do documento, se h termos ambguos ou incorretos dentro do contexto indicado. O atributo avaliado : Informaes corretas verificar se, nas informaes da documentao, h termos ambguos ou incorretos dentro do contexto indicado.

Consistncia capacidade de verificar se o documento para DBC no apresenta contradies internas ou e com a descrio do componente. Para isso, avaliada a consistncia dos termos que devem ter um significado nico em toda a documentao, e tambm a consistncia entre as informaes da documentao e as da descrio do componente. Os atributos avaliados so: Consistncia dos termos verificar se os termos apresentam um significado nico em toda a documentao; Consistncia com a descrio do componente verificar a consistncia entre as informaes da documentao e as da descrio do componente.

90

Inteligibilidade capacidade de verificar se o documento para DBC de boa compreenso pela classe de usurios que normalmente utilizam o componente em suas tarefas, como projetistas, desenvolvedores, arquitetos de software etc. Para verificar a inteligibilidade, utiliza-se uma seleo apropriada de termos, exibies grficas e explicaes detalhadas. Os atributos avaliados so: Termos adequados verificar se os termos utilizados so apropriados para o contexto do componente; Exibies grficas verificar se o documento possui exibies grficas, como ilustraes, figuras, para facilitar a compreenso; Explicaes detalhadas verificar se o documento possui explicaes em um nvel de detalhes que facilite a compreenso; Clareza verificar se as informaes apresentadas na documentao so claras, de fcil entendimento.

Apresentao e Organizao capacidade de verificar se a documentao possui uma boa apresentao e organizao, de tal modo que quaisquer relacionamentos sejam facilmente identificados. Para isso, verificado se h presena de ndices analticos e remissivos e se possui uma boa apresentao visual e de layout. Os atributos avaliados so: Presena de ndices verificar se h presena de ndices analticos e remissivos na documentao; Apresentao visual verificar se h uma boa apresentao visual; por exemplo, tamanhos e tipos de fontes, cores e layout.

4.6.3 Componentes no DBC Para o Componente em si, o modelo de qualidade se decompe nas seguintes caractersticas e suas respectivas subcaractersticas: Funcionalidade capacidade do componente de prover servios que satisfaam as necessidades especificadas, quando o componente for usado sob condies especficas. Adequao capacidade do componente de prover um conjunto apropriado de servios para tarefas e objetivos do usurio especificados. Para isso, verificada sua adequao com uma determinada arquitetura, se a implementao cobriu os servios oferecidos pelas interfaces do

91

componente, se h excesso de interfaces para desempenhar os servios oferecidos pelo componente e se o componente autocontido. Os atributos avaliados so: Adequao arquitetural verificar a adequao do componente com a arquitetura especificada; Cobertura verificar se a implementao do componente cobriu os servios oferecidos pelas suas interfaces; Excesso verificar se h excesso de interfaces no componente, para desempenhar os servios oferecidos por ele; Autocontido verificar se o componente realiza, de forma completa, a funo que ele desempenha, ou seja, as funcionalidades devem estar adequadas para o componente atender seu prprio propsito.

Interoperabilidade capacidade do componente de interagir com um ou mais componentes ou sistemas especificados. Para isso, verificada a compatibilidade dos dados controlados pelo componente: se est em conformidade com padres ou convenes (ex.: ASNI, XML etc.). O atributo avaliado : Compatibilidade de dados verificar se os dados controlados pelo componente esto em conformidade com padres ou convenes.

Conformidade capacidade do componente de estar de acordo com padres, convenes ou regulamentaes previstas em leis e prescries similares relacionadas sua funcionalidade. Para avaliar a conformidade, verificado se o componente est de acordo com padres internacionais ou regulamentaes previstas em leis. O atributo avaliado : Padronizao verificar se o componente est de acordo com padres internacionais ou regulamentaes previstas em leis.

Confiabilidade capacidade do componente de manter um nvel de desempenho especificado, quando usado em condies especificadas. Maturidade capacidade do componente de evitar falhas decorrentes de defeitos no software. Para avaliar a maturidade, verificada a volatilidade das verses, ou seja, o tempo de vida de uma verso no mercado, a evoluo do componente de acordo com o nmero de suas verses que tm sido comercializadas e pelo nmero de remoo de falhas de uma verso para outra.

92

Os atributos avaliados so: Volatilidade verificar qual o tempo de vida de uma verso no mercado; Evoluo entre verses verificar a evoluo do componente de acordo com o nmero de suas verses que tm sido comercializadas; Remoo de falhas verificar o nmero de remoo de falhas de uma verso para outra.

Usabilidade capacidade do componente de ser compreendido, aprendido, utilizado e atrativo para o usurio, quando usado sob condies especificadas. Operacionalidade capacidade do componente de possibilitar ao usurio oper-lo e control-lo. Para isso, avaliada a clareza com que as interfaces so declaradas, a taxa de complexidade para utilizar suas interfaces e o esforo necessrio para operar o componente por meio da configurao de seus parmetros. Os componentes so operados e controlados pelas suas interfaces (por exemplo, interfaces de gerncia, providas, requeridas e interfaces de controle). Os atributos avaliados so: Clareza das interfaces verificar o nvel de clareza com que as interfaces so declaradas; Complexidade verificar a taxa de complexidade para utilizar as interfaces do componente; Esforo de operao esforo necessrio para operar o componente por meio da configurao de seus parmetros.

Manutenibilidade capacidade do componente de ser modificado. As modificaes podem incluir correes, melhorias ou adaptaes do componente, devido a mudanas no ambiente e nos seus requisitos ou especificaes funcionais. Modificabilidade capacidade do componente de permitir que uma modificao especificada seja implementada. Para isso, verificada nesta subcaracterstica a adaptabilidade do componente, ou seja, o nmero de parmetros customizveis que o componente oferece, esforo de customizao, ou seja, a quantidade de parmetros que o componente oferece para customiz-lo com relao s suas interfaces oferecidas; tambm a habilidade de controle de mudana, ou seja, a facilidade do usurio de identificar a verso atual do componente. Os atributos avaliados so: Adaptabilidade verificar o nmero de parmetros customizveis que o componente oferece; Taxa de adaptabilidade verificar a quantidade de parmetros que o componente oferece para customiz-lo com relao s suas interfaces oferecidas;

93

Capacidade de controle de mudana verificar a facilidade com que o usurio identifica a verso atual do componente e suas verses compatveis.

Testabilidade capacidade do componente de permitir que ele possa ser validado quando modificado. Para avaliar a testabilidade, verificado se o componente permite a execuo de testes de inicializao, e tambm se o componente possui conjunto de casos de testes para validar sua funcionalidade. Os atributos avaliados so: Teste de inicializao verificar se o componente permite a execuo de testes de inicializao; Pacotes de teste verificar se o componente possui um conjunto de casos de testes para validar sua funcionalidade.

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

4.6.4 Componente integrado no SBC Para o Componente integrado no Sistema Baseado em Componentes - SBC, o modelo de qualidade se decompe nas seguintes caractersticas e suas respectivas subcaractersticas: Funcionalidade capacidade do componente de prover servios que satisfaam as necessidades especificadas, quando o componente for usado sob condies especficas. Acurcia capacidade do componente de prover, com o grau de preciso necessrio, resultados ou efeitos corretos, ou conforme acordados. Para verificar a acurcia, avaliada, nos componentes, a preciso dos resultados obtidos com o que foi especificado pelo requisito do usurio. O atributo avaliado :

94

Preciso verificar a preciso dos resultados obtidos com o que foi especificado pelo requisito do usurio.

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

Confiabilidade capacidade do componente de manter um nvel de desempenho especificado, quando usado em condies especificadas. Recuperabilidade capacidade do componente de restabelecer seu nvel de desempenho especificado e recuperar os dados diretamente afetados, no caso de uma falha. Para isso, avaliada a habilidade do componente em serializar seus dados e estado; assim, ele pode ser transferido para uma mquina diferente ou armazenado para persistncia. avaliada, tambm, a capacidade do componente de armazenar seu estado para uma futura recuperao; tambm se o componente prov qualquer interface para implementar transaes com suas operaes, e se o componente pode controlar situaes de erros, por meio de mecanismos implementados, como, por exemplo: excees. Os atributos avaliados so: Serializabilidade verificar se o componente capaz de serializar seus dados e estado de modo que ele possa ser transferido para diferentes mquinas ou armazenado para persistncia; Persistncia verificar se o componente possui a capacidade de armazenar seu estado para uma futura recuperao;

95

Transacionalidade verificar se o componente prov qualquer interface para implementar transaes com suas operaes; Tratamento de erros verificar se o componente pode controlar situaes de erros por meio de mecanismos implementados, por exemplo: excees.

Eficincia capacidade do componente de apresentar desempenho apropriado, relativo quantidade de recursos usados, sob condies especificadas (recurso diz respeito configurao de hardware e software). Em relao ao tempo capacidade do componente de fornecer tempos de resposta e de processamento, alm de taxas de transferncia, apropriados, quando o componente executa suas funes, sob condies estabelecidas. Para isso, avaliado o tempo de resposta que o componente gasta, desde a requisio que recebida at a resposta que ele envia. Tambm avaliada a sada que pode ser produzida com sucesso, em um dado perodo de tempo, e tambm medida a soma de entrada de informao que pode ser processada com sucesso, pelo componente, em um dado perodo de tempo. Os atributos avaliados so: Tempo de resposta verificar o tempo que o componente gasta, desde a requisio que recebida at a resposta que ele envia; Capacidade de emisso verificar a sada que pode ser produzida com sucesso, pelo componente, em um dado perodo de tempo; Capacidade de recepo verificar a soma de entrada de informao que pode ser processada com sucesso, pelo componente, em um dado perodo de tempo.

Em relao utilizao de recursos capacidade do componente de usar tipos e quantidades apropriados de recursos, quando o componente executa suas funes sob condies estabelecidas. Para isso, avaliada a soma de memria necessria para o componente operar, e o espao em disco utilizado pelo componente, incluindo o espao utilizado para armazenar seu cdigo e partes constituintes e o espao utilizado, temporria ou permanentemente, durante a execuo. Os atributos avaliados so: Memria requerida verificar a soma de memria necessria para o componente operar; Utilizao de disco verificar o espao em disco utilizado pelo componente, incluindo o espao utilizado para armazenar seu cdigo e partes constituintes e o espao utilizado, temporariamente ou permanentemente, durante a execuo.

96

O modelo de qualidade para componente de software foi objeto de um projeto FINEP - Financiadora de Estudos e Projetos -, desenvolvido pela equipe do CTI, e dever ser aplicado em ambiente produtivo para consolidao da sua adequao. Requisitos de qualidade e o processo de avaliao da qualidade sero assuntos do prximo captulo. Os requisitos de qualidade sero abordados para COTS, usabilidade na interface e documentao de usurio.

97

CAPTULO 5 Requisitos e avaliao da qualidade de software Com estudos e pesquisas bibliogrficas sobre o tema qualidade de produto de software e a identificao e explorao da necessidade de mercado, surge uma viso abrangente e profunda sobre o que deve ser a avaliao da qualidade de produto de software. Assim, em busca de experincia de organizaes nacionais e internacionais e de contatos com entidades nacionais representativas de desenvolvedores de software, tais como: ASSESPRO Associao das Empresas Brasileiras de Tecnologia da Informao, Software e Internet e SOFTEX Associao para Promoo da Excelncia do Software Brasileiro, surge uma viso de como implementar e aplicar um processo de avaliao da qualidade de produto de software, com o objetivo de verificar a qualidade deste em relao a requisitos de padres reconhecidos internacionalmente. Este captulo apresenta normas especficas para executar uma avaliao. Essas normas so relativamente recentes; a mais antiga, internacionalmente, de 1998, e as nacionais esto disponveis desde 2002. Apresenta, tambm, normas especficas para ajudar na especificao de requisitos de qualidade, sendo elas para documentao de usurio, pacotes de software e usabilidade na interface. Existem ainda poucos trabalhos prticos de avaliao de produto de software de mbito internacional, mas indicam uma tendncia na rea e mostram a utilizao das normas abordadas neste trabalho. uma rea de atuao muito recente, tanto da pesquisa como da aplicao.

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

98

O pblico-alvo da srie NBR ISO/IEC 14598 so desenvolvedores, adquirentes e avaliadores independentes, particularmente aqueles que so responsveis por avaliaes de produtos de software. Os resultados de avaliaes obtidos a partir da aplicao da srie NBR ISO/IEC 14598 podem ser utilizados por gerentes, desenvolvedores e mantenedores, para medir a aderncia aos requisitos e para fazer melhorias onde necessrias. Esses resultados tambm podem ser utilizados por analistas, para estabelecer o relacionamento entre medidas internas e externas. Resumidamente, a srie 14598 est organizada da seguinte forma:

Parte 1 Viso geral do processo de avaliao de produto em geral. Tambm explica o

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

Partes 2 e 6 Apoio ao processo de avaliao de produto. Esto relacionadas ao suporte e gesto

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

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

99

Figura 5.1 Relacionamento entre as partes da ISO/IEC 14598.

A elaborao da srie de normas NBR ISO/IEC14598 consolidou-se na estrutura mostrada na Tabela 5.1. Estudos e revises continuam sendo desenvolvidos de forma sistemtica, e as normas so revisadas e evoludas.
Tabela 5.1 Normas da srie ISO/IEC 14598: Status em 2009. Norma 14598-1 Ttulo resumido Assunto Estado Internacional Estado Nacional Norma, publicada em 2002

14598-2

14598-3

14598-4

14598-5

14598-6

Viso geral da estruturao dessa Avaliao de Produto de Software srie de Normas e dos processos Norma, publicada em 1999 Parte 1: Viso Geral de avaliao Avaliao de Produto de Software Atividades de planejamento e Parte 2: Planejamento e gerenciamento do processo de Norma, publicada em 2000 Gerenciamento avaliao. Avaliao de Produto de Software Atividades de avaliao durante o Parte 3: Processo para a equipe processo de desenvolvimento de Norma, publicada em 2000 de desenvolvimento software. Avaliao de Produto de Software Atividades de avaliao no Parte 4: Processo para o processo de seleo para Norma, publicada em 1999 comprador aquisio de software. Processo de avaliao, com Avaliao de Produto de Software definio das atividades, incluindo Parte 5: Processo para o Norma, publicada em 1998 relaes entre avaliador e Avaliador requisitante. Avaliao de Produto de Software Definio da estrutura de Mdulos Norma, publicada em 2001 Parte 6: Mdulos de Avaliao de Avaliao

Norma, publicada em 2003

Norma, publicada em 2002

Norma, publicada em 2003

Norma, publicada em 2002

Norma, publicada em 2004

100

As normas das sries 9126 e 14598 podem ser utilizadas em complementao, umas s outras, de acordo com o objetivo da avaliao. A norma NBR ISO/IEC 14598-1 contm conceitos de como avaliar a qualidade de software e define um modelo de processo de avaliao genrico; junto com as normas NBR ISO/IEC 14598-2 e NBR ISO/IEC 14598-6, estabelecem itens necessrios para o suporte avaliao; e junto com as normas NBR ISO/IEC 14598-3, NBR ISO/IEC 14598-4 e NBR ISO/IEC 14598-5, estabelecem processo de avaliao especfico para desenvolvedores, adquirentes e avaliadores de software, respectivamente. O relacionamento entre elas pode ser visto na Figura 5.2.

Figura 5.2 Relacionamento entre as sries 9126 e 14598.

A norma NBR ISO/IEC 14598-3, que trata do processo de avaliao para desenvolvedores de software, aplica-se a todo software e em todas as fases do ciclo de vida de desenvolvimento. Enfoca a seleo de indicadores, para prever a qualidade do produto final pela medio da qualidade de produtos intermedirios. Tambm enfoca a medio da qualidade do produto final. Uma organizao deve rever todos os requisitos e recomendaes indicados na norma: Requisitos organizacionais infraestrutura que permita a obteno de dados e modificaes nos processos baseados na anlise dos dados. Requisitos de projeto processo de desenvolvimento disciplinado, que permita o planejamento e a conduo das medies do software e sua avaliao; coordenar as atividades de avaliao com

101

suporte; modelo de desenvolvimento similar a projetos anteriores, na sua organizao de desenvolvimento com mesmo conjunto de atributos, deve tambm ser aplicado nos projetos, para permitir a anlise dos dados. Retroalimentao para a organizao muitos mtodos de anlise de dados requerem dados de projetos desenvolvidos anteriormente, sob condies similares e com requisitos de qualidade comparveis. A utilizao de dados obtidos em outras experincias recurso para melhorar o processo de avaliao e os mdulos de avaliao.

O desenvolvedor deve: tornar os dados coletados disponveis para a organizao, para seu uso em outros projetos de desenvolvimento; rever os resultados da avaliao e a validade do processo de avaliao, indicadores e medidas aplicadas; melhorar os mdulos de avaliao, incluir a coleta de dados sobre indicadores extras, de maneira a valid-los para uso posterior, quando necessrio.

Convm que seja aplicado um modelo de desenvolvimento similar ao que foi utilizado em projetos anteriores, na sua organizao; o mesmo conjunto de atributos seja aplicado nos projetos, de maneira a permitir a anlise dos dados. A norma NBR ISO/IEC 14598-4, que trata do processo de avaliao para Adquirentes de software, deve ser usada na aceitao ou seleo de um produto. A norma contm requisitos e orientaes para avaliao da qualidade de produto durante a aquisio de produtos de prateleira, produtos de software de uso geral ou modificaes em produtos de software existentes. O processo de avaliao nela descrito tambm auxilia a estabelecer regras de deciso sobre a aceitao de um nico produto, ou selecionar um produto entre produtos alternativos. A seguir ser abordado especificamente o processo de avaliao de qualidade para produto de software genrico; em seguida, o processo de avaliao contendo diretrizes sugeridas para avaliadores de qualidade de produto de software. 5.1.1 Norma NBR ISO/IEC 14598-1 e NBR ISO/IEC 14598-5 A norma NBR ISO/IEC 14598-1 fornece requisitos e recomendaes para implementao prtica da avaliao de produto de software. O processo de avaliao proposto pode ser usado para avaliar produtos j existentes ou produtos intermedirios, isto , em desenvolvimento. Pode ser utilizada por laboratrios de avaliao, fornecedores de software, compradores de software, usurios e entidades certificadoras, cada qual com seu objetivo.

102

Em termos de caractersticas de qualidade, pode ser usada a norma NBR ISO/IEC 9126-1, por ser uma norma reconhecida internacionalmente. Entretanto, o processo de mensurar diretamente essas caractersticas no prtico; necessrio o desdobramento dessas caractersticas em atributos que possam ser medidos e pontuados. Os atributos devem ser os mais objetivos possveis, para que a avaliao no sofra interferncia da opinio do avaliador. Para que a subjetividade da avaliao seja mnima, necessrio que o processo de avaliao seja repetvel, reproduzvel, imparcial e objetivo. Essas caractersticas so apresentadas na norma NBR ISO/IEC 14598-5, como caractersticas fundamentais esperadas do processo de avaliao, e so detalhadas a seguir: Repetvel a avaliao repetida de um mesmo produto, com mesma especificao de avaliao, realizada pelo mesmo avaliador, deve produzir resultados que podem ser aceitos como idnticos; Reproduzvel a avaliao do mesmo produto, com mesma especificao de avaliao, realizada por um avaliador diferente, deve produzir resultados que podem ser aceitos como idnticos; Imparcial a avaliao no deve ser influenciada frente a nenhum resultado particular; Objetiva os resultados da avaliao devem ser factuais, ou seja, no influenciados pelos sentimentos ou opinies do avaliador.

O processo de avaliao proposto pela norma NBR ISO/IEC 14598-1 inclui quatro etapas de avaliao, contendo dez atividades, como mostra a Figura 5.3.

103

Figura 5.3 Processo de avaliao segundo a norma NBR ISO/IEC 14598-1.

O processo de avaliao proposto pela norma NBR ISO/IEC 14598-5 semelhante ao da parte 1, incluindo uma etapa a mais para as etapas da avaliao, a saber: anlise de requisitos da avaliao, especificao da avaliao, projeto da avaliao, execuo da avaliao e concluso da avaliao, como pode ser visto na Figura 5.4. Nessa figura, so mostradas, adicionalmente, quais as entradas e sadas de cada etapa da avaliao.

104

Figura 5.4 Processo de avaliao segundo a norma NBR ISO/IEC 14598-5.

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

105

5) Comunidade de software, para identificar e validar os mtodos mais adequados de avaliao e, assim, aumentar a credibilidade das tcnicas; 6) Laboratrios de avaliao, para desenvolver uma abordagem de avaliao mais consistente. A anlise de requisitos visa definir os requisitos de qualidade do produto. Deve partir dos objetivos da avaliao que traduzem diretamente o interesse do requisitante da avaliao. A anlise define a profundidade, a abrangncia, o relacionamento da presente avaliao com outras, e os objetos a serem avaliados. b) Especificao da avaliao Nesta etapa, deve-se definir o escopo da avaliao e as medidas a serem executadas no produto submetido avaliao, nos seus vrios componentes. O nvel de detalhes na especificao da avaliao dever ser tal que, na sua base, a avaliao seja repetvel e reprodutvel. c) Projeto da avaliao Nesta etapa, devem ser documentados os procedimentos a serem usados pelo avaliador, para executar as medidas especificadas na fase anterior. O avaliador deve produzir um Plano de Avaliao, que descreve os recursos necessrios para executar a avaliao especificada, assim como a distribuio desses recursos nas vrias aes a serem executadas. d) Execuo da avaliao Nesta etapa, devem ser obtidos resultados da execuo de aes para medir e verificar o produto de software, de acordo com os requisitos de avaliao, como descrito na especificao da avaliao e como planejado no plano de avaliao. Ao executar essas aes, tem-se o rascunho do relatrio de avaliao e os registros da avaliao. e) Concluso da avaliao Nesta etapa, deve-se revisar o relatrio da avaliao e disponibilizar os dados resultantes da mesma para o requisitante da avaliao. Para uma avaliao profissional, esses dados so sigilosos e exclusivos ao requisitante da avaliao, qualquer publicao deles de sua inteira responsabilidade. No processo de avaliao, a identificao do produto a ser avaliado ainda preliminar. No decorrer das etapas do processo, mais informaes so obtidas, o que contribui para uma melhor identificao do produto a ser avaliado. Dvidas que podero ocorrer, dependendo da fase em que se encontrar a avaliao: Quando se trata de produto final, de acordo com o escopo da avaliao, poder ser selecionado todo o produto de software, ou eventualmente apenas alguns de seus componentes. A definio

106

ocorrer quando, no mnimo, os requisitos bsicos de qualidade estiverem definidos. Ser ento necessrio voltar a esta fase de definio de produtos para a sua complementao. Um fator que pode ser determinante na seleo dos componentes a serem avaliados a disponibilidade de mtodos de avaliao na organizao que ir realizar a avaliao. Por exemplo, suponha-se que um propsito de avaliao seja a escolha entre alguns produtos de mercado e que um dos requisitos de qualidade para essa escolha seja segurana de acesso a dados. Suponha-se, tambm, que a organizao no disponha de mtodos de avaliao desse requisito de qualidade. A no disponibilidade poder determinar que os componentes do produto que tratam especificamente de segurana de acesso sejam desconsiderados para efeito de avaliao, ou que esse requisito, caso seja muito importante, tenha que ser avaliado por outra organizao. Para o produto intermedirio, a definio de qual produto intermedirio ser avaliado mais complexa, pois depende, em primeiro, lugar do ciclo de vida de desenvolvimento adotado pela organizao e do estgio em que se encontram seus respectivos produtos. Alm disso, deve-se considerar que as medidas internas devem ser escolhidas de modo a refletir a futura qualidade externa do produto. Assim sendo, necessrio conhecer os requisitos externos, para ento definir que medidas internas so aplicveis aos produtos intermedirios, de modo a obter uma avaliao efetiva.

As primeiras vezes que essas definies de produtos intermedirios para avaliao so feitas, no se constituem em um trabalho simples. Porm, em termos prticos, a partir da existncia de um histrico de medidas aplicadas na organizao, provvel que exista uma referncia emprica a ser considerada, tanto para a seleo de medidas como para identificao dos produtos a serem avaliados. E, conforme j mencionado, a escolha inicial tende a ser refinada nas demais fases de avaliao.

5.2 Especificao da avaliao A fase de especificao da avaliao de um produto de software, neste contexto, traz consigo trs importantes conceitos: medio, pontuao e julgamento, como mostra a Figura 5.5.

107

Figura 5.5 Conceitos num processo de avaliao.

Medio a ao de aplicar uma medida de qualidade de software a um produto de software especfico. Pontuao a ao de transformar a medida obtida em um sistema numrico preestabelecido. Julgamento a emisso de um juzo sobre a qualidade do produto de software.

Por meio da medio de um produto de software, possvel conhecer qualitativamente o nvel de qualidade; aps a pontuao, possvel conhecer quantitativamente o nvel de qualidade. Assim, com a aplicao dos critrios de julgamento, possvel fazer o julgamento da qualidade. Para fazer medio em produto de software, necessria a utilizao de medida de qualidade de software. Esta, por sua vez, precisa de um Mtodo de avaliao e de uma Escala , previamente escolhidos, que podem ser usados para determinar o valor que uma particularidade recebe em um produto de software especfico. O Mtodo de avaliao um procedimento com que se descrevem as aes a serem realizadas por um avaliador, para obter o resultado da medio ou verificao especificadas, quando aplicadas num produto ou em componentes especificados de um produto de software. A Escala atribui rtulos numricos aos atributos de uma entidade, resultando a representao da fidedignidade do atributo. Ela um conjunto de valores com propriedades definidas. Exemplos de tipos de escalas so: Escala nominal que corresponde a um conjunto de categorias; Escala ordinal que corresponde a um conjunto ordenado de pontos de escala;

108

Escala de intervalos que corresponde a uma escala ordenada, com pontos de escala equidistantes; Escala de proporo que tem pontos de escala equidistantes e tambm um zero absoluto.

Medidas usando escalas ordinais ou nominais produzem dados qualitativos, e medidas usando escalas de intervalos ou de proporo produzem dados quantitativos. De acordo com a norma NBR ISO/IEC 14598-1, uma escala pode assumir diferentes nveis de pontuao, como mostra a Figura 5.6. O nvel de pontuao deve ter um valor-limite entre o que seja satisfatrio e insatisfatrio.

Figura 5.6 Nveis de pontuao para as medidas Fonte: NBR ISO/IEC 14598-1 (2002).

A qualidade de uma escala nominal, em sentido abrangente, descreve sua habilidade de refletir veridicamente uma medida obtida. Uma parte significativa desta construo envolve a semntica da escala os adjetivos, palavras, frases e construo das sentenas, que iro trazer tona a resposta correta sobre o assunto. Ao avaliar um produto de software, o avaliador sempre sofre influncias, sejam elas advindas de preferncias pessoais, de experincias anteriores, do conhecimento da rea de aplicao do software. Desse modo, necessrio que as medidas a serem feitas estejam claras e objetivas ao avaliador. A questo da subjetividade do avaliador deve ser eliminada na medida do possvel, procurando executar

109

uma avaliao que seja imparcial e objetiva, com a utilizao das diretrizes especificadas na norma NBR ISO/IEC 14598-5. Para realizar uma avaliao, no basta ter o modelo de qualidade definido por meio das caractersticas at os atributos ainda preciso estabelecer quais sero os critrios de aceitao, as medidas e os nveis de pontuao. Critrio de Aceitao predeterminao dos nveis de pontuaes considerados satisfatrios, ou no satisfatrios, para um atributo de uma entidade, de acordo com a norma NBR ISO/IEC145981, Medida e Nvel de Pontuao. Medida Compreende um mtodo e uma escala de medio. Por escala entende-se: um conjunto de valores com propriedades definidas; por medio, a determinao de um valor (que pode ser um nmero ou uma categoria) para um atributo de uma entidade. Nvel de pontuao pontuaes de uma escala ordinal, que utilizada para categorizar uma escala de medio.

A norma NBR ISO/IEC 9126-1 lembra a necessidade do uso de medidas e nveis de pontuao, alm de mostrar a relao existente entre eles, conforme mostra a Figura 5.7. No entanto, a norma no os define, pois eles podem variar de acordo com a organizao e/ou com a aplicao.

Figura 5.7 Valor medido e nvel de pontuao (NBR ISO/IEC 9126-1, 2001).

Dois outros fatores devem ser considerados numa avaliao: o grau de importncia de cada caracterstica de qualidade e o ponto de vista sob o qual o produto de software est sendo analisado. Esses fatores podem ser apontados como bastante subjetivos, mas possvel, numa avaliao comparativa de diferentes aplicaes de software, ponderar as caractersticas de qualidade utilizando um sistema de pesos proporcionais a sua importncia na rea de aplicao do software.

110

O grau de importncia de cada caracterstica de qualidade varia de software para software. Alguns exemplos atestam a variao: a confiabilidade mais importante para software de um sistema de misso crtica; a eficincia mais importante para software de sistema em tempo real; a usabilidade mais importante para software interativo. A norma aponta trs pontos de vista a serem considerados em uma avaliao da qualidade de software: do usurio, da equipe de desenvolvimento e do gerente. Cada um deles tem foco de interesse prprio: O usurio est interessado no uso do software, e no nos seus aspectos internos. Ele quer saber se as funes requeridas esto disponveis no software e quo eficiente, confivel e fcil de usar o produto. A equipe de desenvolvimento est interessada tanto na qualidade dos produtos intermedirios como na qualidade do produto final. O processo de desenvolvimento requer que o usurio e a equipe de desenvolvimento utilizem as mesmas caractersticas de qualidade de software, uma vez que elas se aplicam tanto para os requisitos como para a aceitao. A viso do gerente comercial. Ele est interessado na qualidade de forma geral, e no em caractersticas especficas de qualidade. Sua responsabilidade otimizar a qualidade, dentro das limitaes de custo, recursos humanos e prazos.

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

5.3 Requisitos para pacotes de software Entende-se por pacote de software o conjunto completo e documentado de programas fornecidos a diversos usurios para uma aplicao ou funo genrica. So exemplos de Pacotes de Software: processadores de texto, planilhas eletrnicas, bancos de dados, software grficos, programas para funes tcnicas ou cientficas e programas utilitrios, entre outros. essa classe especfica de produtos de software que conhecida como pacotes de software, e internacionalmente estabeleceu-se a sigla COTS Commercial Off-The-Shelf, ou seja,produto de software comercial de prateleira.

111

A norma NBR ISO/IEC 25051 aplicvel avaliao de pacotes de software na forma em que so oferecidos e liberados para uso no mercado COTS. Incluem-se como possveis usurios dessa norma: fornecedores que estejam especificando os requisitos para um pacote de software; projetando um modelo para descrever produtos; julgando seus prprios produtos; emitindo declaraes de conformidade; submetendo produtos certificao ou obteno de marcas de conformidade; entidades de certificao que pretendam estabelecer um esquema de certificao por terceira parte; laboratrios de teste, que tero de seguir as instrues durante a execuo de testes para certificao ou para emisso de marca de conformidade; laboratrios de avaliao, que executam medio e pontuao de requisitos de qualidade de software; entidades de credenciamento que credenciam entidades de certificao e laboratrios de testes e de avaliao; auditores, quando julgam a competncia de laboratrios de teste e de avaliao; compradores que pretendam comparar seus prprios requisitos com os aqui descritos; comparar os requisitos necessrios para executar uma determinada tarefa com a informao presente nas descries de produtos existentes; procurar por produtos certificados; verificar se os requisitos foram atendidos; usurios que se pretendam beneficiar com produtos melhores.

Essa norma estabelece os requisitos para pacotes de software, requisitos de documentao de teste, instrues para avaliao de conformidade de um pacote de software com relao aos requisitos preestabelecidos. Alguns produtos de software necessitam de requisitos adicionais: por exemplo, software em que o requisito de segurana seja um fator crtico; por exemplo, software com diferentes nveis de acesso de usurios. Nesses casos, devem ser includos outros requisitos importantes para sua determinada classe de aplicao. Os requisitos de qualidade estabelecidos nessa norma podem tambm ser utilizados para produtos de software que no sejam especificamente COTS. Isso pode ser feito verificando, entre os requisitos estabelecidos na norma, aqueles que podem ser aplicados para quaisquer produtos de software. A Figura 5.8 mostra a estrutura bsica do contedo da norma, relacionando os requisitos de qualidade para pacotes, para documentao de teste e avaliao de conformidade e tambm as atividades de avaliao de conformidade para um pacote de software.

112

Figura 5.8 Estrutura da norma NBR ISO/IEC 25051.

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

113

Servir como base para testes.

Este documento deve estar disponvel ao usurio, independentemente da aquisio do produto, por meio de um catlogo, de uma mdia digital e de apresentao ou qualquer outro meio disponvel que alcance esse objetivo. A descrio deve ser clara, compreensvel e harmnica com os outros documentos associados. A norma prope aspectos prticos e diretos, indicando o que deve conter a descrio. Na Tabela 5.2, esto os itens que compem os requisitos do documento Descrio de produto; nos requisitos propriamente ditos, h uma descrio observando quais so os mandatrios e os recomendveis, segundo a norma.
Tabela 5.2 Requisitos de qualidade para a descrio do produto. Item Disponibilidade Contedo 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.

Identificao e indicaes

Declaraes sobre funcionalidade

Declaraes sobre confiabilidade

Declaraes sobre usabilidade

Declaraes sobre eficincia Declaraes sobre manutenibilidade Declaraes sobre portabilidade Declaraes sobre qualidade em uso

b) Documentao de usurio

114

A documentao de usurio o conjunto completo de documentos, disponveis na forma impressa ou no, fornecidos para utilizao de um produto. Essa documentao deve incluir todos os dados para a instalao, para o uso da aplicao e para a manuteno do produto de software. A norma ISO 9127 pode ser utilizada para auxiliar nessa documentao. Os principais requisitos da documentao de usurio esto descritos na Tabela 5.3, com a mesma estrutura da tabela anterior. Os requisitos obrigatrios prevalecem nesse tipo de documentao.
Tabela 5.3 Requisitos de qualidade para a documentao do usurio. Item Completeza Correo Consistncia Inteligibilidade Apreensibilidade Operacionalidade Requisitos 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. A informao apresentada deve estar correta e sem ambiguidade. 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 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

Confiabilidade

Usabilidade

115

e organizao que facilitem uma viso geral das informaes, alm de procedimentos operacionais que o auxiliem: por exemplo, a reverso de uma funo executada e o uso de recursos de hipertexto em funes de auxlio, entre outros. Eficincia Deve estar em conformidade com as declaraes na descrio do produto. O software deve poder ser instalado; a instalao e a operao devem ser verificadas em todas as plataformas e deve fornecer meios de desinstalao. Manutenibilidade Deve estar em conformidade com as declaraes na descrio do produto. Portabilidade

Qualidade em uso Deve estar em conformidade com as declaraes na descrio do produto.

5.3.2 Requisitos para documentao de teste O objetivo da documentao de teste demonstrar a conformidade do software em relao aos requisitos de qualidade para o software. A documentao de teste deve incluir: plano de teste, descrio do teste e resultados dos testes, conforme descritos na Tabela 5.5.
Tabela 5.5 Requisitos da documentao de teste Item Requisitos gerais Requisitos

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

5.3.3 Instrues para avaliao de conformidade A avaliao da conformidade de pacotes de software pode ser vista como uma avaliao de terceiraparte. Sendo a terceira-parte um laboratrio com estruturas de certificao ou um laboratrio de avaliao interno, que seja independente do desenvolvedor. Este item especifica como um produto deve ser avaliado em relao aos requisitos de qualidade. Na Tabela 5.6, so mostradas essas especificaes, dividindo as instrues em fases e recomendaes.
Tabela 5.6 Instrues para avaliao de conformidade

116

Fases Pr-requisitos Atividades Processo de avaliao

Recomendaes Todos os itens descritos devem estar presentes e conformes Requisitos especificados na descrio, requisitos especificados na documentao e requisitos especificados no software devem ser avaliados. O fornecedor deve prover subsdios para avaliao de terceira-parte, obedecendo s atividades do item anterior. O relatrio deve conter: identificao do produto, data de encerramento da avaliao, descrio dos sistemas computacionais utilizados, documentos utilizados, resumo das atividades de avaliao, resumo dos resultados de avaliao de conformidade, resultado detalhado da avaliao de conformidade e relao de no conformidades. Esse documento deve ter suas pginas numeradas e o nmero total de pginas As partes alteradas nos documentos e software, as partes inalteradas, as que devem ser influenciadas e as que podem influenciar pelas partes alteradas ou pelas alteraes em um determinado sistema devem ser avaliadas como se fosse um novo software.

Relatrio

Avaliao na fase de acompanhamento

5.4 Outros requisitos de qualidade Produtos de software geralmente so destinados para um grande nmero de usurios e um diversificado tipo de usurios. V-se como importante que o produto fornea uma interface, isto , uma interao homem-mquina, adequada ao uso e uma documentao completa do usurio, para ser consultada. Assim, apresenta-se a seguir um conjunto de requisitos para a usabilidade na interface e um conjunto de requisitos para a documentao de usurio. 5.4.1 Requisitos de usabilidade na interface Projetos de interfaces com usurios e servio ao cliente geraro provavelmente mais valor agregado s empresas de computadores que a manufatura de hardware; e interfaces com usurios refletem um caminho para diferenciao de produtos, num mercado dominado pela tendncia dos sistemas abertos. H um tempo a interao entre o homem e o computador recebeu a designao de user friendly, porm este termo no o mais adequado, uma vez que: Usurios no precisam que as mquinas sejam amigveis, precisam de mquinas que no interfiram nos seus mtodos, quando eles tentam realizar suas tarefas. As necessidades do usurio podem ser descritas ao longo de uma nica dimenso, por sistemas que so mais ou menos amigveis. Na realidade, diferentes usurios tm diferentes necessidades, e um sistema que amigvel para um pode parecer muito tedioso para outro.

Segundo Nielsen (1993), em certo grau, usabilidade um conceito restrito, comparado com a ampla questo de aceitabilidade de sistema. Tal conceito basicamente, a constatao de que o sistema

117

suficiente para satisfazer todas as necessidades e requisitos dos usurios e outros potenciais stakeholders, tais como clientes e gerentes. Grande parte da aceitabilidade de um sistema de computador uma combinao da aceitabilidade social e da aceitabilidade prtica. Existe, atualmente, uma procura por regulamentao com relao usabilidade. Algumas voltadas para ergonomia em hardware, que tambm inclui usabilidade de software. Existem normas que esto sendo criadas, sero oficializadas em alguns pases e, certamente, tero grande impacto em outros. Pode-se utilizar usabilidade com a seguinte definio: Usabilidade medida na qual um produto pode ser usado por usurios especficos a fim de atingir objetivos especficos, como eficcia, eficincia e satisfao, em um determinado contexto de uso.

Usabilidade deve ser considerada como fator importante no projeto de produtos de software porque diz respeito a quanto os usurios dos produtos so capazes de trabalhar eficazmente, eficientemente e satisfeitos. A seguir sero apresentados alguns requisitos que auxiliam na especificao de uma interface, definidos no conjunto de normas da srie ISO 9241 (1996 e 1997). Assim, sero explicitadas trs orientaes, abordando: Princpios de dilogo, Orientaes sobre a usabilidade e Organizao da informao numa interface. Esses assuntos so tratados nas partes 10, 11, 12, respectivamente. a) Princpios de dilogo A norma ISO 9241-10, que define princpios de dilogo, estabelece sete princpios importantes para o projeto e avaliao de um dilogo com computador, ou seja, interface. So eles: Adequao tarefa um dilogo adequado para uma tarefa quando ele apoia o usurio na concluso efetiva e eficiente da tarefa; Autodescrio um dilogo autodescrito quando cada passo imediatamente compreensvel por meio da resposta do sistema ou explicado ao usurio, quando solicitado; Controlabilidade um dilogo controlvel quando o usurio pode iniciar e controlar a direo e ritmo da interao, at que seu objetivo tenha sido atingido; Conformidade com expectativas do usurio um dilogo est em conformidade com as expectativas do usurio, quando consistente e corresponde s caractersticas do usurio, tais como: conhecimento da tarefa, educao e experincia, e s convenes comumente aceitas; Tolerncia a erro um dilogo tolerante a erros se, apesar de erros de entrada evidentes, o resultado esperado pode ser obtido com pouca ou nenhuma ao corretiva do usurio;

118

Adequao individualizao um dilogo capaz de individualizao quando a interface pode ser modificada, para se adequar s necessidades da tarefa, preferncias individuais e habilidades do usurio; Adequao ao aprendizado um dilogo adequado para aprendizado quando auxilia e orienta o usurio a usar o sistema.

Com esses sete princpios, a interface de um produto de software ficar mais adequada ao usurio, permitindo melhor utilizao do produto. b) Orientaes sobre a usabilidade A norma ISO 9241-11 estabelece orientaes sobre a usabilidade, atributos de usabilidade e objetivos dos testes de usabilidade. Esta norma trata dos benefcios de medir a usabilidade em termos de performance e satisfao do usurio, que so medidas pela extenso com que as metas pretendidas so alcanadas, pelos recursos a serem gastos para alcanar as metas, e pela extenso com que os usurios avaliam o produto como aceitvel. Esta norma enfatiza que a usabilidade dos computadores depende do contexto de uso, e o nvel de Usabilidade alcanada depender de circunstncias especficas em que o produto usado. O contexto de uso consiste em usurios, tarefas, equipamentos, tais como hardware, software e materiais; ambiente fsico e social, que podem influenciar a Usabilidade de um produto num sistema de trabalho. Medidas de performance e satisfao do usurio avaliam o sistema de trabalho como um todo. Quando um produto o foco de interesse, essas medidas fornecem informaes sobre a usabilidade daquele produto num contexto de uso particular, fornecido pelo resto do sistema de trabalho. Esses efeitos de mudanas em outros componentes do sistema de trabalho, tais como a quantidade de treinamento ao usurio, ou melhoria da iluminao, podem ser medidos pela satisfao e performance do usurio. A usabilidade dos produtos pode ser melhorada com a incorporao de caractersticas e atributos conhecidos, para beneficiar os usurios em um contexto de uso particular. Para determinar o nvel de usabilidade obtida, necessrio medir a performance e a satisfao dos usurios que trabalham com o produto. Medida de usabilidade particularmente importante do ponto de vista da complexidade das interaes entre o usurio, os objetivos, as caractersticas das tarefas e os outros elementos do contexto de uso. Um produto pode ter significativamente diferentes nveis de usabilidade, quando usado em diferentes contextos. c) Organizao da informao A norma ISO 9241-12 estabelece a organizao da informao distribuda numa interface.

119

A apresentao da informao deve permitir ao usurio realizar tarefas de maneira eficiente, eficaz e com satisfao. Para atingir esse objetivo, os seguintes atributos devem ser considerados: Clareza o contedo da informao passado rpida e corretamente; Descrio a informao apresentada pode ser corretamente distinguida; Conciso os usurios no so sobrecarregados com informaes fora do contexto; Consistncia design nico, em conformidade com a expectativa do usurio; Deteco a ateno do usurio direcionada para a informao requerida; Legibilidade a informao fcil de ser lida; Compreensibilidade o significado claramente compreendido, sem ambiguidade, interpretvel e reconhecido.

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

5.4.2.1 Documento do usurio de software

Segundo a norma ANSI/IEEE 1063, documento do usurio de software o corpo do material que fornece informaes aos usurios; tipicamente na forma de material impresso ou armazenado em algum outro meio, no formato de um documento impresso. Os requisitos bsicos de documentao de usurio esto apresentados na Tabela 5.7

Tabela 5.7 Requisitos bsicos de Incluso de um Documento de Usurio do Software.

120

Volume nico Componente Pgina de Ttulo Restries Garantias ndice Lista de ilustraes Introduo Descrio do Pblico-alvo Aplicabilidade Objetivo Uso do Documento Documentos relacionados Convenes Relato de problemas Corpo do Documento Modo Instrutivo Modo de Referncia Condies de erro Anexos Bibliografia Glossrio ndice remissivo 8 Pginas ou Menos M M R O O R M R R R M R 1 1 R O M M 2 Mais que 8 Pginas M M R M O M M M M R M M 1 1 R O M M 2

Multivolumes Primeiro Volume M M R M O M M M M R* M M 1 1 R O M** M** M** Demais Volumes M M R M O R M R R R R R 1 1 R O M** M** M**

Legenda da Tabela 5.7 M Obrigatrio: deve ser includo quando a informao existe. O Opcional. R Referncia: includo numa seo ou referenciado onde a informao pode ser encontrada dentro do conjunto de documentos. * deve mostrar o relacionamento com os outros volumes do conjunto de documentos. ** Obrigatrio em pelo menos um dos volumes do conjunto de documentos, e referncia a informaes, nos demais volumes. 1 Todo documento tem um corpo; cada conjunto de documentos dever apontar as necessidades de modo instrutivo e de referncia do pblico-alvo.

121

2 Para documentos com 40 ou mais pginas, obrigatrio um ndice, sendo opcional para documentos com menos de 40 pginas.

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

5.4.2.2 Documentao de usurio e Informao de capa para compradores de pacotes de software

A norma ISO 9127 descreve a documentao do usurio e a informao de capa fornecida para compradores de pacotes de software. Segundo a norma, a documentao do usurio fornece ao usurio final toda a informao necessria para instalar e executar o software. Tipicamente, essa documentao, em forma impressa ou eletrnica, vem includa dentro do pacote de software; ela s estar disponvel ao usurio aps a compra do pacote de software. A informao de capa est disponvel para o possvel comprador, externamente ao produto, para que ele possa decidir sobre a aplicabilidade do software, mediante suas necessidades. Uma lista de itens recomendados para o contedo de uma documentao de usurio apresentada na Tabela 5.8.
Tabela 5.8 Itens de informao recomendados para um Documento de Usurio Item da informao Identificao do pacote Contedo do pacote Descrio funcional do software Instalao do software Categoria ESS ESS ESS ESS

122

Utilizao do software Informao tcnica do software Teste Informao contratual Glossrio ndice Comentrios de usurios

ESS CON OPT ESS CON CON OPT

Legenda da Tabela 5.8: ESS Informao essencial. OPT Informao opcional. CON Informao condicional, se necessria.

O objetivo da documentao do usurio fornecer, ao usurio final, informao suficiente para um claro entendimento dos seguintes assuntos: objetivo, funes e caractersticas do software; como instalar usar o software; e direitos e responsabilidades contratuais. Uma lista de itens recomendados para o contedo de uma informao de capa apresentada na Tabela 5.9. Alm da documentao de usurio, a norma sugere outro documento, denominado informao de capa, com o objetivo de permitir que potenciais compradores possam avaliar a aplicabilidade do software quanto s suas necessidades.
Tabela 5.9 Itens de informao recomendados para o contedo da Informao de capa. Item da informao Identificao do pacote Propsito e campo de aplicao Ambiente Entrada Sada Restries Instrues para uso Informao suplementar Informao contratual Contatos do fornecedor Categoria ESS ESS ESS OPT OPT CON OPT OPT ESS OPT

123

Itens fornecidos Padres e leis Certificao independente Cdigo do produto Preo Marca registrada

ESS OPT OPT ESS OPT OPT

Legenda da Tabela 5.9: ESS Informao essencial. OPT Informao opcional. CON Informao condicional, se necessria.

O objetivo deste captulo foi relatar as normas existentes para avaliao e requisitos de qualidade e mostrar como um produto de software pode ser avaliado, de acordo com requisitos estabelecidos em normas internacionais de qualidade. No Captulo 6, ser apresentada a metodologia de avaliao de produto de software, de acordo com os requisitos de qualidade e processo de avaliao definidos nas normas de qualidade apresentadas at aqui.

124

CAPTULO 6 Metodologia do processo de avaliao Descritas as normas reconhecidas internacionalmente com modelos e processos da rea de qualidade de produto de software, o prximo passo apresentar um mtodo sistemtico para avaliao. Essa metodologia est de acordo com o processo de avaliao estabelecido pela norma NBR ISO/IEC 14598-1 e 14598-5, com o foco de viso do usurio; foi desenvolvida no mbito do CTI e demonstrou ser uma metodologia til para avaliar produtos de software. No processo de avaliao, existem vrios agentes atuantes, ou pessoas com diferentes funes a serem exercidas em determinadas atividades desse processo, tais como: Requisitante da avaliao a pessoa ou entidade que tem interesse na avaliao; ela especificar o objetivo da avaliao e, finalmente, receber o resultado. Coordenador da avaliao a pessoa responsvel por conduzir o processo de avaliao como um todo. Avaliador a pessoa responsvel pela medio do processo. Profissional estatstico a pessoa de apoio estatstico, no momento de estabelecer a pontuao das medidas e a classificao dos dados resultantes da avaliao. Comit de julgamento em alguns casos de avaliao, pode ser necessrio montar um comit de profissionais (com conhecimento especfico na rea de aplicao do produto de software), para auxiliar na fase de pontuao e na fase de especificao dos critrios de julgamento, ajudando a estabelecer os juzos de valores das medidas.

Essas funes podem ser executadas por diferentes pessoas ou, em alguns casos, o coordenador da avaliao e o avaliador podem ser uma s pessoa. O processo de avaliao descrito neste capitulo composto de cinco fases, que apresentam uma estrutura bem definida: Estabelecer requisitos de avaliao, Especificar a avaliao, Projetar a avaliao e Executar a avaliao.

125

Concluso da avaliao.

Cada uma delas apresenta passos bem determinados, que podem garantir o resultado esperado do processo. A Figura 6.1 apresenta, de forma esquemtica, as atividades de um processo de avaliao genrico, que esto descritas na norma NBR ISO/IEC 14598-1, sendo que a concluso da avaliao uma sugesto de atividade proposta na parte 5. Esta figura mostra a importncia da existncia de um patrocinador e de um produto executvel para avaliao.

Figura 6.1 Processo de Avaliao segundo a norma NBR ISO/IEC 14598-1.

A seguir, ser apresentada cada uma das fases do processo de avaliao, com sugestes para programar as dez atividades nele definidas.

6.1 Estabelecer requisitos de avaliao O objetivo desta fase estabelecer o que se quer avaliar e o que se quer como resultado da avaliao. O requisitante da avaliao e o coordenador da avaliao tm atuao essencial nesta fase, para que, juntos, possam consolidar os requisitos da avaliao e esclarecer o resultado da avaliao a ser obtido.

126

Nesta fase do processo de avaliao, esto previstas as seguintes atividades: Estabelecer o propsito da avaliao; Identificar o tipo de produto a ser avaliado e Especificar o modelo de qualidade.

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

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

Funcionalidade. nfase (1 a 5): ________________________________ Confiabilidade. nfase (1 a 5): ________________________________ Usabilidade. nfase (1 a 5): __________________________________

127

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

Quais funes merecem maior dedicao durante a avaliao? Quantas janelas de interao de dados com o usurio o produto possui?

128

 2. 3.

Quem so os principais usurios do produto? Como o ambiente no qual o produto ser inserido?

Resp.:

Nvel de conhecimento exigido dos usurios em relao informtica. Resp.: Nvel de conhecimento exigido dos usurios em relao ao domnio da aplicao em si. Resp.: Quais so os principais componentes do produto que sero submetidos avaliao?
Documento Manual do Usurio Manual de Operao Procedimentos para Instalao Descrio do Produto (folder, catlogo, site, etc.) Outros. Quais? Impresso (no de pgs.) On Line (no de janelas)

4.

Existe massa de dados disponvel para a avaliao, ou seja, dados-exemplos para agilizar a avaliao? Resp.: Especificar os requisitos de hardware e software para executar o produto de software.
Rede (S/N): 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: Quais:

5.

6.1.3 Especificar o modelo de qualidade O modelo de qualidade adotado foi o definido pela norma NBR ISO/IEC 9126-1. A sugesto a definio do modelo de qualidade para avaliao de software, apresentado na seo 4.4, o qual estruturado por sete componentes, e cada um desses componentes com suas respectivas caractersticas de qualidade, como mostra a Figura 6.2:

129

Figura 6.2 Estrutura do modelo de qualidade.

Este modelo de qualidade pode ser visto como um modelo genrico para avaliar software, independente da sua rea de aplicao. Em determinados casos ele pode ser adaptado ao contexto do software a ser avaliado, dependendo do objetivo da avaliao explicitado pelo requisitante. Por exemplo, se o software no tiver embalagem ou descrio do usurio esses componentes podem ser desconsiderados.

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

6.2.1 Selecionar medidas De acordo com o modelo de qualidade definido na Seo 6.1.3, o prximo passo desdobrar as subcaractersticas de qualidade em atributos que possam ser medidos e pontuados. A metodologia adotada aqui foi a elaborao de uma lista de verificao, onde cada componente do software foi desdobrado em questes e itens que possam ser verificados e respondidos pelo avaliador. O desdobramento em itens tem o objetivo de criar uma escala adequada, facilitando o uso pelos

130

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

131

AP (Avaliao Prejudicada): para proposies que o avaliador no est em condies de avaliar, ou por falta de recursos, por falta de informaes, ou mesmo por falta de conhecimento especfico sobre o assunto abordado.

A atribuio dessa alternativa pouco desejvel, pois significa que os recursos de que se dispe so insuficientes. Exemplo: se a avaliao estiver sendo executada com um equipamento cuja resoluo grfica diferente da exigida, ento o avaliador dever optar pela alternativa AP (Avaliao Prejudicada). Podem existir outros tipos de respostas, dependendo da proposio lgica feita. H situaes em que a medida pode ser quantificada em faixas de valores, tais como: A (Algumas vezes), N (Nunca) ou M (Muitas), P (Poucas) ou M (Muitos), N (Nenhum), P (Poucos) ou A (Alguns), N (Nenhum), T (Todos).

A Tabela 6.1 mostra os sete componentes do modelo de qualidade e para cada componente, os atributos a serem avaliados.
Tabela 6.1 Subconjunto do modelo de qualidade Componente Instalao Caracterstica Completitude Portabilidade Documentao do usurio Completitude Usabilidade Funcionalidade Interface Usabilidade Funcionalidade Software Funcionalidade Eficincia Confiabilidade Portabilidade Descrio do Produto Embalagem Completitude Completitude Usabilidade Atributo Especificao dos requisitos de Hardware na Documentao do usurio Instrues para Instalao Identificao do produto Apresentao visual Acurcia Clareza Padres Internos Acesso Seletivo Interao com perifricos Backup Ambiente de Software Identificao do Produtor Identificaes Aspectos prticos

132

Funcionalidade Desinstalao Portabilidade

Aspectos de robustez Instrues

Exemplos de medidas podem ser baseados nos relatrios tcnicos ISO/IEC 9126-2, 9126-3 e 9126-4. Esta metodologia utilizou medidas com resultados qualitativos. A seguir so apresentados exemplos de medidas para cada atributo de qualidade da Tabela 6.1.

Componente: Instalao
Primeiramente, na fase da Instalao, mostra-se o atributo Especificao dos requisitos de hardware na Documentao do Usurio, com as seguintes medidas, em forma de proposies: Na documentao do usurio:
(_____) .1.

est especificado o tipo de processador necessrio para colocar o produto em uso. S=Sim; N=No.

(_____) .2.

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

(_____) .3.

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

(_____) .4.

esto especificados os dispositivos de sada de dados necessrios para colocar o produto em uso. Ex.: CD e DVD, alto-falante, fones de ouvido, placa de som, impressoras, plotters etc.; T=Todos; A=Alguns; N=Nenhum.

(_____) .5.

est especificado o tamanho do perifrico de armazenamento necessrio para colocar o produto em uso. S=Sim; N=No.

(_____) .6.

esto especificadas as placas de expanso necessrias para colocar o produto em uso. Ex.: placa de acelerao grfica; S=Sim; N=No.

Em outra medida, na fase da Instalao, mostra-se o atributo Instrues para Instalao, com as seguintes medidas em forma de proposies:

133

Se a instalao pode ser conduzida pelo usurio, a documentao do usurio:

(_____) .1.

apresenta instrues para instalao, disponveis antes de realiz-la. S=Sim; N=No.

Apresentando, as instrues de instalao:

(_____) .2.

orientam passo a passo como executar as aes da instalao; S=Sim; N=No.

(_____) .3.

esto claras quanto ao que deve ser realizado; T=Todas; A=Algumas; N=Nenhuma.

(_____) .4.

fornecem as informaes necessrias para instalar o software. S=Sim; N=No.

Componente: Documentao do usurio

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

o nome do produto; T=Todos; A=Alguns; N=Nenhum.

(_____) .2.

a verso ou data de criao do produto; T=Todos; A=Alguns; N=Nenhum.

A documentao do usurio on-line est identificada com:

(_____) .3.

o nome do produto; S=Sim; N=No.

(_____) .4.

a verso ou data de criao do produto; S=Sim; N=No.

Em outro exemplo de medida, no componente do produto de software Documentao do Usurio Impressa e/ou On-line, mostra-se o atributo Apresentao Visual, com as seguintes medidas, em forma de proposies:

134

A documentao do usurio impressa:

(_____) .1.

possui tamanhos de letra de fcil leitura; T=Todos; Q=Quase todos; A=Alguns; N=Nenhum.

(_____) .2.

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

(_____) .3.

apresenta textos, tabelas e grficos com uma diagramao bem distribuda; S=Sempre; A=Algumas vezes; N=Nunca.

A documentao do usurio on-line:

(_____) .4.

possui tamanhos de letra de fcil leitura; T=Todos; Q=Quase todos; A=Alguns; N=Nenhum.

(_____) .5.

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

(_____) .6.

apresenta textos, tabelas e grficos com uma diagramao bem distribuda. S=Sempre; A=Algumas vezes; N=Nunca.

Em outro exemplo de medida, no componente do produto de software Documentao do Usurio Impressa e/ou On-line, mostra-se o atributo Acurcia, com as seguintes medidas, em forma de proposies: Na documentao do usurio impressa:
(_____) .1.

foram encontradas evidncias de informaes incorretas. Por exemplo: informaes sobre convenes: unidades de medida, nome da moeda corrente, nmero de casas decimais, notao etc. M=Muitas; P=Poucas; N=Nenhuma.

Na documentao do usurio on-line:

(_____) .2.

foram encontradas evidncias de informaes incorretas. Ex.: informaes sobre convenes: unidades de medida, nome da moeda corrente, nmero de casas decimais, notao etc. M=Muitas; P=Poucas; N=Nenhuma.

135

Componente: Interface
No componente do produto de software Interface de Usurio, mostra-se o atributo Clareza, com as seguintes medidas, em forma de proposies: A interface:
(_____) .1.

apresenta erros gramaticais; M=Muitos; P=Poucos; N=Nenhum.

(_____) .2.

apresenta erros ortogrficos; M=Muitos; P=Poucos; N=Nenhum.

A interface:
(_____) .3.

destaca as palavras em outro idioma. Exemplos: entre aspas, itlico etc; T=Todas; A=Algumas; N=Nenhuma.

(_____) .4.

utiliza cdigos e terminologias no significativas. S=Sim; N=No.

O texto apresentado na interface:

(_____) .5.

d margem a interpretaes ambguas. M=Muitas; P=Poucas; N=Nenhuma.

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

ao idioma do mercado a que se destina o produto; S=Sim; N=No.

(_____) .2.

configurao de janelas; S=Sim; N=No.

(_____) .3.

formatao de cones; S=Sim; N=No.

(_____) .4.

s mensagens;

136

S=Sim; N=No.
(_____) .5.

apresentao de resultados ao usurio; S=Sim; N=No.

(_____) .6.

posio de um determinado boto que executa uma mesma funo em caixas de dilogo distintas. Ex.: boto Cancelar, Imprimir, OK etc.; S=Sim; N=No.

(_____) .7.

aos formatos dos campos de entrada de dados; S=Sim; N=No.

(_____) .8.

ao formato do cursor para uma mesma situao; S=Sim; N=No.

Componente: Software
No componente Software, mostra-se o atributo Acesso Seletivo, com as seguintes medidas, em forma de proposies: O software:
(_____) .1.

tem implementado o recurso para acesso seletivo. Ex.: permite acesso de usurios a determinadas tarefas por meio de senhas. S=Sim; N=No.

Possuindo o recurso para acesso seletivo:

(_____) .2.

compatvel com o tipo de informao que manipula; S=Sim; N=No.

(_____) .3.

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

(_____) .4.

permite que cada usurio altere sua prpria senha; S=Sim; N=No.

(_____) .5.

impede a entrada de usurios no autorizados. S=Sim; N=No.

137

Em outro exemplo de medida, no componente Software, mostra-se o atributo Interao com perifricos, com as seguintes medidas, em forma de proposies: Quando o software est interagindo com os perifricos (modem, impressora, scanner etc.):
(_____) .1.

o tempo de resposta compatvel com o perifrico; T=Todos; A=Alguns; N=Nenhum.

(_____) .2.

isso impede o uso de outras funes. T=Todos; A=Alguns; N=Nenhum.

Em outro exemplo de medida, no componente Software, mostra-se o atributo Backup, com as seguintes medidas, em forma de proposies: O software:
(_____) .1.

possui recursos para backup dos dados. S=Sim; N=No.

Possuindo recurso de backup, ele oferece flexibilidade para determinar:

(_____) .2.

o intervalo de tempo entre backups; S=Sim; N=No.

(_____) .3.

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

Finalmente, em outro exemplo de medida, no componente Software, mostra-se o atributo Ambiente de Software, com as seguintes medidas, em forma de proposies: O software:
(_____) .1.

pode ser instalado em outro ambiente operacional de software especificado na documentao do usurio (Ex.: Windows NT, MAC OS, Unix, etc.). Qual (is): S=Sim; N=No.

(_____) .2.

pode ser instalado em ambiente de rede. S=Sim; N=No.

Quando instalado em outro ambiente operacional de software especificado, o software:

138

(_____) .3.

executa do mesmo modo, tanto num ambiente quanto no outro, sem que o usurio possa perceber diferenas. S=Sempre; A=Algumas vezes; N=Nunca.

Componente: Descrio do Produto

No componente Descrio do Produto, mostra-se o atributo Identificao do Produtor, com as seguintes medidas em forma de proposies: No documento de descrio do produto est indicado:
(_____) .1.

o nome do produtor. Pode ser carimbo ou etiqueta impressa; S=Sim; N=No.

(_____) .2.

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

(_____) .3.

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

Componente: Embalagem
No componente Embalagem, mostra-se o atributo Identificaes, com as seguintes medidas, em forma de proposies: A embalagem possui corretamente:
(_____) .1.

o nome do produto; S=Sim; N=No.

(_____) .2.

a verso ou data de criao do produto; S=Sim; N=No.

(_____) .3.

o nome do produtor; S=Sim; N=No.

(_____) .4.

os requisitos de hardware necessrios para colocar o produto em uso; S=Sim; N=No.

(_____) .5.

os requisitos de software necessrios para colocar o produto em uso;

139

S=Sim; N=No.
(_____) .6.

identificao das tarefas ou funes que podem ser executadas, utilizando-se o software; S=Sim; N=No.

Em outro exemplo de medida, no componente Embalagem, mostra-se o atributo Aspectos Prticos, com as seguintes medidas, em forma de proposies: A embalagem:
(_____) .1.

possui um encaixe prtico e simples para abrir e fechar; S=Sim; N=No.

(_____) .2.

dificulta o manuseio da mdia; S=Sim; N=No.

(_____) .3.

dificulta o manuseio da documentao do usurio impressa; S=Sim; N=No.

(_____) .4.

acondiciona os outros componentes, de forma a dificultar seu manuseio. Ex.: hardlock, cabos etc. S=Sim; N=No.

Em outro exemplo de medida, no componente Embalagem, mostra-se o atributo Aspectos de Robustez, com as seguintes medidas, em forma de proposies: A embalagem:
(_____) .1.

quebra ou rasga com facilidade; S=Sim; N=No.

(_____) .2.

acondiciona os componentes, de forma a proteg-los contra choques, umidade. Ex.: apresenta, no seu interior, materiais, tais como: plstico de bolhas, espuma, isopor, papelo etc.; S=Sim; N=No.

(_____) .3.

contm a mdia embalada; S=Sim; N=No.

140

(_____) .4.

contm os manuais embalados separadamente dos outros componentes. Ex.: envelope, invlucro plstico etc.; S=Sim; N=No.

Componente: Desinstalao
Finalmente, na fase de Desinstalao, mostra-se o atributo Instrues para Desinstalao na Documentao do Usurio, com as seguintes medidas em forma de proposies: A documentao do usurio:
(_____) .1.

apresenta instrues para realizar sua desinstalao. S=Sim; N=No.

Apresentando, as instrues de desinstalao:

(_____) .2.

orientam, passo a passo, como executar as aes da desinstalao; S=Sim; N=No.

(_____) .3.

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

Dessa maneira, outras medidas podem ser definidas, desdobrando os atributos do modelo de qualidade. O Apndice A apresenta outros exemplos de medidas que esto agrupadas em forma de lista de verificao, seguindo este modelo de qualidade. 6.2.2 Estabelecer nveis de pontuao para as medidas Depois da seleo de medidas, o prximo passo estabelecer nveis de pontuao para os resultados obtidos pelas medidas. Tais resultados so do tipo nominal e, para que seja possvel sua pontuao, ser necessrio fazer um mapeamento das respostas tipo Nominal para valores numricos. Nesta metodologia, as medidas so questes que tm vrios tipos de resposta; para poder pontuar essas respostas, feito um mapeamento de cada tipo de resposta em um valor numrico. Cada atributo deve ter como resultado um valor numrico; esse valor deve ser normalizado, ou seja, a mdia obtida entre os resultados deve estar entre zero (0) e um (1). Isso importante, pois todos os atributos devem ter pesos iguais, mesmo que eles tenham um nmero de itens variveis. normal isso acontecer, pois cada atributo desdobrado em itens, para que se possa verific-lo de forma mais objetiva

141

e clara. Assim, num atributo que tem dois, trs, ou quatro itens, os valores numricos desses itens vo assumir valores proporcionais e estaro entre zero (0) e um (1), dependendo de quantos itens o atributo for composto. necessrio que a mdia desses itens, isto , que os valores numricos estejam entre zero (0) e um (1). Os itens que receberem como tipo de resposta NA ou AP devem ter um tratamento diferente, pois esse tipo de resposta no pode prejudicar a avaliao do produto. Nesse caso, atribudo um valor chamado missing, e no se atribui um valor numrico a tais itens. A seguir, relacionam-se alguns exemplos de tipos de respostas para cada tipo de questo, com seus valores numricos associados. Nas medidas em que as opes de respostas sejam S e N, e S seja uma proposio VERDADEIRA, e N seja uma proposio FALSA, os valores numricos so estabelecidos como na Tabela 6.2:

Tabela 6.2 Tipo de questo 01 Tipo de resposta AP N NA S Valores numricos * 00,00 * 01,00 Significado do tipo de resposta Avaliao prejudicada No No se aplica Sim

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

Nas medidas em que as opes de respostas sejam S, de SEMPRE; N, de NUNCA; e A, de ALGUMAS VEZES, os valores numricos so estabelecidos como na Tabela 6.4:

142

Tabela 6.4 Tipo de questo 03 Tipo de resposta A AP N NA S Valores numricos 00,50 * 00,00 * 01,00 Significado do tipo de resposta Algumas vezes Avaliao prejudicada Nunca No se aplica Sempre

Em outro exemplo de medida, em que as opes de respostas sejam M, de MUITAS; N, de NENHUMA; e P, de POUCA, os valores numricos so estabelecidos como na Tabela 6.5:

Tabela 6.5 Tipo de questo 04 Tipo de resposta AP M N NA P Valores numricos * 01,00 00,00 * 00,50 Significado do tipo de resposta Avaliao prejudicada Muitas Nenhuma No se aplica Poucas

Em outro exemplo em que as opes de respostas sejam A, de ALGUNS; N, de NENHUM; Q de QUASE TODOS; e T, de TODOS, os valores numricos so estabelecidos como na Tabela 6.6:
Tabela 6.6 Tipo de questo 05 Tipo de resposta A AP N NA Q T Valores numricos 00,33 * 00,00 * 00,66 01,00 Significado do tipo de resposta Alguns Avaliao prejudicada Nenhum No se aplica Quase todos Todos

143

Esses exemplos mostram como transformar a resposta de cada questo tipo Nominal para um valor numrico. Na Seo 6.2.3, explicado como obter a nota do Atributo; em seguida, a nota da Caracterstica e, finalmente, a nota do Componente, possibilitando quantificar a qualidade do software. 6.2.3 Estabelecer critrios para julgamento Julgar a qualidade significa, em essncia, interpretar os resultados das medies. O primeiro passo nesse sentido j foi realizado na Seo 6.2.2, quando se estabeleceram nveis de pontuao para as medidas. Em prosseguimento, seria desejvel obter concluses sobre qualidade, a partir do conjunto de valores obtidos da aplicao de medidas. A seguir, apresenta-se uma sugesto de procedimento para obter resultados sintticos de avaliao, descrito em algumas etapas: Etapa 1 mapear todos os resultados de medidas para uma escala [0, 1], em que 0 significa o pior resultado possvel, enquanto 1 representa o melhor. As medidas sugeridas nesta metodologia seguiram esse padro. Etapa 2 estabelecer pesos para as caractersticas de qualidade de software. Os pesos devem representar a importncia relativa de cada item, no julgamento global de qualidade do produto. Os valores devem ser obtidos, principalmente, a partir do requisitante da avaliao quem, em ltima instncia, deve dizer o que importante e o que no importante, na sua viso, sobre a qualidade do produto; e tambm a partir de profissionais especialistas na rea de aplicao do software. Etapa 3 calcular mdias ponderadas, usando os valores das medidas e os pesos das respectivas caractersticas. sugerido, aqui, usar os valores (de 1 a 5) atribudos para cada caracterstica, na questo 3 da seo 6.1.1. No se recomenda atribuir pesos aos atributos, uma vez que: i) os atributos no esto rigorosamente definidos na norma NBR ISO/IEC 9126-1; ii) um mesmo atributo pode ser utilizado para avaliar vrias subcaractersticas. possvel, assim, calcular mdias agrupando as medidas de cada caracterstica de qualidade. Por exemplo, calcular a mdia para usabilidade, dadas as medidas relacionadas com os atributos de usabilidade. O mesmo pode ser feito com cada caracterstica, separadamente. Etapa 4 finalmente, o processo pode ser repetido no nvel de Componente do so ftware, permitindo que se calcule um ndice ou nota, representando a qualidade do software.

O clculo de notas deve ser feito seguindo abordagem bottom-up do modelo de qualidade adotado na Figura 6.2, isto , primeiro obtendo o valor da nota para cada Item (que depende da resposta atribuda

144

ao produto, dada por cada avaliador); em seguida, a nota do Atributo; depois a nota da Subcaracterstica, da Caracterstica, do Componente e, finalmente, a nota do Produto de software. A seguir, apresenta-se uma descrio do algoritmo de clculo das notas, com suas respectivas frmulas matemticas, as definies e os clculos das notas, nos diferentes nveis do modelo de qualidade, conforme a Figura 6.2: a) Nota do Item Para i = 1...Ij , seja Ai a nota do item i, que pertence ao atributo j, da subcaracterstica k, da caracterstica l, do componente m. b) Nota do Atributo Para j = 1...Jk , definimos a nota do atributo j, da subcaracterstica k, da caracterstica l, do componente m:
I klm j
lm klm jklm

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

i 1

I klm j

B klm j

Cklm
d) Nota da Caracterstica

j 1

J klm

Para l = 1...Lm, definimos a nota da caracterstica l, do componente m:

K lm

Cklm

Dlm
e) Nota do Componente

k 1

K lm

Para l = 1...Lm, seja pl o peso da caracterstica l, do componente m. Para m = 1...M, definimos a nota do componente m:

145

Lm

plm Dlm plm

Em

l 1 Lm l 1

f)

Nota do Produto Para m = 1...M, seja qm o peso do componente m. Definimos a nota do produto:
M

qm Em P
m 1 M

qm
m 1

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

6.3 Projetar a avaliao O objetivo nesta fase produzir o plano de avaliao. Esse plano informa qual mtodo de avaliao ser utilizado, com instrues de como utiliz-lo, e especifica os recursos necessrios, juntamente com o cronograma das aes, para o avaliador. O plano de avaliao deve conter, explicar e definir o mtodo de avaliao, para que o avaliador possa executar a avaliao completamente. 6.3.1 Mtodo de avaliao O mtodo de avaliao, aqui apresentado, composto por uma lista de verificao, como do Apndice A, que contm, tambm, um conjunto de instrues a serem dadas ao avaliador, e por um modelo de

146

relatrio que o avaliador pode redigir como o exemplo do Apndice C, relatando os pontos a serem melhorados e os pontos que esto atendendo os requisitos de qualidade, de acordo com as respostas s questes da lista de verificao. 6.3.2 Instrues ao avaliador O avaliador deve ser uma pessoa treinada no mtodo, conhecer todos os seus atributos. interessante, tambm, que o avaliador seja uma pessoa que tenha o seguinte perfil: conhecedor de informtica, seja uma pessoa detalhista, disciplinada e organizada. desejvel que conhea o domnio de aplicao do software, porm, caso isso no seja possvel, deve haver um treinamento especfico com especialistas da rea de aplicao. A seguir, so sugeridas algumas instrues ao avaliador: Cada atributo composto por itens de atributo, que variam em termos de quantidade. Todos os itens de todos os atributos devem ser verificados e respondidos. As respostas sero atribudas aos itens. Todos os itens com respostas desfavorveis (i.e. aspectos a serem melhorados) para o produto, ou com respostas NA ou AP, devem ser justificados por escrito. A justificativa dever estar identificada com o nmero do atributo e do item, para ajudar na elaborao do relatrio de avaliao. Algumas questes necessitam de anotaes do avaliador como complemento da resposta dada; essas anotaes devero ser documentadas, logo em seguida da questo. Caso o produto de software apresente erros e/ou falhas durante sua avaliao, o avaliador dever anotar os passos realizados que tiveram como conseqncia o erro ou a falha ocorrida, alm de anotar o procedimento adotado para solucion-los, caso o tenha identificado. Isso possibilitar a reproduo posterior do erro ou da falha. conveniente imprimir as telas com mensagens de erro. Caso o avaliador no se sinta seguro para avaliar uma questo, anotar e prosseguir a avaliao, avaliando somente quando sentir segurana da resposta a ser atribuda na questo. Algumas questes, para serem avaliadas, requerem um conhecimento maior do produto. Para isso, importante o avaliador manipular o produto, ler a documentao, executar as funes que o produto possui, navegar pelas janelas, enfim, criar familiaridade com o produto.

147

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

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

6.4.1 Obter as medidas Para medio, as medidas selecionadas so aplicadas ao produto de software pelo avaliador. Como resultado, obtm-se a lista de verificao, preenchida com as notas de cada questo; posteriormente ser calculada a pontuao das medidas, como sugerido na seo 6.2.2. Nesta fase importante que o avaliador siga um procedimento de avaliao estabelecido, para no se perder, e que consiga obter as medidas de forma correta. Assim, so sugeridas as seguintes aes: A) Aes iniciais da avaliao: Com o produto em mos, identificar os folhetos e documentos que vieram dentro e fora da embalagem, ou que foram obtidos no site. Ler atentamente as informaes referentes aos requisitos mnimos de hardware e software, constantes em folhetos, embalagem, documentos e site, caso existam. Com os requisitos mnimos de hardware e software claros, verificar se o equipamento a ser utilizado para a avaliao atende a essas exigncias. Finalizar as atividades, preenchendo o formulrio de Identificao da Avaliao com as seguintes informaes: Data inicial da avaliao, Avaliador, Produtor, Produto, Verso do produto, Descrio resumida do produto, Material apresentado, Condies de Instalao e Operao, conforme documentao e dados disponveis do equipamento utilizado na avaliao. Esse formulrio est apresentado no Apndice B.

148

B) Elaborao do relatrio da avaliao Elaborar o relatrio de avaliao como sugerido no Apndice C. As observaes e justificativas das atribuies que foram anotadas na lista de verificao so muito importantes para a elaborao do relatrio de avaliao, pois nela devero ser registrados: aspectos considerados positivos. aspectos a serem revistos, com recomendaes.

C) Aes finais da avaliao O Avaliador dever checar se os campos do Apndice B Identificao da Avaliao: nome do Produto, Verso e nome do Produtor, que foram previamente preenchidos, correspondem realidade apresentada pelo produto; caso tenha havido alguma inconsistncia, atualizar esses campos. Preencher, no formulrio Identificao da Avaliao, a data final da avaliao.

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

6.5 Concluso da avaliao Esta fase foi includa aqui, seguindo a definio do processo de avaliao da norma NBR ISO/IEC 145985. O objetivo nesta fase disponibilizar o resultado da avaliao para o requisitante da avaliao. O coordenador da avaliao dever finalizar a avaliao com as seguintes atividades:

149

Arquivar os itens utilizados durante a avaliao: Relatrio de avaliao do produto de software; Lista de verificao completamente preenchida;

Finalizar essa tarefa, entregando ao requisitante da avaliao: Produto de software nas mesmas condies recebidas, incluindo folhetos e anexos impressos; Cpia do relatrio de avaliao do produto de software; Declarao do resultado da avaliao.

Esta concluso finaliza as cinco fases do processo de avaliao de produto de software, sendo que esta metodologia um exemplo de como avaliar sistematicamente e no se limita a criatividade ou necessidade de pessoas envolvidas em avaliaes. Cada demanda pode desenvolver seu prprio mtodo de avaliao, o que no pode acontecer a avaliao ser conduzida sem uma sistemtica documentada. Essa metodologia composta de uma lista de verificao, um manual para o avaliador e um modelo de relatrio de avaliao. A lista de verificao tem medidas que so obtidas por meio de um conjunto de alternativas, isto , ela utiliza escalas nominais como explicado no item 5.2 deste livro. Assim o resultado de uma avaliao um relatrio com resultados qualitativos sobre o nvel de qualidade do produto. Adicionalmente uma anlise estatstica pode ser efetuada atribuindo notas geradas pela transformao da escala nominal em valores numricos normalizados, podendo ser obtida uma nota de acordo com o item 6.2.3. A questo de associar escala nominal a valores numricos para que se executem operaes matemticas tem sido polmica na literatura, assim como o modelo de qualidade e as medidas da norma ISO/IEC 9126 (AL-KILIDAR, 2005). Exemplos de medidas para avaliar a qualidade de produto de software so encontrados nos relatrios tcnicos da ISO/IEC 9126 nas partes 2, 3 e 4. A parte 2 contm exemplos de medidas externas do software, a parte 3 contm exemplos de medidas internas e a parte 4 exemplos de medidas de qualidade em uso. A metodologia aqui exposta no pretende dar nfase apenas a medidas para produtos de software e sim apresentar uma viso geral do estagio em que se encontra o produto. A partir dessa avaliao, melhorar o produto para satisfao e conforto do usurio. Isso pode ser obtido no relatrio de avaliao quando se considera os pontos fortes e os pontos a serem melhorados em cada uma das caractersticas associadas aos componentes do software. Isso pode ser visto no apndice E Relatrio de avaliao do software Easy Learn. Em casos onde existe apenas um produto a ser avaliado, no h comparao a ser feita, portanto no h necessidade de notas, pois o objetivo conhecer qualidade do produto de forma global. Em casos onde existe a necessidade de uma comparao entre produtos conveniente fazer uma pontuao das

150

notas dos produtos para facilitar a classificao dos produtos, um exemplo disso foi efetuado no prmio Assespro (ROCHA, 2001).

6.6 Processo de avaliao para componentes de software Este item apresenta uma metodologia de processo de avaliao para componentes de software seguindo os passos do processo de avaliao da norma NBR ISO/IEC 14598-1 e 14598-5. O modelo de qualidade utilizado neste processo de avaliao foi definido no item 4.6. 6.6.1 Estabelecer os requisitos da avaliao

A.

Propsito da avaliao

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

B.

Tipos de produtos a serem avaliados:

Foram identificados trs tipos de produtos a serem avaliados:

Componentes de software artefatos autocontidos, claramente identificveis, que descrevem ou

realizam uma funo especfica e tm interfaces claras, em conformidade com um dado modelo de arquitetura de software, documentao apropriada e um grau de reutilizao definido. Por se tratar de componentes de software a serem disponibilizados em um repositrio, tero as caractersticas comerciais

151

dos produtos COTS; portanto, devem ser acompanhados pelos seguintes artefatos: documento de descrio do componente e documentao para sua utilizao.

Descrio de Componente A descrio de componente que define o produto faz parte do conjunto
de documentao do componente. Ela fornece informaes sobre a documentao para sua utilizao e sobre o componente propriamente dito. Os principais objetivos da descrio de componente so: Ajudar o integrador em potencial, na avaliao da adequao do componente s suas necessidades de utilizao. Por extenso, ela tambm fornece informaes para venda; Servir como base para testes. A descrio de componente deve estar disponvel para pessoas interessadas no componente, antes da aquisio do mesmo, e deve seguir todos os requisitos aplicveis para descrio de produto da norma NBR ISO/IEC 25051.

Documentao para uso A documentao para uso deve conter as informaes necessrias e
subsdios para a construo da documentao do sistema a ser construdo. Devem ser completamente descritos nessa documentao os seguintes itens: todos os servios e as funes de negcio estabelecidos na descrio de componente; todas as caractersticas e elementos do modelo de componentes presentes no componente, a saber: interfaces providas, interfaces requeridas, interfaces de gerncia, eventos recebidos, eventos enviados, propriedades internas ou externas, e interface de acesso; todas as facilidades oferecidas pelo componente, as variveis de configurao ou customizao e a manipulao das propriedades que permitem a configurao do estado dos componentes; todas as funes do componente a que os usurios tiverem acesso devem ser completamente descritas na documentao.

C.

Definio do modelo de qualidade

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

6.6.2 Especificao da avaliao Nesta etapa, deve-se definir o escopo da avaliao e as medidas a serem executadas no produto submetido avaliao. O nvel de detalhes na especificao da avaliao deve ser tal que a avaliao seja repetvel e reprodutvel.

A.

Medidas:

As medidas devem ser desdobradas a partir dos atributos da qualidade externa de componentes de software; devem considerar o contexto de uso do sistema, lembrando que a avaliao deve ser em laboratrio com ambiente adequado de execuo.

152

B.

Estabelecer nveis de pontuao

Os nveis de pontuao dependem dos tipos de medidas a serem adotadas. Exemplo disso j foi abordado na seo 6.2.2.

C.

Critrios de julgamento

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

153

Destino dos dados e documentos de avaliao: Para uma avaliao profissional, esses dados so sigilosos e exclusivos ao requisitante da avaliao, sendo qualquer publicao deles de sua inteira responsabilidade. Relatrio de avaliao entregue formalmente: os documentos submetidos avaliao devem retornar ao requisitante, ou ser arquivados por um tempo determinado, ou devem ser destrudos de maneira segura; o relatrio de avaliao e os registros de avaliao devem ser arquivados por um tempo determinado; todos os outros dados devem ser arquivados por um tempo determinado ou destrudos de maneira segura.

O objetivo foi mostrar um processo de avaliao especfico para componentes de software. Dessa forma, outros exemplos de avaliao poderiam ser apresentados: um deles a avaliao especfica da caracterstica de qualidade usabilidade; outro exemplo seria a avaliao focada por categorias de produtos ou por domnios de aplicao. Este captulo procurou ressaltar a importncia de executar avaliao e produto de software seguindo um processo definido e de forma sistemtica, para garantir a repetibilidade, a reprodutibilidade, a imparcialidade e a objetividade, caractersticas estas fundamentais para esse processo.

154

CAPTULO 7 Avaliao de um software 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

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

7.2 Processo de avaliao O processo de avaliao aplicado no Easy Learn foi realizado seguindo-se as mesmas etapas recomendadas pela norma NBR ISO/IEC 14598-1 e 14598-5 (NBR ISO/IEC 14598-1 e 14598-5, 2002), como detalhadas a seguir: 7.2.1 Estabelecer requisitos de avaliao Foi levantado o objetivo e a expectativa com relao avaliao. O objetivo foi conhecer um software adquirido comercialmente; a expectativa foi avaliar o quanto esse software est em conformidade com as normas de qualidade. O requisitante foi o gerente do projeto de avaliao, que gostaria de ter um exemplo disponibilizado publicamente.

A) Estabelecer o propsito da avaliao

11

O nome fictcio Easy Learn foi usado para preservar a integridade do software.

155

Apresenta-se, a seguir, o formulrio preenchido pelo requisitante da avaliao, que tem como objetivo esclarecer o objetivo da avaliao para ambas as partes: o requisitante da avaliao e o avaliador. Nome do Produto: Easy Learn Verso: 2.0 1. Qual domnio da aplicao do produto? Software educacional para ensino e aperfeioamento do idioma ingls. O Software composto dos seguintes mdulos: Easy Learn, Poliglota e o Tradutor. 2. Qual o seu objetivo em relao avaliao?

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

Funcionalidade. nfase (1 a 5): 4 Confiabilidade. nfase (1 a 5): 3 Usabilidade. nfase (1 a 5): 5 Portabilidade. nfase (1 a 5): 1 Eficincia. nfase (1 a 5): 3 Completitude. nfase (1 a 5): 3
B) Identificar tipos de produtos a serem avaliados
A seguir apresenta-se o formulrio preenchido pelo requisitante da avaliao, para poder especificar o tamanho do software a ser avaliado. Nome do Produto: Easy Learn Verso: 2.0 1. Descrio geral do produto: De quantas funes o produto composto? Resp.: Aproximadamente 70 funes, que so acessadas pelo usurio por meio da interface. Quais so as principais tarefas do produto?

156

Resp.: Realiza tradues; treina a pronncia das palavras; realiza exerccios; inclui palavras no dicionrio e/ou utiliza dicionrios extras; fornece dicas de utilizao de gramtica, com tabelas de gramticas; fornece sinnimo das palavras selecionadas; procura palavras, mesmo sem saber como escrev-las, por meio de rimas; ditado; anagramas. Quais funes merecem maior dedicao durante a avaliao? Resp. As funes do mdulo Easy Learn. Quantas janelas de interao com o usurio o produto possui? Resp.: Aproximadamente 80 janelas. Quem so os principais usurios do produto? Resp.: Indivduos ou grupos de pessoas que queiram aprender o idioma ingls. 2. Como o ambiente no qual o produto ser inserido Nvel de conhecimento exigido dos usurios em relao informtica. Resp.: Conhecimento bsico de operao do sistema operacional Microsoft Windows. Nvel de conhecimento exigido dos usurios em relao ao domnio da aplicao em si. Resp.: No exigido nenhum requisito do domnio de aplicao. 3. Quais sero os principais componentes do produto que sero submetidos avaliao? Marque-os. (Informar o tamanho - nmero de pginas ou de janelas, caso seja a documentao on-line)

Documento

Manual do Usurio Manual de Operao Procedimentos para Instalao Descrio do Produto (folder,
catlogo, site,...) Outros. Quais? Guia de Referncia Rpida

Impresso (no de pgs.) 50 X 1 Os dados esto na prpria embalagem 04

On Line (no de janelas) 80 X 1 X X

4. Existe massa de teste para a avaliao? (so dados exemplos para agilizar a avaliao?) Resp.: No necessrio, o prprio usurio insere dados durante a utilizao e avaliao do produto. 5. Especificar os requisitos de hardware e software para executar o produto?

Rede (S/N): N Quais: Processador: disponvel no mercado Ambiente Operacional: Windows NT ou superior Hardware Adicionais (impressora, scanner, hardlock..) : Microfone e placa de som (opcional) 157

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

A) Selecionar medidas
As medidas selecionadas para esta avaliao so as contidas na lista de verificao do Apndice A.

B) Estabelecer nveis de pontuao para as medidas

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

C) Estabelecer critrios para julgamento 158

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

10 Nvel Alto 7 Nvel Mdio 5 Precisa de Ajustes Software OK!

Nvel Baixo

Inaceitvel

Figura 7.1 Critrios de aceitao

7.2.3 Projetar a avaliao Foi definido o plano de avaliao:

159

a) o mtodo utilizado: lista de verificao do Apndice A; b) a equipe de avaliao foi composta por uma pessoa conhecedora das normas e do mtodo. O tempo de avaliao foi estimado em 20 horas, durante um perodo de cinco dias. O resultado da avaliao foi uma lista de observaes referentes aos atributos avaliados. Esse resultado foi apresentado no relatrio da avaliao do Easy Learn, como no Apndice E 7.2.4 Executar a avaliao O avaliador instalou o produto e, seguindo rigorosamente as instrues constantes na documentao impressa ou on line do produto, exercitou todas as funes disponveis na verso e finalmente desinstalou.

A) Obter as medidas
Para esta atividade foi seguido o procedimento de avaliao sugerido na metodologia. Como resultado, tem-se a Identificao da Avaliao, de acordo com o modelo apresentado no Apndice B. Concluda a obteno das medidas, o avaliador elaborou o relatrio da avaliao do produto, como sugerido no modelo de relatrio de avaliao apresentado no Apndice E.

B) Comparar com critrios

Aps a avaliao, interessante que se faa a classificao grfica dos resultados da avaliao, para ter uma viso geral do comportamento do produto. Isso foi feito por meio da metodologia estatstica Anlise Descritiva, que verifica e mostra a proporo dos itens atendidos em relao ao conjunto total dos itens das medidas estabelecidas na lista de verificao, em forma de nota entre 0,0 e 100,0, de cada componente do software. O grfico foi gerado pelo software Excel, do Windows 98 da Microsoft. O grfico mostrado na Figura 7.2.

160

Figura 7.2 Notas obtidas do Easy Learn

C) Julgar os resultados
Como pde ser observado, o desempenho do software teve a seguinte pontuao: Embalagem atingiu o nvel Alto, com nota 75. Os componentes documentao e interface obtiveram as notas 60 e 57.6, respectivamente, atingindo o nvel mdio da escala da Figura 7.1. Os componentes descrio do produto e software obtiveram as notas 45.5 e 36.7, respectivamente, atingindo o nvel baixo. A nota final, como um todo, foi de 55; essa nota, de acordo com o critrio de aceitao, atingiu o nvel mdio. Isso significa que o software precisa de ajustes, ainda no pode considerar-se que esteja de acordo com os requisitos mnimos exigidos pelas normas de qualidade. 7.2.5 Concluso da avaliao Nesta fase so arquivados a lista de verificao, preenchida pelo avaliador, e o relatrio da avaliao. Com relao ao resultado da avaliao de qualidade do Easy Learn, fortemente sugerido que sejam implementados os aspectos a serem revistos, documentados no relatrio de avaliao apresentado a seguir. Comparando a nota dos componentes do Easy Learn da Figura 7.2 com os aspectos de destaque positivo e aspectos a serem revistos do relatrio de avaliao, pode-se constatar:

161

O componente Embalagem, que alcanou a nota 75, obteve vrios destaques positivos e apresentou poucos aspectos a serem revistos; Os componentes Documentao do usurio e Interface obtiveram as notas 60 e 57.6, respectivamente, e no Relatrio de avaliao podem ser observados vrios aspectos a serem melhorados; O componente Descrio do Produto obteve a nota 45.5; apesar de o produto apresentar a maioria das identificaes e declaraes exigidas pela norma, ainda faltaram algumas, consideradas importantes; O componente Software obteve a nota 36.7; primeira vista, parece ser um valor baixo principalmente por este software j ser comercializado. Pelo Relatrio de avaliao, pode-se constatar que ele possui todas as funes declaradas, porm ainda apresenta falhas durante a execuo das funes. Infelizmente, ainda no se tem uma referncia pblica na qual seria possvel fazer uma comparao entre produtos de software. Poucas so as empresas desenvolvedoras de software que conhecem e aplicam os requisitos de qualidade definidos nas normas. Entretanto, os esforos governamentais e de associaes tm incentivado e patrocinado as empresas nacionais a melhorarem seus produtos para atender a competitividade dos mercados nacional e internacional.

162

Consideraes finais O objetivo deste livro foi apresentar, principalmente, as normas de qualidade de produto de software e as experincias de aplicaes dessas normas. Adicionalmente, o livro tem a sutil pretenso de tratar dos seguintes assuntos: i) ressaltar a importncia da qualidade de produto de software mediante o atual movimento para a melhoria da qualidade de processos; ii) divulgar os modelos para qualidade de produto de software; iii) conscientizar as pessoas envolvidas, como fornecedores e desenvolvedores, para melhorar o software brasileiro e para compradores e usurios de software saberem exigir seus produtos com o mnino de qualidade em relao padres reconhecidos internacionalmente. A qualidade de produto de software um assunto trabalhoso, fica difcil explicitar por meio de requisitos de qualidade as necessidades implcitas e explcitas do usurio. Nesse sentido, o grande benefcio da norma NBR ISO/IEC 9126-1 apresentar um modelo de qualidade bsico e genrico para a qualidade de produtos de software. O modelo pode ser desdobrado em atributos de qualidade para as caractersticas especficas correspondentes a cada produto, caso necessrio. Esse assunto de difcil compreenso e os modelos prticos aqui apresentados mostram exemplos de como tratar dessa questo. O livro apresenta a ideia de qualidade genericamente, qualidade de produto de software, produto esse com caractersticas to especiais que se tenta classific-los para melhor estud-los. Essa prtica facilita a construo de modelos de qualidade com caractersticas especficas para cada categoria. Modelos de qualidade so ferramentas teis que surgiram para ajudar e entender um produto com caractersticas to peculiares, num mercado onde a demanda grande e os envolvidos muitas vezes no sabem como descrever o que necessitam e desejam. Algumas normas at sugerem modelos de qualidade, outros modelos so criados especificamente para alguns tipos de produtos e necessrio e til que se pratiquem a construo de novos modelos de qualidade para produtos de software. O modelo de qualidade ajuda a especificar requisitos de qualidade que sero implementados e supervisionados durante o ciclo de vida de desenvolvimento do produto. O modelo ajuda tambm nas atividades de avaliao dos produtos intermedirios e finais. Aqui foram ressaltadas as atividades de avaliao da qualidade de produtos de software, entretanto as atividades de implementao de requisitos de qualidade, durante o desenvolvimento do produto ainda uma rea carente de experincias prticas. As comunidades que pesquisam e praticam qualidade de processo e produto de software se mantm separadamente nas suas atividades, sendo uma das intenes aqui colocadas que essas comunidades olhem juntas para um s objetivo que a qualidade de software como um todo, tanto do ponto de vista da gesto do desenvolvimento quanto do ponto de vista do usurio. As fbricas de software, com tanta demanda, trabalham numa produo no sistemtica, e dependente de pessoas. Isso chamou a ateno de pesquisadores para que houvesse uma

163

sistematizao (organizao) nos processos de produo de software. O produto gerado acabou ficando sem a devida ateno no que se refere qualidade e padronizao. As normas de qualidade de produto tratam desses aspectos, no entanto no so ainda devidamente conhecidas pelos produtores, nem pelo mercado. As avaliaes da qualidade de produto de software tratadas no livro so do ponto de vista do usurio final, o que necessita de um produto j em fase final de produo ou num processo diferenciado de produo que contemple a qualidade de produto. Avaliao pode ser realizada do ponto de vista do usurio final, como o assunto em questo, mas tambm pode ser do ponto de vista do desenvolvedor, do fabricante, do comprador, entre outros. A metodologia MEDE-PROS que composta de um modelo de qualidade e de um mtodo de avaliao, faz avaliaes da qualidade de produtos de software e serve de base para avaliaes de outros tipos de software. evidente que adaptaes so necessrias para cada caso em particular, onde, por exemplo, documentao do usurio e descrio do produto so partes importantes de qualquer tipo de software e podem ser consideradas ou no. No caso de software do tipo pacote (COTS) esses componentes citados so obrigatrios de acordo com a norma NBR ISO/IEC 25051. Um processo sistemtico de avaliao da qualidade de produto de software mostrado no captulo 6 com detalhes, que tem como base a norma NBR ISO/IEC 14598, partes 1 e 5. Para sua execuo necessrio especificar os requisitos de avaliao de acordo com um modelo de qualidade e a utilizao de medidas que devem ser oriundas do mesmo modelo de qualidade. Da a importncia do modelo de qualidade que est sendo revisto na nova srie ISO/IEC 25000 ser um dos motivos dessa reviso. Esta srie enfatiza a utilizao do modelo de qualidade para a especificao de requisitos e avaliao. O MEDE-PROS utiliza as normas de qualidade para especificar os requisitos e avaliar produtos de software, sendo uma metodologia genrica e que serve para avaliar qualquer produto de software de domnios diversos. A experincia prtica apresentada mostrou-se til e proveitosa para todos os envolvidos e demonstrou grandes benefcios aos produtos avaliados. Com o auxlio da norma NBR ISO/IEC 9126-1, pode-se especificar e avaliar requisitos de qualidade, de forma objetiva, tanto a qualidade do produto de software quanto a qualidade do processo de seu desenvolvimento e sua manuteno. No modelo CMMI e tambm no MPS, a organizao deve trabalhar em parceria com o cliente, entendendo suas necessidades e promovendo um desenvolvimento ou manuteno de produtos de software, que estabelece os requisitos do cliente de forma documentada e garante a alocao desses requisitos aos componentes do software. Portanto, o CMMI, o MPS e a norma NBR ISO/IEC 9126-1 reconhecem o fato de que a qualidade de um software altamente influenciada pela qualidade do seu processo. Assim, qualquer iniciativa no sentido de melhorar a qualidade de produto de software deve estar engajada na melhoria da qualidade

164

de processo de software da organizao. Nesse contexto, possvel dizer que qualidade de software a integrao entre qualidade de processo e qualidade de produto, isto : uma das modalidades isoladamente no ser privilegiada. Isso vem ao encontro da proposta de integrao das abordagens de qualidade de software: processo e produto, em benefcio do prprio software e da sua utilizao. Com essa iniciativa, o foco estar na qualidade do software, e no s no processo, ou s no produto final. Ou seja, devem ser executadas as melhores prticas no processo para desenvolver e manter um produto que possua as caractersticas de qualidade reconhecidas internacionalmente. Todas as reas de processo distribudas nos nveis de maturidade do modelo de processo CMMI ou MPS possuem instncias apontadas aqui, com potencial oportunidade de envolver e utilizar os conceitos da norma NBR ISO/IEC 9126-1. Isso reflete que independentemente do nvel de maturidade da organizao, a oportunidade de utilizar os conceitos, os modelos e o processo de avaliao da qualidade de produto sempre possvel, aplicvel e recomendvel. Esse assunto tambm deve ser pesquisado, debatido e exercitado na prtica, para que se obtenha resultados concretos. Na tomada de deciso de avaliar um produto de software ou no, deve ser analisada a relao custobenefcio. Ou seja, alguns aspectos devem ser observados: a execuo de um processo de avaliao para produtos de software demanda tempo e recursos financeiros tanto para a preparao dos recursos materiais e humanos necessrios ao processo, quanto dos artefatos a serem gerados (atas de reunies e relatrio de avaliao). Portanto, a experincia mostra que necessrio analisar a viabilidade desse tipo de processo ser executado na sua totalidade. Em muitos casos suficiente aplicar parte desse processo de avaliao para se garantir a qualidade esperada a custo reduzido. Dividir a metodologia em fases uma boa prtica. A existncia do atributo ou no, pode ser observada j numa fase inicial, sendo que a sua correta execuo pode ser analisada em uma segunda fase.

165

Guia de Avaliao da Qualidade de Produto de Software

Introduo

1. INTRODUO
Este Guia de Avaliao da Qualidade de Produtos de Software foi elaborado com base no Mtodo de Avaliao da Qualidade de Produto de Software - MEDE-PROS desenvolvido no CTI Centro de Tecnologia da Informao Renato Archer, para apoiar a avaliao da qualidade de produto de software, sob o ponto de vista de um usurio final. Este Guia contm um conjunto de questes para a avaliao de um produto de software. Algumas questes podem ser modificadas, outras eliminadas, e/ou novas questes podem ser acrescentadas, de acordo com a especificao da avaliao do produto de software a ser avaliado. Este Guia apresenta em sua estrutura, uma sequncia de passos, agrupados por tarefas especficas, para orientar a avaliao da qualidade de um produto de software.

1.1 Objetivo
O objetivo deste Guia orientar o avaliador durante a execuo da avaliao da qualidade de produto de software.

1.2 Convenes Utilizadas

Simbologia Definio Exemplo no documentao, software.

Palavras ou expresses Termos que constam finalizadas com o smbolo glossrio (Apndice F). e com fonte AvantGarde.

Pargrafos entre linhas com Instrues ou observaes Antes de letras em negrito e itlico. importantes para o processo questo 4, de avaliao.

avaliar a avalie o atributo 4.2.5 "Execuo da Instalao".

Linhas contnuas precedidas Espao para colocar Descreva a embalagem. anotaes requisitadas que pelo smbolo . complementam o atributo ou a questo avaliada. Nmeros sobrescritos no final Citao de uma referncia Erro " a diferena entre um de uma frase ou expresso. bibliogrfica deste livro. valor ou condio computado, observado, ou medido e o valor ou condio verdadeiro, especificado ou teoricamente 2 correto"
2

refere-se 2 bibliogrfica:
Pgina 1 de 47

referncia

Guia de Avaliao da Qualidade de Produto de Software

Introduo

"[2] AMERICAN NATIONAL STANDARDS ... New York : IEEE Computer Society, 1990." Palavras escritas em negrito. Palavras escritas em itlico. Palavras ou siglas a que se Obs., NA (No se Aplica), etc. deseja dar realce no texto. Palavra de origem estrangeira, setup, scanner, etc. no incorporada na lngua portuguesa.

1.3 Organizao e Uso

Esta seo descreve como est organizado este Guia de Avaliao. A seo 2, "Consideraes para o Procedimento da Avaliao", apresenta uma srie de observaes que devero ser consideradas para a utilizao deste Guia de Avaliao. As sees 3 a 10 incluem um conjunto de instrues e um checklist para avaliar uma parte especfica de um produto de software. Durante a avaliao, recomendamos que o avaliador siga a sequncia das sees: 3 - "Aes Iniciais"; 4 - "Avaliao da Instalao"; 5 - "Avaliao da Documentao, Interface e Software"; 6 - "Avaliao da Descrio do Produto"; 7 - "Avaliao da Embalagem"; 8 - "Avaliao da Desinstalao"; 9 - "Elaborao do Relatrio de Avaliao" e 10 "Aes Finais". Este Guia tambm contm Anexo A - "Explicao das Questes", que apresenta explicaes e exemplos para as questes que precisam de esclarecimentos adicionais, para uma melhor compreenso por parte do avaliador do produto de software.

Pgina 2 de 47

Guia de Avaliao de Qualidade de Produto de Software

Consideraes

2. CONSIDERAES PARA O PROCEDIMENTO DA AVALIAO

Em relao s questes que fazem parte deste Guia de Avaliao, os avaliadores devem considerar as seguintes observaes: As questes so proposies lgicas sobre um atributo a ser verificado em uma avaliao. Cada proposio que compe um atributo dever ser o mais objetiva possvel, envolvendo apenas um aspecto do atributo As questes esto agrupadas por atributos; Todas as questes de todos os atributos devem ser verificadas e respondidas; Uma resposta deve ser atribuda a cada questo; As respostas possveis para as questes so: "S" (Sim) para sentenas verdadeiras; "N" (No) para sentenas falsas; "NA" (No se Aplica) para sentenas que fazem referncia a um aspecto que no se enquadra no produto em avaliao. Obs.: 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. Ex.: 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). "AP" (Avaliao Prejudicada) para sentenas que o avaliador no est em condies de avaliar, ou por falta de recursos, por falta de informaes, ou mesmo por falta de conhecimento especfico no assunto abordado; Obs.: A atribuio desta alternativa pouco desejvel, pois significa que os recursos de que se dispe so insuficientes. Ex.: 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).

Todas as questes com respostas desfavorveis (i.e. aspectos a serem melhorados) ao produto ou com respostas "NA" ou "AP" devem ser justificadas por escrito. A justificativa dever estar identificada com o nmero do atributo e da questo, e colocada no verso da pgina anterior do atributo, para ajudar na elaborao do relatrio de avaliao; Para os atributos que tiverem todas as suas questes com respostas "NA" ou "AP", a justificativa ser relativa ao motivo pelo qual o atributo no se aplica ou teve sua avaliao prejudicada. Ou seja, no ser necessria uma justificativa para cada questo desse atributo; Algumas questes necessitam de anotaes do avaliador como complemento da resposta dada. Essas anotaes devero ser preenchidas na linha, logo abaixo da questo indicada, pelo smbolo ; Termos utilizados neste Guia de Avaliao que possuem uma descrio no Apndice F "Glossrio", esto assinalados com o smbolo; Caso o produto de software apresente erros e/ou falhas durante sua avaliao, o avaliador dever anotar os passos realizados que tiveram como consequncia o erro ou a

Pgina 3 de 47

Guia de Avaliao de Qualidade de Produto de Software

Consideraes

falha ocorrida, alm de anotar o procedimento adotado para solucion-los. Isso possibilitar a reproduo posterior do erro ou da falha. O avaliador dever registr-los no espao reservado, "Ocorrncia de Falhas/Erros". Caso no se sinta seguro para avaliar uma questo, anote-a e prossiga a avaliao, avaliando-a somente quando sentir segurana da resposta a ser atribuda questo. Algumas questes, para serem avaliadas, requerem um conhecimento maior do produto. Para isso manipule o produto, leia a documentao, execute as funes que o produto possui, navegue pelas janelas, crie familiaridade com o produto. Isso facilitar bastante a avaliao. As sees a seguir correspondem a cada etapa da avaliao. Elas apresentam o procedimento de avaliao de um produto de software, contendo um conjunto de instrues e um checklist.

Pgina 4 de 47

Guia de Avaliao da Qualidade de Produto de Software

Aes Iniciais

3. AES INICIAIS

3.1 Instrues para Iniciar a Avaliao

1. Com o produto em mos, identificar os folhetos e documentos que vieram dentro e fora da embalagem; 2. Ler atentamente as informaes referentes aos requisitos mnimos de hardware e software constantes em folhetos, embalagem e documentos, caso existam; 3. Com os requisitos mnimos de hardware e software claros, verificar se o equipamento a ser utilizado para a avaliao atende a essas exigncias; 4. Finalizar esta tarefa, preenchendo, o documento Apndice B - "Identificao da Avaliao", as seguintes informaes: "Data inicial da avaliao"; "Avaliador"; "Produtor"; "Produto"; "Verso" do produto; "Descrio resumida" do produto; "Material apresentado"; "Condies de Instalao e Operao" conforme documentao e disponveis no equipamento utilizado na avaliao.

Pgina 5 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Instalao

4. AVALIAO DA INSTALAO

4.1 Instrues para Avaliao da Instalao

1. Ler as questes da seo 4.2 "Checklist para Avaliao da Instalao"; 2. Passar um antivrus para garantir que o equipamento esteja livre de vrus; 3. Registrar, na tabela abaixo, a data e hora da ltima modificao dos arquivos de configurao de sistema: config.sys, autoexec.bat, win.ini, e fazer uma cpia dos arquivos com os mesmos nomes, mas com extenso ai (antes da instalao): Arquivo config.sys autoexec.bat win.ini Data Hora Nome da Cpia Config.ai Autoexec.ai win.ai

4. Executar a instalao do produto; 5. Registrar, na tabela abaixo, a data e hora da ltima modificao dos arquivos de configurao de sistema: config.sys, autoexec.bat, win.ini, e fazer uma cpia dos arquivos com os mesmos nomes, mas com extenso pi (ps-instalao): Arquivo config.sys autoexec.bat win.ini

Data

Hora

Nome da Cpia Config.pi Autoexec.pi win.pi

6. Verificar se os arquivos de configurao de sistema foram modificados durante o procedimento de instalao. Para isso, pode seguir o seguinte procedimento: - conferir se mudou a data e hora da ltima modificao dos arquivos correspondentes (compare config.ai com config.pi, autoexec.ai com autoexec.pi e win.ai com win.pi); - se no mudou a data e a hora, ento a instalao no modificou esses arquivos; - se mudou a data e hora, sugerimos verificar a igualdade ou no desses arquivos, por meio da impresso deles; - a instalao modificou algum desses arquivos? Quais?

7. Passar um antivrus para garantir que o equipamento continua livre de vrus; 8. Finalizar esta tarefa, preenchendo as questes de 4.2 - "Checklist para Avaliao da Instalao".

Pgina 6 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Instalao

4.2 Checklist para Avaliao da Instalao

Para avaliar os atributos 4.2.1 "Especificao dos Requisitos de Hardware na Descrio do Produto", 4.2.2 "Especificao dos Requisitos de Software na Descrio do Produto" e 4.2.3 "Indicao de Instalao na Descrio do Produto", o avaliador dever procurar as informaes na Descrio do Produto (ver definio na pgina 25). Avalie esses atributos aps ter avaliado o atributo 6.2.1 "Existncia da Descrio do Produto", na pgina 26. Caso tenha atribudo "N" (No) questo 1 do atributo 6.2.1 "Existncia da Descrio do Produto", atribua "NA" (No se Aplica) s questes dos atributos 4.2.1 a 4.2.3.

Completitude da Descrio do Produto 4.2.1 Especificao dos Requisitos de Hardware na Descrio do Produto
o processador necessrio para colocar o produto em uso. Ex.: Pentium 4; o tamanho da memria principal para colocar o produto em uso; os dispositivos de entrada de dados necessrios para colocar o produto em uso. Ex.: kit multimdia, mouse, teclado, scanner; os dispositivos de sada de dados necessrios para colocar o produto em uso. Ex.: kit multimdia, impressoras, plotters, monitores SVGA, etc; placas de expanso de memria necessrias para colocar o produto em uso; os tipos dos perifricos auxiliares necessrios para colocar o produto em uso. Ex.: hardlock, etc; a capacidade dos perifricos necessrios para colocar o produto em uso. monitor de alta resoluo, impressora de alta resoluo, scanner de mesa; placas de rede necessrias para colocar o produto em uso. unidade de fax-modem necessria para realizar tarefas especficas. Ex.:

O documento de Descrio do Produto especifica:

(_____) .1. (_____) .2. (_____) .3.

(_____) .4.

(_____) .5. (_____) .6.

(_____) .7.

(_____) .8. (_____) .9.

Pgina 7 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Instalao

4.2.2

Especificao dos Requisitos de Software Produto

na Descrio do

O documento de Descrio do Produto especifica:

(_____) .1.

o software de sistema operacional necessrio para colocar o produto em uso. Ex.: Windows 2007, etc; para ambiente de rede, o software necessrio para colocar o produto em uso. Ex.: LAN, Novell, etc; outros produtos de software fundamentais para colocar o produto em uso. Ex.: Visual Basic, Access, Delphy, etc.

(_____) .2.

(_____) .3.

4.2.3

Indicao de Instalao na Descrio do Produto

est declarado se a instalao do produto pode ou no ser conduzida pelo usurio.

No documento de Descrio do Produto:

(_____) .1.

Pgina 8 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Instalao

Se existir declarao indicando que a instalao no pode ser conduzida pelo usurio, atribua "NA" (No se Aplica) questo 1 do atributo 4.2.4 "Instrues para Instalao" e a todas as questes do atributo 4.2.5 "Execuo da Instalao", e solicite ao suporte tcnico do produtor para fazer a instalao e v direto para a seo 5 - "Avaliao da Documentao, Interface e Software", na pgina 11. Para avaliar os atributos 4.2.4 "Instrues para Instalao" e 4.2.5 "Execuo da Instalao", o avaliador dever procurar as informaes na documentao impressa (exemplos de documentao impressa: manual, atualizao do manual, guia de referncia rpida, contra capa do CD, etc.) ou no arquivo leia-me.txt ou semelhante, disponvel antes da instalao. No considere para esses atributos as informaes contidas na descrio do produto, nem na embalagem, nem na documentao on-line. Avalie esses atributos aps ter avaliado a questo 1 do atributo 5.2.1"Existncia da Documentao", na pgina 12. Caso tenha atribudo "N" (No) questo 1 do atributo 5.2.1"Existncia da Documentao", atribua "NA" (No se Aplica) s questes dos atributos 4.2.4 e 4.2.5.

Completitude da Documentao 4.2.4 Instrues para Instalao

apresenta instrues para instalao, disponveis antes de realiz-la.

Se a instalao pode ser conduzida pelo usurio, a Documentao:

(_____) .1.

Apresentando, as instrues de instalao:

(_____) .2. (_____) .3.

orientam, passo a passo, como executar as aes da instalao; esto claras, quanto aos procedimentos a serem executados;

Antes de avaliar a questo 4, avalie o atributo 4.2.5 "Execuo da Instalao".

(_____) .4.

fornecem as informaes necessrias para instalar o software.

Pgina 9 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Instalao

Portabilidade Capacidade para ser Instalado 4.2.5 Execuo da Instalao

avisa o usurio sobre a limitao existente em relao ao nmero de instalaes permitidas; permite nveis de instalao segundo a necessidade do usurio. Ex.: Instalao tpica ou Instalao Personalizada; exibe mensagens informando o andamento da tarefa; permite definir o subdiretrio onde se quer instalar o software; cria automaticamente os subdiretrios necessrios; copia os arquivos necessrios automaticamente;

O Procedimento de instalao do software avaliado:

(_____) .1.

(_____) .2.

(_____) .3. (_____) .4. (_____) .5. (_____) .6.

Antes de avaliar as questes 7, 8 e 9 primeiramente verifique se os arquivos de configurao de sistema (config.sys, autoexec.bat, win.ini) foram modificados durante o procedimento de instalao. Se o procedimento de instalao no modificou esses arquivos, ento atribua "NA" (No se Aplica) s questes 7, 8 e 9.
(_____) .7.

realiza cpia de backup dos arquivos de configurao do sistema (config.sys, autoexec.bat, win.ini) anteriores instalao do software antes de executar qualquer modificao nesses arquivos; atualiza os arquivos de configurao do sistema (config.sys, autoexec.bat, win.ini, etc.), pedindo confirmao do usurio; avisa o usurio sobre a necessidade de dar um reboot no sistema, aps instalao; cria o grupo de programa, quando for o caso; cria os itens de programa, quando for o caso; cria os cones para acesso e execuo do software, quando for o caso; fornece uma funo que permite interromper o procedimento de instalao; exibe mensagem sobre o sucesso, ou no, da instalao, aps concluda; uma vez concludo, possvel executar o produto; apresenta alguma(s) irregularidade(s) no mencionada(s) nas questes acima. Qual(is):

(_____) .8.

(_____) .9. (_____) .10. (_____) .11. (_____) .12. (_____) .13. (_____) .14. (_____) .15. (_____) .16.

Pgina 10 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao, Interface e Software

5. AVALIAO DA DOCUMENTAO, INTERFACE E SOFTWARE 5.1 Instrues para Avaliao da Documentao, Interface e Software
Estes trs componentes esto interligados, pois aprendemos a utilizar um produto de software atravs da leitura da documentao, combinada com a navegao pela interface e a execuo do software. Em vista disso, e considerando que algumas das questes da documentao necessitam da utilizao do software, sugerimos a avaliao desses trs componentes em conjunto. 1. Ler as questes de: 5.2 "Checklist para Avaliao da Documentao ", 5.3 "Checklist para Avaliao da Interface " e 5.4 "Checklist para Avaliao do Software"; 2. Conhecer o produto, lendo a documentao, e utilizando o produto de software. Exercitar as funes, o mais completamente possvel, testar todas ou a maioria das funes disponveis, seguindo a documentao e os helps do software como guias; 3. Preencher as questes da documentao tanto impressa como on-line, a interface e software; 4. Finalizar esta tarefa, preenchendo o campo "Descrio resumida" do produto de software, no documento, Apndice B - "Identificao da Avaliao".

Pgina 11 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao

5.2 Checklist para Avaliao da Documentao

A documentao o conjunto completo de documentos disponvel na forma impressa ou on-line. fornecida para auxiliar na utilizao de um produto de software, sendo tambm uma parte integrante deste. Exemplos de documentao impressa: manual, atualizao do manual, guia de referncia rpida, contracapa do CD, arquivo leia-me.txt ou semelhante, disponvel antes da instalao, etc. Exemplos de documentao on-line: help ("Tpicos da Ajuda", "Contedo", tecla <F1>, etc.), disquete de demonstrao, site, etc. Desconsidere, desta parte da avaliao, as seguintes questes: embalagem, descrio do produto, termo de licena de uso, registro do usurio e outros que no forneam informaes da utilizao do produto. Caso o produto no tenha documentao impressa nem on-line, atribua "N" (No) ao atributo 5.2.1"Existncia da Documentao" abaixo e v direto para 5.3 "Checklist para Avaliao da Interface", na pgina 19.

5.2.1

Existncia da Documentao
Existe documentao Impressa. Especifique qual(is):

(_____) .1.

(_____) .2.

Existe documentao on-line. Especifique qual(is):

Completitude da Documentao 5.2.2 Identificao do Produto

est identificado o nome do software; est identificada a verso ou a data de criao do software; caso seja uma variante do software, esta identificada. Ex.: Verso XX, com variante para Windows, Mac, Unix, etc. Onde:

Na Documentao:
(_____) .1. (_____) .2. (_____) .3.

Pgina 12 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao

5.2.3

Identificao das Tarefas o Produto

que Podem Ser Executadas Utilizando-se

Na Documentao:
(_____) .1.

esto identificadas as tarefas que podem ser executadas utilizando-se o software Onde:

5.2.4

Especificao dos Requisitos de Hardware

o processador necessrio para colocar o produto em uso. Ex.: Pentium 4; o tamanho da memria principal para colocar o produto em uso; os dispositivos de entrada de dados necessrios para colocar o produto em uso. Ex.: kit multimdia, mouse, teclado, scanner; os dispositivos de sada de dados necessrios para colocar o produto em uso. Ex.: kit multimdia, impressoras, plotters, monitores SVGA, etc; placas de expanso de memria necessrias para colocar o produto em uso; os tipos dos perifricos auxiliares necessrios para colocar o produto em uso. Ex.: hardlock, etc; a capacidade dos perifricos necessrios para colocar o produto em uso, Ex.: monitor de alta resoluo, impressora de alta resoluo, scanner de mesa; placas de rede necessrias para colocar o produto em uso; unidade de fax-modem necessria para realizar tarefas especficas. Onde:

A Documentao especifica:
(_____) .1. (_____) .2. (_____) .3.

(_____) .4.

(_____) .5. (_____) .6.

(_____) .7.

(_____) .8. (_____) .9.

5.2.5

Especificao dos Requisitos de Software

o software de sistema operacional necessrio para colocar o produto em uso. Ex.: Windows 2007; para ambiente de rede, o software necessrio para colocar o produto em uso. Ex.: LAN, Novell, Samba, etc; outros produtos de software fundamentais para colocar o produto em uso. Ex.: Visual Basic, Access, Delphy, etc. Onde:

A Documentao especifica:
(_____) .1.

(_____) .2.

(_____) .3.

Pgina 13 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao

5.2.6

Declarao sobre a Usabilidade da Interface

A Documentao apresenta, atravs de texto, imagens ou fotos, se a interface com o usurio feita atravs de:
(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6. (_____) .7.

linhas de comando; menus; janelas; teclas de funo; teclas de atalho; barra de botes; som. Onde:

5.2.7

Introduo
apresenta um texto introdutrio e/ou de apresentao. uma descrio geral do produto e do que fazem suas funes; uma viso geral da estrutura da documentao; de fcil compreenso; uma idia clara do contedo da documentao; uma ordem na apresentao das informaes; termos tcnicos que podem dificultar o entendimento de usurios leigos.

A Documentao:
(_____) .1.

Apresentando:
(_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6. (_____) .7.

Pgina 14 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao

Usabilidade - Inteligibilidade 5.2.8 Organizao

instrui o usurio, orientando-o na aprendizagem; organizada visando facilitar o entendimento pelo usurio; permite uma fcil identificao das funes; evita fazer muitas referncias a itens que sero apresentados em captulos posteriores; tem uma organizao lgica e evolutiva, aumentando gradativamente o nvel de complexidade da informao na organizao dos captulos, ilustraes, ndices e glossrio; contm um tpico dedicado a apresentar ao usurio os smbolos e convenes usados na documentao; Ex.: nome de comando em negrito, parmetros em itlico, cones utilizados; contm um tpico dedicado a apresentar ao usurio os smbolos e convenes apresentados pela interface. Ex.: nome de comando em negrito, parmetros em itlico, cones utilizados; possui os componentes numerados corretamente. tpicos, etc; Ex.: captulos, subcaptulos,

A Documentao :
(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5.

(_____) .6.

(_____) .7.

(_____) .8.

(_____) .9.

utiliza recursos para destaque nas informaes relevantes. Ex.: negrito, itlico, palavras em letra maiscula, numerao, sombreamento de texto.

5.2.9

Clareza
claro e preciso, no dando margem a interpretaes ambguas; apresenta erros gramaticais; apresenta erros ortogrficos; utiliza termos e explicaes considerando o tipo de usurio a que se destina o produto; explica as mensagens de erro, quando necessrio; as palavras em outro idioma esto destacadas de forma a melhorar a compreenso do texto. Ex.: entre aspas ou itlico.

O texto da Documentao :
(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6.

Pgina 15 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao

Usabilidade - Apreensibilidade 5.2.10 Exemplos

A Documentao:
(_____) .1.

possui exemplos para auxiliar a compreenso do assunto tratado.

Possuindo, os exemplos:
(_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6. (_____) .7. (_____) .8.

so claros e precisos, no dando margem a interpretaes ambguas; so fceis de entender; so suficientes; so apropriados ao tipo de aplicao do software; so apropriados ao tipo de usurio a que se destinam; citam fontes teis para informaes adicionais; esto no mesmo idioma da documentao.

Usabilidade - Operacionalidade 5.2.11 ndice Geral

A Documentao impressa:
(_____) .1.

apresenta ndice geral.

Apresentando ndice geral:

(_____) .2. (_____) .3. (_____) .4.

ele completo; ele respeita a estrutura dos captulos; ele auxilia o usurio a encontrar a informao procurada atravs da numerao de pginas. apresenta ndice geral.

A Documentao on-line:
(_____) .5.

Apresentando ndice geral:

(_____) .6. (_____) .7. (_____) .8.

apresenta os tpicos de forma organizada; utiliza recursos de hipertexto atravs de links; fornece resultados corretos, levando informao procurada.

Pgina 16 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao

Funcionalidade - Adequao 5.2.12 Coerncia

Verificar se a Documentao apresenta uma relao lgica e consistente entre as idias e/ou texto:
(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5.

na apresentao das informaes, no que se refere a contedo; nos ttulos dos captulos, correspondendo aos assuntos apresentados; nos exemplos apresentados, considerando o contexto; nas ilustraes apresentadas, considerando o contexto; no contedo das informaes, considerando ser um manual do usurio.

Funcionalidade - Acurcia 5.2.13 Consistncia Interna

Na Documentao impressa:
(_____) .1. (_____) .2. (_____) .3. (_____) .4.

foi observada alguma contradio entre informaes apresentadas em locais distintos; faltam pginas; existe troca entre pginas; os ttulos de captulos apresentados no ndice so os mesmos dos captulos referenciados; as pginas apresentadas pelo ndice levam s informaes referenciadas.

(_____) .5.

Na Documentao on-line:
(_____) .6. (_____) .7.

foi observada alguma contradio entre informaes apresentadas em locais distintos; os ttulos de captulos apresentados no ndice so os mesmos dos captulos referenciados; os links apresentados no ndice levam s informaes referenciadas.

(_____) .8.

Pgina 17 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Documentao

5.2.14 Consistncia
Na Documentao:
(_____) .1.

Externa

foi observada alguma contradio e/ou inconsistncia entre as informaes e o que se verifica na interface do produto . Ex.: a documentao informa: aperte o boto "cancelar" para cancelar a operao, mas a interface no apresenta tal boto; em todas as tarefas apresentadas, as opes de comandos correspondem em nmero e nome s apresentadas pela interface, observadas atravs do uso do produto; os ttulos das caixas de dilogo apresentadas na documentao correspondem aos ttulos das caixas de dilogo mostradas pela interface; o contedo das caixas de dilogo apresentado na documentao corresponde ao contedo das caixas de dilogo mostrado pela interface.

(_____) .2.

(_____) .3.

(_____) .4.

5.2.15 Acurcia
Na Documentao:
(_____) .1.

as informaes so as mesmas no manual on-line e no manual impresso.

possvel que, alm do manual principal, o produto apresente um "complemento ou atualizao de manual", contendo somente as informaes referentes s diferenas entre as verses e, neste caso, tambm devem ser considerados.
Na Documentao:
(_____) .2.

o nmero da verso apresentada compatvel com o nmero da verso do software; a informao sobre a configurao de hardware necessria a mesma em todos os locais onde apresentada; a informao sobre a configurao de software necessria a mesma em todos os locais onde apresentada; o contedo apresentado compatvel com a verso do software; caso existam, as informaes sobre convenes utilizadas esto corretas. Ex.: unidades de medida, nome da moeda corrente, nmero de casas decimais, notao, etc; os termos utilizados esto no mesmo idioma da interface.

(_____) .3.

(_____) .4.

(_____) .5. (_____) .6.

(_____) .7.

Pgina 18 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Interface

5.3 Checklist para Avaliao da Interface

As funes do software so representadas na Interface atravs de menus, barra de botes, caixas de dilogo, , teclas de atalho e de funo, etc.

Usabilidade - Inteligibilidade 5.3.1 Aplicabilidade

est organizada em grupos segundo uma forma lgica facilmente compreendida pelo usurio; faz uso de identificadores que representam claramente seu significado. Ex.: ttulos, cones, etc; informa ao usurio sobre o que um boto, menu, cone ou caixa de dilogo faz ao posicionar o cursor do mouse sobre ele em bales explicativos ou barra de status que aparecem na posio do cursor; utiliza o mesmo identificador para uma dada funo no produto como um todo; orienta o usurio nos passos a serem executados para a realizao de uma determinada tarefa; possibilita a realizao da tarefa desejada com um nmero reduzido de passos; permite a criao de atalhos para acesso s funes diretamente; permite desabilitar alguns dilogos e apresentaes iniciais. Ex.: "Dicas do dia" do Word; permite nomear rtulos ou comandos, segundo a necessidade ou preferncia do usurio.

A interface:
(_____) .1.

(_____) .2.

(_____) .3.

(_____) .4. (_____) .5.

(_____) .6. (_____) .7. (_____) .8.

(_____) .9.

Pgina 19 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Interface

5.3.2

Aspectos Visuais
apresentam uma distribuio uniforme de seu contedo, levando em considerao o espao disponvel; possuem reas de seleo dos itens de menu, dimensionadas de forma a facilitar sua visualizao; apresentam somente informaes necessrias e utilizveis, sensveis ao contexto; seguem um padro na distribuio dos objetos, facilitando o entendimento dos mesmos; facilitam a leitura e identificao das funes; facilitam a leitura e identificao dos campos de entrada de dados e seus formatos. Ex.: datas, horas, medidas, intervalos; apresentam os campos de entrada de dados compatveis com a necessidade; exibem as mensagens com bom aspecto visual, utilizando, com moderao, negrito, itlico e sublinhado; utilizam tipos e tamanhos de letras de fcil visualizao; apresentam contrastes de cores, facilitando a leitura.

As telas:
(_____) .1.

(_____) .2.

(_____) .3. (_____) .4.

(_____) .5. (_____) .6.

(_____) .7. (_____) .8.

(_____) .9. (_____) .10.

5.3.3

Localizao
est estruturada de forma a agrupar as tarefas do software em reas funcionais; dispe os objetos de interao (opes de menu, etc) numa ordem lgica. Ex.: Frequncia de uso, grau de importncia, alfabtica, etc; apresenta informaes adicionais em uma barra de status.

A interface:
(_____) .1. (_____) .2.

(_____) .3.

Pgina 20 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Interface

5.3.4

Mensagens apresentadas
exibe mensagens de orientao ao usurio. orientam o usurio, de forma efetiva e eficiente, na execuo da tarefa desejada; so autoexplicativas, isto , quando uma determinada mensagem apresentada, ela imediatamente compreendida pelo usurio, sem a necessidade de consultas adicionais a outras fontes; limitam-se apenas ao contexto da tarefa que est sendo realizada; so controlveis pelo usurio. Ex.: em relao ao tempo de exposio na tela, como continuar com o dilogo, etc; esto de acordo com a expectativa do usurio, obedecendo a suas caractersticas, tais como conhecimento especfico da tarefa, educao e experincia; utilizam-se de uma linguagem instrutiva, polida, neutra e no agressiva. so apropriadas para o aprendizado, isto , orientam e guiam o usurio no sentido de aprender a usar o software.

A interface:
(_____) .1.

Havendo mensagens de orientao ao usurio, elas:

(_____) .2.

(_____) .3.

(_____) .4. (_____) .5.

(_____) .6.

(_____) .7. (_____) .8.

Usabilidade - Operacionalidade 5.3.5 Tipos Diferenciados de Operao

utiliza teclas de atalho ou acelerao, agilizando a ao de usurios experientes; oferece facilidade para que usurios de nveis de familiaridade diferentes possam facilmente se adaptar ao sistema. Ex.: Tutoriais estruturados em nveis: bsico e avanado.

A interface:
(_____) .1. (_____) .2.

Pgina 21 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Interface

Funcionalidade - Adequao 5.3.6 Definio

possui as funes de interface bem definidas, de forma a no deixar dvidas sobre o que fazem. Ex.: Identificao dos Rtulos, Legendas, Cabealhos, Opes de Menu, etc; bem estruturada, de modo a facilitar a seleo das opes relevantes execuo do software. Ex.: menus em nveis hierrquicos, posicionamento de botes; orienta bem o usurio na compreenso e execuo da tarefa. Ex.: Por meio de caixas de dilogo, mensagem de alerta, mensagens de orientao apresentadas na barra de status, linhas de comando, bales explicativos, som; mostra as principais funes para executar as tarefas propostas pelo software; mostra funes no inerentes ao software. backup, etc. Ex.: instalao, desinstalao,

A interface:
(_____) .1.

(_____) .2.

(_____) .3.

(_____) .4. (_____) .5.

5.3.7

Coerncia

As funes do software expressadas na interface atravs de menus, barra de botes, teclas de atalho e de funo, caixas de dilogo, etc:
(_____) .1. (_____) .2.

possuem uma estrutura que permite uma interao rpida e fcil com o usurio; possuem uma estrutura que facilita a localizao e seleo da opo relevante execuo da tarefa; possuem uma estrutura que orienta o usurio na sequncia de passos necessrios para uma execuo eficiente e eficaz da tarefa; possuem uma estrutura de interao uniforme ao longo de todo o software, facilitando o uso, para que o usurio no precise aprender o software a cada nova tarefa.

(_____) .3.

(_____) .4.

5.3.8

Harmonia
quando apresenta menus com muitas opes, organiza-as em grupos separados entre si por traos simples, e compostos por at 7 opes (+ - 2) relacionadas logicamente; possui caractersticas prprias ao tipo de aplicao a que se destina. Ex.: Tcnico, diverso, aprendizagem, etc; apresenta somente as informaes pertinentes execuo da tarefa; apresenta funes que, quando analisadas em conjunto, se complementam, permitindo uma continuidade das tarefas.

A interface:
(_____) .1.

(_____) .2.

(_____) .3. (_____) .4.

Pgina 22 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao do Software

5.4 Checklist para Avaliao do Software

Funcionalidade - Adequao 5.4.1 Completitude

especificadas na documentao, foram todas implementadas; implementadas, atendem documentao; de forma completa os objetivos declarados na

As funes do software:
(_____) .1. (_____) .2.

(_____) .3.

satisfazem a necessidade da tarefa que o produto se prope a realizar.

Funcionalidade - Acurcia 5.4.2 Acurcia

esto todas implementadas corretamente; geram resultados corretos ou conforme o esperado.

As funes verificadas no software:

(_____) .1. (_____) .2.

Funcionalidade Segurana de Acesso 5.4.3 Acesso Seletivo

tem implementado o recurso para acesso seletivo. Ex.: Permite acesso de usurios a determinadas tarefas, por meio de senhas.

O software:
(_____) .1.

Possuindo, o recurso para acesso seletivo:

(_____) .2. (_____) .3. (_____) .4.

compatvel com o tipo de informao que manipula; impede a utilizao das funes no autorizadas; permite gerenciamento das senhas de acesso.

Pgina 23 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao do Software

5.4.4

Recursos de Hardware
espao em disco exigido; quantidade de memria necessria; resoluo grfica exigida; recursos de multimdia (placa de som, CD ROM, caixas de som, placa de vdeo); processador; placas de comunicao.

Os recursos de hardware, utilizados na avaliao, so apropriados quanto a:

(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6.

Confiabilidade - Maturidade 5.4.5 Ocorrncia de Falhas

apresentou falhas durante execuo do software.

O software:
(_____) .1.

No caso de falha, o avaliador deve anotar, no documento - "Ocorrncia de Falhas/Erros", o tipo da falha, a operao que provocou a falha e a sequncia dos passos realizados nessa operao .
As falhas:
(_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6. (_____) .7.

ocorreram numa nica situao dentro do software; impossibilitaram a avaliao do software; provocaram reset no computador; causaram propagao de erros, percebida durante a avaliao; provocaram perda de trabalhos realizados anteriormente a sua ocorrncia; so seguidas de mensagens orientando o usurio em como proceder.

Confiabilidade - Tolerncia a Falhas 5.4.6 Violao de Uso

Em qual situao de violao de uso o software apresentou propagao de erros (tais como perda de dados, resultados incorretos, comportamento imprevisto, etc):
(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5.

no reset; na entrada de um volume de dados fora dos limites permitidos; na entrada de dados fora dos limites permitidos (formatao e/ou valores do campo); nos dados inconsistentes. Ex.: datas invlidas; nos dados insuficientes. deixados em branco. Ex.: campos definidos com preenchimento obrigatrio

Pgina 24 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Descrio do Produto

6. AVALIAO DA DESCRIO DO PRODUTO 6.1 Instrues para Avaliao da Descrio do Produto

Segundo a Norma ISO/IEC 12119 (NBR ISO/IEC 12119), a descrio do produto "um documento expondo as propriedades de um pacote de software, que tem o objetivo de auxiliar os potenciais compradores na avaliao da adequao do produto antes da compra". Esta descrio pode estar disponvel em um catlogo prprio, na embalagem, em um disquete de apresentao, site ou qualquer outro meio disponvel ao usurio, independentemente da aquisio do produto.
1

Este documento nico e de fcil localizao. Caso haja mais do que um documento com a descrio do produto, o avaliador deve considerar aquele que estiver mais completo. O avaliador dever avaliar todos as questes deste componente levando em considerao se as informaes esto corretas ou no. As informaes da descrio do produto devem retratar corretamente o que o produto de software faz, mas no o que o avaliador considera que o produto de software deveria fazer. 1. Verificar a existncia do documento de "Descrio do Produto". Se no existir, atribuir N (No) ao atributo 6.2.1 "Existncia da Descrio do Produto", na pgina 26, e ir para a seo 7 "Avaliao da Embalagem", na pgina 28; 2. Ler as questes da seo 6.2 "Checklist para Avaliao da Descrio do Produto"; 3. Analisar o documento de Descrio do Produto; 4. Finalizar esta tarefa, preenchendo as questes da seo 6.2 "Checklist para Avaliao da Descrio do Produto";

Esta norma foi substituda pela NBR ISO/IEC 25051.

Pgina 25 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Descrio do Produto

6.2 Checklist para Avaliao da Descrio do Produto

Existncia da Descrio do Produto
Existe um documento de descrio do produto. Qual:

6.2.1

(_____) .1.

Completitude - Identificaes e Indicaes 6.2.2 Identificao da Descrio do Produto

existe uma identificao para o documento, tal como "Descrio do Produto", ou "Informao do Produto", ou "Descrio Funcional", ou outra similar.

No documento de Descrio do Produto:

(_____) .1.

6.2.3

Identificao do Produto
est identificado o nome do software; est identificada a verso ou a data de criao do software; caso seja uma variante do software, est identificada. variante para Windows, Mac, Unix, etc. Ex.: Verso XX, com

No documento de Descrio do Produto:

(_____) .1. (_____) .2. (_____) .3.

6.2.4

Identificao das Tarefas que Podem Ser Executadas, Utilizando-se o Produto

esto identificadas as tarefas que podem ser executadas, utilizando-se o software.

No documento de Descrio do Produto:

(_____) .1.

Pgina 26 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Descrio do Produto

Completitude - Declaraes sobre Usabilidade 6.2.5 Declarao sobre a Usabilidade da Interface

O documento de Descrio do Produto indica, atravs de texto, imagens ou fotos, se a interface com o usurio feita atravs de:
(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6. (_____) .7.

linhas de comando; menus; janelas; teclas de funo; teclas de atalho; barra de botes; som.

Pgina 27 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Embalagem

7. AVALIAO DA EMBALAGEM 7.1 Instrues para Avaliao da Embalagem

Por embalagem entende-se meio fsico que acondiciona a mdia e/ou 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, etc. 1. Verificar a existncia da embalagem. Caso o produto seja distribudo pela Internet, atribuir NA (No se Aplica) ao atributo 7.2.1 "Existncia da Embalagem", na pgina 29, e ir para 8 "Avaliao da Desinstalao", na pgina 31; Caso o produto no seja distribudo pela internet e no tenha embalagem, atribuir N (No) ao atributo 7.2.1 "Existncia da Embalagem", na pgina 29, e ir para 8 "Avaliao da Desinstalao", na pgina 31;

2. Ler as questes da seo 7.2 "Checklist para Avaliao da Embalagem"; 3. Analisar a Embalagem; 4. Finalizar esta tarefa, preenchendo as questes da seo 7.2 "Checklist para Avaliao da Embalagem".

Pgina 28 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Embalagem

7.2 Checklist para Avaliao da Embalagem

Existncia da Embalagem
Os componentes do produto esto embalados. Descreva a embalagem.

7.2.1

(_____) .1.

Completitude - Identificaes 7.2.2 Identificaes

nome do produto; verso do produto; nome do produtor; requisitos de hardware suficientes para identificao; requisitos de software suficientes para identificao; identificao das tarefas que podem ser executadas, utilizando-se o software; descrio do contedo da embalagem. Ex.: nmero de Disquetes/CDs, manuais, cabos, etc; indicao sobre necessidade de modeobra especializada para instalao do software; endereo completo, telefone, fax, e-mail, home page ou outra forma de contato com o produtor. Qual(is):

A embalagem possui:
(_____) .1. (_____) .2. (_____) .3. (_____) .4. (_____) .5. (_____) .6. (_____) .7.

(_____) .8.

(_____) .9.

Pgina 29 de 47

Guia de Avaliao da Qualidade de Produto de Software

Avaliao da Embalagem

Usabilidade - Inteligibilidade 7.2.3 Aspectos Visuais

logomarca ou imagens apresentando o software. Ex.: figuras, telas, menus, botes, relatrios, etc; tipos e tamanhos de letras que facilitem a visualizao e leitura; cores que facilitam a leitura e o entendimento das informaes; destaque para as principais informaes. Ex.: utilizao de contrastes, highlights, negritos, uso de cores, etc.

A embalagem possui:
(_____) .1.

(_____) .2. (_____) .3. (_____) .4.

Usabilidade - Operacionalidade 7.2.4 Aspectos Prticos

possui um encaixe prtico e simples para abrir e fechar; facilita o manuseio da mdia; facilita o manuseio da documentao impressa; acondiciona outros componentes, de forma a facilitar seu manuseio. Ex.: hardlock, cabos, etc.

A embalagem:
(_____) .1. (_____) .2. (_____) .3. (_____) .4.

Pgina 30 de 47

Guia de Avaliao da Qualidade de Produto de Software

Relatrio de Avaliao

8. AVALIAO DA DESINSTALAO

8.1 Instrues para Avaliao da Desinstalao

1. Ler as questes de 8.2 "Checklist para Avaliao da Desinstalao"; 2. Executar a Desinstalao do Produto; 3. Registrar, na tabela abaixo, a data e hora da ltima modificao dos arquivos de configurao de sistema: config.sys, autoexec.bat, win.ini, e fazer uma cpia dos arquivos com os mesmos nomes, mas com extenso pd (ps desinstalao): Arquivo Config.sys Autoexec.bat win.ini Data Hora Nome da Cpia Config.pd Autoexec.pd win.pd

4. Caso a instalao tenha modificado os arquivos de configurao de sistema, verificar se a desinstalao restabeleceu os arquivos de configurao de sistema para antes da instalao, verificando se existem diferenas entre os arquivos (compare config.ai com config.pd, autoexec.ai com autoexec.pd e win.ai com win.pd). - A desinstalao restabeleceu algum desses arquivos? Quais?

5. Verificar se os arquivos de configurao de sistema foram modificados durante o procedimento de desinstalao. Para isso, pode seguir o seguinte procedimento: - conferir se mudou a data e hora da ltima modificao dos arquivos correspondentes (compare config.pi com config.pd, autoexec.pi com autoexec.pd e win.pi com win.pd); - se no mudou a data e a hora, ento a desinstalao no modificou esses arquivos; - se mudou a data e hora, sugerimos verificar a igualdade ou no desses arquivos, atravs da impresso deles; - a desinstalao modificou algum desses arquivos? Quais?

6. Finalizar esta tarefa, preenchendo as questes de 8.2 "Checklist para Avaliao da Desinstalao".

Pgina 31 de 47

Guia de Avaliao da Qualidade de Produto de Software

Relatrio de Avaliao

8.2 Checklist para Avaliao da Desinstalao

Portabilidade - Capacidade para ser Desinstalado 8.2.1 Instrues para Desinstalao na Documentao
apresenta instrues para realizar sua desinstalao.

A Documentao:
(_____) .1.

Apresentando, as instrues de desinstalao:

(_____) .2. (_____) .3. (_____) .4.

orientam, passo a passo, como executar as aes da desinstalao; esto claras quanto aos procedimento a serem executados; fornecem as informaes necessrias para desinstalar o software com sucesso.

Pgina 32 de 47

Guia de Avaliao da Qualidade de Produto de Software

Relatrio de Avaliao

8.2.2

Execuo da Desinstalao
apresenta um procedimento automatizado ou manual para realizar sua desinstalao. exibe mensagens informando o andamento da tarefa; exclui os arquivos copiados na instalao do produto; exclui os subdiretrios criados durante a instalao do produto;

O Produto de Software:
(_____) .1.

Apresentando, o procedimento automatizado de desinstalao:

(_____) .2. (_____) .3. (_____) .4.

Antes de avaliar as questes 5 e 6, primeiramente verifique se os arquivos de configurao de sistema (config.sys, autoexec.bat, win.ini) foram modificados durante o procedimento de instalao. Se o procedimento de instalao no tiver modificado esses arquivos, ento atribua "NA" (No se Aplica) s questes 5 e 6.
(_____) .5.

retira dos arquivos de configurao do sistema (tipo config.sys, autoexec.bat, etc) as linhas de comando adicionadas durante a instalao do software; avisa o usurio sobre a necessidade de dar reboot no sistema, aps completada a desinstalao; retira os cones associados, quando for o caso; retira os itens de programa, quando for o caso; retira o grupo de programa, quando for o caso; exibe mensagem final sobre o sucesso, ou no, da desinstalao, aps concluda; apresenta alguma(s) irregularidade(s). Qual(is):

(_____) .6.

(_____) .7. (_____) .8. (_____) .9. (_____) .10. (_____) .11.

Apresentando, o procedimento manual de desinstalao:

(_____) .12. (_____) .13.

indica como excluir, com sucesso, os arquivos copiados na instalao do produto; indica como excluir, com sucesso, os subdiretrios criados durante a instalao do produto;

Antes de avaliar a questo 14, primeiramente verifique se os arquivos de configurao de sistema (config.sys, autoexec.bat, win.ini) foram modificados durante o procedimento de instalao. Se o procedimento de instalao no tiver modificado esses arquivos, ento atribua "NA" (No se Aplica) a questo 14.
(_____) .14.

indica como retirar com sucesso, dos arquivos de configurao do sistema (tipo config.sys, autoexec.bat, etc), as linhas de comando adicionadas durante a instalao do software; indica como retirar, com sucesso, os cones associados, quando for o caso; indica como retirar, com sucesso, os itens de programa, quando for o caso; indica como retirar, com sucesso, o grupo de programa, quando for o caso; apresenta alguma(s) irregularidade(s). Qual(is):

(_____) .15. (_____) .16. (_____) .17. (_____) .18.

Pgina 33 de 47

Guia de Avaliao da Qualidade de Produto de Software

Relatrio de Avaliao

9. ELABORAO DO RELATRIO DE AVALIAO

9.1 Instrues para Elaborao do Relatrio de Avaliao

1. Elaborar o Relatrio de Avaliao segundo a norma NBR ISO/IEC 14598-5; 2. As observaes e justificativas das atribuies que foram anotadas no checklist do Guia de Avaliao so muito importantes para a elaborao do Relatrio de Avaliao, pois nele devero ser registradas: aspectos considerados positivos; aspectos a serem revistos, com recomendaes ao produtor.

Pgina 34 de 47

Guia de Avaliao da Qualidade de Produto de Software

Aes Finais

10. AES FINAIS

10.1 Instrues para Finalizar a Avaliao

1. O avaliador dever checar se os campos da - "Identificao da Avaliao": nome do "Produto", "Verso" e nome do "Produtor", que foram previamente preenchidos, correspondem realidade apresentada pelo produto. Caso tenha havido alguma inconsistncia, atualize estes campos. 2. Preencher, no documento - "Identificao da Avaliao", a data final da avaliao. 3. O avaliador dever arquivar os seguintes itens: Relatrio de Avaliao do produto de software; Guia de Avaliao com o checklist completamente preenchido, incluindo as anotaes nos documentos - "Ocorrncia de Falhas/Erros e E - "Identificao da Avaliao". 4. Finalizar esta tarefa, entregando ao solicitante da avaliao o seguinte: Produto de software nas mesmas condies recebidas, incluindo folhetos e anexos impressos; Cpia do Relatrio de Avaliao do produto de software.

Pgina 35 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Instalao

ANEXO A: EXPLICAO DAS QUESTES

As necessrias explicaes das questes esto organizadas seguindo os cdigos dos atributos correspondentes.

A.1 Explicao das Questes da Instalao

4.2.4

Instrues para Instalao

As instrues para instalao do software referidas neste atributo so especficas ao produto a ser avaliado, devendo ser desconsiderada qualquer referncia a software adicionais, que no fazem parte do produto. 1. Deve ser verificado se o produto de software apresenta instrues para instalao na documentao, disponveis antes de realiz-la. Se existir declarao indicando que a instalao no pode ser conduzida pelo usurio, atribua NA (No se Aplica) a essa questo.

4.2.5

Execuo da Instalao

As observaes feitas acima, referentes a Instrues para Instalao, devem ser consideradas tambm para a Execuo da Instalao. 7., 8. e 9. Antes de avaliar essas questes, primeiramente verifique se os arquivos de configurao de sistema (config.sys, autoexec.bat, win.ini) foram modificados durante o procedimento de instalao. Para isso, existem pelo menos dois procedimentos: imprimir cada um desses arquivos antes e depois da instalao e verificar se existem diferenas;

registrar a data e hora da ltima modificao de cada um desses arquivos e verificar se houve modificao. Se o procedimento de instalao no tiver modificado esses arquivos, ento atribua NA (No se Aplica) a essas questes.

Pgina 36 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Documentao

A.2 Explicao das Questes da Documentao

5.2.1 Existncia da Documentao

O avaliador deve verificar se existe documentao impressa e/ou on-line e relacion-la no Checklist do Guia de Avaliao, para ser avaliada. Existe a possibilidade de obter a documentao impressa que est em mdia, pronta para ser impressa. Esse arquivo pode ser: .doc, .pdf, .txt, etc.

5.2.2

Identificao do Produto

Todos os documentos impressos e/ou on-line devem possuir uma identificao clara e precisa na capa da documentao do produto, com a verso ou data da criao ou modificao. Nem todo documento impresso apresenta capa: como exemplo, Guia de Referncia Rpida. Neste caso, considere como capa a primeira folha desse documento.

5.2.3

Identificao das Tarefas que Podem Ser Executadas Utilizando-se o Produto

Ex.: Em um software de contabilidade, algumas das tarefas seriam: plano de contas, balancete, contabilidade gerencial, ou oramento, entre outras. Obs.: Deve-se estar atento para no confundir tarefa com funo. No exemplo acima, o avaliador dever executar vrias funes, para poder realizar uma tarefa especfica.

5.2.7

Introduo

3. A introduo da documentao pode apresentar, entre outros aspectos, uma breve descrio do contedo de suas partes, captulos, tpicos, etc.

5.2.8

Organizao

1. Possui uma linguagem instrutiva, de forma a ensinar o usurio na utilizao do software; 5. Possui uma abordagem crescente quanto apresentao do assunto. Ex.: os captulos mais complexos ou que dependam de um conhecimento prvio so apresentados ao usurio posteriormente.

5.2.9

Clareza

2. Apresentando "um" erro gramatical, atribua S (Sim); 3. Apresentando "um" erro ortogrfico, atribua S (Sim).

Pgina 37 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Documentao

5.2.11 ndice Geral

Todo documento impresso com mais de 7 pginas deve conter um ndice geral. Para a documentao impressa, pode-se considerar como ndice geral a lista intitulada "ndice", "Contedo" ou "Sumrio". Para a documentao on-line, pode-se considerar como ndice geral a pasta intitulada "Contedo", do "Tpicos da Ajuda". 1. Caso a documentao no possua ndice geral, atribua N (No) a essa questo e no responda as questes subsequentes.

5.2.12 Coerncia
O avaliador dever verificar, na documentao impressa e/ou on-line, as informaes apresentadas neste atributo. 1. As informaes apresentadas na documentao conseguem transmitir ao usurio a ideia do assunto que estiver sendo abordado.

5.2.13 Consistncia Interna

1. Caso for encontrada pelo menos uma contradio entre as informaes apresentadas, atribua S (Sim).

5.2.14 Consistncia Externa

Fique atento, pois possvel que, alm do manual principal, o produto apresente uma atualizao de manual contendo somente as informaes referentes s diferenas entre as verses. 1. Caso for encontrada pelo menos uma contradio entre as informaes apresentadas, atribua S (Sim).

Pgina 38 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Interface

A.3 Explicao das Questes da Interface

5.3.1 Aplicabilidade

1. Ex.: Verificar se a interface apresenta uma boa organizao para os menus. Para isso necessrio observar se as opes de menu esto relacionadas ao objetivo do menu e se os menus conseguem dar ao usurio uma viso do produto como um todo. Por exemplo, no Word, aparecem vrias opes dentro do menu, arquivo que servem para manipular as informaes de arquivos, e os outros menus em conjunto (editar, exibir, inserir...) do uma viso das principais funes do produto. 6. Verificar se a navegao atravs das telas, para ser realizada uma determinada tarefa, mnima.

5.3.3

Localizao

1. Verificar como est a distribuio dos objetos na tela; observe se as funes do software, para executar uma determinada tarefa, esto separadas dos botes que aparecem com frequncia nas telas, ou, de outro modo, verifique se a tela apresenta reas delimitadas ( Legenda da Tela, rea para Menus, rea de apresentao de campos, rea para mensagens de orientao, etc).

5.3.6

Definio

1. Verificar se a nomenclatura adotada para os menus, opes de menu, nome de campos, legendas das telas, etc. consegue expressar, ao usurio, seu significado. 5. Deve ser verificado se o software possui as funes de instalao, desinstalao, backup disponveis ao usurio. No necessrio ter a presena de todas elas; se observar pelo menos uma, atribua S (Sim).

Pgina 39 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Interface

5.3.8

Harmonia

1. Deve ser observada a organizao das opes dentro de cada um dos menus. Quando um menu apresentar muitas opes, essas devero ser reunidas em grupos contendo opes no mximo 7 mais ou menos 2 (7+-2) delas em cada grupo. Esses grupos devero ser separados uns dos outros por meio de trao. Ex. Ver figura ilustrativa abaixo. Editar Desfazer Digitao Repetir Digitao Recortar Copiar Colar Colar Especial ... Limpar Selecionar Tudo Localizar ... Substituir ... Ir Para ... Auto Texto ... Indicador ... Vnculos ... Objeto ...

Pgina 40 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Software

A.4 Explicao das Questes do Software

5.4.1

Completitude

Deve-se ter em mente que o objetivo avaliar o mximo de funes que o software possui. Como nem sempre se tem acesso especificao do produto, consideraremos as funes cuja avaliao seja possvel. Se voc selecionou apenas uma amostra de funes para serem avaliadas, considere, nas questes deste atributo, todas as funes avaliadas. Caso alguma funo no se enquadre em alguma das questes avaliadas, atribua N (No) quela questo. Deve-se considerar o que a documentao prope e o que as funes executam especificamente. Caso haja alguma irregularidade, atribua N (No) s questes correspondentes.

5.4.2

Acurcia

Deve-se ter em mente que o objetivo avaliar o mximo de funes que o software possui. Se voc selecionou apenas uma amostra de funes para serem avaliadas, considere, nas questes deste atributo, todas as funes avaliadas. Deve-se verificar, ao exercitar as funes do software para realizao de uma tarefa, se os resultados obtidos esto sempre corretos ou conforme o esperado. Caso alguma funo no se enquadre na questo avaliada, atribua N (No).

5.4.3

Acesso Seletivo

Este atributo evidencia a capacidade do software de evitar o acesso no autorizado, acidental ou deliberado, a programas e dados. "Qualquer sistema baseado em computador que gerencie informaes delicadas ou provoque aes que possam impropriamente prejudicar (ou beneficiar) pessoas constitui um alvo para o acesso imprprio ou ilegal. O acesso abrange uma ampla variedade de atividades..." "Durante o teste de segurana, o analista (avaliador) desempenha o(s) papel(is) da pessoa que deseja penetrar no sistema. Qualquer coisa vale! O analista (avaliador) pode tentar adquirir senhas mediante contatos externos; pode atacar o sistema com software customizado, projetado para derrubar quaisquer defesas que tenham sido construdas; pode desarmar o sistema, negando servio a outros; pode intencionalmente provocar erros no sistema, esperando acess-lo durante a recuperao; pode "folhear" atravs de dados inseguros, esperando descobrir a chave para a entrada no sistema." [Pressman, 1995] 1. Os aspectos mais comuns de acesso seletivo so: senhas por usurios, ou grupo de usurios, e por funo, ou grupo de funes. Quando o produto possui apenas a senha inicial de instalao, no considere essa senha como recurso de acesso seletivo e assinale NA (No se Aplica) para o produto que no necessita ter senha; ou assinale N (No) para o produto que necessita ter senha, mas no possui esse recurso.

Pgina 41 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Software

5.4.4

Recursos de Hardware

Deve ser verificado se a quantidade e a qualidade de recursos de hardware especificados pelo produtor so adequados aos benefcios resultantes. O ideal que esses recursos sejam compatveis e apropriados ao tipo de produto que est sendo avaliado.

5.4.5

Ocorrncia de Falhas

Deve ser observado se, durante o perodo de avaliao, o software apresentou falha: parada, travamento da mquina, volta ao sistema operacional, etc. No caso de falha, o avaliador deve anotar o tipo da falha, a operao que provocou a falha e a sequncia dos passos realizados nessa operao. Essa informao muito importante para reproduzir e repetir essa falha. O tipo e o grau da falha ficam configurados quando se considera o conjunto de questes do atributo. Por isso, no se deve considerar as questes isoladamente. Por exemplo, o simples fato de ocorrer uma falha no quer dizer nada, se o tipo e as consequncias dessa(s) falha(s) no forem avaliadas. As outras questes, na sequncia, avaliam essas condies, possibilitando caracterizar a(s) falha(s). Obs.: No caso de falha, o avaliador deve anotar o tipo da falha, a operao que provocou a falha e a sequncia dos passos realizados nessa operao.

5.4.6

Violao de Uso

Devem ser efetuadas tentativas de violao no uso do produto, indicadas em cada questo do atributo, em seguida cada operao, deve-se verificar se produzem ou no efeitos colaterais nos programas e dados, ou outro recurso associado. Essas violaes devem ser efetuadas, por exemplo, atravs de algumas operaes incorretas ou no permitidas, utilizando valores acima do limite ou no especificados na documentao. Exemplos de efeitos colaterais que podem ocorrer: deteriorao de dados, travamento do computador, comportamento imprevisto, etc.

Pgina 42 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Descrio do Produto

A.5 Explicao das Questes da Descrio do Produto

Existncia da Descrio do Produto

6.2.1

Especifique em "Qual:" que tipo de documento foi utilizado como sendo o documento de Descrio do Produto. Se foi uma folha parte, um folder, a prpria embalagem, uma pgina na Internet, etc.

6.2.4

Identificao das Tarefas que Podem Ser Executadas, Utilizando-se o Produto

Verifique se h uma descrio das principais tarefas que podem ser realizadas pelo produto. Ex.: em um software de contabilidade, algumas das tarefas seriam: plano de contas, balancete, contabilidade gerencial, ou oramento, entre outras. Obs.: Deve-se estar atento para no confundir tarefa com funo. No exemplo acima, o avaliador dever executar vrias funes, para poder realizar uma tarefa especfica.

6.2.5

Declarao sobre a Usabilidade da Interface

Deve ser verificada a declarao, ou no, da existncia de cada um dos objetos das questes, no produto. Um produto pode ter todas, ou somente algumas dessas opes. Atribua: S (Sim) N (No) NA (No se Aplica) quando o objeto indicado na questo estiver presente no produto e isso estiver descrito no documento de descrio do produto; quando o objeto indicado na questo estiver presente no produto e isso no estiver descrito no documento de descrio do produto; quando o objeto indicado na questo no estiver no produto (neste caso, no h razo para estar descrito no documento de descrio do produto).

Pgina 43 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Embalagem

A.6 Explicao das Questes da Embalagem

Existncia da Embalagem

7.2.1

Descreva, no espao reservado, o tipo da embalagem do produto, conforme exemplos apresentados acima, ou qualquer outro tipo identificado. Atribua: NA (No se Aplica) N (Nenhuma) caso o produto seja distribudo pela Internet; caso o produto no tenha nenhuma embalagem .

Pgina 44 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Embalagem

7.2.2

Identificaes

As questes deste atributo verificam a presena de informaes existentes na embalagem, que podem auxiliar o comprador a identificar o produto. Alm de identificadas, a informao deve estar correta. Atribua N (No) caso no atenda a nenhuma dessas opes. 2. Conferir se a verso apresentada na embalagem corresponde quela apresentada ao executar o produto de software; 4. Os Requisitos de Hardware, para colocar o produto em uso, devem estar claramente especificados, incluindo nomes de fabricantes e identificao do tipo de todos os componentes; por exemplo: unidades de processamento, tamanho da memria principal, tipos e tamanhos dos perifricos de armazenamento, placas de expanso, equipamentos de entrada e sada, ambientes de rede, configurao da impressora, etc. Atribua: S (Sim) N (No) se, com os requisitos de hardware especificados na embalagem, foi possvel colocar o produto em uso; se a embalagem no possui especificao dos requisitos de hardware, ou se no foi possvel colocar o produto em uso por informao incompleta ou incorreta (antes de considerar errada a informao dos requisitos mnimos, deve ser verificado, com a equipe de suporte do laboratrio da avaliao, o real motivo do erro).

5. Os Requisitos de Software, para colocar o produto em uso, devem estar claramente especificados, incluindo o software de sistema e outros produtos de software. Atribua: S (Sim) N (No) se, com os requisitos de software especificados na embalagem, foi possvel colocar o produto em uso; se a embalagem no possui especificao dos requisitos de software, ou se no foi possvel colocar o produto em uso por informao incompleta ou incorreta (antes de considerar errada a informao dos requisitos mnimos, deve ser verificado, com a equipe de suporte do laboratrio da avaliao, o real motivo do erro).

6. Exemplo de tarefa: para um produto de controle de estoque, as principais tarefas so: cadastro de empresas, cadastro de produtos e questes, estoque mnimo, tabela de preos; 7. Considerar todos os componentes, exceto: ficha de cadastramento do usurio, termo de licena de uso ou catlogos de propaganda; 9. Deve ter pelo menos uma forma de contato, impresso ou carimbo. Se houver outra forma de contato com o produtor, diferente das especificadas, identifique em "Qual(is)".

Pgina 45 de 47

Guia de Avaliao da Qualidade de Produto de Software

Explicao das Questes - Embalagem

7.2.3

Aspectos Visuais

As questes deste atributo verificam caractersticas visuais que facilitam ou dificultam a identificao do produto. 4. Considere como principais informaes: nome do produto e produtor. O destaque para o nome do produto deve aparecer bem mais do que a logomarca do produtor. Tambm pode ser dado destaque para as principais facilidades e os benefcios mais importantes do produto.

7.2.4

Aspectos Prticos

As questes deste atributo verificam caractersticas que dificultam o uso no dia a dia, tornando seguro e fcil o manuseio do produto e de seu contedo. Por exemplo: ao retirar os componentes do produto da embalagem, estes esto acondicionados de forma a garantir sua integridade. 3. Se o produto de software avaliado no contm documentao impressa, ento atribua NA (No se Aplica); 4. Se o produto de software avaliado no contm outros componentes, ento atribua NA (No se Aplica).

Pgina 46 de 47

Guia de Avaliao da Qualidade de Produto de Software

Identificao da Avaliao

A.7 Explicao das Questes da Desinstalao

Instrues para Desinstalao na Documentao

8.2.1

Deve ser verificado se o produto de software apresenta instrues para desinstalao na documentao. Obs.: No Windows 2007, a funo de desinstalao pode no estar documentada nem indicada. Mas podemos verificar sua existncia no menu "Iniciar/Configuraes/Painel de Controle/Adicionar ou Remover Programas", se na lista de programas instalados constar o nome do produto. Caso conste, a execuo da desinstalao ser ativada pelo Windows. Se o produto utilizar esse recurso do Windows e no estiver documentado, o avaliador pode sugerir ao produtor que indique, na documentao, como instruo para desinstalao, a utilizao do menu do Windows "Iniciar/Configuraes/Painel de Controle/Adicionar ou Remover Programas" e atribuir N (No) a essa questo. As instrues para desinstalao do software referidas neste atributo so especficas do produto que estiver sendo avaliado, devendo ser desconsiderada qualquer referncia a outros software adicionais, que no fazem parte do produto e foram instalados para possibilitar a avaliao.

8.2.2

Execuo da Desinstalao

As observaes feitas na questo 8.2.1 devem ser consideradas tambm para a execuo da desinstalao. Deve ser verificado se o produto de software apresenta um procedimento automatizado ou manual, para realizar sua desinstalao. Se o produto tem procedimento de desinstalao automatizado, mas no est ativado ou disponibilizado, considere como se o software no tivesse esse procedimento e atribua N (No) questo 1 deste atributo. No Windows 2007, caso o nome do produto esteja na lista de programas do menu "Iniciar/Configuraes/Adicionar ou Remover Programas", considere que a desinstalao automatizada. 5., 6. e 14. Antes de avaliar essas questes, primeiramente verifique se os arquivos de configurao de sistema (config.sys, autoexec.bat, win.ini) foram modificados durante o procedimento de instalao. Se o procedimento de instalao no tiver modificado esses arquivos, ento a atribuio a essas questes dever ser NA (No se Aplica).

Pgina 47 de 47

APNDICE B Modelo da identificao da avaliao

Avaliador: Produtor: Produto: Descrio resumida: Verso:

Material apresentado Mdia: Internet: Manuais (impressos) ou online:

Outros (folders, atestados, documentos etc.):

Condies de instalao e operao Caractersticas Espao em disco rgido Memria RAM Sistema operacional Software especial Hardware (processador e clock) Hardware especial (scanner, modem, hardlock, etc.) Monitor Impressora Conforme Documentao Disponveis no Equipamento Utilizado

Data inicial da avaliao: Observaes

Data final da avaliao:

APNDICE C Modelo de relatrio de avaliao Um relatrio de avaliao um documento que apresenta, para o requisitante da avaliao, os resultados da avaliao e outras informaes relevantes a uma avaliao. Segundo a norma NBR ISO/IEC 14598-5, um relatrio de avaliao pode ter a seguinte estruturao e contedo. Alm disso, algumas informaes adicionais podem ser includas ao relatrio.

Identificaes Esta seo do relatrio de avaliao contm as informaes de

identificao relativas avaliao executada.

Identificao do avaliador Deve conter as seguintes informaes sobre o

avaliador: nome da organizao avaliadora; endereo da organizao avaliadora; local(ais) onde a avaliao foi realizada; e nome da pessoa responsvel pela avaliao.

Identificao do relatrio de avaliao Deve conter a identificao nica do

relatrio e o nmero de pginas do relatrio. Esta informao deve ser copiada em todas as pginas do relatrio. Cada pgina deve ter identificao nica - por exemplo, usando o nmero da pgina.

Identificao do requisitante e fornecedor Deve conter as seguintes informaes

sobre o requisitante da avaliao e sobre o fornecedor do produto de software avaliado: nome da organizao requisitante; endereo da organizao requisitante; nome do fornecedor do produto de software; e endereo do fornecedor do produto de software.

Requisitos de avaliao Esta seo do relatrio deve conter: uma descrio geral do
domnio de aplicao do produto; uma descrio geral do objetivo do produto; e a lista dos requisitos de qualidade e as informaes do produto avaliado incluindo, sempre que possvel, referncia s caractersticas de qualidade e aos nveis de avaliao.

Especificao de avaliao Esta seo do relatrio de avaliao deve conter: a

abrangncia da avaliao, fazendo referncia descrio do produto; quando a descrio do produto no for um documento publicamente disponvel, ela dever ser anexada ao relatrio; a referncia cruzada entre as informaes solicitadas nos requisitos de avaliao e os componentes do produto; a especificao de medies e verificaes; e mapeamento entre a especificao de medies e verificaes com os requisitos de avaliao.

Mtodos de avaliao Esta seo do relatrio de avaliao deve conter a

documentao dos mtodos de avaliao utilizados para executar a avaliao. Quando o mtodo de avaliao estiver documentado em outro local, permitido que se faa uma simples referncia a essa documentao.

Resultados de avaliao Esta seo do relatrio de avaliao deve conter: os

resultados de avaliao propriamente ditos; resultados intermedirios ou decises de

interpretao, sempre que necessrio; e referncia s ferramentas usadas durante a avaliao. A seguir, apresentado um Modelo de Relatrio de Avaliao, contendo essas instrues.

C. 1 Relatrio de Avaliao do produto <nome e verso do produto> C.1.1 Escopo Este documento apresenta o resultado da avaliao genrica do produto <nome e verso do produto> da empresa <nome da empresa>, utilizando o Mtodo de Avaliao da Qualidade de Produto de Software <uma breve descrio do produto>. C.1.2 Introduo A avaliao genrica do produto teve como objetivo observar o atendimento s caractersticas e qualidade de um produto de software, analisando suas subcaractersticas de qualidade, definidas pela norma NBR ISO/IEC 9126-1 2003. Com a verificao ao atendimento dos requisitos de software apresentados pela norma NBR ISO/IEC 25051, foi possvel selecionar alguns itens essenciais completa identificao do produto, quando aplicvel. A avaliao foi realizada por x pessoa(s), que utilizou(aram) equipamento(s) com configurao(es) conforme a tabela a seguir, perfazendo um total de y horas de avaliao (por avaliador).
Tabela C.1 Configurao do equipamento utilizado na avaliao Condies de Instalao e Operao Caractersticas Espao em disco rgido Memria RAM Sistema operacional Software especial Hardware (processador e clock) Hardware especial (scanner, modem, hardlock etc.) Monitor Impressora Equipamentos utilizados

C.1.3 O Processo de Avaliao O processo de avaliao de produto de software, de acordo com o que recomendado pela norma NBR ISO/IEC 14598-5, deve seguir as etapas:

a. Anlise de requisitos da avaliao

O objetivo da anlise de requisitos levantar os requisitos da avaliao.

b. Especificao da avaliao
Nesta etapa so definidos: escopo, restries, mtodos a serem utilizados e as responsabilidades da avaliao.

c. Projeto da avaliao
Nesta etapa definido o plano de avaliao, com o detalhamento dos instrumentos a serem utilizados, prazos, custos, equipe de avaliao, riscos associados e todas as atividades envolvidas na execuo da avaliao.

d. Execuo da avaliao
Nesta etapa so efetuadas as medies, coleta dos dados e das informaes, e realizado o procedimento de anlise.

e. Concluso da avaliao
Nesta etapa so preparados os resultados da avaliao, com a consequente gerao do relatrio de avaliao. C.1.4 Itens de Avaliao A seguir ser apresentado o resultado da avaliao, destacando pontos que atendem as normas de qualidade de software (destaque positivo) e os pontos a serem revistos, com sugestes de melhoria na Instalao, Documentao do Usurio, Interface de Usurio, Software, Descrio do Produto, Embalagem e Desinstalao. Nos prximos 15 itens, devem ser relatados os Aspectos de destaque positivo e os Aspectos a serem revistos para cada um dos itens.

1 Instalao completitude 2 Instalao portabilidade 3 Documentao de usurio impressa e/ou on-line completitude 4 Documentao de usurio impressa e/ou on-line usabilidade 5 Documentao de usurio impressa e/ou on-line funcionalidade 6 Interface de usurio usabilidade 7 Interface de usurio funcionalidade 8 Software funcionalidade 9 Software portabilidade 10 Software eficincia 11 Software confiabilidade 12 Descrio do produto completitude 13 Embalagem completitude

14 Embalagem usabilidade 15 Desinstalao portabilidade

C.1.5 Concluses do Relatrio (Este espao de concluso reservado para o avaliador fazer comentrios gerais sobre o produto.) Recomenda-se rever os itens listados nos Aspectos a serem revistos, para adequar o software s exigncias de qualidade expostas nas normas NBR ISO/IEC 9126-1 ABNT 2003 e a NBR ISO/IEC 25051 ABNT 2008.

APNDICE D Conceitos de qualidade para produtos de software uma sntese

D.1 Para qualidade na utilizao do produto de software Tendo como referncia o modelo de qualidade em uso, da norma NBR ISO/IEC 91261, 2003, podem ser estabelecidos como requisitos de qualidade os seguintes itens: uanto ualidade em so O software deve ser capaz de permitir que usurios especificados atinjam com eficcia, produtividade, segurana e satisfao, metas especificadas, no contexto de uso especificado para o produto. Isto , o software deve atender os seguintes requisitos:

Eficcia O software deve permitir que os usurios especificados atinjam, com acurcia
e completitude, metas especificadas no contexto de uso especificado.

Produtividade O software deve permitir que seus usurios diretos e indiretos

empreguem quantidade apropriada de recursos em relao eficcia obtida, no contexto de uso especificado.

Segurana O software deve apresentar nveis aceitveis de riscos de danos a pessoas,

negcios, software, propriedades ou ao ambiente, no contexto de uso especificado.

Satisfao O software deve satisfazer usurios, no contexto de uso especificado.

D.2 Para qualidade interna e externa do software Tomando como referncia o modelo de qualidade interna e externa, da norma NBR ISO/IEC 91261, podem ser estabelecidos como requisitos de qualidade os seguintes itens: uanto uncionalidade O software deve prover funes que atendam necessidades explcitas e implcitas, quando utilizado sob condies especificadas, isto , o software deve atender os seguintes requisitos:

Adequao O software deve evidenciar a presena de um conjunto de funes

apropriadas para as tarefas especificadas a serem realizadas, com a utilizao do software.

Acurcia O software deve prover, com o grau de preciso necessrio, resultados ou

efeitos corretos ou conforme acordados.

Interoperabilidade O software deve ser capaz de interagir com um ou mais sistemas

que forem especificados.

Segurana de acesso O software deve ser capaz de proteger informaes e dados, de

forma que pessoas ou sistemas no autorizados no possam llos nem modificlos, e que no seja negado o acesso s pessoas ou sistemas autorizados, quando for o caso.

Conformidade O software deve estar de acordo com normas, convenes ou

regulamentaes previstas em leis e prescries similares relacionadas sua funcionalidade.

uanto sa ilidade O software deve ser capaz de ser compreendido, apreendido e operado pelo usurio alvo, e convm que seja atraente para o usurio-alvo, quando usado sob condies especificadas, isto , o software deve atender os seguintes requisitos:

Inteligibilidade O software deve possibilitar ao usurio compreender se o software

apropriado e como ele pode ser usado para tarefas e condies de uso especficas.

Apreensibilidade O software deve possibilitar ao usurio apreender sua aplicao. Operacionalidade O software deve possibilitar ao usurio operlo e controllo. Atratividade Convm que o software seja atraente ao usurio. Conformidade Convm que o software esteja de acordo com normas, convenes,
guias de estilo ou regulamentaes relacionadas sua usabilidade.

uanto on ia ilidade O software deve manter um nvel de desempenho especificado, quando usado em condies especificadas, isto , o software deve atender os seguintes requisitos:

Maturidade O software deve evitar falhas decorrentes de defeitos no software. Tolerncia a Falhas O software deve manter um nvel de desempenho especificado,
em casos de defeitos no software ou de violao de sua interface especificada.

Recuperabilidade O software deve restabelecer seu nvel de desempenho

especificado e recuperar os dados diretamente afetados, no caso de uma falha.

Conformidade O software deve estar de acordo com normas, convenes ou

regulamentaes relacionadas sua confiabilidade.

uanto ici ncia O software deve apresentar desempenho apropriado, relativo quantidade de recursos usados, sob condies especificadas, isto , o software deve atender os seguintes requisitos:

Relao ao Tempo Convm que o software fornea tempos de resposta e de

processamento, alm de taxas de transferncia, apropriados, quando o software executa suas funes, sob condies estabelecidas.

Utilizao de Recursos Convm que o software utilize tipos e quantidades apropriados

de recursos, quando o software executa suas funes sob condies estabelecidas.

Conformidade Convm que o software esteja de acordo com normas e convenes

relacionadas sua eficincia.

uanto anuteni ilidade O software deve ser manutenvel. As modificaes podem incluir correes, melhorias ou adaptaes do software, devido a mudanas no ambiente e nos seus requisitos ou especificaes funcionais, isto , o software deve atender os seguintes requisitos:

Analisabilidade Convm que o software permita diagnosticar deficincias ou causas

de falhas no software, ou permita identificar partes a serem modificadas.

Modificabilidade Convm que o software permita que uma modificao especificada

seja implementada.

Estabilidade Convm que o software possua propriedades ou mecanismos para evitar

efeitos inesperados, decorrentes de modificaes no software.

Testabilidade Convm que o software permita que, quando modificado, seja validado. Conformidade Convm que o software esteja de acordo com normas ou convenes
relacionadas sua manutenibilidade.

uanto orta ilidade Quando for o caso, o software deve ser transfervel de um ambiente para outro especificado, isto , o software deve atender os seguintes requisitos:

Adaptabilidade Convm que o software seja adaptvel a diferentes ambientes

especificados, sem necessidade de aplicao de outras aes ou meios alm daqueles fornecidos, para essa finalidade, pelo software considerado.

Capacidade para Instalado Convm que o software seja instalvel nos ambientes
especificados.

Coexistncia Quando for o caso, convm que o software seja capaz de coexistir com
outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns.

Capacidade para Substituir Quando for o caso, convm que o software seja capaz de
ser usado em substituio a outro produto de software especificado, com o mesmo propsito e no mesmo ambiente.

Conformidade Convm que o software esteja de acordo com normas ou convenes

relacionadas sua portabilidade.

D.3 Para qualidade de software tipo pacote Tomando como referncia os requisitos de qualidade da norma NBR ISO/IEC 25051, o pacote de software como um todo, alm do software, tambm deve apresentar: um documento de Descrio do Produto e a Documentao para o Usurio. Para cada um desses componentes do produto, so estabelecidos os seguintes requisitos: uanto escri o do roduto O software deve apresentar um documento de Descrio do Produto. Este deve descrever sobre o produto em geral, desde questes da instalao, sua documentao do usurio, sua utilizao, seus programas e, se existirem, sobre os dados. Os principais objetivos da descrio de produto so: ajudar o usurio ou o comprador em potencial na avaliao da adequao do produto s suas necessidades; fornecer informaes para venda; e servir como base para testes. Deve, tambm, estar disponvel a pessoas interessadas no produto e ser suficientemente inteligvel, completa e possuir boa organizao e apresentao, a fim de auxiliar os potenciais compradores na avaliao da adequao do produto s suas necessidades.

O documento de descrio do produto de software deve atender os seguintes requisitos:

Identificaes e Indicaes O Documento de Descrio do produto deve possuir as

seguintes identificaes e indicaes:

Ttulo A descrio do produto deve possuir um ttulo que o identifique. Produto O produto a ser descrito deve estar identificado, contendo no mnimo o
nome do produto e a verso ou data de criao.

Produtor e Fornecedores O produtor e pelo menos um fornecedor devem estar

identificados, por maio de nome, CGC e endereo.

Tarefas As atividades que podem ser realizadas com a utilizao do produto devem
ser relacionadas.

Conformidade a documentos de requisitos A descrio de produto pode referir-se

aos documentos, leis, praxes etc. com os quais o produto est em conformidade.

Requisitos de hardware e software Os requisitos para colocar o produto em uso

devem ser especificados, incluindo nomes de fabricantes e identificao do tipo de todos os componentes, com nome e verso.

Interfaces com outros produtos Se a descrio do produto faz referncias a

interfaces com outros produtos, essas interfaces ou produtos devem ser identificados.

Itens a serem entregues Todo componente fsico do produto fornecido deve ser
identificado, em particular todos os documentos impressos ou armazenados.

Instalao do produto Deve ser declarado se a instalao pode, ou no, ser

conduzida pelo usurio.

Suporte Deve ser declarado se o suporte para operao do produto oferecido ou

no. Em caso afirmativo, deve ser especificado o meio de contato.

Manuteno Deve ser declarado se a manuteno oferecida ou no. Em caso

afirmativo, deve ser declarado o que includo e as condies para fornecimento de manuteno.

Declaraes sobre Funcionalidade A descrio do produto deve possuir declaraes

sobre a funcionalidade do produto, incluindo referncias sobre:

Viso geral das funes A descrio de produto deve fornecer uma viso geral das
funes disponveis para o usurio do produto, os dados necessrios e as facilidades oferecidas.

Valores-limites Se o uso do produto limitado por valores limites especficos,

estes devem ser fornecidos. Por exemplo: valores mximos ou mnimos, comprimento de chaves, nmero mximo de registros em um arquivo, nmero mximo de critrios de busca, ou tamanho mnimo de amostra.

Segurana de acesso Convm que a descrio de produto inclua informaes a

respeito de maneiras, se fornecidas, para evitar o acesso no autorizado (acidental ou intencional) a programas e dados.

Declaraes sobre Confiabilidade A descrio de produto deve incluir informaes

sobre a confiabilidade do produto, incluindo referncias sobre:

Preservao dos dados A descrio de produto deve incluir declaraes sobre

procedimentos para preservao de dados (por exemplo, backup ou cpia de segurana).

Propriedades adicionais Convm que propriedades adicionais do produto (como:

verificao se a entrada aceitvel, proteo contra consequncias danosas decorrentes de erro de usurio, recuperao de erro) sejam descritas, para assegurar a capacidade funcional do produto.

Declaraes sobre Usabilidade A descrio de produto deve incluir informaes sobre

a usabilidade do produto, incluindo:

Interface de usurio O tipo de interface com o usurio deve ser especificado; por
exemplo: linha de comando, menu, janelas, teclas de funo e funo de auxlio.

Conhecimento requerido O conhecimento especfico requerido (de uma rea

tcnica, de um sistema operacional, que possa ser adquirido via treinamento especial, outro idioma diferente da descrio de produto) para a aplicao do produto deve ser descrito.

Idiomas Devem ser declarados todos os idiomas utilizados na documentao de

usurio e na interface com o usurio (incluindo mensagens de erro e dados visveis), tanto os do prprio software como os de todos os outros produtos mencionados na descrio de produto.

Adaptao s necessidades do usurio Se o produto pode ser adaptado (mudana

de parmetros, mudana de algoritmos para computao, atribuio de teclas de funo) pelo usurio, ento as ferramentas para essa adaptao e as condies para seu uso devem ser identificadas.

Proteo contra infraes a direitos autorais Se a proteo tcnica contra

infraes a direitos autorais (proteo tcnica contra cpias, datas programadas de expirao de uso, lembretes interativos para pagamento por cpia) puder dificultar a usabilidade, ento esta proteo deve ser declarada.

Eficincia de uso e satisfao de usurio A descrio de produto pode incluir

dados sobre a eficincia de uso e satisfao de usurio.

Declaraes sobre Eficincia A descrio de produto pode incluir dados sobre o

comportamento do produto em relao ao tempo, tais como tempo de resposta e taxas de processamento para uma dada funo, sob condies estabelecidas (por exemplo, da configurao do sistema).

Declaraes sobre manutenibilidade A descrio de produto pode conter declaraes

sobre manutenibilidade.

Declaraes sobre portabilidade A descrio de produto pode conter declaraes

sobre portabilidade.

uanto ocumenta o para o su rio do produto de so t are O produto de software deve apresentar uma documentao para o usurio, que deve atender os seguintes requisitos:

Completitude A documentao de usurio deve conter todas as informaes

necessrias para o uso do produto, incluindo:

Descrio da Funcionalidade Todas as funes que aparecem na interface com o

usurio, ou mencionadas na descrio do produto, devem estar completamente descritas na documentao do usurio. So relevantes aspectos como informaes bem definidas, apropriadas e completas sobre o produto.

Descrio dos Valores-Limites Todo valor-limite deve ser descrito na

documentao de usurio.

Manual de Instalao Se a instalao puder ser executada pelo usurio, a

documentao de usurio dever incluir um manual de instalao, contendo todas as informaes necessrias para tal. Convm que o manual de instalao estabelea os espaos de armazenamento mnimo e mximo para a instalao do produto.

Manual de Manuteno Se algum tipo de manuteno puder ser executado pelo

usurio, a documentao de usurio dever incluir um manual de manuteno de programa, contendo todas as informaes necessrias para essa manuteno.

Usabilidade da Documentao A documentao deve possuir atributos que reduzam o

esforo que o usurio emprega na utilizao da documentao e facilitem a aprendizagem para utilizao do produto. So relevantes aspectos como facilidade de localizao das informaes (possuindo, por exemplo, ndices analtico e remissivo), a linguagem utilizada (correo, consistncia, inteligibilidade), boa apresentao e organizao, recursos empregados para esclarecimento das informaes, a presena de tutorial para aprendizagem e guia rpido de referncia para consultas.

Quanto ao Software O software deve atender os seguintes requisitos:

Funcionalidade O produto deve apresentar um conjunto de funes que permita a

realizao das tarefas propostas. As funes devem estar bem especificadas e devem mostrar-se capazes de suprir as necessidades do usurio. Dentro desse aspecto, tambm so relevantes fatores como: presena de funes que permitem a interao do software com outros produtos de software especificados e funes que garantam a preveno de aes indevidas no software. As funes do software tambm devem atender os seguintes requisitos:

Instalao Se a instalao puder ser realizada pelo usurio, deve ser possvel
instalar os programas com sucesso, seguindo as informaes contidas no manual de instalao. Os requisitos de hardware e software apresentados na descrio de produto devem ser suficientes para a instalao dos programas. Aps a instalao, deve ser possvel identificar se os programas funcionam; por exemplo, usando guias de teste fornecidos, ou por meio de autoteste com as mensagens correspondentes.

Presena de funes Todas as funes mencionadas na documentao de usurio

devem ser executveis na forma nela descrita, com os correspondentes recursos, propriedades e dados, e dentro dos valores-limites fornecidos.

Correo Os programas e dados devem corresponder a todas as declaraes

contidas na descrio de produto e na documentao de usurio. As funes devem ser executadas de maneira correta, para a realizao de uma tarefa. Em particular, programas e dados devem estar de acordo com todos os requisitos definidos em qualquer documento de requisitos citado na descrio de produto.

Consistncia Os programas e dados no devem conter contradies internas,

contradies com a descrio do produto e com a documentao de usurio. Convm que cada termo tenha um significado nico em toda a documentao. Convm que o controle da operao do programa pelo usurio e o comportamento do programa (por exemplo: mensagens, formatos de tela de entrada e relatrios impressos) sejam estruturados de maneira uniforme.

Funcionalidade da Interface So funes que satisfazem s necessidades de

interao com o usurio. So relevantes aspectos como:

Adequao A nomenclatura atribuda para os objetos de interao da interface (os

rtulos dos campos, menus e janelas, as legendas, os cabealhos) deve expressar corretamente seu significado ao usurio. Tambm deve permitir fcil reconhecimento das funes representadas pelos cones; as opes de menu e submenus devem ser correlacionadas; a posio de botes e cones deve ser adequada e deve apresentar somente as informaes relacionadas tarefa a ser executada.

Acurcia As funes de interface devem apresentar consistncia. Por exemplo, na

seleo das opes de interface, o resultado deve estar de acordo, incluindo ttulos etc. Alm disso, as informaes devem ser corretas, tais como: unidades de medida 2 (m, m , Km, L, etc.), moeda corrente (R$, US$ etc.), representao de cones e contedo das mensagens.

Conformidade Os padres internos devem ser respeitados. Por exemplo, o idioma:

se o mercado-alvo for o Brasil, ento a interface toda dever estar em portugus; o formato escolhido para as janelas (rtulos das janelas, caixas de dilogo, campos de entrada, botes e menus, a fonte em relao ao seu tipo, estilo, tamanho, cor e espaamento dos caracteres) deve ser mantido; vocabulrio; resultados apresentados de forma destacada; posies dos botes, formato do cursor, ponteiros etc.

Confiabilidade a capacidade do software em manter seu nvel de desempenho e

recuperar-se na ocorrncia de falhas. As falhas podem ocorrer devido a erro de software, uso incorreto pelo usurio ou problemas no ambiente. So relevantes os seguintes aspectos:

Maturidade O sistema, compreendendo hardware e software, bem como os

programas que pertencem ao produto, no deve entrar em um estado no qual o usurio no consiga control-lo, nem deve corromper ou perder dados. Este requisito deve ser cumprido, ainda que: a capacidade seja explorada at os limites especificados; tentativas sejam feitas para explorar a capacidade alm dos limites especificados; uma entrada incorreta seja feita pelo usurio ou por outros programas listados na descrio de produto; instrues explcitas na documentao de usurio sejam violadas. Esto excludas somente as possibilidades de interrupo do hardware e do sistema operacional, que no podem ser controladas por nenhum

programa (por exemplo, a tecla ou combinaes de teclas para reinicializar o sistema operacional).

Tolerncia a falhas Os programas devem reconhecer as violaes da sintaxe

estabelecida para entrada de dados. No caso de um programa reconhecer uma entrada como errnea ou indefinida, ele no deve process-la como uma entrada permitida.

Usabilidade da Interface A interface deve propiciar a reduo do esforo que o

usurio emprega na interao com a interface. So relevantes os aspectos como: utilizao de uma linguagem simples e natural, prxima da linguagem do usurio especificado; ausncia de requisio de dados e informaes j requisitadas anteriormente; padronizao no modo de requisitar uma informao do usurio ou dar informao a ele; informao ao usurio do que est ocorrendo no sistema; apresentao de um meio fcil de desfazer erros e mesmo de sair do sistema; existncia de diversos nveis de ao do usurio, dependendo do seu grau de familiaridade com a interface; fornecimento de mensagens no ambguas; requisio de dados com um modo de consistncia para preveno de erros por parte do usurio; adequao do esforo de aprendizado e utilizao do software.

Apresentao e organizao Cada meio de armazenamento de dados deve apresentar

a identificao do produto e, se existir mais de um meio, eles devem ser distinguidos por um nmero ou texto. Deve ser sempre possvel ao usurio, quando estiver trabalhando com os programas, descobrir qual funo est sendo executada. Convm que os programas forneam ao usurio informaes claramente visveis e fceis de serem lidas. Convm que o usurio seja guiado por informaes codificadas e agrupadas adequadamente. Onde for necessrio, convm que os programas alertem o usurio. Convm que as mensagens dos programas sejam projetadas de forma que o usurio possa diferenci-las facilmente pelo tipo. Convm que os formatos de tela de entrada, de relatrios e de outras entradas e sadas sejam projetados para serem claros e com boa apresentao e organizao.

Operacionalidade A execuo de funes que tm consequncias graves deve ser

reversvel, ou os programas devem dar uma clara advertncia sobre as consequncias e requisitar a confirmao antes da execuo do comando. Em particular, o processo de apagar dados ou sobrep-los, bem como de interromper um processamento demorado, tem conseqncias graves. Se um texto de documentao exibido em um dilogo, convm que o usurio seja capaz de fazer acesso aos subitens do texto, de maneira direta - por exemplo: pela seleo em uma tabela de contedo exibida na tela, ou por uma funo de busca baseada em palavras-chaves.

Eficincia o conjunto de atributos que evidenciam a quantidade de recursos de

mquina e de tempo utilizados pelo software, na execuo de suas funes. So relevantes, aspectos como a quantidade de memria, espao em disco, velocidade de processamento e resposta, tempo de utilizao de perifricos etc.

Manutenibilidade No h exigncia; entretanto, o produto deve estar em

conformidade com as declaraes de manutenibilidade citadas em sua descrio.

Portabilidade a capacidade do software de ser transportado de um ambiente para

outro. So relevantes, aspectos como independncia em relao ao hardware, facilidade de instalao em vrios ambientes de hardware ou software. uanto orma de Apresenta o O produto deve atender os seguintes requisitos:

Contedo Caso o produto no seja distribudo pela Internet, todo o material pertinente
ao produto de software, como manuais, discos, dispositivos de segurana, dever estar embalado e identificado.

Adequao A embalagem dever ser adequada para o acondicionamento seguro

desse material. Toda a identificao do produto de software, como nome, contedo, fabricante, verso, nmero de srie etc. dever ser visvel e legvel.

RELATRIO DE AVALIAO DO PRODUTO EASY LEARN

1. ESCOPO
Este documento apresenta o resultado da avaliao genrica da qualidade do produto de software Easy Learn,. O Easy Learn compreende um dicionrio em 6 idiomas; dicionrio de ilustraes e mdulos de treinamento para auxiliar na aprendizagem do idioma ingls.

2. INTRODUO
A avaliao do produto teve como objetivo observar o atendimento s caractersticas de qualidade de um produto de software, analisando seus atributos de qualidade, com base na norma NBR ISO/IEC 9126-1. Por meio da verificao ao atendimento dos requisitos de Pacote de Software apresentados pela norma NBR ISO/IEC 12119, foi possvel selecionar alguns itens essenciais completa identificao do produto, quando aplicvel. A avaliao foi realizada por 1 avaliador, perfazendo um total de 48 horas de avaliao.

3. O PROCESSO DE AVALIAO
O processo de avaliao de produto de software, de acordo com o que recomendado pela norma NBR ISO/IEC 14598-1, deve seguir as etapas: a- Anlise de Requisitos da Avaliao O objetivo da Anlise de Requisitos levantar os Requisitos da Avaliao; b- Especificao da Avaliao Nesta etapa so definidos o escopo, restries, mtodos a serem utilizados e as responsabilidades das partes na avaliao; c- Projeto da Avaliao Nesta etapa definido o plano de avaliao, com o detalhamento dos instrumentos a serem utilizados, prazos, custos, equipe de avaliao, riscos associados e todas as atividades envolvidas na execuo da avaliao; d- Execuo da Avaliao Nesta etapa so efetuadas as medies, coleta dos dados e das informaes, e realizado o procedimento de anlise.

4. ITENS DE AVALIAO
A seguir ser apresentado o resultado da avaliao, destacando pontos que atendem as normas de qualidade de software (destaque positivo) e os pontos a serem revistos, com sugestes de melhoria na Instalao, Documentao do Usurio, Interface de Usurio, Software , Descrio do Produto, Embalagem e Desinstalao deste produto de software. 4.1 INSTALAO - COMPLETITUDE Aspectos de destaque positivo

Para instalao do produto de software, os componentes de mdia foram identificados adequadamente, com o nome do produto e ano de criao do produto. Aspectos a serem revistos Na documentao do usurio (Guia de Referncia Rpida), no esto presentes importantes informaes para instalao, como: especificao dos requisitos de hardware e software e outros dados; No documento de descrio do produto, que neste caso foi considerado como o conjunto de informaes do produto contidas na Embalagem, no est declarado se a instalao do produto pode, ou no, ser conduzida pelo usurio.

4.2 INSTALAO - PORTABILIDADE Aspectos de destaque positivo Apresenta instrues para instalao na contracapa do CD, orientando, passo a passo, como executar as aes da instalao; A instalao automatizada. Aspectos a serem revistos Durante o procedimento de instalao, j tendo o produto instalado no equipamento, apresentou a seguinte irregularidade: Apresentou a mensa em de erro rro de trans er ncia de arquivo. Verifique o diretrio destino. Durante o procedimento de instalao, no apresentou mensagem alertando o usurio de que o software j estava instalado.

4.3 DOCUMENTAO DO USURIO IMPRESSA E/OU ON-LINE - COMPLETITUDE Aspectos de destaque positivo Na documentao do usurio (Guia de Referncia Rpida), esto presentes importantes informaes sobre: identificao do produto; identificao das interfaces com os produtos do Windows, como ex. Word, Excel; indicao de valores-limites; As principais funes apresentadas pela interface e na descrio do produto esto documentadas; Na documentao do usurio (Guia de Referncia Rpida), est presente procedimento para adaptao de teclas de funo. Aspectos a serem revistos Na documentao do usurio, no esto presentes importantes informaes sobre: identificao do produtor; No tem indicao de verso ou data de criao do produto com o qual tem interface; No tem indicao de que o suporte tcnico para operao do produto seja oferecido ou no; No informa sobre a proteo tcnica contra infraes a direitos autorais, como consta na Embalagem: 1 Licena de Uso Validade Indeterminado e na capa do CD: Licena de Uso para Cliente (Usurio Final). 4.4 DOCUMENTAO DO USURIO IMPRESSA E/OU ON-LINE - USABILIDADE Aspectos de destaque positivo

A documentao organizada, permitindo uma fcil identificao das funes, com destaque de informaes relevantes; A documentao impressa utiliza papel de boa qualidade, possui tipo e tamanho da letra de fcil leitura, com boa qualidade de impresso; A documentao (impressa e on-line) clara e precisa, no dando margem a interpretaes ambguas, e de fcil entendimento, levando em considerao o pblico-alvo; A documentao on-line apresenta ndice geral, ndice remissivo e, quando necessrio, apresenta recomendaes a consultas adicionais e referncias cruzadas, atravs de links; Na documentao on-line, os recursos para avanos e retrocessos (links) esto estruturados adequadamente; A documentao (impressa e on-line) mantm uma padronizao em relao ao idioma, aos formatos dos ttulos de captulos, sees e subsees, apresentao das funes, distribuio de informao por pgina e aos termos utilizados. Aspectos a serem revistos Foram encontrados alguns erros de ortografia, no texto da documentao do usurio impressa (Guia de Referncia Rpida); Foram encontrados alguns erros de ortografia, no texto da documentao do usurio on-line; A documentao, impressa e on-line, no explica possveis mensagens de erro; A documentao on-line no possui exemplos; A documentao on-line possui poucas ilustraes das janelas do produto.

4.5 DOCUMENTAO DO USURIO IMPRESSA E/OU ON-LINE - FUNCIONALIDADE Aspectos de destaque positivo H coerncia no tratamento das informaes, levando em conta sua forma de apresentao e contedo; A documentao possui harmonia entre suas partes e se complementa de forma natural, facilitando o aprendizado progressivo do produto; A documentao impressa no apresenta contradio entre suas informaes; Na documentao impressa, no foram encontradas evidncias de informaes incorretas. Aspectos a serem revistos Na documentao on-line, foram encontradas algumas contradies com relao aos ttulos apresentados no ndice Geral; Na documentao on-line, foram encontradas algumas evidncias de informaes incorretas, como: Na tela, radu indo rocura Autom tica press es, re ere-se ao ot o press es, e no produto consta o ot o

4.6 INTERFACE DE USURIO- USABILIDADE Aspectos de destaque positivo

A interface apresenta um bom aspecto visual; por exemplo, utilizam moderadamente negritos, itlicos, sublinhados, os recursos de cores, os recursos de efeito, de animao; os textos apresentam-se adequadamente, com relao a fonte, tamanho e espaamento dos caracteres; As janelas seguem um padro na distribuio dos objetos, facilitando o entendimento dos mesmos, e apresentam uma distribuio uniforme de seu contedo, levando em considerao o espao disponvel; As mensagens so controlveis pelo usurio, em relao ao tempo de exposio na tela; A interface utiliza linguagem compatvel com o tipo de usurio a quem se destina o produto; O texto apresentado na interface no d margens a interpretaes ambguas; A interface otimiza a entrada de dados com combo box; A interface informa, por meio do indicador de progresso ou ampulheta do Windows, o tempo necessrio para a operao se completar; A interface utiliza teclas convencionais, para ter acesso a campos posteriores e anteriores, tais como: <Tab>, <Enter>, <Esc>; Quanto proteo contra infraes a direitos autorais, algumas funes somente executam tendo-se o CD, e existe indicao de Licena de uso na Embalagem. Aspectos a serem revistos A interface nem sempre informa ao usurio sobre o que um boto, menu ou cone faz ao se posicionar o cursor do mouse so re o mesmo por e emplo as op es de menu e os cones do ditor de e tos, na anela e tos, no apresentam os nomes dos cones ao posicionar o cursor sobre eles; A interface nem sempre possibilita realizao de tarefas com nmero reduzido de passos. Sugere-se a incluso de teclas de atalho, tais como: <Alt>+<P> ou <Ctrl>+<P>, para Imprimir; <Alt>+<S> ou <Ctrl>+<S>, para Sair; <Alt>+<E> ou <Ctrl>+<E>, para Editar Dicionrio; A interface nem sempre possibilita renomear teclas de atalho; como exemplo, F1 para acessar A uda, em ora permita renomear as teclas de atal o , e A interface no possibilita personalizao de janelas; A interface no apresenta os campos de entrada de dados delimitados de acordo com o nmero mximo de caracteres permitido; A interface nem sempre exibe mensagens de orientao ao usurio, tais como: ao selecionar o cone radu ir conte do da rea de trans er ncia, n o apresenta mensa em orientando o usurio que no h contedo na rea de transferncia; ao inserir o dado , , na rea de Texto, apresentada a traduo da primeira palavra da lista do Dicionrio, e no apresenta mensagem de erro, por se tratar de dado numrico. A interface no possui um tutorial para auxiliar o usurio no entendimento e aprendizagem do produto; A interface nem sempre posiciona o cursor no incio dos campos de entrada de dados e nem sempre possui recurso de limpe a autom tica desses campos por e emplo em in nimos, ao ser solicita do um sin nimo que n o locali ado, apresenta a mensa em o encontrado, e a palavra solicitada passa a ser apresentada de forma destacada, em cinza, alertando que o sinnimo no est dispon vel este caso n o limpou o campo rea de e to , ao teclar < enter>, e no posicionou o cursor no incio do campo. Sendo assim, ao digitar uma nova palavra, esta foi apresentada diretamente ligada palavra anterior. 4.7 INTERFACE DE USURIO - FUNCIONALIDADE Aspectos de destaque positivo

A nomenclatura dos objetos de interao da interface est bem definida, orientando o usurio na compreenso e execuo da tarefa; A interface bem estruturada (menus em nveis hierrquicos, posicionamento de botes...), de modo a facilitar a seleo das opes relevantes execuo das tarefas; Possui reas de seleo dos itens de menu bem dimensionadas, de forma a facilitar sua visualizao; A interface mantm uma padronizao em relao: ao idioma, configurao das janelas, formatao de labels, s mensagens, apresentao de resultados aos usurios, ao posicionamento de botes, aos formatos dos campos de dados, s funes de interface do sistema operacional, ao formato do cursor e s cores. Aspectos a serem revistos A interface faz uso de cones que nem sempre representam claramente seu significado; por exemplo, elecionar um icion rio em tico, radu ir conte do da rea de trans er ncia, imas Procura on tica A interface nem sempre apresenta mensagens de orientao, por exemplo: o ditor de orientao; e tos, n o imprimiu o arquivo desejado e no apresentou mensagem de

No Comando Imprimir, sub-op o do enu principal Arquivo, ao solicitar para imprimir alavras istas o e, n o apresentou mensa em de erro e n o imprimiu este relat rio solicitado A interface nem sempre apresenta somente as informaes pertinentes execuo da tarefa; Foram observadas algumas contradies entre o nome da opo do menu e o correspondente da janela, tais como:

Menu Filtrar Lista Tabelas de Numerais Glossrio da Internet Dicionrio Ilustrado Converso de Medidas Editor de Textos Filtrar Numerais

Janela

Glossrio de Termos da Internet Dicionrio de Ilustraes Converso Textos

Ao e ercitar as un executam;

es de inter ace re erentes ao ditor de

e tos, as op

es de menu n o

A interface nem sempre mantm uma padronizao em relao aos cones; por exemplo: um cone tem a mesma representao na janela principal e na janela do Editor de Textos, mas com funes associadas di erentes imas rocura on tica e rocurar e to 4.8 SOFTWARE - FUNCIONALIDADE Aspectos de destaque positivo Todas as funes do software, especificadas na documentao, foram implementadas e so executveis conforme descrito na documentao; Permite a leitura e gravao de arquivos-textos no formato t t, no ditor de e tos

ermite a leitura de i uras nos ormatos mp e m , con orme o menu de op arquivos das i uras de o o da orca Possui recursos de link; As normas t cnicas s o respeitadas no ditor de e tos O software demonstrou possuir recurso de proteo a programas e dados. Aspectos a serem revistos

es de e tens o de

O software nem sempre possui opo de interveno em funes que esto em execuo, por exemplo: No foi possvel mudar de janela, em itua es de ia em, de alavras para rases speciais; nem selecionar frase ou palavra desejada, utilizando scroll e cursor , como foi possvel em e redos de ron ncia e em tudo o que parece As funes do software nem sempre geraram resultados conforme o esperado, tais como: o ditor de e tos, na anela e tos, n o imprimiu o arquivo dese ado e n o apresentou uma mensagem de orientao; o comando mprimir, su op o do menu principal Arquivo, ao solicitar para imprimir alavras istas o e, no apresentou mensagem de erro e no imprimiu o relatrio solicitado; Ao solicitar mpress o de elat rios de alavras mportantes, n o tendo a impressora conectada, apresentou a barra de status mostrando a porcentagem impressa, e no apresentou mensagem de erro por no ter impressora conectada; nserindo no icion rio a e press o o do , com a tradu o u tam m e, ao entrar nos dicionrios, essa expresso no foi localizada, foi apresentada a traduo da palavra mais prxima. Mas, ao inserir uma outra palavra, sa ilit , como su stantivo, esta oi posteriormente localizada no Dicionrio. so t are n o possui recurso de prote Undo no ditor de e tos o contra erros na opera o, como un o des a er ou

4.9 SOFTWARE

EFICINCIA

Aspectos de destaque positivo Em operaes interativas, o tempo de resposta operao est apropriado, levando em considerao a complexidade do produto e o volume de dados manipulados; O software, quando est interagindo com outros perifricos (impressora), tem o tempo de resposta compatvel com o perifrico e no impede o uso de outras funes; Os recursos de hardware especificados pelo produtor so apropriados s necessidades do software.

4.10 SOFTWARE - CONFIABILIDADE Aspectos de destaque positivo Em situaes de violao de uso, o software no apresentou propagao de erros na entrada de dados com formatao diferente da estipulada, e na entrada de dados inconsistentes; Aps a ocorrncia de uma falha, no exigiu que o sistema operacional fosse reiniciado para prosseguir sua utilizao.

Aspectos a serem revistos

O software apresentou algumas falhas, tais como: Ao utilizar o Dicionrio, no tendo impressora disponvel e fechando o Dicionrio, apresentou a se uinte mensa em de erro lot Ocorreu um erro em seu programa. Para mant-lo uncionando, clique em norar e salve o tra al o em um novo arquivo ara sair, clique ec ar oc perder as in orma es adicionadas desde a ltima ve que as salvou licando em norar, apresentou a mensa em ste pro rama e ecutou uma opera o ile al e ec ou o aplicativo; Ao selecionar a op o Associa o de i uras , de erc cios e reinamentos, apresentou a se uinte mensa em correu um erro em seu pro rama ara mant -lo funcionando, clique em norar e salve o tra al o em um novo arquivo ara sair, clique em ec ar oc perder as in orma es adicionadas desde a ltima ve que as salvou , ec ar norar Ao clicar em ec ar, apresentou a mensa em ro rama e ecutou uma opera o ile al e ser ec ado e o problema persistir, contate o revendedor, ec ar etal es licando em etal es causou uma falha de proteo geral nos e istradores ec ou o aplicativo ao clicar em ec ar m deo- icas, em itua es de ia em, na op o o as, apresentaram mensagem de erro: ser de ined error e, clicando em , ec ou esta anela, retornou anela principal do Easy Learn e fechou o aplicativo. O software nem sempre su mete os dados de entrada a testes de consist ncia, como na rea de e to, ao inserir o dado 3,21, no realizou teste de consistncia desse dado; apresentou a traduo da primeira palavra da lista, e no apresentou mensagem de erro; No caso de ocorrncia de falhas, o sistema no apresentou mensagens de orientao nem de como resolver o erro que possa levar a persistncia ou propagao das provveis causas de falha; No dispe de funo automatizada para backup dos dados. 4.11 SOFTWARE - PORTABILIDADE Aspectos de destaque positivo O produto de software pode ser instalado em ambiente de rede. 4.12 DESCRIO DO PRODUTO - COMPLETITUDE Aspectos de destaque positivo Apresenta as informaes requeridas para um documento de Descrio do Produto, que neste caso esto disponibilizadas na embalagem, segundo orientaes da Norma NBR ISO/IEC 12119; No documento de Descrio do Produto, esto presentes importantes informaes sobre: identificao do produto; identificao do produtor; identificao do fornecedor (o prprio produtor); identificao das tarefas realizadas com o uso do produto; especificao dos requisitos de hardware e software; especificao do ambiente operacional do software; uma viso geral das funes existentes; declarao de fornecimento de suporte tcnico; indicao da usabilidade da interface por meio de imagens, como menus, janelas e caixas de dilogos.

Aspectos a serem revistos No documento de Descrio do Produto, no esto presentes importantes informaes sobre: especificao dos dispositivos de sada; especificao das capacidades dos perifricos, memria de vdeo e impressora; indicao dos itens entregues (contedo da embalagem); declarao de fornecimento de manuteno.

4.13 EMBALAGEM - COMPLETITUDE Aspectos de destaque positivo Algumas identificaes foram encontradas corretamente na embalagem do produto, tais como: nome do produto; verso do produto; nome do produtor; requisitos de hardware e software; tarefas que podem ser executadas, utilizando o software; e forma de contato com o produtor. Aspectos a serem revistos Algumas identificaes no foram encontradas na embalagem do produto, tais como: descrio do contedo da embalagem e indicao de que a instalao pode, ou no, ser conduzida pelo usurio. 4.14 EMBALAGEM USABILIDADE

Aspectos de destaque positivo Apresenta um bom aspecto visual, utilizando letras e cores adequadas ao tipo de produto, destacando as principais informaes; A embalagem prtica, possuindo um encaixe prtico e simples, para abrir e fechar, e no dificulta o manuseio com os componentes do produto.

4.15 EMBALAGEM

FUNCIONALIDADE

Aspectos a serem revistos A embalagem no resistente, pois rasga e amassa com facilidade. 4.16 DESINSTALAO - PORTABILIDADE Aspectos de destaque positivo H instrues de desinstalao, apresentando os procedimentos a serem executados de forma clara; A desinstalao bem sucedida; o procedimento de desinstalao remove, de forma completa, os cones de chamada do programa, itens de programa e grupo de programa.

5. CONCLUSES
Recomenda-se rever os itens listados nos Aspectos a serem revistos, para adequar o software s exigncias de qualidade expostas nas normas NBR ISO/IEC 9126-1 e na atual NBR ISO/IEC 25051, a qual substituiu a NBR ISO/IEC 12119 e para a melhoria do produto com a viso de um usurio.

APNDICE F Glossrio

ABNT
Fundada em 1940, a ABNT Associao Brasileira de Normas Tcnicas o rgo responsvel pela normalizao tcnica no pas, fornecendo a base necessria ao desenvolvimento tecnolgico brasileiro. Sediada na cidade de So Paulo/ Brasil, a ABNT uma entidade privada, sem fins lucrativos, reconhecida como Frum Nacional de Normalizao NICO por meio da Resoluo n. 07 do CONMETRO, de 24.08.1992. membro fundador da ISO International Organization for Standardization, da COPANT Comisso Pan-americana de Normas Tcnicas e da AMN Associao Mercosul de Normalizao.

Acurcia
Atributos do software que evidenciam a gerao de resultados ou efeitos corretos ou conforme acordado. uma subcaracterstica de Funcionalidade.

Adaptabilidade
Atributos de software que evidenciam sua capacidade de ser adaptado a ambientes diferentes especificados, sem a necessidade de aplicao de outras aes ou meios alm daqueles fornecidos para esta finalidade, pelo software considerado. uma subcaracterstica de Portabilidade.

Adequao
Atributos de software que evidenciam a presena de um conjunto de funes e sua apropriao para as tarefas especificadas. uma subcaracterstica de Funcionalidade.

Algoritmo computacional
Conjunto de instrues sequenciais e precisas, sem ambiguidades, que permite obter a soluo de um problema a partir de alguns dados iniciais, previamente reconhecidos. As instrues elementares de um algoritmo devem ser executadas numa sequncia nica e predeterminadas.

Ambiguidade / Ambguo
Que se pode tomar em mais de um sentido; equvoco; cujo procedimento denota incerteza, insegurana; indeciso; indeterminado, impreciso, incerto.

Amostra
Fragmento ou exemplar representativo de alguma coisa. Amostra representativa: que foi obtida por um processo isento de vcio. Subconjunto de uma populao, por meio do qual se estabelecem ou estimam as propriedades e caractersticas dessa populao.

Ampulheta
Smbolo grfico, representado geralmente por um relgio de areia, que aparece no momento da execuo de um processamento.

Anexo
Parte incorporada a um documento.

Apndice
Parte anexa ou acrescentada a uma obra; acrscimo, anexo, acrescentamento.

Apreensibilidade
Atributos do software que evidenciam o esforo do usurio para apreender sua aplicao. uma subcaracterstica de Usabilidade

rea
Regio ou seo de uma tela ou janela que est localizada em uma posio consistente e utilizada consistentemente para atingir um objetivo especfico. Veja tambm Tela e Janela. rea, regio, superfcie, extenso. Uma seo de armazenamento (de dados de computador) reservada para um determinado fim. rea de trabalho: onde so mostrados os textos e grficos

rea de transferncia
rea intermediria que o ambiente operacional utiliza para passar informaes entre aplicativos

Atributo
Uma propriedade mensurvel, fsica ou abstrata de uma entidade.

Avaliao da qualidade
Exame sistemtico para determinar at que ponto uma entidade capaz de atender os requisitos especificados.

Avaliao por requisito

Fase da Verificao de Conformidade em que, de forma detalhada, sero avaliados todos os Requisitos Obrigatrios e Desejveis e a facilidade de uso do CSA, do ponto de vista do usurio e consideradas as normas tcnicas de qualidade de software.

Backup

Cpia de segurana, geralmente mantida em mdia digital, fitas magnticas ou CD-ROM, que permitem o resgate de informaes importantes ou programas em caso de falha do disco rgido.Caractersticas de qualidade de software

Balo explicativo/Bolha informativa/Tooltip

uma caixa de texto que serve para ver o nome de um cone de uma barra de ferramentas e pode conter uma breve explicao sobre a funo que o boto representa. Ativa-se posicionando o ponteiro do mouse sobre o boto, ou clicando no ponto de interrogao na barra de ttulo e em seguida no boto a ser esclarecido.

Barra de status
Apresenta informaes sobre o documento em uso ou sobre um comando selecionado

Boto
Figura representando botes materiais e que, normalmente selecionada por um dispositivo de apontamento (mouse) ou teclas de cursor, e executada por um boto do dispositivo de apontamento ou a tecla "Enter". usado para obter a entrada mais bsica de um usurio. Quando o usurio d um clique no boto de comando, est determinando que uma ao especfica seja executada imediatamente no programa.

Bugs
Um erro de programao que causa um defeito na funcionalidade de um programa. s vezes, o defeito no grave e o usurio pode conviver com ele; outras vezes, pode impedir por completo a utilizao do produto.

Caixa de Dilogo
Painel que apresenta um conjunto de diferentes tipos de mostradores de dados, informaes, mensagens, controles e comandos para apoiar o usurio em uma ao especfica.

Caractersticas de qualidade de software

Conjunto de atributos de um produto de software, por meio do qual sua qualidade descrita e avaliada. Uma caracterstica de qualidade de software pode ser detalhada em mltiplos nveis de subcaractersticas.

Campo de entrada de dados

So espaos na janela ou caixa de dilogo que permitem ao usurio a entrada de dados e informaes numricas e alfanumricas. Os campos podem ser opcionais ou obrigatrios.

Capacidade para ser instalado 3

A capacidade do produto de software para ser instalado em um ambiente especificado. uma subcaracterstica de Portabilidade.

Capacidade para substituir

A capacidade do produto de software para ser usado em substituio de outro produto de software especificado para o mesmo propsito no mesmo ambiente. uma subcaracterstica de Portabilidade.

CenPRA
Conforme Decreto 4.043 de 04 de dezembro de 2001, o Presidente da Repblica decretou a criao do CenPRA Centro de Pesquisas Renato Archer, para o qual foram transferidas a estrutura organizacional e as atividades de pesquisa e desenvolvimento da Diretoria de Tecnologia da Informao da Autarquia ITI Instituto Nacional de Tecnologia da Informao (antiga Fundao CTI Centro Tecnolgico para Informtica). Ligado diretamente ao MCT Ministrio da Cincia e Tecnologia e criado em 1982 com a finalidade de desenvolver e implementar pesquisas cientficas e tecnolgicas no setor de informtica, o CTI colabora ativamente com o setor acadmico e industrial, na medida em que promove a evoluo das tecnologias da informao, mantendo-se no estado da arte em diversos segmentos tecnolgicos-chave, abrangendo basicamente os setores de componentes, sistemas e software. Sua sede est localizada na cidade de Campinas, Estado de So Paulo Brasil.

Ciclo de vida
Conjunto de todas as etapas que compem a existncia de um sistema de software, desde o projeto at a retirada de operao.

CMM
Sigla utilizada para o modelo de processo de software desenvolvido pelo SEI, denominado Capability Maturity Model for Software.

CMMI
Sigla utilizada para o modelo de processo de software desenvolvido pelo SEI, denominado Capability Maturity Model Integration.

Coerncia
Ligao ou harmonia entre partes, situaes, acontecimentos ou ideias; relao harmnica; conexo, nexo, lgica. Estabelecimento de coeso, ligao ou adeso recproca.

Combo Box
Caixa de combinao - componente de uma caixa de dilogo que combina a capacidade de uma "caixa de texto" e uma "caixa de listagem", em ambiente grfico; possibilita a insero de valores ou

textos alternativos, ou a escolha de uma opo, no sistema drop-down (pode-se digitar texto na "caixa de texto" ou clicar sobre o boto de aviso e selecionar a partir da listagem exibida).

Comportamento em relao ao tempo

Atributos de software que evidenciam seu tempo de resposta, tempo de processamento e velocidade na execuo de suas funes. uma subcaracterstica de Eficincia.

Comportamento com relao aos recursos

Atributos de software que evidenciam a quantidades de recursos usados e a durao de seu uso na execuo de suas funes. uma subcaracterstica de Eficincia.

Confiabilidade
Conjunto de atributos que evidenciam a capacidade do software de manter seu nvel de desempenho sob condies estabelecidas durante um perodo de tempo estabelecido. Tem como subcaractersticas: Maturidade, Tolerncia a Falhas e Recuperabilidade.

Conformidade
Atributos do software que fazem com que o mesmo esteja de acordo com as normas, convenes ou regulamentaes previstas em leis e descries similares, relacionadas aplicao ( subcaracterstica de cada caracterstica, mas adequada a cada uma delas).

Conformidade Funcionalidade
A capacidade do produto de software de estar de acordo com normas, convenes ou regulamentaes em leis e prescries similares relativas funcionalidade.

Conformidade confiabilidade
A capacidade do produto de software de estar de acordo com normas, convenes ou regulamentaes relativas confiabilidade.

Conformidade usabilidade
A capacidade do produto de software de estar de acordo com normas, convenes, guia de estilo ou regulamentaes relativas usabilidade.

Conformidade eficincia
A capacidade do produto de software de estar de acordo com normas e convenes relativas eficincia.

Conformidade manutenibilidade

A capacidade do produto de software de estar de acordo com normas e convenes relativas manutenibilidade.

Conformidade portabilidade
A capacidade do produto de software de estar de acordo com normas e convenes relativas portabilidade.

Consistncia
Compatibilidade entre as partes. Concordncia aproximada entre os vrios resultados.

Conveno estilstica
Utilizao dos estilo (fontes e tamanhos) como cdigo para auxiliar na compreenso dos elementos de um texto.

Criptografia
Tcnica para codificar mensagens ou arquivos, tornando-os inviolveis, e permitindo que apenas sejam decodificados por seus destinatrios.

CTI
Centro de Tecnologia da Informao Renato Archer CTI, veja tambm

CenPRA.

Cursor
Determina onde o texto ser inserido quando for digitado.

Defeito
Um passo, processo ou definio de dados incorretos em um programa de computador. Veja tambm Erro e Falha.

Default
Valor predeterminado ou proposto pelos programas, frequentemente utilizado com o objetivo de reduzir as aes de entrada de usurio (escolha de opes, valores etc.). Default vem do francs e si ni ica na alta, isto na alta de o usu rio ter escol ido al o, o pro rama escol e am m pode ser traduzida como opo normal.

Descrio do produto
Um documento expondo as propriedades de um software, com o objetivo de auxiliar os potenciais compradores na avaliao da adequao do produto para sua aquisio, antes de adquiri-lo. Essa descrio pode estar disponvel em um catlogo prprio, na embalagem, em mdia digital de

apresentao, site, ou qualquer outro meio disponvel ao usurio, independente da aquisio do produto. Este documento nico e de fcil localizao.

Desempenho
A capacidade de um sistema ou componente computacional de realizar as funes designadas, dentro das restries dadas.

Diagramao
Diagramao de um livro: determinao da disposio dos espaos a serem ocupados pelos elementos (textos, ilustraes, legendas etc.) de livro, jornal, cartaz, anncio etc., indicando detalhadamente o formato do impresso, os tipos a serem utilizados, as medidas das colunas, etc. Determinao da disposio dos espaos a serem ocupados pelos objetos da interface (textos, figuras).

Dispositivo
Qualquer equipamento, perifrico ou no, ligado ao computador (impressora, modem, monitor, drive de disco, mouse, etc.).

Documentao do usurio/Documentos do usurio

o conjunto completo de documentos, disponvel na forma impressa, ou no; a documentao fornecida para utilizao de um produto, sendo tambm uma parte integrante do produto. Exemplos de documentao do usurio impressa: manual, complemento de manuais, atualizaes, guia de referncia rpida etc. Exemplos de documentao do usurio on-line: help (F1: sensvel ao contexto e on-line: Ajuda, contedo, etc.), mdia digital de demonstrao, site, etc.

Efetiva
Que se manifesta por um efeito real; positivo: negcio efetivo; promessa efetiva. Que merece confiana; seguro, firme: carter efetivo; prova efetiva.

Eficincia
Conjunto de atributos que evidenciam o relacionamento entre o nvel de desempenho do software e a quantidade de recursos usados, sob condies estabelecidas. Tem como subcaractersticas: Comportamento em Relao ao Tempo e Comportamento em Relao aos Recursos.

Embalagem
Meio fsico que acondiciona a mdia e documentos impressos. Exemplos de embalagem: caixa de papelo tipo cartolina, caixa com papelo resistente e com abas tipo encaixe, caixa plstica para CD, caixa com papelo com capa dura e com encaixe sobreposto, etc.

Entidade de Software 7

Por entidade de software, entende-se o conjunto completo, ou um item desse conjunto, de programas de computador, procedimentos, documentao associada e dados designados.

Engenharia de Software
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.

Erro
a diferena entre um valor (ou condio) computado, observado, ou medido e o valor (ou condio) verdadeiro, especificado ou teoricamente correto. Veja tambm Defeito e Falha.

Erro gramatical
Quando a construo de um texto (frase, pargrafo) no correta, no seguindo as regras da linguagem.

Erro ortogrfico
Quando as palavras no so escritas corretamente.

Falha
a incapacidade de um sistema ou componente realizar suas funes requeridas, dentro de requisitos especificados de desempenho. Veja tambm Defeito e Erro.

Feedback
Respostas do sistema s aes do usurio.

Funo
A implementao de um algoritmo em um programa, com o qual o usurio ou o programa pode realizar toda uma tarefa ou parte dela.

Funcionalidade
Conjunto de atributos que evidenciam a existncia de um conjunto de funes e suas propriedades especificadas. As funes so as que satisfazem as necessidades explcitas ou implcitas. Tem como subcaractersticas: Adequao, Acurcia, Interoperabilidade, Conformidade e Segurana de Acesso.

Funes crticas
So aquelas cuja falha pode causar impactos considerveis em segurana, ou perdas financeiras ou sociais.

Grupo funcional 8

 um conjunto de funes para execuo de uma tarefa, geralmente apresentado num menu de funes ou barra de cones, separado de outros grupos funcionais por traos.

Grupo de programas
um conjunto de programas ou aplicativos agrupados num submenu ou numa janela; geralmente os programas pertencem a um mesmo produto de software. Veja tambm Item de programa.

Hardware
Equipamento fsico usado para processar, armazenar ou transmitir programas de computador ou dados.

Help
Recurso de ajuda para esclarecer alguma funo, tpico etc.

Highlight
Tcnica de realce, para enfatizar uma informao importante ou torn-la notvel.

Hipertexto
Conjunto de pginas de informao interligadas ativamente, de forma a possibilitar consultas imediatas em ordem ditada pelo leitor. Qualquer texto que contenha links para outros textos ou outros documentos; o sistema que interconecta documentos, de forma que o usurio possa passar de um para outro rpida e facilmente (geralmente com um clique de mouse); gravao de informaes em uma base de dados, de forma a possibilitar o cruzamento e associaes com informaes de outras bases; conforme se lem as informaes em um documento, possvel, com um clique em uma palavra (ou um boto, ou outro elemento grfico), exibir outras informaes relacionadas com aquela palavra (ou com aqueles outros elementos).

cone
Corresponde a um smbolo, portanto representao concreta, cuja expresso uma imagem grfica. Imagem pictogrfica associada a um comando, a uma operao ou a um arquivo.

IEC
Fundada em 1906, a IEC International Electrotechnical Commission uma organizao global que prepara e publica normas internacionais relacionadas com todas as tecnologias eltricas, eletrnicas e afins. A IEC, sediada em Gnova, na Sua, foi fundada como resultado de uma resoluo do International Electrical Congress, que ocorreu em 1904, na cidade de St. Louis, EUA. So mais de 60 pases-membros, incluindo todas as grandes naes do mundo e um crescente nmero de pases industrializados.

IEEE 9

O IEEE Institute of Electrical and Electronics Engineers , sediado em NJ/EUA, nasceu em 1963 como fruto da fuso do AIEE American Institute of Electrical Engineers e do IRE Institute of Radio Engineers, que datam de 1884. O IEEE auxilia na prosperidade global, promovendo a engenharia do processo de criao, desenvolvimento, integrao, compartilhamento e aplicao de conhecimento sobre tecnologia eltrica, da informao e cincias, para o benefcio da humanidade.

ISO
A ISO International Organization for Standardization uma federao internacional de organismos nacionais de padronizao, composta por aproximadamente 140 pases, sendo 1 organismo de cada pas. A ISO um organismo no governamental, estabelecido em 1947 e sediado em Gnova, na Sua. Sua misso promover o desenvolvimento de padres e atividades afins ao redor do mundo, com a viso de facilitar a troca de experincias e o desenvolvimento corporativo de atividades na esfera intelectual, cientfica, tecnolgica e econmica. Os resultados do trabalho da ISO so consensos internacionais publicados como Normas Internacionais .

Ilustrao
Imagem ou figura de qualquer natureza com que se orna ou elucida o texto de livros, folhetos e peridicos. Figura que complementa uma informao textual.

Implantar
Introduzir, inaugurar, estabelecer, inserir.

Implementar
Executar um plano, programa ou projeto.

ndice geral
Enumerao das principais divises (captulo, sees, artigos etc.) de um documento, na mesma ordem em que a matria nele se sucede; visa a facilitar viso do conjunto da obra e a localizao de suas partes para tanto, deve aparecer no incio da publicao e indicar, para cada parte, a paginao (conforme Normas Brasileiras); ndice de matria, tbua da matria. O ndice geral tambm chamado de ndice, sumrio, contedo etc.

ndice remissivo
ndice alfabtico dos diversos assuntos tratados numa obra, com a respectiva indicao de pgina, captulo etc.; ndice de assuntos.

Inmetro
Instituto Nacional de Metrologia, Normalizao e Qualidade Industrial - Inmetro

Inteligibilidade 10

Atributos do software que evidenciam o esforo do usurio para reconhecer o conceito lgico e sua aplicabilidade. uma subcaracterstica de Usabilidade.

Interface
Meio, ambiente. Conexo, ligao. O meio pelo qual o usurio se relaciona com o computador. Circuito ou ligao que compatibiliza sinais entre itens de hardware e permite interconexo entre eles. O ponto, ou o meio, de interao ou comunicao entre um computador e qualquer outra entidade, como um operador, uma impressora etc.

Interface com o usurio

Uma interface que permite que as informaes sejam passadas entre um usurio e componentes de hardware ou de software de um sistema computacional.

Interface grfica
Interface computador/usurio, que utiliza janelas, cones e outras representaes grficas, manipuladas inclusive por meio de um mouse ou dispositivo similar; tipicamente o programa Windows da Microsoft.

Interoperabilidade
Atributos do software que evidenciam sua capacidade de interagir com sistemas especificados. uma subcaracterstica de Funcionalidade.

Item (de atributo)

Proposio lgica sobre um atributo, a ser verificada em uma avaliao. Cada proposio que compe um atributo dever ser o mais objetiva possvel, envolvendo apenas um aspecto do atributo.

Item de programa
um programa ou aplicativo que faz parte de um grupo de programas ou aplicativos. Veja tambm Grupo de programa.

Janela
rea controlvel independentemente na tela, utilizada para apresentar objetos e/ou conduzir um dilogo com o usurio. Veja tambm Tela

Label
Breve rtulo descritivo para um campo de entrada ou leitura de dados, tabela ou boto de controle, dispositivo de mdia, etc.

Leiaute 11

Define a aparncia da pgina do documento a imprimir, estabelecendo margens, tamanho, linhas de grade, cabealho, etc.

Linhas de comando
Um tipo de interface entre o sistema operacional e o usurio, no qual este digita comandos, usando uma linguagem especial de comandos. Os sistemas com esse tipo de interface so geralmente considerados mais difceis para aprendizado e uso do que os com interfaces grficas (como o Windows e Macintosh). Veja tambm Interface Grfica.

Link
Ponto de ligao entre partes diferentes de um hipertexto ou entre diferentes hipertextos. Veja tambm Hipertexto.

Logomarca / Logotipo
Marca que rene graficamente letras do nome da empresa e elementos formais puros, abstratos. Qualquer representao grfica padronizada e distintiva utilizada como marca; representao visual de uma marca.

MCT
Ministrio da Cincia e Tecnologia

MEDE-PROS
MEDE-PROS Mtodo de Avaliao de Qualidade de Produtos de Software, verso 1.0. Patente junto Fundao Biblioteca Nacional, sob nmero de registro 135.620, livro 216, folha 84. Pedido de registro de marca junto ao INPI, sob nmero 820166243. Rio de Janeiro, Brasil Verso atual 2006. Propriedade do CTI.

MPS
Modelo MPS Melhoria de Processo de Software.

MPS.BR
Programa MPS.BR Melhoria de Processo do Software Brasileiro.

NBR
Norma tcnica elaborada pela ABNT, em conformidade com os procedimentos fixados para o Sistema Nacional de Metrologia, Normalizao e Qualidade Industrial, pela lei 5.966, de 16 de dezembro de 1973.

Qualidade 12

Totalidade das caractersticas de uma entidade, que lhe confere a capacidade de satisfazer s necessidades explcitas e implcitas.

Qualidade de software
Totalidade das caractersticas de software, que lhe confere a capacidade de satisfazer s necessidades explcitas e implcitas.

Linhas de comando
Um tipo de interface entre o sistema operacional e o usurio, no qual este digita comandos, usando uma linguagem especial de comandos. Os sistemas com esse tipo de interface so geralmente considerados mais difceis para aprendizado e uso do que os com interfaces grficas (como o Windows e Macintosh). Veja tambm Interface Grfica.

Link
Ponto de ligao entre partes diferentes de um hipertexto ou entre diferentes hipertextos. Veja tambm Hipertexto.

Manuteno (de sistema)

Alterao de um sistema para corrigir defeitos, para melhorar o desempenho, ou para adaptar o sistema s mudanas de ambiente ou de requisito.

Manutenibilidade
Conjunto de atributos que evidenciam o esforo necessrio para fazer modificaes no software.

Maturidade
Atributos do software que evidenciam a frequncia de falhas por defeitos no software. uma subcaracterstica de Confiabilidade.

Memria
Dispositivo no qual informaes podem ser introduzidas, conservadas e do qual podem ser posteriormente recuperadas; armazenador; dispositivo de armazenamento.

Memria RAM
Do ingls: R(andom) A(ccess) M(emory). Memria principal a que o usurio do equipamento tem acesso para gravao ou leitura de dados e programas; memria de leitura e gravao. uma memria do tipo voltil, em que, ao ser desligado o computador, as informaes armazenadas so perdidas.

Menu 13

Conjunto de opes selecionveis, apresentadas ao usurio pelo computador. As opes podem ser apresentadas ao usurio por meio de dispositivos visuais (textual ou simbolicamente) ou verbais. Veja tambm Menu Drop-down.

Mdia
Diz respeito ao veculo de distribuio de arquivos ou programas: mdia magntica (mdia digital, disco rgido), mdia ptica (CD-ROM) etc.

Modelo de Maturidade
Um modelo que fornece uma abordagem disciplinada, para identificao dos processos crticos e definio de aes de melhoria, alinhadas com os objetivos estratgicos do negcio e consistentes com o estgio de maturidade dos processos de uma empresa.

Multimdia
Tecnologia que permite ao computador trabalhar com diversas mdias, como som, imagem, esttica, animao e vdeo.

Necessidades explcitas
Requisitos, condies e objetivos propostos formalmente pelo consumidor, para um produto ou servio.

Necessidades implcitas
Requisitos, condies e objetivos assumidos pelo consumidor como inerentes ao produto ou servio; nem sempre propostos formalmente.

Norma
Aquilo que se estabelece como base ou medida para a realizao ou a avaliao de alguma coisa. Princpio, preceito, regra, lei. Modelo, padro.

Norma tcnica
Documento tcnico que fixa padres reguladores, visando garantir a qualidade do produto industrial, a racionalizao da produo, transporte e consumo de bens, a segurana das pessoas, a uniformidade dos meios de expresso e comunicao etc.

Normalizao
Atividade que estabelece prescries, relativas a problemas existentes ou potenciais, destinadas utilizao comum e repetitiva, com vistas obteno do grau timo de ordem em um dado contexto.

Objeto (de interao) / Objeto (de interface) 14

Entidades de software bsicas de comunicao utilizadas na interao homem - mquina. Ex.: janelas, caixa de dilogo, menus, botes, cones, etc.

Operacionalidade
Atributos do software que evidenciam o esforo do usurio para sua operao e controle da sua operao. uma subcaracterstica de Usabilidade.

Opo
As opes podem ser classificadas como opo de comando: aciona um comando da aplicao; opo de dilogo: aciona a apresentao de uma caixa de dilogo para a entrada de parmetros de um comando;

Opo de menu: permite ao usurio selecionar opo de comando; opo de submenu: faz a apresentao de outro menu, permitindo ao usurio afinar a sua escolha em termos de opes de comando. Organizao
Uma unidade de uma empresa ou qualquer outra entidade que tenha projetos a serem gerenciados. Uma caracterstica que delimita uma entidade como sendo uma organizao o fato de todos os projetos compartilharem das mesmas polticas e da mesma alta gerncia.

Organizao de software
Toda e qualquer empresa que tenha desenvolvimento e manuteno de software como uma de suas atividades, no sendo, necessariamente, sua atividade-fim.

Pacote de software
Conjunto completo e documentado de programas fornecidos para vrios usurios, para uma aplicao ou funo genrica.

Parmetro
Uma varivel que passada para um programa ou rotina (parte de um programa).

Patrocinador
Empresa, instituio que apresente proposta para uma avaliao de produto. A pessoa que deseja ter o produto avaliado.

Perifrico
Qualquer equipamento conectado ao computador, que fornece entrada, sada ou armazenamento, como o teclado, monitor, impressora, scanner, mouse, drives de disco etc.

Portabilidade 15

Conjunto de atributos que evidenciam a capacidade do software de ser transferido de um ambiente para outro. Tem como subcaractersticas: Adaptabilidade, Capacidade para ser Instalado, Conformidade e Capacidade para Substituir.

Processo de Software
Conjunto de atividades, mtodos, prticas e transformaes que as pessoas usam para desenvolver e manter software e seus produtos associados.

Produto de Software
Conjunto completo de programas de computador, procedimentos, documentao e dados possivelmente associados, designado para liberao a um usurio.

Proposio
Ato ou efeito de propor. Aquilo que se prope; proposta. Expresso verbal de um juzo; assero, asseverao. Mxima, sentena. Filos. Enunciado verbal suscetvel de ser dito verdadeiro ou falso. Enunciado algortmico, equivalente a um enunciado verbal suscetvel de ser dito verdadeiro ou falso. Assunto que vai ser discutido ou assero que vai ser defendida.

Recuperabilidade
Atributos do software que evidenciam sua capacidade de restabelecer seu nvel de desempenho e recuperar os dados diretamente afetados, em caso de falha, e o tempo e esforo necessrios para tal. uma subcaracterstica de Confiabilidade.

Recurso de rolagem
Controle que permite ao usurio visualizar objetos que extrapolam o tamanho da rea disponvel para visualizao. A rolagem pode ser horizontal ou vertical.

Restaurao
Rotina utilizada para recuperao de arquivos danificados ou perdidos. A restaurao s possvel a partir do backup.

Segurana de acesso
Atributos do software que evidenciam sua capacidade de evitar o acesso no autorizado, acidental ou deliberado a programas e dados. uma subcaracterstica de Funcionalidade.

SEI
O SEI Software Engineering Institute um centro de pesquisas e desenvolvimento federal, fundado pelo Departamento de Defesa dos EUA, por meio do OUSD(AT&L) Office of the Under ecretary of efense for Acquisition, ec nolo y, and Lo istics O propsito do SEI, em poucas palavras, aprimorar a prtica da Engenharia de Software.

16

SEPIN
Secretaria de Poltica de Informtica do Ministrio da Cincia e Tecnologia (MCT)

Smbolo
Elemento grfico ou objeto que representa e/ou indica de forma convencional um elemento importante para o esclarecimento ou realizao de alguma coisa. Ex.: smbolo matemtico, smbolo de perigo.

Sistema
Uma coleo de componentes organizados para realizar uma funo especfica ou um conjunto de funes.

Sistema Operacional
Programa que controla toda a operao de processamento num computador, facilitando a outros programas o uso do hardware e permitindo algum controle bsico do usurio sobre o sistema por meio do teclado e de outros dispositivos de entrada manual de dados. Os sistemas operacionais mais usados em microcomputadores so o MS-DOS, o OS/2, o Windows 98, o Unix, o Linux, o Windows NT e o MacOS.

Software
Instrues (programas de computador) que, quando executadas, produzem a funo e o desempenho desejados.

SOFTEX
Associao para Promoo da Excelncia do Software Brasileiro

Suporte Tcnico
Servio de atendimento que fabricantes (de equipamentos ou software), ou respectivos revendedores ou representantes, disponibilizam aos consumidores por diversos meios (correio, correio eletrnico, telefone, visitas domiciliares etc.).

Tarefa
Resultado esperado num contexto de trabalho. Uma srie de transaes que compreende parte ou o todo de uma atividade do usurio.

Tecla de atalho / Tecla aceleradora

Tecla modificadora (Control, Alt), ou combinaes de teclas (por exemplo Control+C) que executa uma funo imediatamente, sem a necessidade de operaes intermedirias. Excluem-se dessa definio as teclas de funo (F1, F2, F3, ...).

Tecla de funo 17

Tecla cuja ativao afeta a entrada de controle. Por exemplo: F1, F2, F3,...

Tela
A tela do monitor. Superfcie de exibio de um vdeo. A imagem ou a informao exibida em um dado momento em um monitor, terminal de vdeo ou outro tipo de display.

TQM
Sigla utilizada para Total Quality Management ou, em portugus, Gerenciamento da Qualidade Total.

Tolerncia a falha
Atributos do software que evidenciam sua capacidade em manter um nvel de desempenho especificado nos casos de falhas no software ou de violao nas interfaces especificadas. uma subcaracterstica de Confiabilidade. Ver tambm Falha e Defeito.

Upgrade
Subir um grau; expanso, melhoria. Com relao a software, atualizar para nova verso, mais poderosa ou aperfeioada. Atualizar um sistema com novos equipamentos.

Usabilidade
Conjunto de atributos que evidenciam o esforo necessrio para poder utilizar o software, bem como o julgamento individual desse uso, por um conjunto explcito ou implcito de usurios. Tem como subcaractersticas: Inteligibilidade, Apreensibilidade e Operacionalidade.

Verso (de Software)

Uma determinada edio de um produto. Quando um software atualizado, nele so incorporados novos recursos ou feitas modificaes; d-se nova edio a denominao de verso, seguida de um nmero, seqencial ou no, que passa a identific-la (Por exemplo: Windows NT ou Windows Server 2008).

18

REFERNCIAS BIBLIOGRFICAS ABNT. Associao Brasileira de Normas Tcnicas. Disponvel em: <http://www.abnt.org.br>. AL-KILIDAR, H.; COX, K.; KITCHENHAM, B.; The use and usefulness of the ISO/IEC 9126 quality standard, In: Empirical Software Engineering, 2005 International Symposium on 17-18 Nov. 2005 Page(s): 7 pp. ANSI/IEEE Std 1063-1987. Standard for Software User Documentation. New York : IEEE Computer Society, 1987. APOLLO. Apollo Marks Inventory. Disponvel Trademarks: Definitions. <http://www.apollogrp.com/trademarks/definitions.htm>. Acesso em 05 fevereiro 2008. ASSESPRO. <http://www.assespro.org.br> acesso em 22 novembro 2008. BACHE, R.; BAZZANA, G. Software Metrics for Product Assessment, In: Software Quality Assurance Series, McGraw-Hill Book Co., 1994 p. 105-111. BOEHM, B. W., Brown, J. R., Kaspar, H., Lipow, M., McLeod, G., and Merritt, M ., Characteristics of Software Quality, North Holland, 1978. BERTOA, M. e Vallecillo, A. Atributos de Calidad para Componentes COTS. Anais do 5Workshop Iberoamericano de Engenharia de Requisitos e Ambientes de Software. 2002. BERTOA, M. e Vallecillo, A, Quality Attributes for COTS Components, ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QUAOOSE'2002), Mlaga, Espanha, 2002. CAPOVILLA, I. G. G. Elementos Intrnsecos do Software e sua Influncia na Qualidade do Processo de Desenvolvimento. 1999. 108 f. Dissertao (Mestrado em Qualidade) IMECC - Instituto de Matemtica, Estatstica e Computao Cientfica, UNICAMP - Universidade Estadual de Campinas, Campinas. 1989. Centro de Tecnologia da Informao Renato Archer CTI/MCT. Disponvel em: <http://www.cti.gov.br>. Acesso em 10 setembro 2008. CERTSOFT06 Stefania Gnesi, Tom Maibaum, Alan Wassyng, An International Workshop on Software Certification, McMaster University August 26 - 27, 2006. CHRISSIS, M. B. CMMI: guidelines for process integration and product improvement . AddisonWesley Publishing Company 2003. CMM. CARNEGIE MELLON UNIVERSITY. SEI - Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. 14. ed. EUA: Addison Wesley Longman, 2000. 441 pp. CMMI. Capability Maturity Model Integration (CMMISM), Version 1.1 CMMISM for Software Engineering (CMMI-SW, V1.1) Continuous Representation, 2002. COLOMBO, R. M. T. Processo de Avaliao da Qualidade de Pacotes de Software . 2004. 169pp.. Dissertao (Mestrado em Qualidade) - Faculdade de Engenharia Mecnica, UNICAMP Universidade Estadual de Campinas, Campinas, SP. 2004. em:

19

CROSBY, P. B. Quality Is Free. 1. ed. USA: McGraw-Hill, 1979. 309 pp. DROMEY, R. G., Concerning the Chimera [software quality], IEEE Software, no. 1, pp. 33-43, 1996. ERGOLIST <http://www.labiutil.inf.ufsc.br/ergolist/projeto.htm> ; < http://www.labiutil.inf.ufsc.br/ergolist/>; Acesso em 28 abril 2009. GUERRA, A. C.; COLOMBO, R. T.; AGUAYO, M. T. V.; PERES R. D.. Modelo de Qualidade de Componentes de software. In: Conferncia Ibero - Americana, 2007, Vila Real, Portugal. Conferncia IADIS Ibero-Americana WWW/Internet 2007, 2007. IEC. International Electrotechnical Commission. Disponvel em: <http://www.iec.ch>. Acesso em 04 novembro 2007. IEEE. Institute of Electrical and Electronics, Inc. Disponvel em: <www.ieee.org>. Acesso em 04 novembro 2007. IEEE 1062 - IEEE COMPUTER SOCIETY. IEEE - Software Engineering Standards Colletion. IEEE STD 1062 - IEEE Recommended Practice for Software Acquisition. New York, NY. 1998. 43pp. ISO. International Organization for Standardization. Disponvel em: <http://www.iso.ch>. Acesso em 04 novembro 2007. ISO/IEC 9126-1. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product quality Part 1: Quality model. Genebra, 2001. 25 pp. ISO/IEC TR 9126-2. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product quality Part 2: External metrics. Genebra, 2003. ISO/IEC TR 9126-3. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product quality Part 3: Internal metrics. Genebra, 2003. ISO/IEC TR 9126-4. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product quality Part 4: Quality in use metrics. Genebra, 2004. ISO 9127. Information processing systems -- User documentation and cover information for consumer software packages, Genebra, 1988. ISO 9241-1. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Ergonomic requirements for office work with visual display terminals (VDTs) -- Part 1: General introduction, 1997. ISO 9241-10. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Ergonomic requirements for office work with visual display terminals (VDTs) - Part 10: Dialogue principles. Geneve : ISO, 1996. ISO 9241-11. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability. Geneve: ISO, 1998. ISO 9241-12. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Ergonomic requirements for office work with visual display terminals (VDTs) - Part 12: Presentation of information. Geneve : ISO, 1998.

20

ISO/IEC 25000. Software Engineering -- Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE, 2005. ISO/IEC 12207. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Systems and software engineering Software life cycle processes. Genebra: ISO, 2008. ISO/IEC 14598-1. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product evaluation Part 1: General overview. Genebra, 1999. 20 pp. ISO/IEC 14598-2. NTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product evaluation Part 2: Planning and management. Genebra, 2000. 20 pp. ISO/IEC 14598-3. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product evaluation Part 3: Process for developers. Genebra, 2000. 16 pp. ISO/IEC 14598-4. NTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product evaluation Part 4: Process for acquirers. Genebra, 1999. 43 pp. ISO/IEC 14598-5. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product evaluation Part 5: Process for evaluators. Genebra, 1998. 50 pp. ISO/IEC 14598-6. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software product evaluation Part 6: Documentation of evaluation modules. Genebra, 2001. 42 pp. ISO/IEC 15504-2. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software process assessment Part 2: A reference model for processes and process capability. Genebra,2003. 39 pp. ISO/IEC 15504-5. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Information technology Software process assessment Part 5: An assessment model and indicator guidance . Genebra, 2006. 123 pp. ISO/IEC 15939:2007. Systems and software engineering - Measurement process. Genebra. 2007.. JURAN, J. M., Juran's Quality Control Handbook, McGraw-Hill, 1988. MAITINGUER, S. T. Um mtodo de avaliao especialista para produtos de software, desenvolvido a partir dos requisitos de um edital. Campinas, SP, 2004. 145pp. Trabalho Final de Mestrado Profissional, Universidade Estadual de Campinas, Faculdade de Engenharia Mecnica. 2004. MAGNANI, G. Melhoria de Processo: Viso Geral e Estudos de Caso . Tutorial oferecido na Semana de Engenharia de Software, 3, 12 agosto 1998, So Paulo. MCCALL, J. A., RICHARDS, P. K., and WALTERS, G. F., Factors in Software Quality, Nat'l Tech.Information Service, no. Vol. 1, 2 and 3, 1977. MCT. Ministrio da Cincia e Tecnologia. Secretaria de Poltica de Informtica e Automao. Qualidade e Produtividade no Setor de Software Brasileiro . Disponvel em: <http://www.mct.gov.br/sepin/ >. Acesso em: 2009.

21

MEDE-PROS . Centro de Tecnologia da Informao Renato Archer CTI/MCT. LAPS - Laboratrio de Tecnologia de Avaliao de Qualidade de Produto de Software. LAQS Laboratrio de Avaliao de Qualidade de Software. MEDE-PROS - Mtodo de Avaliao da Qualidade de Produto de Software. verso 1.0. Campinas, 1996. MARTINEZ, M. R. M., et al, The Software Product Evaluation Data Base Supporting MEDE-PROS . In: ISESS - International Software Engineering Standards Symposium Best Software Practices for the Internet age, 4, 1999, Curitiba. Anais da 4 ISESS. Curitiba:Grfica, maio 1999. NBR ISO 9000. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO 9000 - Sistemas de gesto da qualidade - Fundamentos e vocabulrio Rio de Janeiro: ABNT, dezembro 2005, 35 pp. NBR ISO/IEC 12119. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO/IEC 12119: Tecnologia de informao - Pacotes de software - Testes e requisitos de qualidade. Rio de Janeiro: ABNT, outubro 1998. 13 pp. (verso cancelada pela NBR ISO/IEC 25051, 2009). NBR ISO/IEC 12207. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO/IEC 12207, Tecnologia de Informao Processos de ciclo de vida de software; Rio de Janeiro ABNT out / 1998. 35 pp. NBR ISO/IEC 14598-1. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO/IEC 14598-1 Tecnologia de Informao Avaliao de produto de Software Parte 1: Viso geral. Rio de Janeiro ABNT, 2002. 28 pp. NBR ISO/IEC 14598-2. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO/IEC 14598-2 Tecnologia de Informao Avaliao de produto de Software Parte 2: Planejamento e gesto. Rio de Janeiro ABNT, 2003. NBR ISO/IEC 14598-3. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO/IEC 14598-5 Tecnologia de Informao Avaliao de produto de Software Parte 3: Processo para desenvolvedores. Rio de Janeiro ABNT, 2002. NBR ISO/IEC 14598-4. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO/IEC 14598-5 Tecnologia de Informao Avaliao de produto de Software Parte 4: Processo para . Rio de Janeiro ABNT, 2003. adquirentes NBR ISO/IEC 14598-5. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO/IEC 14598-5 Tecnologia de Informao Avaliao de produto de Software Parte 5: Processo para avaliadores. Rio de Janeiro ABNT, 2002. NBR ISO/IEC 14598-6. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS NBR ISO/IEC 14598-5 Tecnologia de Informao Avaliao de produto de Software Parte 6: Documentao de mdulos de avaliao. Rio de Janeiro ABNT, 2004. NBR ISO/IEC 15504-1. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Tecnologia da informao - Avaliao de processo - Parte 1:- Conceitos e vocabulrio . Rio de Janeiro ABNT, 2008. NBR ISO/IEC 15504-2. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Tecnologia da informao - Avaliao de processo - Parte 2: - Realizao de uma avaliao. Rio de Janeiro ABNT, 2008.

22

NBR ISO/IEC 15504-3. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Tecnologia da informao - Avaliao de processo - Parte 3:- Orientaes para realizao de uma avaliao. Rio de Janeiro ABNT, 2008. NBR ISO/IEC 15504-4. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Tecnologia da informao - Avaliao de processo - Parte 4:- Orientao no uso para melhoria do processo e determinao da potencialidade do processo. Rio de Janeiro ABNT, 2008. NBR ISO/IEC 15504-5. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Tecnologia da informao - Avaliao de processo - Parte 5: - Um exemplo de um modelo de avaliao . Rio de Janeiro ABNT, 2008. NBR ISO/IEC 25000. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Engenharia de software Requisitos e avaliao da qualidade de produtos de software (SQuaRE) - Guia do SQuaRE Rio de Janeiro ABNT, 2008. NBR ISO/IEC 25051. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Engenharia de software Requisitos e avaliao da qualidade de produto de software (SQuaRE) - Requisitos de qualidade de produto de software comercial de prateleira (COTS) e instrues para teste Rio de Janeiro ABNT, 2008. NBR ISO/IEC 25030. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS Engenharia de software Requisitos e Avaliao da Qualidade de Produto de Software (SQuaRE) - Requisitos de qualidade Rio de Janeiro ABNT, 2008. NBR ISO/IEC 9126-1. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. Tecnologia da informao Qualidade de Produto de Software Parte 1:Modelo de Qualidade. Rio de Janeiro, 2003. NIELSEN, J. Usability Engineering 1993, Academic Press Limited, United Kingdom, 362 pp. PAULK, M. C.; et al. The Capability Maturity Model for Software. Pittsburgh: SEI - Software Engineering Institute, 1999. 26 pp. PRESSMAN, R. S. Engenharia de Software. Traduo: Jos Carlos Barbosa dos Santos. Reviso tcnica: Maldonado J. C.; Masiero P. C.; Sanches R. 5 Edio, So Paulo: McGraw-Hill, 2002. 837pp. PIVKA, M. Software Product Certification an alternative approach for a small software house Proceedings of the 3rd Software Quality Management Seville, April 1995. ROCHA, A. R. C.; MALDONADO, J.C.; WEBER, K.C. Qualidade de Software So Paulo: Prentice Hall, 2001. 303 pp. Teoria e Prtica. 1. ed.

SAMETINGER, J., Software Engineering with Reusable Components, New York: Springer. 1997. 271pp. A A A, M. L.; GUERRA A. C. - Quality of Software Process or Quality of Software Product? In: 12th International Conference for Software Quality, Ottawa-Ca, 11/2002.

SCOPE. Software CertificatiOn Programme in Europe - Disponvel em: <http://www.ukoln.ac.uk/services/elib/projects/scope/> <http://www.cse.dcu.ie/essiscope/sm2/atwork/scope.html>. Acesso em abril 2009.

23

SEI. Software Engineering Institute.- Disponvel em: <http://www.sei.cmu.edu>. Acesso em novembro 2008. SOFTEX. Guia Geral do MPS.BR Melhoria de Processo de Software Brasileiro (verso 1.2) ltimo acesso em novembro 2008. http://www.softex.br/portal/mpsbr/_guias/default.asp. SOFTEX. Associao para Promoo da Excelncia do Software Brasileiro. Disponvel em: <http://www.softex.br>. Acesso em fevereiro 2009. SQUAD. Software Quality Across Different Regions - Disponvel em: <http://members.iif.hu/birom/neumann/rendezvenyek/event0106/NJSZT_SQUAD_eng.htm> ; <http://cordis.europa.eu/inco/fp4/projects/ACTIONeqDndSESSIONeq9845200595ndDOCeq10ndTBLe qEN_PROJ.htm>. Acesso em abril 2009. UHCL. University of Houston Clear Lake. Disponvel The Trillium Model. <http://www2.umassd.edu/swpi/BellCanada/trillium-html/trillium.html>. Acesso em outubro 2007. em:

VILLELA, R. M. R., 2000. Busca e Recuperao de Componentes em Ambientes de Reutilizao de Software, Tese de Doutorado, UFRJ-COPPE, Rio de Janeiro, Brasil. WEBER, K. C.; ROCHA, A. R. C.; NASCIMENTO, C. J. Qualidade e Produtividade em Software. 4. ed. Renovada. So Paulo: Makron Books, 2001. 188 pp.

24