Você está na página 1de 53

FACULDADE DE CIÊNCIAS E TECNOLOGIAS

LICENCIATURA EM ENGENHARIA EM TECNOLOGIAS E SISTEMAS DE


INFORMAÇÃO
PÓS-LABORAL
2O ANO

CADEIRA DE: Analise de Sistemas


TEMA: Desenvolvimento de Sistema de Gestão Académico de uma Escola Secundaria –
Escola Comunitária Nossa Senhora do Livramento

DISCENTES:

Edilson Alberto Psungo

Enoque Pai Daniel Cuna

DOCENTE: Helton Luís General

Maputo, Maio de 2023


LISTA DE ABREVIATURAS
TIC – Tecnologias de Informação e Comunicação
LOO - Linguagem Orientada a Objeto
XP - Extreme Programing
MVP - ModePresentientte
MVC - Model View Control
MVVM - Model View View Model
HTML - Hypertext Markup Language
PHP - Hypertext Preprocessor
SQL - Structured Query Language
IDE - Ambiente de Desenvolvimento Integrado
CSS - Cascading Style Sheets
DSs - Diagrama de SequênciaSNE - Sistema Nacional de Educação
MINED – Ministério da Educação
ESG – Ensino Secundário Geral
ECNSL- Escola Comunitária Nossa Senhora do Livramento
BD – Base de Dados
GoM - Governo de Moçambique
SDJTM - Serviços Distrital da Juventude e Tecnologia da Matola
PNE - Política Nacional de Educação
Lista de Gráficos
Gráfico 1: Referente à pergunta n.º 1, feita aos funcionários. .................................................. 5
Gráfico 2: Referente à pergunta n.º 2, feitas aos funcionários. ................................................. 5
Gráfico 3: Referente à pergunta n.º 3, feitas aos funcionários. ................................................. 6
Gráfico 4: Referente a pergunta n.º 4, feitas aos funcionários. ................................................. 6
Gráfico 5: Referente à pergunta n.º 5, feitas aos funcionários. ................................................. 6
Gráfico 6: Referente à pergunta n.º 6, feitas aos funcionários. ................................................. 7
Gráfico 7: Referente à pergunta n.º 7, feitas aos funcionários. ................................................. 7
Gráfico 8: Referente à pergunta n.º 8, feitas aos funcionários. ................................................. 7
Gráfico 9: Referente à pergunta n.º 9, feitas aos funcionários da área académica. .................. 8
Gráfico 10: Referente à pergunta n.º 9.1, feitas aos funcionários da área académica. ............. 8
Gráfico 11: Referente à pergunta n.º 1, feitas aos alunos. ........................................................ 9
Gráfico 12: Referente à pergunta n.º 2, feitas aos alunos. ........................................................ 9
Gráfico 13: Referente à pergunta n.º 3, feitas aos alunos. ...................................................... 10
Gráfico 14: Referente à pergunta n.º 4, feitas aos alunos. ...................................................... 10

Lista de Figuras

Figura 1: Modelo de dados Hierárquico. ................................................................................. 19


Figura 2: Banco de dados em rede fonte. ................................................................................. 19
Figura 3: Modelo Entidade-relacionamento. ........................................................................... 20
Figura 4: Modelo Orientado a Objecto. ................................................................................... 21
Figura 5: Ciclo Extreme Programming (XP). .......................................................................... 23
Figura 6: Ciclo Scrum. ............................................................................................................. 24
Figura 7: Arquitectura MVP. ................................................................................................... 25
Figura 8: Modelo MVVM. ....................................................................................................... 26
Figura 9: Arquitectura MVC. ................................................................................................... 27
Figura 10: Organigrama da Escola Comunitaria Nossa Senhora do Livramento. ................... 30
Figura 11: Diagrama de Classes. ............................................................................................. 38
Figura 12: Diagrama de Sequência Login. .............................................................................. 39
Figura 13: Diagrama de Sequência Cadastro. .......................................................................... 40
Figura 14: Modelo Conceitual. ................................................................................................ 41
Figura 15: Modelo Lógico. ...................................................................................................... 42
Figura 16:Modelo Físico. ......................................................................................................... 43
Lista de Tabelas

Tabela 1: Descrição do caso de uso efectuar login .................................................................. 35


Tabela 2: Descrição do caso de uso cadastrar aluno. ............................................................... 35
Tabela 3:Descrição do caso de uso matricular aluno. .............................................................. 36
Tabela 4: Descrição do caso de uso cadastrar curso. ............................................................... 36
Tabela 5: Descrição do caso de uso Cobrança de emolumento. .............................................. 37
Tabela 6: Descrição do caso de uso Cadastro de emolumentos............................................... 37
ÍNDICE
1. CONTEXTUALIZAÇÃO TEÓRICA ............................................................................ 1

1.1. INTRODUÇÃO ............................................................................................................. 1

1.2. PROBLEMÁTICA .................................................................................................... 2

1.3. OBJETIVOS GERAL ............................................................................................... 3

1.3.1. Objetivo Específicos ........................................................................................... 3

1.4. HIPOTESE ................................................................................................................ 4

1.5. Justificativa do tema ................................................................................................. 4

1.6. Caracterização dos resultados do Inquérito por questionário .............................. 5

1.7. METODOLOGIAS DE DESENVOLVIMENTO. ................................................... 12

1.8. Desenho Metodológico da Investigação ................................................................. 13

1.8.1. Determinação da População e Amostra ......................................................... 13

1.8.2. Tipo de Investigação ........................................................................................ 14

1.9. DESCRIÇÃO DA INSTITUIÇÃO ............................................................................ 15

2. FUNDAMENTAÇÃO TEÓRICA ................................................................................. 17

2.1. Gestão Académica ....................................................................................................... 17

2.2. Automatização Dos Processos Nas Organizações .................................................... 17

2.3. O Sistema de gestão de base de dados na escola ...................................................... 17

2.4. Modelos de Base de dados .......................................................................................... 18

2.4.1. Modelo Hierárquico ............................................................................................ 18

2.4.2. Modelo em Rede................................................................................................... 19

2.4.3. Modelo Relacional ............................................................................................... 20

2.4.4. Modelo Orientado a Objecto .............................................................................. 20

2.5. Metodologias Ágeis de Desenvolvimento de Software ............................................. 21

2.5.1. Extreme Programming (XP)............................................................................... 22

2.5.2. SCRUM................................................................................................................. 23

2.6. Arquitecturas de desenvolvimento de Sistemas de Bases de Dados ....................... 24


2.6.1. MVP (Model View Presenter) ............................................................................ 25

2.6.2. MVVM (Model-View-View Model) ................................................................... 25

2.6.3. MVC (Model View Control) ............................................................................... 26

2.7. Ferramentas e Tecnologias utilizadas ....................................................................... 27

2.7.1. Tecnologias utilizadas.......................................................................................... 27

2.7.2. Ferramentas utilizadas ........................................................................................ 28

CAPÍTULO III ....................................................................................................................... 30

3. MODELAÇÃO DO SISTEMA DE GESTÃO DE BASE DE DADOS...................... 30

3.1. Características e Funcionalidades do Sistema proposto ......................................... 31

3.2. Metodologia Scrum desenvolvimento do Sistema .................................................... 31

3.3. Análise dos Requisitos ................................................................................................ 32

3.3.1. Requisitos Funcionais ............................................................................................ 32

3.3.2. Requisitos Não Funcionais .................................................................................. 33

3.4. Caso de uso do sistema ............................................................................................... 34

3.4.1. Cenário de caso de uso ........................................................................................ 35

3.5. Definição do Modelo de Conteúdo............................................................................. 37

3.5.1. Diagrama de Classes .............................................................................................. 37

3.5.2. Diagrama de sequência ....................................................................................... 38

3.5.3. Modelo Conceitual ............................................................................................... 40

3.5.4. Modelo Lógico ...................................................................................................... 42

3.5.5. Modelo Físico ....................................................................................................... 42

3.6. Plano de Segurança do sistema ..................................................................................... 43

4. CONCLUSÃO ................................................................................................................. 45

5. REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 47


CAPÍTULO I

1. CONTEXTUALIZAÇÃO TEÓRICA

1.1.INTRODUÇÃO
Devido ao avanço das novas tecnologias, do impacto económico e das mudanças que
os Sistemas de Informação (SI) produzem nas organizações e na sociedade, estas têm
desenvolvido, ao longo dos anos, as suas tarefas de maneira mais eficiente e produtiva, com
menores custos, aperfeiçoando a qualidade dos produtos ou serviços oferecidos e ganhando
vantagens competitivas face à concorrência.

A tecnologia exerce uma grande influência em vários setores da sociedade, sendo que
o contexto das organizações está inserido num cenário repleto de mudanças e transformações
tecnológicas, a fim de proporcionar maior eficiência, controle, segurança e até mesmo a
reestruturação dos seus processos produtivos.

Com a introdução das Tecnologias da Informação e da Comunicação (TIC) na educação


a comunidade educativa tem a possibilidade de comunicar, partilhar informações, construir
conhecimento e trocar experiências de forma mais eficiente. Temos, assim, a oportunidade de
quebrar a barreira das paredes da sala de aula e da escola, integrando-a com a comunidade que
a rodeia, a sociedade da informação e com outros espaços produtores de conhecimento.

O desenvolvimento de softwares específicos para a educação mostra que, quando estes


são utilizados de forma adequada, auxiliam o processo da construção do conhecimento
trazendo ganhos para toda a comunidade educativa com efeito direto no processo de ensino-
aprendizagem que se torna mais estimulante e eficaz.

Para os professores destacam-se vantagens como a fluidez e a rapidez na comunicação


com os seus alunos e os respetivos pais e/ou encarregados de educação; a possibilidade de
consulta, a qualquer momento, dos dados pessoais dos alunos; a consulta do seu horário das
turmas; a possibilidade de disponibilizar material de apoio aos alunos; aprovar a partilha de
conteúdos com os seus pares, entre outras.

Para os gestores, destacam-se ganhos de várias ordens, entre os quais, o registo de


professores; consulta e alteração de informações dos professores; fazer as matrículas/inscrição
dos alunos de forma menos burocrática; constituição de turmas associadas aos horários dos
professores, entre outras.

Pág. 1
Para os alunos, permite o acesso ao histórico escolar com maior rapidez; maior controlo
da assiduidade, entre outras.

Contudo, há que reconhecer que a introdução dos softwares específicos para educação
requer que o professor acrescente ao seu perfil novas competências, como por exemplo no
domínio das TIC. Essas competências adquiridas pelos professores fazem com que as
informações transmitidas à organização sirvam de base à tomada de decisão.

1.2.PROBLEMÁTICA
A Escola Comunitária Nossa Senhora do Livramento está enfrentando dificuldades em
gerenciar eficientemente os dados acadêmicos dos alunos, professores, pais e a direção da
escola. O atual processo manual de registro, armazenamento e análise dessas informações tem
se mostrado ineficiente, resultando em perda de tempo, falta de integração de dados e
dificuldades de comunicação entre as partes envolvidas. Como consequência, a escola está
enfrentando desafios na organização de horários, no acompanhamento do desempenho dos
alunos, no envio de comunicados aos pais e na avaliação do trabalho dos professores.

O problema pode ser dividido em quatro partes principais:

Alunos: A gestão dos alunos enfrenta problemas no registro de informações pessoais, como
nome, endereço, data de nascimento, contatos, histórico acadêmico e disciplinas matriculadas.
Além disso, há dificuldades em monitorar a frequência dos alunos, registrar suas notas e
avaliações, acompanhar seu desempenho escolar ao longo do tempo e identificar a necessidade
de intervenção educacional individualizada.

Professores: Os professores têm dificuldades para registrar as notas e avaliações dos alunos,
acompanhar o progresso acadêmico de cada aluno em suas disciplinas, planejar horários de
aulas, elaborar e corrigir tarefas e provas, além de fornecer feedback individualizado aos
alunos. Também enfrentam desafios ao acessar informações sobre o histórico dos alunos e
colaborar com outros professores em projetos pedagógicos.

Pais: Os pais enfrentam problemas para se manterem informados sobre o desempenho


acadêmico de seus filhos, receber comunicados e boletins escolares, acompanhar a frequência
dos alunos e se envolver ativamente na educação de seus filhos. Além disso, há dificuldades
em agendar reuniões com professores e obter feedback sobre o progresso individual de seus
filhos.

Pág. 2
Direção da Escola: A direção da escola encontra dificuldades em coordenar o trabalho dos
professores, monitorar o desempenho acadêmico geral dos alunos, acessar informações
atualizadas sobre frequência, notas e comportamento dos alunos, além de gerar relatórios e
estatísticas sobre o desempenho escolar da instituição. Também há desafios na comunicação
eficiente com os pais, professores e outros membros da equipe administrativa.

1.3. OBJETIVOS GERAL


O objetivo geral deste trabalho de pesquisa é desenvolver um sistema de gestão acadêmica para
a Escola Secundária na base de dados na Escola Comunitária Nossa Senhora do Livramento.
O sistema terá como finalidade otimizar e automatizar os processos administrativos e
acadêmicos da escola, visando melhorar a eficiência, a organização e o desempenho das
atividades educacionais.

1.3.1. Objetivo Específicos


• Analisar as necessidades e os requisitos específicos da Escola Comunitária Nossa
Senhora do Livramento em relação ao sistema de gestão acadêmica.
• Projetar e desenvolver uma estrutura de banco de dados adequada para armazenar as
informações acadêmicas dos alunos, professores, disciplinas e demais dados relevantes.
• Criar módulos funcionais que permitam o cadastro e a atualização de informações dos
alunos, como dados pessoais, histórico escolar, notas e faltas.
• Desenvolver funcionalidades que possibilitem o controle e a gestão das matrículas,
turmas, horários de aula e grade curricular.
• Implementar um sistema de registro e acompanhamento de frequência dos alunos,
permitindo a geração de relatórios e a identificação de problemas de assiduidade.
• Integrar o sistema de gestão acadêmica com outras áreas da escola, como o financeiro
e a secretaria, a fim de agilizar os processos administrativos.
• Garantir a segurança e a privacidade dos dados, implementando medidas de proteção e
controle de acesso ao sistema.
• Realizar testes e validações para garantir a funcionalidade e a usabilidade do sistema
de gestão acadêmica.
• Treinar os funcionários da escola para a utilização do sistema e fornecer suporte técnico
necessário.

Pág. 3
• Avaliar a eficácia e os impactos do sistema de gestão acadêmica após a sua
implementação, verificando se os objetivos propostos foram alcançados e identificando
possíveis melhorias.

Ao cumprir esses objetivos, espera-se que o sistema de gestão acadêmica desenvolvido


proporcione uma maior eficiência e organização para a Escola Comunitária Nossa Senhora do
Livramento, contribuindo para a melhoria do desempenho acadêmico dos alunos e facilitando
a gestão administrativa da instituição.

1.4.HIPOTESE
A implementação de um sistema de gestão acadêmica na Escola secundaria pode melhorar
significativamente a eficiência e a qualidade da gestão acadêmica, tornando o processo de
gestão açadêmica mais rápido, preciso e acessível para estudantes, professores e pais.

1.5. Justificativa do tema


O uso das Tecnologias de Informação e Comunicação (TIC) nas organizações tem evoluído
de uma forma surpreendente, isso devido às vantagens que as mesmas trazem para as
instituições que a implementam, porque além de facilitar a eficiência e automatização dos
serviços, auxiliam na tomada de decisão.

A gestão acadêmica é um processo complexo e exigente, que envolve diversas tarefas como
matrícula, controle de frequência, avaliação, emissão de boletins e históricos escolares, entre
outras. A gestão dessas tarefas manualmente pode ser bastante trabalhosa e demorada, levando
a erros e atrasos na tomada de decisão. Além disso, muitas vezes é difícil para os alunos e seus
pais acompanhar o desempenho acadêmico do aluno em tempo real.

Um sistema de gestão acadêmica pode ajudar a resolver esses problemas, permitindo que a
escola automatize muitas das tarefas de gestão acadêmica, reduzindo a carga de trabalho
administrativo e melhorando a precisão e rapidez do processo. O sistema também pode fornecer
aos estudantes e pais acesso fácil e em tempo real às informações acadêmicas, como notas,
frequência e calendário escolar, permitindo uma melhor compreensão do desempenho do aluno
e uma comunicação mais efetiva entre a escola e os pais.

Assim, a implementação de um sistema de gestão acadêmica em uma Escola Secundaria


pode ter um impacto significativo na eficiência e qualidade da gestão acadêmica, beneficiando
os alunos, professores, pais e a escola como um todo.

Pág. 4
1.6.Caracterização dos resultados do Inquérito por questionário
Após a recolha de dados, com base no inquérito por questionário, obtiveram-se os seguintes
resultados de diagnóstico da situação:

Descrição dos resultados do inquérito aplicado aos funcionários:

Gráfico 1: Referente à pergunta n.º 1, feita aos funcionários.

Quanto aos meios informáticos que fazem parte das ferramentas na escola, o gráfico acima
ilustra que 100% dos funcionários responderam “Computador”, 67% responderam
“impressoras”, 33% responderam “internet”, 33% responderam “Rede de Computadores” e
100% responderam “MS Excel e MS Word”.

Gráfico 2: Referente à pergunta n.º 2, feitas aos funcionários.

O gráfico acima apresentado mostra que 34% dos funcionários considera suas habilidades no
uso do computador e internet “Boa”, 33% considera “Muito Boa” e 33% considera
“Suficiente”.

Pág. 5
Gráfico 3: Referente à pergunta n.º 3, feitas aos funcionários.

O gráfico acima mostra que 100% responderam que a gestão da informação da escola é “Boa”.

Gráfico 4: Referente a pergunta n.º 4, feitas aos funcionários.

O gráfico acima mostra que 100% responderam que a eficiência nos serviços de atendimento
ao aluno prestado pela secretaria da escola é “Boa”.

Gráfico 5: Referente à pergunta n.º 5, feitas aos funcionários.

O gráfico acima mostra que 100% afirma que no processo de matrículas dos alunos na escola
utiliza-se “uma ficha de matrícula em papel e recibo em papel”.

Pág. 6
Gráfico 6: Referente à pergunta n.º 6, feitas aos funcionários.

O gráfico acima ilustra que 100% afirma que no pagamento de emolumentos e propinas usa-se
“Bloco de facturação em papel”.

Gráfico 7: Referente à pergunta n.º 7, feitas aos funcionários.

Neste gráfico mostra que 67% consideração que existe “pouca duplicação de tarefas” e 33%
considera que existe “Muita duplicação de tarefas”.

Gráfico 8: Referente à pergunta n.º 8, feitas aos funcionários.

Pág. 7
No gráfico n.º 8, 67% considera que é necessária uma informatização dos processos de
matrículas para listar e procura de dados no bloco de facturação” e 33% considera “tarefas
manuais e bastante desdobramento para organização e localização dos dados dos alunos”.

Gráfico 9: Referente à pergunta n.º 9, feitas aos funcionários da área académica.

O gráfico acima mostra que 100% responderam “Não” são feitas mediante um sistema
informático.

Gráfico 10: Referente à pergunta n.º 9.1, feitas aos funcionários da área académica.

No gráfico representado acima 67% responderam que consideram a utilização de um sistema


informático baseado numa base de dados para tarefas de matrículas e facturação na escola
“Boa” e 33% responderam “Muito Boa”.

Pág. 8
Descrição dos resultados do inquérito aplicado aos alunos:

Gráfico 11: Referente à pergunta n.º 1, feitas aos alunos.

O gráfico nº 11, 20% considerou os serviços prestados pela secretária da escola “Mau”, 46,7%
considerou “Bom”, 26,7% considerou “Muito Bom” e 6,7% considerou “Suficiente”.

Gráfico 12: Referente à pergunta n.º 2, feitas aos alunos.

O gráfico representado acima, 80% respondeu “Preenchimento manual de uma ficha de


matrícula”, 17% respondeu “Atendimento mediante um computador e Preenchimento de
recibo” e 3% respondeu “Atendimento mediante um Computador e impressão de Recibo”.

Pág. 9
Gráfico 13: Referente à pergunta n.º 3, feitas aos alunos.

Neste gráfico mostra que 83% respondeu “Preenchimento manual de um bloco de facturação”,
7% respondeu “Atendimento mediante um Computador e preenchimento de recibo” e 10%
respondeu “Atendimento mediante um Computador e impressão de recibo”.

Gráfico 14: Referente à pergunta n.º 4, feitas aos alunos.

O gráfico acima mostra que 20% considera que o tempo de atendimento no acto de matrículas
e pagamentos de emolumentos e propinas “Mau”, 50% considera “Bom”, 27% considera
“Muito Bom” e 3% considera “Suficiente”.

Gráfico 1: Referente à pergunta n.º 5, feitas aos alunos.


Pág. 10
No gráfico nº 15, 40% respondeu “Sim” e 60% respondeu “Não”.

Gráfico 2: Referente à pergunta n.º 5.1, feitas aos alunos.

No gráfico acima mostra que 17% dos alunos que responderam sim considerou o tempo de
resolução “Mau”, 67% considerou “Bom”, 8% considerou “Muito Bom” e 8% considerou
“Suficiente”.

Gráfico 3: Referente à pergunta n.º 6, feitas aos alunos

Pág. 11
No gráfico acima mostra que 30% respondeu “Sim” e 70% respondeu não.

Gráfico 4: Referente à pergunta n.º 6.1, feitas aos alunos.

O gráfico nº.18, mostra que 22,2% dos alunos que responderam sim considerou o tempo de
resolução do caso “Mau”, 44,4% considerou “Bom” e 33,3% considerou “Muito Bom”.

1.7. METODOLOGIAS DE DESENVOLVIMENTO.


Ao desenvolver um sistema de gestão acadêmico para uma escola secundária como a Escola
Comunitária Nossa Senhora do Livramento, é essencial escolher uma metodologia de
desenvolvimento adequada para garantir um processo eficiente, organizado e de alta qualidade.
Existem várias metodologias disponíveis, cada uma com suas próprias características e
abordagens. Neste contexto, uma metodologia ágil, como o Scrum, seria uma escolha ideal.

O Scrum é uma metodologia ágil amplamente utilizada no desenvolvimento de software. Ela


se concentra na colaboração, comunicação eficiente e adaptação contínua para alcançar
resultados de alta qualidade. Existem várias razões pelas quais o Scrum seria benéfico para o
desenvolvimento de um sistema de gestão acadêmico:

i) Colaboração e envolvimento das partes interessadas: O Scrum enfatiza a


colaboração próxima entre a equipe de desenvolvimento, os professores, os
administradores e outros envolvidos no projeto. Isso permite uma compreensão
clara dos requisitos e uma visão compartilhada do sistema a ser desenvolvido. Os
professores e administradores terão a oportunidade de fornecer feedback
regularmente, garantindo que o sistema atenda às suas necessidades específicas.
ii) Flexibilidade e adaptação contínua: O ambiente educacional está sujeito a
mudanças frequentes, como atualizações curriculares, mudanças nas políticas
educacionais e requisitos adicionais. O Scrum permite uma abordagem iterativa e

Pág. 12
incremental, com entregas regulares de funcionalidades. Isso permite que a escola
obtenha valor em etapas, adaptando-se às mudanças ao longo do tempo. O sistema
pode ser facilmente ajustado para incorporar novas exigências à medida que
surgem.
iii) Entregas rápidas e visíveis: O Scrum se baseia em iterações curtas chamadas de
sprints, geralmente de duas a quatro semanas. Cada sprint resulta em uma versão
funcional do sistema que pode ser avaliada pelos professores e administradores. Isso
permite que a escola veja o progresso do desenvolvimento e forneça feedback
regularmente, garantindo que o sistema esteja sendo desenvolvido de acordo com
suas expectativas.
iv) Melhoria contínua: O Scrum incentiva a reflexão e a melhoria contínua através de
cerimônias como as retrospectivas de sprint. Essas reuniões permitem que a equipe
de desenvolvimento, os professores e os administradores identifiquem áreas de
melhoria e tomem medidas para ajustar o processo. Isso garante que o sistema
evolua de acordo com as necessidades em constante mudança da escola.
v) Minimização de riscos: O Scrum permite a identificação antecipada de problemas
e riscos. Através de reuniões diárias de acompanhamento do progresso (daily
scrums) e de uma abordagem transparente, os problemas podem ser detectados
rapidamente e soluções podem ser implementadas. Isso reduz os riscos de atrasos
significativos ou falhas do sistema.

Em suma, o Scrum é uma metodologia ágil que oferece uma abordagem colaborativa, flexível
e adaptável para o desenvolvimento de sistemas de gestão acadêmica. Sua ênfase na
comunicação, entrega rápida e melhoria contínua torna-o uma escolha ideal para atender às
necessidades em constante evolução da Escola Comunitária Nossa Senhora do Livramento. No
entanto, é importante adaptar qualquer metodologia às características específicas da escola e
garantir o envolvimento ativo de todas as partes interessadas durante todo o processo de
desenvolvimento.

1.8.Desenho Metodológico da Investigação


1.8.1. Determinação da População e Amostra
a) População

Segundo Souza (2010), a população é a totalidade de elementos sob estudo que apresentam
uma ou mais características em comum.

Pág. 13
Para o presente estudo, a população foi constituída por 3 funcionários administrativos e 1500
alunos da Escola Comunitaria Nossa Senhora do Livramento.

b) Amostra

Amostra é um subconjunto da população usado para obter informação acerca do todo.

A amostra selecionada para este estudo foi a probabilística aleatória.

A amostra foi constituída por 3(três) funcionários e 30 alunos Escola Comunitaria Nossa
Senhora do Livramento.

1.8.2. Tipo de Investigação


A pesquisa quantitativa, portanto, é apropriada para medir opiniões, atitudes, preferências,
comportamentos. Aplica-se quando se pretende saber quantas pessoas usam determinado
produto ou serviço, ou têm interesse em um novo conceito de produto. Esta técnica de pesquisa
também deve ser utilizada igualmente para medir um mercado, estimar o potencial ou volume
de um negócio e para medir o tamanho e a importância de segmentos de mercado (Calza, 2013).

A abordagem quantitativa busca mensurar e analisar fenômenos por meio da coleta e análise
de dados numéricos. Nesse contexto, o Sistema de Gestão Acadêmico visa automatizar e
otimizar processos, como o registro de alunos, lançamento de notas e controle de presenças.
Esses processos geram dados quantitativos, como notas numéricas, frequência em aulas e
registros de estudantes, que podem ser coletados e analisados de maneira objetiva e
quantitativa.

A combinação de abordagens quantitativas e qualitativas permite uma visão mais completa e


abrangente da efetividade do sistema de gestão acadêmico. Os dados quantitativos fornecem
informações objetivas e mensuráveis, enquanto os dados qualitativos enriquecem a
compreensão dos aspectos subjetivos, interpretativos e contextuais relacionados à utilização do
sistema.

Portanto, ao desenvolver um Sistema de Gestão Acadêmico, é recomendável utilizar uma


abordagem mista, combinando métodos quantitativos e qualitativos, a fim de obter uma visão
holística e aprofundada do sistema, considerando tanto os aspectos objetivos quanto subjetivos
que podem influenciar sua eficácia e aceitação pelos usuários.

Pág. 14
1.9. DESCRIÇÃO DA INSTITUIÇÃO
Em 1983 foi introduzido, em Moçambique, o Sistema Nacional de Educação (SNE)
através da Lei Nº 4/83, de 23 de Março o qual nove anos mais tarde viria a ser reajustado pela
Lei Nº 6/92, de 6 de Maio, com vista a adequá-lo, do ponto de vista pedagógico e organizativo,
à nova conjuntura política, económica e social do País e do mundo.

Entretanto, o MINED por sua vez empreendeu esforços no sentido de expandir a rede
escolar. No quadro das políticas de expansão do ensino e em consonância com a alínea b) do
artigo 1 da Lei 6/92 de 06 de Maio, o Estado passou a permitir "a participação de outras
entidades, incluindo comunitárias, cooperativas, empresariais e privadas no processo
educativo".

Com efeito, à luz do Diploma Ministerial n.º 126/94, de Boletim da República, o


MINED autorizou o exercício da actividade do Ensino Privado, onde se destacam o Ensino
Particular Privado cujo objectivo é de obter lucros ou não e o Ensino Particular Comunitário,
sob regência da Comunidade, cujo objectivo é apoiar pessoas carenciadas da Comunidade.
Entretanto, o funcionamento dos dois tipos de Ensino obedece a um calendário previamente
instruído pelo Ministro de Educação através da instrução ministerial.

Em 1995, o Governo de Moçambique (GoM) adoptou através da Resolução Nº 8/95 do


Conselho de Ministros, a Política Nacional de Educação (PNE) e a respectiva Estratégia de
Implementação, que operacionaliza o SNE, determinando como objectivos do Ensino
Secundário, por um lado, a ampliação e a consolidação dos conhecimentos adquiridos no
Ensino Primário, tendo em vista o ingresso dos graduados deste subsistema, no Ensino Superior
ou em actividades produtivas. O aumento do acesso às oportunidades educativas para todos os
moçambicanos à todos os níveis do sistema educativo, por outro (GoM, 1995:180: MINED,
1997).

É neste contexto que foi criada, em 1998, a Escola Comunitária Nossa Senhora do
Livramento (ECNSL) localizada no bairro T3, Posto Administrativo de Infulene,

Município da Matola, propriedade da Igreja Católica. O Director desta Escola é o


administrador local da referida Igreja. Porém, uma parte da Direcção Pedagógica é nomeada
pela Direcção Provincial de Educação e Cultura de Maputo, visto que na altura da sua
construção, a Escola assinou um contrato de prestação de serviços com o MINED, onde este
se predispôs a enviar uma parte dos professores necessários, e a Escola, por sua vez, se

Pág. 15
comprometeu a receber alguns alunos das Escolas Públicas enviados pelos Serviços Distrital
da Juventude e Tecnologia da Matola (SDJTM).

A maior parte dos alunos desta Escola vêm da Comunidade local, sendo várias as razões
que os levam a ingressar naquela Escola. Dessas razões destacam-se as afectações a partir das
Escolas Primárias Públicas circunvizinhas, dos que tiverem idades superiores a 13 anos, dos
que tiverem perdido a vaga em Escolas Secundárias Públicas por excesso de faltas, outros ainda
por terem reprovado mais de duas vezes na mesma classe, ou que tenham sido expulsos de
outras Escolas Secundárias, entre outras.

No que diz respeito à estrutura organizacional, a ECNSL é, em conformidade com o


artigo 7 do Regulamento do ESG, do Tipo C (com menos de 20 salas, para além das infra-
estruturas constantes do cadastro) e tal como outras Escolas deste subsistema, a ECNSL deveria
estar constituída pelos seguintes órgãos: a) Conselho de Escola; b) Direcção da Escola; c)
Colectivo de Direcção; e d) Conselho Pedagógico. Mas, o que acontece é que a ECNSL só
possui a Direcção da Escola, e o Colectivo de Direcção. Esta Escola lecciona em regime de
três turnos, tem 76 professores, dos quais 19 do sexo feminino e 57 do sexo masculino.

Destes, 35 são licenciados ao passo que 41 têm o nível médio. Mais de metade dos
professores auferem salários a partir do Orçamento do Estado e aos restantes, a Direcção da
Escola paga a partir dos fundos provenientes das mensalidades pagas pelos alunos.

Pág. 16
CAPÍTULO II

2. FUNDAMENTAÇÃO TEÓRICA
NESTE CAPÍTULO SÃO ABORDADOS CONCEITOS RELEVANTES SOBRE BASE
DE DADOS DIGITAIS QUE SUSTENTA A PARTE PRÁTICA.

2.1.Gestão Académica
Segundo (GENNERA, 2017), a Gestão académica é um modelo educacional idealizado pelas
instituições de ensino com o objetivo de mobilizar e articular aspectos como talento humano e
competência educacional, visando a melhoria do ensino.

2.2.Automatização Dos Processos Nas Organizações


Automatizar processos nada mais é do que racionalizar e optimizar as atividades que geram os
resultados de uma organização. Seu principal objetivo é "enxugar" a produção: reduzir o
trabalho e o tempo utilizado para a execução, diminuir custos e substituir tarefas manuais por
aplicações de software. (Roig, 2017)

Com a automatização de processos obtêm-se enumeras vantagens como ganho na


produtividade, diminuição das tarefas repetitivas, integração dos setores, padronização dos
produtos e serviços, análise do desempenho, redução de custos.

2.3. O Sistema de gestão de base de dados na escola


Enquanto a informação for de tamanho reduzido, a sua manipulação e armazenamento limita-
se principalmente na utilização de planilha de cálculos (Excel) e em documentos no formato
do word (doc). A medida que a informação for aumentando haverá necessidade de identificar
uma melhor forma de armazenamento para evitar, principalmente, a redundância e o excesso
de trabalho. A melhor forma de se evitar tal situação, com auxílio das Tecnologias de
Informação e Comunicação (TIC) é a utilização de base de dados (BD) (Cab, 2015)

O uso de um sistema de gestão de base de dados, permite aumentar a eficiência no que diz
respeito aos gastos de materiais de consumo e a eficácia do processo de tomada de decisão
devido à maior e mais fácil acesso e transparência de informação para aqueles agentes que
participam da gestão escolar (Júnior, Schmitz, & Neto, 2012).

As bases de dados na gestão académica oferecem muitas vantagens, tais como: possibilidade a
gestão a manutenção de dados académicos, contribui para o aperfeiçoamento da produtividade

Pág. 17
de gestor escolares, inclui dados relacionais de alunos, professores, disciplinas e planos de
ensino, produz informação sobre os resultados de aprendizagem (António & Marcelino, 2014).

A implementação de um sistema de gestão de base de dados, mesmo não abrangendo todos os


domínios administrativos e, ou acadêmicos, proporciona resultados importantes analisando-se
o facto da integração. Sem ela, com o contínuo crescimento dos dados, tornar-se-ia cada vez
mais difícil a manutenção e consistências dos mesmos. O foco do desenvolvimento na
integração traz um melhor entendimento sobre os domínios, suas relações, processos internos
e externos. Também dessa forma os dados comuns a um grupo de setores ou interessados são
revistos pelos membros do grupo, evitando inconsistências (Araújo, et al., 2017)

Segundo Prezzo (2017) um sistema de gestão de base de dados para instituição de ensino pode
oferecer diversas vantagens para o estabelecimento educacional:

• Maior controle da instituição de ensino;


• Segurança nas informações através de senhas criptografadas e com dados armazenados
em servidor;
• Todos os dados e informações da escola reunidos num único sistema;
• Melhores condições de análise e de verificação do aproveitamento dos alunos;
• Emissão de relatórios financeiros, administrativos e escolares.

2.4.Modelos de Base de dados


2.4.1. Modelo Hierárquico
Segundo Ribeiro (2017), nesse modelo, os dados são estruturados em hierarquias ou árvores.
Os nós das hierarquias contêm ocorrências de registos, onde cada registo é uma colecção de
campos (atributos), cada qual contendo somente um valor.

Os registos são conectados uns aos outros por meio de uma ligação, também chamada de link
(associação essa entre exactamente dois registos). (Ribeiro, 2017).

Pág. 18
Figura 1: Modelo de dados Hierárquico.

2.4.2. Modelo em Rede


No modelo em rede, os registos são organizados em grafos onde aparece um único tipo de
associação (set) que define uma relação 1: N entre 2 tipos de registos: proprietário e membro.
Desta maneira, dados dois relacionamentos 1:N entre os registos A e D e entre os registros C e
D é possível construir um relacionamento M:N entre A e D (Takai, Italiano, & Ferreira, 2011).

Ao contrário do Modelo Hierárquico, em que qualquer acesso aos dados passa pela raiz, o
modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz.

Figura 2: Banco de dados em rede fonte.

Pág. 19
2.4.3. Modelo Relacional
A estrutura fundamental do modelo relacional é a relação (tabela). Na verdade, o modelo é
composto por uma colecção de tabelas de nomes únicos. Cada relação ou tabela é constituída
por uma ou mais colunas chamadas de atributos (campos) que são os tipos dos dados contidos
na relação. O conjunto de valores passíveis de serem assumidos por um atributo será intitulado
de domínio. Cada linha da relação é chamada de tupla (registo) (Ribeiro, 2017).

Figura 3: Modelo Entidade-relacionamento.

Porém, para trabalhar com essas tabelas, algumas restrições precisaram ser impostas para evitar
aspectos indesejáveis, como: Repetição de informação, incapacidade de representar parte da
informação e perda de informação. Essas restrições são: integridade referencial, chaves e
integridade de junções de relações (Takai, Italiano, & Ferreira, 2005).

2.4.4. Modelo Orientado a Objecto


A base de dados orientada a objecto(OO) é um modelo em que cada informação é armazenada
na forma de objectos, e só pode ser manipulada através de métodos definidos pela classe em
que esteja o objecto. O conceito de base de dados OO é o mesmo da LOO (linguagem orientada
a objecto), havendo uma pequena diferença: a persistência de dados (Ribeiro, 2017).

O acesso aos dados é feito diretamente ao objecto seguindo os ponteiros, podendo ser bem mais
rápido, porque não é necessário junções.

Pág. 20
Alguns problemas do modelo orientado a objectos são: ele não tem base teórica (formalismo)
como os modelos anteriores e não existe linguagem padronizada para acesso e manipulação
dos dados (tal qual o SQL) (Ribeiro, 2017).

Figura 4: Modelo Orientado a Objecto.

2.5.Metodologias Ágeis de Desenvolvimento de Software


As metodologias ágeis para desenvolvimento de software são uma resposta às chamadas
metodologias pesadas ou tradicionais. Mesmo com a evolução dos computadores, das técnicas
e ferramentas nos últimos anos, a produção de software confiável, correto e entregue dentro
dos prazos e custos estipulados ainda é muito difícil.

Segundo Soares (2004), processos orientados a documentação para o desenvolvimento de


software, como o modelo em Cascata, são de certa forma fatores limitadores aos
desenvolvedores. Além disso, muitas organizações não possuem recursos ou inclinação para
processos pesados de produção de software. Por esta razão, muitas organizações,
particularmente as pequenas, acabam por não usar nenhum processo, o que pode levar a efeitos
desastrosos em termos de qualidade de software.

Então surge a necessidade da utilização de metodologias ágeis, que não são orientadas à
documentação, preocupam-se apenas com a codificação.

Pág. 21
2.5.1. Extreme Programming (XP)
A Extreme Programming (XP) é uma Metodologia Ágil para equipas pequenas e médias de
desenvolvem softwares baseado em requisitos vagos e que se modificam rapidamente. Entre
as principais diferenças da XP em relação às Metodologias Clássicas estão o feedback
constante, a abordagem incremental e o encorajamento da comunicação entre as pessoas
(Daniel, 2008)

Segundo Américo,(2009), Extreme Programming (XP) é um processo de desenvolvimento de


software que adopta os valores de comunicação, simplicidade, feedback e coragem. Estes
quatro valores servem como critérios que norteiam as pessoas envolvidas no desenvolvimento
de software e serão detalhados a seguir:

• Comunicação: XP foca em construir um entendimento pessoa-a-pessoa do problema,


com o uso mínimo de documentação formal e com o uso máximo de interação “cara-a-
cara” entre as pessoas envolvidas no projeto;
• Simplicidade: XP sugere que cada membro da equipe adote a solução mais fácil que
possa funcionar. O objetivo é fazer aquilo que é mais simples hoje e criar um ambiente
em que o custo de mudanças no futuro seja baixo;
• Feedback: é importante, pois possibilita que as pessoas aprendam cada vez mais sobre
o sistema e assim corrijam os erros e melhorem o sistema;
• Coragem: Ela é necessária para que realmente se aplique XP como deve ser aplicado.
Exemplos de atitude que exigem coragem são: alterar código já escrito e que está
funcionando; jogar código fora e reescrever tudo de novo; e permitir código
compartilhado por todos.

O XP funciona baseado em voltas de feedback, ou seja, retornos sobre cada entrega. Para
conseguir se adaptar às mudanças, o XP preconiza ciclos curtos que dão previsibilidade e
redução de incertezas ou riscos, simplificam e geram melhorias constantes de código
(refactoring) para facilitar a mudança a partir de testes automatizados e integração contínua,
aumentando a confiança (Battistelli, 2017).

Pág. 22
Figura 5: Ciclo Extreme Programming (XP).

2.5.2. SCRUM
Scrum é um método ágil de desenvolvimento de software criado por Jeff Sutherland e sua
equipe no início de 1990. O Scrum considera uma abordagem mais humana ao solucionar os
problemas existentes no desenvolvimento de software (Carvalho & Mello, 2012).

O Scrum serve como fundamento para um projeto complexo, não ditando regras que devem
ser estritamente seguidas, mas que podem ser personalizadas conforme a necessidade da
equipe, servindo como base para uma gerência de sucesso (Bay, et al., 2016).

No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O


Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é


conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning na qual
o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que
ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint
são transferidas do Product Backlog para o Sprint Backlog (Desenvolvimento Ágil, 2018).

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada
Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior,
identificar impedimentos e priorizar o trabalho do dia que se inicia (Desenvolvimento Ágil,
2018).

Pág. 23
Ao fim de um Sprint, a equipe apresenta os requisitos e funcionalidades desenvolvidas em uma
Sprint Review Meeting. Após uma retrospectiva, a equipe de desenvolvimento passa para o
planejamento do próximo Sprint. A divisão de tarefas no Scrum baseia-se em Sprints e
Reuniões Diárias. O Sprint é o ciclo em que diversas atividades precisam ser feitas e entregues
no final para que possam ser entregues para o cliente, possuem duração fixa, normalmente de
duas a quatro semanas, mas podem ser adaptadas de acordo com a necessidade da empresa,
desde que mantenha a entrega constante (Bay, et al., 2016).

Figura 6: Ciclo Scrum.

2.6.Arquitecturas de desenvolvimento de Sistemas de Bases de Dados


A arquitectura de software de um sistema consiste na definição dos componentes de software,
suas propriedades externas, e seus relacionamentos com outros softwares. O termo também se
refere à documentação da arquitectura de software de sistema. A documentação da arquitectura
de software facilita a comunicação entre os stakeholders, regista as decisões iniciais acerca do
projecto de alto-nível, e permite o reúso do projecto e padrões entre projectos (ictea.com,
2019).

Entre as várias arquitecturas existentes destacam neste estudo: o Model View Presenter (MVP),
Model-View-View Model (MVVM) e o Model View Control (MVC).

Pág. 24
2.6.1. MVP (Model View Presenter)
Segundo Coelho (2012), o MVP é um padrão de arquitectura que visa a separação das camadas
lógicas da aplicação em três elementos:

• Model, responsável pelos dados, suas classes de domínio e regras de negócio;


• View, responsável camada de visualização, contendo todos os elementos de interface
gráfica e toda a interação com o Utilizador final;
• Presenter, camada responsável pela apresentação de dados, comunicação da view com
os comportamentos e dados do model.

Figura 7: Arquitectura MVP.

Para Coelho (2012) ao adoptar-se a arquitectura MVP, resolve-se dois problemas comuns na
camada de visualização:

Testabilidade, com o uso do MVP, nós conseguimos obter um nível maior de testabilidade no
projeto, pois conseguimos abstrair a tecnologia de visualização dos testes.

Portabilidade – Existem cenários em que precisamos portar determinadas telas e recursos em


mais de uma tecnologia, por exemplo, Web e Desktop. Nestes casos, sem a adoção de um
pattern como o MVP, normalmente pode-se ter repetição de código e um menor nível de reuso

2.6.2. MVVM (Model-View-View Model)


Para Coelho (2012), o MVVM visa estabelecer uma clara separação de responsabilidades em
uma aplicação, mantendo uma espécie de fachada entre o Modelo de objecto e a View.

Segundo Souto (2018), o padrão desta estruturado estabelece-se da seguinte forma:

Pág. 25
Figura 8: Modelo MVVM.

• View: Entidade responsável por definir a estrutura, layout e aparência do que será
exibido na tela. Dentro do nosso contexto, as Views são nossas Activities, Fragments e
elementos visuais criados para serem disponibilizados na tela.
• Model: Implementação do modelo de domínio da aplicação que inclui o modelo de
dados, regras de negócio e validações de lógica.
• ViewModel: Ele age como intermediário entre a View e o Model, é o responsável por
manusear o Model para ser utilizado pela View.

2.6.3. MVC (Model View Control)


A arquitectura MVC (Model-View-Controller), consiste na divisão de uma aplicação em três
camadas físicas, separando a informação de sua apresentação.

Wilson (2015), explica que a melhor maneira de discutir a arquitectura MVC é discutir cada
componente individualmente:

• O Model no MVC é a parte do seu aplicativo que representa seus dados. Um modelo
específico é uma classe que representa dados.
• A View no MVC é simplesmente o que é apresentado ao Utilizador. A view também é
responsável pela interação do Utilizador com o aplicativo, através do uso de links,
botões, JavaScript etc. O View também é responsável por pegar os modelos e
representá-los ao Utilizador da aplicação.
• O Control é responsável por interpretar a solicitação do Utilizador e responder a ela.
Ele pode carregar modelos específicos relevantes para a solicitação e transmiti-los para
uma visualização para representação, ou pode aceitar dados de uma visualização (por
meio de algo como uma solicitação HTTP POST) e convertê-los em um modelo e
persistir no armazenamento de dados.

Pág. 26
Figura 9: Arquitectura MVC.

Para a construção do Sistema de Gestão para a Escola Comunitaria Nossa Senhora do


Livramento optou-se pelo padrão de arquitectura MVC, por ser uma arquitectura que facilita o
reaproveitamento de código, manutenção, adição de recursos e oferece Maior integração da
equipa ou divisão de trabalho.

2.7.Ferramentas e Tecnologias utilizadas


Para a escolha de ferramentas e tecnologias para o desenvolvimento do protótipo optou-se por
aqueles que nos sentimos mais familiarizados e aqueles que nos permitirão no futuro continuar
com o desenvolvimento do protótipo melhorando e acrescendo funcionalidades.

2.7.1. Tecnologias utilizadas


a) HTML

Segundo (Costa, 2007), é uma linguagem padrão utilizada para o acesso e exibição de páginas
Web. As linhas de código HTML são interpretadas pelo browser que mostra o resultado final
ao utilizador. Genericamente, a linguagem HTML é constituída de textos e de códigos especiais
denominados marcas ou tags.

Actualmente na versão HTML5 segundo Ferreira & Eis (2014) um dos principais objectivos é
facilitar a manipulação do elemento possibilitando o desenvolvedor a modificar as
características dos objetos de forma não intrusiva e de maneira que seja transparente para o
Utilizador final.

Pág. 27
b) PHP

PHP (um acrónimo recursivo para "PHP: Hypertext Preprocessor") é uma linguagem de script
Open Source de uso geral, muito utilizada e especialmente guarnecida para o desenvolvimento
de aplicações Web embútivel dentro do HTML. É uma linguagem que permite criar sites WEB
dinâmicos, possibilitando uma interacção com o Utilizador através de formulários, parâmetros
da URL e links. (integrator tecnology e design, 2014)

c) Bootstrap

O Bootstrap é um framework utilizado principalmente para criar sites responsivos, ou seja,


aqueles que se adequam a telas de diversos formatos. Já que estamos cada vez mais conectados
em multitelas que não se restringem a de um computador, é preciso que o acesso mobile seja
agradável e proporcione uma boa experiência para os Utilizadors.

d) SQL (Structured Query Language)

SQL é uma linguagem uniformizada que facilita o armazenamento e acesso de informações.


As principais vantagens do MySQL são velocidade, robustez e facilidade de uso.

2.7.2. Ferramentas utilizadas


a) Netbeans

O NetBeans IDE permite o desenvolvimento rápido e fácil de aplicações desktop Java, móveis
e Web e também aplicações HTML5 com HTML, JavaScript e CSS. O IDE também fornece
um grande conjunto de ferramentas para desenvolvedores de PHP e C/C++. Ela é gratuita e
tem código-fonte aberto, além de uma grande comunidade de Utilizadors e desenvolvedores
em todo o mundo.

b) Wamp server

Para armazenamento dos dados foi adotado o banco de dados MySQL, para trabalhar com o
banco de dados utilizou-se o phpMyAdmin e a Consola Mysql que ajudou na análise do banco
de dados, junto com essas escolhas foi definido o servidor web que será executado diretamente
numa máquina local, para isso foi definido o WAMP que possui um pacote de aplicações livres
como Apache, PHP, MySQL e phpMyAdmin.

c) MySQL Workbench - é uma ferramenta visual para design, desenvolvimento e


administração de base de dados MySQL.

Pág. 28
d) StarUML - é uma ferramenta Open Source utilizada para desenvolvimento rápido de
projetos modelados pela UML.
e) BrModelo - é uma ferramenta para projeto de BD relacional. Ela abrange todas as
etapas, tarefas e subtarefas necessárias neste processo (Ramos & Menna, 2011).

Pág. 29
CAPÍTULO III

3. MODELAÇÃO DO SISTEMA DE GESTÃO DE BASE DE DADOS


Caracterização do Sistema manual de gestão Académica da Escola Comunitária Nossa Senhora
do Livramento.

A Escola Comunitária Nossa Senhora do Livramento como qualquer instituição de ensino está
dividida em uma hierarquia de direcção e a mesma é apresentada na figura abaixo:

Figura 10: Organigrama da Escola Comunitaria Nossa Senhora do Livramento.

Director é responsável por supervisionar toda a actividade da instituição. O Director nas suas
actividade é auxiliado pelo subdirector administrativo e Pedagógico.

O sector pedagógico compreende as actividade pedagógicas e orientação Educacional.

O coordenador Pedagógica avalia e acessória as actividades pedagógicas e curriculares, suas


atribuições e supervisionar e apoiar, prestar assistência pedagógica e didáctica.

O sector Administrativo é responsável por organizar, planificar e orientar o uso de recurso da


instituição.

A secretaria é responsável pelo planejamento, coordenação e execução dos trabalhos


estabelecidos na escola e pela participação nas reuniões pedagógicas e gestão. Nela registou o
histórico do aluno e demais funcionários da instituição.

Pág. 30
A Escola Comunitaria Nossa Sra. Do Livramento no seu sistema manual de gestão, as
informações são armazenadas em formato de papel, folha de cálculo do Excel e no Word.

No caso de matrículas é requisitado que o aluno ou encarregado traga uma capa de processo e
documentos do educando, e é fornecido no acto da matrícula uma ficha de matrícula para ser
preenchida e depois é arquivado temporariamente o processo para que depois do fim do
processo seja cadastrado em uma folha de calculo do Excel aberta para o ano lectivo em
referência.

No caso de pagamentos de propinas o aluno ou encarregado, apresenta o depósito bancário, o


funcionário faz o registo no livro de registo em papel.

Com base na justificação de investigação elaborada para este estudo, neste capítulo apresenta-
se uma proposta de sistema de base de dados para contribuir na automatização e gestão da
informação da Escola Comunitária Nossa Sra. Do Livramento.

3.1.Características e Funcionalidades do Sistema proposto

Com o objectivo de contribuir na melhoria do processo de funcionamento subjacente ao


trabalho realizado poder-se-á resumir ao seguinte:

• Somente o Administrador poderá cadastrar os funcionários que terão acesso aos demais
serviços.
• Somente os funcionários previamente definidos poderão cadastrar, gerir, controlar,
remover alunos e actualiza-los;
• O sistema também permitirá que os funcionários previamente definidos imprimem
relatórios.

3.2.Metodologia Scrum desenvolvimento do Sistema

Primeiro foram levantadas as necessidades ou requisitos do sistema com base no problema


levantado, definido assim o Product BackLog. O projecto foi dividido em ciclos (Sprint) onde
são definidas a ordem de desenvolvimento e implementação dos requisitos definidos no
Product BackLog, de seguinda é feita a Sprint Backlog onde são subtraídas a tarefas do product
backlog, ou seja, são selecionadas as tarefas ainda não concluídas. A cada ciclo (Sprint) é feita
o controlo das dificuldades e observar até que ponto esta o projecto. A Sprint review nesta fase
são avaliados os objectivos definidos no sprint e adaptar se necessário ao product backlog, a
Sprint Sprint retrospective, nesta fase são avaliados os pontos positivos e negativos que

Pág. 31
aconteceram no ciclo que se encera, e por fim o produto final e posteriormente sua
implementação.

Optou-se pela metodologia SCRUM por ser a metodologia mais usada no mundo
(principalmente para desenvolvimento web), por ser flexível e por oferecer resultados visíveis
em cada etapa do desenvolvimento.

3.3.Análise dos Requisitos


A análise de requisitos é a primeira etapa do processo de desenvolvimento de software e
sistemas de informação.

A análise de requisitos em engenharia de sistemas e engenharia de software abrange aquelas


tarefas que determinam as necessidades ou condições a serem atendidas para um produto novo
ou alterado, tendo em conta os requisitos possivelmente conflituantes das várias partes
interessadas, como beneficiários ou Utilizadors (Sofia, 2010)

O sistema permitira que o utilizador (administrador/funcionário), cadastre alunos, podendo


assim efectuar matrículas dos mesmo e impressão da lista de matriculados por turma, ainda
permitira que se processe o pagamento de propinas e impressão de recibo.

3.3.1. Requisitos Funcionais

Segundo Sofia (2010), requisitos funcionais explicam o que deve ser feito, identificando a
tarefa necessária, ação ou atividade que deve ser realizada.

Descreve-se os seguintes requisitos funcionais do sistema proposto:

RF01-Efectuar Login

A aplicação deverá permitir que o Administrador/Funcionários aceda ao sistema por meio de


uma autenticação onde deve-se informar o nome do Utilizador e a palavra passe para o acesso
do sistema.

RF02-Cadastrar Funcionar/Administrador

A aplicação deverá permitir o Administrador cadastre um novo utilizador do sistema em sua


base de dados, informando os dados precisos. O acesso à informação do sistema será mediante
permissões atribuídas ao Administrador.

Pág. 32
RF03 – Inscrever aluno

A aplicação deverá permitir que o utilizador funcionário cadastre estudante em sua base de
dados, informando os dados necessários.

RF04 - Cadastro de Curso

A aplicação deve permitir que o Administrador/Funcionário cadastre cursos, informando os


dados necessários.

RF05 - Matricular Aluno

A aplicação deve permitir que o Funcionário efectue matrícula de alunos informando os dados
necessários.

RF06 – Facturar de emolumentos

O sistema de permitir que o Funcionário efectue a facturação de emolumentos colocando os


dados precisos.

RF07- Visualizar

A aplicação deve permitir a visualização da ficha de matrícula, lista de alunos cadastrados no


sistema, lista de alunos matriculados por turma e curso, lista do pagamento de propina por
turma e curso.

RF08 – Imprimir

A aplicação deve permitir a impressão da ficha de matrícula, lista de alunos matriculados por
turma, curso e classe, lista do pagamento de propina por turma e curso e classe e recibo de
pagamento da propina.

3.3.2. Requisitos Não Funcionais


Para Machado (2016), os requisitos não funcionais não estão ligados directamente com as
funções fornecidas pelo sistema. Em geral se preocupam com os padrões de qualidade como
confiabilidade, desempenho, robustez, segurança, usabilidade, portabilidade, legibilidade,
qualidade, manutenibilidade, entre outros.

RNF01- Usabilidade

A aplicação devera permitir que o utilizador execute uma função do sistema no máximo de
dois cliques, apresentar uma interface objectiva, amigável, consistente, intuitiva e de fácil

Pág. 33
acessibilidade, isto é, suas informações e funcionalidades deverão estar bem visíveis e
disponíveis.

RNF02- Desempenho

A aplicação deverá executar as funções e carregar as páginas em tempo útil.

RNF03- Segurança

A aplicação deverá ser acedida após o utilizador ter inserido os seus credenciais válidos em
formulário de Login.

3.4.Caso de uso do sistema

Para o sistema em causa foi definido dois actores nomeadamente:

Actor 1 – Administrador: Funcionário escolhido para ser administrador do Sistema,


responsável pela manutenção do sistema.

Actor 2 – Funcionário: Funcionário que lida diariamente com os serviços

Pág. 34
3.4.1. Cenário de caso de uso
Efectuar Login (Cenário Principal)
Pré-Condição Estar pré cadastrado no sistema
Descrição • O caso de uso efectuar login começa quando o
Utilizador acede ao sistema.
• O sistema abre a tela de login onde o
Administrado/Utilizador poderá inserir as informações
como nome e palavra passe que serão os requisitos para
entrar no sistema.
• O sistema vai mostrar a página principal em caso dos
dados forem válidos.
Fluxo de evento Nome ou palavra passe não correspondem o sistema retorna
secundário uma mensagem “nome ou palavra passe invalidadas”
Tabela 1: Descrição do caso de uso efectuar login

Cadastrar aluno
Pré-condição Estar autenticado no sistema
Descrição • A aplicação solicita os dados necessários para cadastrar
o aluno.
• O Administrador/Utilizador informa os dados do
estudante.
• O Utilizador clica em Guardar.
• O sistema emite a mensagem “Cadastrado com sucesso”
Fluxo de evento Caso as informações não forem inseridas, ou seja, existir
Secundário campos obrigatórios vazios a aplicação vai notificar erro.
Tabela 2: Descrição do caso de uso cadastrar aluno.

Pág. 35
Matricular aluno
Pré-condição Estar autenticado no sistema
Descrição • A aplicação solicita os dados necessários para a
matrícula do aluno.
• O Administrador/Utilizador informa os dados
necessários para a matrícula.
• O Utilizador clica em matricular
• O Sistema emite uma mensagem “matriculado com
sucesso”.
Fluxo de evento Caso as informações não forem inseridas, ou seja, existir
secundário campos obrigatórios vazios a aplicação vai notificar erro.
Tabela 3:Descrição do caso de uso matricular aluno.

Cadastrar Secção
Pré-condição Estar autenticado no sistema
Descrição • A aplicação solicita os dados necessários para cadastrar
curso.
• O Administrador/Utilizador informa os dados
necessários.
• O Administrador/Utilizador clica em cadastrar o
sistema.
• O sistema emite uma mensagem “cadastrado com
sucesso”.
• O sistema retorna a lista de curso cadastrado.
Fluxo de evento Caso as informações não forem inseridas, ou seja, existir
secundário campos obrigatórios vazios a aplicação vai notificar erro.
Tabela 4: Descrição do caso de uso cadastrar curso.

Pág. 36
Cobrança de emolumento
Pré-condição Estar autenticado no sistema
Descrição • A aplicação solicita os dados necessários para cadastrar
curso.
• O Administrador/Utilizador informa os dados
necessários.
• O Administrador/Utilizador clica em cadastrar o
sistema.
• O sistema emite uma mensagem “cadastrado com
sucesso”.
• O sistema imprime o recibo de pagamento.
Fluxo de evento Caso as informações não forem inseridas, ou seja, existir
secundário campos obrigatórios vazios a aplicação vai notificar erro.
Tabela 5: Descrição do caso de uso Cobrança de emolumento.

Cadastrar emolumento
Pré-condição Estar autenticado no sistema
Descrição • A aplicação solicita os dados necessários para cadastrar
curso.
• O Administrador/Utilizador informa os dados
necessários.
• O Administrador/Utilizador clica em cadastrar o
sistema.
• O sistema emite uma mensagem “cadastrado com
sucesso”.
• O sistema retorna a lista de emolumentos.
Fluxo de evento Caso as informações não forem inseridas, ou seja, existir
secundário campos obrigatórios vazios a aplicação vai notificar erro.
Tabela 6: Descrição do caso de uso Cadastro de emolumentos.

3.5.Definição do Modelo de Conteúdo


3.5.1. Diagrama de Classes
O diagrama de classes é a estrela principal de um sistema orientado a objectos. Nesse diagrama
é possível modelar detalhes das classes e seus relacionamentos. (Melo, 2010).

Pág. 37
Figura 11: Diagrama de Classes.

3.5.2. Diagrama de sequência


Os diagramas de sequência (DSs) permitem especificar colaborações, descrevendo a sequência
de mensagens passadas de objecto a objecto necessária para a realização de um determinado
procedimento, seja ele um processo de negócio ou uma funcionalidade em um sistema.
(Pereira, 2011).

Pág. 38
Figura 12: Diagrama de Sequência Login.

Pág. 39
Figura 13: Diagrama de Sequência Cadastro.

3.5.3. Modelo Conceitual


O modelo conceitual deve ser uma descrição do sistema proposto que possa ser entendida pelo
usuário. Deve conter ideias e conceitos integradas referências ao processo da tarefa sobre o que
deve ser feito, como deve comportar e com o que deve parecer. (Rebelo, 2011)

Pág. 40
Figura 14: Modelo Conceitual.

Pág. 41
3.5.4. Modelo Lógico
É uma representação lógica das informações da área de negócio, não é um banco de dados, é
independente do modelo físico. Ele é independente da tecnologia implementada devido a
constante mudança dos produtos tecnológicos. (Mayer, 2005)

Figura 15: Modelo Lógico.

3.5.5. Modelo Físico


A modelagem física de dados lida com o design do banco de dados com base nos requisitos
reunidos durante a modelagem de banco de dados lógico.

Durante a modelagem física, os objectos são definidos em nível chamando de nível de


esquema. (difference between, 2011)

Pág. 42
Figura 16:Modelo Físico.

3.6.Plano de Segurança do sistema


De um modo geral, a segurança informática consiste em garantir que os recursos materiais ou
softwares de uma organização sejam utilizados apenas no âmbito previsto. (Pillou, 2017)

Segundo o (Rodrigues, Torres, & Florian, 2018), a segurança informação tem cinco objectivos
principais:

• A confidencialidade: garante que a informação seja acessível apenas àqueles


autorizados a ter acesso. Assim, um usuário sem direito de acesso, que pretende roubar
informações trocadas entre o remetente e o destinatário, não será capaz de extrair
nenhum dado protegido;
• A integridade: Verificar a integridade dos dados consiste em determinar se eles não
foram alterados durante a comunicação (de maneira fortuita ou intencional);
• A disponibilidade: garante que o acesso a um serviço ou recursos;

Pág. 43
• O não-repúdio da informação: é a garantia de que nenhum dos correspondentes
poderá negar a transacção;
• A autenticação: garante a identidade do usuário, ou seja, que ele é quem diz ser. Ela
viabiliza a comprovação de uma identidade por diversos meios (biométricos, senhas,
etc.). Na verdade, é o controle de acesso que vai permitir o acesso das pessoas
autorizadas aos recursos, mediante a digitação de uma senha, por exemplo. O controle
de acesso por autenticação é, sempre, garantido pela integridade dos dados informados.
• Confiabilidade: é demonstrar ao usuário/cliente a fidelidade e a boa qualidade da
informação com a qual ele está a trabalhar.

Pág. 44
4. CONCLUSÃO
Neste relatório, apresentamos uma proposta de desenvolvimento de um sistema de gestão
acadêmica baseado em banco de dados para a Escola Comunitária Nossa Senhora do
Livramento. O objetivo dessa proposta é fornecer uma solução eficiente e integrada para
facilitar o gerenciamento das atividades acadêmicas e administrativas da escola.

Neste estudo foi feito uma análise dos requisitos e da problemática mediante um inquérito por
questionário. Optou-se pelo modelo de base dados denominados Modelo Relacional; a
metodologia de desenvolvimento de software utilizada foi Scrum; a arquitectura de
desenvolvimento de sistema utilizado consistiu no MVC. As ferramentas e tecnologias
utilizadas são: html, php, bootstrap, SQL, Netbeans, wamp server, mysql workbench, star uml,
brModelo;

Inicialmente, analisamos os desafios e as necessidades da escola, identificando áreas como


matrículas, registros de alunos, notas, faltas, horários de aula e geração de relatórios que
poderiam se beneficiar de um sistema automatizado e centralizado.

Em seguida, propusemos um sistema de gestão acadêmica baseado em banco de dados, que


envolve a criação de uma estrutura de banco de dados que armazenará todas as informações
relevantes da escola. Essa estrutura incluirá tabelas para alunos, cursos, disciplinas, notas,
faltas, horários, professores e outros dados pertinentes.

Além disso, recomendamos o desenvolvimento de uma interface de usuário intuitiva e


amigável, que permitirá que os usuários acessem e atualizem as informações de forma fácil e
rápida. Essa interface poderá ser acessada tanto por administradores da escola, para realizar
tarefas de gestão, como por alunos e pais, para acessar informações acadêmicas individuais.

A implementação desse sistema trará diversos benefícios para a Escola Comunitária Nossa
Senhora do Livramento. Primeiramente, facilitará o processo de matrícula e inscrição dos
alunos, permitindo que essas tarefas sejam realizadas de forma online, economizando tempo e
reduzindo a carga de trabalho administrativo.

Além disso, o sistema automatizará o registro de notas e faltas, simplificando o cálculo de


médias e a geração de boletins e relatórios acadêmicos. Isso tornará mais fácil para os
professores acompanharem o desempenho dos alunos e identificarem áreas em que eles possam
precisar de apoio adicional.

Pág. 45
Outro benefício importante é a disponibilização de um portal para pais e alunos, onde eles
poderão acessar informações sobre horários de aula, notas, faltas e comunicados da escola. Isso
promoverá uma maior transparência e comunicação entre a escola e a comunidade escolar,
permitindo que os pais acompanhem de perto o progresso acadêmico de seus filhos.

Em conclusão, a implementação de um sistema de gestão acadêmica baseado em banco de


dados na Escola Comunitária Nossa Senhora do Livramento trará melhorias significativas para
a administração e o acompanhamento acadêmico dos alunos. Através desse sistema, a escola
poderá agilizar processos, melhorar a eficiência e fortalecer a comunicação entre todos os
envolvidos na educação dos alunos. Recomendamos fortemente a adoção dessa proposta para
auxiliar no desenvolvimento e crescimento da instituição escolar.

Pág. 46
5. REFERÊNCIAS BIBLIOGRÁFICAS
GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.

Ludke, M., & André, M. E. (1986). Estudos de validade de testes psicológicos: uma revisão da
literatura. Estudos de Psicologia (Campinas), 3(2), 207-216.

Souza, J. M. (2010). [Sem título do artigo ou nome da publicação].

GENNERA, M. (2017). Gestão acadêmica: o que é e como aplicar. São Paulo: Penso.

Roig, R. (2017). Automação de processos de negócios: como simplificar e aprimorar a gestão


empresarial. São Paulo: Évora.

Cab, J. (2015). Banco de dados: conceitos e fundamentos. São Paulo: Érica.

Campos, F. R. M., & Campos, M. L. M. (2001). Desenvolvimento de software educacional. In


A. Valente (Ed.), O computador na sociedade do conhecimento (pp. 189-214). Campinas:
UNICAMP/NIED.

Silveira, S. R., & Cassino, J. (2003). Software livre: a liberdade conquistada. São Paulo:
Conrad Editora do Brasil.

Calza, R. (2013). Pesquisa de mercado: teoria e prática. São Paulo: Atlas.

Echarri, M. J. (2002). Modelos e simulação: uma introdução. São Paulo: Editora Livraria da
Física.

Lakatos, E. M., & Marconi, M. A. (2007). Metodologia do trabalho científico. São Paulo: Atlas.

Cervo, A. L., & Bervian, P. A. (1996). Metodologia científica. São Paulo: Makron Books.

Governo de Moçambique. (1995). Política Nacional de Educação. Maputo: Ministério da


Educação.

Pág. 47

Você também pode gostar