school-management-backend

Backend System Overview

REST API

API Docs

• Backend default port: 4000
• Base address: http://<HOST_NAME>:4000/
• Route Categories:
  • /login - Login related routes
  • /class - Class Management related routes
  • /homework - Homework related routes
  • /df - definition related routes
  • /m - master routes
  • /rel - relationship related routes

Login Routes

Admin Routes

Parent Routes

Teacher Routes

Class Routes

Homework Routes

All Other Routes

The following is the list of routes following the above architecture

Chat Module Architecture

Project Report

Introduction

Project Background

. The education sector is a fast-growing industry in Sri Lanka. Due to the rapid development of the private school system, there is huge competition among schools and parents (Department of Census & Statistics, 2019).

Schools are expected to provide many sporting activities and subjects to their students. Due to the higher workload, schools and teachers forget to deliver the required information within a limited period. There is a direct impact on children's education due to this delay. Most of the children like to play or do anything other than homework. If parents or teachers didn’t give any homework, many children would not do any work related to education.

Less work will lead them to lower performances. If parents identify the reasons, they can find solutions. Parent-teacher meetings, home-work, past papers and term tests can be used to identify and correct the weakness of students. Fast and efficient communication and resource sharing between teachers and parents can be used to identify and correct the weaknesses of the children. School attendance is also very important to generate higher performances (attendanceworks.org, 2018).

The team was named as HexaTech as a motivation factor. All team members are possed with keen to learn and overcome challenges.

Members of the team are:

Thissa Gunarathne	as	Project Manager
Amila Dissanayaka		Server Administrator
Preshan Visad Silva		Business Analyst
Niruhan Viswarupan		System Developer
Mohan Prakashini		QA Executive
Lankitha Gallage		System Developer

Aims and objectives

As a team, we expect to reduce the communication gap between teachers and parents. Shilpa (Ys,am) is a Progressive Web Application developed using MERN Stack which is to create a user-friendly personalized environment for schools, to maintain their communication between teachers, parents, and students.

We aim to develop the efficiency of teachers and school management for better results. Development objectives can be categorized into five areas;

App messaging:

Message to	All the members
	An entire grade
	An entire class
	A particular parent
	A teacher from a parent

Notifications:

Send Notifications to	Student unauthorized absence
	Fees reminders
	Parent-teacher meetings
	Homework
	Annual student profile update by parents

Time tables:

Record	Class time table
	Exam time table
	Extra activities

Downloads:

Links to download	Exam report card
	Exam past papers
	Academic reports

File update:

Master & Transaction	Student profile
	Teachers profile
	School calendar
	Contact information
	Attendance

Project Planning

Here shows the Gantt chart used in the life cycle of software development of the project. There are five milestones to check the progress with the time. Using milestones project deviation can be identified. Parallel activities are visible in the same colours. Then identification of such tasks is easier than other tasks.

ask Allocation

Task allocation is done according to the selected role of the members. There are three members allocated for programming and development related tasks. Other three members are assigned for quality assurance, business analysis and project management. Task allocation sheet is an effective way to identify members assigned for each task.

Project Name Shilpa(Parents teacher communication application)				Project Start Date 15/01/2020
Brainstorming	15/12/2019	High	15/12/2019	Done	Every team member	Discussion about the project topics
Requirement gathering	30/1/2020	Normal	28/01/2020	Done	Preshan	Completed successfully
Business feasibility analysis	4/2/2020	Normal	3/2/2020	Done	Preshan/Amila/Thissa	Completed successfully
Technical feasibility analysis	10/2/2020	Normal	10/2/2020	Done	Lankitha/Niruhan/Amila	Completed successfully
Software design phase 1	15/02/2020	High	15/02/2020	Done	Lankitha/Preshan/Amila	Completed successfully
Software design phase 2	18/02/2020	High	18/02/2020	Done	Preshan/Niruhan/Lankitha	Completed successfully
User interface design	14/02/2020	Normal	27/03/2020	Pending	Lankitha	Pending due to the workload of the programmer
Quality Assurance Of the Design	20/02/2020	Normal	27/03/2020	Pending	Prakashini	Partially completed
Back-end Programming	8/3/2020	High	10/3/2020	Done	Niruhan	Most of the development process done
Front-end programming	15/03/2020	High	27/03/2020	Pending	Lankitha	Pending due to the workload of the programmer
Integration of the Modules	17/03/2020	High	27/03/2020	Pending	Lankitha/Amila/Niruhan	Pending due to defendant work
Testing	18/03/2020	Normal	27/03/2020	Pending	Prakashini/Preshan/Thissa	Pending due to defendant work
Quality Assurance Of the software	20/03/2020	Normal	27/03/2020	Pending	Prakashini	Pending due to defendant work
Finalize the development process	20/03/2020	Normal	27/03/2020	Pending	Lankitha/Niruhan/Preshan	Pending due to defendant work

Risk management

Risk management is an important part of the successful completion of the project. Software risk management requires a greater depth of knowledge than other risk management processes.

Identified Risks

ID	Identified Risk	Risk management method
R1	Not being able to complete the project on time	Assign half of the team members for development related tasks. Frequently ask programmers to present their work.
R2	Less user satisfaction	Instructions were given to the developers and business analysis to tally the gathered requirements and development output.
R3	Cost overrun	Encourage members to develop most of the modules within the team.
R4	Complete failure of the project.	Due to coronavirus infections, there is a possibility that the project fails. Advice has given to the members to maintain their health.
R5	Software quality problems	Rigorous quality assurance testing and validation
R6	knowledge gaps of the members	Self-learning the identified gaps online, and knowledge sharing among group members
R7	Less Commitment of the team members.	Always motivate team member to finish the work as soon as possible

System Analysis

System analysis is used to identify requirements and convert them into a software reality. First required information should be collected. By analysing gathered requirements, the framework of the software can be designed.

Fact gathering techniques

We used the following techniques to gather the required information.

1. Interviews - Top-down approach used frequently
2. Observation - school work process observed
3. Document Analysis - analysis student reports, school letters and documents published on the notice board

Analysis of gathered facts

According to the gathered facts, most of the schools expect unique applications rather than a common application. They need to overcome the weakness of the Whatsapp app. Their budget is also limited. Schools expect to reduce the workload of the teachers up to some extent. They mainly expect attendance, absence tracking, homework distribution, attendance to extracurricular activities, payment reminders and individual directed communication using the mobile application. Better security of the application and over-the-phone production support also among the expectations of the school management.

Software Requirement Specification

Introduction:

The purpose of this document is to improve communication systems in school.

**Document convention: **Database, distributed database and the entity relationships

Feasibility Study

Economic feasibility

1. SHILPA reduced a lot of manual work in school.
2. Using SHILPA app school's work efficiency will be improved.
3. Student’s sensitive information (eg. medical updates) can be updated safely and no unauthorized access.

Therefore Shilps app is economically feasible.

Technical feasibility

1. MongoDB is used as a database which is easy to install and setup and easy to scale.
2. The app is developed under the ReactJS environment where it provides real and significant mobile applications and it supports both Android and iOS mobile devices. It will save developers time because developers do not need to develop two applications for Android and iOS.

Therefore Shilpa app can be developed in a reasonable time.

Operational feasibility

The Shilpa app develops to enhance communication and relationship between schools and families. Since the app can run on both Android and iOS mobile devices, anyone can log in to the app at any time anywhere. School computer laptops or tablets can be used for backend purposes. Since the server is hosted on the cloud, no need to keep the server administrator to look after the server and take backups.

Therefore Shilpa app is operationally easy to handle.

Intended audience & suggestions

The system is restricted within the school premises with admin, students, parents and teachers. This was implemented under the requirements gathered from;

Interview with	Position	School
Rev.Fr. Indunil Sampath	Rector (Primary Principle)	St. Sebastian’s College, Mortuwa.
Mrs Aruni Fernando	Class teacher	St. Sebastian’s College, Mortuwa.
Mrs Shalika Perera	Parent	St. Sebastian’s College, Mortuwa.
Mas Nimira Cooray	Student	St. Sebastian’s College, Mortuwa.
Mrs Sharmila Fernando	Sectional head	Holy Family Convent, Bambalapitiya.
Mrs Rozan	English teacher	Holy Family Convent, Bambalapitiya.

Project Scope

1. Access to students, parents, teachers, and admins to use the new application
2. Direct messaging between teachers and parents
3. Storing student details in the database
4. Attendance tracking
5. Fee status tracking and reminders
6. Parent-teacher meeting scheduling
7. Homework distribution

Out of Scope

1. Online fee payment through gateway
2. Timetable for subjects, extracurricular activities
3. Advanced level stream recommendation
4. School transport GPS tracking
5. School calendar view

Other Equivalent Systems

We refer to a few other systems to identify the process. We aim to identify the process to build our system with the higher compatible ability to the market. here are a few systems with their functions.

ParentSquare

Features:

Sending individual messages

Sending group messages

Newsletters

Sending emergency alerts/notification

Students attendance management

School directory

Payments update

School calendar

    10. **_  TASS.web_**

Features:

Student profile / Attendance / Assignment

Update medical information of the student

Behavioural management

The Internet payment gateway for pay fees

Test time tables

Test results

Assessment results

View teachers comments

2. Product description 14. Product Perspective

There are three major users of the system;

Student Basic Student Information Class Details Attendance Marks Extracurricular Activities

Parent Basic Parent Information Occupation Details

Teacher Basic teacher Information Education qualifications Teaching subjects Extracurricular

Apart from the users mentioned above, there are administrative users. Who have all the rights to maintain the system.

15. **_User Class and Characteristics_**

    11. **_Functions & Features are shown below_**

Functions:

1. Hostel administration (future development)
2. Learning administration
3. Education dashboard
4. Class, marks and registration update
5. Disciplinary management etc.(future development)

Features:

1. Centralized app for schools
2. Maintain system users
3. Sending messages, popup notifications to parents
4. Finalizing the exam marks, average, ranks
5. Informing the parent's meetings, calendar reminders
6. Downloads

16. **_Tools & Environment _**

The operating environment for this school application is used are;

1. Hosting Server – CentOS 7.8
2. Firewall – IPTables
3. Frontend Platform – ReactJS
4. Backend Platform – NodeJs + Express
5. Database – MongoDB
6. Push Notifications - Firebase 17. Database distribution

18. Client / Server System

1. Distributed with client/server side.
2. All data resides on the server-side
3. The application executed on the client-side. 19. _ Hardware_

The system can be used with the following hardware

1. Tablet
2. Desktop
3. Mobile phone 20. Software Quality Attributes
4. Availability: including all detailed information(competition venue, time transport facility).
5. Correctness: passing an accurate information
6. Maintainability: admin will manage the database and the app
7. Usability: satisfy the school team and parents.
8. System Design 21. _ 3-Tier Architecture_

Three-tier architecture is used to compose the layers of logical computing, as per to our application we used as a specific type of server-side and client-side. This supported many benefits for the development environment and modularizing the user's interface, data storage of a school. As well, it was very useful to update a specific new feature to an application independently of other parts with flexible improvement in the overall development process. This is used because it can help the application to redevelop and modernize without affecting other functional business data access. It contains a presentation, layer and data tier and well supportive architecture to speed up the development of an application and to check it’s performances and to modularize.

It was used for end application from the database and selected according to school needs, specific parts of the application without affecting other features. These were developed as layers it showed in below image.

22. **_Agile Methodology_**

This methodology is used to develop school application and it is used to determine the enhancement needed on the development methods and terms with five those are as follows;

**Requirement Analysis: The **stage where the needed requirements are gathered in some schools and describe the problems and motivation for building the school application.

**Planning: **Targeting the end-users and deciding the time duration and frequent versions. Hence feedback is received regularly. Debugging the errors, and fixing the problems on time.

Designing: An approach using XP and coding style with simple designs to log and view by delivering the domain knowledge to users. Tasks are allocated according to the respective developers and keeping the task in the form of a board of “to do” and “in progress”. ** **

Testing: Mapping for the process and testing is created in every iteration and it has been started and an artefact is constructed. After the iteration levels, the whole system is tested and results demonstrated immediately. XP uses TDD techniques to ensure all implemented features are tested.

**Release: **In this phase, we review the results, then assess the current performance of the application. Identifying whether the system is completed without any errors and failures, Checked whether it is supported to the end-users when release is planned for retirement.

**Maintenance: **Once the feedback is received from schools at each stage, the results are discussed with the team and the features are further improved and the factors are decided according to their perspective.

This model is used to get high-quality applications and it is a more adaptable alternative with a unique modification. Due to the above features and advantages, we decided to use an Agile methodology to develop our application.

4. System development 23. Development of the Prototype

Two different prototypes were made. The first was made for the interim presentation. Based on the feedback from the lecturer we decided to develop a new prototype from scratch. In the prototype both the frontend and backend was developed within the same project and 3-tire architecture was not fully used. The frontend was developed using ReactJS and the backend using Node.js + Express. The frontend was basic and not responsive. It behaved more like a static web page rather than a responsive React application. Based on suggested data model changes and feature changes we moved onto the next version which is described in the next section.

24. **_Used Technologies/Algorithm_**

As discussed earlier, a 3-tire architecture was applied in development. Model and controller resided in the backend and the view was made in the front end. The backend was built in Node.js with Express server. Socket.io was used for developing messaging systems.

The model was designed as Mongoose schemas which can be stored in MongoDB. The backend and frontend communicate using REST API with HTTP requests. The frontend was developed in ReactJS and use Axios to connect with the backend. The UI was developed with Material-UI & Bootstrap.

Once a user is logged in a key is sent to the frontend, this will be used for all the transactions. And along with the username password, the system is sending the service key using for the push notifications to the server to map the users for the notifications. This is used with the Firebase for the notifications.

Sample of a sent token is shown below;

Users of the system are derived as Administrators, Teachers, Parents, Students. Each of them has different credentials of the system. Administrators have all the authentication.

Administrators can maintain the core details of the organization. The option for the privileges is limited.

Once a notification needs to be sent to a specific group, an administrator or an authorized teacher and push the notifications to the firebase server. And the users will get them instantly. A sample notification is shown below;

System users can also use the internal messaging service to send and receive messages. When a user logged in and chat using socket.io a port is reserving for s particular message thread. System users can be assigned to theses threads by the administrator.

GitHub was used for version controlling and collaborating among team members.

5. _System QA Testing _

Report

Testing is combined as manual testing and automated testing for the front end. According to our school application, I used manual testing for the front end by creating the test cases in excel sheets which allows us to cover all functional & nonfunctional scenarios in our system. Back end was tested using MongoDB, Node.js and Postman while testing the back-end the first time it was successful and again when testing other parts overall back-end testing got stuck I restarted and tried to get results but errors continuously occurred therefore that unable to give the results because of time constraints. For front end presentation I used the excel sheet to update the process of application whether the application passes or fails with actual and expected results, test cases are created along with the development. As per our team development, we followed the agile methodology in which it can repeat the process in the development stage and from time to time new features are implemented. To test the function, I used some process & procedures which the specific function got pass without any failure. While testing front end errors and bugs are identified and reported to our developer then all bugs errors are corrected by developers. Once bugs are fixed again, execute the failing test case to verify whether the specific function is passed.

QA Testing methods, process, procedures

As a QA the testing more importantly concerned to give a good quality of product to the specific school, therefore that to cover all functional requirements without any failure in the application I followed some testing process and procedures those are as below,

1. QA Testing Methods Analyzed

2. Test Design - Manual Testing with excel test cases

3. Testing Methodology - agile testing strategy

The below shows the procedures and process how application tested as per to agile testing strategy

4. **Retest Error test strategy **

Tracking the error in UI if errors are tracked and identified in application reporting to developer to fix the bugs and give back to retest the specific functions to check get pass.