Haramaya University

HARAMAYA UNIVERSITY
COLLEGE OF COMPUTING AND INFORMATICS
DEPARTMENT OF SOFTWARE ENGINEERING
Requirement Document on Online Teachers Evaluation System

Teachers Evaluation Systems

By : Group : 2

Group Members:

Name Id No

1. Bekalu Atto ------------------------------------ 0232/12

2. Daniel Mesfin ----------------------------------- 1732/12

3. Abel Mulatu ----------------------------------- 0305/12

4. Selatiyal Tinsay --------------------------------- 0345/12

5. Semmira Ahmed -------------------------------- 4136/12

SUBMITTED TO :
SUBMISSION DATE :

Page i
 Haramaya University

ABSTRACT
Haramaya University instructors are evaluated by manual paper based evaluation
questionquestions. The existing system is not fully computerized. There is fully manual job. First
the form is prepared by the the university standard based on different criteria to different
evaluators such as: - forms filled by student, co-workers(peers), and head with a little different
criterion.

The current Evaluation system is currently working by using manual way which means fully
paperwork, which consist a lot of man power and time in managing the record and evaluation
process. And human mistake is unavoidable while the workload is increasing. Therefore we
motivate for the developing of Instructors evaluation system, which making their Evaluating
instructors performances form paperwork into automate system.

Generally in this project, we developed an automated OTES that facilitates various activities
taking place at the Haramaya University. The OTES do different activities such as evaluate
instructor, view average result. This project must be an active document that grows with changes
while anticipating future requirements like integrates the system to mu student website.

Page ii
 Haramaya University

Table of Contents
CHAPTER ONE..........................................................................................................................................1
1.1 Background..................................................................................................................................1
1.2. Statement Of The Problem...............................................................................................................2
1.2.1 Problem of Existing System........................................................................................................2
1.3. Objective..........................................................................................................................................2
1.3.1 General Objectives......................................................................................................................2
1.3.2 Specific Objectives.....................................................................................................................3
1.4 Significant of the project...................................................................................................................3
1.5. Scope and Limitation........................................................................................................................3
1.5.1 Scope..........................................................................................................................................4
1.5.2. Limitation..................................................................................................................................4
1.6. Methodology....................................................................................................................................4
1.6.1 Data collection Methodology......................................................................................................4
1.6.2 Software Development Methodology.........................................................................................5
1.6.2.1 Process model..........................................................................................................................5
1.6.3 System development tool............................................................................................................5
CHAPTER TWO.........................................................................................................................................7
SYSTEM ANALYSIS.............................................................................................................................7
2.1. Introduction......................................................................................................................................7
2.2. Purpose of the project.......................................................................................................................7
2.3. Scope of the system..........................................................................................................................7
2.4. Objectives and success criteria of the project...................................................................................8
2.5. Definitions, acronyms, and abbreviations.........................................................................................8
2.6. Current system description...............................................................................................................8
2.6.1 Evaluation procedure..................................................................................................................8
2.7. The proposed system........................................................................................................................9
2.7.1 Overall Description.....................................................................................................................9

Page iii
 Haramaya University

2.8. Functional Requirement....................................................................................................................9

2.9. Nonfunctional requirement.............................................................................................................12
SYSTEM MODELING.........................................................................................................................14
2.10. Scenarios...................................................................................................................................14
2.10.1 Use case Diagram...................................................................................................................14
2.10.2 Use case description................................................................................................................16
2.8. Analysis object model.....................................................................................................................23
2.11. Dynamic Model............................................................................................................................26
2.11.1 Sequence diagrams.................................................................................................................26
CHAPTER THREE...................................................................................................................................28
SYSTEM DESIGN DOCUMENT........................................................................................................28
3.1.1 Overview of System Design.....................................................................................................28
3.1.2 Design Goals for OTES system..............................................................................................28
3.1.3. Definitions, acronyms, and abbreviations................................................................................29
3.2. Overview:.......................................................................................................................................30
3.2.1. Current System Architecture....................................................................................................31
3.2.2. Proposed System Architecture.....................................................................................................31
3.3. Overview........................................................................................................................................33
3.3.1 Subsystem decomposition.........................................................................................................33
3.4. Hardware/software mapping...........................................................................................................33
3.5. Persistent data management..........................................................................................................34
3.5.1 Data Object...............................................................................................................................35
3.5.2. Logical Database schema.........................................................................................................37
3.5.3. Access Control and Security....................................................................................................37
3.6. Global software control..................................................................................................................38
3.7. Boundary Condition.......................................................................................................................39
3.8. Exception Handling........................................................................................................................39
3.9. Sub system Description..................................................................................................................41
CHAPTER FOUR..........................................................................................................................................42
TESTING AND DEBUGGING....................................................................................................................42
4. INTRODUCTION.............................................................................................................................42
4.1. Objective........................................................................................................................................42

Page iv
 Haramaya University

4.2. Form Layout design........................................................................................................................42

4.2.1 Log in form...............................................................................................................................42
4.3. Testing............................................................................................................................................43
4.4. Coding............................................................................................................................................44
4.4.2. Unit Testing.......................................................................................................................44
4.4.3. Acceptance Testing............................................................................................................45
4.4.4. System Testing...................................................................................................................46
4.4.5. Sample code.......................................................................................................................46
CHAPTER FIVE............................................................................................................................................52
CONCLUSION AND RECOMMENDATION.....................................................................................52
5.1. Conclusion......................................................................................................................................52
5.2. Recommendation............................................................................................................................52
6. Glossary.............................................................................................................................................53
7. Reference......................................................................................................................................54

List of Figures

Figure 1 use case diagram..........................................................................................................................15

Figure 2 class diagram...............................................................................................................................25
Figure 3 sequence diagram for login.........................................................................................................26
Figure 4 sequence diagram for evaluate instructor...................................................................................27
Figure 5 Proposed system diagram...........................................................................................................32
Figure 6 Deployment diagram...................................................................................................................34
Figure 7 Subsystem architecture...............................................................................................................40
Figure 8 Log in form..................................................................................................................................42
Figure 9 Evaluation form...........................................................................................................................43

Page v
 Haramaya University

List of Tables

Table 1 Use case description.....................................................................................................................22

Table 2 data object for student table........................................................................................................35
Table 3 data object for account table........................................................................................................35
Table 4 data object for result table...........................................................................................................35
Table 5 data object for Teacherstable.......................................................................................................36
Table 6 data object for chair head table....................................................................................................36
Table 7 data object for evaluation table....................................................................................................36
Table 8 data object for school information...............................................................................................36
Table 9 Table data object for administrator table.....................................................................................36
Table 10 Access control.............................................................................................................................38

Page vi
 Haramaya University

CHAPTER ONE

1.1 Background

It is obvious that in all Ethiopian higher institutions many Systems are not automated as
much as it is expected to be. Almost all activities are going on manually, which leads to
wastage of time, labor, accuracy, and speed. Teachers evaluation system is evaluating the
Teachers performance and skills using some criteria by using papers or manually. The
paper distributed through the students by the evaluator committee and collected the paper
back. After collected the paper they sum up the results of each Teacher from the paper.
This project solves the problem by developing web based application for Teachers
Evaluation System is manual which evaluates the performance of teaching and learning
process each teacher in the school. Our system will mainly focus on evaluating the
teachers with a pre-specified evaluation criteria and display evaluation result in a report
format. The purpose of this evaluation is to managing teaching learning process and to
reward those Teachers who were dedicated and work hard in the teaching learning
process and increase their performance. At thisuntil this time evaluation of teachers is
done manually an.d they use one system to compute evaluation result. But Tthus, thise
existing manual system is weak and does not fulfill all teachers evaluation requirement.
So we are going to develop a web based Teachers Evaluation System that overcomes the
problems of the existing system. Our new system enables both teachers and the students
to efficiently use their time and resources. The systems we are developing will be more
efficient and reliable.

1.2. Statement Of The Problem

Page 1
 Haramaya University

Haramaya University instructors are evaluated by manual paper based evaluation

question. The existing system is not fully computerized. There is fully manual job. First
the form is prepared by the the university standard based on different criteria to different
evaluators such as: - forms filled by student, co-workers / peers, and head with a little
different criterion. Then paper is duplicated and delivered to those evaluators. Then the
evaluator fills the form on the paper, eventually the form filled back to the committee.
After collecting the form from each student the evaluator gives the form to College.

1.2.1 Problem of Existing System

As we have analyzed the problem of the existing system, the system has the following
problems;
 The system is paper based or manual.
 It is costly in which duplicating many papers.
 Working is not efficient way
 It’s time consuming
 The evaluation held in the classroom, which may affect teaching learning
time.
 Sometimes the evaluation is not going on time.
 A student is able to evaluate a teacher more than once.
 To calculate the evaluated result is time consuming
 Administrative assistant waste their time in distributing and collecting the
forms.
This project should overcome problems listed above by developing web based
application.

1.3. Objective

1.3.1 General Objectives

The general objective of this project is to develop a OTES(Online Teachers Evaluation
System).

Page 2
 Haramaya University

1.3.2 Specific Objectives

Specifically OTES will perform the following things.

 To design Teachers evaluation based on the university standard question or

criteria.
 To develop real time web based Teachers evaluation system by
HTML,CSS ,Java-script ,php programming and MySQL data base management
system, by using them at front end tool and back end tool .
 Portable application (it can access from any were. Whether the evaluator found in
university or not)
 To prepare accurate result of evaluated instructor.
 To solve school of computing evaluator problems.

1.4 Significant of the project

The new system is bringing remarkable change in the Teachers evaluation system.
This project has the following significant:-
 Used for Haramaya University to evaluate instructors any time , anywhere.
 It saves time to calculate instructor’s evaluation result.
 The system gives fast delivery evaluation report for school of computing.
 Developers getting experience.
 Instructors evaluated correctly because one evaluator can evaluate only ones.
 Generally it is used for Colleges , staff members for saving their time, man power.

1.5. Scope and Limitation

Haramaya university evaluation type is subdivided into different evaluator like: staff
evaluation, administrative evaluation, Teachers evaluation. Among them our project
emphasis is on automating only Teachers evaluation.

Page 3
 Haramaya University

1.5.1 Scope
This project designs and implements OTES in and can be accessed easily through WAN,
internet and LAN networks.

 The students, co-workers(peers), sSchool head should fill the evaluation form and
submit it.
 The system cCalculate the values filled by the evaluator and store it in to the
database.
 Then the head can easily view each instructor’s evaluation total as well as average
result.

1.5.2. Limitation
The system expects to evaluate faculty members like secretary, lab assistance but
currently don’t focus about these because as we mentioned above the scope of this project
is only Teachers evaluation.
The following are the limitation of our system:
 Evaluation system expected to evaluate all staff members but our system evaluates
only Teachers.

1.6. Methodology

1.6.1 Data collection Methodology

In order to gather the relevant data, we use both primary and secondary way of data
collection so that help us for studying the system analysis.
Primary data collection:
Practical observation:-enables us to list out the existing system problems, since it is what
we see or observe in reality.
Secondary data collection: we went to College of computing administrator and we get
forms that are prepared for the university standards.

Page 4
 Haramaya University

1.6.2 Software Development Methodology

1.6.2.1 Process model

The project modeling process is prototyping. Users are actively involved in the
development. Since in this methodology a working model of the system is provided, the
users get a better understanding of the system being developed. Errors can be detected
much earlier. Quicker user feedback is available leading to better solutions.

1.6.3 System development tool

Front-end Technologies
We use the front-end of the software systems developed using HTML, php, JavaScript,
CSS markup language and style sheet.
Back-end Technologies
One of the most important technologies in the implementation, and deployment of the
software system is the back-end or database technology. We decide to use MYSQL.
MySQL server compared to others:

 MySQL Advantage is a suite of for web based application, and well-supported

ones–that work together to run interactive, dynamic Internet sites.
 MySQL is characterized as a free, fast, reliable open source relational database. It
does lack some sophistication and facilities, but it has an active development team
and, as it goes from release to release, more capabilities are added. At certain
times there will be a trade-off between speed and capabilities, and the MySQL
team intends to keep their database engine fast and reliable.


Page 5
 Haramaya University

My SQL Features:

 Because of its unique storage engine architecture MySQL performance is

very high.
 Supports large number of embedded applications which makes MySQL very
flexible.
 Use of Triggers, Stored procedures and views which allows the developer to
give a higher productivity.
 Allows transactions to be rolled back, commit and crash recovery.
 It's secure: MySQL includes solid data security layers that protect sensitive
data from intruders. Rights can be set to allow some or all privileges to
individuals. Passwords are encrypted.
 It's inexpensive: MySQL is included for free with NetWare® 6.5 and
available by free download from MySQL Web site.

 CHAPTER TWO

REQUIREMENT ANALYSIS

Page 6
 Haramaya University

2.1. Introduction
System analysis is the transformation of the problem statement into analysis model. Up to
now we were in the problem domain. This chapter focuses on studding the analysis of
functional requirements, nonfunctional requirements and constraints described in the
problem statement sections.

2.2. Purpose of the project

The purpose of this document is to describe the requirement analysis document which
includes current system description, activity provided by existing system, overview of
proposed system, functional and nonfunctional requirements. And the next is system
designing that contain: physical and logical design, design tool use case diagram,
sequence diagram, and class diagram.

2.3. Scope of the system

Haramaya university evaluation type is subdivided into different organs like: staff
evaluation, administrative evaluation ,Teachers evaluation . among this our project
emphasis on automating evaluation system of the Teachers. That is to change the manual
system into automated system. The automated system is a web based application
overcome existing challenges by providing the following features.

 It allows evaluate Teachers performance.

 It allows to update users profile
 Generating conclusive report to give the evaluation result for Teachers.
 It allows viewing evaluation result.

2.4. Objectives and success criteria of the project

The general objective of this project is to develop a Web based Teachers evaluation
System to evaluate Teachers.

Page 7
 Haramaya University

2.5. Definitions, acronyms, and abbreviations

OTES: Online Teachers Evaluation System

FR: functional requirement

NFR: nonfunctional requirement

2.6. Current system description

The existing system of Haramaya University Teachers evaluation system is a manual
system. Evaluation form is prepared by the university standards based on different
criteria to different evaluators after the paper is prepared, the paper is distributed among
all the colleges, and finally colleges distribute the evaluation paper to their Schools. After
the Schools receive the evaluation paper from their colleges, then the School distributes
evaluation paper to their students and the students fills the evaluation forms to the
evaluator teachers. After this the School collects the evaluated paper from the students
then the School sends to administrative assistant. And the administrative assistant
calculates the total and average result using excel. At the end the administrative assistant
return the evaluation total result in Schools or department to each evaluated teachers.

2.6.1 Evaluation procedure

Step 1. There is prepared evaluation paper by the university standards

Step 2. Distribute to their Schools or department.

Step 3. Then distributes the paper to students, teachers(peers) and head.

Ste p 4 The evaluator fill the form and back.

Step 5. The evaluation committee collects the paper and give to the administrative
assistant

Step 6.At the end the evaluation coordinator will return the evaluation total result in
Schools or department to each evaluated teachers.

2.7. The proposed system

Page 8
 Haramaya University

The proposed system has many applications and advantages compared to the existing
system. It solves the problems of the existing system and increase the performance of the
evaluation. In our proposed system we develop a web based application Teachers
evaluation system that is capable of controlling the evaluation form.
The applications of proposed system are:
 Replace the manual to automated system.
 The proposed system enables to calculate the evaluation result and store
evaluation information in the database.
 The application composes different forms to store data to the database and
retrieve required information from the database.
 Create accounts for different users .
 Deactivate created personal accounts if needed.

2.7.1 Overall Description

Teachers Evaluation system is a web application more reliable and efficient service. Any
operations can be done easily with an easy interaction with the system. Furthermore, the
system especially could used to evaluate tTeachers and might calculate the evaluation
result more easily than before the existing system.

2.8. Functional Requirements

Page 9
 Haramaya University

The functional requirements are the features that the system must include to satisfy the
system need and to be acceptable by the user. The functional requirements of proposed
system are:-

[FR-01]: add information of head of department

Description: The system must continuously add information of head of department
based on the correct input given.

Requirements: The system need inputs like full name email address, office number. Fill
the inputs correctly then click add button.

Ranking: Essential

[FR-02]: Add evaluation criteria

Description: The system must continuously add evaluation criteria based on the correct
input given.

Requirements: The system need inputs like criteria id with one word explanation e.g.
explain objective then click Add evaluation criteria button.

Ranking: Essential

[FR-03]: Delete evaluation criteria

Description: The system must delete evaluation criteria based on the order.
Requirements: The system must allow the administrator to delete evaluation criteria in
the system by clicking the delete button.
Ranking: Essential

[FR-04]: Update evaluation criteria

Description: making or becoming different from the previous record.

Requirements: To update evaluation criteria fill the criteria id what you want then click
update button.

Ranking: desirable

Page 10
 Haramaya University

[FR-05]: Filling evaluation forms

Description: The system continuously accepts the correct input given before.
Requirements: The system need inputs like (0-5) checking the respective radio button,
then click submit button.
Ranking: Essential

[FR-06]: Add student and Teachers records

Description: The system must continuously add students and Teachers information based
on the correct input given.

Requirements: The system need inputs like full name, id, year, department, section
email address, office number respectively. Fill the inputs correctly then click add button.

Ranking: Essential
[FR-07]: Modify account information
Description: The system must modify account information based on the correct input
given.
Requirements: The system need inputs old password, new password, confirm password.
Fill the input correctly then click update button.
Ranking: Essential
[FR-08]: View average result
Description: The system must display the average result in graphical format for each
single criterion.
Requirements: The head firstly select Teachers name then click the average result
button.
Ranking: Essential
[FR-08]: View overall average result
Description: The system must display the overall average result in table format for each
single criterion with its remark.
Requirements: The head firstly select Teachers name then click the view overall average
result button.
Ranking: Essential

Page 11
 Haramaya University

[FR-09]: create account

Description: The system must continuously create account based on the correct input
given.

Requirements: The system need inputs like username, password, email address, then
click Add evaluation criteria button.

Ranking: Essential

2.9. Nonfunctional requirement

A Non-Functional Requirement is usually some form of constraint or restriction that must
be considered when designing the solution. Non-functional requirements of the proposed
system are:

[NFR-1] usability

Description: the system must be easily understandable by the clients without requiring
much experience and expertise .

Requirement: the system is object oriented approach.

Rank: essential

[NFR-2] reliability

Description: it describes the functionality of the system

Requirement: the system must be includes all the requirements of the client.

Rank: essential

[NFR-3] performance

Description: describes the ability of the system for its function and

Waiting for an application to load can be frustrating for an end user. so make them a
quick start up is extremely important.

Requirements: The System must have a startup time of less than 5 seconds,
Page 12
 Haramaya University

Rank: essential

[NFR-5] Supportability.

Description: the system must be run in all browser.

Requirement: The system must compile and run successfully on any Windows.

Rank: essential.

[NFR-7] implementation

Description: The system is implemented using PHP, HTML and uses MySQL for
database.

Requirement: the system must be corrective, adaptive, or perfective through time.

Rank: desirable

[NFR-8] interface

Description: boundary between the user and the system.

Requirement: the system has an interface that enables for the data flows from the data
base.

Rank: essential

[NFR-9] packaging

Description: installing of the system by the client to use it.

Requirement: the loading time must be less than 5minutes.

Rank: essential

Page 13
 Haramaya University

CHAPTER THREE

SYSTEM MODELING

32..10. Scenarios
Scenario name: Instructors Online Teachers evaluation

Participating actor student: Abeche: Instructor: Keemeto: head: Gaawo: Admin:

Demeke

At the end of the semester the college need to evaluate the Teachers performance. Next
to that Demeke create the account of Gaawo, Abeche, and Keemeto. Then the actor’s
login to OTES and Evaluate Teachers performance based on the prepared form displayed
by the system. Means Abeche, Gaawo, Keemeto fill the evaluation form and click the
submit button, Based on the evaluation rule and regulation OTES calculates the Teachers
Evaluation Result. Then each Teachers can see their own result and also the school head
Gaawo can see all instructors’ evaluation result.

32.10.1 Use case Diagram

Use case diagrams are created to visualize interaction of our system with external world.
Also a use case model is the representation of the system intended functions and its

Page 14
 Haramaya University

environment. The functionalities are specified by the “use case” and “the actor “specified
to the environment. Since the identification of these two entities goes hand in hand, we
have identified them together.
The actors are: -
 Student
 Teachers
 Head
 Administrator
 Co-workers or peers

The use cases are: -

 Login
 Evaluate Teacher
 Update account
 Create account for user(one who evaluates the Teacher)
 Deactivate user account when needed
 Add Teachers records
 View evaluation result
 add new evaluation Criteria if any
 Delete evaluation criteria
 Modify evaluation criteria
 Register department information like Semester, Batch, Section, Year, Course

Page 15
 Haramaya University

Figure 1 use case diagram

32.10.2 Use case description

Add student and Teachers records
Use case name Add student and Teachers records
Identifier UC 001
Actor(s): Head
Description Allows Head to add records of the students and Teachers.
Precondition Head must have an account, the students and the Teachers
are going to register in the system.

Page 16
 Haramaya University

Basic course 1. Login by providing appropriate information

of actions 2. Click on Add record button
3. Choose to add the students or the Teachers record.
4. Fill the information
5. Click Add button
6. Use case ends
Alternative Step1. If the Head do not have an account, the login fails.
course Step5. If the students or the teacher’s information is not
of action correct or not fully added. Add record will fail.

Post The teachers or students information is added.

condition

Add Head Record

Use case name Add Head Record

Identifier UC 002
Actor(s) Administrator
Description Allow administrator to add the Head information.
Precondition Administrator must have an account and the head must be
selected as a head by the admin.
Basic course 1. Administrator login in his/her own account
of actions 2. Click on Add record button
3. Fill the information
4. Click Add button
5. Use case ends

Alternative Step1. If the administrator doesn’t have an account, the login

course of fails.
action Step3. If the head information is not correct or not fully
added. Add record will fail.
Post Head information is added

Page 17
 Haramaya University

condition:

Fill evaluation form

Use case name Fill evaluation form
Identifier UC 003
Actor(s) Student, Teacher(peer), head
Description Allows the Actor(s) to fill the evaluation form to evaluate
teachers
Preconditio Actor(s) must be authorized to perform this activity and the
n Head must activate the evaluation date and the evaluation
instructor’s.

Basic 1. Actor(s) enters username and password to the system.

course 2. Clicks on evaluation button
of actions 3. Selects the teacher name to evaluate.
4. Fills the evaluation form.
5. The system calculates the evaluation result
6. Clicks save button
7. The use case ends

Alternative Step 1. If the student’s username or password is incorrect the

course system displays incorrect username or password and displays
of action try again.
Step 4. If the evaluation form is filled partially or not filled
at all, the system displays fill all the fields’ message.
Post the system will calculate the evaluation result
condition

Modify account information

Page 18
 Haramaya University

Use case name Modify Account information

Identifier UC 004
Actor(s) Administrator, Head, Teacher and Student
Description Allows all the users to modify their account information
from the system
Preconditio all users must have an account
n
Basic course 1. Enters username and password to the system.
of actions 2. Clicks update button
3. selects the place to update their password
4. modify the password
5. Clicks save button
6. The system saves changes made by the user
7. The use case ends

Alternative Step 1. If the user’s username or password is incorrect the

course system displays incorrect username or password and displays
of action try again.

Post the user account information will be updated

condition

View evaluation result

Use case View evaluation result

name
Identifier UC 005

Actors Head, Teacher

Description Visits the calculated result that came from students

evaluation form.
Precondition Both head and Teacher must have an account and the student

Page 19
 Haramaya University

must full fill the evaluation form.

Include Calculate evaluated result

Basic course 1. Both Teachers and head login in his/her own

of action account
2. Click evaluation result button
3. The head have the ability to visit the evaluated result
of all of the Teachers .
4. The Teachers have the possible ability to visit only
his/her evaluation result.
5. Use case ends

Alternative Step 1. If both Teachers and head doesn’t have an account,

course of then the login will fail.
action
Post The system will display all the Teachers evaluated results.
condition

Add new evaluation criteria

Use case name Add new evaluation criteria

Identifier UC 006

Actors Head

Description Allows head to add new evaluation criteria or new

evaluation question.
Precondition head must have an administrator account.

Basic course of action 1. head logins in his/her own account.

2. Clicks on the Add button.
3. Writes new criteria’s to be added.

Page 20
 Haramaya University

4. Then clicks the save button.

5. Use case ends.
Alternative course of Step 1. If head doesn’t have an account, then the
action login will fail.
Post condition The evaluation criteria successfully added

Modify evaluation criteria

Use case Modify evaluation criteria

name

Identifier UC 007

Actors Head

Description Allows head to update evaluation criteria or update

evaluation question.

Preconditio Head must have an administrator account.

n

Basic course 1. Head logins in his/her own account.

of action 2. Clicks on the update button.
3. Searches the questions to be updated.
4. Update the questions selected.
5. Then clicks the save button.
6. Use case ends.

Alternative Step 1. If head doesn’t have an account, then the login will
course of fail.

Page 21
 Haramaya University

action Step 3.If the question that is being searched is not available
the system displays error message.
Post The evaluation criteria successfully updated
condition

Delete evaluation criteria

Use case Delete evaluation criteria
name
Identifier UC 008
Actors Head
Description Allows head to delete evaluation criteria or evaluation
question.
Precondition Head must have an account.
Basic course 1. head logins in his/her own account.
of action 2. Clicks on the delete button.
3. Searches the questions to be deleted.
4. Delete the questions selected.
5. Then clicks the save button.
6. Use case ends.
Alternative Step 1. If head doesn’t have an account, then the login will
course of fail.
action Step 3.If the question that is being searched is not available
the system displays error message.
Post The evaluation criteria successfully deleted
condition

Manage account
Use case Manage account

Page 22
 Haramaya University

name
Identifier UC 009
Actors Administrator
Description The administrator manages the account of the other actors.
Like head, students and Teachers .
Precondition Administrator must have an administrator account.
Basic course 1. Login by using own account.
of action 2. Searches manageable account.
3. Deletes account.
4. Then clicks the save button.
5. Use case ends.
Alternative Step 1. If all users don’t have an account, then the login will
course of fail.
action Step 3. If the account that is being searched is not available
the system displays no account with this user name message.
Table 1 Use case description

32.8. Analysis object model

In this project we have 8 classes each has its own activities.

1. Students
2. head
3. Administrator
4. Teachers (peer)
5. Account
6. School Information
7. Evaluation
8. Result
Students: allows to performing the following action

Page 23
 Haramaya University

 Evaluate Teachers
 Modify their own account

Head: allows to performing the following action

 Evaluate Teachers
 Add Teachers records
 Register department information
 Update account information
 View evaluation result
Administrator: A person who control or manage all the functionality of the system like;

 Create account
 Add new evaluation criteria
 Update evaluation criteria

Teacher
 View evaluation result
 Filling the evaluation forms
 Update account information

Account: Means an attribute of the actor used to enter in the system.

 User name
 Password

Result: The Evaluated Teachers .

 Total result
 Average result

School Information: Store School information listed below

 Programs
 Batch

Page 24
 Haramaya University

 Sections
 Semesters
 Years

Evaluation: Store evaluation criteria or question.

 Question id
 Question
 word

Page 25
 Haramaya University

 word

Page 26
 Haramaya University

Figure 2 class diagram

Page 27
 Haramaya University

32.11. Dynamic Model

32.11.1 Sequence diagrams

Sequence diagrams are used to depict graphically how objects interact with each other via
messages in the execution of a use case or operation. They illustrate how the operations
are performed between objects and in what sequence.

sd Use Case Mo...

Actor ApplicationForm LoginControler Login<<UI>> UserAccount

Login
Basic Course of action
click()

Initiate()

<<create>>()

enter username and password()

UserName()

Password()

Validate(Username,Password)

Invalid()

Invalid username or password Reenter again()

valid()

Succesfully Loged in()

acces required page()

X X X X X

Figure 3 sequence diagram for login

Page 28
 Haramaya University

sd Class Mo...

Actor Menu<<UI>> evaluateInstructor

Teacher FormControler evaluationform<<UI>> DB

Click
fill evaluation form link()
BasicCourseOfaction
Click()

initiate()

Create()

DisplayForm()

Fill
Form()

Invalid()

please select the value ()

Valid()

Evaluate()

Succesfully
evaluated()

Actor:
customer
X X X X
X
X

Figure 4 sequence diagram for evaluate instructor

Page 29
 Haramaya University

CHAPTER FOUR

SYSTEM DESIGN DOCUMENT

3.1 Introduction
System design is the transformation of the analysis model into a system design model. Up
to now we were in the problem domain. System design is the first part to get into the
solution domain in a software development. This chapter focuses on transforming the
analysis model into the design model that takes into account the nonfunctional
requirements and constraints described in the problem statement and requirement analysis
sections discussed earlier.
The purpose of designing is to show the direction how the system is built and to obtain
clear and enough information needed to drive the actual implementation of the system. It
is based on understanding of the model the software built on. The objectives of design are
to model the system with high quality. Implementing of high quality system depend on
the nature of design created by the designer. If one want to changes to the system after it
has been put in to operation depends on the quality of the system design. So if the system
is designed effetely, it will be easy to make changes to it.

3.1.1 Overview of System Design

Software design is a process through which the requirements are translated into
representation software. Design of software includes conceiving, planning out and
specifying the externally observable characteristics of the software product. The goal of
design process is to provide a blue print for implementation, testing and maintenance
activities.

3.1.2 Design Goals for OTES system

The main aim of the design is to show the different type of class type architecture such as
user interface, process/control, business/domain, persistence and system layers and also
different types of system modeling techniques that are used for the implementation of the
system such as class, component, and deployment modeling. Also some system design

Page 30
 Haramaya University

techniques such as user interface, training and maintenance designs are also to be covered
in this design chapter.

The design goals are derived from non-functional requirements that means non-functional
requirement is the description of the feature characteristics and attribute of the system as
well as any constraints that may limit the boundary of the proposed solution.
Design goals describe the qualities of the system that the developers should consider.
[i.] Reliability: OTES system should be reliable
[ii.] Security: OTES system should be secured, i.e., not allow other users or
unauthorized users to access data that has no the right to access it.
[iii.] Fault Tolerance: OTES system should be fault tolerant to loss of connectivity with
the service.
[iv.] Modifiability: OTES system should be modifiable for further modification and
enhancement of the application.
[v.] Performance: The system should respond fast with high throughput, i.e. it should
Perform evaluation and report generation in a time less than 2 minutes.
[vi.] Cost: The system should be developed with minimum cost possible. In reality there is
always trade-offs or disadvantages and therefore, from its previous experience the
university prefers to invest more in development cost than maintenance cost to
minimize bugs which may appear the later stage.
[vii.] End User Criteria: - The system should have simple and understandable graphical
user Interface such as forms and buttons which have descriptive names. It should
give reliable response for each user request at least before the session
expires. All the interfaces, forms and buttons are written or designed in a
simple language or common language so that the user can access it without any
difficult.
[viii.] Response time: As we mentioned the performance characteristics in the non-
functional requirement of the requirement analysis document the system should
respond the user requests within a specified period of time and up to the standard
response time after the request has been issued.

3.1.3. Definitions, acronyms, and abbreviations

Page 31
 Haramaya University

Design goal: describing the qualities of the system that developers should optimize.

Boundary condition: describing the system configuration, startup, shutdown, and

exception handling issues.

Subsystem: is a replaceable part of the system with wells-defined interfaces that

encapsulates the state and behavior of its contained classes.

Client/Server Architecture Often used in database systems:

• Front-end: User application (client)

• Back end: Database access and manipulation (server)

Software architecture: describing the subsystem decomposition in terms of subsystem

responsibilities, dependencies among subsystems, subsystem mapping to hardware, and
major policy decisions such as control flow, access control, and data storage.

RAD: Requirement analysis document.

LAN: local area network.

OTES: Online Teachers evaluation system.

OOD: object oriented design used to design the project by representing real world things.

SDD: system design document

PHP: php hypertext preprocessor

3.2. Overview:
SDD focuses on the Design goal, descriptions of current software architecture, proposed
system architecture, subsystem decomposition, software and hardware mapping, the user
model of the system in terms of access control, the boundary conditions: startup,
shutdown, and error behavior of the system, and also a brief description of the
implementation plan for the subsystem. In this design phase, we focus on the processes,
data structures, and software and hardware components to implement the system using
structural or Object Oriented approaches.
Page 32
 Haramaya University

3.2.1. Current System Architecture

Currently the System Architecture is a manual based, that’s why we are intended to
develop computerized system to solve the problem of this paper based instructors
evaluation system for soc. The instructor’s evaluation system uses manual based
architecture to calculate and process instructor’s evaluation. Thus we can say the
instructors evaluation have no specified architecture at the moment. We are unable to
document the current software architecture. Although we have not observed any
architecture it is common that web based application best fit with client/server
architecture.

3.2.2. Proposed System Architecture

This proposed system architecture describes the system architecture of LRS by using OO
architecture and has two main subsystems architecture. The land registration Institution
follows client/server architecture.

We use client/server architecture mainly to take advantage

• Centralized data management

• Data integrity and database consistency

• Database security

• Concurrent operations (multiple user access)

• Centralized processing

In general the solution architecture advantage are listed below

 Low deployment and maintenance costs

Even if accessed by many users from different locations the system can be fully managed
and maintained by operating on the central server; no intervention is required to install or
maintain workstations.

 Access from anywhere

Page 33
 Haramaya University

Users can access the system from any workstation running a generic Web Browser that
support both local and remote connections through the internet.

 High Data Security

End users can access the system data only through the application layer which
implements appropriate business rules to allow only authorized operations based on
the actual user permissions; no direct access to the physical database is needed.

 High System Reliability

The centralization of the data allows efficient monitoring and backup procedures; no data
is stored on clients Proposed system diagram

3.3. Overview
The proposed system has sub component like view user information, account
management, database, That means the soc can access the IES application using local
area network, and also the user can access IES application through the internet.

3.3.1 Subsystem decomposition

Record management
This sub system Record information like school information, Teachers information,
students information.

Page 34
 Haramaya University

View management
The user module includes the follow functionalities:
View Teachers result.

Database:

This component of the OTES application comprise relational database store information
in various tables regarding user detail, account detail, delivery Order and other service
detail.

Account Management
- Add user account
- Delete user account
- Maintain the system
- Manage User Authentication and access control

3.4. Hardware/software mapping

The OTES will have three main components: the client, the web server and the database
server. The web server of the OTES will run at HTML&PHP and will contain all
subsystems. The database server will use WAMP SERVER 2007 database and will
handle all persistent data storage. Again, the client will access the OTES website through
their internet browser (i.e. Mozilla Firefox, Google Chrome, Internet Explorer…).The
web server and the database server will be hosted on the same physical machine.
However it is possible to place on separate machines is desired. Place on separate
machines is desired

Page 35
 Haramaya University

deployment Deployment Mo...

deployment of SOC IES

«device» System application

client machine

SOC IES
Internet
brow ser(mozila,
crome,safari)

<<HTTP>>

serv er

w eb
serv er(appache)

<<install>>

database
serv er(mysql)

Figure 5 Deployment diagram

3.5. Persistent data management

The OTES will use the WAMP SERVER 2007 database engine for storing data. This will
allow the database to be easily integrated with and accessed by the rest of the system. The
database will retain user information and calculate the input given before. Each of the
items will be a separate table

Page 36
 Haramaya University

3.5.1 Data Object

We describe data object for each table below.

Table object Type Length Default value Null

Id Int 11 - X

First name Varchar 30 - X

Last Name Varchar 30 - X

department Varchar 30 - X

Section varchar 11 - X

Year Int 30 - X

Table 2 data object for student table

Table object Type Length Default value Null

User Name Varchar 20 - X
Password Varchar 15 - X
Email address Varchar 30 - X
Table 3 data object for account table

Table object Type Length Default value Null

Overall result Varchar 30 - X
Average result varchar 30 - X
Bach varchar 30 - X
Course varchar 30 - X
department varchar 30 - X
Teachersname varchar 40 - X
Section varchar 30 - X
Table 4 data object for result table

Page 37
 Haramaya University

Table object Type Length Default value Null

First Name Varchar 20 - X
Last name varchar 20 - X
Id Varchar 15 - X
Table 5 data object for Teachers table

Table object Type Length Default value Null

Chair head Name Varchar 20 - X
Chair head id Varchar 15 - X
Office no. varchar 15 - X
Table 6 data object for head table

Table object Type Length Default value Null

Quation id Varchar 20 - X
Question name Varchar 15 - X
Table 7 data object for evaluation table

Table object Type Length Default value Null

Bach Varchar 20 - X
Course Varchar 15 - X
Section Varchar 15 - X
Semester Varchar 11 - X
Table 8 data object for school information

Table object Type Length Default value Null

First name Varchar 20 - X
last name Varchar 15 - X
Id Int 11 - X
Table 9 Table data object for administrator table

3.5.2. Logical Database schema

A database consists of multiple relations.

Page 38
 Haramaya University

Account: store information about accounts

User information: stores information about student, Teachers and head information

Account (full name, User name, User Id , password, email address)

Student (first name, last name, stud id, section, year)

Teachers(first name, last name, inst id, office no.)

Head (first name, last name, h id, office no.)

Result (average result, overall result, teachername, section, semester, course,

department)

School information (course, program, batch, section, semester)

3.5.3. Access Control and Security

System access control and security is the main issue of the project. Therefore system
identify someone who is, what he/she wants to access, check whether the somebody is
authorized or not and granting permission or deny. Thus the system provides protection
over system from unauthorized users and allows those who have an authority to access
the system and even an authorized body forgot either of his/her user name or password
the system prompts to correct again. We are concerned with information security and
application controls. The information security of the OTES aims to preserve:-

 Confidentiality:

The only people to see the data those authorized to see it. Private data is kept private;
personal privacy is respected.
 Integrity:

There are limits on who can change the OTES.

 Availability:

The registered instructors or user data is available at all times to authorized users.
 Accountability:

It is possible to discover that after the event who has modified what data in the OTES

Page 39
 Haramaya University

Table Access control C=create R=read U=update D=delete

student instructor Head Administrat
or
OTES
C R U D C R U D C R U D C R U D

Stud                
Info

Teachers                
info

School                
info

Account                

Result                

School                
info

evaluati                
on

Criteria                

3.6. Global software control

Page 40
 Haramaya University

Due to its nature as a website, the OTES will be event driven. When a user is presented
with a web page they will have the option of clicking on a number of links. When a link
is clicked, a function in the system management subsystem will be invoked. Functions in
a subsystem may call other functions within that same subsystem or they may
communicate with other system using the interface provided in those subsystems.

3.7. Boundary Condition

 Startup and Shutdown

The OTES does not have any startup or shutdown procedures. Since it is a
website, startup and shutdown are controlled by the web server and host, both of
which are outside of OTES’s scope. The website is designed to be online 24 hours
a day; 7 days a week; 365 days a year except during system maintenance. If the
web server and host are running, then OTES is operational.
 Initialization

The OTES does not require any initialization upon system startup. When creating
the website for the first time some interesting persistent data needed to be added
to the database. However these operations can be performed at any time. If the
web server is rebooted for example, it is not necessary to re-add the previously
performed operations, since this information already exists inside the database.

3.8. Exception Handling

All exception handling will be managed by the Exception Handling subsystem.
The Exception handling subsystem manages the following exceptions:
 Database Exception – Occurs when there is an error accessing the database.
Recovery from this error is achieved by displaying an error message stating that
the database is temporarily unavailable.
 Access Control Exception – Occurs when a user is trying to access a function that
they do not have permission to access. Recovery from this error is achieved by
preventing the user for executing this function.

Page 41
 Haramaya University

 Data Validation Exception – Occurs when a user tries to add HTML, a DATA
BASE query, or any other unauthorized text into a string. Recovery from this
error is achieved by removing the unauthorized text

cmp Class Mo...

VIEW MANAGEMENT
EVALUATION MANAGEMENT

DATABASE

RESULT MAAGEMENT ACCOUNT MANAGEMENT

Figure 6 Subsystem architecture

Page 42
 Haramaya University

3.9. Sub system Description

Evaluation management

 This sub system evaluates Teachers performance in the case teaching and learning
process.
View management
The user module includes the follow functionalities:
 Search and View evaluated Teachers result by selecting each Teachers.
Database

 This component of the OTES application comprise relational database store

information in various tables regarding Teachers and students information, user
detail, account detail, and other service detail.
Account Management
Account management is LRS sub system that are used to perform the following
operations
- Add user account
- Delete user account
- Edit profile
- Manage User Authentication and access control
Result Management

 Store the evaluated Teachers result and the head and each Teachers retrieve the result.

Page 43
 Haramaya University

CHAPTER FIVEFOUR

TESTING AND DEBUGGING

4. INTRODUCTION
The implementation document enables the user (society) as well as the administrator to
work with the system and to use the application efficiently and effectively. It helps users
not to be confused with the system. It includes sample snapshot. It gives the users a brief
over view of the system.

4.1. Objective
The implementation is to change what we did in the design Phased to machine readable
form by writing code using php to all modules. The system contains forms that are
connected to the data base in each individual form also combined in one module in order
to work the system as whole.

4.2. Form Layout design

4.2.1 Log in form

This page is available for student, chairs and administrator to login and do different
activities. Like create account, fill form, view average result, modify evaluation criteria.

Page 44
Haramaya University

Page 45
 Haramaya University

Figure 7

Page 46
 Haramaya University

Log in form

Page 47
 Haramaya University

Figure 8 Evaluation form

4.3. Testing
Final phase of implementation is testing. Testing is a process to show the correctness of
the program. Testing is checking of System Implementation is the phase where objectives
of physical operations of the system turned into reality i.e. real working model. The
crucial phase in the system development life cycle is the successful implementation of the
new system design. The process of converting as new system into an operational one is
known as system implementation. This includes all those activities that take place to
convert from an old system to a new system.

Page 48
 Haramaya University

4.4. Coding
The system workability in an attempt to discover errors and avoiding such errors from the
system. In this the team members tested the entire system as a whole with all forms, code
in this we tested all the functionalities in the System. All errors in the forms, functions
have been tested. The following are different testing strategies.
4.4.2. Unit Testing
Unit testing is every module of the System is separately tested. It is often done by the
programmer to test that the unit he/she has implemented is producing expected output
against given input.
Test Case 1:
Test Case ID = Administrator – TestCase02
Unit to Test = create account
Assumptions = successfully created!
Test Data = Username (invalid, Valid, empty)
Password(invalid, valid, empty)
User type(Selected, empty)
Password (invalid, valid, empty)
conform password (not match, matched, empty)

Steps to be Executed Data Expected Results

Empty username and all
others filled and Click Add
button
Empty password and Click
Add button
Not select user type and
Click add button
Password not Match
Test Case 2:
Test Case ID = chair head – TestCase01
Any valid data for the other “username must
fields Required”
Any valid data for the other “password must
fields and last name empty Required”
“select user type you
Not select user type
want to be!”
Type unmatched password "Password do not match!"

Page 49
 Haramaya University

Unit to Test = add student

Assumptions = successfully registered!
Test Data = first Name (invalid, Valid, empty)
Last name(invalid, valid, empty)
Id(valid, empty)
year(valid, empty)
section(invalid, valid, empty)

Steps to be Executed Data Expected Results

Empty first Name and all “First name must have
Any valid data for the other
others filled and Click Add alphabet characters
fields
button only”
“Last name must have
empty last name and Click Any valid data for the other
alphabet characters
Add button fields and last name empty
only”
All fields with valid data All fields with valid data Successfully
and Click Add button registered!

4.4.3. Acceptance Testing

Acceptance testing is the process of testing system (e.g. software, lots of manufactured
mechanical parts, or batches of chemical products) prior to its delivery. A system is
mainly developed for an end user normally a customer of the school. A system is said to
be accepted if and only if the user of the system is satisfied. In this perspective
acceptance testing is widely used to prove that system performs as per the requirements.

In acceptance testing the user provides the input data to validate the system operation. It
is also known as functional testing, black-box testing, release acceptance, QA testing,
application testing, confidence testing, final testing, validation testing, or factory
acceptance testing

Page 50
 Haramaya University

4.4.4. System Testing

It is the final step of testing. In this the team members tests the entire system as a whole
with all forms, code. This form of testing is popularly known as Black Box testing or
System tests. In this the team members tests all the functionalities in the System. All
errors in the forms, functions are tested.

CHAPTER SIXFIVE

CONCLUSION AND RECOMMENDATION

5.1. Conclusion
Generally in this project, we developed an automated OTES that facilitates various
activities taking place at the Haramaya University . The OTES do different activities such
as evaluate instructor, view average result. We realize that the existing system is not
capable of reducing errors and too backward to work in a flexible manner. However, the
newly developed system has dynamic features of manipulating and managing data.
Furthermore this document briefly describes the problems and the solutions we proposed
with the figures to visualize better and steps taken to solve the problem. In other words
this document introduces the technical details of the OTES. In the first part of the
technical design the major functions needed to develop OTES are introduced. Later on,
these major functions and their sub-functions are visualized with the use case diagrams.
In the second part, user interfaces are described in a detailed manner with figures. Lastly,
data modules and their relationships are discussed. We believe from heartily that the
existing problems of the OTES will be resolved and a sustainable working environment
will be created just by taking advantage of the newly developed system. To conclude, this
document constitutes a base for the development of OTES. In addition, with
implementing the new system will make the overall system more convenient and give
fast and reliable service for users which has continuous relation with school. Overall the
implementation of this project was an excellent learning opportunity for us.

Page 51
 Haramaya University

5.2. Recommendation
This paper will recommend specific steps to transform the elements of the OTES in to
technologies like integrating the system to e student. These steps, if taken, will result in
better support to users while expediting access to different information requirements and
decreasing the workload of the staffs. These improvements will depend on the creation of
an integrated software development with one lead agent in charge of developing,
maintaining, and growing the architecture. The OTES is immense and expanding. There
should be one centralized element responsible for design control and monitoring. It is
imperative that automation is properly reviewed and focused around the Core Task of
evaluation. There needs to be a plan for the entire system. This plan must be an active
document that grows with changes while anticipating future requirements. The following
paragraphs will provide specific recommendations Automation of Common Tasks: OTES
tasks were manual procedures. Instead of multiple manual submissions of identical
information, automation solutions could significantly simplify these tasks with the use of
standardized applications within existing software solutions. Rapid Response: OTES
Automation must be responsive to the needs and requirements of the user and. The design
must be responsive enough to implement changes prior to requirements for users the final
recommendation is to establish effective, efficient and reliable OTES.

56.3 Glossary
Main terms

Use case: A use case expresses a contract between the stakeholders of a system about its
behavior. It describes the system’s behavior and interactions under various conditions as
it responds to a request on behalf of the stakeholders, the primary actor, showing how the
primary Actor’s goal gets delivered or fails. The use case collects together the scenarios
related to the primary actor’s goal.

Scenario: A scenario is a sequence of action and interactions that occurs under certain
conditions, expressed without branching.

Actor: Something with behavior. It might be a mechanical system, computer system, a

person, an organization or some combination.

Page 52
 Haramaya University

Use case diagram: In UML, the diagram showing the external actors, the system
boundary, the use cases as ellipses, and arrows connecting actors to ellipses or ellipses to
ellipses. Primarily useful as a context diagram and table of contents

Sequence diagram: In UML, the diagram showing actors across the top, owning
columns of space, and interactions as arrows between columns, with time flowing down
the page. Useful for showing one scenario graphically.

Class diagram: Class diagrams show the classes of a system and their interrelationship’s.
Class diagrams are often mistakenly referred to as object models.

OTES: Online Teachers evaluation system.

PHP: - PHP Hypertext Preprocessor used for back end.

HTML: - Hyper Text Markup Language used for front end.

SQL: - Structural Query Language.

CSS: - Cascading Style Sheet used to style the interface of web.

UML: - Unified Modeling Language.

RAD: Requirement analysis document

LAN: local area network

SDD: system design document

7. Reference
1.Www.google .com specifically system designing with object oriented approach.

Page 53