Upload
doanmien
View
212
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA REGISTRO DE PRESENÇAS EM AULAS PARA A ACADEMIA WAVE UTILIZANDO RECONHECIMENTO BIOMÉTRICO
por
Rafael Macário da Rocha
Itajaí (SC), Novembro de 2013
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA REGISTRO DE PRESENÇAS EM AULAS PARA A ACADEMIA WAVE UTILIZANDO RECONHECIMENTO BIOMÉTRICO
Área de Sistemas de Informação
por
Rafael Macário da Rocha
Relatório apresentado à Banca Examinadora do Trabalho Técnico-científico de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Adriana Gomes Alves, M. Eng.
Itajaí (SC), Novembro de 2013
RESUMO
ROCHA, Rafael Macário da. Sistema para Registro de Presenças em Aulas para a Academia Wave utilizando Reconhecimento Biométric o. Itajaí, 2013. 107 páginas. Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2013. Um dos grandes diferenciais da Academia Wave é oferecer aos alunos uma variada lista de programas destinados à prática de atividades físicas como, aulas de ginástica, natação e artes marciais. Com o tempo, surgiu a necessidade de controlar o acesso dos alunos a estas aulas, e também de ter uma ferramenta para demonstração de indicadores de desempenho das aulas oferecidas. Observando esta necessidade da empresa, durante a disciplina de Engenharia de Software no curso de Ciência da Computação, foi desenvolvido um software em que os alunos pudessem registrar suas presenças, digitando sua matrícula e data de nascimento. Apesar da visível melhora no processo, alguns problemas foram revelados e algumas ideias foram sugeridas para implementação. O principal problema relatado era a formação de filas em horários de pico das aulas, isso porque alguns alunos possuem dificuldade em memorizar a sua matrícula, um segundo problema era a falta de usabilidade, necessária para atender a larga faixa etária dos alunos. Neste contexto, o objetivo deste trabalho foi implementar a segunda versão do Sistema para Registro de Presenças em aulas para a Academia Wave utilizando reconhecimento biométrico e fazer a análise de usabilidade das interfaces, para que o principal problema enfrentado pela Academia Wave fosse eliminado. Após testes realizados antes e depois do desenvolvimento, houve uma grande diminuição no tempo de registro de presenças, passando de 15,30 segundos em média para 5,60 segundos. Palavras-chave: Usabilidade. Biometria. Sistemas de Informação.
ABSTRACT
The large differential of Gym Wave is to offer clients a diverse list of programs for physical activity as exercise classes, swimming and martial arts. Over time there was a need to control the access of students to those classes and also have a tool to demonstrate performance indicators of classes offered. Observing this business need for the discipline of software engineering course in Computer Science, a software was developed in which clients could record their presence by entering their enrollment and date of birth. Despite the visible improvement in the process, some problems were revealed and some ideas were suggested for implementation. The main problem reported is the formation of queues at peak times of the classes because some students have difficulty memorizing their registration, and the lack of usability analysis that is required to meet the wide age range of students. This project aims to create a second version of the System to Record Attendance in classes for the Gym Wave using biometric recognition and make the usability analysis of interfaces, so that the main problem faced by the Gym Wave is eliminated. After tests conducted before and after implementation, there was a large decrease in record time attendance, going from 15.30 seconds on average to 5.60 seconds. Keywords: Usability. Biometrics. Information Systems.
LISTA DE FIGURAS
Figura 1. Grade de aulas do totem ............................................................................ 20 Figura 2. Tipos de biometria ...................................................................................... 22 Figura 3. Impressão Digital........................................................................................ 25 Figura 4. Impressão Digital. Thinning ........................................................................ 25 Figura 5. Impressão digital recortada ........................................................................ 26 Figura 6. Dispositivos Touch Screen. ........................................................................ 31 Figura 7. Sistema Correlatado - Pacto Gestão de Academias .................................. 39 Figura 8. Sistema Correlatado - SCA ........................................................................ 40 Figura 9. Sistema Correlatado - iFitness ................................................................... 41 Figura 10. Sistema Correlatado - Cad4 ..................................................................... 41 Figura 11. Diagrama - totens primeira versão ........................................................... 44 Figura 12. Diagrama - totens segunda versão .......................................................... 45 Figura 13. Pacote Alterado - PCT01. Cadastro ......................................................... 49 Figura 14. Pacote Alterado - PTC02. Relatórios ....................................................... 51 Figura 15. Pacote Alterado - PCT03. Registrar Presença ......................................... 52 Figura 16. Pacote Novo - PCT04. Histórico de Presença ......................................... 53 Figura 17. Modelo Entidade-Relacional .................................................................... 54 Figura 18. Código XAML - Botão de aula .................................................................. 55 Figura 19. Código XAML - Style ................................................................................ 56 Figura 20. Método Buscas Aulas - Totem ................................................................. 57 Figura 21. Interface WCF .......................................................................................... 57 Figura 22. SQL de busca das aulas .......................................................................... 58 Figura 23. Grade de aulas - primeira versão ............................................................. 62 Figura 24. Grade de aulas - Nova versão ................................................................. 64 Figura 25. Tela de identificação ................................................................................ 65 Figura 26. Identificação biométrica ............................................................................ 67 Figura 27. Confirmação de presença ........................................................................ 68 Figura 28. Comprovante de presença ....................................................................... 68 Figura 29. Gerenciador de aulas ............................................................................... 71 Figura 30. Grade de aulas – Cadastro ...................................................................... 71 Figura 31. Cadastro de aulas da grade ..................................................................... 72 Figura 32. Relatório 1 - Presenças. ........................................................................... 73 Figura 33. Relatório 2 - Meta dos professores. ......................................................... 74 Figura 34. Histórico de Presenças ............................................................................ 74 Figura 35. Diagrama de Casos de Uso ..................................................................... 82 Figura 36. PCT01. Cadastros .................................................................................... 83 Figura 37. PCT02. Relatórios .................................................................................... 95 Figura 38. PCT03. Registrar presença ...................................................................... 97
LISTA DE TABELAS
Tabela 1. Análise de dados quantitativos .................................................................. 33 Tabela 2. Trabalhos Correlatados ............................................................................. 39 Tabela 3. Passos para registro de presença de aluno. ............................................. 59 Tabela 4. Média da avaliação de desempenho ......................................................... 59 Tabela 5. Média da avaliação de desempenho - Segundo teste ............................... 69 Tabela 6. UC01.01 - Cadastrar Professores ............................................................. 84 Tabela 7. UC01.02 - Cadastrar Salas ....................................................................... 85 Tabela 8. UC01.03 - Cadastrar Aulas ....................................................................... 86 Tabela 9. UC01.04 - Editar grade de aulas ............................................................... 88 Tabela 10. UC01.05 - Cadastrar Usuários ................................................................ 90 Tabela 11. UC01.06 - Cadastrar Modalidades .......................................................... 91 Tabela 12. UC01.07 - Cadastrar Faixas Etárias ........................................................ 92 Tabela 13. UC01.08 - Efetuar login ........................................................................... 93 Tabela 14. UC01.09 - Cadastrar Totens. .................................................................. 94 Tabela 15. UC02.01 - Emitir relatório de aulas realizadas por professor. ................. 96 Tabela 16. UC02.02 - Emitir relatório detalhado de presenças das aulas. ................ 96 Tabela 17. UC03.01 - Registrar presença na aula. ................................................... 98
LISTA DE QUADROS
Quadro 1. Características biométricas ...................................................................... 25 Quadro 2. Dados de retorno do aluno ....................................................................... 37 Quadro 3. Dados de retorno das biometrias.............................................................. 38 Quadro 4. Dados de retorno do funcionário .............................................................. 38
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface DLL Dynamic-link library ER Entidade Relacional ERP Enterprise Resource Planning RF Requisito Funcional RN Regra de Negócio RNF Requisito Não Funcional PCT Pacote SDK Software Development Kit TTC Trabalho Técnico-científico de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XAML eXtensible Application Markup Language XML Extensible Markup Language WCF Windows Communication Foundation WPF Windows Presentation Foundation
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................. 11
1.1 PROBLEMATIZAÇÃO ................................................................................................. 14
1.1.1 Formulação do Problema ......................................................................................... 14
1.1.2 Solução Proposta ...................................................................................................... 15
1.2 OBJETIVOS .................................................................................................................. 15
1.2.1 Objetivo Geral ............................................................................................................ 15
1.2.2 Objetivos Específicos ............................................................................................... 15
1.3 METODOLOGIA ........................................................................................................... 16
1.4 ESTRUTURA DO TRABALHO ................................................................................... 17
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 18
2.1 SISTEMA PARA REGISTRO DE PRESENÇAS EM AULAS DA ACADEMIA WAVE: PRIMEIRA VERSÃO .............................................................................................. 18
2.1.1 Módulo Gerenciador de Aulas ................................................................................. 18
2.1.2 Módulo dos Totens .................................................................................................... 20
2.2 BIOMETRIA ................................................................................................................... 21
2.2.1 Elementos da biometria ............................................................................................ 22
2.2.2 Identificação pela Impressão Digital ...................................................................... 24
2.2.3 SDK (Software Development Kit) ........................................................................... 27
2.3 USABILIDADE .............................................................................................................. 28
2.3.1 Avaliação de Usabilidade em Interfaces Touch Screen ..................................... 31
2.3.2 Testes de Usabilidade .............................................................................................. 32
2.4 WCF ................................................................................................................................ 34
2.4.1 Contratos .................................................................................................................... 35
2.4.2 Integração com o ERP da Academia Wave .......................................................... 36
2.5 TRABALHOS CORRELATADOS .............................................................................. 39
3 DESENVOLVIMENTO .................................................................................................... 43
3.1 ANÁLISE DE REQUISITOS ........................................................................................ 43
3.1.1 Informações sobre o sistema .................................................................................. 43
3.1.2 WCF para totens ....................................................................................................... 43
3.1.3 Requisitos Funcionais .............................................................................................. 45
3.1.4 Requisitos Não Funcionais ...................................................................................... 46
3.1.5 Regras de Negócio ................................................................................................... 48
3.1.6 Diagrama de Casos de Uso .................................................................................... 49
3.1.7 PCT01 – Cadastro .................................................................................................... 49
3.1.8 PCT02 – Relatórios ................................................................................................... 51
3.1.9 PCT03 – Registrar Presença .................................................................................. 51
3.1.10 PCT04 – Histórico de Aulas .................................................................................. 53
3.2 MODELO ENTIDADE-RELACIONAMENTO ........................................................... 53
3.3 IMPLEMENTAÇÃO ...................................................................................................... 55
3.3.1 Ferramentas utilizadas ............................................................................................. 55
3.3.2 Modificação do módulo dos totens ......................................................................... 55
3.3.3 WCF para os totens .................................................................................................. 56
3.4 INTERFACES, TESTE E RESULTADOS ................................................................ 58
3.4.1 Avaliação Heurística da primeira versão ............................................................... 61
3.4.2 Tela das aulas em andamento. ............................................................................... 61
3.4.3 Tela de identificação. ................................................................................................ 65
3.4.4 Resultado das Alterações. ....................................................................................... 69
3.4.5 Módulo Gerenciador das Aulas ............................................................................... 70
4 CONCLUSÕES ................................................................................................................ 75
APÊNDICE A. DOCUMENTO DE MODELAGEM DO SISTEMA .............................. 79
A.1 ANÁLISE DE REQUISITOS ....................................................................................... 79
A.1.1 Requisitos Funcionais .............................................................................................. 79
A.1.2 Requisitos não funcionais ........................................................................................ 80
A.1.3 Regras de negócio .................................................................................................... 81
A.2 CASOS DE USO .......................................................................................................... 82
A.2.1 Diagrama de pacotes ............................................................................................... 82
A.2.2 PCT01 – Cadastros .................................................................................................. 83
A.2.3 PCT02 – Relatórios .................................................................................................. 95
A.2.4 PCT03 – Registrar presença .................................................................................. 97
A.2.5 PCT04 – Histórico de Aulas .................................................................................. 101
APÊNDICE B. TESTE DE DESEMPENHO COM USUÁRIOS ................................ 103
B.1 TESTE COM A PRIMEIRA VERSÃO ..................................................................... 104
B.2 TESTE COM A SEGUNDA VERSÃO ..................................................................... 105
APÊNDICE C. TABELA DE NOMES DO BANCO DE DADOS ............................... 106
11
1 INTRODUÇÃO
Ter controle do negócio é essencial para qualquer empresa independente da
área de atuação, sendo assim, sistemas personalizados elaborados individualmente
para cada empresa tornam-se importantes ferramentas para garantir que este
controle seja eficaz e facilitar a tomada de decisões dos empresários. Os sistemas
personalizados objetivam atender necessidades específicas das empresas, o que
não ocorre com os sistemas comerciais normalmente praticados no mercado.
A Academia Wave foi fundada em 2000 na cidade de Balneário Camboriú no
Estado de Santa Catarina, tendo por objeto de negócio, oferecer exercícios físicos
com acompanhamento adequado, profissionais especializados e equipamentos de
ponta. Com o tempo conquistou o mercado e tornou-se referência no segmento
fitness na região litoral catarinense.
Ao longo dos anos a empresa abriu novas filiais em outras cidades,
atualmente possui quatro unidades, duas localizadas na cidade de Balneário
Camboriú, unidade Barra Sul e Barra Norte, uma em Camboriú e outra unidade na
cidade vizinha, Itapema.
Um dos seus grandes diferenciais é oferecer aos alunos uma variada lista de
programas destinados à prática de atividades físicas, sendo que, os programas são
elaborados de acordo com as necessidades dos alunos, com programas especiais
para idosos e crianças. Entre as atividades disponibilizadas estão: musculação,
aulas de natação para adultos, crianças e bebês, hidroginástica, vôlei, basquete,
futebol, aulas de ginástica, yoga, ballet, pilates, artes marciais como Judô, Karatê,
Jiu Jitsu entre outras. Outro grande diferencial é o acesso irrestrito a todas as
atividades pelos alunos indiferente do plano contratado, pois os mesmos
diferenciam-se apenas no tempo de vigência e no horário permitido para a entrada
na Academia.
Desde a sua inauguração, os administradores verificaram a necessidade de
controlar o acesso dos alunos às aulas de ginástica, natação e de artes marciais,
verificou-se também a necessidade de ferramentas para demonstração de
indicadores de desempenho das aulas oferecidas. Inicialmente este controle foi
12
realizado manualmente em planilha eletrônica, onde apenas era possível verificar o
número de clientes que frequentavam as aulas, sendo que, a contagem era feita
pelo professor e repassada aos administradores.
Ocorre que, por meio deste mecanismo não era possível ter a exatidão das
informações, tampouco limitação de acesso dos alunos, dificultando o controle tendo
em vista que há aulas em que o número de vagas deve ser limitado.
Observando esta necessidade da empresa, e deparando-se com a disciplina
de Engenharia de Software realizada no Curso de Ciência da Computação, verificou-
se a possibilidade de desenvolvimento de um software que atenda às necessidades
de controle e gerenciamento para a Academia Wave.
Na disciplina são apresentados os fundamentos e conceitos da engenharia de
software, tendo por objeto orientar o acadêmico para que consiga projetar e
organizar o desenvolvimento de um software. Ao longo dos três semestres da
disciplina, os alunos escolhem um tema, onde é realizado o levantamento de
requisitos, projeto, implementação e testes, sendo este, o trabalho principal da
disciplina.
Como objeto principal deste projeto, foi proposto desenvolver um sistema que
registre as presenças nas aulas da Academia Wave, com algumas funcionalidades
como: a utilização de monitores touch screen1, facilitando a utilização do sistema
pelos clientes.
No curso na disciplina de Engenharia de Software, foi iniciado o
desenvolvimento do sistema, sendo que, dividiu-se em duas partes. Como primeira
parte, foi desenvolvido o Módulo dos Totens que exibe a grade de aulas da
Academia Wave para que os clientes e professores registrem suas presenças nas
aulas escolhidas. Posteriormente foi desenvolvido o Módulo Gerenciador de Aulas,
onde os administradores gerenciam o conteúdo que os totens irão exibir aos
clientes.
1 Monitor sensível ao toque.
13
O sistema foi desenvolvido para registro das presenças em aula, utilizando o
cadastro dos alunos do sistema ERP da Academia Wave, que permite, além do
cadastro dos alunos, planos, controle de acesso na academia e treinos de
musculação. O sistema ERP é terceirizado e totalmente web, sendo que, para a
consulta destes dados foi realizada uma negociação com a empresa proprietária do
sistema onde os mesmos disponibilizaram serviços para consumo de dados,
possibilitando assim a consulta através do sistema desenvolvido em sala de aula.
Apesar da visível melhora no processo de registro das presenças nas aulas
oferecidas pela Academia Wave, alguns problemas foram revelados e algumas
ideias foram sugeridas para implementação.
Entre os problemas, pode-se citar as filas que se formam em horários de pico,
pois é necessário digitar a matrícula e data de nascimento para registrar presença,
contudo nem todas as pessoas lembram do número da matrícula. Além disso, a
Academia Wave possui alunos com a faixa etária entre 6 à 94 anos de idade, dessa
forma, o sistema não possui a usabilidade ideal para atender a necessidade de
todos os clientes, principalmente idosos que têm muita dificuldade em digitar vários
números através do teclado físico.
A liberação de presenças em aulas de natação para alunos que não possuem
exame dermatológico ou que possuem o mesmo vencido, também se tornou um
problema.
O objetivo foi desenvolver uma nova versão do Sistema para Registro de
Presenças em Aulas para a Academia Wave utilizando o reconhecimento biométrico
por impressão digital revisando toda a usabilidade da primeira versão e
acrescentando algumas funcionalidades sugeridas pela empresa.
A usabilidade pode ser compreendida como a qualidade de interação entre o
usuário e o sistema, que depende das características tanto do sistema quanto do
usuário.
Buscando mais eficiência no processo de registro de presença e
consequentemente uma maior satisfação dos usuários, este projeto visa
implementar o reconhecimento biométrico por impressões digitais, fazendo com que
o tempo do registro de presença diminua junto com as filas em horários de pico.
14
No universo das redes de computadores, biometria refere-se ao conjunto de
métodos automatizados que permitem autenticar, identificar ou verificar
automaticamente a identidade de um indivíduo baseando-se em suas características
físicas ou comportamentais (PINHEIRO, 2008).
A impressão digital do aluno capturada no momento do registro da presença
em uma aula é comparada com um banco de impressões digitais dos clientes da
Academia Wave. Este banco de dados é hospedado pela empresa terceirizada que
desenvolveu o sistema ERP que a academia utiliza. A equipe de desenvolvedores
deste sistema, disponibilizou um serviço para consumo de dados do tipo WCF
(Windows Communication Foundation) para que seja possível buscar informações
no ERP da Academia Wave.
O Windows Communication Foundation é um SDK (Kit de Desenvolvimento
de Software) para desenvolvimento e distribuição de serviços no Windows (LÖWY,
2007).
O objetivo principal do WCF é permitir que desenvolvedores possam criar
aplicações voltadas para computação distribuída. Assim é possível a integração de
diferentes sistemas utilizando este tipo de serviço.
Este projeto se justifica como um Trabalho de Conclusão de Curso pois busca
o desenvolvimento de software voltado para uma necessidade de controle na área
de negócios de Academias, utilizando conceitos de reconhecimento biométrico
através da impressão digital, sistemas de informação e usabilidade.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Após o desenvolvimento e implantação do Sistema para Registro de
Presenças para a Academia Wave durante a disciplina de Engenharia de Software
da UNIVALI, constatou-se que grande parte dos clientes que utilizam o sistema
possui dificuldade em lembrar o número da matrícula da Academia Wave para
registrar a presença, formando filas em horários de pico. Outro problema verificado
15
foi a liberação de presença para alunos que não possuem exame dermatológico ou
que o mesmo esteja vencido, em aulas de natação. Percebeu-se a necessidade de
uma análise da usabilidade na interface do totem que é utilizado por alunos de
diferentes faixas etárias, pois os mesmos demonstraram algumas dificuldades em
relação à escolha das aulas devido à forma que as interfaces foram projetadas.
1.1.2 Solução Proposta
Diante dos problemas verificados, este trabalho se propõe a adicionar o
reconhecimento biométrico pela impressão digital dos clientes da Academia Wave
para que o processo de registro de presença se torne mais rápido, além de alterar e
adicionar novas funcionalidades e revisar a usabilidade da interface do Módulo dos
Totens para que a mesma se torne apta para larga faixa etária dos clientes da
Academia Wave.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho consiste em implementar a funcionalidade de
identificação biométrica pela impressão digital de alunos no Sistema para Registros
de Presenças em Aulas para a Academia Wave, adequando a usabilidade do
Módulo de Totens do sistema.
1.2.2 Objetivos Específicos
Foram considerados objetivos específicos para este trabalho:
• Estudar e compreender os conceitos relacionados à usabilidade;
• Pesquisar e compreender a utilização do reconhecimento biométrico
através da impressão digital;
• Pesquisar os conceitos e as tecnologias necessárias à implementação
do sistema;
• Analisar as interfaces do Módulo dos Totens de acordo com as normas
de usabilidade, propondo as alterações, caso necessário.
16
• Atualizar a modelagem do projeto com as novas funcionalidades
propostas;
• Implementar as novas funcionalidades de acordo com a modelagem;
• Testar e validar a implementação do sistema;
• Aplicar testes de interface;
• Documentar o sistema, e os seus resultados.
1.3 METODOLOGIA
Para a realização deste trabalho, foram realizados testes com alunos da
Academia Wave utilizando a primeira versão do software, além de análise de novos
recursos junto com os administradores da empresa.
Para a modelagem do projeto proposto, optou-se em utilizar metodologias de
análise e projeto orientado a objetos com notação UML.
As etapas da metodologia utilizada para a realização do projeto foram:
• Fundamentação teórica: constitui em pesquisar e estudar os conceitos
necessários;
o Fornecer uma visão geral sobre a primeira versão do Sistema
para registro de presenças em aulas para a Academia Wave;
o Fornecer uma introdução sobre Usabilidade e como será
abordada no projeto;
o Fornecer uma introdução sobre Reconhecimento Biométrico;
o Fornecer uma introdução sobre WCF (Windows Communication
Foundation).
• Projeto:
o Definição dos requisitos e funcionalidades do sistema proposto
17
� Revisão dos requisitos funcionais, requisitos não
funcionais e regras de negócio que contemplam o
funcionamento do sistema;
� Revisão dos casos de uso; e
� Revisão do diagrama ER (Entidade Relacionamento);
1.4 ESTRUTURA DO TRABALHO
No Capítulo 1 deste trabalho é apresentada a introdução do mesmo,
envolvendo descrição geral, problematização, solução, objetivos geral e específicos,
e a metodologia utilizada na realização do trabalho.
O Capitulo 2 trata da fundamentação teórica. Neste é abordada a primeira
versão do Sistema para Registro de Presenças em Aulas para a Academia Wave,
aspectos de usabilidade a serem utilizados, uma introdução ao WCF (Windows
Communication Foundation) e conceitos de biometria e reconhecimento biométrico
por impressão digital, além de alguns trabalho correlatados.
O Capitulo 3 apresenta o desenvolvimento, onde são apresentadas as
definições do projeto como os requisitos funcionais, requisitos não funcionais, regras
de negócio, casos de uso que foram seguidos no desenvolvimento do projeto, além
da avaliação de usabilidade das telas da primeira versão e da segunda versão.
O Capítulo 4 trata das conclusões sobre este trabalho, descrevendo as
dificuldades e soluções encontradas no desenvolvimento deste trabalho.
18
2 FUNDAMENTAÇÃO TEÓRICA
Este trabalho aborda os seguintes temas na fundamentação teórica: (I)
Apresentação da primeira versão do Sistema para Registro de Presenças nas Aulas
para a Academia Wave, apresentando os objetivos e as técnicas utilizadas; (II)
Descrição sobre os tipos de reconhecimento biométricos utilizados em sistemas; (III)
Conceitos de Usabilidade que serão utilizados; (IV) Conceito sobre WCF (Windows
Communication Foundation); e (V) Trabalhos correlatados.
2.1 SISTEMA PARA REGISTRO DE PRESENÇAS EM AULAS DA ACADEMIA WAVE: PRIMEIRA VERSÃO
O sistema conta com 2 módulos: (i) Módulo Gerenciador de Aulas onde os
administradores cadastram aulas, professores, salas e a grade de aulas, e (ii)
Módulo dos Totens, que fica instalado em totens distribuídos pela Academia. Na
primeira versão do sistema, o módulo dos totens era constituído de um computador
com sistema operacional Windows, um monitor touch screen, um teclado numérico e
uma impressora térmica para emissão de comprovante. Nesta segunda versão do
módulo dos totens foi removido o teclado numérico e inserido um leitor biométrico de
impressões digitais.
Nas próximas seções são descritas as funcionalidades compreendidas pela
primeira versão do sistema.
2.1.1 Módulo Gerenciador de Aulas
O módulo gerenciador de aulas é utilizado pelos administradores da
Academia Wave para gerenciar todo o conteúdo que é visualizado nos totens. Este
módulo possui o cadastro de aulas, cadastro de professores, cadastro de salas,
cadastro de usuários do sistema e o cadastro da grade de aulas.
Cadastro de aulas
O cadastro de aulas dá a opção de inserir uma nova aula, editar uma aula
existente e excluir aulas. Estas aulas serão utilizadas para montar a grade de aulas
19
posteriormente. Os dados necessários para incluir uma aula são: nome da aula,
lotação máxima, tempo para exibição no totem antes do início da aula, tempo para
exibição no totem depois do início da aula.
Cadastro de salas
O cadastro de salas dá a opção de inserir uma nova sala, editar uma sala
existente e excluir salas. Estas salas serão utilizadas para montar a grade de aulas
posteriormente. Para as salas armazena-se apenas seus nomes.
Cadastro de professores
O cadastro de professores dá a opção de inserir um novo professor, editar um
professor existente e excluir professores. Os professores cadastrados recebem um
código identificador único gerado automaticamente pelo banco dados, podendo
assim utilizar este código para registrar uma presença em alguma aula no totem.
Cadastro de usuários
O Módulo Gerenciador de Aulas só pode ser utilizado por usuários
autorizados na Academia Wave, portanto no cadastro de usuários é possível inserir
estes usuários autorizados para que os mesmos possam utilizar o sistema.
Grade de aulas
O cadastro da grade de aulas possibilita gerenciar toda a programação que
será visível nos totens, inserindo uma aula que esteja previamente cadastrada no
sistema, atribuindo um horário de início, duração e uma sala que esteja previamente
cadastrada. Durante a modelagem da primeira versão do sistema optou-se em não
vincular um cadastro de professor à um registro da grade de aulas, pois na
Academia Wave é possível que algum professor deixe de ministrar a aula por
motivos maiores e outro professor seja convocado à substituí-lo, assim esse
professor substituto deve ter o seu cadastro no sistema para que possa registrar a
presença naquela aula.
20
2.1.2 Módulo dos Totens
No Módulo dos Totens o aluno ou professor pode visualizar as aulas que a
Academia Wave oferece de acordo com o horário atual, podendo pressionar com o
dedo a aula escolhida. A Figura 1 apresenta a tela da primeira versão do totem com
a lista de aulas.
Figura 1. Grade de aulas do totem
Em seguida, é apresentada a tela para identificação da pessoa. O usuário
digitava o seu número de matrícula e a data de nascimento, e assim primeiramente o
sistema efetuava uma consulta em seu banco de dados local da empresa e
confirmava se a data de nascimento é a mesma que foi digitada, caso seja, era
apresentada uma tela de confirmação e impresso um recibo que era entregue ao
professor daquela aula.
Todos os dados dos alunos foram cadastrados pelo sistema ERP que a
Academia Wave utiliza em todas as suas filiais e disponibilizados pela empresa
proprietária do sistema através de uma conexão direta ao seu banco de dados.
Cada vez que um aluno registra sua presença em alguma aula, o banco de dados é
21
consultado e os dados do aluno são salvos localmente, assim, em cada novo
registro de presença, primeiramente o sistema efetua a consulta do banco local da
empresa para confirmar a presença e em segundo plano, é feita uma consulta ao
banco de dados do ERP da Academia Wave buscando uma atualização dos dados
do aluno no banco local. Isso torna muito mais rápida a liberação da presença ao
aluno, além de garantir que o sistema do totem funcione localmente em caso de
falha de conexão com a internet.
2.2 BIOMETRIA
Ainda vista como uma tecnologia futurista, na verdade a utilização da
biometria é algo muito antigo, utilizado a cerca de 6.000 anos atrás. Na Ásia, a
impressão digital era utilizada pelos artesãos de cerâmica como marca de sua
autoria. No Egito, os negociantes eram identificados pela sua altura, cor dos olhos e
sua compleição, mas só em 1880 o Dr. Henry Faulds propôs que as impressões
digitais de um indivíduo eram únicas e que poderiam ser utilizados na solução de
crimes. Posteriormente, novas tecnologias começaram a surgir como,
reconhecimento pela Iris, reconhecimento facial e retina, mas foi a partir dos anos 90
que começou a surgir vários fornecedores e aplicações com sistemas automatizados
de reconhecimento biométrico, popularizando dessa forma a tecnologia
possibilitando a utilização em qualquer sistema (SANTOS, 2007; PINHEIRO, 2008).
A palavra Biometria vem do grego Bio Métron, onde bio significa vida e
métron significa medida. Furtado (2002) define biometria como “o processo pelo qual
é possível identificar uma pessoa através de suas características físicas”.
Pinheiro (2008) também relaciona o conceito ao ramo da tecnologia:
No universo de redes de computadores, biometria refere-se ao conjunto de métodos automatizados que permitem autenticar, identificar ou verificar automaticamente a identidade de um indivíduo baseando-se em suas características físicas ou comportamentais.
Atualmente a segurança de informações é objeto de grande importância na
área de computação, e uma das principais medidas de segurança é o tipo de
autenticação de um usuário no sistema. A autenticação biométrica vem auxiliar de
forma eficaz este problema, verificando as características físicas ou
22
comportamentais do usuário capturadas por dispositivos e comparando esses dados
com as informações armazenadas em um banco de dados.
2.2.1 Elementos da biometria
Vários métodos foram desenvolvidos na busca do reconhecimento biométrico,
verificando as características únicas em cada indivíduo. Dentre os tipos de
reconhecimento, existem os sistemas baseados no reconhecimento físico e
reconhecimento comportamental, como pode ser visto na Figura 2.
Figura 2. Tipos de biometria Fonte: PINHEIRO (2008).
Alguns critérios são analisados para a melhor escolha do tipo de
reconhecimento como: conforto de utilização, precisão, custo benefício e nível de
segurança, e dependendo do nível de segurança necessário, é recomendável utilizar
mais de um tipo de reconhecimento intercalado.
Seja qual for o tipo de biometria utilizada, ela deve estar de acordo com o
modelo de um sistema biométrico, ou seja, deve possuir alguns processos padrões
para que um indivíduo seja reconhecido. De acordo com Furtado (2013), um sistema
biométrico pode ser encarado como um sistema de reconhecimento de padrões que
busca extrai-los de uma pessoa, armazená-los em um bando de dados para
posteriormente serem comparados com novas amostras e determinar a identidade
de cada amostra em uma população.
23
De acordo com Teixeira (2011), um algoritmo é uma sequência de instruções
ordenadas de forma lógica para a resolução de uma determinada tarefa ou
problema. Para um sistema biométrico simples, são necessários 3 algoritmos
específicos, para aquisição de um tipo biométrico, processamento e comparação.
Esses algoritmos são constituídos de um subconjunto de rotinas, onde são
combinados para interagir com o sistema operacional e rotinas de baixo nível. Essas
sub-rotinas executam tarefas como: processamento de imagens, classificação,
geração de modelos biométricos, criptografias, etc. Esses métodos são abstraídos
através de uma API (Application Programming Interface), onde disponibilizam
apenas os métodos básicos para atingir o objetivo.
Na primeira utilização de um sistema biométrico é necessário o registro prévio
de suas características biométricas em um banco de dados, e para esse registro é
necessário a aquisição de um exemplar como por exemplo, um leitor de impressões
digitais, sendo que esse dado deve ser armazenado em um banco de dados.
Esse registro é baseado em um modelo digital das características físicas,
chamado de template2. Posteriormente em uma tentativa de identificação do usuário,
é realizada uma nova aquisição das características biometricas, esse exemplar é
analisado e são extraídos os atributos principais que diferenciam sua biometria e
depois comparado com os templates armazenados no banco de dados. O template
extraído da impressão digital do indivíduo, dificilmente será igual ao template
armazenado no banco de dados, essa diferença envolve diversos fatores como
sujeira, pressão do dedo, umidade e posição do dedo no leitor. Dessa forma, um
template não pode possuir um índice no banco dados para uma identificação mais
rápida, já que o algoritmo precisa analisar as características do template para
comparar com outros templates que podem ser totalmente diferente do extraído,
porém o algoritmo de comparação leva em conta todas essas diferenças entre
templates armazenados e extraídos para comparação.
Nem sempre o template será comparado com todos os registros do banco de
dados, caso o template combine com as características de um determinado registro
2 Estrutura de dados que armazena os dados biométricos.
24
do banco de dados e verificado que se trata das mesmas características biométricas,
essa comparação é então finalizada, pois o usuário foi reconhecido. A cada
comparação, o algoritmo verifica se as primeiras características do template extraído
é compatível com as primeiras características do template do banco de dados, caso
não haja uma compatibilidade, esta comparação é finalizada para que o próximo
template do banco de dados seja comparado ao invés de comparar todas as
características de um template incompatível.
Este método de comparação funciona em um tempo rápido para um grande
volume de comparações, além de ser a forma mais barata. Porém em ambientes
onde há milhões de biometrias à serem comparadas como um banco de dados da
polícia, este método pode se tornar lento. Existe a técnica de Cluster que pode ser
utilizada nestes casos, onde diferentes servidores executam o algoritmo de
comparação em determinadas partes do banco de dados, o primeiro servidor que
reconhece o template armazenado no banco de dados, retorna um aviso aos demais
servidores informando o sucesso na busca. Esta técnica permite aumentar a
velocidade de reconhecimento à medida em que mais servidores são inseridos no
esquema.
2.2.2 Identificação pela Impressão Digital
De acordo com Santos (2007), a impressão digital é o método de biometria
mais utilizado no mundo, além de serem mais baratos, sem barreiras culturais, eles
também são seguros. As impressões digitais são únicas para cada indivíduo e
consideradas o tipo biométrico mais seguro para determinar a identidade depois do
teste do DNA.
Por ser bastante estudada, várias empresas criaram API’s para
desenvolvimento, contendo todos os métodos necessários para a utilização de
leitores de impressão digital e a comparação com registros biométricos
armazenados em um banco de dados.
Martins (2013) descreve os processos que a imagem da impressão digital
sofre no momento da leitura. Após colocar o dedo no leitor é extraída uma imagem
das linhas da impressão digital. (Figura 3)
25
Figura 3. Impressão Digital
Fonte: Martins (2013).
Essa imagem sofre um processo chamado Thinning (Figura 4), onde a
imagem é filtrada e as linhas da impressão digital são deixadas apenas com 1 pixel
de largura.
Figura 4. Impressão Digital. Thinning
Fonte: Martins (2013).
Posteriormente, são identificadas as características datiloscópicas3. O Quadro
1 mostra essas características:
Quadro 1. Características biométricas Característica Imagem Ponto
Ilha ou Ilhota
3 Características utilizadas no processo do reconhecimento biométrico por impressão digital.
26
Cortada
Extremidade de linha
Bifurcação
Confluência
Haste ou Arpão
Ponte ou Anastomose
Lago ou Encerro
No entanto, somente 100 pixels a partir do centro da imagem são definidos
como região de interesse (Figura 5).
Figura 5. Impressão digital recortada
Fonte: Martins (2013).
A localização dos pontos reconhecidos é armazenada em uma estrutura de
dados chamada Template e pode ser salvo em um banco de dados em um formato
de um array de bytes para que posteriormente pode ser comparado com outra
amostra.
27
Pinheiro (2008) descreve que existem 3 tipos básicos de erros em um sistema
biométrico. O primeiro erro é a Falsa Rejeição, onde o usuário é legítimo, mas o
sistema o rejeita. O segundo erro é a Falsa Aceitação, onde o sistema aceita o
usuário errado, e o terceiro é um problema de inserção de erros, onde é levada em
conta a variação das características físicas que dificultam o processo de
reconhecimento, como por exemplo, no reconhecimento através da impressão
digital, caso o dedo esteja coberto com poeira, as marcas não ficarão evidenciadas
na captura da mesma, ou até mesmo em um reconhecimento da voz, caso o
indivíduo esteja em um estado emocional diferenciado.
Devido à esses problemas conhecidos pela Academia Wave que já utiliza o
reconhecimento biométrico por impressão digital para controle do acesso na
empresa, onde os alunos idosos e crianças possuem dificuldades em utilizar esse
tipo de reconhecimento devido à má formação ou deformação das linhas da
impressão digital, foi acordado em implementar o reconhecimento biométrico na
nova versão do sistema, deixando como método auxiliar, a opção antiga de
identificação através da inserção da matrícula e data de nascimento, permitindo que
todos os alunos possam identificar-se no sistema.
2.2.3 SDK (Software Development Kit)
Conforme já exposto, hoje existem muitos fornecedores de API’s para serem
utilizadas em softwares. Os produtos que esses fornecedores oferecem são
chamados de SDK (Software Development Kit ou Kit de Desenvolvimento de
Aplicativos). Conforme Chandler(2009) explica, um SDK é um pacote de
programação que pode ser usado no desenvolvimento de software. Geralmente, um
SDK inclui APIs, ferramentas e documentação.
Kirk e Hwu (2010), dizem que uma API é uma camada de software
padronizada, ou seja, uma coleção de funções de biblioteca, que permite que
aplicações (como jogos por exemplo) usem serviços e funcionalidades do software
ou do hardware.
A Academia Wave possui um banco de dados com cerca de 13.000 templates
biométricos de seus clientes, que é utilizado pelo próprio sistema de controle de
acesso que a empresa utiliza. Cada software de controle de acesso instalado nas
28
unidades da Academia Wave, necessita que um SDK esteja instalado para que o
software de controle de acesso possa comunicar-se com o dispositivo leitor de
impressão digital e também para que o sistema possa utilizar os métodos básicos
para manipulação da biometria. O SDK que a Academia Wave utiliza é da empresa
Griaule Biometrics, possuindo várias licenças de utilização para todos os seus
dispositivos.
Como citado anteriormente, o reconhecimento por impressão digital é um dos
métodos mais seguros, e como a Academia Wave já possui várias licenças para a
utilização do SDK da marca Griaule, optou-se em utilizar esse SDK no projeto.
Este SDK da marca Griaule, possui alguns métodos básicos que permitem
apenas a comunicação, extração da biometria com o dispositivo leitor de impressão
digital, verificação da qualidade da impressão digital e a comparação de um template
biométrico com outro template. As demais funções como armazenamento no banco
de dados e consulta dos templates biométricos do banco para comparação, por
exemplo, foram implementados no sistema.
2.3 USABILIDADE
Cada vez mais a usabilidade é alvo de muita preocupação em um projeto de
software. Com o surgimento dos dispositivos móveis como smartphones e tablets, o
uso de aplicativos nesse tipo de aparelho deixou os usuários mais acostumados à
utilização da tecnologia Touch Screen. Com isso, é essencial que se um aplicativo
seja voltado para o cliente, ele deve ter as mesmas características de um software
que este cliente esteja familiarizado.
De acordo com a norma 9241-11 (1998) da ISO (International Organization for
Standardization), a usabilidade é definida como “o alcance para qual um produto
pode ser utilizado por determinados usuários para atingirem metas específicas com
afetividade, eficiência e satisfação dentro de um contexto específico”. Esses
objetivos compreendem a base do que é dominado “User expercience”.
29
User experience é a experiência do usuário quando ele interage com produtos
ou serviços (SILVA FILHO, 2010). Esses produtos podem ser qualquer coisa, como
Smartphones, notebooks, painel de um carro ou um Software.
Nielsen Norman Group (2013a) define user experience como:
User experience compreende todos os aspectos da interação do usuário final com a organização, seus serviços e seus produtos. O primeiro requisito para um experiência de usuário é atender as necessidades exatas do cliente de maneira objetiva. Além disso, há a simplicidade e elegância que geram produtos que são atrativos para o uso. A verdadeira experiência de usuário vai além de dar aos usuários o que eles querem ou oferecer características de uma lista de itens solicitados. Visando obter experiência de usuário com qualidade nos benefícios de uma organização, deve haver uma combinação de serviços de várias disciplinas, incluindo engenharia, marketing, projeto industrial e design gráfico, e projeto de interface.
Em qualquer negócio, o cliente é sempre o mais importante, portanto a
usabilidade deve ser analisada antes, durante e após o desenvolvimento de um
software. Dentro deste contexto, cabe destacar que a interface de usuário é um fator
determinante do sucesso de um produto. O resultado disso é que as interfaces bem
projetadas aumentam a eficiência com que o usuário realiza suas tarefas, além de
uma maior satisfação com o sistema.
No desenvolvimento de um software é importante trabalhar com as premissas
de usabilidade e fazer com que isso um requisito essencial do produto.
Neste projeto, será utilizado o método de abordagem pelas qualidades das
interfaces proposto por Pollier (1992) apud ANDRADE, 2007, p. 56), onde o
avaliador navega pela interface a partir de um conjunto de heurísticas de usabilidade
ou qualidades que ela deveria apresentar. Além deste método, como complemento é
utilizado testes com usuários.
Nielsen Norman Group (2013c) descreve a avaliação heurística como um
método fácil, rápido e barato de avaliar interfaces, onde o objetivo da avaliação
heurística é encontrar os problemas de usabilidade no projeto, para que possam ser
atendidos como parte de um processo de design interativo. Avaliação heurística
envolve um pequeno conjunto de avaliadores que examina a interface e avalia a sua
30
conformidade com os princípios de usabilidade reconhecidos “Heurísticas”. De
acordo com Nielsen Norman Group (2013b) as heurísticas são:
• Exibir o estado do sistema, oferecendo visibilidade do status;
• Fazer o mapeamento natural entre o sistema e o mundo real;
• Prover suporte de controle e liberdade de escolha para os usuários;
• Prover consistência e seguir recomendações de padrões;
• Priorizar a prevenção de erros de usuários;
• Minimizar a necessidade de memorização dos usuários, priorizando o
reconhecimento à recordação;
• Oferecer recursos de uso eficiente e rápido da interface, tornando-a
flexível e customizada às necessidades dos usuários;
• Eliminar informações irrelevantes, visando prover suporte ao projeto
minimalista e à estética;
• Oferecer aos usuários mecanismos de ajuda que lhe permitam
reconhecer, diagnosticar e tratar erros;
• Prover os usuários de documentação e recursos de ajuda baseadas
em tarefas dos usuários.
No contexto deste projeto, faz-se necessária a avaliação de usabilidade de
interfaces touch screen, bem como identificar problemas de usabilidade e propor
soluções, dado os diferentes perfis de usuários que utilizam o sistema.
A avaliação heurística foi escolhida por se tratar do método mais popular de
avaliação, ser de fácil aplicação e barato, como descrito por Nielsen Norman Group
(2013c). Estes itens são avaliados nas próximas seções do projeto.
31
2.3.1 Avaliação de Usabilidade em Interfaces Touch Screen
As interfaces touch screen, permitem que o usuário tenha um contato direto
com as funcionalidades do dispositivo, através do uso do dedo sobre a tela como
mostra a Figura 6.
Figura 6. Dispositivos Touch Screen.
De acordo com Silva Filho (2010), na avaliação de usabilidade de interfaces
touch screen devem ser levados em conta alguns problemas diferenciados dos
outros tipos de interfaces. Para que seja um sistema intuitivo, nenhum destes fatores
deve ser impactante:
• Dimensões pequenas dos elementos de interação: Cada pessoa
possui um tamanho diferente de dedo, e dependendo da função que se
quer exercer em um sistema touch screen é preciso o uso de uma
caneta para realizar o toque, portanto, é ideal que os elementos de
interação tenham no mínimo 5x5 milímetros.
• Toque (com acionamento) acidental de funcionalidades: Pode haver
situações que o usuário toca acidentalmente em elementos que
executam alguma função no sistema, podendo haver até perda de
dados. Neste caso, o sistema deve fornecer métodos para desfazer as
ações.
• Interação com a interface do usuário, puramente, sequencial: Uma das
principais limitações nos monitores touch screen é a utilização
sequencial como um sistema que não é desenvolvido para touch
32
screen, fazendo com que a interação do usuário não seja proveitosa
como seria utilizando as duas mãos ou todos os dedos para realizar as
funções.
• Necessidade de esforço adicional para entrada de muitos dados: Há
situações em que o usuário precisa inserir muitos dados e neste caso,
é necessário dar muitos toques na tela utilizando um teclado virtual que
normalmente possui um tamanho menor do que um teclado real.
2.3.2 Testes de Usabilidade
A avaliação de usabilidade de uma interface pode ser feita através da
avaliação heurística combinada com testes com usuários.
Como método de avaliação heurística do projeto da versão 2 do Sistema para
Registros de Presenças para a Academia Wave, foram utilizadas as Heurísticas de
Nielsen somente sobre o Módulo dos Totens.
O Módulo dos Totens é utilizado pelos clientes e professores da Academia
Wave e em média, são registradas 900 presenças diariamente através dos totens
em todas as unidades da Academia Wave. Este número inclui crianças a partir dos 6
anos até idosos de 92 anos.
Foram realizados testes com os próprios clientes da Academia Wave,
observando-os pessoalmente e através de software de acesso remoto na utilização
do Módulo dos Totens. Estes testes foram realizados para levantamento de dados e
posteriormente serem feitos as análises dos mesmos como proposto por Silva Filho
(2011).
Durante o projeto deste TTC, foi feita uma análise do tempo que se leva para
os usuários registrarem suas presenças no sistema. Será visto qual é o principal
fator que gera o atraso do processo e se existe algum método para otimização.
Testes de usabilidade são utilizados para coletar dados, e para realizar um
teste é necessário possuir uma metodologia, ou seja, um conjunto de passos a
serem seguidos para realizar uma tarefa (SILVA FILHO, 2011). Neste sentido, foram
33
listados todos os passos necessários para a realização das principais tarefas que os
alunos e professores executam no Módulo dos Totens, a fim de descobrir quais
passos estão sendo prejudicados pela falta de uma boa usabilidade.
Através dos dados obtidos é necessário efetuar a análise dos mesmos, para
isso, Silva Filho (2011) propõe algumas questões que podem ser respondidas com
esses dados quantitativos, como pode ser visto na Tabela 1.
Tabela 1. Análise de dados quantitativos Nº Questão 1 Tempo para realizar uma tarefa. 2 Percentual de tarefa concluído. 3 Percentual de tarefa concluído por unidade de tempo. 4 Taxa de sucessos/erros. 5 Tempo consumido com erros. 6 Percentual de erros. 7 Número de comandos utilizados. 8 Número de comandos disponíveis não utilizados. 9 Frequência de uso de ajuda (help) ou documentação. 10 Quantidade de vezes que o usuário lembra comandos (isto é retenção ao
longo do tempo). 11 Número de vezes que o usuário expressa satisfação ou frustração. 12 Avaliação subjetiva do usuário quanto ao uso do produto ou serviço.
Fonte: Silva Filho (2011).
Através da análise dos dados obtidos com a observação dos usuários e com
as questões da Tabela 1 respondidas, é possível realizar as seguintes tarefas,
segundo Silva Filho (2011):
1. Avaliar os dados obtidos segundo critérios de usabi lidade
Avaliar os dados com base em critérios de usabilidade, é necessário ter os
seguintes dados:
o (A velocidade de) desempenho do usuário;
o Tempo de aprendizado (do usuário);
o Avaliação subjetiva (do usuário);
o Retenção ao longo (do usuário);
34
o Taxa de erros (do usuário).
2. Priorizar problemas de usabilidade mais severos
Um conjunto de fatores compreende a taxa de severidade de um problema de
usabilidade, são eles:
o Tempo exigido para completar uma tarefa;
o Número de usuários que tiveram ou encontram um problema;
o Impacto negativo da percepção do usuário do produto ou
serviço;
o Grau de dificuldade para realizar tarefas usando o produto ou
serviço (onde você deve considerar difícil se mais de 70% dos
usuários não conseguem realizar tarefa).
3. Identificar a criticidade dos erros.
Para determinar a criticidade de erros, é feita a combinação da taxa de
severidade com a probabilidade de ocorrência do erro, ou seja:
Criticidade do erro = Taxa de severidade + Probabilidade de ocorrência.
O Módulo Gerenciador de Aulas é utilizado somente pelos administradores da
Academia Wave e os mesmos receberam um treinamento sobre a utilização,
portanto não será feita análise de usabilidade deste módulo.
2.4 WCF
Com o avanço da internet, é cada vez mais comum e necessário que os
sistemas utilizem a internet como meio de integração de dados. Empresas que
possuem mais que uma unidade em locais diferentes, necessitam da internet para
que os dados sejam salvos em um banco de dados principal.
Há pouco tempo, começou a ser difundido na área de computação, o termo
Cloud Computing (Computação em nuvem), onde os serviços e recursos podem ser
utilizados de forma virtual e totalmente transparente ao usuário. O WCF é utilizado
35
com o conceito da computação em nuvem, onde sistemas podem consumir os dados
de um banco em qualquer lugar do mundo. Isto facilita muito a integração de
sistemas diferentes, além de integrar os dados de empresas que possuem filiais em
diferentes locais.
De acordo com Löwy (2007) WCF é:
[...] um SDK para desenvolvimento e distribuição de serviços no Windows. É uma implementação da Microsoft de um conjunto de padrões de mercado que definem interações entre serviços, conversões de tipo, condução e vários protocolos de gerenciamento.
Utilizando o WCF, é possível enviar mensagens assíncronas para um serviço,
hospedado por um servidor ou um simples aplicativo. As mensagens podem ser
simples como uma palavra em XML (Extensible Markup Language) ou como um
complexo fluxo de dados binário (MICROSOFT CORPORATION, 2013a).
Portanto, o WCF pode ser utilizado de forma eficaz em diferentes sistemas e
diferentes linguagens, a fim de integrá-los.
2.4.1 Contratos
O WCF utiliza contratos para expor os seus serviços. Löwy (2007, p. 6) define
o contrato como “[...]uma forma padronizada e independente de plataforma para
descrever o que o serviço faz”.
Conforme (MICROSOFT CORPORATION, 2013b; LÖWY, 2007), existem 4
tipos de contratos:
Contratos de Serviço:
É o contrato que descreve todas as operações que um serviço pode realizar,
normalmente declarada em uma Interface para que a classe do serviço WCF
implemente esta interface junto com os métodos do contrato.
Contrato de Dados:
O contrato de dados define o tipo de dados que o serviço e o cliente trocarão.
Löwy (2007, p. 6) complementa que o WCF já fornece contratos para tipos nativos
36
como String, Int, etc. Mas é possível definir contratos de dados pelo próprio usuário
para passar um objeto qualquer.
Contrato de Falhas:
É o contrato que define os erros cobertos pelo serviço e como será feito o
tratamento dos mesmos para os clientes.
Contratos de Mensagens:
O contrato de mensagens é raramente utilizado, mas são úteis quando há a
necessidade de um formato de mensagem pré-existente que precise ser seguido
entre o cliente e o serviço.
2.4.2 Integração com o ERP da Academia Wave
A empresa proprietária do sistema ERP da Academia Wave forneceu acesso
aos serviços WCF que seu próprio sistema utiliza, assim, será possível a integração
do Sistema para Registro de Presenças para a Academia Wave com os dados
utilizados pelo sistema ERP da Academia Wave.
Os serviços utilizados são para consultas do dados dos clientes e
funcionários. Os dados que são utilizados são: nome completo, data de nascimento,
telefone, celular, e-mail, cidade, estado, Sexo, data de exame médico, data de
exame dermatológico, unidade da Wave em que está matriculado, biometria e foto.
Assim, é possível que seja feita a consulta e armazenamento no banco de
dados local do Sistema para Registro de Presenças para a Academia Wave.
O endereço do serviço WCF disponibilizado para consulta dos dados,
disponibiliza diversos métodos, onde cada método retorna diferentes dados. As
informações repassadas pela equipe desenvolvimento do ERP da Academia Wave,
são:
Endereço para consulta das informações dos alunos
• O endereço disponibilizado para consulta dos dados dos alunos:
o http://xxx.xxx.xxx.xxx:8083/WCF/Clientes/wcfClientes.svc.
37
• Assinatura do método que retorna os dados do aluno:
o VOClientes ListarClienteID(int IdCliente, int IdAluno)
• Detalhe dos argumentos necessários para o método:
o IdCliente: Identificador único da Academia Wave entre os clientes da
empresa proprietária do ERP da Academia Wave.
o IdAluno: Matrícula do aluno no sistema ERP da Academia Wave.
• O Quadro 2 apresenta os atributos da classe de retorno:
Quadro 2. Dados de retorno do aluno Int Id String Nome; String Telefone_Celular; String Telefone_Residencial; Datetime Dt_Nascimento; Datetime Dt_Exame_Medico; Datetime Dt_Exame_Dermatologico; String Endereço; Char Sexo; String Cidade; String Estado; String Cep; String Bairro; String Email; Int Id_Filial;
Outro método utilizado no mesmo endereço WCF, é para o retorno de todas
as biometrias do alunos e funcionários da Academia Wave, onde as mesmas são
atualizadas diariamente com o banco de dados local:
• Assinatura do método que retorna a biometria dos alunos e funcionários:
o VOBiometrias[] RetornarBiometrias(int IdCliente)
• Detalhe dos argumentos necessários para o método:
o IdCliente: Identificador único da Academia Wave entre os clientes da
empresa proprietária do ERP da Academia Wave.
38
• O Quadro 3 apresenta os atributos da classe de retorno:
Quadro 3. Dados de retorno das biometrias Int Id_Biometria Int Id_Cliente; Int Id_Funcionario; byte[] Template;
Endereço para consulta das informações dos funcioná rios
• O endereço disponibilizado para consulta dos dados dos funcionários é:
o http://xxx.xxx.xxx.xxx:8083/WCF/Funcionarios/wcfFuncionarios.svc
• Assinatura do método que retorna os dados do aluno:
o VOFuncionario ListarFuncionarioID(int IdCliente, int IdFuncionario)
• Detalhe dos argumentos necessários para o método:
o IdCliente: Identificador único da Academia Wave entre os clientes da
empresa proprietária do ERP da Academia Wave.
o IdFuncionario: Matrícula do funcionário no sistema ERP da Academia
Wave.
• O Quadro 4 apresenta os atributos da classe de retorno:
Quadro 4. Dados de retorno do funcionário Int Id String Nome; String Telefone_Celular; String Telefone_Residencial; Datetime Dt_Nascimento; String Endereço; Char Sexo; String Cidade; String Estado; String Cep; String Bairro; String Email; Int Id_Filial;
39
Todos os dados citados no Quadro 4 serão atualizados no momento em que o
aluno ou funcionário registra sua presença no totem.
2.5 TRABALHOS CORRELATADOS
Este capítulo apresenta alguns sistemas que são utilizados em academias.
Todos eles oferecem um controle gerencial da empresa como: controle financeiro,
clientes, contratos e até mesmo na área operacional como: controle de acesso aos
clientes na entrada da academia, avaliações físicas e controle de treinos de
musculação.
Na Tabela 2 é possível conferir o título do sistema pesquisado, quais as
funcionalidades, tipo do sistema e as características semelhantes com este projeto.
Tabela 2. Trabalhos Correlatados Título Pacto Gestão Academia
Soluções do software
Este software oferece várias funcionalidades para gestão da academia como, controle financeiro, contratos, controle de acesso na academia de clientes através de catraca, controle técnico como treinos de musculação, avaliação física. A Figura 7 exibe uma das telas do sistema.
Figura 7. Sistema Correlatado - Pacto Gestão de Academias
Fonte: PACTO, 2013.
Tipo do sistema
WEB
Características semelhantes com a
Com base nas informações disponibilizadas pelo desenvolvedor, esta aplicação não fornece nenhuma funcionalidades semelhante à proposta deste projeto, pois o
40
proposta mesmo apenas possui as principais funcionalidades como controle financeiro, controle de clientes, contratos e não possui controle de alunos nas aulas oferecidas pelas academias.
Título Sistemas SCA
Soluções do software O sistema SCA oferece as seguintes funcionalidades: controle
financeiro, controle de acesso de alunos e funcionários na entrada da academia, avaliação física, controle de treinos de musculação, controle de turmas e terminal de visualização dos dados do aluno. A Figura 8 exibe uma das telas do sistema.
Figura 8. Sistema Correlatado - SCA
Fonte: PROSISTEMAS, 2013
Tipo do sistema
Aplicativo Desktop
Características semelhantes com a proposta
Esta aplicação possui o controle de turmas que visa controlar os alunos das aulas oferecidas pela academia, porém a forma de utilização é totalmente diferente da proposta deste projeto. Cada aula é cadastrada no sistema e o funcionário registra os alunos que estão interessados em realizar frequentemente a aula. Esta lista de alunos é repassada ao professor no momento da aula onde o mesmo realiza uma chamada para registrar a presença de cada aluno, desta forma, cada vaga fica reservada para cada aluno interessado e funciona de forma satisfatória em academias que possuem fluxo de alunos baixo ou em aulas infantis, onde os pais deixam reservado a vaga para a criança. Para academias com o fluxo de alunos muito alto, esta funcionalidade não é prática.
Título i-Fitness
41
Soluções do software Este aplicativo fornece o controle financeiro, controle de acesso
aos alunos na entrada da academia, controle de marketing, avaliação física, controle de treinos de musculação e terminal para impressão. A Figura 9 exibe uma das telas do sistema.
Figura 9. Sistema Correlatado - iFitness
Fonte: I-FITNESS, 2013 Tipo do sistema
Aplicativo Desktop
Características semelhantes com a proposta
Com as mesmas funcionalidades que os sistemas anteriores, este aplicativo não fornece nenhuma maneira de registrar os alunos nas aulas oferecidas pela academia.
Título Cad4 – Administração de Academias Soluções do software
Este aplicativo fornece o controle de clientes, venda de produtos e serviços, controle financeiro, controle de estoque, controle de usuários e cadastro das aulas oferecidas pela academia. A Figura 10 exibe uma das telas do sistema.
Figura 10. Sistema Correlatado - Cad4
42
Fonte: TERRAZUL, 2013.
Tipo do sistema
Aplicativo Desktop
Características semelhantes com a proposta
Esta aplicação fornece a opção de cadastras as aulas da academia, permitindo imprimir uma lista para ser entregue ao professor, para que o mesmo possa realizar uma chamada. Como dito anteriormente, este método torna-se funcional apenas para academias que possuem baixo fluxo de alunos nas aulas, principalmente se os mesmos alunos frequentam as mesmas aulas.
Entre os trabalhos apresentados, dois deles utilizam uma solução semelhante
ao projeto proposto. Porém o método que utilizam é baseado em criação de turmas,
onde um funcionário da academia registra os alunos que pretendem participar
frequentemente da aula, então o professor recebe uma lista de alunos para realizar
uma chamada e confirmar as presenças.
A Academia Wave utilizou este método de registro de presença quando
possuía outra versão do ERP que utilizam, porém foi constatado que devido ao
grande número de clientes que frequentam as aulas e também devido à alta faixa de
rotatividade de alunos nas aulas, este tipo de método acaba tornando-se complicado
de se obter um controle das presenças.
43
3 DESENVOLVIMENTO
Neste capítulo é apresentada uma descrição das particularidades técnicas do
sistema, o modelo conceitual e físico, objetivo, seu funcionamento, testes e as
dificuldades encontradas durante a implementação.
3.1 ANÁLISE DE REQUISITOS
A análise de requisitos procurou proporcionar um sistema útil e fácil de usar.
A análise foi realizada estudando-se a primeira versão do software que foi utilizada
na Academia Wave, onde foram verificados os requisitos já implementados e os que
foram identificados, porém não chegaram a ser implementados. No Apêndice “A” é
apresentada a documentação completa do software em sua nova versão, incluindo
todos os requisitos do projeto e o detalhamento dos cenários dos casos de uso.
3.1.1 Informações sobre o sistema
O principal objetivo deste sistema é permitir que os alunos da Academia
Wave possam verificar as aulas em andamento e registrarem suas presenças nas
aulas utilizando sua impressão digital como método de reconhecimento, além de
permitir que o professor registre sua presença na mesma, fazendo com que essas
informações sejam disponibilizadas aos gerentes através de relatórios.
As informações registradas neste sistema, serão salvas em uma base de
dados localizada em um servidor local dentro da empresa. Somente os dados dos
alunos serão consultados em um serviço web que disponibiliza informações do ERP
da Academia Wave, permitindo a integração dos sistemas.
3.1.2 WCF para totens
O módulo dos totens em sua primeira versão realizava todos os
procedimentos de inserção e consulta ao banco de dados do sistema. Além disso,
toda consulta ao WCF do sistema ERP da Academia Wave era feita diretamente
pelo totem, ou seja, na primeira vez do registro de presença de um aluno, o totem
fazia uma consulta no banco de dados local e caso não houvesse registro, o totem
realizava uma consulta no WCF do ERP da Academia Wave na internet. Quando os
44
dados do aluno retornavam, o totem realizava uma inserção destes dados no banco
de dados local, registrando a presença do aluno.
O diagrama de sequência apresentado na Figura 11 demonstra uma visão
geral da troca de mensagens entre os servidores e o totem na primeira versão do
sistema. Apresenta-se o processo de registro de uma presença de um aluno que
nunca registrou presença antes.
Figura 11. Diagrama - totens primeira versão
Verificou-se que a solução adotada centralizava no Totem toda a lógica,
acesso a banco e ao WCF externo, sobrecarregando o recurso. Em função disso, na
segunda versão desenvolvida com este trabalho, foram criados serviços locais em
WCF para que os totens se comuniquem com o servidor local, centralizando neste
os acessos ao banco de dados e ao WCF externo. A Figura 12 apresenta o
diagrama de sequência com a nova arquitetura, para execução do mesmo processo
descrito e apresentado na Figura 11.
45
Figura 12. Diagrama - totens segunda versão
Quando o aluno já registrou a presença pela primeira vez, o comportamento
do sistema difere um pouco. Após o WCF local verificar se o aluno já está
cadastrado, ele registra sua presença retornando a confirmação ao totem. Após isso,
uma nova thread é criada no WCF local fazendo uma consulta ao WCF externo
buscando os dados do aluno e atualizando os dados existentes no servidor. Desta
forma os dados do aluno sempre estarão armazenados localmente e atualizados
com o ERP da Academia Wave.
3.1.3 Requisitos Funcionais
Os requisitos funcionais são funcionalidades do sistema, ou seja, o que o
sistema deve permitir fazer. A seguir, são apresentados os requisitos funcionais da
primeira versão do Sistema para Registro de Presenças em Aulas para a Academia
Wave e que não foram implementados, porém foram implementados na segunda
versão:
46
• RF05. O sistema deverá permitir ao administrador gerar o relatório de
todas as aulas realizadas por professor, sendo agrupadas as
informações pela aula, horário de início e duração, com filtros por sala,
professor, aula e período;
• RF06. O sistema deverá permitir ao administrador emitir relatórios das
presenças de alunos agrupadas por aula, sala ou professor.
Foram identificados novos requisitos nesta nova versão, os quais são
apresentados a seguir:
• RF10. O sistema deverá permitir ao administrador efetuar o cadastro,
alteração e exclusão dos totens;
• RF11. O sistema deve permitir ao administrador a visualização de todo
o histórico de aulas realizadas;
• RF12. O sistema deve permitir ao administrador inserir, editar e excluir
as faixas etárias;
• RF13. O sistema deve permitir ao administrador inserir, editar e excluir
as modalidades;
• RF14. Na grade de aulas do gerenciador de aulas, o sistema deve
permitir que ao administrador possa filtrar as aulas por modalidade e
faixa etária;
• RF15. O Módulo dos Totens deve permitir que o aluno ou funcionário
possa digitar a matricula ou data de nascimento através de um teclado
virtual.
• RF16. O sistema deve permitir ao administrador, definir uma idade
mínima e máxima dos alunos da aula.
3.1.4 Requisitos Não Funcionais
Alguns requisitos não funcionais da primeira versão foram alterados, são eles:
47
O item RNF03 é um requisito não funcional de usabilidade, referindo-se ao
tamanho das áreas onde o usuário toca na tela. Como será visto toda a usabilidade
do Módulo dos Totens, este requisito não funcional foi alterado para:
RNF03. O sistema deve possuir usabilidade, usando a abordagem pelas
qualidades das interfaces.
O item RNF04 refere-se à conexão com o banco de dados que a Academia
Wave utiliza, onde na primeira versão era através de uma conexão direta ao banco
de dados em SQL Server 2008 e na segunda versão deverá ser através de serviços
WCF fornecidos pela empresa proprietária do software.
RNF04. O sistema deve se conectar a base de dados do sistema de
gerenciamento da academia através de serviços WCF fornecidos pela empresa
proprietária do sistema.
O item RNF05 refere-se aos totens que devem possuir um teclado numérico
para o aluno digitar sua matrícula. Na segunda versão este teclado será
implementado no próprio software, tornando o teclado virtual, portanto, este requisito
não funcional não é mais válido. Para o reconhecimento biométrico é necessário um
leitor de impressões digitais, então o requisito não funcional RNF05 foi substituído
pelo seguinte:
• RNF05. Os totens devem estar equipados com um monitor touch
screen com resolução de 1024x768, uma impressora térmica para
recibos e um leitor biométrico do modelo Digital Persona u 4000b.
O item RNF06 refere-se ao banco de dados que foi modificado durante o
desenvolvimento da primeira versão, portanto, o requisito referente à essa
característica do software foi modificado, conforme apresentado a seguir:
• RNF06. O sistema deverá utilizar banco de dados SQL Server 2008
Express para registrar seus dados.
48
3.1.5 Regras de Negócio
As seguintes regras de negócio foram propostas na primeira versão, porém
não foram implementadas:
• RN03. O aluno não poderá efetuar a presença nas aulas de natação se
o vencimento do exame dermatológico tenha passado.
O item RN07 refere-se à identificação dos alunos e professores nos totens
somente pela matrícula e data de nascimento. Essa regra de negócio foi alterada
para contemplar a identificação biométrica por impressão digital.
• RN07. A identificação dos alunos e funcionários nos totens é feita
através de sua matricula e data de nascimento ou pela impressão
digital cadastrada no Sistema da Academia Wave.
Para finalizar foram acrescentadas algumas regras de negócio.
• RN08. O aluno não poderá efetuar presença se seu exame médico
esteja vencido e a aula exija um exame médico;
• RN09. O sistema do totem deverá exibir a foto da aula escolhida e a
foto do aluno reconhecido;
• RN10. O cadastro do professor somente poderá ser feito buscando o
mesmo no cadastro de funcionários da Academia Wave;
• RN11. Somente um professor pode ter a presença registrada por aula;
• RN12. Uma aula só poderá ser excluída do cadastro de aulas se não
existir nenhum registro da mesma na grade de aulas e no histórico de
aulas.
• RN13. Um professor não poderá ser excluído caso exista alguma aula
com sua presença.
• RN14. Uma sala só poderá ser excluída do cadastro de salas se não
existir nenhum registro da mesma na grade de aulas e no histórico de
aulas.
49
• RN15. Um totem não poderá ser excluído caso haja alguma aula
vinculada ao mesmo.
3.1.6 Diagrama de Casos de Uso
Nesta seção são apresentados os casos de uso que definem como o sistema
funciona. O diagrama de caso de uso descreve as funcionalidades do sistema de
acordo com a análise de requisitos. A descrição detalhada dos cenários dos casos
de uso é apresentada no Apêndice “A”.
3.1.7 PCT01 – Cadastro
Este Pacote contém os Casos de Uso que podem ser realizados pelos
usuários administradores do Módulo Gerenciador de Aulas. A Figura 13 apresenta
os Casos de Uso do Pacote PTC01.
Figura 13. Pacote Alterado - PCT01. Cadastro
50
A seguir, são apresentados os Casos de Uso do Pacote PCT01 que foram
alterados no projeto:
UC01.01 – Cadastrar Professores – Permite ao administrador buscar o
cadastro de funcionário do sistema ERP da Academia Wave e importar seus dados
de forma que fiquem registrados no banco local do sistema. Assim, esses dados
serão utilizados pelo Módulo de Totens para quando este funcionário for identificado,
ele poderá ser um professor da aula escolhida.
Requisitos atendidos: RF03, RN10 e RF13.
UC01.03 – Cadastrar Aulas – Permite ao administrador inserir, editar, excluir
e consultar as aulas fornecidas pela Academia Wave. As aulas serão vinculadas
com um item do cadastro da grade de aulas.
Requisitos atendidos: RF01, RF12, RF16 e RN16.
A seguir, serão apresentados os Casos de Uso que foram incluídos no
projeto:
UC01.06 - Permite ao administrador inserir, editar e excluir as modalidades
que serão utilizadas no cadastro das aulas.
Requisitos atendidos: RF13;
UC01.07 - Permite ao administrador inserir, editar e excluir as faixas etárias
que serão utilizadas no cadastro das aulas.
Requisitos atendidos: RF12;
UC01.08 - Permite ao administrador ter acesso ao sistema, através da
autenticação de login e senha.
Requisitos atendidos: RN06;
51
3.1.8 PCT02 – Relatórios
Este Pacote contém os Casos de Uso que podem ser realizados pelos
usuários administradores do Módulo Gerenciador de Aulas. A Figura 14 apresenta
os Casos de Uso do Pacote PTC02.
Figura 14. Pacote Alterado - PTC02. Relatórios
Os Casos de Uso do Pacote PCT02 que foram definidos na primeira versão
mas não foram implementados, serão implantados na nova versão. São eles:
UC02.01 - Permite ao administrador, emitir relatórios do total de presenças de
alunos por aula, permitindo que seja filtrado a sala, professor, aula e/ou período.
Requisitos atendidos: RF05.
UC02.02 - Permite ao administrador emitir relatórios das presenças de alunos
por aula, demonstrando o nome, telefone, matrícula do aluno e hora que foi efetuada
presença, permitindo filtrar por sala, professor, aula e período.
Requisitos atendidos: RF06.
3.1.9 PCT03 – Registrar Presença
Este Pacote contém os Casos de que podem ser realizados pelos alunos e
professores no Módulo dos Totens. A Figura 15 apresenta os Casos de Uso do
pacote PCT03:
52
Figura 15. Pacote Alterado - PCT03. Registrar Presença
A seguir, serão apresentados os Casos de Uso do Pacote PCT03 que foram
alterados neste projeto:
UC03.01 - Permite ao aluno ou funcionário digitar sua matrícula e data de
nascimento ou colocar sua impressão digital no leitor para que seja registrada sua
presença na aula e emitir um comprovante impresso. Para registrar, o Módulo dos
Totens deve verificar se existe a impressão digital ou a matricula e data de
nascimento do Sistema ERP da Academia Wave. Caso o funcionário identificado
como professor esteja bloqueado em seu cadastro no Módulo Gerenciador de Aulas,
o sistema não deverá registrar sua presença.
Requisitos atendidos: RF07, RF15, RN01, RN02, RN03, RN04, RN05, RN08,
RN09, RN11, RNF01, RNF04, RF16 e RN16.
53
3.1.10 PCT04 – Histórico de Aulas
Este Pacote não existia na primeira versão do sistema. Ele contém o Caso de
Uso que podem ser realizados pelo administrador do sistema sobre o histórico de
aulas realizadas. A Figura 16 apresenta o Caso de Uso do pacote PCT04
Figura 16. Pacote Novo - PCT04. Histórico de Presença
UC04.01 – Permite que o administrador possa visualizar o histórico de aulas
realizadas com o professor e os alunos que registraram as presenças.
Requisitos atendidos: RF11, RN01, RN02, RN05, RN06 e RN11.
3.2 MODELO ENTIDADE-RELACIONAMENTO
O diagrama de Entidade Relacionamento (E-R) é um modelo diagramático
que descreve o modelo de dados de um sistema com alto nível de abstração. O diagrama de
E-R foi totalmente revisto com vista às novas funcionalidades do sistema. A Figura 17
apresenta o diagrama de E-R criado para esta versão.
55
3.3 IMPLEMENTAÇÃO
Nesta seção são apresentadas as técnicas, linguagens e ferramentas
utilizadas e a operacionalidade da implementação.
3.3.1 Ferramentas utilizadas
Para o desenvolvimento do sistema foi utilizado o Visual Studio 2012 e o
Expression Blend 4 que permite de maneira mais avançada, criar gráficos mais
elaborados às telas do sistema, muito necessário no módulo dos totens. Ambos os
softwares são Microsoft.
3.3.2 Modificação do módulo dos totens
Para a modificação das telas do módulo dos totens, foi utilizado o software
Expression Blend 4 com linguagem XAML. Esta linguagem se assemelha com o
XML e é destinada a construir o layout, animação e ligação com dados do software
em desenvolvimento.
A Figura 18 ilustra o exemplo de código XAML do botão onde são exibidas as
aulas no módulo dos totens.
Figura 18. Código XAML - Botão de aula
56
Na linha 101 está o início do template que define as bordas arredondadas do
botão que exibe as aulas. Na linha 126, é definido um modificador automático do
estilo do botão quando o limite de alunos da aula for atingido, fazendo com que o
botão receba o recurso chamado “VermelhoBorderStyle”, ficando vermelho. O que
define a cor azul, transparência, etc, está sendo referenciado no Style, um recurso
chamado “AzulBorderStyle”, onde podemos ver na Figura 19.
Figura 19. Código XAML - Style
3.3.3 WCF para os totens
Foi desenvolvido um serviço WCF e hospedado no servidor interno da
Academia Wave para que este responda as solicitações dos totens. O WCF fornece
aos totens quais aulas estão em andamento e quando um aluno ou professor
fornece seus dados de identificação no totem, o mesmo solicita ao WCF que registre
essa presença. O serviço WCF verifica se o aluno já possui os dados cadastrados e
caso este aluno nunca registrou alguma presença anteriormente, o servidor solicita
as informações do usuário ao WCF do sistema ERP da Academia Wave, por fim, a
presença é registrada no banco de dados local e retornada a confirmação ao totem.
A Figura 20 ilustra o método que atualiza as aulas nos totens.
57
Figura 20. Método Buscas Aulas - Totem
Pode-se ver que na linha 234 é instanciado um objeto do tipo
“IServicePresenca”, uma interface que tem definido os contratos do serviço WCF e
pode ser vista na Figura 21. Na linha 235, o método “GetAulas” do WCF é chamado,
passando como parâmetro o horário do totem e seu identificador único entre os
totens, recebendo a lista de aulas em andamento para que a tabela da interface seja
preenchida.
Figura 21. Interface WCF
Quando o método “GetAulas” retorna todas as aulas que estão ativas,
verificando se a sala e o totem estão ativos e qual totem solicitou. Este método faz
uma consulta ao banco de dados local como pode-se ver na Figura 22.
58
Figura 22. SQL de busca das aulas
3.4 INTERFACES, TESTE E RESULTADOS
Nesta seção é apresentada a interface do Módulo Gerenciador das Aulas e o
Módulo dos Totens, bem como a análise de usabilidade das telas do Módulo dos
Totens baseada nas 10 heurísticas de Nielsen e também é apresentada a análise de
desempenho do processo de registro de presença realizado com testes com alunos
da Academia Wave, verificando a diferença entre os testes realizados com a
primeira versão do sistema e a segunda versão.
O processo de avaliação foi através da abordagem pelas qualidades das
interfaces, onde a interface é avaliada a partir de um conjunto de heurísticas de
usabilidade ou qualidade que ela deveria apresentar como proposto por Pollier (1992
apud ANDRADE, 2007, p. 56).
Como complemento desta análise, foi desenvolvida uma lista com todos os
passos necessários para realizar as tarefas no Módulo dos Totem. Dessa forma, foi
feito um teste com os usuários observando-os na realização destas tarefas, e quais
dos passos os usuários apresentavam mais dificuldades como proposto por Silva
Filho (2011).
59
A Tabela 3 demonstra os passos necessários para o registro de presença
como aluno da aula no Módulo dos Totens da primeira versão, realizado por clientes
e funcionários da academia:
Tabela 3. Passos para registro de presença de aluno. Nº Passo 1 Visualizar as aulas em andamento na academia. 2 Escolher uma aula que queira participar. 3 Tocar com o dedo em cima da aula escolhida. 4 Digitar a matrícula através do teclado físico. 5 Digitar a data de nascimento através do teclado físico. 6 Confirmar os dados para registrar a presença.
Com base nos passos da Tabela 3 e nas questões da Tabela 1, foi realizada
a observação de 30 pessoas entre alunos e funcionários que registraram presença
como aluno em três aulas. A primeira aula é chamada de “Natação infantil” e os
alunos possuem idade entre 6 e 12 anos. A segunda aula é chamada de “Zumba” e
os alunos que frequentam esta aula possuem idade entre 15 e 40 anos e a terceira
aula é chamada de “Hidroginástica”, onde a maioria dos alunos possui mais de 40
anos.
A observação da utilização do Módulo dos Totens pelos alunos e funcionários
foi feita pessoalmente, onde foram analisados os passos em que esses usuários
estavam tendo mais dificuldade. Já para os valores quantitativos como tempo para
execução das tarefas, se deu através da gravação das telas realizado por software
de acesso remoto.
A Tabela 4 demonstra a média dos valores analisados com a utilização do
Módulo dos Totens na primeira versão, antes do desenvolvimento deste trabalho. No
Apêndice B, é demonstrada essa análise com os valores separados por cada
usuário.
Tabela 4. Média da avaliação de desempenho Item Questão Média dos usuários 1 Tempo médio para realizar uma tarefa 15,30 segundos
2 Percentual médio de tarefa concluída 100%
3 Percentual médio de passos concluída por
unidade de tempo 6,54%
60
4 Média de quantidade de falhas ocorridas 0,7
5 Tempo médio consumido com erros 2,47 segundos
6 Percentual de erros 13%
7 Número médio de comandos utilizados 17,47
8 Média de vezes que o usuário expressa
frustração.
0,6
Os valores da Tabela 4 são uma média dos valores do teste de desempenho
apresentados no Apêndice B. Abaixo são descritos os itens da tabela:
• 1-Tempo médio para realizar uma tarefa: Tempo médio que os
usuários levaram para realizar o registro da presença;
• 2-Percentual médio de tarefa concluída: O percentual médio do total da
tarefa de registro de presença. Nos testes, todos os usuários
realizaram a tarefa por completo;
• 3-Percentual médio de passos concluídos por unidade de tempo: O
Percentual total concluído da tarefa (Item 2), dividido pelo tempo total
de realização da tarefa (Item 1);
• 4-Média de quantidade de falhas ocorridas: A média da quantidade de
vezes que o usuário erra no processo de registro da presença;
• 5-Tempo médio consumido com erros: Tempo médio que o usuário
leva para corrigir o erro que cometeu. Neste item, os erros ocorrem
quando o usuário seleciona outra aula ou digita a matricula e data de
nascimento errados;
• 6-Percentual de erros: Tempo total de erros que o usuário comete
(Item 5) dividido pelo tempo para realizar a tarefa (item 1);
• 7-Número de comandos utilizados: Quantidade total de comandos que
o usuário realizou;
• 8-Média de vezes que o usuário expressa frustração: Média de vezes
que o usuário expressa alguma frustração sobre o sistema.
61
Normalmente esse número segue a quantidade de vezes em que o
usuário comente algum erro.
Foi verificado que os erros gerados pelos usuários ocorriam em duas partes
do sistema:
• A primeira parte é nos passos 2 e 3 da Tabela 4, onde o aluno deve
buscar qual é a aula que deseja participar e depois tocar com o dedo
em cima da opção. Foi verificado que os alunos, principalmente os
idosos, tiveram dificuldades em visualizar a escrita das aulas e depois
ao selecionar a opção escolhida, acabavam escolhendo por engano
outra aula ao lado da opção desejada. Isso faz com que necessitem
voltar à tela principal;
• A segunda parte é nos passos 4 e 5 da Tabela 4, onde o aluno deve
digitar a matrícula e data de nascimento no teclado físico. Foi verificado
que os alunos possuem dificuldade em lembrar principalmente sua
matrícula no sistema da Academia Wave, constituído por 5 números no
máximo. No total de números digitados com a matrícula e data de
nascimento, são 13 dígitos e a cada vez que o usuário erra algum
digito é necessário refazer estes passos, o que acaba gerando uma
demora significativa na tarefa de registro da presença.
3.4.1 Avaliação Heurística da primeira versão
A seguir, são apresentadas as interfaces da primeira e da segunda versão do
Módulo dos Totens junto com a análise das interfaces seguindo as 10 heurísticas de
(NIELSEN NORMAN GROUP, 2013b). Há casos que heurísticas não são
apresentadas em algumas telas, pois não são aplicadas as mesmas.
3.4.2 Tela das aulas em andamento.
Na tela que exibe as aulas do horário vigente no Módulo dos Totens da
primeira versão (Figura 23), o aluno ou funcionário escolhia a aula que desejava
participar e tocava com o dedo em cima da aula escolhida.
62
Figura 23. Grade de aulas - primeira versão
• Exibir o estado do sistema, oferecendo visibilidade do status.
Problema: Durante todo o dia as aulas são exibidas no totem de acordo com o
seu início. Com os botões é possível ver que há aulas disponíveis, porém quando
não há aulas disponíveis no horário, esta tela não apresenta mensagem ao usuário
informando que não há aulas disponíveis.
Solução: De acordo com a heurística, era necessário informar ao usuário
quando não houvesse aulas em andamento, alguma mensagem informando o
motivo. Foi implementado a mensagem “Nenhuma aula em andamento, por favor,
aguarde” quando não há aulas em andamento na Academia Wave.
• Fazer o mapeamento natural entre o sistema e o mund o real.
Esta interface estava de acordo com a heurística, pois oferece um método
parecido com o utilizado em smart phones e até terminais de autoatendimento
bancário, muito utilizado pela população.
63
• Priorizar a prevenção de erros de usuários.
Problema: Toda aula possui uma lotação máxima, isso evita que aulas como
de bicicleta onde tem disponível apenas 30 aparelhos, possa ser liberado para mais
de 30 alunos. Apesar do campo “Presença/Lotação” da aula, exibir a palavra
“Lotada” quando a mesma atingir a lotação máxima, alguns alunos não identificavam
essa informação antes de clicar na aula, então o aluno tentava selecionar a aula
para depois receber a mensagem que a mesma está lotada.
Solução: De acordo com a heurística, era necessário prever este problema
auxiliando o usuário a não cometer erros. A proposta foi de alterar a cor da aula para
vermelho assim que a mesma atingir a lotação além de modificar o número de
presenças para a palavra “Lotado”, para que o usuário possa identificar antes de
tentar selecioná-la.
Problema: Outra característica que é necessária ser alterada para atender a
heurística são os botões selecionáveis das aulas, pois com os testes de usuários,
constatou-se que alguns selecionam a aula errada porque não compreenderam
corretamente o nome visível da mesma ou selecionam uma aula com a intenção de
selecionar outra.
Solução: Foi aumentado o espaçamento entre os botões, inserido uma cor de
fundo mais clara e transparente, além de aumentar a fonte das letras deixando-as
mais visíveis.
• Minimizar a necessidade de memorização dos usuários , priorizando o
reconhecimento à recordação.
Esta heurística já está sendo atendida nesta interface.
• Eliminar informações irrelevantes, visando prover s uporte ao projeto
minimalista e à estética.
Esta heurística já está sendo atendida nesta interface.
• Oferecer aos usuários mecanismos de ajuda que lhe p ermitam
reconhecer, diagnosticar e tratar erros.
64
Para esta interface, esta heurística não é aplicada, pois se um usuário errar o
comando de selecionar uma aula, a próxima interface deve atender esta heurística,
permitindo que o usuário possa retornar à tela.
• Prover os usuários de documentação e recursos de aj uda baseadas em
tarefas dos usuários.
Por se tratar de uma interface simples e com a tarefa simples de selecionar
uma aula, esta heurística está sendo atendida, pois é exibida a mensagem
“Selecione uma aula”.
A Figura 24 demonstra a nova interface de aulas em andamento da segunda
versão do Módulo dos Totens atendendo as heurísticas analisadas na primeira
versão da interface.
Figura 24. Grade de aulas - Nova versão
65
3.4.3 Tela de identificação.
Após o usuário selecionar a aula na primeira versão do Módulo dos Totens,
era exibida a tela de identificação (Figura 25). O aluno ou funcionário precisava
digitar a sua matrícula do sistema da Academia Wave junto com a sua data de
nascimento e apertar o botão “OK”.
Figura 25. Tela de identificação
• Exibir o estado do sistema, oferecendo visibilidade do status.
Problema: Nesta interface, após o usuário digitar a matrícula e data de
nascimento, o sistema busca no banco de dados local os registros do aluno ou
funcionário. Caso não encontre, o sistema busca as informações mais atualizadas
diretamente no Sistema ERP da Academia Wave. Esse processo de busca demora
alguns segundos.
Solução: O sistema deve mostrar alguma mensagem solicitando que o
usuário aguarde, mostrando que o sistema está trabalhando para obter uma
resposta. Na segunda versão do sistema, foi implementado um bloqueio da tela
informando o usuário que ele deve aguardar.
66
• Fazer o mapeamento natural entre o sistema e o mund o real.
Problema: Nesta primeira versão do Módulo dos Totens, o usuário precisava
digitar a matrícula e a data de nascimento através de um teclado numérico físico e
não no próprio software.
Solução: Visando utilizar a tecnologia touch screen, foi implementado um
teclado virtual somente com as funções necessárias como os dígitos de 0 à 9 e a
opção de apagar dígitos, além de implementar o reconhecimento por impressão
digital.
• Prover suporte de controle e liberdade de escolha p ara os usuários.
Problema: A primeira versão fornecia somente a opção de reconhecimento
através da matrícula e data de nascimento.
Solução: Para atender esta heurística, na segunda versão, foi implementado o
reconhecimento biométrico, dando mais opções de reconhecimento do usuário.
• Oferecer recursos de uso eficiente e rápido da inte rface, tornando-a
flexível e customizada às necessidades dos usuários .
Problema: Com os testes de desempenho, foi verificado que o tempo de
execução da tarefa de registro de presença está alto.
Solução: Como comentado na heurística anterior, a implementação do
reconhecimento biométrico atendeu a mesma.
• Oferecer aos usuários mecanismos de ajuda que lhe p ermitam
reconhecer, diagnosticar e tratar erros.
Esta heurística está sendo atendida, pois o usuário é notificado quando a
matrícula ou data de nascimento está incorreta.
A Figura 26 demonstra a nova interface de reconhecimento de usuário da
segunda versão do Módulo dos Totens atendendo as heurísticas analisadas na
primeira versão da interface. A figura à seguir, demonstra o momento em que o
67
usuário coloca o dedo no leitor e sua impressão digital é comparada com as demais
do banco de dados.
Figura 26. Identificação biométrica
68
A Figura 27 mostra a interface de confirmação de presença após o usuário
ser reconhecido.
Figura 27. Confirmação de presença
A Figura 28 mostra um exemplo do recibo impresso ao aluno após o registro
de presença. O mesmo é entregue para o professor para entrar na aula.
Figura 28. Comprovante de presença
69
3.4.4 Resultado das Alterações.
Após a avaliação heurística realizada com a primeira versão do sistema,
foram incluídas melhorias no sistema no desenvolvimento da segunda versão. Esta
nova versão foi colocada em uso na Academia Wave afim de obter-se um novo
resultado para comparação com os primeiros testes.
Seguindo o mesmo teste cujos resultados obtidos são apresentados na
Tabela 4, foi realizado teste com a segunda versão do sistema. Os resultados deste
teste podem ser vistos na Tabela 5.
Tabela 5. Média da avaliação de desempenho - Segundo teste Item Questão Média dos usuários
2ª Versão Média dos usuários 1ª Versão
1 Tempo médio para realizar uma
tarefa 5,60 segundos 15,30 segundos
2 Percentual médio de tarefa
concluída 100% 100%
3 Percentual médio de passos
concluída por unidade de tempo 17,86% 6,54%
4 Média de quantidade de falhas
ocorridas 0,37 0,7
5 Tempo médio consumido com
erros 1,40 segundos 2,47 segundos
6 Percentual de erros 18% 13%
7 Número médio de comandos
utilizados
3,97 17,47
8 Média de vezes que o usuário
expressa frustração.
0,2 0,6
Em comparação com a Tabela 4, é possível ver uma notável melhora nos
resultados após o desenvolvimento das novas funcionalidades da segunda versão
do sistema. Isso se deve ao fato do reconhecimento biométrico tornar o
reconhecimento do aluno muito mais rápido, com menos comandos e erros. A
primeira questão que fala sobre o tempo para a realização da tarefa, no primeiro
teste, o aluno levava em média 15,30 segundos para finalizar o seu registro de
presença. Agora com o reconhecimento biométrico, este tempo diminuiu para 5,60
segundos.
70
Outro item que obteve uma grande melhora foi a média de quantidades de
falhas ocorridas, diminuindo pela metade. Ocorre que boa parte das falhas deste
segundo teste, são apenas tentativas de reconhecimento da impressão digital que
falharam devido má posição do dedo sobre o leitor.
O número médio de comandos utilizados foi um dos itens mais bem
sucedidos no teste, pois houve uma diminuição significativa da quantidade de
interações do usuário com o sistema. No caso otimista, o usuário irá interagir com o
software apenas duas vezes, a primeira para escolher a aula e a segunda para
colocar a impressão digital sobre o leitor.
O item 6 demonstra o percentual de erros sobre a média total de tempo que
um aluno leva para concluir sua presença na aula. Aparentemente o percentual de
erros teve um aumento, mas não pode ser considerado pois nestas duas situações
são utilizadas médias de tempo totais diferentes, e a proporção é calculada com
base nestas. Somente poderia ser considerado este número caso o tempo total do
registro de presenças permanecesse o mesmo nas duas situações.
3.4.5 Módulo Gerenciador das Aulas
Este módulo foi desenvolvido para que os administradores possam cadastrar
as aulas que serão exibidas nos totens, além de obterem informações através de
relatórios.
A Figura 29 exibe a tela principal com informações básicas sobre as
presenças e os totens.
71
Figura 29. Gerenciador de aulas
O Módulo Gerenciador das Aulas possui algumas telas para cadastro de
Aulas, Totens, Salas e Professores. Todas as telas possuem informações básicas
para que essas informações sejam utilizadas no cadastro da Grade de Aulas,
ilustrado na Figura 30.
Figura 30. Grade de aulas – Cadastro
72
Para registrar um horário na grade que será exibido no totem, é necessário
preencher o formulário clicando na opção “Nova aula” como pode ser visto na Figura
31.
Figura 31. Cadastro de aulas da grade
Para que os administradores possam visualizar as informações das
presenças registradas nos totens, foram desenvolvidos dois relatórios, disponíveis
no menu “Relatórios”.
O primeiro relatório fornece a opção de visualizar quais os alunos registraram
presenças nas aulas e quantas vezes eles registraram presenças, podendo escolher
o período do relatório, uma sala específica, uma aula ou até mesmo os alunos das
aulas de apenas um professor. A Figura 32 ilustra este relatório.
73
Figura 32. Relatório 1 - Presenças.
O segundo relatório, exibe a média de alunos de uma aula. Com essa
informação os gerentes podem definir metas para os professores, podendo bonificar
caso a meta seja atingida. Quanto maior é a média de alunos em uma aula, significa
que esta aula e o professor estão agradando aos alunos. A Figura 33 ilustra este
relatório.
74
Figura 33. Relatório 2 - Meta dos professores.
Para que o administrador possa visualizar todas as aulas que ocorreram e
suas presenças, foi desenvolvida uma tela específica para isso, como pode ser visto
na Figura 34. Selecionando o dia, é possível ver todas as aulas realizadas, qual
professor registrou presença e quais alunos registraram presenças nas aulas.
Figura 34. Histórico de Presenças
75
4 CONCLUSÕES
Os objetivos deste Trabalho Técnico-científico de Conclusão de Curso foram
atingidos e o sistema já se encontra em uso dentro das unidades da Academia
Wave.
Os problemas enfrentados pela Academia Wave sobre o Módulo dos Totens
eram as demoras nos registros de presença dos usuários, que acabavam gerando
filas em horários de picos, também os falsos registros gerados por pessoas que
sabem a matricula e data de nascimento de outras pessoas. O reconhecimento
biométrico resolveu o problema das filas nos totens, mas sobre os falsos registros,
de acordo com pesquisas, foi verificado que crianças e idosos possuem as
características datiloscópicas mal formadas que acaba prejudicando o processo de
identificação. Por este motivo, foi optado em incluir o reconhecimento biométrico
deixando como opção o registro pela matrícula e data de nascimento para as
pessoas que possuem essa dificuldade. Assim, o problema de falsos registros,
infelizmente não terá como ser resolvido, pois se optar somente pelo
reconhecimento biométrico como identificador no totem, acabará criando outro
problema maior que é a dificuldade de reconhecimento de crianças e idosos.
A API da Griaule Biometrics foi escolhida devido a Academia Wave já possuir
licenças para uso e leitores biométricos compatíveis. A API oferece recursos de
extração da imagem biométrica com um leitor e o processo de comparação com
outras biometrias.
Apesar da quantidade de biometrias da Academia Wave não ser grande,
cerca de 13.000 biometrias, o processo de comparação leva cerca de 0,5 segundos
para reconhecer. Através de pesquisas, constatou-se que existe outras formas de
implementar a comparação biométrica, porém o custo se torna muito elevado, o que
impossibilita a implementação em certas empresas. Uma academia por exemplo,
não há a necessidade do mesmo grau de segurança e agilidade que um banco
financeiro.
Nos casos onde há milhões de biometrias no banco de dados, a solução é o
método de comparação com Cluster, onde diversos servidores funcionam como um
76
sistema distribuído e cada um fica responsável em comparar parte dos registros do
banco de dados. Este método se torna muito eficiente e com tempo de
reconhecimento rápido, porém com custo muito elevado, ficando impraticável para a
Academia Wave.
De acordo com os testes com usuários realizados na primeira e segunda
versão do sistema, foi possível verificar uma grande melhoria no processo de
registro de presenças, que era o objetivo principal deste TTC. O tempo médio que
um usuário levava para escolher a aula e se identificar, era de 15,30 segundos.
Após a implementação do reconhecimento biométrico e as melhorias de usabilidade,
este número diminuiu para 5,60 segundos.
Algumas dificuldades foram encontradas no desenvolvimento, principalmente
na utilização da API para o reconhecimento biométrico e na implementação do WCF
para utilização dos totens. Na primeira versão do sistema, os totens realizavam
todos os processos de comunicação com o banco de dados e da consulta ao WCF
do sistema ERP da Academia Wave para sincronização dos dados dos alunos. No
desenvolvimento deste trabalho, foi eliminada esta comunicação dos totens e
desenvolvido apenas um WCF que servem aos totens em todos os processos, assim
um totem apenas solicita que o servidor registre a presença do aluno e o servidor se
encarrega de realizar os processos necessários. Dessa forma, os processos ficam
centralizados no servidor, deixando os totens com menos carga.
Atingidos os objetivos propostos neste trabalho, como projetos futuros pode-
se aplicar novas formas de reconhecimento biométrico como o reconhecimento
facial. Deixando o sistema mais intuitivo e de fácil utilização por todas as pessoas de
diferentes idades. O sistema também poderá ser modificado para a utilização em
diferentes tipos de evento, permitindo que visitantes retirem sua entrada e até
mesmo uma confirmação de presença através da leitura de códigos de barra ao
término do evento.
77
REFERÊNCIAS
ANDRADE, Antonio Luis Lordelo. Usabilidade de interfaces web: Avaliação heurística no jornalismo on-line. Rio de Janeiro: E-Papers Serviços Editoriais, 2007. CANEDO, José Albero. Fórum Biometria. Visão geral de um sistema biométrico. Disponível em: < http://www.forumbiometria.com/fundamentos-de-biometria/129-visao-geral-de-um-sistema-biometrico.html>. Acesso em: 14 Mai. 2013 CHANDLER, Heather M. Ergonomia e Usabilidade . São Paulo: Bookman Editora Ltda, 2009. CYBIS, Walter; BETIOL, Adriana Holtz, FAUST, Richard. Ergonomia e Usabilidade . São Paulo: Novatec Editora Ltda, 2007. FINGERSEC. Cluster de Software. Disponível em: <http://www.fingersec.com.br/upload/downloads/MegaMatcher%20Accelerator_3.0.pdf>. Acesso em: 03 Jul. 2013. FURTADO, Vasco. Tecnologia e gestão da informação na segurança púb lica . Rio de Janeiro: Editora Garamond Ltda, 2002 I-FITNESS, Sistemas. I-Fitness Produtos. Disponível em: <http://www.ifitness.com.br/sistemas-ifitness.asp>. Acesso em: 03 Jul. 2013. ISO 9241-11 Internacional Standart Information Technology – Software Product Quality – Part 11, 1998. KIRK, David B; HWU, Wen-Mei W. Programando para processadores paralelos Uma abordagem Prática à Programação GPU . São Paulo: Elsevier Editora Ltda, 2011. MARTINS, Leonardo Dias. Biometrias de Digitais , Revista Espaço Acadêmico. Disponível em: < http://www.gta.ufrj.br/grad/07_2/leonardo/Autenticaopormincias.html>. Acesso em: 14 Abr. 2013 NIELSEN NORMAN GROUP a, User Experience (UX) — Our Definition. Disponível em: < http://www.nngroup.com/about-user-experience-definition/>. Acesso em: 13 Abr. 2013. NIELSEN NORMAN GROUP b, 10 Usability Heuristics for User Interface Design. Disponível em: < http://www.nngroup.com/articles/ten-usability-heuristics/>. Acesso em: 15 Abr. 2013. NIELSEN NORMAN GROUP c, Heuristic Evaluation. Disponível em: <http://www.nngroup.com/topic/heuristic-evaluation//>. Acesso em: 16 Abr. 2013. PACTO. Gestão de Academia. Disponível em: <http://www.pactosolucoes.com.br/nossas-solucoes/gestao-de-academia/ >. Acesso em: 02 Jul. 2013. PAPILOSCOPIA. Papiloscopia. Pontos Característicos. Disponível em: <http://www.papiloscopia.com.br/pontos.html>. Acesso em: 17 Abr. 2013
78
PINHEIRO, José Maurício. Biometria nos sistemas computacionais: você é a sen ha. Rio de Janeiro, RJ. Editora Ciência Moderna, 2008. PROSISTEMAS. Sistema SCA. Disponível em: <http://www.prosistemas.com.br >. Acesso em: 03 Jul. 2013. SANTOS, Alfredo Luiz dos. Gerenciamento de Identidades . Rio de Janeiro: Brasport Livros e Multimídia Ltda, 2007. SILVA FILHO, Antonio Mendes da. Avaliação de Usabilidade em interfaces Touch Screen . Engenharia de Software Magazine. Rio de Janeiro, n. 27, ano 3, Ago. 2010 Disponível em: <http://www.devmedia.com.br/websys.3/webreader.asp?cat=48&artigo=2819&revista=esmagazine_27#a-2819>. Acesso em: 15 Abr. 2013. SILVA FILHO, Antonio Mendes da. Usabilidade e user experience: essencial para aceitabilidade de produtos e serviços, Revista Espaço Acadêmico , nº 126, Nov. 2011. Disponível em: <http://eduemojs.uem.br/ojs/index.php/EspacoAcademico/article/view/15193/8142>. Acesso em: 12 Mai. 2013 MICROSOFT CORPORATION a. What Is Windows Communication Foundation. Disponível em: <http://msdn.microsoft.com/pt-br/library/ms731082.aspx>. Acesso em: 21 Abr. 2013. MICROSOFT CORPORATION b. WCF Essentials: Contracts. Disponível em: < http://msdn.microsoft.com/en-us/library/ff183866.aspx>. Acesso em: 23 Abr. 2013 b. TEIXEIRA, Cesar. Construção de algoritmos no século XXI . Simplíssimos Livros, 2011. TERRAZUL. I-Fitness Produtos. Disponível em: <http://www.terrazul.com.br/site/produtos/30/Software-de-Administra%C3%A7%C3%A3o-de-Academias/CAD-4>. Acesso em: 03 Jul. 2013.
79
APÊNDICE A. DOCUMENTO DE MODELAGEM DO SISTEMA
Neste apêndice é apresentada a versão completa da documentação de
software, sendo que os itens apresentados incluem também o que foi mantido ou
alterado da primeira versão.
A.1 ANÁLISE DE REQUISITOS
A.1.1 Requisitos Funcionais
RF01. O sistema deverá permitir ao administrador inserir, editar e excluir
aulas;
RF02. O sistema deverá permitir ao administrador inserir e editar a grade de
aulas;
RF03. O sistema deverá permitir ao administrador inserir, editar e excluir
professores;
RF04. O sistema deverá permitir ao administrador inserir, editar e excluir
salas;
RF05. O sistema deverá permitir ao administrador gerar o relatório de todas
as aulas realizadas por professor, sendo agrupadas as informações pela aula,
horário de início e duração, com filtros por sala, professor, aula e período;
RF06. O sistema deverá permitir ao administrador, emitir relatórios das
presenças de alunos agrupadas por aula, sala ou professor;
RF07. O sistema deverá permitir ao aluno e funcionário da Academia Wave
efetuar sua presença e emitir um comprovante impresso;
RF08. O sistema deverá permitir aos professores e alunos, visualizar a grade
de aulas em andamento nos totens da academia;
RF09. O sistema deverá permitir ao administrador efetuar o cadastro,
alteração e exclusão dos usuários;
RF10. O sistema deverá permitir ao administrador efetuar o cadastro,
alteração e exclusão dos totens;
80
RF11. O sistema deve permitir ao administrador a visualização de todo o
histórico de aulas realizadas;
RF12. O sistema deve permitir ao administrador inserir, editar e excluir as
faixas etárias;
RF13. O sistema deve permitir ao administrador inserir, editar e excluir as
modalidades;
RF14. Na grade de aulas do gerenciador de aulas, o sistema deve permitir
que ao administrador possa filtrar as aulas por modalidade e faixa etária;
RF15. O Módulo dos Totens deve permitir que o aluno ou funcionário possa
digitar a matricula ou data de nascimento através de um teclado virtual.
RF16. O sistema deve permitir ao administrador, definir uma idade mínima e
máxima dos alunos da aula.
A.1.2 Requisitos não funcionais
RNF01. A impressão do comprovante de presença deve demorar menos que
5 segundos;
RNF02. A interface do sistema para os totens deve ser implementada para
monitores com telas sensíveis ao toque (touch screen) de tamanho 1024 X 768
pixels;
RNF03. O sistema deve possuir usabilidade, usando a abordagem pelas
qualidades das interfaces;
RNF04. O sistema deve se conectar a base de dados do sistema de
gerenciamento da academia através de serviços WCF fornecidos pela empresa
proprietária do sistema;
RNF05. Os totens devem estar equipados com um monitor touch screen com
resolução de 1024x768, uma impressora térmica para recibos e um leitor biométrico
do modelo Digital Persona u 4000b;
RNF06. O sistema deverá utilizar banco de dados SQL Server 2008 Express
para registrar seus dados;
81
RNF07. O sistema deve ser desenvolvido na linguagem C#;
RNF08. O sistema deve possuir usabilidade, usando a abordagem pelas
qualidades das interfaces.
A.1.3 Regras de negócio
RN01. Um aluno não poderá efetuar duas presenças na mesma aula;
RN02. O Sistema só poderá efetuar a presença caso tenha encontrado a
matrícula no banco de dados do sistema de matrículas da academia;
RN03. O aluno não poderá efetuar a presença nas aulas de natação se o
vencimento do exame dermatológico tenha passado;
RN04. O professor não é vinculado à aula, pois ele é registrado para a
mesma apenas quando confirma a presença no totem;
RN05. O sistema não deverá permitir a efetivação de presenças acima da
lotação definida para a aula;
RN06. O administrador só pode acessar o sistema através de autenticação de
usuário e senha;
RN07. A identificação dos alunos e professores nos totens é feita através de
sua matricula e data de nascimento ou pela impressão digital cadastrada no Sistema
da Academia Wave;
RN08. O aluno não poderá efetuar presença se seu exame médico esteja
vencido e a aula exija um exame médico;
RN09. O sistema do totem deverá exibir a foto da aula escolhida e a foto do
aluno reconhecido;
RN10. O cadastro do professor somente poderá ser feito buscando o mesmo
no cadastro de funcionários da Academia Wave;
RN11. Somente um professor pode ter a presença registrada por aula;
RN12. Uma aula só poderá ser excluída do cadastro de aulas se não existir
nenhum registro da mesma na grade de aulas e no histórico de aulas;
82
RN13. Um professor não poderá ser excluído caso exista alguma aula com
sua presença;
RN14. Uma sala só poderá ser excluída do cadastro de salas se não existir
nenhum registro da mesma na grade de aulas e no histórico de aulas;
RN15. Um totem não poderá ser excluído caso haja alguma aula vinculada ao
mesmo;
RN16. O sistema do totem não deve permitir que um aluno fora da faixa etária
definida no cadastro da aula, registre sua presença na mesma.
A.2 CASOS DE USO
Nesta seção são apresentados os casos de uso que definem como o sistema
funciona. O diagrama de Caso de Uso descreve as funcionalidades do sistema de
acordo com a análise de requisitos.
A.2.1 Diagrama de pacotes
Figura 35. Diagrama de Casos de Uso
83
A.2.2 PCT01 – Cadastros
A Figura 36 exibe os Casos de Uso do PCT01.
Figura 36. PCT01. Cadastros
A.2.2.1 UC01.01 - Cadastrar Professores
Permite ao administrador buscar o cadastro de funcionário do sistema ERP da
Academia Wave e importar seus dados de forma que fiquem registrados no banco
de dados local do sistema. Desta forma esses dados serão utilizados pelo Módulo de
Totens para quando este funcionário for identificado, ele poderá ser um professor da
aula escolhida. A Tabela 6 mostra os cenários do caso de uso UC01.01.
Requisitos atendidos: RF03, RN10 e RF13.
84
Tabela 6. UC01.01 - Cadastrar Professores Cenário Comentário Cadastrar Professores
{Principal}
O administrador deve estar logado no sistema.
1-O administrador solicita a tela para cadastro de professor.
2-O sistema abre uma janela demonstrando a tela de cadastro de professores.
3-O administrador seleciona com um clique o botão "Importar Funcionário" para buscar os funcionários no ERP da Academia Wave.
4-O sistema demonstra uma janela com um campo para digitar a matrícula ou código do funcionário.
5-O administrador digita o nome ou código, aperta a tecla Enter ou seleciona o botão OK.
6-O sistema demonstra os funcionários que contenham os dados informados.
7-O administrador seleciona com um clique duplo na linha do nome do funcionário.
8-O sistema demonstra os dados do professor nos campos apropriados.
9-O administrador clica no botão "Salvar".
10-O sistema valida as informações.
11-O sistema salva as informações.
Excluir cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em excluir o professor.
1-O administrador opta por excluir o registro clicando no botão excluir.
2-O sistema exclui o professor.
Funcionário não localizado
{Exceção}
No passo 5, caso o sistema não encontre as informações.
1-O sistema exibe a mensagem "Funcionário não localizado".
2-Retorna ao passo 2 do cenário principal.
Bloquear registro de presença
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em bloquear o cadastro do professor.
1-O administrador seleciona um professor que deseja bloquear clicando em cima de seu nome.
85
2-O sistema exibe as informações do professor escolhido.
3-O administrador marca a opção “Bloqueado” e clica em “Salvar”.
4-O sistema salva as informações.
Excluir cadastro com vínculo
{Exceção}
No Cenário alternativo Excluir Cadastro, no passo 2 ao validar se o professor possui alguma aula realizada com a sua presença.
2.1-O sistema exibe a mensagem "Professor não pode ser excluído, pois ele possui aulas realizadas".
A.2.2.2 UC01.02 - Cadastrar Salas
Permite ao administrador inserir, editar, excluir e consultar as salas da
academia. As salas serão vinculadas com um item do cadastro da grade de aulas. A
Tabela 7 mostra os cenários do Caso de Uso UC01.02.
Requisitos atendidos: RF04 e RF14.
Tabela 7. UC01.02 - Cadastrar Salas Cenário Comentário Cadastrar Salas
{Principal}
O administrador deve estar logado no sistema.
1-O administrador solicita a tela para cadastro das salas.
2-O sistema abre uma janela demonstrando o cadastro das salas.
3-O administrador seleciona com um clique a opção "Nova sala".
4-O sistema limpa todos os campos para inserção dos dados.
5-O administrador preenche todos os campos necessários e clica em salvar.
6- O sistema valida as informações.
7- O sistema salva as informações.
Editar cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em editar uma sala.
1- O administrador seleciona uma sala do cadastro.
2- O sistema exibe as informações referente à sala
86
cadastrada.
3- O administrador edita as informações e clica em salvar.
4- O sistema valida as informações.
5- O sistema salva as informações.
Excluir cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em excluir uma sala.
1-O administrador seleciona uma sala do cadastro.
2- O sistema exibe as informações referentes à sala selecionada.
3-O administrador clica em "Excluir".
4- O sistema exclui a aula.
Inconsistência na validação de dados.
{Exceção}
No cenário principal, passo 6 e no cenário alternativo "Editar cadastro", passo 4, caso os campos obrigatórios (descrição e exige exame dermatológico) não tenham sido preenchidos.
6.1- O sistema altera a cor dos campos inválidos para vermelho.
Excluir cadastro com vínculo
{Exceção}
No Cenário alternativo Excluir Cadastro, no passo 3 ao validar se a sala possui algum registro no histórico de aulas realizadas.
3.1- O sistema exibe a mensagem "Sala não pode ser excluída, pois possui registro no histórico de aulas".
A.2.2.3 UC01.03 – Cadastrar Aulas
Permite ao administrador inserir, editar, excluir e consultar as aulas fornecidas
pela Academia Wave. As aulas serão vinculadas com um item do cadastro da grade
de aulas. A Tabela 8 mostra os cenários do Caso de Uso UC01.03.
Requisitos atendidos: RF01, RF12, RF16 e RN16.
Tabela 8. UC01.03 - Cadastrar Aulas Cenário Comentário Cadastrar Aulas
{Principal}
O administrador deve estar logado no sistema.
1-O administrador solicita a tela para cadastro das aulas.
2-O sistema abre uma janela demonstrando a tela de
87
cadastro das aulas.
3-O administrador seleciona com um clique a opção "Nova aula".
4-O sistema limpa todos os campos para a inserção dos dados.
5-O administrador preenche todos os campos com os dados necessários e clica em "Salvar".
6- O sistema valida as informações.
7- O sistema salva as informações
Editar cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em editar uma aula.
1-O administrador seleciona uma aula do cadastro.
2-O sistema exibe as informações referentes à aula selecionada.
3-O administrador edita as informações e clica em "Salvar".
4-O sistema valida as informações.
5-O sistema salva as informações.
Excluir cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em excluir uma aula.
1-O administrador seleciona uma aula do cadastro.
2-O sistema exibe as informações referentes à aula selecionada
3-O administrador clica em "Excluir".
4-O sistema exclui a aula.
Inconsistência na validação de dados.
{Exceção}
No cenário principal, passo 6 e no cenário alternativo "Editar cadastro", passo 4, caso os campos obrigatórios (descrição, totens, exibição antes do horário, exibição depois do horário, modalidade, faixa etária, lotação e exige exame médico) não tenham sido preenchidos.
6.1- O sistema altera a cor dos campos inválidos para vermelho.
Excluir cadastro com vínculo
{Exceção}
No Cenário alternativo Excluir Cadastro, no passo 3 ao validar se a aula possui algum registro no histórico de aulas realizadas.
3.1- O sistema exibe a mensagem “Aula não pode ser
88
excluida, pois possui registro no histório de aulas".
A.2.2.4 UC01.04 - Editar grade de aulas
Permite ao administrador consultar os registros da grade de aulas, permitindo
inserir, alterar e excluir os registros da mesma, informando horários, dias da semana
e salas para as aulas que ocorrerão, sendo que esta grade manipula somente as
aulas futuras e não afeta as aulas que já ocorreram, pois estas tem seu histórico
devidamente armazenado no momento de registro de presença.
A grade tem um ciclo semanal, onde as aulas cadastradas serão exibidas no
totem toda a semana. A Tabela 9 mostra os cenários do Caso de Uso UC01.04.
Requisitos atendidos: RF02 e RF14.
Tabela 9. UC01.04 - Editar grade de aulas Cenário Comentário Cadastrar item na grade
{Principal}
O administrador deve estar logado no sistema.
1-O Administrador solicita a tela da grade de aulas.
2-O sistema exibe os registros da grade.
3-O Administrador clica na opção "Nova aula".
4-O sistema abre a tela para preenchimento dos campos necessários.
5-O Administrador preenche os campos necessários e clica em salvar.
6- O sistema valida as informações.
7- O sistema salva as informações.
Alterar item da grade
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em editar um item da grade de aulas.
1-O Administrador opta por alterar um registro da grade, com um clique duplo em cima do registro desejado.
2-O sistema demonstra o registro solicitado em campos passiveis de alteração.
3-O administrador altera os dados desejados, clica em "Salvar".
89
4-O sistema valida as novas alterações.
5-O sistema demonstra uma mensagem: "Alterações efetuadas com sucesso".
Excluir item da grade
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em excluir um item da grade de aulas.
1-O administrador seleciona uma aula do cadastro.
2-O sistema demonstra o registro em campos editáveis.
3-O administrador privilegiado escolhe a opção "Excluir".
4-O sistema exclui o registro da grade.
Filtrar por modalidade
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em filtrar as aulas selecionando uma modalidade.
1-O Administrador escolhe uma modalidade existente para ser filtrada.
2-O sistema exibe somente as aulas que estão vinculadas com a modalidade escolhida.
Filtrar por faixa etária
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em filtrar as aulas selecionando uma faixa etária.
1-O Administrador escolhe uma faixa etária existente para ser filtrada.
2- O sistema exibe somente as aulas que estão vinculadas com a faixa etária escolhida.
Inconsistência na validação de dados.
{Exceção}
No cenário principal, passo 6 e no cenário alternativo "Altera item da grade", passo 4, caso os campos obrigatórios (dias da semana, aula, sala, horário de início e duração) não tenham sido preenchidos.
6.1- O sistema altera a cor dos campos inválidos para vermelho.
A.2.2.5 UC01.05 – Cadastrar Usuários
Permite ao administrador inserir, editar e excluir usuários que virão a utilizar o
sistema. A Tabela 10 mostra os cenários do Caso de Uso UC01.05.
Requisitos atendidos: RF09.
90
Tabela 10. UC01.05 - Cadastrar Usuários Cenário Comentário Cadastrar Aulas
{Principal}
O administrador deve estar logado no sistema.
1-O administrador solicita a tela de cadastro de usuários.
2-O sistema demonstra a tela de cadastro de usuários.
3-O administrador seleciona a opção "Novo usuário".
4-O sistema limpa os campos para preenchimento.
5-O administrador preenche os campos necessários e clica em salvar.
6- O sistema valida as informações.
7- O sistema salva as informações.
Editar cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em editar um usuário.
1-O administrador seleciona um usuário do cadastro.
2-O sistema exibe as informações referentes ao usuário selecionado.
3-O administrador edita as informações e clica em salvar.
4-O sistema valida as informações.
5-O sistema salva as informações.
Excluir cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em excluir um usuário.
1-O administrador seleciona um usuário do cadastro.
2-O sistema exibe as informações relacionadas ao usuário.
3-O administrador clica na opção "Excluir".
4-O sistema exclui o usuário.
Inconsistência na validação de dados.
{Exceção}
No cenário principal, passo 6 e no cenário alternativo "Editar cadastro", passo 4, caso os campos obrigatórios (nome, email, usuário e senha) não tenham sido preenchidos.
6.1- O sistema altera a cor dos campos inválidos para vermelho.
91
A.2.2.6 UC01.06 – Cadastrar Modalidades
Permite ao administrador inserir, editar e excluir as modalidades que serão
utilizadas no cadastro das aulas. A Tabela 11 mostra os cenários do Caso de Uso
UC01.06.
Requisitos atendidos: RF13.
Tabela 11. UC01.06 - Cadastrar Modalidades Cenário Comentário Cadastrar Modalidades
{Principal}
O administrador deve estar logado no sistema.
1- O administrador solicita a tela para cadastro das modalidades.
2- O sistema abre uma janela demonstrando o cadastro das modalidades.
3- O administrador seleciona com um clique a opção "Nova modalidade".
4- O sistema limpa todos os campos para inserção dos dados.
5- O administrador preenche todos os campos necessários e clica em salvar.
6- O sistema valida as informações.
7- O sistema salva as informações.
Editar cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em editar uma modalidade.
1- O administrador seleciona uma modalidade no cadastro.
2- O sistema exibe as informações referentes à modalidade selecionada.
3- O administrador edita as informações e clica em salvar.
4-O sistema valida as informações.
5-O sistema salva as informações.
Excluir cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em excluir uma modalidade.
1- O administrador seleciona uma modalidade do cadastro.
2- O sistema exibe as informações referentes à modalidade selecionada.
92
3- O administrador clica na opção excluir.
4- O sistema exclui a modalidade.
Inconsistência na validação de dados.
{Exceção}
No cenário principal, passo 6 e no cenário alternativo "Editar cadastro", passo 4, caso os campos obrigatórios (descrição) não tenha sido preenchido
6.1- O sistema altera a cor dos campos inválidos para vermelho.
A.2.2.7 UC01.07 – Cadastrar Faixas Etárias
Permite ao administrador inserir, editar e excluir as faixas etárias que serão
utilizadas no cadastro das aulas. A Tabela 12 mostra os cenários do Caso de Uso
UC01.07.
Requisitos atendidos: RF12.
Tabela 12. UC01.07 - Cadastrar Faixas Etárias Cenário Comentário Cadastrar Faixas Etárias
{Principal}
O administrador deve estar logado no sistema.
1- O administrador solicita a tela para cadastro das faixas etárias.
2- O sistema abre uma janela demonstrando o cadastro das faixas etárias.
3- O administrador seleciona com um clique a opção "Nova faixa etária".
4- O sistema limpa todos os campos para inserção dos dados.
5- O administrador preenche todos os campos necessários e clica em salvar.
6- O sistema valida as informações.
7- O sistema salva as informações.
Editar cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em editar uma faixa etária.
1- O administrador seleciona uma faixa etária no cadastro.
2- O sistema exibe as informações referentes à faixa etária selecionada.
93
3- O administrador edita as informações e clica em salvar.
4-O sistema valida as informações.
5-O sistema salva as informações.
Excluir cadastro
{Alternativo}
No passo 2, caso o administrador opte em excluir uma faixa etária.
1- O administrador seleciona uma faixa etária do cadastro.
2- O sistema exibe as informações referentes à faixa etária selecionada.
3- O administrador clica na opção excluir.
4- O sistema exclui a faixa etária.
Inconsistência na validação de dados.
{Exceção}
No cenário principal, passo 6 e no cenário alternativo "Editar cadastro", passo 4, caso os campos obrigatórios (descrição) não tenha sido preenchido
6.1- O sistema altera a cor dos campos inválidos para vermelho.
A.2.2.8 UC01.08 – Efetuar Login
Permite ao administrador ter acesso ao sistema, através da autenticação de
login e senha. A Tabela 13 mostra os cenários do Caso de Uso UC01.08.
Requisitos atendidos: RN06.
Tabela 13. UC01.08 - Efetuar login Cenário Comentário Efetuar login
{Principal}
1- O administrador solicita acesso ao sistema.
2- O sistema demonstra a tela para login e senha.
3- O administrador insere o seu login e sua senha.
4- O sistema valida e dá acesso ao administrador.
Login ou senha incorreta
{Exceção}
No passo 4, caso o administrador opte em editar uma faixa etária.
4.1- O sistema nega o acesso e exibe a mensagem "Login ou senha incorreta”.
94
A.2.2.9 UC01.09 – Cadastrar Totens
Permite ao administrador inserir, editar e excluir os totens que que serão
utilizadas no cadastro das aulas. A Tabela 14 mostra os cenários do Caso de Uso
UC01.07.
Requisitos atendidos: RF10 e RF15.
Tabela 14. UC01.09 - Cadastrar Totens. Cenário Comentário Cadastrar Faixas Etárias
{Principal}
O administrador deve estar logado no sistema.
1- O administrador solicita a tela para cadastro dos totens.
2- O sistema abre uma janela demonstrando o cadastro dos totens.
3- O administrador seleciona com um clique a opção "Novo totem".
4- O sistema limpa todos os campos para inserção dos dados.
5- O administrador preenche todos os campos necessários e clica em salvar.
6- O sistema valida as informações.
7- O sistema salva as informações.
Editar cadastro
{Alternativo}
O administrador deve estar logado no sistema. No passo 2, caso o administrador opte em editar um totem.
1- O administrador seleciona um totem no cadastro.
2- O sistema exibe as informações referentes ao totem selecionado.
3- O administrador edita as informações e clica em salvar.
4-O sistema valida as informações.
5-O sistema salva as informações.
Excluir cadastro
{Alternativo}
No passo 2, caso o administrador opte em excluir um totem.
1- O administrador seleciona um totem do cadastro.
2- O sistema exibe as informações referentes ao totem
95
selecionado.
3- O administrador clica na opção excluir.
4- O sistema exclui o totem.
Inconsistência na validação de dados.
{Exceção}
No cenário principal, passo 6 e no cenário alternativo "Editar cadastro", passo 4, caso os campos obrigatórios (descrição, nome do computador) não tenha sido preenchido
6.1- O sistema altera a cor dos campos inválidos para vermelho.
Exclusão de totem com vínculo.
{Exceção}
No Cenário alternativo Excluir Cadastro, no passo 3 ao validar se o totem possui vínculo com alguma aula no cadastro de aulas.
3.1- O sistema exibe a mensagem “totem não pode ser excluido, pois há aulas vinculadas".
A.2.3 PCT02 – Relatórios
A Figura 37 exibe os casos de uso do PCT02.
Figura 37. PCT02. Relatórios
uc PCT02 - Relatórios
UC02.01 - Emitir relatório de aulas realizadas por
professor.
Administrador
(from Atores)
UC02.02 - Emitir relatório detalhado de presenças das aulas
96
A.2.3.1 UC02.01 - Emitir relatório de aulas realiz adas por professor.
Permite ao administrador logado no sistema, gerar o relatório de todas as
aulas realizadas por professor, sendo agrupadas as informações pela aula, horário
de início e duração, com filtros por sala, professor, aula e período. A Tabela 15
mostra os cenários do Caso de Uso UC02.01.
Requisitos atendidos: RF05.
Tabela 15. UC02.01 - Emitir relatório de aulas realizadas por professor. Cenário Comentário Emitir relatório de aulas realizadas por professor.
{Principal}
O administrador deve estar logado no sistema.
1- O Administrador solicita a impressão do relatório através do menu.
2- O sistema exibe a tela com os campos (sala, aula, professor, período) que possibilitam ao administrador fazer a filtragem do relatório.
3- O Administrador preenche os campos conforme necessário e clica em "Gerar relatório".
4- O sistema exibe o relatório com os dados: (Professor, quantidade de aulas, total de horas/aula, hora de início, quantidade de alunos, média de alunos, horário de início da aula e o nome da aula. Todas as informações agrupadas por (nome da aula, horário de início, duração e professor).
A.2.3.2 UC02.02 - Emitir relatório detalhado de pr esenças das aulas.
Permite ao administrador logado no sistema, emitir relatórios das presenças
de alunos por aula, demonstrando o nome, telefone, e-mail e matrícula do aluno.
Permitindo filtrar por sala, professor, aula ou período e permitindo agrupar por aula,
sala ou professor. A Tabela 16 mostra os cenários do Caso de Uso UC02.02.
Requisitos atendidos: RF06.
Tabela 16. UC02.02 - Emitir relatório detalhado de presenças das aulas. Cenário Comentário Emitir relatório detalhado de presenças das aulas.
{Principal}
O administrador deve estar logado no sistema.
1- O Administrador solicita a impressão do relatório através do menu.
97
2- O sistema exibe as informações, sem restrições, e campos (sala, aula, professor, período) que possibilitam ao administrador fazer a filtragem do relatório.
3- O Administrador preenche os campos conforme necessário e clica em "Gerar relatório".
4- São exibidos os dados: data, hora início, sala, aula, professor, dados do aluno (nome, telefone, matrícula do aluno e hora que foi efetuada presença), demonstrando também a soma total das presenças.
A.2.4 PCT03 – Registrar presença
A Figura 38 exibe os casos de uso do PCT03 que podem ser realizados pelos
clientes e funcionários que possuem sua matrícula e impressão digital devidamente
registrada no sistema ERP da Academia Wave.
Figura 38. PCT03. Registrar presença
98
A.2.4.1 UC03.01 - Registrar presença na aula.
Permite ao aluno e funcionário digitar sua matrícula e data de nascimento ou
colocar sua impressão digital no leitor para que seja registrada sua presença na aula
e emitir um comprovante impresso.
Caso o funcionário/professor esteja bloqueado em seu cadastro no Módulo
Gerenciador de Aulas, o sistema não deverá registrar sua presença. A Tabela 17
mostra os cenários do Caso de Uso UC03.01.
Requisitos atendidos: RF07, RF15, RN01, RN02, RN03, RN04, RN05, RN08,
RN09, RN11, RNF01 e RNF04.
Tabela 17. UC03.01 - Registrar presença na aula. Cenário Comentário Registrar presença de aluno
{Principal}
1- O aluno/funcionário seleciona a aula desejada.
2- O sistema exibe a tela de identificação por impressão digital ou matrícula e data de nascimento.
3- O funcionário/aluno coloca o dedo no leitor de impressão digital ou digita sua matrícula e data de nascimento.
4- O sistema verifica se a impressão digital ou matricula e data de nascimento são válidos e se for funcionário, o sistema verifica se ele é cadastrado como professor.
5- O sistema registra a presença do funcionário/aluno como aluno da aula.
6- O sistema exibe uma tela de confirmação de presença.
7- O sistema imprime um recibo de confirmação de presença.
8- O sistema atualiza os dados do aluno/funcionário no banco de dados local com o banco de dados do ERP da Academia Wave.
Registra presença de professor
{Alternativo}
Caso o usuário seja identificado como funcionário da academia e o mesmo tenha sido cadastrado como professor no módulo gerenciador de aulas.
1- O sistema exibe uma tela solicitando o tipo do registro da presença do professor, se é como professor ou aluno da aula.
2- O sistema registra a presença do funcionário como
99
professor ou aluno, conforme escolhido.
3- Retorna ao passo 6 do cenário principal.
Verifica exame dermatológico
{Exceção}
No passo 4 do cenário principal, o sistema verifica se aula escolhida está vinculada na grade com alguma sala que exija exame dermatológico.
4.1a- Se aula escolhida está vinculada com alguma sala que exija exame dermatológico, o sistema verifica se o cliente possui exame dermatológico ou está vencido.
4.2a- Se uma dessas situações ocorrerem, o sistema demonstra a seguinte mensagem: "Esta aula exige que você tenha o exame dermatológico em dia, procure a recepção".
3- Retorna ao passo 1 do cenário principal.
Verifica exame médico
{Exceção}
No passo 4 do cenário principal, o sistema verifica se aula escolhida exige que o aluno tenha exame médico.
4.1b- Se aula escolhida exige que o aluno tenha exame médico, o sistema verifica se o cliente possui exame médico ou está vencido.
4.2b- Se uma dessas situações ocorrerem, o sistema demonstra a seguinte mensagem: "Esta aula exige que você tenha o exame médico em dia, procure a recepção".
4.3b- Retorna ao passo 1 do cenário principal.
Lotação atingida
{Exceção}
No cenário principal, passo 1, caso o aluno ou funcionário selecione uma aula que já esteja com a lotação máxima atingida.
1.1- O sistema compara o total de alunos presentes com a lotação máxima cadastrada na aula.
1.2-Se a lotação for igual ao número de presenças, o sistema demonstra a mensagem: "Aula lotada".
1.3-Retorna ao Passo 1 do cenário principal.
Aluno já registrado
{Exceção}
No passo 4 do cenário principal, caso o aluno já tenha registrado a presença na aula escolhida.
4.1c-O sistema verifica se o aluno já possui uma presença registrada na aula escolhida.
4.2c-Se existir o sistema demonstra a mensagem: "Sua presença já foi registrada nesta aula".
4.3c-Retorna ao passo 1 do cenário principal.
100
Impressão digital não reconhecida.
{Exceção}
No passo 4 do cenário principal, caso a impressão digital do aluno ou funcionário não tenha sido reconhecida.
4.1d-O sistema não encontra uma impressão digital compatível no banco de dados.
4.2d-O sistema demonstra uma tela com a seguinte mensagem: "Impressão digital não encontrada".
4.3d-Retorna ao passo 3 do cenário principal.
Matrícula não encontrada ou data de nascimento inválida.
{Exceção}
No passo 4 do cenário principal, caso a matrícula ou data de nascimento não tenha sido encontrada.
4.1e-O sistema não encontra a matrícula do aluno/funcionário ou a data de nascimento está errada.
4.2e-O sistema exibe a mensagem "Matrícula ou data de nascimento incorreto".
4.3e-Retorna ao passo 3 do cenário principal.
Professor já registrado
{Exceção}
No cenário alternativo (Registra presença de professor), passo 1, caso haja outro professor com a presença registrada na aula escolhida.
1-O sitema demonstra a mensagem: "Professor já registrado!".
2-Retorna ao passo 1 do cenário principal.
A.2.4.2 UC03.02 - Visualizar a grade de aulas em a ndamento.
O sistema exibe a tela de grade de aulas em andamento que fica em
execução nos totens da academia de forma que os alunos e funcionários possam
visualizar as aulas em andamento, e consequentemente efetuar suas presenças se
desejado.
O sistema constantemente efetua consulta na grade de aulas para poder
mostrar as aulas que já tenham iniciado no horário vigente, ou que o horário vigente
esteja dentro da margem de horários (antes do início e depois do início) cadastrado
na aula. A Tabela 18 mostra os cenários do Caso de Uso UC03.02.
Requisitos atendidos: RF08.
101
Tabela 18. UC03.02 - Visualizar a grade de aulas em andamento. Cenário Comentário Visualizar grade de aulas
{Principal}
1- O sistema demonstra a grade de aulas do horário vigente.
2- O aluno/funcionário visualiza as aulas em andamento na tela do totem, e seleciona a desejada.
A.2.5 PCT04 – Histórico de Aulas
A Figura 39 exibe os casos de uso do PCT04 que pode ser realizado
administrador do sistema.
Figura 39. PCT04. Histórico de Aulas
A.2.5.1 UC04.01 – Visualizar Histórico de Aulas.
Permite ao administrador do sistema as aulas que foram realizadas, bem
como visualizar os alunos e professores que registraram presença nas mesmas. A
Tabela 19 mostra os cenários do Caso de Uso UC04.01.
Requisitos atendidos: RF11, RN01, RN02, RN05, RN06 e RN11.
102
Tabela 19. UC04.01 - Visualizar Histórico de Aulas. Cenário Comentário Inserir aula.
{Principal}
O administrador deve estar logado no sistema.
1- O administrador solicita a tela de histórico de aulas
2- O sistema exibe a tela com as aulas realizadas no dia atual.
3- O administrador escolhe a data.
4- O sistema exibe o histórico de presenças na tela
Visualizar alunos da aula
{Alternativo}
No passo 2 do cenário principal, caso o administrador opte em visualizar os alunos de alguma aula realizada.
1- O administrador clica em cima de alguma aula na lista de aulas realizadas.
2- O sistema exibe os alunos que realizaram a aula escolhida.
Visualizar professor
{Alternativo}
No passo 2, caso o administrador opte em visualizar os alunos de alguma aula realizada.
1- O administrador clica em cima de alguma aula na lista de aulas realizadas.
2- O sistema exibe o professor que realizou a aula.
103
APÊNDICE B. TESTE DE DESEMPENHO COM USUÁRIOS
Informações Tipo de informação
Informação 1 Tempo para realizar uma tarefa (em segundos)Informação 2 Percentual de tarefa concluído.Informação 3 Percentual de tarefa concluído por unidade de tempo.Informação 4 Quantidade de falhas.Informação 5 Tempo consumido com erros. (em segundos)Informação 6 Percentual de erros.Informação 7 Número de comandos utilizados.Informação 8 Número de vezes que o usuário expressa frustração.Informação 9 Avaliação subjetiva do usuário quanto ao uso do produto ou serviço.
10
5 B
.2 TE
ST
E C
OM
A S
EG
UN
DA
VE
RS
ÃO
Tarefa Usuário 1 Usuário 2 Usuário 3 Usuário 4 Usuário 5 Usuário 6 Usuário 7 Usuário 8 Usuário 9 Usuário 10
Informação 1 4 5 13 5 3 6 14 15 5 4
Informação 2 100% 100% 100% 100% 100% 100% 100% 100% 100% 100%
Informação 3 25% 20% 8% 20% 33% 17% 7% 7% 20% 25%
Informação 4 0 1 2 0 0 0 1 2 0 0
Informação 5 0 3 8 0 0 0 3 8 0 0
Informação 6 0% 60% 62% 0% 0% 0% 21% 53% 0% 0%
Informação 7 2 2 17 2 2 2 16 16 2 2
Informação 8 0 0 2 0 0 0 2 1 0 0
Informação 9satisfeito satisfeito pouco frustrado satisfeito satisfeito satisfeito pouco frustrado pouco frustrado satisfeito satisfeito
Hidroginástica
106
APÊNDICE C. TABELA DE NOMES DO BANCO DE DADOS
Aula
Coluna Descrição
id Identificador
nome Nome da aula
lotacao Limite de presenças
exibicao_antes Tempo de exibição no totem antes da aula
exibicao_depois Tempo de exibição no totem depois da aula
faixa_etaria Identificador do registro da tabela faixa_etaria
modalidade Identificador do registro da tabela modalidade
exige_exame_medico Verdadeiro caso a aula exija exame médico
Modalidade
Coluna Descrição
id Identificador
descricao Nome da modalidade
Faixa Etária
Coluna Descrição
id Identificador
descricao Nome da faixa etária
Sala
Coluna Descrição
id Identificador
nome Nome da sala
exige_exame_dermatologico Verdadeiro caso aulas nesta sala exijam exame dermatológico
Aluno
Coluna Descrição
id Identificador
tipo_cadastro_erp Identificador de cliente ou funcionario
nome Verdadeiro caso aulas nesta sala exijam exame dermatológico
nascimento Data de nascimento
celular Celular
telefone Telefone
cidade Cidade
uf Sigla do estado
sexo Gênero
exame_dermatologico Data de vencimento do exame dermatológico
exame_medico Data de vencimento do exame médico
id_unidade Id da unidade em que o aluno está cadastrado no ERP
Professor
107
Coluna Descrição
id Identificador
nome Verdadeiro caso aulas nesta sala exijam exame dermatológico
nascimento Data de nascimento
email e-mail
id_unidade Id da unidade em que o funcionário está cadastrado no ERP
Aula_totem
Coluna Descrição
id_aula Identificador da aula
id_totem Identificador do totem
Totem
Coluna Descrição
id Identificador
descricao Verdadeiro caso aulas nesta sala exijam exame dermatológico
nome_computador Data de nascimento
Biometria
Coluna Descrição
id_biometria Identificador
id_cliente Id do cliente
id_funcionario Id do funcionário
template Array de bytes da biometria
Usuário
Coluna Descrição
nome Nome do usuário
senha Senha
usuario Login
Grade
Coluna Descrição
id Identificador
id_aula Id da aula
id_sala Id da sala
id_professor Id do professor
dia_semana Dia da semana
horario_inicio Horário de inicio
duracao Duração em minutos
Historico_aulas
Coluna Descrição
id Identificador
data Data da aula
inicio Horário de início da aula
fim Horário de fim da aula
108
id_sala Id da sala
id_professor Id do professor
isSubstituto Substituição ou não
id_aula Id da aula
qtd_alunos Quantidade de alunos que deram presenças
lotacao Lotação da aula
horario_presenca_professor Horário de presença do professor
Historico_presencas
Coluna Descrição
id_aluno Identificador do aluno
id_historico_aulas Identificador da tabela Historico_aulas
tipo_cadastro_erp Identificador de funcionário ou cliente
horario Horário da presença