Análise das Métricas Usabilidade - Measurement-and-Metrics-2018-1/2017.1-SIGS GitHub Wiki
Data | Versão | Descrição | Autor(es) |
---|---|---|---|
22/06/2018 | 1.0 | Elaboração do documentação. | Bruno Matias Casas, Carlos Aragon, Francisco Wallacy Coutinho Braz |
Histórico de Revisão
Coleta
Como dito anteriormente na documentação sobre a ferramenta utilizada para a coleta dos dados referente a usabilidade, tornou-se necessário utilizar ferramentas que permitam que o processo de coleta seja baseado em algum ponto de vista subjetivo, sendo assim a utilização de um checklist foi a escolha cabível para suprir as necessidades, em conjunto com entrevistas feitas com coordenadores e ex-coordenadores, dessa forma tornou-se possível o preenchimento do checklist do ponto de vista adequado.
Primeiramente aconteceu o agendamento das entrevistas para dois coordenadores e um ex-coordenador: André Barros, Paula Mayer e Carla Rocha da universidade de brasília, respectivamente. Caso o preenchimento do checklist fosse possível para esses 3 casos, seriam proporcionados um bom conjunto de dados para serem analisados pois além de em todos os casos serem coordenadores , deve-se considerar o fato de que o nível de conhecimento do referido contexto e usabilidade é diverso. Por motivos além do alcance do grupo, só foi possível a entrevista com o coordenador André Barros que está inserido no meio da TI e possui muita experiência referente a usabilidade. Dessa forma a coleta dos dados foi inteiramente referente a essa entrevista.
Na entrevista, pedimos que o entrevistado entrasse no link da aplicação, e executasse cada funcionalidade , e para cada uma, previamente, havia uma explicação para que assim o mesmo conseguisse efetuar as ações, ao final de cada ação referente a funcionalidade foram apresentadas as questões do checklist que foram prontamente respondidas.
O checklist foi montado seguindo um conjunto de funcionalidades acessíveis pelo coordenador, que são elas:
F02 - Manter Sessão de Usuário |
F03 - Solicitar Cadastro |
F06 - Manter Turma |
F07 - Manter Alocações |
F08 - Visualizar Alocação |
F09 - Solicitar Alocação em Espaço Comum |
F10 - Gerenciar Solicitações de Espaço Comum |
F11 - Gerar Relatório |
Dessa forma para cada funcionalidade há um conjunto de questões que são diretamente direcionadas para coletar dados das métricas. Tais métricas foram obtidas do padrão ISO/IEC 25023:2016(SQuaRE) ,que dentre outras especificações, definem algumas métricas de usabilidade. As questões são:
M 1.1.1 - É Descrita de forma compreensível na documentação do produto? | M 1.1.2 - Necessita de capacidade de demonstração? Se sim, está implementado com essa capacidade? | M 1.2.1 - Descrição sobre a funcionalidade na documentação do usuário e / ou facilitação de ajuda se encontra de forma correta? | M 1.3.2 - Funcionalidade requer a capacidade de customização? Se sim, está implementado? | M 1.3.3- Referente ao(s) caminho(s) de tal funcionalidade,quantos são inconsistente(s)? | M 1.4.1 - Campos de entrada referente a funcionalidade necessita de checagem de validade? Se sim, está implementado? | M 1.5.1 - É acessível à pessoas com algum tipo de deficiência? | M 1.6.1 - Elementos de interface referente a funcionalidade podem ser personalizados (se sim, quais na observação)? |
---|
Para as métricas que necessitam de quantidades de componentes atrelados às questões, foram previamente coletadas para facilitação da coleta(Dados objetivos, interno) . Em particular a métrica 1.6.1 referente aos elementos de interface, há a anotação de cada elemento descrito pelo coordenador que necessita de personalização.
Feita a entrevista com o coordenador André Barros, obteve-se as seguintes respostas:
M 1.1.1 | M 1.1.2 | M 1.2.1 | M 1.3.2 | M 1.3.3 | M 1.4.1 | M 1.5.1 | M 1.6.1 | |
---|---|---|---|---|---|---|---|---|
F02 | sim | não | sim | não | 1 - 0 | sim, sim | não | 9 - 0 |
F03 | sim | não | sim | sim, sim | 1 - 0 | sim, sim | não | 14 - 4 |
F06 | sim | sim, não | não | sim, sim | 1 - 0 | sim, sim | não | 10 - 2 |
F07 | não | sim, não | não | sim, sim | 1 - 0 | sim, sim | não | 13 - 3 |
F08 | não | não | não | sim, não | 2 - 0 | sim, sim | não | 5 - 2 |
F09 | não | sim, não | não | sim, sim | 1 - 0 | sim, sim | não | 7 - 0 |
F10 | não | sim, não | não | sim, não | 1 - 0 | não | não | 8 - 2 |
F11 | sim | não | não | sim, não | 1 - 0 | sim, sim | não | 21 - 1 |
obs: Devido a imprevisto ocorrido durante a entrevista, algumas questões do checklist foram preenchidos pelo grupo com base na percepção do usuário entrevistado.
Com isso é possível coletar as informações necessárias para obtenção das métricas:
M 1.1.1 | A = Numero funções (ou tipos de função) descritas de forma compreensívelB = Número total de funções (ou tipos de função) A = 4B = 8Formula: X = A/BResultado: 0.5 |
M 1.1.2 | A = Número de funções implementadas com capacidade de demonstração B = Número total de funções que necessitam de capacidade de demonstração A = 0B = 4Formula: X = A/BResultado: 0 |
M 1.2.1 | A= Números de funções descritas corretamenteB= Total de função implementadasA = 2B = 8Formula: X = A/BResultado: 0.25 |
M 1.3.2 | A = Número de funções implementadas que podem ser customizadas durante a operaçãoB = Número de funções que requerem a capacidade de customizaçãoA = 4B = 7Formula: X = A/BResultado: 0.57 |
M 1.3.3 | A = Número de operações que se comportam de forma inconsistenteB = Número total de operações que se comportam de forma similarA = 0B = 1Formula: X = A/BResultado: 0 |
M 1.4.1 | A = Número de itens de entrada checados para a validação dos dados B = Número de itens de entrada que necessitam de checagem para a validação de dados A = 7B = 7Formula: X = A/BResultado: 1 |
M 1.5.1 | A = Número de funções acessíveis à pessoas com algum tipo de deficiênciaB = Número total de funções implementadas A = 0B = 8Formula: X = A/BResultado: 0 |
M 1.6.1 | A = Número de tipos de elementos de interface que podem ser personalizados.B = Número total de tipos de elementos de interface A = 14B = 87Formula: X = A/BResultado: 0.16 |
Observações por funcionalidade referente a métrica 1.6.1:
F03 | 1.Registro unb na verdade é matrícula fub2.Checkbox e nome no campo de tipo de usuário3. Possibilidade de retornar a página de login4.Mensagem para o usuário deveria aparecer na mesma página |
F06 | 1.Informação sobre qual turma será deletada2.Possibilidade de voltar para página de listagem de turmas na criação |
F07 | 1.Posição do campo de selecionar sala2.mudar os termo da deslocação, seguir padrão3.liberdade do usuário de voltar para a página anterior |
F08 | 1.Possibilidade de visualizar turmas já alocadas na página de alocação2.Liberdade do usuário de voltar para a página anterior |
F10 | 1.As solicitações de espaço comum recusadas não apresenta histórico2.Na listagem de solicitações há "lixo" em sua apresentação |
F11 | 1.O tipo de relatório pode ser personalizado por meio dos campos de filtragem e disposição em uma mesma tela |
Para a métrica 1.3.1 - Clareza de mensagem, feita separadamente, foram listadas todas as mensagens do sistema, assim sendo feita uma revisão, verificando se cada mensagem se encontra compreensível. Com isso foi possível obter dados para obtenção da métrica:
M 1.3.1 | A= Número de mensagens assimiladasB = Número total de mensagens implementadas A = 33B = 38 Formula: X = A/BResultado: 0.86 |
Análise dos resultados
M1.1.1 - Completude da descrição. Baseado no resultado desta métrica, que foi 0,5, é possível constatar que as funcionalidades do sistema encontram-se descritas de forma incompleta em sua descrição. Como consequência, usuários do sistema podem não entender completamente o que o sistema é capaz de oferecer no que diz respeito às suas funcionalidades.
M1.1.2 - Capacidade de demonstração. No que tange essa métrica, cujo resultado foi de 0, é possível verificar que para todas as funcionalidades que segundo a visão do coordenador necessitam de algum tipo de demonstração, não existe implementação. Mais uma vez o resultado encontra-se de acordo com a baseline. Em adição, é possível abstrair dessa métrica a idéia de que o sistema possui uma alta complexidade de uso, pois metade de suas funcionalidades não são intuitivas até mesmo para usuários que entendem do contexto do sistema.
M1.2.1 -. Referente a esta métrica cuja pontuação foi de 0.25, é possível perceber que o sistema no geral encontra-se carente de documentação. Tal resultado encontra-se de acordo com sua hipótese de baseline. Esta métrica pode ser usada com a intenção pura de melhorar a documentação, artefato muito importante para o entendimento do software/sistema.
M. 1.3.1 - Clareza de mensagens. Baseado no valor obtido para esta métrica, conclui-se que os usuários do sistema são capazes de entender a maioria das mensagens emitidas pelo sistema.
M.1.3.2 - Possibilidade de customização. Referente a esta métrica cuja pontuação foi de 0.57, é possível perceber que o sistema possui algumas funcionalidades customizáveis, porém ainda existem algumas que também o poderiam. Apesar da hipótese de baseline para esta métrica estar abaixo, 0.4, a diferença não justificaria uma previsão incorreta. Ou seja, encontra-se dentro do esperado.
M.1.3.3 - Consistência Operacional. Como foi constatado durante a coleta que somente uma das funcionalidades possuíam duas formas de ser acessada, e essas duas formas eram consistentes, pode-se concluir então que o sistema não possui nenhuma inconsistência nesse sentido.
M 1.4.1 - Validação de entrada de dados. Referente a esta métrica cuja pontuação foi de 1, é possível constatar que no contexto de validação de entrada de dados, todos os campos possuem algum tipo de validação.
M 1.5.1 - Acessibilidade física. Referente a esta métrica cuja pontuação foi de 0, é possível constatar que o sistema não lida de forma nenhuma com questões de acessibilidade.
M 1.6.1 - Customização estética da interface do usuário - Para esta métrica, cuja pontuação foi de 0.16, mostra que nesse quesito de personalização, o sistema encontra-se dentro de um valor aceitável de qualidade.
Em suma, baseando-se que os resultados da maioria das métricas coletadas refletem um baixo grau de qualidade nos seus respectivos elementos de usabilidade, é possível concluir que o atual estado da qualidade da usabilidade do sistema SIGS encontra-se de baixo e portanto passível de melhoria. Tal melhoria pode ser executada segundo a perspectiva dos resultados obtidos.
Providências a serem tomadas
Em decorrência dos resultados coletados durante a medição pode-se enumerar uma série de melhorias, do ponto de vista do grupo, para que os critérios definidos antes da coleta de métricas sejam alcançados.
Objetivando a melhora da usabilidade do sistema em termos gerais algumas das soluções propostas são:
- Alteração dos nomes de alguns dos campos de preenchimento para melhor adequação ao contexto da aplicação.
- Padronização das caixas de seleção e grupos de botões.
- Implementação de guias para funções principais do sistema.
- Inclusão de documentação para melhoria de descrição das funcionalidades.
- Incremento de informação nas mensagens de erro.
- Inclusão de mecanismos para possibilitar maior liberdade por parte do usuário.
- Incluir informação sobre o item a ser deletado na mensagem de confirmação.
- Padronização da interface de funcionalidades parecidas.
- Implantação de mecanismos de acessibilidade no sistema.
- Adoção de padrão de cores e identidade visual da UnB.