This project AUTOMATED INVIGILATOR ASSIGNMENT SYSTEM (AIAS) is concerned with the

invigilator examination assignment problem. A web based Automated Invigilator Assignment System
(AIAS) consists of a database storing the information and web based user interface is constructed to solve
the problem by providing an environment for practical usage.
The manual procedure used in educational institutions for invigilating exams is time consuming and error
prone due to human limitations. The purpose of this project is to provide a solution concerning the
invigilation of examinations in educational institutes.
The institutions manually supposed to differentiate different categories of staff and then assign them to
invigilate the exams. This project will provide the best solution to automatically perform all those activities
within a reasonable time with minimum efforts needed.

1.1 OBJECTIVE
Preparing the examination invigilator schedule has always been itself a challenging task as the invigilators
schedule committee has to take into consideration numerous factors and lecturers constraints such as
getting the invigilators schedules ready within a limited time frame, ensuring the invigilator duties
assigned to the lectures do not disrupt their marking and that the lecturers do not invigilate their own
subjects.
The main objective of the AIAS is to assign invigilators duty in the examination rooms, compute the
subject wise list of eligible students for mid semester examination and the number of question papers
required in each room.
Invigilators availability depends on their teaching schedules so that their regular lectures will not get
disturbed. It should be taken into consideration that the workload of invigilator should not exceed more
than 3 hours. The general objective of our project is to change the current manual system into
computerized one.
The project is totally built at administrative end and thus only the administrator is guaranteed the access.

1.2 PROBLEM DOMAIN

An invigilator is the person who supervises student during an examination. Invigilators examination
assignment is a problem of assigning invigilators to examination in such a way that there is no conflicts
or clashes. The manual process of assigning invigilators may also involve many man hours. As the
difficulty of the problem increases due to a large number of invigilators and constraints, an automated
assignment system is often required.

1
Prior to the present invigilation scheduling committee taking over the responsibility of preparing the
invigilation schedules, invigilation duties were assigned randomly and hence there were a lot of mutual
swapping amongst the lecturers resulting in confusion, misunderstanding and complaints on uneven duty
distribution.

An invigilator should not be scheduled to invigilated more than once in the same time slot and the
invigilator’s workload should not exceed more than 3 hours.

1.3 SOLUTION DOMAIN

AIAS aims to reduce manual involvement and time taken by the scheduling committee in developing a
systematic approach in the preparation of invigilation schedules.

With this system, the committee creates a centralised data base for collecting information and identifies
suitable software system which facilitates the data processing process and supports invigilation scheduling
system. Thus, the examination invigilation schedules can be optimised based on the preference of lecturers
and the constraints faced. This system provides us the subject wise list of eligible students for mid semester
examination and the number of question papers required in each room.

The development of this software is significant as it is capable in minimizing the involvement and time
spent by the committee on the preparation of invigilation schedules. Besides it ensures consistency,
reliability and continuity in the invigilation schedules produces in current semester.

1.4 TECHNOLOGY TO BE USED

Front end as:

 HTML (Hyper Text Markup Language)

 CSS (Cascading Style Sheets)

Back end as:

 JSP (Java Server Pages)

 Servlet
 JDBC (Java database Connectivity)

2
Programming Environment: Java

IDE: Netbeans

Web Server: Glassfish Server 4.0

Database: Mysql

3
2.1 INFORMATION GATHERING

On the basis of system study performed in an organization about all the functions that deals with
Automated Invigilator Assignment System following requirements are specified.

 Functional Requirements
 Non Functional Requirements

2.1.1 Functional Requirements

Functional requirements are nothing but services provided by the system to the end users.

The user requirements for this system is make the system fast, flexible, less prone to errors, reduce
expenses, reduce manual work and save time.

Using the AIAS with the following functional requirements are performed by each actor of the system.

FR1

Functional Requirements for Administrator

 The system administrator should be able to manage the information of regular schedule of each
faculty.
 The system administrator should be able to upload the details required for scheduling invigilator
duty.
 Administrator load the attendance into the database.
 Administrator can access all the information of faculty member and student and can manipulate it
also.
 The admin allows the system to send the information about scheduling to the respective faculties.
 The admin will be able to login in to the system.

4
FR2

Functional Requirements for System

 The system generates invigilator duty assigning schedule.

 The system also generate the list of eligible students.
 The system also provide the number of question paper require in each room.
 The system should be able to authenticate through login its user (Admin) by checking information.

2.1.2 Non Functional Requirements

NFR1

Security

 The information should be secure; there should not be any kind of malfunctioning.
 Details of exam taken and venues, invigilators are stored securely in the system.
 System information will not be changed by any person rather than admin.

NFR2

Reliability

 System should be reliable.

 It should keep secure all the information regarding to particular exam invigilation schedule.
 The system must give the perfect calculations.

NFR3

Flexibility

 System is working easily on the internet with the username and password of the user.
 The institute has given right only to the admin to use the system with the provided username.

5
NFR4

Efficiency

 System should be efficient enough to meet all kinds of requirements as required by the admin.
 It should provide correct output in all manners.

NFR5

Safety

 The database may get crashed at any certain time due to virus or operating system failure.
Therefore, it is required to take the database backup.

NFR6

Performance

 The system is fast since it is automated.

 The system must have error handling.

2.2 Feasibility Study

Feasibility focus on does the system useful to the business or the organization, so we proposed our
perception of the system, in accordance with the problems of existing system. In feasibility study phase,
we had undergone through various steps, which are described as follows-

2.2.1 Economic Feasibility

The newly developed system will provide many benefits to the college, especially to the instructors. The
newly being developed system will improve the examination speed.

Economic analysis is most frequently used for evaluation of the effectiveness of the system. In the system
the organization is most satisfied by economic feasibility. Because, if the organization implements this
system, it need not require any additional hardware resources as well as it will be saving lot of time.

6
2.2.2 Technical Feasibility

The proposed system is technically feasible. Because it can generate output in a given time, response time
is minimized, easy to communicate and generally it satisfies the end-user’s requirement.

Technical feasibility centres on the existing manual system of the Automated Invigilator Assignment
System and to what extent it can support the system.

According to feasibility analysis procedure the technical feasibility of the system is analysed and the
technical requirements such as software facilities, procedure, inputs are identified.
Since processing speed is high and the work is reduced in the maintenance point of view management
convince that the project is operationally feasible.

2.2.3 Operational Feasibility

The proposed system AIAS is operationally feasible because it is simple to access and all operations will
be performed easily.

2.2.4 Schedule Feasibility

The proposed system AIAS is will be developed totally and begin to give services according to the time
given. Therefore, it is feasible in the schedule.

2.2.5 Effort

Compared to the existing system the proposed system will provide a better working environment in which
there will be ease of work and the effort required will be comparatively less than the existing system.

2.2.6 Labour

In the existing system the number of staff required for completing the work is more, while the new system
will require quite a less number of staff.

2.2.7 Time

There is no time wasted by instructor as previously wasted on correcting. The instructors will be happy
because their time is saved by the system.

7
3.1 USE CASE DIAGRAM
Use Case Diagram in the Unified Modelling Language (UML) is a type of behavioural diagram defined
by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality
provided by the system in terms of actors, their goals (represented as use cases), and any dependencies
between those use cases. Each use case should provide some observable and valuable result to the actors
of the system.

System
<<include>>
Login Authentication

Add Student Information

Upload Student Attendance

<<extend>> Student Information

Modify Student Record <<extend>>

Student Attendance
ADMIN

Provide Scheduling Information

<<extend>> Add Faculty

Faculty Information
<<extend>>
Modify Faculty

Logout

Show Uploaded Data

Generate Schedule

Generate Student List

SYSTEM
Duty Assigned List

Question Papers Required

Inform Faculty

Figure 3.1: Use Case Diagram for AIAS

8
3.2 CLASS DIAGRAM
In software engineering, a class diagram in the Unified Modelling Language (UML) is a type of static
structure diagram that describes the structure of a system by showing the system's classes, their attributes,
operations (or methods), and the relationships among objects.

Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is
also known as a structural diagram.

Figure 3.2: Class Diagram for AIAS

9
3.3 DATA FLOW DIAGRAM
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information
system, modelling its process aspects. A DFD is often used as a preliminary step to create an overview of
the system without going into great detail, which can later be elaborated. DFDs can also be used for
the visualization of data processing.

It is two dimensional diagram that explains how data is processed and transforms in a system.

Level 0 DFD

Level 0 DFDs, also known as context diagrams, are the most basic data flow diagrams. They provide a
broad view that is easily digestible but offers little detail. Level 0 data flow diagrams show a single process
node and its connections to external entities.

Figure 3.3: Level 0 DFD for AIAS

10
Level 1 DFD
Level 1 DFDs are still a general overview, but they go into more detail than a context diagram. In a level
1 data flow diagram, the single process node from the context diagram is broken down into sub processes.
As these processes are added, the diagram will need additional data flows and data stores to link them
together.

Figure 3.3: Level 1 DFD for AIAS

11
Level 2 DFD
DFD level 2 then goes one step deeper into parts of level1.It may require more text to reach the
necessary level of detail about the system’s functioning.

Figure 3.3 Level 2 DFD for AIAS

12
3.4 ACTIVITY DIAGRAM
Activity Diagram is a flowchart representation to represent the flow of one activity to another activity.

Activity Diagram not only used for visualizing dynamic nature of system but also used to construct the
executable system by using forward and reverse engineering techniques.

Figure 3.4 Activity Diagram for AIAS

13
4.1 DATA DESIGN
Database design is the process of producing a detailed data model of a database. This data model
contains all the needed logical and physical design choices and physical storage parameters needed to
generate a design in a data definition language, which can then be used to create a database. A fully
attributed data model contains detailed attributes for each entity.

4.1.1 Entity Relationship

An entity-relationship diagram (ERD) is a data modelling technique that graphically illustrates an

information system’s entities and the relationships between those entities. An ERD is a conceptual and
representational model of data used to represent the entity framework infrastructure.

There are five main components of an ERD:

 An entity is an object or concept about which we want to store information A weak entity is an
entity that must defined by a foreign key relationship with another entity as it cannot be uniquely
identified by its own attributes alone.
 Actions show how two entities share information in the database.
 Attributes show characteristic of the entity. For example, an employee's social security number
might be the employee's key attribute.
 Connecting lines, solid lines that connect attributes to show the relationships of entities in the
diagram.
 Cardinality specifies how many instances of an entity relate to one instance of another entity.

14
E-R DIAGRAM

Figure 4.1.1 E-R Diagram

15
4.1.2 DATA DICTIONARY
A data dictionary is a collection of descriptions of the data objects or items in a data model for the
benefit of programmers and others who need to refer to them. A first step in analyzing a system of object
with which users interact is to identify each object and its relationship to other objects. This process is
called data modelling and results in a picture of object relationships. After each data object or item is
given a descriptive name, its relationship is described, the type of data is described, possible predefined
values are listed, and a brief textual description is provided. This collection can be organized for
reference into a book called a data dictionary.

Table 4.1.1: Department table

S No. Attribute Data Type Constraint

1 Department_id Int(10) Primary Key
2 Department_name Varchar(30) Null

Table 4.1.2: Admin table

S No. Attribute Data Type Constraint

1 Username Varchar(20) Primary Key
2 Password Varchar(20) Primary Key

Table 4.1.3: Student table

S No. Attribute Data Type Constraint

1 S no. Int(11) Primary Key
2 Enrollment_no Varchar(30) Primary Key
3 FName Varchar(20) Null
4 LName Varchar(20) Null
5 B_id Int(11) Null
6 Section Varchar(10) Null

Table 4.1.4: Student Branch table

S No. Attribute Data Type Constraint

1 B_id Int(11) Primary Key
2 B_name Varchar(20) Null
3 Section Varchar(20) Null

Table 4.1.5: Student Attendance table

S No. Attribute Data Type Constraint

1 S no. Int(10) Primary Key
2 Enrollment_no Varchar(30) Foreign Key
3 Sub_id Int(10) Foreign Key
4 Total_attendance Int(20) Null
5 Section Varchar(10) Null

16
 Table 4.1.6: Subject table

S No. Attribute Data Type Constraint

1 Sub_id Int(11) Primary Key
2 Sub_name Varchar(20) Primary Key
3 T_id Int(11) Foreign key

Table 4.1.7: Teacher table

S No. Attribute Data Type Constraint

1 T_id Int(20) Primary Key
2 Name Varchar(30) Null
3 Department_id Int(10) Foreign Key
4 Email Varchar(20) Null

Table 4.1.8: Teacher lecture table

S No. Attribute Data Type Constraint

1 L_id Int(11) Primary Key
2 T_id Int(11) Foreign Key
3 Department_id Int(11) Foreign Key
4 Timing_id Int(11) Null
5 Day_id Int(11) Foreign Key

Table 4.1.9: Lecture Timing table

S No. Attribute Data Type Constraint

1 Timing_id Int(11) Primary Key
2 Start_Time Default Null
3 End_Time Default Null

Table 4.1.10: Day table

S No. Attribute Data Type Constraint

1 Day_id Int(10) Primary Key
2 Day_name Varchar(20) Null

Table 4.1.11: Total Lecture table

S No. Attribute Data Type Constraint

1 L_id Int(11) Primary Key
2 Sub_id Int(11) Foreign Key
3 Total_lecture Int(11) Null
4 Section Varchar(11) Null

17
After we have carefully planned our project, we will be ready to start the project implementation phase.
The implementation phase involves putting the project plan into action. It’s here that the project manager
will coordinate and direct project resources to meet the objectives of the project plan.

The implementation phase is where we and our project team actually do the project work to produce the
deliverables. The word “deliverable” means anything our project delivers. The deliverables for our project
include all of the products or services that our team is performing for the client, customer, or sponsor,
including all the project management documents that we put together.

The steps undertaken to build each deliverable will vary depending on the type of project we are
undertaking, and cannot therefore be described here in any real detail. For instance engineering and
telecommunications projects will focus on using equipment, resources, and materials to construct each
project deliverable, whereas computer software projects may require the development and implementation
of software code routines to produce each project deliverable. The activities required to build each
deliverable will be clearly specified within the project requirements document and project plan.

Our job as project manager is to direct the work, but we need to do more than deliver the results. We also
need to keep track of how well your team performs. The implementation phase keeps the project plan on
track with careful monitoring and control processes to ensure the final deliverable meets the acceptance
criteria set by the customer. This phase is typically where approved changes are implemented.

Most often, changes are identified by looking at performance and quality control data. Routine
performance and quality control measurements should be evaluated on a regular basis throughout the
implementation phase. Gathering reports on those measurements will help us determine where the
problem is and recommend changes to fix it.

18
Some of the screenshots of our project

19
20
21
22
People are not perfect. We make errors in design and code. Hence testing is an essential activity in software
life cycle. The goal of testing is to uncover as many errors as possible. The software testing is an important
activity carried out in order to improve the quality of the product. For finding out all possible errors the
testing must be conducted systematically and test cases must be designed using disciplined techniques.
Definition: - Software testing is an activity performed to uncover errors. It is a critical element of software
quality assurance and represents the ultimate review of specification, design and coding.

The purpose of software testing is to ensure whether the software functions appear to be working according
to specification and performance requirements.

Testing Principles

1. All tests should be traceable to customer requirements.

2. Tests should be planned long before testing begins.
3. Testing should begin “in small” and progress toward testing “in large”.
4. Exhaustive testing is not possible.
5. To be most effective, testing should be conducted by an independent third party.

There are two general approaches for software testing.

1. Black box testing

The black box testing is used to demonstrate that the software functions are operational. As the name
suggests in black box testing it is tested whether the input is accepted properly and output is correctly
produced.

The major focus of black box testing is on functions, operations, external interfaces, external data and
information.

2. White box testing

In white box testing the procedural details are closely examined. In this testing the internals of software
are tested to make sure that they operate according to specifications and designs. Thus major focus of
white box testing is on internal structures, logic paths, control flows, data flows, internal data structures,
conditions, loops, etc.

23
TESTING OF AIAS

When admin login, then id and password are validate from the database, if id and password is incorrect
then message is displayed on the client side that User id or password is wrong, please check. If both are
correct, admin logged in. Admin can change the details of invigilators personal details and their lecture
timing and can also change student personal details and their attendance and that is stored in the database
successfully.

Only an admin can manipulate the details of invigilators and students and admin can also generates the
duty schedule. Admin provides details for scheduling duties after that system will fetch the details of
invigilator lecture timing from the database and if all the details are appropriate then the invigilators duty
assigning schedule is generated. Admin instructs the system to send mail to all those invigilators whose
duties were assigned.

System also generates the eligible students list according to the criteria provided by the admin from the
selected sections.

Project is successfully tested and it is working properly.

24