FACULDADE PAN AMAZÔNICA ALISON FELIPE AVELINO...

FACULDADE PAN AMAZÔNICA

ALISON FELIPE AVELINO MENDES

ISAQUE DIAS BRITO

ISRAEL EMANUEL QUEIROZ VALENTE

HORAVIP: UMA PLATAFORMA PARA GESTÃO DE ESTABELECIMENTOS DE BELEZA

Belém

2018

1


ISAQUE DIAS BRITO



Trabalho de Conclusão de Curso apresentado à Faculdade Pan Amazônica de ensino como requisito parcial para obtenção do grau de Bacharel em Ciências da Computação. Orientador:

Prof. Me. Diemisom Carlos Romano de Melo.

Belém

2018

2


ISAQUE DIAS BRITO



Trabalho de Conclusão de Curso apresentado à Faculdade Pan Amazônica como requisito parcial para obtenção do grau de Bacharel em Ciências da Computação. Orientador:

Prof. Me. Diemisom Carlos Romano de Melo.

Aprovado em:

Banca Examinadora:

___________________________ - Orientador

Prof. Me. Diemisom Carlos Romano de Melo

___________________________

Prof. Esp. Demys Alves Brito

___________________________

Prof. Esp. Bruno Ormanes Tamer

3

AGRADECIMENTOS

Agradecemos aos nossos professores pelos incentivos, visando o

desenvolvimento profissional dos discentes no decorrer do curso, ao direcionamento

e acompanhamento de nosso orientador Diemisom Melo, por permanecer firme em

suas orientações, como também aos nossos familiares por nos conceder o suporte

necessário para alcançar nossos objetivos e acima de tudo, ao nosso grandioso Deus,

por nos ter dado paciência e ânimo quando mais precisamos.

4

RESUMO

O uso de novas tecnologias centradas no cliente permite que gerentes de

estabelecimentos comerciais acompanhem diretamente as variações na qualidade do

serviço prestado, contando com a opinião do cliente como principal validador do

desempenho do serviço. Com a expansão do mercado da beleza e a necessidade

organizacional ocasionada pela alta competitividade, os estabelecimentos se tornam

ávidos por diferenciais que os destaquem da concorrência, ao mesmo tempo em que

buscam por alternativas que auxiliem em suas atividades rotineiras. Este trabalho

consiste em desenvolver uma plataforma de Gestão para Estabelecimentos de

Beleza, denominada HoraVIP, composta por dois aplicativos para dispositivos móveis,

denominados HoraVIP Estabelecimentos, que permite o gerenciamento das

operações do estabelecimento, como serviços, funcionários e agenda. O segundo

aplicativo é chamado HoraVIP Clientes, permite que os usuários dos serviços realizem

busca de estabelecimentos por região, agendamento de atendimentos, assim como

avaliá-los.

Palavras chave: Framework IONIC, Google Firebase, Aplicativos de Gestão.

5

ABSTRACT

The use of new customer-centric technologies allows managers of commercial

establishments to directly monitor the variations in the quality of the service provided,

relying on the customer's opinion as the main validator of the service performance.

With the expansion of the beauty market and the organizational necessity caused by

high competitiveness, the establishments become eager for differentials that highlight

them from the competition, while seeking alternatives that help in their routine

activities. This work consists of developing a management platform for beauty

establishments, called HORAVIP, consisting of two applications for mobile devices,

called HORAVIP - Estabelecimentos, which allows the management of the operations

of Establishment, such as services, staff and schedule. The second application is

called HORAVIP- Clientes, allows users of the services to search for establishments

by region, schedules, as well as evaluating them

Keywords: IONIC Framework, Google firebase, management applications.

6

LISTA DE ILUSTRAÇÕES

Figura 1 - Camadas da Engenharia de Software ...................................................... 18

Figura 2: Casos de uso (HoraVIP - Estabelecimentos) ............................................. 39

Figura 3 - Casos de uso (HoraVIP - Clientes) ........................................................... 40

Figura 4 - Representação relacional da base de dados das aplicações HoraVIP ..... 44

Figura 5 - Apresentação, login e cadastro. ................................................................ 47

Figura 6 - Autenticação Biométrica ........................................................................... 48

Figura 7 - Tela inicial ................................................................................................. 48

Figura 8 - Tela Agenda .............................................................................................. 49

Figura 9 - Avaliações ................................................................................................. 50

Figura 10 - Configuração do Estabelecimento. ......................................................... 50

Figura 11 - Gerenciamento de Funcionários e Horário ............................................. 51

Figura 12 - Ativação do Estabelecimento .................................................................. 52

Figura 13 - Tela inic¬ial HoraVIP - Clientes .............................................................. 53

Figura 14 - Categorias de serviços ............................................................................ 54

Figura 15 - Solicitação de Agendamento .................................................................. 54

Figura 16 - Login e redefinição de senha .................................................................. 55

Figura 17 - Imagem Carreira Beauty ......................................................................... 60

Figura 18 - Imagem Salão99 ..................................................................................... 61

Figura 19 - Imagem Salão99 ..................................................................................... 62

Figura 20 - Imagem BeautyDate ............................................................................... 63

Figura 21 - Imagem Beauty Date .............................................................................. 64



7

LISTA DE TABELAS

Tabela 1: Tabela Cliente ........................................................................................... 16

Tabela 2: Tabela estabelecimento ............................................................................ 16

Tabela 3: Requisitos Funcionais HoraVIP - Estabelecimentos ................................. 33

Tabela 4: Requisitos não funcionais - HoraVIP - Estabelecimentos .......................... 34

Tabela 5: Requisitos Funcionais - HoraVIP - Clientes ............................................... 35

Tabela 6: Requisitos não funcionais Hora Vip - Clientes ........................................... 37

LISTA DE QUADROS

Quadro 1: Requisitos não funcionais Hora Vip - Clientes .......................................... 42

8

LISTA DE SIGLAS

W3C World Wide WEB Consortium;

HTML Hypertext Markup Language;

CSS Cascading Style Sheets;

JS JavaScript

Sass Syntactically Awesome Style Sheets;

ER Entidade Relacionamento;

IDC Instituto de Defesa dos Direitos do Cidadão;

TI Tecnologia da Informação;

API Application Programming Interface;

SDK Software Development Kit;

PHP Personal Home Page;

BD Banco de dados;

JSON Javascript Object Notation;

noSQL No Structured Query Language;

SCSS Sass Cascading style sheets;

MVP Minimum Viable Product;

TS Type Script;

RF Requisito Funcional;

RNF Requisito não funcional;

SSD Solid state drive;

IDE Integrated Development Environment;

RAM Random access memory;

https://sass-lang.com/

https://sass-lang.com/

9

LISTA DE PALAVRAS

Android Studio: Ambiente de desenvolvimento integrado (IDE) oficial para o

desenvolvimento de aplicativos para a plataforma Android.

Back-end: Termo utilizado para se referir a parte da aplicação responsável por

estruturar as comunicações da camada interação do usuário com a estrutura de

processamento da aplicação (servidor).

Beta: Terminologia originada da letra do alfabeto grego, utilizada na tecnologia

para determinar um estágio não finalizado de um objeto em fase de testes.

Cross-Platform: Característica do software que o define apto para ser

executado em várias plataformas, como PCs, Macs e dispositivos móveis;

Front-end: Termo utilizado para se referir a parte da aplicação que compõe

a interface do usuário;

Tags: Rotulações utilizadas para demarcar a codificação do HTML para que o

navegador as renderize como devido

WEB: Palavra da língua inglesa que significa teia, aplicada na tecnologia com

associação a rede.

WEB Apps: São aplicações multiplataforma que utilizam a estrutura do

navegador para renderizar a interface e acessar recursos do dispositivo.

WEB View: Aplicativo nativo de sistemas operacionais móveis, como Android

e iOS, que permite que a camada de visualização desenvolvida utilizando tecnologias

WEB (HTML, CSS, JS) que pode ser aplicada sobre a estrutura nativa de uma

aplicação, usadas majoritariamente no desenvolvimento de aplicações híbridas.

WHATWG: Grupo de trabalho de pessoas interessadas na evolução do

HTML e as tecnologias ligadas a tal.

Wrappers: Termo utilizado pelo apache cordova para exemplificar o

“empacotamento” do código a ser promovido nas lojas de aplicativos das plataformas.

Xcode: Ambiente de desenvolvimento integrado oficial para desenvolvimento

de aplicações para a plataforma IOS.

https://pt.wikipedia.org/wiki/Ambiente_de_desenvolvimento_integrado

https://pt.wikipedia.org/wiki/Apple_Inc.

10

SUMÁRIO

1 INTRODUÇÃO ....................................................................................................... 12

1.1 JUSTIFICATIVA ............................................................................................................. 12

1.2 OBJETIVO .................................................................................................................... 13

1.2.1 OBJETIVOS ESPECÍFICOS .......................................................................................... 13

1.3 ESTRUTURA DO TRABALHO ........................................................................................... 14

2 TRABALHOS RELACIONADOS ........................................................................... 15

2.1 APLICAÇÕES DE MERCADO ........................................................................................... 15

3 REFERENCIAL TEÓRICO ..................................................................................... 18

3.1 ENGENHARIA DE SOFTWARE ......................................................................................... 18

3.2 PROCESSO DE SOFTWARE ............................................................................................ 18

3.3 ENGENHARIA DE REQUISITOS ....................................................................................... 21

3.3.1 Requisitos ........................................................................................................... 21

3.4 ESPECIFICAÇÃO DO SOFTWARE ..................................................................................... 23

3.4.1 Viabilidade .......................................................................................................... 23

3.4.2 Elicitação ............................................................................................................. 23

3.4.3 Especificação ...................................................................................................... 23

3.4.4 Validação ............................................................................................................ 24

3.5 CASOS DE USO ............................................................................................................ 24

3.6 GESTÃO DE PROJETO DE SOFTWARE ............................................................................. 25

3.7 DESENVOLVIMENTO DE APLICATIVOS MÓVEIS ................................................................. 25

3.7.1 Aplicativos Nativos .............................................................................................. 26

3.7.2 Aplicativos multi plataforma (Híbridos) ................................................................ 26

3.7.3 Frameworks ........................................................................................................ 27

3.8 BANCO DE DADOS NOSQL ............................................................................................ 27

4 TECNOLOGIAS UTILIZADAS ............................................................................... 29

4.1 HTML ......................................................................................................................... 29

4.2 SASS ........................................................................................................................... 29

4.3 FIREBASE .................................................................................................................... 30

4.4 IONIC ......................................................................................................................... 31

4.4.1 Angular ................................................................................................................ 31

4.5 ADOBE EXPERIENCE .................................................................................................... 31

5 SOLUÇÃO IMPLEMENTADA ................................................................................ 32

11

5.1 MODELO DE PROCESSOS ESPIRAL ................................................................................. 32

5.2 REQUISITOS ................................................................................................................ 32

5.2.1 Requisitos funcionais HoraVIP – Estabelecimentos ............................................ 33

5.2.2 Requisitos não funcionais HoraVIP – Estabelecimentos ..................................... 34

5.2.3 Requisitos funcionais HoraVIP - Clientes ............................................................ 35

5.3 DIAGRAMA DE CASOS DE USO ...................................................................................... 39

5.4 FRAMEWORK ............................................................................................................... 40

5.5 FIREBASE .................................................................................................................... 41

5.6 ESTRUTURA DO BANCO DE DADOS ................................................................................. 41

5.7 SELEÇÃO DE PLATAFORMA ........................................................................................... 44

5.8 PLANEJAMENTO DO DESENVOLVIMENTO ........................................................................ 45

5.9 AMBIENTE DE DESENVOLVIMENTO ................................................................................. 45

5.10 TELAS DAS APLICAÇÕES ............................................................................................. 46

5.10.1 Telas HoraVIP - Estabelecimentos .................................................................... 46

5.10.2 Telas HoraVIP - Clientes ................................................................................... 53

6 CONCLUSÃO ........................................................................................................ 56

6.1 DIFICULDADES ENCONTRADAS ...................................................................................... 56

6.2 TRABALHOS FUTUROS .................................................................................................. 57

REFERÊNCIAS ......................................................................................................... 58

APÊNDICE ................................................................................................................ 60

12

1 INTRODUÇÃO

O setor de beleza está sempre em busca de práticas que auxiliem na

produtividade e aumentem a vantagem competitiva, visto que é estabelecido que a

consolidação do estabelecimento e seu crescimento estão diretamente relacionados

aos padrões organizacionais por ele seguido (Oliveira, Carvalho & Rosa, 2012).

Em vista disso, diversas práticas são desenvolvidas para que as auxiliem na

automatização dos processos internos e organizacionais destas empresas. Desde a

tomada de decisão, mediante a avaliação das necessidades do estabelecimento por

meio de estimativas, coordenação administrativa, até a busca pela redução de custos

de operação, a fim de alcançar fluidez das operações realizadas pelo próprio.

Este trabalho tem como objetivo desenvolver uma plataforma para dispositivos

móveis com características que auxiliem na gestão das operações de um

estabelecimento de pequeno ou médio porte, utilizando tecnologias de

desenvolvimento de aplicações híbridas, como alternativa a sistemas existentes no

mercado, devido a seus custos de implantação e de operação que serão destacados

no capítulo 2 (dois) deste trabalho.

1.1 Justificativa

Aliando constatações oferecidas pelo Instituto de Defesa dos Direitos do

Cidadão (IDC) em pesquisa entre 2015 e 2016 sobre o aumento da utilização de

smartphones Bruzz (2013, Apud Araújo & Alves, 2016), da ampla aceitação destes

dispositivos no ambiente de trabalho, juntamente com os resultados obtidos da

pesquisa de (Lunardi, Dolci & Maçada 2016), apontando as oportunidades na

implantação da tecnologia da informação (TI) em estruturas empresariais de pequeno

e médio porte, determinou-se que existe uma necessidade pelo desenvolvimento de

ferramentas de gestão para estabelecimentos de beleza de pequeno e médio porte.

O mercado já dispõe de ferramentas que são capazes de oferecer meios para

que os estabelecimentos possam gerir suas operações, entretanto, grande parte

destas ferramentas é especializada em operações internas (controle de estoque,

caixa, Recursos Humanos) de forma unitária e contida em si própria, e no que diz

respeito a integração de serviços, a interação com outras aplicações é praticamente

inviável.

13

Com base nisso, busca-se o desenvolvimento de uma plataforma baseada em

aplicativos para smartphones, focada em atender majoritariamente os

estabelecimentos de pequeno e médio porte, nos seguintes quesitos: gerenciamento

de funcionários; gerenciamento de atendimentos e serviços e gerenciamento de

qualidade do atendimento, sendo devidamente expostos no capítulo 5.

1.2 Objetivo

Desenvolver uma plataforma de gerenciamento voltada para o mercado da

beleza, composta de duas aplicações. A primeira, voltada aos estabelecimentos,

disponibiliza ao estabelecimento ferramentas de gerenciamento de funcionários,

atendimentos, serviços assim como a visualização da qualidade de seu atendimento

por meio das opiniões recolhidas por seus próprios clientes disponibilizadas na

segunda aplicação, esta por sua vez voltada aos clientes, atuando como um

centralizador dos cadastros dos estabelecimentos, permitindo a busca e o

agendamento de serviços na agenda cadastrada pelos estabelecimentos.

A plataforma é denominada HoraVIP, e o aplicativo voltado para

estabelecimentos é denominado HoraVIP Estabelecimentos e o voltado para os

clientes finais é denominado HoraVip Clientes.

1.2.1 Objetivos Específicos

Apresentar aplicação para estabelecimentos capaz de gerir:

● A agenda do estabelecimento;

● Os serviços oferecidos e seus valores;

● Os funcionários e parceiros associados ao estabelecimento;

● Monitorar a qualidade dos serviços por meio de avaliações dos clientes;

Apresentar uma aplicação para os clientes capaz de:

● Buscar estabelecimentos próximos à localização do usuário;

● Visualizar, e contratar os serviços disponíveis e seus horários;

● Avaliar o atendimento oferecido pelo estabelecimento.

14

1.3 Estrutura do trabalho

No segundo capítulo deste trabalho são apresentados alguns trabalhos com

temáticas relacionadas ao objetivo, assim como descreve as características de

algumas aplicações disponíveis com propostas semelhantes, salientando suas

funcionalidades e delimitações do seu escopo com base nas constatações coletadas

no trabalho presente em anexo deste projeto.

O terceiro capítulo apresenta a conceituação e metodologias empregadas na

engenharia de software e em seus processos estabelecidos, servindo como

referencial teórico para o desenvolvimento deste projeto.

No quarto capítulo são apresentadas as ferramentas e tecnologias que

auxiliaram direta e indiretamente o desenvolvimento das aplicações propostas.

No quinto capítulo são abordados os artefatos produzidos durante o processo

de engenharia (requisitos, diagramas de casos de uso), apresentação da estrutura do

banco de dados, e justificativas a respeito das tecnologias utilizadas no processo de

desenvolvimento, juntamente como as telas das aplicações desenvolvidas.

No sexto capítulo são expostas as conclusões a respeito das possibilidades da

utilização de frameworks híbridos aplicados ao desenvolvimento de soluções para

estabelecimentos de pequeno e médio porte, explanações sobre as dificuldades

encontradas, lições aprendidas e propostas futuras.

15

2 TRABALHOS RELACIONADOS

Santos (2016) apresenta em sua proposta um enfoque semelhante ao

abordado neste projeto. Seu objetivo é desenvolver plataforma que possibilite o

cliente, por meio da aplicação móvel encontrar os estabelecimentos preferidos por ele,

realizar o agendamento nos mesmos, evitando a necessidade de contatá-los ou dirigir

se a eles. Permitindo também que o estabelecimento, por meio de uma aplicação

WEB, consiga controlar os horários disponíveis e organizar seus agendamentos

utilizando. framework IONIC no desenvolvimento da aplicação e AngularJS para

compor a aplicação WEB.

Assim como Santos (2016), citado anteriormente, Loss e Ponte (2015), também

apresentam um enfoque semelhante ao abordado neste projeto, aplicando sua

proposta a necessidade de se utilizar ferramentas baseadas em tecnologias WEB

para que seja possível manter uma relação mais imediata com o cliente, utilizando o

framework Ruby on Rails, apresentando suas características do processo de

desenvolvimento de uma aplicação WEB com este framework.

2.1 Aplicações de Mercado

Tendo em vista a necessidade de se estabelecer a atual situação do mercado

a respeito do desenvolvimento de ferramentas automatizadas que tenham como

objetivo, realizar o gerenciamento de estabelecimentos na área da beleza, foram

analisadas algumas aplicações disponíveis no mercado dentro de um período médio

de 5 anos, que possuem recursos semelhantes as funcionalidades propostos neste

projeto.

Abaixo são dispostas duas tabelas, onde são mensuradas funcionalidades das

aplicações, definindo seus principais objetivos e dimensionamentos. Servindo como

amostragem do mercado, permitindo uma visão analítica de como os softwares nesta

especificidade estão se comportando. Assim como auxiliando na realização do

refinamento das propostas que são abordadas no decorrer deste documento ou que

serão projetadas posteriormente.

Os detalhes das tabelas, serão dispostos na legenda abaixo, para que

proporcione o melhor entendimento do conteúdo das tabelas.

16

Legenda

Carreira Beauty = “A”;

Salão99 = “B”;

Beauty Date = “C”

Hora Vip funcionalidade atual = “D”;

Hora Vip funcionalidade futuras = “E”;

Célula sem conteúdo = “-”;

Possuir a funcionalidade = “x”; Não possua a funcionalidade = “O”

Tabela 1: Tabela Cliente

Funcionalidade A B C D E

Registro via formulário X O X X -

Vincular perfil social X O X O X

Aplicação cliente mobile X O X X -

Aplicação cliente web X O O O -

Gerenciamento de serviços solicitados X O X X -

Utilização de geolocalização O O X X -

Agendamento de horário O O X X -

Favoritos X O X O X

Notificações X O X X -

Pagamentos pela aplicação O O X O X

Avaliação de atendimento O O X X -

Avaliação aplicativo X O X O X

Fonte: Autores

Tabela 2: Tabela estabelecimento

Funcionalidade A B C D E

Registro via formulário X X X X -

Aplicação estabelecimento mobile O X O X -

Aplicação estabelecimento web X O X O -

Gestão de serviços O X X X -

Gestão de produtos O O X O X

17

Utilização de geolocalização para estabelecimento O O O X -

Agendamento de horário manual do cliente O X X X -

Relatórios O X X O X

Notificações X X X X -

Informações transacionais O X X O -

Agenda cliente O X X X -

Fonte: Autores

As aplicações do mercado que foram analisadas, podem ser encontradas no

anexo deste documento, podendo ser visualizadas de forma detalhada. Já a

aplicação Hora Vip proposta por neste trabalho, podem ser visualizada no capítulo 5

do mesmo, de forma fragmentada, onde todas as funcionalidades presentes, são

descritas e definidas de forma legível.

18

3 REFERENCIAL TEÓRICO

Neste capítulo são apresentados os fundamentos utilizados para a construção

da Plataforma HoraVIP. Foi realizada pesquisa bibliográfica com o objetivo de

determinar a melhor estratégia para execução do projeto de construção de software.

3.1 Engenharia de software

Segundo Sommervile (2011, p.3), a engenharia de software consiste em uma

disciplina que se ocupa em estudar, delimitar e conduzir todos os aspectos da

produção de um objeto de software, sendo assim, utilizada desde os estágios iniciais

de produção até após a entrega do mesmo.

Para Pressman (2011, p.39), a engenharia de software atua sobre um grupo

de camadas apoiadas no compromisso da qualidade, instituindo a base da engenharia

de software, podendo ser mescladas com sistemas de melhoria de processos, como

o 6 sigma, por promover o aperfeiçoamento contínuo de processos.

Listadas de baixo para cima, a primeira camada acima da base é a de processos, logo

acima a camada de métodos, e no topo a camada de ferramentas (Figura 1).

Fonte: PRESSMAN (2011), pág. 39

Para Pressman (2011, p.39), a camada de processos é declarada como a de

mais importância entre as demais, visto que esta mantém a camada de tecnologias

coesa e rege o desenvolvimento do software de forma ordenada e dentro do prazo.

3.2 Processo de software

Processos de software são amplamente utilizados na engenharia de software

para se determinar os passos e controlar o desenvolvimento de um objeto. Podem ser

definidos antes e durante o desenvolvimento à medida que eventuais mudanças forem

necessárias, visto que, segundo Pressman (2011, p.19), o processo de software não

Figura 1 - Camadas da Engenharia de Software

19

se traduz em uma prescrição rígida de como se deve desenvolver um software, mas

sim, em uma abordagem adaptável, mantendo como objetivo produzir e entregar o

produto de software dentro do prazo estimado.

Segundo Sommervile( 2011, p. 19), a Engenharia de existe uma grande

variedade de modelos de processo de software, criados de forma a permitir melhor

adaptação a escala do projeto e das necessidades operacionais exigidas pelo

software e ou pela organização. Dentre os modelos mais conhecidos estão:

● Modelo em cascata

Consiste em um conjunto de atividades encadeado idealizado na década

de 70, onde todos os passos de produção são delimitados antes ou no início

do projeto, obtendo avanços em cada fase após a finalização da fase anterior.

Em geral, o modelo é considerado como um processo linear, criticado quanto

a capacidade de ser implementado no mundo real, visto que a verificação de

todas as implicações do projeto se torna impraticável devido a complicações

comuns durante o processo de desenvolvimento de software, além de não levar

em consideração as questões modernas importantes do desenvolvimento,

como: Prototipação, Alterações constantes nos requisitos, entre outros

Pressman (2011, p.59) e Sommervile (2011, p.19).

● Modelo Incremental

Segundo Sommervile( 2011, p.20), o modelo incremental permite que

processos lineares sejam empregados, de modo que cada incremento do

projeto é resultante da finalização de um processo linear aprovado pela equipe

de desenvolvimento. Desta forma, para Sommervile( 2011, p.20), tornar o

projeto executável por uma equipe reduzida necessitando que as exigência do

cliente sejam atendidas na entrega de um produto essencial, que se bem

acolhido, poderá implementar os incrementos seguintes. Tornando o modelo

mais consistente com o necessário do mundo real, permitir melhor feedback

sobre os resultados com o cliente, oferecer meios de avançar e retroceder o

processo de desenvolvimento à medida que problemas forem encontrados,

além permitir mudanças mas fáceis e baratas durante o desenvolvimento do

projeto Pressman ( 2011, p.61) e Sommervile ( 2011, p.20).

20

● Modelo Concorrente

Diferentemente dos modelos de processo anteriormente citados, as

fases do processo deste modelo não ocorrem sequencialmente, ou seja, os

processos são baseados em eventos que demarcam as alterações de estado

em cada fase. Neste caso, o desenvolvimento do projeto, assim como os

processos são orientados pelas necessidades do usuário, decisões gerenciais,

e resultados de revisões técnicas. Possui interatividade entre as fases

aplicadas sobre os processos, estabelecendo comunicação direta entre as

partes necessárias em prol da agilidade no desenvolvimento e compatibilidade

na integração dos processos Pressman (2011, p.67).

● Modelo Espiral

O modelo espiral, introduzido em maio de 1988, é sugerido como um

modelo evolucionário, elaborado sobre o modelo em cascata, acoplando

interatividade da prototipação, definido sobre quatro atividades importantes:

Determinação dos objetivos; Análise de riscos; Desenvolvimento;

Planejamento e Interação. Obtendo reavaliação dos riscos a cada nova

revolução da espiral, com a possibilidade de ser adaptado de modo a estender

a atuação do modelo ao longo do tempo de vida do software Pressman (2011,

p.65) e Sommervile (2011, p.33).

Listadas abaixo estão quatro importantes atividades definidas pelo

modelo:

● Determinação de objetivos: Definição do escopo do projeto,

definição de implicações do projeto como funcionalidades,

desempenho e meios de implementação (plataforma e

tecnologia);

● Análise de riscos: Análise de alternativas existentes, identificação

de riscos operacionais, construção de protótipos;

● Desenvolvimento: codificação integração dos possíveis

componentes, testes funcionais;

● Planejamento e interação seguinte: avaliação dos resultados,

entrega ao cliente;

21

Levando em conta a interatividade disponível do modelo, este

demonstra mais aptidão ao ser aplicado em projetos reais do que o modelo em

cascata, assumindo um processo contínuo de desenvolvimento entre as fases

da espiral. (Pressman(2011, p.66) e Sommervile ( 2011, p.34)

3.3 Engenharia de Requisitos

A Engenharia de Requisitos (ER), é um dos processos fundamentais na criação

de um software, nesta etapa realizam-se todos os levantamentos em relação a

necessidade do cliente para a construção da aplicação, buscando extrair detalhes

relevantes para que seja possível determinar as funcionalidades do sistema com base

nas reais carências do usuário, por meio de reuniões e entrevistas com o os

idealizadores do sistema.

Entretanto, nas reuniões nem sempre se define com clareza todas as

necessidades dos idealizadores do projeto, desta forma, as documentações

requeridas se tornam de suma importância para geração ou ajustes das

funcionalidades. Este tópico abordará conceitos e padrões que ajudam no

desenvolvimento de requisitos.

Segundo Pressman (2011, p.126), a engenharia de requisitos inicia-se com a

concepção na qual uma tarefa ou funcionalidade definem o escopo e a natureza do

problema a ser mensurado, que agregam as necessidades para construção do

projeto, onde os requisitos são devidamente tratados e ajustados.

3.3.1 Requisitos

Segundo Sommervile (2011, p.57), Os requisitos de um sistema são definidos

como detalhamento sobre o que deve ser realizado pelo sistema, nos serviços

oferecidos por ele, as suas restrições e suas funcionalidades. Os requisitos sempre

transcrevem a real necessidade dos clientes a uma finalidade previamente

identificada.

Contudo, a terminologia de requisitos não possui uma definição precisa, visto

que grande parte dos membros desta área, como desenvolvedores e analistas,

realizam o procedimento de levantamento de requisitos utilizando abstrações rasas,

com pouco teor técnico relacionados as descrições das funcionalidades de um projeto

22

ou produto, ocasionando em falhas desde as primeiras fases do levantamento de

requisitos, assim refletindo em problemas no processo de desenvolvimento de

funcionalidades, caso o projeto venha a ser implementado sem outra análise das

informações coletadas Sommervile (2011, p.57).

Em relação ao processo de levantamento não possuir uma metodologia

definida, as fases iniciais de coleta de requisitos resultam em requisitos de alto nível,

Sommervile (2011, p.58) fragmenta o termo “alto nível” relacionado aos requisitos, da

seguinte maneira:

● Requisitos de usuários: “Declarações, em uma linguagem natural com

diagramas, de quais serviços o sistema deverá fornecer a seus usuários e as

restrições com as quais este deve operar.”.

● Requisitos de sistemas: “Descrições mais detalhadas das funções, serviços e

restrições operacionais do sistema de software.”.

De acordo com esta constatação, observa-se que a coleta inicial em alto nível,

se bem realizada, permite a definição de descrições mais detalhadas sobre as

funcionalidades desejadas do sistema a ser desenvolvido, gerando informações que

definem a aplicação e suas visões aos desenvolvedores.

Os tipos de requisitos existentes na literatura são variados, no entanto, em

linhas gerais, segundo Sommervile (2011, p.59), podem ser classificados entre dois

nichos, requisitos funcionais e não funcionais.

● Requisitos Funcionais: Especificações detalhadas do que o sistema

deve oferecer, de como deve se comportar com determinados tipos de

entradas e saídas, como deve reagir diante a peculiaridades que podem

ocorrer quando estiver em uso.

● Requisitos Não-Funcionais: Delimitações aos serviços ou

funcionalidades disponíveis pelo sistema, como tecnologias,

desempenho, usabilidade, ramificado em Setenta Requisitos não

funcionais que se aplicam a quase a todos os aspectos que o sistema

pode definir.

23

3.4 Especificação do software

É de substancial importância se entender que desenvolver um software com

qualidade, munido de velocidade significativa relacionadas a sua criação, podem

acarretar em uma construção não eficiente do projeto quando não se tem uma visão

eficaz dos requisitos. A Engenharia de Requisitos entra neste cenário para ajudar na

construção do Software com excelência, segundo Sommervile (2011, p. 65), existem

quatro atividades principais quanto ao processo de engenharia de requisitos

relacionadas a especificações de requisitos, são elas: Viabilidade, Elicitação,

Especificação e Validação.

3.4.1 Viabilidade

Viabilidade é a possibilidade de satisfazer as necessidades identificadas para

o usuário, usando tecnologias físicas e lógicas para abordar as diversas situações que

podem ocorrer Sommervile (2011, p.24). Além de estudar se o sistemas apresentado

possui perspectiva rentável se analisado como negócio, levando em consideração

também se o projeto pode ser construído com base nas restrições financeiras

agravadas ao usuário (cliente).

3.4.2 Elicitação

Elicitação consiste no processo de derivação dos requisitos do sistema por

meio da observação dos sistemas já existentes, além de discussões com os potenciais

usuários e compradores, análise de tarefas, entre outras etapas. Essa parte do

processo pode envolver o desenvolvimento de um ou mais modelos de sistemas e

protótipos, os quais nos auxiliam a entender o sistema a ser especificado Sommervile

(2011, p.79-80).

3.4.3 Especificação

Segundo Sommervile 2011, p.67-68), Especificação tratada da forma de

transformar informações que foram requeridas no período de análise documental que

especificam os requisitos. Duas abordagem agregam como valor a este documento.

Requisitos de Usuário (3.3.1), são declarações abstratas dos requisitos do sistema

24

para o cliente e usuário final do sistema; Requisitos de Sistema (3.3.1), são uma

descrição mais detalhada da funcionalidade a ser provida.

3.4.4 Validação

A Validação consiste em uma fase no processo que verifica os requisitos

quanto ao quão concreto e verdadeiro são as informações (realismo), o quão

homogênea ela é (consistência) e a particularidade ou características que a definem

(completude). Durante esse processo, os erros no documento de requisitos são

inevitavelmente descobertos. Em seguida, é feito uma análise e os deficiências

encontradas no documento deve ser revistas para correção desses problemas

Sommervile (2011, p.76).

3.5 Casos de uso

Os casos de uso constituem uma parte da engenharia de software, com a

função de delimitar as interações dos usuários com o sistema ou com outros

indivíduos para explicitar de forma concisa as operações a serem realizadas pelos

atores ou personagens, estes, compõem o ponto inicial do desenvolvimento do

diagrama, ramificando em cada caso de uso uma interação por esses realizada

Sommervile (2011, p.75).

“Atores, que podem ser pessoas ou outros sistemas, são

representados como figuras ‘palito’. Cada classe de interação é

representada por uma elipse. Linhas fazem a ligação entre os

atores e a interação. Opcionalmente, pontas de flechas podem

ser adicionadas às linhas para mostrar como a interação se

inicia.” (SOMMERVILE, 2011, p.75).

Para que os conceitos mencionados anteriormente fossem aplicados na

década de 90, foi desenvolvido o modelo linguagem de modelagem unificada (do

inglês UML) segundo Sommervile (2011, p.75), os diagramas se tornaram uma

característica fundamental para linguagem de modelagem, pois a visão orientada a

objeto “abstrata” que ele proporciona do negócio é facilmente compreendida e

consequentemente implantada.

25

3.6 Gestão de projeto de software

Na engenharia de software, o processo, se traduz na ação e no efeito de

administrar ou dirigir um determinado negócio, este conceito pode ser facilmente

atribuído em áreas pertinentes do desenvolvimento de software. Segundo Sommervile

(2011, p.77), a estipulação dos aspectos em relação ao produto de software se inicia

imediatamente nos estágios de especificação do sistema, se estendendo após a sua

entrega por meio da manutenção nos ditos sistemas de longa vida.

Segundo Pressman (2011, p.579), O gerenciamento efetivo do

desenvolvimento de software é instruído com foco nos 4ps, são eles: Pessoas,

Produto, Processo e Projeto. Considerando que todos processos realizados devem

ser tratados com alta prioridade para a gestão saudável do desenvolvimento, do

contrário, a aplicação incorreta de uma dessas etapas pode prejudicar a estrutura

geral do projeto.

3.7 Desenvolvimento de aplicativos móveis

Inicialmente, o desenvolvimento das aplicações eram focados em um único

sistema operacional. Este tipo de método de desenvolvimento, Segundo Prezotto e

Boniatti ( 2014), É Descrito como desenvolvimento nativo. Este método garante

melhor adaptabilidade da aplicação a plataforma, permitindo uma performance mais

ajustada com o hardware que a executa.

Em contrapartida aos ganhos de desempenho alcançados por este método de

desenvolvimento, também são atribuídas dificuldades em casos onde a aplicação

necessite se fazer presente em mais de uma plataforma. Para esses casos, entra em

pauta o desenvolvimento multiplataforma que obteve grandes evoluções desde seus

primeiros estágios.

Neste capítulo, serão apresentadas as definições entre os tipos de

desenvolvimento mais comuns para aplicações móveis, o nativo e o multiplataforma,

assim como uma breve introdução sobre o conceito de WEBApps.

26

3.7.1 Aplicativos Nativos

Aplicativos nativos segundo Prezotto e Boniatti (2014), são aplicações

desenvolvidas especialmente para uma plataforma, utilizando das APIs e SDKs

desenvolvidos pela fabricante da própria plataforma para desenvolver aplicações para

a mesma. Aplicativos desenvolvidos desta forma tendem a possuir um desempenho

superior a outros métodos, ainda que outras tecnologias de desenvolvimento tenham

evoluído para se equiparar.

Entretanto, esta forma de desenvolvimento segundo Prezotto e Boniatti ( 2014),

exige em muitos casos de um ambiente preparado para uma plataforma em

específico, sendo assim, para que uma aplicação nativa possa ser executada em

múltiplas plataformas é necessário recriar a aplicação exigindo tempo, investimento e

empenho da equipe de desenvolvimento nas tecnologias utilizadas a fim de replicar

as funcionalidades da aplicação em cada uma das plataformas alvo segundo Prezotto

e Boniatti ( 2014).

Para auxiliar nesta problemática segundo Prezotto e Boniatti ( 2014), soluções

cross-platform possibilitam o desenvolvimento de uma única aplicação que poderá ser

executada em diferentes plataformas, divididas em duas categorias, WEB Apps e

Aplicações híbridas, apresentadas ainda neste capítulo.

3.7.2 Aplicativos multi plataforma (Híbridos)

Aplicativos multiplataforma ou híbridos, segundo Prezotto e Boniatti ( 2014),

consistem em aplicações com foco principal na portabilidade entre plataformas,

desenvolvidas com a finalidade de operarem em qualquer dispositivo, sendo

necessário instituir sua codificação uma única vez durante o desenvolvimento, o que

em tese, sugere uma redução da necessidade de qualificação específica em uma

plataforma de desenvolvimento por parte da equipe encarregada de desenvolver uma

aplicação deste tipo.

3.7.2.1 WEB Apps

Segundo Prezotto e Boniatti ( 2014), aplicações multiplataforma utilizam a

estrutura do navegador para renderizar o conteúdo da aplicação, não sendo

necessário que o desenvolvedor se preocupe com as diferentes linguagens de

27

programação entre as plataformas, pois este tipo de aplicação utiliza das tecnologias

WEB como HTML, CSS e JS para compor o front-end e PHP, Javascript ou outras

linguagens para o back-end, contando majoritariamente com seu visual responsivo,

viabilizando a exibição da aplicação em diferentes dispositivos com formatos além dos

presentes nos dispositivos móveis, como desktops, tvs, etc. No entanto, apesar de

utilizarem tecnologias que são comuns a maioria dos navegadores, o comportamento

da aplicação pode se dar de formas diferentes entre eles, como o suporte de

componentes, processamento gráfico, entre outros, contando com a otimização dos

desenvolvedores para assegurar que o comportamento se manterá fiel independente

do browser que estará executando-a.

3.7.3 Frameworks

Em desenvolvimento de software, o framework consiste em uma estrutura

produzida com o intuito de facilitar o desenvolvimento de qualquer que seja a

atividade, oferecendo um “esqueleto” genérico, para auxiliar no desenvolvimento do

objeto produzido pelos indivíduos envolvidos Sommervile( 2011).

Com a necessidade de se desenvolver aplicações mais rapidamente, a criação

de frameworks para esta finalidade foi fomentada tanto para aplicações nativas quanto

para aplicações híbridas. Para aplicações nativas, a distribuição dos frameworks é

feita pela própria fabricante do sistema operacional e de suas parceiras. Como por

exemplo, o Android Studio e o Xcode, oferecidos respectivamente pelo Google e pela

Apple.

Em contrapartida, frameworks para desenvolvimento de aplicações híbridas

não possuem um único responsável, com isso, a quantidade de ferramentas com este

propósito é vasta, muitas delas com código fonte open source, entre as mais

populares, se encontram Cordova, Angular, e IONIC.

3.8 Banco de dados noSQL

Com conceito inicial datado da década de 90, obtendo reformulação na primeira

década dos anos 2000. O banco de dados noSQL consiste em uma estrutura de dados

não relacional, podendo ser composta de um dos quatro modelos de dados: chave-

valor, documentos, orientado a colunas e grafos. Surgido como alternativa para

28

manipulação de grandes massas de dados semiestruturados ou desestruturados,

permitindo acesso às informações com baixa latência, alta flexibilidade e alta

performance devido a utilização de clusters escalonáveis horizontalmente (AMAZON,

2018).

● Chave - Valor: O modelo consiste em um dos tipos dos bancos de dados não

relacionais, altamente particionável cujo armazenamento dos dados é feito

como um conjunto de pares de chave-valor, onde as chaves funcionam de

forma semelhante a um identificador exclusivo. O tipo da chave é indefinido,

podendo ser um objeto simples ou composto complexo (AMAZON, 2018).

● Gráfico: O modelo consiste em um dos tipos dos bancos de dados não

relacionais criados para possibilitar o armazenamento de dados de

relacionamentos e da navegação entre eles. Os relacionamentos entre as

entidades são armazenados nas bordas, contando com nós para armazenar as

entidades, onde cada borda possui um nó inicial e um nó final, um tipo e uma

direção, permitindo a descrição dos relacionamentos hierárquicos das ações,

das propriedades, não existindo um limite para a quantidade de

relacionamentos que os nós podem ter (AMAZON, 2018).

Neste tipo de banco de dados o cruzamento das associações se dá por meio

da persistência dos nós no banco uma vez que os relacionamentos entre eles

não são calculados no momento da consulta, tornando-os de grande valor para

aplicações de detecção de padrões, como redes sociais ou sistemas de

detecção de fraude (AMAZON, 2018).

● Orientado a Colunas: O modelo é projetado de modo a permitir o

armazenamento dos dados em colunas, apresentando uma melhor velocidade

na consultas devido sua arquitetura orientada a colunas, onde cada coluna de

uma tabela é dividida sobre os nós usando o conceito de grupos de colunas

indicando onde os usuários devem armazenar as colunas juntas, não

necessitando que as linhas de dados possuam o mesmo grau, ou seja, é

permitido um número variável de colunas, tornando os dados neste modelo

espaçados. Indicado para aplicações que tratam com grandes volumes de

dados com propósito analítico (AMAZON, 2018) e (Souza, 2016).

● Documentos O modelo é projetado com a finalidade de armazenar dados semi

estruturados, como documentos, agrupados em conjuntos, funcionando de

29

forma semelhante às tabelas de um banco de dados (BD) relacional, não

restringindo que os documentos possuam a mesma estrutura de dados entre

si. Este modelo é considerado intuitivo por permitir que dados ao nível da

aplicação sejam armazenados permitindo a persistência dos mesmos aos

desenvolvedores, como documentos JSON por exemplo, podendo possuir a

mesma estrutura de dados ou diferentes entre si (AMAZON, 2018).

4 TECNOLOGIAS UTILIZADAS

Neste capítulo, são apresentadas breves descrições a respeito das tecnologias

utilizadas durante o desenvolvimento, levando em conta um breve histórico evolutivo

destacando a versão escolhida utilizada no projeto.

4.1 HTML

O HTML (Hyper Text Markup Language) em tradução direta, linguagem de

marcação de hipertexto, atua somente na marcação do código estrutural de páginas

WEB criada em 1990 por Tim Bernes Lee, obtendo suas naturais evoluções até a

versão HTML3 onde uma padronização foi necessária devido a grandes diferenças na

escrita do código (tags e estruturas específicas criadas para navegadores da época)

instituída pelo consórcio regulador W3C gerando a versão HTML4, chegando a versão

HTML5 após apresentação da iniciativa criada pelo grupo WHATWG formado pela

parceria entre as empresas Apple, Mozilla e Opera que o apresentou ao W3C, obtendo

lançamento em seguida (HTML, 2018).

Ainda na versão HTML5 a linguagem também incorporou elementos semânticos para

que a estruturação fosse melhor interpretada também para os motores de busca.

4.2 Sass

O Sass criado por Hampton Catlin, trata-se uma “extensão do CSS” que

adiciona recursos a linguagem como variáveis, regras, importações, argumentos,

entre outros itens para permitir que a estrutura das folhas de estilo sejam escritas de

forma mais eficiente. Possui duas sintaxes disponíveis SCSS (Sassy CSS) e o SASS

que contém diferenças internas mas possuem os mesmos recursos apesar de

apresentarem sintaxes diferentes. Independente da Sintaxe utilizada, ao fim, os

30

códigos escritos, são “transpilados” para que seja gerado um arquivo CSS puro, que

pode ser incorporado ao projeto sem perdas (SASS, 2018).

4.3 Firebase

O firebase consiste em um conjunto de serviços (denominados produtos)

oferecidos pelo google, de modo a auxiliar o desenvolvimento da infraestrutura de

aplicações, baseado em tecnologias em nuvem, esta proposta, permite que o

desenvolvedor se preocupe menos com o back-end de sua aplicação, com os custos

iniciais para publicação, implementação de MVP e escalabilidade, devido ao custo

inicial de adoção ser gratuito e permitir uma margem razoável de acessos ou

transações ainda com o benefício gratuito ativo (FIREBASE, 2018).

Entre os serviços oferecidos pelo Firebase, estão o serviço de autenticação

(Firebase Auth), o armazenamento de arquivos em nuvem (Firebase Cloud Storage),

e a base de dados noSQL (Firebase Firestore) utilizados no desenvolvimento de

ambas as aplicações de nome HoraVIP.

● Firebase Auth - Oferece ao desenvolvedor um conjunto de estruturas

que facilitam a integração de um sistema de autenticação na aplicação,

utilizando as mesmas estruturas dos sistemas de autenticação,

verificação de conta e gerenciamento de senhas implementados nos

serviços oferecidos pelo google (Gmail, Smart Lock, e Chrome).

Necessitando apenas que o desenvolvedor integre a API em sua

aplicação com poucas linhas de código (FIREBASE, 2018).

● Firebase Cloud Storage - Consiste em um banco de dados de arquivos,

otimizado para as transações decorrentes do envio e recebimento de

dados dos usuários, como imagens, documentos, e vídeos, orientado de

acordo com a velocidade de conexão do usuário, pausando e retomando

a sincronização dos dados sempre que o usuário se reconectar, de

escalabilidade simplificada e com integração com o Firebase Auth para

autenticar os usuários de forma declarativa (FIREBASE, 2018).

● Firebase Firestore - Consiste em um banco de dados noSQL sob o

modelo de documentos explanado no capítulo 3, disponibilizado para

armazenamento, sincronização e consultas dimensionadas de acordo

31

com o conjunto de resultados, tornando-o escalonável lateralmente

desde a implementação na aplicação (FIREBASE, 2018).

Conta com uma comunidade ativa para a resolução de dúvidas, além de

oferecer suporte direto pela documentação e por um canal de comunicação com o

suporte técnico, pela página inicial do firebase e pelo terminal do desenvolvedor.

4.4 IONIC

O IONIC, é um framework para desenvolvimento de aplicações multi

plataforma, open-source com o intuito de empregar tecnologias WEB para

desenvolvimento do front-end da aplicação como JavaScript, HTML e CSS, integrando

o Apache Cordova, para possibilitar o acesso dos recursos do dispositivos por meio

de APIs, adicionando a codificação e dependências do projeto em wrappers

destinados para cada plataforma (IONIC, 2018).

4.4.1 Angular

Segundo a documentação, o Angular consiste em uma plataforma e também

em um framework construído com o intuito de simplificar o desenvolvimento de

aplicações clientes para sistemas de mesa ou móveis utilizando tecnologias WEB em

conjunto com o TypeScript (ANGULAR, 2018).

O TypeScript (TS), desenvolvido pela microsoft consiste em um conjunto dos

elementos do ECMAScript, acrescentando recursos como Tipagem para auxiliar na

escrita dos códigos. Diferente de iniciativas como o Sass que necessitam transpilar

seus códigos em CSS, o TS pode ser diretamente reconhecido em navegadores que

executam o ECMAScript 3 ou superior (ANGULAR, 2018).

4.5 Adobe Experience

O Adobe Experience consiste em uma ferramenta de desenvolvimento de

designs criada pela Adobe para auxiliar no desenvolvimento de protótipos focados na

experiência do usuário e na interface de usuário, simulando as telas da aplicação

durante o processo de desenvolvimento, criando guias interativas de fluxo entre as

telas, lançada em 2016, inicialmente para Mac OS X, posteriormente para Windows

10. (ADOBE, 2018) e (HASSAN, 2018).

32

5 SOLUÇÃO IMPLEMENTADA

A partir da definição esclarecida sobre a problemática em pauta, foi necessário

determinar as funcionalidades das aplicações de título HoraVIP, assim como seus

casos de uso, requisitos funcionais e não funcionais, pontuando um dos primeiros

estágios do desenvolvimento de ambas as aplicações. Ainda neste capítulo, são

apresentadas as justificativas a respeito do modelo de processo utilizado, framework

de desenvolvimento assim como as configurações do ambiente, e telas desenvolvidas

com base nos casos de uso aprovados.

5.1 Modelo de processos espiral

O modelo de processo seguido foi baseado no modelo espiral devido suas

características de interação e adaptabilidade do modelo no mundo real explanadas no

capítulo 3.

Este modelo foi escolhido pois permite a entrega de uma versão protótipo ao

fim da primeira espiral para ser avaliado e testado em cenários do mundo real, de

modo a refinar funcionalidades com base em amostragem de resultados, ajustando

custo e cronograma de acordo com os resultados obtidos, implementando-os em

futuras versões mais completas.

No decorrer do processo da espiral, foram gerados artefatos que especificam

requisitos e casos de uso para auxiliar os autores na interpretação e no

desenvolvimento de funcionalidades.

5.2 Requisitos

Os requisitos das aplicações foram baseados nas funcionalidades mais

corriqueiras dos estabelecimentos de pequeno e médio porte, orientadas por um

especialista na área, sendo submetidas a avaliação pela equipe de desenvolvimento

para organização de prioridades e negociação de funcionalidades com o especialista

durante o período em que o especialista ficou disponível, a partir daí, as

funcionalidades foram verificadas pelos autores juntamente com o orientador

buscando eliminar problemas de entendimento e escopo.

Os requisitos gerados foram organizados em uma estrutura de tabela com 4

campos: código, descrição, observação e prioridade.

33

● O código é responsável por abreviar a ordenação do requisito e explicitar

se o mesmo se trata de um requisito funcional RF ou um requisito não

funcional RNF;

● O dígito após a abreviação significa a ordem de coleta do requisito;

● A descrição do requisito consiste em uma redução simples da

necessidade da aplicação;

● A observação consiste em uma breve explicação da ocorrência do

requisito, descrevendo a funcionalidade ou o local onde será

implementado;

● Por fim, a prioridade, delimita a urgência do desenvolvimento do

requisito para integração no MVP, no entanto, caso não possa ser

adicionado na versão em desenvolvimento, a prioridade é elevada

crescentemente, apontando seu desenvolvimento imediato na versão

seguinte.

Este método organizacional foi decidido para facilitar a leitura e interpretação

do que se esperava de cada requisito, assim como explicitar o foco necessário para o

desenvolvimento de cada um.

5.2.1 Requisitos funcionais HoraVIP – Estabelecimentos

Tabela 3: Requisitos Funcionais HoraVIP - Estabelecimentos

COD Descrição Observação Prioridade

RF1 O estabelecimento deve poder gerenciar sua agenda

Definir horário de funcionamento, na semana, sábados e domingos e feriados

P1

RF2 O estabelecimento deve poder gerenciar os serviços por ele oferecidos

Permitir a definição inicial dos serviços oferecidos, assim como valores dos mesmos, permitir o manejo destes itens sempre que necessário

P1

RF3 O estabelecimento deve poder gerenciar seus funcionários ou parceiros

A relação estabelecimento, quadro funcional deve ser flexível, delimitando funcionalidades aos membros do quadro e permitindo o manejo das funções dos membros e de seus dados.

P1

34

RF4 O estabelecimento deve aprovar ou recusar agendamentos.

De forma a permitir que o estabelecimento cancele ou permita o agendamento solicitado, informando o motivo da recusa se a houver

P1

RF5 O estabelecimento deve visualizar sua agenda diária

Exibindo os atendimentos aprovados pelo estabelecimento no dia corrente que estão aguardando início dos serviços

P1

RF6 O administrador deverá inserir ao menos 1 foto no sistema

Para que possa oferecer auxílio visual do local aos clientes em potencial.

P1

RF7 Permitir ao estabelecimento acompanhar suas avaliações

Mostrando com prioridade a média de nota das avaliações e quantas opiniões foram inseridas

P3

RF8 Permitir que o estabelecimento responda às avaliações

Permitindo em cada opinião feita sobre o serviço do estabelecimento a possibilidade de resposta do mesmo

P3

RF9 Somente o administrador autenticado pode operar o sistema

A autenticação deve ser feita no login inicial, assim como antes de efetivar quaisquer alterações nos componentes de configuração do estabelecimento e de feedback para os clientes.

P1

RF10 O estabelecimento deve avisar seus clientes em casos de problemas em sua localidade

Falta de energia, falta de água, entre outros problemas locais, devem poder ser sinalizados pelo estabelecimento para evitar insatisfações aos seus clientes agendados no dia.

P3

RF11 O estabelecimento deve poder encaminhar mensagens promocionais a clientes

O envio dessas mensagens é direcionado, permitindo encaminhamento de ofertas ou até mesmo facilitando a comunicação entre o estabelecimento e os seus clientes.

P3

5.2.2 Requisitos não funcionais HoraVIP – Estabelecimentos

Tabela 4: Requisitos não funcionais - HoraVIP - Estabelecimentos


RNF1 O estabelecimento deve ser notificado a cada nova solicitação de atendimento

A notificação deve ficar em destaque na aplicação para evitar perda do atendimento ou atrasar a fila de solicitações.

P1

RNF2 O administrador deve ser lembrado de preencher os dados do

O procedimento será recomendado todas as vezes que o administrador logar na aplicação enquanto não completar as informações do

P2

35

estabelecimento cadastro do estabelecimento.

RNF3 As dados do estabelecimento devem imediatamente postadas

Garantindo alteração imediata dos dados do estabelecimento, no entanto, a verificação dos dados será feita periodicamente evitano fraudes

P1

RNF4 Atendimentos cancelados sem envio de justificativa ao cliente reduzirão a avaliação do estabelecimento

Reduzindo a média avaliativa do estabelecimento para penaliza-lo pelo comportamento duvidoso e fora das diretrizes da plataforma.

P3

RNF5 A agenda do dia será automaticamente atualizada

Mostrando a agenda mais atualizada, mas permitindo que o estabelecimento visualize os atendimentos feitos em datas anteriores.

P1

RNF6 A aplicação deverá adaptar-se a escala das telas, mantendo a definição das informações por ela oferecidas

A aplicação deverá manter seu design inicial na maior quantidade de dispositivos possível.

P1

RNF7 Deverá ser mantido um histórico de atendimentos feitos

Devendo ser adicionado na agenda, para auditoria futura do estabelecimento para comparação de notas ou vouchers promocionais

P2

RNF8 Após aprovar o atendimento, a aplicação emitirá uma notificação ao cliente

Notificando-o de que o atendimento foi aprovado e que o estabelecimento o aguarda no local e hora solicitados.

P2

5.2.3 Requisitos funcionais HoraVIP - Clientes

A tabela de requisitos resultante da avaliação preliminar das funcionalidades

da aplicação dos clientes é demonstrada abaixo.

Tabela 5: Requisitos Funcionais - HoraVIP - Clientes


RF1 Entrar sem Login Apresentar a aplicação e as funcionalidades da aplicação para os clientes antes mesmo de exigir um login do usuário, somente se o mesmo for executar alguma operação como agendar o serviço, ou fazer uma avaliação do atendimento prestado

P1

36

RF2 Apresentar os estabelecimentos cadastrados no sistema.

Permitir que o usuário defina entre as distâncias estabelecidas a quilometragem do raio onde a aplicação irá buscar os estabelecimentos naquela região.

P1

RF3 Pesquisar estabelecimentos específicos assim como serviços cadastrados no sistema

Permitir que o usuário visualize por meio da busca estabelecimentos, ou serviços oferecidos pelo estabelecimento em um raio pré definido pela aplicação.

P3

RF4 Favoritar estabelecimentos selecionados pelo cliente

Permitir que o cliente favorite os estabelecimentos para que eles sejam exibidos em uma área de favoritos.

P3

RF5 Exibir as categorias dos serviços disponíveis ao usuário ao iniciar a aplicação

As categorias listadas de acordo com a barbearia P1

RF6 Permitir que o usuário filtre os resultados de sua busca

Pela localização, pela categoria dos serviços, pelos estabelecimentos,

P2

RF7 Permitir que o cliente agende um atendimento na agenda do estabelecimento no DIA Seguinte

Ao solicitar o atendimento o cliente deve aguardar a aprovação do mesmo para que receba a notificação de aprovação, do contrário, ele receberá uma justificativa do estabelecimento.

P1

RF8 Permitir que o cliente agende um ou mais atendimentos na agenda do estabelecimento durante a SEMANA ou durante o MÊS corrente

Exibir na lista de agenda um seletor mensal, para que o cliente possa fazer a reserva do atendimento com mais antecedência.

P2

RF9 Permitir que o cliente agende um ou mais atendimentos na agenda de um ou mais estabelecimentos em qualquer período do ANO

Para permitir que o usuário estabeleça anualmente a sua rotina de acordo com a frequência de utilização do serviço

P3

RF10 Permitir que o cliente visualize os atendimentos agendados por ele, e os exclua caso deseje

Exibir na área do cliente os atendimentos a serem realizados assim como os atendimentos já concluídos, juntamente com a avaliação dada se acaso ela tiver sido oferecida.

P2

RF11 Avaliar o atendimento Permitir que o cliente avalie o atendimento oferecido pelo estabelecimento após a conclusão do mesmo.

P3

37

5.2.4 Requisitos não funcionais HoraVIP – Clientes

Tabela 6: Requisitos não funcionais Hora Vip - Clientes


RNF1 A aplicação deve permitir login do usuário somente se o mesmo informar seu e-mail e senha

Incluindo novos meios de se cadastrar e logar a medida que o desenvolvimento da aplicação for progredindo

P1

RNF2 O sistema deve dispor filtros para manusear os resultados das buscas do usuário sempre que solicitado.

A filtragem será necessária para limitar os resultados por estabelecimentos, serviços inicialmente, progredindo para data e hora em futuras atualizações.

P3

RNF3 o usuário deve estar autenticado para avaliar um serviço, solicitar atendimento ou alterar suas informações de cadastro.

P1

RNF4 O sistema deve exibir discretamente indicadores de alteração dos dados do cadastro do cliente.

Notificações ou confirmações devem aparecer de forma elegante, sem que haja interrupção da visualização

P3

RNF5 O sistema não deve exibir notificações ou indicadores após envio de avaliações

P3

RNF6 O sistema deve exibir notificação após aprovação do agendamento feito pelo cliente

P1

RNF7 O sistema deve notificar o cliente 1d, 2h, antes do horário do atendimento ser iniciado.

Os alertas devem ser feitos por notificações além de indicarem na aplicação que o cliente possui um atendimento agendado, juntamente a sua data. Permitindo que o cliente cancele o atendimento, mediante autenticação.

P2

RNF8 O sistema deve permitir o cancelamento do serviço somente após aceitação da taxa de multa por cancelamento após 2h do agendamento.

P3

38

RNF9 O sistema deve possuir uma interface agradável de fácil manutenção e navegação

P1

RNF10 O sistema deve identificar que está em execução em telas de tamanhos menores e adaptar sua interface para melhor visualização do conteúdo

P1

RNF11 Interface Familiar O sistema deve funcionar e manter sua interface de navegação semelhante a de outras plataformas (como OLX), buscando em sua identidade manter o apelo visual previsto na aplicação para estabelecimentos.

P1

RNF12 O sistema deve separar os estabelecimentos favoritados em uma tela específica para seleção do cliente.

Desta forma, o cliente sempre poderá visualizar novas ofertas além das que ele já está habituado, permitindo que o mesmo encontre novos estabelecimentos.

P1

RNF13 O sistema deve exibir os estabelecimentos cadastrados em “cartões” assim como uma breve descrição sobre eles.

Os cartões conterão uma capa ou um banner que permitirá o usuário distinguir o estabelecimento entre os demais, juntamente com o nome do local e sua descrição.

P1

RNF14 Iniciar a solicitação de atendimento tocando sobre o estabelecimento, seguindo para a seleção de serviço, funcionário, e horário

Ao clicar no cartão do estabelecimento, o usuário deve poder selecionar o serviço que será encaminhado para alocação na agenda do estabelecimento selecionado

P1

39

5.3 Diagrama de Casos de Uso

Considerando os requisitos levantados e descritos anteriormente, foi possível

modelar as funcionalidades de ambos os sistemas. Abaixo são apresentados os

diagramas de casos de uso dos sistemas de nome HoraVIP, iniciando pela aplicação

dos estabelecimentos (Figura 2).

Fonte: Casos de uso HoraVIP (Estabelecimentos)

Apenas o estabelecimento pode efetuar o cadastro do do mesmo e gerenciar

seus dados cadastrais, assim como cadastro de funcionários, cadastro de serviços e

atribuição de serviços aos membros do estabelecimento.

Figura 2: Casos de uso (HoraVIP - Estabelecimentos)

40

Fonte: Casos de uso HoraVIP (Cliente)

Apenas o cliente poderá buscar os estabelecimentos cadastrados na

plataforma, solicitar atendimento, visualizar os agendamentos, cancelá-los, e avaliar

o serviço prestado.

5.4 Framework

Com base nos artefatos gerados, mais especificamente nos requisitos não

funcionais e nos casos de uso, optou-se por utilizar o framework IONIC, mais

especificamente a versão 3 para desenvolver ambas as aplicações de título HoraVIP,

visto que ambas as aplicações não necessitam de tecnologias específicas de um

sistema operacional para que operem.

Aliado a esta constatação, abaixo encontram-se algumas características

julgadas fundamentais que complementam a justificativa da seleção do framework

pelos autores.

● Comunidade ativa e proativa, concentrada no fórum próprio do

framework;

Figura 3 - Casos de uso (HoraVIP - Clientes)

41

● Grande quantidade de conteúdo disponível como cursos, artigos,

tutoriais, entre outros;

● Gratuidade de utilização;

● Desenvolvimento facilitado, por utilizar tecnologias comuns do ambiente

WEB;

● Permite o desenvolvimento de aplicações para os sistemas mais

populares entre os dispositivos móveis.

5.5 Firebase

Para compor a estrutura de back-end e a base de dados compartilhada entre

as aplicações, optou-se por utilizar a plataforma Firebase, mais especificamente os

serviços, Firebase Auth, Firebase Firestore, Firebase Cloud Storage, explanados no

capítulo 4.

Abaixo, encontram-se as principais características apontadas pelos autores

para implementação da plataforma neste projeto:

● Integração de serviços a aplicação necessitando de poucas linhas de

código;

● Proporciona um sistema de autenticação, formulado para aplicações

populares do google;

● Envio e armazenamento de dados e arquivos com grande margem de

transações simultâneas ainda com o benefício gratuito ativo;

● Velocidade de acesso a dados devido a estrutura escalável lateralmente,

característica dos bancos de dados noSQL;

● Comunicação ampla e tiragem de dúvidas com um suporte técnico da

plataforma;

● Ampla quantidade de conteúdo didático disponível na documentação;

5.6 Estrutura do banco de dados

Por se tratar de um banco de dados não relacional que utiliza o modelo de

documentos, sua estrutura de banco de dados pode ser representada por uma árvore

JSON, abaixo, os objetos representam as coleções, os itens, em negrito dentro do

objeto representam como um todo representa um documento, e individualmente os

registros deste documento.

42

Quadro 1: Requisitos não funcionais Hora Vip - Clientes

{ "saloes": { "doc_id": "(gerador automático aleatório)", "ativoSalao": "boolean", "bairroSalao": "string", "celularSalao": "string", "cepSalao": "string", "cidadeSalao": "string", "complementoSalao": "string", "descricaoSalao": "string", "nomeSalao": "string", "geolocalizacao": "geopoint", "numeroSalao": "number", "uidSalao": "string", "tokensalao": "string" }, "agendas": { "doc_id": "(gerador automático aleatório)", "ativo": "boolean", "bairroSalao": "string", "cidadeSalao": "string", "cepSalao": "string", "geolocalizacaoSalao": "geopoint", "ruaSalao": "string", "numeroSalo": "number", "whatsappSalao": "string", "celularSalao": "string", "nomeSalao": "string", "emailSalao": "string", "descricaoSalao": "string", "fixoSalao": "string", "dataAgenda": "string", "horaAgenda": "string", "tempoEstimadoAgenda": "string", "situacaoAgenda": "number", "descricaoNegacaoAgenda": "string", "precoServico": "string", "categoriaServico": "string", "nomeServico": "string", "nomeFuncionario": "string", "nomeUsuario": "string", "generoUsuario": "string", "nascimentoUsuario": "string", "emailUsuario": "string", "celularUsuario": "string",

43

"uidSalao": "string", "uidUser": "string" "tokenUsuario": "string", "tokenSalao": "string" }, "funcionarios": { "doc_id": "(gerador automático aleatório)", "cpfFuncionario": "string", "funcaoFuncionario": ["string" ], "generoFuncionario": "string", "nomeFuncionario": "string", "telefoneFuncionario": "string", "uidSalao": "string" }, "servicosSaloes": { "doc_id": "(gerador automático aleatório)", "ativoServico": "boolean", "categoriaServico": "boolean", "nomeServico": "boolean", "uidSalao": "string" }, "horariosSaloes": { "doc_id": "(gerador automático aleatório)", "abrirSengundaSexta": "string", "fecharSengundaSexta": "string", "fecharAlmocoSengundaSexta": "string", "abrirAlmocoSengundaSexta": "string", "abrirSabado": "string", "fecharSabado": "string", "fecharAlmocoSabado": "string", "AbrirAlmocoSabado": "string", "abrirDomingo": "string", "fecharDomingo": "string", "checkAlmocoSengundaSexta": "boolean", "checkSabado": "boolean", "checkAlmocoSabado": "boolean", “uidSalao”: “string” "checkDomingo": "boolean" }, "usuarios": { "doc_id": "(gerador automático aleatório)", "nomeUsuario": "string", "celularUsuario": "string", "nascimentoUsuario": "string", "emailUsuario": "string", "generoUsuario": "string", "uidUsuario": "string", "tokenUsuario": "string" },

44

"servicos": { "doc_id": "(nome da categoria)", "servicos": ["string"] }, "availiacaesSalao": { "doc_id": "(gerador automático aleatório)", "refAgenda": "reference", "uidSalao": "string", "uidUsuario": "string", "descricaoAvaliacao": "string", "pontosAvaliacao": "number" } }

Fonte: Autores

Para que seja possível visualizar os relacionamentos entre os documentos do banco

de dados com maior clareza, foi desenvolvida uma representação relacional da base

de dados utilizando somente as chaves de cada documento.

Fonte: Autores

5.7 Seleção de Plataforma

Devido ao baixo custo de produção e as evoluções naturais que as ferramentas

de desenvolvimento multiplataforma obtiveram no que diz respeito a velocidade e

robustez, optou-se por utilizar neste projeto um framework de desenvolvimento para

auxiliar na tarefa. A quantidade de frameworks existentes para este fim é grande, no

Figura 4 - Representação relacional da base de dados das aplicações HoraVIP

45

entanto, dentre elas a escolha do IONIC se deu por alguns fatores que foram

considerados cruciais para a escolha dos autores.

● Opera atualmente com a licença de software livre;

● Possui ampla quantidade de material recursivo, além de contar com uma

comunidade de apoio diversificada;

● Utiliza Angular e Cordova, dois frameworks de grande peso no que diz

respeito a estabilidade e mantenimento de seus códigos;

● Por fim é munido de uma vasta biblioteca dos ditos componentes, que

facilitam o desenvolvimento da aplicação por utilizarem recursos do

sistema operacional.

5.8 Planejamento do Desenvolvimento

Conseguinte a definição do problema e das ferramentas que foram utilizadas,

o próximo passo se deu no planejamento dos processos necessários para se

desenvolver as aplicações. Para isso, a projeção do processo foi instituída em etapas,

detalhadas a seguir.

Planejamento do Desenvolvimento:

● Aquisição de material para estudo dos tópicos, noSQL, Angular 5,

Typescript;

● Familiarização com o framework IONIC e seu ambiente de

desenvolvimento, testando projetos e tutoriais dos materiais adquiridos;

● Familiarização com a arquitetura de desenvolvimento do Angular 5 e

com o Typescript;

● Definição de layout das aplicações utilizando a ferramenta de

prototipação Adobe Experience.

5.9 Ambiente de desenvolvimento

Nesta seção é apresentado o ambiente de desenvolvimento das aplicações de

nome HoraVIP, o projeto foi executado contando com uma sub equipe de 2 pessoas,

com as funções de desenvolvedor e gerente de projeto. A tarefa foi dividida segundo

46

o tempo disponível dos integrantes e seu conhecimento teórico sobre as tecnologias

necessárias para a produção das aplicações.

Os detalhes técnicos do ambiente de desenvolvimento estão listados abaixo:

● Máquina de desenvolvimento: Intel Core i5 2.2Ghz, 8gb de RAM, 128GB

de armazenamento em SSD;

● Sistema Operacional: Windows 10 Home Single Language;

● Sistema Operacional base para desenvolvimento: Android 5.0

(Marshmallow);

● IDE: Visual CODE v.;

● Frameworks: Angular 5, NodeJS v10.9.0, IONIC 3;

● HTML5 e CSS3 utilizados em paralelo para composição da interface

gráfica dos aplicativos;

● Banco de dados: Firebase Filestorage (noSQL);

● Gerenciador de arquivos Firebase Storage;

● Autenticador: Firebase Authentication.

● Aparelhos de testes: Samung Galaxy J7 pro (SM-J730G), Galaxy S7

(SM-G930F)

5.10 Telas das aplicações

Pela característica do projeto se referir ao desenvolvimento de uma plataforma

composta de duas aplicações, a apresentação das telas desenvolvidas foi dividida em

dois subtópicos, de modo a simplificar a visualização das mesmas.

5.10.1 Telas HoraVIP - Estabelecimentos

Ao iniciar a aplicação, o usuário será apresentado a um slide introdutório,

exibindo as principais funcionalidades disponíveis até o momento para a aplicação

dos estabelecimentos, seguindo para uma tela de login, com as funcionalidades

padrões (cadastro, esqueci senha). Abaixo, são listadas detalhadamente as telas e

suas funcionalidades.

47

Fonte: HoraVIP - Estabelecimentos

“A” - Slide Introdutório - Exibido somente se o usuário não tenha se

autenticado anteriormente, responsável por introduzir as principais

funcionalidades do sistema, com rolagem lateral, permitindo que o usuário pule

diretamente para o login se assim preferir.

“B” - Login - Tela de login, assim como o slide introdutório, é exibida somente

se o usuário ainda não tenha se autenticado. Por meio dela, além do login, o

usuário, pode fazer o cadastro (Figura 5, Tela C), e recuperar sua senha, caso

tenha a esquecido (Figura 5, Tela D).

Ao caso do usuário estar retornando a aplicação, a tela de autenticação

biométrica é exibida para autenticar a entrada, somente se o dispositivo suportar

biometria e possuir o sistema operacional a partir do android 6.0.

Figura 5 - Apresentação, login e cadastro.

48


Após a autenticação do usuário, a tela inicial é exibida (Figura 7), dividida em duas

Tabs, Home e Agenda, a Tab Início é composta por 3 cartões (Agendamentos,

Avaliações, Configuração).


“A” - Tela Home - Nela são concentradas todas as operações destinadas ao

gerenciamento do estabelecimento.

● O cartão de título “Agendamento”, contém os principais eventos da

agenda do dia (Clientes Agendados Hoje, Agendamentos Cancelados,

Aguardando Aprovação);

Figura 6 - Autenticação Biométrica

Figura 7 - Tela inicial

49

● O cartão “Avaliações” expõe a média das avaliações dos clientes feitas

aos serviços oferecidos pelo estabelecimento, assim como o total de

avaliações enviadas sobre cada serviço.

● O cartão “Configuração”, concentra todos os itens necessários para

configuração e cadastro do estabelecimento para que o mesmo seja

apresentado na plataforma, sendo necessário que o usuário siga os

passos da configuração de cima a baixo, preenchendo as dependências

do estabelecimento para que ele seja devidamente configurado.

A tab Agenda, concentra os eventos já cadastrados na agenda do estabelecimento,

permitindo que estes sejam visualizados em suas devidas categorias.


“A” - Agenda: Concentra os atendimentos aprovados no dia para o

estabelecimento em categorias;

“B” - Agenda (Clientes): Concentra os clientes que solicitaram atendimento

ao estabelecimento na categoria apresentada na tela Agenda;

“C” - Detalhes da Agenda: Apresentado ao tocar no cliente, concentra os

detalhes do agendamento;

Figura 8 - Tela Agenda

50

Ainda na tela inicial, é possível visualizar as avaliações oferecidas pelos

clientes aos serviços já concluídos pelo local diretamente pelo cartão avaliações, no

item “ver avaliações”.


Para que o estabelecimento seja cadastrado e devidamente ativado, é

necessário que o usuário siga os passos do cartão de configurações de cima a baixo,

iniciando pelo item “Contatos”.


“A” - Contatos: Concentra os dados de contatos do estabelecimento;

“B” - Endereço: Concentra os dados de localidade do estabelecimento;

“C” - Localização: Permite que o usuário marque o seu estabelecimento, para

que sistema detecte a latitude e longitude aproximadas do local;

Figura 9 - Avaliações

Figura 10 - Configuração do Estabelecimento.

51

“D” - Serviços: Permite que o usuário selecione, entre as categorias, os

serviços que oferece.

Fonte:HoraVIP - Estabelecimentos

“E” - Relação de Funcionários - Permite visualizar os funcionários já

cadastrados no sistema, sendo possível inserir novos cadastros a partir do

ícone “+”.

“F” - Atualizar Funcionário - Permite que as informações dos funcionários

sejam editadas ou excluídas, bastando selecionar o funcionário a ser alterado

na tela anterior.

“G” - Horário (Funcionamento) - O horário de funcionamento do

estabelecimento delimita o tempo de início e final das operações do

estabelecimento, sendo particionado de forma a se acomodar intervalos como

o horário de almoço, em dias delimitados dias úteis e finais de semana;

o final do processo de configuração, caso as informações dos itens anteriores

tenham sido preenchidas, é necessário apenas que sejam informados o nome

do estabelecimento e uma breve descrição, para que seja possível ativá-lo

sendo adicionado à listagem de estabelecimentos cadastrados por meio da tela

estabelecimento (Figura 12).

Figura 11 - Gerenciamento de Funcionários e Horário

52


“H (A)” - Estabelecimento - Permite que seja informado o nome e uma breve

descrição sobre o estabelecimento.

“H (B)” - Estabelecimento - Alerta de preenchimento vago, exibido se alguma

das telas anteriores não tenha sido preenchida.

Figura 12 - Ativação do Estabelecimento

53

5.10.2 Telas HoraVIP - Clientes

Ao iniciar a aplicação, o usuário será encaminhado diretamente a tela inicial,

de modo que para visualizar as informações dos estabelecimentos cadastrados na

plataforma. A tela inicial, é composta de 2 guias (Agenda, Categorias).

Figura 13 - Tela inic¬ial HoraVIP - Clientes

Fonte: HoraVIP - Clientes

“A” - Tela inicial - Concentra os estabelecimentos cadastrados na plataforma

“B” - Agenda - Centraliza as solicitações de agendamentos feitas pelo usuário,

juntamente com o status da solicitação (Aguardando, Aprovado, Recusado e

Concluído).

“C” - Detalhe da Agenda - Apresenta os detalhes do agendamento, permitindo

o cancelamento diretamente por esta tela.

“D” - Avaliar Atendimento - Exibido assim que o atendimento agendado for

dado como Concluído pelo estabelecimento;

54

Figura 14 - Categorias de serviços


“A” - Todas as Categorias: Lista todas as categorias inseridas no sistema

até o momento.

“B” - Sub Categorias: Lista todas as subcategorias presentes na categoria

principal.

A solicitação de agendamento inicia-se selecionar o estabelecimento na tela

inicial, redirecionando o usuário para o perfil do mesmo.


Figura 15 - Solicitação de Agendamento

55

“A” - Perfil - Exibido ao selecionar o estabelecimento na tela inicial, concentra

todas as informações cadastrais inseridas pelo estabelecimento em sua

configuração;

“B” - Serviços - Concentra todos os serviços selecionados pelo

estabelecimento, assim como seus valores e tempo médio de duração do

atendimento;

“C” - Funcionário - Concentra os funcionários destinados ao serviço

selecionado pelo cliente, para que seja possível escolher o funcionário que

realizará o atendimento;

“D” - Horário - Apresenta os horários para agendamento no estabelecimento

em um intervalo de 30 minutos entre o horário de funcionamento inicial e final.

Após selecionar o horário, o usuário será verificado, solicitando login para

confirmar o pedido de agendamento, sendo possível também redefinir a senha de

acesso por meio desta tela


Figura 16 - Login e redefinição de senha

56

6 CONCLUSÃO

Neste projeto, se desenvolveu um produto de software focado em auxiliar no

gerenciamento e divulgação de estabelecimentos de pequeno e médio porte na área

da beleza, utilizando o framework IONIC juntamente com a plataforma Firebase

devido ao custo da estrutura do ambiente de desenvolvimento para implementação

ser inferior, produção e implementação inicial das aplicações para testes.

Testes estes que serão feitos em estabelecimentos convidados nos municípios

de Belém e Ananindeua para avaliação do desempenho geral da aplicação, e

refinamento de funcionalidades, uma vez que a aplicação será entregue em paralelo

com a conclusão do primeiro ciclo da espiral do modelo de processos utilizado,

gerando uma aplicação em estado beta.

Pode-se concluir por meio deste trabalho que aplicações híbridas podem

através da mesma codificação, serem portadas para diferentes plataformas de modo

a permitir que equipes pequenas possam desenvolver soluções adaptadas a múltiplas

plataformas além de favorecer a implantação destas soluções em estabelecimentos

de pequeno e médio porte visto, ocasionando em ferramentas mais úteis para

negócios ou indivíduos com poder aquisitivo limitado se comparada a outras

ferramentas disponíveis no mesmo nicho.

Como a aplicação possui fins lucrativos, o código fonte da mesma não será

disponibilizado em nenhum repositório público, Além disso, pretende-se publicar a

aplicação nas lojas oficiais das plataformas Android e iOS no futuro, dando

continuidade no desenvolvimento da aplicação melhorando-a e acrescentando novas

funcionalidades.

6.1 Dificuldades Encontradas

Uma das principais dificuldades encontradas durante o processo de

desenvolvimento ocorreu durante a estruturação da base de dados da aplicação em

noSQL, devido a nenhuma disciplina oferecida no curso de ciências da computação

abordar esta estrutura de banco de dados de forma direta, somente introduzindo-a

como um dos gêneros de bancos de dados existentes, apesar de atualmente ser

considerada uma tecnologia de grande tendência na criação de bases de dados para

aplicações e serviços em uma perspectiva mundial.

57

Junto a isso, encarou-se a falta de incentivo do curso em estimular as

habilidades de gestão de projetos de software durante o período em que os autores

deste projeto o estiveram cursando.

Durante o processo de desenvolvimento, a delimitação de funções dos

membros deve ser bem delimitada mas igualmente flexível, para que o fluxo de

desenvolvimento não se interrompa em casos de imprevistos ou ausências dos

membros.

6.2 Trabalhos Futuros

Devido a expertise obtida durante o processo de desenvolvimento somada ao

aprendizado prospectado durante a evolução do desenvolvimento da aplicação após

a entrega, se obterá a necessidade de expandir o foco e a equipe de desenvolvimento

para outros mercados estimulando a criação de uma plataforma, para que a solução

abrangida após a finalização do desenvolvimento das aplicações de título HoraVIP,

seja aplicada para mais estabelecimentos em outras áreas onde se observar

interações cliente estabelecimento semelhantes às visualizadas no desenvolvimento

deste projeto.

Juntamente a esta projeção, será incorporado a plataforma um módulo de

análise de banco de dados, baseado em inteligência computacional, que entre outras

contribuições, permitirão aos adeptos das plataformas de título HoraVIP, observar

padrões de comportamento e receber orientações e fornecer alternativas autônomas

de tomada de decisões, divulgação de conteúdo, alterações do mercado e serviços,

entre outros.

58

REFERÊNCIAS

ADOBE, Adobe XD. Disponível em Documentação: <https://helpx.adobe.com

/br/xd/user-guide.html> Acesso em: 24 Nov. 2018.

Amazon, W. S. (2018). O que é um banco de dados gráfico?. Disponível em aws:

<https://aws.amazon.com/pt/nosql/graph/> Acesso em 14 de Out. de 2018.

Amazon, W. S. (2018). O que é um banco de dados em colunas?. Disponível em

Documetação: <https://aws.amazon.com/pt/nosql/columnar/>. Acesso em, 15 de 09

de 2018.

Amazon, W. S. O que é NoSQL?, disponível em aws: <https://aws.amazon.com

/pt/nosql/key-value/>. Acesso em 12 de Out. de 2018.

Amazon, W. S. O que é um banco de dados de documentos?, disponível em aws:

<https://aws.amazon.com/pt/nosql/document/>. Acesso em 08 de Out. de 2018.

Angular, Documentation. Disponível em documentação: <https://angular.io

/guide/architecture>. Acesso em: 16 Set. 2018.

Araújo, K., & Alves, L.; Sistematização de tecnologias para o desenvolvimento. In:

WORKSHOP DE GESTÃO, TECNOLOGIA INDUSTRIAL E MODELAGEM

COMPUTACIONAL, 2., 2016 , Anais... Bahia: CIMATEC, 2016, p. 125-126.

Hassan, Adobe XD now available to Windows 10 users in beta, Ms Power User.

Disponível em: <https://mspoweruser.com/adobe-xd-now-available-windows-10-

users-beta/ >. Acesso em: 15 Nov. 2018.

HTML, Documentation. Disponível em Documentação: <https://www.w3.org/ html/>.

Acesso em: 15 Out. 2018.

IONIC, Ionic Framework 4 is almost here. disponível em Documentação: <https:

//ionicframework.com/docs/>. Acesso em 10 de nov. de 2018.

Loss, F. S. e Ponte, M. S. (2015), Desenvolvimento de um aplicativo web para

salões de beleza utilizando ruby on rails, Trabalho de conclusão de curso

(Graduação) – Universidade Tecnologica Federal do Paraná, Pato Branco, 2015.

59

Lunardi, G. L.; Dolci, P. C.; Maçada, A. C. G. Adoção de tecnologia de informação e

seu impacto no desempenho organizacional: Um estudo organizado com micro e

pequenas empresas. Revista de Administração, São Paulo, v. 45, 2010.

Oliveira, D.; Carvalho, R. J.; Rosa, A. C. M. Clima Organizacional: fator de satisfação

no trabalho e resultados eficazes na organização. In: SIMPÓSIO DE EXCELENCIA

EM GESTÃO E TECNOLOGIA, 2012, Anais... Rio de Janeiro: SEGeT, 2012, p 2-13.

Pressman, R. S. Engenharia de Software Uma Abordagem Profissional: 7. ed.

Porto Alegre: AMGH Editora Ltda, 2011.

Prezotto, E.D. e Boniati, B. B. Estudo de Frameworks Multiplatarma Para

Desenvolvimento de Aplicação Mobile Híbridos. In: ENCONTRO ANUAL DE

TECNOLOGIA DA INFORMAÇÃO E SEMANA ACADEMICA DE TECNICNOLOGIA

DA INFORMAÇÃO, 2014, Anais... Rio Grande do Sul: EATI , 2014.

Santos, S. S. Aplicativo para agendamento de horário em salões de beleza.

Especialização digital (Monografia) - Universidade Federal do Paraná, Curitiba,

(2016).

SASS. Sass (Syntactically Awesome StyleSheets)., disponível em Documentação:

<https://sass-lang.com/documentation/file.SASS_REFERENCE .html>. Acesso em

23 de Nov. de 2018.

Sommervile, Ian Engenharia de Software; tradução Ivan Bosnic e Kalinka G. de O.

Gonçalves ; revisão técnica Kechi Hirama: 9. ed. São Paulo: Pearson, 2011.

Souza, J. A. NoSQL2: Administrando banco de dados NoSQL com a linguagem

SQL. 2016, 106f . Dissertação (Mestrado em Informática) – Universidade de Brasília,

2016.

REFERÊNCIAS DAS APLICAÇÕES

Aplicativo Salão99: https://www.salao99.com.br/

Aplicativo Beauty Date: https://beautydate.com.br/programa-salao-de-beleza

Aplicativo Carreira: https://www.carreirabeauty.com/

https://www.salao99.com.br/

https://beautydate.com.br/programa-salao-de-beleza?utm_source=google&utm_medium=cpc&utm_term=Branding%20-%20Exata&utm_campaign=google%7Ccpc%7CBranding%20-%20Exata%7CSCH_B2BC_Beauty%20Date_Branding&gclid=Cj0KCQiAxZPgBRCmARIsAOrTHSbz5awBkXADZRd2ZcMy_x0wfRk-G41Hr4qiZNfsf6hVv8MBYx_D2PsaAlwTEALw_wcB

https://www.carreirabeauty.com/

60

APÊNDICE

Aplicações de Mercado

Dada a necessidade de se estabelecer como o mercado de aplicações voltadas

a estabelecimentos na área da beleza se comporta, foram verificadas algumas

aplicações com o intuito de se estabelecer suas propostas e características.

Carreira Beauty

A aplicação Carreira Beauty, foca na divulgação e na autopromoção de

profissionais na área da beleza que buscam criar um perfil profissional, onde a

associação do usuário se dá por meio de formulários dispostos pela aplicação ou

vinculando perfis sociais. Estendendo a aplicação quando divulga-se espaços para

serem alugados ou que possam realizar Coworking (Ambiente colaborativo). A

aplicação atua de forma semelhante a aplicativos de centralização de mão de obra

especializada (workana), disponibilizando aos usuários meios de se cadastrar em

oportunidades na área, oferecendo também, recursos de “catálogo de ideias” aos

profissionais cadastrados permitindo a autopromoção das criações dos mesmos.

O Carreira Beauty disponibiliza o menu principal com cinco itens, são eles:

Fonte: Prints de telas da aplicação

● “A” - Explorar: Possui cinco tipos de acessos divididos em Submenus,

podendo ser explorados de diferentes formas:

○ Empregos: Disponibilizam serviços voltados para área da beleza;

○ Profissionais: Mostra profissionais na área da beleza e seus

respectivos valores;

Figura 17 - Imagem Carreira Beauty

61

○ Blog: Item que possui dicas e trabalhos relacionados a beleza;

○ Cursos: Submenu responsável por divulgar cursos voltados para

área da beleza;

○ Classificados: Item relacionado a divulgação de espaços para

serem alugados ou que apliquem conceitos de Coworking.

● “B” - Perguntas: Item responsável por centralizar todas as dúvidas dos

usuários, como perguntas e respostas. Funcionando como um Fórum.

● “C” - Fotos: Submenu que divulga trabalhos realizados por usuários,

com a intenção de alcançar futuros clientes através de marketing.

● “D” - Notificações: Item responsável por centralizar diálogos entre

usuários.

● “E” - Perfil: Item responsável por centralizar todas as informações do

usuário, tanto as de nível pessoal quanto as de cunho profissional.

Salão99

Salão99, é um aplicativo voltado para salões de beleza, ele possui uma

proposta semelhante à abordada neste projeto, entretanto, o software não tem a

funcionalidade de agendar horário por parte do cliente, assim centralizando as

operações da aplicação para o salão ou para o prestador de serviços.

A aplicação Salão99, possui um menu fragmentado em 7 itens, são eles:


● “A”- Home: Item inicial onde são mostrados informações como

mensagens que auxiliam o gestor na hora de realizar os processos

Figura 18 - Imagem Salão99

62

relacionados aos agendamentos, finanças e outras mensagens

relacionadas ao sistema.

● “B”- Agendamento: Cadastram funcionários com áreas específicas,

que quando cadastrado o gestor da aplicação podem vincular clientes

que desejam ser atendimento ao mesmo, podendo ser vinculado mais

de um funcionário por cliente e definindo o horário inicial e a duração do

serviço.

● “C”- Comandas: Vincula-se tudo que o cliente utilizar no

estabelecimento, tanto comestível como utensílios a materiais são

vinculados a um atendente.

● “D”- Fluxo de Caixa: Informa com quanto a o estabelecimento inicia o

caixa diariamente e todas as informações atualizadas referentes ao

mesmo pode ser encontradas neste item.

● “E”- Cliente: Menu responsável por realizar todos os procedimentos que envolvam o cadastro informacional do cliente e a vinculação do mesmo aos serviços disponíveis.


● “F”- Cadastro de Despesas: Disponibiliza a vinculação de notas

relacionadas às despesas do estabelecimento, onde essas informações

ficam vinculadas no menu ” financeiro”.

● “G”- Financeiro: Disponibilizados gráficos e estatísticas bem definidas

e legíveis em relação a leitura das informações.

Figura 19 - Imagem Salão99

63

Beauty Date

O Beauty Date, disponibiliza uma proposta aplicada em sua plataforma

semelhante a utilizada neste projeto, a exemplo do sistema de marcação de horários

e da ferramenta de buscas de salões através de geolocalização. Entretanto, a gestão

da aplicação se dá apenas pela aplicação desenvolvida para navegadores.

A versão para SmartPhones do Beauty Date, possui 11 itens, sendo que três

destes ficam dispostos em destaques na “home” da aplicação e as outras compõem

o menu do mesmo, são eles:

Espaço home da aplicação, divide-se em:


● Categoria: Informa as categorias por serviço que os estabelecimentos

possuem;

● Destaques: Mostra os serviços/salões que estão sendo acionado com

mais frequência e os melhores colocados no conceitos dos clientes;

● Favoritos: Apresenta todos os serviços/salões salvos pelo cliente ou os

que ele mais frequenta.

Figura 20 - Imagem BeautyDate

64

O menu do da aplicação se apresenta da seguinte forma:


● “D”- Agendamentos: Apresenta todos os agendamentos que foram

realizados pelo cliente.

● “E”- Notificações: Mostra todas as novidades dos seus serviços

favoritos e informações sobre o seu agendamento.

● “F”- Pagamentos: Item responsável por realizar a vinculação do cartão

paypal como forma de pagamento.

● “G”- Perfil: Apresenta todos os dados relacionados ao cliente.

● “H”- Indique o app: Realiza o envio de mensagem de marketing da

aplicação, podendo ser vinculada a qualquer mídia social, e-mail,

mensagem texto, WhatSapp, entre outras.


Figura 21 - Imagem Beauty Date


65

● “I”- Sobre: Tem a função informativa quanto a parte das informações

relacionadas a aplicação que são disponibilizadas ao usuário.

● “J”- Suporte: O suporte enviamos informações de erros ou de ajuda

sobre a aplicação.

● “L”- Sair: Responsável por finalizar a sessão do aplicativo.

A aplicação web tem a funcionalidade de gerenciar todos os processos de um

estabelecimento, como também de gerir todos os processos relacionados ao cliente,

estando dividido em um menu que possui sete itens principais e três de suporte. Para

realizar o cadastro na versão web ou versão mobile, o sistema utiliza o mesmo padrão

de cadastro, sendo que, uma vez cadastrado o usuário pode utilizar as duas versões

mencionadas anteriormente, pois as informações persistidas em cada, são tratadas

de forma diferente. Sendo assim o sistema fica disposto da seguinte forma:


● Agenda: É um dos itens do menu que fazem parte dos sete principais,

nele aparecem todas as informações relacionadas aos agendamentos

que os clientes realizam;

● Frente de Caixa: Informa o valor financeiro que o caixa do

estabelecimento abre o caixa;

● Cliente: Possibilita vincular um cliente manualmente sem que o mesmo

precise realizar o cadastro através do aplicativos;

● Profissionais: Possibilita cadastrar todos profissionais que trabalham

no estabelecimento;


66

● Serviço e habilidade: Possibilita vincular os profissionais cadastrados

de acordo com a solicitação do cliente, sendo que, o funcionário é

associado diretamente na aplicação e só depois as informações

relacionadas ao trabalho prestado é apresentados no gráfico;

● Estoque: Permite todos os produtos do estabelecimento para que haja

um melhor controle sobre os gastos;

● Fornecedor: Possibilita cadastro de fornecedores, e sinaliza ao gestor

para que entre em contato com com os fornecedores quando há

necessidade de compra de suprimentos;

● Relatório: Disponibiliza relatórios, sendo possível realizar filtros que

proporcionam informações mais detalhadas.

Os últimos três itens que finalizam o menu, se dão da seguinte forma:

● Configuração gerais: Posibilita atualização dados complementares do

estabelecimento, como: CNPJ, nome fantasia, forma de pagamento

dentre outros.

● Controle de acesso: Responsável por conceder determinados níveis de

permissões de acesso para alguns funcionários;

● Ajuda: Proporciona ao usuário informações do sistema, como também

vídeos instrucionais que auxiliam no entendimento do sistema.

Com base nas características recolhidas sobre cada aplicação, foi possível

determinar em que direção o desenvolvimento de aplicações voltadas ao mercado da

beleza segue, resultando em uma comparação efetuada no capítulo 2 do projeto das

características visualizadas nas aplicações disponíveis no mercado com as propostas

oferecidas pela plataforma HoraVIP.

FACULDADE PAN AMAZÔNICA ALISON FELIPE AVELINO...

Documents

Transcript of FACULDADE PAN AMAZÔNICA ALISON FELIPE AVELINO...