Matheus Medeiros Gentil e Sarah Izabel Pfaffenzeller Esquivel
SISTEMA WEB PARA CONTRATAÇÃO DE SERVIÇOS
Florianópolis 2019
SISTEMA WEB PARA CONTRATAÇÃO DE SERVIÇOS
Proposta de Trabalho de Conclusão de Curso submetido ao curso de Sis-temas de Informação para a obtençăo do Grau de Bacharel em Sistemas de Informação.
Orientador: Prof. Leandro José Ko-mosinski
Florianópolis 2019
Ao longo dos anos, um crescente número de aplicações web e mobile surgiram para solucionar problemas do cotidiano das pessoas. Plata-formas de sucesso como Uber, iFood, Mercado Livre, entre outras, são utilizadas todos os dias por usuários do mundo inteiro para facilitar as atividades cotidianas. Tendo isto em vista, observou-se o surgimento de plataformas que permitem a contratação de serviços, como Parafuzo, GetNinjas, Freelancer, Bicos, para citar algumas. Porém, algumas des-sas plataformas de contratação de serviço citadas não atendem a alguns requisitos específicos como: transparência no valor que será cobrado do cliente, confiança no prestador de serviço e garantia da qualidade do trabalho a ser realizado. Tendo isso em vista, este trabalho relata o desenvolvimento de uma aplicação web para contratação de serviços online, em que é possível encontrar prestadores de serviço, visualizar as avaliações e outras informações relevantes sobre o prestador, e contratar o serviço pela plataforma, garantindo assim confiabilidade, segurança e transparência ao contratar um serviço.
Palavras-chave: Contratação de Serviços. Aplicação Web. Aplicação Mobile.
Figura 1 Business Model Canvas - Sebrae (2018) . . . 16
Figura 2 Casos de Uso . . . 26
Figura 3 Arquitetura do Sistema . . . 34
Figura 4 Documentos Incorporados - Documentation (2018) . . . 39
Figura 5 Modelagem Lógica dos Documentos . . . 40
Figura 6 Componentes do Frontend . . . 42
Figura 7 Tela principal . . . 45
Figura 8 Diagrama de Atividades: Cadastro de Usuário . . . 46
Figura 9 Tela de Cadastro do Usuário . . . 46
Figura 10 Diagrama de Atividades: Login do Usuário . . . 47
Figura 11 Tela de Login do Usuário . . . 47
Figura 12 Diagrama de Atividades: Upgrade de conta . . . 48
Figura 13 Tela de Upgrade de conta . . . 48
Figura 14 Diagrama de Atividades: Editar/Adicionar dados da conta . . . 49
Figura 15 Tela de Editar/Adicionar dados da conta . . . 50
Figura 16 Diagrama de Atividades: Listagem de Serviços . . . 51
Figura 17 Tela de Listagem de Serviços . . . 51
Figura 18 Diagrama de Atividades: Cadastro de um Serviço . . . 52
Figura 19 Tela de Cadastro de um Serviço . . . 52
Figura 20 Diagrama de Atividades: Busca de Serviço e Prestador 53 Figura 21 Tela de Busca de Serviço e Prestador . . . 53
Figura 22 Diagrama de Atividades: Contratar Prestador de serviço 54 Figura 23 Tela de Contratação de Prestador de serviço . . . 54
Tabela 1 Análise plataformas existentes . . . 23
Tabela 2 Tabela de Product Backlog. . . 29
Tabela 3 Tabela de Sprints Backlogs. . . 32
1 INTRODUÇĂO . . . 6 1.1 OBJETIVO GERAL . . . 7 1.2 METODOLOGIA . . . 7 1.3 JUSTIFICATIVA . . . 7 2 FUNDAMENTAÇÃO TEÓRICA . . . 9 2.1 APLICATIVO WEB . . . 9
2.2 BANCO DE DADOS NOSQL . . . 9
2.3 PROGRESSIVE WEB APPS . . . 11
2.4 SCRUM . . . 13
2.5 CANVAS . . . 15
3 DESENVOLVIMENTO . . . 18
3.1 ANÁLISE DO MERCADO DE SERVIÇOS . . . 19
3.2 ANÁLISE DAS SOLUÇÕES EXISTENTES . . . 21
3.2.1 Critérios . . . 21 3.2.2 Soluções existentes . . . 21 3.2.3 Resultado . . . 23 3.3 SOLUÇÃO PROPOSTA . . . 23 3.3.1 Modelo de Negócio . . . 24 3.3.2 Levantamento de Requisitos . . . 25 3.4 PRODUCT BACKLOG . . . 28 3.5 SPRINTS BACKLOGS . . . 32 3.6 ARQUITETURA DO SISTEMA . . . 33 3.6.1 Estrutura do Sistema . . . 35 3.6.1.1 Estrutura do Front-end . . . 35 3.6.1.2 Estrutura do Back-end . . . 37 3.6.2 Entidades do Sistema . . . 38 3.6.2.1 Entidades do Back-end . . . 38 3.6.2.2 Entidades do Front-end . . . 41 3.6.3 Tecnologias Utilizadas . . . 42
3.6.3.1 Tecnologias utilizadas no Backend . . . 42
3.6.3.2 Tecnologias utilizadas no Frontend . . . 44
3.7 IMPLEMENTAÇÃO . . . 45
3.7.1 Cadastro de Usuário . . . 45
3.7.2 Login de Usuário . . . 46
3.7.3 Upgrade de conta . . . 47
3.7.4 Visualizar e modificar dados da conta . . . 49
3.7.8 Contratar um Prestador de Serviço . . . 54
4 RESULTADOS OBTIDOS . . . 55
5 CONCLUSÃO . . . 59
REFERÊNCIAS . . . 60
1 INTRODUÇĂO
No momento atual em que se encontra a sociedade, o uso da tecnologia se faz cada vez mais presente no cotidiano coletivo, o que tem levado à criação de sistemas de informação que facilitam diversas atividades rotineiras. Segundo (URSSI, 2015), esses sistemas tornaram-se ferramentas que passam a tornaram-ser utilizadas com muita frequência por diversos tipos de usuários, o que, por muitas vezes, as torna uma opor-tunidade de negócios para empreendedores regionais.
De acordo com Lemos (2005), estas oportunidades de negócios atuam de forma a facilitar os processos do cotidiano, ganhando impor-tância nos dias atuais devido ao fato de agilizar parte da rotina de seus usuários, tornando mais cômodas e práticas atividades rotineiras como realizar compras, pedir comida por telefone, contratar serviços, entre outros.
Contratar profissionais capacitados e de confiança apresenta obs-táculos como o alto custo de contratação, falta de tempo para conhecer candidatos, falta de recomendações por outras pessoas que utilizaram o serviço e falta de segurança.
Contudo, este cenário pode mudar quando o indivíduo tem a possibilidade de utilizar um aplicativo de prestação de serviços. Ao ob-servar os aplicativos comumente utilizados, pode-se concluir que muitos serviços como, entrega de alimentos e serviços bancários, já são execu-tados por meio de plataformas digitais. Mesmo assim, muitas pessoas ainda se sentem inseguras em usar a tecnologia para contratar jardi-neiros, faxineiras ou pedreiros, por exemplo. Essa insegurança se dá principalmente pelo fato de que as pessoas não se sentem seguras e confiantes o suficiente para contratar serviços online.
As soluções digitais que se dispoem a atender esse nicho de mer-cado, portanto, precisam transmitir mais segurança e confiança para seus clientes. Neste contexto, foi constatada a ausência de um sistema web e aplicativos para smartphones para contratação de serviços que possua garantia da qualidade do serviço que seja realizado, transpa-rência (no sentido de saber quem será contratado), além da já citada segurança.
Dessa forma, este trabalho relata o desenvolvimento de uma apli-cação web para contratação de serviços, por meio do qual é possível encontrar prestadores de serviço, visualizar as avaliações de usuários e outras informações relevantes sobre o prestador, além de contratar o serviço pela plataforma, garantindo assim uma maior confiabilidade,
segurança e transparência ao contratar um serviço.
1.1 OBJETIVO GERAL
Desenvolvimento de um MVP (Minimum Viable Product ) de uma aplicação web PWA (Progressive Web Apps), que permita a tratação de serviços realizados de forma autônoma, transparente e con-fiável.
1.2 METODOLOGIA
Para que o objetivo fosse alcançado, foi adotada a seguinte me-todologia:
• Realizar uma análise do mercado de serviços;
• Realizar uma avaliação das plataformas similares a fim de identi-ficar oportunidades de melhoria;
• Criar um modelo de negócios que se mostre eficaz frente aos con-correntes, conseguindo remover as falhas encontradas nas avalia-ções;
• Análise, modelagem e construção do sistema de forma incremen-tal, utilizando uma abordagem ágil adaptada com base no SCRUM; • Publicação do sistema e configuração dos servidores que manterão
o sistema.
1.3 JUSTIFICATIVA
Com a popularidade da internet, aplicações web e mobile, tornaram-se parte da rotina das pessoas, auxiliando nas resoluções de problemas do cotidiano.
Segundo Holding (2016) quando se trata de procurar informa-ções, acessar arquivos ou se comunicar, 64% dos brasileiros usam apli-cativos móveis.
Junto a isso, surgem as plataformas que permitem a contratação de serviços online, garantindo o conforto e comodidade de requisitar um serviço por um aplicativo ou site.
Porém, há dificuldade em encontrar uma plataforma que ofereça a contratação de serviços online de forma que a confiabilidade, empatia, segurança e transparência sejam garantidas.
No mercado competitivo atual, os prestadores de serviços devem repensar constantemente a melhor maneira de oferecer e aprimorar os serviços prestados, pois o melhor de hoje corre o risco de não ser bom o bastante amanhã.
No cenário empresarial, as empresas estão tendo que se adaptar a um novo panorama, no qual, o serviço de qualidade é o principal dife-rencial em um mercado saturado. Os consumidores, que hoje possuem expectativas elevadas, passaram a conduzir a economia.
Um estudo conduzido pela Accenture revelou que, somente em 2015, as empresas brasileiras perderam cerca de 217 bilhões de dólares como consequência de clientes que migraram para a concorrência in-satisfeitos com os serviços prestados. O levantamento destacou ainda que, em função do mau atendimento, 86% dos consumidores locais pas-saram a comprar de outros fornecedores – uma perda que poderia ter sido evitada pelas companhias em 92% dos casos (TADEU, 2017).
2 FUNDAMENTAÇÃO TEÓRICA
Com o objetivo de tornar compreensível o conjunto de tecnolo-gias e conceitos abordados no desenvolvimento deste trabalho, serão apresentados neste capítulo os conceitos fundamentais para compreen-são do desenvolvimento do trabalho realizado.
2.1 APLICATIVO WEB
Para Nations (2018), um aplicativo da web é qualquer programa de computador que executa uma função específica usando um navega-dor da web com o seu cliente. O aplicativo pode ser tão simples quanto um quadro de mensagens ou um formulário de contato em um site ou tão complexo quanto um processador de texto ou um aplicativo de jogos para vários jogadores que alguém baixa por telefone.
Aplicações web são sistemas que executam em ambientes distri-buídos, onde as partes do sistema podem executar em máquinas dife-rentes comunicando-se via protocolo HTTP ou HTTPS (Protocolo Se-guro). A interface com o usuário é realizada pelos navegadores, como o Internet Explorer, Firefox entre outros. Na prática, exemplos comuns de aplicações WEB, são sites de comércio eletrônico, portais dinâmicos e buscadores (como o Google).
2.2 BANCO DE DADOS NOSQL
Segundo (HEUSER, 1998), um modelo de banco de dados é uma descrição dos tipos de informações que estão armazenadas em um banco de dados. Um dos modelos de bancos de dados amplamente usado até os dias de hoje é o modelo relacional. Porém, constatou-se que os modelos de bancos de dados relacional apresentam limitações ao trabalhar com grandes volumes de dados. Este ambiente instigou o surgimento de outros tipos de modelos de banco de dados, para que possam suprir essa necessidade.
Neste contexto, surge uma nova geração de banco de dados que vem ganhando bastante força e espaço, conhecidos como NoSQL (Not Only SQL). Este modelo tem como proposta atender e gerenciar os grandes volumes de dados, buscando um alto desempenho e disponibi-lidade.
Segundo Marília (2012), os bancos de dados NoSQL apresentam as seguintes principais características:
• Escalabilidade Horizontal: Na medida em que o volume de dados cresce, aumenta-se a necessidade de escalabilidade e melhoria do desempenho. Dentre todas as possibilidades para esta solução, a escalabilidade horizontal se torna a mais viável, porém requer diversas threads ou que processos de um tarefa sejam criadas e distribuídas. Dessa forma, o uso de um banco de dados relaci-onal poderia ser muito complexo, pois não escalaria facilmente. O NoSQL tem uma certa vantagem que seria a ausência de blo-queios, o que permite a escalabilidade horizontal com uma maior facilidade e eficiência.
• Ausência de esquema (Schema-free) ou esquema flexível: Ausên-cia parAusên-cial ou total de esquema que define a estrutura de dados. É justamente essa ausência de esquema que facilita uma alta es-calabilidade e alta disponibilidade, mas em contrapartida não há a garantia de integridade dos dados, fato este que não ocorre no Modelo Relacional.
• Suporte nativo a replicação: Esta é uma outra forma de prover a escalabilidade, pois no momento que permitimos a replicação de forma nativa, o tempo gasto para recuperar informações é reduzido.
• API simples para acessar o banco de dados: Em banco de da-dos NoSQL, o foco não está no armazenamento da-dos dada-dos e sim como recuperar estes dados de forma eficiente. Com isso, é fun-damental APIs desenvolvidas para facilitar o acesso às devidas informações para que se possa usar o banco de dados de forma rápida e eficiente.
• Consistência eventual: Outra característica particular de bancos NoSQL é que nem sempre a consistência dos dados é mantida. Esta característica tem embasamento no teorema CAP (Consis-tency, Availability e Partition tolerance) que afirma que em um dado momento só é possível garantir duas destas três proprie-dades, que seriam Consistência, Disponibilidade e Tolerância à partição. No mundo real, normalmente estas duas últimas são privilegiadas. Como consequência disto, as propriedades do ACID (Atomicidade, Consistência, Isolamento e Durabilidade) não são respeitadas simultaneamente; ao contrário temos outro conjunto
de projetos denominado BASE (Basicamente disponível, Estado leve e consistente eventualmente). Ou seja, é necessário haver um planejamento para que o sistema possa tolerar inconsistên-cias temporárias com o objetivo de priorizar a disponibilidade.
O modelo de banco de dados NoSQL que utilizamos neste tra-balho foi o Banco de Dados Orientado a Documento, que armazena co-leções de documentos. Um documento é um objeto identificador único e um conjunto de campos que podem ser strings, listas ou documen-tos aninhados. Neste modelo, temos um agrupamento de documendocumen-tos sendo que em cada um destes documentos temos um conjunto de cam-pos e o valor deste campo. No modelo orientado a documento, temos também a ausência de esquema pré-definido (Schema Free). Isto signi-fica que é possível que ocorra atualizações no documento, com a adição de novos campos, por exemplo, sem afetar adversamente outros docu-mentos.
2.3 PROGRESSIVE WEB APPS
Progressive Web App (PWA) é um termo usado para denotar uma nova metodologia de desenvolvimento de software. Ao contrário dos tradicionais aplicativos, um Progressive Web App pode ser visto como uma evolução híbrida entre as páginas web regulares e um apli-cativo móvel. Segundo Wikipedia (2015), o termo foi cunhado em 2015, pelo designer Frances Berriman e o engenheiro do Google chrome Alex Russell, que utilizaram esse termo para descrever as novas funcionali-dades suportadas pelo navegador.
Progressive Web Apps são úteis para os usuários desde a primeira visita em uma guia de navegador sem exigir instalações. Conforme o usuário desenvolve uma relação com o aplicativo ao longo do tempo, ele se torna cada vez mais eficaz. Ele é carregado com rapidez, mesmo em redes instáveis, envia notificações push relevantes, tem um ícone na tela inicial e é carregado como uma experiência de tela inteira de alto nível (LEPAGE, 2018).
Para LePage (2018), um Progressive Web App é:
• Progressivo - Funciona para qualquer usuário, independentemente do navegador escolhido, pois é criado com aprimoramento pro-gressivo como princípio fundamental.
• Responsivo - Se adequa a qualquer formato: desktop, celular, tablet ou o que for inventado a seguir.
• Independente de conectividade - Aprimorado com service workers para trabalhar offline ou em redes de baixa qualidade. Service workers são arquivos JavaScript executados separadamente do en-cadeamento principal do navegador, interceptando solicitações de rede, armazenando em cache ou recuperando recursos do cache e entregando mensagens.
• Semelhante a aplicativos - Parece com aplicativos para os usuá-rios, com interações e navegação de estilo de aplicativos, pois é compilado no modelo de shell de aplicativo.
• Atual - Sempre atualizado graças ao processo de atualização do service worker.
• Seguro - Fornecido via HTTPS para evitar invasões e garantir que o conteúdo não seja adulterado.
• Descobrível - Pode ser identificado como "aplicativo"graças aos manifestos W3C e ao escopo de registro do service worker, que permitem que os mecanismos de pesquisa os encontrem.
• Instalável - Permite que os usuários "guardem"os aplicativos mais úteis em suas telas iniciais sem precisar acessar uma loja de apli-cativos.
• Linkável - Compartilhável facilmente por URL, não requer insta-lação complexa.
Segundo Wikipedia (2015), desde de 2015 a Google vem man-tendo atualizações no desenvolvimento de novas funcionalidades para os Progressive Web Apps em seu navegador Google Chrome.
Em 2017 os navegadores Mozilla Firefox versão 44 começaram a utilizar service workers como forma de cache, e adicionaram suporte a push notifications e, a partir da versão 58, foi adicionado suporte ao Web App Manifesto, possibilitando a instalação de uma PWA, pelo navegador da Mozilla Foundation.
Em 2018, na versão 46 do navegador Safari Preview da Apple também foi adicionado suporte a service workers por padrão.
Em outubro de 2018 foi adicionado no Google Chrome suporte à instalação de uma PWA numa versão desktop, sendo compatível nas seguintes versões de SO e navegador:
• Chrome OS (Chrome 67+) • Linux (Chrome 70+)
• Windows (Chrome 70+)
Para a versão Mac é esperado que esteja disponível na versão 72 do navegador Chrome.
Plataformas que hoje utilizam PWA:
• Spotify: https://open.spotify.com/browse/featured?pwa=1 • Google Drive: https://drive.google.com/
• G1: https://g1.globo.com/
• globoesporte: https://globoesporte.globo.com/
Todas essas plataformas foram acessadas no dia 15 de novembro de 2018.
2.4 SCRUM
O Scrum é um modelo ágil de processo que foi desenvolvido por Jeff Sutherland, Mike Beedle e Ken Schwaber no início da década de 1990 e segundo Sutherland e Schwaber (1995) baseia-se em cinco características principais: Flexibilidade dos resultados; Flexibilidade dos prazos; Times pequenos; Revisões frequentes e Colaboração;
De acordo com a pesquisa de (CARVALHO B. V. E MELLO, 2012), os benefícios comprovados da implantação do método Scrum no pro-cesso de desenvolvimento de software em uma equipe pequena foram: melhoria na comunicação e aumento da colaboração entre envolvidos no projeto; aumento da motivação da equipe; diminuição do tempo gasto para conclusão do projeto; diminuição dos riscos do projeto; diminuição dos custos de produção e aumento da produtividade da equipe.
O Scrum não requer ou fornece qualquer técnica ou método es-pecífico para a fase de desenvolvimento de software, apenas estabelece conjuntos de regras e práticas gerenciais que devem ser adotadas para o sucesso de um projeto. Seguindo os conceitos de (CARVALHO B. V. E MELLO, 2012), os tópicos a seguir descrevem o funcionamento e as práticas do Scrum:
• Product Owner : Este membro representa o cliente e define quais os requisitos e seus respectivos graus de importância e prioridade. Ele precisa conhecer muito bem as regras de negócio do cliente, de forma a solucionar dúvidas que o time possa ter em relação a funcionalidades do produto.
• Product Backlog: É considerada a prática responsável por arma-zenar, organizar e gerenciar os requisitos coletados, de acordo com (CHO, 2008). Tem a forma de uma lista de funcionalidades, ordenadas por prioridade, que provavelmente serão desenvolvidas durante o projeto.
• Daily Scrum: Uma reunião rápida entre os membros da equipe de desenvolvimento que ocorre diariamente, idealmente no mesmo horário, com um tempo definido, a fim de definir quais serão as tarefas realizadas no dia e saber os resultados das tarefas do dia anterior.
• Sprint : Considerada a principal prática do Scrum, é o período de tempo onde são implementados os itens de trabalho definidos no Product Backlog pela equipe Scrum, que normalmente dura de uma a quatro semanas.
• Sprint Backlog: A Sprint possui uma documentação associada, chamada de Sprint Backlog, uma lista de atividades a serem de-senvolvidas durante uma Sprint. A Sprint Backlog representa um subconjunto do Product Backlog e é definido durante a Reunião de Planejamento da Sprint.
• Reunião de Planejamento da Sprint: o Product Owner junto com o time de desenvolvimento se reunem com o objetivo de deter-minar quais os subconjuntos de itens do Product Backlog mais importanes para construir na próxima Sprint.
• Reunião de Revisão da Sprint: Após cada Sprint é feito uma Reunião de Revisão da Sprint e nela são discutidos erros, acertos e lições aprendidas na Sprint.
• Scrum Master : Papel desempenhado por um desenvolvedor da equipe, que tem como responsabilidade fazer com que o processo do Scrum aconteça e tentar resolver impedimentos que possam estar comprometendo o trabalho dos outros desenvolvedores.
No início de cada Sprint, as responsabilidades são distribuídas. Os desenvolvedores discutem os padrões que serão adotados e as ati-vidades de análise, codificações e testes começam, sendo que no final de cada Sprint, uma versão funcional do produto deverá ser apresen-tada ao cliente para obter feedbacks. Quaisquer defeitos encontrados são adicionados ao Product Backlog.
Neste trabalho, um dos desafios foi adaptar a metodologia Scrum, de modo a refletir a realidade do projeto: um trabalho de conclusão de curso, desenvolvido por duas pessoas. Os papés de Product Owner, Scrum Master e equipe de desenvolvimento foram todos assumidos pe-los dois autores.
2.5 CANVAS
Segundo Sebrae (2018), o Modelo de Negócio ou Canvas, como também é conhecido, é um instrumento que ajuda a iniciar correta-mente um empreendimento. Foi desenvolvido pelo suíço Alex Osterwal-der para facilitar o entendimento completo de um negócio. O modelo tem o objetivo de descrever todos os elementos e fases que compõem um empreendimento, proporcionando a integração da organização.
“O planejamento é, sem dúvida, um fortíssimo aliado na hora de iniciar ou reorganizar um empreendimento. Afinal, planejar é vi-sualizar uma situação futura desejada e como as tornará realidade.” (NAKAMURA, 2001).
O Modelo de Negócio é baseado em um quadro com blocos orga-nizados, como mostra a figura a seguir, e proporciona uma visualização das principais funções do negócio. De acordo com o criador da ferra-menta, os componentes centrais são: segmentos de clientes, proposta de valor, canais de distribuição, relacionamento com clientes, fontes de receita, recursos principais, atividades principais, principais parcerias e custos.
Figura 1 – Business Model Canvas - Sebrae (2018)
• Proposta de Valor: O que sua empresa vai oferecer para o mercado que realmente terá valor para os clientes.
• Segmento de Clientes: Quais segmentos de clientes serão foco da sua empresa.
• Os canais: Como o cliente compra e recebe seu produto e serviço. • Relacionamento com clientes: Como a sua empresa se relacionará
com cada segmento de cliente.
• Atividade Chave: Quais são as atividades essenciais para que seja possível entregar a Proposta de Valor.
• Recursos Principais: São os recursos necessários para realizar as atividades-chave.
• Parcerias Principais: São as atividades-chave realizadas de ma-neira terceirizada e os recursos principais adquiridos fora da em-presa.
• Fontes de receita: São as formas de obter receita por meio de propostas de valor.
• Estrutura de custos: São os custos relevantes necessários para que a estrutura proposta possa funcionar.
3 DESENVOLVIMENTO
O processo de desenvolvimento da plataforma foi composto pelas seguintes etapas: Análise do mercado de serviços; Análise das soluções existentes no ramo; Desenvolvimento do modelo de negócio; Levanta-mento de requisitos; DesenvolviLevanta-mento do Product Backlog; Modelagem da arquitetura do sistema; Implementação e Testes.
Na primeira etapa, foi realizada uma análise do mercado de ser-viços, mais precisamente o mercado de contratação de serviços. O ob-jetivo desta etapa foi analisar como está o mercado hoje, e identificar possíveis desafios e dificuldades no ramo, a fim de realizar um modelo de negócios coerente com a situação atual do mercado.
Na segunda etapa, foi realizada uma pesquisa para identificar e analisar as soluções existentes no mercado. O objetivo dessa etapa foi realizar uma análise, com base em critérios considerados mais im-portantes a serem atendidos, o que auxiliou no desenvolvimento da solução.
Após o estudo sobre o mercado da contratação de serviços e da análise das soluções existentes, foi dado início à terceira etapa de desenvolvimento: o modelo de negócio. O objetivo foi identificar e descrever todos os elementos e fases que compõem a solução proposta, proporcionando organização e esclarecimento sobre o negócio, e conse-quentemente auxiliando na análise de requisitos do sistema.
A quarta etapa do desenvolvimento foi o levantamento de requi-sitos, onde de acordo com o modelo de negócio definido anteriormente, foi realizada a definição dos requisitos do software. O objetivo desta etapa foi descrever os requisitos do sistema e as regras de negócio do mesmo.
Com os requisitos de software definidos, foi iniciada a quinta etapa onde definiu-se uma lista, chamada Product Backlog, de funcio-nalidades que deverão ser implementadas no software, ordenadas por prioridades definidas pelos dois desenvolvedores.
A sexta etapa do desenvolvimento foi composta pela modelagem da arquitetura do sistema, onde foi definida a estrutura do sistema, as entidades e as tecnologias utilizadas no Front-end e Back-end.
A sétima e oitava etapa, implementação e testes, respectivamente foram realizadas em paralelo. Todas as funcionalidades foram imple-mentadas seguindo o ritmo de projeto da metodologia Scrum adaptada, conforme descrito no capítulo de Fundamentação Teórica. A partir do Product Backlog, foi então iniciada a implementação do sistema,
reali-zando Sprints com duração de 2 semanas. A etapa de testes ocorreu diversas vezes simultaneamente ao processo de codificação. Cada fun-cionalidade implementada era testada após o seu desenvolvimento, e quando possível, era testada também a integração da funcionalidade com o restante do sistema.
3.1 ANÁLISE DO MERCADO DE SERVIÇOS
Segundo Ciapipe (2017), a prestação de serviços é o processo pelo qual uma empresa, empreendimento ou prestador de serviços oferece soluções para seus clientes, de acordo com sua área de atuação, visando atender uma demanda existente de seu público-alvo e fazer com que esse processo se torne mais atraente e eficiente para seu cliente potencial.
Segundo o estudo feito pelo Sebrae (2019), o setor de serviços tem destaque no grupo de MEI (Micro Empreendedores Individuais) no Brasil. Este setor aumenta sua participação relativa a cada ano e, em 2018, já representou 45% do total de empreendimentos desta categoria (do total de 7,7 milhões de MEI no país). Entre 2014 e 2018, a taxa média de crescimento do número MEI, no setor de serviços, foi de 18 % a.a., e apenas em 2018, o número de MEI do setor de serviços cresceu 13 %. A pesquisa ainda revela que o crescimento da economia, empurrado pela projeção de uma safra agrícola próxima ao seu recorde histórico, assim como da esperada recuperação do mercado de trabalho, deve sustentar a trajetória de ligeira recuperação do rendimento médio real dos trabalhadores. Isso tende a favorecer as micro e pequenas empresas voltadas à prestação de serviços pessoais, como: cuidador de idosos, instalação e manutenção elétrica, entregas, transporte de passageiro, marketing direto e produção de conteúdo para internet, além dos negócios que atendem as necessidades básicas da população (alimentação, vestuário, calçados e construção).
Junto com o crescimento do setor de serviços é importante tam-bém destacar os principais desafios. Diferentemente da venda de produ-tos, onde o cliente tem atributos palpáveis para se basear, a prestação de serviços é um bem intangível, difícil de mensurar e de diferenciar no mercado. Seguem abaixo os desafios da área de prestação de serviços segundo Qipu (2014):
• Relacionamento:
Colocar o cliente no centro da estratégia é cada vez mais impe-rativo para empresas que queiram crescer mesmo neste momento de crise. No setor de serviços, como em qualquer outro, é preciso
conhecer profundamente seu perfil de cliente, suas necessidades, seus hábitos. Com essas informações integradas, atualizadas e disponíveis, é necessário ainda conhecer seu time interno para saber, por exemplo, qual é o melhor profissional para realizar de-terminada atividade com qualidade e eficiência. O foco, não custa lembrar, deve ser sempre a resolução do problema do cliente. • Captação de Clientes:
Já que o relacionamento está difícil, a conquista de clientes tam-bém está afetada. Conhecer o público em potencial, saber como chegar até ele e mostrar os diferenciais é um enorme desafio do mercado de prestação de serviços. Fazer um bom marketing di-reto permite que os prestadores de serviço estejam mais próximos de seus clientes e possam, dessa maneira, estabelecer um relacio-namento mais efetivo e de longo prazo.
• Precificação:
O mercado de prestação de serviços sofre com o valor percebido pelos clientes, pois não há um bem material para ser avaliado, e por isso a prestação de serviços acaba ficando defasada em relação ao valor real que proporciona.
Os serviços devem ser precificados de acordo com o valor perce-bido pelo cliente, e isso só é possível se houver uma pesquisa para avaliar quanto o cliente está disposto a pagar por um determinado serviço.
Além disso, segundo CDC (1987), Artigo 39: "É vedado ao for-necedor de produtos ou serviços, dentre outras práticas abusivas: executar serviços sem a prévia elaboração de orçamento e au-torização expressa do consumidor, ressalvadas as decorrentes de práticas anteriores entre as partes". E segundo Art. 40: "O for-necedor de serviço será obrigado a entregar ao consumidor orça-mento prévio discriminando o valor da mão-de-obra, dos materiais e equipamentos a serem empregados, as condições de pagamento, bem como as datas de início e término dos serviços."
• Proposta de Valor:
Fazer com que as pessoas percebam qual é o serviço oferecido e como elas serão beneficiadas. Os prestadores de serviço com me-lhor capacidade de comunicar sua proposta terão uma vantagem competitiva bastante significativa em relação aos concorrentes. A
marca deve estar presente onde o cliente estiver, especialmente, no ambiente online.
3.2 ANÁLISE DAS SOLUÇÕES EXISTENTES
3.2.1 Critérios
Para análise das soluções existentes, foram considerados critérios que façam com que as pessoas se sintam mais seguras e dispostas a contratar um serviço online. Os critérios são:
• Liberdade de escolha: Liberdade para escolher quem irá prestar o serviço, através de diversas opções de prestadores de serviços. • Transparência: Se a plataforma possibilita saber exatamente quem
se pretende contratar (antes de contratar) para prestar o serviço, através de informações sobre o prestador de serviço e/ou avalia-ções de outros usuários.
• Orçamento online: Possibilidade de realizar ou simular um orça-mento online.
• Pagamento online: Possibilidade de realizar pagamento online, por meio de plataforma de pagamento própria ou de terceiros. • Diversidade de serviços: Possui serviços para mais de um
seg-mento específico.
• Versão mobile: Possui versão mobile, ou web responsivo.
Como forma de atendimento aos critérios citados foi utilizado os seguintes valores:
• SIM: Atende ao critério. • NÃO: Não atende o critério.
3.2.2 Soluções existentes
Para a análise, foi feito um levantamento de algumas das so-luções existentes mais conhecidas na área de contratação de serviços, utilizando-se a versão de outubro de 2018 das mesmas. Segue abaixo a
lista das plataformas analisadas:
GetNinjas (https://www.getninjas.com.br) é uma empresa de in-ternet brasileira, com sede em São Paulo, foi fundada em 2011 por Edu-ardo L’Hotellier, possuí mais de 200 serviços disponibilizados e atende 80.000 clientes por mês.
Parafuzo (https://parafuzo.com) é uma empresa que foca na con-tratação de serviços de limpeza, fundada em 2014 por Eduardo Campos, garante agilidade no atendimento, podendo marcar uma limpeza, com 24 horas de antecedência. Não divulga o número de clientes atendidos.
StarOfService(https://www.starofservice.com.br), fundada em 2013 com sede em Paris, é uma plataforma onde você pode contratar profis-sionais do mundo inteiro. Possui mais de 1100 serviços cadastrados, e atende mais de 5 milhões de projetos anualmente.
Habitissimo (https://www.habitissimo.com.br) é uma empresa de Internet líder na Espanha, no Brasil e América Latina que ajuda a conectar oferta e demanda no setor de obras, reformas e serviços domés-ticos. Foi fundada em 2009, conta com 270.000 profissionais registrados, e não divulga o número de clientes atendidos anualmente.
3.2.3 Resultado
A análise foi realizada através da utilização de cada uma das plataformas (cadastro, contratação de serviço, navegação no site), e após a análise, originou-se a tabela a seguir:
Tabela 1 – Análise plataformas existentes Análise plataformas existentes
GetNinjas Parafuzzo StarOfService Habittisimo Liberdade de
Escolha
NÃO NÃO NÃO NÃO
Transparência NÃO NÃO NÃO NÃO
Orçamento Online
NÃO SIM SIM NÃO
pagamento Online
NÃO SIM NÃO NÃO
Diversidade de Serviços
SIM NÃO SIM SIM
Versão Mo-bile
SIM SIM SIM SIM
3.3 SOLUÇÃO PROPOSTA
Com a análise das soluções existentes, foi concluído que não foi possível encontrar atualmente nenhuma solução que contemple todos os critérios. Ainda, entre as plataformas analisadas, os critérios menos atendidos foram justamente liberdade de escolha e transparência. Em quase todas as plataformas analisadas, há pouca informação sobre o prestador de serviço que irá ser contratado, antes de definitivamente contratá-lo, além de não possuir nenhum feedback de outros usuários, nem nenhum metódo de avaliação que possibilite a classificação dos prestadores.
Neste contexto, foi dado início na modelagem e definição de uma solução para a contratação de serviços online, de forma que os parâme-tros considerados mais importantes sejam atendidos. Dentre os critérios analisados na etapa anterior, o software atenderá a todos. Na questão de liberdade de escolha, o usuário poderá ver todos os prestadores dis-poníveis para a sua região e escolher o que melhor se adequa a seu caso. No quesito transparência, decidimos implementar um perfil para o prestador, onde ele terá as avaliações de seus serviços feitas por ou-tros usuários, e poderá incluir informações que ele achar relevante para o serviço que presta. Quanto o quesito versão mobile, decidimos imple-mentar a versão web como um PWA, que garante os recursos mobile mesmo que a aplicação seja uma aplicação web. A parte de orçamento online, ficará a critério do prestador, podendo fornecer ou não o custo de seus serviços. Por fim com relação ao pagamento online, não será implementado nessa versão do TCC, por questão de tempo.
3.3.1 Modelo de Negócio
Visto o conceito de Modelo de Negócio no capítulo de Fundamen-tação Teórica, a seguir a descrição do Modelo de Negócio ou Canvas realizado para este trabalho.
1. Segmentos de Clientes: Os clientes são os usuários que pos-suem acesso à Internet. Existem dois tipos principais de clientes: os usuários prestadores de serviço que querem oferecer serviços na plataforma, e os usuários jovens, profissionais ou empresas que precisam contratar algum serviço. Cada um desses tipos de cliente formam um segmento, pois possuem interesses diferentes na utilização da plataforma.
2. Prospostas de valor: A proposição de valor é uma plataforma web que para o prestador de serviço, permite atrair novos clien-tes, aumento da visibilidade no mercado e publicidade com re-torno mensurável. Para o usuário que contrata serviços, permite contratar serviços de forma transparente e segura.
3. Canais: O principal canal com o cliente é a própria plataforma. Para o prestador de serviço se dá através de cadastro no site e venda direta pela plataforma. Para o usuário que contrata ser-viço, é através de e-mails de marketing, publicidade digital e rede sociais.
4. Relacionamento com o Cliente: O relacionamento com os clientes é virtual, através de um FAQ (perguntas mais frequentes) para o prestador de serviços e e-mails e site para os usuários que contratam serviços.
5. Fontes de receitas: Possíveis fontes de receita a serem utilizados são a porcentagem da prestação do serviço realizado.
6. Recursos principais: São recursos chaves para garantir o fun-cionamento do sistema, entre eles, sistemas de tecnologia da in-formação, a reputação da marca e recursos humanos.
7. Atividades principais: As atividades chave seriam o prospecto de novos prestadores de serviço, o marketing e o gerenciamento da contratação de serviço.
8. Parcerias principais: As parcerias principais seriam as em-presas de prestação de serviço, emem-presas de pagamento online e empresa de material de construção.
9. Estrutura de custos: Os principais custos são os custos com pu-blicidade, transações financeiras online e recursos humanos.
3.3.2 Levantamento de Requisitos
Através da análise das soluções já existentes no mercado, e do modelo de negócio definido, foi realizado o levantamento dos requisitos de software, ilustrados na figura 2 e que são explicados logo a seguir.
• R1 - Cadastro: O sistema deve permitir o cadastro de um usuário. Na tela de cadastro, será necessário inserir informações como Nome, Sobrenome, Email e senha.
• R2 - Login: O programa deverá permitir que o usuário faça login no sistema, através do seu email e senha que foram cadas-trados na etapa de Cadastro.
• R3 - Buscar um serviço: A busca de um serviço, deverá ser permitida mesmo se o usuário não estiver logado no sistema, e deverá retornar prestadores que realizem o serviço buscado. • R4 - Buscar um prestador: A busca de um prestador deverá
ser permitida mesmo se o usuário não estiver logado no sistema, e deverá retornar prestadores que possuem um nome semelhante ao da string buscado. Deverá conter um input de busca, onde o usuário poderá inserir qualquer informação sobre o serviço que necessita utilizar(por categoria, por nome do serviço, ou palavras relacionadas). Deverá também conter um menu lateral, separado por Áreas de serviços(Categorias), e cada área conterá serviços específicos. Ao buscar um serviço pelo input ou pelo menu, o sistema deverá apresentar uma lista com os resultados da busca, e na lateral, deverá conter filtros de pesquisa por categorias de preço, região, avaliação, e etc.
• R5 - Contratar um serviço: O sistema deverá permitir que o usuário contrate/agende um serviço, podendo escolher exata-mente quem será o prestador do serviço a ser contratado. • R6 - Cancelar um serviço: O sistema deverá permitir que o
usuário/prestador de serviço, possa cancelar um serviço previa-mente contratado, podendo ou não ser penalizado por isso. • R7 - Ver Perfil do prestador: O sistema deverá permitir que
o usuário visualize o perfil de um prestador de serviços, podendo ver suas avaliações, e informações de preços dos serviços quando aplicável.
• R8 - Ver dados da conta: O sistema deverá permitir que o usuário veja seus dados de conta, como endereço, email e etc... • R9 - Modificar dados da conta: O sistema deverá permitir
que o usuário modifique seus dados de conta, como endereço, email e etc...
• R10 - Upgrade de conta para Prestador de Serviço: O sistema deverá permitir que usuários comuns virem prestadores de serviço, preenchendo alguns dados que são necessários para a prestação de serviço, como área de atuação e telefone para con-tato.
• R11 - Cadastro de serviço: O sistema deverá permitir que usuários que possuem conta de prestador de serviço, possam ca-dastrar quais serviços que eles oferecem, podendo descrever o ser-viço, e pedir que algumas perguntas sejam respondidas por quem o está contratando.
• R12 - Acompanhar serviços: O sistema deverá permitir que qualquer tipo de usuário possa acompanhar seus serviços, tanto os que estão agendados como os que ja foram concluídos. • R13 - Histórico de Avaliações: O sistema deverá permitir
consultar as avaliações de outro usuário.
• R14 - Avaliar um Serviço Contratado: O sistema deverá permitir avaliar um serviço, por meio de uma nota, junto com um comentário.
• R15 - Finalizar um Serviço: O sistema deverá permitir que um usuário/prestador de serviço, indique que um serviço foi con-cluído.
• R16 - Avaliar um clienteR16 - Avaliar um cliente: O sistema deverá permitir avaliar um cliente que contratou um serviço, por meio de uma nota junto com um comentário.
3.4 PRODUCT BACKLOG
Utilizando os casos de uso apresentados na última seção, foi cri-ado o Product Backlog, apresentcri-ado na tabela a seguir:
Tabela 2 – Tabela de Product Backlog. Product Backlog
ID Nome Descrição Parte do
Sistema Estimativa (em dias) 1 Arquitetura do sistema Definir a arquite-tura: Linguagens; Frameworks; Bibli-otecas; Back-end e Front-end 14 dias 2 Entidades do sistema Definir as entida-des do sistema: De-finir e modelar as entidades do banco de dados e seus relacionamentos, e os componentes do Front-end Back-end e Front-End 10 dias 3 Estrutura do sistema Desenvolver a da base do sistema (configuracao do gitlab, heroku, criação do projeto em si, etc) Back-End e Front-End 4 dias
4 Cadastro Desenvolver o Re-quisito 1: Cadastro de um usuário Front-end e Back-end 14 dias
5 Login Desenvolver o
Re-quisito 2: Login de um usuário Front-end e Back-end 14 dias 6 Upgrade de conta Desenvolver o Re-quisito 10: Rea-lizar Upgrade de uma conta normal para prestador de serviço, Back-end e Front-End 4 dias
Continuação da tabela 3
ID Nome Descrição Parte do
Sistema Estimativa (em dias) 7 Ver Dados da conta Desenvolver o Re-quisito 8: Vizuali-ção de seus dados da conta Back-end e Front-End 5 dias 8 Modificar dados da conta Desenvolver o Re-quisito 9: Edição de seus dados da conta
Back-end e Front-End 5 dias 9 Cadastro de Serviço Desenvolver o Re-quisito 11: Realizar o cadastro de servi-ços que são presta-dos Back-end e Front-End 21 dias 10 Busca de um serviço Desenvolver o Re-quisito 3: Realizar a busca de serviços Back-end e Front-End 7 dias 11 Busca de um prestador Desenvolver o Re-quisito 4: Realizar a busca de presta-dores de serviço Back-end e Front-End 7 dias 13 Visualizar o perfil de um prestador Desenvolver o Re-quisito 7: Poder Visualizar os deta-lhes de perfil de um prestador Back-end e Front-End 7 dias 14 Contratar um Serviço Desenvolver o Re-quisito 5: Reali-zar a contratação de um serviço Back-end e Front-End 14 dias
Continuação da tabela 3
ID Nome Descrição Parte do
Sistema Estimativa (em dias) 15 Acompanhar Serviços Desenvolver o Re-quisito 12: Visuali-zar seus serviços em aberto, ou já con-cluídos Back-end e Front-End 7 dias 16 Cancelar um Serviço Desenvolver o Re-quisito 6: Reali-zar o cancelamento de um serviço em aberto Back-end e Front-End 7 dias 17 Finalizar um Serviço Desenvolver o Re-quisito 15: Realizar a finalização de um serviço que está em aberto Back-end e Front-End 7 dias 18 Avaliar um Serviço Desenvolver o Re-quisito 14: Realizar a avaliação de um serviço contratado Back-end e Front-End 7 dias 19 Avaliar um Cliente Desenvolver o Re-quisito 16: Realizar a avaliação de um cliente no qual pres-tou um serviço Back-end e Front-End 7 dias 20 Visualizar Histórico de Avaliações Desenvolver o Re-quisito 13: Visuali-zar histórico de ava-liações de um usuá-rio Back-end e Front-End 7 dias Fim da Tabela
3.5 SPRINTS BACKLOGS
Utilizando o Product Backlog apresentado como base, foi possí-vel dividir uma ou mais tarefas organizadas em sprints de desenvolvi-mento. Neste projeto o Product Backlog foi dividido em dez sprints, como mostra a tabela a seguir:
Tabela 3 – Tabela de Sprints Backlogs. Sprints Backlogs
ID Nome Descrição Parte do
Sistema
Estimativa (em dias) 1 Sprint 1 Definição da
Arqui-tetura, linguagens, frameworks e bibli-otecas Back-end e Front-end 14 dias
2 Sprint 2 Modelagem das en-tidades do sistema e criação da estru-tura do sistema Back-end e Front-end 7 dias
3 Sprint 3 Cadastro de usuá-rio
Back-end e
Front-end
15 dias
4 Sprint 4 Login e Logout do usuário
Back-end e
Front-end
15 dias
5 Sprint 5 Upgrade de Conta
Back-end e
Front-end
15 dias
6 Sprint 6 Visualizar e modifi-car dados da conta
Back-end e
Front-end
15 dias
7 Sprint 7 Listagem de Servi-ços
Back-end e
Front-end
Continuação da tabela 3
ID Nome Descrição Parte do
Sistema
Estimativa (em dias) 8 Sprint 8 Cadastro de
Servi-ços
Back-end e
Front-end
15 dias
9 Sprint 9 Busca de um Pres-tador de Serviço
Back-end e
Front-end
15 dias
10 Sprint 10 Contratar um Ser-viço Back-end e Front-end 15 dias Fim da Tabela 3.6 ARQUITETURA DO SISTEMA
A arquitetura de um software consiste na estrutura dos compo-nentes do sistema e nas regras de comunicação entre esses compocompo-nentes (VALIPOUR, 2009).
Segundo (SOMMERVILLE, 2011), uma arquitetura de software, quando adequadamente documentada, facilita a compreensão da estru-tura de um sistema, evitando a compreensão a partir do código fonte e ajudando nas comunicações com a equipe de desenvolvimento e com clientes. Além disso, a arquitetura de um software permite perceber, de forma rápida, decisões na construção do software que influenciam no sucesso de software. Assim, o desenvolvimento da arquitetura de um sistema afeta fatores como reuso, manutenibilidade, extensibilidade e escalabilidade.
Na figura 3 pode-se analisar o diagrama da arquitetura proposta para este sistema:
Figura 3 – Arquitetura do Sistema
O usuário acessa o Front-end digitando o endereço web da apli-cação. Ao fazer isso ele acessa o Router que verifica o caminho especifi-cado pelo usuário, e verifica se o mesmo possui autenticação necessária para acessar esse endereço consultando o módulo Authenticator. Caso possua autenticação o usuário é direcionado para a página especifi-cada, carregando os Containeres e Componentes dessa página, e caso contrário é direcionado para a página inicial da aplicação.Após o car-regamento completo da página, o usuário pode interagir com ela, por meio dos seus componentes. Sempre que uma interação do usuário ne-cessitar se comunicar com o servidor é acionado o modulo API Cliente para realizar essa comunicação.
Requisições do Front-end chegam através do modelo REST, um modelo de arquitetura que foi descrito por Roy Fielding, um dos prin-cipais criadores do protocolo HTTP. Todas as requisições batem no Router, que escuta solicitações que correspondem às rotas e métodos especificados e, quando detecta uma correspondência, chama a função de retorno de chamada especificada. Entre a identificação da rota es-pecificada e a chamada da função de retorno, existe configurado um middleware para autenticação de algumas rotas. Middleware é um me-canismo de filtragem de requisição HTTP, que permite ou barra deter-minados fluxos de requisição ao entrar na aplicação, baseado em regras definidas. No caso, utilizamos como middleware um módulo de auten-ticação que através de um Token, valida se o cliente está autenticado ou não. Após isso, as solicitações passam para a camada do Controller, onde fica a lógica de negócio da aplicação, são feitas validações com os dados. Então, caso necessite se comunicar com o banco de dados, passa para o Model, que é o módulo responsável por se comunicar com
o banco de dados.
3.6.1 Estrutura do Sistema
O Back-end e o Front-end foram separados em dois projetos, seguindo o princípio Separation of Concerns (Separação de Responsa-bilidades), facilitando a manutenibilidade dos projetos, e possibilitando o auto escalonamento das plataformas de acordo com a demanda, mi-tigando problemas como DoS (Denial of service).
Para versionamento do código, foi utilizado o Git (https://git-scm.com). Git é um sistema de controle de versão distribuído gratuito e de código aberto, projetado e desenvolvido por Linus Torvalds. O Git é utilizado principalmente no desenvolvimento de software. Ele permite manter um histórico de todos os pontos de alterações dos pro-jetos, permitindo também que cada desenvolvedor trabalhe em uma versão diferente do mesmo projeto. Isto impede que, ao realizar al-guma alteração, se altere a versão que outra pessoa está trabalhando, e assim evitando erros que poderiam refletir na versão de outro desenvol-vedor. Caso seja necessário, é só voltar para uma versão anterior onde o projeto estava funcionando.
Para armazenar os dois projetos, foi utilizado o Github (https://github.com), um gerenciador de repositório de software baseado em git que permite
a criação de inúmeros repositórios públicos e privados gratuitamente, assim como inúmeros colaboradores. Dentre os recursos que o Github fornece estão ferramentas de revisão de código, suporte a Wiki, ras-treamento de erros, branchs privadas e sistema de CI/CD (Continuos Integrations e Continuos Delivery).
3.6.1.1 Estrutura do Front-end
Para desenvolver o Front-end foi escolhida a biblioteca React, que facilita a criação de componentes web. Ela foi escolhida pelo uso da mesma pelo seu ótimo desempenho.
O padrão de projetos escolhido foi o padrão Presentational e Container componentes criado em 2015 por Dan Abramov, um dos cri-adores do React. Esse padrão constitui em separar os componentes em dois tipos, os presentationals components, que seriam os componen-tes puramente visuais, não possuindo nenhuma lógica do négocio, e os container componentes, que possuiriam a lógica da aplicação, como por
exemplo realizar uma chamada de API, podendo ser gerado também por outros componentes.
Para Dan Abramov (2015) Presentational components possuem as seguintes características:
• Estão preocupados com a aparência das coisas.
• Podem conter presentational e container component dentro de si; normalmente possuem algumas marcações DOM e estilos pró-prios.
• Não possuem dependência do resto da aplicação.
• Não especifica como o dado vai ser carregado ou modificado. • Recebe dados e callbacks exclusivamente de um componente pai. • Raramente possuem estado próprio(Somente quando for um
es-tado referente a Interface de Usuário).
• São escritos como componentes funcionais, a não ser que neces-sitem de estado, ciclo de vida, ganchos ou otimizações de perfo-mance .
• Exemplos: Page, Sidebar, Story, UserInfo, List. Os benefícios dessa abordagem, são:
• Melhor separação de preocupação: Você acaba entendendo me-lhor sua aplicação, e sua UI escrevendo componentes dessa ma-neira.
• Melhor reusabilidade: É possível utilizar o mesmo presentational component com diferentes fontes de dados.
• Presentational Components acabam sendo a paleta da aplicação, podendo ser colocados numa página, para que o designer tenha acesso sem que interaja com a aplicação. Dessa forma não modifi-cam a lógica da aplicação, e é possível realizar testes de regressão nessas página.
• Essa abordagem força a extração de "componentes de layout"como Sidebar, Page, Menu, em vez de duplicar o mesmo HTML e layout em diversos componentes.
Foi seguindo este modelo de arquitetura que foi definida então os módulos que formam a estrutura do Front-end:
• Authenticator (Frontend): Responsável por verificar se há usuá-rio logado ou não, e caso haja quais os níveis de permissão desse usuário. Atualmente o sistema possui 3 estados de autenticação: usuário não logado, usuário comum e usuário prestador de servi-ços.
• API Cliente: Instância de um cliente http, serve para se comuni-car com o servidor.
• Component : Componentes puramente visuais que não possuem dependência com a aplicação. Ex: componente de input de email. • Container : Responsável pelas regras de negócio da aplicação, ele se comunica com o API Cliente e repassa as informações para o resto da aplicação.
• Page: Páginas que servem para encapsular os containers e com-ponents e mostrar uma tela específica, ex: Página inicial. • Router (Frontend): Responsável pelo roteamento interno do
fron-tend. Direciona o usuário entre as páginas da aplicação.
• Redux : Responsável pelo gerenciamento do estado da aplicação frontend, serve para compartilhar estados entre componentes e containeres.
3.6.1.2 Estrutura do Back-end
Para a definição da estrutura do Back-end, seguimos o modelo de arquitetura MVC (Model-View-Controller).
Podemos descrever a arquitetura MVC em palavras simples: • Model: A parte da aplicação que lidará com o banco de dados ou
qualquer funcionalidade relacionada a dados.
• View: Renderiza o modelo em uma visualização adequada para interação, geralmente por meio de uma interface com o usuário. • Controller: A lógica da aplicação e a cola entre models e views.
Aqui os models são chamados para obter os dados, e então esses dados são enviados para a view para serem enviados ao cliente.
Foi seguindo este modelo de arquitetura que definimos então os componentes que formam a estrutura do Back-end:
• Router: Representa a View. É responsável por responder as re-quisições do cliente (browser) através das URLs.
• Authenticator: Módulo responsável pela autenticação das rotas da API.
• Controller: É responsável pela lógica da aplicação e possui os arquivos responsáveis pelos métodos da API.
• Models: Representa os documentos do banco de dados MongoDB, os chamados "Schemas".
3.6.2 Entidades do Sistema
3.6.2.1 Entidades do Back-end
A principal decisão em projetar modelos de dados para aplica-ções que utilizam o MongoDB gira em torno da estrutura de docu-mentos e de como a aplicação representa os relacionadocu-mentos entre os dados. Tem-se duas formas para modelar os dados: modelo de dados incorporados e modelo de dados normalizados. O modelo de dados incorporados permite que dados relacionados sejam incorporados em um único documento. Já o modelo de dados normalizados descrevem relacionamentos usando referências entre documentos.
Para arquitetar o banco de dados deste projeto, decidimos utili-zar o modelo de dados incorporados, que por incorporar estruturas de documentos em um campo ou matriz dentro de um documento, esse modelo de dados desnormalizados permite que as aplicações recupe-rem e manipulem dados relacionados em uma única operação de banco de dados. Segue abaixo um exemplo de um modelo de documentos incorporados.
Figura 4 – Documentos Incorporados - Documentation (2018)
Os modelos de dados incorporados permitem que as aplicações armazenem informações relacionadas no mesmo registro do banco de dados. Como resultado, as aplicações podem precisar enviar menos consultas e atualizações para concluir operações comuns.
Para realizar a modelagem do banco de dados, foi utilizada a notação baseada em agregados para representar, em nível lógico, banco de dados NoSQL de documento, desenvolvida pelo grupo de banco de dados da Universidade Federal de Santa Catarina (GBD/UFSC). A seguir a modelagem lógica:
• User: Representa o usuário da aplicação, que possui um identi-ficador, nome, sobrenome, email, senha, avatar (foto de perfil), sexo, telefone, endereço, e um documento incorporado Provider.
• Provider: Representa do prestador de serviços, que possui um identificador, uma galeria de fotos (uma lista de URL‘s de fotos armazaenadas no Bucker S3 da Amazon), um documento incor-porado ProvidedServices, District e Rating.
• ProvidedServices: Representa o serviço prestado por um presta-dor de serviço, possui um identificapresta-dor, preço, orçamento (é um valor booleano, identifica se o serviço prestado é negociado por orçamento), método de cobrança (por hora ou serviço fechado), e o documento incorporado Service.
• Service: Representa um serviço, possui um identificador, um nome e descrição.
• District: Representa o bairro/região que o prestador atende. Pos-sui um nome. Exemplo: Trindade.
• Rating: Representa a pontuação do prestador de serviço na plata-forma. Possui um identificador, um identificador do usuário que realizou a avaliação, uma nota que vai de 1 a 5, e um comentário.
3.6.2.2 Entidades do Front-end
Seguindo o padrão Presentational components de Dan Abramov (2015), foram definidos os seguintes componentes:
Figura 6 – Componentes do Frontend
3.6.3 Tecnologias Utilizadas
Segue abaixo uma lista das tecnologias e frameworks que foram utilizadas no Backend e Frontend:
3.6.3.1 Tecnologias utilizadas no Backend
• MongoDB (2018): É um banco de dados NoSQL, que utiliza um modelo de dados flexível, de modo que o schema pode mudar fa-cilmente conforme a aplicação evolui. Apesar de ser um banco de dados NoSQL ele oferece funcionalidades comuns dos bancos de dados tradicionais, tais como múltiplos índices, uma linguagem de consulta completa, operações de agregação e consistência rigo-rosa. No MongoDB os dados são armazenados em JavaScript Ob-ject Notation (JSON), podendo assim conter atributos aninhados e evitar normalizações desnecessárias. Por se tratar de um banco de dados NoSQL, MongoDB foi construído para escalabilidade, performance e alta disponibilidade, escalando de implementações simples para grandes e complexas arquiteturas. Além disso, ele possui performance de escrita "in-memory", o que da o
benefí-cio de ter alto desempenho para escritas. Diferente dos bancos de dados relacionais que obrigatoriamente escrevem os dados em disco antes de retornar o sucesso da operação.
• Nodejs (2018): É uma plataforma construída sobre o motor Ja-vaScript Google Chrome para facilmente construir aplicações de rede rápidas e escaláveis. Node.js usa um modelo de I/O direci-onada a evento não bloqueante, ou seja, nenhuma tarefas pesa-das de IO vai travar a aplicação, pois elas serão executapesa-das em background sem bloquear a aplicação e quando elas finalizarem você trata os resultados através dos callbacks das funções. Isso o torna leve e eficiente, ideal para aplicações em tempo real com troca intensa de dados através de dispositivos distribuídos. Além disso, ser totalmente baseado em JavaScript facilita na hora de programar, uma vez que JavaScript é uma linguagem simples e muito presente na web. O Node.js oferece uma quantidade grande de pacotes, através do seu gerenciador de pacotes, o NPM (Node Package Manager), o que possibilita maior produtividade durante o desenvolvimento.
• Typescript (2018): É um superconjunto de JavaScript desenvol-vido e mantido pela Microsoft. O código é escrito em TypeScript e o compilador compila(converte) o que foi escrito para JavaScript puro.A vantagem do uso de tipagem estática, e de ter sintaxe e estrutura fortemente orientados à objetos, permite que as IDEs ganhem a possibilidade de aprimorarem seus mecanismos de de-tecção de erros e de sintaxe em tempo de desenvolvimento, ajuda a manter o código mais escalável, proporciona uma maior com-preensão por todos da equipe do código produzido, facilitando sua extensão.
• Express (2018): É um framework Nodejs que contém um robusto conjunto de recursos para desenvolver aplicações web do lado servidor, que inclui um sistema de Views intuitivo (MVC), um robusto sistema de roteamento, um executável para geração de aplicações, entre outros recursos.
• Mongoose (2018): É uma biblioteca Nodejs que traduz os dados do banco de dados para objetos JavaScript para que possam ser utilizados na aplicação. Essa biblioteca oferece uma solução ba-seada em esquemas para modelar os dados da aplicação, possui um sistema de conversão de tipos, criação de consultas, validação e hooks para lógica de negócios. O Mongoose também oferece a
capacidade de pré-definir eventos para acontecer, antes que um documento seja salvo por exemplo. Isso é muito poderoso porque consolida o código que você teria que escrever e coloca esse código onde deveria estar próximo à lógica do documento e não na lógica do aplicativo.
3.6.3.2 Tecnologias utilizadas no Frontend
• React (2018): uma biblioteca Javascript de código aberto para criar interfaces de usuário de forma declarativa. - baseada em componentes e foi criada pelo Facebook. Hoje, mantida pelo Fa-cebook, juntamente com uma comunidade de desenvolvedores in-dividuais.
• Redux (2018): uma biblioteca Javascript de código aberto, para gerenciar o estado da aplicação. Ela segue a arquitetura flux, que substitui o padrão de projeto MVC.
• Webpack (2018): é um "agrupador"de módulos Javascript de có-digo aberto, seu principal uso é o de agrupar arquivos, transforma-los e empacotá-transforma-los.
• Typescript (2018): é um superconjunto de Javascript criado pela Microsoft, que nos possibilita adicionar tipagem estática ao có-digo, aumentando a confiabilidade, e manutenibilidade do código.
• SemanticUI (2018): é um framework de UI(user interface), que agiliza o processo de desenvolvimento de telas responsivas, possui integração com o react, e alta customização de seus componentes.
• NGINX (2018): é um servidor HTTP e proxy reverso, que possui alta perfomance e segurança, será utilizado para servir todo o Front-end.
• AWS (2019): O Amazon Simple Storage Service (Amazon S3) é um serviço de armazenamento de arquivos que oferece esca-labilidade líder do setor, disponibilidade de dados, segurança e performance.
3.7 IMPLEMENTAÇÃO
A seguir, os detalhes mais relevantes da implementação dos re-quisitos do sistema, representados utilizando diagrama de atividades e capturas de tela do sistema.
A seguir a tela principal do sistema:
Figura 7 – Tela principal
3.7.1 Cadastro de Usuário
Caso de uso: R1
Para se cadastrar no sistema, o usuário deve clicar em "Cadastrar-se", e preencher as informações como Nome, Sobrenome, Email e Senha. Uma requisição POST é feita à API, que recebe os dados e salva no banco de dados. Em caso de sucesso no cadastro, o usuário é automa-ticamente logado no sistema.
Figura 8 – Diagrama de Atividades: Cadastro de Usuário
Figura 9 – Tela de Cadastro do Usuário
3.7.2 Login de Usuário
Caso de uso: R2
Para se logar no sistema, o usuário deve clicar em "Entrar", e preencher o e-mail e senha. Uma requisição POST é enviada à API que gera um Token de autenticação e retorna esse Token junto com as informações do usuário.
Figura 10 – Diagrama de Atividades: Login do Usuário
Figura 11 – Tela de Login do Usuário
3.7.3 Upgrade de conta
Caso de uso: R10
sistema decide se tornar um prestador de serviço. Para realizar a ope-ração, o usuário deve clicar em "Torne-se um profissional", e preencher informações como o CPF, Telefone e Sexo. Uma requisição POST é feita à API, com as informações, e o Back-end salva esses dados no banco de dados, e retorna sucesso ou erro ao Front-end.
Figura 12 – Diagrama de Atividades: Upgrade de conta
3.7.4 Visualizar e modificar dados da conta
Caso de uso: R7, R9
Em "Minha conta» "Meus dados", é possível visualizar e modi-ficar informações da conta do usuário. Ao editar alguma informação, uma requisição PUT é feita à API, enviando os dados modificados, assim, o Back-end faz a modificação no banco de dados, e retorna as informações atualizadas.
Figura 15 – Tela de Editar/Adicionar dados da conta
3.7.5 Listagem de Serviços
Caso de uso: R3
Para usuários que são prestadores de serviço, em "Minha Conta» "Serviços", é possível visualizar a lista de serviços cadastrados. Nesta tela é possível editar ou deletar um serviço. Ao entrar nesta tela, uma requisição GET é feita à API, enviando o ID do prestador de serviço. Como retorno, a API envia uma lista de serviços do prestador em ques-tão.
Figura 16 – Diagrama de Atividades: Listagem de Serviços
Figura 17 – Tela de Listagem de Serviços
3.7.6 Cadastro de Serviço
Caso de uso: R11
Para cadastrar um serviço, o usuário deve ir na tela "Minha Conta» "Serviços"e clicar em "Novo Serviço", incluir o Nome e
Des-crição do serviço, informar se o preço é Fixo ou Orçamento, o tipo de cobrança, se é Por Hora ou Serviço Fechado, e informar o preço. Ao clicar em "Criar Serviço", uma requisição POST é enviada ao Back-end com as informações, onde os dados são inseridos no banco de dados.
Figura 18 – Diagrama de Atividades: Cadastro de um Serviço
Figura 19 – Tela de Cadastro de um Serviço
3.7.7 Busca de Serviço e Prestador
Para buscar um prestador de serviço, é preciso digitar a busca no campo de busca e clicar Enter. Caso o usuário digite algo, o dado é enviado através de uma requisição GET para a API, onde a busca é feita através de uma query no banco de dados, que tenta encontrar strings correspondentes com a string recebida na request, em nome, sobrenome, e-mail e descrição do prestador de serviço, além de nome de serviço e descrição de serviço. Caso não seja digitado nada, o Front-end faz a mesma requisição ao Back-Front-end porém todos os prestadores de serviço disponíveis são retornados na busca.
Figura 20 – Diagrama de Atividades: Busca de Serviço e Prestador
3.7.8 Contratar um Prestador de Serviço
Caso de uso: R7, R5
Para contratar um prestador de serviço, o usuário deve Clicar em "Contratar", no perfil do prestador de serviço de acordo com a busca feita. Assim, é aberta uma tela de informações de contato do prestador como e-mail e telefone.
Figura 22 – Diagrama de Atividades: Contratar Prestador de serviço
4 RESULTADOS OBTIDOS
A realização deste trabalho possibilitou o registro do desenvol-vimento de uma aplicação web, onde foi dada a devida importância às etapas que antecedem a implementação de um software, como: pesquisa de mercado, análise de soluções existentes, modelo do negócio, levanta-mento de requisitos, utilização de uma metodologia ágil e modelagem da arquitetura do sistema.
Após o desenvolvimento deste trabalho, realizamos a análise dos critérios que analisamos na seção 3.2, em relação as soluções existentes no mercado. Foi possível concluir que o sofware desenvolvido para este trabalho atende aos seguintes critérios:
Tabela 4 – Análise do software desenvolvido Análise do software desenvolvido
Critério Atende ao critério
Liberdade de Escolha SIM
Transparência SIM
Orçamento Online NÃO
Pagamento Online NÃO
Diversidade de Serviços SIM
Versão Mobile SIM
Foi possível implementar 10 dos 16 requisitos levantados durante o desenvolvimento deste trabalho. A seguir os requisitos implementa-dos:
• Realizar Cadastro • Realizar Login • Buscar Serviço • Buscar Prestador
permitida através da disponibilização das informações de contato do prestador de serviço
• Visualizar perfil de prestador • Visualizar dados da conta • Modificar dados da conta • Virar prestador de serviço • Cadastrar Serviço
Os requisitos que não puderam ser implementados, por motivo de tempo, foram: • Cancelar serviço • Avaliar serviço • Avaliar cliente • Finalizar serviço • Acompanhar serviço
• Visualizar histórico de avaliações
Além disso, foi realizada a implantação do sofware na web: O Back-end foi publicado em uma máquina da Amazon, utili-zando a plataforma Lightsail (https://aws.amazon.com/pt/lightsail/). Lightsail é uma plataforma de nuvem que oferece infraestrutura da AWS. Foi criada uma instância com Linux/UNIX e NodeJS versão 12.7.0. Para subir o servidor, foi utilizado o gerenciador de proces-sos para tempo de execução PM2 (https://pm2.io/), uma ferramenta open source para o gerenciamento e deploy de aplicações Node.js em ambientes de produção. Além disso, para armazenar o MongoDB, foi utilizado o MongoDB Atlas (https://www.mongodb.com/cloud/atlas), um serviço cloud do MongoDB, feito para gerenciar e manter os dados na nuvem. Após hospedado o banco de dados na nuvem, a URL é utilizada no servidor.
O Front-end, foi hospedado no Netlify (https://www.netlify.com/), uma plataforma de computação em nuvem, que oferece serviços de hos-pedagem para sites estáticos.
A aplicação está disponível em https://tccbazzu.netlify.com/. Para instalar a PWA no dispositivo móvel, é preciso usar o Mozilla
Firefox, pois o netlify não possui um certificado válido que outros nave-gadores como Google Chrome exigem. Ao instalar o nevegador Mozilla Firefox, basta acessar a URL da aplicação, e clicar no ícone "casa"com um ícone mais (+) dentro, clicar em "adicionar a tela inicial", e o apli-cativo estará disponível no dispositivo móvel.
