INSTRUMENTO DE AVALIAÇÃO DA SATISFAÇÃO
DE USUÁRIOS DE PRODUTOS DE SOFTWARE
Autor: Welington Souza Alves
Orientador: Prof. Dr. Paulo Sérgio Vilches Fresneda
Co-orientador: Prof. Dr. Fábio Bianchi Campos
Mestrado
WELINGTON SOUZA ALVES
INSTRUMENTO DE AVALIAÇÃO DA SATISFAÇÃO DE USUÁRIOS DE PRODUTOS 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 para a obtenção do grau de Mestre em Gestão do Conhecimento e da Tecnologia da Informação.
Orientador: Prof. Dr. Paulo Sérgio Vilches Fresneda
Co-orientador: Prof. Dr. Fábio Bianchi Campos
Dissertação de autoria de Welington Souza Alves, intitulada “INSTRUMENTO DE
AVALIAÇÃO DA SATISFAÇÃO DE USUÁRIOS DE PRODUTOS DE SOFTWARE”,
apresentada como requisito parcial para obtenção do título de Mestre em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília, em 28 de Agosto de 2009, defendida e aprovada pela banca examinadora abaixo assinada:
Professor Doutor Paulo Sérgio Vilches Fresneda Orientador
Programa de Pós-Graduação em Gestão do Conhecimento e da Tecnologia da Informação –
UCB
Professor Doutor Fábio Bianchi Campos Co-orientador
Programa de Pós-Graduação em Gestão do Conhecimento e da Tecnologia da Informação –
UCB
Professora Doutora Rejane Maria da Costa Figueiredo Examinadora Externa
Universidade de Brasília – UNB/Faculdade do Gama – FGA
A minha esposa, por toda dedicação e paciência com que zela por nossa família, e pela coragem com que enfrenta os desafios que a vida lhe impõe.
Ao meu filho, que em dois anos de vida tanto me trouxe alegria e forças para continuar na busca por melhorar como pessoa.
A minha mãe, mulher de caráter e batalhadora.
Aos meus orientadores, Prof. Dr. Paulo Sérgio Vilches Fresneda e Prof. Dr. Fábio Bianchi Campos, por toda dedicação, apoio e compreensão nos momentos de dificuldade.
Aos professores do MGCTI por sua dedicação e competência no compartilhamento de seu conhecimento.
A equipe do MGCTI por toda atenção e carinho.
“Sessenta anos atrás eu sabia tudo, hoje sei que nada sei. A
educação é o descobrimento progressivo da nossa ignorância”
RESUMO
É um grande desafio para qualquer organização que produz software atingir um alto nível de qualidade em seu produto. Simplesmente produzir software com aspectos técnicos excelentes não é mais suficiente. Há uma grande demanda por softwares que sejam amplamente acessíveis, de fácil utilização e aprendizado e que se integrem ao ambiente de trabalho, sobretudo que sejam desenvolvidos com foco nos usuários finais.
Pode-se esbarrar em um critério muito subjetivo ao se desenvolver com direcionamento ao usuário final, que é a satisfação obtida pelo usuário no uso de determinado software. Esta satisfação nada mais é do que a percepção do usuário sobre o produto, que pode ser influenciada por alguns fatores, os quais estão relacionados com o observador, com o alvo da percepção ou com o próprio contexto de uso.
Com base nesses pressupostos, esta pesquisa buscou trabalhar dentro de uma abordagem um pouco diferente da convencional usada na avaliação de software, o que permitiu a construção de um instrumento para avaliação da satisfação de usuários finais de produtos de software, que além de identificar o nível de satisfação do usuário com determinadas características, funcionalidades e comportamentos do software avaliado, também analisa fatores externos ao software que possam impactar em sua satisfação, provendo assim, subsídios a empresa desenvolvedora do produto para que implemente melhorias direcionadas às necessidades dos usuários finais de seu software.
ABSTRACT
It is a great challenge for any organization that produces softwares to reach a high level of quality in its product. To simply produce softwares with excellent technical aspects is not enough. There is a great demand for softwares that are widely accessible, easy to use and master, integrated with the workplace and, above all, that are developed targeting at the end users.
To develop aiming the end user may trigger a very subjective criterion which is the satisfaction that the user acquired having used a given software. This satisfaction is nothing more than the perception of the user about the product, which can be influenced by some factors related to the observer, the target of the perception or the even context of use.
Based on the stated assumptions, this research worked on a different approach from the other usual software evaluation concept, which has allowed the construction of an instrument to evaluate the end users satisfaction of software products that besides identifying the level of determined satisfaction of the user with characteristics, functionalities and behaviors of the evaluated software, it also analyzes external factors to the software that can impact in its satisfaction, thus providing subsidies to the company in charge of developing the product so that it implements direct improvements to the necessities of the end users of its software.
LISTA DE FIGURAS ... 11
LISTA DE TABELAS ... 12
LISTA DE GRÁFICOS ... 14
1. INTRODUÇÃO ... 15
1.1 Contextualização da Pesquisa ... 15
1.2 Relevância do Estudo ... 16
1.3 Formulação do Problema ... 17
1.4 Objetivos ... 18
1.4.1 Geral ... 18
1.4.2 Específicos ... 18
1.5 Estruturação do Trabalho ... 19
2. REVISÃO DE LITERATURA ... 20
2.1 Qualidade de Produto de Software ... 20
2.1.1 Qualidade de Software ... 20
2.1.2 Norma ISO/IEC 9126 ... 23
2.1.3 Norma ISO/IEC 25000 ... 38
2.1.4 Norma ISO/IEC 9241-11 ... 40
2.1.5 Benefícios dos Modelos e Padrões de Qualidade de Software ... 42
2.2 Avaliação da Qualidade de Produtos de Software ... 43
2.2.1 Avaliação da Qualidade em Uso ... 46
2.2.2 Norma ISO/IEC 14598 ... 47
2.2.3 Métodos de Avaliação ... 51
2.2.4 Fidedignidade de Instrumentos de Avaliação ... 57
2.3 Conclusões do Capítulo ... 60
2.3.1 Qualidade de Produto de Software ... 60
2.3.2 Avaliação da Qualidade de Produto de Software ... 60
3. METODOLOGIA DE PESQUISA ... 62
3.1 Classificação da Pesquisa ... 62
3.2 Fontes de Informação Utilizadas ... 63
3.3 Suposições ... 64
3.4 Delimitação do Estudo ... 65
3.5 Identificação e Amostragem da População... 65
3.6 Desenvolvimento do Instrumento ... 66
3.6.1 Etapas do Desenvolvimento do Instrumento ... 68
3.6.2 O Instrumento iASUS ... 70
3.6.3 Escalas Utilizadas no Instrumento iASUS ... 77
3.7 Pesquisa de Campo ... 78
3.7.1 Teste Piloto do Instrumento iASUS ... 78
3.7.2 Aplicação da Pesquisa de Campo... 80
3.8 Tabulação e Apresentação dos Dados Coletados ... 87
3.8.1 Tipo de Gráfico Utilizado ... 87
3.8.2 Proposta para Construção dos Gráficos ... 87
3.8.3 Gráficos Propostos para Utilização na Análise ... 89
3.9 Interpretando os Dados ... 91
3.10 Fidedignidade do Instrumento iASUS ... 93
4. APRESENTAÇÃO E ANÁLISE DOS RESULTADOS ... 97
5.1 Conclusões Gerais ... 120
5.2 Suposições e Objetivos ... 122
5.3 Contribuições ... 123
5.4 Limitações ... 124
5.5 Trabalhos Futuros ... 124
REFERÊNCIAS ... 126
APÊNDICE A – INSTRUMENTO PARA AVALIAÇÃO DA SATISFAÇÃO DO USUÁRIO ... 133
APÊNDICE B – CONVITE A PARTICIPAÇÃO DO TESTE ... 136
APÊNDICE C – INSTRUÇÕES PARA REALIZAÇÃO DO TESTE ... 137
APÊNDICE D – QUESTIONÁRIO DE AVALIAÇÃO DO INSTRUMENTO DE PESQUISA ... 138
APÊNDICE E – CONVITE A PARTICIPAÇÃO DA PESQUISA – SYSOKA ... 139
APÊNDICE F – RELATÓRIO DE AVALIAÇÃO DO SOFTWARE SYSOKA ... 140
APÊNDICE G – TELAS DO QUESTIONÁRIO HOSPEDADO NO LIMESURVEY .. 156
APÊNDICE H – RELATÓRIO DE AVALIAÇÃO DO ERP P... 159
LISTA DE FIGURAS
Figura 1: Modelo de qualidade para qualidade interna e externa ... 25
Figura 2: Modelo de qualidade para qualidade em uso ... 30
Figura 3: Práticas de desenvolvimento orientado ao desenvolvedor versus orientação ao usuário ... 32
Figura 4: Medidas de qualidade em uso determinadas pelo contexto de uso ... 34
Figura 5: A qualidade no ciclo de vida do desenvolvimento de softwares ... 43
Figura 6: Relação entre as normas ISO/IEC 9126 e ISO/IEC 14598 ... 49
Figura 7: Processo de avaliação de produto de software ISO/IEC 14598-1 ... 49
Figura 8: Processo de avaliação de produto de software ISO/IEC 14598-5 ... 50
Figura 9: Fórmula de Spearman-Brown ... 59
Figura 10: Pergunta sobre o tempo de uso do software ... 72
Figura 11: Escalas para as sentenças da Parte II do Instrumento iASUS ... 77
Figura 12: Escalas para as perguntas da Parte IV do Instrumento iASUS ... 78
Figura 13: Etapas para aplicação do instrumento iASUS ... 82
Figura 14: Exemplo de Pontuação Máxima para Subcaracterística Acurácia ... 88
Figura 15: Exemplo de cálculo do percentual da Subcaracterística Acurácia ... 88
Figura 16: Exemplo de cálculo do percentual da Característica Funcionalidade ... 89
Figura 17: Exemplo do gráfico índice geral de satisfação ... 90
Figura 18: Exemplo do gráfico satisfação por Característica ... 90
Figura 19: Exemplo do gráfico satisfação por Subcaracterística ... 91
Tabela 1: Características do modelo de qualidade para qualidade interna e externa
(NBR ISO/IEC 9126-1, 2003) ... 25
Tabela 2: Subcaracterísticas da Característica Funcionalidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003) ... 26
Tabela 3: Subcaracterísticas da Característica Confiabilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003) ... 26
Tabela 4: Subcaracterísticas da Característica Usabilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003) ... 27
Tabela 5: Subcaracterísticas da Característica Eficiência do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003) ... 27
Tabela 6: Subcaracterísticas da Característica Manutenibilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003) ... 27
Tabela 7: Subcaracterísticas da Característica Portabilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003) ... 28
Tabela 8: Características do modelo de qualidade para qualidade em uso (NBR ISO/IEC 9126-1, 2003) ... 30
Tabela 9: Divisões da série SQuare (ISO/IEC 25000, 2004)... 39
Tabela 10: Resultado da pesquisa por palavras-chave ... 64
Tabela 11: Características e Subcaracterísticas utilizadas no instrumento ... 69
Tabela 12: Quantidade de sentenças por Característica e Subcaracterística ... 72
Tabela 13: Sentenças da Característica Funcionalidade ... 73
Tabela 14: Sentenças da Característica Usabilidade ... 73
Tabela 15: Sentenças da Característica Eficiência ... 74
Tabela 16: Pergunta para avaliar a satisfação com o software avaliado ... 74
Tabela 17: Comentários, críticas e/ou sugestões acerca do software avaliado ... 75
Tabela 18: Perguntas para análise de fatores externos ao software avaliado ... 76
Tabela 19: Resultado do pré-teste: avaliação do instrumento iASUS ... 79
Tabela 20: Divisão das respostas dos entrevistados e somatório dos valores – SysOKA ... 95
Tabela 21: Divisão das respostas dos entrevistados e somatório dos valores – ERP P ... 95
Tabela 22: Fidedignidade pelo coeficiente de correlação de Spearman-Brown – SysOKA ... 95
Tabela 23: Fidedignidade pelo coeficiente de correlação de Spearman-Brown – ERP P ... 95
Tabela 24: Sentenças que compõem a Subcaracterística Acurácia - SysOKA ... 97
Tabela 25: Sentenças que compõem a Subcaracterística Adequação - SysOKA... 98
Tabela 26: Sentenças que compõem a Subcaracterística Inteligibilidade - SysOKA 99 Tabela 27: Sentenças que compõem a Subcaracterística Apreensibilidade - SysOKA ... 100
Tabela 28: Sentenças que compõem a Subcaracterística Operacionalidade - SysOKA ... 100
Tabela 29: Sentenças que compõem a Subcaracterística Atratividade - SysOKA .. 102
Tabela 30: Sentenças que compõem a Subcaracterística Tempo - SysOKA ... 102
Tabela 31: Sentenças que compõem a Subcaracterística Recursos - SysOKA ... 103
Tabela 32: Satisfação dos usuários por Característica - SysOKA ... 104
Tabela 37: Sentenças que compõem a Subcaracterística Apreensibilidade - ERP P
... 111
Tabela 38: Sentenças que compõem a Subcaracterística Operacionalidade - ERP P ... 111
Tabela 39: Sentenças que compõem a Subcaracterística Atratividade - ERP P... 112
Tabela 40: Sentenças que compõem a Subcaracterística Tempo - ERP P ... 113
Tabela 41: Sentenças que compõem a Subcaracterística Recursos - ERP P ... 114
Tabela 42: Satisfação dos usuários por Característica – ERP P ... 115
Tabela 43: Fatores externos ao software avaliado – ERP P ... 115
Tabela 44: Comparação entre o instrumento iASUS e alguns métodos de avaliação ... 119
Tabela 45: Fidedignidade pelo coeficiente de correlação de Spearman-Brown – SysOKA ... 121
Tabela 46: Fidedignidade pelo coeficiente de correlação de Spearman-Brown – ERP P ... 121
LISTA DE GRÁFICOS
Gráfico 1: Satisfação dos usuários por Característica - SysOKA ... 104
Gráfico 2: Índice de satisfação na Característica Funcionalidade - SysOKA ... 106
Gráfico 3: Característica Funcionalidade: Subcaracterística Acurácia - SysOKA .... 106
Gráfico 4: Característica Funcionalidade: Subcaracterística Adequação - SysOKA 106
Gráfico 5: Satisfação dos usuários por Característica – ERP P ... 114
Gráfico 6: Índice de satisfação na Característica Funcionalidade – ERP P ... 117
Gráfico 7: Característica Funcionalidade: Subcaracterística Acurácia – ERP P... 117
1. INTRODUÇÃO
1.1 Contextualização da Pesquisa
As Tecnologias da Informação e da Comunicação - TIC tem seu uso cada vez mais diversificado e se tornaram críticas ao sucesso dos negócios, e sobretudo proporcionam as organizações apoio a tomada de decisão (LAUDON & LAUDON, 2002). Através da infinita gama de softwares disponíveis e com suas distintas aplicações, agilizam desde a simples confecção de um oficio até o controle de usinas nucleares, além de prover informação em alto nível de complexidade (CASH et al, 1992).
Este contexto faz com que organizações que busquem softwares que atendam suas necessidades tenham que efetuar uma avaliação mais criteriosa da qualidade dos mesmos, bem como as próprias empresas desenvolvedoras de tais softwares, que na tentativa de manter a continuidade de seus produtos e a fidelidade de seus clientes também necessitem avaliá-los de forma contínua. O que torna a avaliação de softwares de suma importância, uma vez que a ausência de avaliação leva os indivíduos a atuarem com base em intuições e, por diversas vezes, se mantêm cegos quanto aos seus comportamentos, tanto individuais como coletivos (ARGYRIS et al, 1985). Portanto, reforça a importância de métodos de avaliação, uma vez que com resultados expressos em números ou representados graficamente, se pode identificar com mais clareza pontos fracos e fortes em um determinado produto ou processo.
usuário final, é o produto projetado e fabricado para executar apropriadamente a função designada.
Como forma de decidir o que implementar em termos de melhorias em seu produto, o desenvolvedor de software pode lançar mão do uso de métodos de avaliação, que lhe possibilitam obter subsídios para a tomada de decisão sobre modificações que se façam necessárias em seu software, onde o uso de técnicas e ferramentas para avaliar sistematicamente uma situação devem ser empregadas, provendo assim o tomador de decisão com informações o mais completas possíveis (CLEMEN, 1996, p.46).
O usuário final de um software tem resultados a serem atingidos, e o software deve ser um instrumento capaz de prover meios para que seja realizado com eficiência e efetividade, além de lhe proporcionar satisfação com o processo e seus resultados (MAURER, 2004). Adicionalmente, Arnold (1994, p.13) define que a satisfação do cliente também faz parte da qualidade de um software, sendo de primordial importância, desenvolver ou selecionar produtos de software de alta qualidade (ISO 9126-1, 2003, p.2).
Assim, o objetivo dessa pesquisa foi identificar no segmento de Qualidade de Software fatores críticos a satisfação de usuários finais de softwares, e propor um método um pouco diferente do convencional para avaliar a qualidade do software percebida por seus usuários, construindo para tal, um instrumento que avalie a satisfação de usuários de produtos de software.
1.2 Relevância do Estudo
Na visão de muitas organizações, a melhoria do processo de construção de softwares para se adequar a contratos ou mesmo padrões internacionais está se tornando um pré-requisito para realizar negócios (DADOUN, 1992, p.433-437; BOLINGER & McGOWAN, 1991, p.25-41), mesmo assim, as necessidades dos usuários estão sendo ignoradas, porque não há um critério objetivo para identificá-las quando se está desenvolvendo ou comprando um software (BEVAN, 1999B, p.89-96).
Para melhorar a qualidade de um software, é necessário adquirir entendimento sobre o processo real de trabalho no qual ele é utilizado, incluindo não somente aspectos técnicos, mas também aspectos comportamentais e sociais (BANSLER & BODKER, 1993). Sendo que estudos tradicionais de usabilidade deixam de fora importantes aspectos do uso diário dos softwares (LINDGAARD, 1994, p.112).
Dessa forma, nota-se a relevância de se avaliar a satisfação dos usuários com seus softwares, mas, identificando também, e de forma pontual, onde está à deficiência do produto no ponto de vista de seu usuário final, beneficiando assim, a empresa desenvolvedora do software, que tomará ações direcionadas a evolução do seu produto, e de forma indireta, maximizará o retorno do investimento a empresa cliente, já que potencializa o uso da solução por seus usuários.
1.3 Formulação do Problema
Avaliar a qualidade de um software pela percepção de seus usuários finais é importante para a empresa desenvolvedora do mesmo, pois as organizações estão cada vez mais dependentes dos sistemas de informação, e, por conseguinte, seus usuários para realizarem suas tarefas (MILKOVICH & BOUDREAU, 2000, p.116-131).
(1990, p.8), poucas organizações avaliam sistematicamente a satisfação de seus usuários.
Para ilustrar a necessidade de uma avaliação constante da satisfação dos usuários finais de um produto de software, digamos que: para executar uma determinada tarefa em um software um usuário tenha que passar por cinco diferentes telas. Baseado nisso não se pode afirmar que o software tenha baixa qualidade, mas isso pode fazer com que o software seja considerado de baixa qualidade se fizer com que o usuário seja menos efetivo, menos eficiente, ou mesmo que não se sinta muito confortável com o produto. Quando questionado acerca de sua satisfação, o usuário provavelmente não será capaz de identificar exatamente onde no software ela se situa, no máximo dirá que não está confortável com o uso do software ou que realizar suas tarefas utilizando tal produto é um processo muito enfadonho.
Com base nesses pressupostos, formulou-se a seguinte questão de pesquisa: É possível construir um instrumento para avaliar a satisfação de usuários finais de softwares que forneça à organização desenvolvedora do mesmo, subsídios à melhoria de seu produto?
1.4 Objetivos
1.4.1 Geral
O objetivo geral deste trabalho é desenvolver e testar um instrumento para avaliar a satisfação de usuários finais de produtos de software.
1.4.2 Específicos
Os objetivos específicos deste trabalho de pesquisa são:
Identificar na literatura modelos, métodos e normas de avaliação de produtos de software que contemplem a perspectiva dos usuários nos critérios de avaliação;
Propor um instrumento de avaliação que permita identificar a satisfação de usuários de produtos de software;
Identificar oportunidades de melhoria no software avaliado, através da aplicação do instrumento proposto;
Propor um modelo de relatório para apresentação dos resultados obtidos da análise do software avaliado.
1.5 Estruturação do Trabalho
Este trabalho é composto de cinco capítulos. Onde o primeiro e corrente capítulo contextualiza o ambiente no qual o tema da pesquisa se insere, apresenta a questão de pesquisa e especifica os objetivos.
No Capítulo 2 será apresentada uma análise do conceito de qualidade de software e qualidade em uso na literatura, a evolução das normas no segmento de qualidade de software e modelos de qualidade que formaram a base para o instrumento proposto neste trabalho. Também apresenta métodos de avaliação da qualidade de software, qualidade em uso e usabilidade, bem como realiza uma discussão acerca dos pontos fortes e fracos encontrados nos mesmos.
O Capítulo 3 descreve os materiais e métodos utilizados para a abordagem e execução do trabalho em que constam: classificação da pesquisa; fontes de informação utilizadas; identificação e amostragem da população; principais etapas da pesquisa de campo; a construção do instrumento e a fidedignidade da pesquisa.
No Capítulo 4 são apresentados os resultados da pesquisa de campo, onde foi posto em prática o instrumento proposto no Capítulo 3, permitindo assim, avaliar sua aplicabilidade.
2. REVISÃO DE LITERATURA
Neste capítulo, apresenta-se uma revisão de literatura referente aos principais temas que envolvem o tópico da pesquisa, com destaque para: qualidade de software; normas de qualidade de software; avaliação da qualidade de produtos de software; e métodos de avaliação da qualidade de softwares.
2.1 Qualidade de Produto de Software
Uma vez que o objetivo desta dissertação é contribuir com um instrumento para avaliar a satisfação de usuários finais de produtos de software, e consequentemente a qualidade do software, torna-se importante apresentar os conceitos, definições, a evolução e destacar os modelos acerca do tema qualidade de produtos de software.
2.1.1 Qualidade de Software
O termo qualidade é freqüentemente empregado na literatura e na prática nas organizações em geral, basicamente agregando valor ou realçando propriedades de um produto ou serviço. Contudo, existem distintos enfoques acerca do seu significado em determinados contextos, de como pode ser desenvolvido, controlado e como pode afetar em particular um produto de software. Os softwares estão relacionados, de forma direta ou indireta, a quase todas as circunstâncias de nossas vidas, seja nas atividades diárias, nós negócios e até mesmo na cultura (PRESSMAN, 2000). Desenvolver softwares de qualidade é fundamental, pois sem a devida qualidade estamos sujeitos a diversas falhas, como interrupções em serviços de comunicação, transportes, energia e de saúde (JURAN, 2002).
GARVIN (1984, p.39) definiu cinco visões para qualidade:
a) Visão transcendental: esta visão vê a qualidade como alguma coisa que pode ser reconhecida, mas não definida;
b) Visão do usuário: o usuário vê a qualidade como uma
adequação para o seu propósito;
c) Visão do desenvolvedor: observa a qualidade como
conformidade a especificação;
d) Visão do produto: vê a qualidade como característica inerente ao produto;
e) Visão baseada em valor: vê a qualidade como dependente do que o consumidor está disposto a pagar;
Avaliar a qualidade de um software vai muito além da preocupação com defeitos de funcionamento (PFLEEGER, 2001; PRESSMAN, 2000). Diversas características devem ser analisadas visando à avaliação da qualidade interna e externa de produtos de software (ISO/IEC 9126-1, 2003). Porém, dependendo do tipo de software e de seu grupo de usuários, diferentes fatores podem ser mais ou menos importantes (KAN, 2002).
Para Pressman (2000), a qualidade de software deve ser implementada em todo o seu ciclo de vida. As atividades para implantação de um controle de qualidade no desenvolvimento de um software são:
Aplicação de metodologia e técnicas de desenvolvimento; Utilização de processos formais de revisão;
Teste de software;
Ajustes aos padrões de desenvolvimento; Controle de mudanças e medições;
Gestão da informação sobre o controle da qualidade.
Em um software pode-se encontrar as seguintes visões de qualidade Pressman (2000):
a) Necessária ou requerida: é a qualidade que requer o cliente;
b) Programada ou especificada: é a qualidade que foi especificada explicitamente e que se tenta conseguir;
c) Realizada: é a qualidade que se conseguiu alcançar.
O objetivo é conseguir que as três visões coincidam. A interseção entre a qualidade requerida e a qualidade realizada se chama qualidade percebida, sendo a única que o cliente dá valor. Toda a qualidade que se implementa, mas não se necessita é um gasto inútil de tempo e dinheiro.
A qualidade deixou de ser um simples modismo para se tornar parte dos produtos e serviços prestados. O cliente é o melhor avaliador da qualidade, ele exige o nível de qualidade que está disposto a pagar, portanto, se deve quantificar o nível de qualidade que é exigido para que se planeje a qualidade dos serviços ou produtos finais. Ao se analisar as necessidades dos clientes, deve-se ter em conta uma provável evolução de suas necessidades e tendências de seu negócio.
É uma grande oportunidade e um desafio para a indústria de software desenvolver estratégias que permitam um posicionamento e um reconhecimento internacional com produtos competitivos, o que irá requerer entre outras coisas, a definição e implantação de modelos ou padrões de qualidade, deixando de lado a informalidade.
A obtenção de um software com qualidade implica na utilização de métodos e procedimentos padrões para análise, desenho, programação e teste do software, a fim de uniformizar a filosofia de trabalho para que se obtenha maior confiabilidade, facilidade de manutenção e de teste, acarretando em aumento da produtividade tanto para o trabalho de desenvolvimento quanto para o controle da qualidade de produto de software, que segundo Ortega (2003, p.233) abrange os seguintes aspectos:
Qualidade interna: medida a partir de características intrínsecas do software, como o código fonte;
Qualidade externa: medida sobre o comportamento do software, como em um teste;
Qualidade em uso: medida durante a utilização do software por parte do usuário.
O objetivo não é necessariamente alcançar a qualidade perfeita, apenas a qualidade necessária e suficiente para cada contexto de uso, seja na entrega do produto, seja durante o uso por parte dos usuários (ISO/IEC 9126-1, 2003, p.5), sendo que, é necessário compreender a real necessidade dos usuários com o maior detalhe possível.
A seguir serão apresentados alguns dos principais padrões de qualidade utilizados no segmento de qualidade de produtos de software.
2.1.2 Norma ISO/IEC 9126
O marco na definição de padrões de qualidade de software destinados a avaliação se deu por volta de 1991, quando a ISO/IEC publicou o modelo de qualidade e processo de avaliação (ISO/IEC 9126, 1991). Cabe ressaltar que desde 1976 já se publicavam trabalhos que foram reconhecidos e utilizados no desenvolvimento da norma (BOHEM et al, 1976; BOHEM et al, 1978; McCALL et al, 1977), onde já se definiam modelos e estruturas de qualidade.
assumiu o nome de NBR 13596 no ano de 1996, sendo que, no ano de 2003 foi cancelada e substituída pela Norma NBR ISO/IEC 9126, sob o título geral
“Engenharia de software – Qualidade do produto”, que consiste das seguintes
partes:
Parte 1: Modelo de qualidade; Parte 2: Métricas externas; Parte 3: Métricas internas;
Parte 4: Métricas de qualidade em uso.
A NBR ISO/IEC 9126-1 (2003) especifica um modelo de qualidade do produto de software composto de duas partes: Qualidade interna e Qualidade externa; e Qualidade em uso. Ainda segundo a ISO/IEC 9126-1 (2003, p.3), o modelo pode ser utilizado, dentre outras coisas, para:
Validar a completitude de uma definição de requisitos; Identificar requisitos de software;
Identificar objetivos de projeto de software; Identificar objetivos para teste de software; Identificar critérios para garantia de qualidade;
Identificar critérios de aceitação para produtos finais de software.
2.1.2.1 Qualidade Interna e Qualidade Externa
O modelo de qualidade para qualidade interna e externa apresenta uma estrutura hierárquica que categoriza os atributos de qualidade de software em seis
características: funcionalidade, confiabilidade, usabilidade, eficiência,
manutenibilidade e portabilidade, onde cada uma dessas Características é subdividida em Subcaracterísticas, conforme demonstrado pela Figura 1.
Figura 1: Modelo de qualidade para qualidade interna e externa Fonte: NBR ISO/IEC 9126-1 (2003)
A Tabela 1 apresenta uma definição resumida das características do modelo de qualidade para qualidade interna e externa.
Tabela 1: Características do modelo de qualidade para qualidade interna e externa (NBR ISO/IEC 9126-1, 2003)
Característica Conceito Principal Objetivo
Funcionalidade
Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas
Satisfazer as necessidades
Confiabilidade Capacidade do produto de software de manter um nível de desempenho especificado, quando
usado em condições especificadas
Ser livre de falhas
Usabilidade
Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas
Ser fácil de usar
apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas
Manutenibilidade
Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais
De fácil modificação
Portabilidade Capacidade do produto de software de ser
transferido de um ambiente para outro De fácil mudança de ambiente
Cada Característica de qualidade estabelecida pela norma é desdobrada em Subcaracterísticas, para que haja possibilidade de se medir grandezas relacionadas aos produtos de software, conforme demonstrado nas Tabelas 2, 3, 4, 5, 6 e 7.
Tabela 2: Subcaracterísticas da Característica Funcionalidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003)
Funcionalidade
Adequação Capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados
Acurácia Capacidade do produto de software de prover, com grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados Interoperabilidade Capacidade do produto de software de interagir com um ou mais sistemas especificados
Segurança de acesso
Capacidade do produto de software de proteger informações e dados, de forma que pessoas ou sistemas não autorizados não possam lê-los nem modificá-los e que não seja negado o acesso às pessoas ou sistemas autorizados
Conformidade Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações previstas em leis e prescrições similares relacionadas à funcionalidade
Tabela 3: Subcaracterísticas da Característica Confiabilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003)
Confiabilidade
Maturidade Capacidade do produto de software de evitar falhas decorrentes de defeitos no software
Tolerância a falhas Capacidade do produto de software de manter um nível de desempenho especificado em casos de defeitos no software ou de violação de sua interface especificada
Recuperabilidade Capacidade do produto de software de restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha
Tabela 4: Subcaracterísticas da Característica Usabilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003)
Usabilidade
Inteligibilidade Capacidade do produto de software de possibilitar ao usuário compreender se o software é apropriado e como ele pode ser usado para tarefas e condições de uso específicas
Apreensibilidade Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação Operacionalidade Capacidade do produto de software de possibilitar ao usuário operá-lo e controlá-lo Atratividade Capacidade do produto de software de ser atraente ao usuário
Conformidade Capacidade do produto de software de estar de acordo com normas, convenções, guias de estilo ou regulamentações relacionadas à usabilidade
Tabela 5: Subcaracterísticas da Característica Eficiência do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003)
Eficiência
Comportamento em relação ao tempo
Comportamento em relação ao tempo. É a capacidade do produto de software de fornecer tempos de resposta e de processamento, além de taxas de transferência, apropriados, quando o software executa suas funções, sob condições estabelecidas
Utilização de recursos
Utilização de recursos. É a capacidade do produto de software de usar tipos e quantidade apropriados de recursos, quando o software executa suas funções sob condições estabelecidas
Conformidade Capacidade do produto de software de estar de acordo com normas e convenções relacionadas à eficiência
Tabela 6: Subcaracterísticas da Característica Manutenibilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003)
Manutenibilidade
Analisabilidade Capacidade do produto de software de permitir o diagnóstico de deficiências ou causas de falhas no software, ou a identificação de partes a serem modificadas
Tabela 7: Subcaracterísticas da Característica Portabilidade do Modelo de Qualidade (NBR ISO/IEC 9126-1, 2003)
Portabilidade
Adaptabilidade
Capacidade do produto de software de ser adaptado para diferentes ambientes especificados, sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado
Capacidade para
ser instalado Capacidade do produto de software para ser instalado em um ambiente especificado
Coexistência Capacidade do produto de software de coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns
Capacidade para substituir
Capacidade do produto de software de ser usado em substituição a outro produto de software especificado, com o mesmo propósito e no mesmo ambiente
Conformidade Capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à portabilidade
Em etapas iniciais do ciclo de vida de um software é possível medir, avaliar e controlar a qualidade interna, que foi definida pela ISO/IEC 9126-1 (2003, p.6) como:
“A totalidade das características do produto de software do ponto de vista interno. A qualidade interna é medida e avaliada com relação aos requisitos de qualidade interna. Detalhes da qualidade do produto de software podem ser melhorados durante a implementação do código, revisão e teste, mas a natureza fundamental da qualidade do produto de software representada pela qualidade interna mantém-se inalterada, a menos que seja reprojetada.”
“A totalidade das características do produto de software do ponto de vista externo. É a qualidade quando o software é executado, o qual é tipicamente medido e avaliado enquanto está sendo testado num ambiente simulado, com dados simulados e usando métricas externas. Durante os testes, convém que a maioria dos defeitos seja descoberta e eliminada. Entretanto, alguns defeitos podem permanecer após o teste. Como é difícil corrigir a arquitetura do software ou outro aspecto básico do projeto do software, a base do projeto usualmente permanece inalterada ao longo do teste.”
A relação entre qualidade interna e qualidade externa pode ser vista através do retorno dado pela avaliação da qualidade externa, que uma vez que não tenha seus requisitos atingidos, fornece subsídios para o aprimoramento dos atributos internos do software, o que leva a melhoria da qualidade externa, assim, apoiando o processo de melhoria contínua do produto de software.
Os requisitos de qualidade externa incluem os requisitos derivados das necessidades de qualidade dos usuários e são usados como meta para validação em vários estágios do desenvolvimento, inclusive podendo ser traduzidos em requisitos de qualidade interna para avaliação do produto de software.
Devido à quantidade de Subcaracterísticas do modelo para qualidade interna e externa apresentadas na Figura 1, a norma ISO/IEC 9126-1 (2003) ressalta que na prática não é possível medir todas elas em todas as partes de um produto de software de grande porte, e afirma ainda que é necessário alocar recursos entre os diferentes tipos de medições, de acordo com os objetivos do negócio e da natureza do produto e dos processos utilizados no projeto.
2.1.2.2 Qualidade em Uso
“Capacidade do produto de software de permitir que usuários especificados atinjam metas especificadas com eficácia, produtividade, segurança e satisfação em contextos de uso especificados. É a visão da qualidade do produto de software do ponto de vista do usuário.”
Os atributos de qualidade em uso são categorizados em quatro características: eficácia, produtividade, segurança e satisfação, conforme demonstrado pela Figura 2.
Figura 2: Modelo de qualidade para qualidade em uso Fonte: NBR ISO/IEC 9126-1 (2003)
A Tabela 8 apresenta uma definição resumida das Características do modelo de qualidade para qualidade em uso.
Tabela 8: Características do modelo de qualidade para qualidade em uso (NBR ISO/IEC 9126-1, 2003)
Eficácia Capacidade do produto de software de permitir que usuários atinjam metas especificadas com acurácia e completitude, em um
contexto de uso especificado
Produtividade Capacidade do produto de software de permitir que seus usuários empreguem quantidade apropriada de recursos em relação à
eficácia obtida, em um contexto de uso especificado
Segurança
Capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso especificado
Satisfação Capacidade do produto de software de satisfazer usuários, em
O conceito de qualidade em uso tem sido revisado na literatura e na prática ao longo dos anos. No que diz respeito a softwares, o conceito evoluiu acompanhando a admirável evolução da indústria desse segmento. Na opinião de alguns especialistas como Bevan (1995B), a mudança fundamental é a atenção cada vez maior que é dedicada aos usuários e ao contexto quando se avalia a qualidade de um produto de software em uso.
Em seu trabalho sobre qualidade em uso, Bevan e Azuma (1997) comparam os conceitos genéricos de qualidade percebida e qualidade em uso, indicando que usualmente a percepção da qualidade por parte dos usuários é julgada como subjetiva e inexata. Garvin (1984) afirma que os conceitos podem ser tão subjetivos quanto avaliações estéticas, e que um produto pode ter qualidade somente em relação ao propósito para o qual foi criado.
As normas ISO/IEC demonstram a importância de se considerar o ponto de vista dos usuários, e como já foi dito anteriormente, a Norma ISO/IEC 9126-1 (2003) corrobora essa abertura conceitual nas definições, proporcionando uma base para avaliações mais complexas, mas também mais amplas e adaptáveis a produtos distintos. Já que se especifica a qualidade em uso como um modelo de qualidade diferente e complementar ao modelo de qualidade de software.
Figura 3: Práticas de desenvolvimento orientado ao desenvolvedor versus orientação ao usuário Fonte: Traduzido de IBM em https://www.306.ibm.com/software/ucd
Pelo que já foi exposto em tópicos anteriores, os termos qualidade em uso e usabilidade estão relativamente próximos, haja visto que os dois termos tem sido empregados como sinônimos na comunidade de engenharia de software durante muito tempo. Em uma pesquisa onde se revisa o uso do termo usabilidade sob perspectivas distintas, como os trabalhos de Folmer e Bosch (2004) e de Bevan et al (1991), pode-se notar o surgimento do termo usabilidade sob o conceito de user friendly, ou interface amigável.
Conforme destacado por Bevan (1999A, p. 3), melhorar a qualidade em uso trará significativos benefícios as organizações, usuários finais e a sociedade, e elenca seis benefícios advindos da melhoria na qualidade em uso:
I. Melhoria na Acessibilidade: Desenvolvimento com foco no usuário final proporciona métodos e ferramentas para identificar uma gama de necessidades dos usuários, dessa forma, ajuda a definir um amplo leque de requisitos de acessibilidade, incluindo a própria interface com o usuário;
II. Aumento de Eficiência: Um software que incorpora um bom design ergonômico, que é construído de acordo com as capacidades físicas e preferências de trabalho do usuário final, proporcionará uma operação efetiva e eficiente;
III. Aumento de Produtividade: Uma boa interface para um produto bem
desenhado permitirá ao usuário se concentrar na tarefa e não na ferramenta em si;
IV. Redução de Falhas: Uma proporção significativa de falhas chamadas
“erro-humano” podem ser atribuídas a um produto com uma interface
pobre, que não está ligada diretamente as necessidades do usuário ou ao seu modelo mental para condução de uma tarefa;
V. Diminuição de Treinamentos: Um software desenvolvido com foco no usuário final pode reforçar o aprendizado, reduzindo assim esforços e tempo de treinamento; e,
VI. Aumento da Aceitação: Usuários estão mais propensos a usar e confiar em um software mais acessível, que tenha sido construído de forma que a informação seja fácil de ser encontrada e que também seja apresentada de uma maneira que seja simples de ser assimilada.
praticamente impossível conseguir esse feito, mas se forem tomados “todos” os usuários de um determinado contexto, é amplamente possível desenvolver um software com alto nível de qualidade em uso que permita que usuários especificados atinjam metas especificadas com eficácia, produtividade, segurança e satisfação em contextos de uso especificados.
2.1.2.2.1 Contexto de Uso
A qualidade em uso é determinada não somente pelo produto de software, mas também pelo contexto em que o software é usado. A norma ISO/IEC 9126-1 (2003) define contexto de uso como sendo os usuários, tarefas, hardware, software e o ambiente tanto físico quanto social em que um produto é utilizado. Tal interação pode ser vista na Figura 4.
A Figura 4 ilustra que a qualidade em uso, medida pela eficácia, produtividade, segurança e satisfação é o resultado da interação entre usuário e produto enquanto realizam uma tarefa nos ambientes técnicos, físicos, sociais e organizacionais (BEVAN, 1995A).
A importância do contexto está em que conclusões sobre qualquer avaliação podem não ser válidas se o contexto não é especificado corretamente, ou se o mesmo produto é avaliado em contextos diferentes, o que faz com que os resultados não possam ser comparáveis (BEVAN & McLEOD, 1994, p.132-145).
A ISO/IEC 9126-1 (2003, p. 5) ressalta que é necessário entender as reais necessidades do usuário, tão detalhadamente quanto possível e representá-las nos requisitos do software. Embora, a finalidade não é, necessariamente, atingir a qualidade perfeita, mas sim a qualidade necessária e suficiente para cada contexto de uso especificado quando o produto for entregue e utilizado pelos usuários finais.
Além de um desenvolvimento direcionado a um contexto específico, para usuários específicos com metas específicas, a avaliação da qualidade em uso também deve levar em conta medidas subjetivas para avaliar características como a satisfação do usuário ao usar um software. Medições subjetivas estão sujeitas a julgamentos pessoais, o que uma pessoa considera bom, outra pode considerar ruim, o que leva a dificuldades na obtenção de um consenso, por isso é importante reconhecer que medidas subjetivas podem ser úteis, desde que se entendam suas imprecisões (NORMAN & FENTON, 1997).
2.1.2.3 Métricas
De acordo com Daskalantonakis (1992) as métricas de software devem ser:
Simples de entender;
Definidas com precisão a fim de facilitar a consistência do cálculo e da análise dos valores das métricas;
Serem objetivas a fim de diminuir a influência de julgamentos pessoais, tanto para o cálculo quanto para a análise dos valores das métricas; Ter uma boa relação custo benefício afim de que se tenha um retorno
positivo sobre o investimento (o valor da informação obtida deve ser superior ao custo dos dados coletados, calculando a métrica e analisando seu valor);
Informativas, a fim de assegurar que os valores tenham interpretação significativa.
Métricas de qualidade em uso medem o quanto um produto atende às necessidades de usuários especificados para que atinjam metas especificadas com eficácia, produtividade, segurança e satisfação em um contexto de uso especificado (ISO/IEC 9126-1, 2003, p. 14).
A característica Satisfação do modelo de qualidade envolve critérios subjetivos como conforto e aceitação no uso do software. Um exemplo de métricas para avaliar a satisfação dos usuários poderia ser o percentual de comentários negativos e positivos sobre o software ou problemas de saúde relatados durante seu uso (ISO/IEC 9126-4, 2002, p. 39). Medirir qualidade em uso proporciona benefícios que podem ser usados para:
Predizer, assegurar e melhorar a qualidade de um software; Controlar e melhorar o processo de produção;
Decidir sobre a aceitação de um software;
Selecionar um software entre outros produtos alternativos.
processo de medição, a atividade que, empregando a definição da métrica permite obter os valores das medidas (BACHE & BAZZANA, 1994).
As Características do modelo de qualidade possuem atributos, como por exemplo, “Eficácia da Tarefa” e “Completitude da Tarefa”, ambos relacionados a Característica Eficácia. Por sua vez, dado atributo é mensurável se está quantificado por meio de uma métrica apropriada e adequadamente definida. Para o atributo
“Completitude da Tarefa” foi elaborada uma métrica indireta denominada “Proporção
de Tarefas Completadas Corretamente”, que permite saber qual a proporção de uma tarefa foi completada corretamente por um usuário (ISO/IEC 9126-4, 2002).
A Norma ISO/IEC 9126-4 (2002) propõe um conjunto de métricas relacionadas a cada uma das quatro Características do modelo de qualidade para qualidade em uso, com o objetivo de avaliar a qualidade em uso de um produto de software. Tais métricas têm o objetivo de medir os atributos de qualidade em uso, que segundo a própria Norma não constituem um conjunto exaustivo de métricas, sendo que, os responsáveis pela gestão da qualidade, quer sejam os compradores, os desenvolvedores ou os avaliadores, podem modificá-las ou mesmo adicionar outras, de acordo com a necessidade de cada avaliação (ISO/IEC 9126-4, 2002).
Em teoria estas métricas são aplicáveis a qualquer produto de software, embora nem todas sejam aplicáveis a qualquer classe de produto. Mesmo assim não são atribuidas faixas de valores as métricas a níveis pré-estabelecidos para cumprimento, pois considera-se que esses valores devem ser definidos para cada produto de software de acordo a sua natureza ou contexto organizacional (ISO/IEC 9126-4, 2002).
válida dividida pela quantidade de respostas válidas, indicará o grau de satisfação para o grupo de usuários participantes da pesquisa (KAN, 2002).
Uma vez que o objetivo deste trabalho é avaliar a satisfação de usuários, mas direcionando os possíveis problemas e melhorias encontrados no software, para as Características e Subcaracterísticas do modelo de qualidade para qualidade interna e externa, não serão estabelecidas métricas como é sugerido pela Norma, uma vez que não se encaixam no instrumento proposto.
2.1.3 Norma ISO/IEC 25000
A criação de uma nova série de padrões, a ISO/IEC 25000, foi um esforço para harmonizar as normas ISO/IEC 9126 e ISO/IEC 14598 (ISO/IEC 25000, 2004).
A norma também chamada de SQuaRE – Software Product Quality Requirements
and Evaluation, contém um modelo de qualidade de software genérico, que pode ser aplicado a qualquer produto de software adaptado a um propósito específico.
O objetivo geral para a criação da SQuaRE foi cobrir os processos de especificação de requisitos de qualidade de software e avaliação da qualidade de software, com o apoio de processos de medição de qualidade. Inclui também um modelo de qualidade para alinhar as definições de qualidade dos clientes com os atributos de qualidade do processo de desenvolvimento. Além de proporcionar medidas recomendadas para os atributos de qualidade dos sistemas de software que podem ser utilizados pelos desenvolvedores, adquirentes e avaliadores (ISO/IEC 25000, 2004).
Suryn et al (2003) citam alguns benefícios encontrados em relação aos antecessores da ISO/IEC 25000:
Orientação para a especificação de requisitos de qualidade dos produtos de software;
Harmonização com a Norma ISO/IEC 15939, em forma de modelo de referência na medição da qualidade do produto apresentado na Norma ISO/IEC 25020;
Introdução de elementos de medidas de qualidade dentro da divisão de medição da qualidade;
Propõe uma qualidade final através de avaliações intermediárias;
Permite realizar um rastreamento entre as expectativas, requisitos e medidas de avaliação.
A série SQuaRE está dividida em 5 partes, conforme pode ser visto na Tabela 9.
Tabela 9: Divisões da série SQuare (ISO/IEC 25000, 2004)
Norma Divisão Descrição
ISO/IEC 2500n Gestão de Qualidade
Define todos os modelos, termos e definições comuns a série SQuaRE. Direcionamento aos usuários sobre os documentos da série, bem como sugestões para ajudá-los na aplicação da Norma adequada a aplicações específicas.
ISO/IEC 2501n Modelo de Qualidade
Esta divisão inclui um modelo de qualidade detalhado, baseado na ISO/IEC 9126, compreendendo características de qualidade interna e externa, e qualidade em uso. O modelo também decompõe tais Características em Subcaracterísticas. Esta divisão também inclui um modelo de qualidade de dados.
ISO/IEC 2502n Medição da Qualidade
Esta divisão inclui um modelo de referência para medir a qualidade de um produto de software, definições matemáticas das medidas de qualidade e um guia prático para sua aplicação. Estas medidas se aplicam tanto a qualidade interna e externa quanto a qualidade em uso.
ISO/IEC 2503n Requisitos de Qualidade
Apóia na identificação e especificação de requisitos de qualidade. Os desenvolvedores podem usar esses requisitos de qualidade para levantar e definir requisitos de qualidade para o produto de software que venha a ser desenvolvido ou como entrada para um processo de avaliação.
ISO/IEC 2504n Avaliação da Qualidade
Estas normas contêm os requisitos, recomendações e guias para avaliação de produtos de software, quer seja realizado por desenvolvedores, adquirentes ou avaliadores. Esta divisão se baseia na série de normas ISO/IEC 14598.
2.1.4 Norma ISO/IEC 9241-11
A Norma ISO 9241-11 (1998) estabelece orientações sobre usabilidade, atributos de usabilidade e objetivos dos testes de usabilidade, e fazem parte do conjunto de normas da série ISO 9241, que versa sobre ergonomia de softwares de escritórios. Essa norma trata dos benefícios de medir-se a usabilidade em termos de performance e satisfação do usuário, que são medidas pela extensão com que as metas pretendidas são alcançadas, pelos recursos a serem gastos para alcançar as metas e pela extensão com que os usuários avaliam o produto como aceitável.
A ISO 9241-11 (1998) define usabilidade como:
“A eficiência, a eficácia e a satisfação com as quais determinados usuários realizam determinadas tarefas em um determinado contexto de uso.”
Está definição destaca que a usabilidade não é uma propriedade isolada do produto, mas que depende de quem o está utilizando, com quais objetivos e em que contexto de uso ou ambiente o produto está sendo utilizado.
Hiltunen (2002) destaca três componentes que considera exercerem grande influência na opinião geral do usuário sobre um produto: a disponibilidade, ou seja, o serviço deve estar sempre online e funcionando perfeitamente; a aparência deve ser agradável e atraente; e todo o processo offline deve ser eficiente. Neste último componente o autor inclui vários elementos que estão na retaguarda do serviço oferecido, como por exemplo o apoio ao usuário.
Cato (2001, p.29) sugere os seguintes atributos para garantir a usabilidade de um produto:
Controle: os usuários devem sentir-se no controle da aplicação e não ao contrário;
Habilidades: os usuários devem sentir que o software os apóia, complementa e realça suas habilidades;
Privacidade: o software ajuda os usuários a proteger sua informação e/ou de seus clientes;
Para um usuário final a usabilidade de um software é essencial, porque influencia na sua produtividade e satisfação (DIX et al, 2004, p.103), possibilitando-lhe executar tarefas com mais eficiência e efetividade. Para a gerência, a usabilidade é um fator de decisão importante, particularmente para selecionar um produto, uma vez que pode ter influência direta na produtividade da empresa. Para o desenvolvedor de software, a usabilidade pode ser descrita em termos de atributos internos do software que afetarão a produtividade do usuário (MAYHEW, 1999, p.29).
Para se referir a mesma característica de usabilidade, são utilizados diferentes termos, como a ISO 9241-11 (1998) que define aprendizado como um simples sub-atributo do tempo de aprendizado, enquanto a ISO 9126-1 (2003) o define como um fator independente de qualidade, que pode ser decomposto em diversos atributos.
O conceito de usabilidade está imerso no que é chamado Interação
Homem-Máquina, ou simplesmente HCI – Human Computer Interaction, que é uma disciplina
relacionada com o desenho, a avaliação e a implementação de sistemas para uso humano e o estudo dos fenômenos que o cercam. O HCI se incumbe do desenho de sistemas de informação que se ajustem as necessidades das pessoas, usando conhecimento, métodos e disciplinas muito diferentes, como: informática, psicologia, ciências sociais e ergonomia.
máquinas, algoritmos e programação específica, implementação de interfaces e aspectos de engenharia aplicada a interfaces (ANDREWS, 2003). Seus objetivos principais são a usabilidade, segurança e funcionalidade. Alguns atributos de usabilidade são:
Consistência e padrões: os usuários não têm que adivinhar que diferentes palavras, situações ou ações significam a mesma coisa;
Evitar erros: o desenvolvimento cuidadoso que previna problemas é melhor que boas mensagens de erro;
Interface minimalista: não apresentar informação que não seja relevante. Cada informação adicional compete com informação importante e diminui sua visibilidade;
Reconhecer, diagnosticar e recuperar-se de erros: para ajudar os usuários, as mensagens de erro devem ser apresentadas em linguagem simples e indicar o problema de forma precisa;
Ajuda e documentação: deve ser fácil de encontrar, direcionada as tarefas dos usuários, breve e objetiva.
2.1.5 Benefícios dos Modelos e Padrões de Qualidade de Software
A maioria dos processos de desenvolvimento de software foca exclusivamente nas especificações técnicas (BEVAN, 1999A, p.2), fazendo com que a maioria dos usuários de softwares de negócio sejam produtivos em somente 30-40% do tempo, sendo que 60-70% do tempo é gasto com o entendimento de como usar o software ou se restabelecer de erros (MACLEOD et al, 1997). Desta forma, Juran (2002) elenca alguns benefícios de se implementar modelos ou padrões de qualidade:
Tornar a empresa de software mais competitiva; Reduzir os custos de todo o processo de software; Garantir a satisfação dos clientes internos e externos; Ter produtos de software e serviços com valor agregado;
Oportunidade para corrigir os processos de software que tenha se desajustado com o tempo;
Gerar uma cultura organizacional imbuída em cumprir os requisitos dos clientes;
Obter certificações requeridas para competir em todos os mercados; Realizar uma melhoria continua na qualidade dos processos de
software e serviços;
Ter critérios de medição e indicadores apropriados que possam ser utilizados por toda a organização para comparar as melhores práticas de mercado;
Identificar as forças e fraquezas da organização.
2.2 Avaliação da Qualidade de Produtos de Software
A avaliação da qualidade é um exame sistemático do quanto uma entidade é capaz de atender os requisitos especificados (ISO/IEC 14598-1, 1999). Avaliar a qualidade de um produto de software é necessário para: identificar e compreender os motivos técnicos para possíveis deficiências e limitações do produto; comparar produtos; e preparar um plano de ação para evolução do produto de software, onde tal avaliação consiste na investigação de um produto final resultante de um processo de desenvolvimento de software, ou de produtos advindos de atividades de fases intermediárias desse processo (SCOPE, 1993).
A qualidade de um software deve ser avaliada durante o seu processo de desenvolvimento, e em seguida, deve ser avaliado o produto gerado e, finalmente, o produto em uso, pois a qualidade do processo influencia a qualidade do produto. A Figura 5 demonstra a qualidade no ciclo de vida do desenvolvimento de softwares:
Conforme apresentado na Figura 5, existe uma relação de dependência e influência entre qualidade interna, qualidade externa e qualidade em uso, sendo que, a qualidade em uso tem uma dependência externa ao produto de software, que é o contexto em que o mesmo está sendo utilizado. A qualidade em uso pode ser influenciada por fatores externos, os quais estão relacionados com o observador, com o alvo da percepção ou com o próprio contexto de uso do produto.
De acordo com a Norma ISO/IEC 14598 (2001), dentro das características desejáveis para qualquer processo sistemático de avaliação, quatro tem caráter obrigatório: ser repetível, reproduzível, imparcial e objetiva. Embora não indique uma técnica ou procedimento específico que deva ser empregado, especifica claramente cinco atividades que devem ser consideradas pelos avaliadores:
I. Estabelecer os requisitos de avaliação;
II. Especificar a avaliação com base nos requisitos de avaliação e sobre a descrição do produto fornecida por quem solicitou a avaliação;
III. Desenhar um plano de avaliação baseado na especificação da avaliação, sendo que, deve-se levar em conta os componentes do software a ser avaliado, os métodos e ferramentas propostos pelo avaliador;
IV. Executar o plano de avaliação, que consiste em inspecionar, modelar, medir e testar o produto e seus componentes conforme o plano;
V. Concluir a avaliação, que consiste na entrega do relatório de avaliação e a destruição ou desinstalação, por parte do avaliador, tanto do produto quanto de seus componentes, quando esses tiverem sido enviados apenas para a avaliação.
Também é importante fazer referência a Norma ISO/IEC 14598-5 (1998), que estava inserida originalmente na ISO/IEC 9126 (1991), que tem como objetivo principal prover uma base de avaliação genérica e abstrata, que permitisse aos avaliadores juntamente com os desenvolvedores, compradores, vendedores e usuários em geral, expressar requisitos de qualidade seguindo o modelo de qualidade definido na Norma ISO/IEC 9126-1 (2001).
Conforme abordado pela Norma ISO/IEC 14598-4, as características esperadas de um processo de avaliação devem ser:
Repetíveis: a avaliação de um mesmo produto quanto repetida dentro das mesmas especificações de avaliação, e sendo realizada pelo mesmo avaliador, deve produzir resultados que podem ser aceitos como iguais;
Reprodutíveis: a avaliação de um mesmo produto quando repetida dentro das mesmas especificações de avaliação, e sendo realizada por um avaliador diferente, deve produzir resultados que podem ser aceitos como iguais;
Imparciais: a avaliação não deve ser influenciada por nenhum fator particular;
Objetivas: os resultados da avaliação devem ser baseados em fatos e não ser influenciados por sentimentos ou opinião pessoal do avaliador.
De acordo com Bache e Bazzana (1994, p. 115-111) o processo de avaliação da qualidade de um produto de software é composto de procedimentos para medições em uso, incluindo métodos como:
Análise estática: verificação da documentação do usuário e etc;
Análise dinâmica: teste de integração, teste de desempenho e etc.
objetivam definir as características de um software, com intuito de permitir a análise de seu atendimento (AZEVEDO, 1998).
Para o objetivo deste trabalho, que é construir um instrumento para avaliar a satisfação de usuários finais de softwares, e por conseqüência a qualidade em uso do produto e, também fornecer subsídios ao desenvolvedor do software para a melhoria contínua de seu produto, nos próximos tópicos serão tratados temas mais específicos quanto à abordagem pretendida para o trabalho.
2.2.1 Avaliação da Qualidade em Uso
Como já se discutiu nos capítulos anteriores, o conceito de qualidade quanto a produtos de software não é absoluto e nem pode ser limitado por uma única perspectiva. A idéia por trás desta discussão é que um produto de software não deve cumprir apenas com requisitos implícitos e explícitos de seu desenvolvimento, mas principalmente com as expectativas de usuários específicos em contextos de uso definidos. Implicando em que, qualquer que seja a perspectiva que se queira medir, interna, externa ou em uso, a qualidade não pode ser medida diretamente, ou seja, de modo simples e direto (OLSINA et al, 2005B).
Vale ressaltar que a avaliação de qualidade em uso de um produto de software se realiza sobre um produto já pronto. Portanto, é necessário empregar um contexto real de trabalho em que o software será utilizado, levar em conta o perfil dos usuários que utilizarão tal software, equipamentos utilizados e as tarefas a serem realizadas. Tal avaliação acaba por se tornar uma avaliação orientada a tarefas, uma vez que é necessário avaliar o quão eficientes, produtivos, seguros e satisfeitos estão os usuários ao utilizarem o software em um contexto de uso específico.
avaliação da qualidade em uso deve objetivar a efetividade, produtividade, segurança e satisfação do usuário acerca do produto.
Uma avaliação completa da qualidade em uso é atingida através de múltiplas sessões de avaliação. Cada contexto de uso e cada grupo de usuários alvo devem ser incluídos para que se tenha uma representação completa da qualidade em uso do produto, embora isso não seja possível na maioria das situações de desenvolvimento. Progressivamente os softwares estão ampliando seus grupos de usuários, e muitas vezes somente é possível incluir um pequeno grupo durante os testes de avaliação, devido à limitação de recursos. Um típico processador de textos não é usado somente por secretárias e escritores, mas também por estudantes e famílias, e mesmo sendo possível identificar e avaliar os principais contextos de uso, a avaliação não é realizada devido ao tempo e custo associados (BEVAN, 2002).
2.2.2 Norma ISO/IEC 14598
A Norma ISO/IEC 14598 (1999) apresenta uma visão geral dos processos de avaliação de produtos de software e fornece guias para avaliação, baseados na utilização prática da norma ISO/IEC 9126. Está organizada em diferentes objetivos de avaliação, segundo o ponto de vista do desenvolvedor, do adquirente e do avaliador independente. Esta Norma está dividida em seis partes:
1) ISO/IEC 14598-1: Visão geral;
2) ISO/IEC 14598-2: Planejamento e Gerenciamento; 3) ISO/IEC 14598-3: Processo para desenvolvedores; 4) ISO/IEC 14598-4: Processo para compradores; 5) ISO/IEC 14598-5: Processo para avaliadores;
6) ISO/IEC 14598-6: Documentação dos módulos de avaliação.
Apoiado na Norma ISO/IEC 14598-1 (1999), Bevan (2002) também definiu a qualidade em uso como:
