DEPARTMENT OF COMPUTER SCIENCE Project o

ADIGRAT UNIVERSITY
COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE
Project on
Web Based Class Scheduling System for ADU
Prepared by: - Id
1. Zerue Tlahun RET 1817/06

2. Mhret Aregay RET 1799/06
3. Yebahrnesh Tajebe RET 1814/06
4. Tsge Demewoze RET 1810/06
5. Wegene Maru RET 1393/06
6. Bizen G/meskel RET 1779/06
Advisor Name: Inst. Filmawit M.
Final project II
Submitted to Department of Computer Science, college of engineering and technology of

Adigrat University, in Partial fulfillment for the requirement of the Degree of Bachelor of
Science in (Computer Science)
ADIGRAT, ETHIOPIA
May, 2017
WEB BASED CLASS SCHEDULING SYSTEM FOR ADIGRAT UNIVERSITY
Declaration
The Project is our own and has not been presented for a degree in any other university and all
the sources of material used for the project have been duly acknowledged.
ZerueTlahun
------------------------------------- ---------------------------------------------
Name Signature
Wegenea Maru
---------------------------------- ---------------------------------------------
Name Signature
Tsige Demowez
------------------------------------- ---------------------------------------------
Name
Mhret Aregay Signature
---------------------------------- ---------------------------------------------
Name
YebahrineshTajebe Signature
------------------------------------- ---------------------------------------------
Name
Bizen Geremeskel Signature
------------------------------------- ---------------------------------------------
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM i

Approval Sheet
College: College of Engineering and Technology
Program: Computer Science
Project subject: CLASS SCHEDULING SYSTEM FOR ADU
We certify that this project satisfies all the requirements as a project for the degree of
Bachelor of Science.
TewhasomAregay
------------------------------------- ---------------------------------------------
Name of Department Head Signature
This is to certify that we have read this project and that in my opinion it is fully adequate, in
scope and quality, as a thesis for the degree of Bachelor of Science.
Filmawit Mekonen
------------------------------------- ---------------------------------------------
Name of Advisor Signature
Examining committee members Signature Date
1. Chairman ____________ ___________ ___________
2. Examiner 1 ____________ ___________ ___________
3. Examiner 2 ____________ ___________ ___________
It is approved that this project has been written in compliance with the formatting rules laid
down by the college of the university
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM ii

Acknowledgements
First of all, we would like to thank our God. Then, we would like to really thank and
appreciate our advisor instructor Filmawit M. for her remarkable comments, suggestions and
over all advice for us from starting day of project up to the enter life cycle of the project
without any tiredness. Finally, we thank the chief of Class Scheduling System Mr. Zelealem
T. of Adigrat University who helped us by providing important information during data
gathering for our project
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM iii

Table of Contents pages

Declaration ............................................................................................................................................... i
Approval Sheet........................................................................................................................................ ii
Acknowledgements ................................................................................................................................ iii
List 0f Figures ...................................................................................................................................... viii
List of Tables ......................................................................................................................................... ix
Abstract ................................................................................................................................................... x
Acronyms and Abbreviation .................................................................................................................. xi
Operational Definitions ......................................................................................................................... xii
CHAPTER ONE ..................................................................................................................................... 1
1. Introduction ..................................................................................................................................... 1
1.1 Background of the university .................................................................................................. 1
1.2 Background of the project ....................................................................................................... 1
1.3 Statement of the Problem ........................................................................................................ 2
1.4 Objectives of the project ......................................................................................................... 3
1.4.1 General Objective ........................................................................................................... 3
1.4.2 Specific Objectives ......................................................................................................... 3
1.5 Scope of the project ................................................................................................................ 3
1.6 Limitation of the project ......................................................................................................... 4
1.7 Significance of the Project ...................................................................................................... 4
1.8 Target Beneficiaries of the System ......................................................................................... 4
1.9 Methodology of the project ..................................................................................................... 5
1.9.1 Data Sources ................................................................................................................... 5
1.9.2 Fact finding technique ..................................................................................................... 5
1.9.3 System Analysis and Design Methodology .................................................................... 6
1.9.3.1 Object oriented Analysis ............................................................................................. 6
1.9.3.2 Object oriented design ................................................................................................ 6
1.9.4 Development Methodology............................................................................................. 6
1.9.5 Implementation methodology ......................................................................................... 6
1.9.5.1 Software Tools ............................................................................................................ 7
1.9.5.2 Hardware Tools ........................................................................................................... 7
1.9.6 Feasibility Studies ........................................................................................................... 7
1.9.6.1 Technical Feasibility ................................................................................................... 8
1.9.6.2 Operational Feasibility ................................................................................................ 8
1.9.6.3 Political Feasibility ..................................................................................................... 8
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM iv

1.9.6.4 Schedule feasibility ..................................................................................................... 8

1.9.6.5 Economic Feasibility................................................................................................... 9
1.9.7 Testing Procedures .......................................................................................................... 9
1.9.7.1 Unit testing: - .............................................................................................................. 9
1.9.7.2 Integration Testing:-.................................................................................................... 9
1.9.7.3 System Testing: - ........................................................................................................ 9
1.10 Task and Time schedule........................................................................................................ 10
1.11 Team composition ................................................................................................................. 11
CHAPTER TWO .................................................................................................................................. 12
2 Requirement Analysis Description ............................................................................................... 12
2.1 Overview of the Existing System.......................................................................................... 12
2.2 Player of the Existing System ............................................................................................... 12
2.3 Activities of the system ......................................................................................................... 12
2.4 Business Rule of the Existing System................................................................................... 13
2.5 Problems of the existing system............................................................................................ 13
2.5.1 Performance .................................................................................................................. 13
2.5.2 Security and controls..................................................................................................... 13
2.5.3 Efficiency ...................................................................................................................... 14
2.5.4 Input and output ............................................................................................................ 14
2.6 Report generated in the existing system ............................................................................... 14
2.7 Forms and Other Documents of the Existing System ........................................................... 14
2.8 Practices to be preserved from existing system .................................................................... 15
2.9 Overview of the Proposed System ........................................................................................ 15
2.10 Specific Requirements .......................................................................................................... 16
2.10.1 Functional Requirement ................................................................................................ 16
2.10.2 Non-Functional Requirement ........................................................................................ 18
2.11 Systems Requirement............................................................................................................ 19
2.11.1 Hardware Requirement ................................................................................................. 19
2.11.2 Software Requirement................................................................................................... 19
2.12 Constraint and Assumption ................................................................................................... 20
2.12.1 Constraints: ................................................................................................................... 20
2.12.2 Assumptions .................................................................................................................. 20
CHAPTER THREE .............................................................................................................................. 21
3 System Analysis and Modeling..................................................................................................... 21
3.1 Introduction ........................................................................................................................... 21
3.2 System Requirement Specifications (SRS) ........................................................................... 21
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM v

3.2.1 Actor Specification ....................................................................................................... 21

3.3.1 Sequence Diagram for Login ........................................................................................ 37
3.3.2 Sequence Diagram for Adding Information .................................................................. 38
3.3.3 Sequence Diagram for Update Information .................................................................. 38
3.3.4 Sequence Diagram for Delete Information ................................................................... 39
3.3.5 Sequence Diagram to Add User Account ..................................................................... 40
3.3.6 Sequence Diagram for Add Class Schedule.................................................................. 40
3.3.7 Sequence Diagram for Search Schedule ....................................................................... 41
3.4 Activity Diagram .................................................................................................................. 42
3.4.1 Activity Diagram for login ............................................................................................ 42
3.4.2 Activity Diagram for Adding Information .................................................................... 43
3.4.3 Activity Diagram for Updating Information ................................................................. 44
3.4.4 Activity Diagram for Deleting Information .................................................................. 45
3.4.5 Activity Diagram for Adding User Account ................................................................. 46
3.4.6 Activity Diagram for Adding Class Schedule ............................................................... 47
3.4.7 Activity Diagram for Searching Schedule .................................................................... 48
3.5 User Interface Prototyping .................................................................................................... 49
3.6 Supplementary specifications ............................................................................................... 50
3.6.1 Business rules................................................................................................................ 50
CHAPTER FOUR................................................................................................................................. 51
4 System design ............................................................................................................................... 51
4.1 Introduction ........................................................................................................................... 51
4.2 Design Goal .......................................................................................................................... 51
4.3 System architecture ............................................................................................................... 52
4.4 Class Diagram ....................................................................................................................... 52
4.5 State chart modeling ............................................................................................................. 53
4.6 Deployment Diagram ............................................................................................................ 57
4.7 Persistence Data Management .............................................................................................. 57
4.8 Access Control and security .................................................................................................. 60
4.9 User interface ........................................................................................................................ 61
CHAPTER FIVE .................................................................................................................................. 64
5 IMPLEMENTATION AND TESTING ........................................................................................ 64
5.1 Implementation Overview..................................................................................................... 64
5.1.1 Objective of the implementation ................................................................................... 64
5.2 Sample code and overview ................................................................................................... 64
5.3 Testing Overview .................................................................................................................. 68
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM vi

5.3.1 Test by scope................................................................................................................. 68

5.3.1.1 Unit testing ................................................................................................................ 68
5.3.1.2 Integrated testing ....................................................................................................... 69
5.3.2 Testing By Requirements .............................................................................................. 69
5.3.3 Test Implementation (Validation testing) ..................................................................... 70
5.4 Hardware Software acquisitions ........................................................................................... 70
5.5 User manual preparation ....................................................................................................... 71
5.6 Installation Process ............................................................................................................... 71
5.7 Start-up strategy .................................................................................................................... 72
CHAPTER SIX ..................................................................................................................................... 73
6 CONCLUSIONS AND RECOMMENDATION .......................................................................... 73
6.1 Conclusion ............................................................................................................................ 73
6.2 Recommendations ................................................................................................................. 73
References ............................................................................................................................................. 75
Appendix ............................................................................................................................................... 77
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM vii

List 0f Figures
Figure 1 : Final Class Scheduling Form................................................................................................ 14
Figure 2: Course offering Form which sends from department to registrar.......................................... 15
Figure 3: Use case diagrams of Scheduler, system user use and department. ...................................... 22
Figure 4: Sequence Diagram for Login................................................................................................. 37
Figure 5: Sequence Diagram for Adding Information .......................................................................... 38
Figure 6: Sequence Diagram for updating Information ........................................................................ 39
Figure 7: Sequence Diagram for Delete Information ............................................................................ 39
Figure 8: Sequence Diagram for Adding Account................................................................................ 40
Figure 9: Sequence Diagram for Add Schedule.................................................................................... 40
Figure 10: Sequence Diagram for Search Schedule .............................................................................. 41
Figure 11: Activity Diagram for login .................................................................................................. 42
Figure 12: Activity Diagram for Adding Information .......................................................................... 43
Figure 13: Activity Diagram for Updating Information ....................................................................... 44
Figure 14: Activity Diagram for Deleting Information......................................................................... 45
Figure 15: Activity Diagram for Adding User Account ....................................................................... 46
Figure 16: Activity Diagram for Adding Class Schedule ..................................................................... 47
Figure 17: Activity Diagram for Searching Schedule ........................................................................... 48
Figure 18: User Interface prototyping ................................................................................................... 49
Figure 19: System architecture model .................................................................................................. 52
Figure 20: class diagram of ADU class scheduling system .................................................................. 53
Figure 21: State Chart modeling for login ............................................................................................ 54
Figure 22: State Chart Modeling for Adding Information .................................................................... 55
Figure 23: State Chart modeling for search .......................................................................................... 56
Figure 24: deployment diagram architecture model ............................................................................. 57
Figure 25: mapping object. ................................................................................................................... 60
Figure 26: Access Control and Security. .............................................................................................. 61
Figure 27: Home Page .......................................................................................................................... 62
Figure 29: Add course offering ............................................................................................................. 62
Figure 32: Add Entry College, block etc. ............................................................................................. 63
Figure 33: Add schedule ....................................................................................................................... 63
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM viii

List of Tables
Table 1: software tools ............................................................................................................................ 7
Table 2: hardware cost ............................................................................................................................ 9
Table 3: software cost ............................................................................................................................. 9
Table 4: schedule .................................................................................................................................. 10
Table 5: team composition .................................................................................................................... 11
Table 6: use case documentation for login............................................................................................ 23
Table 7: use case documentation for create account ............................................................................. 24
Table 8:use case documentation for Manage system user .................................................................... 25
Table 9: Use case documentation for Add Faculty Information ........................................................... 26
Table 10: Use case documentation for Add Department Information .................................................. 27
Table 11: Use case documentation for Add Building Information ....................................................... 27
Table 12: Use case documentation for Add Room Information ........................................................... 28
Table 13: Use case documentation for Add Instructor Information...................................................... 29
Table 14: Use case documentation for Add Student (year and section) Information ........................... 30
Table 15: Use case documentation for Add Course information .......................................................... 30
Table 16: Use case documentation for Delete course information ....................................................... 31
Table 17: Use case documentation to Add Class Schedule .................................................................. 32
Table 18: Use case documentation to Add Class Schedule .................................................................. 33
Table 19: Use case documentation to Delete Class Schedule ............................................................... 34
Table 20: Use case documentation to Search Schedule ........................................................................ 35
Table 21: Use case documentation to Search Schedule ........................................................................ 36
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM ix

Abstract
This document proposes a Class scheduling system which is a web-based application that
manages all daily activities of Adigrat University of registrar office. The system can keep
track of registrar office adding, editing, searching, viewingand deleting of Class scheduling
system. The process of data collection will use to develop this proposal via interview and
observation and other methodology. The existing system is manual based system. We want to
change the existing manual system by new automated system. In this project we will use
object oriented system development methodology (OOSD) using php programming language
and html language from an effective design and MYSQL to database application. The project
aims at developing newly automated system that provides fast and reliable service for the
registrar office, departments, lectures and students by minimizing time and resource wastage.
Our project tries to identify the weakness of the existing system by highly investigating the
problems of the existing system and providing clear and concise solutions for those problems.
Before directly deploying this system we will perform different types of testing procedures
for its functionality. Our project specifies hardware and software requirements. The project
will be done by all the group members and each member has his/her own individual task and
is responsible for his/her tasks.
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM x

Acronyms and Abbreviation

Admin  Administrator or scheduler
ADUAdigrat University
CourseSubject
CPUCentral Processing Unit
Cr. Hr.  Credit Hours
HDDHard Disk Driver
HTTPHyper Text Transfer Protocol
InstructorTeacher
MySQLStructured Query Language (database management system)
PHPHypertext Preprocessor (text editor)
RAMRandom Access Memory
Scheduledprepared
SchedulerRegistrar Office or admin
UMLUnified Modeling Language
WAMPWindows, Apache, MySQL, and PHP/Perl/Python)
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM xi

Operational Definitions
Automation: Is the use or introduction of automatic equipment in a manufacturing or other
process or facility.
Accuracy: Is the quality or state of being correct or precise.
Availability: Is Present and ready for use at hand accessible.
Browser: Is a software application for retrieving presenting and traversing information

resources on the World Wide Web.
Performance: Is an act of presenting a play concert or other form of entertainment.
Reliability: Is dependability: the quality of being dependable or reliable.
Integrity: Is the quality of being honest and having strong moral principles.
Security: Is the state of being free from danger or threat.
Usability: Is the ease of use and learns ability of a human made object.
Add Class scheduling: Preparing classrooms for student and instructor in a course of
teaching in a particular subject in a list of times of departures and arrivals.
Documentation: Is material that provides official information or evidence or that serves.
ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM xii

CHAPTER ONE
1. Introduction
1.1 Background of the university
Adigrat University (ADU) is one of the Ethiopian public universities established in 2004 E.C
with the intention of producing highly qualified graduates. ADU is established in the beautiful
town of Adigrat which is located approximately 900km far from Addis Ababa the capital city of
Ethiopia. The town also owns the Addis pharmatical factory which gives for almost service for
almost the whole Africa countries. Adigrat is the center of the corridor between Mekelle and
Axum.
In July 2004E.C the university started its duties with 4 collages and 13 departments’ by
enrolling 960 students. ADU has formally commenced the teaching learning process on
December 5/2004E.C. From then onwards, the university is registering a very fast and
remarkable growth in almost all areas as higher education institution.
1.2 Background of the project

Scheduling is used in different educational areas such as: colleges, and universities (higher
educational institutions) and doing this takes a lot of time and resources. Based on this we
proposed to solve the problem of the existing scheduling system of Adigrat University for
Colleges by developing web based scheduling system. Our proposed system will eliminate
weaknesses of the existing system by providing fast and easy class scheduling system.
Students and Instructors can view their class schedule online. This system will also provide
benefits for the college by providing simple mechanism to schedule classes. Generally the
proposed system will be able to improve previous resources, time consuming and tedious way
of scheduling system.
Department of computer science Page 1

1.3 Statement of the Problem
The existing Class Scheduling System at ADU is susceptible to different labor and time
problems. The main problems of the current Class Scheduling System are as follows.
 Repetition of work:if there are any changes to be made during scheduling class
manually the data will have to be entered again. At times the worker would forget to
make the changes or forget that they had already altered it and might redo it again,
it’s again time consuming.
 Time conflict:during scheduling class one class can have more than one course at the
same time. And class duplication is also based on the time conflict.
 Inconsistency of data: there will be unavailability for future use, since data might get
misplaced during manual scheduled class .so data won’t be preserved properly for
future use.
 Slow retrieval of data: the information of instructors list, students list, building list,
course list, lecture classroom list stored in a paper it takes a long time to retrieve the
data (information).
 Too much paper work:since everything and every detail like instructors list, students
list, building list, course list, lecture classroom list and so on in the current class
schedule are written down manually in paper there will be too much paper work.
 Scheduling all classrooms take lot of time.
 Besides, it is highly error prone because it is done by human not by computer and a
number of human labor is required.
 The loss of manpower (employee power), wastage of time to prepare manually class
scheduling system.
Hence, the development of this project is critically important to address the problems listed
above.

1.4 Objectives of the project

1.4.1 General Objective
The general objective of this project is to develop Web based class scheduling system for ADU.
1.4.2 Specific Objectives

The specific objective of this project includes: -
 Identify the user requirements using interviews, questionnaires and document analysis
 Design the system for implementation with detailed UML specifications.
 Develop a system that can replace the manual class scheduling system based on the UML design
specifications.
 Test the system for any defects using different white and black box test mechanisms
 Integrate help facilities with respect to the use of the application
1.5 Scope of the project
This project focuses on the current work flow of class scheduling system of ADU. The scope of
this project is hence bounded to replacing the manual class scheduling system activities that are
currently undertaken at ADU by a more convenient web-based system that removes the obstacles
stated in the statement of problem. Generally the scope of the new proposed system includes:-
 Class scheduling
 View class scheduled
 The new system is going to perform storing data for:-
 Offered courses of each department.
 Assigned instructors of each offered courses.
 Assigned class rooms.
 Allocated time (period) of each course.

1.6 Limitation of the project
The Project does not include:

 The system doesn’t provide service for disable peoples such as peoples that can’t
visualize, unable to hear and the like.
 Make up class
 Add and Drop Students
 Weekend classes and extension
 Exam scheduling system
1.7 Significance of the Project
After implementing this automated system it is very easy to schedule class. This system solves
the previous time consuming and tiresome system it saves a lot of time and money, scheduling is
very fast and delays can be avoided and it helps the university in reducing costs such as labor and
stationary. And it avoids wastage of time in teaching and learning process.
1.8 Target Beneficiaries of the System
The main purpose of our project which is Web Based Class Scheduling System is to justify the
problems which are found on the existing class scheduling system that we describe above.
Because of the existence of the new system it changes the use of manually system application
forms to the computerized system. This System can be improved quality or increased
predictability of quality and improved robustness (consistency), of processes or product. This
project is centered on the design and implementation of computer software’s that handle class
scheduling system for ADU. It aims at providing applications that will make the processing of
ADU very easy and reliable.
1. For Scheduler:
 The system will save the time to schedule time table.
 it also enable the scheduler to easily manage records
 Reduce errors and overlapping of time table.

2. For Student: The student gets quickly service (i.e. view their class schedule) due to Web
Based Class Scheduling System.
3. For Instructor: The instructor gets quickly service (i.e. view their class schedule) due to
Web Based Class Scheduling System.
1.9 Methodology of the project

1.9.1 Data Sources
The data/information needed to develop the new system has obtained from registrar workers, and
documents.
1.9.2 Fact finding technique

Interview:-
We have used interview to collect relevant workflow, the tasks performed in the class scheduling
system, and anything that the team can’t find from the document analysis.
Questionnaires:-
We have understood the work flow of the class scheduling system by preparing some
questionnaires.
Observation:
We have observed to see functions of the employers of class scheduling system, and to extract
any workflow or activity missed from conducting the interview and document analysis. It also
helps to deeply understand the detail tasks involved in the –class scheduling process and the
source and nature of errors.
Documentation:
We have collected and referred different documents and reviewed all necessary documents,
books that support this project.

1.9.3 System Analysis and Design Methodology

The team chooses to follow the object oriented system analysis and design methodology during
the whole project life cycle (Analysis, design etc.) for the many benefits that it has over
structured approach including reusability, improve quality, maintainability and manages
complexity.
Hence, we have applied the concepts of object oriented system development methodology
throughout the project, because it manages and assemble objects that are implement in our
system, and the composition of objects and interaction between objects on the system. This
categorized in to two phases. These phases are:-
1.9.3.1 Object oriented Analysis
During this phase we have looked at the problem domain, and with the aim of producing a
conceptual model of the information that exists in the area which have been analyzed. And this
Model the functions of the system (use case modeling), identifying the business objects, organize
the objects and also the relationship between them.
1.9.3.2 Object oriented design
During this phase Model object interactions and behaviors that support the use case scenario, and
finally update object model to reflect the implementation environment. And also transforms the
conceptual model produced in object-oriented analysis to take account of the constraints imposed
to our system format, so that we used this phase to refine the use case model to reflect the
implementation environment.
1.9.4 Development Methodology

The development method we are using to develop the proposed system is the Waterfall approach.
Because of that the system documentation process activities of specification, development,
validation and evolution represented in a separate process phases.
1.9.5 Implementation methodology

In this project the following system development tools were used: -

1.9.5.1 Software Tools
Activities Tools/Programs
Client side coding HTML
Client side scripting Java script

Platform Windows
Database server/ Web server MySQL database
Server-side scripting PHP
Editors G Edit, notepad++

Documentation MS Word
User Training MS PowerPoint

Modeling UML(Unified Modeling Language)
Table 1: software tools
1.9.5.2 Hardware Tools

 Client computer: The class scheduling system can be used on workstations with
512MB or less free space HDD (Hard Disk Drive) and 1GB RAM for fast browsing.
 Server computer: CPU 4.00 GHZ, 500GB HDD and 4GB RAM is required for the
system server.
 External hard disk: for Back up data.
1.9.6 Feasibility Studies

Feasibility is the measure of how the new system is viable or beneficial from the existing
system. It is an ongoing process done frequently during systems development projects in order to

achieve a creeping commitment from the user and to continually assess the current status of the
project.
1.9.6.1 Technical Feasibility

Usually new systems established in order to overcome the technical illness of the previous
system. In the same way, this system is technically big enough to be applied easily to the
problem identified in the existing system. In addition that, both hardware’s and software’s for
this system are highly available and can be owned with small cost. Therefore, it can be
concluded that the system is technically feasible
1.9.6.2 Operational Feasibility
The system will operate on any operating systems or platforms which have apache installed.
Therefore the system will operate in any kind of platforms .so the entire team member expects
the system to be operationally feasible.
1.9.6.3 Political Feasibility
The system is politically feasible cannot cause any harm or it does not have an influence in the
environments. The project is beneficial because it satisfies the objectives of the customer or the
university. System is free from any problems because there is no negative side to user or workers
to university
1.9.6.4 Schedule feasibility

Schedule feasibility is used to determine how the proposed system accomplished with the given
Timetable. It implies effective time management for the system, and the project should finished
within deadline. So the team implemented and configured the system on time without any delay.
The project schedule is according to the time it has schedule the documentation and the time to
time activities will be done on time.
Hardware cost
Materials Quantity Unit price Total price

DVD-RW, 2 140.00Birr 280.00Birr
Flash 16GB 3 200.00Birr 600.00Birr
Paper 500 1.00 500.00Birr

Print 5 times (proposal 40.00Birr 200.00 Birr

phase, analysis phase,
design phase,
implementation and
presentation)
Total 800.00 Birr
Table 2: hardware cost
Software cost
Materials Quantity Unit price Total price
Programming tools PHP Trial 0

Database tool MYSQL database Trial 0
Table 3: software cost
1.9.6.5 Economic Feasibility

This feasibility is used for evaluating the effectiveness of a new system. In economic analysis
the procedure is to determine the benefits and savings that are expected from a candidate
system and compare them with costs. If benefits outweigh costs, then the decision is made to
design and implement could also be referred to as cost/benefit analysis.
1.9.7 Testing Procedures
Before directly deploying this system the team performed different types of testing procedures
for its functionality. The system tested by the following testing types.
1.9.7.1 Unit testing: -
We tested each process independently to check their functionality.
1.9.7.2 Integration Testing:-

After we tested each unit of the system we performed an integration test to check whether the system
meets all the functional requirements. When a number of components are complete; we tested the
components to ensure that they integrate well with each other, the operating system, and other
components.
1.9.7.3 System Testing: -

Testing conducted on a complete, integrated system to evaluate the system performance with its specified
requirements. System Testing falls within the scope of black box testing and should require no knowledge

of the inner design of the code or logic. Series of reliability and functionality tests designed to find
software engineering errors.
Alpha Testing: Testing using correct input and sees for any failures. If failure occurs find and correct
the bug.
Beta Testing: In this testing method, team forced the system to be tested for incorrect data input. The
System tested by the customer. If any failures occurred while testing the system in all the above testing
methods, the team took immediate correction.
1.10 Task and Time schedule
We have conducted our study in a team of six students, each of which is responsible for the
project to accomplish. We have met twice in a week for two weeks, and we stayed on to observe
our work for about 16 hours during the two weeks.
Activities Month
No October Novemb Decem Janua Febr M April Ma June

er ber ry uary arc y
h
Project title 2
1 submitted
2 Analysis phase 5
3 proposal 19
4 Design phase 1
5 Coding 1 28
6 Implementation & 30 30
testing
7 Project close-up 25
Table 4: schedule

1.11 Team composition
Project Web Based Class Scheduling System

Title
Prepared S. Name ID. No. Email Responsibility

By No.
1. MhretAregay Ret1799/06 Mhretaregay2008@gmail.com Code developer
Data collector
2. ZerueTlahun Ret1817/06 Zerue092504@gmail.com Data collector
3. YebahrneshTajebe Ret1814/06 YebahrneshTaj@gmail.com Code developer
Data collector
4. TsgeDomewoz Ret1810/06 TsgeDj@gmail.com Code developer
Data collector
5. Wegeneamaru Ret1393/06 Wegenea@gmail.com Analyst and programmer
Data collector
6. Bizen G/skel Ret1779/06 BizenG/skel @gmail.com Data collector
Date 2017G.C
Advisor FilmawitM.
Table 5: team composition

CHAPTER TWO
2 Requirement Analysis Description

2.1 Overview of the Existing System
As we know manual system is quite tedious and since the existing scheduling system is manual,
it has to process everything manually from course offering to the final schedule. The tasks that
are performed currently in the registrar and departments regarding the scheduling are scheduling
class rooms, scheduling laboratory classes and scheduling laboratory hours for the instructors
and for the students. All of the tasks that we visited during the study are performed manually and
it is tedious needs a lot of time, needs a great commitment and previous skill. For the better
accomplishments of those tasks computerized system is the best and interactive as it reduce
efforts, costs and wastage of time.
2.2 Player of the Existing System
An existing system compromises different players to carry out its job. Among those different
actors (players), the most common are -
 Student: - view the posted schedule.
 Instructor: - can be professor, assistance professor, lecturer or assistance lecturer and is a
user who gets any information regarding the schedule.
 Registrar personnel: - a user who manages the scheduling process.
 Department head: - perform course offering process and then sends the offered courses to
the scheduler.
2.3 Activities of the system
I. Class Scheduling
The department head prepares list of offered courses based on the curriculum with respective
instructors. Then send the courses to registrar. The registrar personnel prepare the timeline. And
it distributes scheduled paper for all colleges and sends the schedule for department heads under

the college. Then the department head posts the schedule for the students as well as for the
instructors. But sometimes one copy of the schedule is given to the representative student of each
class. Most of the time since overlapping of periods happens, the department head reviews the
schedule and arranges it according to the requirement of the department.
2.4 Business Rule of the Existing System
 No two courses can be scheduled for the same room at the same time.
 An instructor cannot teach two courses at the same time.
2.5 Problems of the existing system
The manual Class Scheduling system is laying face down to various problems. These problems
can be seen from the following perspectives like performance, security, efficiency, budget,
human power and services given by the existing system to the users.
2.5.1 Performance
 Prone to error
 When the scheduler performs the scheduling process overlapping (clashing) of periods
may happen.
 Time Consuming
 More timetables will be processed every semester, the process to arrange the schedule
is very complicated since the scheduler need to consider many criteria.
 Preparing the schedules for each department in every semester takes long time.
 If the scheduler made an error when scheduling the time table, recovering error will
take another time to regard.
2.5.2 Security and controls
The existing Class Scheduling system records are stored in plain text and they are not encrypted.
For files that are stored as paper files can be lost, burnet or damaged by moisture or can be eaten
by rats and termites. So, it is difficult to control and secure these manual records, since it doesn’t
have any authentication and authorization system.

2.5.3 Efficiency
Due to the manual operation most of the activities are prone to wastage of resources like papers,
man power, time etc. to produce the corresponding outputs. This makes the current system
inefficient while utilizing resources. There should be a mechanism that reduce wastage of
resources and that make the system to be efficient.
2.5.4 Input and output
In the existing of Adigrat University Class Scheduling system the input of information is
redundant, inaccurate, not well organized and hard and also these inputs may leads to create
confusion and work load on employees and produce inaccurate output since the information is
written by pen and on paper.
2.6 Report generated in the existing system
Figure 1 : Final Class Scheduling Form
2.7 Forms and Other Documents of the Existing System

Figure 2: Course offering Form which sends from department to registrar.
2.8 Practices to be preserved from existing system
Even if the existing system is manual system as it has weakness it also has some strong side that
we need to be preserved are: -
 The governing rule and regulation.
2.9 Overview of the Proposed System
During our observation and interview of users we observed certain problems from their manual
based system. Because of this we proposed to solve the problem of the existing scheduling
system by developing automated web based system. This means our proposed system will
minimize the current problem and weakness of existing system. The proposed system will also
have some other features like:
 Accuracy in the handling of data.

 Fast rate of operation and excellent response time.
 The system is flexible i.e. it can be accessed at any time.
 Easy way of backup or duplicating data in case of data loss.
 Better storage and faster retrieval system.
 User friendly interface.
2.10 Specific Requirements

2.10.1 Functional Requirement
The functional requirement of this proposed class scheduling system should be described
regardless of its implementation. It points the major functionalities that expected to be included
in the proposed system to satisfy the objectives of the project.
The proposed system must provide the following features:
Scheduler
Requirement id: - 01
Scheduler Requirement: -The system shall allow the scheduler to: -add: - College,
department, year and section, building, room, academic year information to the system.
Requirement priority: - High.
Requirement id: -02
Requirement: -The system shall allow the scheduler to: -delete: - College, department,
year and section, building, room, academic year information to the system.
Requirement id: -03
Requirement: -The system shall allow the scheduler to: -edit: - College, department,
year and section, building, room, academic year information to the system.
Requirement id: -04
Requirement: -The system shall allow the scheduler to add schedule by insert:-
department, year and section, academic year, semester, day, time start, time end, course,
instructor, room information.
Requirement id: -05
Requirement: -The system shall allow the scheduler to search schedule.
Requirement id: -06
Requirement: -The system shall allow the scheduler to login with his or her account by
using username and password


Requirement id: -07
Requirement: -The system shall allow the scheduler to logout.
Requirement: -The system shall allow the scheduler to: - delete user account.
Priority: High
Requirement: -The system shall allow the scheduler to view feedback and feedback to
department by insert username and email.
Requirement priority: - High
Requirement: -The system shall allow the scheduler to: - edit user account.
Requirement: -The system shall allow the scheduler to post announcement.
Department
Requirement: -The system shall allow the department to: -to view feedback from
scheduler and to send feedbacks to the scheduler by insert username and email.
Requirement priority: High
Department Requirement id: - 13
Requirement: -The system shall allow the department to: -submit sleep by insert:-
department, course code, course title, year, semester, lab hour, lecture hour, credit hour,
mode of delivery, instructor, note to the scheduler.
Requirement: -The system shall allow the department to view announcement post.

Requirement id: -15

Requirement: -The system shall allow the Department to login with his or her. Account
by using username and password
Requirement id: -16
Requirement: -The system shall allow the Department to logout.
2.10.2 Non-Functional Requirement

Nonfunctional requirements describe user-visible aspects of the system that are not directly
related with the functional behavior of the system.
The following are non-functional requirement of the system:-
Requirement id: 01
Requirement: the system should provide a simple, responsive user interface. By
designing user friendly interface, the end users are able to communicate within few
response times.
Requirement id: 02
Requirement: The system should support concurrent users.
Requirement Id: 03
Requirement: The system should minimize errors and error messages should be
displayed that guide user to handle it.
Requirement id: 04
Requirement: The system does not allow any user to access other user’s information
except the authorized user
Requirement id: 05
Requirement: The external security should be provided by giving the login
authentication.


Requirement id: 06
Requirement: The system will be available to its users with internet connection 24 hours
a day.
2.11 Systems Requirement

2.11.1 Hardware Requirement
For Server Computer:
Minimum Hardware requirement:
o Intel Pentium 4 processor, 3.0 GHz CPU , 4 GB of RAM and 80GB HDD
For Client Computer:
Minimum Hardware requirement:
o Intel Pentium 4 processer, 2.0 GHz CPU, 512 MB of RAM and 40GB HDD
2.11.2 Software Requirement
The software requirements for installing this system requires:-
1. Operating System:
a. For Server Computer: Microsoft Windows Server 2003 or higher versions
b. For client Computer: Any operating system.
2. WAMP Server: WAMP (Windows, Apache, MySQL, and PHP/Perl/Python) or separate
PHP for windows higher version and MySQL Community Server version 5.6 or higher.
3. Browser: for client computer
Mozilla Firefox version 20 or higher, Chrome any, Opera version 9 or higher, internet
explorer higher version.
4. Application Software: for both server and client computer
 Microsoft Office Word 2007 or higher: for writing, formatting and adding digital
signatures to letters.

2.12 Constraint and Assumption

2.12.1 Constraints:
Our proposed class scheduling system can’t handle if the power is lost. The instructor and
student can’t print their schedule if the printer is broken or fail. So, it is difficult to generate the
class schedule.
2.12.2 Assumptions
 It is assumed that the Registrar office will have trained staff to take care of the system.
 The users have sufficient knowledge of computers.
 To access information from the web application users must know the web address or URL.
 The users must know the English language.

CHAPTER THREE
3 System Analysis and Modeling

3.1 Introduction
In this project, the team use an object oriented system development methodology which
incorporates two principal phases. These principal phases are Object-Oriented Analysis and
Object-oriented Design. This chapter discusses the first phase of the methodology: object
oriented analysis (OOA). During Object Oriented Analysis the following major activities are
performed. System Requirement Specifications (SRS), Use case modeling and documentation
(for each use case identified), and the development of sequence and activity diagrams and user
interface prototyping.
3.2 System Requirement Specifications (SRS)

3.2.1 Actor Specification
 Scheduler: is an actor who manages the scheduling process. The scheduler is personnel
from registrar office. The scheduler manages all records needed for scheduling and also
schedule class.
 System user: can view and print class schedule.
 Department head: - perform course offering process and then sends the offered courses
to the scheduler.
 Use Case diagram
The figure below shows as the interaction between the actors (i.e. scheduler, system user and
department head) and the use cases, which is found in our proposed class scheduling system
software.
Here are some use cases that we have identified:

 UC1.Login
 UC2. Add System User
 UC3.ManageSystem user
 UC4.Add Faculty Information
 UC5.Add Department Information
 UC6.Add Building Information
 UC7.Add Room Information
 UC8.Add Instructor Information
 UC9.Add Student (year and section) Information
 UC10.Add course information
 UC11.Delete course information
 UC12.Add Class Schedule
 UC13.Edit Schedule
 UC14.Delete Schedule
 UC15. Search Schedule
 UC16.View Schedule
Figure 3: Use case diagrams of Scheduler, system user use and department.

Login
Use Case Name Login

Use Case ID UC1
Brief description User who have privilege to access the system’s functionalities should be able to
login each time he/she wants to use the system
Actor Scheduler and User (Department Heads) not all System user
Pre-condition The user must to be registered to user Account.
Post Condition If the user is authenticated the User logged into the system and the system displays
all features available for the role associated to the user.
Basic Course Of Action (BCA)
This use case starts when the User accesses the login in feature of the system by selecting his privilege.
1. The system displays a login form
2. The user enters his/her user and password
3. The user clicks login button
4. The system validates the entered information.
5. The system takes the user to his/her interface.
6. The use case ends.
Alternate Flows
Title Description
4.2User fills invalid username 1. The system Displays error message.
and/or password 2. The system prompts the user to re enter the valid information.
3. Use case continues with BCA 2.
Table 6: use case documentation for login
Add System User
Use Case Name Add System User

Use Case ID UC2
Brief description This use case allows for register new system user.
Actor Scheduler
Pre-condition Scheduler already login into the system and load the Add user form
Post Condition User of the system success fully added

This use case starts when the Scheduler accesses the system feature that enables him/her to create an account by
entering information that is saved in the User’s account.
1. The system displays user Account Form.
2. Scheduler enters the required user account information on the form.
3. The system verifies values entered are valid.
4. System saves the new account in the database after Scheduler Click the save button.
5. The system notifies success message.
6. The use case is end when Scheduler clicks the ok button.
Alternate Flows
Title Description
3.1 User inserts Invalid User 1. The system prompts invalid user account
Account Information 2. system prompts user to re enter valid account
3. use case continues with BCA 2
3.2 user inserts existed 1. system prompts error message
account 2. System display message that the account is already exist.
3. use case ends
Table 7: use case documentation for create account
Manage System user
Use Case Name Manage system user

Use Case ID UC3
Brief description This use case allows Editing, Updating, or Deleting each system users by using
user_id.
Actor Scheduler
Pre-condition Scheduler already login into the system and load the user Account page
Post Condition User profile changed in the data base.

This use case starts when the user access the system feature that enable Edit system user
1. Scheduler is able to edit, update and delete information for each user in the system by clicking on
The edit/Save or Delete Buttons on the form for each system users.
2. If he press Edit button the system Display change profile form
2.1 The Scheduler changes the users profile
2.2 The Scheduler clicks on save
2.3 The system Update the information changed to the user profile or
3. If the Admin Press Delete Button
3.1 The system will prompt that he is really want to delete the account?
3.1 The system will Delete the user account from the system.
4. The system shows success acknowledgement
Alternate Flows
Title Description
2.1 User inserts Invalid 1. The system prompts invalid user account
Account Information when 2. System prompts user to re enter valid account information.
editing
Table 8:use case documentation for Manage system user
Add Facility Information
Use Case Name Add College Information

Use Case ID UC4
Brief description This use case represents the procedure which the Scheduler goes before using the
system resource. It typically accomplished by typing information of faculty and
program on the form and sends to the data base.
Actor Scheduler
Pre-condition Scheduler already login into the system and load the Add faculty form
Post Condition Faculty information added to the database

1. The use case starts before scheduling is done.

2. The Scheduler has to enter the Faculty information.
3. When the Scheduler click on the save button.
4. The system then validates the entry.
5. If it is correct save the file to the database.
6. The system shows success acknowledgement message.
Alternate Flows
Title Description
4.1Entered Faculty already 1. system prompts error message
exists 2. System display Faculty information already exists.
3. Use case ends.
4.2 Required information is 1. system prompts error message
missing 2. System display Required Faculty information is missing.
3. Use case continues with BCA2.
Table 9: Use case documentation for Add Faculty Information
Add Department Information
Use Case Name Add Department Information

Use Case ID UC5
Brief description This use case represents the procedure which the Scheduler goes to add
information to the system . It typically accomplished by typing information of
Department information to the form and sends to the data base.
Actor Scheduler
Pre-condition Scheduler already login into the system and load the Add Department form
Post Condition Department information added to the database
2. The Scheduler has to enter the Department information.
4. The systems then validate the entry.
5. If it is correct save the file to the database.
Alternate Flows
Title Description

4.1Entered Department already 1. system prompts error message

exists 2. System display Department information already exists.
3. Use case ends.
4.2 Required information is 1. system prompts error message
missing 2. System display Required Department information is missing.
3. Use case continues with BCA2.
Table 10: Use case documentation for Add Department Information
Add Building Information
Use Case Name Add Building Information

Use Case ID UC6
Brief description This use case represents the procedure which the Scheduler goes to add
information to the system It typically accomplished by typing information of
building on the form and sends to the data base.
Actor Scheduler
Pre-condition Scheduler already login into the system and load the Add Building form
Post Condition The information is Added to the database.
2. The Scheduler enters the building information.
3. When the Scheduler click on the save button
4. The system validates the entry.
Alternate Flows
Title Description
4.1 Entered Building 1. The system Display the already exist message
information already exists 2. The use case end
4.2Required information is 1. The system Display the required information is missing
missing 2. The use case continue with use BCA2
Table 11: Use case documentation for Add Building Information
Add Room Information

Use Case Name Add Room Information
Use Case ID UC7
Brief description This Use case represents also which the Scheduler accomplishes by typing
information of building in Use case adds room information send to the database.

Actor Scheduler
Pre-condition Scheduler already login into the system and load the Add Room form
Post Condition Entered Room information is saving.
2. The Scheduler has to enter the Room information.
5. The system will save the information to the database.
Alternate Flows
Title Description
4.1 Entered Room information 1.The system Display the already exist message
already exists 2. The use case end
4.2Required information is 1. The system Display the required information is missing
missing 2. The use case continue with use BCA 2
Table 12: Use case documentation for Add Room Information
Add Instructor Information
Use Case Name Add Instructor Information

Use Case ID UC8
Brief description This Use case represents also which the Scheduler accomplishes by entering
instructor information to the database
Actor Scheduler
Pre-condition Scheduler already login into the system and load the Add Instructor form
Post Condition Instructor Information Saved


2. The Scheduler have to enter the Room information.
Alternate Flows
Title Description
4.1 Entered Instructor 1.The system Display the already exist message
4.2 User inserts Invalid 1. The system Display the required information is missing
instructor information 2. The use case continue with use BCA 2
Table 13: Use case documentation for Add Instructor Information
Add Student (year and section) Information
Use Case Name Add Student (year and section Information

Use Case ID UC9
information to the database
Actor Scheduler
Pre-condition Scheduler already login into the system and load the Add year and section form
Post Condition year and section Information Saved
2. The Scheduler has to enter the year and section information.
Alternate Flows
Title Description
4.1 Entered year and section 1.The system Display the already exist message

4.2 User inserts Invalid year 3. The system Display the required information is missing
and section information 4. The use case continue with use BCA 2
Table 14: Use case documentation for Add Student (year and section) Information
Add Course information
Use Case Name Add Course Information

Use Case ID UC10
Actor Scheduler/ User(Department Heads)
Pre-condition Scheduler/ User already login into the system and load the Add Course form
Post Condition Course Information Saved
2. The Scheduler has to enter the Course information.
7. The use case is end when Scheduler/ User clicks the ok button.
Alternate Flows
Title Description
4.1Entered Course information 1.The system Display the already exist message
already exists 2. The use case end
4.2 User inserts Invalid Course 1. The system Display the required information is missing
information 2. The use case continue with use BCA 2
Table 15: Use case documentation for Add Course information
Delete course information

Use Case Name Delete Course Information
Use Case ID UC11
Actor Scheduler

Pre-condition Scheduler already login into the system and load the Course form
Post Condition Course Information Saved
1. The use case starts when the Schedulers select the particular Course ID that needs to be deleted
2. The Scheduler click on Delete button.
3. The system will prompt that he really want to delete the course.
4. When the Scheduler select Yes Button,
5. The system will delete the course information entry from the database..
Alternate Flows
Title Description
4.1 When the Scheduler select 1.The system Return back to the course page
No Button, 2. The use case end
Table 16: Use case documentation for Delete course information
Add Class Schedule

Use Case Name Add Class Schedule
Use Case ID UC12
Brief description This use case allows the scheduler to setup scheduling time for each year and
section by assigning room, instructor, course, education day and time and to
prepare Schedule based on the request of Programs.
Actor Scheduler
Pre-condition 1. The Scheduler already login into the system and the system has load
theAdd Class schedule form.
2. All required information must be entered.
Post Condition The Class schedule data is saved to the database

1. The use case starts when the scheduler load class schedule page.
2. The system prompts the scheduler to select departments that he or she wishes to Add Class schedules.
3. The system display Add schedule form.
4. The Scheduler fills all the Required information by selecting and by writing.
5. When the scheduler click on the save button.
7. The system will Save the Class Schedule to the database
Alternate Flows
Title Description
5.1If year and sections have a 1. The system Display a message This year and section student have
class on that time schedule on this day and time
2. The use case continue with use BCA 3
5.2 If Instructor have class on 1. The system Display a message This Instructor have schedule on this day
that time for other year and and time for this Year and section students.
section student 2. The use case continue with use BCA 3
5.3 If the Room already 1. The system Display a messageThis Room is Reserved by Instructor name
reserved by other year and for the year and section student with the course
5.4 User inserts Invalid 1. The system Display the required information is missing
Schedule information 2. The use case continue with use BCA 3
Table 17: Use case documentation to Add Class Schedule
Edit Schedule
Use Case Name Edit Schedule

Use Case ID UC13
Brief description The Scheduler wants to edit or modify the Schedule for any year and section
Actor Scheduler
Pre-condition 1.The Scheduler have to logged inland
2. The Schedule for the Class and Year students must exist.
Post Condition Save the changes on the schedule to the database.

1. The use case starts when the scheduler Click Edit Button on Class schedule page for the
selected schedule by using Schedule ID
2. The system displays Edit Schedule Form that have all information about the previous schedule
and prompts the Scheduler to edit the Schedule details
3. The Scheduler makes the modifications and clicks on Save.
4. The system validates the entry. Al
5. The system will Save the Class Schedule to the database.
7. The use case is end when Scheduler clicks the ok button
Alternate Flows
Title Description
4.1If year and sections have a 1. The system Display a message This year and section student have schedule
class on that time on this day and time
2. The use case continue with use BCA 3
4.2 If Instructor have class on 1. The system Display a message This Instructor have schedule on this day
that time for other year and and time for this Year and section students.
4.3 If the Room already 1. The system Display a message This Room is Reserved by Instructor name
reserved by other year and for the year and section student with the course
4.4User inserts Invalid 1. The system Display the required information is missing
Schedule information 2. The use case continue with use BCA 3
Table 18: Use case documentation to Add Class Schedule
Delete Schedule
Use Case Name Delete Schedule

Use Case ID UC14
Brief description The Scheduler may decide to delete Schedule if it no more necessary, clears
unnecessary Schedule.
Actor Scheduler
Pre-condition 1. The scheduler is logged in
2. The Schedule exists.
Post Condition Delete the schedule from the data base

1. The Use case Begin when the Scheduler Click DELETE button on class schedule page for the
selected schedule by using scheduling Id
2. The system will Prompt the scheduler that he Really want to Delete the Selected schedule
3. When the Scheduler select Yes Button, Al
4. The system Delete the class Schedule information entry from the database.
Alternate Flows
Title Description
3.1 When the Scheduler select 1.The system Return back to the Schedule page
No Button, 2. The use case end
Table 19: Use case documentation to Delete Class Schedule
Search Schedule
Use Case Name Search Schedule

Use Case ID UC15
Brief description The user should be able to search and filter the schedule information detailusing
different criteria.
Actor All system User
Pre-condition The user is logged in to the system or not
Post Condition Properties and schedule matching the criteria are displayed in a report view.
1. The Use case Begin when the users click on search class schedule link
2. The user select search schedule for Year and section Al
3. The system displays a search Form to select Year and section, semester and academic year.
4. When the user click on the Submit button
5. The system filters the data from the database according to the search criteria’s.
6. The system displays a Search result as Report.
7. The user select Print Schedule Button
8. The system prompt the user to select his printer form list Al
9. The system Print the Report
10. The use case is end when the user clicks on Back Button.
Alternate Flows
Title Description

2.1: User Select Instructor 1. The user select search schedule for Instructor
schedule search 2. The system displays a search Form to select Instructor Name, Semester and
Academic year.
3. use case continue with BCA 4
2.2: user select Room 1. The user select search schedule for Room
schedule search 2. The system displays a search Form to select Room Name, Semester and
Academic year.
8.1. If the user may have no 1. The user selects "Microsoft XPS Document Writer" and click on Print.
printer 2. The system prompts to select place and Name for Report to save as File.
3. The system Save the schedule.
Table 20: Use case documentation to Search Schedule
View All Schedule
Use Case Name View Schedule Report

Use Case ID UC16
Brief description To view the status of class room, instructor and year and section
Actor Scheduler
Pre-condition 1. Scheduler have to login into the system
2. System has load the schedule form for each Department
Post Condition Report is viewed to the user
1. The use case starts when the scheduler load class schedule page.
2. The system prompts the scheduler to select departments that he or she wishes to view schedules.
3. The system display List of schedules for that selected department for all year and sections. Al
4. The system Display academic year, semester, department, year and section, day, course, time start,
time end, instructor name, room and actions
5. The Scheduler can sort the schedule in Ascending or Descending order.
6. The Scheduler can Determine items to previw per page
7. The System provide capability to Navigate from one page to another by clicking on 1,2,3,...pages or
By Click on Next , Last, First or Priv Buttons or to Determine
8. The use case is end when Scheduler Click All Button (Back to All Department List)
Alternate Flows

Title Description
3.1 When the scheduler wants 1. The Scheduler can search:
to search specifically  By Instructor Name
 By Year And Section
 By Room Name
 By Academic year
 By Semester
 By Department
 By Day
 BY Course
 By Time start
 By Time end
Table 21: Use case documentation to Search Schedule

3.3 Sequence Diagram
Sequence diagrams are used to model the logic of usage scenarios or the description of the
potential way the system used. Sequence diagrams are a great way to validate and flesh out the
logic of use case scenarios and to document the design of the system.
Adigrat University Online Classroom Scheduling System has the following sequence diagrams.
3.3.1 Sequence Diagram for Login
login Form Login

:Users :Database
:GUI :Controler
User Name & Password
Login ( )
Validate ( )
Display Error Message ( )

Valid ()
Display User Home Login conformation
Figure 4: Sequence Diagram for Login

3.3.2 Sequence Diagram for Adding Information
:Admin/ Home Page Add General

:Database
Scheduler/User :GUI :Controler :Form
Click Add Button
Transfer Request ( )
Initialize Add form ()
Display Add form ( ) Display Created Form ( )

Select Add Catagory
Add( )
Validate ( )

Submit ( ) Store ( )
Display Successfully Add

Display ( ) Confirmation ()
Added message
Figure 5: Sequence Diagram for Adding Information
3.3.3 Sequence Diagram for Update Information
:Admin/ Home Page Update General

:Database
Scheduler/User :GUI :Controler :Form
Select Update Catagory
Click Edit Button Transfer Request ( )
Initialize Edit form ( )
Display Edit form ( ) Edit Form ( )
Edit ( ) Update ( )
Validate ( )

Submit ( ) Change Saved ( )
Display Successfully Update

Update Message

Figure 6: Sequence Diagram for updating Information
3.3.4 Sequence Diagram for Delete Information
Home Page Delete General

:Admin/Schedule :Database
:GUI :Controler :Form
Select Delete Catagory
Click Delete Button Transfer Request ( )
Initialize Delete form ( )
Display Created Create Form ( )

form ( )
Confirm ( ) Request Delete ( )
Validate ( )

Confirm ( ) Delete ( )
Display Successfully Delete

Delete Message
Figure 7: Sequence Diagram for Delete Information

3.3.5 Sequence Diagram to Add User Account
Admin Home Page Account General

:Admin :Database
Click Add
Account Button
Initialize Add form ( )
Display Account Display Account

form ( ) Created Form ( )
Fill information ( ) Create ( )
Validate ( )

Display Account Account

Successfully Display ( ) Confirmation ()
Created Message
Figure 8: Sequence Diagram for Adding Account
3.3.6 Sequence Diagram for Add Class Schedule
Scheduler Home Page Schedule General

:Scheduler :Database
Click Add
Class Schedule Button
Initialize Add form ( )
Display Schedule Display Schedule

Fill Schedule
Create ( )
Information
Validate ( )

Display Schedule Schedule

Successfully Display ( ) Confirmation ()
Added Message
Figure 9: Sequence Diagram for Add Schedule

3.3.7 Sequence Diagram for Search Schedule
:Admin/ Scheduler/ User Home Page Search General

:Database
User/ Any User :GUI :Controler :Form
Click Search
Class Schedule Button
Initialize Search form ( )
Display Search Display Search

Fill Search Criterya Search ( )
Validate ( )

Submit ( ) Query Data ( )
Display Retrived Retrive Search

Display ( ) information ( )
Information
Figure 10: Sequence Diagram for Search Schedule

3.4 Activity Diagram
Activity diagram is used to document the logic of a single operation/method, a single use case or
the flow of logic of a business process. It is equivalent to flowchart and data flow diagram from s
structured development.
3.4.1 Activity Diagram for login
Index
Click On Login By selecting

Account Type
Enter User Name And Password
Click On Login
Invalid
Valid
User Account Type

Home
Figure 11: Activity Diagram for login

3.4.2 Activity Diagram for Adding Information
Index
Select Account Type and

Click On Login
Invalid
Valid
Admin/ Scheduler/ User Home
Select Add Information Catagory
Enter the information on the Provided form
Click on Save
Invalid
Valid
System Display Succsess message
Figure 12: Activity Diagram for Adding Information

3.4.3 Activity Diagram for Updating Information
Index

Click On Login
Invalid
Valid
Admin/ Scheduler Home
Select Update Catagory
Click on Edit Button to Edit the information

that needed to Update on the Provided form
Click on Save
Invalid
Valid
Figure 13: Activity Diagram for Updating Information

3.4.4 Activity Diagram for Deleting Information
Index

Click On Login
Invalid
Valid
Admin/ Scheduler Home
Select Delete Catagory
Click on Delete Button for the information that

needed to deleted.
Conformation
No
Yes
Figure 14: Activity Diagram for Deleting Information

3.4.5 Activity Diagram for Adding User Account
Index

Click On Login
Invalid
Valid
Admin Home
Click Add Acount button
Fill all required User information on

Registrer Form
Click on Save
Invalid
Valid
System Display Acknowledgment
Figure 15: Activity Diagram for Adding User Account

3.4.6 Activity Diagram for Adding Class Schedule
Index

Click On Login
Invalid
Valid
Scheduler Home Page
Select Department
Click On Add Class Schedule Button
Fill All required Information on the form
Click On Save
Invalid
Valid
System Save the schedule
System Display Sucessfully Addede

Mesage
Figure 16: Activity Diagram for Adding Class Schedule

3.4.7 Activity Diagram for Searching Schedule
Index
Select Search Schedule
Select Your schedules Type
Fill Your search Criteriya
Click On Submit Button

Invalid
Valid
System Display the Search Result
The User Can Print or Save the Result
Figure 17: Activity Diagram for Searching Schedule

3.5 User Interface Prototyping
User interface prototyping is an iterative development technique in which users are actively
involved in the mocking-
The figure below shows us the User interface prototyping diagram.
Figure 18: User Interface prototyping

3.6 Supplementary specifications

3.6.1 Business rules
The guideline or rule that the system uses to achieve its objective. The following are rules that
govern the system to complete each task.
BR1: Authorize to the System: Users must have a valid user name and password for their
respective privilege, the Users Name should be unique and each users should enter their user
name& password to get access to the system.
BR2: Validate users Information: if the user registered correctly then the system will validates
the user information and then authorized to use the system.
BR3: The Scheduler should administer the system and give accesses (views) to those system
users by creating account as per their priority to the system and update their password.
BR4: Uniqueness: A student (year and section), Instructor, Room, Faculty andDepartment must
have unique ID.
BR5: Each course should have a unique course code
BR6: The system must get input the list of Course, Instructors, Room and Year section (student)
for Scheduling
BR 7: The schedule always prepared before the beginning of each semester.
BR8: The Report generates all static information regarding students, instructors and Room
schedule.
BR9: System should provide various reports in accordance with requested information i.e. (about
Students, Instructor, and Room schedule (weekly or for the semester).
BR 10: The report should be clear and summarized.

CHAPTER FOUR
4 System design
4.1 Introduction
This chapter mainly concerned with the design part of Class Scheduling System. In order to
make the implementation easy the design is very important. In this chapter we are introduce
Design Goal, system Architecture, Deployment Diagram, Persistence Data Management, Access
Control and Security and User Interface Design deepened on the class scheduling system.
Generally this chapter is describes how the project is designed, what tasks done under this
project
4.2 Design Goal
The major design goals of the proposed class scheduling system are Good response time,
portability, low cost, accessibility, minimize error, flexibility, and handle redundancy.
Good response time: this class scheduling system will be implemented by PHP programming
language, which is in general ease to readable for all browsers. The interfaces will design such
that information can be transmitting efficiently. It’s avoided a user waiting time on wherever
possible. It minimizes a lot of time for registrar office and department heads for doing all
activates in class scheduling.
Portability: The class scheduling system is platform independent, so it’s run at any windows.
Low cost: This proposed system will minimize cost, which is the cost, spent to the papers and
other materials which is used by the current manually system.
Accessibility: The user can be printing their scheduled at any time.
Minimize error: If registrar office and department heads are using manual system for schedule
class, error will be occurring. But our proposed system will minimize error occurring.

4.3 System architecture
The proposed subsystem will be implemented using PHP programming language .the below
diagram describes the PHP system architecture model in 3-tier architecture those are database
server, personal desktop and web server.
Figure 19: System architecture model
4.4 Class Diagram
Class Diagram is used to describe the structure of a system by showing the system’s classes,
their attributes and the relationship between the classes. In addition to that it shows the static
relationship between the classes.
Classes that identified form scheduling system are specified by adding the possible methods an
attributes for each classes. The Class during this phase is detailed to help the developer to start
developing the source code.

Instructor
instructor bulding
-instructor_id: int (PK time_start -bulding_id: int (PK)
faculity
-instructor_name: varchar -bulding_name: varchar (U)
-time_start_id:int (PK)
-acadamic_rank:varchar -faculity_id: int (PK) -no_of_room:int
-person_incharge:varchar time_start +add()
-faculity_name: varchar (U) +add()
-distination:varchar -person_incharge:varchar +edit()
-department:varcar +edit() +delete()
-address:varcar +delete()
+add () +add() +search()
+edit () +search()
+edit()
+delete () +delete() bulding
+search () +search()
Depfacu
schedule
time_e room
year_section -schedule_id: int (PK)
-room_id: int (PK)
year_section dep -department:varchar
department -acadamic_year: varchar -bulding_name: varchar
-year_section_id: int (PK -semester: varchar -room_name: varcar (U)
dep -department_id: int (PK) -description: varchar
-year_section: varcar (U) -year_section: varchar
-department:varchar -faculity_name:varchar -course:varchar -max_capacity:int
-no_of_student:int -department_name: varcar (U) -instructor:varchar +add()
+add() -person_incharge:varchar -day:varchar
room +edit()
+edit() -address:varcar -time_start:varchar +delete()
+delete() +add () -time_end:varchar +search()
+search() +edit () -room:varchar
+delete () +add () Add
+search () Acadamic +edit () edit
delete
course -memberName +delete ()
+search () user
search
-course_id: int (PK)
-department:varchar -user_id: int (PK)
-course_code: varchar (U) course -first_name:varchar
-course_title: varchar time_S -last_name:varchar
-course_catagory: varchar -user_name: varchar (U)
-year:varchar -password:varchar
-semester:varchar -email:varchar
-lab_hours:varchar acadamic_year time_end -faculity:varchar
-lecture_hours:varchar -department:varchar
-total_chr:varchar -acadamic_year_id (PK)
-time_end_id:int (PK) -user_type:varchar
-mod_of_delivery:varchar -acadamic-year:varchar -security_q:varchar
time_end
+add () +add() -security_a:varchar
+add()
+edit () +edit() +add ()
+edit()
+delete () +delete() +edit ()
+delete()
+search () +search() +delete ()
+search()
+search ()
Figure 20: class diagram of ADU class scheduling system
4.5 State chart modeling
State chart diagram is used for modeling the dynamic aspects of systems if focuses on
identifying the behavior within our system, behavior specified to the instances of a single class.It
is similar to activity diagram. Both activity and state chart diagrams are useful in modeling the

lifetime of an object. However, activity diagram shows flow of control from activity to activity;
whereas state chart diagram shows flow of control from state to state.
Home page
login
Invalid
Valid
User Account Type
Home
Figure 21: State Chart modeling for login

Home Page
Login
Invalid
Valid
Admin/ Scheduler/ User Home
Select Add Information Catagory
Enter the information on the Provided

form
Click on Save
Invalid
Valid
Figure 22: State Chart Modeling for Adding Information

Index
Select Search Schedule
Select Your schedules Type
Fill Your search Criteriya
Click On Submit Button
Invalid
Valid
System Display the Search Result
The User Can Print or Save the Result
Figure 23: State Chart modeling for search

4.6 Deployment Diagram
A deployment diagram is used to depict the relationship among run-time components and
hardware nodes. A web server, for example, is a component that provides services to Web
browsers. A component is a physical unit of implementation with well-defined interfaces that is
intended to be used as a replaceable part of a system.
Figure 24: deployment diagram architecture model
As you can see from the above diagram a user uses a web server and gain accesses to the
schedule system through the web application server. The web server passes information and
request between user’s web server and a single schedule server.
4.7 Persistence Data Management
As it is discussed in the previous sections, the ADU class schedule system consists of a number
of systems, these are: instructor Registration system, course Registration system, classroom
Registration system, Update Registration system, Delete Registration system, Edit Registration

system, Display Registration system are web based systems that run only over a WAN, and the
persistent data of these systems will be stored in an MySQL database.
Mapping:-
In order to store information persistently we map objects into tables and the attributes into fields
to the specific table based on the objects found on the system. Therefore, we identified the major
tables that will be implemented on the selected DBMS.

faculity faculity <<Table>> department department <<Table>>

-faculity_id: int (PK) -faculity_id: int (PK) -department_id: int (PK) -department_id: int (PK)
-faculity_name: varchar (U) -faculity_name: varchar (U) -faculity_name:varchar -faculity_name:varchar
-person_incharge:varchar -person_incharge:varchar -department_name: varcar (U) -department_name: varcar (U)
-address:varcar -address:varcar -person_incharge:varchar
-person_incharge:varchar
+add() -address:varcar -address:varcar
+edit() +add ()
+delete() +edit ()
+search() +delete ()
+search ()
acadamic_year
acadamic_year <<Table>>
-acadamic_year_id (PK) schedule schedule <<Table>>
-acadamic-year:varchar -acadamic_year_id (PK)
+add() -acadamic-year:varchar -schedule_id: int (PK) -schedule_id: int (PK)
+edit() -department:varchar -department:varchar
+delete() -acadamic_year: varchar -acadamic_year: varchar
+search() -semester: varchar -semester: varchar
-year_section: varchar -year_section: varchar
-course:varchar -course:varchar
bulding<<Table>> -instructor:varchar -instructor:varchar
bulding
-day:varchar -day:varchar
-bulding_id: int (PK) -time_start:varchar -time_start:varchar
-bulding_id: int (PK)
-bulding_name: varchar (U) -time_end:varchar -time_end:varchar
-bulding_name: varchar (U) -room:varchar -room:varchar
-no_of_room:int
-no_of_room:int +add ()
+edit ()
room room <<Table>> +delete ()
+search ()
-room_id: int (PK) -room_id: int (PK)
-bulding_name: varchar -bulding_name: varchar
-room_name: varcar (U) -room_name: varcar (U)
-description: varchar
instructor instructor <<Table>>
-description: varchar
-max_capacity:int -max_capacity:int
-instructor_id: int (PK -instructor_id: int (PK
-instructor_name: varchar -instructor_name: varchar
year_section year_section -acadamic_rank:varchar -acadamic_rank:varchar
-person_incharge:varchar -person_incharge:varchar
-year_section_id: int (PK -year_section_id: int (PK -distination:varchar -distination:varchar
-year_section: varcar (U) -department:varcar -department:varcar
-year_section: varcar (U)
-department:varchar +add ()
-department:varchar
-no_of_student:int +edit ()
-no_of_student:int
+delete ()
+search ()

course course <<Table>> user user <<Table>>

-course_id: int (PK) -course_id: int (PK) -user_id: int (PK) -user_id: int (PK)
-department:varchar -department:varchar -first_name:varchar -first_name:varchar
-course_code: varchar (U) -course_code: varchar (U) -last_name:varchar -last_name:varchar
-course_title: varchar -course_title: varchar -user_name: varchar (U) -user_name: varchar (U)
-course_catagory: varchar -course_catagory: varchar -password:varchar -password:varchar
-year:varchar -year:varchar -email:varchar -email:varchar
-semester:varchar -semester:varchar -faculity:varchar -faculity:varchar
-lab_hours:varchar -lab_hours:varchar -department:varchar -department:varchar
-lecture_hours:varchar -lecture_hours:varchar -user_type:varchar -user_type:varchar
-total_chr:varchar -total_chr:varchar -security_q:varchar -security_q:varchar
-mod_of_delivery:varchar -mod_of_delivery:varchar -security_a:varchar -security_a:varchar
+add () +add ()
+edit () +edit ()
+delete () +delete ()
+search () +search ()
time_end time_start
time_end<<Table>> time_start <<Table>>
-time_end_id:int (PK) -time_start_id:int (PK)
time_end -time_end_id:int (PK) -time_start_id:int (PK)
time_start
+add() time_end +add() time_start
+edit() +edit()
+delete() +delete()
+search() +search()
Figure 25: mapping object.
4.8 Access Control and security
Access control is way of limiting access to a system or to physical or virtual resources. In

computing, access control is a process by which users are granted access and certain privileges to
systems, resources or information. In access control systems, users must present credentials
before they can be granted access. In physical systems, these credentials may come in many
forms, but credentials that can't be transferred provide the most security.

Function Actors
Scheduler Department System user

head
Add entry 
View course  
Add schedule 
View schedule   
Manage system user 
Manage schedule 
Submit sleep 
Search class schedule   
Print   
Login  
Figure 26: Access Control and Security.
4.9 User interface
User interface design or user interface engineering is the design of computers, appliances,
machines, mobile communication devices, software applications, and websites with the focus on the
user's experience and interaction. The goal of user interface design is to make the user's interaction
as simple and efficient as possible, in terms of accomplishing user goals what is often called user-
centered design

Figure 27: Home Page
Figure 28: Add course offering

Figure 29: Add Entry College, block etc.
Figure 30: Add schedule

CHAPTER FIVE
5 IMPLEMENTATION AND TESTING

5.1 Implementation Overview
Implementation in the system includes implementing the attributes and methods of each object
and integrating all the objects in the system, to function as a single system. The implementation
activity spans the gap between the detailed object design model and a complete set of source
code files that can be compiled together.
In this chapter we mainly focuses on the implementation part, implementation concerned with the type of
material (Hardware and Software required), techniques to develop the system, algorithm for the system,
code samples of the system, data preparation, how to install the system, some testing techniques, start up
strategy for the new installed system and some others are briefly described.
5.1.1 Objective of the implementation

The objective of systems implementation phase is to convert the final physical system
specifications into working and reliable system, document the work that has been done, and
provide help for current and future users and caretakers of the system.
5.2 Sample code and overview
sampleCode for authentication / seassion creation/ error message and history log
following code is used when the user enter his user name and password the system accept the
name and password and cheek its validity and if it is valid take the user to his privilege page, by
using the

<?php
if (isset($_POST['Login']))
{
function clean($str) {
$str = @trim($str);
if (get_magic_quotes_gpc())
{
$str = stripslashes($str);
}
returnmysql_real_escape_string($str);
}
$user_name=clean($_POST['user_name']);
$password=clean($_POST['password']);
$user_type=clean($_POST['user_type']);
$login_query=mysql_query("select * from users where user_name='$user_name'

and password='$password' and user_type='Scheduler'");
$login_query1=mysql_query("select * from users where
user_name='$user_name' and password='$password' and user_type='User'");
$count=mysql_num_rows($login_query); // this is 4 Scheduler

$count1=mysql_num_rows($login_query1); // this is 4 user
$row=mysql_fetch_array($login_query);
$row1=mysql_fetch_array($login_query1);
$f=$row['first_name'];
$l=$row['last_name'];
$user_type=$row['user_type'];
if ($count == 1)
{
$logout_query=mysql_query("select * from users where user_id='".$row['user_id']."'");

$row=mysql_fetch_array($logout_query);
mysql_query("INSERT INTO history (data,action,date,user)VALUES('$f $l', 'Login',

NOW(),'$user_type')")or die(mysql_error());
session_start();
session_regenerate_id();
$_SESSION['id']=$row['user_id'];
header('location:home.php');
session_write_close();
exit();
}
else if ($count1 == 1)
{session_start();
$_SESSION['id']=$row2['user_id'];
$logout_query=mysql_query("select * from users where user_id='".$row['user_id']."'");

$row=mysql_fetch_array($logout_query);
mysql_query("INSERT INTO history

(data,action,date,user)VALUES('$f $l', 'Login', NOW(),'$user_type')")or die(mysql_error());
Session _start ();

session_regenerate_id();
$_SESSION ['id']=$row['user_id'];
header('location:user_home.php');
session_write_close();

exit();
}
// the following message will be displayed when the user submit an invalid informaion
else{
?>
<div class="alert alert-error">
<button class="close" data-dismiss="alert">×</button>
Please check your User Name,Password and select ur account type
and try again!!!
</div>
<?php }
}
?>
Sample code for checking whether the field takes only Numbers or not
if(isset($_POST['submit']))
{
$user_name=$_POST["user_name"];
$password=$_POST["password"];
$user_type=$_POST["user_type "];
if(is_numeric($password) || is_numeric($password) || is_numeric($user_type))

{ ?>
<script type="text/javascript">
alert('All information must be character strings');
history.back();
</script>.
<?php
}
?>

5.3 Testing Overview
Testing is the process of running a system with the intention of finding errors. Testing
enhances the integrity of a system by detecting deviations in design and errors in the
system. Testing aims at detecting error-prone areas. This helps in the prevention of errors
in a system. Testing also adds value to the product by conforming to the user
requirements.
In this phase the entire software system is tested. The reference document for this process is the
requirements document, and the goal is to see whether the software meets the requirements.
5.3.1 Test by scope

5.3.1.1 Unit testing
In computer programming, Unit testing is a procedure used to validate that individual units of source
code are working properly. So In this test the team tries to test each module individually but not
integrate the whole system. It focuses verification efforts even in the smallest unit of software design
in each module. This is also known as ―Module Testing.The testing is carried out in the
programming style itself. In this testing each ,module is focused to work satisfactorily as regard to
the expected output from the module .There are some validation checks for the fields.
Test Case1:
Test Case Name: Login
Purpose: To verify (authenticate) authorized users
Input Expected Result Output Pass/Fail
Valid user name and The system Successfully The system Successfully accept Pass
password combination accept the user and display the user and display the user
the profile page profile page
Valid user name and Please check your User Please check your User Name, fail
invalid Password Name, Password and select ur Password and select ur account

account type and try again!!! type and try again!!!
Incorrect user name Please check your User Please check your User Name, fail
and valid Password Name, Password and select ur Password and select your
account type and try again!!! account type and try again!!!
Incorrect user name Please check your User Please check your User Name, fail
and Incorrect Name, Password and select ur Password and select ur account
Password account type and try again!!! type and try again!!!
Null user name and "Pleas fill out this filed" by "Pleas fill out this filed" by fail
Password pointing the empty field pointing the empty field
User name and null "Pleas fill out this filed" by "Pleas fill out this filed" by fail
Password pointing the empty field pointing the empty field
5.3.1.2 Integrated testing

Integration testing (sometimes called, Integration and testing, abbreviated I&T) is the phase of
software testing in which individual software modules are combined and tested as a group. So
the team in this testing part combined all the modules together and tested it for its fitness with
each other and with the systems functionality. If error occurs in combining them, the module
with problem will be identified.
5.3.2 Testing By Requirements

System test insures that the entire integrated software system meets requirements. It tests a
configuration to insure known and predictable results. System testing is based on process
description and flows, emphasizing pre-driven process links and integration points.
In essence system testing is not about checking the individual parts of design, but about checking
the system as a whole. In effect it is one giant component.
System testing insures the following have been met correctly. They are:

 Functional requirements
 Non Functional requirements such as
 Performance:-Are the performance criteria met?
If our computer performance is high then the system test will show you that the
performance requirement satisfied.
 Volume:-Can large volumes of information are handled?
Large volume of information can be handled in our system.
 Documentation:-Is the documentation usable for the system?
The documentation can be used as a guide for the user of the system.
 Robustness:-Does the system remain stable under adverse circumstances?
Is a system able to hold different obstacles?
5.3.3 Test Implementation (Validation testing)
 Password checking:
When unauthorized users are try to access to the system displays an alert message “please check
user name, password and select ur account type and try again”.
 Data type validations:
Accepts only validate data .If you insert invalidate data the system display alert message “please
insert validate data “.
 Null input:
Allows the system to accept the needed data rather than null. Else display an error message box.
5.4 Hardware Software acquisitions
For the project implementation, the following hardware and Software’s are used.
Hardware:-
 Printer: For printing Documentation
 Computers
 Flash Disk(8 GB)
 RG 45 cable

Software:-
 Operating system:- Window 7 and Windows 8
 Modeling Software: - Microsoft Visio2013.
 Programming language:-
-Php, Java script, query, Ajax
 As Server Software:- Wamp server V. 2.1

 Database Software :- MYSQL 5.0
 Antivirus:- A vast
 Document tools:- MS word.
 Presentation: - MS power point.
 IIS server
 Firefox browser
 Adobe photo shop
5.5 User manual preparation
In order to access the system, first of all every user i.e. department head must have an
account or permission from scheduler/admin. So scheduler has the right to create an account
for every user like department head and for him/her. Users should enter into the system parts
by using their User Name and Password in order to access the system. These User Name and
Password are created by the scheduler.
5.6 Installation Process
CSS is a web based system as a result there is no need to install it on a particular machine rather
it will be hosted on a server then a system user can access via local area connection.

5.7 Start-up strategy
Once the system has been deployed, the system users in our case there is some authorized users for
example department head. System user enters to authorized page by entering the correct user
name (ID) and password.

CHAPTER SIX
6 CONCLUSIONS AND RECOMMENDATION

6.1 Conclusion
The objective of this project was to build a web based program for property Adigrat University
office of registrar In order to facilitate their work and make computerize. The system developed
is able to meet all the basic requirements. It will provide the facility to the end-user, the Adigrat
University office of registrar scheduling staff will be also benefited by the proposed system, as it
will automate the whole procedure, which will reduce the workload. The security of the system
is also one of the prime concerns finally the important thing is that the system should be flexible
enough for future modifications and to maintain. Every effort has been made to cover all user
requirements and make it user friendly.
6.2 Recommendations
Nowadays, the world is highly becoming a competitive world. Organizations have to divert their
attention on using the recent technology to be on the first line and competitive. This can be real if
they are able to use computerized system to successfully achieve their objective. Adigrat
University is the Government institution that includes many offices in fulfilling its function. As we
describe in this document, almost all activities of the organization is done on manual basis. The
project team wants to recommend some ideas considering the project .This project is developed
based on the current problems of scheduling staff of Adigrat University registrar office so we
think that this project is the best solution for the problems raised based on the manual system of
the office. And help the office to save time, money and man power whenever the project is small
scale.
From the various facts that constitute the project, the following points can be recommended:
 Attention should be given to the existing practice in the design, development and
utilization of the new system.
 Serious consideration should be given for the introduction of the new system.

 Behavioral change of the users of the system to adapt the new system.
 There should be a network infrastructure in order to connect the different computers and
access the system.
 We advise that the site be hosted on a secure server and that the administration of the
website is give to a person or entity that has experience in managing a website.
 We also fell for ease of access an accompanying application is developed for the system
for Smartphone implementing the Android and IOS operating systems.
Finally the project teams concluded that the department should give a special consideration for
the computer lab, internet connection and last semester studying credit hours specially for
graduating student, because during the development of the project the group members faced
some problems because of this.

References
Book
1. A.Hoffer. (2007). Modern Systems Analysis and Design (6th Edition).

2. . Boston: Allyn and Bacon(2000).Object Oriented System Analysis and Design(6th
Edition)
3. James Rumbaugh, Ivan Jacobson, Grady Booch. The Unified Modeling Language
Reference Manual (5th Edition)..
4. Whitten, L.Jeffrey.Bentley, D.Lonne.Barlow, M.Victor. Systems Analysis and
Design Methods (2nd Edition).

Webliography
1. https://www.google.com.et/#q=classroom+scheduling+system+documentation
2. http://www.w3schools.com
3. http:// www.uml diagram.org
4. http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
5. http://guide.agilealliance.org/guide/acceptance.html
6. http://en.wikipedia.org/wiki/Class_diagram
7. http://www.mitre.org/publications/systems-engineering-guide/
8. http://en.wikipedia.org/wiki/Systems_analysis
9. http://en.wikipedia.org/wiki/Activity_diagram
10. http://searchsoftwarequality.techtarget.com/definition/3-tier-application
11. http://www.planet-source-code.com/vb/default.asp?lngWId=8

Appendix
Interview questions
1. When was the college established?

2. How many departments and students are there?
3. How is the current scheduling system works?
4. What is the basic problem of the current scheduling system?
5. What are the strength and weakness of the current system?
6. How much time does the scheduling process take?
7. Who is responsible for scheduling class schedule?
8. What are the business rules of the organization?
9. What kind of features would you expect from the new system?
10. How the scheduler is benefit from the new proposed system? What about instructor and
student?
11. How are the scheduling distributed to the instructor and students?
Full name and signature__________________________________________

DEPARTMENT OF COMPUTER SCIENCE Project o

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DEPARTMENT OF COMPUTER SCIENCE Project o

Uploaded by

Copyright:

Available Formats

ADIGRAT UNIVERSITY

COLLEGE OF ENGINEERING AND TECHNOLOGY

1. Zerue Tlahun RET 1817/06

Advisor Name: Inst. Filmawit M.

Submitted to Department of Computer Science, college of engineering and technology of

Mhret Aregay Signature

Bizen Geremeskel Signature

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM i

Program: Computer Science

Project subject: CLASS SCHEDULING SYSTEM FOR ADU

Name of Department Head Signature

Name of Advisor Signature

Examining committee members Signature Date

1. Chairman ____________ ___________ ___________

2. Examiner 1 ____________ ___________ ___________

3. Examiner 2 ____________ ___________ ___________

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM ii

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM iii

Table of Contents pages

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM iv

1.9.6.4 Schedule feasibility ..................................................................................................... 8

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM v

3.2.1 Actor Specification ....................................................................................................... 21

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM vi

5.3.1 Test by scope................................................................................................................. 68

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM vii

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM viii

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM ix

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM x

Acronyms and Abbreviation

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM xi

Accuracy: Is the quality or state of being correct or precise.

Availability: Is Present and ready for use at hand accessible.

Browser: Is a software application for retrieving presenting and traversing information

Performance: Is an act of presenting a play concert or other form of entertainment.

Reliability: Is dependability: the quality of being dependable or reliable.

Security: Is the state of being free from danger or threat.

Documentation: Is material that provides official information or evidence or that serves.

ADGRAT UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE CLASS SCHEDULING SYSTEM xii

1.2 Background of the project

Department of computer science Page 1

1.3 Statement of the Problem

Department of computer science Page 2

1.4 Objectives of the project

1.4.2 Specific Objectives

1.5 Scope of the project

Department of computer science Page 3

1.6 Limitation of the project

The Project does not include:

1.7 Significance of the Project

1.8 Target Beneficiaries of the System

Department of computer science Page 4

1.9 Methodology of the project

1.9.2 Fact finding technique

Department of computer science Page 5

1.9.3 System Analysis and Design Methodology

1.9.3.1 Object oriented Analysis

1.9.3.2 Object oriented design

1.9.4 Development Methodology

1.9.5 Implementation methodology

Department of computer science Page 6

1.9.5.1 Software Tools

1. Chairman ______ _ _______

2. Examiner 1 ______ _ _______

3. Examiner 2 ______ _ _______