1

UNIVERSIDADE VIRTUAL DO ESTADO DE SÃO PAULO

José Vilson Bezerra de Albuquerque -RA 1712316

José William Rodrigues Pereira- RA 2004712
Luís Fernando Moura Fernandes Braga-RA 2011286
Marcelo Martins Ribeiro dos Santos-RA 2009113
Michelle Neves de Oliveira L. de Souza-RA 2003009

Desenvolvimento de um sistema de agendamento para recursos tecnológicos

didáticos

Vídeo de apresentação do Projeto Integrador

<https://youtu.be/7KDSwtpSoFU>

Barueri - SP
2021
 2

UNIVERSIDADE VIRTUAL DO ESTADO DE SÃO PAULO

Desenvolvimento de um sistema de agendamento para recursos tecnológicos

didáticos

Relatório Técnico-Científico apresentado na disciplina de

Projeto Integrador para os cursos de Engenharia da
Computação, Ciência de dados e Tecnologia da informação
da Universidade Virtual do Estado de São Paulo
(UNIVESP).

Barueri - SP
 3

2021

ALBUQUERQUE, José V. B.; PEREIRA, José W. R.; BRAGA, Luís F. M. F.; SANTOS,
Marcelo M. R.; SOUZA, Michelle N. O. L. Desenvolvimento de um sistema de agendamento
para recursos tecnológicos didáticos. 43f. Relatório Técnico-Científico. Engenharia da
Computação, Ciência de Dados e Tecnologia da Informação – Universidade Virtual do Estado
de São Paulo. Tutor: SILVA, Cláudia Liciely Barbosa. Polo Barueri, 2021.

RESUMO

Ao longo dos anos trabalhando em escolas públicas temos observado no dia a dia, o modo como
professores e outros profissionais da educação tem evoluído suas técnicas didáticas e
orientações com o uso das tecnologias da informação e a manipulação de dispositivos que a
cada dia mais escolas tem disponibilizado aos profissionais da educação para organizar sua
demanda pedagógica na aprendizagem dos alunos. Isso gera um problema no controle e
organização na retirada e entrega desses dispositivos quando utilizados pelos usuários. Devido
à grande quantidade de dispositivos eletrônicos utilizados diariamente, como chromebooks e
projetores de vídeo, surgem conflitos de agendamento no acesso e na entrega desses
dispositivos. Isso tem ocorrido nas escolas que visitamos, sendo que estas escolas tem grande
número de salas de aula e consequentemente grande número de usuários desses dispositivos.
Neste sentido, este trabalho tem como objetivo apresentar uma proposta de solução tecnológica
para auxiliar a gestão de distribuição e controle desses equipamentos eletrônicos para os
usuários. A partir dos problemas apresentados em relação ao controle eficiente e prático desses
equipamentos e recursos didáticos da escola e de pesquisas realizadas com professores e alunos,
surgiu a proposta de desenvolvimento de um software de agendamento de dias e horários e
registro de uso de entrada e saída pelo professor responsável. O desenvolvimento desse software
será com um framework web que utilize noções de banco de dados, praticando controle de
versão. O registro de uso será armazenado em um banco de dados. Com base nos resultados
obtidos, o sistema atende a demanda de agendamento e controle dos equipamentos tecnológicos
melhorando as metodologias utilizadas atualmente.

PALAVRAS-CHAVE: Tecnologia; Dispositivos; Software; Controle.

 4

ALBUQUERQUE, José V. B.; PEREIRA, José W. R.; BRAGA, Luís F. M. F.; SANTOS,
Marcelo M. R.; SOUZA, Michelle N. O. L. Desenvolvimento de um sistema de
agendamento para recursos tecnológicos didáticos. 43f. Relatório Técnico-Científico.
Engenharia da Computação, Ciência de Dados e Tecnologia da Informação – Universidade
Virtual do Estado de São Paulo. Tutor: SILVA, Cláudia Liciely Barbosa. Polo Barueri, 2021.

ABSTRACT

Over the years working in public schools we have observed on a daily basis, how teachers and
other education professionals have evolved their didactic and guiding techniques with the use
of information technologies and the manipulation of devices that more and more schools have
made available to education professionals to organize their pedagogical demand on their
students' learning, generating an impact on ways of using and appropriating information and
communication technologies. Due to the large amount of electronic devices used daily, such as
chromebooks and video projectors, scheduling conflicts arise in the access and delivery of these
devices. In this sense, this work aims to present a technological solution proposal to help the
management of distribution and control of these electronic devices for the users. From the
problems presented in relation to the efficient and practical control of these equipments and
didactic resources of the school and from researches done with teachers and students, the
proposal of developing a software for scheduling days and times and registering the use of entry
and exit by the responsible teacher emerged. The development of this software will be with a
web framework that uses notions of database, practicing version control. The usage register will
be stored in a database. Based on the results obtained, the system meets the demand for
scheduling and control of technological equipment improving the methodologies currently used.

KEY WORDS: Technology; Devices; Software; Control.

 5

LISTA DE ILUSTRAÇÕES

FIGURA 1– PÁGINA DA DOCUMENTAÇÃO E INSTALAÇÃO DO GIT..............................……………....... 11

FIGURA 2– PÁGINA DO GITHUB.......................................................................………………............ 12

FIGURA 3– PÁGINA DA DOCUMENTAÇÃO DO FLASK..............................................…………….......... 14

FIGURA 4– PÁGINA DO MARIADB……………….................................................………………........ 15

FIGURA 5– FORMULÁRIO DE PESQUISA………………............................................………............. 17

FIGURA 6– RESPOSTAS DOS PROFESSORES (CARGO)..............................................……………......... 18

FIGURA 7– RESPOSTAS DOS PROFESSORES (ESCOLA EM QUE LECIONA).......................……………... 19

FIGURA 8– RESPOSTAS DOS PROFESSORES (UTILIZAÇÃO DOS RECURSOS TECNOLÓGICOS)…............. 19

FIGURA 9– RESPOSTAS DOS PROFESSORES (IMPORTÂNCIA NO USO DE UM APLICATIVO)...…….......... 20

FIGURA 10– CARRINHO DE CHROMEBOOKS........................................................……………………… 25

FIGURA 11– PÁGINA “HOME” DA SOLUÇÃO INICIAL.............................................………….............. 26

FIGURA 12– PÁGINA “HOME” DA SOLUÇÃO INICIAL (PARA CELULAR) ......................…............. 27

FIGURA 13– FORMULÁRIO DE AGENDAMENTO – NOME, ESCOLA E PERÍODO...............…………....... 28

FIGURA 14– FORMULÁRIO DE AGENDAMENTO – DISCIPLINA E HORÁRIOS..................…………....... 29

FIGURA 15– FORMULÁRIO DE AGENDAMENTO – CARRINHOS………………...............……............. 29

FIGURA 16– CADASTRO REALIZADO COM SUCESSO………………..........................………………….30

FIGURA 17– PÁGINA “HOME” DA SOLUÇÃO FINAL……………………………............................. 32

FIGURA 18– CALENDÁRIO DIÁRIO DAS RESERVAS EFETUADAS……..…………............................. 32

FIGURA 19– TELA DE LOGIN………………….………………..….………………......................... 33

FIGURA 20– PÁGINA “HOME” – ÁREA DO USUÁRIO…………..…………..…............................... 34

FIGURA 21– PÁGINA “AGENDAR” (ANTES DA RESERVA)..……………..…..…............................. 35

FIGURA 22– PÁGINA “AGENDAR” (DEPOIS DA RESERVA)..………………....…............................. 35

FIGURA 23– PÁGINA “EXCLUIR” ..…………..…...................………………………………….......... 36

FIGURA 24– PÁGINA “HOME” – ÁREA DO ADMINISTRADOR ..………….....…..........................………37

FIGURA 25– CADASTRO E EXCLUSÃO DE USUÁRIOS ..…………..…..........................………………... 38

FIGURA 26– CADASTRO E EXCLUSÃO DE CARRINHOS ..…………..…........................……………..... 38

FIGURA 27– CADASTRO E EXCLUSÃO DE AGENDAMENTOS...…………..…..........................…………. 39

 6

SUMÁRIO

1. INTRODUÇÃO...................................................................................................................... 7
2. DESENVOLVIMENTO....................................................................................................... 9
2.1 PROBLEMA E OBJETIVOS ........................................................................................................ 9
2.2. JUSTIFICATIVA ...................................................................................................................... 9
2. 3. FUNDAMENTAÇÃO TEÓRICA ................................................................................................ 10
2.4. APLICAÇÃO DAS DISCIPLINAS ESTUDADAS NO PROJETO INTEGRADOR ................................. 15
2.5. METODOLOGIA ................................................................................................................... 16
3. RESULTADOS .................................................................................................................. 24
3.1. SOLUÇÃO INICIAL ................................................................................................................ 25
3.2. SOLUÇÃO FINAL .................................................................................................................. 31
4. CONSIDERAÇÕES FINAIS ............................................................................................ 40
REFERÊNCIAS ..................................................................................................................... 42
 7

1.INTRODUÇÃO

Muitos ambientes escolares como laboratórios, salas de informática e até mesmo salas
de vídeo, onde os docentes desenvolvem suas atividades e aulas práticas, envolvem o uso de
equipamentos e materiais utilizados para desenvolverem seus projetos pedagógicos. Outras
vezes, os docentes utilizam esses equipamentos ou dispositivos tecnológicos em sala de aula,
sendo necessário requisitar esses equipamentos e depois devolverem no local, onde são
guardados. Por isso é necessário um controle para agendamento desses recursos e muitas vezes
esse controle é feito de forma manual, fazendo anotações na retirada e entrega desses materiais.
Nas escolas da rede municipal de Barueri existem essas características, principalmente no que
diz respeito ao laboratório de informática, onde estão alocados dezenas de computadores
portáteis, chamados de chromebooks. Esses chromebooks são diariamente utilizados por
professores que requisitam ou agendam esses dispositivos para utilização dos seus alunos em
sala de aula, além dos projetores de vídeos. Foi o que constatamos em duas escolas da rede
municipal de Barueri, onde propusemos o desenvolvimento de um software de agendamento de
dias e horários e registro de uso de entrada e saída pelo professor responsável.
O controle desses equipamentos é realizado de modo manual com anotações feitas em
uma planilha impressa, por um docente responsável pelo laboratório, procedimento esse às
vezes impreciso, pois na correria muitos professores retiram os equipamentos sem anotação
causando alguns problemas de esquecimento na entrega.
Foi realizada uma pesquisa com professores de algumas escolas da rede municipal de
Barueri devido à criticidade do problema vivenciado pelos usuários. Nesta pesquisa,
questionamos a possível aplicação do software a ser desenvolvido e sua real importância para
os professores, principais usuários. Desta forma, podemos confirmar a demanda que já foi
apresentada por um pequeno grupo de professores, já tendo sido alvo de discussões e problemas
nas escolas devido à falta de organização no uso e manejo dos recursos utilizados
A dificuldade em gerenciar a disponibilização dos equipamentos, o controle realizado
de forma escrita, manualmente, a dificuldade na responsabilização em caso de equipamentos
danificados e/ou extraviados, bem como a falta de uma forma adequada, eficiente e simples de
agendar o uso dos recursos motivaram a escolha do tema deste projeto, o qual se correlaciona
com o tema norteador definido pela UNIVESP, porque irá propor e desenvolver um software
com framework web que irá utilizar, por exemplo, o banco de dados de usuários, utilização e
agendamentos para gerenciar a utilização de equipamentos nas escolas. O desenvolvimento será
 8

feito de forma colaborativa entre os membros da equipe utilizando ferramenta de

versionamento.
 9

2.DESENVOLVIMENTO
2.1 Problema e Objetivos

Objetivo geral:

• Desenvolver um software com framework web utilizando banco de dados de

usuários para gerenciar a utilização e agendamentos de equipamentos nas escolas,
praticando controle de versão.
Objetivos específicos:
• Utilizar o Framework Web Flask para desenvolver uma página web.
• Utilizar o gerenciador de banco de dados MariaDB para integrar a comunicação
(armazenar e recuperar dados) entre sistema e usuário.
• Facilitar o agendamento de equipamentos e outros dispositivos tecnológicos
necessários para a realização de aulas práticas de professores.
• Prover um controle maior na retirada e entrega desses equipamentos
• Facilitar o gerenciamento dos equipamentos quanto à necessidade de manutenção

2.2. Justificativa e delimitação do problema

Nossa proposta de intervenção surgiu a partir de uma conversa com a comunidade

escolar a respeito de problemas existentes atualmente e que poderiam ser solucionados a partir
de um software simples
Diante do problema levantado, “dificuldade em gerenciar a disponibilização dos
equipamentos, o controle realizado de forma escrita manualmente, a dificuldade na
responsabilização em caso de equipamentos danificados e/ou extraviados, bem como a falta de
uma forma adequada, eficiente e simples de agendar o uso dos recursos”, surgiu a pergunta:
Como podemos melhorar o gerenciamento desses recursos tecnológicos de forma segura e
eficaz?
A utilização de um software que auxilie no gerenciamento dos recursos materiais
disponíveis para os usuários em uma escola ou outra instituição oferece muitos benefícios,
criando um ambiente que promove a colaboração e a responsabilidade, além da relevância
social de se buscar maneiras cada vez mais modernas e eficientes para desempenhar atividades
do dia a dia, gerando uma economia de tempo para todos os envolvidos.
 10

Elaboramos uma pesquisa para ser respondida pelos próprios usuários dos recursos para
levantamento dos requisitos necessários à implementação da solução deste problema. Esta
pesquisa, através das respostas dos usuários, demonstrou claramente a necessidade de se
implementar um software de controle e agendamento dos recursos utilizados.

2. 3. Fundamentação teórica

2.3.1 Levantamento de requisitos

Podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo
cliente que deverão ser atendidas para solucionar um determinado problema do negócio no qual
o cliente faz parte (SPÍNOLA, 2008). No caso de requisito de software é o que define os
objetivos e funções que um software precisa executar, bem como as que ele não pode ter.
Segundo a IEEE (1990) a análise de requisitos é um processo que envolve o estudo das
necessidades do usuário para se encontrar uma definição correta ou completa do sistema ou
requisito de software.
Quanto ao levantamento desses requisitos, em Engenharia de requisitos existem várias técnicas
que podem ser utilizadas. Em MORAES, (2009) vamos encontrar que as técnicas de
levantamento de requisitos têm por objetivo superar as dificuldades relativas a esta fase. Todas
as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que
podem ser utilizadas em conjunto pelo analista”.
A técnica utilizada neste levantamento de requisitos foi a elaboração de um questionário
para os usuários dos recursos a serem gerenciados pelo software. Segundo MORAES, (2009) a
técnica de entrevistas e questionários é uma das técnicas mais simples, mas de grandes
resultados principalmente nas fases iniciais do projeto. Para esta técnica é necessário haver um
plano de entrevista ou questionário bem definido, para que no momento da entrevista não haja
desvios e dispersão do assunto principal, entrevistas longas e cansaço pode acarretar em
prejuízos na coleta de requisitos por esta técnica.

2.3.2 Controle de versões

São ferramentas que gerenciam mudanças em programas de computador, documentos,

web sites, etc. Com essas ferramentas, é possível rastrear alterações no código, combinar
 11

diferentes atualizações, reverter as versões anteriores, etc. Podendo assim obter o histórico de
alterações que foram feitas ao longo do desenvolvimento do programa.

Em nosso projeto foi utilizado o GIT, que é um sistema de controle de versões que
permite gerenciar e rastrear o histórico de alterações no código.

O GIT é um sistema de controle de versão que, pela sua estrutura interna, é uma máquina
do tempo extremamente rápida e é um robô de integração bem competente. Foi criado em 2005
por Linus Torvalds, o mesmo criador do Linux, que estava descontente com o Bitkeeper, o
sistema de controle de versão utilizado no desenvolvimento do kernel do Linux. AQUILE e
FERREIRA (2014,pg 3). Abaixo a página da documentação e instalação do GIT:

Figura 1 - Página da documentação e instalação do GIT

Fonte: https://git-scm.com/

O projeto foi armazenado no GitHub que é um serviço de armazenamento em nuvem e

permite gerenciar repositórios criados com o GIT. Criado em 2008 o GitHub é uma aplicação
web que possibilita a hospedagem de GIT, além de servir como como uma rede social para
programadores AQUILE e FERREIRA (2014,pg 3). Abaixo a página do GitHub:
 12

Figura 2 - Página do GitHub

Fonte: https://github.com/

2.3.3 Python

A linguagem de programação utilizada neste projeto foi a linguagem Python que é uma
linguagem muito popular, utilizada por muitos desenvolvedores para desenvolvimento web e
outras aplicações.

A linguagem Python foi criada no final dos anos 1980 por Guido Van Rossum, no CWI
(Centrum Wiskunde & Informatica) - Centro de Matemática e Ciência da Computação - em
Amsterdã, na Holanda, onde trabalhava na época.

Em MACIEL, (2020, p. 1) encontramos as principais características de Python que são:

• Alto nível — é uma linguagem de alto nível, ou seja, sua sintaxe é,
conceitualmente, mais próxima da linguagem natural que da linguagem de
máquina.
• Interpretada — O código-fonte é rodado por outro programa, o interpretador.
De fato, primeiro o código é convertido para um formato intermediário,
denominado bytecode (tecnicamente, o código é compilado para esse formato).
Os arquivos no formato bytecode têm extensão .pyc. Esse código intermediário é
então convertido pelo interpretador, que é específico para cada sistema
operacional, em chamadas nativas ao S.O. da máquina na qual o programa está
sendo executado. Esse processo tem vantagens e “desvantagens”. A principal
vantagem é a portabilidade de código — código convertido para bytecode de
uma determinada arquitetura deve executar em qualquer interpretador que
implemente a mesma arquitetura. Coloquei a palavra desvantagens entre aspas
porque, de fato, o maior problema dessa abordagem, quando ela surgiu, era o
tempo que a máquina perdia no processo de tradução e execução, porém,
atualmente os computadores são tão rápidos que esse tempo é, quase sempre,
irrelevante (com exceção de sistemas para os quais o tempo de execução é crítico,
mas esses costumam ser desenvolvidos com outras linguagens).
 13

• De script — Pode ser utilizada para escrever pequenos programas (scripts), esse
é um ponto muito forte de Python. É possível automatizar facilmente diversas
tarefas com pouca codificação.
• Multiparadigma — Python não se enquadra em um único paradigma de
linguagem de programação, sendo considerada, ao mesmo tempo, imperativa e 1

funcional. Dentro do paradigma imperativo pode ser classificada,

simultaneamente, como procedural e orientada a objetos.
• Tipagem forte — Uma linguagem de programação é dita fortemente tipada se
os tipos de dados são verificados em todas as operações, seja em tempo de
compilação ou de execução. Ficou confuso? Veja um exemplo:
Em JavaScript, se declarar:
‘2’ + 3 // resultado: ‘23’
5 + True // resultado: 5True
Pois o interpretador não restringe os tipos permitidos, então você consegue somar uma
string com um número ou um número com um booleano; em Python, tais somas resultariam
em erros de compilação.
• Tipagem dinâmica — Uma linguagem possui tipagem dinâmica se ela infere o
tipo de dados que uma variável armazena com base no valor recebido, sem a
necessidade de o programador declará-lo explicitamente. Nas linguagens
estaticamente tipadas, como é o caso de C e Pascal, por exemplo, o programador
deve especificar o tipo da variável. Além disso, em uma linguagem
dinamicamente tipada, a variável pode mudar o seu tipo de dado em tempo de
execução. Não entenda isso como uma limitação, há tarefas para as quais uma
determinada linguagem é mais indicada que outra.
• Case sensitive — Uma linguagem é case sensitive quando faz distinção entre
maiúsculas e minúsculas. Assim, dois identificadores (nomes), Something1 e
something1 são coisas diferentes para o interpretador Python.
2.3.4 Flask
Flask é um micro framework escrito com a linguagem Python para criar aplicativos Web
de fácil usabilidade. Foi criado e desenvolvido por Armin Ronacher, líder da comunidade de
entusiastas do Python chamada Poocco. O Flask é baseado no kit de ferramentas Werkzeug
WSGI e na biblioteca Jinja2 que são projetos da Poocco (WILLIAN, 2020).
O Flask é instalado no terminal de comando através do Python utilizando o PIP install
e tem versões para MacOs, Linux e Windows . Abaixo a página da documentação e suporte do
Flask.

Figura 3 - Página da documentação do Flask

 14

Fonte: https://flask.palletsprojects.com/en/2.0.x/

2.3.5 Maria DB
O MariaDB é um dos bancos de dados relacionais mais conhecidos do mundo, criado
pelos mesmos desenvolvedores do MySQL, que mantiveram a estrutura de código aberto. Sua
principal característica é a rapidez, escalabilidade e robustez de suas ferramentas, plugins e,
claro, capacidade de armazenamento. Isso o fez conseguir usuários de renome, como: Google,
Wikipedia, Blablacar, Nokia e Samsung SOUZA, (2020).
O nome MariaDB seguiu a mesma tradição do MySQL. Como os desenvolvedores do
MySQL e do MariaDB são os mesmos e o nome MySQL vem da primeira filha de Monty
Widenius chamada My, o nome MariaDB é o nome de sua filha mais nova, Maria. Mas esse
nome mudou para Aria e uniu as tecnologias MySQL e MariaDB, como é hoje. Abaixo temos
a página do MariaDB:

Figura 4 - Página do MariaDB

 15

Fonte: https://mariadb.org/

2.4. Aplicação das disciplinas estudadas no Projeto Integrador

As observações dentro do ambiente escolar permitiram a percepção de um problema

que poderia ser usado como objeto cientifica de estudo, dentro da proposta da disciplina de
Projetos e Métodos para a Produção do Conhecimento, a elaboração da metodologia
somada a pratica de observação, indução, dedução e experimentação tornaram a solução do
problema uma possibilidade de criação de um produto viável. A elaboração de todo projeto foi
realizada dentro da proposta de revisão literária, levantamento de dados e analises bem como a
documentação direta das tecnologias utilizadas.
Baseado no conteúdo de Ética e Cidadania, os princípios da ética foram aplicados
constantemente dentro de todo o contexto de pesquisa em campo, respeitando todas as diretrizes
de pesquisa e confidencialidade dos voluntários que responderam aos questionários.
Após a identificação do problema e a proposta de uma solução, conforme o que foi
estudado na disciplina Pensamento Computacional, buscou-se sempre se atentar aos quatro
pilares: a decomposição ao analisar os motivos das dificuldades no uso organizado dos
equipamentos na escola, o reconhecimento de padrões por entender que essa situação também
estava diretamente ligada ao uso de outros materiais coletivos, além de ser uma necessidade
que se repete em diversos outros contextos, sendo assim passível de ser extrapolada para
qualquer lugar que possa vir a necessitar de soluções similares de agendamento. Além disso,
temos também a abstração por focar em situações que envolviam organização de processos e
por último o pilar algoritmo, trabalhando a ideia de estruturação lógica das etapas do processo,
além de utilizar o conhecimento obtido no uso de linguagem de programação para a
 16

estruturação lógica de um software, isto é, construir um raciocínio organizado ao longo de todo

o desenvolvimento, seja buscando evitar redundâncias ou mesmo utilizando estruturas
condicionais de maneira apropriada.
Tivemos também a aplicação dos conceitos aprendidos em Introdução de Conceitos
de Computação, Fundamentos Matemáticos para Computação e Fundamentos de Web
para criação e modelagem orientada a objetos com instancias de classes, ideia de herança e
polimorfismo. Também foi muito útil a disciplina Algoritmos de Computação para aplicação
dos conhecimentos na linguagem Python, além das semânticas de HTML, como o uso de tags,
imagens, cores e tabelas estilizadas via CSS.
A disciplina Leitura e Produção de Texto, também foi bem utilizada principalmente
na formatação e escrita dos relatórios do projeto integrador. Já Inglês foi muito importante
para leitura e compreensão dos diversos sites consultados com a documentação oficial e
manuais das tecnologias utilizadas na aplicação, como a própria linguagem Python, o
framework Flask ou mesmo o sistema de banco de dados Mariadb.

2.5. Metodologia

2.5.1. Ouvir e Interpretar o Contexto

Dissemos anteriormente que o contexto onde o projeto foi realizado, se deu na Emeief
José Emídio de Aguiar e Emef Ézio Berzagui, duas escolas públicas da rede de ensino da cidade
de Barueri. A necessidade de se ter um controle maior sobre a disponibilização de equipamentos
de informática, áudio e vídeo nestas escolas nos levou à ideia da criação de um aplicativo que
proporcionasse segurança, praticidade e controle no agendamento desses dispositivos que antes
era feito à mão, causando diversos transtornos. Foi realizada uma pesquisa com professores
destas escolas sobre as expectativas e aceitação de se fazer um aplicativo que atendesse a essa
demanda. Utilizamos o formulário Google Forms com perguntas simples e rápidas sobre a
viabilidade desse projeto como se encontra na figura abaixo:
 17

Figura 5 - Formulário de pesquisa

 18

Fonte: https://forms.gle/mXy71SNqXSWZXmQcA

De acordo com as respostas inseridas na pesquisa com professores das duas escolas,
pudemos traçar o perfil dos sujeitos participantes e elaboramos gráficos representativos por
 19

pergunta, que embasaram a necessidade de implementação deste projeto. Abaixo as figuras dos
gráficos relacionados a cada pergunta do questionário.

a) Com relação ao cargo de professor na escola:

Figura 6 – Respostas dos professores (cargo)

Fonte: Disponível nas respostas do formulário https://forms.gle/mXy71SNqXSWZXmQcA

b) Com relação à escola em que leciona:

Figura 7- Respostas dos professores (escola em que leciona)

 20

Fonte: Disponível nas respostas do formulário https://forms.gle/mXy71SNqXSWZXmQcA

c) Com relação à utilização dos recursos tecnológicos:

Figura 8 – Respostas dos professores (utilização dos recursos tecnológicos)

Fonte: Disponível nas respostas do formulário https://forms.gle/mXy71SNqXSWZXmQcA

d) Com relação ao nível de importância para o uso de um aplicativo de gestão dos

recursos:
Figura 9 – Respostas dos professores (nível de importância no uso de um aplicativo)
 21

Fonte: Disponível nas respostas do formulário https://forms.gle/mXy71SNqXSWZXmQcA

Com relação às sugestões dadas pelos professores dentre muitas, relacionamos algumas
abaixo que são interessantes e levamos em consideração na implementação do projeto:
• Acho excelente e pode facilitar muito nosso dia a dia;
• Atualização constante das informações, possibilidade de reagendar, alterar data,
cancelar o agendamento e liberar para que outra pessoa possa utilizar sua desistência;
• Trazer praticidade ao trabalho pedagógico;
• Que haja um aviso quando esgotar algum recurso disponível;
• Seria importante que o aplicativo mandasse um alerta sobre o uso (dia / horário);
• Aplicativos que atendam o currículo conforme a BNCC seriam de extrema importância
na educação;
• Um Aplicativo para gestão da lousa digital e do emprego de jogos digitais em sala de
aula;
• Mais ferramentas para os alunos, mas com restrições a algumas páginas;
• Ainda preciso aprender essas ferramentas melhor;
• Seria maravilhoso, ganharíamos tempo e organização;
• Que seja intuitivo.

2.4.2 Criação e Prototipagem

 22

A partir dos problemas e necessidades apresentados pelos professores nas respostas aos
formulários, pudemos avaliar bem os requisitos para então traçar o melhor caminho de
desenvolvimento que atendesse a todas as demandas apresentadas.
Inicialmente nos preocupamos em começar a fazer a parte de front-end, que é a parte do
projeto que vai ter interação com o usuário final através das diversas telas do aplicativo. É por
essas telas que será possível ao usuário navegar entre as opções de datas e dispositivos
disponíveis para agendamento.
O método de desenvolvimento utilizado inicialmente foi a criação de uma página web
com HTML5 e CSS que são a Linguagem de marcação de hipertexto para criar a estrutura da
página e Folhas de estilo em cascata para adicionar estilos à página, respectivamente.
Buscamos seguir as orientações da W3C (https://www.w3c.br/), instituição que
desenvolve especificações técnicas e orientações com o objetivo de garantir um
desenvolvimento alinhado com os requisitos de implementação exigidos de sites modernos e
eficientes. Seguir essas orientações envolve muitas boas práticas que se manifestam em diversas
etapas do desenvolvimento, por exemplo na organização de pastas, agrupando arquivos de estilo
CSS em uma pasta ‘styles’ e arquivos de manipulação de elementos na pasta ‘scripts’.
Um outro exemplo é uma preocupação com a ideia de “Mobile First”, ou seja, um
desenvolvimento que se inicia partindo do pressuposto de que a maior parte do público-alvo irá
acessar a aplicação web a partir do dispositivo smartfone, desse modo as visualizações devem
ser construídas adaptadas a esse formato de tela para dispositivos móveis. Entretanto, a
aplicação deve também estar otimizada para o acesso em outros tamanhos de telas, como a do
próprio computador, assim foi essencial adotarmos durante a construção da aplicação a ideia de
responsividade, ou seja, a aplicação de diferentes tipos de exibição dependendo do tipo de tela
do usuário.
Um desafio que surgiu durante o desenvolvimento foi em relação a forma de
apresentação do calendário, pois em se tratando de uma aplicação de agendamento de datas, o
calendário acaba se tornando o coração do projeto. Dentre as inúmeras possibilidades
disponíveis, optamos por uma chamada ‘Flatpickr’ (https://flatpickr.js.org/) trata-se de um
selecionador de datas leve e poderoso escrito em javascript e sem qualquer outra dependência.
A grande vantagem deste selecionador de datas em relação aos outros está em sua estrutura
altamente customizável, desde sua aparência para o usuário, até ao formato da data que será
enviada para o banco de dados e até mesmo a possibilidade de criar condições para tornar datas
específicas inacessíveis, algo que será extremamente necessário quando precisarmos indicar
que todos os equipamentos em uma data específica já estão reservados.
 23

Tudo isso nos permitiu criar um esboço daquilo que será o nosso projeto para atender a
demanda necessária para gerenciamento dos recursos tecnológicos das escolas envolvidas na
pesquisa, que foi realizada junto à comunidade escolar.
Para garantir a colaboração e o trabalho em equipe o esboço está armazenado na
plataforma GitHub. Nesse primeiro momento, optamos pela separação entre front-end (tudo
aquilo que envolve a interação do usuário cliente com a aplicação, sua interface gráfica e
comportamentos resultantes dessa interação) e back-end (lado do servidor, os bastidores do
projeto, responsável por receber as requisições dos usuários, verificar as disponibilidades no
banco de dados e entregar as respostas adequadas). Em relação à parte de visualizações o projeto
está hospedado na página do perfil de nosso colega de grupo, Marcelo Martins Ribeiro dos
Santos, no qual todos somos colaboradores e o endereço para acessar o projeto é
https://github.com/marcelo5g/projeto-integrador.

Por outro lado, a parte de back-end e integração com banco de dados está sendo
desenvolvida pelo colega José William Rodrigues Pereira e pode ser acessado no endereço
https://github.com/JoseWRPereira/pi1-GestaoInteligenteRecursos.
As próximas etapas serão as mais desafiadoras, pois é o momento em que buscaremos
realizar a integração entre as ações dos usuários e o que acontece no banco de dados por meio
da combinação da declaração de condições específicas e consultas ao banco de dados para então
renderizar na página as datas e equipamentos disponíveis ou não. Com isso buscaremos atender
ao máximo as demandas apresentadas pela comunidade escolar nas respostas dos formulários,
como ‘Atualização constante das informações’, ‘Que haja um aviso quando esgotar algum
recurso disponível’ ou ‘Que seja intuitivo’.

2.4.3 Implementação e Testes

Para testar nossa aplicação tiramos proveito de uma condição bastante vantajosa que é
a proximidade do grupo com nosso público-alvo, pois temos professores no grupo que estão
 24

diariamente em contato com a comunidade escolar de Barueri nas unidades Emeief José Emídio
de Aguiar e Emef Ézio Berzagui. Desse modo, estamos constantemente retornando às demandas
apresentadas nas respostas dos formulários e verificando se nossa aplicação está atendendo a
todos os problemas que foram apresentados. O contato direto com a comunidade nos permite
constantemente apresentar aos professores das escolas pequenos trechos e protótipos da
aplicação isolados e assim coletar as devolutivas necessárias como sugestões sobre detalhes
mais específicos.
Algumas dessas devolutivas nos obrigaram a alterar nossa estratégia, como por
exemplo, o fato de a aplicação inicial não possuir sistema de login e senha, permitindo que
qualquer usuário anônimo pudesse agendar equipamentos, da mesma forma, não existia um
acesso de administrador com privilégios de acesso que pudesse fazer a gestão adequada em
casos de erros ou necessidade de ajustes. Outras melhorias indicadas foram em relação à
possibilidade de excluir um agendamento, funcionalidade que não estava disponível na primeira
versão do protótipo e também que fosse apresentado a quantidade de chromebooks presentes
em cada carrinho, algo que pode auxiliar bastante a rotina e a organização.

3. RESULTADOS

Ouvir
 25

Conforme indicamos na metodologia, buscamos seguir os princípios do design thinking

para o desenvolvimento de projetos e inovações. Para isso, foi essencial ouvir a comunidade
para a qual estávamos desenvolvendo a aplicação, seja através de meios mais formais como
formulários, seja através de conversas informais no dia a dia e nas rotinas escolares, permitindo
identificar detalhes e demandas e problemas que talvez passassem despercebidos a um grupo
de pesquisa sem esse contato.

Criar
A criação da solução, por sua vez, apresentou um desafio enorme com um nível de
complexidade que nos obrigou a recorrer a inúmeros materiais, desde as diversas consultas às
documentações oficiais das linguagens utilizadas (principalmente em relação à linguagem
Python e as formas de integração com o banco de dados Mariadb) até aos materiais usados nas
disciplinas da Univesp, com toda a fundamentação teórica necessária para um bom projeto,
conforme descrito no item ‘Aplicação das disciplinas estudadas no Projeto Integrador’ no
capítulo 2.
Buscamos ao máximo aproveitar a bagagem intelectual de cada membro do grupo,
atribuindo tarefas específicas a quem tivesse maior familiaridade e facilidade com determinado
campo ou ferramenta, com o objetivo de otimizar o tempo e alcançar o melhor resultado
possível. Porém, mantivemos também uma comunicação constante, para que cada um pudesse
explicar o que estava fazendo e assim contribuir com o processo de aprendizado de todos.
No entanto, a falta de experiência somada a alta complexidade da tarefa e a insuficiência
de alguns materiais de consulta (principalmente em relação ao uso do sistema de
versionamento) nos trouxeram alguns problemas e prejuízos na evolução do projeto, conforme
descreveremos logo a frente.
Nesse cenário, a parte da implementação com base nos feedbacks recebidos, nos
levaram a uma série de alterações de nosso protótipo, com sua completa reformulação em
determinados momentos. Isso nos mostrou a importância e relevância do método adotado, uma
vez que a aplicação deveria solucionar problemas reais enfrentados por sujeitos e para alcançar
essas melhorias é necessário um trabalho constante de escuta, com atenção, às reais demandas
que a proposta visa solucionar.

3.1. Solução inicial

 26

A necessidade de agendamento para o uso de recursos tecnológicos nas escolas surge

principalmente quando estamos falando dos carrinhos. Trata-se de um armário móvel
comportando 40 notebooks (mais especificamente chromebooks por utilizarem o sistema
operacional ChromeOS) que são transportados diariamente para salas de aula para serem usados
pelos alunos em atividades propostas pelos professores.

Figura 10 – Carrinho de Chromebooks

Fonte: Elaborado pelos autores.

O processo de construção da primeira solução desenvolvida pelo grupo iniciou-se pela

separação entre front-end e back-end (o que posteriormente constataríamos ter se tratado de
uma terrível decisão), dessa forma um integrante ficou responsável pelo front-end, ou seja, a
criação das telas e toda a parte de interface com a qual o usuário interage e realiza as reservas
de equipamentos. E outro integrante ficou responsável pelo back-end, a infraestrutura do lado
do lado do servidor que recebe as requisições do usuário (por exemplo, a requisição de reservar
um equipamento na quarta-feira), realiza uma consulta no banco de dados e verifica a
disponibilidade daquela requisição e devolve uma resposta para o usuário (podendo ser o aviso
que a reserva foi feita com sucesso, ou que o horário já está ocupado e que deve optar por outro).
Para mais detalhes e visualizar o código completo basta acessar o repositório público
por meio do link a seguir (https://github.com/marcelo5g/projeto-integrador). E o protótipo em
funcionamento (ainda sem a integração com o banco de dados) pode ser acessado neste
endereço (https://marcelo5g.github.io/projeto-integrador/)
 27

No capítulo 2, no item ‘Criação e Prototipagem’ falamos em detalhe sobre essa parte do

front-end, no uso de HTML e CSS. Trata-se de uma área que exige o uso de habilidades técnicas
e artísticas, quase adentrando o ramo do design, para estruturar boas visualizações, também
conhecido como UI/UX (Interface e Experiência do Usuário). Nesse sentido, trabalhamos na
composição de elementos, alinhamento e harmonia entre as cores, de modo que seja limpo e
garanta ao usuário uma experiência agradável e prazerosa. Além de garantir também a
responsividade, isto é, a adaptação automática a diferentes tamanhos de tela, conforme vemos
a seguir:

Figura 11 – Página “Home” da Solução Inicial

Fonte: Elaborado pelos autores.

 28

Figura 12 – Página “Home” da Solução Inicial (para celular)

Fonte: Elaborado pelos autores.

 29

Para o agendamento em si utilizamos um formulário simples em que o usuário digita

seu nome, seleciona a escola em que trabalha e o período.

Figura 13 – Formulário de agendamento – Nome, Escola e Período

Fonte: Elaborado pelos autores.

Em seguida, o usuário seleciona a disciplina que leciona e escolhe um dia no calendário.

Utilizamos a biblioteca ‘Flatpickr’ pois com ela é possível selecionar datas, além de deixar
alguma condições pré-configuradas.
 30

Figura 14 – Formulário de Agendamento – Disciplina e Horários

Fonte: Elaborado pelos autores.

Figura 15 – Formulário de Agendamento - Carrinhos

Fonte: Elaborado pelos autores.

 31

Por fim, o usuário seleciona o carrinho desejado e salva o cadastro. Ao fazer isso o
formulário é submetido e enviado ao back-end para ser apropriadamente tratado e inserido no
banco de dados.
Figura 16 – Cadastro realizado com sucesso

Fonte: Elaborado pelos autores.

Essa foi nossa solução inicial, apostando na simplicidade e praticidade, entretanto, ao

apresentá-la para alguns professores surgiram várias ressalvas e críticas como por exemplo a
ausência de um sistema de autenticação, uma tela para o usuário realizar login por meio de uma
senha (uma vez que no protótipo anterior bastava digitar o nome do professor que iria reservar
o equipamento), ou mesmo uma forma de acesso de administrador com privilégios de acesso
para ajustes pontuais, cadastro de usuários, senhas e disciplinas, etc. Tudo isso acabou
evidenciando as limitações deste primeiro protótipo e a necessidade de um sistema bem mais
robusto capaz de atender a demandas que não havíamos previsto.
 32

3.2. Solução Final

Para mais detalhes e visualizar o código completo basta acessar o repositório público
por meio do link a seguir (https://github.com/JoseWRPereira/appAgendei_pi1). E o protótipo
em funcionamento pode ser acessado neste endereço (https://agendei-pi1.herokuapp.com/)
A partir dos feedbacks coletados nas escolas em que o projeto foi desenvolvido, muitas
mudanças e melhorias tiveram que ser realizadas na aplicação. Em primeiro lugar, o
desenvolvimento em paralelo (front-end de um lado e back-end do outro) acabou se mostrando
bastante ineficiente e as dificuldades no uso do Github (que tem como principal propósito evitar
esse tipo de problema) acabou gerando atrasos e estruturas que não se comunicavam e não se
integravam muito bem. Uma das grandes lições aprendidas nesse momento foi a de que o uso
adequado desse sistema de versionamento, com uma comunicação mais eficiente poderia ter
evitado problemas e permitido um desenvolvimento mais colaborativo, em menos tempo.
Em segundo lugar, de acordo com os feedbacks coletados, percebemos a necessidade
de reformular alguns elementos do projeto, desta vez trabalhando front-end e back-end
simultaneamente, seguindo as etapas de desenvolvimento aprendidas com os materiais das
aulas: criar uma função na camada ‘view’, em seguida página na camada ‘template’ e por fim
atualizar a lista de postagens.
Num primeiro momento, ao acessar a página inicial, o usuário se depara com a página
de boas vindas da nossa plataforma “Agendei – Gestão Inteligente de Equipamentos” na qual
o projeto reformulado apresenta algumas melhorias. Por exemplo, no canto superior direito foi
incluída a principal exigência dos professores, o campo ‘Conecte-se’ permite a realização de
login tanto dos usuários quanto do administrador do sistema (que no caso, entendemos se tratar
do professor de informática de cada escola).
 33

Figura 17 – Página “Home” da Solução Final

Fonte: Elaborado pelos autores.

No cabeçalho da página temos os botões “Reservas” e “Conecte-se”. Ao clicar no

primeiro é possível acessar a página pública com a agenda diária conforma apresentado abaixo:
Figura 18 – Calendário diário das reservas efetuadas

Fonte: Elaborado pelos autores.

Nesta página é possível navegar pelos dias clicando nas setas, direita para avançar e
esquerda para retroceder. E em cada dia são apresentados os carrinhos que já se encontram
reservados, com a especificação do número do carrinho, o período (manhã, tarde ou noite) e o
 34

nome do professor que efetuou a reserva. Note que esta página é apenas para consulta e não
pode ser alterada, pois para realizar uma nova reserva ou qualquer outra operação, é necessário
logar na plataforma por meio do outro botão no canto superior direito: “Conecte-se”.
Figura 19 – Tela de login

Fonte: Elaborado pelos autores.

Aqui temos uma página padrão de login com nome de usuário e senha. Novos usuários
podem ser cadastrados pelo administrador do sistema, processo que será apresentando logo
mais. Após se conectar, outras opções surgem para o usuário:
 35

Figura 20 – Página “Home” – Área do Usuário

Fonte: Elaborado pelos autores.

Além do botão “Reservas” que permanece inalterado, agora temos também os botões
“Agendar”, “Excluir” e “Sair” que, de modo muito intuitivo, oferecem respectivamente as
opções de realizar um novo agendamento, excluir um agendamento feito previamente e sair da
área do usuário. Vejamos a seguir cada uma delas.
Ao clicar em “Agendar” somos levados à tela abaixo, com a agenda dos agendamentos
já efetuados (bem como as setas de navegabilidade diária) e os nomes das pessoas que
reservaram algum dos 4 carrinhos disponíveis e em qual período foi realizada a reserva. Para
efetuar uma nova reserva basta clicar no botão “Reservar” e o campo será substituído pelo nome
da pessoa atualmente logada na plataforma (em nosso exemplo, o integrante do grupo Marcelo
efetua uma reserva para o dia 27/11/2021 no carrinho 4 no período Noite).

Figura 21 – Página “Agendar” (Antes da Reserva)

Fonte: Elaborado pelos autores.

Figura 22 – Página “Agendar” (Depois da Reserva)

 36

Fonte: Elaborado pelos autores.

De modo inverso, o botão “Excluir” permite remover uma reserva em caso de

desistência ou alteração de cronograma. A grande diferença nesse caso é que o usuário só terá
acesso às reservas efetuadas por ele próprio, não sendo possível acessar horários reservados por
terceiros. Trata-se de um detalhe sutil mas extremamente elegante. Basta clicar no botão
“Excluir” e aquele carrinho, naquele dia e período volta a ficar disponível para que outros
usuários possam reservá-lo.

Figura 23 – Página “Excluir”

Fonte: Elaborado pelos autores.

Por fim, o botão “Sair” permite sair da área de usuário e retornar para a área pública em
que está disponível apenas o botão “Reservas” para consultar o calendário e as disponibilidades.
No canto superior esquerdo está sempre visível e acessível em todas as páginas o botão verde
com o nome de nosso aplicativo web “Agendei” que é um link para a página inicial.
Trataremos agora dos privilégios de administrador. Cada escola que utilizar a
plataforma deverá deixar alguém responsável por fazer a gestão do sistema (provavelmente o
 37

professor de informática de cada unidade). Desse modo, o administrador terá acesso a recursos
adicionais que iremos descrever a seguir.

Figura 24 – Página “Home” – Área do Administrador

Fonte: Elaborado pelos autores.

Clicando em “Conectar-se” e efetuando o login como “Admin” novos recursos ficam

acessíveis no menu superior conforme a imagem acima. Além dos links para as páginas já
descritas, temos também agora os botões “Usuários”, “Carrinhos” e “Agendamentos”.
Nesse cenário, o administrador será o responsável por cadastrar ou excluir usuários. A
título de exemplo usamos os nomes dos integrantes do nosso grupo.
 38

Figura 25 – Cadastro e Exclusão de usuários

Fonte: Elaborado pelos autores.

Conforme imagem acima, buscamos simplificar ao máximo a quantidade de

informações necessárias, sendo suficientes o número de identificação funcional de cada
funcionário, seu nome de usuário e a senha. Neste momento optamos por essa solução mais
simples e manual porém, na continuidade de desenvolvimento de um sistema mais robusto,
seria apropriado pensar em soluções de criptografia ou mesmo redefinição de senha pelo
próprio usuário. Existe também a opção de excluir um usuário.
Em relação aos carrinhos a lógica é a mesma, sendo ainda mais simples pois basta
identificar o número de cada um.

Figura 26 – Cadastro e Exclusão de carrinhos

 39

Fonte: Elaborado pelos autores.

A identificação dos carrinhos pode variar de escola para escola, seja por meio de um
número, uma letra ou mesmo uma cor, desse modo, fica a critério do administrador cadastrar
os nomes da forma julgar mais adequada.

Figura 27 – Cadastro e Exclusão de agendamentos

Fonte: Elaborado pelos autores.

Por fim, a página “Agendamentos”. Esta talvez seja a página em que os poderes do
administrador surgem com maior intensidade e evidência. Basicamente, aqui o administrador
pode manipular toda a agenda, seja efetuando uma reserva em nome de outro usuário (acontece
 40

com frequência professores solicitarem verbalmente ao professor de informática para que uma
reserva seja feita), seja para fazer ajustes e modificações pontuais ou mesmo excluir algo feito
de forma equivocada ou alguma desistência.

Considerações finais

Portanto, após um longo percurso, acreditamos ter alcançado nossos objetivos iniciais,
que de modo geral giravam em torno de desenvolver um software com framework web
utilizando banco de dados, e isso foi executado usando o framework Flask e o banco de dados
MariaDB, o que sem dúvida permite gerenciar a utilização e agendamentos de equipamentos
nas escolas. Trata-se de um pequeno passo no sentido de buscar facilitar o agendamento de
equipamentos para a realização de aulas práticas de professores. Tudo isso, aliado ao fato de
que essa dinâmica permite fornecer um controle maior na retirada e entrega desses
equipamentos.
Um outro objetivo específico se relacionava com a ideia de facilitar o gerenciamento
dos equipamentos quanto a necessidade de manutenção. Este foi um ponto que não
conseguimos abordar mas que fica como funcionalidade em aberto, passível de ser
implementada no futuro e capaz de agregar bastante valor ao escopo geral do projeto.
Além disso, praticar o controle de versão através do site Github foi um aprendizado
valioso para todos, permitindo explorar as possibilidades de desenvolvimento em paralelo de
diferentes partes do projeto.
Podemos apontar como uma grande contribuição do trabalho, não apenas todo o
aprendizado envolvido em sua construção como também apresentar à comunidade as
possibilidades e as vantagens de uma aplicação dessas, capaz de tornar o dia a dia mais dinâmico
e simples, e o grande impacto da solução criada seria dar mais autonomia para o professor e
eliminar a necessidade do uso de papel e planilhas para realizar agendamentos manuais.
Uma grande limitação do trabalho, conforme apontamos, refere-se à questão de
segurança e geração de senha que permanece de forma manual, porém não apresenta um
 41

problema tão grande assim pois o escopo do projeto não prevê o uso de informações sensíveis
dos usuários. A estilização da interface também pode ser otimizada para que fique ainda mais
intuitiva, simples e elegante para o usuário.
Entre a solução inicial e a final acreditamos haver um salto gigantesco. A partir do
feedback da comunidade escolar percebemos a necessidade de ajustes de rota significativos,
pois a implementação login e senha era algo que não foi previsto num primeiro momento e se
tornou crucial para os passos seguintes. Nesse cenário, vimos algo que parecia simples crescer
e se tornar cada vez mais robusto e complexo, tornando-se verdadeiro desafio e exigindo do
grupo bastante dedicação e empenho para que a ideia se materializasse num produto acabado
capaz de cumprir seu propósito.
De forma geral, podemos dizer que houve uma evolução significativa em todos os
integrantes do grupo ao longo do desenvolvimento desse projeto integrador, seja pesquisando
a documentação das tecnologias utilizadas, testando e verificando os resultados, seja revisitando
materiais de disciplinas passadas para compreender melhor alguns conceitos, o que nos permitiu
uma apropriação bastante clara da proposta do Projeto Integrador em seu sentido mais amplo,
isto é, a integração envolvendo várias áreas de estudo e habilidades técnicas e comportamentais.
A satisfação em entregar a aplicação é imensa, porém sabemos que ela permanece aberta
e incompleta e ainda pode melhorar bastante. Temos em mãos um protótipo que cresceu
bastante em algumas quinzenas e que tem bastante potencial para crescer ainda mais. Quem
sabe até ser implementado de fato ou mesmo se tornar um produto comercialmente viável?
 42

REFERÊNCIAS

AQUILE, A.; FERREIRA, R. Controlando versões com Git e GitHub. São Paulo: Casa do código,
2014.
MACIEL, F. B. M. Python e Django-Desenvolvimento web moderno e ágil. Rio de Janeiro:
Altabooks, 2020.
IEEE - Instituteof Eletricaland Eletronics Engineers. Standards Glossary of Software
Engineering Terminology: Std 610.12, N.Y.,1990. 84p.

SOUZA, I. MariaDB ou MySQL: saiba qual tecnologia de banco de dados escolher.

Disponível em https://rockcontent.com/br/blog/mariadb/ . Acesso em 04/10/2021
SPÍNOLA, R. O. Introdução à Engenharia de Requisitos. Disponível em
https://www.devmedia.com.br/introducao-a-engenharia-de-requisitos/8034#2. Acesso em
21/09/2021

STICKDORN,M.; SCHNEIDER, J. Isto é design thinking de serviços. Porto Alegre:

Bookman, 2014.

MORAES, Janaína Bedani Dixon. Engenharia de Software 2 – Técnicas para levantamento

de Requisitos. Disponível em: http://www.devmedia.com.br/engenharia-de-software-2-
tecnicas-para-levantamento-de-requisitos/9151Acesso em: 21/09/2021
WILLIAN, J. Flask: O que é e como codar com esse micro framework Python. Disponível
em: http://blog.geekhunter.com.br/flask-framework-python/#o-que-e-o-flask Acesso em
29/09/2021
43