PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA STRICTO SENSU EM GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA INFORMAÇÃO. Mestrado

Transcrição

1 PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA STRICTO SENSU EM GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA INFORMAÇÃO Mestrado 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

2 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 Brasília 2009

3 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 Brasília 2009

4 A minha família, meu porto seguro!

5 AGRADECIMENTOS 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. Aos meus amigos e todos aqueles que de forma direta ou indireta me ajudaram e me incentivaram na conclusão deste projeto.

6 Sessenta anos atrás eu sabia tudo, hoje sei que nada sei. A educação é o descobrimento progressivo da nossa ignorância William James Durant

7 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. Palavras-Chave: Qualidade de Software; Qualidade em Uso; Satisfação do Usuário; Método de Avaliação; Instrumento de Avaliação

8 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. Keywords: Software Quality; Quality in Use; User Satisfaction; Evaluation Method; Evaluation Instrument.

9 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE GRÁFICOS INTRODUÇÃO Contextualização da Pesquisa Relevância do Estudo Formulação do Problema Objetivos Geral Específicos Estruturação do Trabalho REVISÃO DE LITERATURA Qualidade de Produto de Software Qualidade de Software Norma ISO/IEC Norma ISO/IEC Norma ISO/IEC Benefícios dos Modelos e Padrões de Qualidade de Software Avaliação da Qualidade de Produtos de Software Avaliação da Qualidade em Uso Norma ISO/IEC Métodos de Avaliação Fidedignidade de Instrumentos de Avaliação Conclusões do Capítulo Qualidade de Produto de Software Avaliação da Qualidade de Produto de Software METODOLOGIA DE PESQUISA Classificação da Pesquisa Fontes de Informação Utilizadas Suposições Delimitação do Estudo Identificação e Amostragem da População Desenvolvimento do Instrumento Etapas do Desenvolvimento do Instrumento O Instrumento iasus Escalas Utilizadas no Instrumento iasus Pesquisa de Campo Teste Piloto do Instrumento iasus ção da Pesquisa de Campo Tabulação e Apresentação dos Dados Coletados Tipo de Gráfico Utilizado Proposta para Construção dos Gráficos Gráficos Propostos para Utilização na Análise Interpretando os Dados Fidedignidade do Instrumento iasus APRESENTAÇÃO E ANÁLISE DOS RESULTADOS Satisfação dos Usuários: software SysOKA... 97

10 4.2 Satisfação dos Usuários: ERP P Análise Comparativa dos Modelos CONCLUSÕES Conclusões Gerais Suposições e Objetivos Contribuições Limitações Trabalhos Futuros REFERÊNCIAS APÊNDICE A INSTRUMENTO PARA AVALIAÇÃO DA SATISFAÇÃO DO USUÁRIO APÊNDICE B CONVITE A PARTICIPAÇÃO DO TESTE APÊNDICE C INSTRUÇÕES PARA REALIZAÇÃO DO TESTE APÊNDICE D QUESTIONÁRIO DE AVALIAÇÃO DO INSTRUMENTO DE PESQUISA APÊNDICE E CONVITE A PARTICIPAÇÃO DA PESQUISA SYSOKA APÊNDICE F RELATÓRIO DE AVALIAÇÃO DO SOFTWARE SYSOKA APÊNDICE G TELAS DO QUESTIONÁRIO HOSPEDADO NO LIMESURVEY APÊNDICE H RELATÓRIO DE AVALIAÇÃO DO ERP P APÊNDICE I CONVITE A PARTICIPAÇÃO DA PESQUISA ERP P

11 LISTA DE FIGURAS Figura 1: Modelo de qualidade para qualidade interna e externa Figura 2: Modelo de qualidade para qualidade em uso Figura 3: Práticas de desenvolvimento orientado ao desenvolvedor versus orientação ao usuário Figura 4: Medidas de qualidade em uso determinadas pelo contexto de uso Figura 5: A qualidade no ciclo de vida do desenvolvimento de softwares Figura 6: Relação entre as normas ISO/IEC 9126 e ISO/IEC Figura 7: Processo de avaliação de produto de software ISO/IEC Figura 8: Processo de avaliação de produto de software ISO/IEC Figura 9: Fórmula de Spearman-Brown Figura 10: Pergunta sobre o tempo de uso do software Figura 11: Escalas para as sentenças da Parte II do Instrumento iasus Figura 12: Escalas para as perguntas da Parte IV do Instrumento iasus Figura 13: Etapas para aplicação do instrumento iasus Figura 14: Exemplo de Pontuação Máxima para Subcaracterística Acurácia Figura 15: Exemplo de cálculo do percentual da Subcaracterística Acurácia Figura 16: Exemplo de cálculo do percentual da Característica Funcionalidade Figura 17: Exemplo do gráfico índice geral de satisfação Figura 18: Exemplo do gráfico satisfação por Característica Figura 19: Exemplo do gráfico satisfação por Subcaracterística Figura 20: Níveis de pontuação para as medidas... 93

12 LISTA DE TABELAS Tabela 1: Características do modelo de qualidade para qualidade interna e externa (NBR ISO/IEC , 2003) Tabela 2: Subcaracterísticas da Característica Funcionalidade do Modelo de Qualidade (NBR ISO/IEC , 2003) Tabela 3: Subcaracterísticas da Característica Confiabilidade do Modelo de Qualidade (NBR ISO/IEC , 2003) Tabela 4: Subcaracterísticas da Característica Usabilidade do Modelo de Qualidade (NBR ISO/IEC , 2003) Tabela 5: Subcaracterísticas da Característica Eficiência do Modelo de Qualidade (NBR ISO/IEC , 2003) Tabela 6: Subcaracterísticas da Característica Manutenibilidade do Modelo de Qualidade (NBR ISO/IEC , 2003) Tabela 7: Subcaracterísticas da Característica Portabilidade do Modelo de Qualidade (NBR ISO/IEC , 2003) Tabela 8: Características do modelo de qualidade para qualidade em uso (NBR ISO/IEC , 2003) Tabela 9: Divisões da série SQuare (ISO/IEC 25000, 2004) Tabela 10: Resultado da pesquisa por palavras-chave Tabela 11: Características e Subcaracterísticas utilizadas no instrumento Tabela 12: Quantidade de sentenças por Característica e Subcaracterística Tabela 13: Sentenças da Característica Funcionalidade Tabela 14: Sentenças da Característica Usabilidade Tabela 15: Sentenças da Característica Eficiência Tabela 16: Pergunta para avaliar a satisfação com o software avaliado Tabela 17: Comentários, críticas e/ou sugestões acerca do software avaliado Tabela 18: Perguntas para análise de fatores externos ao software avaliado Tabela 19: Resultado do pré-teste: avaliação do instrumento iasus Tabela 20: Divisão das respostas dos entrevistados e somatório dos valores SysOKA Tabela 21: Divisão das respostas dos entrevistados e somatório dos valores ERP P Tabela 22: Fidedignidade pelo coeficiente de correlação de Spearman-Brown SysOKA Tabela 23: Fidedignidade pelo coeficiente de correlação de Spearman-Brown ERP P Tabela 24: Sentenças que compõem a Subcaracterística Acurácia - SysOKA Tabela 25: Sentenças que compõem a Subcaracterística Adequação - SysOKA 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 Tabela 28: Sentenças que compõem a Subcaracterística Operacionalidade - SysOKA Tabela 29: Sentenças que compõem a Subcaracterística Atratividade - SysOKA Tabela 30: Sentenças que compõem a Subcaracterística Tempo - SysOKA Tabela 31: Sentenças que compõem a Subcaracterística Recursos - SysOKA Tabela 32: Satisfação dos usuários por Característica - SysOKA Tabela 33: Fatores externos ao software avaliado - SysOKA

13 Tabela 34: Sentenças que compõem a Subcaracterística Acurácia - ERP P Tabela 35: Sentenças que compõem a Subcaracterística Adequação - ERP P Tabela 36: Sentenças que compõem a Subcaracterística Inteligibilidade - ERP P. 109 Tabela 37: Sentenças que compõem a Subcaracterística Apreensibilidade - ERP P Tabela 38: Sentenças que compõem a Subcaracterística Operacionalidade - ERP P Tabela 39: Sentenças que compõem a Subcaracterística Atratividade - ERP P Tabela 40: Sentenças que compõem a Subcaracterística Tempo - ERP P Tabela 41: Sentenças que compõem a Subcaracterística Recursos - ERP P Tabela 42: Satisfação dos usuários por Característica ERP P Tabela 43: Fatores externos ao software avaliado ERP P Tabela 44: Comparação entre o instrumento iasus e alguns métodos de avaliação Tabela 45: Fidedignidade pelo coeficiente de correlação de Spearman-Brown SysOKA Tabela 46: Fidedignidade pelo coeficiente de correlação de Spearman-Brown ERP P Tabela 47: Resultado do pré-teste: avaliação do instrumento iasus

14 LISTA DE GRÁFICOS Gráfico 1: Satisfação dos usuários por Característica - SysOKA Gráfico 2: Índice de satisfação na Característica Funcionalidade - SysOKA Gráfico 3: Característica Funcionalidade: Subcaracterística Acurácia - SysOKA 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 Gráfico 6: Índice de satisfação na Característica Funcionalidade ERP P Gráfico 7: Característica Funcionalidade: Subcaracterística Acurácia ERP P Gráfico 8: Característica Funcionalidade: Subcaracterística Adequação ERP P.. 117

15 15 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. Especificação e avaliação da qualidade do produto de software são fatores chave para garantir a qualidade adequada de um software. É importante que cada característica relevante de qualidade do produto de software seja especificada e avaliada, utilizando, sempre que possível, métricas validadas ou amplamente aceitas (ISO , 2003, p.2). A qualidade de um produto é o quanto ele satisfaz seus requisitos, mas, mesmo que um produto seja fruto de um esboço que não tenha requisitos apropriados, ainda assim pode ser um produto de alta qualidade (GARVIN, 1984, p.25), o que é chamado qualidade de produção. Para Hutchins (1994, p.75), a qualidade é a adequação ao uso, é a conformidade às exigências do

16 16 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 , 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 Rotineiramente utiliza-se a palavra qualidade como um atributo para comparar um produto ou serviço e definir se é de alta ou baixa qualidade, mas pouco se atenta ao fato de ser uma avaliação vaga, que conforme colocado por Kitchenharn e Pfleeger (1996, p.12-21), é difícil de definir, impossível de medir e fácil de reconhecer. Embora o termo qualidade possa parecer auto-explicativo, na prática existem diferentes visões do que realmente significa e como a qualidade deve ser alcançada como parte de um processo de software (OLSINA et al, 2005A, p.42-52).

17 17 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 ; 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 ). Isso faz com que o desenvolvedor tenha que prover uma aplicação capaz de atender as expectativas de seus clientes, visando garantir a satisfação dos usuários finais, bem como a continuidade de seu produto, tornando necessário à avaliação do software junto a seus usuários finais, pois conforme colocado por Conrath e Mignen

18 18 (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 Geral O objetivo geral deste trabalho é desenvolver e testar um instrumento para avaliar a satisfação de usuários finais de produtos de software 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; Empregar o instrumento para avaliar sua aplicabilidade prática;

19 19 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. No Capítulo 5 são apresentadas as conclusões finais deste trabalho de pesquisa, os benefícios do instrumento proposto e as questões que ainda necessitam ser aprofundadas em trabalhos futuros.

20 20 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 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). A NBR (1996) define que qualidade de software é a totalidade das características de um produto de software, que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas. Para Cavano e McCall (1978) determinar a qualidade de um software é um fator chave, contudo, este tipo de julgamento é muito subjetivo e não há um conhecimento absoluto sobre isso, não devendo se esperar medir a qualidade de um software com exatidão, até porque o comportamento do mesmo é determinado por suas regras de entrada e saída (STEWARD, 1981, p.78-89).

21 21 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 , 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: çã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. A qualidade de um software é o conjunto de qualidades que o caracterizam e que determinam sua utilidade e existência, a qual busca o equilíbrio entre eficiência, confiabilidade, facilidade de manutenção, portabilidade, facilidade de uso, segurança e integridade.

22 22 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. Os modelos de qualidade são aqueles documentos que integram a maior parte das melhores práticas, propõe temas de administração em que cada organização deve enfatizar, integram diferentes práticas direcionadas aos processos chave e permitem medir os avanços em qualidade (ORTEGA, 2003). Quanto aos padrões de qualidade, Ortega (2003) sustenta que eles permitem definir um conjunto de critérios de desenvolvimento que direcionam a forma em que se aplica a engenharia de softwares. Os padrões provêem meios para que todos os processos se realizem da mesma forma e são um guia para que se obtenha produtividade e qualidade.

23 23 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 , 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 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. A Norma ISO/IEC 9126 (1991) teve o mérito de estabelecer um modelo básico de qualidade de produto de software, transformando-a em referência conhecida pela maioria da comunidade de qualidade de software. A versão brasileira

24 24 assumiu o nome de NBR 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 (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 (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. No modelo de qualidade a qualidade do produto de software pode ser especificada e avaliada sob diferentes perspectivas pelos envolvidos com aquisição, requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia da qualidade e auditoria de software. O modelo pode ser utilizado por desenvolvedores, adquirentes, pessoal de garantia de qualidade e avaliadores independentes, especialmente os responsáveis por especificar e avaliar qualidade do produto de software (ISO/IEC , 2003).

25 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 (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 , 2003) Característica Funcionalidade Confiabilidade Usabilidade Conceito 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 Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas Objetivo Principal Satisfazer as necessidades Ser livre de falhas Ser fácil de usar Eficiência Capacidade do produto de software de Ser rápido

26 26 Manutenibilidade Portabilidade apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas 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 Capacidade do produto de software de ser transferido de um ambiente para outro De fácil modificação 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 , 2003) Funcionalidade Adequação Acurácia Interoperabilidade Segurança de acesso Conformidade Capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados Capacidade do produto de software de prover, com grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados Capacidade do produto de software de interagir com um ou mais sistemas especificados 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 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 , 2003) Confiabilidade Maturidade Tolerância a falhas Recuperabilidade Conformidade Capacidade do produto de software de evitar falhas decorrentes de defeitos no software 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 Capacidade do produto de software de restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações relacionadas à confiabilidade

27 27 Tabela 4: Subcaracterísticas da Característica Usabilidade do Modelo de Qualidade (NBR ISO/IEC , 2003) Usabilidade Inteligibilidade Apreensibilidade Operacionalidade Atratividade Conformidade 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 Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação Capacidade do produto de software de possibilitar ao usuário operálo e controlá-lo Capacidade do produto de software de ser atraente ao usuário 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 , 2003) Eficiência Comportamento em relação ao tempo Utilização de recursos Conformidade 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. É 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 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 , 2003) Manutenibilidade Analisabilidade Modificabilidade Estabilidade Testabilidade Conformidade 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 Capacidade do produto de software de permitir que uma modificação especificada seja implementada Capacidade do produto de software de evitar efeitos inesperados decorrentes de modificações no software Capacidade do produto de software de permitir que o software, quando modificado, seja validado Capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à manutenibilidade

28 28 Tabela 7: Subcaracterísticas da Característica Portabilidade do Modelo de Qualidade (NBR ISO/IEC , 2003) Portabilidade Adaptabilidade Capacidade para ser instalado Coexistência Capacidade para substituir Conformidade 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 do produto de software para ser instalado em um ambiente especificado Capacidade do produto de software de coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns 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 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 (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. Durante o desenvolvimento, requisitos de qualidade interna são definidos de forma que permitam que a qualidade de produtos intermediários ou estágios de desenvolvimento do software sejam avaliados. É muito importante que os atributos de qualidade interna de um software estejam diretamente relacionados aos requisitos de qualidade externa, para que dessa forma as características de qualidade do produto de software em desenvolvimento possam ser avaliadas no que diz respeito às necessidades de qualidade do sistema final. A qualidade externa foi definida pela ISO/IEC (2003, p.6) como:

29 29 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 (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 Qualidade em Uso A segunda parte do modelo de qualidade proposto pela NBR ISO/IEC (2003), é o modelo de qualidade para qualidade em uso, que é a visão da qualidade sob a perspectiva do usuário, e que foi definida pela ISO/IEC (2003) como:

30 30 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 (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 , 2003) Eficácia Produtividade Segurança Satisfação Capacidade do produto de software de permitir que usuários atinjam metas especificadas com acurácia e completitude, em um contexto de uso especificado 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 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 Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado

31 31 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 (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. A ISO/IEC (2003) acrescenta que a qualidade em uso é a visão da qualidade dos usuários de um ambiente que contém um software, e é medida sobre os resultados de se usar o software em tal ambiente, e não sobre as propriedades do software em si mesmo. A Figura 3 apresenta uma comparação do desenvolvimento tradicional com as melhores práticas do desenvolvimento direcionado ao usuário, onde se busca a qualidade em uso.

32 32 Figura 3: Práticas de desenvolvimento orientado ao desenvolvedor versus orientação ao usuário Fonte: Traduzido de IBM em 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. O termo user friendly foi adquirindo um conceito muito subjetivo, surgindo em definitivo o termo usabilidade em seu lugar. Em seguida a usabilidade foi definida como uma característica principal da qualidade de um produto de software na ISO/IEC 9126 (1991), e depois foi ampliada na ISO/IEC (2001) como qualidade em uso, onde oferece uma idéia mais abrangente e completa de qualidade do que usabilidade. Fazendo com que a qualidade em uso seja mais ampla que a usabilidade (ISO/IEC , 2003, p.12).

33 33 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. Simplesmente entregar softwares com aspectos técnicos excelentes para o usuário utilizar não é mais suficiente, há uma grande demanda por softwares que sejam amplamente acessíveis, fáceis de usar, aprender e de se integrar ao ambiente de trabalho (BEVAN, 1999B). Mas há uma barreira técnica para que se chegue a esse mundo ideal, que é desenvolver softwares capazes de satisfazer a todos os usuários. Se for tomada em conta literalmente a palavra todos, pode ser

34 34 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 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 (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. Figura 4: Medidas de qualidade em uso determinadas pelo contexto de uso Fonte: Traduzido e adaptado de BEVAN (1995A, p. 5)

35 35 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 ). A ISO/IEC (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) Métricas Métricas são usadas para proporcionar visibilidade sobre processos ou produtos para que se possa avaliar a aderência a padrões, linhas de direção e princípios, estimar e predizer, e também para aceitar um produto (KELLER et al, 1990, p.28), uma vez que também podem proporcionar subsídios a tomadores de decisão. As métricas podem ser usadas como insumo a um modelo de desenvolvimento para estimar parâmetros de softwares, tais como: tempo, esforço, utilização de recursos e até mesmo como um padrão para aceitação de um produto de software produzido sob um contrato de aceitação.

36 36 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 , 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 , 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. As métricas podem ser diretas, onde pode-se aplicar um método de medição objetivo ou subjetivo; ou indiretas, que são aquelas definidas em função de outras métricas, e são calculadas com base no método de cálculo associado, ou seja, com base em uma fórmula. Para cada métrica definida é necessário levar a cabo o

37 37 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 , 2002). A Norma ISO/IEC (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 , 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 , 2002). As métricas da Característica Satisfação são utilizadas para medir a satisfação do usuário final de um software, onde normalmente se utilizam questionários, cujo objetivo é considerar aspectos como a complexidade das interfaces, a qualidade da documentação, a facilidade e conteúdo da ajuda e a adequação das funcionalidades, dentre outros. Em geral se utiliza um instrumento validado estatísticamente, com um mecanismo de cálculo que permita obter um valor de acordo as respostas de cada usuário. A somatória do resultado de cada resposta

38 38 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 Norma ISO/IEC 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 (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; Incorporação e revisão do processo de avaliação;

39 39 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. 9. A série SQuaRE está dividida em 5 partes, conforme pode ser visto na Tabela Tabela 9: Divisões da série SQuare (ISO/IEC 25000, 2004) Norma Divisão Descrição ISO/IEC 2500n ISO/IEC 2501n ISO/IEC 2502n ISO/IEC 2503n ISO/IEC 2504n Gestão de Qualidade Modelo de Qualidade Medição da Qualidade Requisitos de Qualidade Avaliação da 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. 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. 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. 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. 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 Também possui uma extensão (ISO/IEC a ISO/IEC 25099), criada para incluir normas internacionais de qualidade para produtos de software e relatórios técnicos que se ocupam de domínios de aplicação específicos ou que se possam usar como complemento de uma ou mais normas internacionais SQuaRE (AZUMA, 2001).

40 Norma ISO/IEC A Norma ISO (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 (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. De acordo com Jokela et al (2003) a ISO está se tornando a principal referência para usabilidade, pois além de ser amplamente reconhecida na literatura, foi a definição de usabilidade escolhida para elaboração do CIF Commom Industry Format for Usability Test Reports, que fornece um modelo padrão para geração de relatórios de teste de usabilidade.

41 41 um produto: Cato (2001, p.29) sugere os seguintes atributos para garantir a usabilidade de 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), possibilitandolhe 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 (1998) que define aprendizado como um simples sub-atributo do tempo de aprendizado, enquanto a ISO (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. HCI estuda o êxito de tarefas realizadas em conjunto por pessoas e máquinas, a natureza da comunicação entre eles, a capacidade de uso de

42 42 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 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; Classificar as empresas como de classe mundial;

43 43 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 , 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: Figura 5: A qualidade no ciclo de vida do desenvolvimento de softwares Fonte: NBR ISO/IEC (2003)

44 44 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 (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. São consideradas quatro atividades de modelagem direcionada ao usuário final que deveriam ser levadas em conta durante todas as etapas de um projeto: compreender e especificar o contexto de uso, especificar os requisitos dos usuários e da organização, produzir soluções de modelagem e avaliar alternativas de modelagem frente aos requisitos.

45 45 Também é importante fazer referência a Norma ISO/IEC (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 (2001). Conforme abordado pela Norma ISO/IEC , 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 ) 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. Sendo assim, a qualidade de um produto de software é conseqüência das atividades realizadas no processo de desenvolvimento do mesmo. Avaliar a qualidade de um produto de software é analisar, através de métodos e técnicas, o quanto os requisitos são atendidos. Tais requisitos, de forma geral, expressam necessidades, quer seja em termos quantitativos, quer seja em termos qualitativos, e

46 46 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 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. Bevan (1997; 1999B; 2000) argumentou em diversas ocasiões que a qualidade em uso é a medida adequada de todo sistema de qualidade para um produto de software, e que a qualidade em uso pode ser considerada o principal objetivo do desenvolvimento de um produto de software. Se um software tem alta qualidade em uso, então os usuários considerarão o produto como sendo de alta qualidade, independente da atual qualidade interna ou externa, uma vez que a

47 47 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) Norma ISO/IEC A Norma ISO/IEC (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 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 : Visão geral; 2) ISO/IEC : Planejamento e Gerenciamento; 3) ISO/IEC : Processo para desenvolvedores; 4) ISO/IEC : Processo para compradores; 5) ISO/IEC : Processo para avaliadores; 6) ISO/IEC : Documentação dos módulos de avaliação. Apoiado na Norma ISO/IEC (1999), Bevan (2002) também definiu a qualidade em uso como: A extensão na qual um produto utilizado por usuários específicos atende às suas necessidades de atingir objetivos específicos com eficácia, produtividade e satisfação em um contexto de uso específico.

48 48 Sendo assim, a qualidade em uso é a visão de qualidade a partir do ponto de vista do usuário e é medida em função dos resultados da utilização do sistema e não das suas propriedades (BEVAN, 1999B). Com este novo enfoque a Norma ISO/IEC (1999) já não considera a qualidade separada das necessidades dos usuários, senão que, qualidade em uso pode ser avaliada de acordo com a eficácia, produtividade e satisfação com que determinados usuários podem atingir metas específicas em um ambiente específico de trabalho. No contexto de um processo de garantia de qualidade de um produto de software, os atributos de qualidade interna e externa deveriam ser o meio e a qualidade em uso o fim, o objetivo a ser atingido. As necessidades dos usuários podem ser expressas como um conjunto de requisitos desejáveis para o comportamento do produto em uso, e esses requisitos por sua vez podem ser quantificados a partir de métricas coletadas quando o software estiver em uso no contexto que será avaliado (ISO/IEC 14598, 1999). Cabe ressaltar que, tratando-se de um guia de avaliação, a relação que é proposta entre os distintos níveis de avaliação que podem ser estabelecidos para um produto de software entre métricas internas e externas. Sendo que, as métricas internas correspondem à medição de artefatos produzidos na fase de desenho e desenvolvimento (modelos, código fonte e etc.), enquanto que as métricas externas se aplicam a versões executáveis do produto, durante as fases de integração e teste do software, bem como durante o uso do mesmo. Esta norma pode utilizar qualquer modelo de qualidade, no entanto a aplicação deste processo de avaliação é muito mais simples se for utilizado o modelo da Norma ISO/IEC (2003), uma vez que todas as normas da série estão fortemente relacionadas a este modelo de qualidade (ABNT, 1999). A Figura 6 ilustra a relação entre estas normas.

49 49 Figura 6: Relação entre as normas ISO/IEC 9126 e ISO/IEC Fonte: NBR ISO/IEC (2003) O processo de avalição proposto pela ISO/IEC é composto de quatro etapas de avaliação, através de dez atividades, conforme ilustra a Figura 7. Figura 7: Processo de avaliação de produto de software ISO/IEC Fonte: ABNT (1999)

50 50 O processo de avaliação definido pela norma ISO/IEC é semelhante ao da ISO/IEC , onde fornece requisitos e recomendações para a implementação prática de avaliação de um produto de software, quando várias partes envolvidas necessitam entender, aceitar e confiar nos resultados da avaliação, de modo a garantir a repetitibilidade, reprodutibilidade, imparcialidade e objetividade nas avaliações (ABNT, 2001, p. 5). Para isto, o processo de avaliação é composto por um conjunto de atividades que são conduzidas pelos requisitantes e pelo avaliador cooperativamente, conforme ilustrado pela Figura 8. Figura 8: Processo de avaliação de produto de software ISO/IEC Fonte: ABNT (2001) Conforme ilustrado na Figura 7, para realizar o processo de avaliação devem ser seguidas as seguintes etapas (ISO/IEC 14598, 2001): Estabelecer requisitos de avaliação: o objetivo deste processo é descrever as metas e os objetivos da avaliação. Tais objetivos se relacionam com o uso da aplicação em consideração de um ou vários pontos de vista e as regras associadas. O domínio da aplicação do produto a ser avaliado deve ser considerado, assim como aspectos críticos como segurança, econômicos e legais devem ser levados em conta.

51 51 Especificar a avaliação: o objetivo deste processo consiste em definir o escopo da avaliação e as medidas a serem realizadas na avaliação. O nível de detalhamento da saída (o documento de especificação da avaliação) deve ser de tal modo que se assegure a repetitividade e reprodutibilidade do processo. Projetar a avaliação: o objetivo deste processo consiste em documentar os métodos e procedimentos a serem utilizados pelo avaliador para realizar as medições e verificações contidas no documento de especificação da avaliação. O avaliador produzirá como resultado deste processo um plano de avaliação que descreve os recursos necessários (humanos, materiais, tecnológicos, etc) e a distribuição e designação dos mesmos às atividades. Executar a avaliação: o objetivo deste processo é obter os resultados ao realizar todas as ações para medir e verificar o produto conforme os requisitos da avaliação, segundo o especificado e planejado Métodos de Avaliação Durante pesquisa realizada acerca do tema de avaliação de softwares, alguns métodos e modelos de avaliação foram encontrados e, em maior ou menor grau, contribuíram para a elaboração do instrumento proposto neste trabalho. Nos próximos tópicos serão apresentados alguns desses métodos e modelos de avaliação Método SUMI O método SUMI Software usability measurement inventory foi desenvolvido pela University College Cork para medir a satisfação de usuários, avaliando a qualidade percebida pelos usuários do software. O SUMI é parte do projeto MUSiC Measuring the Usability of Systems in Contex, desenvolvido pelo projeto European MUSiC para prover meios válidos e confiáveis para especificar e medir tanto usabilidade quanto qualidade em uso, bem como fornecer subsídios para melhoria da qualidade em uso. MUSiC inclui ferramentas e técnicas que implementam os

52 52 princípios da ISO para especificação de contexto de uso e medição da performance e satisfação do usuário (MACLEOD et al, 1997). O MUSiC prove medidas confiáveis de efetividade e eficiência do software, avaliando a medida em que objetivos de tarefas específicas são atingidos, bem como prove medidas para o tempo gasto de forma improdutiva, como: superando problemas e procurando por ajuda. O diagnóstico ajuda na identificação do local onde problemas específicos foram encontrados, e onde melhorias necessitam ser realizadas. O método SUMI é composto de um questionário de cinqüenta perguntas, disponível em sete idiomas, ressaltando que o mesmo não é gratuito. Os usuários respondem ao questionário com base em suas experiências no uso do software ou mesmo de um protótipo. Os resultados fornecidos pelo método SUMI tem se mostrado confiáveis entre diferentes tipos de software, sendo que, são baseados em uma extensa base de dados construída a partir de diversos produtos de software, possuindo um inventário de medidas de usabilidade (PORTEOUS et al, 1993). As respostas obtidas com a aplicação do questionário são comparadas com normas de qualidade como a ISO/IEC , que trata de princípios ergonômicos gerais, aplicáveis a desenhos de diálogos entre pessoas e sistemas de informação, bem como a ISO/IEC , fazendo referência as métricas que podem ser utilizadas para especificar ou avaliar o comportamento de um software quando operado pelos usuários. Embora não tenha sido possível ter acesso a detalhes de como são calculados os índices de satisfação utilizados pelo método SUMI, bem como detalhes mais técnicos de sua construção, pode-se perder tempo com afirmativas redundantes utilizadas no questionário, como: Eu recomendaria o uso deste software a meus colegas; Me agrada o tempo com este software; Trabalhar com esse software é gratificante; Eu não gostaria de usar este software todos os dias; Usar este software é frustrante;

53 53 Eu acho que uma vez este software me causou dor de cabeça. afirmativas: O mesmo padrão mencionado acima também pode ser visto nas seguintes Este software é mesmo muito estranho; Este software é estranho quando eu quero fazer algo que foge do padrão. Outro ponto que pode prejudicar a análise de satisfação dos usuários é a escala de respostas utilizada, que limita o entrevistado a responder: Concordo, Discordo ou Indeciso. Vale ressaltar que algumas afirmativas são interessantes e foram consideradas na abordagem proposta por este trabalho, como: A organização dos menus e listas de informação parecem ser lógicas; A documentação do software é muito informativa; Mensagens de prevenção a erros não são adequadas; De acordo com as diretivas do método SUMI, para sua aplicação é necessário um mínimo de dez respondentes para que se satisfaçam os requisitos para obtenção de resultados estatísticos estáveis (KIRAKOWSKI & CORBETT, 1993, p.210). Não foi objetivo deste trabalho avaliar em detalhes o método SUMI, mas foi possível observar que o método não atenderia integralmente a abordagem proposta, pois dentre outras coisas, não analisa fatores externos ao software que está sendo avaliado. O método foi considerado neste trabalho como uma referência de características a serem mantidas, a serem descartadas e/ou modificadas para o desenvolvimento do instrumento proposto neste trabalho.

54 Avaliação Heurística A avaliação heurística 1 consiste em analisar a conformidade da interface com princípios reconhecidos de usabilidade (heurísticas), mediante a inspeção de vários avaliadores especialistas (MOLICH & NIELSEN, 1990; NIELSEN & MACK, 1994). Avaliadores especialistas são utilizados para validar a interface do produto, pois é difícil para o desenvolvedor encontrar todos os problemas de usabilidade em uma interface. A avaliação da interface é realizada por cada um dos avaliadores, e ao terminarem os mesmos se comunicam para compilar os resultados obtidos. Este procedimento é importante para garantir avaliações independentes e imparciais de cada avaliador. Os avaliadores podem se basear em um conjunto de regras para encontrar problemas de usabilidade, como as definidas por Nielsen e Mack (1994). Estas regras são denominadas Heurísticas de Usabilidade, e são as seguintes: Visibilidade do estado do sistema: determina a necessidade de que o sistema mantenha o usuário informado do estado em que se encontra o sistema; Utilizar a mesma linguagem dos usuários: o sistema deve se comunicar na linguagem dos usuários, com palavras, frases e conceitos familiares, em lugar de termos técnicos; Controle e liberdade para o usuário: dispor de ações de fazer e desfazer, bem como opções de saída bem claras em caso erros; 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; Prevenção a erros: a aplicação deve assegurar que o usuário conhece exatamente o que se requer no sistema; Minimizar a necessidade de memorização: manter objetos, ações e opções visíveis, evitando a necessidade de memorização por parte do usuário; 1 De acordo com a ANSI/IEEE STD , a heurística trata de métodos ou algoritmos exploratórios para solução de problemas. As soluções são buscadas por aproximações sucessivas, avaliando-se os progressos alcançados, até que o problema seja resolvido.

55 55 Flexibilidade e eficiência no uso: as instruções para o uso do sistema devem ser visíveis ou facilmente acessíveis sempre que se necessite; Diálogos estéticos e desenho 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. As principais vantagens da Avaliação Heurística são o baixo custo de implementação, é intuitiva para os usuários e pode ser realizada em etapas iniciais do desenvolvimento do produto. A usabilidade de um produto é um dos itens críticos a obtenção de um bom resultado na avaliação da qualidade em uso de um software, sobretudo no que diz respeito à satisfação dos usuários. Independentemente se é realizada por especialistas, se é sobre um protótipo ou produto pronto, se é sobre um software que se pensa em adquirir ou sobre um já em uso por uma organização. Com base nesses pressupostos, o instrumento para avaliação da satisfação de usuários de software desenvolvido neste trabalho incluiu a característica usabilidade, dentre os pontos a serem avaliados para obtenção do grau de satisfação de usuários finais de software Método MEDE-PROS O método MEDE-PROS Método de Avaliação da Qualidade de Produto de Software, foi desenvolvido no Centro de Pesquisa Renato Archer, ou simplesmente CenPRA, que é uma instituição associada ao Ministério da Ciência e Tecnologia, que tem a finalidade de desenvolver e implementar pesquisas científicas e tecnológicas.

56 56 O método foi desenvolvido para apoiar a avaliação da qualidade de produtos de software sob o ponto de vista do usuário final, verificando o quanto o software atende os padrões das normas internacionais de qualidade, de acordo com as Normas ISO/IEC 9126 e ISO/IEC 12119, com relação a características de qualidade e pacotes de software. O resultado desta avaliação é um relatório identificando os aspectos do produto que atende as normas de qualidade de software e os aspectos a serem revistos, com sugestões de melhoria (CENPRA, 2004). O CenPRA também credencia laboratórios para utilização do MEDE-PROS. O MEDE-PROS contém um total de 526 questões divididas em sete componentes: instalação, documentação do usuário, interface do usuário, software, descrição do produto, embalagem e desinstalação. Estas questões estão divididas entre os componentes citados, abrangendo Características e Subcaracterísticas de qualidade, como: completitude, funcionalidade, portabilidade, usabilidade, adequação, operacionalidade e etc. O processo de avaliação de produtos de software é baseado na série ISO/IEC 14598, sendo formado pelas seguintes etapas: Definição da estrutura física e de pessoal necessários a avaliação; Levantamento de requisitos, elaboração, negociação e formalização da proposta de avaliação; Planejamento das tarefas para execução da avaliação; Testes funcionais e inspeção da documentação do produto; Devolução do material avaliado juntamente com o relatório da avaliação; A avaliação de um produto de software utilizando-se o MEDE-PROS é realizada simulando o uso do produto. Começando pela análise da documentação do produto, instalando o produto conforme a documentação e utilizando o produto da forma mais completa possível. Durante todo o processo de avaliação o avaliador atribui pontuações ao produto de acordo com as perguntas do checklist, bem como o tempo gasto na avaliação, especifica as principais funções do produto e tece comentários sobre o produto que considere relevantes. A última etapa do processo

57 57 de avaliação é preparar o relatório de avaliação, que deve apresentar os aspectos positivos do produto avaliado e sugestões para sua melhoria. O método MEDE-PROS tem sido referência no Brasil como método de avaliação de produtos de software, e como tal, tem inegável aprovação da comunidade de software nacional e notória qualidade no resultado de suas avaliações. Mas é importante ressaltar que o processo de avaliação é conduzido por um consultor especialista, executando a avaliação sob o ponto de vista técnico da Engenharia de Software, identificando o quanto o produto avaliado cumpre com requisitos definidos em normas internacionais de qualidade. Desta forma, além de ser uma avaliação que pode ter um custo considerado alto para sua aplicação, a mesma deixa de fora a opinião de quem realmente conhece do negócio e que faz o verdadeiro uso do produto, que são os usuários finais. Além de que não foi observado no método, a preocupação com o ambiente em que este produto é usado, e que pode impactar diretamente em uma avaliação de satisfação de usuários de software. Não foi objetivo deste trabalho avaliar em detalhes o método MEDE-PROS. O método foi considerado neste trabalho como uma referência de características a serem mantidas, a serem descartadas e/ou modificadas para o desenvolvimento do instrumento proposto neste trabalho Fidedignidade de Instrumentos de Avaliação A elaboração de questionários requer cuidados especiais, uma vez que podem não ser respondidos corretamente, fornecendo informações distorcidas ao pesquisador, ou seja, o instrumento não mede corretamente o que se propõe a medir. O que faz com que seja necessário, ao se utilizar tais instrumentos, encontrar meios que aumentem a confiança as medidas realizadas. Isso pode ser feito através da avaliação de fidedignidade do instrumento. A fidedignidade é considerada como a qualidade de um teste relativo à sua estabilidade, precisão e constância. Pode-se dizer que um teste é fidedigno quando mede com a mesma precisão, ou seja, reporta os mesmos resultados em sucessivas

58 58 aplicações realizadas em situações similares, conforme definido por Fox (1969, p.353). Por fidedignidade entende-se a exatidão dos dados no sentido de sua estabilidade, repetitividade ou precisão. Um instrumento de coleta de dados perfeitamente fidedigno é aquele que se administrado duas vezes nas mesmas circunstâncias forneceria os mesmos dados. A importância da fidedignidade de um instrumento também pode ser vista na colocação de Viana (1978, p.145). Se um teste é aplicado ao mesmo grupo um grande número de vezes, espera-se que os resultados sejam os mesmos, desde que o grupo não se modifique. Se em cada vez que o teste for aplicado, satisfeitas determinadas condições, os escores forem diferentes para o mesmo grupo, não se poderá ter confiança no instrumento, porque não haverá consistência nas medidas. O objetivo primordial da avaliação de um questionário é garantir que este seja de fato aplicável e que responda efetivamente aos problemas colocados pelo investigador (KETELE & ROEGIERS, 1999), indicando a confiança que podemos ter acerca de que as pontuações obtidas pelos entrevistados nos testes sejam realmente suas pontuações verdadeiras. Para estimar a fidedignidade de um instrumento recorre-se a procedimentos estatísticos 2, podendo ser utilizado para tal o coeficiente de fidedignidade, que pode ser interpretado como uma correlação que ao estar perto de +1 indica alta fidedignidade, e perto de zero indica ausência de fidedignidade (MOREIRA & ROSA, 2007, p.20). 2 Estatística é a teoria e método de analisar dados obtidos de amostras de observações com o fim de descrever populações, estudar e comparar fontes de variância, para ajudar a tomar decisões sobre aceitar ou rejeitar relações entre fenômenos e para ajudar a fazer inferências fidedignas de observações empíricas (KERLINGER, 1980, p.353).

59 59 Dentre os métodos disponíveis para avaliar fidedignidade de um instrumento, pode-se utilizar o método da metade ou par-ímpar, que consiste em dividir o teste em duas partes e procurar pela correlação entre as duas metades, ou seja, primeira metade frente à segunda metade do instrumento ou questões pares frente a questões ímpares. (FOX, 1969): A utilização da forma par-ímpar é a mais indicada pelos seguintes fatores Normalmente, um instrumento de medida cobre diferentes áreas do conhecimento em diferentes seções, as quais geralmente são estanques e bem diferenciadas; Fatores tais como fadiga ou perda de interesse poderiam causar omissão por parte do respondente nas questões finais do teste. Neste trabalho será utilizada a fórmula de Spearman-Brown para medir a fidedignidade do instrumento proposto, conforme pode ser vista na Figura 9. αsb 2x α = 1+ α Figura 9: Fórmula de Spearman-Brown Onde α SB é a chamada estimativa de fidedignidade de Spearman-Brown, sendo α a correlação entre as duas metades do teste. O que esta fórmula proporciona é somente uma predição ou estimativa da fidedignidade que o pesquisador poderia esperar para o instrumento como um todo a partir dos valores de fidedignidade obtidos para cada metade do teste (MOREIRA & ROSA, 2007, p.83). Ainda segundo Moreira e Rosa (2007), coeficientes de correlação da ordem de 0,90 ou 0,85 e até mesmo 0,70 seria aceitável dependendo da informação, já que as expectativas para a fidedignidade de um instrumento irão diferir dependendo da natureza da informação que está sendo procurada.

60 60 Utilizando-se a estimativa de fidedignidade de Spearman-Brown, pode-se realizar apenas uma interação com os dados coletados, o que é um facilitador, dada a dificuldade de se aplicar o mesmo questionário mais de uma vez ao mesmo grupo de entrevistados. A avaliação da fidedignidade do instrumento para um novo grupo pode ser interessante, para que seja avaliado se o instrumento continua a ser válido em outros contextos, embora não seja obrigatória uma segunda avaliação do instrumento. 2.3 Conclusões do Capítulo Qualidade de Produto de Software Neste capítulo foram abordados os conceitos e termos relativos à qualidade de produto de software, modelos e qualidade em uso, que permitem concluir que qualidade em uso não é um conceito absoluto, e que existem diferentes perspectivas sobre qualidade para produtos de software. De acordo com a Norma ISO/IEC (2003), tanto qualidade interna, quanto qualidade externa e qualidade em uso podem ser especificados, medidos e avaliados, considerando que cada perspectiva tem seu valor agregado em uma estratégia de garantia de qualidade ao longo do ciclo de vida de um produto de software. Conforme definido no Capítulo 1, a proposta deste trabalho é um instrumento para avaliar a satisfação de usuários finais de softwares, e conseqüentemente a qualidade em uso de tais produtos. Dando como retorno ao desenvolvedor do software, a identificação de Características e Subcaracterísticas da qualidade interna e externa do produto que estejam impactando na satisfação dos usuários do software avaliado Avaliação da Qualidade de Produto de Software Um dos tópicos fundamentais e que formaram a base para a construção da abordagem proposta neste trabalho de pesquisa, foram os métodos de avaliação da qualidade de software apresentados neste capítulo. Alguns com foco mais em qualidade em uso e usabilidade, e outros de aspecto mais amplo.

61 61 Embora os métodos apresentados não tenham sido analisados amiúde, uma vez que não era foco deste trabalho fazê-lo, procurou-se identificar lacunas e pontos positivos nos mesmos, para que pudessem ser utilizados no instrumento proposto neste trabalho, conforme pode ser visto em cada uma das seções ao longo deste capítulo. Ainda que sejam de notório reconhecimento na comunidade de qualidade de software, alguns pontos merecem ser destacados como possíveis empecílhos a uma avaliação mais precisa da satisfação de usuários finais de produtos de software. Nenhum dos métodos pesquisados considera fatores externos ao software em sua análise. Apenas o método SUMI tem participação efetiva do usuário final na avaliação da qualidade em uso, possibilidade que se não for considerada pode ser prejudicial ao processo, uma vez que não irá retratar a satisfação do usuário final. Mesmo que esses métodos tenham suas análises amparadas por métricas bem definidas e bases de conhecimento, seria relevante para uma análise da qualidade em uso considerar critérios subjetivos, e não somente números, principalmente em se considerando fatores externos. Os métodos também não disponibilizam espaço para que o usuário final possa relatar de forma aberta críticas e/ou sugestões, o que poderia contribuir muito para a análise subjetiva e também para corroborar o resultado apresentado pelas fórmulas e gráficos. Dentre os métodos apresentados neste capítulo, alguns contribuíram em maior ou menor grau para a elaboração do instrumento proposto neste trabalho, seja com seus pontos positivos ou com pontos deixados em aberto. No próximo capítulo serão descritos os procedimentos metodológicos utilizados para execução deste trabalho, bem como será apresentado o detalhamento da construção do instrumento proposto, cuja base foi sendo delineada ao longo deste Capítulo 2.

62 62 3. METODOLOGIA DE PESQUISA Este capítulo descreve a metodologia adotada na pesquisa visando cumprir os objetivos propostos. 3.1 Classificação da Pesquisa A classificação da pesquisa foi baseada em Moresi (2004): a) Quanto à natureza do estudo: pesquisa aplicada, uma vez que tem por objetivo a proposição de um instrumento para aplicação prática, contribuindo assim, para o segmento de Qualidade de Software. b) Quanto à forma de abordagem do problema: inicialmente a pesquisa será quantitativa, uma vez que parte do instrumento transforma as respostas dos entrevistados em números e aplica fórmulas matemáticas; e qualitativa, pois uma segunda parte do instrumento servirá de base para uma análise de dados subjetivos. c) Quanto à finalidade do estudo: pesquisa classificada como exploratória e metodológica. Exploratória, porque visa identificar empiricamente, elementos que remetam a satisfação do usuário em métodos e modelos de avaliação de usabilidade e qualidade em uso; Metodológica, porque visa construir um instrumento para captação da realidade, a satisfação de usuários acerca dos softwares que utilizam. d) Quanto aos meios de investigação: pesquisa classificada como bibliográfica e de campo. Bibliográfica, serviu de base para melhor conhecimento do objeto de estudo e identificar métodos e modelos de avaliação de usabilidade e qualidade em uso; De campo, foi utilizado o instrumento de pesquisa, sendo aplicado através de questionário conduzido junto a usuários do software SysOKA 3 e do ERP P 4. 3 SysOKA: é uma ferramenta que pode ser definida como sendo um software de automatização de questionários, uma vez que foi desenvolvido para automatizar a aplicação do questionário utilizado pelo método Organizational Knowledge Assessment OKA, método este que foi criado pelo World Bank Institute para diagnosticar a situação da Gestão do Conhecimento nas organizações. 4 ERP P: não foi autorizada a divulgação do nome do software. É um ERP (Sistema Integrado de Gestão Empresarial) utilizado mundialmente por empresas de diversos segmentos.

63 Fontes de Informação Utilizadas Para a realização da pesquisa bibliográfica deste trabalho foram utilizados livros, periódicos, artigos, sites na internet, bancos de dados de teses e dissertações de universidades. Outra fonte considerada importante para o conhecimento do fenômeno estudado refere-se à experiência de vinte anos do autor na área de Tecnologia da Informação, lidando entre outras coisas com desenvolvimento, implantação de softwares, gerência de projetos e consultoria. As principais fontes digitais de informação consultadas na Internet foram: Universidade Católica de Brasília - Universidade de São Paulo - Univ. Federal do Rio de Janeiro - A pesquisa bibliográfica foi realizada junto a três dos principais portais disponíveis na Internet. Definiu-se como principais palavras-chave da pesquisa os termos Usability, Usability Test, Quality in Use e Software Metrics. Os resultados são apresentados na Tabela 10.

64 64 Tabela 10: Resultado da pesquisa por palavras-chave Fontes Disponíveis Scirus Portal Computer Palavras-chave da Pesquisa ACM Periódicos Outros Diversos Diversos Usability Usability e-commerce Usability human-computer interaction Usability interface design Usability user-computer interface Usability user-computer interface software Usability user-computer interface software software validation Usability user interface design Usability user interface design computer-based systems Usability test Usability test human-computer interaction Usability test human-computer interaction user satisfaction Usability test human-computer interaction human factors society Usability test human-computer interaction computer-based Usability test user satisfaction Usability test user satisfaction feedback relevance Usability test user satisfaction satisfaction questionaire Quality in Use Quality in Use customer satisfaction Quality in Use customer satisfaction software metrics Quality in Use customer satisfaction usability Quality in Use software measurement Quality in Use software measurement software metrics Quality in Use usability Quality in Use usability user satisfaction Quality in Use user satisfaction Quality in Use user satisfaction business value Metrics software metrics Metrics software metrics software measurement Suposições Este trabalho de pesquisa apresenta as seguintes suposições: O grau de satisfação de um usuário para com determinado software pode ser avaliado; É possível identificar de forma pontual as Características e Subcaracterísticas de um software que estejam gerando insatisfação em seus usuários.

65 Delimitação do Estudo Esta pesquisa limita-se a aplicar o instrumento proposto a dois softwares de porte e segmentos diferentes, o software SysOKA e o ERP P. Não é escopo do instrumento proposto avaliar produtos de software durante o processo de desenvolvimento, em fase de protótipo e nem durante processos de aquisição. Pois a avaliação da satisfação de usuários se dará sobre um produto já em uso, tendo como participantes diretos os próprios usuários finais do software a ser avaliado. 3.5 Identificação e Amostragem da População Uma vez que a proposta deste trabalho é construir um instrumento para avaliação da satisfação de usuários finais de softwares, mas sem delimitar o tipo, porte ou segmento de tal produto, torna-se muito difícil estabelecer a quantidade exata de indivíduos que compõe a população de usuários de softwares, devido à imensa quantidade de produtos de software disponíveis, mesmo reduzindo este universo a dois softwares, SysOKA e ERP P. Assim, a amostra selecionada para aplicação do instrumento proposto foi definida pelo acesso do autor a usuários finais dos softwares SysOKA e ERP P, que podem ser definidos como: a) SysOKA: é um software que foi desenvolvido para automatizar a aplicação do método OKA 5 Organizational Knowledge Assessment. Uma vez que a aplicação do método OKA se mostrava um pouco trabalhosa devido a extensão de seu questionário e a geração de gráficos para análise dependerem de ferramentas estatísticas como o SPSS, foi criado o SysOKA para amenizar tais situações. b) ERP P: foi desenvolvido para satisfazer os mais complexos requisitos de negócio para empresas de diversos segmentos, sendo utilizado mundialmente. O Sistema têm módulos integrados de gestão de ativos, CRM, automação de serviços, gestão financeira, RH e suprimentos, dentre outros. 5 OKA Organizational Knowledge Assessment, é um método que objetiva diagnostricar a situação da Gestão do Conhecimento nas organizações, tendo sido desenvolvido pelo WBI World Bank Institute, unidade organizacional do Banco Mundial.

66 66 A amostra de usuários finais utilizada na pesquisa de campo para o software SysOKA foi de dezessete (17), e para o ERP P onze (11), o que se considerou suficiente para aplicação do instrumento proposto. Uma vez que não foi realizado um estudo para estabelecer uma quantidade mínima de respondentes, tomou-se por referência as diretivas do método SUMI, que estabelece que para sua aplicação sejam necessários um mínimo de dez respondentes para que se satisfaçam os requisitos para obtenção de resultados estatísticos estáveis (KIRAKOWSKI & CORBETT, 1993, p.210). Tal referência foi utilizada devido o método SUMI ter certa similaridade ao instrumento proposto neste trabalho, e também por ter notório reconhecimento junto à comunidade de qualidade de software como um método eficaz para avaliação da satisfação de usuários de softwares. 3.6 Desenvolvimento do Instrumento Devido à experiência do mestrando na área de Tecnologia da Informação com consultoria, desenvolvimento e contato com usuários de softwares de diversos segmentos, havia uma preocupação em conseguir avaliar a real percepção do usuário final de softwares acerca da qualidade do produto utilizado por eles. Mas o resultado dessa avaliação de satisfação deveria prover a empresa desenvolvedora do produto, subsídios para que pudesse implementar melhorias em seu software, de forma direcionada as necessidades dos usuários finais. Inicialmente efetuou-se uma pesquisa por modelos e métodos de avaliação de qualidade de software, satisfação de usuários, avaliação de usabilidade e qualidade em uso. Com o intuito de identificar lacunas a serem exploradas no tema de avaliação da satisfação de usuários finais de softwares. Foi constatado que existe certa quantidade de modelos e métodos para avaliar a qualidade de software, e dentre eles, alguns de notório reconhecimento, mas quando se fala em avaliar a qualidade em uso de um produto de software, principalmente no que tange a satisfação de usuários finais, poucos são os métodos disponíveis, sendo que, alguns têm custo associado, alguns não realizam a

67 67 avaliação com o usuário final do software e outros dependem de avaliadores especialistas. Outro ponto que se julgou importante para a abordagem pretendida foi o contexto de uso, onde muito se falou em considerá-lo para que fosse possível efetuar uma avaliação mais precisa da qualidade em uso, conforme pode ser visto ao longo do Capítulo 2. Mas o que se observou acerca desta recomendação é apenas o fato de que se deve especificar o contexto de uso para efeitos comparativos da avaliação do produto, para que não sejam tiradas conclusões equivocadas sobre qualquer avaliação e/ou para que o efeito requerido do produto seja obtido. Já foi mencionado na Seção , mas cabe ressaltar novamente o que é colocado pela Norma ISO/IEC (2003), que o contexto de uso são os usuários, tarefas, hardware, software e o ambiente, tanto físico quanto social em que o produto é utilizado. Portanto, o entendimento de contexto de uso que se obteve da pesquisa realizada, e que não foi encontrado nos modelos e métodos pesquisados, é que há a necessidade de se analisar o ambiente em que o produto de software é utilizado, para que se possa chegar a uma conclusão mais precisa na avaliação da satisfação de usuários finais de produtos de software. Também foi observado nos métodos pesquisados, que o usuário mesmo quando participa diretamente da avaliação, não tem como expressar suas opiniões e anseios sobre o produto além das perguntas e opções de respostas préestabelecidas. Ou seja, falta dar ao usuário final a oportunidade de relatar de forma aberta suas necessidades. Dessa forma, optou-se por construir um instrumento para avaliar a satisfação de usuários de software que tivesse os seguintes requisitos: Não dependesse de avaliadores especialistas; Fosse baseada no usuário final do produto; Levasse em consideração fatores externos ao software que está sendo avaliado;

68 68 Que desse liberdade ao usuário de se expressar além das perguntas/proposições pré-estabelecidas nos métodos usuais; Como resultado final, que fornecesse subsídios à empresa desenvolvedora do produto para a melhoria do software, mas de forma direcionada às necessidades dos usuários Etapas do Desenvolvimento do Instrumento Tendo como referência os pressupostos elencados na seção anterior, deu-se início a construção do instrumento proposto. A base principal para o desenvolvimento do instrumento para avaliação da satisfação de usuários de software foram os modelos e métodos pesquisados, que vão desde normas para avaliação da qualidade de software, qualidade em uso, pacotes de software, requisitos de ergonomia, avaliação de usabilidade e avaliação heurística dentre outros, bem como, a experiência de cerca de vinte anos do mestrando na área de Tecnologia da Informação, lidando entre outras coisas com desenvolvimento, implantação de softwares e consultoria. A partir da pesquisa foram selecionadas características, funcionalidades e comportamentos de produtos de software que pudessem impactar na satisfação de seus usuários finais. Feito isto, procurou-se identificar onde tais situações poderiam ser encaixadas dentro das Características e Subcaracterísticas do Modelo de Qualidade proposto pela Norma ISO/IEC , que é uma das principais referências para o instrumento proposto. As Características e Subcaracterísticas do modelo citado podem ser vistas nas Tabelas 1, 2, 3, 4, 5, 6 e 7 da Seção Dentre as Características e Subcaracterísticas do Modelo de Qualidade, algumas tratam de requisitos de qualidade que não são perceptíveis aos usuários finais de um produto de software, ou seja, mesmo formando parte de um conjunto que deve funcionar de maneira harmônica para que o software execute adequadamente, o usuário final não percebe tal requisito de qualidade até ter seu trabalho interrompido por uma falha, como por exemplo:

69 69 Manutenibilidade: o usuário pode perceber como baixa a manutenibilidade de seu software apenas no momento em que necessitar de correções ou melhorias no mesmo; Portabilidade: o usuário pode perceber a falta de portabilidade de um software apenas quando houver necessidade de mudança de ambiente do mesmo; Segurança de acesso: o usuário pode saber que existe e que é importante, mas não tem como identificar ou mensurar o nível de segurança de acesso em um software; Das noventa e seis perguntas, e dez Subcaracterísticas inicialmente relacionadas, deu-se início ao trabalho de refinamento, onde o critério de seleção de quais Características e Subcaracterísticas do Modelo de Qualidade seriam utilizados, foi o de que deveriam remeter a satisfação direta de usuários finais de produtos de software, ou seja, que fosse perceptível, e como tal, influenciasse diretamente no trabalho do usuário junto ao software avaliado. A Tabela 11 apresenta as Características e Subcaracterísticas utilizadas no instrumento proposto. Tabela 11: Características e Subcaracterísticas utilizadas no instrumento Funcionalidade Acurácia Adequação Usabilidade Inteligibilidade Apreensibilidade Operacionalidade Atratividade Eficiência Tempo Recursos A definição de cada Característica e Subcaracterística elencadas na Tabela 11 podem ser vistas nas Tabelas da Seção Em seguida foram identificados fatores externos ao software em si, que pudessem afetar a percepção de satisfação dos usuários, como condições do local de trabalho, performance de computadores e experiência no uso de sistemas computacionais, dentre outros.

70 70 Também deveria ser considerada uma forma do usuário explicitar abertamente seus anseios e necessidades em relação ao software avaliado. Foi então criado o instrumento iasus Instrumento para Avaliação da Satisfação de Usuários de Software, que será explicado em detalhes na Seção Por último, foi modelado o template de um relatório, onde os dados coletados e toda a análise relativa à avaliação da satisfação de usuários finais de um determinado software pudessem ser apresentados ao solicitante da avaliação O Instrumento iasus Optou-se pela criação de um questionário como instrumento para coleta das informações junto aos usuários finais de softwares, pois conforme Goldenberg (1998), o questionário permite compilar dados tanto de ordem qualitativa como quantitativa. Segundo Ketele e Roegiers (1999), o questionário pode ser considerado como a técnica mais apropriada quando o estudo visa obter respostas a algumas questões como: O quê? ; Quando? ; Onde? e Quantos?. Vale ressaltar ainda as principais vantagens para o uso de questionários, que segundo Marconi e Lakatos (2002, p.98-99) são: Economia de tempo em deslocamentos e contatos com os entrevistados; Abrangência geográfica; Obtenção de respostas mais rápidas e com maior grau de precisão; Menor distorção de respostas devido à ausência do investigador; Definição por parte do respondente do melhor dia e hora para responder e devolver o questionário. Inicialmente a quantidade de questões elaboradas para o instrumento iasus foram de noventa e seis questões, mas optou-se por diminuir esse número, pois

71 71 conforme colocado por Ghiglione e Matalon (1993, p.113), a duração de um questionário depende muito do interesse que o indivíduo tem pelo tema, da forma como ele é elaborado e das condições de sua aplicação, pois um questionário composto na sua maioria por questões fechadas, não deveria ultrapassar quarenta e cinco minutos de resposta, o que após esse tempo o interesse do entrevistado diminui sensivelmente. Portanto, foi criado o instrumento iasus Instrumento para Avaliação da Satisfação de Usuários de Software, que é um questionário composto de cinqüenta e três perguntas divididas em quatro partes: II. Tempo de uso; III. Características, ações e funcionalidades; IV. Críticas e sugestões; V. Fatores externos. Uma vez selecionadas as Características e Subcaracterísticas do Modelo de Qualidade, conforme apresentado na Tabela 11, o próximo passo foi formular as sentenças que seriam usadas para captar a percepção dos usuários acerca das funcionalidades, características e comportamentos do software a ser avaliado. Tais sentenças foram formuladas, ou seja, criadas, adaptadas ou traduzidas tendo como base modelos e métodos pesquisados, conforme exposto no Capítulo 2, bem como a experiência do mestrando. O próximo passo foi selecionar situações relacionadas ao ambiente em que boa parte dos softwares comerciais são utilizados, situações estas que possam induzir o usuário a uma percepção equivocada quanto a qualidade do software. Na seqüência perguntas foram formuladas, para que mediante determinada resposta, seja possível fornecer subsídios a identificação de fatores externos que possam estar afetando a satisfação dos usuários. A seguir são apresentadas as partes que compõe o instrumento iasus.

72 Parte I: Tempo de Uso A primeira parte do instrumento iasus é composta de uma pergunta, onde o usuário é questionado sobre o tempo de uso que ele tem do software que está sendo avaliado, conforme ilustrado pela Figura 10. O intuito desta pergunta é analisar, se em caso de alguma discrepância nas respostas, se o fator tempo de uso do software possa estar impactando nas respostas dadas pelo entrevistado ou pelo grupo participante da avaliação do software. A quanto tempo você utiliza o software que está sendo avaliado? Escala Menos de 6 meses De 6 meses a 1 ano De 1 ano a 2 anos Mais de 2 anos Figura 10: Pergunta sobre o tempo de uso do software Parte II: Características, Ações e Funcionalidades A segunda parte do instrumento é composta de quarenta e uma sentenças, que foram criadas, adaptadas ou traduzidas tendo como base modelos e métodos pesquisados, conforme Capítulo 2, bem como a experiência do mestrando. As sentenças estão divididas por Característica e Subcaracterística conforme apresentado na Tabela 12. Tabela 12: Quantidade de sentenças por Característica e Subcaracterística Funcionalidade Usabilidade Eficiência Acurácia Adequação 3 sentenças 6 sentenças Inteligibilidade Apreensibilidade Operacionalidade Atratividade 8 sentenças 3 sentenças 9 sentenças 5 sentenças Tempo Recursos 3 sentenças 3 sentenças Quarenta sentenças foram formuladas para que o entrevistado responda a seguinte questão: Relativo ao uso do software que está sendo avaliado, por favor informe seu grau de satisfação com as seguintes características, ações e/ou funcionalidades que este software apresenta.

73 73 O entrevistado tem as seguintes opções de resposta: ; ; Indiferente; ; ; Não se. Esta escala de resposta será tratada na Seção As sentenças foram relacionadas às Características e Subcaracterísticas do Modelo de Qualidade da Norma ISO/IEC (2003) conforme Tabelas 13, 14 e 15. O questionário com as sentenças na ordem a ser apresentado ao respondente pode ser visto no Apêndice A. Ao ler a sentença é possível que se julgue que não está associada à Subcaracterística correta, mas é necessário interpretar bem a definição dada pela Norma, que foi exposta na Seção Tabela 13: Sentenças da Característica Funcionalidade Característica Funcionalidade Subcaracterística Acurácia Acurácia Acurácia Adequação Adequação Adequação Adequação Adequação Adequação Sentença Realização correta de todas as tarefas a que se propõe Dar mais precisão ao seu trabalho Integridade dos dados do software após atualizações Estruturação da inteface de forma a agrupar as tarefas em áreas operacionais, mantendo assim, a sequência lógica do trabalho a ser realizado Funcionalidades para satisfazer as necessidades do seu trabalho Disponibilização de Help contextualizado em qualquer parte do software ao se pressionar F1 Menus e lista de informações organizados de forma lógica Informação de andamento das tarefas que estão sendo realizadas Mensagens que ajudam na prevenção a erros do usuário Tabela 14: Sentenças da Característica Usabilidade Característica Usabilidade Subcaracterística Inteligibilidade Inteligibilidade Inteligibilidade Inteligibilidade Inteligibilidade Inteligibilidade Inteligibilidade Inteligibilidade Sentença Apresentação clara e de fácil entendimento das informações Simplicidade para realização de suas atividades Utilização de códigos e termos técnicos condizentes com o trabalho a ser realizado É fácil de entender e reconhecer a estrutura, a lógica e a aplicabilidade do software O texto apresentado na interface do software não dá margem a interpretações ambíguas A documentação do software tem uma organização lógica e evolutiva, aumentando gradativamente o nível de complexidade da informação que lhe é apresentada. Facilita-se assim, o aprendizado e entendimento da operação do software O manual do usuário demonstra as principais atividades a serem realizadas com o uso do software, de modo que se consiga explorar bem suas funcionalidades Confiança de que está usando corretamente o software

74 74 Apreensibilidade Apreensibilidade Apreensibilidade Operacionalidade Operacionalidade Tempo requerido para o aprendizado do software Sistema de Help e tutoriais capaz de esclarecer todas as suas dúvidas A documentação do software é clara e precisa A forma de realizar uma tarefa no software está alinhada a forma que você organiza seu trabalho O software possui comportamento semelhante em situações semelhantes, ou seja, solicita do usuário ações similares para tarefas similares Operacionalidade Normalmente o software faz o que você espera que ele deveria fazer Operacionalidade Completo entendimento do que deve ser feito em todas as partes do software Operacionalidade Navegar em distintos níveis do software sem se perder ou desorientar Operacionalidade É mantido um padrão de cores, botões e mensagens em todo o software Operacionalidade Os botões são todos de tamanho e forma similiar em todo o software Operacionalidade Cada janela tem um título que a identifica claramente Operacionalidade Atratividade Atratividade Atratividade Atratividade Atratividade A interface do software informa ao usuário sobre o que um botão, menu, ícone ou caixa de diálogo faz ao se posicionar o cursor do mouse sobre ele O software utiliza de uma linguagem instrutiva, polida, neutra e não agressiva Atratividade e interface amigável Navegação simples entre os menus e itens de menu As telas do software utilizam tipos e tamanhos de letras de fácil visualização As cores são utilizadas com equilíbrio, ou seja, são bem distribuídas evitando assim poluição visual Tabela 15: Sentenças da Característica Eficiência Característica Eficiência Subcaracterística Tempo Tempo Tempo Recursos Recursos Recursos Sentença Resposta rápida as requisições de consultas e relatórios Resposta rápida as entradas realizadas Tempo gasto na execução das tarefas Otimização do seu trabalho, criando condições mais favoráveis para realização do mesmo Tempo gasto para localizar funcionalidades ou ferramentas dentro do software Quantidade de passos para executar as tarefas A última sentença da Parte II do instrumento iasus é uma pergunta, conforme pode ser visto na Tabela 16. É um questionamento direto ao respondente acerca da sua satisfação global com o software avaliado. Esta pergunta foi criada para corroborar e também confrontar o resultado da avaliação da satisfação do usuário realizada pelo instrumento proposto. Tabela 16: Pergunta para avaliar a satisfação com o software avaliado Pergunta Qual seu grau de satisfação em relação ao software que está sendo avaliado?

75 Parte III: Sugestões A terceira parte do instrumento é composta por um campo de entrada livre para o usuário apresentar comentários, críticas e/ou sugestões acerca do software avaliado, conforme apresentado na Tabela 17. Tabela 17: Comentários, críticas e/ou sugestões acerca do software avaliado Caso seja de seu interesse, utilize o espaço abaixo para comentários, críticas e/ou sugestões de melhoria do software que está sendo avaliado: Uma vez que um dos objetivos específicos deste trabalho é prover uma análise ao desenvolvedor do software avaliado, para que efetue melhorias de forma direcionada as necessidades dos usuários do seu produto, este campo de entrada livre foi criado para que o usuário possa expressar textualmente sua avaliação em relação ao software. Dependendo do conteúdo dos comentários do entrevistado, o texto pode ser utilizado na análise geral da satisfação dos usuários ou simplesmente ser disponibilizado no relatório final a ser encaminhado ao solicitante da avaliação, como pontos a serem melhorados no produto de software Parte IV: Fatores Externos A quarta parte do instrumento é composta de dez perguntas, que servirão para analisar se o ambiente em que o software está sendo executado tem alguma nuance, ou seja, se há algum fator externo ao software em si que possa estar impactando na percepção dos usuários acerca da qualidade do produto, e conseqüentemente em sua satisfação com o software. As perguntas para avaliação de fatores externos ao software avaliado são apresentadas na Tabela 18, e foram formuladas para que o entrevistado responda a seguinte questão: Considerando o ambiente em que o software que está sendo avaliado é utilizado, por favor responda as seguintes perguntas.

76 76 Nesta parte do instrumento o entrevistado tem as seguintes opções de resposta, que podem variar de acordo com a pergunta: a) Não; ; Sim; Não se ; b) Fraco; Regular; Bom; Ótimo; Não se. Esta escala de resposta será tratada na Seção Tabela 18: Perguntas para análise de fatores externos ao software avaliado Pergunta O software que está sendo avaliado foi implantado em substituição a algum outro software ou processo manual que você utilizava anteriormente? Você considera que as necessidades dos usuários foram levadas em consideração no desenvolvimento deste software? Como você classifica o treinamento recebido para utilizar o software? Como você classifica seu nível de experiência no uso de sistemas computacionais? Como você classifica seu nível de motivação com as tarefas que desempenha usando o software em questão? Como você classifica as condições do local de trabalho para a execução das tarefas que dependem do software? Como você classifica o nível do suporte prestado em caso de dúvidas ou problemas? Como você classifica os meios ofertados ao usuário para apresentar sugestões de melhoria? Em termos de velocidade de processamento, como você classifica os computadores usados com este software? Como você classifica o seu grau de fluência no idioma em que o software é apresentado? Uma vez que se tenha em mãos os percentuais relativos ao grau de satisfação dos usuários separados por Característica e Subcaracterística, oriundos da tabulação dos dados da Parte II do iasus, o responsável pela avaliação deverá analisar as respostas obtidas com a avaliação do ambiente, procurando identificar fatores externos que possam estar impactando na satisfação dos usuários.

77 Escalas Utilizadas no Instrumento iasus Para que se possa medir atitudes, opiniões e outras variáveis emitidas por um determinado indivíduo ou grupo de pessoas, costuma-se fornecer a elas uma lista de expressões ou adjetivos, que são chamados de Escalas. A esses indivíduos é solicitado responder a esta lista de expressões ou adjetivos de acordo com seus sentimentos, opiniões e expectativas acerca do assunto abordado (ALRECK & SETTLE, 1995). Ainda segundo Alreck e Settle (1995), as escalas devem ser utilizadas quando o investigador tem como objetivo obter respostas que possam ser comparáveis umas com as outras. Os tipos de escalas mais comuns são: nominal, ordinal, intervalo, proporção e absoluta. Os tipos de escala de uma medida afetam o tipo de transformação admissível, as transformações aritméticas e a análise estatística que se pode aplicar sobre os valores (FENTON & PFLEEGER, 1997, p ). Neste trabalho serão utilizadas escalas ordinais, que correspondem a um conjunto ordenado de pontos de escala, sendo que, permitem transformações incrementais, aplicação de fórmulas estatísticas como Mediana, Spearman, Kendall Tau e Testes não paramétricos. Como exemplo pode-se utilizar o grau de disponibilidade, funcionalidade, complexidade e etc. (FENTON & PFLEEGER, 1997, p ). Para a Parte II do instrumento a escala utilizada vai de a, com mais uma opção de resposta que é Não se, para que o entrevistado tenha uma opção de escolha caso não seja escopo do software avaliado ter determinada característica, funcionalidade ou ação questionada no instrumento. Conforme pode ser visto na Figura 11. Indiferente Não se Figura 11: Escalas para as sentenças da Parte II do Instrumento iasus Este tipo de escala apresentado na Figura 11, com categorias ordenadas e igualmente espaçadas é largamente utilizada em pesquisas organizacionais (BADRI et al, 1995; TAMIMI et al, 1995). Não incluir uma categoria central, que no caso é a

78 78 categoria Indiferente, pode conduzir os respondentes a uma tendência, forçandoos a maracarem a direção que estiverem mais inclinados. Incluir uma opção Não Sei ou Não se no exterior da escala gradual é uma boa sugestão para a construção da escala, sendo que, existem escalas variando de quatro a onze categorias, mas as escalas de quatro e cinco categorias são as mais populares (ALEXANDRE et al, 2002). Figura 12. Para a Parte IV do instrumento as escalas utilizadas estão representadas na Resposta Não Sim Não se Fraco Regular Bom Ótimo Não se Figura 12: Escalas para as perguntas da Parte IV do Instrumento iasus Pode-se observar que são dois tipos de escalas diferentes, utilizadas de acordo com a pergunta realizada. O intuito desta variação é que se tenham mais alternativas de resposta para a análise dos fatores externos ao software avaliado. 3.7 Pesquisa de Campo A pesquisa de campo teve dois grandes objetivos: a) Verificar junto á amostra escolhida se o instrumento iasus é um instrumento simples de se manusear e útil para avaliar a satisfação de usuários de produtos de software; b) r o instrumento iasus em um ambiente real, junto a dois diferentes softwares para avaliar o nível de satisfação de seus usuários e identificar oportunidades de melhoria em tais produtos Teste Piloto do Instrumento iasus Depois de finalizada a construção do instrumento iasus, quando se chegou ao modelo de quatro partes e cinqüenta e três perguntas, conforme apresentado na Seção 3.6.2, decidiu-se fazer um teste piloto antes de se realizar a pesquisa de campo, com o intuito de: a) identificar falhas e/ou oportunidades de melhoria no

79 79 instrumento; b) saber se o instrumento é simples de se manusear; c) saber se o instrumento é útil para avaliar a satisfação de usuários de produtos de software. Para tal, foram selecionados dois produtos a ser avaliados com o instrumento iasus, o software SysOKA e o ERP P. Para cada um desses softwares foram selecionadas três pessoas que faziam uso dos mesmos, ou seja, eram usuários finais dos produtos citados. Foi enviado um aos usuários do software SysOKA e do ERP P, convidando-os a participar no teste do instrumento, conforme Apêndice B. Anexados ao foram enviados uma planilha Excel com o instrumento iasus, um documento com instruções para a realização do teste e uma segunda planilha Excel com um questionário para avaliação do instrumento de pesquisa, conforme Apêndices A, C e D respectivamente. Os entrevistados deveriam devolver por a planilha do instrumento iasus e a planilha de avaliação do instrumento preenchidas. As seis pessoas selecionadas devolveram preenchidos os documentos do teste piloto, a Tabela 19 apresenta os resultados tabulados. Tabela 19: Resultado do pré-teste: avaliação do instrumento iasus Pergunta Respostas Sim Não As perguntas do Instrumento de Pesquisa estão claras para você? 83,33% 16,67% Você teve dificuldade em responder alguma pergunta? 16,67% 83,33% O formato do Instrumento de Pesquisa facilita responder as perguntas? 0,00% 100,00% A escala de avaliação do Instrumento de Pesquisa, que vai de " " a " ", está compreensível? 100,00% 0,00% Você acha que as perguntas do Instrumento de Pesquisa estão bem formuladas e são completas para avaliar seu grau de satisfação com o software que está sendo avaliado? 100,00% 0,00% A explicação sobre o intuito do estudo, o que será feito com os dados obtidos e como responder o instrumento de pesquisa foi clara e completa? 83,33% 16,67% Para todos os participantes do teste piloto o formato do instrumento iasus dificultou no momento de responder as perguntas, pois o instrumento foi enviado em formato de uma planilha Microsoft Excel. Na pesquisa de campo o formato de apresentação do instrumento iasus seria modificado. Para o restante das perguntas

80 80 o instrumento teve uma avaliação muito boa, variando de 83,33% a 100%, fazendo com que não houvesse necessidade de alterações ou ajustes significativos no instrumento iasus ção da Pesquisa de Campo O objetivo da pesquisa de campo foi verificar, junto a uma amostra de usuários finais dos softwares SysOKA e ERP P em um ambiente real, a aplicabilidade do instrumento iasus para obter o nível de satisfação de tais usuários e identificar oportunidades de melhoria para os citados softwares. Nesta Seção será apresentado um roteiro de como aplicar o instrumento iasus e a aplicação da pesquisa de campo junto aos usuários finais dos softwares SysOKA e ERP P Como r o Instrumento iasus Um dos principais objetivos deste trabalho é prover a empresa desenvolvedora do software avaliado subsídios para implementar melhorias em seu produto, de maneira direcionada as necessidades dos usuários finais. Sugerindo então, que a aplicação deste instrumento devesse partir da empresa desenvolvedora do produto, o que não é correto, pois a empresa cliente, a que utiliza o software também pode fazer a aplicação do instrumento, inclusive dando o devido direcionamento a interpretação dos resultados de acordo com seu ambiente e contexto. Nas próximas seções serão apresentadas as etapas para aplicação do instrumento iasus Preparando a Avaliação Quer seja a empresa desenvolvedora do software ou a empresa cliente do produto que está tomando a iniciativa da avaliação da satisfação dos seus usuários, deverá ser definido um avaliador para conduzir a aplicação da avaliação do software. O ideal é que o avaliador seja um profissional da área de qualidade de software, por já ter familiaridade com requisitos de qualidade, modelos e métodos de avaliação, o que pode trazer mais credibilidade ao resultado da avaliação.

81 81 O avaliador deverá selecionar os usuários que participarão da pesquisa, identificando se será necessário haver alguma segmentação por nível hierárquico, escolaridade, departamento ou outro critério, com o intuito de se ter uma contribuição a mais na análise dos resultados. Uma vez identificado o público alvo da pesquisa o avaliador deverá preparar o questionário iasus, acrescentando o nome do software a ser avaliado nos enunciados para que o entrevistado se situe melhor no contexto da pesquisa. O questionário poderá ser disponibilizado em algum web site ou então ser utilizada alguma ferramenta para aplicação de questionários. Quando então o avaliador irá preparar um informando como acessar o questionário, o teor da pesquisa, o prazo para resposta e convidando os usuários selecionados a participar Tabulando os Dados Coletados Após expirado o prazo para que os usuários selecionados respondam o questionário, o avaliador fará a tabulação dos dados coletados, gerando os gráficos e tabelas necessários a etapa de análise para conclusão da avaliação. Todo o processo de manuseio dos dados coletados está descrito na Seção Analisando os Dados Coletados Estando o avaliador de posse dos gráficos, tabelas e demais dados pertinentes a avaliação, deverá iniciar a análise dos dados conforme descrito na Seção 4.1. Nesta etapa o avaliador produzirá os resultados que irão compor o relatório final da avaliação da satisfação dos usuários do software Apresentando os Resultados O avaliador deverá elaborar um relatório final com os resultados da avaliação da satisfação dos usuários do software avaliado. Sugere-se o modelo apresentado no Apêndice F, que é composto de quatro partes: I. Introdução: contém informações sobre o instrumento iasus, o objetivo da avaliação, empresa e público alvo, e perfil dos entrevistados;

82 82 II. Conceitos: uma vez que os dados são apresentados com certo viés técnico, busca-se nesta seção um alinhamento acerca dos termos técnicos utilizados ao longo do relatório; III. Resultados: os dados compilados da aplicação do instrumento iasus são apresentados de forma gráfica nesta seção, e uma análise sobre o resultado da satisfação dos usuários do software avaliado é realizada de forma analítica, ou seja, cada uma das Subcaracterísticas avaliadas pelo instrumento. Também se levará em conta as respostas dadas a análise de fatores externos e as críticas e sugestões, que também são apresentadas de forma aberta nesta seção; IV. Conclusão: um parecer final sobre a avaliação da satisfação dos usuários finais com o software avaliado é emitido pelo responsável por conduzir a avaliação. Concluído o relatório, o avaliador realizará a entrega do mesmo ao solicitante da avaliação, e fará a apresentação formal dos resultados obtidos. A Figura 20 ilustra as etapas para aplicação do instrumento iasus. Figura 13: Etapas para aplicação do instrumento iasus

83 ção do Instrumento iasus: Software SysOKA A aplicação do instrumento iasus junto a usuários do software SysOKA foi realizada seguindo o roteiro apresentado na Seção , e para tal, será considerado que os desenvolvedores do software SysOKA são os solicitantes da avaliação de seus produtos, e o autor deste trabalho foi selecionado como avaliador. a) Preparação da Avaliação: Para automatizar a aplicação do questionário do instrumento iasus foi efetuado o cadastro junto ao LimeSurvey 6. Todo o questionário anteriormente em planilha Excel foi cadastrado no LimeSurvey, ou seja, as cinqüenta e três questões que compõem o instrumento iasus. Algumas telas de exemplo do questionário hospedado naquele web site podem ser vistas no Apêndice G, e o questionário completo está no Apêndice A. Uma vez selecionado o software objeto da pesquisa, e o questionário estar pronto para ser respondido, o passo seguinte foi selecionar os entrevistados. O correto neste tipo de pesquisa seria selecionar o contexto de uso para aplicação do instrumento, que poderia ser a escolha de uma única organização ou até mesmo uma determinada área ou um nível hierárquico dentro da organização selecionada, para evitar que particularidades no uso do produto contaminem os resultados. Devido a particularidades do SysOKA, que normalmente é utilizado por uma ou duas pessoas da área de Gestão do Conhecimento das organizações, o que poderia ser uma quantidade considerada pequena de respondentes para se realizar uma pesquisa, optou-se por selecionar usuários de organizações distintas, tanto do setor público quanto privado. O único requisito para participação na pesquisa é que a pessoa fizesse uso do SysOKA, o que caracterizaria ser um usuário final do produto. 6 LimeSurvey é um web site especializado na hospedagem de questionários, cujo endereço é

84 84 Ainda por conta das características deste produto, o avaliador fez uma adaptação da primeira pergunta do instrumento iasus, mudando a escala de tempo de uso do software, para uma escala de quantidade de vezes que se usou o SysOKA, conforme pode ser visto no Item 2 do Apêndice G. O questionário completo está no Apêndice A. O avaliador determinou o período de 18/05/2009 a 06/06/2009 para que os usuários finais do SysOKA respondessem a pesquisa. Para dar mais comodidade aos respondentes e facilitar a coleta dos dados, o avaliador disponibilizou o questionário do instrumento iasus em um web site. Foi elaborado e enviado um convite aos respondentes, ou seja, aos usuários finais do software SysOKA, solicitando a participação na avaliação, conforme pode ser visto no Apêndice E. No convite também consta o endereço do web site onde se encontrava hospedado o questionário do instrumento iasus. b) Tabulação dos Dados Coletados Após expirado o prazo para que os usuários selecionados respondessem o questionário, o link da pesquisa foi desativado e as respostas foram coletadas, sendo que, foram obtidas 49 respostas, mas apenas 17 estavam completas, podendo, portanto, ser aproveitadas para a avaliação. As respostas consideradas incompletas foram apenas registros de entrada no questionário, possivelmente realizadas por pessoas que receberam o convite a participação da pesquisa, e por qualquer motivo que seja não se dispuseram a responder o questionário. Os dados coletados foram tabulados utilizando-se o software Microsoft Excel e seguindo os procedimentos expostos na Seção 3.8. Foram gerados os gráficos e as tabelas que serão utilizados na análise da avaliação da satisfação dos usuários finais do software SysOKA. A relação completa dos gráficos e tabelas produzidos nesta pesquisa de campo e utilizados na análise são apresentados no Apêndice F. Depois de concluída a etapa de tabulação dos dados coletados, geração dos gráficos e tabelas, deu-se início ao processo de interpretação de todo o material gerado, seguindo as orientações apresentadas na Seção 4.1. No Capítulo 4 serão

85 85 apresentados os resultados obtidos. O relatório completo com o resultado da análise dos dados pode ser visto no Apêndice F ção do Instrumento iasus: ERP P A aplicação do instrumento iasus junto a usuários do ERP P foi realizada seguindo o roteiro apresentado na Seção , e para tal, será considerado que os desenvolvedores do ERP P são os solicitantes da avaliação de seus produtos, e o autor deste trabalho foi selecionado como avaliador. Embora a empresa usuária do ERP P onde foi conduzida a pesquisa tenha mais de dois mil funcionários trabalhando em suas instalações, não foi possível concentrar a pesquisa dentro de um único departamento, ou mesmo realizá-la segmentando por departamentos, o que poderia contribuir com a avaliação da satisfação dos usuários. Um módulo do software utilizado pelo departamento A que estivesse melhor que outro módulo utilizado pelo departamento B, poderia dar um viés indesejado a avaliação quando os dados fossem tabulados juntos, podendo direcionar os resultados para um nível de insatisfação, neutralidade ou mesmo de satisfação dos usuários que poderia não corresponder à realidade. Uma vez que a pesquisa não foi solicitada pela empresa, a realização da mesma se deu junto a usuários que demonstraram interesse em apoiar uma pesquisa academica, o que resultou em uma amostra de respondentes de mais de um departamento, portanto, com grande probabilidade de utilizarem módulos ou funcionalidades distintas do ERP P. O ERP P foi desenvolvido para satisfazer os mais complexos requisitos de negócio para empresas de diversos segmentos, sendo utilizado mundialmente. O Sistema tem módulos integrados de gestão de ativos, CRM, automação de serviços, gestão financeira, RH e suprimentos, dentre outros. a) Preparação da Avaliação: O primeiro passo do avaliador foi selecionar as pessoas que iriam responder ao questionário iasus, foram selecionados dezenove usuários de diferentes

86 86 departamentos da Montadora de Veículos. Uma vez tendo identificado os usuários finais do software, estava então selecionado o público alvo da avaliação. O avaliador determinou o período de 08/06/2009 a 30/06/2009 para que os usuários finais do ERP P respondessem a pesquisa. Para dar mais comodidade aos respondentes e facilitar a coleta dos dados, o avaliador disponibilizou o questionário do instrumento iasus em um web site. Foi elaborado e enviado um convite aos respondentes, ou seja, aos usuários finais do ERP P, solicitando a participação na avaliação, conforme pode ser visto no Apêndice I. No convite também consta o endereço do web site onde se encontrava hospedado o questionário do instrumento iasus. b) Tabulação dos Dados Coletados Após expirado o prazo para que os usuários selecionados respondessem o questionário, o link da pesquisa foi desativado e as respostas foram coletadas, sendo que foram obtidas 11 respostas. Os dados coletados foram tabulados utilizando-se o software Microsoft Excel e seguindo os procedimentos expostos na Seção 3.8. Foram gerados os gráficos e as tabelas que serão utilizados na análise da avaliação da satisfação dos usuários finais do ERP P. A relação completa dos gráficos e tabelas produzidos nesta pesquisa de campo e utilizados na análise são apresentados no Apêndice H. Depois de concluída a etapa de tabulação dos dados coletados, geração dos gráficos e tabelas, deu-se início ao processo de interpretação de todo o material gerado, seguindo as orientações apresentadas na Seção 4.1. No Capítulo 4 serão apresentados os resultados obtidos. O relatório completo com o resultado da análise dos dados pode ser visto no Apêndice H.

87 Tabulação e Apresentação dos Dados Coletados Para que se possa analisar os dados coletados com o instrumento iasus, e consequentemente avaliar a satisfação dos usuários com o software avaliado, é preciso tabular os dados, gerar gráficos e tabelas de apoio, utilizando para tal o software Microsoft Excel. Todo este processo será apresentado nas próximas seções Tipo de Gráfico Utilizado Os gráficos são uma forma de sumarizar uma grande quantidade de dados, proporcionando visualizações de informações e discernimento da relação entre diferentes variáveis, fazendo isso muito melhor que outras formas de visualização, como as tabelas (LARKIN & SIMON, 1987). A utilização de gráficos é uma forma amigável de transmitir informações para os usuários. Na grande maioria das vezes, a transmissão de informações dos sistemas para os usuários é feita através de tabelas com uma quantidade muito grande de dados, ou por outras formas de apresentação pouco atrativas. O papel dos gráficos é sintetizar tais informações e traduzi-las para os usuários de maneira simples e intuitiva. Porém, é importante salientar que os gráficos utilizados devem ser construídos de forma adequada, pois de outra maneira estarão transmitindo informações irrelevantes ou até mesmo incorretas (MILLER, 1998). Foram escolhidos gráficos de barra para retratar os dados tabulados da pesquisa realizada com o instrumento iasus, pois são normalmente usados para retratar categorias, proporção e percentuais. Segundo Tufte (2001), as pessoas normalmente são capazes de julgar o tamanho de barras de forma mais precisa do que áreas ou ângulos Proposta para Construção dos Gráficos Os gráficos das Características têm uma pequena diferença em sua construção quando comparados com os gráficos das Subcaracterísticas, por isso eles serão apresentados em separado. Com o intuito de facilitar o entendimento do procedimento acerca da construção dos gráficos, será apresentada inicialmente a fórmula para obtenção do percentual das Subcaracterísticas.

88 Fórmula para as Subcaracterísticas Deve-se estabelecer uma pontuação máxima para as Subcaracterísticas, lembrando que cada Subcaracterística tem um número determinado de questões, conforme Tabela 12. A fórmula utilizade é: PontuaçãoMáxima = TotalEntrevistados * TotalQuestõesSubcaracterística Total de Respondentes: Total de Questões: Pontuação Máxima: Figura 14: Exemplo de Pontuação Máxima para Subcaracterística Acurácia De acordo com o exposto na Figura 14, o Total de Respondentes é a quantidade total de entrevistados, mas apenas dos que responderam totalmente o questionário. O Total de Questões irá variar de acordo com a Subcaracterística avaliada, pois cada uma tem um número diferente de questões associadas, sendo que, neste exemplo a Subcaracterística Acurácia tem três questões associadas. Uma vez obtida à pontuação máxima para determinada Subcaracterística, o próximo passo é contar quantas ocorrências houve para cada uma das opções de resposta possíveis. O percentual final para as escalas,, Indiferente,, e Não se é obtido pela fórmula abaixo: PercentualRespostasEscala = TotalRespostasEscala / PontuaçãoMaxima Total Respostas: Percentual Escala: TI PI IN PS TS NA ,00% 0,00% 15,69% 39,22% 43,14% 1,96% Figura 15: Exemplo de cálculo do percentual da Subcaracterística Acurácia O procedimento para todas as Subcaracterísticas segue o que foi relatado acima, o único ponto de atenção é para o total de questões, que varia de acordo com a Subcaracterística.

89 Fórmula para as Características Uma vez que se tenha calculado o percentual de satisfação para todas as Subcaracterísticas, poderá ser iniciado o cálculo do percentual de satisfação para as Características. Cada Característica deve ser calculada separadamente, pois a quantidade de Subcaracterísticas influenciará no cálculo. Da mesma forma, cada uma das escalas também deverá ser calculada separadamente. A fórmula utilizada é: (TotalRespostasSubcaracterística1 + TotalRespostasSubcaracterísticaN) / (PontuaçãoMáximaSubcaracterística1 + PontuaçãoMaximaSubcaracterísticaN) Funcionalidade Acurácia Adequação Indiferente Não se ,92% 4,58% 15,03% 39,22% 30,72% 6,54% Figura 16: Exemplo de cálculo do percentual da Característica Funcionalidade O procedimento para todas as Características segue o que foi relatado acima, o único ponto de atenção é para a quantidade de Subcaracterísticas que compõe a Característica, conforme pode ser observado na Tabela Gráficos Propostos para Utilização na Análise Conforme dito anteriormente, todos os gráficos utilizados na análise são do tipo Barra, e serão apresentados e comentados nas seções seguintes Gráfico: Índice Geral de Satisfação Este gráfico representa o índice geral de satisfação dos entrevistados acerca do software avaliado. É obtido através de uma única pergunta da Parte II do instrumento iasus: Qual seu grau de satisfação em relação ao software que está sendo avaliado?. Um exemplo do gráfico pode ser visto na Figura 17.

90 90 Satisfação dos Usuários do Software Avaliado 100,00% 80,00% 60,00% 40,00% 20,00% 0,00% Indiferente Índice de Satisfação Figura 17: Exemplo do gráfico índice geral de satisfação A construção deste gráfico é realizada de acordo com a fórmula apresentada na Seção Gráfico: Satisfação por Características Este gráfico representa o grau de satisfação por Característica, dos entrevistados acerca do software avaliado. É construído tendo como referência a fórmula apresentada na Seção Um exemplo do gráfico pode ser visto na Figura 18. Satisfação dos Usuários por Característica 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Indiferente Funcionalidade Usabilidade Eficiência Figura 18: Exemplo do gráfico satisfação por Característica

91 Gráfico: Satisfação por Subcaracterística Os gráficos que representam as Subcaracterísticas seguem o mesmo modelo/layout, e são construídos tendo como referência a fórmula apresentada na Seção Um exemplo do gráfico pode ser visto na Figura 19. Funcionalidade: subcaracterística Acurácia 45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% 0,00% 0,00% 15,69% Indiferente 39,22% 43,14% Figura 19: Exemplo do gráfico satisfação por Subcaracterística 3.9 Interpretando os Dados Depois de concluída a etapa de tabulação dos dados coletados, geração dos gráficos e tabelas, inicia-se o processo de interpretação dos mesmos, com o intuito de identificar o nível de satisfação dos usuários do software avaliado. O avaliador, ou seja, a pessoa responsável pela avaliação terá em mãos o seguinte material que lhe servirá como subsídio à avaliação: Um gráfico consolidado de satisfação dos usuários; Um gráfico consolidado de satisfação comparando as Características; Três gráficos demonstrando as Características individualmente; Oito gráficos individuais demonstrando as Subcaracterísticas; Onze tabelas apresentando a tabulação das variáveis de ambiente; Relação de comentários, críticas e sugestões dos entrevistados sobre o software avaliado.

92 92 Inicialmente o avaliador deverá ver as tabelas que apresentam a tabulação das variáveis de ambiente, ou seja, deverá identificar se algum fator externo ao software obteve uma baixa classificação e poderá impactar negativamente na satisfação dos usuários finais com o produto avaliado. Em seguida deverá ler os comentários, críticas e sugestões feitas pelos entrevistados e, se possível, separálos por tipo de assunto, como: melhoria, usabilidade, ambiente externo e etc. Os gráficos apresentam de forma direta o grau de satisfação dos usuários, quer seja com o software como um todo, ou se aprofundando a níveis com maior grau de detalhamento. Considerando a soma dos s e s, o avaliador pode emitir seu parecer utilizando a seguinte escala: 100%: não há nada a ser melhorado no quesito; De 90% a 99%: é possível melhorar, mas deve-se avaliar o custo benefício associado, já que é uma margem de melhoria pequena e pode não ser perceptível ao usuário final; De 75% a 89%: é uma boa oportunidade de melhoria do produto no quesito em questão, uma vez que pode ser perceptível ao usuário final a evolução implementada, aumentando assim seu nível de satisfação; Abaixo de 75%: a empresa desenvolvedora do software deve tomar uma ação que traga melhorias imediatas para o produto no quesito avaliado, sob pena de no futuro ter impactada a avaliação de outros quesitos do software e, como conseqüência, uma possível descontinuação de seu produto na empresa cliente. A escala utilizada acima foi baseada na Norma ISO/IEC , onde diz que uma escala pode assumir diferentes níveis de pontuação, conforme ilustrado na Figura 20. O nível de pontuação deve ter um valor-limite entre o que seja satisfatório e insatisfatório (GUERRA & COLOMBO, 2009, p.186).

93 93 Figura 20: Níveis de pontuação para as medidas Fonte: Guerra e Colombo, 2009, p.186 No momento de emitir seu parecer em relação a um determinado percentual apresentado para uma Característica ou Subcaracterística, quer seja alto ou baixo, o avaliador deverá fazer uma análise subjetiva, lançando mão dos fatores externos e dos comentários, críticas e sugestões dos entrevistados, utilizando-os para corroborar e/ou identificar com maior detalhe a causa de uma possível insatisfação com o software avaliado Fidedignidade do Instrumento iasus Na Seção foi realizada uma explanação do que é e como pode ser medida a fidedignidade de um instrumento. Agora que se tem a pesquisa de campo concluída, será executado o teste de fidedignidade do instrumento iasus. Será utilizado o coeficiente de Spearman-Brown, que fornecerá uma predição ou estimativa da fidedignidade do instrumento iasus, medindo a correlação entre duas metades do instrumento. Esse método será utilizado devido sua rapidez e facilidade de aplicação, já que utiliza uma única interação do instrumento a ser

94 94 avaliado, separando as respostas de cada entrevistado em duas metades e então realizando a correlação das mesmas. Conforme relatado na Seção 2.2.4, o coeficiente de fidedignidade pode ser interpretado como uma correlação que ao estar perto de +1 indica alta fidedignidade, e perto de zero indica ausência de fidedignidade (MOREIRA & ROSA, 2007, p.20). O instrumento iasus está dividido em quatro partes, mas apenas uma parte, a Parte II, é utilizada para avaliar a satisfação de usuários. As outras três partes servem de apoio a análise e não serão consideradas na medição da fidedignidade do instrumento. A Parte II é composta de quarenta e uma questões, mas a questão de número 41 também é utilizada apenas para apoio a análise e não será considerada na medição da fidedignidade do instrumento. Portanto, será realizada a medição da fidedignidade apenas da Parte II do instrumento e sobre quarenta questões. Para as escalas utilizadas nas respostas as questões do instrumento foram atribuídos os seguintes valores: = 5 = 4 Indiferente = 3 = 2 = 1 Não se = 0 As repostas dos entrevistados foram pontuadas conforme demonstrado acima e divididas em duas partes, questões de 1 a 20 e questões de 21 a 40, e em seguida foram somadas. Esse procedimento foi realizado duas vezes, uma vez para cada uma das pesquisas de campo realizadas, conforme pode ser visto nas Tabela 20 e 21.

95 95 Tabela 20: Divisão das respostas dos entrevistados e somatório dos valores SysOKA Soma Soma Metade-1 Metade-2 Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Tabela 21: Divisão das respostas dos entrevistados e somatório dos valores ERP P Soma Soma Metade-1 Metade-2 Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Entrevistado Uma vez que foram elaboradas as tabelas apresentadas acima, o próximo passo foi aplicar a fórmula de Spearman-Brown sobre o resultado da divisão ao meio do questionário e soma dos valores, o resultado pode ser visto nas Tabelas 22 e 23. Para realizar toda a tabulação dos dados, cálculos e aplicação da fórmula de Spearman-Brown foi utilizado o software Microsoft Excel versão Tabela 22: Fidedignidade pelo coeficiente de correlação de Spearman-Brown SysOKA Coeficiente de correlação de Spearman-Brown: 0,84 Tabela 23: Fidedignidade pelo coeficiente de correlação de Spearman-Brown ERP P Coeficiente de correlação de Spearman-Brown: 0,99

96 96 Os valores de 0,84 e 0,99 resultante do cálculo do coeficiente de correlação de Spearman-Brown para as duas pesquisas de campo realizadas, demonstra a correlação entre os dados obtidos, caracterizando o grau de fidedignidade do instrumento iasus, que conforme colocado por Hayes (2003), quando esse valor é maior que 0,80, o instrumento de medição utilizado é confiável. Tendo o coeficiente de correlação de Spearman-Brown sido aplicado ao instrumento iasus neste trabalho, não há uma obrigatoriedade de nova interação a cada aplicação do instrumento, mesmo sendo outro software ou contexto, mas o avaliador poderá fazê-lo para corroborar os resultados aqui apurados, caso seja de seu interesse.

97 97 4. APRESENTAÇÃO E ANÁLISE DOS RESULTADOS Este capítulo apresenta os resultados obtidos com a aplicação do instrumento iasus, realizada junto a usuários finais dos softwares SysOKA e ERP P. A interpretação dos dados coletados seguiu o roteiro apresentado na Seção Satisfação dos Usuários: software SysOKA Será apresentado a seguir o resultado de cada uma das sentenças que compõem a Parte II do instrumento iasus, onde poderá ser visto no detalhe a classificação dada pelos respondentes durante a avaliação do software SysOKA: 1) Funcionalidade a) Acurácia Tabela 24: Sentenças que compõem a Subcaracterística Acurácia - SysOKA Sentença: Realização correta de todas as tarefas a que se propõe Indiferente Não se 0,00% 0,00% 5,88% 35,29% 58,82% 0,00% Sentença: Dar mais precisão ao seu trabalho Indiferente Não se 0,00% 0,00% 11,76% 70,59% 17,65% 0,00% Sentença: Integridade dos dados do software após atualizações Indiferente Não se 0,00% 0,00% 29,41% 17,65% 52,94% 0,00% Média da Subcaracterística Acurácia Indiferente Não se 0,00% 0,00% 15,69% 41,18% 43,14% 0,00%

98 98 b) Adequação Tabela 25: Sentenças que compõem a Subcaracterística Adequação - SysOKA Sentença: Estruturação da inteface de forma a agrupar as tarefas em áreas operacionais, mantendo assim, a sequência lógica do trabalho a ser realizado Indiferente Não se 0,00% 0,00% 23,53% 52,94% 23,53% 0,00% Sentença: Funcionalidades para satisfazer as necessidades do seu trabalho Indiferente Não se 0,00% 0,00% 5,88% 64,71% 29,41% 0,00% Sentença: Disponibilização de Help contextualizado em qualquer parte do software ao se pressionar F1 Indiferente Não se 35,29% 17,65% 5,88% 35,29% 5,88% 0,00% Sentença: Menus e lista de informações organizados de forma lógica Indiferente Não se 0,00% 11,76% 0,00% 58,82% 29,41% 0,00% Sentença: Informação de andamento das tarefas que estão sendo realizadas Indiferente Não se 0,00% 0,00% 29,41% 41,18% 29,41% 0,00% Sentença: Mensagens que ajudam na prevenção a erros do usuário Indiferente Não se 0,00% 11,76% 23,53% 35,29% 29,41% 0,00% Média da Subcaracterística Adequação Indiferente Não se 5,88% 6,86% 14,71% 48,04% 24,51% 0,00%

99 99 2) Usabilidade a) Inteligibilidade Tabela 26: Sentenças que compõem a Subcaracterística Inteligibilidade - SysOKA Sentença: Apresentação clara e de fácil entendimento das informações Indiferente Não se 0,00% 11,76% 5,88% 41,18% 41,18% 0,00% Sentença: Simplicidade para realização de suas atividades Indiferente Não se 0,00% 0,00% 11,76% 47,06% 41,18% 0,00% Sentença: Utilização de códigos e termos técnicos condizentes com o trabalho a ser realizado Indiferente Não se 0,00% 5,88% 5,88% 64,71% 23,53% 0,00% Sentença: É fácil de entender e reconhecer a estrutura, a lógica e a aplicabilidade do software Indiferente Não se 0,00% 5,88% 11,76% 58,82% 23,53% 0,00% Sentença: O texto apresentado na interface do software não dá margem a interpretações ambíguas Indiferente Não se 5,88% 23,53% 0,00% 64,71% 5,88% 0,00% Sentença: Confiança de que está usando corretamente o software Indiferente Não se 0,00% 5,88% 0,00% 70,59% 23,53% 0,00% Sentença: A documentação do software tem uma organização lógica e evolutiva, aumentando gradativamente o nível de complexidade da informação que lhe é apresentada. Facilita-se assim, o aprendizado e entendimento da operação do software Indiferente Não se 29,41% 11,76% 17,65% 35,29% 5,88% 0,00% Sentença:

100 100 O manual do usuário demonstra as principais atividades a serem realizadas com o uso do software, de modo que se consiga explorar bem suas funcionalidades Indiferente Não se 29,41% 5,88% 5,88% 47,06% 11,76% 0,00% Média da Subcaracterística Inteligibilidade Indiferente Não se 8,09% 8,82% 7,35% 53,68% 22,06% 0,00% b) Apreensibilidade Tabela 27: Sentenças que compõem a Subcaracterística Apreensibilidade - SysOKA Sentença: Tempo requerido para o aprendizado do software Indiferente Não se 0,00% 11,76% 17,65% 35,29% 35,29% 0,00% Sentença: Sistema de Help e tutoriais capaz de esclarecer todas as suas dúvidas Indiferente Não se 35,29% 11,76% 5,88% 47,06% 0,00% 0,00% Sentença: A documentação do software é clara e precisa Indiferente Não se 29,41% 17,65% 23,53% 29,41% 0,00% 0,00% Média da Subcaracterística Apreensibilidade Indiferente Não se 21,57% 13,73% 15,69% 37,25% 11,76% 0,00% c) Operacionalidade Tabela 28: Sentenças que compõem a Subcaracterística Operacionalidade - SysOKA Sentença: A forma de realizar uma tarefa no software está alinhada a forma que você organiza seu trabalho Indiferente Não se 0,00% 5,88% 35,29% 41,18% 17,65% 0,00% Sentença:

101 101 O software possui comportamento semelhante em situações semelhantes, ou seja, solicita do usuário ações similares para tarefas similares Indiferente Não se 0,00% 0,00% 0,00% 47,06% 52,94% 0,00% Sentença: Normalmente o software faz o que você espera que ele deveria fazer Indiferente Não se 0,00% 5,88% 5,88% 29,41% 58,82% 0,00% Sentença: Completo entendimento do que deve ser feito em todas as partes do software Indiferente Não se 0,00% 5,88% 11,76% 64,71% 17,65% 0,00% Sentença: Navegar em distintos níveis do software sem se perder ou desorientar Indiferente Não se 0,00% 0,00% 5,88% 47,06% 47,06% 0,00% Sentença: É mantido um padrão de cores, botões e mensagens em todo o software Indiferente Não se 0,00% 0,00% 5,88% 17,65% 76,47% 0,00% Sentença: Os botões são todos de tamanho e forma similiar em todo o software Indiferente Não se 0,00% 0,00% 11,76% 47,06% 41,18% 0,00% Sentença: Cada janela tem um título que a identifica claramente Indiferente Não se 0,00% 0,00% 11,76% 47,06% 41,18% 0,00% Sentença: A interface do software informa ao usuário sobre o que um botão, menu, ícone ou caixa de diálogo faz ao se posicionar o cursor do mouse sobre ele Indiferente Não se 35,29% 0,00% 5,88% 35,29% 23,53% 0,00% Média da Subcaracterística Operacionalidade Indiferente Não se 3,92% 1,96% 10,46% 41,83% 41,83% 0,00%

102 102 d) Atratividade Tabela 29: Sentenças que compõem a Subcaracterística Atratividade - SysOKA Sentença: O software utiliza de uma linguagem instrutiva, polida, neutra e não agressiva Indiferente Não se 0,00% 0,00% 11,76% 17,65% 70,59% 0,00% Sentença: Atratividade e interface amigável Indiferente Não se 0,00% 5,88% 5,88% 23,53% 64,71% 0,00% Sentença: Navegação simples entre os menus e itens de menu Indiferente Não se 0,00% 0,00% 5,88% 35,29% 58,82% 0,00% Sentença: As telas do software utilizam tipos e tamanhos de letras de fácil visualização Indiferente Não se 0,00% 0,00% 5,88% 35,29% 58,82% 0,00% Sentença: As cores são utilizadas com equilíbrio, ou seja, são bem distribuídas evitando assim poluição visual Indiferente Não se 0,00% 0,00% 5,88% 52,94% 41,18% 0,00% Média da Subcaracterística Atratividade Indiferente Não se 0,00% 1,18% 7,06% 32,94% 58,82% 0,00% 3) Eficiência a) Tempo Tabela 30: Sentenças que compõem a Subcaracterística Tempo - SysOKA Sentença: Resposta rápida as requisições de consultas e relatórios Indiferente Não se 0,00% 5,88% 0,00% 47,06% 47,06% 0,00% Sentença:

103 103 Resposta rápida as entradas realizadas Indiferente Não se 0,00% 0,00% 0,00% 52,94% 47,06% 0,00% Sentença: Tempo gasto na execução das tarefas Indiferente Não se 0,00% 29,41% 5,88% 47,06% 17,65% 0,00% Média da Subcaracterística Tempo Indiferente Não se 0,00% 11,76% 1,96% 49,02% 37,25% 0,00% b) Recursos Tabela 31: Sentenças que compõem a Subcaracterística Recursos - SysOKA Sentença: Otimização do seu trabalho, criando condições mais favoráveis para realização do mesmo Indiferente Não se 0,00% 0,00% 11,76% 64,71% 23,53% 0,00% Sentença: Tempo gasto para localizar funcionalidades ou ferramentas dentro do software Indiferente Não se 0,00% 11,76% 11,76% 70,59% 5,88% 0,00% Sentença: Quantidade de passos para executar as tarefas Indiferente Não se 0,00% 17,65% 11,76% 41,18% 29,41% 0,00% Média da Subcaracterística Recursos Indiferente Não se 0,00% 9,80% 11,76% 58,82% 19,61% 0,00% O Gráfico 1 e a Tabela 32 apresentam uma visão do quão satisfeitos estão os usuários do software SysOKA em relação as Características Funcionalidade, Usabilidade e Eficiência, que compõem a análise do grau de Satisfação geral dos usuários do software avaliado.

104 104 Satisfação dos Usuários por Característica 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Indiferente Funcionalidade Usabilidade Eficiência Gráfico 1: Satisfação dos usuários por Característica - SysOKA Tabela 32: Satisfação dos usuários por Característica - SysOKA Indiferente Funcionalidade 3,92% 4,58% 15,03% 39,22% 30,72% Usabilidade 6,59% 5,41% 9,41% 39,29% 35,29% Eficiência 0,00% 10,78% 6,86% 50,98% 28,43% Média Geral 3,50% 6,92% 10,43% 43,16% 31,48% Efetuando-se uma análise dentro das Características, nota-se que é muito boa a aceitação do SysOKA, mas é possível observar que existem pontos de melhoria para o software, onde o índice de s e s estão em torno de 10%. Portanto, é necessário analisar as Subcaracterísticas para identificar se esse percentual de insatisfação está restrito a pontos específicos do software ou a fatores externos. Tabela 33: Fatores externos ao software avaliado - SysOKA O software que está sendo avaliado foi implantado em substituição a algum outro software ou processo manual que você utilizava anteriormente? Não Sim Não se 70,59% 5,88% 11,76% 11,76% Você considera que as necessidades dos usuários foram levadas em consideração no desenvolvimento deste software? Não Sim Não se 5,88% 17,65% 47,06% 29,41% Como você classifica o treinamento recebido para utilizar o software? Não se Fraco Regular Bom Ótimo

105 105 5,88% 29,41% 17,65% 0,00% 47,06% Como você classifica seu nível de experiência no uso de sistemas computacionais? Fraco Regular Bom Ótimo Não se 0,00% 17,65% 23,53% 58,82% 0,00% Como você classifica seu nível de motivação com as tarefas que desempenha usando o software em questão? Fraco Regular Bom Ótimo Não se 0,00% 5,88% 35,29% 41,18% 17,65% Como você classifica as condições do local de trabalho para a execução das tarefas que dependem do software? Fraco Regular Bom Ótimo Não se 23,53% 0,00% 23,53% 41,18% 11,76% Como você classifica o nível do suporte prestado em caso de dúvidas ou problemas? Fraco Regular Bom Ótimo Não se 29,41% 11,76% 23,53% 5,88% 29,41% Como você classifica os meios ofertados ao usuário para apresentar sugestões de melhoria? Fraco Regular Bom Ótimo Não se 17,65% 35,29% 11,76% 5,88% 29,41% Em termos de velocidade de processamento, como você classifica os computadores usados com este software? Fraco Regular Bom Ótimo Não se 0,00% 11,76% 52,94% 29,41% 5,88% Como você classifica o seu grau de fluência no idioma em que o software é apresentado? Fraco Regular Bom Ótimo Não se 0,00% 0,00% 41,18% 52,94% 5,88% A Tabela 33 apresenta a tabulação dos fatores externos ao software, onde se pode notar que a pontuação dada a treinamento, suporte e necessidade dos usuários contempladas no software não foram muito boas, sendo classificadas como Fraco ou Regular para cerca de 70% dos respondentes da pesquisa. Os Gráficos 2, 3 e 4 apresentam uma visão analítica da Característica Funcionalidade, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do SysOKA no critério Funcionalidade.

106 106 Característica Funcionalidade 40,00% 35,00% 30,00% 25,00% 39,22% 30,72% 20,00% 15,00% 10,00% 5,00% 0,00% 3,92% 4,58% 15,03% Indiferente Gráfico 2: Índice de satisfação na Característica Funcionalidade - SysOKA Funcionalidade: subcaracterística Acurácia 45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% 0,00% 0,00% 15,69% Indiferente 39,22% 43,14% Gráfico 3: Característica Funcionalidade: Subcaracterística Acurácia - SysOKA Funcionalidade: subcaracterística Adequação 40,00% 35,00% 30,00% 25,00% 39,22% 24,51% 20,00% 15,00% 10,00% 5,00% 0,00% 5,88% 6,86% 14,71% Indiferente Gráfico 4: Característica Funcionalidade: Subcaracterística Adequação - SysOKA

107 107 Com a visualização individualizada das Subcaracterísticas Acurácia e Adequação, é possível observar que o principal ofensor na Característica Funcionalidade reside na Adequação do software SysOKA. O treinamento recebido para utilização do software foi classificado como fraco ou regular para cerca de 70% dos entrevistados, que também informaram ter utilizado o software no máximo dez vezes. O software SysOKA foi muito bem avaliado por seus usuários, remetendo a um índice de mais de 80% de satisfação com o produto, mas alguns pontos devem ser avaliados com a maior brevidade possível, pois podem impactar diretamente na qualidade percebida por seus usuários. Dentre os problemas encontrados que poderiam remeter a um baixo índice de satisfação dos usuários do software SysOKA, foi possível observar que o treinamento dado aos usuários não foi adequado, sendo o principal ofensor a satisfação de seus usuários, e conseqüentemente a qualidade do produto. Deve ser avaliado o serviço de suporte prestado aos usuários do software SysOKA, que embora não tenha afetado diretamente a satisfação dos mesmos, poderá ao longo do tempo afetar a percepção de qualidade do produto. Aprimorar os meios ofertados aos usuários para apresentar sugestões de melhoria no software SysOKA. Uma vez que os usuários tenham necessidades específicas atendidas pelo software dentro de um contexto de uso específico, aumenta a qualidade do produto percebida pelos mesmos. Considerando esses fatores, pode-se inferir que a Subcaracterística Adequação foi afetada devido o baixo nível de experiência no uso do SysOKA e o treinamento inadequado ofertado aos usuários. Portanto, orienta-se que sejam tomadas ações de treinamento, e que visem demonstrar a adequação do software à necessidade dos usuários. Foi criado um relatório para apresentação da avaliação do software SysOKA, que se encontra no Apêndice F. Neste relatório é apresentada uma análise completa quanto à satisfação dos usuários finais do SysOKA.

108 Satisfação dos Usuários: ERP P Será apresentado a seguir o resultado de cada uma das sentenças que compõem a Parte II do instrumento iasus, onde poderá ser visto no detalhe a classificação dada pelos respondentes durante a avaliação do ERP P: 1) Funcionalidade a) Acurácia Tabela 34: Sentenças que compõem a Subcaracterística Acurácia - ERP P Sentença: Realização correta de todas as tarefas a que se propõe Indiferente Não se 0,00% 18,18% 0,00% 63,64% 18,18% 0,00% Sentença: Dar mais precisão ao seu trabalho Indiferente Não se 0,00% 0,00% 0,00% 81,82% 18,18% 0,00% Sentença: Integridade dos dados do software após atualizações Indiferente Não se 9,09% 9,09% 0,00% 36,36% 45,45% 0,00% Média da Subcaracterística Acurácia Indiferente Não se 3,03% 9,09% 0,00% 60,61% 27,27% 0,00% b) Adequação Tabela 35: Sentenças que compõem a Subcaracterística Adequação - ERP P Sentença: Estruturação da inteface de forma a agrupar as tarefas em áreas operacionais, mantendo assim, a sequência lógica do trabalho a ser realizado Indiferente Não se 0,00% 0,00% 0,00% 81,82% 18,18% 0,00% Sentença: Funcionalidades para satisfazer as necessidades do seu trabalho

109 109 Indiferente Não se 0,00% 0,00% 0,00% 90,91% 9,09% 0,00% Sentença: Disponibilização de Help contextualizado em qualquer parte do software ao se pressionar F1 Indiferente Não se 36,36% 18,18% 0,00% 18,18% 27,27% 0,00% Sentença: Menus e lista de informações organizados de forma lógica Indiferente Não se 9,09% 0,00% 0,00% 63,64% 27,27% 0,00% Sentença: Informação de andamento das tarefas que estão sendo realizadas Indiferente Não se 9,09% 18,18% 18,18% 27,27% 27,27% 0,00% Sentença: Mensagens que ajudam na prevenção a erros do usuário Indiferente Não se 36,36% 18,18% 0,00% 18,18% 27,27% 0,00% Média da Subcaracterística Adequação Indiferente Não se 15,15% 9,09% 3,03% 50,00% 22,73% 0,00% 2) Usabilidade a) Inteligibilidade Tabela 36: Sentenças que compõem a Subcaracterística Inteligibilidade - ERP P Sentença: Apresentação clara e de fácil entendimento das informações Indiferente Não se 9,09% 0,00% 18,18% 27,27% 45,45% 0,00% Sentença: Simplicidade para realização de suas atividades Indiferente Não se 0,00% 18,18% 36,36% 36,36% 9,09% 0,00% Sentença:

110 110 Utilização de códigos e termos técnicos condizentes com o trabalho a ser realizado Indiferente Não se 0,00% 9,09% 0,00% 63,64% 27,27% 0,00% Sentença: É fácil de entender e reconhecer a estrutura, a lógica e a aplicabilidade do software Indiferente Não se 9,09% 0,00% 0,00% 72,73% 18,18% 0,00% Sentença: O texto apresentado na interface do software não dá margem a interpretações ambíguas Indiferente Não se 9,09% 9,09% 18,18% 36,36% 27,27% 0,00% Sentença: Confiança de que está usando corretamente o software Indiferente Não se 0,00% 9,09% 36,36% 36,36% 18,18% 0,00% Sentença: A documentação do software tem uma organização lógica e evolutiva, aumentando gradativamente o nível de complexidade da informação que lhe é apresentada. Facilita-se assim, o aprendizado e entendimento da operação do software Indiferente Não se 9,09% 9,09% 18,18% 45,45% 18,18% 0,00% Sentença: O manual do usuário demonstra as principais atividades a serem realizadas com o uso do software, de modo que se consiga explorar bem suas funcionalidades Indiferente Não se 18,18% 18,18% 18,18% 36,36% 9,09% 0,00% Média da Subcaracterística Inteligibilidade Indiferente Não se 6,82% 9,09% 18,18% 44,32% 21,59% 0,00%

111 111 b) Apreensibilidade Tabela 37: Sentenças que compõem a Subcaracterística Apreensibilidade - ERP P Sentença: Tempo requerido para o aprendizado do software Indiferente Não se 9,09% 18,18% 18,18% 27,27% 27,27% 0,00% Sentença: Sistema de Help e tutoriais capaz de esclarecer todas as suas dúvidas Indiferente Não se 27,27% 0,00% 18,18% 45,45% 9,09% 0,00% Sentença: A documentação do software é clara e precisa Indiferente Não se 9,09% 0,00% 45,45% 27,27% 18,18% 0,00% Média da Subcaracterística Apreensibilidade Indiferente Não se 15,15% 6,06% 27,27% 33,33% 18,18% 0,00% c) Operacionalidade Tabela 38: Sentenças que compõem a Subcaracterística Operacionalidade - ERP P Sentença: A forma de realizar uma tarefa no software está alinhada a forma que você organiza seu trabalho Indiferente Não se 9,09% 0,00% 27,27% 45,45% 18,18% 0,00% Sentença: O software possui comportamento semelhante em situações semelhantes, ou seja, solicita do usuário ações similares para tarefas similares Indiferente Não se 0,00% 18,18% 18,18% 54,55% 9,09% 0,00% Sentença: Normalmente o software faz o que você espera que ele deveria fazer Indiferente Não se 9,09% 36,36% 0,00% 36,36% 18,18% 0,00% Sentença: Completo entendimento do que deve ser feito em todas as partes do software

112 112 Indiferente Não se 0,00% 18,18% 45,45% 18,18% 18,18% 0,00% Sentença: Navegar em distintos níveis do software sem se perder ou desorientar Indiferente Não se 9,09% 0,00% 0,00% 72,73% 18,18% 0,00% Sentença: É mantido um padrão de cores, botões e mensagens em todo o software Indiferente Não se 0,00% 0,00% 18,18% 36,36% 45,45% 0,00% Sentença: Os botões são todos de tamanho e forma similiar em todo o software Indiferente Não se 0,00% 0,00% 0,00% 45,45% 54,55% 0,00% Sentença: Cada janela tem um título que a identifica claramente Indiferente Não se 0,00% 9,09% 0,00% 54,55% 36,36% 0,00% Sentença: A interface do software informa ao usuário sobre o que um botão, menu, ícone ou caixa de diálogo faz ao se posicionar o cursor do mouse sobre ele Indiferente Não se 18,18% 0,00% 0,00% 54,55% 27,27% 0,00% Média da Subcaracterística Operacionalidade Indiferente Não se 5,05% 9,09% 12,12% 46,46% 27,27% 0,00% d) Atratividade Tabela 39: Sentenças que compõem a Subcaracterística Atratividade - ERP P Sentença: O software utiliza de uma linguagem instrutiva, polida, neutra e não agressiva Indiferente Não se 0,00% 9,09% 9,09% 36,36% 45,45% 0,00% Sentença: Atratividade e interface amigável Indiferente Não se

113 113 0,00% 9,09% 0,00% 63,64% 27,27% 0,00% Sentença: Navegação simples entre os menus e itens de menu Indiferente Não se 9,09% 0,00% 0,00% 45,45% 45,45% 0,00% Sentença: As telas do software utilizam tipos e tamanhos de letras de fácil visualização Indiferente Não se 0,00% 0,00% 0,00% 45,45% 54,55% 0,00% Sentença: As cores são utilizadas com equilíbrio, ou seja, são bem distribuídas evitando assim poluição visual Indiferente Não se 0,00% 9,09% 18,18% 18,18% 54,55% 0,00% Média da Subcaracterística Atratividade Indiferente Não se 1,82% 5,45% 5,45% 41,82% 45,45% 0,00% 3) Eficiência a) Tempo Tabela 40: Sentenças que compõem a Subcaracterística Tempo - ERP P Sentença: Resposta rápida as requisições de consultas e relatórios Indiferente Não se 18,18% 9,09% 18,18% 45,45% 9,09% 0,00% Sentença: Resposta rápida as entradas realizadas Indiferente Não se 9,09% 27,27% 0,00% 54,55% 9,09% 0,00% Sentença: Tempo gasto na execução das tarefas Indiferente Não se 18,18% 18,18% 0,00% 54,55% 9,09% 0,00% Média da Subcaracterística Tempo Indiferente Não se 15,15% 18,18% 6,06% 51,52% 9,09% 0,00%

114 114 b) Recursos Tabela 41: Sentenças que compõem a Subcaracterística Recursos - ERP P Sentença: Otimização do seu trabalho, criando condições mais favoráveis para realização do mesmo Indiferente Não se 9,09% 18,18% 0,00% 54,55% 18,18% 0,00% Sentença: Tempo gasto para localizar funcionalidades ou ferramentas dentro do software Indiferente Não se 9,09% 27,27% 18,18% 36,36% 9,09% 0,00% Sentença: Quantidade de passos para executar as tarefas Indiferente Não se 9,09% 18,18% 9,09% 54,55% 9,09% 0,00% Média da Subcaracterística Recursos Indiferente Não se 9,09% 21,21% 9,09% 48,48% 12,12% 0,00% O Gráfico 5 e a Tabela 42 apresentam uma visão do quão satisfeitos estão os usuários do ERP P em relação as Características Funcionalidade, Usabilidade e Eficiência, que compõem a análise do grau de Satisfação geral dos usuários do software avaliado. Satisfação dos Usuários por Característica 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Indiferente Funcionalidade Usabilidade Eficiência Gráfico 5: Satisfação dos usuários por Característica ERP P

115 115 Tabela 42: Satisfação dos usuários por Característica ERP P Funcionalidade Usabilidade Eficiência Média Geral Indiferente 11,11% 9,09% 2,02% 53,54% 24,24% 6,18% 8,00% 14,55% 43,27% 28,00% 12,12% 19,70% 7,58% 50,00% 10,61% 9,80% 12,26% 8,05% 48,94% 20,95% Efetuando-se uma análise dentro das Características, nota-se que é relativamente boa a aceitação do ERP P, mas é possível observar que existem pontos de melhoria para o software, onde o índice de s e s variam de 15% a 30%, de acordo com a Característica. Portanto, é necessário analisar as Subcaracterísticas para identificar se esse percentual de insatisfação está restrito a pontos específicos do software ou a fatores externos, que são apresentados na Tabela 43. Tabela 43: Fatores externos ao software avaliado ERP P O software que está sendo avaliado foi implantado em substituição a algum outro software ou processo manual que você utilizava anteriormente? Não Sim Não se 45,45% 0,00% 54,55% 0,00% Você considera que as necessidades dos usuários foram levadas em consideração no desenvolvimento deste software? Não Sim Não se 27,27% 54,55% 18,18% 0,00% Como você classifica o treinamento recebido para utilizar o software? Não Fraco Regular Bom Ótimo se 18,18% 9,09% 63,64% 9,09% 0,00% Como você classifica seu nível de experiência no uso de sistemas computacionais? Fraco Regular Bom Ótimo Não se 0,00% 0,00% 72,73% 27,27% 0,00% Como você classifica seu nível de motivação com as tarefas que desempenha usando o software em questão? Fraco Regular Bom Ótimo Não se 0,00% 9,09% 81,82% 9,09% 0,00% Como você classifica as condições do local de trabalho para a execução das tarefas que dependem do software? Fraco Regular Bom Ótimo Não se 0,00% 9,09% 81,82% 9,09% 0,00%

116 116 Como você classifica o nível do suporte prestado em caso de dúvidas ou problemas? Fraco Regular Bom Ótimo Não se 0,00% 9,09% 54,55% 36,36% 0,00% Como você classifica os meios ofertados ao usuário para apresentar sugestões de melhoria? Fraco Regular Bom Ótimo Não se 0,00% 27,27% 63,64% 9,09% 0,00% Em termos de velocidade de processamento, como você classifica os computadores usados com este software? Fraco Regular Bom Ótimo Não se 9,09% 9,09% 63,64% 18,18% 0,00% Como você classifica o seu grau de fluência no idioma em que o software é apresentado? Fraco Regular Bom Ótimo Não se 0,00% 9,09% 72,73% 18,18% 0,00% destacados: Dentre os fatores externos apresentados na Tabela 43 alguns merecem ser O treinamento recebido para utilização do software foi classificado como Fraco ou Regular para 27,27% dos entrevistados; Para 27% dos entrevistados as necessidades dos usuários não foram consideradas no software; Para 54,55% dos entrevistados o ERP P veio a substituir outro software. Os Gráficos 6, 7 e 8 apresentam uma visão analítica da Característica Funcionalidade, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do ERP P no critério Funcionalidade.

117 117 Característica Funcionalidade 60,00% 53,54% 50,00% 40,00% 30,00% 24,24% 20,00% 10,00% 11,11% 9,09% 2,02% 0,00% Indiferente Gráfico 6: Índice de satisfação na Característica Funcionalidade ERP P Funcionalidade: subcaracterística Acurácia 70,00% 60,00% 60,61% 50,00% 40,00% 30,00% 27,27% 20,00% 10,00% 0,00% 3,03% 9,09% 0,00% Indiferente Gráfico 7: Característica Funcionalidade: Subcaracterística Acurácia ERP P Funcionalidade: subcaracterística Adequação 50,00% 50,00% 40,00% 30,00% 22,73% 20,00% 10,00% 15,15% 9,09% 3,03% 0,00% Indiferente Gráfico 8: Característica Funcionalidade: Subcaracterística Adequação ERP P

118 118 Com a visualização individualizada das Subcaracterísticas Acurácia e Adequação, é possível observar que o principal ofensor na Característica Funcionalidade reside na Adequação do ERP P. O ERP P foi relativamente bem avaliado por seus usuários, remetendo a um índice de 81,82% de satisfação com o produto, mas alguns pontos devem ser avaliados com a maior brevidade possível, pois podem impactar diretamente na qualidade percebida por seus usuários. Dentre os problemas encontrados que poderiam remeter a um baixo índice de satisfação dos usuários do ERP P, foi possível observar que o treinamento dado a alguns usuários não foi adequado, sendo o principal ofensor a satisfação de seus usuários, e conseqüentemente a qualidade do produto. Portanto, orienta-se que sejam tomadas ações de treinamento, que vise demonstrar a adequação do software à necessidade dos usuários. Os computadores utilizados com o ERP P devem ser avaliados quanto ao seu desempenho, pois é um item que pode impactar diretamente na satisfação do usuário final, e ao longo do tempo afetar a percepção de qualidade do produto. Aprimorar os meios ofertados aos usuários para apresentar sugestões de melhoria no ERP P. Uma vez que os usuários tenham necessidades específicas atendidas pelo software dentro de um contexto de uso específico, aumenta a qualidade do produto percebida por seus usuários. Em virtude da insatisfação com o ERP P estar restrita a cerca de 20% dos entrevistados, pode ser interessante realizar a pesquisa segmentando por departamento, com o intuito de se apurar algum viés relacionado a alguma funcionalidade que não esteja correpondendo a necessidade dos usuários de um dos departamentos que participou da pesquisa. Foi criado um relatório para apresentação da avaliação do ERP P, que se encontra no Apêndice H. Neste relatório é apresentada uma análise completa quanto à satisfação dos usuários finais do ERP P.

119 Análise Comparativa dos Modelos Uma vez realizada a aplicação do instrumento iasus na avaliação de softwares reais em contextos de uso reais, foi possível efetuar uma análise comparativa entre o instrumento iasus e alguns métodos de avaliação da qualidade de software, conforme apresentado na Tabela 44. Tabela 44: Comparação entre o instrumento iasus e alguns métodos de avaliação Instrumento iasus Método SUMI Avaliação Heurística Método MEDE-PROS Análise de fatores externos ao software avaliado Envolvimento do usuário final Alto Inexistente Inexistente Inexistente Alto Alto Baixo Baixo Análise de Usabilidade Médio Médio Alto Alto Análise da Qualidade em Uso Captura do nível de Satisfação dos usuários do software avaliado Alto Alto Inexistente Médio Alto Alto Inexistente Inexistente Utilização de análise subjetiva Alto Inexistente Inexistente Inexistente Usuário final relatar livremente críticas e/ou sugestões Dependência de avaliadores especialistas Alto Inexistente Inexistente Inexistente Alto Alto Alto Alto Fidedignidade Alto Alto Alto Alto

120 CONCLUSÕES Este capítulo apresenta as conclusões obtidas durante o desenvolvimento deste trabalho, bem como as principais contribuições ao segmento de qualidade de software e sugestões de trabalhos futuros. 5.1 Conclusões Gerais O objetivo fundamental do trabalho apresentado nesta dissertação foi propor um instrumento, nomeado de iasus 7, onde buscou-se trabalhar dentro de uma abordagem um pouco diferente da convencional para avaliação da qualidade em uso de produtos de software. Pois além de envolver diretamente um dos principais interessados na qualidade do software, seus usuários finais, procurou também analisar fatores externos ao software em si, mas que pudessem impactar na satisfação dos usuários. Para tal, foi seguido um processo de discussão e análise do estado da arte e da prática de avaliação da qualidade de produtos de software, avaliou-se e adotouse uma metodologia, uma forma de avaliação e medição, indicadores foram elaborados para a pesquisa de campo e em cada etapa se extraíram conclusões de distintas importâncias ao trabalho. O instrumento proposto procurou preencher as lacunas encontradas nos métodos pesquisados e referenciados ao longo do Capítulo 2. Como a participação direta do usuário final na avaliação, a consideração de fatores externos ao software em si na análise do contexto de uso do produto, e a opção para que o usuário manifeste de forma aberta seus anseios e necessidades, sendo um item a mais de apoio a análise e subsídios ao desenvolvedor do software para melhoria contínua do produto. O assunto tratado no Capítulo 2, acerca do significado das relações e termos como qualidade e qualidade em uso, oferece uma idéia clara que a definição de qualidade não é um conceito absoluto, sendo que, existem diferentes perspectivas sobre a mesma, tendo em conta um produto de software em uso ou não. De 7 iasus Instrumento para Avaliação da Satisfação de Usuários de Software

121 121 qualquer forma, se diz que o objetivo final de um processo de especificação, medição e avaliação de qualidade, é alcançar um nível aceitável de qualidade em uso. Foi realizada também uma revisão na literatura e nas melhores práticas relacionadas, identificando a evolução do significado de termos chave como usabilidade e qualidade em uso. Tal evolução foi refletida pelas normas de padronização, que atualmente indicam a necessidade de se avaliar não somente a qualidade de um software em funcionamento, ou seja, qualidade interna, processos de desenvolvimento, qualidade externa, artefatos, mas também a qualidade percebida pelos usuários finais do produto em um contexto de uso real, que se resume como qualidade em uso. Também foi apurado que na opinião de diversos autores as atividades próprias de medição e avaliação da qualidade em uso estão sendo utilizadas como apoio ao processo de desenvolvimento, propondo o planejamento da qualidade em uso de produtos de software desde etapas iniciais, como é feito com a qualidade interna e qualidade externa. É possível afirmar que o planejamento, a medição e a avaliação da qualidade em uso de produtos de software são processos complexos e inter-relacionados, pois inclui aspectos objetivos e subjetivos, interação entre especialistas e usuários finais, ademais de que não são generalizáveis a contextos diferentes. Para dar confiabilidade ao iasus, o instrumento teve sua fidedignidade avaliada através da medição do coeficiente de correlação de Spearman-Brown, conforme pode ser visto nas Tabelas 45 e 46. Tabela 45: Fidedignidade pelo coeficiente de correlação de Spearman-Brown SysOKA Coeficiente de correlação de Spearman-Brown: 0,84 Tabela 46: Fidedignidade pelo coeficiente de correlação de Spearman-Brown ERP P Coeficiente de correlação de Spearman-Brown: 0,99 Os resultados obtidos de 0,84 e 0,99 são para um máximo de 1, caracterizando o instrumento como confiável, ou seja, mede corretamente o que se propõe a medir.

122 122 Para avaliar a aplicabilidade do instrumento proposto neste trabalho realizouse uma pesquisa de campo, apresentada nos Capítulos 3 e 4. A pesquisa de campo se desenvolveu com dois objetivos, onde um estava relacionado com os softwares avaliados, o SysOKA e o ERP P, e outro de caráter geral, que foi avaliar a aplicabilidade do instrumento iasus para avaliação da satisfação de usuários finais de produtos de software. Sendo este último objetivo altamente relevante ao propósito desta dissertação, os resultados são apresentados na Tabela 47. Tabela 47: Resultado do pré-teste: avaliação do instrumento iasus Pergunta Respostas Sim Não As perguntas do Instrumento de Pesquisa estão claras para você? 83,33% 16,67% Você teve dificuldade em responder alguma pergunta? 16,67% 83,33% O formato do Instrumento de Pesquisa facilita responder as perguntas? 0,00% 100,00% A escala de avaliação do Instrumento de Pesquisa, que vai de " " a " ", está compreensível? 100,00% 0,00% Você acha que as perguntas do Instrumento de Pesquisa estão bem formuladas e são completas para avaliar seu grau de satisfação com o software que está sendo avaliado? 100,00% 0,00% A explicação sobre o intuito do estudo, o que será feito com os dados obtidos e como responder o instrumento de pesquisa foi clara e completa? 83,33% 16,67% Os resultados da pesquisa de campo conduzida junto a usuários do software SysOKA e do ERP P, juntamente com os resultados apresentados com a aplicação do instrumento iasus, indicam que o instrumento iasus pode ser útil na identificação do nível de satisfação de usuários bem como apoiar a melhoria continua do software avaliado, o que vai de encontro ao objetivo geral proposto para este trabalho de pesquisa, que foi: Criar um instrumento para avaliar a satisfação de usuários finais de produtos de software. 5.2 Suposições e Objetivos Os resultados apresentados no Capítulo 4 demonstraram a realização prática da aplicação do instrumento proposto neste trabalho, que é avaliar a satisfação de usuários de produtos de software. Mas com uma abordagem diferenciada, analisando fatores externos ao software que está sendo avaliado e também permitindo ao respondente maior interação com a pesquisa, dando-lhe liberdade para expressar abertamente seus anseios e necessidades com o software avaliado.

123 123 Os resultados obtidos com a aplicação do instrumento iasus junto aos usuários finais do software SysOKA e do ERP P são os seguintes: Que o instrumento é de fácil aplicação e que não toma muito tempo do entrevistado para respondê-lo, cerca de 20 minutos; Que o instrumento obteve um índice de fidedignidade de 0,84 e 0,99 em um valor máximo de 1, podendo ser considerado confiável para medir o que se propõe, de acordo com o coeficiente de correlação de Spearman-Brown; A análise do ambiente onde o software está sendo executado, ou seja, a identificação de fatores externos ao software em si, contribuem e não devem ser negligenciadas em uma avaliação da satisfação de usuários de produtos de software; A entrada para críticas e sugestões quando alimentada com assuntos pertinentes pelo entrevistado, podem contribuir para a melhoria do produto bem como para corroborar possíveis falhas apontadas pela análise final da satisfação dos usuários; O relatório de análise da satisfação dos usuários finais dos softwares SysOKA e ERP P podem provêer subsídios as organizações desenvolvedoras desses produtos, para que possam implementar melhorias de forma direcionada as necessidades dos usuários. Tendo como base os resultados elencados acima, o instrumento proposto neste trabalho mostrou-se ser eficaz para medição da satisfação de usuários finais de produtos de software da categoria a qual o SysOKA e o ERP P se enquadram. 5.3 Contribuições Ao propor um instrumento para avaliação da satisfação de usuários finais de produtos de software, este trabalho oferece as seguintes contribuições potenciais: Prover subsídios aos desenvolvedores de softwares para que implementem melhorias em seus produtos, direcionadas aos usuários finais;

124 124 Implementação de uma análise de fatores externos ao software, como complemento a avaliação da satisfação de usuários finais de softwares; Colaboração com o segmento de qualidade de software na produção de formas de avaliar critérios subjetivos como a satisfação de usuários finais de softwares; Fornecer subsídios aos desenvolvedores dos softwares SysOKA e do ERP P para melhoria contínua dos mesmos; Contribuir para futuros estudos acadêmicos no segmento de qualidade de software. 5.4 Limitações Embora tenha sido apresentado que o instrumento iasus é de uso relativamente amplo, ou seja, poderia ser aplicado a diferentes tipos de softwares, essa colocação é uma suposição, feita com base nas características do instrumento, e como tal necessita de validação. Devido a restrições de tempo para conclusão deste trabalho de pesquisa, o instrumento iasus foi testado com apenas dois softwares, o SysOKA e o ERP P, cuja definições podem ser vistas no Capítulo Trabalhos Futuros Como conseqüência deste trabalho de pesquisa, alguns estudos futuros são recomendados: r o instrumento iasus a outros produtos de software com o intuito de avaliar sua eficácia e efetividade; Além dos fatores externos analisados nesta abordagem, identificar outros que também possam impactar na satisfação dos usuários finais de software; Complementar o instrumento iasus com outras Características e/ou Subcaracterísticas do Modelo de Qualidade da Norma ISO/IEC ; r o instrumento dentro de uma única organização, segmentando o resultado por nível hierárquico ou departamento dos entrevistados,

125 125 com o intuito de se avaliar a eficácia e a efetividade do instrumento para diferentes perfis de usuários; Avaliar junto a desenvolvedores de softwares se o instrumento é útil em prover subsídios à melhoria do software; r o iasus versus outros instrumentos, Sumi e MEDE-PROS para avaliar os instrumentos de avaliação.

126 126 REFERÊNCIAS ABNT. Guia para utilização das normas sobre avaliação de qualidade de produto de software ISO/IEC 9126 e ISO/IEC ABNT-Associação Brasileira de Normas Técnicas. Maio, ABNT. NBR ISO/IEC : Tecnologia de informação Avaliação de produto de software Parte 1: Visão geral. Rio de Janeiro, ALEXANDRE, J. W. C.; ANDRADE, D. F.; VASCONCELOS, A. P.; ARAUJO, A. M. S.; BATISTA, M. J. Teoria da resposta ao item: aplicação do modelo de escala gradual na gestão pela qualidade. Anais do XXII Encontro Nacional de Engenharia de Produção, Curitiba, ALRECK, P.; SETTLE, R. The Survey Research Handbook. Irwin/McGraw-Hill, Boston, ANDREWS, K. Human Computer-Interaction. Graz University of Technology, Austria, ARGYRIS, C.; PUTNAM, R.; SMITH, D. Action science: concepts, methods, and skills for research and intervention. San Francisco: Jossey-Bass, ARNOLD, K.L. The Manager's Guide to ISO New York: The Free Press, AZEVEDO, G. D. F., et al. Projeto TAQS Tecnologia para Avaliação da Qualidade de Software. In Workshop ProTeM-CC, Belo Horizonte, 1998, p AZUMA, M. Quality in use; Its Concept, Metrics and Methodology. Proceedings 2 nd WCSQ, AZUMA, M. SQuaRE: The next Generation of ISO/IEC 9126 and International Standards Series on Software Product Quality. Proceedings of the European Software Control and Metrics Conference (ESCOM). London, UK, 2001, p BACHE, R.; BAZZANA, G. Software Metrics for Product Assessment, Software Quality Assurance Series, McGraw-Hill Book Co., 1994, p BADRI, M. A.; DONALD, D.; DONNA, D. A study of measuring the critical factors of quality management. International Journal of Quality & Reliability Management, v.12, n. 2, 1995, p BANSLER, J.; BODKER, K. A Reappraisal of Structured Analysis: Design in an Organizational Context. ACM Transactions on Information Systems, 1993.

127 127 BASILI, V.R.; GALDIERA, G.; ROMBACH, H.D. Goal Question Metric paradigm. Enciclopaedia of Software Engineering, Vol 1, John Wiley and Sons, BEVAN, N.; KIRAKOWSKI, J.; MAISSEL, J. What is Usability. Proceedings of the 4th International Conference on HCI. Stuttgart, September BEVAN, N.; McLEOD, M. Usability measurement in context. Behaviour & Information technology, 1994, vol. 13, p BEVAN, N. Usability is Quality of Use. Proceedings of the 6 th International Conference on Human Computer Interaction. Anzai & Ogawa, Julho/1995A. BEVAN, N. Measuring usability as quality of use. Software Quality Journal, 1995B, p BEVAN, N.; AZUMA, M. Quality in use: Incorporating Human Factors into the Software Engineering Lifecycle. IEEE, 1997, p BEVAN, N. Quality in use for all. Stephanidis: Lawrence Erlbaum, 1999A. BEVAN, N. Quality in use: meeting user needs for quality. Journal of Systems and Software, 1999B, n. 49, p BEVAN, N. Quality in use for all. User interfaces for all. New York: Lawrence Erlbaum, BEVAN, N. Cost-effective user-centred design based on ISO Tutorial notes. UPA 2002, Orlando, Florida,USA. July, BOEHM, B. W.; BROWN, J. R.; LIPOW, M. Quantitative evaluation of software quality. Proceedings of the 2nd international conference on Software engineering, San Francisco, California, United States, 1976, p BOEHM, B. W.; BROWN, J. R.; LIPOW, M.; MACLEOD, J. L.; MERRID, M. J. Characteristics of Software Quality. Elseiver Nort Holland, BOEHM, B.W. Software risk management: principles and practices. IEEE Software, Janeiro/1991, vol. 8, p BOLINGER, T.; McGOWAN, C. A critical look at software capability evaluations. IEEE Software, Jul/1991, vol. 8, p CASH, Jr. J.; McFARLAN, W.; McKENNEY, J. Corporate Information Systems Management, The issues facing senior executives. Third edition, Boston, CATO, J. User-centered Web design. Harlow, England: Addison-Wesley, CAVANO, J. P.; McCALL, J. A. A Framework for the measurement of Software Quality. ACM Software Quality Assurance Workshop, November/1978.

128 128 CENPRA. Manual do avaliador: MEDE-PROS. Centro de Pesquisas Renato Archer, Campinas, CLEMEN, R.T. Making Hard Decisions. Toronto: Duxbury Press, CONRATH, D. W.; MIGNEN, O. P. What is being done to measure user satisfaction with EDP/MIS. Information & Management, v.19, 1990, p DADOUN, G. ISO A requirement for doing business. Canada: In Proceedings of CASCON 92, Center for Advanced Studies, Nov/1992, p DASKALANTONAKIS, M. K. A practical view of software measurement and implementation experiences within Motorola. IEEE Transaction on Software Engineering, Nov/1992, vol. 18, n. 11, p DIX, A.; FINLAY, J.; ABOWD, G.; BEALE, R. Human-Computer Interaction. Pearson: Prentice Hall, DROMEY, R.G. A model for software product quality. IEEE Transactions on Software Engineering, Vol 21, 1995, p FENTON, N.E.; PFLEEGER, S.L. Software Metrics: a Rigorous and Practical Approach. PWS Publishing Company, FERNÁNDEZ, L. Una Revisión Breve de la Medición del Software. Novática, 1999, p FOLMER, E.; BOSCH, J. Architecting for Usability: a Survey. Journal of Systems and Sotfware, 2004, p FOX, D. J. The research process in education. New York: Holt, Rinehart and Winston, GARVIN, D. What does product quality really mean? Sloane Management Review, 1984, p GHIGLIONE, R.; MATALON, B. O Inquérito: Teoria e Prática. Editora Celta, GOLDENBERG, M. A arte de pesquisar. Rio de Janeiro: Record, GUERRA, A. C.; COLOMBO, R. M. T. Tecnologia da Informação: Qualidade de Produto de Software. PBQP Software, HAYES, B. E. Medindo a satisfação do cliente. Rio de Janeiro: Editora QualityMark, HILTUNEN, M.; LAUKKA, M.; LUOMALA, J. Mobile User Experience. Finland: Edita Publishing Inc., 2002.

129 129 HUTCHINS, G. ISO 9000 Um guia completo para registros, as diretrizes e a certificação bem sucedida. São Paulo: Makron Books, ISO International Organization for Standardization. Acessível via ISO/IEC Information Technology Software Product Evaluation Quality Characteristics and Guidelines for their use. Geneve,1991. ISO/IEC Software Engineering - Software Product Quality - Part 1: Quality Model. International Organizational. for Standardization, Geneva, ISO/IEC Engenharia de Software - Qualidade do Produto. Parte 1: Modelo de Qualidade. Associação Brasileira de Normas Técnicas. Rio de Janeiro, ISO/IEC Software Engineering - Software product quality - Part 4: Quality in use metrics. Geneve, ISO/IEC Ergonomic Requirements for Office Work with Visual Display Terminals. Part 11: Guidance on Usability ISO/IEC Tecnologia de Informação Pacotes de software Teste e requisitos de qualidade ISO/IEC Information Technology Software Life Cycle Processes ISO/IEC Information Technology Software Life Cycle Processes - AMD ISO/IEC Information Technology Software Life Cycle Processes - AMD ISO/IEC User Center Design process for interactive systems ISO/IEC Information technology - Software product evaluation - Part 5: Process for evaluators ISO/IEC Information technology - Software product evaluation - Part 1: General overview ISO/IEC Information technology - Software product evaluation - Parts 1 to 6. International Organization for Standardization, Geneva, ISO/IEC Software Engineering Software Product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE. Geneva: International Organization for Standardization, JOKELA, T.; LIVARI, N.; MATERO, J.; KARUKKA, M. The standard of usercentered design and the standard definition of usability: analysing ISO against ISO Proceedings of CLIHC 2003, Rio de Janeiro, 2003, p

130 130 JURAN, J. M. A. Qualidade desde o Projeto: Novos Passos para o Planejamento da Qualidade em Produtos e Serviços. São Paulo: Pioneira Thomson Learning, KAN, S. H. Metrics and Models in Software Quality Engineering. Boston: Addison-Wesley, KELLER, S.E.; KAHN, L.G; PANARA, R.B. Specifying Software Quality Requirements with Metrics, System and Software Requirements Engineering. IEEE Computer Society Press Tutorial, KERLINGER, F. N. Metodologia da pesquisa em ciências sociais. São Paulo: INEP, KETELE, J.; ROEGIERS, X. Metodologia de Coleta de Dados: Fundamentos dos Métodos de Observações, de Questionários, de Entrevistas e de Estudo de Documentos. Editora Instituto Piaget, KIRAKOWSKI, J.; CORBETT, M. SUMI: The Software Usability Measurement Inventory. British Journal of Educational Technology, 1993, p KITCHENHARN, B.; PFLEEGER, S. Software Quality: The Exclusive Target. IEEE Software, KUVAJA, P.; SIMILIA, J.; KRZANIK, L.; BICEGO, A.; KOCH, G.; SAUKKONEN, S. Software Process Assessment and Improvement: The Bootstrap Approach. London, Blackwell Publishers, KUVAJA, P.; BICEGO, A.; DORLING, A. SPICE: The software assessment model. Proceedings of ESI-ISCN conference, Vienna, LARKIN, J.; SIMON, H. A. Why a diagram is sometimes worth then ten thousand words. Cognitive Science, 1987, p LAUDON, K.; LAUDON, J. Management information systems: managing the digital firm. 7ª. ed. Upper Saddle River: Prentice Hall, LINDGAARD, G. Usability Testing and System Evaluation: A Guide for Designing Useful Computer Systems. London: Chapman and Hall, MACLEOD, M.; BOWDEN, R.; BEVAN, N.; CURSON, I. The MUSiC Performance Measurement Method. Behaviour and Information Technology, 1997, p MARCONI, M. A.; LAKATOS, E. M. Técnicas de pesquisa: planejamento e execução de pesquisas, amostragens e técnicas de pesquisas, elaboração, análise e interpretação de dados. Editora Atlas: São Paulo, 2002.

131 131 MAURER, D. Using a strawman for page layout design. CM Briefing, Disponível em: Acessado em: 04/05/2008. MAYHEW, D.J. The Usability Engineering Lifecycle: A Practitioner s Handbook for User Interface Design. Morgan Kaufman Publishers, McCALL, J. A.; RICHARDS, P.K.; WALTERS, G.F. Factors in software quality, Vol I, II, III: Final Technical Report, RADC-TR Rome Air Development Center, Air Force System Command, Griffith Air Force Base. NY, MILLER, D. K. Measurement by the Physical Educator: Why and How. Boston: McGraw-Hill, MILKOVICH, G.; BOUDREAU, J. Administração de recursos humanos. São Paulo: Atlas, MOLICH, R.; NIELSEN, J. Heuristic evaluation of user interface. Proc. ACM CHI, Seattle, MOREIRA, M. A.; ROSA, P. R. S. Uma Introdução à Pesquisa Quantitativa em Ensino. Porto Alegre: UFRGS. Campo Grande: UFMS MORESI, E. A. D. Apostila: metodologia da pesquisa. Brasília: Universidade Católica de Brasília, NBR Tecnologia de Informação - Avaliação de produto de software - Características de qualidade e diretrizes para o seu uso. ABNT. Rio de Janeiro, NEAL, A. S.; SIMON, R. M. Playback: A Method for Evaluating the Usability of Software and its Documentation. IBM Systems Journal, 1984, n.23. NIELSEN, J.; MACK, R. L. Usability Inspection Methods. John Wiley and Sons, New York, NIELSEN, J. Designing Web Usability: The Practice of Simplicity. New Riders, Berkeley, NORMAN, E.; FENTON, S. L. Software Metrics a Rigorous and Practical Approach. International Thomson Publishing Company, OLSINA, L.; ROSSI, G. Measuring Web Application Quality with WebQEM. IEEE Multimedia Magazine, Vol. 9, Nº 4, 2002, p OLSINA, L.; MARTÍN, M. A. Ontology for Software Metrics and Indicators. Journal of Web Engineering, Rinton Press, Vol 2 Nº 4, 2004, p

132 132 OLSINA, L.; PAPA, F.; MOLINA, H. Organization-oriented Measurement and Evaluation Framework for Software and Web Engineering Projects. Sydney, vol. 3579, 2005A, p OLSINA, L.; COVELLA, G.; ROSSI, G. Web Engineering: Theory and Practice of Metrics and Measurement for Web Development. Spinger Verlag, 2005B. ORTEGA, Maryoly. Construction of a systemic quality model for evaluating a software product. Software Quality Journal, July/2003, p PFLEEGER, S. L. Software Engineering: Theory and Practice. New Jersey: Prentice Hall, PORTEOUS, M.; KIRAKOWSKI, J.; CORBETT, M. SUMI User Handbook. University College Cork, Irlanda, PRESSMAN, R. S. Software Engineering: a Practitioner s Approach. New York: McGraw-Hill, ROSENBAUM, S. Selecting Appropriate Subjects for Documentation Usability Testing. Amsterdam: Elsevier Science Publishers,1989. SCOPE. Final Report. Verilog, STEWARD, D.V. Svstems Analvsis and Management: Structure and Design. New York: PBI, SURYN, W.; ABRAN, A.; APRIL, A. ISO/IEC SQuaRE. The second generation of standards for software product quality. 7th IASTED International Conference on Software Engineering, TAMIMI, N.; GERSHON, M.; CURRALL, S. C. Assessing the psychometric properties of Deming s 14 principles. Quality Management Journal, spring, v. 2, n. 3, 1995, p TUFTE, E. R. The Visual Display of Quantitative Information. Graphic Press, VIANNA, H. M. Testes em educação. São Paulo: Ibrasa, 1978.

133 APÊNDICE A INSTRUMENTO PARA AVALIAÇÃO DA SATISFAÇÃO DO USUÁRIO 133 A quanto tempo você utiliza o software que está sendo avaliado? Escala Menos de 6 meses De 6 meses a 1 ano De 1 ano a 2 anos Mais de 2 anos Resposta Relativo ao uso do software que está sendo avaliado, qual o seu grau de satisfação com com as seguintes funcionalidades deste produto: Pergunta Realização correta de todas as tarefas a que se propõe Dar mais precisão ao seu trabalho Estruturação da inteface de forma a agrupar as tarefas em áreas operacionais, mantendo assim, a sequência lógica do trabalho a ser realizado Funcionalidades para satisfazer as necessidades do seu trabalho Integridade dos dados do software após atualizações A forma de realizar uma tarefa no software está alinhada a forma que você organiza seu trabalho O software possui comportamento semelhante em situações semelhantes, ou seja, solicita do usuário ações similares para tarefas similares Normalmente o software faz o que você espera que ele deveria fazer Otimização do seu trabalho, criando condições mais favoráveis para realização do mesmo Apresentação clara e de fácil entendimento das informações Indiferente Não se

134 O software utiliza de uma linguagem instrutiva, polida, neutra e não agressiva Completo entendimento do que deve ser feito em todas as partes do software Simplicidade para realização de suas atividades Utilização de códigos e termos técnicos condizentes com o trabalho a ser realizado É fácil de entender e reconhecer a estrutura, a lógica e a aplicabilidade do software O texto apresentado na interface do software não dá margem a interpretações ambíguas Navegar em distintos níveis do software sem se perder ou desorientar Confiança de que está usando corretamente o software Tempo requerido para o aprendizado do software Disponibilização de Help contextualizado em qualquer parte do software ao se pressionar F1 Sistema de Help e tutoriais capaz de esclarecer todas as suas dúvidas A documentação do software é clara e precisa A documentação do software tem uma organização lógica e evolutiva, aumentando gradativamente o nível de complexidade da informação que lhe é apresentada. Facilita-se assim, o aprendizado e entendimento da operação do software O manual do usuário demonstra as principais atividades a serem realizadas com o uso do software, de modo que se consiga explorar bem suas funcionalidades Atratividade e interface amigável Navegação simples entre os menus e itens de menu É mantido um padrão de cores, botões e mensagens em todo o software As telas do software utilizam tipos e tamanhos de letras de fácil visualização Os botões são todos de tamanho e forma similiar em todo o software Cada janela tem um título que a identifica claramente As cores são utilizadas com equilíbrio, ou seja, são bem distribuídas evitando assim poluição visual A interface do software informa ao usuário sobre o que um botão, menu, ícone ou caixa de diálogo faz ao se posicionar o cursor do mouse sobre ele Menus e lista de informações organizados de forma lógica Informação de andamento das tarefas que estão sendo realizadas Mensagens que ajudam na prevenção a erros do usuário Resposta rápida as requisições de consultas e relatórios Resposta rápida as entradas realizadas Tempo gasto para localizar funcionalidades ou ferramentas dentro do software Tempo gasto na execução das tarefas Quantidade de passos para executar as tarefas Qual seu grau de satisfação em relação ao software que está sendo avaliado?

135 135 Considerando o ambiente em que o software que está sendo avaliado é utilizado, responda as seguintes perguntas: Pergunta O software que está sendo avaliado foi implantado em substituição a algum outro software ou processo manual que você utilizava anteriormente? Você considera que as necessidades dos usuários foram levadas em consideração no desenvolvimento deste software? Como você classifica o treinamento recebido para utilizar o software? Como você classifica seu nível de experiência no uso de sistemas computacionais? Como você classifica seu nível de motivação com as tarefas que desempenha usando o software em questão? Como você classifica as condições do local de trabalho para a execução das tarefas que dependem do software? Como você classifica o nível do suporte prestado em caso de dúvidas ou problemas? Como você classifica os meios ofertados ao usuário para apresentar sugestões de melhoria? Em termos de velocidade de processamento, como você classifica os computadores usados com este software? Como você classifica o seu grau de fluência no idioma em que o software é apresentado? Resposta Não Sim Não Sim Não se Não se Fraco Regular Bom Ótimo Fraco Regular Bom Ótimo Fraco Regular Bom Ótimo Fraco Regular Bom Ótimo Fraco Regular Bom Ótimo Fraco Regular Bom Ótimo Fraco Regular Bom Ótimo Fraco Regular Bom Ótimo Não se Não se Não se Não se Não se Não se Não se Não se Caso seja de seu interesse, utilize o espaço abaixo para comentários, críticas e/ou sugestões de melhoria do software que está sendo avaliado:

136 136 APÊNDICE B CONVITE A PARTICIPAÇÃO DO TESTE Prezado(a)..., Sou mestrando na Universidade Católica de Brasília no curso Mestrado em Gestão do Conhecimento e da Tecnologia da Informação. Gostaria de convidá-lo a participar da fase de Teste do instrumento de pesquisa que será utilizado em minha dissertação de mestrado, que tem como tema: Abordagem para avaliação da qualidade em uso de produtos de software. Esta fase, denominada Teste, consiste na análise do documento Instrumento de Pesquisa, onde você irá responder um questionário com 53 perguntas, que visa mensurar seu grau de satisfação com o software que está sendo avaliado. O tempo médio de resposta do questionário é de 20 minutos. O intuito dessa pesquisa é avaliar a satisfação dos usuários do software SysOKA com seu uso, e dessa forma fornecer subsídios a empresa desenvolvedora do mesmo, para que possa implementar melhorias no citado software. Os dados aqui obtidos serão utilizados exclusivamente para fins acadêmicos, e serão apresentados de forma agregada, sendo que a identificação do participante será mantida em sigilo. Por favor, leia inicialmente o documento Instruções para realização do Teste do Instrumento de Pesquisa que contém as informações necessárias a realização da avaliação. Desde já agradeço sua colaboração, e informo que uma cópia do resultado da avaliação do grau de satisfação do grupo de usuários participantes desta pesquisa lhe será encaminhado. Atenciosamente, Welington Alves

137 137 APÊNDICE C INSTRUÇÕES PARA REALIZAÇÃO DO TESTE Você faz parte do grupo de pessoas que irá efetuar a análise do instrumento de pesquisa a ser utilizado na minha dissertação de mestrado. Esta fase, denominada Teste, consiste na análise do documento Instrumento de Pesquisa, onde você irá responder um questionário com 53 perguntas, que visa mensurar seu grau de satisfação com o software que está sendo avaliado. O tempo médio de resposta do questionário é de 20 minutos. * Procedimentos para realização do Teste: 1) Preencher o Instrumento de Pesquisa que é um questionário composto de 53 perguntas, e está dividido em três partes: a) A primeira parte é composta de 42 perguntas que visam avaliar sua satisfação em relação ao software que está sendo avaliado. Onde você deverá informar seu grau de satisfação com determinados requisitos do software, através de uma escala que vai de a ; b) A segunda parte é composta de 10 perguntas que visam avaliar o ambiente em que o software que está sendo avaliado é utilizado. Onde você deverá responder de acordo com a escala apresentada para a pergunta; c) A terceira parte é composta de um campo para comentários, críticas e/ou sugestões de melhoria do software que está sendo avaliado. 2) Após a análise e resposta do Instrumento de Pesquisa, você deverá responder o Questionário de Avaliação do Instrumento de Pesquisa, que é composto de 7 perguntas, onde busco obter sua contribuição para melhoria do Instrumento. * Material enviado junto ao 1) Documento com instruções para realização do Teste do Instrumento de Pesquisa; 2) Questionário do Instrumento de Pesquisa; 3) Questionário de Avaliação do Instrumento de Pesquisa. Qualquer dúvida, por favor entrar em contato pelo walves@tycon.com.br. Atenciosamente, Welington Alves

138 138 APÊNDICE D QUESTIONÁRIO DE AVALIAÇÃO DO INSTRUMENTO DE PESQUISA Avaliação do Instrumento de Pesquisa - Questionário Nome do Respondente: Número Pergunta Sim Não 1 As perguntas do Instrumento de Pesquisa estão claras para você? Se não, informe o que não ficou claro: Texto Livre: Número Pergunta Sim Não 2 Você teve dificuldade em responder alguma pergunta? Se sim, informe quais perguntas você teve dificuldade e qual a natureza da dificuldade: Texto Livre: Número Pergunta Sim Não 3 O formato do Instrumento de Pesquisa facilita responder as perguntas? Se não, informe o que dificultou no uso do Instrumento de Pesquisa: Texto Livre: Número Pergunta Sim Não A escala de avaliação do Instrumento de Pesquisa, que vai de " " a " ", está compreensível? Se não, informe o que não compreendeu: Texto Livre: Número Pergunta Sim Não Você acha que as perguntas do Instrumento de Pesquisa estão bem formuladas e são completas para avaliar seu grau de satisfação com o software SysOKA? 5.1 Se não, informe que tipo de questionamento você acha que faltou: Texto Livre: Número Pergunta Sim Não A explicação sobre o intuito do estudo, o que será feito com os dados obtidos e como responder o instrumento de pesquisa foi clara e completa? 6.1 Se não, informe que informação faltou: Texto Livre: Número 7 Pergunta Você gostaria de sugerir alguma melhoria no Instrumento de Pesquisa? Texto Livre:

139 139 APÊNDICE E CONVITE A PARTICIPAÇÃO DA PESQUISA SYSOKA Prezado(a), Sou mestrando na Universidade Católica de Brasília no Programa de Mestrado em Gestão do Conhecimento e da Tecnologia da Informação - MGCTI. Convido-o a participar da pesquisa de campo que será utilizada em minha dissertação, intitulada: Abordagem para avaliação da qualidade em uso de produtos de software. Esta pesquisa consiste na aplicação de um Instrumento de Pesquisa em forma de um questionário, e conseqüente análise dos dados. Este questionário é composto de 53 perguntas e o tempo médio de resposta é de 20 minutos. O objetivo dessa pesquisa é avaliar a aplicabilidade de uma abordagem para avaliar a satisfação de usuários com determinado software, e dessa forma, fornecer subsídios aos desenvolvedores para que possam implementar, de forma mais direcionada as necessidades dos usuários, melhorias em seus produtos. O software em questão é o SysOKA. Os dados aqui obtidos serão utilizados exclusivamente para fins acadêmicos, e serão apresentados de forma agregada, sendo que a identificação do participante será mantida em sigilo. Para responder a pesquisa, por favor acesse o endereço: Desde já agradeço sua participação, Welington Alves

140 140 APÊNDICE F RELATÓRIO DE AVALIAÇÃO DO SOFTWARE SYSOKA A seguir será apresentado o relatório de avaliação da satisfação dos usuários do software SysOKA. Este relatório foi produzido a partir da aplicação do instrumento iasus Instrumento para Avaliação da Satisfação de Usuários de Software. Avaliação do Grau de Satisfação dos Usuários do Software SysOKA Empresa Usuária: N/A Software Avaliado: SysOKA Data do Relatório: 07/06/2009 Versão do Documento: 1.0 Consultor Responsável pela Análise: Welington Alves 1. Introdução 1.1 Objetivo Através da aplicação do Instrumento iasus, procurou-se identificar o grau de Satisfação dos usuários do software SysOKA com seu uso, e desta forma, prover à empresa desenvolvedora do citado software, subsídios a melhoria continua do SysOKA. Este relatório apresenta uma análise da compilação dos dados obtidos com a aplicação do Instrumento iasus, onde serão apresentadas possíveis deficiências e oportunidades de melhoria para o software SysOKA. Como parte da mensuração do grau de Satisfação e análise do que pode estar gerando tal resultado, serão apresentados dados analíticos de Características e Subcaracterísticas do Modelo de Qualidade para Qualidade em Uso de Softwares da Norma ISO/IEC 9126 de 2003.

141 141 Não é objetivo do instrumento ou desta análise, avaliar áreas específicas do software, como por exemplo se a Usabilidade do software é boa ou não, e sim, identificar áreas que possam ser a causa da insatisfação dos usuários no uso do software. Se tal constatação estiver relacionada à Usabilidade do software, então deverão ser aplicados métodos específicos para avaliar a Usabilidade de softwares. 1.2 Participantes O software objeto desta análise é o SysOKA, desenvolvido para automatizar o método OKA Organizational Knowledge Assessment. A avaliação do grau de Satisfação para com o software SysOKA foi conduzida da seguinte forma: Empresa: Devido as características do software SysOKA, não foi possível realizar a avaliação dentro de uma única empresa, a mesma foi conduzida em organizações de diversos segmentos, tanto público quanto privado. Usuários participantes: 17 Perfil dos participantes: Não houve seleção prévia dos entrevistados. O único requisito a participar da avaliação é que o entrevistado fosse usuário do software SysOKA. Uma vez que os dados são apresentados de forma consolidada não haverá identificação individual dos respondentes. 2. Conceitos Com o intuito de alinhar o entendimento acerca de conceitos e termos técnicos utilizados neste documento, a seguir serão apresentadas algumas definições importantes para que se obtenha pleno entendimento desta análise. 2.1 Norma ISO/IEC (2003) Norma que tem como título geral Engenharia de Software Qualidade do Produto. 2.2 Modelo de Qualidade Conjunto de características e os relacionamentos entre elas, que fornecem a base para a especificação dos requisitos de qualidade e para

142 142 a avaliação de qualidade. Este modelo está dividido em duas partes: a) Modelo de qualidade para qualidade interna e externa; b) Modelo de qualidade para qualidade em uso. 2.3 Qualidade É a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explicitas e implícitas. 2.4 Modelo de Qualidade para Qualidade em Uso de Softwares 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 sob a perspectiva do usuário. 2.5 Característica Satisfação do Modelo de Qualidade em Uso Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado. É a resposta do usuário a interação com o produto e inclui atitudes relacionadas ao uso do produto. 2.6 Característica Funcionalidade do Modelo de Qualidade para Qualidade Interna e Externa Capacidade do produto de software de prover funções que atendam às necessidades explicitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas. A pergunta a ser feita é: o software satisfaz às necessidades? Subcaracterística Adequação Capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados. A pergunta a ser feita é: o software se propõe a fazer o que é apropriado? Subcaracterística Acurácia Capacidade do produto de software de prover, com grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados. A pergunta a ser feita é: o software faz de forma correta o que foi proposto?

143 Característica Usabilidade do Modelo de Qualidade para Qualidade Interna e Externa Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas. A pergunta a ser feita é: o software é fácil de usar? Subcaracterística 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. A pergunta a ser feita é: é fácil entender o conceito e a aplicação do software? Subcaracterística Apreensibilidade Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação. A pergunta a ser feita é: o software é fácil de usar e aprender? Subcaracterística Operacionalidade Capacidade do produto de software de possibilitar ao usuário operá-lo e controlá-lo. A pergunta a ser feita é: o software é fácil de operar e controlar? Subcaracterística Atratividade Capacidade do produto de software de ser atraente ao usuário. A pergunta a ser feita é: o software é atraente? 2.8 Característica Eficiência do Modelo de Qualidade para Qualidade Interna e Externa Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas. A pergunta a ser feita é: o software é rápido?

144 Subcaracterística 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. A pergunta a ser feita é: o tempo de resposta e a velocidade de execução do software são apropriados? Subcaracterística 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. A pergunta a ser feita é: quanto de recurso e por quanto tempo o software utiliza? 3. Resultados 3.1 Grau de Satisfação Consolidado O Gráfico 1 apresenta o grau de satisfação dos usuários do software SysOKA com este produto. Esta informação foi obtida através de uma pergunta direta aos entrevistados: Qual seu grau de satisfação em relação ao software que está sendo avaliado?. Esta pergunta não é utilizada diretamente na avaliação do software, servirá apenas como referência aos resultados que serão apresentados no decorrer desta análise. Satisfação dos Usuários do Software SysOKA 100,00% 80,00% 60,00% 40,00% 20,00% 0,00% Indiferente Índice de Satisfação

145 145 Gráfico 1: Índice de satisfação dos usuários do software SysOKA É possível notar que o índice de satisfação atingido pelo software SysOKA é muito alto, mas esse número, independente de ser bom ou ruim, não deve ser considerado isoladamente, se faz necessário avaliar o grau de satisfação dos usuários dentro das Características e Subcaracterísticas de qualidade do software. 3.2 Grau de Satisfação por Característica O Gráfico 2 e a Tabela 1 apresentam uma visão do quão satisfeitos estão os usuários do software SysOKA em relação as Características Funcionalidade, Usabilidade e Eficiência, que compõem a análise do grau de Satisfação geral dos usuários do software avaliado. Satisfação dos Usuários por Característica 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Indiferente Funcionalidade Usabilidade Eficiência Gráfico 2: Satisfação dos usuários por característica Indiferente Funcionalidade 3,92% 4,58% 15,03% 39,22% 30,72% Usabilidade 6,59% 5,41% 9,41% 39,29% 35,29% Eficiência 0,00% 10,78% 6,86% 50,98% 28,43% Tabela 1: Satisfação dos Usuários por Característica Efetuando-se a análise dentro das Características, nota-se que continua muito boa a aceitação do SysOKA, mas é possível observar que existem pontos de melhoria para o software, onde o índice de s e s estão em torno de 10%. Portanto, é necessário analisar as Subcaracterísticas para identificar se esse percentual de insatisfação está restrito a pontos específicos do software.

146 Grau de Satisfação: Característica Funcionalidade O Gráfico 3, o Gráfico 4 e o Gráfico 5 apresentam uma visão analítica da Característica Funcionalidade, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do SysOKA. Característica Funcionalidade 40,00% 35,00% 30,00% 25,00% 39,22% 30,72% 20,00% 15,00% 10,00% 5,00% 0,00% 3,92% 4,58% 15,03% Indiferente Gráfico 3: Índice de satisfação na Característica Funcionalidade Funcionalidade: subcaracterística Acurácia 45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% 0,00% 0,00% 15,69% Indiferente 39,22% 43,14% Gráfico 4: Característica Funcionalidade: Subcaracterística Acurácia

147 147 Funcionalidade: subcaracterística Adequação 40,00% 35,00% 30,00% 25,00% 39,22% 24,51% 20,00% 15,00% 10,00% 5,00% 0,00% 5,88% 6,86% 14,71% Indiferente Gráfico 5: Característica Funcionalidade: Subcaracterística Adequação Com a visualização individualizada das Subcaracterísticas Acurácia e Adequação, é possível observar que o principal ofensor na Característica Funcionalidade reside na Adequação do software. Na Seção 3.6 serão apresentadas variáveis externas ao software que possam impactá-lo, mas nesse momento devem ser apresentadas algumas que podem estar impactando diretamente na avaliação da Adequação do SysOKA: O treinamento recebido para utilização do software foi classificado como Fraco ou Regular para cerca de 80% dos entrevistados. Cerca de 70% dos entrevistados utilizaram o software no máximo dez vezes. Considerando esses fatores externos, pode-se inferir que a Subcaracterística Adequação foi afetada devido o baixo nível de experiência no uso do SysOKA e o treinamento inadequado ofertado aos usuários. Portanto, orienta-se que sejam tomadas ações de treinamento, e que vise demonstrar a adequação do software à necessidade dos usuários. 3.4 Grau de Satisfação: Característica Usabilidade Os Gráficos 6, 7, 8, 9 e 10 apresentam uma visão analítica da Característica Usabilidade, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do SysOKA.

148 148 Característica Usabilidade 40,00% 35,00% 39,29% 35,29% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 6,59% 5,41% 9,41% 0,00% Indiferente Gráfico 6: Índice de satisfação na Característica Usabilidade Usabilidade: subcaracterística Inteligibilidade 50,00% 48,53% 40,00% 30,00% 20,00% 22,06% 10,00% 8,09% 8,82% 7,35% 0,00% Indiferente Gráfico 7: Característica Usabilidade: Subcaracterística Inteligibilidade

149 149 Usabilidade: subcaracterística Apreensibilidade 30,00% 27,45% 25,00% 21,57% 20,00% 15,00% 13,73% 15,69% 11,76% 10,00% 5,00% 0,00% Indiferente Gráfico 8: Característica Usabilidade: Subcaracterística Apreensibilidade Usabilidade: subcaracterística Operacionalidade 45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% 3,92% 1,96% 10,46% Indiferente 39,22% 41,83% Gráfico 9: Característica Usabilidade: Subcaracterística Operacionalidade

150 150 Usabilidade: subcaracterística Atratividade 60,00% 58,82% 50,00% 40,00% 30,00% 31,76% 20,00% 10,00% 0,00% 0,00% 1,18% 7,06% Indiferente Gráfico 10: Característica Usabilidade: Subcaracterística Atratividade Com a visualização individualizada das Subcaracterísticas Inteligibilidade, Apreensibilidade, Operacionalidade e Atratividade, é possível observar que nos quesitos Inteligibilidade e Operacionalidade é possível buscar melhorias no software, mas o principal ofensor na Característica Usabilidade reside na Apreensibilidade do software. Na Seção 3.6 serão apresentadas variáveis externas ao software que possam impactá-lo, mas nesse momento devem ser apresentadas algumas que podem estar impactando diretamente na avaliação da Apreensibilidade do SysOKA: O treinamento recebido para utilização do software foi classificado como Fraco ou Regular para cerca de 80% dos entrevistados. O treinamento recebido pelos usuários pode estar afetando diretamente a Subcaracterística Apreensibilidade, levando a crer que o treinamento ofertado aos usuários foi inadequado. Portanto, orienta-se que sejam tomadas ações de treinamento no software para os usuários. 3.5 Grau de Satisfação: Característica Eficiência Os Gráficos 11, 12 e 13 apresentam uma visão analítica da Característica Eficiência, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do SysOKA.

151 151 Característica Eficiência 60,00% 50,00% 50,98% 40,00% 30,00% 28,43% 20,00% 10,00% 0,00% 0,00% 10,78% 6,86% Indiferente Gráfico 11: Índice de satisfação na Característica Eficiência Eficiência: subcaracterística Tempo 50,00% 45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% 0,00% 11,76% 1,96% Indiferente 45,10% 37,25% Gráfico 12: Característica Eficiência: Subcaracterística Tempo

152 152 Eficiência: subcaracterística Recursos 60,00% 56,86% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% 0,00% 9,80% 11,76% Indiferente 19,61% Gráfico 13: Característica Eficiência: Subcaracterística Recursos Com a visualização individualizada das Subcaracterísticas Tempo e Recursos, nota-se um índice de insatisfação muito pequeno. Embora possa ser uma oportunidade de melhoria nestes quesitos, não é possível afirmar com precisão o que pode estar causando tal insatisfação. Cabe ressaltar que das sugestões de melhoria que foram dadas pelos entrevistados, muitas estão relacionadas ao método OKA, método que foi automatizado pelo software SysOKA, e não ao software em si. Portanto, é possível que os entrevistados não tenham sido orientados corretamente no momento de responder a pesquisa e acabaram por confundir os conceitos do software SysOKA com o do método OKA, que tem particularidades que remetem diretamente a recursos e tempo. Orienta-se que depois de tomadas as devidas ações de treinamento, recomendadas em tópicos anteriores, seja feita nova avaliação, informando melhor os entrevistados para a correta dissociação entre software SysOKA e método OKA. 3.6 Fatores Externos A seguir será apresentada a tabulação da pesquisa quanto aos fatores externos, que devem ser considerados na análise da satisfação dos usuários do software SysOKA. Índice de utilização do software SysOKA Menos de 5 vezes De 6 a 10 vezes De 11 a 20 vezes Mais de 20 vezes 52,94% 17,65% 17,65% 11,76%

153 153 O software que está sendo avaliado foi implantado em substituição a algum outro software ou processo manual que você utilizava anteriormente? Não Sim Não se 70,59% 5,88% 11,76% 11,76% Você considera que as necessidades dos usuários foram levadas em consideração no desenvolvimento deste software? Não Sim Não se 5,88% 17,65% 47,06% 29,41% Como você classifica o treinamento recebido para utilizar o software? Fraco Regular Bom Ótimo Não se 5,88% 29,41% 17,65% 0,00% 47,06% Como você classifica seu nível de experiência no uso de sistemas computacionais? Fraco Regular Bom Ótimo Não se 0,00% 17,65% 23,53% 58,82% 0,00% Como você classifica seu nível de motivação com as tarefas que desempenha usando o software em questão? Fraco Regular Bom Ótimo Não se 0,00% 5,88% 35,29% 41,18% 17,65% Como você classifica as condições do local de trabalho para a execução das tarefas que dependem do software? Fraco Regular Bom Ótimo Não se 23,53% 0,00% 23,53% 41,18% 11,76% Como você classifica o nível do suporte prestado em caso de dúvidas ou problemas? Fraco Regular Bom Ótimo Não se 29,41% 11,76% 23,53% 5,88% 29,41% Como você classifica os meios ofertados ao usuário para apresentar sugestões de melhoria? Fraco Regular Bom Ótimo Não se 17,65% 35,29% 11,76% 5,88% 29,41%

154 154 Em termos de velocidade de processamento, como você classifica os computadores usados com este software? Fraco Regular Bom Ótimo Não se 0,00% 11,76% 52,94% 29,41% 5,88% Como você classifica o seu grau de fluência no idioma em que o software é apresentado? Fraco Regular Bom Ótimo Não se 0,00% 0,00% 41,18% 52,94% 5,88% 3.7 Comentários, Críticas e Sugestões dos Entrevistados A seguir são apresentados os comentários, críticas e sugestões dos entrevistados. Comentário 1: A qtd de perguntas é muito grande para se pedir que pessoas com pouco tempo disponível, como um gestor, respondam. Sinto falta de uma visão mais adequada onde o gestor do processo de uso do SysOKA possa ver quem já respondeu a quantas perguntas. Comentário 2: 1.Redução do número de perguntas, proporcionando assim ampliação dos interessados em responder; 2.Maior clareza nas perguntas, possibilitanto maior grau de segurança para respondentes que desconheçam GC. Comentário 3: Desenvolvimento de um diagrama por dimensão do conhecimento. Comentário 4: Faltou a melhor forma de respoder o questionário, se em grupo ou individual, se poderia ser respondido por pilar (pessoas, sistemas ou processos, quantidade de pessoas para melhor análise entre outros pontos. Comentário 5: 1. Indicar a escala dos resultados gerados pelo Sistema OKA para cada dimensão, pois esta fica implícita, mas não pude confirmar em nenhum lugar; 2.Como mencionado no documento da Ana Flávia Fonseca sobre o Método, de 12/05/2006, haverá ou haveria intervalos que mostrariam, apenas com os resultados de nossa organização, o grau de efetividade em cada dimensão. Se já existem esses intervalos de referência, indicar como ter acesso a eles; 3. Disponibilizar meio processo para se obter a comparação com a Média das Organizações Internacionais e com a das Organizações do Setor; 4. Seria muito interessante para o usuário ter acesso aos resultados obtidos, por questão, dimensão ou mesmo elemento, de todos os respondentes, para fins de análises estatísticas como desvio padrão e variância; 5. Por último e relacionada à sugestão 4, para adequado tratamento estatístico dos dados, poderia haver no sistema funcionalidade de exportação dos dados de todos os respondentes, por exemplo, para um banco de dados (MS-Access) ou planilha. Comentário 6: Achei o Sysoka muito fácil de usar Comentário 7: Poder exportar o banco de dados

155 Conclusão O software SysOKA foi muito bem avaliado por seus usuários, remetendo a um índice de mais de 80% de satisfação com o produto, mas alguns pontos devem ser avaliados com a maior brevidade possível, pois podem impactar diretamente na qualidade percebida por seus usuários. Dentre os problemas encontrados que poderiam remeter a um baixo índice de satisfação dos usuários do software SysOKA, foi possível constatar que o treinamento dado aos usuários não foi adequado, sendo o principal ofensor a satisfação de seus usuários, e conseqüentemente a qualidade do produto. Deve ser avaliado o serviço de suporte prestado aos usuários do software SysOKA, que embora não tenha afetado diretamente a satisfação dos mesmos, poderá ao longo do tempo afetar a percepção de qualidade do produto. Aprimorar os meios ofertados aos usuários para apresentar sugestões de melhoria no software SysOKA. Uma vez que os usuários tenham necessidades específicas atendidas pelo software dentro de um contexto de uso específico, aumenta a qualidade do produto percebida pelos mesmos.

156 156 APÊNDICE G TELAS DO QUESTIONÁRIO HOSPEDADO NO LIMESURVEY 1) Tela introdutória aos entrevistados: 2) Tela da Parte 1 do instrumento iasus:

157 157 3) Tela da Parte 2 do instrumento iasus: 4) Tela da Parte 3 do instrumento iasus:

158 5) Tela da Parte 4 do instrumento iasus: 158

159 159 APÊNDICE H RELATÓRIO DE AVALIAÇÃO DO ERP P A seguir será apresentado o relatório de avaliação da satisfação dos usuários do ERP P. Este relatório foi produzido a partir da aplicação do instrumento iasus Instrumento para Avaliação da Satisfação de Usuários de Software. Avaliação do Grau de Satisfação dos Usuários do ERP P Empresa Usuária: Montadora de Veículos X Software Avaliado: ERP P Data do Relatório: 20/07/2009 Versão do Documento: 1.0 Consultor Responsável pela Análise: Welington Alves 1. Introdução 1.1 Objetivo Através da aplicação do Instrumento iasus, procurou-se identificar o grau de Satisfação dos usuários do ERP P com seu uso, e desta forma, prover à empresa desenvolvedora do citado software, subsídios a melhoria continua do ERP P. Este relatório apresenta uma análise da compilação dos dados obtidos com a aplicação do Instrumento iasus, onde serão apresentadas possíveis deficiências do ERP P. Como parte da mensuração do grau de Satisfação e análise do que pode estar gerando tal resultado, serão apresentados dados analíticos de Características e Subcaracterísticas do Modelo de Qualidade para Qualidade em Uso de Softwares da Norma ISO/IEC 9126 de 2003.

160 160 Não é objetivo do instrumento ou desta análise, avaliar áreas específicas do software, como por exemplo se a Usabilidade do software é boa ou não, e sim, identificar áreas que possam ser a causa da insatisfação dos usuários no uso do software. Se tal constatação estiver relacionada à Usabilidade do software, então deverão ser aplicados métodos específicos para avaliar a Usabilidade de softwares. 1.2 Participantes O software objeto desta análise é o ERP P, desenvolvido para satisfazer os mais complexos requisitos de negócio. Com módulos integrados de gestão de ativos, CRM, automação de serviços, gestão financeira, RH e suprimentos, dentre outros. A avaliação do grau de Satisfação para com o ERP P foi conduzida da seguinte forma: Empresa: A empresa usuária do ERP P é uma companhia multinacional do segmento de veículos. A avaliação se deu junto a usuários do ERP P de uma de suas montadoras. Usuários participantes: 11 Perfil dos participantes: Não houve seleção prévia dos respondentes. O único requisito a participar da avaliação é que o entrevistado fosse usuário do ERP P na empresa Montadora de Veículos X. Uma vez que os dados são apresentados de forma consolidada não haverá identificação individual dos respondentes. 2. Conceitos Com o intuito de alinhar o entendimento acerca de conceitos e termos técnicos utilizados neste documento, a seguir serão apresentadas algumas definições importantes para que se obtenha pleno entendimento desta análise. 2.1 Norma ISO/IEC (2003) Norma que tem como título geral Engenharia de Software Qualidade do Produto. 2.2 Modelo de Qualidade Conjunto de características e os relacionamentos entre elas, que fornecem a base para a especificação dos requisitos de qualidade e para a avaliação de qualidade. Este modelo está dividido em duas partes: a) Modelo de qualidade para qualidade interna e externa; b) Modelo de qualidade para qualidade em uso.

161 Qualidade É a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explicitas e implícitas. 2.4 Modelo de Qualidade para Qualidade em Uso de Softwares 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 sob a perspectiva do usuário. 2.5 Característica Satisfação do Modelo de Qualidade em Uso Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado. É a resposta do usuário a interação com o produto e inclui atitudes relacionadas ao uso do produto. 2.6 Característica Funcionalidade do Modelo de Qualidade para Qualidade Interna e Externa Capacidade do produto de software de prover funções que atendam às necessidades explicitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas Subcaracterística Adequação Capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados Subcaracterística Acurácia Capacidade do produto de software de prover, com grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados. 2.7 Característica Usabilidade do Modelo de Qualidade para Qualidade Interna e Externa Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas Subcaracterística 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.

162 Subcaracterística Apreensibilidade Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação Subcaracterística Operacionalidade Capacidade do produto de software de possibilitar ao usuário operá-lo e controlá-lo Subcaracterística Atratividade Capacidade do produto de software de ser atraente ao usuário. 2.8 Característica Eficiência do Modelo de Qualidade para Qualidade Interna e Externa Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas Subcaracterística 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 Subcaracterística 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. 3. Resultados 3.1 Grau de Satisfação Consolidado O Gráfico 1 apresenta o grau de satisfação dos usuários do ERP P com este produto. Esta informação foi obtida através de uma pergunta direta aos entrevistados: Qual seu grau de satisfação em relação ao software que está sendo avaliado?. Esta pergunta não é utilizada diretamente na avaliação do software, servirá apenas como referência aos resultados que serão apresentados no decorrer desta análise.

163 163 Satisfação dos Usuários do "ERP P" 80,00% 60,00% 40,00% 20,00% 0,00% Indiferente Índice de Satisfação Gráfico 1: Índice de satisfação dos usuários do ERP P É possível notar que o índice de satisfação atingido pelo ERP P é relativamente alto, 81,82%, mas esse número, independente de ser bom ou ruim, não deve ser considerado isoladamente, se faz necessário avaliar o grau de satisfação dos usuários dentro das Características e Subcaracterísticas de qualidade de software. 3.2 Grau de Satisfação por Característica O Gráfico 2 e a Tabela 1 apresentam uma visão do quão satisfeitos estão os usuários do ERP P em relação as Características Funcionalidade, Usabilidade e Eficiência, que compõem a análise do grau de Satisfação geral dos usuários do software avaliado. Satisfação dos Usuários por Característica 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Indiferente Funcionalidade Usabilidade Eficiência Gráfico 2: Satisfação dos usuários por característica

164 164 Funcionalidade Usabilidade Eficiência Tabela 1: Satisfação dos Usuários por Característica Indiferente 11,11% 9,09% 2,02% 53,54% 24,24% 6,18% 8,00% 14,55% 43,27% 28,00% 12,12% 19,70% 7,58% 50,00% 10,61% Efetuando-se a análise dentro das Características, nota-se que continua muito boa a aceitação do ERP P, mas é possível observar que existem pontos de melhoria para o software, onde o índice de s e s variam de 15% a 30%, de acordo com a Característica. Portanto, é necessário analisar as Subcaracterísticas para identificar se esse percentual de insatisfação está restrito a pontos específicos do software. 3.3 Grau de Satisfação: Característica Funcionalidade O Gráfico 3, o Gráfico 4 e o Gráfico 5 apresentam uma visão analítica da Característica Funcionalidade, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do ERP P. Característica Funcionalidade 60,00% 53,54% 50,00% 40,00% 30,00% 24,24% 20,00% 10,00% 11,11% 9,09% 2,02% 0,00% Indiferente Gráfico 3: Índice de satisfação na Característica Funcionalidade

165 165 Funcionalidade: subcaracterística Acurácia 70,00% 60,00% 60,61% 50,00% 40,00% 30,00% 27,27% 20,00% 10,00% 0,00% 3,03% 9,09% 0,00% Indiferente Gráfico 4: Característica Funcionalidade: Subcaracterística Acurácia Funcionalidade: subcaracterística Adequação 50,00% 50,00% 40,00% 30,00% 22,73% 20,00% 10,00% 15,15% 9,09% 3,03% 0,00% Indiferente Gráfico 5: Característica Funcionalidade: Subcaracterística Adequação Com a visualização individualizada das Subcaracterísticas Acurácia e Adequação, é possível observar que o principal ofensor na Característica Funcionalidade reside na Adequação do software. A posteriori serão apresentadas variáveis externas ao software que possam impactá-lo, mas nesse momento devem ser apresentadas algumas que podem estar impactando diretamente na avaliação da Adequação do ERP P. O treinamento recebido para utilização do software foi classificado como Fraco ou Regular para 27,27% dos entrevistados. Para 27% dos entrevistados as necessidades dos usuários não foram consideradas no software. Para 54,55% dos entrevistados o ERP P veio a substituir outro software. Considerando esses fatores externos, pode-se inferir que a

166 166 Subcaracterística Adequação foi afetada a um treinamento inadequado ofertado a alguns usuários. Portanto, orienta-se que sejam tomadas ações de treinamento, que vise demonstrar a adequação do software à necessidade dos usuários. 3.4 Grau de Satisfação: Característica Usabilidade Os Gráficos 6, 7, 8, 9 e 10 apresentam uma visão analítica da Característica Usabilidade, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do ERP P. Característica Usabilidade 50,00% 43,27% 40,00% 30,00% 28,00% 20,00% 14,55% 10,00% 6,18% 8,00% 0,00% Indiferente Gráfico 6: Índice de satisfação na Característica Usabilidade Usabilidade: subcaracterística Inteligibilidade 50,00% 44,32% 40,00% 30,00% 20,00% 10,00% 6,82% 9,09% 18,18% 21,59% 0,00% Indiferente Gráfico 7: Característica Usabilidade: Subcaracterística Inteligibilidade

167 167 Usabilidade: subcaracterística Apreensibilidade 35,00% 30,00% 27,27% 33,33% 25,00% 20,00% 15,00% 15,15% 18,18% 10,00% 6,06% 5,00% 0,00% Indiferente Gráfico 8: Característica Usabilidade: Subcaracterística Apreensibilidade Usabilidade: subcaracterística Operacionalidade 50,00% 46,46% 40,00% 30,00% 27,27% 20,00% 10,00% 5,05% 9,09% 12,12% 0,00% Indiferente Gráfico 9: Característica Usabilidade: Subcaracterística Operacionalidade Usabilidade: subcaracterística Atratividade 50,00% 41,82% 45,45% 40,00% 30,00% 20,00% 10,00% 1,82% 5,45% 5,45% 0,00% Indiferente Gráfico 10: Característica Usabilidade: Subcaracterística Atratividade

168 168 Com a visualização individualizada das Subcaracterísticas Inteligibilidade, Apreensibilidade, Operacionalidade e Atratividade, é possível observar que nos quesitos Inteligibilidade e Operacionalidade é possível buscar melhorias no software, mas o principal ofensor na Característica Usabilidade reside na Apreensibilidade do software. A posteriori serão apresentadas variáveis externas ao software que possam impactá-lo, mas nesse momento devem ser apresentadas algumas que podem estar impactando diretamente na avaliação da Apreensibilidade do ERP P. O treinamento recebido para utilização do software foi classificado como Fraco ou Regular para 27% dos entrevistados, o que pode estar afetando diretamente a Subcaracterística Apreensibilidade, levando a crer que o treinamento ofertado aos usuários foi inadequado. Portanto, orientase que sejam tomadas ações de treinamento no software para os usuários. 3.5 Grau de Satisfação: Característica Eficiência Os Gráficos 11, 12 e 13 apresentam uma visão analítica da Característica Eficiência, onde pode ser visto qual Subcaracterística foi a maior ofensora da satisfação dos usuários do ERP P. Característica Eficiência 50,00% 50,00% 40,00% 30,00% 20,00% 10,00% 12,12% 19,70% 7,58% 10,61% 0,00% Indiferente Gráfico 11: Índice de satisfação na Característica Eficiência

169 169 Eficiência: subcaracterística Tempo 60,00% 50,00% 51,52% 40,00% 30,00% 20,00% 10,00% 15,15% 18,18% 6,06% 9,09% 0,00% Indiferente Gráfico 12: Característica Eficiência: Subcaracterística Tempo Eficiência: subcaracterística Recursos 50,00% 48,48% 40,00% 30,00% 21,21% 20,00% 10,00% 9,09% 9,09% 12,12% 0,00% Indiferente Gráfico 13: Característica Eficiência: Subcaracterística Recursos Com a visualização individualizada das Subcaracterísticas Tempo e Recursos, nota-se um índice de insatisfação relativamente alto, cerca de 30%. Cerca de 18% classificaram a velocidade de processamento dos computadores utilizados com o ERP P como fraco ou regular, e 63% como sendo boa, o que pode caracterizar a necessidade de uma avaliação dos equipamentos utilizados. Uma vez que tenha sido descartado um possível problema de desempenho nos equipamentos, o nível de insatisfação com a Eficiência do software pode residir também em questões de treinamento, pois os usuários podem estar gastando muito tempo na localização de funcionalidades, ferramentas e até mesmo executando tarefas por vias mais trabalhosas.