EXAM CELL AUTOMATION SYSTEM

Project ID- 10

Project Advisor: Mr. Adil Shan

Submitted By

Muhammad Asim ID of Student

Muhammad Aqib ID of Student

University of Education
 EXAM CELL AUTOMATION SYSTEM

BS in Information
Technology-2024

A project submitted in partial fulfillment

of the requirements for the award of the
degree of BS in information Technology

MUHAMMAD ALI
INSTITUTE OF SCIENCE
AND TECHNOLOGY
LAYYAH

AFFILETED WITH
UNIVERSITY OF
EDUCATION LAHORE

August 2024
“I hereby declare that I have read this project documentation and in my opinion this project is sufficient
in terms of scope and quality for the award of the degree of BS in Information Technology.”

Project Primary Supervisor Project Examiner

Mr. Muhammad Arshad Name:

Lecturer Designation

Muhammad Ali Institute of Science University of Education Lahore

And Technology Layyah

 DECLARATION
I declare that this project title entitled “write your project title here” is the result of my own
research and development except as cited in the references. This project has not been accepted
for any degree and is not concurrently submitted in candidate for any other degree. At any time if
my statement is found to be incorrect even afterwards of BS in Information Technology, the
university has the right to withdraw my BS in Information Technology degree.

Signature: Signature:

Name: Name:

Date: Date:
 PLAGIARISM UNDERTAKEN

I solemnly declare that project work presented in this documentation

entitles “Name of your project” is solely my work with no significant
contribution from any other person. Small contribution/help wherever
taken has been acknowledged and that complete project has been
written by me.

I understand that zero tolerance policy of the HEC and University of

Education, Lahore towards plagiarism. Therefore, we as an author of
the above titled project declare that no portion of my project
documentation and any material used as reference is properly referred/
cited.

I undertake that of I am found guilty of any formal plagiarism in the

above titled project even after award of BS/MSc degree, the
University reserve the rights to withdraw/revoke my BS/MSc degree
and that HEC and the University has the right to publish my name on
the HEC/University Website on which names of students are place
who submitted plagiarized projects.

Signature: Signature:

Name: Name:

Date: Date:
 CERTIFICATE OF APPROVAL

This is to certify that the project work presented in this documentation

entitled, “write name of your project”, was conducted by “name of
member 1”, “name of member 2”, “name of member 3”, “name of
member 4”, under the supervision of “write your supervisor name”.
No part of this project has been submitted anywhere else for any
degree. This project is submitted to the “name of your campus,
University of Education” is partial fulfillment of the requirements of
the degree of BS in Information Technology/MSc in Information
Technology.

Signature: Signature:

Name: Name:

Date: Date:

Project Primary Supervisor Project Examiner

Mr. Adil Shan Name:

Lecturer Designation

Muhammad Ali Institute of Science University of Education Lahore

And Technology Layyah

 OFFICE OF CONTROLLER OF EXAMINATION

NOTIFICATION

No: Date:

It is notified for the nomination of all the concerned that Mr./Ms. (name of
the student-1), (name of the student-2), (name of the student-1), (name of
the student-1) BS/MSc student of Name of the department of University of
Education has completed all the requirements for the award of BS/MSc
Degree in the discipline of Information Technology as per detail given
hereunder:

BS in Information Technology/ Cumulative Result

MSC in Information Technology Credit Hours: Cumulative
Grade Point
Registration No Complete Name Course work Project Total
Average
(CGPA)

Project Title: Online Quiz and Evaluation System

Name of Supervisor: Mr.Adil Shan

Signed by
Controller of
Examination

CC:
1. abcd
2. xyz3

ACKNOWLEDGEMENT

We truly acknowledge the cooperation and help make by Name of

Acknowledger, Designation of Address of Organization. He has
been a constant source of guidance throughout the course of this
project. We would also like to thank Acknowledger from
Designation, Address of Organization for his help and guidance
throughout this project. We are also thankful to our friends and
families whose silent support led us to complete our project.

1- Mr. Furqan
2- Mr. Akram

Date:
March 11, 2016
 ABSTRACT

Examination is a core activity of any educational institution. As the examination arrives there
exists a lot of work like consolidating the timetable, seating arrangement, and invigilation
allotment which will be done manually it takes a lot of time, and requires manpower. Thus, an
automated system would solve the above stated problem in just few clicks of work. The purpose
of developing an Examination Management Automation System is to computerize the traditional
way of conducting exams. It is a web and android application that can be used by students and
exam cell coordinator using their smart phones or PCs. The project keeps track of various details
in modules such as Students Details, Staff Details, and Hall Details with proper descriptions. It
also has some features to generate reports for bundle handovers, absentee’s statements and roll
lists. The exam Cell Automation System is developed for the college or institute to computerize
the traditional way of conducting exams and to simplify examination hall allotment and seating
arrangement. Also, automating the timetable generating process will help get rid of various
anomalies caused due to human error. Mostly staff faces many problems in assigning exam halls
depending upon the availability of classes, capacity of classes, student details, allotment of duties
to the respective teachers, etc. And the manual system of preparing time table in colleges is very
time consuming and usually ends up with various classes clashing either at same room or with
same teachers having more than one class at a time. To overcome all these problems, an
automated system is proposed. -
Contents
CHAPTER NO 1: Information Gathering............................................................................................xiii
1.1. Introduction.................................................................................................................................xiii
1.2 PURPOSE.......................................................................................................................................xv
1.2.1 Disadvantages of the current system:........................................................................................xv
1.2.2 Advantages over the current system:.........................................................................................xv
1.3 Problem Statement.........................................................................................................................xv
1.4 Objective........................................................................................................................................xvi
1.5 Methodology.....................................................................................................................................xvii
1.5.1 Existing Methodologies............................................................................................................xviii
1.5.2 Waterfall Model......................................................................................................................xviii
1.5.1.1 Requirement Analyses and Definition....................................................................................xx
1.5.1.2. System and software Design:................................................................................................xx
1.5.1.3. Implementation and testing:..................................................................................................xx
1.5.1.4. Integration and system testing:.............................................................................................xxi
1.5.1.5. Operations and Maintenance:...............................................................................................xxi
1.5.2 Incremental Models.................................................................................................................xxii
1.5.3 Spiral Model...........................................................................................................................xxiv
1.6. Adopted Methodology....................................................................................................................xxvi
1.6.1. Reasons for choosing the Methodology................................................................................xxvii
CHAPTER NO 2: Software Requirement Specification...................................................................xxviii
2.1. Functional Requirement...............................................................................................................xxviii
2.2 Non- Functional Requirement........................................................................................................xxix
2.3 Tools and Techniques........................................................................................................................xxx
2.3.1 PHP.........................................................................................................................................xxx
2.3.2 Xampp.....................................................................................................................................xxxi
2..3.3 MYSQL...................................................................................................................................xxxii
2.3.4 HTML.....................................................................................................................................xxxii
2.3.5 Bootstrap...............................................................................................................................xxxii
2.3.6 Java Script.............................................................................................................................xxxiii
2.3.7 Sublime Text..........................................................................................................................xxxiii
2.3.8 CSS........................................................................................................................................xxxiii
CHAPTER NO 3: Analysis.................................................................................................................xxxiv
3.1 Use Cases for Online Exam Cell Automation System..............................................................xxxiv
3.2 . Actors........................................................................................................................................xxxiv
3.4. Detailed Use Case Examples....................................................................................................xxxvi
CHAPTER NO 4: Design..................................................................................................................xxxviii
4.2. Entity-Relationship Diagram (ERD).......................................................................................xxxix
4.3. Data Flow Diagram (DFD)...........................................................................................................xli
4.4. Class Diagram..............................................................................................................................xliii
4. 5. Sequence Diagram......................................................................................................................xliv
Visual Representation........................................................................................................................xlv
CHAPTER NO 5: Graphical user Interface........................................................................................xlvi
5.1 Login Page....................................................................................................................................xlvi
5.2 Dashboard....................................................................................................................................xlvii
5.3 Teacher Module...........................................................................................................................xlvii
5.3.1 View Teacher.........................................................................................................................xlviii
5.4 Add Student................................................................................................................................xlviii
5.4.1 View Student...........................................................................................................................xlix
5.5 Subject Management....................................................................................................................xlix
5.5.1 View Subject................................................................................................................................l
5.6 Class Management............................................................................................................................l
5.6.1 View Class.................................................................................................................................li
5.7 Exam Management........................................................................................................................li
CHAPTER NO 6: Test Cases...................................................................................................................lii
6.1 Test Scenario.......................................................................................................................................lii
6.2 Test Plan...........................................................................................................................................lii
CHAPTER NO 7: Conclusion and Future work...................................................................................lv
Future Work........................................................................................................................................lv
List of Images
Figur.Error! Use the Home tab to apply 0 to the text that you want to appear here..1.2 Waterfall
Model 2.....................................................................................................................................................xxi
Figure 1.Error! Use the Home tab to apply 0 to the text that you want to appear here..2 Incremental
Model......................................................................................................................................................xxiii
Figure1.3 Stages of Incremental Model...................................................................................................xxiv
Figure 1.4 Spiral Model.............................................................................................................................xxv
Figure 1..5 Full Version of Spiral Model...................................................................................................xxvi

Figure 4 1 Architecture design...............................................................................................................xxxix

Figure 4. 2 ERD............................................................................................................................................xl
Figure 4 3 Data Flow Diagram...................................................................................................................xlii
Figure 4 4 Class Diagram..........................................................................................................................xliii
Figure 4 5 Use Case...................................................................................................................................xlv

Figure 5. 1 Login page...............................................................................................................................xlvi

Figure 5. 2 Admin Dashboard..................................................................................................................xlvii
Figure 5. 3 Add Teacher...........................................................................................................................xlvii
Figure 5. 4 View Teacher.........................................................................................................................xlviii
Figure 5. 5 Add Students........................................................................................................................xlviii
Figure 5. 6 View Students.........................................................................................................................xlix
Figure 5. 7 Add Subject.............................................................................................................................xlix
Figure 5. 8 View Subject...............................................................................................................................l
Figure 5. 9 Add class.....................................................................................................................................l
Figure 5. 10 View Classes.............................................................................................................................li
Figure 5. 11 Exam Report.............................................................................................................................li

List Of Table

Table 2. 1 Functional Requirement...........................................................................................................xxx

Table 2. 2 Non-Functional Requirement..................................................................................................xxxi
CHAPTER NO 1: Information Gathering
1.1. Introduction
The proposed system is an android and web based application that is designed to manage and
handle the operations in an educational institute during the time examinations. It is an application
that can be used by all the students and staff in an educational institute in order to facilitate the
communication between them. The application is easily adaptable as it is used on a desktop
systems and mobile device. Since the developed application is used on a mobile devices, it
improves connectivity between the users, thus helping the institution to provide a more
transparent system altogether. The Examination Management Automation System was developed
for the educational institute to simplify the allocation of halls, seating arrangement of students
and allocating staff to the examination halls. Allocation of faculty to corresponding rooms will be
done by the exam cell coordinator in the form of word documents and excel sheets and also
allocation of students to their corresponding rooms is a frantic work which will be done
manually and it takes lot of time and requires man power. The project keeps track of various
details in modules such as Students Details, Staff Details, and Hall Details with proper
descriptions. Most of the important processes in an educational institute are carried out manually
such as teaching and nonteaching staff details, student information and number of halls available
for the examination as all these process is done manually it increase the work load and easily
prone to errors. The current systems are traditional systems which support manual processes
leading to an immense time consumption and pile of hard copies. Existing system is inefficient,
ineffective and less accurate, in such a situations report generation is not an simple task also if
report is generated calculations has to be done manually which will surely results in errors.

In the contemporary educational landscape, the efficiency and effectiveness of administrative

processes play a crucial role in ensuring smooth academic operations. One such critical aspect is
the management of examination-related activities. Traditionally, exam cell management has
involved a significant amount of manual work, including scheduling exams, allocating
invigilators, handling student queries, and processing results. These tasks are not only time-
consuming but also prone to human errors, which can lead to inaccuracies and delays.
The advent of technology presents an opportunity to revolutionize these administrative processes
through automation. An Exam Cell Automation System (ECAS) is designed to streamline and
enhance the efficiency of examination management. This system leverages the power of software
to automate various functions such as exam scheduling, invigilator allocation, result processing,
and student query handling. By reducing the dependency on manual interventions, an ECAS
ensures higher accuracy, faster processing times, and improved overall management of
examination activities.

1.2 PURPOSE
The purpose of developing the Examination Management Automation System is to
automate the regular way of organizing the examinations in an educational institute and
generating reports according to the examination type and time.

1.2.1 Disadvantages of the current system:

 Takes a lot of time.
 Resembles a complex problem while allocating faculty to different rooms.
 Less Accurate.
 Requires more manual work.
 Paper work required.
 Previous records not stored.

1.2.2 Advantages over the current system:

 Easy to handle and operate.
 Friendly interface.
 Fast and convenient.
 Less human effort.
 Easy to update.
 Easy message passing.
 Smart way of communication
 No paperwork required.
1.3 Problem Statement

The management of examination processes within educational institutions is a complex and

labor-intensive task. Traditional methods involve extensive manual work, including the
scheduling of exams, allocation of invigilators, distribution of exam materials, handling of
student inquiries, and processing and dissemination of results. These manual processes are
fraught with several challenges:

 Time-Consuming Procedures: Manual scheduling and allocation tasks require

considerable time and effort from administrative staff, often leading to delays and
inefficiencies.
 Human Errors: The reliance on manual input increases the risk of errors in scheduling,
invigilation assignments, and result processing, which can result in inaccuracies and
necessitate additional time for corrections.
 Inefficient Resource Management: Ineffective allocation of resources, such as
invigilators and exam venues, can lead to underutilization or overcrowding, impacting the
overall examination environment.
 Lack of Transparency and Tracking: The absence of a centralized system makes it
difficult to track the progress of various examination-related activities, resulting in poor
transparency and accountability.
 Inconsistent Communication: Communication between students, faculty, and
administrative staff regarding exam schedules, venues, and results is often inconsistent
and unreliable, causing confusion and frustration.
 Data Management Issues: Managing large volumes of data manually, including student
records, exam schedules, and results, is prone to data loss and security breaches.

1.4 Objective

The primary objective of the Exam Cell Automation System (ECAS) is to enhance the
efficiency, accuracy, and transparency of examination management processes within educational
institutions. By leveraging automation, ECAS aims to streamline various exam-related tasks,
thereby reducing manual intervention and the associated risks of errors and delays. The specific
objectives of the system are as follows:
 Automate Exam Scheduling: Develop a system that automatically schedules exams,
considering factors such as available time slots, exam venues, and the availability of
invigilators, to optimize resource utilization and minimize scheduling conflicts.
 Efficient Invigilator Allocation: Create an automated process for assigning invigilators
to exams, ensuring fair and balanced distribution of duties while taking into account
individual preferences and availability.
 Streamline Result Processing: Implement a robust mechanism for the automated
processing, verification, and dissemination of exam results, ensuring accuracy and
reducing the time taken to publish results.
 Enhance Communication: Facilitate seamless communication between students,
faculty, and administrative staff regarding exam schedules, venues, and results through
automated notifications and updates.
 Improve Data Management: Establish a centralized database to store and manage all
exam-related data securely, enabling easy access, retrieval, and analysis of information
while ensuring data integrity and confidentiality.
 Increase Transparency and Accountability: Provide real-time tracking and monitoring
of examination activities, enhancing transparency and accountability in the management
of exams.
 Minimize Human Errors: Reduce the dependency on manual processes to minimize the
risk of human errors in scheduling, invigilation, and result processing, thereby improving
the overall reliability of the examination system.
 Optimize Resource Utilization: Ensure efficient utilization of available resources,
including exam venues and personnel, to avoid underutilization or overcrowding and to
create an optimal examination environment.
1.5 Methodology
In software engineering, various methodologies can be adopted to manage and execute projects
efficiently. For the "Online Exam Cell Automation System," it is essential to choose a
methodology that ensures a structured approach, facilitates collaboration, and provides flexibility
to adapt to changes.

1.5.1 Existing Methodologies

Several methodologies are commonly used in software development:

1.5.2 Waterfall Model

The first published model of the software development process was derived from other
engineering processes. Because of the cascade from one phase to another, this model is known as
the waterfall model. This model is also known as linear sequential model. The Waterfall Model
is a software development life cycle (SDLC) model. An SDLC model is a general software
development framework or methodology which fol-
lows a specific set of steps in a specific order. For example, in this methodology, the
development process is divided into different phases, and a developer can only proceed to the
next phase when the current phase is complete. The phases do not overlap, making development
flow sequentially. Due to this, the Waterfall Model is referred to as a linear-sequential life cycle
model. Progress moves downward in the Waterfall Model, evoking the feeling of a waterfall.
The water in a waterfall does not go back up; it plummets down toward the earth. The Waterfall
Model is similar in that once the cycle starts, the developer has to continue until reaching the
end; one cannot go back or flow upwards to return to previous phases. The only way one can go
back to a previous phase is by starting the development cycle over again. There are slight
variations of the Waterfall Model’s phases. However, the general consensus is that there are six
phases. The first phase is Requirement Analysis.
During this phase, the requirements of the project are discussed with the client. All
requirements are analyzed in order to determine if there are any vague or inconsistent
requirements. These issues are then discussed with the client, who agrees upon a solution with
the development team. Once the requirements are finalized, the requirements for the system are
noted in a software requirement specification (SRS) document. This formal documentation
serves as an agreement between the team and the client, outlining the official specifications of
the project.
The second phase is System Design. The development team utilizes the SRS document and
analyzes it to create a design that fulfills all of the client’s requirements. This phase involves
designing the software and specifying the hardware used to develop the system. The third phase
is Implementation. The software that follows the design for- mulated in the previous phase is
created at this time. Once the Implementation phase is complete, the fourth phase begins, which
is
Testing. There are various tests that can be performed on the newly-created software.
Some of the common tests for software include unit testing, integration testing, and
acceptance testing. Unit tests are done for each block of code with unique functionality in the
system. Integration tests combines the individual functionalities and tests the system as a whole.
Acceptance testing is done by the client. During this process, the client performs the final tests
and decides to accept or reject the software. If the software is rejected, the team will have to
restart the Waterfall Model at the first phase and make changes to the software requirements.
The fifth phase is Deployment. The software product is released into the real world according to
the client’s release requirements. For example, the software could
be released for the client’s company to use only, or it could be released on the internet, under the
name of the client’s company.
The sixth and final phase is Maintenance. After deploying the software, there
are potential changes that will need to be made. Once the updates are complete, the
new software is then released once more. There are different types of maintenance that can be
done on the software. The three main types of maintenance are corrective main- tenance,
perfective maintenance, and adaptive maintenance. Corrective maintenance is done to correct
issues that were not discovered during testing. Perfective maintenance
is maintenance that enhances the existing functionalities of the product. Adaptive
maintenance occurs if the software needs to be moved to a new environment.
 Figure 1.1 Waterfall Model 1

1.5.1.1 Requirement Analyses and Definition

The systems services, constraints and goals are established by consultation with system users.
They are then defined in detail and serve as a system specification.

1.5.1.2. System and software Design:

System design process partitions the requirements to either hardware or software systems. It
establishes and overall system architecture. Software design involves fundamental system
abstractions and their relationships.

1.5.1.3. Implementation and testing:

During this stage the software design is realized as a set of programs or program units. Unit
testing involves verifying that each unit meets its specifications.

1.5.1.4. Integration and system testing:

The individual program unit or programs are integrated and tested as a complete system to
ensure that the software requirements have been met. After testing, the software system is
delivered to the customer.

1.5.1.5. Operations and Maintenance:

Normally this is the longest phase of the software life cycle. The system is installed and put into
practical use. Maintenance involves correcting errors, which were not discovered in earlier stages
of the life cycle, services as new requirements are discovered.

Real projects rarely follow the sequential flow that the model proposes. In general these phases
overlap and feed information to each other. Hence there should be an element of iteration and
feedback.

A mistake caught any stage should be referred back to the source and all the subsequent stages
need to be revisited and corresponding documents should be updated accordingly. This feedback
path is shown in the following diagram.

Figur.Error! Use the Home tab to apply 0 to the text that you want to appear here..1.2 Waterfall Model 2
Because of the costs of producing and approving documents, iterations are costly and require
significant rework.

The Waterfall Model is a documentation-driven model. It therefore generates complete and

comprehensive documentation and hence makes the maintenance task much easier. It however
suffers from the fact that the client feedback is received when the product is finally delivered and
hence any errors in the requirement specification are not discovered until the product is sent to
the client after completion. This therefore has major time and cost related consequences .

1.5.2 Incremental Models

The major drawbacks of the waterfall model are due to the fact that the entire product is
developed and delivered to the client in one package.

This results in delayed feedback from the client. Because of the long elapsed time, a huge new
investment of time and money may be required to fix any errors of omission or commission or to
accommodate any new requirements cropping up during this period. This may render the product
as unusable.

Incremental model may be used to overcome these issues. In the incremental models, as opposed
to the waterfall model, the product is partitioned into smaller pieces, which are then built and
delivered to the client in increments at regular intervals.

Since each piece is much smaller than the whole, it can be built and sent to the client quickly.
This results in quick feedback from the client and any requirement related errors or changes
could be incorporated at a much lesser cost. It is therefore less traumatic as compared to the
waterfall model.
 Figure 1.Error! Use the Home tab to apply 0 to the text that you want to appear here..2 Incremental Model

It also required smaller capital outlay and yield a rapid return on investment. However, this
model needs and open architecture to allow integration of subsequent builds to yield the bigger
product. A number of variations are used in object-oriented life cycle models.

There are two fundamental approaches to the incremental development. In the first case, the
requirements, specifications, and architectural design for the whole product are completed before
implementation of the various builds commences. In a more risky version, once the user
requirements have been elicited, the specifications of the first build are drawn up.
 Figure1.3 Stages of Incremental Model

When this has been completed, the specification team turns to the specification of the second
build while the design team designs the first build. Thus the various builds are constructed in
parallel, with each team making use of the information gained in the all the previous builds. This
approach incurs the risk that the resulting build will not fit together and hence requires careful
monitoring.

1.5.3 Spiral Model

Barry Boehm developed this model. The main idea of this model is to avert risk, as there
is always an element of risk in development of software. For example, key personnel may resign
at a critical juncture, the manufacturer of the software development may go bankrupt, etc. In its
simplified form, the Spiral Model is Waterfall model plus risk analysis. In this case each stage is
preceded by identification of alternatives and risk analysis and is then followed by evaluation
and planning for the next phase. If risks cannot be resolved, project is immediately terminated.
This is depicted in the following diagram.
 Figure 1.4 Spiral Model

As can be seen, a Spiral Model has two dimensions. Radial dimension represents the cumulative
cost to date and the angular dimension represents the progress through the spiral. Each phase
begins by determining objectives of that phase and at each phase a new process model may be
followed.
 Figure 1..5 Full Version of Spiral Model

The main strength of the Spiral Model comes from the fact that it is very sensitive to the risk.
Because of the spiral nature of development it is easy to judge how much to test and there is no
distinction between development and maintenance. It however can only be used for large-scale
software development and that too for internal (in-house) software only.

1.6. Adopted Methodology

We will adopt incremental model to develop the system. In this Model an overall
architecture of the total system is developed first, the detailed increments and releases are
planned. Each increment has its own complete life cycle. The increments may be built serially or
in parallel depending on the nature of the dependencies among release and on availability of
resources. Each increment adds additional or improved functionality to the system.
 1.6.1. Reasons for choosing the Methodology

There are many reasons to choose the incremental development, the main reasons for
choosing the Incremental model are:

 Because the project management is more manageable for each incremental

 It is easier to understand and to test the smaller increments of functionality.
 Use of successive increments provides the opportunity to incorporate user refinements,
resulting from experience with earlier release, into subsequent releases; the resulting software
is more adaptable by design.
 Initial functions are developed sooner, and there is a successive building of operational
functionality overtime.
 The returns for the investment in development are seen earlier as increments are delivered.
 Software released in increments over time is more likely to satisfy changing user
requirements than if it were planned as a single overall release at the end of the same period
 Project team & work breakdown structure
 Project development team is consisting of two members and documentation and development
is equally distributed among them.
 Project team’s objective
 The vital purpose of this Project Plan is to clearly define the each of the subsidiary plans. The
main goals and objectives for the project team is to achieve the following goals.
 Project will be completed on time.
 Project will be completed within budget.
 Project will be completed with the highest degree of quality possible.

All Functional and user requirements will be achieved.

CHAPTER NO 2: Software Requirement Specification

2.1. Functional Requirement

Requirement
ID Description Priority
Type
FR-
Functional User Authentication High
01
The system shall provide secure login functionality for
administrators, teachers, and students.
FR-
Functional User Roles and Permissions High
02
The system shall define roles (Admin, Teacher, Student) and
assign appropriate permissions for each role.
FR-
Functional Exam Creation High
03
The system shall allow teachers to create exams with multiple
question types (MCQs, short answer, etc.).
FR-
Functional Question Bank Medium
04
The system shall provide a question bank where teachers can
store and manage questions.
FR-
Functional Exam Scheduling High
05
The system shall allow administrators to schedule exams and
notify students.
FR-
Functional Online Exam Conduct High
06
The system shall allow students to take exams online within
the specified time frame.
FR-
Functional Auto-Grading for Objective Questions High
07
The system shall automatically grade objective questions and
provide immediate feedback to students.
FR-
Functional Manual Grading for Subjective Questions Medium
08
The system shall allow teachers to manually grade subjective
questions and enter scores.
FR-
Functional Result Generation High
09
The system shall generate and publish exam results to students
and teachers.
FR- Functional Report Generation Medium
 Requirement
ID Description Priority
Type
10
The system shall generate various reports (e.g., performance
reports, attendance reports) for analysis.
FR-
Functional Notifications Medium
11
The system shall send notifications to users regarding exam
schedules, results, and other important updates.
Table 2. 1 Functional Requirement

2.2 Non- Functional Requirement

Requirement
ID Description Priority
Type
NFR-
Non-Functional Performance High
01
The system shall handle up to 1,000 concurrent users without
performance degradation.
NFR-
Non-Functional Security High
02
The system shall ensure data encryption, secure access, and
protection against common security threats.
NFR-
Non-Functional Usability Medium
03
The system shall have an intuitive user interface that is easy
to navigate for all user roles.
NFR-
Non-Functional Reliability High
04
The system shall have an uptime of 99.9% and be resilient to
failures.
NFR-
Non-Functional Scalability Medium
05
The system shall be scalable to accommodate increasing
numbers of users and data.
NFR-
Non-Functional Maintainability Medium
06
The system shall be designed for easy maintenance and
updates.
NFR-
Non-Functional Compatibility Medium
07
The system shall be compatible with major web browsers
and mobile devices.
 Requirement
ID Description Priority
Type
NFR-
Non-Functional Backup and Recovery High
08
The system shall have automated backup and recovery
processes to prevent data loss.
NFR-
Non-Functional Documentation Medium
09
The system shall include comprehensive documentation for
users and administrators.
Table 2. 2 Non-Functional Requirement

2.3 Tools and Techniques

 Php

 Xampp

 Mysql yog

 HTML

 Bootstrap

 Sublime text

 Git hub

 Java Script

 Css
2.3.1 PHP
Hypertext Preprocessor (or simply PHP) is a server-side scripting language designed for
Web development, but also used as a general-purpose programming language. It was
originally created
by Rasmus Lerdorf in 1994,] the PHP reference implementation is now produced by The PHP

Group. PHP originally stood for Personal Home Page,] but it now stands for the recursive
acronym PHP: Hypertext Preprocessor.

PHP code may be embedded into HTML code, or it can be used in combination with
various web template systems, web content management systems, and web frameworks.
PHP code is usually processed by a PHP interpreter implemented as a module in the web
server or as a Common Gateway Interface (CGI) executable. The web server combines the
results of the interpreted and executed PHP code, which may be any type of data, including
images, with the generated web page. PHP code may also be executed with a command-
line interface (CLI) and can be used to
implement standalone graphical applications.

2.3.2 Xampp

XAMPP is a free and open source cross-platform web server solution stack package
developed by Apache Friends, consisting mainly of the Apache HTTP Server, MariaDB
database, and interpreters for scripts written in the PHP and Perl programming languages.
XAMPP stands for Cross-Platform (X), Apache (A), MariaDB (M), PHP (P) and Perl (P).
It is a simple, lightweight Apache distribution that makes it extremely easy for developers
to create a local web server for testing and deployment purposes. Everything needed to set
up a web server – server application (Apache), database (MariaDB), and scripting language
(PHP) – is included in an extractable file. XAMPP is also cross-platform, which means it
works equally well on Linux, Mac and Windows. Since most actual web server
deployments use the same components as XAMPP, it makes transitioning from a local test
server to a live server extremely easy as well.

2..3.3 MYSQL

MySQL Workbench is a unified visual tool for database architects, developers, and DBAs.
MySQL Workbench provides data modeling, SQL development, and comprehensive
administration tools for server configuration, user administration, backup, and much more.
MySQL Workbench is available on Windows, Linux and Mac OS X.
 2.3.4 HTML
Hypertext Markup Language (HTML) is the standard markup language for creating web
pages and web applications. With Cascading Style Sheets (CSS) and JavaScript, it forms a
triad of cornerstone technologies for the World Wide Web.[4]

Web browsers receive HTML documents from a web server or from local storage and
render the documents into multimedia web pages. HTML describes the structure of a web
page semantically and originally included cues for the appearance of the document.

HTML elements are the building blocks of HTML pages. With HTML constructs, images
and other objects such as interactive forms may be embedded into the rendered page. HTML
provides a means to
create structured documents by denoting structural semantics for text such as headings,
paragraphs, lists, links, quotes and other items.

2.3.5 Bootstrap
Bootstrap is a free and open-source front-end framework for designing websites and web
applications. It contains HTML- and CSS-based design templates for typography, forms,
buttons, navigation, and other interface components, as well as optional JavaScript
extensions. Unlike many web frameworks, it concerns itself with front-end development
only.

2.3.6 Java Script

JavaScript often abbreviated as JS, is a high-level, interpreted programming language. It is
a language that is also characterized as dynamic, weakly typed, prototype-based and multi-
paradigm.

Alongside HTML and CSS, JavaScript is one of the three core technologies of the World Wide
Web. JavaScript enables interactive web pages and thus is an essential part of web
applications. The vast majority of websites use it, and all major web browsers have a
 dedicated JavaScript engine to execute it.

2.3.7 Sublime Text

Sublime Text is a proprietary cross-platform source code editor with a Python application
programming interface (API). It natively supports many programming languages and markup
languages, and functions can be added by users with plugins, typically community-built and
maintained under free software licenses.

2.3.8 CSS
Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation
of a document written in a markup language like HTML. CSS is a cornerstone technology
of the World Wide Web, alongside HTML and JavaScript.

CSS is designed to enable the separation of presentation and content, including layout, colors,
and fonts. This separation can improve content accessibility, provide more flexibility and
control in the specification of presentation characteristics, enable multiple web pages to
share formatting by specifying the relevant CSS in a separate css file, and reduce
complexity and repetition in the structural content.

CHAPTER NO 3: Analysis

3.1 Use Cases for Online Exam Cell Automation System

To provide a visual representation, a use case diagram typically includes the main actors (users)
and their interactions with the system. Since a visual diagram cannot be provided directly here,
below is a detailed textual description of the use cases along with the actors involved.
3.2 . Actors

 Administrator: Manages user roles, schedules exams, and oversees the overall
system.
 Teacher: Creates and manages exams, adds questions to the question bank, grades
subjective questions, and reviews results.
 Student: Takes online exams, views exam schedules, and checks results.
 System: Handles automated processes such as authentication, auto-grading,
notifications, and report generation.

33. Use Case Descriptions

Use Case
Use Case Actor(s) Description
ID

Administrator, The system authenticates users based on their

User
UC-01 Teacher, Student, credentials and grants access to the respective
Authentication
System roles (Administrator, Teacher, Student).

The Administrator creates, updates, and deletes

UC-02 Manage Users Administrator
user accounts, and assigns roles and permissions.

Teachers create new exams by adding exam

UC-03 Create Exam Teacher details such as title, date, duration, and questions
from the question bank.

Teachers add, update, and delete questions in the

Manage
UC-04 Teacher question bank, categorizing them by subject and
Question Bank
type (MCQs, short answer, etc.).

The Administrator schedules exams by setting

Schedule
UC-05 Administrator the date, time, and assigning them to specific
Exam
classes or groups of students.

Students log in, view their scheduled exams, and

UC-06 Take Exam Student
take exams within the allotted time frame.
Use Case
Use Case Actor(s) Description
ID

The system automatically grades objective

UC-07 Auto-Grading System questions (e.g., MCQs) immediately after the
exam is submitted.

Manual Teachers manually grade subjective questions

UC-08 Teacher
Grading and input scores into the system.

Students and Teachers view exam results.

UC-09 View Results Student, Teacher Teachers can analyze performance, and students
can check their scores.

The system generates various reports such as

Generate Administrator, performance reports, attendance reports, and
UC-10
Reports Teacher exam statistics for analysis by administrators and
teachers.

The system sends notifications to users regarding

Send
UC-11 System exam schedules, results, and other important
Notifications
updates.

Backup and The system performs automated backups and

UC-12 System
Recovery ensures data recovery to prevent data loss.

3.4. Detailed Use Case Examples

Use Case: User Authentication

 Actor(s): Administrator, Teacher, Student, System

 Description:
o Precondition: User has valid credentials (username and password).
o Main Flow:
1. The user navigates to the login page.
 2. User enters username and password.
3. The system verifies credentials.
4. The system grants access to the user based on their role (Administrator,
Teacher, or Student).
o Postcondition: User is logged into the system with appropriate access
permissions.

Use Case: Create Exam

 Actor(s): Teacher
 Description:
o Precondition: Teacher is logged into the system.
o Main Flow:
1. Teacher navigates to the 'Create Exam' section.
2. Teacher enters exam details (title, date, duration).
3. Teacher selects questions from the question bank.
4. Teacher saves the exam.
o Postcondition: The new exam is created and saved in the system.

Use Case: Take Exam

 Actor(s): Student
 Description:
o Precondition: The student is logged into the system and has a scheduled exam.
o Main Flow:
1. Student navigates to the 'Scheduled Exams' section.
2. The student selects the exam and starts it.
3. Student answers the questions within the given time frame.
4. Student submits the exam.
o Post condition: The exam is submitted for grading.

Use Case: Auto-Grading

  Actor(s): System
 Description:
o Precondition: An exam containing objective questions has been submitted.
o Main Flow:
1. The system receives the submitted exam.
2. System grades the objective questions (e.g., MCQs).
3. System stores the results.
o Post condition: Objective questions are graded, and results are saved.

CHAPTER NO 4: Design

4.1. Architecture Design

Description: The architecture design provides a high-level overview of the system's structure,
including its components, their interactions, and the technologies used. The architecture of the
Online Exam Cell Automation System is based on a multi-tier architecture, consisting of the
following layers:

1. Presentation Layer: This is the front-end of the system, including the user interface. It
interacts with users (administrators, teachers, and students) through web pages or mobile
applications.
 2. Application Layer: This is the business logic layer that processes user inputs, applies
business rules, and manages data flow between the presentation and data layers.
3. Data Layer: This layer includes the database management system (DBMS) and handles
data storage, retrieval, and management.

Technologies:

 Frontend: HTML, CSS, JavaScript, Angular/React (for web applications)

 Backend: Java/Spring Boot or Node.js/Express (for business logic)
 Database: MySQL or PostgreSQL (for data storage)
 Figure 4 1 Architecture design

4.2. Entity-Relationship Diagram (ERD)

Description: The ERD depicts the data model and relationships between entities in the system.
Key entities and their relationships are illustrated.

Entities and Relationships:

 User: Represents users in the system (attributes: user_id, username, password, role).
 Exam: Represents exams created by teachers (attributes: exam_id, title, date, duration).
  Question: Represents questions in the question bank (attributes: question_id, text, type,
answer).
 Result: Represents the results of exams (attributes: result_id, student_id, exam_id, score).

Relationships:

 User - Exam: One-to-many relationship (one teacher can create multiple exams).
 Exam - Question: Many-to-many relationship (an exam consists of multiple questions,
and a question can be part of multiple exams).
 User - Result: One-to-many relationship (one student can have multiple results).

Figure 4. 2 ERD
4.3. Data Flow Diagram (DFD)

Description: The DFD illustrates how data moves through the system and the processes
involved at each stage.

Levels:

 Level 0 (Context Diagram): Shows the system as a single process interacting with
external entities (users: administrators, teachers, and students).
 Level 1: Breaks down the system into major sub-processes (e.g., user management, exam
management, result processing).

Processes:

 User Management: Handles user authentication and role assignment.

 Exam Management: Manages exam creation, scheduling, and question bank.
 Result Processing: Handles exam submissions, auto-grading, manual grading, and result
generation.
Figure 4 3 Data Flow Diagram
4.4. Class Diagram

Description: The class diagram models the static structure of the system by showing its classes,
attributes, operations, and relationships among objects.

Classes:

 User: Attributes (user_id, username, password, role); Methods (login(), logout()).

 Exam: Attributes (exam_id, title, date, duration); Methods (createExam(),
scheduleExam()).
 Question: Attributes (question_id, text, type, answer); Methods (addQuestion(),
deleteQuestion()).
 Result: Attributes (result_id, student_id, exam_id, score); Methods (calculateScore(),
generateReport()).

Relationships:

 Association: User creates Exam, Exam contains Questions, User receives Result.
 Inheritance: User has subclasses (Administrator, Teacher, Student) with specific roles
and permissions.

Figure 4 4 Class Diagram

4. 5. Sequence Diagram

Description: The sequence diagram depicts the interactions between objects in a sequential
order, focusing on the flow of messages over time for a specific scenario.

Scenario: Student Takes Exam

Objects:

 Student: Initiates the exam-taking process.

 Exam: Represents the exam being taken.
 System: Manages the exam process and grading.

Sequence of Interactions:

1. Student logs in: Student -> System (login()).

2. System authenticates: System -> Student (authentication response).
3. Student starts exam: Student -> System (startExam()).
4. System retrieves exam: System -> Exam (getExamDetails()).
5. Student submits answers: Student -> System (submitAnswers()).
6. System processes answers: System -> Exam (processAnswers()).
7. System auto-grades: System -> Result (autoGrade()).
8. Student views result: Student -> System (viewResult()).
 Figure 4 5 Use Case

Visual Representation

Creating visual diagrams is crucial for a complete understanding. Here are the suggested steps
for creating them:

 Architecture Design: Use diagramming tools like Lucidchart or Microsoft Visio to

create a multi-tier architecture diagram.
 ERD: Tools like MySQL Workbench, Draw.io, or ER/Studio can be used to draw the
ERD.
 DFD: Use Microsoft Visio or Lucidchart to create context and level diagrams.
 Class Diagram: UML tools like Enterprise Architect or StarUML can be used for class
diagrams.
 Sequence Diagram: Use tools like Lucidchart, Microsoft Visio, or UMLet to create
sequence diagrams.
CHAPTER NO 5: Graphical user Interface

5.1 Login Page

Figure 5. 1 Login page

5.2 Dashboard

Figure 5. 2 Admin Dashboard

5.3 Teacher Module

Figure 5. 3 Add Teacher

 5.3.1 View Teacher

Figure 5. 4 View Teacher

5.4 Add Student

Figure 5. 5 Add Students

 5.4.1 View Student

Figure 5. 6 View Students

5.5 Subject Management

Figure 5. 7 Add Subject

 5.5.1 View Subject

Figure 5. 8 View Subject

5.6 Class Management

Figure 5. 9 Add class

 5.6.1 View Class

Figure 5. 10 View Classes

5.7 Exam Management

Figure 5. 11 Exam Report

CHAPTER NO 6: Test Cases

6.1 Test Scenario

The Exam Cell Automation System (ECAS) needs to be tested to ensure that it performs as
expected across all its functionalities. The testing will cover both black-box and white-box
testing approaches to validate the system's functionality, performance, and security.

6.2 Test Plan

The test plan outlines the strategy for testing the ECAS, including the scope, objectives,
resources, schedule, and types of tests to be performed.

Scope:
Testing will cover all modules of the ECAS, including exam scheduling, invigilator allocation,
result processing, notifications, and data management.
Objectives:
Ensure that the system functions correctly, efficiently, and securely. Identify and fix any defects
before deployment.
Resources:
Test team, test environment (including software and hardware), test data, and tools.
Schedule:
Testing will be carried out over a defined period, with specific milestones for different phases
such as unit testing, integration testing, system testing, and acceptance testing.
Types of Tests:
 Black-Box Testing: Functional testing without considering internal code structure.
 White-Box Testing: Structural testing considering the internal workings of the system.
Definition of Test Case
A test case is a set of conditions or variables used to determine if a system under test satisfies
requirements and works correctly. Each test case includes inputs, execution conditions, and
expected results.

Test Case Specification

Test case specifications provide detailed information about each test case, including ID,
description, preconditions, test steps, expected results, and actual results.
Black-Box Testing
Test Case ID: BB001
Description: Verify exam scheduling functionality.
Preconditions: System is logged in as an admin.
Test Steps:
Navigate to the exam scheduling module.
Enter exam details (course, date, time, venue).
Submit the schedule.
Expected Results: Exam is scheduled and confirmation message is displayed.
Actual Results: (To be filled after testing)
Test Case ID: BB002
Description: Verify invigilator allocation.
Preconditions: System is logged in as an admin.
Test Steps:
Navigate to the invigilator allocation module.
Select an exam and assign invigilators.
Submit the allocation.
Expected Results: Invigilators are assigned and confirmation message is displayed.
Actual Results: (To be filled after testing)
White-Box Testing
Test Case ID: WB001
Description: Verify internal logic for exam date conflict detection.
Preconditions: System has existing exam schedules.
Test Steps:
Attempt to schedule a new exam on a date/time already occupied.
Execute the function checking date conflicts.
Expected Results: Function detects conflict and prevents scheduling.
Actual Results: (To be filled after testing)
Test Case ID: WB002
Description: Verify database integrity during result processing.
Preconditions: System has student data and exam results to process.
Test Steps:
Run the result processing script.
Check database for correct result entries.
Expected Results: Database reflects correct results without any integrity issues.
Actual Results: (To be filled after testing)
Test Case Results
Black-Box Testing Results:

BB001: (To be filled after testing)

BB002: (To be filled after testing)
White-Box Testing Results:

WB001: (To be filled after testing)

WB00
2: (To be filled after testing)
CHAPTER NO 7: Conclusion and Future work

The Exam Cell Automation System (ECAS) project has successfully demonstrated the potential
to revolutionize the management of examination processes within educational institutions. By
automating critical tasks such as exam scheduling, invigilator allocation, result processing, and
communication, ECAS offers a robust solution to the inefficiencies and inaccuracies associated
with traditional manual methods. The system has shown significant improvements in terms of:

1. Efficiency: Automation of repetitive tasks has drastically reduced the time and effort
required from administrative staff.
2. Accuracy: The elimination of human errors in scheduling, invigilation, and result
processing has led to higher accuracy and reliability.
3. Resource Utilization: Optimal allocation of resources, including exam venues and
invigilators, has enhanced the overall management of examinations.
4. Transparency and Accountability: Real-time tracking and monitoring of examination
activities have increased transparency and accountability in the exam management
process.
5. Communication: Automated notifications and updates have facilitated seamless
communication between students, faculty, and administrative staff.

Overall, the implementation of ECAS has resulted in a more streamlined, efficient, and user-
friendly examination management system that benefits all stakeholders involved.

Future Work
While the current implementation of ECAS addresses many challenges associated with
traditional exam management, there are several areas for future enhancement and development to
further improve its functionality and adaptability:

1. Integration with Learning Management Systems (LMS): Integrating ECAS with

existing LMS platforms can provide a seamless flow of information and enhance overall
academic management.
2. Mobile Application Development: Developing a mobile application version of ECAS
can provide users with on-the-go access to exam schedules, notifications, and results,
improving accessibility and convenience.
3. Advanced Analytics and Reporting: Incorporating advanced analytics and reporting
capabilities can offer deeper insights into examination trends, student performance, and
resource utilization, aiding in strategic decision-making.
4. AI and Machine Learning: Utilizing AI and machine learning algorithms for predictive
analysis and decision-making can further optimize scheduling, invigilator allocation, and
result processing.
5. Enhanced Security Features: Implementing advanced security measures, such as
biometric authentication and encrypted data storage, can ensure higher levels of data
protection and integrity.
6. User Feedback Mechanism: Introducing a feedback mechanism for students, faculty,
and administrative staff can help in continuously improving the system based on user
experiences and suggestions.
7. Scalability and Customization: Ensuring the system is scalable and customizable to
cater to the specific needs of different educational institutions, regardless of their size or
complexity.
8. Regulatory Compliance: Regular updates to ensure compliance with evolving
educational regulations and standards.

By focusing on these future enhancements, ECAS can continue to evolve and remain at the
forefront of exam management solutions, offering even greater value to educational institutions
and their stakeholders.