Um estudo de caso sobre a aplicação da norma NBR 12119:avaliação de pacotes de software

(1)

ii

ANDRÉ LUIS CURY CARAZZA

UM ESTUDO DE CASO SOBRE A APLICAÇÃO DA

NORMA NBR 12119 – AVALIAÇÃO DE PACOTES DE

SOFTWARE

Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília, como requisito parcial para obtenção do Título de Mestre em Gestão do Conhecimento e da Tecnologia da Informação.

Orientador: Prof. Dr. Walcélio L. Melo

(2)

iii

Dissertação defendida em 12 de abril de 2004 e aprovada, pela banca examinadora constituída pelos professores:

______________________________________________ Prof. Dr. Walcélio L. Melo – Orientador

______________________________________________ Prof. Dr. Javam de Castro Machado – Banca

(3)

iv

(4)

v A Deus,

Que com a sua misericórdia e enorme bondade, permitiu a conclusão de um sonho.

A minha esposa,

Por todo o amor, compreensão e carinho entregues por ela, em vários momentos difíceis na trajetória desta dissertação.

Aos meus filhos,

Que souberam me agüentar, com todo o carinho do mundo, quando estava mais estressado.

Aos meus pais e minha sogra,

Não mais presentes aqui na terra comigo, mas que me orientaram na busca deste título.

Ao meu sogro,

Que tanto me ajudou.

Aos meus amigos Andrea Kabu e Varely Fernandes, Que me ajudaram na construção desta dissertação. Ao meu irmão Sérgio,

Pela revisão técnica desta dissertação. À Professora Sheila

Pela revisão desta dissertação. Ao Professor Walcélio,

Que conseguiu, num prazo exíguo, orientar-me na busca de novos conhecimentos, permitindo a conclusão desta dissertação.

Ao Professor Gentil Lucena,

(5)

vi

(6)

RESUMO

A Garantia da Qualidade de Software é um dos desafios que as empresas de tecnologia da informação enfrentam no mercado. Essa Garantia de Qualidade, em sentido amplo, envolve a avaliação de métodos, processos, pacotes de software e ferramentas usadas no processo de desenvolvimento do ciclo de vida de um software. No intuito de organizar as questões relacionadas à qualidade desses pacotes, a ABNT publicou a norma NBR ISO/IEC 12119 [12119], que define seus requisitos de qualidade. De acordo com [PESQUI01] [PESQUI99], somente um pequeno número de empresas brasileiras usam adequadamente a norma NBR ISO/IEC 12119 na avaliação desses pacotes. Nesta dissertação, está proposta uma metodologia para avaliação de pacotes de software baseada na NBR. Para validá-la, é desenvolvida uma avaliação dos pacotes dos softwares Lotus Notes e MS-Exchange. Esta dissertação apresenta os resultados da avaliação mencionada.

(7)

ABSTRACT

The Software Quality Assurance is one of the challenges information technology corporations face in their business. Software Quality Assurance in a broad sense would include the evaluation of the software methods, processes, software packages, and tools used in software development life cycle. In order to address issues related to the quality of software packages, ABNT published the standard NBR ISO/IEC 12119 [12119], which addresses quality requirements of software packages. According to [PESQUI01] [PESQUI99], only a few Brazilian companies adequately use the NBR ISO/IEC 12119 for evaluating software packages. In this dissertation, a roadmap for software package evaluation based on the NBR is proposed. In order to validate this roadmap, an evaluation of Lotus Notes and MS-Exchange software packages is performed. This dissertation presents the results of this evaluation.

(8)

LISTA DE ABREVIATURAS

ABNT – Associação Brasileira de Normas Técnicas ISO – International Organization for Standardization MINE – Multiporpuse Internet Mail Extension

(9)

SUMÁRIO

RESUMO ... vii

ABSTRACT...viii

LISTA DE ABREVIATURAS... ix

LISTA DE FIGURAS ...12

LISTA DE TABELAS ...15

1. INTRODUÇÃO...17

1.1. Motivação...17

1.2. Objetivo e Metodologia ...20

1.3. Organização da Dissertação...21

2. QUALIDADE DE SOFTWARE ...23

2.1. Conceito de Qualidade...23

2.2. Conceito de Software...24

2.3. Conceito de Qualidade de Software...25

2.4. Métricas de Qualidade de Software ...27

2.5. Qualidade dos Produtos de Software...31

2.5.1. Modelo para Características Externas e Internas ...32

2.5.2. Modelo para Qualidade em Uso ...37

2.5.3. Norma NBR ISO/IEC 12119 ...38

2.6. Pacotes de Software Avaliados...42

2.6.1. Lotus Notes...42

2.6.2. MS-Exchange ...44

2.7. A Abordagem Goal/Question/Metric (GQM)...50

3. AVALIANDO A QUALIDADE DE PACOTES DE SOFTWARE ...54

3.1. Metodologia...54

3.2. Elaboração do Formulário de Avaliação ...57

3.3. Estabelecimento dos requisitos de qualidade ...83

3.4. Elaboração e estabelecimento dos requisitos de qualidade para o Formulário de Avaliação...85

(10)

4.1. Distribuição e captação do Formulário de Avaliação ...87

4.2. Avaliação e Análise de Resultados ...88

4.2.1. Análise Geral ...88

4.2.2. Análise do Lotus Notes ...107

4.2.3. Análise do MS-Exchange...125

5. CONCLUSÕES E PERSPECTIVAS FUTURAS ...144

6. BIBLIOGRAFIA ...148

ANEXO I – Formulário de Avaliação ...152

(11)

LISTA DE FIGURAS

Figura 1: Fatores de Qualidade de Software 28

Figura 2: Hierarquia GQM 52

Figura 3: Metodologia Proposta 57

Figura 4: Formulário de Avaliação com marcação dos requisitos de qualidade 84 Figura 5: Porcentagem de atendimento aos requisitos de qualidade - Descrição

do Produto 96

Figura 6: Porcentagem de atendimento aos requisitos de qualidade -

Documentação do Usuário 97

Figura 7: Porcentagem de atendimento aos requisitos de qualidade - Programas

e Dados 97

Figura 8: Porcentagem de atendimento aos requisitos de qualidade 99

Figura 9: Tempo de conhecimento dos técnicos 100

Figura 10: Natureza das Organizações 100

Figura 11: Porcentagem de atendimento aos requisitos de qualidade para o

Formulário de Avaliação 107

Figura 12: Porcentagem de atendimento aos requisitos de qualidade - Descrição

do Produto - para o Lotus Notes 114

Documentação do Usuário - para o Lotus Notes 115

Programas e Dados - para o Lotus Notes 115

Figura 15: Porcentagem de atendimento aos requisitos de qualidade para o

Lotus Notes 116

Figura 16: Tempo de conhecimento dos técnicos para o pacote Lotus Notes 117 Figura 17: Natureza das Organizações para o pacote Lotus Notes 118 Figura 18: Porcentagem de atendimento do pacote Lotus Notes aos requisitos

de qualidade para o Formulário de Avaliação 125

Figura 19: Porcentagem de atendimento aos requisitos de qualidade - Descrição

(12)

Documentação do Usuário - para o MS-Exchange 133

Programas e Dados - para o MS-Exchange 133

Figura 22: Porcentagem de atendimento aos requisitos de qualidade para o MS-Exchange 135 Figura 23: Tempo de conhecimento dos técnicos para o pacote MS-Exchange 136 Figura 24: Natureza das Organizações para o pacote MS-Exchange 136 Figura 25: Porcentagem de atendimento do pacote MS-Exchange aos requisitos

de qualidade para o Formulário de Avaliação 143

Figura 26: Porcentagem de atendimento aos requisitos de qualidade por pacote

de software 145

Figura 27: Porcentagem de atendimento aos requisitos de qualidade do

Formulário de Avaliação 146

Figura 28: Aplicativo – Modelo Entidade x Relacionamento 164

Figura 29: Aplicativo – Tela de Apresentação 164

Figura 30: Aplicativo – Acesso ao Cadastro 165

Figura 31: Aplicativo – Cadastro – Pacote 166

Figura 32: Aplicativo – Inclusão de Pacote 167

Figura 33: Aplicativo – Alteração e/ou Exclusão de Pacote 167 Figura 34: Aplicativo – Cadastro - Organizações 168 Figura 35: Aplicativo – Inclusão de Organização 169 Figura 36: Aplicativo – Alteração e/ou Exclusão de Organização 169 Figura 37: Aplicativo – Cadastro – Grupo de Respostas 170 Figura 38: Aplicativo – Inclusão de Grupo de Respostas 171 Figura 39: Aplicativo – Alteração e/ou Exclusão de Grupo de Respostas 171

Figura 40: Aplicativo – Cadastro – Respostas 172

Figura 41: Aplicativo – Inclusão de Respostas 173

Figura 42: Aplicativo – Alteração e/ou Exclusão de Respostas 173 Figura 43: Aplicativo – Cadastro – Seções da Norma 174

Figura 44: Aplicativo – Inclusão de Seções 175

(13)

Figura 46: Aplicativo – Cadastro – Itens da Norma 176

Figura 47: Aplicativo – Inclusão de Itens 177

Figura 48: Aplicativo – Alteração e/ou Exclusão de Respostas 177

Figura 49: Aplicativo – Cadastro – Questões 178

Figura 50: Aplicativo – Inclusão de Questões 179

Figura 51: Aplicativo – Inclusão de Requisitos de Qualidade 179 Figura 52: Aplicativo – Alteração e/ou Exclusão de Questões 180

Figura 53: Aplicativo – Cadastro – Avaliadores 181

Figura 54: Aplicativo – Inclusão de Avaliadores 182

Figura 55: Aplicativo – Inclusão de Avaliações 182

Figura 56: Aplicativo – Alteração e/ou Exclusão de Avaliadores 183

Figura 57: Aplicativo – Acesso a Mensuração 184

Figura 58: Aplicativo – Lista de Avaliações não concluídas, caso ocorram 184 Figura 59: Aplicativo – Formulário de Avaliação 185

Figura 60: Aplicativo – Consultas 186

Figura 61: Aplicativo – Análise - Total 187

Figura 62: Aplicativo – Análise – Porcentagem de Atendimento 188 Figura 63: Aplicativo – Análise – Item – Porcentagem de Atendimento 188

Figura 64: Aplicativo – Análise – Consolidação 189

Figura 65: Aplicativo – Análise – Requisitos de Qualidade 190 Figura 66: Aplicativo – Perfil – Tempo de Conhecimento 191 Figura 67: Aplicativo – Perfil – Natureza das Organizações 192

Figura 68: Aplicativo – Parceiros - Total 193

Figura 69: Aplicativo – Parceiros - Porcentagem 193 Figura 70: Aplicativo – Formulário – Porcentagem de Atendimento 194

(14)

LISTA DE TABELAS

Tabela 1: Relação de características, subcaracterísticas e perguntas típicas 35 Tabela 2: Relação entre as questões do Formulário de Avaliação com os Itens

da Norma 82

Tabela 3: Porcentagem de atendimento dos requisitos de qualidade por questão

do Formulário 92

Tabela 4: Grau de atendimento aos requisitos de qualidade por item da norma 95 Tabela 5: Grau de atendimento aos requisitos de qualidade por seção da norma 98 Tabela 6: Porcentagem de atendimento dos requisitos de qualidade por questão do Formulário de Avaliação, considerando somente os técnicos que trabalham

nas empresas parceiras dos pacotes 104

Tabela 7: Porcentagem de atendimento dos requisitos de qualidade por questão do Formulário de Avaliação para o pacote Lotus Notes 111 Tabela 8: Grau de atendimento aos requisitos de qualidade por item da norma

para o pacote Lotus Notes 113

Tabela 9: Grau de atendimento aos requisitos de qualidade por seção da norma

para o pacote Lotus Notes 116

Tabela 10: Porcentagem de atendimento dos requisitos de qualidade por questão do Formulário de Avaliação, considerando somente os técnicos que trabalham nas empresas parceiras do Lotus Notes 121 Tabela 11: Porcentagem de atendimento dos requisitos de qualidade por questão do Formulário de Avaliação para o pacote MS-Exchange 129 Tabela 12: Grau de atendimento aos requisitos de qualidade por seção da

norma para o pacote MS-Exchange 132

Tabela 13: Grau de atendimento aos requisitos de qualidade por item da norma

para o pacote MS-Exchange 134

(15)

(16)

1. INTRODUÇÃO

Este capítulo apresenta a motivação, os objetivos e a metodologia utilizada e a estruturação de capítulos desta dissertação, considerando o contexto em que esta se encontra e o estado da arte sobre o tema abordado.

1.1. Motivação

Muito se tem discutido sobre Qualidade de Software, ou ainda, Métricas de Qualidade de Software. Entretanto, na prática, a maioria das empresas que utilizam software para gestão de seus negócios não possui estrutura sistêmica definida de forma clara, precisa e de fácil aplicação, que permita estabelecer parâmetros de exigência em termos de requisitos de qualidade.

Para se ter uma idéia da necessidade da adoção dos conceitos de Qualidade de Software nas empresas brasileiras que desenvolvem software, comparam-se os indicadores das duas últimas pesquisas de Qualidade e Produtividade no Setor de Software Brasileiro [PESQUI99] [PESQUI01]. Ocorreu uma grande redução, de 63,8% para 34,2%, de empresas que conhecem a norma sobre Qualidade de Produtos de Software - ISO/IEC 9126. Em contrapartida, o indicador “conhecimento e utilização” subiu de 3,4% para 3,9%.

(17)

Numa análise superficial, estes indicadores apresentam-se negativamente em relação aos conceitos mais gerais de Qualidade de Software. Mas, na realidade, eles demonstram a necessidade latente de garantir a Qualidade de Software conforme normas e avaliações. Várias empresas não adotam avaliações constantes e periódicas, pois não possuem um ferramental que atenda a essas necessidades [OLSINA99a].

A Qualidade de Software é literalmente esquecida por várias empresas que perguntam, freqüentemente: porque gastamos tanto ao desenvolver e/ou manter um software? onde está a documentação do software, agora que precisamos realizar um processo de manutenção? será que estamos atendendo realmente às expectativas dos nossos clientes? Estas perguntas podem ser respondidas com a aplicação das técnicas e processos de Qualidade de Software.

Um dos principais objetivos da Qualidade de Software, entre outros, é construir e manter um software até o final de sua vida útil, gastando o mínimo possível e utilizando-se de todos os recursos disponíveis com eficácia e eficiência [REZEND99].

(18)

Avaliá-los proporcionará aos desenvolvedores, gestores e aos seus usuários finais a garantia que estes pacotes de software atendam as suas necessidades e estejam conformes com o que há de mais moderno na área da Gestão de Tecnologia da Informação. Portanto, avaliar estes pacotes de software de forma sistêmica e coesa, mensurando sua qualidade a partir de seus objetivos específicos, passou a ser uma necessidade no estado da arte da Gestão da Tecnologia da Informação.

Segundo a pesquisa Qualidade e Produtividade no Setor de Software Brasileiro [PESQUI01], cerca de 61% das empresas consultadas na pesquisa realizada em 2000, desenvolveram pacote de software, e 21% da distribuição da comercialização bruta anual proveniente de software referenciaram-se a pacotes de software.

Abordaremos os pacotes Lotus Notes - versão 5.08 e o MS-Exchange - versão 2000 - utilizados para desenvolvimento de software e verificaremos, por um processo de avaliação que inclui um formulário de avaliação e sua análise, se estes pacotes estão de acordo com os requisitos de qualidade definidos e utilizados pela norma NBR ISO/IEC 12119. Sabemos que muitos pacotes são fáceis de ser utilizados, com boa interface, realizando aquilo a que se propõem, mas sem documentação apropriada e padronizada.

(19)

A escolha do MS-Exchange se deve ao fato deste ser um pacote voltado para o desenvolvimento de formulários integrados ao servidor de correios. A exemplo do Lotus Notes, não foi encontrado nenhum documento na literatura consultada versando se o MS-Exchange está em conformidade com a norma NBR ISO/IEC 12119.

Este trabalho visa fornecer diversas informações que poderão contribuir para a melhora da qualidade dos pacotes de software nas organizações que utilizam estes pacotes e, prover informações aos fabricantes dos mesmos, permitindo-lhes uma análise crítica de seu produto.

1.2. Objetivo e Metodologia

O objetivo deste trabalho é buscar uma forma prática de aplicação e validação dos conceitos de Qualidade de Software em relação a pacotes de software, tanto para desenvolvedores de software como para seus clientes, por intermédio da aplicação da norma NBR ISO/IEC 12119.

A utilização da abordagem GQM – Goal Questions Metrics (item 2.7 – página 50) e das orientações apresentadas pela norma ISO/IEC 9126 proporcionou um conjunto de questões (Metrics) mensuráveis e de fácil aplicação, específicas para a construção, utilização e validação do Formulário de Avaliação aplicado.

Após a confecção das questões, ocorreu a definição dos requisitos de qualidade segundo a norma NBR ISO/IEC 12119.

(20)

avaliação e, conseqüente se os mesmos estão de acordo com os requisitos de qualidade definidos e utilizados pela norma NBR ISO/IEC 12119.

Houve a preocupação de solicitar o preenchimento do Formulário de Avaliação pelo maior número de técnicos possível para aquele dado pacote de software, visando a obter uma amostra significativa.

Houve também a preocupação de avaliar o perfil destes técnicos (tempo de conhecimento, natureza das organizações em que trabalham1_{) com o objetivo de} verificar se a avaliação foi tendenciosa ou não.

1.3. Organização da Dissertação

Esta dissertação contém quatro capítulos, além desta Introdução.

No capítulo 2, são apresentados os conceitos gerais de Qualidade de Software e seu estado da arte. É apresentada, ainda, a abordagem GQM.

No capítulo 3, é apresentado a metodologia de avaliação da qualidade de um pacote de software por intermédio da aplicação da norma NBR ISO/IEC 12119.

No capítulo 4, é apresentado o estudo de caso relativo aos pacotes Lotus Notes e MS-Exchange.

No capítulo 5, são apresentadas as conclusões e contribuições desta dissertação e as perspectivas para futuras pesquisas.

No Anexo I é apresentado o Formulário de Avaliação destacando os requisitos de qualidade definidos para o Formulário de Avaliação.

1_{Entendemos como natureza das organizações: organizações públicas, organizações}

(21)

(22)

2. QUALIDADE DE SOFTWARE

Num mercado de uma dezena de bilhões de reais por ano, sendo 21% de comercialização de pacotes de software [PESQUI01], o software brasileiro busca seu espaço nos mercados interno e externo. Para apoiar esta competitividade as empresas brasileiras e mundiais de software estão adotando a Qualidade de Software como base de sustentação do processo de desenvolvimento de software.

Várias empresas buscam entrar neste mercado ou se adaptar a ele, adquirindo Tecnologia da Informação. Entretanto, o retorno não é significativo. Cerca de 80% das empresas que fizerem investimentos em Tecnologia da Informação estão obtendo, tipicamente, apenas 20% dos benefícios que estão disponíveis [GATESB99]. A adoção da Tecnologia da Informação não é suficiente para produzir ou usar software de qualidade. É necessária a adoção de normas e características para o bom aproveitamento desta tecnologia. Neste contexto, destacamos a importância de se garantir a Qualidade de Software.

2.1. Conceito de Qualidade

Segundo [SCHULM97], o conceito de Qualidade é amplo e de muitas faces. A Qualidade é percebida em vários domínios, incluindo filosofia, economia, marketing, e planejamento. [SCHULM97] conclui que Qualidade pode ser descrita em cinco diferentes perspectivas:

9 Transcendental: qualidade como algo que pode ser reconhecido mas não definido;

(23)

9 Produto: qualidade como um vínculo inerente às características do produto;

9 Valor Base: qualidade como fator dependente para o custo e pagamento de algo.

Qualidade é um quesito exigido no dia a dia, tanto na forma como vivemos, quanto no que comemos ou vestimos [JUNIOR96].

As organizações têm tentado utilizar a referência de qualidade como o ponto de vista de fabricação. A ISO 8492, de 1986, define Qualidade como a totalidade de fatores e características de produtos ou serviços que sustentam habilidades para satisfazer as necessidades explícitas e implícitas [SCHULM97].

Qualidade pode ser definida como "estar em conformidade com os requisitos do cliente". Esta é a definição bem simples aplicada pela Engenharia de Software, que busca constantemente obter o melhor nível de satisfação do cliente, não só em relação ao atendimento de seus requisitos, mas também com relação à credibilidade e confiança no software [SCHULM97].

2.2. Conceito de Software

(24)

Uma descrição de software num livro didático, segundo [PRESSM00], poderia assumir a seguinte forma: "Software é: (1) instruções (programas de computador) que, quando executadas, produzem a função e o desempenho desejados; (2) estruturas de dados que possibilitam que os programas manipulem adequadamente a informação; e (3) documentos que descrevem a operação e o uso dos programas".

Para o objetivo de nosso trabalho, enfocaremos o item 3 da definição acima, que diz respeito às documentações que compõem o software. Entretanto, vamos acrescentar a esta definição o conceito de que a documentação necessária para instalar, usar e manter os programas de computador é parte integrante e necessária de um software de qualidade.

2.3. Conceito de Qualidade de Software

Pressman cita Philip Crosby para ponderar sobre o que seria Qualidade de Software: [PRESSM00]

(25)

A última frase da definição acima é significativa. Todos acham que Qualidade de Software é algo a ser atingido ou realizado apenas quando o tempo permitir. É justamente por esta "falta de qualidade" que estas pessoas continuam buscando o referido tempo para aplicar e seguir as orientações da Qualidade de Software.

Muitas definições de Qualidade de Software têm sido propostas na literatura. Para os nossos propósitos, Qualidade de Software é definida como: "Conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido” [PRESSM00].

A definição apresentada acima serve para enfatizar três pontos importantes: [PRESSM00]

1. Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de conformidade aos requisitos significa falta de qualidade;

2. Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios não forem seguidos, o resultado quase que seguramente será a falta de qualidade;

(26)

Segundo [REZEND99], pode-se estender este conceito para o atendimento aos padrões ISO e ainda, [SHEPPE92], um conjunto de propriedades a serem satisfeitas em um determinado grau, de modo que o software satisfaça às necessidades de seus usuários.

Entretanto, várias empresas adotam como Qualidade de Software apenas a Garantia do produto, que implica em [ROCHAA01]:

9 Garantir que todos os planos exigidos pelo contrato estejam de acordo com o mesmo, sejam documentados, estejam mutuamente consistentes e sejam executados quando exigidos;

9 Garantir que os produtos de software e sua documentação estejam de acordo com o contrato e os planos;

9 Garantir que os produtos de software satisfaçam totalmente aos requisitos contratuais e sejam aceitáveis pelo adquirente.

2.4. Métricas de Qualidade de Software

(27)

Conforme ainda [PRESSM00], os fatores de Qualidade se Software que focalizam suas características operacionais, sua manutenibilidade de mudanças e sua adaptabilidade a novos ambientes são apresentados na Figura 1.

Figura 1: Fatores de Qualidade de Software

Diferentes autores definem vários outros fatores de Qualidade de Software. Luis Olsina [OLSINA00], por exemplo, definiu vários Fatores de Qualidade para o ambiente Web.

É importante destacar que estes fatores precisam ser medidos, verificados e validados. Com este objetivo, foram criadas as Métricas de Qualidade de Software.

(28)

sentidos. Está é a maior vantagem das medidas – ela melhora nossa capacidade de sentir coisas não acessíveis às nossas habilidades ou inteligência nativas. Sem outro auxílio, nosso cérebro toma todos os dados dos sentidos – visão, som, olfato, paladar e tato – transformando estes impulsos simples em medidas, que são então utilizadas para estimar distâncias, dimensões, claridade, sabores etc. [ARTHUR94].

Segundo [REZEND99], o software é medido por várias razões: indicar a qualidade do produto; avaliar a produtividade das pessoas que produzem o produto; avaliar os benefícios (em termos de produtividade e qualidade) derivados de novos métodos e ferramentas de software; formar uma linha base para estimativas e; ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional.

Medir é fundamental em qualquer disciplina. Pressman cita Lorde Kelvin, que disse, certa vez: [PRESSM00]

“Quando se pode medir aquilo sobre o qual se está falando e expressá-lo em números, sabe-se alguma coisa sobre o mesmo; mas quando não se pode medi-lo, quando não se pode expressá-lo em números, o conhecimento que se tem é de um tipo inadequado e insatisfatório; este pode ser o começo do conhecimento, mas dificilmente alguém terá avançado em suas idéias para o estágio de ciência”.

(29)

As Métricas de Software referem-se a uma ampla variedade de medidas de software. No contexto de gerenciamento de projetos, temos métricas de produtividade e de qualidade. Essas Métricas são medidas de resultado de desenvolvimento de software como uma função do esforço aplicado e medidas da "adequação ao uso" do resultado que é produzido [PRESSM00].

A qualidade pode ser medida ao longo do processo de engenharia de software e depois que o software for entregue ao cliente e aos usuários [PRESSM00].

Assim, como na ISO/IEC 9126, todas as características para Web são avaliadas por intermédio de métricas. Podemos entender métricas (nível qualitativo) como um método e uma escala quantitativa que podem ser usados para determinar o valor que uma particularidade (feature) recebe em um produto de software específico [9126-1].

As métricas podem ser classificadas de diferentes formas, dentre as quais destacamos:

9 objetivas (expressões numéricas ou representações gráficas de expressões

numéricas que podem ser computadas de documentos de software) e subjetivas (medidas relativas, baseadas em estimativas pessoais ou de grupo, por exemplo: bom, ruim, etc.) [MÖLLER93];

9 diretas (existência e a quantificação de um fator de qualidade sem depender

de outro atributo) ou indiretas (são aquelas que envolvem as medidas de um ou mais atributos) [OLSINA99];

9 automáticas e não automáticas. As métricas automáticas são aquelas das

(30)

automáticas são aquelas que dependem de algum fator não automatizado [OLSINA99].

Embora o uso de Métricas seja ainda recente, elas podem ser utilizadas para diferentes fins, como por exemplo, para estimativa de recursos de projeto, como mecanismo para avaliar o desempenho do projeto e da equipe de desenvolvimento, para avaliação de métodos de desenvolvimento e para ajudar a equipe de desenvolvimento a conseguir boas estimativas da qualidade do seu trabalho [REZEND99].

As principais preocupações da indústria e dos pesquisadores de métricas para software referem-se à falta de validações empíricas de métricas, principalmente métricas para projeto e especificações, à falta de bons experimentos para essas validações e à falta de ferramentas de suporte [FENTON91].

As métricas podem ser utilizadas com diferentes propósitos na Engenharia de Software, além da qualidade do produto. Nesse contexto, Basili [BASILI94] propôs utilizar métricas segundo objetivos específicos, conforme o paradigma Goal/Question/Metrics (GQM). O GQM representa uma aproximação prática para resolver o problema de medidas. A abordagem GQM será abordada no item 2.7 – página 50.

2.5. Qualidade dos Produtos de Software

As normas técnicas publicadas pela ISO têm por objetivo estabelecer regras e padrões nos processos de avaliação da Qualidade [ROCHAA01].

(31)

avaliar a qualidade dos produtos de software. Especificamente, destacamos as normas de Qualidade de Produto de Software, a saber [WEBERK01]:

9 ISO/IEC 9126-1: Modelo de Qualidade; 9 ISO/IEC 9126-2: Métricas Externas; 9 ISO/IEC 9126-3: Métricas Internas;

9 ISO/IEC 9126-4: Métricas de Qualidade em Uso.

O modelo da qualidade definido na ISO/IEC 9126-1 [9126-1], utilizado como referência para o processo de avaliação da qualidade de produto de software, está subdividido em duas partes: modelo para características externas [9126-2] e internas [9126-3]; e modelo para qualidade em uso [9126-4].

2.5.1. Modelo para Características Externas e Internas

O modelo de qualidade para características externas e internas classifica os atributos de qualidade dos produtos de software em seis características (funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade). Estas características podem ser desdobradas em subcaracterísticas. As subcaracterísticas podem ser desdobradas em mais níveis, que caracterizam os atributos da qualidade. As métricas internas e externas aplicam-se, em geral, ao nível dos atributos da qualidade. Portanto, o modelo de qualidade está dividido em características, subcaracterísticas e métricas [WEBERK01].

A ISO/IEC 9126 define que as características de qualidade de um produto são [WEBERK01] [9126-2] [9126-3]:

9 Funcionalidade: conjunto de atributos que evidenciam a existência de

(32)

são as que satisfazem as necessidades explícitas ou implícitas. Tem como subcaracterísticas: adequação, acurácia, interoperabilidade, segurança de acesso e conformidade;

9 Confiabilidade: conjunto de atributos que evidenciam a capacidade do

software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido. Tem como subcaracterísticas: maturidade, tolerância a falhas, recuperabilidade e conformidade;

9 Usabilidade: conjunto de atributos que evidenciam o esforço

necessário para se poder utilizar o software, bem como o julgamento individual desse uso, por um conjunto explícito ou implícito de usuários. Tem como subcaracterísticas: inteligibilidade, apreensibilidade, operacionalidade, atratividade e conformidade;

9 Eficiência: conjunto de atributos que evidenciam o relacionamento

entre o nível de desempenho do software e a quantidade de recursos usados, sob condições estabelecidas. Tem como subcaracterísticas: comportamento em relação ao tempo, comportamento em relação aos recursos e conformidade;

9 Manutenibilidade: conjunto de atributos que evidenciam o esforço

necessário para fazer modificações especificadas no software. Tem como subcaracterísticas: analisabilidade, modificabilidade, estabilidade, testabilidade e conformidade;

9 Portabilidade: conjunto de atributos que evidenciam a capacidade do

(33)

subcaracterísticas: adaptabilidade, capacidade para ser instalado, coexistência, capacidade para substituir e conformidade.

A Tabela 1 mostra as subcaracterísticas e as perguntas típicas para cada característica [LIMARS01]:

Funcionalidade Satisfaz as necessidades?

Adequação Propõe-se a fazer o que é apropriado? Acurácia Faz o que foi proposto de forma correta?

Interoperabilidade É capaz de interagir com os sistemas especificados? Segurança Controla acessos não autorizados a programas e dados? Conformidade Esta de acordo com as normas, leis etc.?

Confiabilidade É imune a falhas?

Maturidade Com que freqüência apresenta falhas por defeitos no software?

Tolerância à falha Ocorrendo falhas, como ele reage?

Recuperabilidade É capaz de recuperar dados em caso de falhas? Usabilidade É fácil de usar?

Inteligibilidade É fácil entender seu conceito lógico e sua aplicabilidade? Apreensibilidade É fácil aprender a usá-lo?

Operacionalidade É fácil operá-lo e controlá-lo? Atratividade É capaz de ser atrativo? Eficiência É rápido e "enxuto"? Comportamento em

relação ao tempo

Qual é o tempo de resposta, processamento e velocidade na execução de suas funções?

Comportamento em

relação aos recursos Quanto de recurso usa? Durante quanto tempo? Manutenibilidade É fácil modifica-lo?

Analisabilidade É fácil de encontrar uma falha, quando ocorrer? Modificabilidade É fácil de se modificar e de se adaptar?

(34)

Funcionalidade Satisfaz as necessidades?

uma alteração?

Testabilidade É fácil validar o software modificado? Portabilidade É fácil usá-lo em outro ambiente?

Adaptabilidade É fácil adaptar-se a ambientes diferentes? Capacidade para ser

instalado É fácil instalá-lo?

Coexistência Está de acordo com os padrões de portabilidade? Capacidade para

substituir É fácil usá-lo em substituição a outro?

Tabela 1: Relação de características, subcaracterísticas e perguntas típicas

A ISO/IEC 9126-1 conduz a um entendimento dos conceitos que definem as diversas características e subcaracterísticas da qualidade de produto de software; porém, na prática, ainda não facilita o suficiente a definição dos requisitos de qualidade a partir dela. As definições de características de qualidade permitem perceber um possível universo de requisitos que se enquadram no conceito apresentado, mas dificilmente permitiriam elaborar uma declaração de requisitos mais criteriosa, quanto às mesmas. Não faz sentido, por exemplo, uma declaração do tipo “o produto de software deve ter uma usabilidade de 0,5”, pois esse número não teria qualquer significado (pelo menos no estado da arte em que se encontra o tema de medição da qualidade de produto de software) [WEBERK01].

(35)

do tipo “a operacionalidade deve ser igual a 0,8”, por exemplo, continua sem fazer sentido [WEBERK01].

Assim, o usuário da norma que necessite elaborar sua declaração de requisitos deve fazer o próximo nível de desdobramento, os atributos, (que não estão presentes na ISO/IEC 9126-1), identificando aspectos relevantes ao produto de software e que se enquadram nas características e subcaracterísticas citadas. Desta forma, uma declaração do tipo “o tempo de uso do produto de software, até que se tenha domínio operacional do mesmo, deverá ser inferior a 20 horas”, por exemplo, é adequada como requisito da subcaracterística operacionalidade, que faz parte da característica usabilidade. Observe que foi necessário descer ao nível do atributo “tempo para se ter domínio operacional” para que o requisito pudesse ser declarado de forma objetiva e não ambígua [WEBERK01].

O documento ISO/IEC 9126-2 define métricas externas que se associam a atributos de qualidade e que podem ser uma referência inicial, facilitando a tarefa de definir atributos. O modelo de qualidade da ISO/IEC 9126-1 privilegia a visão do usuário do produto de software que, em geral, atua a partir da operação do sistema do qual o produto de software faz parte. Esta é a visão de qualidade externa [WEBERK01].

(36)

sendo que a identificação das correlações existentes não é um trabalho simples, depende de cada organização que desenvolve o software. Apesar disso, se a organização fizer este investimento, terá mais condições de garantir a qualidade de seus produtos pois será capaz de especificá-los e avaliá-los (através das características, subcaracterísticas e atributos externos) cada vez com mais precisão [WEBERK01].

Apesar da norma enumerar as características e subcaracterísticas de um software, algumas destas características são medidas de forma subjetiva. A norma ISO/IEC 9126 não define como quantificá-las.

2.5.2. Modelo para Qualidade em Uso

O modelo de qualidade em uso apresenta um conjunto de características aplicáveis a qualquer produto de software. A Qualidade em Uso é a capacidade de o produto de software permitir a determinados usuários atingir metas especificadas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado [9126-4]. Os atributos da qualidade em uso são classificados em quatro características [ROCHAA01]:

9 Efetividade: refere-se à capacidade de o produto de software

possibilitar aos usuários atingir metas especificadas com acurácia e completeza em um contexto de uso especificado;

9 Produtividade: refere-se à capacidade do produto de software de

(37)

9 Segurança: refere-se à capacidade de o produto de software oferecer níveis aceitáveis de risco de danos a pessoas, negócios, software, propriedade ou ao ambiente em um contexto de uso especificado;

9 Satisfação: refere-se à capacidade do produto de software em

satisfazer usuários em um contexto de uso especificado.

A visão do modelo de qualidade levando em conta os resultados obtidos a partir do uso do software no ambiente especificado é uma inovação em relação ao modelo original da ISO/IEC 9126. Esta visão pode ser usada como referência para a definição de requisitos da qualidade esperados para o ambiente de uso, assim como para a avaliação dos resultados obtidos. Quando o modelo de qualidade em uso for utilizado para a definição de requisitos, é necessário o estabelecimento das regras de derivação de atributos de características externas para o produto de software, a partir das características da qualidade em uso [WEBERK01].

2.5.3. Norma NBR ISO/IEC 12119

Esta norma versa sobre Qualidade de Pacotes de Software, estabelecendo os requisitos de qualidade para pacotes e apresentando instruções de como avaliar um pacote de software.

(38)

quanto o das propriedades especificadas na descrição do produto. Devem incluir, também, o teste de inspeção dos documentos e o teste caixa-preta.

Esta norma não trata de processos de produção de software (tampouco atividades e produtos intermediários, por exemplo especificações); trata somente de pacotes de software na forma como são oferecidos e liberados para uso. O sistema de qualidade do produto (tratado, por exemplo, na NBR ISO 9001) está fora do escopo desta norma.

A norma NBR ISO/IEC 12119 - Pacotes de Software - foi escrita com o objetivo de auxiliar fornecedores, compradores, entidades que desejam Certificações e laboratórios de testes, na aquisição, venda ou teste de pacotes de software. Entretanto, a aplicação dos quesitos de qualidade definidos por esta norma serve de indicadores para verificarmos se os pacotes de software estão de acordo com as Métricas de Qualidade de Software.

A norma define:

9 Descrição do Produto como “documento expondo as propriedades de

um pacote de software”;

9 Documentação do Usuário como “conjunto completo de documentos,

disponível na forma impressa ou não, que é fornecido para a utilização de um produto, sendo também uma parte integrante do produto”;

9 Programas como “unidade sintática que está em conformidade com as

(39)

9 Dados como “representação reinterpretável da informação de maneira formalizada, adequada para comunicação, interpretação ou processamento”.

A norma define ainda como requisitos de qualidade para Pacotes de Software: 9 necessidade de que cada pacote se software tenha uma descrição de

produto e documentação de usuário;

9 requisitos para a descrição do produto. Em particular, há um requisito estabelecendo que esta descrição deve conter informações específicas e que todas as suas declarações devem ser passíveis de testes e corretas;

9 requisitos para a documentação de usuário;

9 requisitos para os programas e dados, caso existam, incluídos no pacote.

A Descrição do Produto, segundo a norma, define o produto e é uma parte do conjunto de documentação do produto. Ela fornece informações sobre a documentação de usuário, programas e, se existirem, sobre os dados.

Os principais objetivos da descrição do produto são:

9 ajudar o usuário ou o comprador em potencial na avaliação da adequação do produto às suas necessidades. Por extensão, ela também fornece informações para venda;

9 servir como base para testes.

(40)

organização e apresentação, a fim de auxiliar os compradores em potencial na avaliação da adequação do produto às suas necessidade, antes de comprá-lo.

A Descrição do Produto deverá incluir: 9 Identificação e Indicações;

9 Declarações sobre Funcionalidade; 9 Declarações sobre Confiabilidade; 9 Declarações sobre Usabilidade; 9 Declarações sobre Eficiência;

9 Declarações sobre Manutenibilidade; 9 Declarações sobre Portabilidade.

A Documentação do Usuário deverá ter as seguintes características: 9 Completitude: informações necessárias para o uso do produto; 9 Correção: informações devem estar corretas;

9 Consistência: informações não devem apresentar contradições; 9 Inteligibilidade: informações devem ser inteligíveis aos usuários;

9 Apresentação e organização: informações devem ser bem

apresentadas e organizadas.

Os Programas e Dados deverão possuir as seguintes características: 9 Funcionalidade;

9 Confiabilidade;

9 Usabilidade;

9 Eficiência;

9 Manutenibilidade;

(41)

Cabe ressaltar que as normas NBR ISO/IEC 12119 e a ISO/IEC 9126 apresentam as mesmas características: Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade. Enquanto a norma ISO/IEC 9126 enfoca o desenvolvimento do produto, a norma NBR ISO/IEC 12119 enfoca a documentação dos pacotes de software.

2.6. Pacotes de Software Avaliados

Avaliamos os pacotes: Lotus Notes e o MS-Exchange. A seguir são apresentas algumas das características destes pacotes.

2.6.1. Lotus Notes

Podemos destacas as seguintes características deste pacote [LOTUSN04]: 9 Sistema de correio eletrônico, agenda em grupo, tarefas a executar e

integração das mesmas com Intranet e Internet;

9 Plataforma de desenvolvimento de aplicações para uso interno e externo em Intra/Inter e Extranets;

9 Digitação on-line de pedidos (colocados via WEB diretamente em BD relacionais, como Oracle, Sybase, Informix, SQL/Server, DB2, etc.) através de DECS, disponível sem custo adicional com o Lotus Notes; 9 Atendimento a clientes/consumidores: "Fale Conosco": sugestões,

(42)

9 Coleta "on-line" de informações de vendas: representantes ou vendedores podem entrar informações sobre preços de concorrência, giros de estoque, etc. As informações, entradas de todo o Brasil ou mundo, ficam centralizadas e formatadas para apresentação centralizada em forma de estatísticas de tempo real;

9 Disponibilização de informações estatísticas de vendas por

representante, região, vendedor, etc;

9 Integração com clientes do exterior, disponibilizando-se dados sobre pedidos, entregas, embarques, etc;

9 Help-desk: controle de problemas, ocorrências, pendências, com estatísticas de tempo demandado por solicitante, departamento, centro de custo, alocação de mão-de-obra, histórico de manutenção de equipamentos etc. Possibilidade de utilização via WEB para filiais ou usuários finais em Intranet/Internet;

9 Solicitações de manutenção de sistemas: identicamente, controle sobre necessidades de alterações em sistemas com estatísticas completas sobre distribuição de carga de trabalho, prazos, alocações por departamentos e centros de custos, etc;

9 Informações variadas de marketing podem ser publicadas

automaticamente na WEB, com os dados sendo alimentados pelos próprios usuários não-técnicos da área. Basta digitar-se/atualizar-se documentos para as informações estarem disponíveis na WEB;

(43)

Scanner para a Intranet, com controle de distribuição pública ou restrita e de usuários que devem ler as informações (exigindo o visto dos mesmos);

9 Possibilidade de se publicar manuais técnicos, normas, manuais de montagem de produtos etc; substituindo as cópias físicas de manuais, que podem ser atualizados automaticamente via WEB;

9 Sistema de compras on-line, um dos componentes de comércio eletrônico na categoria "Business-to-Business"; o departamento de compras pode publicar automaticamente as cotações sendo efetuadas e fornecedores cadastrados, através de senha, consultam e divulgam seus preços. O sistema apóia todo o processo com avisos por email e mantém estatísticas, históricos e informações gerenciais centralizadas e controladas hierarquicamente;

9 Solicitações de adiantamentos e relatórios de viagens;

9 Publicação de informações de Recursos Humanos, como aniversários, calendário de eventos, promoções de pessoal, dados sobre políticas de Recursos Humanos etc.

2.6.2. MS-Exchange

Podemos destacar as seguintes características deste pacote [MICROS04]: 9 Integração com o Microsoft Active Directory™: o Exchange 2000

(44)

grupos, permissões, dados de configuração, logon na rede, arquivo, compartilhamentos da Web, etc;

9 Conteúdo de e-mail nativo da Internet: o Exchange 2000 aumenta substancialmente o desempenho do e-mail da Internet, permitindo que os clientes de e-mail armazenem e recuperem o conteúdo MIME2 diretamente do sistema de armazenamento, com uma conversão de formato "por demanda" conforme necessário;

9 Roteamento SMTP: o Exchange 2000 leva a integração das mensagens com a Internet para um novo nível, proporcionando um roteamento de alto desempenho dos e-mails entre os servidores que usam o SMTP; 9 Monitoramento do sistema usando a instrumentação do Windows: o

Exchange 2000 emprega uma novíssima infra-estrutura de monitoramento e interface do usuário para permitir o monitoramento do sistema de uma infra-estrutura do Exchange, fornecendo uma visão simples, filtrável e nivelada de todos os servidores e conectores da empresa;

9 Listas de controle de acesso do Windows 2000: o acesso a todos os recursos compartilhados no Exchange é definido com as listas de controle de acesso, fornecendo a integração da segurança;

2_{MIME significa extensões de múltiplos propósitos do correio do Internet, e consulta a um}

(45)

9 Grupos de armazenamento: um grupo de armazenamento é um agrupamento de bancos de dados que compartilham um único log de transações e, portanto, um só ponto de administração, backup e restauração para redução dos tempos de backup e restauração;

9 Diretivas: as diretivas proporcionam uma forma poderosa e flexível para alterar, em uma única operação, as opções administrativas de um conjunto de objetos como, por exemplo, caixas de correio de usuários, servidores e pastas públicas;

9 Objetos de colaboração de dados (CDO) do Exchange Management: os CDO do Exchange Management são uma interface de programação abrangente para criar aplicativos de gerenciamento personalizados que podem executar uma ampla variedade de tarefas de gerenciamento; 9 Hospedagem de aplicativos da Web: por meio da firme integração entre

o Exchange 2000 e o Internet Information Services, os desenvolvedores podem hospedar tanto os seus aplicativos da Web quanto o conteúdo dos aplicativos, a partir de um único local no Exchange 2000. Essa integração permite que os desenvolvedores nivelem a mesma segurança, programação, replicação e backup/restauração dos seus dados e aplicativos;

(46)

9 Layout gráfico do fluxo de trabalho: o Workflow Designer para Exchange 2000 oferece uma ferramenta de modelagem gráfica para que os designers criem modelos e implementem suas soluções de fluxo de trabalho. Com essa ferramenta, é possível criar novas soluções de fluxo de trabalho ou adicionar fluxo de trabalho a aplicativos existentes; 9 Conferência de dados: o Exchange 2000 oferece conferência de dados

com vários pontos, para permitir que grupos de pessoas se comuniquem e colaborem em tempo real através da Internet ou de Intranet corporativa. Entre os serviços, incluem-se o compartilhamento da área de trabalho, dos aplicativos, discussão de texto, recursos de quadros de comunicações e transferência de arquivos;

9 Gerenciamento de agenda: o serviço de gerenciamento de conferências do Exchange 2000 coordena tecnologias de conferência diferentes, assim como a administração de recursos de conferência corporativa limitados, para garantir a máxima eficiência de recursos de conferência e de rede;

9 Administração de estação única: o uso de um único console para gerenciar todos os servidores Microsoft, incluindo o próprio Windows 2000, significa que os administradores treinam uma vez e reutilizam sua experiência nas tarefas de gerenciamento;

(47)

9 Formulários do Outlook: o Outlook 2000 inclui um ambiente completo para desenvolvimento de formulários, que está firmemente integrado ao Exchange Server;

9 Criptografia da chave pública: com o Exchange e o Outlook, o e-mail pode ser assinado digitalmente e criptografado. O sistema de criptografia usa o Certificate Server do Windows e é gerenciado pelo servidor de administração de chaves (KMS) da Microsoft;

9 Interoperabilidade de e-mail: o Exchange Server inclui ferramentas para a interoperação com os seguintes sistemas de e-mail: Microsoft Mail, Lotus cc:Mail, Lotus Notes/Domino e Novell GroupWise;

9 Interoperabilidade do diretório: o Exchange Server inclui ferramentas que permitem a interoperação com os seguintes sistemas para obter informações de diretórios: Microsoft Mail, Novell GroupWise, Lotus cc:Mail e Lotus Notes/Domino;

9 Cliente Outlook 2000: o Exchange 2000 inclui o Outlook 2000, o principal cliente de mensagens e colaboração disponível. Além de completar a funcionalidade do e-mail, o Outlook 2000 inclui o agendamento de grupos, gerenciamento de tarefas e contatos, e ferramentas de desenvolvimento de aplicativos para aplicativos comerciais personalizados;

(48)

9 Integração do Internet Information Server (IIS): O Exchange 2000 integra-se firmemente ao IIS, proporcionando uma plataforma de aplicativos da Web completa e acesso de alto desempenho às informações da Web;

9 Cluster: Para aumentar os níveis já altos de confiabilidade no Exchange Server, o Exchange 2000 oferece um cluster ativo/ativo de duas vias. O cluster requer o Exchange 2000 Enterprise Server e o Windows 2000 Advanced Server;

9 Roteamento tolerante a falhas: Os algoritmos aprimorados garantem que as mensagens sejam entregues por um custo acessível, através de topologias complexas, apesar das muitas falhas de rede ou máquina; 9 Suporte aos padrões da Internet: O suporte nativo a SMTP, POP,

LDAP, HTTP, IMAP, NNTP, S/MIME e X.509v3 permite que o Exchange seja um gateway da organização para a Internet;

9 Segurança do Windows 2000: O Exchange 2000 é o único sistema de mensagens e colaboração que usa todos os recursos do Windows 2000 para garantir a segurança das mensagens e da colaboração. Os administradores do sistema podem criar e gerenciar todos os grupos e permissões de usuários uma vez para toda a rede e os cenários de mensagens e colaboração;

(49)

em C++, Microsoft Visual Basic, Visual Basic Scripting Edition, Java Script e Java;

9 Integração com o FrontPage 2000: Os designers de aplicativos podem usar O Microsoft FrontPage 2000 para criar e manter aplicativos do Web Storage System;

9 Formulários do Web Storage System: Os formulários do Web Storage System são personalizados e gerados por scripts ASP ou por extensões ISAPI que substituem o formulário padrão e visualizam os processos do Outlook Web Access. Esta tecnologia fornece aos designers de aplicativos uma ferramenta poderosa e integrada para vincular os aplicativos da Web às propriedades de lógica comercial, eventos e metadados do Web Storage System;

9 Endereçamento de URL: Todos os dados armazenados no Web Storage System podem ser acessados por meio de um navegador da Web com um URL amigável para o usuário, permitindo o acesso fácil às informações.

2.7. A Abordagem

Goal/Question/Metric (GQM)

O sucesso de um projeto de software é determinado pelo grau com que ele atinge os objetivos que motivaram a sua construção [ROCHAA01].

(50)

A abordagem GQM parte da suposição de que, para uma organização adotar um processo de medida definitivo, é necessário, em primeiro lugar, estabelecer os objetivos da própria organização e de seus produtos. Definidos esses objetivos, é necessário criar um ambiente (framework) de suporte que seja capaz de interpretar os dados comparando-os com os objetivos estabelecidos. Sendo assim, em termos gerais, é necessário identificar qual a necessidade de informações da organização; se essas podem ser quantificadas e qualificadas; como obtê-las, e se podem ser analisadas em função dos objetivos [ESEGRO01].

A abordagem GQM foi definida originalmente para avaliação de defeitos em um conjunto de projetos na NASA. A aplicação envolveu um conjunto de estudos de casos e foi expandida para incluir várias abordagens experimentais. Embora a abordagem tenha sido usada originalmente para definir e avaliar os objetivos de um projeto específico, seu uso foi expandido para contextos maiores [BASILI01].

A abordagem GQM é uma metodologia usada para a definição de um processo de mensuração que possibilita o acompanhamento e a avaliação do processo operacional de produção de software. Essa abordagem representa uma sistemática para ajuste e interação de objetivos operacionais, táticos e estratégicos de uma organização com modelos de processos, produtos e perspectivas de qualidade de software com base em necessidades específicas do projeto e da organização [ROCHAA01].

Os princípios desta abordagem podem ser resumidos em [PERFEC01]: 9 Conjunto definido de objetivos;

9 Aquisição de modelos de qualidade por parte dos envolvidos;

(51)

9 Derivação das métricas;

9 Análise e interpretação dos dados obtidos.

A abordagem GQM considera que devemos definir um conjunto selecionado de objetivos (Goal) do projeto no contexto de uma organização (considerando as características e atributos desejados dos processos, produtos e recursos), construindo e refinando um conjunto de perguntas (Questions) para cada objetivo e, em função de cada pergunta, elegem-se as métricas apropriadas (Metric). [OLSINA00] [SOLING99]

As fases da abordagem GQM são [TRAVAS01]: 9 Planejamento;

9 Definição;

9 Coleta de dados; 9 Interpretação.

A Figura 2 mostra os componentes do modelo e sua estrutura hierárquica.

(52)

Os níveis do modelo são [ESEGRO01]:

9 Nível Conceitual (Objetivos): diz respeito à definição do objetivo para o objeto a ser medido, levando-se em conta o modelo de qualidade que se pretende atingir e o ponto de vista da observação;

9 Nível Operacional (Questões): diz respeito a um conjunto de questões a partir de um objetivo, em relação a características de qualidade selecionadas para um ponto de vista;

9 Nível Quantitativo (Métricas): diz respeito a um conjunto de métricas para cada questão, de modo a responder a cada uma delas quantitativamente. Estes dados podem ser objetivos (depende apenas do objeto que está sendo medido e não do ponto de vista em que são obtidos) ou subjetivos (depende do objeto que está sendo medido e do ponto de vista em que são obtidos).

O resultado da aplicação da abordagem GQM é a especificação de um sistema de medidas objetivando um conjunto particular de casos e de regras na interpretação dos dados medidos [TRAVAS01].

(53)

3. AVALIANDO A QUALIDADE DE PACOTES DE

SOFTWARE

A verificação se um dado pacote de software está ou não de acordo com as normas técnicas indica que este pacote possui os requisitos mínimos exigidos pelos conceitos da Qualidade de Software. A avaliação por intermédio da aplicação das exigências da norma NBR ISO/IEC 12119 tem por objetivo verificar se estes pacotes estão de acordo com tais exigências de qualidade. Portanto, avaliar a qualidade dos pacotes de software pode ser o primeiro passo na obtenção de uma futura certificação e/ou uma garantia na compra ou venda destes pacotes e/ou o primeiro passo na busca da qualidade de uma instituição. Além disso, o mercado de informática precisa de subsídios para afirmar ou questionar se um pacote é de qualidade ou não. O mais importante é validar se a aplicação da norma pode e deve ser utilizada como parâmetro de aquisição para novos pacotes e de comparação entre eles.

3.1. Metodologia

(54)

resposta deverá ser utilizado e, quais serão os graus de atendimento aos requisitos de qualidade.

A metodologia engloba os seguintes passos:

1. Elaboração das questões (Metrics): baseado nas Normas NBR ISO/IEC 12119 e ISO/IEC 9126 em conjunto com as orientações dispostas nestas normas e, utilizando a abordagem GQM, será construído um conjunto de questões que individualmente possibilitará a avaliação de cada tópico apresentado na Norma NBR ISO/IEC 12119 e, de forma conjunto, possibilitará a avaliação dos Itens e Seções da NBR ISO/IEC 12119. A elaboração das questões é apresentada no item 3.2. Elaboração do Formulário de Avaliação na página 57.

2. Estabelecimento dos requisitos de qualidade: após a construção das questões a serem utilizadas, será necessário o estabelecimento dos requisitos de qualidade para cada questão. O estabelecimento destes requisitos será baseado nos requisitos de qualidade apresentados nas Normas NBR ISO/IEC 12119 e ISO/IEC 9126. O estabelecimento dos requisitos de qualidade é apresentado no item 3.3. Estabelecimento dos requisitos de qualidade na página 83.

(55)

é apresentada no item 3.4. Elaboração e estabelecimento dos requisitos de qualidade para o Formulário de Avaliação na página 85.

4. Estabelecimento dos requisitos de qualidade para as questões de avaliação do Formulário de Avaliação: após a construção das questões a serem utilizadas na avaliação do Formulário de Avaliação, será necessário o estabelecimento dos requisitos de qualidade para cada questão. O estabelecimento destes requisitos será baseado nos requisitos de qualidade apresentados nas Normas NBR ISO/IEC 12119 e ISO/IEC 9126. O estabelecimento dos requisitos de qualidade é apresentado no item 3.4. Elaboração e estabelecimento dos requisitos de qualidade para o Formulário de Avaliação na página 85.

5. Elaboração do Formulário de Avaliação: será elaborado um Formulário de Avaliação contendo as questões definidas nos passos 1 e 3. Este Formulário conterá ainda uma série de orientações para os avaliadores e um gabarito para preenchimento da avaliação. Este gabarito visará facilitar o envio da avaliação pelo avaliador ao responsável pela análise dos resultados. A elaboração do Formulário de Avaliação é apresentado no item3.2. Elaboração do Formulário de Avaliação na página 57.

(56)

7. Realização da Avaliação e Análise dos resultados: Após o recebimento das avaliações serão realizadas as análises necessárias para verificar se os pacotes estão em conformidade com os requisitos de qualidades solicitados pelas normas NBR ISO/IEC 12119 e ISO/IEC 9126. A realização da avaliação e análise dos resultados estão dispostos no Capítulo 4. ESTUDO DE CASO na página 87.

Podemos expressar, em termos gráficos, a metodologia proposta conforme apresentada na Figura 3.

Figura 3: Metodologia Proposta

3.2. Elaboração do Formulário de Avaliação

Para estabelecermos os requisitos de qualidade, analisaremos a norma NBR ISO/IEC 12119 e observaremos sua orientação para as características de qualidade para pacote de software.

(57)

[9126-1] e de outros trabalhos na literatura (como por exemplo, [LIMARS00]), elaboraremos um formulário de avaliação que utilizará escalas ou graus de atendimento aos requisitos de qualidade.

O objetivo desta avaliação é verificar se estes pacotes estão de acordo com os requisitos de qualidade apresentados na norma. Então, decidimos avaliar os pacotes de software utilizados no Ministério do Planejamento, Orçamento e Gestão, Correios e Telégrafos, Agência Nacional de Águas e em algumas organizações privadas.

Um aspecto importante a ser citado é que partimos da consideração de que todas as Organizações, por intermédio de seus técnicos, que irão responder às questões contidas no Formulário de Avaliação, já utilizam os pacotes a serem avaliados e que esta utilização ocorre de forma legal, proporcionando o “Kit” completo do pacote de software.

Definimos então, que elaboraríamos um Formulário de Avaliação que traduzisse as características de qualidade em métricas reais e calculáveis, conforme orientações dispostas na seção 4. Instruções de teste da norma NBR ISO/IEC 12119.

Construiremos o Formulário de Avaliação utilizando a abordagem GQM (item 2.7). Para cada item das seções 1. Objetivo e 3. Requisitos de Qualidade da norma NBR ISO/IEC 12119, serão realizadas uma ou mais Questions e destas Questions derivaremos para uma ou mais Metrics e seus graus de atendimento (grupos de respostas) aos requisitos de qualidade.

(58)

9 0-Nunca, 1-Quase Nunca, 2-Às Vezes, 3-Quase Sempre, 4-Sempre e 5-Não Sei Afirmar;

9 0-abaixo de 10, 1- de 10 até 15, 2- de 15 até 20, 3- de 20 até 25, 4- de 25 até 30 e 5-Acima de 30.

A escolha do grupo de resposta para cada questão ocorreu conforme interpretação da norma NBR ISO/IEC 12119. Sendo assim, construímos o modelo GQM descrito a seguir.

Goal: Verificar os requisitos de qualidade do pacote em avaliação.

Question 1: Atender aos requisitos de qualidade apresentados na seção 1 da

norma NBR ISO/IEC 12119, ou seja, referentes ao objetivo da norma que é a sua aplicabilidade.

Metric 1: Ao ler a documentação deste produto, você percebeu que

suas necessidades seriam atendidas?

Grupo de Respostas: ( )0-Não ( )1-Sim ( )2-Não Sei Afirmar;

Requisitos de Qualidade para aMetric 1: 1-Sim;

Question 2: Atender aos requisitos de qualidade apresentados na seção 3 da

norma NBR ISO/IEC 12119, ou seja, referentes a existência da documentação e do treinamento do pacote.

Metric 2: No momento, existe alguma documentação deste produto

disponível para você?

Grupo de Respostas: ( )0-Não ( )1-Sim ( )2-Não Sei Afirmar;

Requisitos de Qualidade para a Metric 2: 1-Sim;

(59)

Grupo de Respostas: ( )0-Nunca ( )1-Quase Nunca ( )2-Às Vezes ( )3-Quase Sempre ( )4-Sempre ( )5-Não Sei Afirmar;

Requisitos de Qualidade para a Metric 3: 3-Quase Sempre e

4-Sempre;

Metric 4: O material utilizado no treinamento está disponível?

Grupo de Respostas: ( )0-Nunca ( )1-Quase Nunca ( )2-Às

Vezes ( )3-Quase Sempre ( )4-Sempre ( )5-Não Sei Afirmar;

4-Sempre;

Question 3: Atender aos requisitos de qualidade apresentados no item 3.1.1

da norma NBR ISO/IEC 12119, ou seja, referentes aos requisitos gerais sobre o conteúdo da descrição do produto.

Metric 5: A descrição do produto está fácil de ser compreendida?

4-Sempre;

Metric 6: A descrição do produto está bem organizada?

4-Sempre;

(60)

Grupo de Respostas: ( )0-Nunca ( )1-Quase Nunca ( )2-Às Vezes ( )3-Quase Sempre ( )4-Sempre ( )5-Não Sei Afirmar;

4-Sempre;

Question 4: Atender aos requisitos de qualidade apresentados no item 3.1.2

da norma NBR ISO/IEC 12119, ou seja, referentes a identificações e indicações da descrição do produto.

Metric 8: Cada termo apresentado na descrição do produto possui

um único significado?

4-Sempre;

Metric 9: Cada item da descrição do produto é passível de ser

verificado?

4-Sempre;

Metric 10: O documento que contém a descrição do produto possui

uma única identificação, como por exemplo, um nome e/ou um número?

(61)

Metric 11: O documento que contém a descrição do produto possui

versão ou data de produção?

Requisitos de Qualidade para a Metric 11: 1-Sim

Metric 12: A descrição do produto, em todos os seus volumes e

versões, contém o nome e o endereço de algum fornecedor do produto?

4-Sempre;

Metric 13: A descrição do produto identifica as tarefas que podem ser

executadas utilizando-se o mesmo?

4-Sempre;

Metric 14: Caso o produto afirme estar em conformidade com alguma

norma ergonômica ou técnica, a descrição do produto faz referência a estas normas ou técnicas?

(62)

Metric 15: Caso o produto afirme estar em conformidade com alguma

lei ou decreto, a descrição do produto faz referência a esta lei ou decreto?

4-Sempre;

Metric 16: A descrição do produto especifica o hardware necessário

para sua execução?

Metric 17: A descrição do produto especifica o software necessário

para sua execução?

Metric 18: A descrição do produto faz referência a interface com

outros produtos?

4-Sempre;

Metric 19: A descrição do produto apresenta como a interface é