Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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
ALISON FELIPE AVELINO MENDES
ISAQUE DIAS BRITO
ISRAEL EMANUEL QUEIROZ VALENTE
HORAVIP: UMA PLATAFORMA PARA GESTÃO DE ESTABELECIMENTOS DE BELEZA
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
ALISON FELIPE AVELINO MENDES
ISAQUE DIAS BRITO
ISRAEL EMANUEL QUEIROZ VALENTE
HORAVIP: UMA PLATAFORMA PARA GESTÃO DE ESTABELECIMENTOS DE BELEZA
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
Figura 22 - Imagem Beauty Date .............................................................................. 64
Figura 23 - Imagem Beauty Date .............................................................................. 65
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;
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.
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
COD Descrição Observação Prioridade
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
COD Descrição Observação Prioridade
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
COD Descrição Observação Prioridade
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
Fonte: HoraVIP - Estabelecimentos
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).
Fonte: HoraVIP - Estabelecimentos
“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.
Fonte: HoraVIP - Estabelecimentos
“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”.
Fonte: HoraVIP - Estabelecimentos
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”.
Fonte: HoraVIP - Estabelecimentos
“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
Fonte: HoraVIP - Estabelecimentos
“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
Fonte: HoraVIP - Clientes
“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.
Fonte: HoraVIP - Clientes
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
Fonte: HoraVIP - Clientes
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/
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:
Fonte: Prints de telas da aplicação
● “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.
Fonte: Prints de telas da aplicação
● “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:
Fonte: Prints de telas da aplicação
● 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:
Fonte: Prints de telas da aplicação
● “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.
Fonte: Prints de telas da aplicação
Figura 21 - Imagem Beauty Date
Figura 22 - 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:
Fonte: Prints de telas da aplicação
● 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;
Figura 23 - Imagem Beauty Date
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.