Tribhuvan University

Faculty of Humanities and Social Sciences

A Project Report on

“Student Record Management System”

In partial fulfillment of the requirement for the degree of Bachelor in Computer

Application (BCA)

Submitted to:

Department of Computer Application

Kathmandu College of Technology

Submitted by:

Samyog Subedi (6-2-1105-60-2019)

Diwas Kumar (6-21105-44-2019)

2079/04/16

0
 Tribhuvan University

Faculty of Humanities and Social Sciences

Kathmandu College of Technology

SUPERVISOR’S RECOMMENDATION

I hereby recommend that this project prepared under my supervision by “Samyog Subedi
and Diwas Kumar” entitled “Student Record Management System” in partial fulfilment
of the requirements for the degree of Bachelor of Computer Application is recommended
for the final evaluation

………………….

SIGNATURE

Mr.Prashant Gautam

Supervisor

Kathmandu College of Technology

1
 Tribhuvan University

Faculty of Humanities and Social Sciences

Kathmandu College of Technology

LETTER OF APPROVAL

This is to certify that this project is prepared by “Samyog Subedi and Diwas Kumar”
entitled “Student Record Management System” in partial fulfillment of the requirements
for the degree of Bachelor in Computer Application has been evaluated. In our opinion it
is satisfactory in the scope and quality as a project for the required degree.

………………………………. ……………………………….

Mr.Prashant Gautam Mr.Prashant Gautam

Supervisor Coordinator

………………………………. ……………………………….

Internal Examiner External Examiner

2
 ACKNOWLEDGEMENT

We would like to thank our respected supervisor, Mr. Prashant Gautam, for his guidance,
support, and continuous encouragement throughout the project. We would also like to
extend our sincere thanks to the team at Kathmandu College of Technology's Department
of Bachelor of Computer Application.

We would like to thank everyone who has supported us, helped us, and given us advice
during this time of writing and development of the project. Without them, we never would
have been able to do this.

Samyog Subedi

Diwas Kumar

i
 ABSTRACT

The project automates the student record management system by designing two modules.
One is for the administration and the other is for the students.

The admin side takes care of all activities, such as student registration, uploading notices,
managing student library activities etc. and the student side model helps students receive
notifications and see their personal information along with library activities.

The prototype has been tested with dummy data. It has been observed that the system
successfully registers students, publishes notices, tracks library activities of individual
students, and summarizes the available data.

All the phases of the software development cycle are employed and it is worthwhile to state
that the system is user-friendly and strong. Provision is made for future development in the
system.

Keywords: Students Record Management System, Student Record, SMS

ii
 Table of Contents

ACKNOWLEDGEMENT .................................................................................................... i

ABSTRACT .........................................................................................................................ii

Chapter1: Introduction .................................................................................................... 1

1.1 Background ........................................................................................................... 1

1.2 Problem Statement ................................................................................................ 2

1.3 Objective ............................................................................................................... 2

1.4 Scope and Limitations ........................................................................................... 2

1.4.1 Scopes ............................................................................................................ 3

1.4.2 Limitation ....................................................................................................... 3

1.5 Report organization ............................................................................................... 3

Chapter2: Literature Review........................................................................................... 4

2.1 Literature Review .................................................................................................. 4

Chapter3: System analysis and design ............................................................................ 5

3.1 System analysis ..................................................................................................... 5

3.1.1 Requirement analysis ..................................................................................... 5

3.1.1.1 Functional requirement ........................................................................... 6

3.1.1.2 Non-Functional Requirement ................................................................. 7

3.1.2 Feasibility analysis ......................................................................................... 7

3.1.2.1 Technical feasibility ............................................................................... 8

3.1.2.2 Operational Feasibility ........................................................................... 8

3.1.2.3 Economic Feasibility .............................................................................. 8

3.1.2.4 Schedule feasibility................................................................................. 8

3.2 System Design ....................................................................................................... 9

3.2.1 Data Modeling (ER-Diagram) ....................................................................... 9

iii
 3.2.2 Process Modeling (DFD) ............................................................................. 10

3.2.3 Flow chart .................................................................................................... 11

3.2.4 Architectural Design .................................................................................... 13

3.2.5 Database Schema ......................................................................................... 14

3.2.6 Interface Design (UI Interface / Interface Structure Diagrams) .................. 15

Chapter4: Implementation and Testing ........................................................................ 20

4.1 Implementation.................................................................................................... 20

4.1.1 Tools Used ................................................................................................... 20

4.1.2 Implementation Details of Modules............................................................. 21

4.2 Testing ................................................................................................................. 22

4.2.1 Test Cases for Unit Testing.......................................................................... 23

4.2.2 Test Case for System Testing ...................................................................... 26

Chapter5: Conclusion and Future Recommendation .................................................... 28

5.1 Lesson Learned / Outcome .................................................................................. 28

5.2 Conclusion........................................................................................................... 28

5.3 Future Recommendation ..................................................................................... 28

Chapter6: References .................................................................................................... 29

iv
List of Figures
Figure 3.1 Incremental Development Model ....................................................................... 5
Figure 3.2 Use Case Diagram (SRMS) ................................................................................ 7
Figure 3.3 Gantt chart of SRMS ......................................................................................... 9
Figure 3.4 ER Diagram (SRMS)........................................................................................ 10
Figure 3.5 level 0 DFD ...................................................................................................... 11
Figure 3.6 level1 DFD ....................................................................................................... 11
Figure 3.7 Flow chart of admin module (SRMS) .............................................................. 12
Figure 3.8 Student module flow chart (SRMS) ................................................................. 13
Figure 3.9 architectural design for SRMS ......................................................................... 13
Figure 3.10 Database schema of SRMS ............................................................................ 15
Figure 3.11 Admin Registration page Design (SRMS) ..................................................... 15
Figure 3.12 Admin Login page Design (SRMS) ............................................................... 16
Figure 3.13 Dashboard page Design (SRMS).................................................................... 16
Figure 3.14 Add students Page Design (SRMS) ................................................................ 17
Figure 3.15 Book Issue page Design (SRMS) ................................................................... 17
Figure 3.16 Student registration page Design (SRMS) ..................................................... 18
Figure 3.17 student login page design (SRMS) ................................................................. 18
Figure 3.18 students home page Design (SRMS) .............................................................. 19

v
List of Tables
Table 4.1 Test case for admin registration ......................................................................... 23
Table 4.2 Test case for admin login ................................................................................... 24
Table 4.3 Test case for add student .................................................................................... 24
Table 4.4 Test case for student registration ....................................................................... 24
Table 4.5 test case for student login................................................................................... 26

List of Abbreviations
CSS Cascading Style Sheet

DFD Data Flow Diagram

ER Diagram Entity Relationship Diagram

GUI Graphical User Interface

HTML Hypertext Markup Language

MySQL Structured Query Language

PHP Hypertext preprocessor

SRMS Student Record Management System

vi
 Chapter1: Introduction

1.1 Background
In General overview, any school has more than 1000 students that take different courses. It
is true that the success of any Institute depends on its ability to acquire accurate and timely
data about its operations, to manage this data effectively, and to use it to analyze and guide
its internal daily activities.

Student Database System deals with all kind of student details by tracking all the details of
a student from the day one to the end of his or her course which can be used for all reporting
purpose, tracking of attendance, progress in the course, completed semesters years, coming
semester year curriculum details, exam details, project or any other assignment details, final
exam result; and all these are purposed for future references when interpreting an
organization performance.

The student record management system is responsible for handling student information and
gathering them during enrollment. This information includes each student’s background
information like (Name, Address, Phone-Number, DOB) courses taken by student,
performance record, and other information needed by the Institution

1
1.2 Problem Statement
Many educational institutions are still storing student’s record details locally, where hard
copies of files for every student is kept in office shelves, this seems to be tiresome and
time-consuming in case the registrar is looking of a particular student document.

The problems facing the current manual system are:

• Data redundancy,
• Difficult to update and maintain,
• Inconsistent data,
• Insecurity,
• Difficult to back up.

Due to the inefficiency of the current manual system, the need arises to automate SRMS in
order to efficiently handle students’ Record.

1.3 Objective
➢ To automate students, records.
➢ To make distributed recording system.

1.4 Scope and Limitations

The project was designed in order to provide automation for recording students record. The
educational institutes still use the traditional way of recording student in file-keeping
system. This project emphasizes on providing facilities that are easily accessible to the
users.

2
1.4.1 Scopes
The project provides comprehensive Student Database System for academic
Institute. Student Database System store semester details, course details, department details
and all the details of students including their background information, educational
qualifications and personal detail. Using digital method for record it is easy to update, edit
and delete any student’s information very easily. The information can also be retrieving
which helps in summarizing, analyzing and tracking students report.

1.4.2 Limitation
The project allows adding new students, manipulating information detail, publishing
notices. However, there are some limitation which are listed below:

• Online web Application: The System is only supposed through internet access.
Without the access of the internet user cannot use the protocol system.
• Limited number of courses are added in the system.
• The basic features such as reviews, comments lack in the system.

1.5 Report organization

This report document contains five chapters:

Chapter one: The first chapter describes the introduction of the build system.

Chapter two: Chapter two defines and describe an Overview of related existing systems
and their pros and cons.

Chapter three: Chapter three presents the System Analysis and Design, including
Requirement Analysis and Feasibility Analysis.

Chapter four: chapter four includes the process of implementation, Testing and
Debugging.

Chapter five: Chapter five includes Conclusion, Limitations and Future Enhancement

3
 Chapter2: Literature Review

2.1 Literature Review

Different article, documentation, and project have been referred related to student record
management system, optimization etc. in the preparation of this report. A short summary
of these report sources is mentioned below:

Student record management systems (SRMS) are part of the larger field of information
systems (IS) and have a lengthy history. Broadly defined, an SRMS is “a general
information system for maintaining and providing student information, and it almost exists
in all the schools, colleges, universities, and any other education institutions”.

The availability of services is at the core of every system's efficiency, because users
frequently evaluate the overall system performance based on their satisfaction with such
services. Almost every online student management system offers a variety of options to
fulfill the demands and expectations of its users. For example, according to Maree (2011),
the SRMS is responsible for student administration, which includes admission Record,
students’ personal records, examination, notice, finance, room assignment, and
examination results feedback. As a result, it is likely that most institutions of higher
learning will develop in-house online student management systems to aid in student
registration, online profiling, financial recording, examination grade records, transcript
generation, and maintaining student records. [1]

Student Management (SMS) software has several advantages. SMSs serve both the
administration and the students at most colleges. To the university administration, the SMS
handles the majority of critical administrative tasks such as admissions, enrollment, and
examinations. Students may now register for new semesters and access their academic and
biographic data via internet-enabled devices like as cellphones and PCs, thanks to the
development of online student information systems in recent years. Students are given a
new platform to not only learn knowledge, but also to express it. The main advantages of
SMSs for students is that they can access information regarding class and test schedules,
school activities, and holidays round the clock. [1]

4
 Chapter3: System analysis and design

3.1 System analysis

Considering the fact that this project involves design and implementation of a software
system regardless that is web-based, it was necessary to mention and consider certain
models used in software development and deployment. For this project, we are using an
incremental model.

Incremental Model is a process of software development where requirements divided into

multiple standalone modules of the software development cycle. In this model, each
module goes through the requirements, design, implementation and testing phases. Every
subsequent release of the module adds function to the previous release. The process
continues until the complete system achieved.

Figure 3.1 Incremental Development Model

3.1.1 Requirement analysis

Requirements analysis is a crucial step for determining the success of a system or software
project. Requirements are generally split into two types:

5
 1) Functional requirements
2) Non-functional requirements

3.1.1.1 Functional requirement

This section provides the requirement overview of the system. Various modules
implemented by the system are:

• Administration module.
➢ Administration will be able to add new students.
➢ Administration will be able to modify students as well as organization details.
➢ Multi organization login.
➢ Administration will be able to publish notices.
➢ Administration will be able to modify or delete notices in case needed.
➢ Administration will be able to record issued books to individual students.
• Student Module
➢ Students will be able to preview their personal information.
➢ Students can be able to see notices published by their institutions.
➢ Students can be able to see their library activities.

• Login module
➢ Only registered user can log in the system.
➢ It ensures security to the system.
➢ It helps to authenticate the users.
➢ Only validate email and password is used to log in the system.

6
 • Use case diagram

Figure 3.2 Use Case Diagram (SRMS)

3.1.1.2 Non-Functional Requirement

Non-functional requirements of the system are identified as availability, security
performance, reliability. The non-functional requirements included in the project are:

1) Availability
Since the developed system is web-based so, the system will be available online.
2) Security
Since users first have to register themselves and login using registered information.
Login with incorrect information does not let users be logged in. It is a multivendor
application, so only information of the particular registered institute is shown. So,
there is proper provision of security.
3) Performance
This system will be designed for smooth performance with optimization and good
response.
4) Reliability
Since the system has proper provision of security and reliability, the system will be
reliable to the users.

3.1.2 Feasibility analysis

The feasibility analysis includes Technical feasibility, Operational feasibility, Economic
feasibility, Schedule feasibility.

7
3.1.2.1 Technical feasibility
The technologies and development tools that has been intended to use are all readily
available and are open source. Furthermore, team members have sufficient fundamental
knowledge of design and programming patterns. We should be able to improvise, adapt and
overcome challenges that may arise during development of the system.

3.1.2.2 Operational Feasibility

The application is platform independent and can run on any web enabled device. The
backend of the system needs a JavaScript and PHP environment with MySQL connection,
but the one-time setup is minimal and can be achieved in any host environment.

3.1.2.3 Economic Feasibility

There is no major cost associated with the development of the system. The system does
need a server with MYSQL environment which is open and free so it is expected to be
economically feasible to any institution looking to implement a system like this. Also, the
manpower required for management of the databases and moderation of content is quite
low which helps in minimizing the production cost.

3.1.2.4 Schedule feasibility

Since this project is to be submitted before our board exams, which is very good as our
college activities are passive, time should not be a problem.

The working scheduled of our project is described in the following GANTT chart.

GANTT CHARTS

A Gantt chart is a form of bar chart that shows the progress of a project. A Gantt chart,
which is widely used in project management, is one of the most popular and useful methods
for displaying activities against time. It can also be used to examine a project's start and
finish dates in a single graph. Gantt's charts were created in our project using Microsoft
Excel, as seen in the picture below.

8
 Figure 3.3 Gantt chart of SRMS

3.2 System Design

System design is the process of defining the components, modules, interfaces, and data for
a system to satisfy specified requirements. System development is the process of creating
or altering systems, along with the processes, practices, models, and methodologies used
to develop them.

The system design used while developing this “student record management system’’ are
briefly described and designed below:

3.2.1 Data Modeling (ER-Diagram)

This ER (Entity Relationship) diagram represents the model of “student record
management system”. The entity-relationship diagram of SRMS shows as all the visual
instrument of database tables and the relations between Admin, Users, and list of activities.
It used structure data and to define the relationships between structured data groups of
SRMS functionalities. The database system contains user and account entities which
contain a primary key as a unique identifier for each entity and other attribute to show the
properties of these entities.

9
 Figure 3.4 ER Diagram (SRMS)

3.2.2 Process Modeling (DFD)

A context diagram is drawn in order to define and clarify the boundaries of the software
system. The student record management system context diagram, sometimes called a level
0 data-flow diagram, identifies the flows of information between the system and external
entities. Here the external entities are the students are who visit the student record
management system to either create an account by filling a registration form or login to the
system and perform transaction. The system module is where the admin will manage and
update students and the system and provide relevant information to students. The system
context diagram shows how student and admin interact with other in student record
management system.

10
 Figure 3.5 level 0 DFD

Figure 3.6 level1 DFD

3.2.3 Flow chart

A flowchart is a diagrammatic representation of an algorithm. A flowchart can be helpful
for both writing programs and explaining the program to others. In the developed student
record management system, the module is different for admin and students where data
flows as:

11
Figure 3.7 Flow chart of admin module (SRMS)

12
 Figure 3.8 Student module flow chart (SRMS)

3.2.4 Architectural Design

Figure 3.9 architectural design for SRMS

13
3.2.5 Database Schema
Database schema of this developed system contains four logical schemas such as admin,
students, library and notice, and it contains different fields, views and integrity constrains.
Student logical schema have field like registration number, name, address, email, course,
enroll year, image, organization name and table name which defines all the logical
constraints that need to be applied on data stored in physical schema. Similarly, admin
logical schema is the administration of the system which have created an account through
registration system where it has field like name, email, password, confirm password, and
image. Admin can perform operation such as adding students, manipulating data.
Similarly, library logical schema has field like ID, registration number, student name, book
name, ISBN, issue date and return date. Similarly, notice logical schema have field like ID,
notice title, description, time. Admin of the system can access the whole database and can
manage the students, library and notice of the logical schema students are linked with both
library and admin using foreign key and ID of each schema present in proposed system is
primary and unique.

14
 Figure 3.10 Database schema of SRMS

3.2.6 Interface Design (UI Interface / Interface Structure Diagrams)

The aim of UI is to provide smooth, effective and efficient eye appealing and smooth
transaction between pages. Some main user interface design of the developed project are
shown below:

Figure 3.11 Admin Registration page Design (SRMS)

15
Figure 3.12 Admin Login page Design (SRMS)

Figure 3.13 Dashboard page Design (SRMS)

16
Figure 3.14 Add students Page Design (SRMS)

Figure 3.15 Book Issue page Design (SRMS)

17
Figure 3.16 Student registration page Design (SRMS)

Figure 3.17 student login page design (SRMS)

18
Figure 3.18 students home page Design (SRMS)

19
 Chapter4: Implementation and Testing

4.1 Implementation

In the first phase, data were collected. Data collection took longer time than other phase. It
was the critical stage in the project's development. All the physical design of the project is
turned into working computer code. Many tools and technologies that were utilized to
develop the system were discussed in the preceding chapter.

4.1.1 Tools Used

• Front-end: Bootstrap, HTML5, CSS3, and JavaScript.

1. HTML5
(Hyper Text Markup Language) HTML is used for structuring webpage design in
our project, and it provides us with overall skeleton structure of webpage. HTML
is the main presentation language of our project because it helps us to show the
structure of our page in the browser, which helps us to debug easily and efficiently.
2. CSS3
(Cascading Style Sheets) CSS is used to style the HTML document in our project.
It is used to make our webpages responsive however bootstrap is used to make our
webpages responsive.
3. JavaScript
JavaScript is used to make our webpages interactive and many JavaScript functions
such as dialogue box is used in this project to make webpages interactive and user-
friendly.
4. Bootstrap
Bootstrap is the most popular HTML, CSS, and JavaScript framework for
developing responsive, mobile-first websites.

20
 • Backend: PHP, MySQL and XAMPP
1. PHP
It is used to develop dynamic and interactive webpages.
2. MySQL
It is mainly used for the purpose of database.
3. XAMPP
XAAMP is used for local server and database to fulfill the need of the project and
Apache and MySQL is used as local server and database.

4.1.2 Implementation Details of Modules

The proposed system is composed of different module such as student module, admin
module, login module, book issue detail module, remove user or delete user module. The
individual modules are briefly described below.

• Student Module
In student module account is created by filling the form detail which includes the
field like registration number (provided by educational institution), email address
(linked with respective educational institution), password, confirm password. If
students enter already registered email and registration number, then student cannot
register themselves twice. While filling the input field, user must fill the all data in
the input field so that it would not throw an error message. Student data is stored in
the database after filling correct details in the registration form while creating an
account. After successfully creating an account, the student can log in to the system.
• Admin Module
In Admin Module authentication is done using email and password given to the
admin if admin enter correct email and password then admin can access to his
dashboard. Admin manage students in the system and in admin module contains
home page or dashboard in which admin can manage students by clicking in the
student detail list present in the admin dashboard and admin can log out of the
system by clicking logout button in the admin dashboard.

21
 • Login Module
In the Login Module, a user can log in to the system after successfully creating an
account. Login module consist of two fields (in admin side) and three fields (in
students’ side) such as email field and password field and registration number field
(in case of students). A user is only logged in to the system when the email and
password entered by the user is matched with database email and password. In this
module, user can log in through email and password. User must enter correct email
and password to login into the system. If user enter wrong email and password, then
it throws an error message and in order to login in the system, user must enter
correct email and password.
• Delete user Module
In Delete User Module students can be removed from the existing system and this
module is performed by admin only and in this module admin login into the admin
dashboard by admin login details and in admin home page admin can remove the
students by clicking into the students list where admin can access all the students
present in the database and remove the user from the existing system. Only admin
can access this module.

4.2 Testing
On the basis of the software requirement specification document, testing was performed to
investigate and validate the behavior of a fully integrated software product. Before
deploying an application or website, it must be thoroughly tested. As a result, this
application's test cases were written. Some types of testing that we did are described below.

22
4.2.1 Test Cases for Unit Testing
Table 4.1 Test case for admin registration

ID Test Case Test Data Expected Result Actual Pass/

Description Result Fail
A_REG User do not Name: xyz Display message As Pass
_1 match Email: [email protected] Passwords do not expected
passwords Password:12345699 match

ConfirmPassword:123456
Logo: logo1.png
A_REG User try to Name: xyz Display message As Pass
_2 register wit Email: email already exist expected
already [email protected]
registered Password:123456
email ConfirmPassword:123456
Logo: logo1.png
A_REG User forgets Name: Display message As Pass
_3 to enter a Email: Name required expected
particular [email protected]
required field Password:123456
ConfirmPassword:123456
Logo: logo1.png
A_REG User try to Name: xyz Display message As Pass
_4 register Email: Please select a file expected
without [email protected]
uploading Password:123456
image ConfirmPassword:123456
Logo:

23
 Table 4.2 Test case for admin login

ID Test Case Test Data Expected Actual Pass/Fail

Description Result Result

A_LOG Admin email:[email protected] Display As Pass

_1 message expected
enters a wrong password: 123456
**Email Not ,

email Registered
Yet**

A_LOG Admin email: Display As Pass

_2 message expected
enters a wrong [email protected]
**Incorrect ,

password password: hfgkjhjkf Password**

A_LOG Admin email: Logged into As Pass

_3 [email protected] admin expected
enters
password: 123456 dashboard ,
correct email
page
and password
Table 4.3 Test case for add student

ID Test Case Test Data Expected Result Actual Pass/

Description Result Fail
ADD_S Admin forget to All data Display message As pass
_1 enter a particular empty Please fill out this expected
required field field
Admin assign 123(which Display message As pass
ADD_S registration that is has been Registration Number expected
_2 already been already Already in Use
assigned assigned)
Table 4.4 Test case for student registration

24
ID Test Case Test Data Expected Result Actual Pass/Fa
Description Result il
S_REG User selects Registration:127 Display message ** As Pass
_1 already Email: Looks Like You Have expected,
existing email [email protected] Already Register**
and Password:123456
registration ConfirmPassword:1
23456
S_REG User enters all Registration:123456 Redirect to Login Page As Pass
_2 the details Email: expected,
successfully [email protected]
Password:123456
ConfirmPassword:
123456
S_REG User forgets Registration:123456 Display message As Pass
_3 to enter a Email: **All Fields Need to be expected,
particular Password:123456 Filled**
required field ConfirmPassword:
123456
S_REG User did not Registration:123 Display message As pass
_4 match Email: **Password and expected,
password and [email protected] Confirm Password Do
confirm Password:1234567 Not Match **
password ConfirmPassword:1
23456

25
 Table 4.5 test case for student login

ID Test Case Test Data Expected Actual Pass/Fail

Description Result Result
S_LOG User enters a email: [email protected] Display As Pass
_1 wrong registration:127 message expected,
email id password: 123456 **Incorrect
Registration
Number**
S_LOG User enters a email: Display As
_2 wrong [email protected] **Incorrect expected,
registration registration:1299 Registration

number password: 123456 Number**

S_LOG User enters a email: Display As Pass

_3 wrong [email protected] message expected,
password registration:127 **Password
password: jigjigs Incorrect**

S_LOG User enters email: User logs As Pass

_4 correct [email protected] in expected,
username registration:127 successfully
registration password: 123456
number and
password

4.2.2 Test Case for System Testing

Check system behavior,
➢ If the site launches properly with all the relevant pages, features and logo.

➢ If the user can register/login to the site.

26
➢ If the main features, such as adding students, manipulating data, analyzing
data in pie chart, deleting particular student, editing admin detail like logo,
name, password function as expected.

➢ If the site works properly in the newest versions of all major browsers.
➢ If the content of pages is properly aligned, well managed and without
spelling mistakes.
➢ If session is working as expected.

➢ If a user is satisfied with the site after utilizing it, or if the user does not
find it difficult to utilize it.

➢ If dropdown menu, Menu Bar icon works smoothly and properly or not.

27
 Chapter5: Conclusion and Future Recommendation

5.1 Lesson Learned / Outcome

with the completion of the project, it was possible to achieve the project's goal. After filling
the register form, user can view and perform different actions online through web browser.
In this way, user can save time and perform managing student from this website.

5.2 Conclusion
An educational institution has to keep and maintain record of numerous students for long
period of time. Traditionally, if records are maintained in files they are very difficult to
maintain for long period of time and searching for particular information is time-consuming
but with help of developed system it is made automated. Student record management is
successfully implemented using HTML5, CSS3, JavaScript, Bootstrap, PHP which are
open source and freely available on internet, and it successfully solves the problem of
traditional record keeping system. The proposed system is useful for people with minimal
IT knowledge with the use of internet. Towards the end of the project, it was discovered
that the application might benefit from a number of improvements. Some of these
suggestions came from the app's testers, while others came from both of us. Any more
enhancements to the application can be made during future development.

5.3 Future Recommendation

There are many things that can be added in future to improve this website such as user
experience, and portability. There is more to be done, thus this application can be seen of
as a launching pad for something bigger to come. All of them will need more time and
resources to complete, but they are still highly realistic and achievable goals.
➢ Addition of dark themes,
➢ Making a good user profile,
➢ Greater user experience,
➢ Add forget password options.
➢ Add student’s attendance report along with exam report

28
 Chapter6: References

[1] Symon C. Lubanga ,Felix Majawa ,Winner Dominic Chawinga,Sellina Kapondera,

"Web based student information management system in universities".

[2] "Bcanotesnepal," 7 February 2021. [Online]. Available:

https://bcanotesnepal.com/bca-fourth-semester-project-sample-fot-project-i-bca-tu/.
[Accessed March 2022].

[3] I. Sommerville, Software engineering, vol. ninth edition, Pearson, 2011.

[4] U. Winnefred, "Student Academic Information System," 2011.

29