UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Rafael Macario da...

108
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

Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Rafael Macario da...

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.

54

Figura 17. Modelo Entidade-Relacional

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.

104

B.1 TESTE COM A PRIMEIRA VERSÃ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