TCC COMPLETO-REPO -CONVERTIDO

Prévia do material em texto

UNIVERSIDADE FEDERAL DE SANTA CATARINA 
 
 
 
 
 
 
 
 
HENRIQUE DE QUEVEDO FRANCO 
 
 
 
 
 
 
 
 
PROPOSTA DE DESENVOLVIMENTO DE SOFTWARE PARA GESTÃO DA 
BATERIA UNIVERSITÁRIA DA UFSC - BATERAAACA 
 
 
 
 
 
 
 
 
 
 
 
Araranguá, maio de 2021 
 
 
 
 
HENRIQUE DE QUEVEDO FRANCO 
 
 
 
 
 
 
PROPOSTA DE DESENVOLVIMENTO DE SOFTWARE PARA GESTÃO DA 
BATERIA UNIVERSITÁRIA DA UFSC - BATERAAACA 
 
 
 
 
 
 
 
Trabalho de Conclusão de curso 
submetido à Universidade Federal de 
Santa Catarina como parte dos 
requisitos necessários para obtenção do 
grau de Bacharel em Tecnologias da 
Informação e Comunicação. Sob a 
orientação do professor Dr. Vinicius 
Faria Culmant Ramos e coorientação da 
professora Ma. Tatiana Nilson dos 
Santos 
 
 
 
 
 
Araranguá, maio de 2021 
Ficha de identificação da obra elaborada pelo autor,
 através do Programa de Geração Automática da Biblioteca Universitária da UFSC.
Franco, Henrique de Quevedo
 PROPOSTA DE DESENVOLVIMENTO DE SOFTWARE PARA GESTÃO DA
BATERIA UNIVERSITÁRIA DA UFSC - BATERAAACA / Henrique de
Quevedo Franco ; orientador, Vinicius Faria Culmant Ramos
, coorientador, Tatiana Nilson dos Santos, 2021.
 67 p.
 Trabalho de Conclusão de Curso (graduação) -
Universidade Federal de Santa Catarina, Campus Araranguá,
Graduação em Tecnologias da Informação e Comunicação,
Araranguá, 2021.
 Inclui referências. 
 1. Tecnologias da Informação e Comunicação. 2.
Desenvolvimento De Software Para Gestão Da Bateria
Universitária. I. Ramos , Vinicius Faria Culmant . II.
Santos, Tatiana Nilson dos . III. Universidade Federal de
Santa Catarina. Graduação em Tecnologias da Informação e
Comunicação. IV. Título.
 
 
 
 
PROPOSTA DE DESENVOLVIMENTO DE SOFTWARE PARA GESTÃO DA 
BATERIA UNIVERSITÁRIA DA UFSC – BATERAAACA
Este Trabalho Conclusão de Curso foi julgado adequado para obtenção do Título de “Bacharel 
em Tecnologias da Informação e Comunicação” e aprovado em sua forma final pelo Curso de 
Graduação em Tecnologias da Informação e Comunicação
Araranguá, 13 de maio de 2021.
________________________
Prof. Vilson Gruber, Dr.
Coordenador do Curso
Banca Examinadora:
________________________
Prof.ª Vinicius Faria Culmant Ramos, Dr.
Orientador
Universidade Federal de Santa Catarina
________________________
Prof.ª Tatiana Nilson dos Santos, Ma.
Coorientadora
Universidade Federal de Santa Catarina
________________________
Prof. Adriano de Oliveira, Me.
Universidade Federal de Santa Catarina
________________________
Prof. Jim Lau, Dr.
Universidade Federal de Santa Catarina
 
 
 
 
Araranguá, maio de 2021 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“Dedico esse trabalho a todos meus amigos, colegas, família e em especial aos 
professores que dedicaram seu tempo para me auxiliar”. 
 
Henrique de Quevedo Franco 
 
 
 
 
AGRADECIMENTOS 
“Agradeço a todos que me ajudaram na elaboração deste trabalho, em especial 
aos meus pais, Henrique de Oliveira Franco e Rosemeri de Quevedo Franco e 
minha irmã Karina de Quevedo Franco, que me incentivaram e me apoiaram a 
não desistir e concluir este trabalho. Agradeço também a minha namorada 
Vanessa Pavanate por estar sempre presente, e a todos os meus amigos que 
me apoiaram, especialmente ao Gabriel Alves, Alex Moraes, Guilherme 
Menegat, Raphael Minervini, Arthur Oliveira, Natalia Maldaner, Nathalia 
Paschoali, Yasmin Coelho e Lucas Leonardo Dias por deixarem a graduação 
muito mais legal e estarem sempre disponíveis para me auxiliar. Ao professor 
orientador Vinicius Faria Culmant Ramos, que orientou esse trabalho. À 
professora Tatiana Nilson dos Santos que ajudou muito como coorientadora e 
com as “puxadas de orelhas”, e também a todos os membros e amigos da 
BaterAAACA que sem esse grupo, ou melhor essa família, este trabalho não 
existiria.” 
Henrique de Quevedo Franco 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“…você precisa desaprender o que aprendeu” 
(Mestre Yoda, Star Wars) 
 
 
 
 
RESUMO 
Este trabalho tem como objetivo analisar e desenvolver um software que 
seja capaz de gerenciar o fluxo de uma Bateria Universitária, no qual há a 
necessidade de ter informações seguras e centralizadas, além do acesso por 
todos os membros ser imprescindível. Este trabalho traz uma proposta de 
software para a gestão da bateria universitária da UFSC – BaterAAACA. Para 
atingir esse objetivo, o trabalho foi divido entre as etapas de: levantamento da 
bibliografia e trabalhos relacionados. Foi utilizado a metodologia de 
desenvolvimento de software em cascata que consiste em análise, 
implementação, testes, implantação e manutenção, e por fim, foi decidido 
desenvolver para um ambiente web, utilizando Php como linguagem de 
programação, a arquitetura de projeto MVC (Model, View, Controller), banco de 
dados MySQL, além de linguagem de HTML, CSS e JavaScript. O sistema tem 
como função oferecer uma interface amigável para que o usuário possa ter 
acesso a avisos e compromissos com a bateria, que possa fazer pesquisas e 
inserir informações de maneira fácil, rápida, estável e confiável. Procurou, 
através dos procedimentos e das rotinas diárias, a melhor maneira para 
desenvolver uma solução específica para baterias universitárias, que pudesse 
auxiliar no dia a dia, bem como nas tomadas de decisões dentro da mesma. 
Como resultado, foi entregue uma ferramenta digital capaz de gerir por completo 
as atividades de gestão da BaterAAACA, atender as necessidades do dia a dia. 
Os trabalhos futuros são para implantação do sistema na BaterAAACA e testes 
com usuários finais, integração do sistema com um Blog e com um aplicativo 
para o controle de presença em ensaio, e por fim consumir uma API de 
notificações para melhorar a comunicação de novos eventos com os ritmistas. 
Palavras-chave: Bateria, Software, Gestão, Web, Php. 
 
 
 
 
 
ABSTRACT 
This work aims to analyze and develop software that is capable of 
managing the flow of a University Battery, in which there is a need to have secure 
and centralized information, in addition to access by all members being essential. 
This work presents a software proposal for the management of the university 
battery of UFSC - BaterAAACA. To achieve this objective, the work was divided 
into the following stages: survey of the bibliography and related works. The 
cascade software development methodology was used, which consists of 
analysis, implementation, testing, implementation and maintenance, and finally, 
it was decided to develop for the web environment, using Php as a programming 
language, the MVC project architecture (Model, View, Controller), MySQL 
database, as well as HTML, CSS and JavaScript language. The function of the 
system is to offer a friendly interface so that the user can have access to warnings 
and appointments with the battery, who can do research and enter information in 
an easy, fast, stable and reliable way. He sought, through daily procedures and 
routines, the best way to develop a specific solution for university batteries, which 
could assist in daily life, as well as in decision-making within it. As a result, a 
digital tool was able to fully manage the management activities of BaterAAACA, 
to meet the needs of everyday life. Future work is for the implementation of the 
system at BaterAAACA and tests with end users, integration of the system with 
a Blog and with an application for the control of presence in rehearsal, and finally 
consuming a notification API to improve the communication of new events with 
the rhythmists. 
 
Keywords: Battery, Software, Management, Web, Php. 
 
 
 
 
 
LISTA DE FIGURAS 
Figura 1: Quadro Kanban...................................................................................16 
Figura 2: Primeiros instrumentos da BaterAAACA.............................................18 
Figura 3: Uma das formações BaterAAACA, com os instrumentosnovos..........19 
Figura 4: Exemplo de uma função em PHP........................................................23 
Figura 5: Exemplo de uma função em JavaScript...............................................23 
Figura 6: Exemplo de script em SQL...................................................................24 
Figura 7: Interface do GitHub..............................................................................25 
Figura 8: Editor de código-fonte Visual Studio Code...........................................26 
Figura 9 – Estrutura básica do modelo cliente-servidor......................................29 
Figura 10: Esquema do banco para o módulo do presidente..............................29 
Figura 11: As camadas do Modelo MVC.............................................................31 
Figura 12: Tela de login......................................................................................32 
Figura 13: Tela de recuperação de senha...........................................................33 
Figura 14: Tela principal.....................................................................................34 
Figura 15: Comportamento do menu para usuário com status de diretor............35 
Figura 16: Comportamento do menu para usuário com status de ritmista..........35 
Figura 17: Tela de página não encontrada.........................................................36 
Figura 18: Tela de edição dos dados pessoais, aba geral..................................37 
Figura 19: Tela de edição dos dados pessoais, aba de recuperar senha..........37 
Figura 20: Tela de certificados............................................................................37 
Figura 21: Tela de listagem de usuário...............................................................38 
Figura 22: Tela de listagem de contatos.............................................................39 
Figura 23: Tela de propostas..............................................................................39 
Figura 24: Tela de listagem de certificados........................................................39 
Figura 25: Tela de configuração de ensaio.........................................................40 
Figura 26: Tela de registro de presença.............................................................40 
Figura 27: Tela de justificativas de faltas............................................................40 
Figura 28: Tela de inscrições para oficina..........................................................41 
Figura 29: Tela de formulários preenchidos para a oficina.................................41 
Figura 30: Tela de agenda de apresentações....................................................41 
Figura 31: Tela de controle de caixa...................................................................42 
Figura 32: Tela de produtos no inventário..........................................................42 
Figura 33: Tela de produtos solicitados..............................................................43 
Figura 34: Tela de produtos para venda.............................................................43 
Figura 35: Tela de registro de ensaios................................................................43 
Figura 36: Tela de materiais de estudos.............................................................44 
Figura 37: Tela para consulta de ensaios...........................................................44 
Figura 38: Tela para consulta de faltas por usuário............................................44 
Figura 39: Tela de consulta de dívida por usuário..............................................45 
Figura 40: Tela de consulta de materiais de estudos..........................................45 
Figura 41: Tela de solicitação de produtos.........................................................46 
Figura 42: Tela de regimento interno da BaterAAACA.......................................46 
Figura 43: Funcionamento de um processo de teste de software......................47 
 
 
 
 
LISTA DE TABELAS 
 
Tabela 1 – Divisão interna da BaterAAACA........................................................19 
Tabela 2 – Análise de requisitos, através de histórias de usuários....................27 
Tabela 3 – Resultados da fase de teste..............................................................47 
Tabela 4 – Resultado do teste de compatibilidade.............................................48 
Tabela 5 – Resultado do teste de segurança......................................................49 
 
 
 
 
 
LISTA DE ABREVIATURAS E SIGLAS 
 
AAACA – Associação Atlética Acadêmica Campus Araranguá 
AJAX - Asynchronous JavaScript and XML 
API – Application Program Interface 
BATERAAACA – Bateria universitária da Associação Atlética Acadêmica 
Campus Araranguá 
CSS – Cascading Style Shee 
HTML – Hypertext Markup Language 
JS – JavaScript 
MVC – Model View Controller 
PHP – Personal Home Page 
SI – Sistema da informação 
SQL – Structured Query Language 
UFSC – Universidade Federal de Santa Catarina 
 
 
 
 
 
SUMÁRIO 
 
1 INTRODUÇÃO ............................................................................................ 11 
1.1 Objetivos ............................................................................................. 12 
1.1.1 Objetivo Geral .................................................................................. 12 
1.1.2 Objetivos Específicos ....................................................................... 12 
1.2 Justificativa .......................................................................................... 12 
1.3 Metodologia ......................................................................................... 13 
1.4 Organização do trabalho ......................................................................... 14 
2 FUNDAMENTAÇÃO TEÓRICA .................................................................. 16 
2.1 A BaterAAACA .................................................................................... 16 
2.2 Importância de um sistema da informação em uma organização ....... 18 
3 IDENTIFICAÇÃO DAS FERRAMENTAS .................................................... 20 
3.1 HTML: Linguagem de marcação de Hipertexto ................................... 20 
3.2 PHP: Linguagem de programação principal ........................................ 20 
3.3 JavaScript: Linguagem de Scripiting ................................................... 21 
3.4 JQuery: Biblioteca JavaScript ............................................................. 21 
3.5 CSS: Folha de estilo em cascata ........................................................ 22 
3.6 Bootstrap: Framework CSS ................................................................. 22 
3.7 MySQL: Banco de dados .................................................................... 22 
3.8 Composer: Gerenciador de pacotes.................................................... 22 
3.9 GitHub: Sistema de gerenciamento de versões .................................. 23 
3.10 Apache: Servidor web ......................................................................... 23 
3.11 Visual Studio Code: Editor de código-fonte ......................................... 23 
4 DESENVOLVIMENTO DA APLICAÇÃO .................................................... 25 
4.1 Definição de Requisitos ....................................................................... 25 
4.1.1 Modelo Cliente-servidor ................................................................... 26 
4.2 Projeto de Sistemas de Software ........................................................ 27 
4.2.1 Modelagem do Banco de dados ...................................................... 27 
4.2.2 Padrão de projeto MVC.................................................................... 28 
4.3 Implementação .................................................................................... 29 
4.3.1 Tela de login ....................................................................................29 
4.3.2 Tela de recuperação de senha ........................................................ 30 
4.3.3 Tela principal .................................................................................... 31 
4.3.4 Tela de página não encontrada e de negação de acesso ............... 34 
4.3.5 Tela de edição dos dados pessoais ................................................. 34 
4.3.6 Módulo do presidente ...................................................................... 36 
 
 
 
 
4.3.7 Módulo de gestão de pessoas ......................................................... 38 
4.3.8 Módulo de marketing ....................................................................... 39 
4.3.9 Módulo do financeiro ........................................................................ 40 
4.3.10 Módulo do mestre ......................................................................... 41 
4.3.11 Módulo do ritmista ........................................................................ 42 
4.4 Teste de Software ............................................................................... 44 
4.4.1 Teste de compatibilidade ................................................................. 46 
4.4.2 Teste de segurança ......................................................................... 46 
5 CONSIDERAÇÕES FINAIS ........................................................................ 48 
5.1 Dificuldades encontradas no desenvolvimento do trabalho ................ 48 
5.2 Proposta para trabalhos futuros .......................................................... 49 
REFERÊNCIAS ................................................................................................ 50 
ANEXOS .......................................................................................................... 52 
Anexo I – Regimento interno da BaterAAACA .............................................. 52 
 
 
 
 
 
1 INTRODUÇÃO 
 
É comum hoje em dia percebermos que as tecnologias estão quase 
sempre presentes no nosso cotidiano, e cada vez mais tarefas, desde ler notícias 
até o pagamento de contas, podem ser realizadas utilizando apenas um 
dispositivo com conexão à Internet. Os softwares são ferramentas que estão 
sempre em constante evolução, buscando atender as mais diversas 
necessidades. Neste contexto, e com o mercado cada vez mais competitivo, faz-
se necessária a implantação do maior número possível de práticas para 
elevarem a produtividade e buscar uma maior otimização dos processos, para 
que as tarefas sejam realizadas de maneiras cada vez mais simples e 
informatizadas, ou seja, de modo que seja exigido o menor esforço possível por 
parte das pessoas. 
Na Universidade Federal de Santa Catarina Campus Araranguá, cada vez 
mais os alunos procuram projetos extraclasses durante a graduação, seja como 
hobbies ou para complementar o aprendizado. Na UFSC, contamos com vários 
projetos complementares, como laboratórios, monitorias, atlética, cheerleading e 
também a bateria universitária. Esta última nasceu com o intuito de acompanhar 
a atlética do campus (AAACA) durante os campeonatos como forma de torcida, 
mas com o tempo, o samba dos momentos de torcida passou por diversas 
transformações e por um forte aprimoramento técnico desde sua origem. Assim, 
nos últimos anos, pode ser escutado também em competições próprias de 
baterias e apresentações em contextos externos à universidade. 
Deste modo, a Bateria Universitária da Associação Atlética Acadêmica 
Campus Araranguá (BaterAAACA) é responsável pela seleção, montagem e 
manutenção dos membros, agendamento de ensaio e treino com músicos 
especialistas de cada modalidade, inscrição em campeonatos de baterias 
universitárias (BU’s) e ações sociais. E todas essas tarefas, hoje em dia é gerida 
de maneira manual ou por meio de planilhas eletrônicas, deixando os dados 
descentralizados e pouco confiáveis. 
O objetivo deste trabalho é o desenvolvimento de um sistema da 
informação para a gestão do projeto da bateria universitária. Em vista disso, 
busca-se um ganho significativo na manutenção e eficácia dos processos, do 
controle interno das rotinas, permitindo que as informações fiquem centralizadas 
e seguras, auxiliando para que o presidente e a diretoria tenham conhecimento 
de quem realmente está se dedicando, informações do caixa, do patrimônio, da 
agenda, entre outros. Este sistema visa trabalhar de forma autônoma para que 
a diretoria e os restantes dos ritmistas tenham mais tempo para se dedicar às 
melhorias técnicas e musicais da bateria, e também detenham mais tempo livre 
para se dedicarem a seus cursos de graduação e outras tarefas da universidade 
e cada vez menos tenham que se preocupar com o controle administrativo, 
sabendo que terão toda a informação estará segura e centralizada em um 
sistema desenvolvido para as suas necessidades. 
 
 
 
 
1.1 Objetivos 
 
Os objetivos do trabalho estão divididos em objetivo geral e específicos. 
 
1.1.1 Objetivo Geral 
 
Desenvolver e apresentar uma solução de software que tem como 
propósito eliminar o uso de interfaces manuais e padrões pessoais para 
gerenciar cada tipo de informação de uma bateria universitária, além de otimizar 
o fluxo e aumentar a qualidade e eficiência do mesmo dentro da bateria, 
eliminando redundância, melhorando o controle dos processos e otimizando as 
tomadas de decisões. 
 
1.1.2 Objetivos Específicos 
 
• Realizar a análise de requisitos, identificando as características 
essenciais para desenvolver um software que atende as 
necessidades do grupo; 
• Aplicar técnicas de programação web para construção de um 
sistema otimizado e fácil de usar; 
• Melhorar o processo de gerenciamento de dados da BaterAAACA; 
• Permitir que as informações fiquem centralizadas e seguras, e que 
todos os membros tenham seus determinados acessos. 
 
1.2 Justificativa 
 
Em uma organização que não possui um sistema informatizado com 
suporte de software, no caso de uma bateria universitária, todas as informações 
de ritmistas, fluxo de dinheiro e organização de materiais são gerenciadas por 
meio de planilhas eletrônicas, tornando a forma de gerenciamento precária, visto 
que não é centralizada e confiável. Como consequência, pode haver falta ou 
redundância de informações e ainda mais grave, a perda de dados. Todos estes 
problemas se agravam caso algum membro venha a sair e consigo leve toda a 
sua rotina e dados que lhe eram empregados sobre a diretoria em que era 
responsável. 
Dessa forma, o impacto causado por isso pode ser muito grande para a 
bateria, uma vez que raramente detém o controle exato da quantidade de 
dinheiro em caixa, da quantidade de instrumentos, de produtos para venda, de 
 
 
 
 
materiais disponíveis para cada ritmista, cadastro de ritmistas e suas 
informações como documentação, telefone, matricula, certificados, entre outros. 
 Nesse sentido, uma vez que o autor deste trabalho fez parte da 
BATERAAACA, uma organização que não possui apoio de software, notou-se a 
carência de um sistema para gerenciamento e centralização de dados e 
processos. Após várias conversas e reuniões com os membros da diretoria 
administrativa e musical da bateria para entender como eram realizados os 
processos internos, e quais as necessidades reais que gostariam que fossem 
atendidas, decidiu-se então, criar um sistema web, possibilitando assim o acesso 
dos usuários e membros da bateria de qualquer lugar, através de qualquer 
dispositivo, mediante acesso à internet. 
 
1.3 Metodologia 
 
Em engenharia de software, processos podem ser definidos para atividades 
como desenvolvimento, manutenção, aquisição e contratação de software. Podem-
se também definir subprocessos para cada um desses; por exemplo, um processo de 
desenvolvimento abrange subprocessos de determinação dos requisitos, análise, 
desenho, implementação e testes. Em um processo de desenvolvimento de software, 
o ponto de partida para a sua arquitetura é a escolha de um modelode ciclo de vida 
ou método de engenharia de software (FILHO, 2009). 
O sistema foi desenvolvido seguindo as etapas de: análise de requisitos, 
projeto do sistema, implementação e testes de software, e todas etapas serão 
documentadas. 
Na etapa de análise de requisitos, foram feitas reuniões e conversas com a 
diretoria da bateria, sobre a sua rotina de trabalho para saber o que o sistema precisa 
fazer, e como será utilizado. Pode ser entendido como a tradução da necessidade ou 
requisito operacional para uma descrição da funcionalidade a ser executada e servem 
como uma especificação do sistema. 
Foi feito o projeto do sistema para saber como este iria operar, em termos de 
prototipação da interface do usuário, software, linguagem de programação a ser 
utilizada, banco de dados e relatórios. 
Na implementação, que tem como objetivo cumprir todos os requisitos 
especificados na fase de análise, ela segue o modelo de desenvolvimento em 
cascata, que consiste em um desenvolvimento sequencial na qual o processo é 
constante para frente através das fases de análise de requisitos, projeto, 
implementação, testes e manutenção de software. Na fase em que foram 
desenvolvidos os códigos do sistema, ficou decidido que o sistema seria em modelo 
ERP (Enterprise Resource Planning), que consiste em interligar todos os dados e 
processos de uma organização em um único sistema. Para o desenvolvimento deste 
 
 
 
 
sistema na plataforma web será utilizado a linguagem de programação PHP na versão 
7, o padrão de projeto MVC (Model View Controller) e o banco de dados relacional 
MySQL. 
O software precisa ser validado, para garantir a qualidade que ele faz o que 
realmente foi projetado para fazer. Mas para ser validado é preciso primeiramente 
passar por uma bateria de testes de sistema. O teste é o processo de executar o 
programa com o intuito de encontrar erros antes de ser entregue ao cliente ou usuário 
final, e neste trabalho foi escolhido usar o teste no modelo teste de mesa, que consiste 
em um processo manual que é utilizado para validar a lógica de um determinado 
algoritmo. 
Figura 1: Modelo de Cascata. 
 
Fonte: (casadaconsultoria, 2021). 
 
1.4 Organização do trabalho 
 
 O trabalho está estruturado em cinco capítulos. No primeiro capítulo será 
apresentado uma introdução sobre o assunto a ser abordado, justificativa e 
resolução do problema, objetivos gerais e específicos, e a metodologia. 
 No segundo capitulo é desenvolvido a fundamentação teórica, ou seja, 
consiste em se basear através de pesquisas, artigos e livros os aspectos teóricos 
que serão utilizados no trabalho. 
 O terceiro capítulo apresenta a descrição e o porquê de todas as 
tecnologias e ferramentas utilizadas nesse trabalho contendo um pouco da sua 
funcionalidade e utilização. 
 No quarto capítulo apresenta o levantamento dos requisitos principais, o 
desenvolvimento do sistema da bateria, contendo exemplos de scripts utilizados. 
Também mostra toda a arquitetura da interface do sistema e explica a 
funcionalidade das mesmas para um maior entendimento. E por fim, explica 
como foi a fase de testes realizados para garantir que o sistema está apto para 
ser utilizado pelos membros da bateria. 
 
 
 
 
 Finalizando, como quinto e último capítulo, são apresentadas as 
considerações finais sobre o desenvolvimento do projeto e sugestões para 
trabalhos futuros. 
 
 
 
 
 
2 FUNDAMENTAÇÃO TEÓRICA 
Este capitulo descreve um pouco de como se deu início o projeto da bateria 
universitária da UFSC Campus Araranguá, suas conquistas, e como funciona a 
sua organização administrativa, bem como a importância da utilização de 
sistemas da informação em uma organização, para que seja possível traçar um 
paralelo do motivo deste trabalho ser desenvolver um sistema de gestão para a 
bateria da UFSC. 
2.1 A BaterAAACA 
 
A BaterAAACA é um projeto de bateria universitária formado por alunos 
da Universidade Federal de Santa Catarina do Campus de Araranguá, criada em 
2017 pelo aluno de Engenharia de Energia Roberto Arruda e mais alguns 
colegas com o objetivo de promover a união, integração, alegria e entretenimento 
à comunidade através do incentivo musical, disseminando diversas culturas e 
ritmos. 
No início, os treinos e apresentações eram com instrumentos de garrafa 
pet e uma bateria desmontada no intuito de acompanhar a atlética do campus 
(AAACA) durante os campeonatos como forma de torcida, mas com o tempo, o 
samba dos momentos de torcida passou por diversas transformações e por um 
forte aprimoramento técnico desde sua origem. Os primeiros instrumentos foram 
comprados da Escola de Samba Unidos do Arroio, com dinheiro arrecado na 
venda de rifas e festas. Em 2018 foi o ano que a bateria teve a sua primeira 
gestão estruturada, a primeira oficina para formação de novos ritmistas, o 
primeiro show em uma formatura da UFSC e a compra de 15 novos 
instrumentos. Em 2019 foi realizado a primeira participação em uma competição 
de baterias universitárias em Laguna, cidade localizada no Estado de Santa 
Catarina. 
 
Figura 2: Primeiros instrumentos da BaterAAACA. 
 
Fonte: Arquivos da BaterAAACA. 
 
 
 
 
 
Figura 3: Uma das formações BaterAAACA, com os instrumentos novos. 
 
Fonte: Arquivos da BaterAAACA. 
A Bateria Universitária da Associação Atlética Acadêmica Campus 
Araranguá é responsável pela seleção, montagem e manutenção dos ritmistas, 
agendamento de ensaio e treino com músicos especialistas de cada modalidade, 
inscrição em campeonatos de baterias universitárias (BU’s), ações sociais como 
visitas em escolas públicas, arrecadação de alimentos não perecíveis, 
arrecadação de brinquedos, entre outros. Ela é formada por alunos da 
universidade e para arrecadar dinheiro para custear todos os gastos com 
instrumentos, materiais, viagens, músicos, treinadores e inscrições em 
campeonatos, periodicamente promove eventos e exerce venda de itens 
personalizados, para alunos, ritmistas e qualquer outra pessoa que se interessar. 
A vendas destes itens e as apresentações em eventos são essenciais para a 
divulgação da bateria para a comunidade. 
Em sua organização administrativa, o grupo é dividido em presidente e 
diretorias e cada um possui responsabilidades especificas que estão descritas 
na tabela abaixo, as informações foram retiradas do regimento interno da 
BaterAAACA (Anexo I). 
 
Tabela 1 – Divisão interna da BaterAAACA. 
Cargo Responsabilidades 
Presidente • Gerenciar os diretores; 
• Prezar pelo bom convívio do grupo; 
• Estar ciente de competições e 
eventos; 
• Manter contato com outras baterias; 
• Convocar e organizar as reuniões 
gerais; 
• Trazer sempre novas ideias e 
propostas para manter a bateria em 
movimento. 
 
 
 
 
Diretor financeiro • Buscar orçamentos de novos 
instrumentos sempre que 
necessário; 
• Estar ciente do estado físico dos 
instrumentos; 
• Realizar um fluxo de caixa 
• Manter transparência com os 
integrantes; 
• Buscar soluções para movimentar o 
caixa; 
• Organizar compra e venda de 
produtos da bateria. 
Diretor de marketing • Ter um padrão de publicações; 
• Ter contato com outras mídias; 
• Integração com outras baterias; 
• Replicar publicações principais da 
AAACA; 
• Divulgar a Bateria dentro e fora da 
universidade. 
Diretor de gestão de pessoas • Ser acolhedor compreensível e 
responsável em relação a 
cobranças; 
• Avaliar a logística de ensaios e 
apresentações; 
• Gestão de tempo, agenda da 
bateria; 
• Responsável pelo desligamento de 
membros quando necessário; 
• Gerenciamento da admissão de 
membros; 
• Controle de presença. 
Mestre • Organizar e liderar os ritmistas em 
ensaios e apresentações; 
• Coordenar diretores musicais; 
• Representar a diretoria musical nos 
assuntos administrativos; 
• Avaliar, juntos dos demais diretores 
musicais, o estado dos instrumentos. 
 
 
2.2 Importância de um sistema da informação em uma organização 
 
A utilização de sistemas de informação tem cada vez mais importâncianas 
organizações. Segurança, gestão e controle são alguns dos benefícios desses 
softwares. Os sistemas de informação são compostos por subsistemas que 
recolhem diversas informações, e estas podem ser utilizadas para controlar 
compras, estoques, finanças, departamento comercial, entre outros. Através de 
dados centralizados e relatórios que este software disponibiliza, é possível obter 
uma visão mais abrangente do negócio, o que facilita a tomada de decisões 
 
 
 
 
estratégicas e a correção de rumos tomados pelo grupo. Além disso, eles 
mostram de forma aprofundada como funcionam as questões operacionais da 
organização (OLIVEIRA, 2015). 
Para Mañas (1999), a informação transformou-se em recurso fundamental 
em qualquer organização. Um sistema é capaz de disponibilizar informações em 
tempo real para todos os membros com acesso ao sistema e isso torna mais fácil 
e rápido identificar as necessidades. A área de produção, por exemplo, consegue 
identificar quando o estoque está baixo e resolver a questão antes que se torne 
um problema. 
O sistema de informação se adapta às necessidades da empresa. Como é 
modular, permite contratar determinada quantia de módulos, como finanças, 
estoque e recursos humanos e, conforme mudam as necessidades, pode incluir 
novas funcionalidades, como marketing e e-commerce. 
O SI está ligado com toda a organização e não somente a área de TI como 
às vezes e confundida. O TI envolve a parte de processamento dos dados para 
gerar as informações desejadas ao SI, enquanto o SI envolve todas as 
informações pertinentes, os colaboradores envolvidos e a parte de TI, por isso 
sua complexidade (OLIVEIRA, 2015). 
Seguindo este raciocínio, Laudon (2007) define SI como um conjunto de 
componentes inter-relacionados recuperam, processam, armazenam e 
distribuem informações destinadas a apoiar a tomada de decisões, a 
coordenação e o controle de uma organização. Além de dar apoio a tomada de 
decisões, a coordenação e ao controle, esses sistemas também auxiliam os 
gerentes e trabalhadores a analisar problemas, visualizar assuntos complexos e 
criar novos produtos. 
Esses sistemas têm grande importância no crescimento das empresas. Com 
o uso destas ferramentas, elas conseguem definir estratégias de crescimento 
sólido, reduzir as perdas e projetar ações futuras de grande impacto (OLIVEIRA, 
2015). 
 
 
 
 
3 IDENTIFICAÇÃO DAS FERRAMENTAS 
 
A internet é algo que está em constante evolução e está muito presente, 
tanto na vida pessoal quanto na profissional. Com isso, a proposta do trabalho é 
o desenvolvimento de um sistema web, ou seja, estará hospedado em um 
servidor e que será acessado por qualquer computador ou dispositivo conectado 
à internet. Sendo executado através de quaisquer navegadores como Internet 
Explorer, Mozilla Firefox, Google Chrome, Opera, Safari e etc. 
Sendo assim, as ferramentas escolhidas para o desenvolvimento foram: 
• HTML: Linguagem de marcação de Hipertexto; 
• PHP: Linguagem de programação principal; 
• JavaScript: Linguagem de Scripiting; 
• JQuery: Biblioteca JavaScript; 
• CSS: Folha de estilo em cascata; 
• Bootstrap: Framework CSS; 
• MySQL: Banco de dados; 
• Composer: Gerenciador de pacotes; 
• GitHub: Sistema de gerenciamento de versões; 
• Apache: Servidor web; 
• Visual Studio Code: Editor de código-fonte. 
 
3.1 HTML: Linguagem de marcação de Hipertexto 
 
HTML (HyperText Markup Language) é uma linguagem de marcação 
construída por tags que é a base da web, é utilizada para produzir páginas web 
que serão interpretadas pelos navegadores. Os documentos HTML são 
documentos de texto simples, estáticos e que podem ser criados e editados em 
qualquer editor de texto comum. A versão utilizada foi a cinco, (FREEMAN, 2008) 
que afirma que o HTML5 facilitou as aplicações em CSS, ganhando mais tempo, 
novas ferramentas e novas tags. 
3.2 PHP: Linguagem de programação principal 
 
Segundo PHP (2021), o PHP é uma linguagem de programação open 
source, capaz de gerar conteúdo dinâmico. O código é interpretado no lado do 
servidor, e os resultados são gerados em HTML no navegador do cliente. 
Segundo SOARES (2008), uma das características mais marcantes no PHP é 
sua capacidade de se misturar ao HTML, demarcando-os por meio de tags 
especiais, tornando mais fácil a geração de páginas web dinâmicas. 
Essa linguagem foi escolhida pelo fato de apresentar um bom suporte para 
o problema apresentado, e também por ser possível utiliza-la de forma gratuita. 
 
 
 
 
Figura 4: Exemplo de uma função em PHP 
 
Fonte: Sistema de gestão da BaterAAACA 
3.3 JavaScript: Linguagem de Scripiting 
 
JavaScript, as vezes abreviado para JS, é uma linguagem de programação 
interpretada estruturada, leve, de script de alto nível e suporta programação 
orientada a objetos, e funcional (MDN Contributors, 2021). 
No projeto, essa linguagem será utilizada para deixas as páginas mais 
dinâmicas e conseguir ter algumas interações com o usuário sem a necessidade 
de fazer uma requisição no servidor, como bloqueio e liberação de campos em 
formulários, exibir alertas e também solicitar confirmação para finalizar alguma 
ação, como por exemplo ao tentar excluir um registro. 
Figura 5: Exemplo de uma função em JavaScript 
 
Fonte: Sistema de gestão da BaterAAACA 
3.4 JQuery: Biblioteca JavaScript 
 
Ainda utilizando JS, existe a biblioteca chamada JQuery que foi 
desenvolvida no intuito de simplificar a navegação no documento HTML, seleção 
de elementos, manipulação de elementos, animações. Para isso, esta biblioteca 
conta com uma série de funções em JS já prontas e com uma combinação de 
versatilidade e extensibilidade, o que faz do jQuery a mais popular biblioteca JS 
(OpenJS Foundation, 2021). 
 
 
 
 
 
3.5 CSS: Folha de estilo em cascata 
 
Cascading Style Sheet (CSS) ou em português folhas de estilo em cascata, 
é uma linguagem de estilo que descreve como os elementos devem ser 
mostrados na tela (MDN Contributors, 2021). 
O CSS serve principalmente para definirmos um método para adicionarmos 
cores, espaçamento, tipo de letra, etc. aos documentos web. 
Para SILVA (2008), a grande vantagem do uso do CSS é a separação da 
marcação HTML, da apresentação do site. 
3.6 Bootstrap: Framework CSS 
 
O Bootstap consiste em um kit de ferramentas open source (código aberto) 
para personalização rápida de páginas web e principalmente para que a mesma 
seja responsiva e fique bem apresentada também em dispositivos móveis. 
Esse kit consiste em classes e variáveis CSS, componentes HTML pré-
construídos e poderosos plugins JavaScript (Bootstrap team, 2021). 
3.7 MySQL: Banco de dados 
 
O MySQL é um sistema de Gerenciamento de Banco de Dados (SGBD), 
que utiliza a linguagem Structured Query Language (SQL) que significa 
Linguagem de consulta Estruturada (Oracle, 2021). 
Essa linguagem é de fácil uso, compatível com PHP que é a principal 
linguagem de programação desse projeto. Além disso, ela tem alto desempenho, 
confiabilidade, estabilidade e portabilidade e serve basicamente para acessar, 
guardar e gerenciar da melhor forma toda a base de dados do sistema proposto. 
Figura 6: Exemplo de script em SQL 
 
Fonte: Sistema de gestão da BaterAAACA 
3.8 Composer: Gerenciador de pacotes 
 
O Composer é uma ferramenta para gerenciamento e versionamento de 
dependências (ou pacotes) em PHP. Ele permite que toda vez que for preciso 
utilizar um código ou biblioteca de terceiros como um pacote para envio de e-
mail, um conjunto de funções matemáticas e muitos outros. Assim que declarar 
 
 
 
 
no Composer, o mesmo será responsável por instalar e atualizar os pacotes no 
projeto. 
3.9 GitHub: Sistema de gerenciamento de versões 
 
Para a organização do código fonte do trabalho foi utilizado o GitHub. O 
GitHub é uma plataforma web que utiliza o Git como base e tem como principal 
função o controle de versão de sistemas. Com ele, pode-se criar projetos no qual 
várias pessoas podem contribuir ao mesmo tempo, ele écapaz de mostrar todos 
os detalhes das modificações de cada colaborador. Como o GitHub é web, ele 
permite que os colaboradores do projeto consigam contribuir de qualquer 
computador e de qualquer lugar do mundo (GitHub, 2021). 
Figura 7: Interface do GitHub 
 
Fonte: Capturada pelo autor 
3.10 Apache: Servidor web 
 
Ao acessar qualquer site ou sistema web, há um servidor por trás 
responsável por disponibilizar as páginas e todos os outros recursos. Assim, 
quando é acessado uma rede social, por exemplo, um servidor web é 
responsável por processar todas essas informações. 
O Apache é um servidor web livre, o que leva ele a ser um dos mais 
utilizados do mundo e possui a capacidade de executar e interpretar códigos em 
PHP, Perl, Shell Script, entre outros (Apache, 2021). Sua utilização mais 
conhecida é a que combina Apache, PHP e o banco MySQL, que foi a 
combinação utilizada nesse projeto. 
3.11 Visual Studio Code: Editor de código-fonte 
 
Para edição do código-fonte do projeto, foi utilizado o Visual Studio Code 
criado pela Microsoft. Ele foi escolhido por ser leve, mas poderoso, e tem um rico 
arsenal de extensões que facilitam muito na hora de escrever os códigos em 
 
 
 
 
PHP, HTML, CSS e JS e também pelo fato de o Visual Studio Code ter uma 
ferramenta de integração com o Git e GitHub (Microsoft, 2021), o que torna fácil 
a resolução de conflito e comparação do código com as versões anteriores do 
projeto. 
Figura 8: Editor de código-fonte Visual Studio Code 
 
Fonte: Capturada pelo autor 
 
 
 
 
 
4 DESENVOLVIMENTO DA APLICAÇÃO 
4.1 Definição de Requisitos 
 
Requisitos de um sistema, de acordo com SOMMERVILLE (2007), são 
descrições dos serviços fornecidos pelo sistema e as suas restrições 
operacionais. São as necessidades dos clientes de um sistema que ajuda a 
resolver algum problema, por exemplo, enviar um pedido ou encontrar 
informações. 
Muitas vezes, as especificações de requisitos de software são criadas sem 
que haja real entendimento das necessidades e problemas da organização. Por 
meio de técnicas de modelagem de processo de negócio, é possível 
compreender melhor o ambiente no qual o sistema a ser construído irá funcionar, 
o que possibilita identificar requisitos correspondentes para as reais 
necessidades do negócio (BAKER, 2001). Para esse trabalho, foi utilizado a 
modelagem de requisitos usando a notação Unified Modeling Language (UML). 
A maneira utilizada para levantar os dados foram as entrevistas, reuniões 
e conversas com os membros da BaterAAACA. A entrevista é uma das técnicas 
tradicionais mais simples de utilizar e que produz bons resultados na fase inicial 
de obtenção de dados. 
Tabela 2 – Análise de requisitos, através de histórias de usuários. 
Análise de requisitos, através de histórias de usuários 
Requisitos Descrição 
1 – Autenticação 1) O sistema deve oferecer na página inicial um formulário de 
login. 
2 – Permissão 1) Usuários devem ser divididos entre diretores e ritmistas. 
3 – Módulo apenas 
para diretores 
1) Dashboard contendo 
a) Tile com a data do próximo ensaio 
b) Tile com valor atual em caixa 
c) Tile com presença do diretor logado no sistema 
d) Tile com avisos de eventos cadastrado no calendário e 
usuário de aniversário no dia 
e) Calendário de eventos, podendo cadastrar, listar, editar e 
excluir 
2) Área de configuração geral do usuário logado 
a) Alterações de dados da conta 
b) Listagem com opção de downloads dos certificados já 
obtido 
c) Alterar senha de acesso 
3) Cadastro, edição e listagem de usuários 
4) Cadastro, edição e listagem de resumo de reuniões 
5) Cadastro, edição e listagem de documentos 
6) Cadastro, edição e listagem de certificação dos ritmistas 
7) Cadastro, edição e listagem de proposta de show 
8) Listagem de contatos do site 
9) Configuração das datas de ensaio e período de férias 
10) Cadastro, edição e listagem de ensaios, cada ensaio gera lista 
de presença para os ritmistas 
11) Listagem de presença e atrasos por ritmista 
 
 
 
 
12) Listagem de justificativa de falta em ensaio 
13) Cadastro e listagem de formulário para oficina de novos 
membros 
14) Cadastro e listagem de formulário para eleições de novos 
diretores 
15) Listagem de feedbacks da bateria 
16) Cadastro e listagem de apresentações da bateria 
17) Cadastro e listagem de usuários administradores do site(blog) 
18) Cadastro e listagem financeiros: abertura de caixa, fechamento 
de caixa, entrada de dinheiro, saída de dinheiro, saldo total 
19) Cadastro e listagem de inventário da bateria 
20) Listagem de solicitação de produtos novos 
21) Cadastro e listagem de produtos para a venda 
22) Cadastro e listagem de matérias de estudo 
3 – Módulo para 
ritmista e diretores 
1) Listagem de ensaios 
2) Listagem de faltas do usuário logado 
3) Listagem de dividas do usuário logado 
4) Listagem de vídeos para estudo 
5) Cadastro de solicitação de compra 
6) Descrição do regimento interno da bateria 
7) Listagem de resumos de reuniões, com opção de download 
8) Listagem de documentos, com opção de download 
9) Lista com todos os membros, com informações como 
aniversário, e-mail e telefone. 
 
4.1.1 Modelo Cliente-servidor 
 
O modelo cliente-servidor é a forma como um servidor fornece recursos e 
serviços para um ou mais clientes. Cada servidor fornece recursos para 
dispositivos clientes, como computadores de mesa, laptops e smartphones. 
Segundo RENAUD (1994, p.3), cliente-servidor é um conceito lógico, mais 
precisamente um paradigma, ou modelo para interação entre processos de 
software em execução concorrente. 
Esse modelo faz uso de protocolos de comunicação simples do tipo 
requisição/resposta. A fim de obter um serviço, um cliente envia uma requisição 
para o servidor. Este, por sua vez, executa as operações associadas ao serviço 
e envia uma resposta ao cliente, contendo dados ou um código de erro, caso 
tenha falha durante a execução do processo. Funcionalidades como a troca de 
e-mail, acesso à internet ou acesso a um banco de dados, são construídos com 
base no modelo cliente-servidor. Por exemplo, um navegador web é um 
programa cliente, executado no dispositivo do usuário, que consome as 
informações armazenadas em um servidor web na internet. Neste trabalho será 
usado o servidor web como forma de hospedar o sistema desenvolvido para que 
ele seja acessado de qualquer lugar com conexão à internet, portanto será usado 
o modelo cliente-servidor. 
 
 
 
 
 
 
 Esta modelagem foi criada usando o software PhpMyAdmin e, com esta 
ferramenta, foi possível criar todo o código de cadastro das tabelas, de forma 
que seja possível importar o arquivo no servidor do banco. 
4.2.2 Padrão de projeto MVC 
 
O padrão assumido para o desenvolvimento do projeto foi o MVC, Model 
View Controller, que consiste em um padrão arquitetural e que é um dos mais 
antigos e mais utilizados atualmente (Devmedia, 2021). 
A implementação de um padrão como o MVC é importante pelo fato de 
proporcionar para o desenvolvedor uma manutenção mais fácil e o possível 
reaproveitamento de classes e partes do projeto sempre que necessário, e até 
mesmo em projetos futuros. O termo padrões de projeto ou Design Patterns, 
descreve soluções para problemas recorrentes no desenvolvimento de sistemas 
de software orientados a objetos (Devmedia, 2021). 
O principal conceito do modelo MVC é utilizar uma solução já definida para 
separar partes distintas do projeto reduzindo suas dependências ao máximo, 
trazendo alguns benefícios como: aumento da produtividade, uniformidade na 
estrutura do software, redução de complexidade e entre outras. Sua arquitetura 
possibilita a divisão do projeto em camadas muito bem definidas (Devmedia, 
2021). Cada camada executa o que lhe é definido e nada mais que isso, o que 
traz como benefício o isolamento das regras de negócio da lógica de 
apresentação, que é a interface do usuário. 
As camadas do MVC são divididas em controlador (Controller), que 
interpreta as entradasatravés da rota informada na barra de endereços do 
navegador enviadas pelo usuário e mapeia essas ações em comandos que são 
enviados para o modelo (Model) ou para a janela de visualização (View) para 
efetuar a resposta ao usuário. O modelo gerencia um ou mais elementos de 
dados e faz quando necessário as alterações no banco de dados e também é 
responsável por modelar o problema a ser resolvido. Por fim, a visão gerencia a 
área que é responsável por apresentar as informações de forma amigável para 
o usuário através de elementos em HTML, ou seja, é a camada de interface com 
o usuário e é utilizada para receber a entrada de dados e apresentar visualmente 
o resultado. 
 
 
 
 
 
Figura 11: As camadas do Modelo MVC 
 
Fonte: (Portalgsti, 2007) 
4.3 Implementação 
 
O estágio de implementação do desenvolvimento de software é o processo 
de conversão de uma especificação de sistema em um sistema executável. Ele 
sempre envolve os processos de projeto e de programação de software, mas se 
uma abordagem evolucionária for utilizada, pode também envolver o refinamento 
da especificação de software (SOMMERVILLE, 2007). 
O protótipo pode ser entendido como uma primeira versão do sistema que 
é apresentado para o usuário. O objetivo da prototipação é permitir que os 
usuários ganhem experiências direta com a interface (SOMMERVILLE, 2007). 
Quando os usuários são apresentados para uma interface e realizam 
experiências e exemplos das funcionalidades, fica mais fácil ser identificadas as 
características que querem, o protótipo serve também como mecanismo para 
identificação dos requisitos do sistema. 
Neste trabalho é apresentado o protótipo da interface do sistema, como 
uma proposta para auxiliar a Bateria Universitária da UFSC a ter mais facilidade 
com o gerenciamento de suas tarefas e rotinas. A seguir, é apresentado o 
desenvolvimento das telas que foram criadas, junto com uma breve descrição 
das suas funcionalidades. 
4.3.1 Tela de login 
 
Para garantir o acesso restrito aos membros da BaterAAACA e proteger 
suas informações, é necessária uma política de segurança que restringe tal 
acesso e consequentemente, somente quem possuí usuário e senha consegue 
acessar o sistema e suas informações. 
Nesse sentido, o login ao sistema contém o campo de usuário, senha, o 
botão para entrar no sistema e um link para recuperar a senha, como ilustra a 
figura abaixo. 
 
 
 
 
 
Figura 12: Tela de login 
 
Fonte: Capturada pelo autor. 
 
Nos campos de usuário e senha, deverá ser informado, respectivamente, 
o usuário e a senha cadastradas no sistema. Quando clicado no botão de entrar, 
será validado os dados informados e, se estes estiverem corretos, o usuário será 
redirecionado para a página principal do sistema. Todavia, caso estiverem 
incorretos, aparecerá um aviso de dados inválidos. 
4.3.2 Tela de recuperação de senha 
 
Caso o usuário não lembre a sua senha, ele poderá clicar no link de 
recuperar, que o levará para a tela de recuperar senha, onde deve ser informado 
o e-mail cadastrado. Nesse momento, o sistema vai buscar em sua base de 
dados o e-mail informado e caso exista, será gerado uma nova senha aleatória, 
e enviará para o e-mail do usuário a nova senha de acesso. 
 
 
 
 
 
Figura 13: Tela de recuperação de senha 
 
Fonte: Capturada pelo autor 
 
4.3.3 Tela principal 
 
Depois de ter seus dados validados, o usuário será redirecionado para a 
página principal. Esta página (Figura 14) é composta por um menu lateral, no 
qual contém os botões principal, os submenus dos módulos de presidente, 
gestão de pessoas, marketing, financeiro e mestre na subdivisão de diretoria. Na 
subdivisão de ritmista contém os botões ensaios, minhas faltas, minhas dívidas, 
escolinha, solicitar compra, regimento interno e o submenu outros. 
Na parte superior da página contém o nome do usuário logado no sistema 
e os botões de configuração e sair. No centro há uma mensagem de boas-vindas 
e o apelido do usuário e quatro quadros contendo: a data do próximo ensaio, 
dinheiro em caixa, porcentagem de presença em ensaios do usuário logado e 
um quadro de avisos que mostra eventos registrados para o dia ou se algum 
membro faz aniversário no dia e por fim um calendário de eventos, onde pode 
ser cadastrado reuniões, apresentações, ensaios extras e qualquer outro evento 
que precise ser registrado. Um evento pode ser cadastrado com os status: 
“normal” definido pela cor azul, “importante” definido pela cor amarela ou 
“urgente” definido pela cor vermelha. 
 
 
 
 
 
Figura 14: Tela principal 
 
Fonte: Capturada pelo autor. 
 
Durante a fase de análises de requisitos, foi definido que o sistema teria 
diferentes níveis de acesso. Para isso, quando um usuário é cadastrado, é 
possível definir o status como diretor ou ritmista e caso o status seja diretor, o 
usuário terá acesso a todos os módulos do sistema e caso seja ritmista, ele terá 
somente acesso a subdivisão de ritmistas. Na ilustração abaixo (Figura 15), é 
possível ver o comportamento do menu para os diferentes status. Caso o usuário 
com status de ritmista tente acessar outras páginas, digitando o link diretamente 
na barra de endereços do navegador, o mesmo será redirecionado para uma 
página de acesso negado. 
 
 
 
 
 
Figura 15: Comportamento do menu para usuário com status de diretor. 
 
Fonte: Capturada pelo autor. 
 
Figura 16: Comportamento do menu para usuário com status de ritmista. 
 
Fonte: Capturada pelo autor. 
 
 
 
 
 
4.3.4 Tela de página não encontrada e de negação de acesso 
 
Esta tela é apresentada para qualquer usuário que não esteja usando o 
status de diretor e tente acessar alguma função restrita do sistema, e também 
caso o sistema não encontre uma rota informada, por exemplo, seja digitado 
através da barra de navegação do navegador uma rota que não exista. 
Figura 17: Tela de página não encontrada 
 
Fonte: Capturada pelo autor 
 
4.3.5 Tela de edição dos dados pessoais 
 
Ao clicar no ícone de configuração na página inicial, o usuário será 
redirecionado para a tela de edição dos dados pessoais. Nesta tela, será 
carregada com os dados do usuário logado, e o mesmo pode conferir se os 
dados estão corretos e também fazer alterações. Entretanto, os únicos dados 
que não podem ser alterados são o nome de usuário, pois quando um usuário é 
cadastrado o sistema gera um nome de usuário a partir do nome completo da 
pessoa, para que possa ter um padrão e também não pode ser alterado o 
endereço de e-mail pois é o identificador para recuperação da senha. 
Na segunda aba desta página, é possível alterar a senha de acesso, 
informando a senha atual e a nova senha, o sistema irá validar a senha antiga, 
caso esteja correta será feito a troca. 
 
 
 
 
 
Figura 18: Tela de edição dos dados pessoais, aba geral. 
 
Fonte: Capturada pelo autor 
 
Figura 19: Tela de edição dos dados pessoais, aba de recuperar senha. 
 
Fonte: Capturada pelo autor 
 
Ainda na mesma página, é possível consultar os certificados de 
participação do usuário logado, caso ele tenha, para que possam utilizar para 
validação de horas complementares do curso de graduação (Figura 20). 
 
Figura 20: Tela de certificados 
 
Fonte: Capturada pelo autor 
 
 
 
 
 
4.3.6 Módulo do presidente 
 
O módulo do presidente é composto pelos submenus: usuários, resumo de 
reuniões, documentos, certificados, propostas, contatos do site e configurações 
de ensaio. 
Na parte de usuários, que corresponde aos membros da bateria que usarão 
o sistema, é possível cadastrar, listar, pesquisar, editar e excluir um dado, e 
também é possível gerar relatórios com as informações selecionadas. A emissão 
de relatórios é algo importante, pois muitas vezes a bateria precisa mandar uma 
relação de membros que se apresentarão em um determinado show, ou 
participarão de uma competição. Ainda na tela de usuário, é possível alterar o 
nível de acesso ao sistema entre “ritmista” ou “diretor”. Casoo usuário for diretor, 
a linha do seu registro vai ficar com a coloração azul. Sempre que é cadastrado 
um usuário novo o sistema gera o nome de usuário automático para manter um 
padrão, pegando sempre o primeiro e último nome da pessoa e unindo com um 
ponto. 
Figura 21: Tela de listagem de usuário 
 
Fonte: Capturada pelo autor 
 
As telas de resumo de reuniões e documentos possuem os seus 
comportamentos bem parecidos, ambas servem para que seja colocado 
arquivos externos como um documento pdf, por exemplo, para que os membros 
tenham fácil acesso a esses documentos e de forma centralizada. A única 
diferença presente é que na tela de resumo de reuniões é uma tabela exclusiva 
para as pautas e atas de reuniões da bateria, enquanto a página de documentos 
seria para outros documentos que os membros sintam a necessidade de ter no 
sistema. 
 
Em relação à página de contatos do site, ela corresponde ao local onde fica 
registrado os contatos feitos para a bateria através do seu Blog, que ainda está 
em desenvolvimento. Os contatos ficam registrado com o nome, data, e-mail e 
assunto e através do sistema é possível responder, e essa resposta será 
encaminhado para o e-mail informado no contato do blog, o sistema também 
salva o nome do membro que respondeu, como forma de registro. 
 
 
 
 
 
 
Figura 22: Tela de listagem de contatos 
 
Fonte: Capturada pelo autor 
 
Na tela de propostas (Figura 23), é onde cadastra os dados de uma 
possível apresentação da bateria, se essa apresentação vai render algum 
pagamento, os dados de contato com o cliente e as etapas em que essa proposta 
se encontra. 
 
Figura 23: Tela de propostas 
 
Fonte: Capturada pelo autor 
 
Na página de certificados (Figura 24), é onde o presidente da bateria ou o 
responsável cadastra os certificados de participação dos membros. Depois de 
cadastrado um certificado, o usuário correspondente pode visualizar na página 
de configurações gerais. 
Figura 24: Tela de listagem de certificados 
 
Fonte: Capturada pelo autor 
 
E por último, no módulo do presidente conta com a página de configuração de 
ensaios, onde é definido os dias da semana que vão ocorrer os ensaios, e se a bateria 
está em período de férias ou não. Os dias aqui definidos ou se a bateria tá em período 
de férias, são informados no quadro de ensaios da página inicial. 
 
 
 
 
 
Figura 25: Tela de configuração de ensaio. 
 
Fonte: Capturada pelo autor 
 
4.3.7 Módulo de gestão de pessoas 
 
O módulo de gestão de pessoas é composto pelos submenus: presença, 
justificativas e formulários de inscrição para oficina, candidatura para as eleições 
e feedbacks da bateria. 
 A tela de presença (Figura 26) lista os usuários ativos do sistema e registra um 
ensaio. Nessa lista, o diretor pode informar se o ritmista está presente no ensaio, se 
faltou ou se atrasou e o tempo de atraso. De acordo com o regimento interno da bateria, 
após 10 minutos de atraso é cobrado uma multa de R$0,20 por minuto. 
Após o diretor clicar no botão de salvar, o sistema verifica se possui algum atraso 
e já realiza o cálculo da multa e, caso tenha, ele adiciona um registro a tabela “minhas 
dívidas” para que o usuário possa consultar e também coloca como um movimento de 
entrada no caixa aberto do financeiro. 
Figura 26: Tela de registro de presença. 
 
Fonte: Capturada pelo autor 
 
 Na tela de justificativas de falta (Figura 27), aparecem os registros de 
justificativas de falta enviadas pelo ritmista e cabe ao diretor aprovar ou não. De 
acordo com o regimento interno, a bateria cobra uma frequência de 80% de 
participação em ensaios e caso uma falta seja justificada e aprovada pelo diretor 
de gestão de pessoas, ela não entra nessa contagem. 
Figura 27: Tela de justificativas de faltas 
 
Fonte: Capturada pelo autor 
 
 
 
 
As telas de formulários de oficina (Figura 28) e eleições definem se tem 
eleição para diretoria ou oficina de novos ritmistas com inscrições abertas e uma 
sub listagem com os formulários enviados pelos ritmistas ou novos interessados 
no projeto. Os formulários para inscrições podem ser preenchidos pelo blog da 
bateria. 
E por fim, há a tela de feedbacks (Figura 29), onde há formulários em que 
o público em geral pode fazer uma avaliação da BaterAAACA. Esta tela tem um 
comportamento parecido com a lista de formulários da oficina. Os formulários 
são preenchidos no blog da bateria e listados no sistema. 
 
Figura 28: Tela de inscrições para oficina. 
 
Fonte: Capturada pelo autor 
 
Figura 29: Tela de formulários preenchidos para a oficina. 
 
Fonte: Capturada pelo autor 
 
4.3.8 Módulo de marketing 
 
O modulo de marketing é composto pela tela de agenda de apresentações 
(Figura 30), onde nessa página o diretor define o título, local e data de uma 
apresentação da bateria. Estes registros são listados no blog da bateria para que 
a comunidade tenha ciência de quando ocorrerá uma apresentação. 
Figura 30: Tela de agenda de apresentações. 
 
Fonte: Capturada pelo autor 
 
 
 
 
 
4.3.9 Módulo do financeiro 
 
No módulo do financeiro, encontram-se as telas de caixa, inventário, 
produtos solicitados e produtos para venda. 
 Na tela de caixa é possível abrir ou fechar um caixa. Um caixa aberto 
aceita a inserção de novos movimentos financeiros, podendo ser de entrada 
quando a bateria está recebendo dinheiro, ou de saída caso a bateria esteja 
fazendo alguma compra, por exemplo. Ainda nessa tela, é possível alterar entre 
os caixas já fechados, para poder visualizar as movimentações financeiras 
anteriores. Porém, se o caixa está com o status de fechado, não é possível editar 
nenhum movimento. 
As multas que são geradas através de atrasos de ritmistas entrarão 
automaticamente no caixa, como um movimento de entrada e, caso uma 
solicitação de compra seja aprovada, ela entrará no caixa como movimento de 
saída. 
No fim da página, o sistema mostra um resumo do saldo atual em caixa 
(Figura 31) e um link para que possa ser gerado um relatório com as 
movimentações financeiras de todos os caixas. 
Figura 31: Tela de controle de caixa. 
 
Fonte: Capturada pelo autor 
 
A tela de produtos inventário (Figura 32) é para que os diretores possam 
registrar todos os instrumentos e materiais da bateria para que fique mais fácil 
de saber o que há de disponível. Isto é importante em razão de evitar burocracias 
na hora de abrir oficina para novos membros e, desse modo, fica mais fácil saber 
quais instrumentos estão disponíveis e quais vagas poderão ofertar. 
Figura 32: Tela de produtos no inventário. 
 
Fonte: Capturada pelo autor 
 
 
 
 
 
A tela de produtos solicitados (Figura 33) traz a listagem de produtos que 
os ritmistas solicitam pela página de “solicitar compra” e traz a opção para o 
diretor financeiro aprovar ou não e caso a compra seja aprovada, a mesma 
entrará como movimento de saída no caixa. 
 
Figura 33: Tela de produtos solicitados. 
 
Fonte: Capturada pelo autor 
 
Na tela de produtos para a venda (Figura 34) está localizado o cadastro de 
produtos personalizados que a bateria vende, como chaveiro e copos. Esta tela 
possui botões de ações para aumentar ou diminuir uma unidade do produto, 
como se o mesmo fosse vendido ou reposto, utilizando essa opção pelos botões 
de ação, o sistema automaticamente gera um movimento de entrada ou saída 
no caixa aberto. 
Figura 34: Tela de produtos para venda 
 
Fonte: Capturada pelo autor 
 
4.3.10 Módulo do mestre 
 
O módulo do mestre é composto pelas telas de registro de ensaio e 
material de estudo. 
Na tela de registro de ensaio (Figura 35), o mestre pode informar se o 
ensaio do dia foi produtivo, mediano ou ruim e adicionar uma descrição de 
como foi ou o que poderia melhorar, para que os ritmistas possam consultar 
caso tenham dúvidas ou tenham faltado ao ensaio. 
Figura 35: Tela de registro de ensaios 
 
 
 
 
 
Fonte: Capturada pelo autor 
 
Com relação ao material de estudo (Figura 36), é onde omestre da bateria 
pode colocar vídeos para estudos, divididos por naipes de instrumentos e 
dificuldades. Os vídeos cadastrados nessa tela estarão disponíveis para os 
ritmistas na tela de escolinha. 
 
Figura 36: Tela de materiais de estudos. 
 
Fonte: Capturada pelo autor 
 
4.3.11 Módulo do ritmista 
 
O módulo do ritmista é composto pelas páginas: ensaios, minhas faltas, 
minhas dívidas, escolinha, solicitar compra, regimento interno e o submenu 
outros que contem a listagem de pautas e resumos, documentos com opção de 
download e uma lista de membros ativos na bateria. 
A tela de consulta de ensaios (Figura 37) traz uma listagem dos ensaios 
com a descrição informada pelo mestre da bateria para caso um ritmista tenha 
faltado em um ensaio, ele possa acompanhar o que foi ensaiado. 
 
Figura 37: Tela para consulta de ensaios 
 
Fonte: Capturada pelo autor 
 
A tela de minhas de faltas (Figura 38) é uma listagem das faltas e atrasos 
em ensaios do usuário que está logado no sistema. Ainda nessa tela o ritmista 
pode enviar uma justificativa para a falta que será avaliada pelo diretor de gestão 
de pessoas. Caso o ritmista não tenha falta, o sistema mostrara uma mensagem 
indicando que não há faltas. 
 
 
 
 
 
Figura 38: Tela para consulta de faltas por usuário 
 
Fonte: Capturada pelo autor 
 
A tela de minhas dívidas (Figura 39) condiz a uma listagem com as dívidas 
do usuário logado, como multa por atrasos em ensaios e também traz o status 
do pagamento, se está pendente ou pago. Caso o usuário não tenha nenhuma 
dívida, o sistema mostrará uma mensagem indicando que não há dívidas. 
Figura 39: Tela de consulta de dívida por usuário 
 
Fonte: Capturada pelo autor 
 
A tela de consulta de materiais (Figura 40) funciona como consulta de 
materiais de estudo cadastrado pelo mestre da bateria e é dividida por naipes de 
instrumentos onde cada material tem um nível de dificuldade informado, para 
que os ritmistas possam treinar em casa ou mesmo iniciar os estudos em outro 
instrumento, além do que já toca normalmente. 
Figura 40: Tela de consulta de materiais de estudos 
 
Fonte: Capturada pelo autor 
 
A tela solicitar compra (Figura 41) é uma tela onde os ritmistas podem 
solicitar material, peça de reposição ou manutenção para o financeiro. É muito 
comum durante os ensaios que quebre alguma baqueta, ou acabe danificando 
um pouco o instrumento e nesta tela, o usuário pode informar a necessidade 
 
 
 
 
(normal ou urgente) e a descrição, como: “Pele de surdo 18 polegadas”. Esse 
pedido será encaminhado para o financeiro que irá aprovar ou não a compra. 
 
Figura 41: Tela de solicitação de produtos 
 
Fonte: Capturada pelo autor 
 
Por fim, a tela de regimento interno (Figura 42) é uma página contendo todo 
o regimento interno da bateria dividido por assuntos, para que os ritmistas 
consigam consultar de forma mais rápida e diretamente no sistema, não tendo a 
necessidade de realizar o download do documento. 
Figura 42: Tela de regimento interno da BaterAAACA 
 
Fonte: Capturada pelo autor 
 
 
4.4 Teste de Software 
 
O Teste é o processo de executar um programa com o intuito específico de 
encontrar erros, antes da sua entrega para o usuário final (MYERS, 1979). 
À medida que os defeitos são descobertos, o programa deve ser depurado 
e isso pode requerer que outros estágios no processo de teste sejam repetidos. 
Os erros nos componentes de programa podem aparecer durante o teste de 
 
 
 
 
sistema. O processo é, portanto, iterativo, com as informações sendo 
alimentadas dos estágios posteriores para as partes iniciais do processo 
(SOMMERVILLE, 2007). 
O processo de teste de software possui duas metas distintas. A primeira é 
demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos 
levantados. A segunda é descobrir falhas ou defeitos no software que apresenta 
comportamento incorreto, não desejável ou em não conformidade com a sua 
especificação. 
Figura 43: Funcionamento de um processo de teste de software 
 
Fonte: (Sommerville, 2007). 
 
As atividades fundamentais são testes de componentes, e teste do sistema 
como um todo. O teste de sistema envolve a integração de dois ou mais 
componentes que implementam funções ou características do sistema e depois 
o teste desse sistema integrado (SOMMERVILLE, 2007). 
Para esse projeto, a fase de teste foi dividida em duas partes. Teste de 
integração, no qual consiste em acessar o código-fonte do sistema e verificar se 
a lógica implementada está correta. Para isso, foi utilizado o modelo de teste de 
mesa, que é um processo manual que consiste em ler cada uma das instruções 
e anotar o resultado de cada tarefa, verificando possíveis erros ou outras formas 
de solucionar o problema. E para a segunda parte, onde será aplicado o teste de 
realeases, no qual uma versão do sistema que poderia ser liberada aos usuários, 
é testada. Este teste concentra-se em validar se o sistema atende aos requisitos 
e assegurar que o sistema é confiável. O teste geralmente é feito usando a 
interface do usuário, onde alguns valores são testados para verificar o retorno 
do sistema. 
Tabela 3 – Resultados da fase de teste. 
Teste Falha Status 
Cadastro de eventos no 
calendário. 
Aceita eventos no mesmo 
horário, sem gerar conflito 
Pendente 
Cadastro de eventos no 
calendário. 
Aceita que usuários sem 
privilégios de administrador 
cadastrem eventos. 
Pendente 
Cadastro de usuário. O campo de matricula está 
aceitando valor nulo. 
Pendente 
Cadastro de resumo de 
reuniões, documentos e 
certificado. 
Não aceita arquivo com mais 
de 2.5mb. 
Pendente 
Calculo de multa em atraso 
nos ensaios. 
Multas geradas no caixa, por 
atraso de ritmista no ensaio 
não está respeitando a 
tolerância de 15min. 
Pendente 
Cadastro de apresentação 
na agenda. 
Permite que seja cadastrado 
evento em data inferior a 
data atual. 
Pendente 
 
 
 
 
Quebra do layout das 
tabelas. 
Em dispositivos pequenos 
como smartphones, tabelas 
com muitos dados acabam 
tendo uma usabilidade ruim. 
Pendente 
 
4.4.1 Teste de compatibilidade 
 
As aplicações Web precisam operar em ambientes que diferem uns dos 
outros. Diferentes computadores, dispositivos de exibição, sistemas 
operacionais e navegadores, têm uma influência significativa na operação. 
Para esse teste, foram utilizados alguns dos navegadores mais populares 
do mercado. 
Tabela 4 – Resultado do teste de compatibilidade: 
Navegador Resultado 
Google Chrome O teste foi satisfatório. Todas as funcionalidades implementadas 
foram executadas no navegador de forma correta. 
Mozilla Firefox O teste foi satisfatório. A maioria das funcionalidades foram 
executadas. Mas alguns campos de data/hora no cadastro do 
calendário não foram executados. Fazendo com que o usuário tivesse 
que informar manualmente. 
Microsoft Edge O teste foi satisfatório. Todas as funcionalidades implementadas 
foram executadas no navegador de forma correta. 
Internet Explorer O teste não foi satisfatório. Em alguns pontos, houve uma leve 
alteração do layout implementado e a função para ocultar o menu não 
funcionou, os campos de data/hora no cadastro do calendário não 
foram executados, e a navegação se mostrou muito lenta em várias 
funcionalidades do sistema. 
 
Com o teste de compatibilidade, foi possível observar que os navegadores 
tiveram diferentes resultados na execução do sistema. 
O Google Chrome e o Microsoft Edge foram os de melhor desempenho, e 
não apresentaram erros de execução ou layout desconfigurado. 
O Mozilla Firefox obteve um bom resultado, executou a grande maioria das 
operações. A única funcionalidade que não foi executada corretamente foram os 
campos de data/hora que servem para facilita ao usuário escolher a data e hora. 
O Internet Explorer teve um desempenho bem abaixo dos outros citados. 
Além de um pouco de lentidão nos processos e nas mudanças de páginas, a 
função de ocultar o menu não funcionou e também não foipossível executar os 
campos de data/hora. 
4.4.2 Teste de segurança 
 
O teste de segurança tem como principal objetivo buscar falhas que possam 
servir como porta de entrada para invasores, e também garantir a integridade e 
proteção das informações contidas no sistema. 
 
 
 
 
Testes de segurança são projetados para encontrar vulnerabilidades no 
ambiente do lado do cliente, nas comunicações de rede que ocorrem quando 
dados são passados do cliente para o servidor (PRESSMAM, 2006). 
Para garantir que o funcionamento do sistema esteja exatamente como 
especificado na análise, deve ser verificado se o software comporta-se 
adequadamente mediante as mais diversas tentativas ilegais de acesso, visando 
possíveis vulnerabilidades. Para isso, testa-se todos os mecanismos de proteção 
embutidos na aplicação para verificar se de fato existe a proteção quanto a 
acessos indevidos. 
Tabela 5 – Resultado do teste de segurança 
Teste Falha Status 
Restrição para somente 
usuários com status de 
administrador possam 
cadastrar eventos no 
calendário. 
Sem restrição, qualquer 
usuário pode cadastrar. 
Pendente 
Função “Excluir ensaio” Exclui sem pedir confirmação Corrigido 
Criptografia de dados 
sensíveis no banco de dados 
(CPF, telefone, e-mail, 
matricula) 
Somente a senha é 
criptografada, os dados 
sensíveis não. 
Pendente 
 
No próximo Capítulo será apresentada as considerações finais, 
demonstrando também as dificuldades encontradas e propostas de trabalhos 
que poderão ser feitos no futuro. 
 
 
 
 
 
5 CONSIDERAÇÕES FINAIS 
 
Este projeto teve como seu objetivo principal desenvolver um software que 
elimine o uso de interfaces manuais e pessoais das informações, criando 
padrões dentro da BaterAAACA. Portanto, visou-se suprir as necessidades da 
organização, principalmente, em relação as suas atividades e seus membros, 
por meio de cadastros de todos seus dados no sistema, mantendo atualizado e 
salvo todas as informações necessárias para a gestão. 
De acordo com o que foi levantado em entrevistas com os membros da 
bateria em relação aos seus processos e rotinas, juntamente com o 
conhecimento adquirido durante o curso de Tecnologia da Informação e 
Comunicação e o conhecimento em experiencias vivenciadas no mercado de 
trabalho, o desenvolvimento e uma versão inicial do projeto pode ser dada como 
concluída com sucesso. 
As disciplinas de engenharia de software, linguagens de programação, 
banco de dados, empreendedorismo, entre outras que foram estudadas durante 
a graduação foram essenciais para o desenvolvimento do projeto, juntamente 
com o auxílio dos professores durante o processo de realização do trabalho de 
conclusão de curso. 
Alinhado a tudo o que já foi citado anteriormente, o estudo feito para a 
elaboração do referencial teórico complementou conceitos vistos durante a 
graduação e como eles devem ser implementados em um projeto de software. 
Este projeto deu a oportunidade de explorar outras áreas e obter mais 
conhecimento de como facilitar a gestão de um projeto que já está em 
andamento. Também traz a experiência de aprender uma linguagem que é uma 
das mais cobiçadas no mercado de trabalho, ainda agregando a experiência de 
tela aplicada em um projeto e conhecido as dificuldades e imprevistos em que o 
trabalho nesta linguagem pode trazer, aumentando a visibilidade no mercado e 
o conhecimento obtido, este último que é um meio indestrutível para qualquer 
ser humano. 
5.1 Dificuldades encontradas no desenvolvimento do trabalho 
 
Desde o surgimento da ideia, existia o entendimento que teria dificuldades 
durante o projeto, principalmente na parte de desenvolvimento que, por ser a 
parte prática, tendia a ser a mais complicada. E não foi diferente, algumas das 
dificuldades estarão listadas a seguir. 
Um questionamento ocorrido durante o desenvolvimento do projeto 
também veio a se tornar um problema, que seria, como ajudar o usuário que 
esqueceu sua senha de acesso ao sistema. Para solucionar, foi preciso alterar 
o registro da senha do usuário na base de dados para uma senha temporário e 
encontrar uma ferramenta onde para enviar essa senha temporária para o e-mail 
cadastrado. O PHPMailer supriu a necessidade e de forma objetiva solucionou 
 
 
 
 
esse problema do envio de e-mails sem a necessidade de um servidor dedicado 
a envio de e-mails. 
Sem dúvida, a principal dificuldade foi em função da pandemia de COVID-
19 que estamos vivendo, pois, este sistema foi feito para dar suporte a todas as 
atividades presenciais da bateria universitária da UFSC. E como estamos em um 
momento atípico e a maioria das atividades estão sendo adaptadas ao contexto 
de isolamento social e, portanto, não está havendo ensaios, o que limita grande 
parte das funções do sistema, que só poderão ser exploradas totalmente após a 
normalidade das atividades. 
A certeza que fica é que todas as dificuldades encontradas, além das 
citadas acima, fazem parte do crescimento profissional, intelectual e humano. É 
com elas que se forma um grande profissional, adquirindo experiências e 
conhecimento para saber os caminhos para vencer os próximos desafios que 
surgirem no mercado de trabalho. 
 
5.2 Proposta para trabalhos futuros 
 
Nesta seção são listadas algumas propostas para melhorias e adaptações no 
sistema desenvolvido neste trabalho, para trabalhos futuros. 
• Avaliar e testar o software com usuários reais, e comparar as atividades 
da bateria antes e após a utilização do sistema; 
• Desenvolver um blog para a BaterAAACA, para integrar junto ao sistema; 
• Desenvolver um aplicativo para facilitar o controle de presença durante os 
ensaios da BaterAAACA; 
• Converter e adaptar o sistema para que ele atenda também a atlética e a 
equipe de Cheerleanding da AAACA; 
• Integrar o sistema com uma API de notificações, para avisar os ritmistas 
quando um evento é cadastrado ou está perto de acontecer. 
 
 
 
 
REFERÊNCIAS 
 
APACHE. 2021. Disponível em: < https://www.apache.org/>. 
Acesso em 13/04/2021 
BOOTSTRAP.2021 Disponível em: <https://getbootstrap.com>. 
Acesso em: 12/04/2021 
CAELUM. 2016. Desenvolvimento WEB com HTML, CSS e JavaScript. 
Disponível em: 
< https://www.caelum.com.br/download/caelum-html-css-javascript.pdf> 
Acesso em: 03/04/2021 
CASADACONSULTORIA. 2021 Modelo Cascata: O que é e como funciona? 
Disponível em: <https://casadaconsultoria.com.br/modelo-cascata/> 
Acesso em: 19/05/2021 
COMPOSER. 2021. Disponível em: < https://getcomposer.org/>. 
Acesso em 24/04/2021 
DATE, C.J. Introdução aos Sistemas de Bancos de Dados, 8ª Edição, 
Editora Campus, Rio de Janeiro, 2003. 
GITHUB. 2021 Disponível em: <https://github.com>. 
Acesso em: 12/04/2021 
IDG-Now. Pequenas e médias devem investir mais em TI em 2003. 
ComputerWorld – Negócios. Disponível em 
<www.computerworld.com.br/AdPortalV3>. Acesso em: 03/04/2021. 
MAÑAS, Antonio Vico. (1948). Administração de sistemas de informação. 
São Paulo: Érica, 1999. 
MYSQL. 2021. Disponível em: < https://www.mysql.com/>. 
Acesso em 12/04/2021 
O´BRIEN, J. A.; MARAKAS, G. M. Administração de sistemas de 
informação: Uma introdução.13º Edição. São Paulo: McGraw-Hill. 2007. 
RENAUD, Paul E. (1994). Introdução aos Sistemas Cliente/Servidor: Guia 
Prático para Profissionais de Sistemas. 
SOARES, Walace. (2008). PHP 5: conceitos, programação e integração 
com banco de dados. 5.ed. São Paulo: Érica, 2008. 
SOMMERVILLE, Ian. (2007). Engenharia de software. 8 Ed. São Paulo: 
Pearson AddisonWesley, 2007. 
VISUALSTUDIOCODE. Disponível em: < https://code.visualstudio.com/docs> 
Acesso em 14/04/2021 
 
 
 
 
WELLING, Luke / Thomson, Laura. (2005). PHP e MySQL: desenvolvimento 
Web. Rio de Janeiro: Campus, 2005. 
ZEMEL, TÁRCIO. Composer: a evolução PHP. Disponível em: 
<https://desenvolvimentoparaweb.com/php/composer-a-evolucao-php/ > 
Acesso em 24/04/2021 
 
DZENDZIK, I. T. Processo de desenvolvimento de web sites com recursos 
da UML. Dissertação (Mestrado em Computação Aplicada)