ARBA MINCH UNIVERSITY

ARBA MINCH INSTITUTE OF TECHNOLOGY

FACULITY OF COMPUTING AND SOFTWARE ENGINEERING

Industrial Project Proposal On:

Web-Based Class Schedule Management System for AMIT
by:
NAME ID No

1.KALKIDAN DERESSE EVAMIT/027/13

2.EMRU ERADE EVAMIT/105/13
3.BAHIRU DIKOSA EVAMIT/008/13
4.DESALGNE DEMEKE EVAMIT/017/13

ADVISOR: ALEMSEGID K. (Asst. Prof)

A Senior project proposal Submitted to Department of Computer Science,

Faculty of Computing and Software Engineering, AMIT, Arba Minch University,
in Partial fulfillment for the requirement of the Degree of Bachelor Science in
Computer Science.

DEC, 2024

ARBA MINCH, ETHIOPIA

 Abstract
The manual system of preparing time table for class schedule is very time consuming and usually
ends up with various classes clashing either at same room or with same teacher having more
than one class at a same time. It is becoming a continuing problem in higher education
institution, due to the bulky nature of the task of the schedule preparation. Even the most
advanced higher education institutes in Ethiopia haven’t succeeded in automating the task of
scheduling. To overcome all these problems, we propose an automated system that accepts
various inputs like teacher name, module name, module code, credit hour, target group, block &
hall number, and lab session. By using the above inputs, it will make a possible class schedule by
making optimal utilization of resources. This projects hopes to contribute a lot to all Ethiopian
higher education institutions in general and Arba Minch institute of technology in particularly.
Our project includes background of the organization for which the project is to be developed.

Keywords: Class Scheduling, Manual based System, Web-based.

i
 Acknowledgments

First of all, and for most, I would like to thank almighty God for being with me all the time and
given me health, strength and uncountable gifts during this Project work and in my entire life for
His glory and His name.

I would like to express my deepest appreciation and heartfelt thanks to my advisor Mr.
Alemsegid K (Asst. Prof) for his sustainable and appreciable guidance, advising, providing
information, skill, experience and most of all being as friend work by fine-tuning starting from
the idea of the title through until the successful completion of my thesis work

Moreover, appreciation and thanks should also be extended to AMIT Staffs, administrators for
unreserved collaboration and kindness during data collection. I’m extremely grateful to their
willingness to share their knowledge in this regard. Their contribution to this research deserves
special thanks and recognition.

ii
Table of contents
Abstract .................................................................................................................................................. i
Acknowledgments ................................................................................................................................... ii
Table of contents.................................................................................................................................... iii
Acronyms ............................................................................................................................................... vi
List of Tables ......................................................................................................................................... vii
List of Figures ........................................................................................................................................viii
Chapter One ............................................................................................................................................ 1
1. Introduction ................................................................................................................................. 1
1.1 Background of the study ................................................................................................................ 1
1.2 Vision of AMU .............................................................................................................................. 2
1.3 Mission AMU ................................................................................................................................. 2
1.4 Team composition ......................................................................................................................... 2
1.5 Background of the project .............................................................................................................. 3
1.6 Statement of the problem.................................................................................................................... 3
1.7 The Objectives of the Study ............................................................................................................... 4
1.7.1 General objectives ..................................................................................................................... 4
1.7.2 Specific Objectives .................................................................................................................. 4
1.8 Scope of project ................................................................................................................................. 4
1.9 Limitations of the project.......................................................................................................... 5
1.10 Significance of the project......................................................................................................... 5
1.11 Target beneficiaries of the system ............................................................................................ 6
1.12 Feasibility of project ................................................................................................................. 6
1.12.1 Economic feasibility ................................................................................................................ 6
1.12.2 Behavioral/Political feasibility ................................................................................................. 7
1.12.3 Schedule feasibility ................................................................................................................. 8
1.12.4 Operational feasibility ............................................................................................................. 9
1.12.5 Technical feasibility ................................................................................................................. 9
1.12.6 Political Feasibility ................................................................................................................... 9
1.13 Methodology for the Project..................................................................................................... 9
1.13.1 Data source ............................................................................................................................. 9
1.13.2 Data Source .......................................................................................................................... 10

iii
 1.14 Fact finding techniques .............................................................................................................. 10
1.14.1 Interview .............................................................................................................................. 10
1.14.2 Practical Observation ............................................................................................................ 10
1.14.3 Document Analysis ............................................................................................................... 10
1.15 Systems Analysis and Design ...................................................................................................... 11
1.16 Development Tools .................................................................................................................... 11
1.17 Testing procedures .................................................................................................................... 12
1.18 Implementation ......................................................................................................................... 12
1.19 Risk and Assumptions ................................................................................................................ 12
1.20 Testing Procedures .................................................................................................................... 13
Chapter Two .......................................................................................................................................... 14
2. Description of the Existing System .................................................................................................... 14
2.1 Introduction of Existing System ................................................................................................... 14
2.2 Players in the existing system....................................................................................................... 14
2.3 Major functions/activities in the existing system like inputs, processes & outputs ......................... 15
2.4 Business rules .............................................................................................................................. 16
2.5 Report generated in the existing system ........................................................................................ 16
2.6 Forms and other documents of the existing systems ...................................................................... 16
2.7 Bottlenecks of the existing system................................................................................................ 17
2.7.1 Performance (Response time).................................................................................................. 17
2.7.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate .................................................. 17
2.7.3 Security and Controls .............................................................................................................. 17
2.7.4 Efficiency ............................................................................................................................... 17
2.8 Proposed solution of the new system that address problems of the existing system ....................... 17
2.9 Requirements of the Proposed System .......................................................................................... 18
2. 9.1 Functional requirements ......................................................................................................... 18
2. 9.2 Nonfunctional requirements ................................................................................................... 20
Chapter Three........................................................................................................................................ 22
3. System Analysis ................................................................................................................................ 22
3.1 Introduction ................................................................................................................................. 22
3.2 System Requirement Specifications (SRS) ................................................................................... 22
3.2.1 Use case diagrams................................................................................................................... 22

iv
3.2.2 Use case documentation .......................................................................................................... 24
3.2.3 Sequence diagram ................................................................................................................... 36
3.2.4 Activity Diagram .................................................................................................................... 42
3.2.5 Analysis level class diagram (conceptual modeling) ................................................................ 47
3.2.6 User Interface Prototyping ...................................................................................................... 47
3.2.7 Supplementary specifications .................................................................................................. 48

v
Acronyms

AMIT Arba Minch Institute of Technology

AMU Arba Minch University.
CSMS Class Schedule Management System

vi
List of Tables
Table 1 Team composition ..........................................................................................................3
Table 2 Hardware costs ...............................................................................................................7
Table 3 Software costs ................................................................................................................7
Table 4 Schedule of the project ...................................................................................................8
Table 5 hardware requirements.................................................................................................. 11
Table 6 Software requirement ................................................................................................... 11
Table 7 functional requirement for making class schedule ......................................................... 18
Table 8 functional requirement for edit class schedule ............................................................... 19
Table 9 functional requirement for view class schedule ............................................................. 19
Table 10 functional requirement for teacher view class schedule .............................................. 19
Table 11 functional requirement for student view class schedule ............................................... 20
Table 12 Use case documentation for Login .............................................................................. 24
Table 13 Use case documentation for manage user .................................................................... 25
Table 14 Use case documentation for entry data of teacher. ....................................................... 26
Table 15 Use case documentation for entry data of section. ....................................................... 27
Table 16 Use case documentation for entry data of subject. ....................................................... 28
Table 17 Use case documentation for entry data of room. .......................................................... 29
Table 18 Use case documentation for entry data of department.................................................. 31
Table 19 Use case documentation for entry data of year. ........................................................... 32
Table 20 Use case documentation for make class schedule. ....................................................... 33
Table 21 Use case documentation for view history log. ............................................................. 34
Table 23 Use case documentation for view class schedule. ........................................................ 35

vii
List of Figures
Figure 1 Class schedule system ................................................................................................. 16
Figure 2 Use case Diagram ........................................................................................................ 24
Figure 3 Sequence diagram for login admin .............................................................................. 36
Figure 4 Sequence diagram for make schedule .......................................................................... 37
Figure 5 Sequence diagram for add data .................................................................................... 38
Figure 6 Sequence diagram to delete data .................................................................................. 39
Figure 7 Sequence diagram to edit data ..................................................................................... 40
Figure 8 Sequence diagram for view class schedule .................................................................. 41
Figure 9 Activity diagram of Login ........................................................................................... 42
Figure 10 Activity diagram of entry data ................................................................................... 43
Figure 11 Activity diagram of make class schedule ................................................................... 44
Figure 12 Activity diagram of view history log ......................................................................... 45
Figure 13 Activity diagram of view class schedule .................................................................... 46
Figure 14 Analysis model class diagram of schedule ................................................................. 47
Figure 15 User Interface Prototyping ......................................................................................... 48

viii
 Chapter One
1. Introduction
The world seems to be rapidly evolving towards modernization and continuously gearing up on
becoming a technology driven planet because of the changes information technology offers.
Computer infrastructures have already invaded various aspects of our lives. They have become
vital instruments in our activities. More and more establishments, institutions and organizations
both public and private, are instituting IT systems in their operations to achieve better speed,
accuracy and efficiency in the quality of their works. Obviously, the academe is one of the
sectors that if would be granted the appropriate information systems could benefit most from the
modernization brought about by the technology. And an information system that would eliminate
the tedious task of manual scheduling or time tabling of the availability of faculty, students and
classrooms is one of the greatest contribution that the Computer science could impart in
institutions specially in larger universities where there is vast amount of resources.

Class Scheduling Management System of universities is a large, complex, and time consuming
task. Along the time line of each, classroom slots must be able to be allocated to instructors and
their classes of different departments without violating any predefined rules or constraints. Class
Scheduling System is software that improves and speeds up the process of room utilization and
scheduling of classes by making it more accurate, efficient and suitable to everyone impacted by
these processes. The system has features that can provide a database for storing records and
information. It allows the end-user to add, edit, delete, save and update records or information if
some changes occur. It can generate reports such as class schedule, room schedule, instructors
list, room list and section list.

1.1 Background of the study

AMIT is the faculty in Arba Minch University containing 10 departments each department
hosting huge number of students. For each section of students, the institute performs different
kinds of operations such as scheduling classes & exam, registering students, publishing students’
grade and so on. Class scheduling is one of these activities that require more attention. The
scheduler schedules time and classes for lecture class, laboratory class schedules without
overlapping. When this scheduling is performed it requires critical thinking and needs more time
to schedule manually. Still now there is no automated system for class scheduling.

1
For this reason, we want to generate an automated Class Scheduling Management System
(CSMS) for institute of AMIT.

1.2 Vision of AMU

Arba Minch University aspires to be a leading University in Ethiopia, a center of excellence in

the field of water resources in Africa and competitive in the world by 2020.

1.3 Mission AMU

Arba Minch University has a mission of offering relevant and quality education and training;
conducting demand driven research and rendering accessible community services. AMU is
mandated to:

 Establish, organize and determine the status, functions and responsibilities of academic units,
and close down any of them when appropriate;
 Design and implement undergraduate and graduate programs and short-term trainings in
accordance with the needs of the country;
 Publish and disseminate research works as well as hold discussion forums to deliberate up;
 Establish and run academic journals and newsletters;
 Upgrade the qualifications of its academic staff and enhance their professional competency;
 Contribute specially to the institutional capacity building of other public and nonprofit
making private institutions, including the upgrading of the qualifications of their academic
staffs;
 Provide consultancy services to government, industries and communities;
 Organize modern library services and provide access to entitled users;
 Cooperate with the agency on education relevance and quality matters;
 Charge appropriate fees for its services when warranted;
 Carry out such other activities that accord with its objectives.

1.4 Team composition

The team of this project comprises 4 Computer science undergraduate students with experience
of doing different mini projects. The ultimate objective of the team members is to develop a
reliable and proficient Class Schedule Management System.

2
1.5 Background of the project
Student and department number is growing rapidly in Arba Minch University. So, manual
process of recording, retrieving and updating each record is getting to be very tedious. Routine
student and faculty inquiries cannot be readily providing whatever the expected information
using the existing system on time due to its bulky nature.

Conflicts in clash of class records and scheduler have to be manually attended by registration
office personnel when update is needed. During peak transaction times for each new semester,
scheduling lines are getting longer as well as every user waiting and processing time. With the
current process involved and the mounting frustrations and complaints from students, faculty and
university personnel alike, there is an urgent need to develop the university have automated
scheduling system.

Table 1 Team composition

Prepared No. Name ID. No. Email/Mobile Responsibility

By 1 Kalkidan Deresse EVAMIT/027/13 Participate in all

tasks
2 Emru Erade EVAMIT/105/13 Participate in all
tasks

3 Bahiru Dikosa EVAMIT/008/13 Participate in all

tasks
4 Desalgne Demeke EVAMIT/017/13 Participate in all
tasks
Date January, 2025

Advisor Mr. Alemseged K.(Asst. Prof)

1.6 Statement of the problem

Class Scheduling is being performed currently by the manual system. It requires more effort and
time. And it is difficult to handle the schedule quickly in the manual system. The current system
consumes more time and other resources, like paper and printer color. Correlated problems such
as class and time delay during the beginning of every semester. Including these facts there are
number of problems with the existing system. Such as: -

3
  Difficult to identify who is assigned to which department and group.
 Clashing of instructor, room and labs etc.
 Shortage of resource (such as paper, printer color and etc.).
 Not simple to correct any conflicts and clashes in schedules.
 Require more labor force during schedule.
 Time wastage to schedule the data.

1.7 The Objectives of the Study

1.7.1 General objectives
The general objective of this project is to develop web based Class Scheduling Management
System for AMIT.
1.7.2 Specific Objectives
The following are specific objectives that this project is going to achieve.

 To analysis existing system

 To design proposed system
 To create a data base which record the information about room, lecture, student group,
and course information.
 To develop schedule/timetable module.
 To develop update or edit class schedule module
 To view and print updated timetable.
1.8 Scope of project
The scope of this system is to develop Class Schedule management system, which can improve
the current system that is in use. In order to achieve the Objectives, due to the time constraints,
the scope of the timetable system covers the following features and functions:
An administrative Section which includes the following:
 Login
 Class scheduling.
 Edit and delete class schedule.
 View class schedule
 Manage user account.

4
A lecturers’ Section which includes the following: -

 View the schedule

 print the schedule
 Download the schedule
A students’ Section which includes the following: -

 View the schedule

 print the schedule
 Download the schedule
1.9 Limitations of the project
The project is limited to only AMIT. The project is not concerned about the other colleges and
schools. Below are some of the limitations that may hinder the functionalities of the system:

 Unserious collaborative work from staffs in the various departments.

 Incomplete data from data collaborators.
 Wrong data input by technical user: the system will only work with data supplied; hence
wrong data input might have to be edited manually.
 Wrong constraints specification.
 Lack of successful algorithm to do our system.
 The system will not work properly unless network connection is available at the time
 The system will not work properly unless the user device has enough balance to access
internet.

1.10 Significance of the project

The Significance of the project is listed below: -
 To make class schedule.
 To view class schedule.
 To print and download class schedule.
 To know how many rooms and labs at AMIT.
 It reduces resource expenditure of the university that exposed to prepare schedule.
 It reduces time wastage.

5
  It provides distributed and equal information through online for all students, lectures and
for other concerning bodies.
 It avoids data lost and it keeps data available at any time.
 It provides security for the data.
 Many tasks are automated.
1.11 Target beneficiaries of the system
Target beneficiaries of Class scheduling Management System are: -
 Student: -Student can view and print schedule in easy way.
 Lecturers: -Lecturers can also view and print and teach the student according to the
schedule.
 Department: - They can view, download and print the schedule
 Institute of AMIT: - They are view, download and print the schedule

1.12 Feasibility of project

This phase is to evaluate the Class scheduling Management System to determine the difficulties
to carry out the designed task and to check whether the cost and benefits of the proposed project
is achievable from different point of view. For instance, in developing of the project, we
considering all the following points of feasibility.

 Operational feasibility
 Technical feasibility
 Economic feasibility
 Political/Behavioral Feasibility
 schedule feasibility

1.12.1 Economic feasibility

Economic feasibility is concerned with assessing the financial benefits and the cost association
with our project to generate economic benefits. It referred to as cost benefits, analysis. At the
time of project initiation and planning, that is not possible to clarify correctively all the benefits
and cost that related to our project specifically, even if it is important aspect. Is the action taken
to determine how well, how poorly? It is commonly done on financial question.

6
The refined cost benefit analysis will be presented as follow. In our project, we analyzed the
costs in terms of tangible and intangible to clear out the benefits.

Table 2 Hardware costs

No Materials used Amount Price per Birr Total cost

1 HP Computer 1 30,000 30,000

2 Pen 10 25 250

3 Document print 1 500 500

4 Flash Disk 1(4 GB) 300 500

Total 31,250

Table 3 Software costs

No Materials used Price per Birr

1 Microsoft Word 2021 Free

2 Visual Studio Free

3 E-draw Free

6 Mozilla Firefox Free

7 Chrome Free

8 Android studio Free

Total 0

1.12.2 Behavioral/Political feasibility

This includes the following questions:
 Is there sufficient support for the users?

 Will the proposed design cause harm?

The project would be beneficial because it satisfies the objectives of university when designed
and developed after completing the implementation it spreads in to all campuses.

7
Since the user interface is very simple and easily understandable, no training is
required for using this project. Hence the project is behaviorally feasible.

1.12.3 Schedule feasibility

Schedule feasibility is making sure whether potential time frames and completion data can be
meeting or not. The project team members discussed on it to work hardly and also estimate
project to be completed on time without any delay. For organization replacing current systems
with automated one is advisable for better performance. To replace the current system,
developers (we) should make the whole plan before starting to develop a computerized system.
In order to develop this project, we have planned all the necessary tasks. In order to accomplish
time effectively and efficiently, we used the Gant charts to schedule time in all phases of project
we do. It’s important for group teams in case of managing time to complete this project as
scheduled.

Table 4 Schedule of the project

Activity Time (2024/5)

Feb 26-may
Feb 25
Feb 19-
Feb 18
Feb 1
Jan 15-

Jun1-
Jan 30

20
30

Project Proposal

Requirement Analysis

System Design

Implementation & coding

Testing

Project defense

8
1.12.4 Operational feasibility

The user should not misuse the system. To determine the operational feasibility of the system we
should take into consideration the knowledge level of the users. Initially this system is proposed
to be designed to who use computer. The application is expected to be very flexible for its users.
And this is also one of the factors that make it operationally feasible.
1.12.5 Technical feasibility
Technical feasibility is assessing the organization ability to construct easy way of scheduling.
CSMS is technically feasible because it need all required hardware and software tools that are
available in the system. Almost all of accomplishments of this project are acquired by the group
member through predicated course given at AMU. Further skill required will be attained through
research and reading. E.g. Reading some information from internet and following some tutorial.

1.12.6 Political Feasibility

The project team members will build the system without violating the rules and regulations of the
governments as well as the organization. The system being built is for the sake of the productivit y
of the organization and customers so that the project is legally feasible.
1.13 Methodology for the Project

1.13.1 Data source

The team chooses object oriented analysis and design approach to analyze and design the system,
based on our preliminary analysis of the old system. In our project the team will use Object
Oriented Software Development Methodology (OOSD) because it has the following advantages:

 Increase reusability: - the object oriented provides opportunities for reuse through the
concepts of inheritance, polymorphism, encapsulation and modularity.
 Increased extensibility: - when there is a need to add new feature to the system you only
need to make changes.
 Improved quality: - quality of our system must be on time and meet our exceeded the
expectation of the users of our system, improved quality comes from increased participation
of users in the system development.

9
 Managed complexity: -The object- oriented methods solve software complexity in this way.
Design our software the expectation that it will need to be modified and being able to
respond quickly when our environment changed.
1.13.2 Data Source
 Registrar office of the AMIT
 scheduler of the AMIT
 Documented Files.
 Department of AMIT

1.14 Fact finding techniques

We try to collect the necessary data or information for the project from AMU staff Venders,
department head, our project Advisor and AMIT Registrar Office. There are different kinds of
methods to collect data. Among those we have used three major methods in order to gather
requirement for the project three of them. These are:

1.14.1 Interview
This was the most exhaustible method of data collection. The team used their data superior
collection skills to extract data from registrar office and department. The interviewers created a
conductive environment in which the interviewees could feel free to let out the best they could
that helped the team come up with the most effective system to fulfill their needs.

Among the data collected the following was highlighted to be of a great consideration: how they
make schedule and how they fix errors.

1.14.2 Practical Observation

The team closely observed the schedulers’ activities how they prepare current schedules. And
again we observe how the scheduler handles errors using the current system which it is a very
bulky and it requires more time. Information’s don’t reach to students, teachers, and department
on time.

1.14.3 Document Analysis

We will refer current scheduling document of Arba Minch Institute of Technology and we
observe how they make schedule and how they handle errors.

10
1.15 Systems Analysis and Design
In this project we used Object Oriented System Development methodology (OOSD). This has two phases.

Object Oriented Analysis (OOA): During this phase the team used to Model the functions of the
system (use case modeling), Find and identify the business objects, Organize the objects and identify the
relationship between them and finally model the behavior of the objects.

Object Oriented Design (OOD): During this phase the team used to refine the use case model to
reflect the implementation environment, Model object interactions and behaviors that support the use case
scenario, and finally update object model to reflect the implementation environment.

1.16 Development Tools

Table 5 hardware requirements

Device Size/Type

Processor Intel(R) Core 3 Duo

RAM 2:00 GB

Hard Disk 500GB Available Storage

Table 6 Software requirement

Activities Tools
Client side scripting JavaScript
Client side Coding HTML
Platform MS windows
Database Server MySQL
Server side Scripting PHP
Browsers Google Chrome/Mozilla Firefox
Editor Edraw Max,Notepad++
Documentation MS Word
Presentation MS PowerPoint

11
1.17 Testing procedures
We will perform different testing procedures for checking functionality of our proposed system.

1.17.1 Unit testing: - First we will test each unit at each system. So, if a problem is encountered
it will immediately maintain at which the problem is occurred.

1.17.2 Integration Testing: -After we test each unit of the proposed system we will perform an
integration test to check whether the system meets all the functional requirements. When a
number of components are complete; it will test to ensure that they integrate well with each
other, the operating system, and other components.
1.18.3. System testing: -After all of the above testing are checked we will test our system by
other peoples and we will conduct some comments how they get our system.
1.18 Implementation
To implement our system, we will use different tools such as hypertext markup language
(HTML) for client side scripting, Java Script for validation, MySQL for database server, Apache
for web server, hypertext pre-processor (PHP) for server side scripting, and Notepad++ for
writing codes.

1.19 Risk and Assumptions

Technical risks: These risks may result from excessive constraints, lack of experience, poorly
defined parameters, or dependencies on organizations outside the direct control of the protect
team. In order to mitigate this risk, the team will perform periodic checks on the work.
Requirement changes: since this risk leads to system poor communication resulting in
misunderstandings, quality problems and rework, the team altered participatory type of data
modeling to overcome such risks. Since, the team discusses with the scheduler when needed in
each phase, the team will handle this risk before it leads to system rework.
The project team chooses this iterative data model because:
 Building and improving the project is step by step.
 Can get the reliable user feedback.
 Less time is spent on documenting and more time is given for designing.
 Can only create a high-level design of the application before we actually begin to build.

12
1.20 Testing Procedures

The web based class schedule management system will be tested using the following system
testing procedures.
A. Functional Testing

Unit Testing: - Every module of the system is separately tested. i.e., the team tests every module
by applying some selection mechanism. Through this mechanism every module gets tested. If an
error occurs correction will be taken without affecting another module.
Integration Testing: - In this testing part all the modules will be combined together and tested it
for its fitness with the each other and with the system functionality. If error occurs in combining
them, the module with problem will be identified and recombined. Both unit testing and
integrated testing is performed by all team members at the workplace.
System Testing: Here compile the whole system stating from initial and proceeds testing the
whole system checks out for errors and flow control of the system.
Acceptance Testing: Is a level of software testing where the system is tested for acceptably. The
purpose of this test is to evaluate the systems compliance with the business requirements and
assess whether it is acceptable for delivery and used to determine whether or not the system
satisfies the acceptances criteria and to enable the use, customers or other authorized entity to
determine whether or not to accept the system.
B. Non-Functional Testing

Security Testing: Is done to check how the software, application, or website is secure from
internal and/or external threats. This testing includes how much software is secure from
malicious programs, viruses and how secure & strong the authorization and authentication
processes are.
Performance Testing: Is testing of an application’s stability and response time by applying
load.
Usability Testing: Is testing an application from the user’s perspective to check the look and feel
and user-friendliness.
Compatibility Testing: - Is testing the compatibility of software on different device. We will
perform different testing for checking the functionality of our proposed system.

13
 Chapter Two

2. Description of the Existing System

2.1 Introduction of Existing System

The current system of class scheduling management system is a manual. Class scheduling is
prepared by concerning Institute, departments, batches and groups based on academic calendar.
Currently the registrar director or responsible body for developing the schedule prepares
schedule by checking all of the resource in the system (such as: number of section, instructor,
course offer and credit hour) with the following method.

 Prepare a table which contains appropriate format for timetable

 Select one row
 Select one course and write on each field
 Scheduler: considering the credit hour for each course, the scheduler will not assign two
consecutive periods for those courses that have the same credit hours. It assigns two
different periods by postponing one credit hour for another day.
 During the scheduling process, if free period/s is available, the scheduler allocates that
period for another course.
 Select another course and schedule on the rest period of the day in similar way up to the
end of the day period and proceed to the next date.

2.2 Players in the existing system

 Office of registrar: prepare the Class Scheduling Management System of the university
each year includes with president and vice president and submit the same to the senate for
approval.
 Institute: give the comment for prepared schedule and transfer to the department.
 Department: accepting the prepared schedule and give comment if there is overlap.
 Instructor: based on the schedule they teach students.

14
 Student: they learn based on schedule

2.3 Major functions/activities in the existing system like inputs, processes & outputs

The major function of scheduling management system is preparing schedule for instructor and
students based on the academic calendar. It announces for student’s class and time. Activities in
existing system of schedule: -

Input: when preparing the schedule office of registrar uses:

Course offering form for each department like

 Course name
 Course code
 Course credit hour
 Instructor name
 Block and class room
 Period of the course per week

Process:

 Collecting course offering from each department.

 Recording (inserting) the information of the course offering in table columns heading based
on number of course with arrows.
 Preparing a table of total course working hours with six days of the week.
 After the preparation of the format allocation of the time for each course based on its credit,
is being given and allocated randomly.
 After the completion of the table source preparing the tentative schedule by recording what
has been allocated in the above.
 And printing the tentative schedule and send to the concerned departments and stake holders
and posted to the students.
 After being commented by each department the final schedule is being prepared by making
edition.

Output: -post the final schedule for all students and send to the department .

15
2.4 Business rules
 Each department should submit the course offering to the registrar before a month.
 Each department should give the comment on the prepared schedule.
 The institute schedule shall provide the class period, from beginning to end of Semesters.
 In holidays time the schedule will not function.
 If one course has more credit hours, it may have more than one period in a week.

2.5 Report generated in the existing system

There is no generated report in the existing system. Except that there sending the prepared
schedule from registrar up to departments. The registrar sends prepared schedule to the following

 Institute
 president officer
 vise president officer
 Quality officer

2.6 Forms and other documents of the existing systems

Figure 1 Class schedule system

16
2.7 Bottlenecks of the existing system
2.7.1 Performance (Response time)
 The performance of scheduling management system on response time has poor
performance. That means it takes more time when they preparing the schedule.

2.7.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate

Input:

 Data is not correctly captured (gathered) because the system is manual it leads to
redundancy.
 Data is not flexible: not easy to meet new information needs from stored data

Output:
 tentative of the schedule

2.7.3 Security and Controls

Have no security and control mechanism even if someone may take the posted schedule before
students view their schedule.

2.7.4 Efficiency
The current system is not efficient because it takes too much time to generate the schedule.
During scheduling process clash of room may occur i.e. two classes at same time and room may
be assigned. It needs extra resources like time, paper, color, etc.

Practices to be preserved

 The schedule is preparing by using table.

 The other thing is data collection mechanism. It is the same as with the existing system.
 Each department should submit the course offering to the registrar before a month.
 Each department should give the comment on the prepared schedule within three days.
 The schedule provides the class period at beginning and end of Semesters.

2.8 Proposed solution of the new system that address problems of the existing system
Since the new system that we are interested to develop computerized, it can easily solve the
problem of the current system So that, the new system also has the following similar scope and

17
Functionality with the existing system but with different implementation that is prepare schedule
that are computerized.

To solve problems by using data base connection update data, insert data, delete data for avoid
overlap and clashing,

 Updating of class scheduling means that if there is coming of new instructor then the
schedule will be inserting of that instructor with lectured course so by inserting the
instructor and course we avoid class missing for the student and instructor.
 Insert data when there is add and drop course is occurred that means to update the
schedule we insert data like adding or inserting added course instead of dropped course.
 Avoid clashing that occurred during schedule by checking and referring the redundant
classes with in the schedule using validation.
 Make more reliable and effective by announcing the instructor to which department and
group is lectured. The schedule is done for each and every department.
 Minimizing time taken by developing automate system it reduces human power and time
taken since it is computerized
 Based on academic calendar management system displaying of the message like class and
exam schedule on time.

2.9 Requirements of the Proposed System

2. 9.1 Functional requirements
The new system has basic functional requirements to perform system functionality. The
functional requirements of this project are make schedule, update schedule, print and view
schedule, and add course, department and room in the database.
Administrative Section
Table 7 functional requirement for making class schedule

Requirement ID and Requirement R1:Make class schedule

Description The system administrator generates or make class

schedule by filling all forms in add schedule page. such
forms are course id, room, semester, year and etc.

Input Course id, section, room, semester, year

18
Output Class Schedule is successfully add to the data base

Storage Store in class schedule table

Table 8 functional requirement for edit class schedule

Requirement ID R2:Edit class schedule

and Requirement

Description By using class update page the system administration update the schedule
when there is error in the schedule.

Input Edit and delete button

Output Class schedule is updated successfully and saved in the data base

Storage Store in class schedule table

Table 9 functional requirement for view class schedule

Requirement ID R3:admin view class schedule

and Requirement

Description The administrator can view the schedule by select the schedule year and
department. And again the admin can print the schedule by hit print button.

Input Year, department

Output Class schedule of a give department and year.

A lecturers’ Section:

Table 10 functional requirement for teacher view class schedule

Requirement ID R4:lecture view class schedule

and Requirement

Description The lectures can view schedule in understandable manner. the lecturer should
able to view must select department and year. and again they can print the
schedule

19
Input Department and year

Output Class schedule display on the screen.

A students’ section

Table 11 functional requirement for student view class schedule

Requirement ID R9:student view class schedule

and Requirement

Description The students can view schedule in understandable manner. The student should
able to view must select department and year. and again they can print the
schedule

Input Department and year

Output Class schedule display on the screen.

2. 9.2 Nonfunctional requirements

Nonfunctional requirements deals with the qualities of the application system

needed to be developed from different evaluation point of view like the response time of the
application to a given user queries, the user friend lines of the application and this requirement
do not directly affect the performance of the system, but they are not that much important. There
are many non-functional requirements ranging from user interface to security issues.
Generally non-functional requirements of the system can be viewed as follows.

2.9.2.1 Performance
 Speed: - the system should perform at optimum speed at normal circumstances (i.e., when
networks and nodes are ok).
 Robustness: - The system should be tolerant of errors and produce error reports that are
simple to be understood by the users.
 Reliability: - The system should be reliable in generating schedule without any conflict.
2.9.2.2 User Interface
Since there are potentially many users of this system, it will have different types of user
interface. It will include the necessary features for each user so the application will have a user

20
friendly interface for low knowledge of computer users, and simple and interactive user interface
components should be part of the system.

2.9.2.3 Security and Access permission

The system should be protected with different security features (techniques) on both the
software and hardware part.

On software part: - on this part the admin who wants to login to the system must be enter
correct user name and password. This protects the system from any unauthorized access. Without
scheduler other users can’t edit, insert, delete any data, but they can view/see only the data exist.

On hardware part: - the server is expected to be placed in a secured room.

2.9.2.4 Backup and Recovery

To recover a data, we will have a copy of the original data in another place. Like CD, DVD,
flash desk, email etc.

21
 Chapter Three
3. System Analysis

3.1 Introduction
Modeling helps the analyst to understand the functionality of the system we are going to develop
and models are used to communicate with users of the system. Different models present the
system from different perspectives.

 External perspective showing the system’s context or environment.

 Behavioral perspective showing the behavior of the proposed system.
 Structural perspective showing the system or data architecture.
In this project, we use an Object-Oriented Analysis and Object-oriented Design. That will help
us to design the use case modeling, class diagram, Sequence diagram, activity diagrams, and user
interface of the Class Schedule System.

3.2 System Requirement Specifications (SRS)

The following lists of objects are System Requirement Specifications (SRS) for class scheduling
management system in Arba Minch Institute of Technology.

 Use Case diagram list and their details description

 Actors
 Sequence diagram.
 Activity diagram. Analysis
 Level class diagram.
 User Interface prototyping diagram

3.2.1 Use case diagrams

Use case defines set of interaction between actor and the proposed system under consideration. It
is a methodology used in system analysis to identify, clarify, and organize system requirements.
It should contain all system activities that have significance to users. Use case are used during

22
requirement analysis to represent the functionality of the system we are going to develop and It
also describes function provided by the system that yields a visible result for any actor. Actor
describes any entity that interacts with the system proposed. It may be class of users, roles user
can play, or other system.

Essential use cases that the proposed system consists are: -

 Login
 Manage account
 Entry data
 Make schedule
 View history log
 View schedule

23
 Class Schedule Management System
Login

Manage User
Add
Add Teacher Add Add
Admin Dept Section Subject
<<include>>
Add
<<include>>
<<include>> <<include>> Room
<<include>>
<<include>> Add
Year
Entry Data

Make
Schedule

Institute
Dept
View History Head

Download
Schedule

View Schedule

Lecture Student
Print
Schedule

Figure 2 Use case Diagram

3.2.2 Use case documentation
This is the step by step description of the actions performed by each use case contains
precondition, post condition, main course of action, use case alternate course of action if any and
steps of actions.

Table 12 Use case documentation for Login

Use case ID UC01

24
Use case name Login

Actor Admin

Description Used for security system validate to access or account authentication. The system
admin must login the system.

Precondition The admin must have password and user name

post condition After login perform his/her task.

Flow of events Actor action System response

Admin wants to login to the system 1.1 Display home page

follow the following step 2.1 The system displays login page

1. Browse the system 4.1 The system check entered user name and
2. Click on admin login password is valid or not
button.
4.2 If the entered password and user name is
3. Fill user name and
valid, display the admin home page of the
password form.
actor.
4. Click on login button.
4.3 If the entered password and user name is
invalid display error message and login page.

alternative If entered user name and password is not correct, error message is displayed.

Table 13 Use case documentation for manage user

Use case ID UC02

Use case name Manage user

actor Admin

25
description The administrators after login in his/her site he/she create, delete, and edit account.

Precondition The admin must have user name and password and he/she must be login to admin
home page.

post condition The user account is displayed in the table by alphabetical order.

Flow of events Actor action System response

1. Admin wants to manage user 2.1 displays add user button and the
account registered user data in alphabetical
2. Click on the user account. order.

3.1 The system display add user form.

5.1 The system saves all entered data in

3. If he/she need to add another the table.

user, he/she click on add user
button.
4. Fill all form of user account.
5. Click on save button.
alternative All forms of add user form is must filled with proper data, if not the system display
error message.

Table 14 Use case documentation for entry data of teacher.

Use case ID UC03

Use case name Entry data

26
actor Admin

description The administrator after login to admin page enters teacher’s full name,
department and any other information in to data base.

Precondition The admin have to click entry button after login.

post condition Entered data displayed in table form in alphabetical order.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on entry button. 2.1 displays entry page

3. Click on add teacher button. 3.1 displays add data form

4. Fill all forms of teacher and click on 4.1 if the form is fill correctly the
save button. entered data will be saved in data base

4.2 if the form is not fill correctly

display error message and the form.

alternative 1. If admin need any correction, he/she click on the edit button and change
the data in the data base and he/she can save edited data in data base.
2. If admin want to delete the data he/she click delete button and the data
will removed from data base

Table 15 Use case documentation for entry data of section.

Use case ID UC04

27
Use case name Entry data

actor Admin

description The administrator after login to admin page enters section name and department of
the group in to data base.

Precondition The admin have to click entry button after login.

post condition Entered data displayed in table form in alphabetical order.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on entry button. 2.1 displays entry page

3. Click on add section button. 3.1 displays add section form

4. Fill all forms of section and click on 4.1 if the form is fill correctly the
save button. entered data will be saved in data base

4.2 If the form is not fill correctly

display error message and the form.

alternative 1. If admin need any correction, he/she click on the edit button and change the
data in the data base and he/she can save edited data in data base.
2. If admin want to delete the data he/she click delete button and the data will
removed from data base

Table 16 Use case documentation for entry data of subject.

28
Use case ID UC05

Use case name Entry data

actor Admin

description The administrator after login to admin page enters subject title, subject code and
other information in to data base.

Precondition The admin have to click entry button after login.

post condition Entered data displayed in table form in alphabetical order.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on entry button. 2.1 displays entry page

3. Click on add subject button. 3.1 displays add subject form

4. Fill all forms of subject and click on 4.1 if the form is fill correctly the
save button. entered data will be saved in data base

4.2 If the form is not fill correctly

display error message and the form.

alternative 1. If admin need any correction, he/she click on the edit button and change the
data in the data base and he/she can save edited data in data base.
2. If admin want to delete the data he/she click delete button and the data will
removed from data base

Table 17 Use case documentation for entry data of room.

29
Use case ID UC06

Use case name Entry data

actor Admin

description The administrator after login to admin page enters room name and description
in to data base.

Precondition The admin have to click entry button after login.

post condition Entered data displayed in table form in alphabetical order.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on entry button. 2.1 displays entry page

3. Click on add room button. 3.1 displays add room form

4. Fill all forms of room and click on 4.1 the entered data will be saved in
save button. data base

alternative 1. If admin need any correction, he/she click on the edit button and
change the data in the data base and he/she can save edited data in
data base.
2. If admin want to delete the data he/she click delete button and the data
will removed from data base

30
Table 18 Use case documentation for entry data of department.

Use case ID UC07

Use case name Entry data

actor Admin

description The administrator after login to admin page enters department information in
to data base.

Precondition The admin have to click entry button after login.

post condition Entered data displayed in table form in alphabetical order.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on entry button. 2.1 displays entry page

3. Click on add department button. 3.1 displays add department form

4. Fill all forms of department and 4.1 if the form is fill correctly the
click on save button. entered data will be saved in data
base

4.2 If the form is not fill correctly

display error message and the form.

alternative 1. If admin need any correction, he/she click on the edit button and
change the data in the data base and he/she can save edited data in
data base.
2. If admin want to delete the data he/she click delete button and the
data will removed from data base

31
Table 19 Use case documentation for entry data of year.

Use case ID UC08

Use case name Entry data

actor Admin

description The administrator after login to admin page enters school year in to data base.

Precondition The admin have to click entry button after login.

post condition Entered data displayed in table form in alphabetical order.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on entry button. 2.1 displays entry page

3. Click on add school year button. 3.1 displays add school year form

4. Fill all forms of school year and 4.1 if the form is fill correctly the
click on save button. entered data will be saved in data base

4.2 If the form is not fill correctly

display error message and the form.

alternative 1. If admin need any correction, he/she click on the edit button and change
the data in the data base and he/she can save edited data in data base.
2. If admin want to delete the data he/she click delete button and the data
will removed from data base

32
Table 20 Use case documentation for make class schedule.

Use case ID UC09

Use case name Make class schedule

actor Admin

description The administrator of the system is generating class schedule by filling class
schedule form in their page.

Precondition The admin have to click on the class schedule after login his/her page

post condition Entered data displayed in table form in alphabetical order.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on class schedule button. 2.1 displays add class schedule button
and privies entered data in the table.
3. Click on add class schedule button.
3.1 displays add class schedule form
4. Fill all forms of class schedule and
click on save button. 4.1 if the form is fill correctly the
entered data will be saved in data base

4.2 If the form is not fill correctly

display error message and the form.

alternative 1. The schedule maker must fill all forms, which are display in the add
class schedule page

33
Table 21 Use case documentation for view history log.

Use case ID UC11

Use case name view history log

actor Admin

description The administrator of the system can view who does what in the system and at
what time action have done. In history log the system record all information
what change occur in what time and date. This uses for security purpose.

Precondition The admin login in his/her page click and click on history log button.

post condition The admin of system know who does what in what time and date.

Flow of events Actor action System response

1. Admin login to admin home page.

2. Click on history log button. 2.1 displays the history who is do

same thing in the system

alternative

34
Table 22 Use case documentation for view class schedule.

Use case ID UC12

Use case name view class schedule

actor Admin, dep’t head, lecture, student

description Everybody can view class schedule in anytime and anywhere boy open class
schedule management system.

Precondition The user must know the website of class schedule management system.

post condition View class schedule of his/her class section.

Flow of events Actor action System response

1. Open home page of class schedule

management system.
2.1 Display drop down option
2. Click on class schedule button.
3.1 Display search forms
3. Select course year section or room

4. Fill search form and click on submit 4.1 Display class schedule, print
button. schedule, and download by excel
button.

alternative If user wants to download the schedule he/she clicks on download

button and if he/she wants print click on print schedule button.

35
3.2.3 Sequence diagram
A Class Schedule sequence diagram is an interaction diagram that shows how processes operate
with one another and in what order. It is a construct of a Message Sequence Chart. It shows
object interactions arranged in time sequence and depicts the objects involved in the scenario and
the sequence of messages exchanged between the objects needed to carry out the functionality of
the scenario.

login admin
Admin homepage admin login
controler hompage

intiate brwose

display homepage

select admin login

display login form

fill the form and click login button

Validate

display login form display admin homepage

Figure 3 Sequence diagram for login admin

36
 admin schedule form
Admin schedule Data Base
homepage form controler

intiate to admin hompage

display admin homepage

select schedule

select add schedule

display form

fill the form and click save button

Validate

display form
Store to Data Base

Figure 4 Sequence diagram for make schedule

37
 admin Entry form
Admin Data Base
homepage data controler

intiate to admin hompage

display admin homepage

select entry data

display add button

click add button

display add form

fill the form and click save button

Validate

display form Store to Data Base

Figure 5 Sequence diagram for add data

38
 admin Entry delete
Admin homepage Data Base
data controler

intiate to admin hompage

display admin homepage

select entry data

display Data

select the data you want to delete

display delete button

click delete button

Are you sure you want to delete?

delete from data base

display existing data

Figure 6 Sequence diagram to delete data

39
 admin Entry edit
Data Base
homepage data controler
Admin

intiate to admin hompage

display admin homepage

select entry data

display Data

select the data you want to edit

display edit button

click edit button

display the data with in form

fill the form and click save button Validate

display existing data Store to data base

Figure 7 Sequence diagram to edit data

40
 user room/ search
Schedule Data Base
homepage course controler
user

intiate to browse hompage

dispay homepage

select schedule

select room/ course

display form

fill the form and click submit button Validate

display error message execute query

display schedule

view schedule

Figure 8 Sequence diagram for view class schedule

41
3.2.4 Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency.

Figure 9 Activity diagram of Login

42
Figure 10 Activity diagram of entry data

43
Figure 11 Activity diagram of make class schedule

44
Figure 12 Activity diagram of view history log

45
Figure 13 Activity diagram of view class schedule

46
3.2.5 Analysis level class diagram (conceptual modeling)

Figure 14 Analysis model class diagram of schedule

3.2.6 User Interface Prototyping

User interface (UI) prototyping is an iterative analysis technique in which users are actively
involved in the making the UI for a system.

47
 View Class Admin
Home Help
Schedule Login

Add Class History User

Entry Logout
Schedule Log Account

Teacher

Course Year/Section

Course/Subject

Room

Department

School Year

Figure 15 User Interface Prototyping

3.2.7 Supplementary specifications
The Supplementary Specifications capture the system requirements that are not readily captured
in the use cases of the use-case model. Such requirements include: -

 Legal and regulatory requirements and application standards.

 Quality attributes of the system to be built, including usability, reliability, performance,
and supportability requirements.
 Other requirements such as operating systems and environments, compatibility
requirements, and design constraints.

Some of the supplementary specifications are

 Help: to show the rules how to login and how to access the system.
 Related sites: the site which are related to acquire the information from other site.
 Search room class schedule: to view the room on the class schedule.
 Search course year section on class schedule: to view the course of the class schedule.

48