PI1A5 Desenho Da Aplica o v07 Teste

IFSP - Instituto Federal de Educação, Ciência e Tecnologia
Câmpus São Paulo
Débora Peixoto dos Santos SP3069028

Gabriela Dias Dutra SP3030041
João Pedro Vanderlei SP3069427
Pedro Henrique Beserra Lima SP3073785
CARLLET
São Paulo - SP - Brasil

16 de Maio de 2023
Câmpus São Paulo
Débora Peixoto dos Santos SP3069028

Gabriela Dias Dutra SP3030041
João Pedro Vanderlei SP3069427
Pedro Henrique Beserra Lima SP3073785
CARLLET
Proposta de projeto para disciplina PI1A5 -

Projeto Integrado I
Professor: ANTONIO AIRTON PALLADINO

Professor: JOSE BRAZ DE ARAUJO

Câmpus São Paulo
Tecnologia em Análise e Desenvolvimento de Sistemas
PI1A5 - Projeto Integrado I
São Paulo - SP - Brasil

16 de Maio de 2023
Este trabalho é dedicado aos motoristas de aplicativo que, com seu trabalho diário,
facilitam a vida de milhares de pessoas.
Agradecimentos
Gostaríamos de expressar nossa sincera gratidão aos familiares dos integrantes do

grupo e aos professores orientadores Antonio Palladino e José Braz, que nos acompanharam
ao longo deste trabalho. Aos familiares, agradecemos por todo o apoio e incentivo que nos
deram durante esta jornada. Seus encorajamentos e palavras de incentivo nos motivaram
a perseverar mesmo nos momentos mais difíceis. Aos orientadores, agradecemos pela
paciência, direção e ensinamentos valiosos que nos transmitiram. Sem a orientação e
feedbacks de qualidade que recebemos, não teríamos sido capazes de realizar este trabalho.
Estamos profundamente agradecidos a todos pelo apoio e confiança que nos concederam.
“Eu acredito que às vezes são as pessoas que ninguém
espera nada que fazem as coisas
que ninguém consegue imaginar”
(Alan Turing)
Resumo
Este trabalho apresenta o desenvolvimento do aplicativo Carllet, que tem como principal
objetivo promover o controle financeiro para motoristas de aplicativos de corrida. A
plataforma oferece recursos como registro automático de corridas e gastos, cálculo de lucro
líquido e análise de despesas, possibilitando uma gestão simplificada das finanças Além
disso, os usuários podem definir metas de ganhos e receber alertas de gastos excessivos
com manutenções, tornando a ferramenta ainda mais eficaz. A equipe responsável pelo
projeto identificou um grande potencial de mercado para a solução, devido à sua utilidade,
facilidade de uso e alta demanda por parte dos motoristas.
Em suma, o Carllet é uma solução viável e eficiente para lidar com questões financeiras
no contexto de transporte urbano. Seu desenvolvimento foi baseado em uma pesquisa
de mercado e na identificação das necessidades dos usuários, garantindo uma plataforma
simples, funcional e adaptada às demandas do público-alvo.
Palavras-chaves: motoristas de aplicativo. gestão financeira. transporte urbano.

Abstract
This paper presents the development of the Carllet app, which aims to promote financial
control for ride-hailing drivers. The platform offers features such as automatic registration
of rides and expenses, calculation of net profit and expense analysis, enabling simplified
management of users’ finances. Additionally, drivers can set earning goals and receive
alerts for excessive expenses such as maintenance, making the tool even more effective. The
project team identified a significant market potential for the solution, due to its usefulness,
ease of use, and high demand from drivers.
In summary, Carllet is a viable and efficient solution for handling financial issues in
the context of urban transportation. Its development was based on market research and
identification of user needs, ensuring a simple, functional, and tailored platform for the
target audience.
Keywords: ride-hailing drivers, financial management, urban transportation.

Lista de ilustrações
Figura 1 – Evolução do Quantitativo de Trabalhadores da Gig Economy no Setor

de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figura 2 – Evolução do Rendimento Efetivo Médio Mensal, em Termos Reais (em
R$) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figura 3 – Evolução dos preços médios - GASOLINA COMUM . . . . . . . . . . 18
Figura 4 – Gráfico - Métricas Gerais . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 5 – Gráfico - Métricas de Desenvolvimento . . . . . . . . . . . . . . . . . . 32
Figura 6 – Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 7 – Modelo Entidade Relacionamento . . . . . . . . . . . . . . . . . . . . . 46
Figura 8 – Diagrama Entidade Relacionamento . . . . . . . . . . . . . . . . . . . 46
Figura 9 – Estimativa de horas necessárias para executar RF . . . . . . . . . . . . 60
Figura 10 – Estimativa de valor por hora dos recursos do projeto . . . . . . . . . . 61
Figura 13 – Custo Estrutura da Empresa (Mensal) . . . . . . . . . . . . . . . . . . 62
Figura 14 – Custo Manutenção do Serviço (Mensal) . . . . . . . . . . . . . . . . . . 62
Figura 15 – Custos (Projeção Até 9 Meses) . . . . . . . . . . . . . . . . . . . . . . 62
Figura 16 – Estimativa de ganho com publicidade gerado pela AdMob Google . . . 63
Figura 17 – Receitas (Projeção Até 9 Meses) . . . . . . . . . . . . . . . . . . . . . . 64
Figura 18 – Gráfico - Cenário Otimista . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 19 – Gráfico - Cenário Realista . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 20 – Gráfico - Cenário Pessimista . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 21 – Arquitetura Versão 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figura 22 – Arquitetura Versão 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figura 23 – Link Repositório GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figura 24 – Link Canal do YouTube . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figura 25 – Link Repositório SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figura 26 – Link Blog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Lista de tabelas
Tabela 1 – Métricas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Tabela 2 – Métricas de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 31
Lista de quadros
Quadro 1 – Inflação do Carro Novembro 2022 - Agência Autoinforme . . . . . . . 18

Quadro 2 – Aplicativos similares . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Quadro 3 – Comparativo de funcionalidades entre aplicativo Carllet e similares . 21
Quadro 4 – Estruturação de habilidades - Hard Skill . . . . . . . . . . . . . . . . 27
Quadro 5 – Atribuição de tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Quadro 6 – Atribuição de funções . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Quadro 7 – Sprint e respectivos objetivos . . . . . . . . . . . . . . . . . . . . . . 29
Quadro 8 – Histórias de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Quadro 9 – Regras de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Quadro 10 – Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Quadro 11 – Requisitos Não Funcionais . . . . . . . . . . . . . . . . . . . . . . . . 45
Quadro 12 – Entidades do Modelo Entidade Relacionamento . . . . . . . . . . . . . 47
Quadro 13 – Dicionário de Dados - Condutor . . . . . . . . . . . . . . . . . . . . . 48
Quadro 14 – Dicionário de Dados - Tipo Despesa . . . . . . . . . . . . . . . . . . . 48
Quadro 15 – Dicionário de Dados - Despesa . . . . . . . . . . . . . . . . . . . . . . 49
Quadro 16 – Dicionário de Dados - Ganho . . . . . . . . . . . . . . . . . . . . . . . 49
Quadro 17 – Dicionário de Dados - Marca . . . . . . . . . . . . . . . . . . . . . . . 49
Quadro 18 – Dicionário de Dados - Modelo . . . . . . . . . . . . . . . . . . . . . . 50
Quadro 19 – Dicionário de Dados - Veículo . . . . . . . . . . . . . . . . . . . . . . 50
Quadro 20 – Dicionário de Dados - Viagem . . . . . . . . . . . . . . . . . . . . . . 51
Quadro 21 – Top 10 maiores riscos de segurança para aplicativos web . . . . . . . . 53
Quadro 22 – Comparativo entre versões Free e Premium . . . . . . . . . . . . . . . 59
Quadro 23 – Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Quadro 24 – Histórico de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Lista de abreviaturas e siglas
API Application Programing Interface - Interface de Programação de

Aplicação - Citado em 33
CD Continuous Deployment - Implantação Contínua - Citado em 58
CDN Content Delivery Network - Rede de Distribuição de Conteúdo -
Citado em 33
CI Continuous Integration - Integração Contínua - Citado em 58
CI/CD Continuous Integration/Continuous Deployment - Integração Con-
tínua/Implantação Contínua - Citado em 53
CNH Carteira Nacional de Habilitação - Citado em 48
CVEs Common Vulnerability and Exposures - Vulnerabilidades e Exposi-
ções Comuns - Citado em 53
CVSS Common Vulnerability Scoring System - Sistema de Pontuação de
Vulnerabilidades Comuns - Citado em 53
CWEs Common Weakness Enumerations - Enumerações de Fraquezas
Comuns - Citado em 53
DER Diagrama Entidade Relacionamento - Citado em 45, 46
GNV Gás Natural Veicular - Citado em 20
GPS Global Positioning System - Sistema de Posicionamento Global -
Citado em 15, 63
IDE Integrated Development Environment - Ambiente de Desenvolvi-
mento Integrado - Citado em 58
Ipea Instituto de Pesquisa Econômica Aplicada - Citado em 16
JWT Json Web Tokens - Json Web Tokens - Citado em 54
LGPD Lei Geral de Proteção de Dados Pessoais - Citado em 45, 51, 54
MER Modelo Entidade Relacionamento - Citado em 45
MVP Minimum Viable Product - Produto Mínimo Viável - Citado em 33,
62, 66
OWASP Open Web Application Security Project - Projeto aberto de segurança
para aplicações Web - Citado em 52
POC Proof of Concept - Prova de Conceito - Citado em 33, 62, 66
SPA Single Page Application - Aplicativo de Página Única - Citado em
55
TIC Tecnologias da Informação e Comunicação - Citado em 22
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Análise da Concorrência . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Drive you . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.2 For driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.3 Rebu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.4 Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Serviços na Era Digital . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.1 Aplicativos para Motoristas Parceiros . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 Inseguranças sobre Ganhos Líquidos . . . . . . . . . . . . . . . . . . . . . 23
3 METODOLOGIAS DE GESTÃO DE PROJETO E DE DESENVOL-

VIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Formação da Equipe - Carllet . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Análise de Conhecimento dos Integrantes . . . . . . . . . . . . . . . . . . 26
3.2 Gestão do Tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Ferramentas Utilizadas para o Gerenciamento do Projeto . . . . . . 29
3.4 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 DESENVOLVIMENTO DO PROJETO . . . . . . . . . . . . . . . . 33
4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Histórias de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1.1 Descrição das Histórias de Usuário . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Regras de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.3 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.4 Requisitos Não Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Modelagem do Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1.1 MER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1.2 DER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1.3 Dicionário de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Critérios de Segurança, Privacidade e Legislação . . . . . . . . . . . 51
4.4.1 Segurança dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.2 Legislação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.1 Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.2 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.3 Estrutrura de Pastas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.4 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.5 APIs externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.6 Versionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.7 Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.6 Manutenibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.1 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.2 Análise Estática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.3 Integração Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.4 Sistema de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.5 Coding Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.6 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.7 Modelo de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.8 Viabilidade Financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8.1 Custos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8.1.1 Custos da Análise e Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 60
4.8.1.2 Custos da Estrutura da Empresa . . . . . . . . . . . . . . . . . . . . . . . . 61
4.8.1.3 Custos da Manutenção do Serviço . . . . . . . . . . . . . . . . . . . . . . . 62
4.8.2 Projeção de Receitas e Faturamento . . . . . . . . . . . . . . . . . . . . . 63
4.9 Fases de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.10 Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.11 Produto Mínimo Viável . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.12 Entrega Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.13 Histórico de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.14 Escolhas e Descartes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.15 Problemas Ocorridos no Gerenciamento e do Projeto . . . . . . . . . 71
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
GLOSSÁRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
APÊNDICES 78
APÊNDICE A – LINKS DO PROJETO . . . . . . . . . . . . . . . . 79
APÊNDICE B – ATAS DE REUNIÃO . . . . . . . . . . . . . . . . . 81

B.1 Ata de Reunião 25/02/2023 . . . . . . . . . . . . . . . . . . . . . . . 81
B.2 Ata de Reunião 25/02/2023 . . . . . . . . . . . . . . . . . . . . . . . 82
B.3 Ata de Reunião 21/03/2023 . . . . . . . . . . . . . . . . . . . . . . . 83
B.4 Ata de Reunião 22/04/2023 . . . . . . . . . . . . . . . . . . . . . . . 84
B.5 Ata de Reunião 06/05/2023 . . . . . . . . . . . . . . . . . . . . . . . 85
APÊNDICE C – POSTAGENS NO BLOG . . . . . . . . . . . . . . 87

C.1 Semana 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
C.2 Semana 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
C.3 Semana 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
C.4 Semana 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
C.5 Semana 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
C.6 Semana 6 - Produção a Todo Vapor . . . . . . . . . . . . . . . . . . 89
C.7 Semana 7 - Entrega do Desenho da Aplicação . . . . . . . . . . . . . 89
C.8 Semana 8 - Apresentação do Desenho da Aplicação . . . . . . . . . 90
C.9 Semana 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
C.10 Semana 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.11 Semana 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.12 Mudança de integrantes do grupo . . . . . . . . . . . . . . . . . . . . 91
C.13 Semana 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
APÊNDICE D – PROPOSTA INCICIAL . . . . . . . . . . . . . . . 94

14
1 Introdução
A automatização e robotização dos processos produtivos tem avançado nos últimos

anos, tendo como consequência a diminuição do trabalho precário(ANTUNES, 2020).
Dentre os avanços tecnológicos surgidos na última década, pode-se citar a crição
de aplicativos diversos com função de intermediar a prestação de serviços voltados para
corridas particulares, como Uber, 99, Cabify, inDriver.
Segundo dados do IPEA (2022), no quarto trimestre de 2021 havia aproximadamente
945 mil pessoas exercendo a função de motorista de aplicativo e taxista no Brasil. Juntas,
Uber e 99 já atenderam mais de 48 milhões de passageiros no Brasil. De 2014 até 2021, a
Uber intermediou mais de 6,7 bilhões de viagens e entregas somente no Brasil.
Com estas novas modalidade de trabalho, o uso do termo uberização tem sido
utilizado para definir o serviço realizado via demandas por aplicativos de intermediação,
devido à grande relevância nesta modalidade de trabalho do aplicativo Uber. A uberização
consiste na intermediação de prestação de serviços entre trabalhadores e consumidores por
meio de aplicações (empresas) (BARBOSA, 2020).
Cada empresa ou start-up possui suas exigências e termos, além de descontos
e taxas aplicadas a cada serviço realizado. Os motoristas têm de arcar com gastos de
abastecimento e manutenção, sem garantia de jornada e remuneração (ANTUNES, 2020).
O último levantamento da Inflação do Carro, realizado pelo AutoInforme (2022),
indica que o gasto médio mensal com o automóvel, em Novembro de 2022, considerando
um uso cotidiano, chega a R$ 2.015,73(dois mil e quinze reais e setenta e três centavos).
Como motoristas de aplicativos usam o automóvel como meio de trabalho e gastam mais
tempo utilizando o carro, o valor de gastos tende a ser maior.
Ao tornar-se motorista parceiro destas aplicações, surge a questão sobre a gestão
do real ganho, já que diversas variáveis - como o gasto com abastecimento, manutenções,
tempo parado e outros - podem influenciar no ganho líquido, impactando no planejamento
financeiro.
1.1 Objetivos
A aplicação irá contribuir para que motoristas avaliem de forma prática e descom-
plicada seus ganhos e gastos na prestação de serviço para aplicativos parceiros.
Pode-se listar os seguintes Objetivos Específicos:
Capítulo 1. Introdução 15
• Falicitar a gestão dos gastos relacionados ao abastecimento do automóvel;
• Falicitar a gestão dos gastos relacionados à manutenção do automóvel;
• Falicitar a gestão dos lucros reais relacionados aos serviços prestados via aplicativos
de mobilidade;
• Proporcionar um melhor planejamento ao motorista por meio do estabelecimento de

metas diárias;
• Contribuir para que motoristas parceiros de aplicativos diminuam sua insegurança e

incerteza em relação aos lucros reais advindos de seu serviço prestado.
1.2 Solução Proposta

A partir da inserção do valor que o motorista pretende obter em um determinado
período de tempo (mês, por exemplo), juntamente com outras informações, tais como dias
da semana e faixas de horários em que costuma trabalhar, são geradas metas diárias para
que o valor estabelecido seja atingido. O condutor consegue acompanhar o seu desempenho
por meio da visualização da comparação de valores entre o montante esperado e o valor
gerado pelo modelo preditivo contido na aplicação, que tem como base valores registrados
no banco de dados, os quais foram inseridos também pelo próprio motorista. Viabilizando
este recurso, esta funcionalidade se apresenta então como o diferencial da aplicação Carllet.
Ademais, através do uso do Global Positioning System (GPS) do celular, o motorista
consegue visualizar sua posição no mapa, e o aplicativo, inclusive, realiza o cálculo total de
quilômetros rodados por período. Esta função, por vez, possibilita as outras funcionalidades
previstas.
A inclusão de informações sobre o abastecimento realizado no automóvel (valor e
datas), pemitirá que a aplicação informe uma estimativa de custo/litros por percurso e
quilômetros rodados.
Através da inclusão de informações sobre manutenção do autómovel (calibragem,
troca dos pneus, troca das velas, do óleo, dos filtros de ar, etc.), a aplicação faz o envio de
uma notificações ao motorista para realização das referidas manutenções.
Com os dados relativos ao abastecimento e à manutenção, a aplicação oferece
a visualização em um dashboard dos gastos, assim como o desempenho do automóvel,
utilizando da análise descritiva.
1.3 Justificativa
Segundo dados do IPEA (2022), no quarto trimestre de 2021 havia aproximadamente
945 mil pessoas exercendo a função de motorista de aplicativo e taxista. A partir do
primeiro semestre de 2020, quando iniciaram as restrições de locomoção no Brasil referente
a pandemia da covid-19, houve uma queda no número de pessoas exercendo a mesma
função. O número de motoristas voltou a subir no terceiro trimestre de 2020, o que pode
ser visualizado na Figura 1:
Figura 1 – Evolução do Quantitativo de Trabalhadores da Gig Economy no Setor de

Transporte
figuras/evolucao-quantitativo-transporte.png
Fonte: IPEA (2022)
Entre 2020 e 2021, período da pandemia da covid-19, foi estimado que existiam
mais de 14 milhões de brasileiros desempregados (IBGE, 2023). A pesquisa do Serasa
(2023), publicada em janeiro de 2023 e focada no Brasil, informa que 23% dos entrevistados
passaram a utilizar o carro como ferramenta de trabalho, comparando o período pré e
pós pandêmico. O estudo da consultoria ACCENTURE (2023), a pedido do aplicativo
Uber, realizou entrevistas com 4.941 motoristas e entregadores de seis países (Austrália,
Brasil, Canadá, Estados Unidos, França e Reino Unido) e relatou que 62% dos motoristas
se cadastraram no aplicativo durante a pandemia pois não conseguiram encontrar outro
trabalho e 73% dos motoristas e entregadores concordaram que a plataforma funcionou
como uma rede de proteção.
O estudo realizado pelo Ipea ainda registra um comparativo em relação à renda
destes trabalhadores ao longo dos anos pré e pós covid. Pode-se visualizar, na Figura 2,
que houve uma queda no rendimento dos motoristas de aplicativo e taxistas. Se, por um
lado, o rendimento observado no último trimestre de 2021 - em torno de R$ 1,9 mil - é
superior ao valor recebido em meados de 2020 - em torno de R$ 1,5 mil - ainda assim é
bastante inferior aos R$ 2,7 mil recebidos, em média, no início de 2016.
Figura 2 – Evolução do Rendimento Efetivo Médio Mensal, em Termos Reais (em R$)
figuras/evolucao-rendimento-mensal.png
Fonte: IPEA (2022)
Como cada empresa possui suas exigências e termos, além de descontos e taxas
aplicadas a cada serviço realizado, o rendimento efetivo é impactado não somente por
estas variáveis, mas também pelo preço de abastecimento e manutenção do carro.
No levantamento realizado pela AutoInforme (2022), o combustível tem uma parcela
elevada na contribuição de gastos com o uso do automóvel, chegando a 29,27% em novembro
de 2022. Para motoristas de aplicativos, o gasto tende a ser maior pelo tempo rodado com
o carro. Em julho de 2021, foi estimado que a gasolina representa entre 40% e 50% do
gasto diário de um motorista de aplicativo, e a taxa paga aos aplicativos, em torno de 25%
(G1, 2021).
A variação nos preços de combustíveis traz um impacto direto no lucro do motorista.
Em junho de 2022, o preço médio da gasolina comum chegou a R$ 7,25 (ANP, 2023) e
segundo a AutoInforme (2022), neste período a participação do gasto em combustível
chegou a 38% de um total de R$ 2.070,75, como pode ser visto no Quadro 1.
Quadro 1 – Inflação do Carro Novembro 2022 - Agência Autoinforme
Item Variação Participação Valor

Combustíveis 4,32% 29,27% [1]
Peças de reposição 0,38% 15,51% [1]
Serviços 1,10% 18,33% [1]
Impostos 0,00% 12,93% [1]
Seguros 2,80% 23,96% [1]
[1] [1] 100,00% R$ 2015,73
Fonte: Agência Autoinforme 2022. Adaptado pelos autores.
Como observado no Quadro 1, o combustível tem uma parcela elevada na contri-

buição de gastos com o uso do automóvel, chegando a 29,27% em novembro de 2022.
Como pode ser observado na Figura 3, que representa a variação no preço médio
da gasolina nos últimos 12 meses, infere-se que a previsão de ganhos pode ser instável,
visto que são os motoristas que arcam com o custo do abastecimento.
Figura 3 – Evolução dos preços médios - GASOLINA COMUM
figuras/bi_anp_gasolina.png
Fonte: ANP (2023)
Em junho de 2022, o preço médio da gasolina comum chegou a R$ 7,25 como pode
ser observado na Figura 3. Em paralelo, considerando o mesmo período, o rendimento
médio mensal de motoristas de aplicativos e taxistas chegou ao valor mais baixo desde
a medição, valor menor que R$ 1.500,00 mensais, no segundo semestre de 2020, como
visualizado na Figura 2.
Ao mesmo tempo que a retomada do crescimento de serviços de motoristas por
aplicativos, evidenciada na Figura 1 confirma o amplo mercado em crescimento que temos
como alvo deste projeto, o declínio do rendimento mensal deste setor comparado antes
do período pandêmico, demonstrado pela Figura 2, deixa claro a crescente necessidade
dos motoristas de gerenciarem suas rendas e de encontrarem alternativas para minimizar

gastos.
1.4 Análise da Concorrência

Na análise da concorrência buscou-se por sistemas que tivessem um mesmo propósito,
o de ser uma ferramenta de auxílio a motoristas de aplicativo, sobretudo em termos de
gestão financeira. Assim sendo, foram consideradas na análise as aplicações: Driveyou, For
driver e Rebu.
No Quadro 2, constam as informações: empresa responsável pelo aplicativo, para
qual plataforma foi desenvolvida e a quantidade de downloads:
Quadro 2 – Aplicativos similares
Aplicação Empresa Plataforma Downloads

Driveyou Driveyou WEB —-
For driver NERD Tecnologia Mobile (Android) 10 mil+
rebU Marlon Luz Mobile (Android) 500 mil+
Fonte: Google Play Store. Adaptado pelos autores
1.4.1 Drive you

Plataforma paga no valor de R$ 29,90/uma única vez (consultado em abril de
2023), em formato para Web, que se propõe a ser um sistema de controle financeiro para
motoristas de aplicativo, taxistas e motoristas independentes (DRIVEYOU, 2023). Dentre
seus recursos, a plataforma oferece:
• Controle financeiro para gestão de gastos, lucros e investimentos;
• Comunidade para interação entre motoristas;
• Premiações para usuários, por meio de sorteios mensais e descontos em produtos e

serviços.
1.4.2 For driver

O For Driver é um aplicativo mobile gratuito com foco em ser um organizador
financeiro para motoristas profissionais (DRIVER, 2023). Desta forma, suas funcionalidades
são:
• Definição de metas por parte do motorista;
• Gestão financeira, com gerenciamento de recebimentos e gastos;
• Gráficos que informam o rendimento mensal.
1.4.3 Rebu
O Rebu é um aplicativo mobile desenvolvido para motoristas profissionais, cuja
proposta é proporcionar maior segurança e auxílio no cotidiano do motorista, bem como
promover o controle de suas finanças. Conta com duas versões, uma gratuita e outra
Premium, sendo que a Premium oferece maior amplitude de funcionalidades comparativa-
mente à versão gratuita (REBU, 2023). Algumas das funcionalidades da versão gratuita
são:
• Função ’Alerta de Risco’, que notifica o motorista caso ele se aproxime de uma área
de risco;
• Mapas com diversos indicadores, tais como: postos com Gás Natural Veicular (GNV),
sanitários gratuitos, melhor região próxima para receber corridas, locais onde houve
furto de carros nas últimas 24 horas;
• Função ’Alerta de Pânico’, que envia um alerta a autoridades ou outros motoristas,

caso o usuário se encontre em situação de perigo.
1.4.4 Comparativo
Foram levantadas as principais funcionalidades das aplicações consideradas na
análise comparativa e elaborado o Quadro 3, para melhor visualização dos requisitos que
cada aplicação implementa e no quê se destaca:
Quadro 3 – Comparativo de funcionalidades entre aplicativo Carllet e similares
Funcionalidade Carllet Driveyou For driver Rebu

Gestão ganhos X X X X
Gestão gasto despesas X X X X
Dashboard descritivo X X X X
Android X X X
Cálculo de km rodados via GPS X X
Estimativa custo/litro por km X
Estipulação de meta diária X
Análise preditiva X
UI/UX simplificado X
IOS X
Fonte: Elaborado pelos Autores
Desta forma, o principal diferencial do aplicativo Carllet, em comparação aos

aplicativos similares, é proporcionar valores de metas diárias para que o motorista tenha
um melhor planejamento financeiro e mais segurança em relação aos seus ganhos, bem
como o acompanhamento de desempenho por meio de uma comparação entre o valor
pretendido e o valor gerado através do uso de análise preditiva.
1.5 Estrutura do Trabalho

O presente trabalho é estruturado da seguinte forma:
• Capítulo 1: Contém a introdução, definição do problema, justificativa do trabalho e

proposta de solução do projeto;
• Capítulo 2: Contém a revisão de literatura dos principais termos do projeto;
• Capítulo 3: Contém os assuntos que abordam o gerenciamento do projeto;
• Capítulo 4: Contém os assuntos que abordam o desenvolvimento do projeto;
• Capítulo 5: Contém a conclusão dos pontos principais do texto
• Apêndices: Contém os links do projeto, atas de reunião,publicações realizadas no

blog da equipe e proposta inicial do Carllet
22
2 Revisão da Literatura
Esta seção foi dividida em duas partes. Na primeira, é apresentada uma discussão
sobre as mudanças na prestação de serviços na era digital. Na segunda são apresentadas
as principais plataformas de transporte individual.
2.1 Serviços na Era Digital

As novas Tecnologias da Informação e Comunicação (TIC) ampliam a automatização
e robotização dos processos produtivos (ANTUNES, 2020). Apresentada como uma variante
do neo-empreendedorismo, a expansão de possibilidades para pequenos negócios através da
expansão das TIC é também bastante difundida pelo Banco Mundial (ANTUNES, 2020).
Estas tendências em curso, segundo Antunes (2020), demonstram a ampliação do
trabalho precário, onde o autor define o termo uberização como: "o processo no qual as
relações de trabalho são crescentemente individualizadas e invisibilizadas", assumindo
assim a aparência de prestação de serviços e obliterando as relações de assalariamento e
de exploração do trabalho.
Desta forma, os aplicativos quase sempre consideram os trabalhadores como autô-
nomos, remunerando-os por serviço realizado, sem nenhuma garantia de jornada e remune-
ração. (ANTUNES, 2020)
Apesar de considerar quase sempre os motoristas como autônomos, estes devem
seguir as regras da plataforma, porém não somente o tempo de jornada e remuneração são
impactados por intermédio da aplicação, mas também as condicoes de trabalho.
O relatório do Fairwork (2021), projeto executado pelo Oxford Internet Institute,
University of Oxford e pelo Berlin Social Science Center focado no Brasil, analisa como as
principais plataformas no país se relacionam com os princípios de trabalho definido como
"decente". Em uma escala de 0 a 10 pontos, foram analisados 5 princípios: Condições Justas,
Pagamento Justo, Contratos Justos, Gestão Justa e Representação Justa. O resultado da
pesquisa entre as empresas Uber, 99, Ifood, UberEats e Rappi e GetNinjas demonstra
um dado preocupante. Numa escala de 0 a 10 pontos, a pontuação máxima foi 2 pontos,
atingidos pelo IFood e 99. A Uber atingiu 1 ponto, enquanto UberEats, Rappi e GetNinjas
ficaram com 0 pontos.
Capítulo 2. Revisão da Literatura 23
2.1.1 Aplicativos para Motoristas Parceiros

Na última década foram criados por empresas diversos aplicativos para intermediar
a prestação de serviços voltados para corridas particulares, como Uber, 99 taxi, Cabify,
inDriver.
Segundo a própria Uber, desde seu lançamento no Brasil em 2014 e até 2021, a
mesma intermediou mais de 6,7 bilhões de viagens e entregas, chegando a mais de 30
milhões de usuários no Brasil (UBER, 2023).
A 99 taxi foi fundada em 2012 e se tornou o primeiro unicórnio brasileiro em 2018,
ao ser vendida para a chinesa Didi Chuxing. O seu website, acessado em abril de 2023,
informa que conectaram 18 milhões de passageiros a 600 mil motoristas, atingindo em
janeiro de 2020 a marca de 20 bilhões de viagens no mundo (99, 2023).
Com o objetivo de garantir mais segurança e preços justos a motoristas e passageiros,
a Prefeitura da Cidade de São Paulo, lançou em março de 2023 o mobizapSP. É um
aplicativo de mobilidade urbana, que oferece benefícios para a população. Possui taxa fixa
de administração de 10,95% para o motorista, monitoramento de todos os veículos em
tempo real, e não aplica a tarifa dinâmica para o passageiro (MOBIZAPSP, 2023).
2.1.2 Inseguranças sobre Ganhos Líquidos

Desde seu lançamento no Brasil em 2014 até 2021, a Uber repassou pelo menos R$
76 bilhões a motoristas e entregadores parceiros. No ano de 2021 a Uber gerou um valor
econômico estimado em R$36 bilhões para a economia brasileira, equivalente a 0,4% do
PIB (UBER, 2023).
A Agência Autoinforme realiza um levantamento intitulado "Inflação do Carro"que
levanta os custos que o motorista tem para andar de carro e realizar a manutenção
(AUTOINFORME, 2022). O último levantamento referente a novembro de 2022 aponta
que mensalmente são gastos R$ 2.015,73 em custos com o uso e manutenção do automóvel,
Desta forma, os aplicativos quase sempre consideram os trabalhadores como autôno-
mos, os remuneram por serviço realizado, sem nenhuma garantia de jornada e remuneração,
tendo de arcar com as despesas como seguro, gastos com manutenção, abastecimento, ali-
mentação, enquanto a empresa entermediária se beneficia do valor gerado pelos motoristas,
sem nenhuma regulação social do trabalho (ANTUNES, 2020).
Considerados como autônomos, mas devendo seguir as regras aplicadas nas plata-
formas, a greve mundial de motoristas Uber realizada em maio de 2019, onde o Brasil teve
participação e foi citada pela mídia internacional como The New York Times (2019) e The
Guardian (2019), demonstra uma organização da classe para exigir melhores condições e
remunerações pelos serviços realizados pela plataforma.
Capítulo 2. Revisão da Literatura 24
Em 21 de março de 2023, a Uber atualizou seus Termos de uso. Foi incluído no

Parágrafo 8.3 a proibição de acesso às telas e prints, onde o aplicativo bloqueia o recurso
de captura de tela, além disso, também é proibida a divulgação dos relatórios e dados
extraídos na plataforma.
Finalmente, você reconhece e confere força probatória plena: (i) às telas

sistêmicas do aplicativo da Uber, inclusive as capturas de tela coletadas
em dispositivos móveis; e (ii) aos relatórios e dados extraídos da pla-
taforma interna da Uber, consentindo que tais documentos constituem
meio de prova válido para todos os fins, nos termos do artigo 190 do
Código de Processo Civil e artigo 18, I, da Lei Federal 13.874/2019.
Esta mudança nos Termos e Condições, pode ser entendida como mais uma forma
de inibir que os motoristas compartilhem seus ganhos com terceiros, e que de alguma
forma sejam questionadas as taxas e valores repassados pela plataforma.
25
3 Metodologias de Gestão de Projeto e de

Desenvolvimento
No cenário de desenvolvimento deste projeto decidimos trabalhar utilizando fra-

mework Scrum, com possíveis modificações para melhor suprir as necessidades da equipe.
Inclusive adotando o quadro do Kanban para dar melhor visibilidade na progressão
das atividades para toda a equipe.
3.1 Formação da Equipe - Carllet

A formação da equipe do projeto se iniciou no primeiro dia de aula. A equipe é
composta por 4 integrantes do curso de Análise e Desenvolvimento de Sistemas do Instituto
Federal - Campus São Paulo:
• Débora Peixoto dos Santos: atua há mais de 1 ano na área de dados. Sua primeira
experiência relacionada à análise de dados foi no Museu de Arte Moderna de São
Paulo, no qual foi responsável por desenvolver um relatório diagnóstico sobre a
documentação da instituição por meio de estudo de amostragem. Posteriormente,
foi estagiária de Bussines Intelligence na Prodam, Empresa de Tecnologia da In-
formação e Comunicação do Município de São Paulo, onde atuava principalmente
com visualização e análise de dados, tanto para projetos externos quanto internos.
Atualmente faz parte do time data science na Farmtech, empresa de crédito digital
rural, na qual apoia a estratégia de negócio da empresa com tecnologia e estatística,
sendo responsável por auxiliar no processo de análise e visualização de dados para
insights. As principais ferramentas que possui conhecimento pertinentes à área em
que atua são SQL, Power BI, DBeaver, SQL Server e Python (Pandas e Numpy).
• Gabriela Dias Dutra: atuou como estagiária de engenharia de dados na empresa

Accenture e com gestão de projetos em uma start-up de recursos humanos. Tem
experiência com ferramentas de data warehouse, visualização de dados e bancos de
dados, além de utilizar plataformas de nuvem como Azure. Têm sólida experiência em
atuar em equipes ágeis, que utilizam o Scrum e Kanban como auxílio para o projeto.
Atualmente dedica-se a estudar e aplicar os conhecimentos em desenvolvimento
front-end com HTML/CSS e JavaScript além de frameworks como o React. Tem
interesse em contribuir com o projeto na parte de prototipação e estilização.
Capítulo 3. Metodologias de Gestão de Projeto e de Desenvolvimento 26
• João Pedro Vanderlei: desenvolvedor full-stack atualmente estagiando no Itaú-

Unibanco desenvolvendo API’s em .NET, Automação e ?? em Python. Anteriormente
atuou como freelancer em projetos de desenvolvimento web. Possui conhecimento
em React, Node.js, .Net, MongoDB, SQL Server, Google Cloud, Python e Selenium.
No banco desenvolveu conhecimentos em metodologias ágeis, principalmente Scrum
e na definição de objetivos para equipes utilizando OKR’s.
• Pedro Henrique Beserra Lima: desenvolvedor full-stack com 2 anos de experiência

em tecnologias como React, React Native, C#, .NET, CSS3, Javascript, Next.js,
Styled-Components, Tailwind e APIs REST. Atualmente trabalha na DeÔnibus,
o segundo maior e-commerce de passagens rodoviárias do Brasil, onde aplica suas
habilidades em uma empresa de grande porte e complexidade. No passado, exerceu
atividades como desenvolvedor full-stack, para a comunidade zen-budista Daissen
Ji, onde teve a oportunidade de aprimorar os seus conhecimentos como desenvolver
mobile e desenvolver diferentes soft skills que são extremamente importantes no
mercado, como comunicação, proatividade, trabalho em equipe e senso de valor.
Pedro é capaz de trabalhar em todas as camadas de uma aplicação, desde o front-end
até o back-end. Ele tem experiência em desenvolvimento de aplicações web e mobile,
integração de sistemas e construção de APIs.
3.1.1 Análise de Conhecimento dos Integrantes

Para melhor distribuição de tarefas, realizamos um levantamento dos conhecimentos
técnicos e relacionados ao desenvolvimento aplicando metodologias ágeis.
Para construção do Quadro 4, cada membro teve de elencar seus conhecimentos
numa escala de:
0: Não tenho conhecimentos do que é.
1: Já ouvi falar, mas não sei como opera.
2: Já utilizei, mas não sou capaz de atuar independentemente.
3: Sou capaz de desenvolver soluções básicas sem auxílio.
4: Sou capaz de desenvolver soluções complexas.
5: Sou especialista em tal campo.
A distribuição de atividades foi composta de acordo com os conhecimentos e habilidades

relacionadas às tarefas. O Quadro 5 indica a atribuição das tarefas entre os recursos do
projeto.
Quadro 4 – Estruturação de habilidades - Hard Skill
Hard Skill Débora Gabriela João Pedro

Back-end 3 3 4 4
Front-end 3 3 3 5
Banco de dados 4 3 3 3
Deploy/CI/CC 2 2 2 2
Arquitetura 2 2 3 3
Análise de requisitos 3 3 2 2
Documentação 3 4 3 3
Criar user story/tasks 3 3 3 3
Testes Unitários 3 2 2 3
Testes Estáticos 2 2 2 2
Seguranca 2 2 2 2
Metodologias ágeis 3 5 4 3
Quadro 5 – Atribuição de tarefas
Atividade Débora Gabriela João Pedro

Back-end x x
Banco de dados x
Blog x x
Documentação x x x x
Front-end x x x
Jira board x x x x
Vídeos x x
Fonte: Elaborado pelos autores
A distribuição de funções foi composta de acordo com os conhecimentos e habilidades

relacionadas às tarefas. O Quadro 6 indica a atribuição das tarefas entre os recursos do
projeto.
Quadro 6 – Atribuição de funções
Atividade Débora Gabriela João Pedro

PM x
Scrum x
Arquiteto x x
Analista de requisitos x x
DBA x
Desenvolvedor Full-Stack x x x x
3.2 Gestão do Tempo

3.2.1 Sprint
O acompanhamento das tarefas é realizado nas dailys e através dos boards no
Jira Projects. O Quadro 7 mostra todas as Sprints de entrega do MVP e seu respectivo
objetivos, estabelecidos com base nas datas de entrega e considerando os requisitos que
serão entregues em cada escopo.
Quadro 7 – Sprint e respectivos objetivos

SPRINT OBJETIVO
SPRINT 1 (15/02 - 21/02) Formação do grupo e discussão sobre temas
SPRINT 2 (22/02 - 28/02) Reunião com professores e definição do tema
Finalizar documento e apresentação para a Entrega da
SPRINT 3 (01/03 - 07/03)
Apresentação da Proposta (07/03)
SPRINT 4 (08/03 - 14/03) Iniciar documentação para o desenho da aplicação
Definir regras de negócio, requisitos funcionais e não
SPRINT 5 (15/03 - 21/03)
funcionais
Definição arquitetura, modelagem de banco de dados,
SPRINT 6 (22/03 - 28/03) pesquisa sobre análise financeira, segurança, e revisão de
literatura
Configuração de setup, revisar documentação e tópicos
SPRINT 7 (29/03 - 04/04)
pendentes para Entrega do Desenho da Aplicação (04/04)
Configuração de ambiente Google Cloud, preparação
SPRINT 8 (05/04 - 11/04)
para Entrega Apresentação do Desenho da Aplicação
Implementação do RF03, criação BD e preparação para
SPRINT 9 (12/04 - 18/04)
Entrega Apresentação do Desenho da Aplicação (18/04)
Deploy Cloud, Testes de conectividade e realizar Apre-
SPRINT 10 (19/04 - 25/04)
sentação da POC (25/04)
SPRINT 11 (26/04 - 02/05) Implementação RF02
Implementação RF04 e Revisar Documentação do Pro-
SPRINT 13 (10/05 - 16/05)
jeto para entrega (16/05)
SPRINT 15 (24/05 - 30/05) Testes de segurança
SPRINT 16 (31/05 - 06/06) Testes Integrados, Construção da SPA
SPRINT 17 (07/06 - 13/06) Entrega da Apresentação Final do Projeto (13/06)
SPRINT 18 (14/06 - 20/06) Entrega da Apresentação Final do Projeto (20/06)
Correções levantadas para realizar entrega Final do Pro-
SPRINT 19 (07/06 - 20/06)
jeto (20/06)
3.3 Ferramentas Utilizadas para o Gerenciamento do Projeto

Jira: a ferramenta serve para gerenciar as tarefas relacionadas ao projeto. Foram
criados 2 boards, um voltado para a gestão do desenvolvimento, a partir das histórias de
usuários, e outro boards para a gestão das entregas de documentação, apresentação, blog e
Youtube, além do próprio desenvolvimento.
3.4 Métricas
Com o objetivo de demonstrar a evolução do projeto Carllet, a equipe realizou
extrações de métricas abordando alguns aspectos que permitem medições. As métricas
foram definidas em:
Métricas Gerais
A Tabela 1 contém as métricas gerais para cada mês de desenvolvimento do projeto.
Elas englobam todos os arquivos presentes no repositório da equipe. É notável o aumento
nas quantidades de versões e de requisitos dado o progresso do projeto.
Tabela 1 – Métricas do Projeto

Métrica Fevereiro Março Abril Maio
Atas de Reuniões 1 2 1 1
Total de Commits 2 3 1 1
Versões de Documentação 0 2 4 7
Arquivos 4 2 7 6
Links Compartilhados 12 61 7 18
Imagens 4 11 32 30
Publicações no Blog 1 7 5 4
Regras de Negócio 0 6 6 7
Requisitos Funcionais 0 11 11 12
Requisitos Não-Funcionais 0 5 5 5
Vídeos produzidos 0 1 1 1
A seguir, a representação gráfica dos dados apresentados na tabela X:

Figura 4 – Gráfico - Métricas Gerais
figuras/metricasGerais.png
Métricas de Desenvolvimento
A Tabela 2 contém as métricas refentes ao desenvolvimento do front-end e backend,
para cada mês de desenvolvimento. Analisando a tabela é possível notar um maior
crescimento entre os meses de abril e maio, pois foi o momento em que o código, junto a
documentação, foram os focos de desenvolvimento.
Tabela 2 – Métricas de Desenvolvimento

Métrica Fevereiro Março Abril Maio
Total de Commits 2 3 1 1
Linhas de Código 3 30 31.801 14.742
Por fim, a representação gráfica dos dados apresentados acima acerca do desenvolvimento
do projeto.
Figura 5 – Gráfico - Métricas de Desenvolvimento
figuras/metricasDev.png

33
4 Desenvolvimento do Projeto
Ao longo do capítulo são apresentadas as definições para implantação da aplicação.

Através da escrita das Historias de usuário foi possível levantar os Requisitos Funcionais, não
Funcionais e as Regras de Negócio necessárias para implantação do projeto. A partir disso
foram definidas as Tecnologias Utilizadas, os Critérios de Segurança, Manutenibilidade,
a Modelagem do Banco de Dados e o Desenho da Arquitetura. Paralelamente com estas
definições, foi realizado o estudo de Viabilidade Financeira. O levantamento e os dados
apresentados neste capítulo consideram as três Fases de Entrega previstas (POC, MVP e
Entrega Final).
4.1 Arquitetura
A arquitetura do sistema foi elaborada baseada na infraestrutura Azure disponibili-
zada pela Microsoft , como pode ser observado na Figura 6:
Figura 6 – Arquitetura
figuras/arquitetura-carllet.png
O sistema foi pensado como uma arquitetura client-server, em que o back-end é uma
Application Programing Interface (API), contemplando a regra de negócio da aplicação.
O Cliente é o aplicativo mobile, desenvolvido em React Native que pode ser acessado
tanto em dispositivos Android quanto IOS e que consome a API fornecida pelo back-end.
Para os arquivos estáticos da aplicação, como imagens, arquivos de usuários entre
outros, utilizou-se o Azure CDN (Content Delivery Network), Ao utilizá-lo, não há fluxo
desnecessário no banco de dados com conteúdos estáticos que não possuem uma alteração
tão dinâmica quanto os dados que giram em torno da regra de negócio principal.
Capítulo 4. Desenvolvimento do Projeto 34
O cliente fica disponível nas lojas de cada plataforma (App Store e Play Store),
assim qualquer usuário que desejar utilizar a aplicação, tem fácil acesso e um local de
download que verifica a integridade e veracidade da aplicação.
A Azure fornece instâncias de máquinas virtuais por meio de sua App Service,
permitindo que a aplicação utilize os recursos necessários para sua carga de trabalho e
escalonamento automático. A plataforma utiliza o fluxo do Docker para a configuração
e build da aplicação, permitindo que um contêiner seja executado por meio do Azure
Container Instances.
Com a necessidade de exibir notificações aos usuários, recorre-se a um worker
service que execute a cada 3 minutos. Baseado no Cron Expression, o worker service
verifica os dados do banco de dados, com a atualização de informações do usuário, e chama
o notification push.
4.2 Análise de Requisitos

Para definir os Requisitos Funcionais, Requisitos não Funcionais e as Regras de
Negócio, foram levantadas em primeiro momento as Histórias de usuário necessárias para
implementar a aplicação, considerando as três fases de entrega. Com a escrita das Histórias
de usuário foi possível mapear os Requisitos funcionais necessários para implementá-las,
possibilitando a definição dos requisitos não funcionais e as regras de negócio. Desta forma,
a Análise de Requisitos foi a base para a definição do escopo, tecnologias utilizadas, a
modelagem do banco de dados e o desenho da arquitetura.
4.2.1 Histórias de Usuário

Foram mapeadas 18 Histórias de Usuário, e o Quadro 8 as relacionam com os 11
Requisitos Funcionais levantados para sua implementação, exceto a história de usuário
US16 pois o desenvolvimento da SPA não está diretamente relacionado aos requisitos das
aplicação, sendo um complemento para garantir a qualidade do produto.
Quadro 8 – Histórias de Usuário
Requisito
Código Nome História de Usuário Funcional
Relacionado
US01 Criar Conta RF01
US02 Acessar a aplicação RF01, RF02
US03 Autenticar o usuário RF02
US04 Visualizar localização no mapa via GPS RF03
US05 Registrar início de locomoção do carro RF04
US06 Registrar abastecimento do carro RF06
US07 Registrar ganhos no app parceiro RF07
US08 Registrar manutenções com o carro RF08
US09 Visualizar total de km rodados por dia/período RF04, RF05
US10 Visualizar abastecimento do carro por dia/período RF06, RF09
US11 Visualizar ganhos no app parceiro por dia/período RF07, RF09
Visualizar gastos com manutenção do carro por
US12 RF08, RF09
dia/período
Visualizar uma estimativa de gasto com gasolina por dia RF04, RF05,
US13
e km rodados RF06, RF09
RF06, RF07,
US14 Visualizar Dashboard
RF08, RF10
US15 Notificação manutenção RF08, RF11
US16 Página Web (SPA) N/A
US11 Gerenciar dados para meta RF11
US18 Comparação de Valores RF12
4.2.1.1 Descrição das Histórias de Usuário
A descrição das Histórias de Usuário foi elaborada a partir da definição "Como

[persona], eu [quero], [para]". O levantamento dos critérios de aceitação contribui para que
a História seja concluída atendendo todos requisitos funcionais, não funcionais e regras de
negócio relacionados a mesma.
1. US01 - Criar Conta

Descrição: Como motorista, eu quero criar uma conta no aplicativo Carllet para
ter acesso aos serviços disponíveis.
Requisitos relacionados: RF01, RN01
Critérios de aceitação:
• O motorista deve preencher corretamente todos os campos obrigatórios.

• O motorista deve concordar com os Termos de Uso para prosseguir com a
criação da conta.
• O campo de data de nascimento deve ser validado pelo sistema para garantir
que o motorista seja maior de 18 anos.
• O motorista deve ser capaz de criar uma conta de usuário após fornecer todas
as informações necessárias.
• O motorista deve ser capaz de acessar todas as funcionalidades do sistema após
criar a sua conta.
• A aplicação deve notificar o motorista se a criação da conta obteve sucesso ou
erro.
2. US02 - Acessar a aplicação

Descrição: Como motorista, eu quero acessar as funcionalidades do sistema para
poder utilizar as ferramentas e serviços oferecidos pelo aplicativo Carllet.
Requisitos relacionados: RF01, RF02
• O motorista deve ser capaz de logar na aplicação inserindo suas credenciais

(e-mail e senha) corretamente na tela de login.
• Após o motorista fazer login com sucesso, a aplicação deve direcioná-lo para a
página inicial, onde as funcionalidades do aplicativo estarão disponíveis.
• O motorista deve ser capaz de gerenciar seu perfil de usuário, alterando infor-
mações.
• O motorista deve ser capaz de sair da aplicação encerrando a sessão atual, e ser
direcionado para a tela de login após o logout.
3. US03 - Autenticar o usuário

Descrição: Como motorista, eu quero recuperar meus dados esquecidos, para que
eu possa acessar a minha conta novamente.
Requisitos relacionados: RF01,RF02
• O motorista deve ser capaz de autenticar-se com segurança na aplicação.

• O motorista deve ser informado após 3 tentativas de entrada de uma senha
incorreta que é necessário redefinir a senha.
• Caso o motorista esqueça as credenciais de acesso(e-mail e senha) o sistema
deve redirecioná-lo para uma tela de recuperação.
• O motorista deve receber no e-mail cadastrado as informações para redefinição
de senha.
4. US04 - Visualizar localização no mapa via GPS

Descrição: Como motorista, eu quero visualizar a minha localização atual, para
que eu possa saber onde estou iniciando uma corrida.
Requisitos relacionados: RF03
• O motorista deve permitir o uso do GPS pela aplicação.

• A aplicação deve informar a localização aproximada do motorista.
• A aplicação deve apresentar um mapa da localização aproximada do motorista.
5. US05 - Registrar início de locomoção do carro

Descrição: Como motorista, eu quero registrar uma viagem feita com o carro, para
que ela possa servir na contagem de ganhos e lucros.
• O motorista deve ter acesso de forma fácil a uma opção(em formato de botão)
para registrar o início e término da viagem.
• O motorista deve informar o tipo de viagem que está sendo realizada: se é
particular ou à trabalho.
• A aplicação deve notificar que o início e o término da contagem de quilômetros
rodados no tipo de viagem escolhida.
• Após o início da viagem o sistema deve utilizar os dados para calcular a

quilometragem diária.
6. US06 - Registrar abastecimento do carro

Descrição: Como motorista, eu quero registrar o abastecimento do automóvel, para
que essa informação seja contada no cálculo de custos
• O motorista deve ser capaz de incluir a data, o valor gasto e a quantidade de

combustível abastecida.
• A aplicação deve verificar e validar a data informada.
• a aplicação deve notificar o motorista se a inclusão de gastos obteve sucesso ou
gerou erro.
7. US07 - Registrar ganhos no app parceiro

Descrição: Como motorista quero registrar meus ganhos com viagens à trabalho,
para que essa informação seja considerada no cálculo dos meus lucros.
• O motorista deve ter acesso a tela para incluir os ganhos líquidos e brutos que
obteve na prestação de serviços via aplicativos de corrida.
• O motorista deve ter opção para incluir o valor líquido e bruto que obteve na
prestação de serviços via aplicativos de corrida no dia.
• O formulário deve validar e informar se a data é permitida e se o valor líquido
menor que o valor bruto.
• O motorista deve receber algum tipo de mensagem informando se a inclusão de
ganhos líquidos e brutos no dia informado, obteve sucesso ou erro.
8. US08 - Registrar manutenções com o carro

Descrição: Como motorista eu quero registrar as manutenções feitas no veículo,
para que eu possa manter um controle das manutenções que realizo no veículo.
• O motorista deve ter acesso a tela para incluir seus gastos com manutenções
com o carro.
• O motorista deve ter opção para selecionar o tipo de manutenção, data realizada
e valor gasto.
• A aplicação deve validar a data preenchida no formulário.
• O motorista deve receber algum tipo de mensagem informando que inclusão de
gasto com manutenção obteve sucesso ou erro.
• A aplicação deve considerar as informações de manutenção no cálculo de despesas
do automóvel.
• As manutenções registradas devem ser exibidas no dashboard do aplicativo.
• O sistema deve notificar o motorista quando for necessário realizar uma nova
manutenção, com base no período previsto entre as manutenções e na data da
última manutenção realizada.
9. US09 - Visualizar total de km rodados por dia/período

Descrição: Como motorista quero visualizar quantos quilômetros eu rodei pelo
período que eu escolher, para ter uma base do uso de veículo.
• O motorista deve ter acesso as informações de quilômetros rodados por dia ou

período selecionado através da Gestão de Finanças e do DashBoard.
• O motorista deve ter acesso na tela principal sobe a informação de quantos
quilômetros ja foram rodados no dia para a categoria de trabalho.
• A aplicação deve diferenciar quilômetros rodados pela categoria de viagem a
trabalho ou uso pessoal.
• As informações devem ser exibidas em formato de gráfico.
10. US10 - Visualizar abastecimento do carro por dia/período

Descrição: Como motorista eu quero visualizar meus gastos com o automóvel, para
ter um controle financeiro melhor.
• O motorista deve visualizar as informações de abastecimento do automóvel

por dia ou período selecionado através de um dashboard e da seção Gestão de
Finanças.
• As informações exibidas devem incluir o valor gasto, a quantidade de combustível,
o tipo de combustível e a data do abastecimento para cada registro.
• O motorista deve ser capaz de filtrar as informações de abastecimento por data

ou período selecionado
11. US11 - Visualizar ganhos no app parceiro por dia/período

Descrição: Como motorista, eu quero visualizar meus ganhos obtidos, para que eu
possa acessar essa informação de forma fácil e clara.
• O motorista deve selecionar o período que deseja visualizar os ganhos.

• A aplicação deve disponibilizar diariamente os valores dos ganhos que o motorista
obteve.
• O motorista deve ter acesso as informações dos ganhos que obteve pelo período
selecionado através de um dashboard gráfico.
12. US12 - Visualizar gastos com manutenção do carro por dia/período

Descrição: Como motorista eu quero visualizar os gastos que tive na manutenção
do automóvel, para avaliar corretamente os meus gastos.
• O motorista deve selecionar o período que deseja visualizar.

• A aplicação deve disponibilizar os dados diários dos gastos com manutenção.
• O motorista deve ter acesso as informações de gastos com manutenção do
automóvel pelo período selecionado através de um dashboard gráfico.
13. US13 - Visualizar uma estimativa de gasto com gasolina por dia e km
rodados
Descrição: Como motorista, eu quero visualizar os gastos que tive com gasolina
pelo período que eu escolher, para ter uma noção das minhas despesas totais.
Requisitos relacionados: RF04, RF05, RF06, RF09
• A aplicação deve exibir uma estimativa de gastos com gasolina pelo período
selecionado em formato gráfico.
• A aplicacão deve disponibilizar diariamente, para consulta, os gastos com
gasolina.
• A aplicação deve diferenciar o gasto com gasolina considerando os quilômetros
rodados pela categoria de viagem a trabalho ou de uso pessoal.
14. US14 - Visualizar Dashboard

Descrição: Como motorista eu quero visualizar meus gastos, lucros e ganhos, para
que eu possa saber como estão as minhas finanças.
Requisitos relacionados: RF06, RF07, RF08, RF10
• O motorista deve visualizar de forma gráfica seus ganhos brutos e líquidos

recebidos pelos serviços prestados.
• O motorista deve visualizar de forma gráfica seus gastos com abastecimento.
• O motorista deve visualizar de forma gráfica seus gastos com manutenção.
• O motorista deve visualizar de forma gráfica os quilômetros rodados por cate-
goria de viagem.
• O motorista deve visualizar de forma gráfica a correlação dos quilômetros
rodados, abastecimento do automóvel e ganhos líquidos.
15. US15 - Notificação manutenção

Descrição: Como motorista, eu quero ser notificado quando precisarei realizar
manunteções no veículo, para estar informado de quando será necessário realizá-las.
• O motorista deve receber notificações da aplicação sobre a necessidade de

manutenção do automóvel.
• A aplicação deve usar como base os dados inseridos na US07 - Registrar
manutenções com o carro.
• A aplicação deve usar para o cálulo os valores de período previsto para cada tipo
de manutenção a ser mapeada, de acordo com a recomendação do fabricante.
16. US16 - Página Web

Descrição: Eu como usuário, quero ter uma página web para visualizar informações
de como instalar o aplicativo Carllet corretamente.
Requisitos relacionados: N/A
• A página deve contem informações de quais lojas o aplicativo está disponível

para download.
• A página deve estar acessível em inglês e português.
• As informações de como acessar o aplicativo devem estar visíveis.
• As políticas de privacidade devem estar disponíveis ao usuário.
17. US17 - Gerenciar dados para meta

Descrição: Eu, como motorista, gostaria de gerenciar os dados para a minha meta
diária, para que eu possa definir e acompanhar o valor que preciso ganhar por dia.
Requisitos relacionados:RF11
• O usuário deve ter a opção de criar uma nova meta diária, inserindo o valor
desejado.
• usuário deve ter a opção de editar os dados que geram a meta.
• O usuário deve ter a opção de excluir uma meta diária já criada.
• A aplicação deve permitir que o usuário visualize a meta diária atual e o valor
já ganho no dia;
• A aplicação deve alertar o usuário caso o valor ganho no dia esteja abaixo da
meta diária definida;
• Os dados de meta diária devem ser salvos e mantidos na aplicação mesmo após
o encerramento da sessão.
18. US18 - Comparação de Valores

Descrição: Eu, como motorista, quero visualizar a relação entre a previsão de ganhos
de forma automática, para acompanhar a as minhas metas e ganhos.
Requisitos relacionados:RF12
• A aplicação deve apresentar um modelo preditivo que utilize dados históricos

de ganhos para gerar uma previsão do valor total a ser recebido ao final do
período.
• A aplicação deve mostrar a relação entre a meta definida pelo usuário e o valor
previsto gerado pelo modelo preditivo.
• A relação deve ser clara e fácil de entender, indicando se o usuário está no
caminho certo para alcançar a meta ou se precisa ajustar sua estratégia para
atingi-la.
• A aplicação deve atualizar a previsão de ganhos totais baseada nas alterações
feitas na meta diária.
• A aplicação deve ser atualizada com frequência para garantir que a previsão
gerada pelo modelo preditivo seja o mais precisa possível.
4.2.2 Regras de Negócio

Foram mapeadas 7 Regras de Negócio. O Quadro 9 as relaciona com os 11 Requisitos
Funcionais mapeados, e que são abordados posteriormente no Quadro 10.
Quadro 9 – Regras de Negócio

Código do Requisito
Nome Descrição
Requisito Relacionado
Apenas maiores de 18 anos poderão reali-
RN01 Cadastro RF01
zar o cadastro no app
Apenas usuários devidamente logados po-
RN02 Cadastro derão ter acesso às funcionalidades do RF02
aplicativo
Um condutor poderá registrar mais de
RN03 Cadastro RF01
um carro na aplicação
O condutor precisará inserir e-mail e se-
RN04 Login nha para acessar a aplicação e suas res- RF02
pectivas funcionalidades
O condutor precisa permitir que a aplica-
ção tenha acesso à sua localização para
RN05 GPS RF01, RF03
utilizar as funcionalidades referentes às
corridas
O dashboard será gerado a partir dos da-
RN06 Dashboard dos relacionados aos ganhos e despesas RF06, RF10
inseridos pelo condutor
O condutor terá a opção de assinar a ver-
RN07 Premium são Premium do aplicativo, que liberará RF04, RF11
mais funcionalidades
4.2.3 Requisitos Funcionais

Foram mapeados 11 Requisitos Funcionais. O Quadro 10 mostra, de forma resumida,
seus pressupostos:
Quadro 10 – Requisitos Funcionais

Código do
Nome Descrição
Requisito
Gerenciador A aplicação deve permitir que o usuário crie, edite e
RF01
de usuário exclua sua conta
Login e auten-
RF02 A aplicação deve permitir que o usuário acesse sua conta
ticação
Localização
A aplicação deve permitir que o usuário visualize sua
RF03 no Mapa via
localização no mapa através do uso do GPS
GPS
A aplicação deve permitir que o usuário inicie e finalize
Gerenciador
RF04 uma corrida para que os valores de quilômetros rodados
de Corrida
prestando serviços sejam calculados
A aplicação deve armazenar os dados de quilômetros
RF05 Rodômetro rodados via GPS em segundos por quilômetro de forma
automática
A aplicação deve permitir que o usuário registre as
Registrar des-
RF06 despesas do automóvel, informando o tipo de despesa e
pesa
valor gasto
Registrar Lu- A aplicação deve permitir que o usuário registre diaria-
RF07
cros mente seus ganhos, informando lucro bruto e líquido
A aplicação deve permitir que o usuário visualize todas
Gerenciador
RF08 as informações registradas sobre os lucros e gastos com
de Finanças
abastecimento e manutenção do carro
A aplicação deve permitir que o usuário visualize, em
forma de dashboard, para o período informado, as in-
RF09 Dashboard
formações referentes aos seus lucros, assim como gastos
com abastecimento e manutenção do carro
Notificação de A aplicação deve informar ao usuário de forma prévia a
RF10
manutenção necessidade de manutenção do automóvel
Gerenciar da- A aplicação deve permitir que o usuário crie, edite e
RF11
dos para meta exclua dados utilizados para gerar o valor da meta diária
A aplicação deve mostrar ao usuário a relação entre o
Comparação
RF12 valor registrado como meta e o valor previsto gerado por
de Valores
um modelo preditivo no final do período
4.2.4 Requisitos Não Funcionais

Foram mapeados 5 Requisitos Não Funcionais. O Quadro 11 mostra, de forma
resumida, seus pressupostos:
tabular
Quadro 11 – Requisitos Não Funcionais

Código do
Módulo Descrição
Requisito
A aplicação deverá dispor de uma interface organi-
RNF01 Usabilidade zada para que o usuário possa usufruir de todas as
funcionalidades propostas.
A aplicação deverá possuir um layout responsivo para
RNF02 Usabilidade que possa ser utilizado em dispositivos de diferentes
dimensões
A aplicação deverá apresentar um bom desempenho
RNF03 Performance em sua execução, não ultrapassando o tempo de espera
tolerado pelo usuário (NIELSEN, 1993)1.
A aplicação deve atender às especificações que cons-
tam na Lei Geral de Proteção de Dados Pessoais
RNF04 Segurança (LGPD) (Lei nº 13.709/2018), não permitindo que
os dados fornecidos pelos usuários sejam utilizados
indevidamente (LGPD, 2018).
A aplicação deve ser executada em ambiente Android
RNF05 Compatibilidade
e IOS.
1 De 0 a 0.1s de espera = Perfeito; De 0.1 a 1.0s = Aceitável. Maior que 1.0 a 10s = Problemático.
4.3 Modelagem
4.3.1 Modelagem do Banco de Dados
A partir das histórias de usuários, requisitos funcionais e não funcionais, foi elabo-
rada a modelagem do banco de dados, concretizada através do Modelo Entidade Relacio-
namento (MER) e do Diagrama Entidade Relacionamento (DER).
4.3.1.1 MER
A Figura 7 representa o MER para implementação do projeto. Foram consideradas

as entidades Condutor, Ganho, Despesa, Descrição Despesa, Veículo e a entidade associa-
tiva Viagem:
Figura 7 – Modelo Entidade Relacionamento
figuras/mercarllet.png
4.3.1.2 DER
A Figura 8 representa o DER do projeto, onde é possível observar a relação entre

as tabelas Condutor, Ganho, Despesa, Descrição Despesa, Veículo e Viagem, além dos
atributos e as chaves-primárias(PK) de cada tabela/entidade
Figura 8 – Diagrama Entidade Relacionamento
figuras/dercarllet.png

Quadro 12 – Entidades do Modelo Entidade Relacionamento

Entidade Descricao
Entidade em que são armazenados dados referentes ao
Condutor
condutor cadastrado no aplicativo
Entidade associativa em que são armazenados dados
Viagem
referentes às viagens, condutor e veículo associado
Entidade em que são armazenados dados referentes ao
Veículo
veículo cadastrado pelo condutor
Entidade em que é armazenado o atributo de marca do
Marca
veículo
Entidade em que é armazenado o atributo de modelo do
Modelo
veículo
Entidade em que são armazenados os dados de ganhos
Ganho
do condutor
Entidade em que são armazenados os dados de despesas
Despesa
referentes ao veículo, inseridos pelo condutor
Entidade em que é armazenado o atributo de detalhe da
Tipo despesa
despesa do veículo
4.3.1.3 Dicionário de Dados
O Dicionário de Dados mapeia os atributos das tabelas e permite visualizar em

forma de quadro as informações como o nome do atributo, tipo de dado, se pode ser nulo,
se é uma chave primária e uma breve descrição. Cada tabela possui seu próprio dicionário
de dados.
O Quadro 13 representa o dicionário de dados referentes à tabela Condutor:

Quadro 13 – Dicionário de Dados - Condutor

Chave Nulo Atributo Tipo de Dado
Descrição
Campo numérico identificador
PK Não id_condutor UUID
único do condutor.
Campo de texto, nome inserido
- Não nome_condutor VARCHAR(100) pelo condutor para devida identi-
ficação.
- Não dt_nascimento DATE Data de nascimento do condutor.
Campo de texto, número do do-
- Não numero_cnh VARCHAR(10) cumento da Carteira Nacional de
Habilitação (CNH) do condutor.
E-mail de cadastro inserido pelo
- Não email VARCHAR(255)
condutor.
Senha de login cadastrada pelo
- Não senha VARCHAR(64)
condutor.
Número do telefone celular do
- Não telefone VARCHAR(14)
condutor.
Identificador do dispositivo do
- Não deviceId VARCHAR(22)
condutor.
Campo sobre a adesão ou não
- Não possui_plano BOOLEAN adesão do condutor ao plano Pre-
mium.
Data referente ao início da adesão
- Sim dt_inicio DATE
do condutor ao plano Premium.
Data referente ao fim da adesão
- Sim dt_fim DATE
do condutor ao plano Premium.
DOUBLE PRE- Valor do faturamento bruto pre-
- Não meta
CISION tendido pelo condutor.
Quantidade de dias trabalhados
- Não dias_trabalhados SMALLINT
por semana pelo condutor.
O Quadro 14 representa o dicionário de dados referentes à tabela Tipo Despesa:
Quadro 14 – Dicionário de Dados - Tipo Despesa

Chave Nulo Atributo Tipo de Dado Descrição
id_descrição Campo identificador único da des-
PK Não UUID
_despesa pesa.
- Não cod_descrição UUID Código da descrição da despesa.
_despesa
- Não label_descrição VARCHAR(50) Descrição do tipo de despesa.
_despesa
O Quadro 15 representa o dicionário de dados referentes à tabela Despesa:
Quadro 15 – Dicionário de Dados - Despesa

Chave Nulo Atributo Tipo de Dado
Descrição
PK Não id_despesa UUID
único da despesa.
Chave estrangeira identificadora
FK Não id_condutor UUID
do condutor associado à despesa.
FK Não cod_descrição UUID da descrição associada ao tipo da
_despesa despesa.
Data e hora da inserção da infor-
- Não dt_hr_insercao DATETIME
mação pelo condutor.
Tipo de despesa selecionada pelo
- Não tipo_despesa VARCHAR (25)
condutor.
Campo que armazena o valor cor-
DOUBLE PRE-
- Não valor_despesa respondente à despesa inserida
CISION
pelo condutor.
O quadro 16 representa o dicionário de dados referentes à tabela Ganho:
Quadro 16 – Dicionário de Dados - Ganho

PK Não id_ganho UUID
único do ganho.
do condutor associado ao ganho.
Data e hora da inserção da infor-
- Não dt_hr_insercao DATETIME
mação pelo condutor.
Campo que armazena o valor cor-
DOUBLE PRE-
- Não valor_ganho respondente à quantia obtida na
CISION
corrida inserida pelo condutor.
O quadro 17 representa o dicionário de dados referentes à tabela Marca:
Quadro 17 – Dicionário de Dados - Marca

Campo identificador único da
PK Não id_marca_carro UUID
marca do veículo.
- Não marca VARCHAR(25) Marca do veículo.
O quadro 18 representa o dicionário de dados referentes à tabela Modelo:
Quadro 18 – Dicionário de Dados - Modelo

Campo identificador único do
PK Não id_modelo_carro UUID
modelo do veículo.
- Não modelo VARCHAR(25) Modelo do veículo.
O quadro 19 representa o dicionário de dados referentes à tabela Veículo.:
Quadro 19 – Dicionário de Dados - Veículo

PK Não id_veiculo UUID
único do veículo.
FK Não id_condutor UUID do condutor associado ao veí-
culo.
- Não ano SMALLINT Ano de fabricação do veículo.
Informa se o veículo cadastrado
- Não is_alugado BOOLEAN
pelo condutor é alugado ou não.
O quadro 20 representa o dicionário de dados referentes à tabela Viagem:

Quadro 20 – Dicionário de Dados - Viagem

Campo numérico iden-
PK Não id_viagem UUID tificador único da via-
gem.
Chave estrangeira
identificadora do
FK Não id_veiculo UUID
veículo associado à
viagem.
Chave estrangeira
identificadora do
condutor associado à
viagem.
Tipo da viagem a ser
cadastrada, dispondo
- Não tipo CHAR(1) das valores “C” para
corrida e “P” para pas-
seio.
Registro dos quilôme-
DOUBLE
- Não km_rodados tros rodados durante a
PRECISION
viagem.
Data e hora da inser-
- Não dt_hr_inicio_viagem DATETIME ção pelo usuário do iní-
cio da viagem.
Data e hora da inser-
- Não dt_hr_fim_viagem DATETIME ção pelo usuário do fim
da viagem.
4.4 Critérios de Segurança, Privacidade e Legislação

O rápido desenvolvimento das redes de internet possibilitou gigantescos avanços
para a sociedade. A denominada indústria 4.0 se pautou na tecnologia para crescer e
fortalecer a globalização. Porém, com o uso da tecnologia adentrando em mais setores
da sociedade fez-se necessário aumentar o investimento em segurança. Hoje o mercado
de segurança da informação é um dos que mais cresce devido ao aumento das ameaças
virtuais. Além dos riscos ao negócio caso percam ou vazem dados, podemos ser submetidos
a punições por violações da LGPD.
Além dos riscos funcionais e legais, segundo (BALAPOUR; NIKKHAH; SABHERWAL,
2020) hoje o usuário final já tem percepção dos riscos que os vazamentos de dados são para
ele, desinstalando apps que solicitam muitas permissões, se preocupando com aplicativos
executando em segundo plano e levando-os a não consumirem aplicativos que já tiveram
vazamentos. Diante desta situação, e devido à natureza de nossa aplicação, que utiliza
dados financeiros e de localização, reforçamos nosso compromisso com o desenvolvimento
pavimentado por princípios de segurança.
4.4.1 Segurança dos Dados

Primordial para a prevenção de incidentes de segurança é o conhecimento dos
tipos de ameaças. Para tanto, tomamos como base a lista do Open Web Application
Security Project (OWASP) na formulação do Quadro 21, que elenca os 10 maiores riscos
de segurança para aplicativos web (OWASP, 2021):
Quadro 21 – Top 10 maiores riscos de segurança para aplicativos web

Controle de Acesso Quebrado
94% dos aplicativos foram testados quanto a este tipo de risco. As 34 Common
Weakness Enumerations (CWEs) (Enumerações de Fraquezas Comuns) mapeadas
para Controle de Acesso Quebrado foram mais frequentes em aplicativos do que em
outras categorias.
Falhas de Criptografia
Categoria anteriormente identificada como "Exposição de Dados Sensíveis"; falhas de
criptografia geralmente levam à exposição de dados sensíveis e comprometimento do
sistema.
Injeção (Injection)
94% dos aplicativos foram testados para algum tipo de injection; as 33 Enumerações
de Fraquezas Comuns (CWEs) mapeadas nesta categoria têm o segundo maior
número de ocorrências em aplicativos.
Design Inseguro
Categoria nova com foco nos riscos relacionados a falhas de design.
Configuração de Segurança Incorreta
90% dos aplicativos foram testados quanto a alguma forma de configuração incorreta.
Sofwares cada vez mais configuráveis explicam a alta classificação desta categoria na
lista.
Componentes Desatualizados e Vulneráveis
Única categoria que não possui Common Vulnerability and Exposures (CVEs) (Vul-
nerabilidades e Exposições Comuns) mapeadas para as Enumerações de Fraquezas
Comuns (CWEs) existentes, portanto acaba recebendo pontuações padrão.
Falhas de Identificação e de Autenticação
Anteriormente apenas Falha de Autenticação, agora inclui Enumerações de Fraquezas
Comuns (CWEs) relacionadas a falhas de identificação.
Falhas de Integridade de Software e de Dados
Categoria que se concentra na falta de verificação de integridade em questões rela-
cionadas a atualizações de software, a dados críticos e a pipelines de Continuous
Integration/Continuous Deployment (CI/CD).
Falhas de Registro de Segurança e de Monitoramento
Categoria difícil de testar e mal representada nas Vulnerabilidades e Exposições
Comuns (CVEs) e no Sistema de Pontuação de Vulnerabilidades Comuns (Common
Vulnerability Scoring System (CVSS)), mas cujas falhas podem afetar diretamente o
alerta de incidentes e a análise forense.
Falsificação de Solicitacão do Servidor
Os dados mostram uma taxa de incidência relativamente baixa deste risco, mas com
cobertura acima da média por parte da comunidade de segurança.
Fonte: OWASP (2021)
Pautados por tais riscos, é responsabilidade dos analistas desenvolverem suas

atividades e refatorarem, quando necessário, levando fatores de segurança em consideração.

Para a segurança das requisições entre cliente e servidor, utilizaremos o protocolo
OAuth2, um dos protocolos mais modernos para garantir acesso a informações restritas,
apenas pelos usuários autorizados. Para este protocolo que se baseia em Tokens, utilizaremos
Json Web Tokens (JWT) para podermos transitar dados criptografados. Junto deste
protocolo, utilizaremos Refresh Tokens para termos chaves de acesso com menor tempo de
vida, diminuindo a chance de os dados serem descriptografados. Os Refresh Tokens são
de maior duração, por isso devem ser guardados no dispositivo cliente de maneira segura,
não utilizando da memória padrão do framework React Native pois este permite acesso
irrestrito por outras aplicações.
Um cuidado importante por se tratar de desenvolvimento de aplicativos móveis é o
armazenamento local de informações. Por padrão o React Native guarda as informações
em ambiente não criptografado, podendo suas informações serem acessadas por outros
aplicativos. Para evitar estes riscos, utilizamos, no ambiente Android, o Android Keystore,
e no IOS, o Keychain Service.
4.4.2 Legislação
A Lei Geral de Proteção dos Dados (LGPD), regula desde 2020 as regras para
armazenamento, processamento e deleção de dados. Estipula punições em casos de violações
de suas regras. A lei é aplicável para qualquer processo que ocorra em território nacional,
independente da nacionalidade do usuário ou país de sede da empresa. Também disponibiliza
parâmetros para quais dados de usuários devem ser tratados com maior sigilosidade,
como gênero e sexualidade, define como o titular dos dados deve ter controle de suas
informações. Determina como diferentes os papéis assumidos pelas instituições no processo
de manipulação de dados e quais serão suas responsabilidades.
No desenvolvimento do projeto foi levado em consideração as exigências de tal lei
desde o princípio, no desenho da aplicação especificamos a necessidade de dados do usuário
apenas o suficiente para garantir fidedignidade, não solicitando dados pessoais sensíveis ou
de menores de idade. O usuário titular deve aprovar a utilização de tais informações antes
de acessar o aplicativo e tem acesso a elas, sendo-lhe permitido modificar ou deletar caso
haja necessidade.
A aplicação desenvolvida se enquadra em todos os princípios exigidos no artigo 6
da lei, onde dissertam sobre os princípios a serem seguidos no tratamento de dados. Os
protocolos definidos em 4.5.1 servirão para garantir que os dados só trafeguem pela rede
quando criptografados.
4.5 Tecnologias Utilizadas

O sistema é disponibilizado em forma de Aplicação Mobile, além da Landing Page
do aplicativo, onde constarão informações sobre política de privacidade, leis de proteção
de dados e descrição da aplicação e de suas funcionalidades.
As tecnologias utilizadas são o C#, .NET Framework, Javascript, React, React
Native, PostgreSQL e Azure e API’s externas a definir.
4.5.1 Front-end
Para o Front-end, as tecnologias utilizadas são o React.js e o React-Native.
O React.js, biblioteca JavaScript de criação de interfaces de usuário, de propriedade
do grupo Meta Platforms, é utilizado para construção da Landing Page do aplicativo.
Atualmente, as lojas precisam de algumas informações como políticas de privacidade do
aplicativo para que ele possa ser confirmado e verificado nas lojas de distribuição como
“App Store” e “Play Store”.
A tecnologia foi escolhida pois permite desenvolver uma Single Page Application
(SPA), resultando em economia dos recursos do backend e a possibilidade de escalabilidade
da aplicação, caso necessário.
O React-Native é um framework open source de propriedade da Meta Platforms.
(NATIVE, 2023). Com uma forma de escrever muito semelhante ao React, o React Native
possibilita desenvolver aplicações mobile, utilizando o mesmo contexto de tecnologia de
base do React, o Javascript.
Além disso, o uso do React Native foi favorável mediante a possibilidade de
desenvolver uma aplicação mobile que pode ser utilizada nas plataformas Android e IOS.
4.5.2 Back-end
O Back-end é fundamentalmente desenvolvido utilizando-se C# (C Sharp), uma
linguagem de programação moderna, orientada a objeto e fortemente tipada. O C#
permite que os desenvolvedores criem muitos tipos de aplicativos seguros e robustos que
são executados no .NET, plataforma de código aberto criada pela Microsoft. (MICROSOFT,
2023)
A comunidade de desenvolvedores do .NET é ativa, disponibilizam conteúdos
documentados e uma grande quantidade de recursos disponíveis que contribuíram para
auxiliar no desenvolvimento da aplicação.
Baseado na linguagem C# o .NET é uma plataforma de desenvolvimento muito
poderosa e versátil que permite desenvolver aplicações backend escaláveis, que se necessário,
podem ser compartilhadas com diferentes aplicações.
4.5.3 Estrutrura de Pastas

A estrutura de pastas do front-end foi organizada de uma maneira:
4.5.4 Banco de dados

Para o banco de dados foi utilizado o PostgreSQL, sistema gerenciador de banco
de dados objeto relacional de código aberto, desenvolvido pelo grupo PostgreSQL Global
Development. (POSTGRESQL, 2023)
4.5.5 APIs externas

Para a geolocalização e geração de mapas, a princípio serão utilizadas integrações
com as APIs da Plataforma Google Maps, porém outras opções de integração serão
avaliadas posteriormente.
4.5.6 Versionamento
Para realizar o versionamento do código da aplicação, utilizamos o Git, ferramenta
open-source e muito popular na comunidade utilizada por grande parte dos desenvolvedores
para versionar projetos em um âmbito geral. Para hospedar o código versionado através do
Git, utilizamos o repositório online Github, onde conseguimos alocar o código versionado em
uma “organização” que contém todos os membros do grupo, facilitando o compartilhamento
e acesso.
4.5.7 Deploy
Após uma criteriosa análise de várias opções de nuvem, optou-se por implantar a
plataforma Azure da Microsoft. A escolha da Azure foi motivada pela sua escalabilidade,
segurança e confiabilidade, bem como pela facilidade de integração com outras ferramentas
e serviços de desenvolvimento, como o Visual Studio e o ambiente .NET. Além disso, a
Azure oferece uma ampla gama de recursos e soluções personalizáveis que atendem às
necessidades específicas do do aplicativo Carllet, como armazenamento de dados, serviços
de banco de dados gerenciados e gerenciamento de recursos em nuvem.
4.6 Manutenibilidade
4.6.1 Testes Automatizados
React Native - Detox
Optou-se por utilizar a biblioteca de testes Detox, cuja estrutura de escrita é
baseada no Jest. A ferramenta Detox se mostrou eficaz na realização de testes end-to-end,
capazes de simular fluxos reais de usuário desde o início até o final do processo. Com essa
abordagem, foi possível identificar falhas no fluxo de usuários e resultados inesperados
em tela. O objetivo final é garantir a funcionalidade e usabilidade do aplicativo, sem a
presença de bugs de fluxo que pudessem comprometer a experiência do usuário.
React Native Testing Library
Além da biblioteca Detox, que é usada para realizar os testes end-to-end e simular
fluxos reais de usuário, escolheu-se utilizar a biblioteca "React Native Testing Library"para
realizar testes unitários em componentes. Dada esta escolha, é possivel verificar o resultado
esperado dos componentes e sua qualidade.
React - Jest
Para realizar os testes no fluxo da página web de apresentação do aplicativo,
utilizamos a biblioteca de testes Jest, desenvolvida e mantida pela Meta. Jest é uma
biblioteca de teste sólida e consolidada no ecossistema do React. Com ela, conseguimos
testar os componentes que estarão presentes na aplicação Web e estarão visíveis para os
usuários que desejam conhecer o aplicativo, através da sua página de apresentação e/ou
ler as nossas políticas de privacidade.
.NET - XUnit
Para realizar os testes unitários no nosso back-end, utilizamos o XUnit, uma
biblioteca open source e muito consolidada no ecossistema do .NET, com recomendações e
tutoriais de uso na própria documentação desenvolvida pela Microsoft. Com ele, somos
capazes de testar nossas classes e validar o funcionamento de todo código desenvolvido
na aplicação, garantindo a qualidade e diminuindo os riscos de falha na nossa regra de
negócio principal. Além disso, a grande quantidade de conteúdo do XUnit presente na
comunidade pode auxiliar na elaboração de testes mais complexos e garantir ainda mais a
qualidade do projeto.
4.6.2 Análise Estática

C# - SonarQube
O SonarQube Community Edition é uma plataforma gratuita e de código aberto.
Implementa a estratégia Clean as You Code, que permite a definição de regras em diferentes
níveis. Pode ser usado através de uma instalação tradicional ou pode ativar um contêiner
do Docker usando uma das imagens disponibilizadas em seu website. Com o uso desta
ferramenta conseguimos eliminar Code Smells, impedir que alguma vulnerabilidade ou bug
sejam introduzidos, além de revisar todos os pontos de acesso de segurança.
O SonarLint, plataforma gratuita e de código aberto, será utilizado combinado com
o SonarQube para formar uma solução de código limpo poderosa e integrada com a detecção
de pontos de acesso de segurança. O SonarLint é utilizado direto na Integrated Development
Environment (IDE) Visual Studio Code, contribuindo para detectar problemas de qualidade
durante a codificação.
4.6.3 Integração Contínua

No processo de desenvolvimento de Continuous Integration (CI) e Continuous
Deployment (CD), utilizamos o Github Actions, que pode ser integrado de forma bem
simples e facilitada com as ferramentas da Azure através do plugin "Azure Container
Registry Build". Esse processo permite que o contêiner Docker seja montado (buildado)
e executado na nuvem de forma automatizada com a publicação de novas versões da
aplicação. Através do Azure Container Registry, é possível armazenar e gerenciar imagens
de contêineres Docker de forma privada e segura, sendo possível utilizá-las em diferentes
ambientes de implantação. Além disso, o Azure DevOps oferece uma solução completa
para o desenvolvimento de software, incluindo integração contínua, entrega contínua e
testes automatizados.
4.6.4 Sistema de Logs

Para trabalhar com os logs da aplicação, utilizamos a biblioteca Serilog, disponível
no .NET . Essa biblioteca facilita o processo de captura dos logs e permite desenvolver
um padrão para captura de logs de uma maneira mais simples e objetiva e pode ser
integrada com o Azure Monitor. Através disso, os logs da aplicação são centralizados
em uma única plataforma. Ademais, para a captura de logs gerados pelo cliente mobile,
utilizamos a biblioteca App Center, que é uma ferramenta da Azure para o desenvolvimento
e distribuição de aplicativos mobile. Com a App Center, conseguimos coletar os logs do
aplicativo mobile e enviá-los para o Azure Monitor, mantendo todos os registros de
atividades da aplicação em um só lugar.
4.6.5 Coding Convention

Com o objetivo de garantir que o aplicativo Carllet mantenha a escalabilidade e
a robustez, as convenções de código que são utilizadas no desenvolvimento do aplicativo
Carllet seguem os padrões da linguagem C# e JavaScript.

No React/React Native, o padrão de codificação comumente usado é o JavaScript
Standard Style. Ele define regras para a formatação do código, incluindo o uso de ponto
e vírgula, espaços e a ordem das declarações. O objetivo é tornar o código legível e
consistente. O padrão recorrente para o C# é o C# Coding Conventions, que define regras
para a formatação do código, incluindo a indentação, uso de espaços e nomes de variáveis.
Ademais, o padrão incentiva a utilização de comentários para melhorar a legibilidade do
código visando a facilidade de futuras manutenções e escala.
4.6.6 Design Patterns

A utilização do padrão "Decorator"possibilita a criação de várias classes decoradoras
distintas, cada uma adicionando funcionalidades específicas para diferentes cenários de
utilização do veículo. Dessa forma, a classe original de motorista permanece inalterada, o
que simplifica o código e aumenta a modularidade do sistema. Além disso, a adoção desse
padrão contribui para manter o código organizado e de fácil manutenção, permitindo sua
extensão de forma mais simples e eficiente no futuro.
4.7 Modelo de Negócio

A aplicação utiliza do modelo Freemium, onde o usuário tem acesso à maioria das
funcionalidades, mas de maneira limitada, e pode optar por fazer uma assinatura para
disponibilizar de outras funções ou retirar limitações do aplicativo.
No Carllet, a diferença entre a versão Free e Premium podem ser observados no
Quadro 22:
Quadro 22 – Comparativo entre versões Free e Premium

Free Premium
Guarda informações de viagens Guarda informações de viagens
por 3 meses por tempo indeterminado
Permite inserir até 6 tipos de des- Permite inserir um número ilimi-
pesa para o automóvel tado de despesas
Não envia alertas de manutenção Envia alertas baseados em quilo-
metragem e tempo para quando
uma manutenção deve ser feita
Contém propaganda Não contém propaganda
4.8 Viabilidade Financeira

Cruz (2012) propõe como elementos para análise de viabilidade econômico-financeira
de um projeto de aplicativo a identificação dos custos do projeto e a estimativa de receitas.
Os custos podem ser divididos nas seguintes categorias: Recursos humanos; Infraestrutura
tecnológica; Infraestrutura física; e Custos de operação. A estimativa de receitas é baseada
em pesquisas de mercado para identificação do potencial de comercialização do produto e
da política de preços definida na estratégia comercial do projeto.
4.8.1 Custos do Projeto

Para realizar a análise de custos foi considerado o valores gastos com análise,
desenvolvimento, estrutura da empresa e manutenção e as possíveis receitas num período de
até 9 meses. A planilha de Custos e Receitas utilizada foi construída baseada nos materiais
disponibilizadas nas disciplina de Gestão de Projetos (GPRA4) e Projeto Integrado I
(PI1A5) do curso de TADS do IFSP.
4.8.1.1 Custos da Análise e Desenvolvimento
Para calcular as horas totais de esforço para o desenvolvimento da aplicação, os RF

foram classificados entre fáceis, médios e difíceis. Com isso foram estimados quantos dias e
horas são necessárias para executar todo o projeto. Os resultados podem ser observados
na Figura 9:
Figura 9 – Estimativa de horas necessárias para executar RF
figuras/estimativa_horas_rf.png
Para considerar o custo por tipo de recurso necessário para o desenvolvimento

da aplicação, foram considerados os salários médios no Brasil para funcionários CLT,
consultados no GlassDoor em abril de 2023 para os cargos de: Analista de Requisitos Pleno
(R$6.000,00), Project Manager (R$11.000,00), Scrum Master (R$8.413,00), DBA Pleno
(R$7.033,00), Desenvolvedor Full Stack Pleno (R$6.000,00) e Desenvolvedor Full Stack
Junior (R$3.064,00).
Para chegar ao valor da hora que pode ser observado na Figura 10, foi considerado
o salário médio para cada cargo consultado no GlassDoor em abril de 2023 e aplicada
a divisão por 176 horas (44 horas semanais multiplicado por 4 semanas). Também foi
aplicado um fator de 1.68 sobre o valores da hora para considerar os custos trabalhistas e
sociais. Tal valor foi estabelecido conforme a lei trabalhista segundo Torres (2022).
Figura 10 – Estimativa de valor por hora dos recursos do projeto
figuras/af_recursos_projeto.png
Com o total de horas necessárias para o desenvolvimento dos RF e o valor médio

por hora de cada função, aplicamos a distribuição de horas necessárias considerando a
análise e desenvolvimento, como pode ser observada na Figura 12:
figuras/af_custos_analise_dev.png
figuras/af_custos_analise_dev.png
4.8.1.2 Custos da Estrutura da Empresa
Para o cálculo dos Custos da Estrutura da Empresa que pode ser observado na
Figura 13, consideramos os gastos com infraestrutura Cloud e utilizamos da ferramenta
da Azure para estimar o valor médio gasto com servidores. Foi precificado o preço mé-
dio de R$280,00 por mês gasto em infraestrutura. Não foram considerados valores com
equipamentos, pois os funcionários já possuem.
Figura 13 – Custo Estrutura da Empresa (Mensal)
figuras/af_custos_estrutura_empresa.png
4.8.1.3 Custos da Manutenção do Serviço
Para o cálculo do custo mensal da Manutenção do Serviço, foram considerados os

valores referentes ao Desenvolvimento e da Estrutura da empresa, que pode ser observado
na Figura 14:
Figura 14 – Custo Manutenção do Serviço (Mensal)
figuras/custo_manutencao_servico_mensal.png
Para realizar o cálculo do Custos Totais do Projeto que pode ser observado na
Figura 15, com uma projeção de até 9 Meses, foram considerados os valores referentes ao
Desenvolvimento e Manutenção do Serviço. O desenvolvimento será realizado em 4 meses,
com três fases de entrega Minimum Viable Product (MVP), Proof of Concept (POC) e
o Produto Final. Após este período, somente o valor das Manutenções de Serviços são
consideradas.
Figura 15 – Custos (Projeção Até 9 Meses)
figuras/custo_projecao_9_meses.png

4.8.2 Projeção de Receitas e Faturamento

A Projeção de Receitas e Faturamento são divididas em três cenários: Otimistas,
Realista e Pessimista.
O cálculo do retorno de publicidade foi feito utilizando a ferramenta Google
AdMob (2023), que pode ser observado na Figura 16. Assumimos que um usuário acessa o
aplicativo 25 dias no mês e a cada dia ele acessa o aplicativo 10 vezes, entre iniciar o GPS,
abastecimentos e manutenção e visualizar suas métricas. Obtivemos o valor de 250.000
acessos por mês a cada 1000 usuários ativos. A partir disso parametrizamos um ganho
estimado em aproximadamente 4075 dólares por ano ou 340 dólares por mês, convertidos
na cotação do dólar aproximado para R$5,20, assumimos um ganho de R$1.770,00 para
cada 1000 usuários.
Figura 16 – Estimativa de ganho com publicidade gerado pela AdMob Google
figuras/calculo_publicidade.png
Fonte: Google AdMob (2023)
A assinatura diz respeito a princípio sobre bloquear as publicidades. Ao longo do

projeto serão analisadas possibilidades de incluir funcionalidades para os assinantes da
aplicação. Foi considerado o valor de R$15,00 por assinatura, assumindo que no primeiro
mês seriam 200 assinaturas, e um aumento de 100 usuário a cada mês.
Para realizar as projeções foram considerados 4 meses de desenvolvimento. Assim,
somente após este período está previsto o inicío das receitas.
A projeção de receitas considerando os tres cenarios pode ser observado na Figura
17, que representa a planilha que foram realizados os cálculos.
Figura 17 – Receitas (Projeção Até 9 Meses)
figuras/receita_projecao.png
A projeção do cenário otimista em forma gráfica e que apresenta o Ponto de

Equilíbrio pode ser observado na Figura 18.
Figura 18 – Gráfico - Cenário Otimista
figuras/cenario_otimista.png
A projeção do cenário realista em forma gráfica e que apresenta o Ponto de Equilíbrio

pode ser observado na Figura 19.
Figura 19 – Gráfico - Cenário Realista
figuras/cenario_realista.png
A projeção do cenário pessimista em forma gráfica e que apresenta o Ponto de

Equilíbrio pode ser observado na Figura 20.
Figura 20 – Gráfico - Cenário Pessimista
figuras/cenario_pessimista.png

4.9 Fases de entrega

O desenvolvimento do projeto foi dividido em três fases de entregas. A primeira delas
consiste na POC, a segunda a apresentação do MVP e a terceira e última, a Entrega Final.
O Quadro 23 relaciona os Requisitos Funcionais com a fase em que a sua implementação
foi planejada.
Quadro 23 – Escopo do Projeto

Entrega
Requisito Funcional POC MVP
Final
RF01 - Gerenciador de usuário X X
RF02 - Login e autenticação X X
RF03 - Localização no Mapa via GPS X X X
RF04 - Gerenciador de Corrida X X
RF05 - Rodômetro X X
RF06 - Registrar Abastecimento X
RF07 - Registrar Lucros X
RF08 - Registrar Gastos X
RF09 - Gerenciador de Finanças X
RF10 - Dashboard X
RF11 - Notificação manutenção X
4.10 Prova de Conceito

A prova de conceito (POC) é a evidência obtida de um projeto piloto, que é
executado para demonstrar que uma ideia de produto, plano de negócios ou plano de
projeto é viável. Por exemplo, no desenvolvimento de medicamentos, os ensaios clínicos
são usados para reunir provas de conceito para um produto final.(MALSAM, 2021)
A prova de conceito consistiu em um processo de desenvolvimento e teste para a
avaliação da viabilidade do produto em termos de funcionalidade, desempenho e eficiência.
Inicialmente apresentada na plataforma de nuvem Google Cloud, a equipe de desenvolvi-
mento logo percebeu que seria necessário migrar para uma solução de nuvem adequada
com o propósito da aplicação.
A migração para a plataforma de nuvem Azure da Microsoft possibilitou a cria-

ção de uma infraestrutura de backend estável e integrada aos demais componentes da
aplicação. Com os recursos e ferramentas oferecidos pela plataforma Azure, a equipe de
desenvolvimento conseguiu desenvolver e testar o aplicativo de forma eficiente e eficaz,
validando a escolha da plataforma de nuvem. A prova de conceito foi bem-sucedida, e o
aplicativo Carllet mostrou-se capaz de atender às expectativas nos termos requisitados.
4.11 Produto Mínimo Viável

O MVP do Carllet trata-se de uma versão inicial do aplicativo e das funcionalidades
essenciais.
"Um produto mínimo viável, ou MVP, é uma versão básica do seu aplicativo que
contém apenas os recursos essenciais. Isso ocorre porque o objetivo principal de um MVP
é testar a viabilidade do seu aplicativo. Você testa as águas para ver se há uma demanda
genuína para seu aplicativo de usuários reais ou se sua solução funciona."(BAUS, 2022)
Com base nessa premissa, a equipe de desenvolvimento do Carllet propões entregar
as seguintes funcionalidades:
• Tela de cadastro e login do usuário
• Localização do motorista no mapa via GPS
• Rodômetro, que possibilita iniciar e finalizar a contabilização de uma corrida
• Gerenciador de corrida
4.12 Entrega Final

A entrega final representa a conclusão de um ciclo de desenvolvimento que envolve
a implementação do backend, front-end, regras de negócio e histórias de usuário que foram
projetados na Prosposta Inicial.
Isso significa que todas as funcionalidades planejadas foram criadas, testadas e
integradas em um produto final coeso e funcional. A entrega da aplicação completa
também representa o resultado de um processo de colaboração e aprimoramento contínuo,
envolvendo a equipe de desenvolvimento, testes e usuários finais.
Sendo assim, o produto é disponibilizado para uso em produção e pode atender às
necessidades dos motoristas, fornecendo uma solução eficaz para a gestão financeira de
suas atividades profissionais.
4.13 Histórico de Atividades

Quadro 24 – Histórico de Atividades
Sprint Atividades
Sprint 1 Escolha do tema; Elaboração da proposta inicial; Criação
do blog e canal do Youtube
Sprint 2 Criação da primeira versão da documentação
Sprint 3 Mudança de escopo do projeto e tema
Sprint 4 Elaboração dos Requisitos Funcionais; Elaboração dos
Requisitos Não-Funcionais; Elaboração dos Regras de
Negócio;
Sprint 5 Modelagem: Criação do MER, DER e Dicionário de
Dados;
Sprint 6 Desenho da Arquitetura; Criação das histórias de usuário
Sprint 7 Alteração da modelagem; Alteração das regras de negó-
cio;
Sprint 8 Alteração da modelagem; Criação da primeira versão da
logo do app;
Sprint 9 Alteração da modelagem;
Sprint 10 Desenvolvimento da POC; Elaboração da Apresentação
Sprint 11 Correção de bugs e documentação
Sprint 12 Desenvolvimento do MVP
4.14 Escolhas e Descartes

Ao longo do desenvolvimento do projeto, houveram algumas mudanças, tanto por
parte da própria proposta do aplicativo quanto em relação à sua respectiva arquitetura.
Ambas as modificações visaram melhorar o potencial do aplicativo e fazer com que a sua
realização fosse mais viável.
A princípio, a proposta inicial de Carllet era a de ser um aplicativo de gestão
financeira para motoristas de aplicativos com um forte viés de sustentabilidade. Nesta
versão do projeto, o aplicativo incentivaria o motorista a tomar decisões mais sustentáveis
e econômicas, como por exemplo, abastecer o veículo com um combustível menos poluente.
E para que este incentivo fosse mais efetivo, o app seria gamificado: haveria um sistema
de recompensas, o qual pontuaria o motorista por cada ação sustentável, e esta pontuação,
por sua vez, faria com que este tivesse mais relevância para criar e engajar tópicos nas
comunidades do aplicativo, além de ranking dos motoristas, que colocaria o condutor
com maior pontuação, consequentemente, o com mais escolhas e atitudes sustentáveis, no
topo. Uma vez que carros geram custos, principalmente no que se refere ao abastecimento
(G1, 2021) e que os carros também são uma das maiores fontes de poluição urbana atual
(UBER, 2022), essa primeira versão foi considerada razoável pelo grupo como um todo,
pois o motorista de aplicativo, que não pode dispensar o uso do carro porque o utiliza como
ferramenta de trabalho, conseguiria gerar melhor os gastos e ganhos, além de colaborar
com o meio ambiente e reduzir sua pegada de carbono. Inclusive, esta mesma versão foi a
apresentada como proposta da aplicação.
Porém, a justificativa para o aplicativo não estava sólida, o grupo encontrou
dificuldades para comprovar que a aplicação seria atrativa para o suposto público alvo.
Como não foi feita uma pesquisa de campo prévia para mensurar a aderência de motoristas
de aplicativo à sustentabilidade e que este assunto era de interesse dos motoristas, o grupo
estava correndo risco de fazer um aplicativo para um espantalho, para um público idealizado,
que na realidade não existe. Além disso, a relação entre os fatores sustentabilidade,
gamefication e comunidade não estavam claramente definida. Estava determinado que
estes três elementos se retroalimentariam e um justificaria o outro, contudo, como o fator
de sustentabilidade possuía uma fundamentação frágil, esta mesma incerteza repercutiu
nos outros dois, que dependiam entre si.
Desta forma, por orientação dos professores, a proposta foi modificada, sendo
retirados assim, os elementos de sustentabilidade, comunidade e gamificação, e Carllet
passou a se focar integralmente para ajudar na gestão financeira dos motoristas de
aplicativo.
Outro ponto de mudança foi em relação à arquitetura do aplicativo. No início, a
plataforma Google Cloud foi escolhida para a estrutura da aplicação, e esta escolha se
deu por conta das experiências prévias bem sucedidas por parte de alguns dos membros
da equipe, além da facilidade proporcionada para mensurar gastos e riscos referentes ao
projeto. Assim sendo, esta foi a primeira escolha do ambiente cloud para a arquitetura
de Carllet. A primeira versão da arquitetura está ilustrada na Figura 21, na qual mostra
o aplicativo sendo dependente do Firebase, sendo que, na prática, ele seria utilizado
apenas para o serviço de notificações, logo, o diagrama não exprimia genuinamente como
a aplicação funcionaria. Este aspecto foi corrigido na outra versão do diagrama, na Figura
22, que posteriormente também foi alterado.
No desenvolvimento da POC, esta arquitetura foi posta em prática e, junto à
implementação, foram observados problemas para realizar a implantação dos containers,
impossibilitando então que a estrutura previamente estabelecida fosse concluída. Ao tentar
encontrar uma solução para o empecilho, foi constatado que a documentação para .NET 7
na Google Cloud era muito escassa e, consequentemente, por falta de literatura, o problema
para subir os containers persistiu e parte da prova de conceito apresentava problemas. Esta
versão com erros foi apresentada, juntamente com comentários dos integrantes do grupo
sobre as dificuldades encontradas no processo de implementação. Também por orientação
dos professores e por consenso entre a equipe, a arquitetura foi modificada de Google
Cloud para Azure, que possui uma melhor documentação para a stack escolhida, além da
melhor compatibilidade com o ambiente, dado que a Microsoft detém os direitos da Azure
e é uma das maiores patrocinadoras do .NET (MICROSOFT, 2023).
Após esta modificação, a arquitetura foi implementada novamente, desta vez na
plataforma Azure, de forma mais facilitada, sem as problemáticas presentes no ambiente
Google. Ademais, também foi inserida uma camada a mais na aplicação: o Expo, que
realiza a intermediação entre as notificações direcionadas para dispositivos androids e
dispositivos IOS. Sequencialmente, após estas mudanças que tangem a arquitetura da
aplicação, a POC foi reapresentada, desta vez, com êxito.
Figura 21 – Arquitetura Versão 1.0
figuras/arquitetura1.0.jpeg
Figura 22 – Arquitetura Versão 1.1
figuras/arquitetura1.1.jpeg

4.15 Problemas Ocorridos no Gerenciamento e do Projeto

A formação inicial da equipe contava com seis integrantes. Porém, no decorrer
do projeto houveram problemas enfrentados pela equipe, principalmente relacionados a
falta de comunicação, alinhamento e expectativas entre os integrantes, além de atritos
interpessoais. Estes problemas resultaram na saída de dois dos seis integrantes do grupo.
Com o desfalque no time, os integrantes remanescentes se depararam com percalços
para absorver, gerenciar e executar as atividades até então atribuídas aos outros membros
em pouco tempo, dado que ambas as saídas ocorreram próximas a datas de entrega
importantes.
72
5 Conclusão
O gerenciamento financeiro para trabalhadores autônomos (neste contexto, em

especial, motoristas de aplicativo como Uber e 99) se mostra necessário, pois proporciona
mais autonomia e controle de gastos, e consequentemente, mais segurança em relação aos
seus ganhos em meio às incertezas inerentes desta modalidade de trabalho.
Desta forma, Carllet busca ser uma aplicação mobile de uso recorrente que viabiliza
esta solução por meio de por meio de funcionalidades que se adequam às necessidades do
público alvo. Para tal, foram utilizadas ferramentas como as linguagens C# e Javascript,
banco de dados PostgreSQL, com arquitetura baseada na infraestrutura Azure, além de
API’s externas.
Apesar de problemas encontrados no decorrer do andamento do projeto, tanto em
termos de tecnologias e ferramentas de desenvolvimento quanto em termos de gerenciamento
de equipe, estes contratempos foram contornados dentro do possível e os aprendizados
foram absorvidos. Com isso, o processo de desenvolvimento do projeto até então foi
proveitoso para o time, uma vez que conhecimentos teóricos e práticos por parte dos
integrantes foram aplicados, além do trabalho em equipe, se fez indispensável.
73
Referências
99. A 99 - 99. 2023. Disponível em: https://99app.com/sobre-a-99/. Citado 2 vezes

nas páginas 23, 76.
ACCENTURE. PLATFORMS WORK - Research with workers using the Uber
app during the first year of the COVID-19 pandemic. 2023. Disponível em:
https://www.platformsworkreport.com/. Citado 1 vez na página 16.
AGENCIA NACIONAL DO PETROLEO, GAS NATURAL E BIOCOMBUSTIVEIS.
Power BI - Painel Dinâmico de Preços de Combustíveis e Derivados do Petró-
leo. 2023. Disponível em: https://app.powerbi.com/view?r=eyJrIjoiMGM0NDhhMTU
tMjQwZi00N2RlLTk1M2UtYjkxZTlkNzM1YzE5IiwidCI6IjQ0OTlmNGZmLTI0YTYtNGI0Mi
1iN2VmLTEyNGFmY2FkYzkxMyJ9. Citado 1 vez nas páginas 17, 18.
ANTUNES, Ricardo (Ed.). Uberização, trabalho digital e Indústria 4.0. Sao Paulo:
Boitempo, 2020. ISBN 9786557170113. Citado 7 vezes nas páginas 14, 22, 23.
AUTOINFORME. Inflação do Carro tem nova alta em novembro | AutoInforme.
2022. Disponível em: https://www.autoinforme.com.br/inflacao-do-carro-tem-
nova-alta-em-novembro/. Citado 4 vezes nas páginas 14, 17, 23.
BALAPOUR, Ali; NIKKHAH, Hamid Reza; SABHERWAL, Rajiv. Mobile application
security: Role of perceived privacy as the predictor of security perceptions. Inter-
national Journal of Information Management, v. 52, p. 102063, 2020. ISSN
0268-4012. DOI: https://doi.org/10.1016/j.ijinfomgt.2019.102063. Disponível
em: https://www.sciencedirect.com/science/article/pii/S0268401219309041.
Citado 1 vez na página 51.
BARBOSA, LUIZA FERNANDES DE ABRANTES. A PRECARIZAÇÃO DAS
CONDIÇÕES DE TRABALHO PELA UBERIZAÇÃO: NECESSIDADE
DA PROTEÇÃO JURÍDICA NAS NOVAS RELAÇÕES LABORAIS. 2020.
Disponível em: https://antigo.monografias.ufrn.br/jspui/bitstream/123456
789/11035/1/APrecarizacaoDasCondicoesDeTrabalho_Barbosa_2020.pdf. Citado
1 vez na página 14.
BAUS, Ante. What is an MVP in the mobile app development process. 2022.
Disponível em: https://decode.agency/article/what-is-mvp-in-mobile-app-
development/. Citado 1 vez na página 67.
CRUZ, Sérgio Cristiano da. Plano de Projeto de Desenvolvimento de um Software
de Gerenciamento de Dispositivos Móveis. 2012. F. 2012. 96. Trabalho de
Referências 74
Conclusão de Especialização em Gestão de Projetos – Universidade do Vale do Rio dos

Sinos (UNISINOS), São Leopoldo. Citado 1 vez na página 60.
DRIVEYOU. DriveYou. 2023. Disponível em: https://driveyou.com.br/. Citado 1
vez na página 19.
FAIRWORK. Fairwork Brasil 2021: Por Trabalho Decente Na Economia De
Plataformas. 2021. Disponível em: https://fair.work/wp- content/uploads/
sites/17/2022/03/Fairwork- Report- Brazil- 2021- PT- 1.pdf. Citado 1 vez na
página 22.
FOR DRIVER. For Driver | Controle Financeiro para Motoristas. 2023. Disponível
em: http://fordriver.com.br/. Citado 1 vez na página 19.
GOOGLE ADMOB. Mobile App Monetization. 2023. Disponível em: https://admob.
google.com/home/home-calc. Citado 1 vez na página 63.
IBGE – INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA. PNAD Con-
tínua - Pesquisa Nacional por Amostra de Domicílios Contínua. 2023. Dis-
ponível em: https://www.ibge.gov.br/estatisticas/sociais/trabalho/9173-
pesquisa-nacional-por-amostra-de-domicilios-continua-trimestral.html?
edicao=20653&t=series-historicas. Citado 1 vez na página 16.
INSTITUTO DE PESQUISA ECONÔMICA APLICADA. Painel da Gig Economy no
setor de transportes do Brasil: quem, onde, quantos e quanto ganham. 2022.
Disponível em: https://www.ipea.gov.br/cartadeconjuntura/index.php/2022/
05/painel-da-gig-economy-no-setor-de-transportes-do-brasil-quem-onde-
quantos-e-quanto-ganham/. Citado 2 vezes nas páginas 14, 16, 17.
LGPD. Lei Geral de Proteção de Dados. 2018. Disponível em: https://www.planalto.
gov . br / ccivil _ 03 / _ato2015 - 2018 / 2018 / lei / l13709 . htm. Citado 0 vez na
página 45.
MALSAM, Willian. What Is Proof of Concept (POC)? Definition, Steps Best
Practices. 2021. Disponível em: https://www.projectmanager.com/blog/proof-
of-concept-definition/. Citado 1 vez na página 66.
MICROSOFT. Um tour por C# – Visão geral | Microsoft Learn. 2023. Disponível
em: https://learn.microsoft.com/pt- br/dotnet/csharp/tour- of- csharp/.
Citado 3 vezes nas páginas 55, 70, 76.
NIELSEN, Jakob. Response Times: The 3 Important Limits. 1993. Disponível em:
https://www.nngroup.com/articles/response- times- 3- important- limits/.
Citado 0 vez na página 45.
OPEN WEB APPLICATION SECURITY PROJECT. OWASP Top Ten | Top 10
Web Application Security Risks. 2021. Disponível em: https://owasp.org/www-
project-top-ten/#. Citado 1 vez nas páginas 52, 53.
Referências 75
PORTAL G1. Preço dos combustíveis aperta lucro de motoristas de app e

motoboys – que escolhem corridas e pensam em largar a profissão | Economia
| G1. 2021. Disponível em: https://g1.globo.com/economia/noticia/2021/07/28/
preco- dos- combustiveis- aperta- lucro- de- motoristas- de- app- e- motoboys-
que- escolhem- corridas- e- pensam- em- largar- a- profissao.ghtml. Citado 2
vezes nas páginas 17, 69.
PREFEITURA DE SÃO PAULO. Aplicativo mobizapSP já está em funcionamento
— Prefeitura. 2023. Disponível em: https://www.capital.sp.gov.br/noticia/
aplicativo-mobizapsp-ja-esta-em-funcionamento. Citado 1 vez na página 23.
REACT NATIVE. React Native · Aprenda uma vez, escreva em qualquer lugar.
2023. Disponível em: https://reactnative.dev/. Citado 1 vez na página 55.
REBU. rebU — Motorista Profissional. 2023. Disponível em: https://motoristatop.
com/rebu/. Citado 1 vez na página 20.
SERASA. Pesquisa: a Relação do Brasileiro com o Automóvel. 2023. Disponível
em: https://www.serasa.com.br/carteira-digital/blog/pesquisa-a-relacao-
do-brasileiro-com-o-automovel/. Citado 1 vez na página 16.
THE GUARDIAN. Uber drivers strike over pay and conditions. 2019. Disponível
em: https://www.theguardian.com/technology/2019/may/08/uber- drivers-
strike-over-pay-and-conditions. Citado 1 vez na página 23.
THE NEW YORK TIMES. Uber Drivers’ Day of Strikes Circles the Globe Before
the Company’s I.P.O. 2019. Disponível em: https://www.nytimes.com/2019/05/
08/technology/uber-strike.html. Citado 1 vez na página 23.
THE POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL: The World’s
Most Advanced Open Source Relational Database. 2023. Disponível em: https:
//www.postgresql.org/. Citado 1 vez na página 56.
TORRES, Vitor. Quanto custa um funcionário para empresa? Veja o cálculo
e como economizar na contratação. 2022. Disponível em: https://www.conta
bilizei.com.br/contabilidade-online/quanto-custa-um-funcionario-para-
empresa/. Citado 1 vez na página 61.
UBER. Nossa jornada até o fim das emissões de carbono | Uber. 2022. Disponível
em: https://www.uber.com/br/pt-br/about/sustainability/. Citado 1 vez na
página 69.
UBER. The Impact of Uber in Brazil – How Uber has transformed the on-
demand economy. 2023. Disponível em: https://uberbrazil.publicfirst.co/
?lang=pt-br. Citado 2 vezes na página 23.
76
Glossário
.NET Framework livre e de código aberto para os sistemas operacionais

Windows, Linux e macOS - Citado em 26, 58, 69, 70
99 Aplicativo de transporte individual com carros particulares em
atividade no Brasil (99, 2023) - Citado em 14
boards Quadro de visibilidade de atividades - Citado em 28, 29
Cloud Refere-se a tecnologia de serviços em nuvem - Citado em 61
Commits unidades estruturais de um cronograma de projeto Git - Citado em
30
dailys Reunião diária feita pelos membros de um time de tecnologia res-
ponsável por um projeto em andamento - Citado em 28
framework Estrutura de regras ou conceitos que servem de base para a cons-
trução de algo. - Citado em 25
Kanban Método popular de gestão de fluxo de trabalho - Citado em 25
Scrum Framework ágil para gestão de projetos de softwares - Citado em 25
C# Linguagem de programação desenvolvida pela Microsoft como parte
da plataforma .NET(MICROSOFT, 2023) - Citado em 59
Cabify aplicativo de transporte que lhe permite se movimentar em diversas
cidades ao redor do mundo. - Citado em 14
gamificação Gamificação ou Gamification, utilização de técnicas, estratégias e o
design de games em outros contextos que não sejam necessariamente
jogos - Citado em 69
Gig Economy Refere-se às formas alternativas de emprego - Citado em 7, 16
inDriver Aplicativo que permite a negociação da tarifa das viagens entre
motoristas e passageiros. - Citado em 14
IOS Sistema operacional móvel da Apple Inc. - Citado em 21, 70
Jest Estrutura de teste de JavaScript - Citado em 57
Sprint Período de tempo menor ou igual a um mês de desenvolvimento de
um projeto no Fframework Scrum - Citado em 9, 11, 28, 29
start-up Termo que representa uma "empresa" emergente e recém-criada
ainda em fase de desenvolvimento - Citado em 14, 25
Uber Aplicativo de transporte via carro particular, táxi e mototáxi fun-
dado em 2009 nos Estados Unidos - Citado em 14
Glossário 77
UI User Interface, é um termo comumente utilizado para explicar como

serão feitas as interações entre pessoas e softwares - Citado em 21
UX User Experience, é a forma como as pessoas interagem com um
produto ou serviço - Citado em 21
hyperref
Apêndices
79
APÊNDICE A – Links do Projeto
figuras/qrcoderepgit.png
Figura 23 – Link Repositório GitHub

https://github.com/orgs/pi1a5-grupo5/repositories
figuras/qrcodecanal.png
Figura 24 – Link Canal do YouTube

https://www.youtube.com/@carllet-app
APÊNDICE A. Links do Projeto 80
figuras/qrcoderepsvn.png
Figura 25 – Link Repositório SVN

https://svn.spo.ifsp.edu.br/svn/a6pgp/S202301-PI-NOT/Carllet/
figuras/qrcodeblog.png
Figura 26 – Link Blog

https://carlletapp.blogspot.com/
81
APÊNDICE B – ATAS DE REUNIÃO
Esta seção contém as atas das reuniões realizadas durante o período de desenvolvi-
mento.
B.1 Ata de Reunião 25/02/2023

Data: 25 de Fevereiro de 2023
Horário: 10:00
Local: Remoto (Google Meet)
Presentes: Daniel Rodrigues, Debora Peixoto, Estefanie Soares, Gabriela Dias, João
Pedro Vanderlei, Pedro Henrique Beserra
Pauta:
• Brainstorm de ideias de tema para aplicativos ou sistemas e escolha por meio de

votação
• Organização de tarefas e atividades
• Discussão sobre ideias, tecnologias e ferramentas
• Pesquisa de concorrentes
O que foi discutido: Cada integrante do grupo propôs ideias de tema e aplicações
resultando em 11 propostas para serem avaliadas e escolhidas.
1. Aplicativo de gestão para motoristas de apps (Uber, 99, etc) O app possui duas
features principais, a primeira é a gestão financeira para o motorista como controle de
abastecimento de gasolina, lucros, custos, análise descritiva de performance
E a segunda é a gestão do automóvel, como manutenção e custos Diferencial:
Previsão de lucro e gamification Possível plataformas: web pwa e app nativo em React
Native 2. Aplicativo de investimentos: plataforma que unifica investimentos Features:
Informativos de fundos de investimentos, venda de investimentos por empresas terceiras,
auxílio para o mercado financeiro. Necessidade de utilização de apis públicas para o
desenvolvimento da aplicação. 3. Site de contratação de equipes ágeis A plataforma web
permite que o cliente cadastre o projeto e os requisitos necessários e a equipe ágil se
candidata ao projeto.
APÊNDICE B. ATAS DE REUNIÃO 82
Há também leilão de equipes e negociação de valores pelos contratados, uma espécie

de cooperativa de desenvolvedores.
4. Gestão de tempo de tela para crianças
Aplicativo que visa resolver o problema de tempo de tela de crianças, com o controle
pelos pais e cronômetro para atividades que exigem foco e tempo fora da tela como lição
de casa etc.
5. Aplicativo de rotina, motivacional e treinos de Academia O aplicativo visa
resolver um dos maiores problemas de quem quer se exercitar que é manter a rotina de ir
a academia
Todos os itens necessários em um só lugar ( rotina de treinos, mapa de ganho
muscular em cada parte do corpo, cálculo de macro nutrientes, dieta e motivação(alarmes
e mensagens para motivar o usuário) 6. Design de Horta Mapeamento de plantas que
podem ou não estar perto de outra espécie 7. Aplicativo para troca de itens entre pais
recentes Bazar online que permite a troca de itens para bebês e crianças entre pais de
primeira viagem 8. Aplicação para gerenciamento de compra de ingressos Esboço da ideia
de uma plataforma que organize a compra de ingressos 9. Aplicação para pessoa jurídica
Plataforma de Gerenciamento para pessoas jurídicas 10. Plataforma de times e jogos Site
para que jogadores de cadastrem e formem times 11. Gamification Esboço de ideia de um
app que utilize a gamification para superação de vícios, construção de hábitos Após a
discussão e votação de todos os integrantes, foi decidido que a ideia escolhida será a número
1, "Aplicativo de gestão para motoristas de aplicativo"Também realizamos a pesquisa de
possíveis concorrentes e foram encontrados 3 ( driveyou, Fordriver, Rebu) Foi acordado
que o próximo passo será a elaboração de um plano de ação para o desenvolvimento do
documento a ser entregue, que deverá incluir o levantamento de requisitos e todos os
itens necessários conforme orientado pelos docentes. Ficou decidido que a plataforma de
gerenciamento de tarefas será o Jira, logo a metodologia ágil a ser utilizada será o Scrum.
E cada integrante já escolheu uma tarefa para realizar durante esta primeira Sprint.
Foi definido que a próxima reunião será realizada após a aula de terça feira dia 28/02 para
que o grupo tenha mais clareza sobre o tema e a aprovação dos professores.
Encerramento: Não havendo mais nada a ser tratado, a reunião foi encerrada às
12:40. Com duração de 2h e 40 minutos A ata foi redigida por Gabriela Dias Dutra. Todos
os presentes estão de acordo.

Data: 05 de Março de 2023
Horário: 10:00
Local: Remoto (Google Meet)

Pauta:
• Definição do escopo da apresentação e do projeto
• Discussão sobre uma possível mudança de escopo devido a análise de viabilidade
O que foi discutido: A reunião iniciou-se com a discussão sobre uma possível
mudança de escopo do projeto, onde o foco era estritamente os motoristas de aplicativo. E
a sugestão de mudança seria para atender motoristas em geral.
O problema era a viabilidade do uso de GPS.
Após a discussão ficou definido que será mantida a proposta já validada pelos
professores.
A reunião também serviu para o grupo organizar como será a primeira apresentação
e o que é esperado para as próximas.
Foi definido que a próxima reunião será realizada após a aula de terça feira dia
07/03 sendo a primeira apresentação.
Encerramento:
Não havendo mais nada a ser tratado, a reunião foi encerrada às 11:02. Com
duração de 1 hora.
A ata foi redigida por Gabriela Dias Dutra. Todos os presentes estão de acordo.

Data: 05 de Março de 2023
Horário: 10:00
Local: Presencial - IFSP
O que foi discutido: Necessidade da criação de um Rodômetro. O Rodômetro ficará
ligado o tempo todo(em segundo plano) computando os dados do carro em movimento(
porque não tem como saber se ele está em corrida ou em passeio)Mas é necessário um botão
de Play( que podemos colocar qualquer nome) para iniciar o Rodômetro da CorridaFoi
nesse momento que o Braz sugeriu o app da Porto Seguro que computa os dados da
aceleração do carro e velocidade automaticamente porque ele até afirmou "Quanto menos
o aplicativo depender do usuário melhor, o cara não vai ter que ficar apertando o botão
de ligar e desligar toda hora"Sugeriram também que seria mais fácil ter uma notificação
perguntando se o usuário está em corrida ou não, ou se não está em corrida hoje. O
Rodômetro precisa guardar duas variáveis no local storage Pesquisar sobre: Como funciona
um acelerômetro Api do Waze e app da Porto seguro Necessidade de marcar o início e fim
de uma corrida Como isso será feito? Pela captura da tela do app do Uber(por exemplo)
O cálculo do lucro pode ser feito com a fórmula: Faturamento - combustível -
manutenção = lucro O custo de manutenção deve levar em conta todos os fatores incluindo
alinhamento e balanceamento do carro, troca de vela e etc
Despesas de longo prazo e despesas de curto prazo O aplicativo necessita ter essas
informações Em resumo, o que é para ser entregue na poc é a prova de que é possível
calcular os quilômetros rodados de um destino. Como por exemplo um carro sai do ponto
A e precisa chegar no ponto C passando por B, o aplicativo deve considerar todo esse
percurso. E tendo esses dados é possível calcular as despesas. O grupo está se organizando
por meio do Whatsapp e cada um está contribuindo para a definição de requisitos e
atualização da documentação do projeto. Também estamos discutindo sobre arquitetura
do sistema

Data: 22 de Abril de 2023
Horário: 22:00
Local: Remoto (Discord)
Presentes: Debora Peixoto, Estefanie Soares, Gabriela Dias, João Pedro Vanderlei,
Pedro Henrique Beserra
Pauta:
• Organização de tarefas sobre documentação
• Discussão sobre mudanças para apresentação da POC
• Grupo de estudos Backend
O que foi discutido: Os integrantes do grupo se reuniram para discutir sobre o

andamento do projeto e dos pontos citados acima.
1. Organização de tarefas sobre documentação Foi realizada a divisão das tarefas

restantes antes da apresentação da POC. A divisão se deu entre: Edição de documentação,
correção de erros e desenvolvimento da POC.
2- Discussão sobre mudanças para apresentação da POC Questionamentos sobre os
possíveis erros que poderiam acontecer na apresentação.
3- Grupo de Estudos Backend Houve a troca de conhecimento entre os integrantes
com relação ao backend da aplicação e a apresentação da POC. Foram exibidas as principais
classes e foi discutido possíveis implementações de cloud e da arquitetura do sistema
00:10. Com duração de 2 horas e 10 minutos.

Data: 6 de Maio de 2023
Horário: 21:40
Local: Remoto (Discord)
Presentes: Debora Peixoto, Estefanie Soares, Gabriela Dias, João Pedro Vanderlei,
Pedro Henrique Beserra
Pauta:
• Discussão sobre a nova funcionalidade e diferenciais
• Atualização do MER e Der
• Discussão sobre Design patterns
O que foi discutido: Os integrantes do grupo se reuniram para discutir sobre o

andamento do projeto e dos pontos citados acima.
1. Nova Funcionalidade Conforme descrito na documentação: A partir da inserção
do valor que o motorista pretende obter em um determinado período de tempo (como
mês, por exemplo), juntamente com outras informações, tais como dias da semana e
faixas de horários em que costuma trabalhar, serão geradas metas diárias para que o valor
estabelecido seja atingido. O condutor conseguirá acompanhar o seu desempenho por
meio da comparação de valores entre o montante esperado e o valor gerado pelo modelo
preditivo contido na aplicação, que terá como base valores registrados no banco de dados,
os quais foram inseridos também pelo próprio motorista. Viabilizando este recurso, esta
funcionalidade se apresenta então como o diferencial da aplicação Carllet.
2- Atualização do Mer e Der Conforme discutido com os professores na aula anterior

3- Design Patterns
Discussão de quais designs implementar e como seria feito na situação onde o
motorista necessita compartilhar o carro e etc.
22:30. Com duração de 50 minutos
87
APÊNDICE C – Postagens no Blog
C.1 Semana 1
Publicado por: Gabriela Dias Dutra em 19/02/2023
Bom dia!
Somos o grupo 5 da disciplina Projeto Integrado I (PI1A5), noturno, do curso de
Análise e Desenvolvimento de Sistemas do IFSP - Instituto Federal de Educação, Ciência
e Tecnologia de São Paulo. Este blog foi criado para acompanhar, através de postagens
semanais, o andamento do nosso projeto final do curso.
Nosso grupo é formado por: Daniel Fonseca, Débora Peixoto, Estefanie Coleone,
Gabriela Dias, João Pedro Vanderlei e Pedro Henrique Beserra. Sendo que todos nós
éramos do período matutino e acabamos de ser transferidos para o noturno, e também
por já termos colaborado em outros trabalhos de outras disciplinas, fazia sentido que
formássemos um grupo para desenvolver nosso trabalho final.
Por enquanto, ainda não temos um tema de projeto, o qual será definido em breve,
em reunião. O tema será então apresentado aos professores para que seja aprovado. Até lá!
C.2 Semana 2
Após reunião realizada remotamente via Google Meet, o tema do nosso projeto
foi enfim definido. Depois de brainstorm de ideias, que resultou em 11 propostas, uma
votação elegeu o tema: o grupo 5, agora apelidado Carllet, desenvolverá uma aplicação
mobile que dará suporte a motoristas de aplicativo, provendo-lhes com ferramentas para
sua organização financeira, ao mesmo tempo em que foca em escolhas mais econômicas
e sustentáveis. O nome Carllet vêm da junção das palavras em inglês "car"(carro) e
"wallet"(carteira).
C.3 Semana 3
Em aula do dia 28/02, os professores validaram nosso tema, mas solicitaram que
definíssemos melhor qual seria o diferencial do nosso aplicativo em comparação aos demais
aplicativos similares disponíveis. Nos dias seguintes, foi elaborado um pitch de apresentação
APÊNDICE C. Postagens no Blog 88
da proposta, a qual foi apresentada em aula do dia 07/03. Um documento explicando a

ideia da aplicação, seus objetivos e tecnologias também foi elaborado e entregue neste dia.
C.4 Semana 4
Chegamos a quarta semana de desenvolvimento. Após a apresentação do da
07/03/2023 o grupo se reuniu informalmente pelo Whatsapp para discutir quais ru-
mos o projeto deveria tomar, levando em conta os comentários e sugestões dos professores
durante a apresentação.
Tivemos dificuldades em relação ao diferencial do aplicativo, uma vez, que ainda
restavam dúvidas sobre como implantaríamos a questão de sustentabilidade no app.
No dia 14/03/2022 realizamos uma reunião pelo Google Meet para aprimorar o
vídeo do Gource e novamente debater sobre o tema do aplicativo.
Ficou decidido nesta mesma noite que seguiríamos com o diferencial de interface do
aplicativo, simplicidade(acessibilidade) e verificar se a questão de recompensa ainda faria
sentido. Também ficou decidido que os integrantes: Estefanie, Daniel, Débora e Gabriela
ficariam responsáveis pelo documento de requisitos, histórias de usuário e a documentação
do projeto, enquanto João e Pedro dariam início ao desenvolvimento.
C.5 Semana 5
Esse post tem o objetivo de publicar o que foi discutido na quinta semana de
desenvolvimento entre o grupo e os professores. Pontos falados: Necessidade da criação de
um Rodômetro. O Rodômetro ficará ligado o tempo todo(em segundo plano) computando
os dados do carro em movimento( porque não tem como saber se ele está em corrida ou
em passeio)Mas é necessário um botão de Play( que podemos colocar qualquer nome) para
iniciar o Rodômetro da CorridaFoi nesse momento que o Braz sugeriu o app da Porto
Seguro que computa os dados da aceleração do carro e velocidade automaticamente porque
ele até afirmou "Quanto menos o aplicativo depender do usuário melhor, o cara não vai
ter que ficar apertando o botão de ligar e desligar toda hora"Sugeriram também que seria
mais fácil ter uma notificação perguntando se o usuário está em corrida ou não, ou se
não está em corrida hoje. O Rodômetro precisa guardar duas variáveis no local storage
Pesquisar sobre: Como funciona um acelerômetro Api do Waze e app da Porto seguro
Necessidade de marcar o início e fim de uma corrida Como isso será feito? Pela captura da
tela do app do Uber(por exemplo) Sobre a manutenção do veículo Cadastrar tabela de

consumo, É necessário mostrar diariamente valores de manutenção exemplo
O cálculo do lucro pode ser feito com a fórmula:
Faturamento - combustível - manutenção = lucro O custo de manutenção deve
levar em conta todos os fatores incluindo alinhamento e balanceamento do carro, troca de
vela e etc Despesas de longo prazo e despesas de curto prazo O aplicativo necessita ter
essas informações
Resumo da ópera
O que é para ser entregue na poc é a prova de que é possível calcular os quilômetros
rodados de um destino. Como por exemplo um carro sai do ponto A e precisa chegar no
ponto C passando por B, o aplicativo deve considerar todo esse percurso. E tendo esses
dados é possível calcular as despesas.
Como está o grupo?
O grupo está se organizando por meio do Whatsapp e cada um está contribuindo
para a definição de requisitos e atualização da documentação do projeto. Também estamos
discutindo sobre arquitetura do sistema
C.6 Semana 6 - Produção a Todo Vapor

Na sexta semana de desenvolvimento o grupo se dedicou a finalizar o documento e
desenhar a arquitetura do projeto.
Tivemos algumas dificuldades relacionadas a como desenvolver as histórias de
usuário que após pesquisas na internet e orientação dos professores conseguimos desenvolver
e para a arquitetura também foi necessário o estudo de todos os integrantes do grupo
Dedicamos algumas horas para editar a documentação e ajustar o texto.
Após a aula do dia 28/03 esclarecidos todos os pontos que necessitam ser excluídos
ou melhorados e sanamos as dúvidas que tínhamos com relação a entrega do dia 04/03
O grupo mantém a comunicação diária no Whatsapp onde discutimos tudo que
será feito e tiramos as dúvidas de cada um
C.7 Semana 7 - Entrega do Desenho da Aplicação

Na aula de 04/04/2023 entregamos o desenho da aplicação.
No momento da entrega conversamos com os professores que nos orientaram sobre

os erros que tínhamos e que seria necessário a correção.
O foco do grupo agora está na correção da documentação, produção da apresentação
do desenho da aplicação e planejando os próximos passos
C.8 Semana 8 - Apresentação do Desenho da Aplicação

Na oitava semana de desenvolvimento o foco foi estudar para a apresentação e
corrigir os erros da documentação conforme orientação dos professores
No 11 de abril de 2023 apresentamos o desenho da nossa aplicação
O grupo se reuniu informalmente pelo Whatsapp e Discord para que cada integrante
infromasse o que estava sendo desenvolvido por cada pessoa e o grupo validasse. Esta
semana não há muitas mudanças que podem ser descritos nesta postagem.
C.9 Semana 9
A semana nove necessitou que o grupo tivesse maior engajamento para corrigir os
erros após receber o relatório dos professores sobre a documentação entregue
Estas foram as seguintes modificações que precisavam ser corrigidas além do
desenvolvimento da Prova de Conceito.
Adicionar consistência e fluidez entre os dados, verificar dados divergentes da
justificativa Recorte dos dados apresentados (localização geográfica) Texto e Gráfico
IPEA - referencias ultizadas em outras partes do texto estao divergentes sobre aumento
de uber pos pandemia Topico de Gastos deve estar na Justificativa Termo hard skills -
conhecimento e habilidade Falta falar das cerimonias Scrum Arrumar diagrama arquitetura
Texto arquitura mal escrito História de Usuário - concisa e direta Nao lembro mas falaram
MER - ganho e despesa relacionado ao veículo (despesas do veículo) ganho e despesa na
entidade associativa // marca e modelo do carro separado (normalização) Tipo de dado da
senha Mudar os tipos de dados do der Texto com adjetivos sem fonte ex: excelente Codding
Convention Design Pattern Tabela de Viabilidade - detalhes das horas/dias de projeto
(quadro e texto) Ajuste de estimativa Detalhes do que compõem a receita (o que é por
propaganda, o que é por assinatura etc) Protótipo do Dash de Gerenciamento Financeiro
Consistência e fluidez dos textos Tempo verbal Referencias Acentuação Referencia no texto
dos quadros/tabelas/imagens Incluir siglas na lista de siglas Colocar italito palavras em
Ingles
Além disso foram precisas mais horas do que o esperado para a correção de bugs
do sistema para efetivamente entregar a poc.
C.10 Semana 10
Semana de entrega e apresentação da Prova de Conceito da arquitetura da aplicação
Carllet
Essa foi uma semana intensa para a produtividade e desenvolvimento do grupo.
O foco estava em corrigir todos os erros e entregar a Poc corretamente, porém pela
ineficiência da Cloud escolhida(GOOGLE CLOUD) a apresentação não cumpriu com as
expectativas. Mas isso serviu para que o grupo se rearranjasse da solução e buscasse novas
clouds para desenvolver.
C.11 Semana 11
E chegamos a mais uma semana de desenvolvimento, Sprint 11, segundo o crono-
grama proposto pelo grupo.
Na terça feira o grupo reapresentou a POC provando a eficiência da aplicação, o
que não ocorreu na primeira apresentação.
Ficou decidido que a arquitetura passará por mudanças de Cloud.
Além disso depois da conversa com os professores tivemos o aval para implementar
a análise preditiva que será um diferencial do produto, porém só ocorrerá posteriormente.
Agora o foco será entregar o que foi proposto para o MVP na Apresentação do Projeto.
Serão entregues as implementações dos seguintes requisitos funcionais: RF1: Geren-
ciador de Usuário RF2: Login e Autenticação RF3: Localização no Mapa via GPS RF4:
Gerenciador de corrida RF5- Rodometro
C.12 Mudança de integrantes do grupo

A partir da presente data 09/05/2023, o grupo de desenvolvimento do aplicativo
Carllet é composto pelos seguintes 4 integrantes: Débora Peixoto dos Santos, Gabriela
Dias Dutra, João Pedro Vanderlei, Pedro Henrique Beserra Lima
C.13 Semana 12
Na décima segunda semana de desenvolvimento o grupo agora composto por 4
integrantes se reorganizou nas divisões de tarefas e decidiu quais itens priorizar para a
entrega do MVP.
A idéia e focar em adicionar mais elementos textuais para complementar a docu-
mentação, corrigir todos os erros e desenvolver o MVP.
Neste momento, nota-se uma maior integração entre a equipe e o foco em entregar
um trabalho de altíssima qualidade.
93
APÊNDICE D. Proposta Incicial 94
APÊNDICE D – Proposta Incicial
figuras/propostaInicial/capa.png
figuras/propostaInicial/intro.png
figuras/propostaInicial/intro2.png
figuras/propostaInicial/objetivos.png
figuras/propostaInicial/tenologias.png
figuras/propostaInicial/concorrentes.png
figuras/propostaInicial/concorrentes2.png
figuras/propostaInicial/ref.png
figuras/propostaInicial/ref2.png

PI1A5 Desenho Da Aplica o v07 Teste

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PI1A5 Desenho Da Aplica o v07 Teste

Enviado por

Direitos autorais:

Formatos disponíveis

IFSP - Instituto Federal de Educação, Ciência e Tecnologia

Câmpus São Paulo

Débora Peixoto dos Santos SP3069028

São Paulo - SP - Brasil

Débora Peixoto dos Santos SP3069028

Proposta de projeto para disciplina PI1A5 -

Professor: ANTONIO AIRTON PALLADINO

IFSP - Instituto Federal de Educação, Ciência e Tecnologia

São Paulo - SP - Brasil

Gostaríamos de expressar nossa sincera gratidão aos familiares dos integrantes do

Palavras-chaves: motoristas de aplicativo. gestão financeira. transporte urbano.

Keywords: ride-hailing drivers, financial management, urban transportation.

Figura 1 – Evolução do Quantitativo de Trabalhadores da Gig Economy no Setor

Tabela 1 – Métricas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Quadro 1 – Inflação do Carro Novembro 2022 - Agência Autoinforme . . . . . . . 18

API Application Programing Interface - Interface de Programação de

3 METODOLOGIAS DE GESTÃO DE PROJETO E DE DESENVOL-

APÊNDICE A – LINKS DO PROJETO . . . . . . . . . . . . . . . . 79

APÊNDICE B – ATAS DE REUNIÃO . . . . . . . . . . . . . . . . . 81

APÊNDICE C – POSTAGENS NO BLOG . . . . . . . . . . . . . . 87

APÊNDICE D – PROPOSTA INCICIAL . . . . . . . . . . . . . . . 94

A automatização e robotização dos processos produtivos tem avançado nos últimos

• Falicitar a gestão dos gastos relacionados ao abastecimento do automóvel;

• Falicitar a gestão dos gastos relacionados à manutenção do automóvel;

• Proporcionar um melhor planejamento ao motorista por meio do estabelecimento de

• Contribuir para que motoristas parceiros de aplicativos diminuam sua insegurança e

1.2 Solução Proposta

Figura 1 – Evolução do Quantitativo de Trabalhadores da Gig Economy no Setor de

Fonte: IPEA (2022)

Fonte: IPEA (2022)

Quadro 1 – Inflação do Carro Novembro 2022 - Agência Autoinforme

Item Variação Participação Valor

Como observado no Quadro 1, o combustível tem uma parcela elevada na contri-

Figura 3 – Evolução dos preços médios - GASOLINA COMUM

Fonte: ANP (2023)

dos motoristas de gerenciarem suas rendas e de encontrarem alternativas para minimizar

1.4 Análise da Concorrência

Quadro 2 – Aplicativos similares

Aplicação Empresa Plataforma Downloads

1.4.1 Drive you

• Controle financeiro para gestão de gastos, lucros e investimentos;

• Comunidade para interação entre motoristas;

• Premiações para usuários, por meio de sorteios mensais e descontos em produtos e

1.4.2 For driver

• Definição de metas por parte do motorista;

• Gestão financeira, com gerenciamento de recebimentos e gastos;

• Gráficos que informam o rendimento mensal.

• Função ’Alerta de Pânico’, que envia um alerta a autoridades ou outros motoristas,

Quadro 3 – Comparativo de funcionalidades entre aplicativo Carllet e similares

Funcionalidade Carllet Driveyou For driver Rebu

Desta forma, o principal diferencial do aplicativo Carllet, em comparação aos

1.5 Estrutura do Trabalho

• Capítulo 1: Contém a introdução, definição do problema, justificativa do trabalho e

• Capítulo 2: Contém a revisão de literatura dos principais termos do projeto;

• Capítulo 3: Contém os assuntos que abordam o gerenciamento do projeto;

• Capítulo 4: Contém os assuntos que abordam o desenvolvimento do projeto;

• Capítulo 5: Contém a conclusão dos pontos principais do texto

• Apêndices: Contém os links do projeto, atas de reunião,publicações realizadas no

2.1 Serviços na Era Digital

2.1.1 Aplicativos para Motoristas Parceiros

2.1.2 Inseguranças sobre Ganhos Líquidos

Em 21 de março de 2023, a Uber atualizou seus Termos de uso. Foi incluído no

Finalmente, você reconhece e confere força probatória plena: (i) às telas