PROJECT REPORT ON TIME TABLE GENERATOR

A desertion submitted in partial fulfillment of the degree of Bachelor of Technology of Information

Technology, School Of Technology,NEHU.

GUIDED BY: SUBMITTED BY:

Mr. Swarup Roy Ameet Bora, BT/IT 0704

Assistant Professor Dweepjyoti Das, BT/IT 0712

Department of Information Technology HrishikeshBora,BT/IT 0720

PritamBonia, BT/IT 0744

SarfarazJelil, BT/IT 0748

DEPARTMENT OF INFORMATION TECHNOLOGY

SCHOOL OF TECHNOLOGY

NORTH EASTERN HILL UNIVERSITY

SHILLONG-22
 ACKNOWLEDGEMENT

The developers take the opportunity to offer their deep sense of gratitude and heartiest thanks
to Mr. Swarup Roy, Assistant Professor, Dept. Of I.T., School Of Technology, NEHU, Shillong for his
invaluable guidance, helpful suggestions and constant encouragement throughout the course of the
project work and in the preparation of the report.

He also expresses his sense of gratitude and thanks to all other respected teachers and staff
members of the department for their co-operation and timely help during the course of the project.
CONTENTS

1. Introduction and overview

2. Gantt Chart
3. Software Requirement Specification (SRS)
4. Design Startegy
5. Interface Design Strategy
6. User Manual
INTRODUCTION AND OVERVIEW

A timetable or schedule is an organized list, usually set out in tabular form, providing
information about a series of arranged events: in particular, the time at which it is planned these
events will take place.

A timetable can be used anywhere such as schools, universities, airlines, etc. Generally in places
like schools and universities the timetables are created manually, i.e., handwritten. However if the
required timetable is very large then it is very difficult to manage it manually which leads to almost
certain mistakes such as allotment of two subjects to a teacher at the same time or allotment of
more than one class at the same room, etc. Thus generating timetables manually is erroneous.

Manual generation of timetables is cumbersome and error-prone due to the following reasons:

a) The Human Factor (“to err is human” )

b) In case of a large event list, manually checking which ones have been scheduled and which
ones are yet to be scheduled increases the probability of errors.
c) Many-to-One or One-to-Many clashes may remain undetected and unresolved.

A software solution would render all these problems obsolete to a large degree.

a) A software is less-faulty than a human.

b) Probability of error remains miniscule even in the case of large event lists.
c) A properly designed software will utilize algorithms to handle clashes during the timetable
generation phase, leaving the USER with the simple task of data entry.
d) Multiple database backups may be made, making the chance of data loss negligible.

From this perspective, the Timetable Generator tool must have the followingfeatures:

1) Interactive scheduling for faculty, room and course.

2) Clash-free scheduling

3) Should support printing of the generated timetable

4) Must be secure
 GANTT CHART

Aug Sept Sep Sept Oc Oc Oc N

. 25 .1 t. 2 . 15 t.1 t.1 t.2 Oct. ov
6 7 0 21 .1
Study &
SRS

Study & SRS

design

Coding

Testing

Documentatio
n
ORGANIZATION OF THE REPORT:
SOFTWARE REQUIREMENT SPECIFICATION

FUNCTIONAL REQUIREMENTS:

R1: Student view of the timetable

DESCRIPTION:

It is clearly obvious that a student of an institution should be able to view the timetable in an
understandable manner. The student should be able to view his relevant timetable by just giving his
department and semester details, as a result of which he will be displayed his relevant timetable. The
student may also be able to print his timetable if he wishes to.

Input : Department and Semester

Output : Timetable for the given department and semester

R1.1: Printing the displayed timetable

Input : “print” option

Output : A printed timetable

R2: Teachers view of the timetable

DESCRIPTION:

Similar to that of a student the faculties or the teachers should be able to view the semester
timetables and in addition to that he should also be able to view a timetable which displays his classes
for the whole week. The faculties will also have the option of printing the timetables. For this purpose
the faculties would be given the respective user login id and their passwords.

R2.1: Faculty Login

Input : Username and password

Output : Successful authentication

R2.2: Display semester timetable

Input : Department and Semester

 Output : Timetable

R3: Application of the system by the manager /the administrator

DESCRIPTION:

The TT Manager should have authority over the complete system. He must have a
unique username and password as login credentials. Thereafter, he must be able to view, edit or
delete any database if needed be. In addition, he must be able to add new users or remove any
existing ones.

R3.1: TT Manager Login

Input : Username and password

Output : Successful authentication, display of main window

R3.2: Create a new database; View, edit or delete the existing database

DESCRIPTION:

The TT_Manager should be able to create a new database or modify an existing one.
Any database will have the corresponding identifiers “department” and/or “semester. These
identifiers will uniquely identify a database and will be the criteria based on which databases
will be modified and/or deleted.

R3.2.1 : Identify the database to be operated on

Input : “rooms”, “courses” or “faculties”

Output : Prompt the user for department details.

R3.2.2 : Enter department details

Input : Department code and name

Output : Window for modification of respective database

R3.3 : Modify user accounts

DESCRIPTION:

The TT_Manager may add new users by specifying a username and password, or may
remove an existing user by specifying his username as the one to be deleted. In addition, he may
also change his password to guard against possible password compromises.

R3.3.1 : Add new user

Input : username and password

Output : successful creation of new user account

R3.3.2 : Remove an existing user

Input : username

Output : Successful deletion of user account

R3.3.3 : Change the TT_Manager password

Input : existing password; new password

Output : successful change of password

R3.4 : Generate the timetable

DESCRIPTION:

The TT_Manager is the one responsible for generating the end timetable from the
existing rooms, courses and faculty databases. He must first specify the start time of classes, the
duration of a single period or event, the time of lunch break, as well as the total number of
classes in a day. Thereafter, he will have to identify the department and semester for which the
timetable is being generated, after which, he may begin creating the timetable.

R3.4.1 : Specify duration and number of periods in a day

Input : Duration of a single period; number of periods in a day

Output : Prompt for start time of classes

R3.4.2 : Give start time of classes, and the timing of the lunch break

Input : Start time of classes; start time and duration of lunch break

Output : Prompt for department details on successful completion

R3.4.3 : Enter department details and semester

Input : Department code and name; semester

Output : Show window for creation of timetable

GRAPHICAL REPRESENTATION OF THE INTERACTIONS BETWEEN THE VARIOUS
ACTORS AND THE SYSTEM

INTERACTION BETWEEN THE STUDENT AND THE SYSTEM:

STUDENT

PROMPT FOR
DEPARTMENT AND
SEMESTER

INPUT DETAILS

DISPLAY PRINT
TIMETABLE TIMETABLE
INTERACTION BETWEEN THE FACULTY ANDTHE SYSTEM:

FACULTIES

PROMPT FOR
USERNAME &
PASSWORD

INPUT DETAILS PRINT

DISPLAY DISPLAY FACULTY’S

ALLOCATED CLASSES
SEMESTER
FOR THE WEEK
TIMETABLE

INTERACTION BETWEEN THE MANAGER/ADMINISTRATOR AND THE SYSTEM:

 TT_Manager

PROMPT FOR
USERNAME &
PASSWORD

INPUT DETAILS

DISPLAY MAIN
WINDOW

ASSIGN COURSES TO
FACULTIES
ROOMS COURSES FACULTIES

PROMPT FOR PROMPT FOR

DEPARTMENT DEPARTMENT
DETAILS & SEMESTER

ENTER DETAILS ENTER DETAILS

SHOW WINDOW FOR UPDATION OF DATABASE

DELETE DELETE DATABASE

ENTER DETAILS
SELECTED
PROMPT FOR DEPT. &
DATABASE
WHICH DATABASE TO
DELETE
 USECASE MODEL:

TT_MANAGER

CREATE ACCOUNT

FACULTY

LOGIN

EDIT OR CREATE
TIMETABLE

STUDENT

DISPLAY TIMETABLE

PRINT

TT GENERATOR
NON-FUNCTIONAL REQUIREMENTS:

N1: Web Support:

It should preferably be possible to invoke the visit timetable functionality from any place by
using a web browser.

N2: Usability:

The interface should be pleasant and user-friendly. It should make the task of data entry a
breeze and provide a clear benefit over manual entry.

N3: Portability:

The developed system should be easily transferable from one computer to another, along with
the database if necessary.
DESIGN STRATEGY
2.1 ENTITY-RELATIONSHIP (E-R) DIAGRAM:

ROOM_ID NAME

ROOM
NAME
DESCRIPTION
COURSE_ID NAME
FAC_ID
FLOOR

TIMETABLE COURSE CREDITS

FACULTY

DEPARTME
DAY
SEMESTER
TYPE SEMESTER

TIME THEORY PRACTICAL

TEACHES
2.2 RELATIONAL SCHEMAS FOR DATABASE TABLES:

Room = (room_id, room_name, description, floor)

eg :( 1, Digital Classroom 1, 6th Semester use, 2 )

Faculty = (fac_id, fac_name, department)

eg :( 1, Faculty_RDBMS, IT )

Course = (course_id, course_name, type, semester, credits)

eg :( 1, Relational Database Management Systems, Theory, 6, 4 )

2.3 RELATIONAL SCHEMAS FOR RELATIONSHIP SETS:

Teaches = (course_id, course_name, fac_id, fac_name)

eg :( 1, Relational Database Management Systems, 1, Fac_RDBMS )

Conducted = ( room_id, room_name, course_id, course_name)

eg :( 1, Digital Classroom 1, 1, Relational Database Management Systems)

Timetable = ( semester, day, time, course_name, fac_name,room_name )

eg :( 6, Monday, 9:30 – 10:30, Relational Database Management Systems,
Fac_RDBMS, Digital Classroom 1 )
2.4 DATA FLOW DIAGRAMS:

2.4.1 CONTEXT DIAGRAM

timetable
TIMETABLE
TT_MANAGER Manager details

Manager response
Fac response TIME TABLE
GENERATION TOOL Dept, sem
0

Fac details
FACULTY STUDENT
2.4.2 LEVEL-1 DFD
DB s
2.4.3 DATA DICTIONARY:

Manager_details : uid + pwd

Manager_response : DB_modified msg + TT modified msg +

Accnt modified msg +
timetable

Fac_details : fac_uid + fac_pwd

Fac_response : show schedule + timetable

DB details : rooms + courses + faculties + search keywords

Db modified msg : room_mod msg + course_mod msg +

fac_mod msg +
retrieved results
2.4.4 LEVEL-2 DFD:

faculties
INTERFACE DESIGNING
 Timetable Automaton
Interface

The Timetable Automaton starts off with the following screen, which allows the user in question to
select his role. The roles available are that of the administrator or the timetable generator, faculty
and student. Let’s follow these three roles in order.

Student:

Student Interaction

A student using the system needs to input his department name and semester to get his timetable.
On entering a valid department name and semester from the options provided, the student gets to
 Timetable View

this screen where he may view his concerned timetable. If he wishes to see which faculty is taking
up a particular course and vice versa, he may click the “Course and Faculty” button at the bottom to
get the details.

Instructors for Courses

Eventually, what the student may desire to do is take a printout of the timetable. All he has to do is
click on “Print It” to get his job done. In addition, the system provides the student with the ability to
take a soft copy of the timetable along with him instead of a printout. The formats supported are
PDF, Doc, Rpt, Excel spreadsheet or simply as rich text data.
Faculty:

A faculty will have to provide a valid username and password to login to the system.

Faculty Login

On successful authentication, the faculty gets to the following screen.

Faculty Viewing a Timetable

Here, the faculty may view the timetable of any semester by simply checking on the Timetable
option and inputting the required Semester number.
In addition, the system provides the faculty with the option of viewing his personal schedule for the
week. That is, the faculty may view his allocated classes for the week irrespective of semester for
the entire week. In order to do this, the faculty simply has to check the option “My Schedule for the
week” and he gets his schedule as follows:

Faculty viewing his personal schedule for the week

The faculty may thereafter get a printout of a timetable or his personal schedule by simply clicking
on the “Print It” option. In addition, he may get a softcopy of the timetable or his schedule in PDF,
Word, Excel, Rpt or rich text formats.
Administrator/Timetable Generator

The administrator has to input his user ID and password to get in to the system.

Administrator Login

On successful authentication, he gets to the following screen.

Administrator Home Interface

The interface highlights what the user has to do at every step. The user may see that the interface
tells him/her to select his department from File -> Department Details.

Registering Department details

On doing this, the home interface screen livens up. The progress bars indicate which databases are
filled up and which are not. The interface thereafter instructs the user to populate the empty
databases or proceed with timetable generation if all the progress bars are full.

Administrator Interface after registering Department

The administrator may click on “Create Database” to populate the rooms, courses or faculties
database for the particular department that he registered. A sample snapshot is shown below, for
the courses database. The procedure for each of the other databases is identical.

Selection of Create Database -> Courses gives us

Viewing the Courses Database

As can be seen, the interface is intuitive. The user may enter records by filling in the necessary
details in the boxes provided under “Add new” and clicking on “OK”. She/he may search for existing
records based on the Course ID, name of the course or semester. Also, he may select any record in
the view and click on “Delete Record” to get rid of it permanently. In cases where he may want to
modify any record, all the user has to do is type in the new value over the previous value in the
view. That’s it! Thus, the interface is remarkably easy to use.

A similar interface is used for the rooms and the faculty database.

Once the user has populated the courses and the faculty database, he/she has to begin assigning
courses to the various faculties. This may be accomplished by going to Create Database -> Assign
Courses to Faculties.

In this window, the user has to enter the semester number first and click on OK before he may
begin assigning courses to faculties. Entering the semester number will list only those courses in the
boxes that belong to that particular semester. This helps the user to easily assign courses to
faculties per semester and helps to narrow down the list for faster use of the system. Thereafter all
the user has to do is select the appropriate course from the course boxes and the corresponding
faculty from the faculty boxes and click on “Assign Course to Faculty” to finish the job.

Assigning courses to faculty

The user is provided with the appropriate “Delete Record” button to delete any faulty records.
However, he is not permitted to modify the value of any record.

The administrator thereafter has to specify the period structure for the department.
This may be accessed by going to Create Database -> Period Details. The user may choose to
develop the period structure automatically or manually. The left side of the interface contains the
necessary values to be input by the user for automatic period table generation. This includes the
start time of the first period, duration of a period, number of periods before and after lunch and the
duration of the lunch period. For manual generation, the user (on the right side of the interface) has
to use an integral value to denote the period number (i.e 1 for Period 1, 2 for Period 2 and so on). It
is to be noted that the user has to use a 24 hour clock timing standard to input the time values in
this interface. In addition, to denote the lunch period, the user has to use the identifier “L”. A
“Delete Tuple” button is provided to delete any individual faulty tuples. In order to ensure that the
timings are correct (say, the start time is always lesser than the end time, and ensuring that timings
of one period do not overlap with another), the user may click on “Check for conflicts”. If any errors
are detected, they are shown as follows:
 Erroneous Period Table

The entries in pink and red denote the conflicting pair of timings. The user may thereafter input the
correct timing by overwriting the values in the view. If the timings are correct, a “schedule is error-
free” message will show up when the user clicks on “Check for conflicts”.

If all the databases have been populated, the user can proceed with timetable generation. The
process may be started by selecting a valid semester in the home interface.

Selection of semester for timetable generation

The user has to select a semester from only the options given in the box. If it all goes well, clicking
on “Lets start” takes the user to the main interface for timetable generation.
 Interface for timetable generation

As can be seen, the interface is pleasing and very intuitive (easy to understand and use). The user
may select any period in the interface by simply clicking on it once. For instance, in the above
snapshot, period 3 on Monday is highlighted. The user may deselect the period by double clicking
on it.

Thereafter, the user will have to first select the course from the course boxes, and the
corresponding faculty for that course will show up in the faculty boxes as per the assignment in the
“Course to Faculty” interface. After selection of the room, the user may click on “Ok add it” to
assign the course-faculty-room combo to the selected period slot. Provided there are no conflicts,
the course-faculty-room combination will be assigned to that period and it will show up in that slot.
In this way, the timetable for the particular semester in question may be filled up.

Several constraints are maintained throughout. For example, a room may not be assigned if it’s
already allocated to some other course-faculty for some period, or a faculty may not be allocated
for a period if he has already been assigned in some other room for some other semester during
that same period. If any such conflicts show up, the admin is asked whether he wants to try and
resolve the conflict.

Solve the conflict?

In this case, the conflicting schedule is shown with the conflicting entry highlighted in red, which
may then be reallocated by the admin or deleted if required.

Conflict resolution during timetable generation (red highlights the conflict)

The entry in red highlights the conflict. Clicking on delete deletes the conflicting period, after which
the admin may resume generation of the earlier timetable.

The system also throws up a warning if the same faculty is allocated two consecutive classes or
more, or if the credit limit is exceeded for a course and the course is allocated too may times over
the week. The system takes care to prevent any conflicts of such nature and this is all done behind
the scenes. All the user ever has to take care of is simply populating the timetable. Thus, it becomes
a very pleasing experience. The admin may also click on the “Show Practicals” button to highlight
the practical periods or use the “Delete” button to free up any period.

Also, the admin may click on “Print It” to print out a copy of his generated timetable or a softcopy in
PDF, Word, Excel, Rpt, or rich text format. A sample printout copy is shown below:

Printout copy of the timetable

The user may also want to delete the databases. He may do this by clicking on “Delete Database” in
the home screen. This brings us to the following
 Delete Database

The interface is pretty self-explanatory. The databases to be deleted should be checked and the
“Delete” button clicked to get rid of the databases desired. It should be understood that the
different databases are related to each other as being parts of a timetable and so, deletion of a
database impacts the other databases as well and may lead to loss of entire timetables in the worst
case.

The other functionalities provided by the system to the admin are to add and remove user accounts
for the faculty. This may be done by going to User Accounts -> Add and Remove Users. This
requires a user id and password and the name of the faculty for which it is being created.
 Adding and deleting users (faculty)

The system also allows the administrator to change his login password. This may be accessed by
going to User Accounts -> Change Admin Password in the main interface.

Changing the admin password

This ensures a safer and more secure system.

In addition, the system provides the following features:

1) Auto complete features in textboxes for faster data entry.

2) Debugging error messages to quickly detect and correct user input error.
3) Support for multiple departments, and hence timetables for multiple semesters and
multiple departments.

This is the Timetable Automaton system.