Developing a Web Based Student Management System

1.1 System objectives

The primary objective of the proposed system is to have an efficient and cost-effective solution in all of the processes of Data Science School (DSS) by developing a web-based student management system.


The system also aims to provide the following:


  • To enable students/clients, agents and staff to apply online
  • To speed up the admission process
  • To have an accurate capturing and reporting of data
  • To have a reliable record-keeping
  • To produce accurate records and reports
  • To track student’s performance  
  • To provide agents an easier approach in tracking the status of applications and commissions
  • To eliminate redundancy in making files
  • To have a timely processing of outstanding payments
  • To eliminate processing duplicate payments and over payment of agent commissions
  • To provide secure data storage
  • To reduce staff and maintenance costs

1.     Use Case Diagram


The interactions among the objects in any system is illustrated using the Use Case Diagram. It is used in the system analysis phase to define the system requirements (Rouse 2014).

The Use Case Diagram of Data Science School Management System is composed of five actors namely the student, agent, trainer, admin/staff and the manager/owner. The diagram has system of interest, roles of the actors, use cases and relationships between and among the actors and the use cases.

Based on the figure 1 above, the primary actor of the system is the admin/staff as he/she is involved in several key interactions among the other actors and has many permissions in navigating the system. The admin/staff role acts as a middle man between the student/client and the manager.

2.     Context Level Diagram


Context diagram is the top level of Data Flow Diagram. It also shows the main external entities and one process which generalises the function of the entire system in relationship to the external entities

 According to Valacich, George and Hoffer (2015), context Diagram is the master plan of the system requirements thus, Figure 2, shows the Context Diagram of Data Science School management system which has four entities and these include: Student, Teacher, Agent and Staff. These entities are the objects outside the system with which the system communicates. Therefore showing the source and destinations of the system inputs and outputs. For instance the student entity lodges an application for admission and gets a feedback through a data which is the application update. This in turn gives the student the present statues of the application she/he lodged.   In the same vein the Agent entity supplies data through lodging application and receives a data through application update and then agent entity can lodge request for claiming commission. Also the Teacher entity gets data from the process via Course details and gives back information via Assign marks data. However, the Staff entity gets data through the Reports and Commission request and gives back to the system via a data course details and issue payment.

3.     Level 0 Data Flow Diagram


Just as the saying goes a picture is worth a thousand words, this level of data flow diagram is. It is an expanded version of the context diagram and gives a full overview of the system. It shows more detailed data flow diagram with number of steps ranging from the major process, data stores and data flow. It shows the scope and boundaries of a system at a glance plus other systems that interact with it.

Figure 3, shows the Data flow Diagram level zero of Data Science School with four entities namely: Student, Staff, Agent and Teacher. As the diagram depicts there are six stores which are login info, admission database, course info, communication history, result database and payment history.

It also has six processes which are:

  1. Signup/log in
  2. Admission process,
  3. Communication,
  4. Process course info,
  5. Results calculator,
  6. Process payment.

On the other hand it has the following Data flow:

  1. Agent log in info
  2. Teacher login info
  3. Student login info
  4. Staff login info
  5. Apply for admission
  6. Admission update
  7. Check info
  8. Show notification
  9. Admission update lodge application
  10. Manage application
  11. Store admission info
  12. Retrieve admission info
  13. See communication history
  14. Manage communication
  15. Update course info
  16. Store course info
  17. Retrieve course info
  18. Manage payment
  19. Issue commission
  20. Claim commission
  21. Submit queries
  22. Issue COE
  23. Feedbacks
  24. Get course info
  25. Store result
  26. Retrieve result
  27. Pay fees
  28. Payment notification
  29. Store payment history
  30. Retrieve payment info
  31. Provide marks
  32. See grades
  33. Request certificate

4.     ERD Diagram


According to Valacich, George and Hoffer (2015), an entity-relationship diagram (ERD) represents data in step by step order, with proper logical and graphical notations. It models the entities involved in a system, relationship among them and outlines the attributes of the entities as well as their relationships.

Entities are data about the user, object or event which will be interacting with the system and whose data needs to be maintained. Entities are represented by rectangles, lines are used to represent the relationships between the entities. The entities can identified uniquely through their primary key. Sometimes foreign key is used, which is a field in one table, to uniquely identify the rows in another table.

In our system the entities are:

  • Agent
  • Student
  • Teacher
  • Staff
  • Application
  • Result
  • Course
  • Transaction

The relationships among the major entities can be seen in the diagram (Fig. 4). It show the logical structure of the database. We have also introduced cardinality between the data in the diagram.

5.     CRUD Diagram


The CRUD (create, read, update, delete) diagram describe how the will be used by the processes in the system. It shows where in the system the data are created and how it will be accessed on important processes of the system.

Fig. 5 represents the CRUD diagram of our system. It shows the user interaction with use cases of our system. In the diagram, we see that staff has the maximum permission as their accessibility rights. The manager on the other hand, can just read the as he will can only oversee the whole system. The teacher are more involved with course info, timetable, attendance and grading of the system.

6.     Prototype of website design (At least include one form and one report)

 7.1 Student Admission form

This is the Data Science School's Student Admission Form (fig. 6). Signing up this form is the first step of the enrolment process. Three actors can use this form, the agent, the admin and the student/client. This is where the client's personal details, educational background and his/her preferred course will be entered into the system. This form is also able to attach forms and documents. Once the client (or the agent/admin) submitted this form, a notification message will be sent to the admin that a new enrolment form has been created.( Missing home page ??)

 6.2              Payment form

This is the Data Science School Payment Form (fig. 7). This is where the student can pay his or her course fee via debit or credit card. Once the submit button is clicked, automatically the system will generate a receipt and notification. The receipt will be sent to the student's email address that was given on this form while the notification message that a payment has been made will be sent to the Data Science School admin.

The system includes an SSL certificate for added protection and security of the system's data and payment transactions.


7.3       Login form

This is the Data Science School Login Form (fig. 8). This form can be used by the student, admin, trainer, agent and the manager. Each user type has different levels of permissions and user profiles based on their roles. The login credentials of the users are created by the admin.

 7.4       Grades form

This is the Data Science School Grades form (fig. 9). The trainer is the main user of this. He/she is able to create, read, update and delete the marks of the students. The marks will be processed and stored in the database. Students can only view the results once they are available.

7.5       Agent form

This is the Data Science School Agent's form (fig. 10). This can track the students that have been recruited by the agent and their commissions payable to them. The notifications for outstanding balances and deadlines are also included in this form.7.6       Student Dashboard

This is the Data Science School Student Dashboard (fig.11). This dashboard will be used by the student to see the course he/she is enrolled, the payments, grades and various academic performance reports.

 7.     Reflections and Conclusions


The main goal of this project was to create an online management system for Data Science School which can conduct the whole admission procedure online, solves the problem of data duplication, ensures proper availability of data, keep track of the communication with students and with the agents, keeps track of the deadlines.  We solved this problems and at the same times made the system more enriched by taking the course management procedure online. We have also introduced a financial section which keep track of the financial records and where the students can make the payment online. As a result of this, the time spent in each of the admission processes, course management, payment sections will significantly reduce.

When making the initial design for the system, we were surprised at the amount of information that the staffs needed to keep in memory, i.e. deadlines for each course and the payment details. In the payment section the online payment of the salaries of the staffs and teachers was not included as per the user request which may be needed to change in the near future with the growth of the company.