ASSOSA UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF COMPUTER SCIENCE

WEB BASED ETHIOPIAN HIGHER EDUCATION STUDENT

PLACEMENT SYSTEM
A Project Submitted to the Department of computer science of Assosa University in
Partial Fulfillment of the Requirements for the Degree of Bachelor of Science in
Computer Science.

BY:
Abdumalik Nadi
Abiyot Girma
Bereket Mengistu
Chala Dechasa
Feysal Kashif

Advisor: - Mr. Getaneh Berie

June, 2017

Assosa, Ethiopia
 Assosa University
Collage of Computing and Informatics (CCI)
Department of Computer Science

We the name listed below have cordially evaluated the importance offered to Computer Science
Department Students conducted by

1. Abdumalik Nadi
2. Abiyot Girma
3. Bereket Mengistu
4. Chala Dechasa
5. Feysal Kashif

The final Project Entitled On “Web Based Ethiopian Higher Education Student Placement
System” under Collage of Computing and Informatics in Computer Science Department and we
are absolutely confident that all the project under this paper are necessary and approved with
definitive signature.

Declared By:-

Name: _________________________ Name: _________________________

Signature: ______________________ Signature: ______________________
Date: __________________________ Date: __________________________

Name: _________________________ Name: _________________________

Signature: ______________________ Signature: ______________________

Date: __________________________ Date: __________________________

Name: _________________________
Confirmed By Advisor:-
Signature: ______________________
Date: __________________________
Name: _________________________
Signature: ______________________
II
Date: __________________________
 APPROVAL SHEET

Approved by Board of Examiners

___________________ ______________ _____________

Project Coordinator Signature Date

___________________ _______________ _____________

Advisor Signature Date

___________________ _______________ _____________

Examiner Signature Date

___________________ _______________ _____________

Examiner Signature Date

III
 Acknowledgement

We would like to express our special thanks of gratitude to our advisor Mr. Getaneh Berie for his
great advice and assistance in making this project a piece of work. Next we, we want to thanks
workers of government office especially the workers of Benishangul Gumuz region Educational
Bureau and students of Assosa Secondary and Preparatory school that help us in giving
information that we require to develop the project. We also like to thanks to our friend that help
us by giving their experience and share some information to us. At last we would like to thanks
to all of our friends and the people who help us doing this piece of projects.

i
 Table of Contents

Acknowledgement ........................................................................................................................... i

Abbreviations .................................................................................................................................. x

HEI: Higher Education Institution .................................................................................................. x

LAN: Local Area Network ............................................................................................................ x

MOE: Ministry of Education ......................................................................................................... x

ESLC: Ethiopian School Leaving Certificate. ................................................................................ x

REB: Regional educational Berue .................................................................................................. x

ERD: Entity Relationship Diagram ................................................................................................ x

Abstract .......................................................................................................................................... xi

CHAPTER ONE ............................................................................................................................. 1

PROPOSAL .................................................................................................................................... 1

1. Introduction ............................................................................................................................. 1

1.1. Background of the study .................................................................................................. 1

1.2. Statement of the Problem ................................................................................................. 2

1.3. Objective of the Study ...................................................................................................... 3

1.3.1. General Objective ..................................................................................................... 3

1.3.2. Specific Objective ..................................................................................................... 3

1.4. Scope of the study ............................................................................................................ 4

1.5. Significance and Beneficiaries of the Project .................................................................. 4

1.6. Methodology .................................................................................................................... 5

1.6.1. Data Gathering Methodology ................................................................................... 5

1.6.2. Development Methodology ...................................................................................... 6

1.6.3. Development Approaches ......................................................................................... 6

1.6.4. Testing Methodology ................................................................................................ 8

ii
 1.7. Feasibility Study............................................................................................................... 9

1.7.1. Schedule Feasibility .................................................................................................. 9

1.7.2. Technical Feasibility ................................................................................................. 9

1.7.3. Economic Feasibility ................................................................................................ 9

1.7.4. Operational Feasibility .............................................................................................. 9

1.7.5. Political feasibility .................................................................................................... 9

CHAPTER TWO .......................................................................................................................... 10

SYSTEM ANALYSIS .................................................................................................................. 10

2. Introduction ........................................................................................................................... 10

2.1. Existing System Description .......................................................................................... 10

2.1.1. Advantage of Existing System ................................................................................ 10

2.1.2. Disadvantage of Existing System ........................................................................... 10

2.2. Overview of the New System......................................................................................... 11

2.3. System Requirements ..................................................................................................... 11

2.3.1. Functional Requirement (FR) ................................................................................. 11

2.3.2. Non-Functional Requirements ................................................................................ 12

2.4. System Modeling............................................................................................................ 13

2.4.1. System Use Case Modeling .................................................................................... 13

2.4.2. System Use case Documentation ............................................................................ 17

2.4.3. Sequence Diagram .................................................................................................. 41

2.4.4. Activity Diagram .................................................................................................... 56

2.4.5. Conceptual class Diagram....................................................................................... 72

SYSTEM DESIGN ....................................................................................................................... 73

3.1. Introduction ........................................................................................................................ 73

3.2. Design goals ....................................................................................................................... 73

iii
 3.3. Proposed System Architecture ........................................................................................... 74

3.3.1. Subsystem Decomposition .......................................................................................... 75

3.4. System Class Diagram ....................................................................................................... 76

3.5. State chart Modeling .......................................................................................................... 77

3.6. Collaboration diagram ........................................................................................................ 79

3.7. Logical Database Requirements ......................................................................................... 81

3.7.1. Entity Relationship Diagram (ERD)............................................................................ 81

3.8. Persistent Data Management .............................................................................................. 82

3.9. Component Diagram .......................................................................................................... 93

3.10. Deployment Diagram ....................................................................................................... 93

CHAPTER FOUR ......................................................................................................................... 95

IMPLEMENTATION ................................................................................................................... 95

4.1. System Implementation .................................................................................................. 95

4.2. Objective of the implementation .................................................................................... 95

4.3. Interface design .............................................................................................................. 96

4.4. Testing ............................................................................................................................ 99

4.5. Sample source code ...................................................................................................... 100

CHAPTER FIVE ........................................................................................................................ 107

CONCLUSION AND RECOMMENDATION ...................................................................... 107

5.2. Recommendation .......................................................................................................... 107

References ................................................................................................................................... 108

iv
List of Figures

Figure1. 1 Iterative Refinement model ........................................................................................... 7

Figure 2. 1 the proposed system use case diagram……………….……………………………...16
Figure 2. 2 Sequence diagram for Login. ..................................................................................... 42
Figure 2. 3 Sequence Diagram for Create account. ...................................................................... 43
Figure 2. 4Sequence Diagram for Change password. ................................................................... 43
Figure 2. 5 Sequence Diagram for Register Score. ....................................................................... 44
Figure 2. 6 Sequence Diagram for Register field choice. ............................................................. 45
Figure 2. 7 Sequence Diagram for Register HEI choice. .............................................................. 45
Figure 2. 8 Sequence Diagram for Register intake capacity. ........................................................ 46
Figure 2. 9 Sequence Diagram for View Score. ........................................................................... 46
Figure 2. 11 Sequence Diagram for Generate announcements. .................................................... 46
Figure 2. 12 Sequence Diagram for View Announcement. .......................................................... 47
Figure 2. 13 Sequence Diagram for View Placement result. ........................................................ 47
Figure 2. 14 Sequence Diagram for View HEI Information. ........................................................ 48
Figure 2. 15 Sequence Diagram for Process Placement. .............................................................. 49
Figure 2. 16 Sequence Diagram for Give Comment..................................................................... 49
Figure 2. 17 Sequence Diagram for View Comment. ................................................................... 50
Figure 2. 18 Sequence Diagram for Register Field....................................................................... 50
Figure 2. 19 Sequence Diagram for Ask question. ....................................................................... 51
Figure 2. 20 Sequence Diagram for Register School .................................................................... 51
Figure 2. 21 Sequence Diagram for Register HEI ........................................................................ 52
Figure 2. 22 Sequence Diagram for Register Student................................................................... 52
Figure 2. 23 . Sequence Diagram for Download student data. ..................................................... 53
Figure 2. 24 Sequence Diagram for Upload HEI information ...................................................... 54
Figure 2. 25 Sequence Diagram for View Field ........................................................................... 55
Figure 2. 26 Sequence Diagram for View Score detail. ............................................................... 56
Figure 2. 27 Sequence Diagram for Delete account. .................................................................... 56

Figure 2. 29 Activity Diagram for Login. ..................................................................................... 57

v
Figure 2. 30 Activity diagram for create account ......................................................................... 58
xFigure 2. 31 Activity Diagram for Change Password. .............................................................. 58
Figure 2. 32 Activity Diagram for Register student score. ........................................................... 59
Figure 2. 33 ACtivity Diagram for Register field of study. .......................................................... 59
Figure 2. 34 Activity Diagram for Register HEI choice ............................................................... 60
Figure 2. 35 Activity Diagram for Register intake capacity ......................................................... 61
Figure 2. 36 Activity Diagram for View Student Score. .............................................................. 61
Figure 2. 37 Activity Diagram for View student field and HEI choice. ....................................... 62
Figure 2. 38 Activity Diagram for Generate Announcement. ...................................................... 62
Figure 2. 39 Activity Diagram for View Announcement. ............................................................ 62
Figure 2. 40 Activity Diagram for View HEI information ........................................................... 63
Figure 2. 41 Activity Diagram for View placement result ........................................................... 63
Figure 2. 42 Activity Diagram for Process placement. ................................................................. 64
Figure 2. 43 Activity Diagram for Give comment. ....................................................................... 64
Figure 2. 44 Activity Diagram for View comment ....................................................................... 65
Figure 2. 45 Activity Diagram for View Question ....................................................................... 65
Figure 2. 46 Activity diagram for Ask Question .......................................................................... 66
Figure 2. 47 Activity diagram for Register HEI ........................................................................... 66
Figure 2. 48 Activity Diagram for Register School ...................................................................... 67
Figure 2. 49 Activity Diagram for Register student ..................................................................... 67
Figure 2. 50 Activity Diagram for Download student data .......................................................... 68
Figure 2. 51 Activity Diagram for Upload HEI information. ....................................................... 68
Figure 2. 52 Activity Diagram for view field. .............................................................................. 69
Figure 2. 53 Activity Diagram for view Score detail.................................................................... 69
Figure 2. 54 Activity Diagram for register field. .......................................................................... 70
Figure 2. 55 Activity Diagram for delete account ........................................................................ 70
Figure 2. 56 Activity diagram for update account. ....................................................................... 71

Figure3. 1 architecture of the project. .......................................................................................... 74

Figure3. 2 subsystem decomposition ............................................................................................ 75
Figure3. 3 Class diagram of the system ........................................................................................ 76

vi
Figure3. 4 State Chart diagram for Login ..................................................................................... 77
Figure3. 5 State chart diagram for Create account ....................................................................... 78
Figure3. 6 state chart diagram for View placement result ............................................................ 78
Figure3. 7 Collaboration diagram for Login ................................................................................. 79
Figure3. 8 Collaboration diagram for Create account .................................................................. 80
Figure3. 9 Collaboration diagram for view placement result ....................................................... 80
Figure3. 10 Entity relationship diagram ....................................................................................... 81
Figure3. 11 Component diagram of the system ............................................................................ 93
Figure3. 12 Deployment Diagram ................................................................................................ 94

Figure 4. 1 Home page for Web based Ethiopian Higher Education Student placement ........... 96
Figure 4. 2 Student Registration page of the System .................................................................... 97
Figure 4. 3 Registering Field Choice For Student ........................................................................ 97
Figure 4. 4 Home page for Ministry of Education ........................................................................ 98
Figure 4. 5 Processing placement page ......................................................................................... 98

vii
List of Tables

Table2. 1 Use case documentation for Login. .............................................................................. 17

Table2. 2 Use case documentation for Create Account ................................................................ 18
Table2. 3 Use case documentation for Change Password ............................................................ 19
Table2. 4 Use case documentation for View Comment. .............................................................. 20
Table2. 5 Use case documentation for Generate announcement .................................................. 20
Table2. 6 Use case documentation for Register student Score. .................................................... 21
Table2. 7 Use case documentation for View announcement. ....................................................... 22
Table2. 8 Use case documentation for View Placement Result. .................................................. 23
Table2. 9 Use case documentation for View Student Score. ........................................................ 24
Table2. 10 Use case documentation for View HEI information. .................................................. 25
Table2. 11 Use case documentation for View choice information. .............................................. 25
Table2. 12 Use case documentation for Register field choice. ..................................................... 26
Table2. 13 Use case documentation for Register Higher Education Institution choice. .............. 27
Table2. 14 Use case documentation for Register intake capacity of Higher Education Institution.
....................................................................................................................................................... 28
Table2. 15 Use case documentation for ask question ................................................................... 29
Table2. 16 Use case documentation for process placement ......................................................... 30
Table2. 17 Use case documentation for upload university information ....................................... 31
Table2. 18 Use case documentation for give comment ................................................................ 32
Table2. 19 Use case documentation for view question................................................................. 33
Table2. 20 Use Case Documentation for Register Higher Education Institution. ....................... 33
Table2. 21. Use Case documentation for Register School............................................................ 34
Table2. 22. Use Case documentation for Register student ........................................................... 35
Table2. 23 Use case Documentation for Download Student data. ............................................... 36
Table2. 24 Use Case Documentation for Upload HEI information. ............................................ 37
Table2. 25 Use Case documentation for View Score detail. ........................................................ 37
Table 2. 26 Use Case documentation for View field .................................................................... 38

viii
Table2. 27 use case documentation for Register field .................................................................. 39
Table2. 28 use case documentation for delete account ................................................................. 40

Table 3. 1 University..................................................................................................................... 83
Table 3. 2 School .......................................................................................................................... 83
Table 3. 3 Student ......................................................................................................................... 84
Table 3. 4 Information .................................................................................................................. 84
Table3. 5 Announcement ............................................................................................................. 84
Table 3. 6 Natural Score ............................................................................................................... 85
Table 3. 7 Social Score ................................................................................................................. 86
Table 3. 8 Field Natural ................................................................................................................ 87
Table 3. 9 Field Social .................................................................................................................. 87
Table 3. 10 Natural Capacity ....................................................................................................... 87
Table 3. 11 Social Capacity .......................................................................................................... 88
Table 3. 12 Placement .................................................................................................................. 88
Table 3. 13 Comment .................................................................................................................... 89
Table 3. 14 User ........................................................................................................................... 89
Table 3. 15 Question .................................................................................................................... 89
Table 3. 16 choice natural ............................................................................................................ 90
Table 3. 17 choice social ............................................................................................................... 90
Table 3. 18 university choice ........................................................................................................ 90
Table 3. 19 upload......................................................................................................................... 91
Table 3. 20 REB ............................................................................................................................ 91

ix
Abbreviations

HEI: Higher Education Institution

LAN: Local Area Network

MOE: Ministry of Education

ESLC: Ethiopian School Leaving Certificate.

EHEEE: Ethiopian Higher Education Entrance Examination.

ICT: Information Communication and Technology

FR: Functional Requirement

NFR: Nonfunctional Requirement.

UML: Unified Modeling Language

REB: Regional educational Berue

ERD: Entity Relationship Diagram

x
 Abstract

The goal of Web Base Ethiopian Higher Education Student Placement System is to develop a
system that handles higher education entrance placement and making available the
placement information to the public in an online manner.

In general we can view Web Base Ethiopian Higher Education Student Placement System in
three directions. The first one is one who registers student information including detail
information about the student and the result of the student. The second is the part which
processes the placement and the third and the last one is the one the part which sends student
information to students, universities and their schools.

xi
 CHAPTER ONE

PROPOSAL

1. Introduction

Education is the backbone for the development of one country, due to this the current Ethiopian
government recognizes the importance of education for national development. The Ethiopian
government Policy is mainly aimed at expanding the education sector, improving quality and
ensuring that educational content is harmonized with the country's economic needs. To expand
ensure quality of education higher education institution or university play a great role. This web
based Ethiopian higher education student placement system has a great role in ensuring quality
of education.

Generally this chapter contains the background, objectives, significance, methodology, project
plan, and budget plan for the project.

1.1. Background of the study

Currently the world we done in our life is experiencing the effects of rapid globalization and
liberalization as the impact of the emerging information age characterized by Information and
Communication Technology (ICT). ICT have a great role in human life because of its speed,
quality service, reduction of manual working, reduction of cost. For this reason now a days ICT
are involved in every sectors of works. There are many numbers of applications of ICT. Web
based Ethiopian higher education student placement system is one application of ICT.

We can categorize the educational parts of Ethiopia in to three this is Primary education,
secondary education and preparatory education. Primary education has duration of 8 year from
grade 1-8. The second is secondary education is that from grade 9-10. The third is preparatory
education; the students who pass grade 10 national exam learn preparatory education.
Preparatory education has also consisted of a 2-year period.

In current Ethiopian education policy the preparatory students take entrance exam and if they get
pass mark according to ministry of education criteria they are placed to governmental higher
education institution in Ethiopia. In Ethiopia there are many number of private and governmental

1
higher education institutions. In private institution students join any institution he/she likes by
his/her felling. However, in governmental higher education institutions placement is done
by Ministry of Education based on the score of the student, choice of the student, the availability
of fields of study, the number of students that it can accommodate, the government policy,
proximity of the institution to student‟s home. Based on the criteria set by the Ministry of
Education those students who satisfy the entrance requirement will fill in a form about their
choice of field of study and higher education institution they would like to join. After field and
higher education institution choice entry is being completed, it will be processed by the
system, then the placement information will be available to students, schools and universities.

1.2. Statement of the Problem

Currently the task of placement is done by ministry of education. Now the number of students
who enters in university is increasing year to year. Due to this some problems are there in current
system, the problems are listed below:

The system cannot give full information about the Higher education institutions and field
of study: The current system which is used by ministry of education cannot give full information
about Higher Education Institution that is it cannot give opportunities to participate HEI due to
this students will confused when they choose HEI even if they cannot know the HEI that found
in our country. The other is the field and their descriptions are not given to students that mean
they confused when they choose their field of study.

Misplacement: Ministry of education has some criteria to place a students but the current system
cannot place a students with their appropriate choice and their recent proximity institution based
on ministry of education criteria. The main problem of this is since the system is developed by
private company its source code is not accessed, so it is not easily corrected.

Students cannot see their choice of university and field choice: in current system the student
fill their choice by paper and give to school, the school fills their choice. To see their choice
whether it is correct or not they should have go to school due to this they can lose their time and
also cost.

2
When multiple users access the system, the system becomes busy: when the placement result
is released automatically many number of user can access the system. The current system
response time is not good because to see the result we wait for long period of time.

In general the current system have some problems since the source code for the project is not
available freely due to this a great improvement to the system is not done well, but after this
project is done it helps the next developer or students to concentrate on this area and improve the
system.

1.3. Objective of the Study

1.3.1. General Objective

The general objective of the study is to develop a web based Ethiopian higher education student
placement system.

1.3.2. Specific Objective

In order to accomplish the general objective of the study the following specific objectives are
formulated:

 To identify and gather requirements from existing systems and also review
relevant literature such as related books, journals, articles and papers from the
internet have been reviewed in order to achieve the objective of the project.
 To analyze and specify the requirement of the system.
 To design a way to solve the problem or to address the requirement that is specified
in the analysis phase of the proposed system.
 To implement the proposed system or to change the design in to real solution that
can lead to the final solution of the problem.
 To test the system using various testing methodology to be sure the system is
implemented with all functionalities.
 To deploy the system in the working environment.

3
 1.4. Scope of the study

The scope of this project is to place students to their respective University or higher education
institution based on the student‟s entry field of study form and other criteria. Student placement
can be viewed from two parts. These are Higher education institution choice and field of study
choice. When students choose Higher Education Institution and field of study, there is also
another rule or criteria to consider, these are the intake capacity of universities and special
consideration for disabilities. Based on this the system carry out many tasks that is related to
student placement. These include by taking student information that is required like score, field
of choice and it process the placement based on the criteria of ministry of education. After
processing the placement it sends the newly placed student information to their appropriate
schools and universities.

1.5. Significance and Beneficiaries of the Project

Student: The student simply see their result by inserting id as well as they can see their choice
before placement is held. The other benefit the student gets from this system is to know the full
information about all universities and they will not confuse when they choose the field and
university.

School: Can fill the choice of the student easily and get information about their students. The
other benefit that school gets from this system is they get the placement result and inform that
result to students.

University: Universities can simply get the information of the newly placed students, much
number of students cannot placed, that is the exact number of students that university needed is
placed based on the intake capacity of the university.

Ministry of education: Since the correct information is delivered correct placement is held and
the other question is simply asked by website and simply gives the answer without wasting a
resource and time. The placement is done based on the ministry of education criteria.

Developers: even if the system is available, the source code for this system is not available due
to this we improve our talent by developing this complex system by our creation. The other

4
benefit we get from this project is previously we don‟t know how placement is held, now we will
have a good knowledge how the placement is held.

1.6. Methodology

In order to develop Software we use different methodologies. That is we use different

methodology to gather the requirement or data, to develop the system and in what approach the
system will be done and the testing methodology that we will apply in the system. The
methodologies we use are described below.

1.6.1. Data Gathering Methodology

When we develop this system, data gathering plays a great role to know the tasks or activities
that can be done by the system. To do this system, it is important to know what activities are
done in existing system. After we know activity which is done on this manual system, it easy to
develop the system. We can gather data from different sources. To gather our requirement we
use two type of data gathering methodology. These methodologies are discussed below:

 Primary Data gathering Methodology

Interview: Interview is one of the best primary methods that used to gathering information
because it allows simply asking clear questions, it has high response rate and the interview is
flexible and adaptable way of finding information.

Observation: This technique is used to gather accurate information about how the system
actually operates, particularly about the processes. Observing how the tasks are actually is the
good way of understanding the existing system.

 Secondary Data Gathering

Document Analysis: Students‟ field of study and higher institution choosing forms, and
Ministry of Education, Placement rule documents of the ministry.

Internet: By searching information and taking experience of other country through internet.

5
 1.6.2. Development Methodology

Among the different methodologies available team plan, we use the object oriented software
development methodology for the development of our system. Because it is best way to
construct, manage and assemble objects that are implemented in our system, and the composition
of objects and collaboration between objects on the system.

We can choose Object Oriented Software Development methodology due to the following
reason:

 Provides seamless transition among different phases of the system.

 Reusable of analyses, design, and programming result.
 Improve the communication among the user, analysts, designer and programmers.

1.6.3. Development Approaches

There is several software approaches used to develop software. From that approach we choose
iterative software development approach. We select this type approach due to the following
reason:

 Iteratively enhance the evolving version until the full system is implemented.
 Team members can recover previous errors.
 Repeating every step after end phase of the system.
 On every next iteration, more features and modules are designed, coded, tested, and
added to the software.
 It is easier to manage the development process
 Easily identify missing functionality.

6
Figure1. 1 Iterative Refinement model

1.6.3.1. Hardware Specification

 Client
- Processor speed- 3 MHz
- RAM size- 2 GB.
- Internal Hard disk Space-250 GB.
 Server
- Processor speed- 3 MHz
- RAM size- 4 GB.
- Internal Hard disk Space-1 TB.
 Others
- Switch, Network Cables(UTP Cat 5e), RJ-45

1.6.3.2. Software Specification

To develop the system from requirement analysis to deployment we use the following software:

 Microsoft word 2013.

7
  Microsoft Power Point 2013.
 Edraw max.
 Adobe Photoshop.
 Snipping Tools.
 Notpad++, micromedia dreamwaver.
 Smadav.
 Xamp Server/ wamp server.
 Window 8 operating system.

1.6.4. Testing Methodology

The project is tested based on different testing constraints using many test cases such black box
testing and white box testing. We select both of these testing methodology to check whether the
functionality of the system is fulfilled or not. We use these both testing methodology due to the
following reasons:

Black Box Testing: Black box testing or functional testing is a method which is used to examine
software functionality without knowing its internal code structure. To elaborate, a professional
using this method to test an application‟s functionality will only know about the input and
expected output but not about the program which helps the application reach the desired output.
The professional will only enter valid and invalid inputs and determine the expected outputs
without having any in-depth knowledge of the internal structure.

Advantage:

 Tester is free from any pressure of knowledge of specific programming languages to test
the reliability and functionality of an application / software
 Test is performed from a user‟s point-of-view and not of the designer‟s
White Box Testing: This method is the methodology the team going to use. Skilled man in
different programming languages tries to test the logic of our system. If the person who tests the
system is not skilled, it is difficult to understand our systems functionality. If any failures occur
while testing the system the team will take immediate correction where this fault occurred before
jumping to next work

8
 1.7. Feasibility Study
1.7.1. Schedule Feasibility
The project feasible in schedule because it is finished within the expected time.

1.7.2. Technical Feasibility

The is project technical Feasible because the system is developed using existing technology.
Team uses hardware and software devices for development and implementation of the proposed
system. And also the required person to operate and use the system is not expected to be
professional. Anyone who has basic computer knowledge can use the system easily.

1.7.3. Economic Feasibility

This project is economically feasible because it requires minimum amount of cost for
deployment process that will be low when it is compared to the existing system. After
completing our project limits loss of budget for users.

1.7.4. Operational Feasibility

The proposed system can be operated easily and has a user friendly interface. The developed
system is plat form independent, so it can work on different operating system. The system is
easily understood by user; due to this worker is simply trained and operate on the system.

1.7.5. Political feasibility

The proposed system does not interfere with governmental policy, because it is developed to
serve the citizen and the system cannot cause any harm in the environment. Therefore, the
proposed system is independent of any political activity.

9
 CHAPTER TWO

SYSTEM ANALYSIS

2. Introduction

System analysis is a main activity that must be done in any project to have a clear idea of the
proposed system. In chapter we will discuss details of the proposed system analysis.

2.1. Existing System Description

Previously the placement to higher education is held manually by using human labor, paper and
other manual materials. At that time there is a great problem are occurred these problems are
security, time wastage, cost and other problems are there. Currently Ministry of education has a
system which manages the student placement result but it is almost impossible to view the
placement information of students through internet due to problem on the existing system. Even
if there is system is available it cannot satisfy the need of the users. To make the system more
interesting and more complete we develop Web Based Ethiopian Higher Education student
placement system

2.1.1. Advantage of Existing System

Since ministry of education uses system and it has several advantages. These advantages are:

 It reduces the time to fill their choice of field and Higher education institution when
compared to the previous system.
 It reduces the cost used to give and get service.
 It increases the accuracy of the placement result.
 It increases the security.
 It reduces data redundancy.

2.1.2. Disadvantage of Existing System

Currently Ministry of education has student placement system and this system has different
problems or disadvantages. The first is Misplacement ministry of education has a criteria to place
a students but the current system cannot place a students with their appropriate choice and their

10
recent proximity institution. The main problem of this is since the system is developed by private
company its source code is not accessed, so it is not easily corrected. The second as soon as the
placement is held the response time of the system is minimum due to this we cannot see
placement result when we need to see. The third is the student cannot access their field and HEI
choice information. To get their field and HEI choice information they should have to go to
school and they waste their time and resource.

2.2. Overview of the New System

The student who joins in higher education institution should have to complete preparatory
education. Those students who complete preparatory education and gets pass mark they can join
governmental higher education institutions. Ministry of education has criteria to place these
students to higher education. According to Ministry of Education criteria the students can choose
their field of study and higher education institution, based on their choice and other criteria the
system can process the placement and place the students to their respective higher education
institution and field of study. After the placement is processed and completed the system
announces the placement result to students, schools and higher education institution.

2.3. System Requirements

There are two types of requirements to develop this project. Namely Functional requirements
(FR) and Non Functional requirement‟s (NFR).

2.3.1. Functional Requirement (FR)

Functional requirements are fundamental building block requirements. It is a statement of

exactly what the system must do.

The new system will take care the following functional requirements:-

 Login.
 Create account.
 Change password.
 Register students, schools and Higher Education Institution.
 Register students score.

11
  Register student‟s field of study choice and higher education institution choice.
 Register intake capacity of university.
 View students score.
 View Students field of study and higher education institution choice.
 View student placement result.
 Release higher education institution information and view higher education institution
information.
 Download Student data.
 Process the placement.
 Ask question and view the question.

2.3.2. Non-Functional Requirements

Performance:
 Multi user should be use the system at a time
 The system should give services 24 hours in a day with maximum response time
 There should not redundancy of data anywhere in the database

Usability:
Every one authorized to use the system can use it without any difficult.

Availability:

 The system should provide service for the user at any time.
 The MOE Student Placement system should usable any year

Security:
 The MOE Student Placement system will be secured and the information will be kept
safe.
 The system should allow for the user password must be encrypted when it is placed in the
database
 The system should allow login to any authorized users who have previously create
account.

12
Error Handling: When users use the system many errors are occurred to overcome this error
this system must be able to validate all input to their assigned value and returns message to the
user.
Graphical User Interface: The system should have easily understandable graphical user
interface. The user can interact with the system through the user interface. The user can use it
without having high level knowledge of the computer application

Accuracy: The MOE Student Placement system gives only valid result if the user gives the
correct input.

Backup and Recovery: We will use removable flashes disk and CD ROM for backup and
recovery mechanism. Because there is a probability to lose our data by different causes.

Portability: Since the system works country wide, the system is easily carried from one place to
another and also the system is platform independent. The system can do with many browsers
and anyplace without crash, unless no Internet access by using different reasons.
Reliability: The system is always reliable and can operate for long period of time.

Maintainability: The system will be modifiable at any time to enhance features based on the
country‟s needs. As needs change from time to time the original system will be made available to
fill the gap between the system and the newly emerging needs. The system could be enhanced by
adding new functionalities without necessarily changing the functionality of the system.

2.4. System Modeling

In System Model we discusses use case diagrams, use case documentation, class diagram,
activity diagram, sequence diagram of the new system.

2.4.1. System Use Case Modeling

System use case model consists of actors, use case and their relationship. Actor is an external
entity that interacts with the system and use cases are a set of action done by a system.

13
 2.4.1.1. Identifying Actors and its Descriptions

The following are all actors that interact with the system under development.

MOE: Authorized on administering the whole system and personnel that can process the
placement and also responsible for registering student score, school, Higher education
Institution, registering REB.

Student: A user of the system and he/she can see his/her placement information, he/she can
view his/her choice of university, view score and view the detail information about all
universities or higher education institution.

Higher education institution (HEI): A user of a system that can register the intake capacity,
register their detail information.

School: A user of the system which registers the student‟s higher education institution choice
and field of study choice, get the information the score of students and download the information
of the students.

REB: A user of the systems who create account for schools and register all school that available
in their region.

2.4.1.2. Identifying Use Cases

The following are listing of all use cases that interact or involved with the system under
development.

 Login.
 Create account.
 Delete account.
 Update account.
 Register field.
 Change password.
 Register score.
 Register field of study choice.

14
 Register Higher Education institution choice.
 Register intake capacity of university.
 View score.
 View score detail.
 Register Higher Education institution (HEI).
 Register school.
 Register student.
 View choice information.
 Generate announcement.
 View announcement.
 View placement result..
 Upload higher education institution information.
 View higher education institution information.
 Process the placement.
 Download student data.
 Give comment.
 View comment.
 Ask question.
 View question.
 Logout.

15
 2.4.1.3. Use Case Diagram

Use case diagrams graphically depict system behavior. The following diagram present a high
level view of how the system is used as viewed from an outsider‟s or actor‟s perspective. The use
case diagram of the system is shown in Figure below.

Figure2. 1 the proposed system use case diagram

16
 2.4.2. System Use case Documentation

Table2. 1 Use case documentation for Login.

Use Case Name Login

ID UC#1

Actors MOE, School, Higher Education Institute(HEI), REB

Description Describe how the user logs into the system.

Precondition The user should have account which is created first.

Post condition The system is opened, then the user logged into the system.

Basic Flow of Event 1. The user opens the application and clicks on login
link.
2. The system will display login page that asks the user
to enter user name and password.
3. The user fills and submits their user name and
password to login the system.
4. The user clicks Login Button.
5. The system checks the user name and password from
the database.
6. The system displays access page for the respective
user.
7. Use case ends.
Alternative flow of Event. If the user do not enter user name and password.

A6. The system asks the user to enter correct user name and
password.

A7. Use Case ends.

Exceptional flow of Events E6. You enter incorrect email or password or your account is

17
 not activated

E7. Use Case ends.

Table2. 2 Use case documentation for Create Account

Use Case Name Create Account

ID UC#2

Description The create account for user and create account use case
allows the user to become a member and get an account.

Actors MOE, REB

Basic Flow of Event 1. The user selects the option or click create account link.

2. Create account form is displayed.

3. The user fills the required information and press create

account button.

4. The system checks the information entered by the user.

5. You are successfully created an account message is

displayed.

6. Use Case ends.

Post Condition Accounted created for new user and the user is a member of
the system.

Alternative Flow of Event E5. The entered information is not correct. Please try again.
Message is displayed.

E6. Use Case ends.

18
Exceptional Flow of an Event E5. Email already exist please try another.

E6. Use Case ends.

Table2. 3 Use case documentation for Change Password

Use Case Name Change Password

ID UC#3

Actors MOE, School, Higher Education Institution, REB

Description The user changes their password.

Precondition The user must have an account that is previously created.

Basic Flow of Event 1. The user click change password link.

2. Change password form is displayed.
3. The user fills the required information and click on
change password button.
4. The system checks the entered information by users.
5. The user can change successfully the password
message is displayed.
6. Use Case ends
Post Condition The users successfully change the existing password.

Alternative Flow of Events A5. The entered information is not correct. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional Flow of Events E5. Old message did not match message.

E6. Use Case Ends

19
Table2. 4 Use case documentation for View Comment.

Use Case Name View comment

ID UC#4

Actors MOE

Description To see the comment given by student, school and higher

education institution.

Precondition The comment is given by user.

Post Condition The system MOE can view the given comment.

Basic Flow of Events 1. The MOE open and click view comment link.
2. Comment form is displayed.
3. MOE fill the required field.
4. The system checks the entered value.
5. The authorized person can view the given comment.
6. Use Case ends.
Alternative flow of Events A5. If the user can not view the comment correctly, then
error is there.

A4. Use Case ends.

Exceptional view of an Event E3. If the entered comment is incorrect then the output is
incorrect.

E4.Use case ends.

Table2. 5 Use case documentation for Generate announcement

Use Case Name Generate announcement

ID UC#5

20
Actor MOE

Description MOE can generate announcement.

Precondition The system must logs as MOE

Basic Flow of Events 1. The MOE clicks on generate announcement link.

2. Generate announcement form is displayed.
3. The administrator fills the information carefully and
click on generate announcement button.
4. The system validates the entered information.
5. The administrator successfully generates
announcement.
6. Use Case Ends.
Post Condition The MOE generates or creates announcement.

Alternative Flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional flow of Events E5. Error is there in posting announcement.

E6.Use Case ends.

Table2. 6 Use case documentation for Register student Score.

Use Case Name Register Score

ID UC#6

Actors MOE

Description To register the score of the student.

Precondition The MOE must login to the system.

21
Post Condition The Scores are registered.

Basic Flow of Events 1. The MOE clicks on register score link.

2. Register score form is displayed
3. The MOE fills the required information and click on
register score button.
4. The system check the entered value
5. Student score successfully registered message is
displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. The Current registration number is inserted Previously
please try again

E6.Use case ends.

Table2. 7 Use case documentation for View announcement.

Use Case Name View announcement

ID UC#7

Actors Student, School, Higher education institution

Description To view the announcement.

Precondition Announcement must be generated first by administrator.

Post Condition View the generated announcement.

22
Basic Flow of Events 1. The user click on view announcement link.
2. The system displays the announcement.
3. The user can view the announcement.
4. Use Case ends.
Alternative flow of Events A3. If the user cannot view the news correctly, then error is
there.

A4. Use Case ends.

Exceptional view of an Event E3. If the entered announcement is incorrect then the output
is incorrect.

E4.Use case ends.

Table2. 8 Use case documentation for View Placement Result.

Use Case Name View Placement Result

ID UC#8

Actors Student

Description To view the Placement result.

Precondition Placement must be held first by MOE.

Post Condition To view the placement result.

Basic Flow of Events 1. The user click on view placement link.

2. The system displays the view placement form.
3. The user can fill the form.
4. The system checks the entered value.
5. The user can successfully view the placement result.
6. Use Case ends.
Alternative flow of Events A5. If the user can not view the placement result correctly,

23
 then error is there.

A6. Use Case ends.

Exceptional view of an Event E5. Sorry, You Enter Incorrect Registration Number or The
Student cannot be passed.

E6.Use case ends.

Table2. 9 Use case documentation for View Student Score.

Use Case Name View score

ID UC#9

Actors Student

Description To view the score of the student.

Precondition The score must be entered by MOE.

Post Condition View the student score result.

Basic Flow of Events 1. The user click on view score link.

2. The system displays the view score form.
3. The user can fill the form.
4. The system checks the entered information
5. The user can successfully view the score of the
student.
6. Use Case ends.
Alternative flow of Events A5. If the user can not view the score correctly, then error is
there.

A6. Use Case ends.

Exceptional view of an Event E5. If the entered score is incorrect then the output is

24
 incorrect.

E6.Use case ends.

Table2. 10 Use case documentation for View HEI information.

Use Case Name View Higher Education Institution information

ID UC#10

Actors Student

Description To view HEI information.

Precondition The information must be entered by Higher Education

Institution.

Post Condition To view the Higher Education Institution information

Basic Flow of Events 1. The user click on view HEI information link.
2. The view HEI information form is displayed.
3. The user can fill the required information.
4. The system checks the entered value.
5. The user can view the HEI information.
6. Use Case ends.
Alternative flow of Events A4. If there is no upload HEI information, then the step
resumes at 2.

Table2. 11 Use case documentation for View choice information.

Use Case Name View choice information.

ID UC#11

Actors Student, School.

25
Description To view field choice and Higher Education Institution
choice.

Precondition The field choice and Higher Education Institution choice

should have to be filled by school.

Post Condition To view field choice and HEI (Higher Education Institution)
choice.

Basic Flow of Events 1. The user click on view choice information link.
2. The system displays the view choice information
form.
3. The user can fill the form.
4. The systems check the entered value.
5. The user can view the choice of the student.
6. Use Case ends.
Alternative flow of Events A5. If the student field and HEI choice is not registered,
resumes at step 2.

A6. Use Case ends.

Exceptional view of an Event E5. If the entered choice is incorrect then the output is
incorrect.

E6.Use case ends.

Table2. 12 Use case documentation for Register field choice.

Use Case Name Register field choice

ID UC#12

Actors School

Description To register the field choice of the student.

26
Precondition The School must login to the system.

Post Condition The fields of choice are registered.

Basic Flow of Events 1. The School clicks on register field choice link.
2. Register field of choice form is displayed
3. The School fills the required information and click on
register field choice button.
4. The system check the entered value
5. Student field of choice is successfully registered
message is displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. Error cannot connect to system admin! Please contact the
system administrator.

E6.Use case ends.

Table2. 13 Use case documentation for Register Higher Education Institution choice.

Use Case Name Register Higher Education Institution choice

ID UC#13

Actors School

Description To register the Higher Education Institution choice of the

student.

Precondition The School must login to the system.

27
Post Condition The students Higher Education Institution choices are
registered.

Basic Flow of Events 1. The School clicks on register HEI choice link.
2. Register HEI choice form is displayed
3. The School fills the required information and click on
register HEI choice button.
4. The system check the entered value
5. Student HEI choice is successfully registered
message is displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. Error is there.

E6.Use case ends.

Table2. 14 Use case documentation for Register intake capacity of Higher Education Institution.

Use Case Name Register Intake capacity.

ID UC#14

Actors HEI

Description To register the intake capacity of HEI.

Precondition The HEI must login to the system.

Post Condition The Intake capacity of HEI are registered.

Basic Flow of Events 1. The HEI clicks on register intake capacity link.
2. Register intake capacity form is displayed

28
 3. The HEI fills the required information and click on
register intake capacity button.
4. The system check the entered value
5. Intake capacity of HEI successfully registered
message is displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5The current university Fill the capacity.

E6.Use case ends.

Table2. 15 Use case documentation for ask question

Use Case Name Ask question

ID UC#15

Actors Student

Description By asking a question to get service from each other.

Post Condition To successfully ask a question.

Basic Flow of Events 1. The user clicks on ask question link.

2. Ask question form is displayed
3. The user fills the required information and click on
ask question button.
4. The system check the entered value
5. You ask your question successfully message is
displayed.
6. Use Case ends.

29
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. Error! Please contact the system administrator.

E6.Use case ends.

Table2. 16 Use case documentation for process placement

Use Case Name Process placement

ID UC#16

Actors MOE

Description It process and held the placement.

Precondition You logged as MOE and Student score and choice should be
registered and all student‟s field and HEI choice is registered.

Post Condition The student placement is held based on their choice of their
field and Higher Education Institution choice and other
criteria.

Basic Flow of Events 1. The MOE clicks on process placement link.

2. Process placement button is displayed.
3. The MOE click on process placement button.
4. The system process the placement
5. Successfully placement held message is displayed.
6. Use Case ends.
Alternative flow of Events A5. Please try again. Message is displayed.

A6. Use Case Ends.

30
Exceptional view of an Event E5. Error! Please contact the system administrator.

E6.Use case ends.

Table2. 17 Use case documentation for upload university information

Use Case Name Upload information

ID UC#17

Actors Higher Education Institution (HEI)

Description To upload the information of higher education institution.

Precondition The Higher Education Institution must login to the system.

Post Condition The Higher Education Institution information are uploaded.

Basic Flow of Events 1. The Higher Education Institution clicks on upload

information link.
2. Upload information form is displayed
3. The Higher Education Institution fills the required
information and click on upload button.
4. The system check the entered value.
5. You successfully upload Higher Education Institution
information message is displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

31
Exceptional view of an Event E5. Error! Please try again message is displayed.

E6.Use case ends.

Table2. 18 Use case documentation for give comment

Use Case Name Give comment

ID UC#18

Actors Student, School, Higher Education Institution

Description To give comment.

Post Condition The users are successfully giving their comment.

Basic Flow of Events 1. The user clicks on give comment link.

2. Give comment form is displayed.
3. The user fills the required information and clicks on
give comment button.
4. The system check the entered value
5. You give your comment successfully message is
displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. Error! Please contact the system administrator message is
displayed.

E6.Use case ends.

32
Table2. 19 Use case documentation for view question

Use Case Name View question

ID UC#19

Actors Student

Description To see the question and answer given by user.

Precondition The question and answer is given by user.

Post Condition The user can view the question successfully.

Basic Flow of Events 1. The user open and click view question link.
2. The system displays the given question and answer.
3. The user can view the question and answers.
4. Use Case ends.
Alternative flow of Events A3. If the user can not view the comment correctly, then
error is there.

A4. Use Case ends.

Exceptional view of an Event E3. If the entered comment is incorrect then the output is
incorrect.

E4.Use case ends.

Table2. 20 Use Case Documentation for Register Higher Education Institution.

Use Case Name Register HEI

ID UC#20

Actors MOE

Description To register the Higher Education Institution found in our

33
 country.

Precondition The MOE must login to the system.

Post Condition The available Higher Education Institution found in our

country is registered.

Basic Flow of Events 1. The MOE clicks on register HEI link.

2. Register HEI form is displayed
3. The MOE fills the required information and click on
register HEI button.
4. The system check the entered value
5. HEI is successfully registered message is displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. Error! Message is displayed.

E6.Use case ends.

Table2. 21. Use Case documentation for Register School.

Use Case Name Register School

ID UC#21

Actors REB

Description To register the Schools found in our country.

Precondition The REB must login to the system.

Post Condition The available School found in our country is registered.

34
Basic Flow of Events 1. The REB clicks on register School link.
2. Register School form is displayed
3. The REB fills the required information and click on
register school button.
4. The system check the entered value
5. School is successfully registered message is
displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. Error! Message is displayed.

E6.Use case ends.

Table2. 22. Use Case documentation for Register student

Use Case Name Register Student

ID UC#22

Actors School

Description To register the Students who take entrance exam.

Precondition The school must login to the system.

Post Condition All student which Take entrance exam found in our country
is registered.

Basic Flow of Events 1. The school clicks on register student link.

2. Register student form is displayed
3. School fills the required information and click on

35
 register student button.
4. The system check the entered value
5. Students are successfully registered message is
displayed.
6. Use Case ends.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

Exceptional view of an Event E5. Error! Please try again message is displayed.

E6.Use case ends.

Table2. 23 Use case Documentation for Download Student data.

Use case name Download student data

Use case Identifier UC#23

Actor(s) HEI (Higher Education Institution)

Precondition The user must login as their account, and placement should have to
be held.
Post condition Download student information.

Description The user can be download the student information.

Basic flow of action 1) The user clicks on download student data link.
2) The systems display the download student data form.
3) The student enters the required field.
4) The students press download button.
5) The systems validate the form.
6) The system display successful download messages.
7) Use case end.

36
 Alternative flow of event A6: If placement is not held it display the data is not exist message.

Table2. 24 Use Case Documentation for Upload HEI information.

Use case name Upload HEI Information

Use case Identifier UC#24

Actor(s) HEI (Higher Education Institution)

Precondition HEI should be enters valid username and password in order to

upload information.
Post condition HEI Should Upload the information successfully.

Description The HEI upload the HEI information.

Basic flow of action 1) The HEI click upload information link.

2) The system display uploads information form.
3) The HEI fills the required results.
4) The HEI press upload button.
5) The system validates the form.
6) System display successful upload information messages.
7) Use case end.
Alternative flow of event A6: If HEI fills incorrect result, the HEI again to check.

Table2. 25 Use Case documentation for View Score detail.

Use Case Name View score detail

ID UC#25

Actors School

Description To view the detail score of all students.

37
Precondition The score must be entered by MOE.

Post Condition View the student detail score result.

Basic Flow of Events 1. The user click on view score detail link.
2. The system displays the view score detail form.
3. The user can fill the form.
4. The system checks the entered information
5. The user can successfully view the detail score of the
student.
6. Use Case ends.
Alternative flow of Events A5. If the user can not view the score detail correctly, then
error is there.

A6. Use Case ends.

Exceptional view of an Event E5. If the entered score is incorrect then the output is
incorrect.

E6.Use case ends.

Table 2. 26 Use Case documentation for View field

Use Case Name View field

ID UC#26

Actors Student

Description To view the Fields available.

Precondition First field should have to be registered.

Post Condition To View the field.

Basic Flow of Events 1. The user click on view field link.

38
 2. The system displays the view field form.
3. The user can fill the form.
4. The system checks the entered information.
5. The user can successfully view field
6. Use Case ends.
Alternative flow of Events A5. If the user can not view field correctly, then error is
there.

A6. Use Case ends.

Exceptional view of an Event E5. If the placement held is incorrect then the output is
incorrect.

E6.Use case ends.

Table2. 27 use case documentation for Register field

Use Case Name View register field.

ID UC#27

Actors MOE

Description To register field available.

Precondition The MOE must logged to the system.

Post Condition Register available fields.

Basic Flow of Events 1. The MOE click on register field link.

2. The system displays the register field form.
3. The user can fill the form.
4. The system checks the entered information.
5. The user can successfully register a field.
6. Use Case ends.
Alternative flow of Events A5. If the entered value is incorrect then error is there, please

39
 try again message is displayed.

A6. Use Case ends.

Exceptional view of an Event E5. Error, please contact system manager message is
displayed.

E6.Use case ends.

Table2. 28 use case documentation for delete account

Use Case Name Delete account

ID UC#28

Actors MOE

Description To delete a user account field available.

Precondition The MOE must logged to the system.

Post Condition Delete account of a user.

Basic Flow of Events 1. The MOE click on delete account link.

2. The system displays the delete account form.
3. The user can fill the form.
4. The system checks the entered information.
5. The user can successfully delete an account.
6. Use Case ends.
Alternative flow of Events A5. If incorrect value is inserted please try again message
is displayed.

A6. Use Case ends.

Exceptional view of an Event E5. Error, please contact system manager message is
displayed.

E6.Use case ends.

40
Table 2.29 use case documentation for update account

Use Case Name Update account

ID UC#29

Actors MOE

Description To update a user account available.

Precondition The MOE must logged to the system.

Post Condition Update account of a user.

Basic Flow of Events 1. The MOE click on update account link.

2. The system displays the update account form.
3. The user can fill the form.
4. The system checks the entered information.
5. The user can successfully update an account.
6. Use Case ends.
Alternative flow of Events A5. If incorrect value is inserted please try again message
is displayed.

A6. Use Case ends.

Exceptional view of an Event E5. Error, message is displayed

E6.Use case ends.

2.4.3. Sequence Diagram

Sequence diagrams are used to show how objects interact in a given situation. Since The
sequence diagram is used primarily to show the interactions between objects in the sequential

41
order that those interactions occur. It depicts the objects and classes involved in the scenario and
the sequence of messages exchanged between the objects needed to carry out the functionality of
the system. Generally Sequence diagram is an interaction diagram that shows how objects
operate with one another and in what order. It is a construct of a message sequence.

Figure2. 2 sequence diagram for Login.

42
 Figure2. 3 sequence Diagram for Create account.

Figure2. 4 sequence Diagram for Change password.

43
Figure2. 5 sequence Diagram for Natural Score.

44
 Figure 2. 6 Sequence Diagram for field choice.

Figure2. 7 sequence diagram for register HEI choice.

45
 Figure2. 8 sequence diagram for register intake capacity.

Figure2. 9 sequence diagram for view Score.

Figure2. 10 sequence diagram for generate announcements.

46
Figure2. 11 sequence diagram for view Announcement.

Figure2. 12 sequence diagram for view placement result.

47
Figure2. 13 sequence diagram for view HEI Information.

48
Figure2. 14 sequence diagram for Process Placement.

Figure2. 15 sequence diagram for Give Comment

49
 Figure2. 16 sequence diagram for View Comment.

Figure2. 1710 sequence diagram for Register Natural Field

50
 Figure2. 18 sequence diagram for Ask question.

Figure2. 1911 sequence diagram for Register School

51
 Figure2. 2012 sequence diagram for Register HEI

Figure2. 21sequence diagram for Register Student.

52
Figure2.22 sequence diagram for download student data.

53
Figure2.22 sequence diagram for download student data.

Figure2. 23 sequence diagram for information

54
Figure2. 13 sequence diagram for View Field

55
 Figure2. 14 sequence diagram for View Score.

Figure2. 15 Sequence diagram for Delete account.

2.4.4. Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams are intended to model both computational and organizational processes. Activity
diagrams show the overall flow of control.

Activity diagrams are constructed from a limited number of shapes, connected with arrows. The
most important shape types are rounded rectangles represent actions, diamonds represent
decisions, a black circle represents the start (initial state) of the workflow, an encircled black
circle represents the end (final state).

56
Figure2. 16 Activity diagram for Login.

57
 Figure2. 17 Activity diagram for create account

Figure2. 18 Activity Diagram for Change Password.

58
Figure2. 19 Activity Diagram for Register student score.

Figure2. 20 Activity Diagram for Register field of study.

59
Figure2. 21 Activity Diagram for Register HEI choice

60
Figure2. 22 Activity Diagram for Register intake capacity

Figure2. 23 Activity Diagram for View Student Score.

61
Figure2. 24 Activity Diagram for View choice information.

Figure2. 25 Activity Diagram for Generate Announcement.

Figure2. 26 Activity Diagram for View Announcement.

62
Figure2. 27 Activity Diagram for View HEI information

Figure2. 28 Activity Diagram for View placement result

63
Figure2. 29 Activity Diagram for Process placement.

Figure2. 30 Activity Diagram for Give comment.

64
Figure2. 31 Activity Diagram for View comment

Figure2. 32 Activity Diagram for View Question

65
Figure 2. 33 Activity diagram for Ask Question

Figure2. 34 Activity diagram for Register HEI

66
Figure2. 35 Activity Diagram for Register School

Figure 2. 36 Activity Diagram for Register student

67
Figure 2. 37 Activity Diagram for Download student data.

Figure2. 38 Activity Diagram for Upload HEI information.

68
 Figure2. 39 Activity Diagram for view field.

Figure2. 40 Activity Diagram for view Score detail.

69
Figure2. 41 Activity Diagram for register field.

Figure2. 42 Activity Diagram for delete account

70
 .

Figure2. 43 Activity diagram for update account.

71
 2.4.5. Conceptual class Diagram

We used class diagram to describe the structure of the proposed system in terms of
objects, classes, attributes, operations, and their associations. Classes are abstractions that
specify the common structure and behavior of a set of objects in Use Cases. Objects are instances
of classes that are created, modified, and destroyed during the execution of the system.
The proposed system consists MOE, School, Student, and Higher Education Institution. The
class diagram will be refined during system design to include classes representing the solution
domain.

Figure2. 1 Conceptual class diagram

72
 CHAPTER THREE

SYSTEM DESIGN
3.1. Introduction

Next to system analysis we can see about system design of Web based Ethiopian higher
education student placement system. In the requirement analysis phase, we have identified
requirements. In system design we transformation these requirement in analysis model into a
system design model System design is part to get into the solution domain. In this chapter, we
define the design goals of the system; decompose the system in to smaller components that can
be easily realized, the software architecture and persistent data management and also user
interface of the system.
3.2. Design goals

The design goals represent the desired qualities of the system and provide a consistent set of
criteria that must be considered when making design decisions. The following design goals are
identified.

Performance
The response time of the system is reasonable. It also support parallel user with minimum
response time and it takes few minutes to process the placement
Usability
The system is user friendly so that user can use the system without confusion. It requires little
knowledge to use the system.
Dependence
The system should have ability to avoid service failures in the presence of mistakes even if we
enter wrong inputs it survive and it cannot fail.
Availability
The system should be available for any valid users at any time at any place and the system
should be available 24 hours, 7 days a week.
Security
Since the system is going to handle sensitive data concerning an individual, the personal

73
Information of an individual should be handled with a great care. And hence it provide
authentication and database security.
Maintenance
The system should be easily modified based on the government placement policy and add
new functionality to the system. The code for the system should be easily readable,
understandable and should be easily mapped to specific requirements.
Cost

The system should be developed with minimum cost possible.

3.3. Proposed System Architecture

The proposed subsystem will be implemented in Client/Server architecture. Wherever a user is as

long as there is Internet connection he/she can browse the Web based Ethiopian higher
education student placement system page, fill the required inputs by the web page, and
then submit it then the request of the user will be sent to the central server. The server
will give response based on the user request. We represent the architecture of project as follows.

Figure3. 1 architecture of the project.

74
3.3.1. Subsystem Decomposition

In order reduce the complexity of the system, the system is decomposed into subsystems, during
decomposition we have tried to achieve low coupling between subsystems and there will be a
high coherence within a subsystem. The following figure describes the subsystem decomposition
of the system.

Figure3. 2 subsystem decomposition

75
3.4. System Class Diagram

Class Diagram provides an overview of the target system by describing the objects and classes
inside the system and the relationship between them. It provides a wide variety of usages from
modeling the domain specific data structure to detailed design of the target system. Class
diagram describes the structure of a system by showing classes of a system their attributes
methods and interrelationship between classes. Class diagram shows all classes of the system
with their attributes and their relationship. The following diagram shows the class diagram of the
system.

Figure3. 3 Class diagram of the system

76
 3.5. State chart Modeling

State chart diagram is one of the UML diagrams used to model dynamic nature of a system. They
define different states of an object during its lifetime. And these states are changed by events. So
State chart diagrams are useful to model reactive systems. Reactive systems can be defined as a
system that responds to external or internal events. State chart diagram describes the flow of
control from one state to another state. States are defined as a condition in which an object exists
and it changes when some event is triggered. So the most important purpose of State chart
diagram is to model life time of an object from creation to termination. Mainly state chart
modeling is used for:
 To model dynamic aspect of a system.

 To model life time of a reactive system.

 To describe different states of an object during its life time.

Figure3. 4 State Chart diagram for Login

77
 Figure3. 5 State chart diagram for Create account

Figure3. 6 state chart diagram for View placement result

78
 3.6. Collaboration diagram

UML Collaboration diagrams or interaction diagrams illustrate the relationship and interaction
between software objects. They require use cases, system operation contracts, and domain model
to already exist. The collaboration diagram illustrates messages being sent between classes and
objects. A diagram is created for each system operation that relates to the current development
cycle. When creating collaboration diagrams, patterns are used to justify relationships. Patterns
are best principles for assigning responsibilities to objects and are described further in the section
on patterns. There are two main types of patterns used for assigning responsibilities which
are evaluative patterns and driving patterns.

Figure3. 7 Collaboration diagram for Login

79
 Figure3. 8 Collaboration diagram for Create account

Figure3. 9 Collaboration diagram for view placement result

80
 3.7. Logical Database Requirements

3.7.1. Entity Relationship Diagram (ERD)

An entity relationship diagram (ERD) shows the relationships of entity sets stored in a database.
An entity in this context is a component of data. In other words, ER diagrams illustrate the
logical structure of databases. The following diagram shows the entity diagram of the Web
Based Ethiopian Higher Education Student Placement System.

Figure3. 10 Entity relationship diagram

81
 3.8. Persistent Data Management

Persistence data management represent by Persistence model. It is a model that describes the
persistent data aspects of a software system. Persistence modeling is used to communicate the
design of a database to both users and to other developers. The persistent data of these
subsystems will be stored in an MYSQL Server database. His will allow the database to be easily
integrated with and accessed by the rest of the system.

The Web Based Ethiopian Higher Education Student Placement System contain several tables
which are stored in MYSQL server. These tables are:

 User Table: a table used to store user accounts information.

 University table: a table used to store HEI (higher education institution) information.
 School table: a table used to store School information.
 Student table: a table used to store student information.
 Information table: a table used to store the information which released by HEI.
 Announcement table: a table used to store appointment.
 Natural score table: a table used to store natural students score.
 Social score table: a table used to store social students score.
 Field natural table: a table used to store natural field.
 Field social table: a table used to store social field.
 University choice table: a table used to store HEI choice of students.
 Capacity table: a table used to store intake capacity of HEI.
 Placement table: a table used to store placement result information.
 Comment table: a table used to store comment given by users.
 Natural choice table: used to store the natural field choice of students.
 Social choice table: used to store the social field choice of students.
 Question table: a table used to store questions.
 REB: a table used to store a regional education bureau.

82
Table 3. 1 University

Field Name Data Type Visibility Description Key

heiID Int + NOT NULL Primary Key

name Varchar + NULL

town Varchar - NULL

region Varchar - NULL

code Varchar - NULL

Table 3. 2 School

Field Name Data Type Visibility Description Key

schoolId Int + NOT NULL Primary Key

Schoolname Varchar - NULL

Schoolcode Int - NOT NULL Primary Key

Region Varchar - NULL

Zone Varchar - NULL

Town Int - NOT NULL

83
Table 3. 3 Student

Field Name Data Type Visibility Description Key

studentId Int + NOT NULL Primary

regno Int + NOT NULL Primary

firstname Varchar - NULL NULL

middlename Varchar - NULL NULL

lastname Varchar - NULL NULL

Sex Char - NOT NULL

region Int - NOT NULL

stream Varchar - NOT NULL

status int +

Table 3. 4 Information

Field Name Data Type Visibility Description Key

InformationId Int + NOT NULL Primary Key

userId Int + NOT NULL Foreign Key

Information Text - NOT NULL

Table3. 5 Announcement

Field Name Data Type Visibility Description Key

84
announcementId Int + NOT NULL Primary Key

nameannouncement Varchar - NULL

selectto Varchar - NULL

announcement Text - NOT NULL

date Date - NOT NULL

status int -

Table 3. 6 Natural Score

Field Name Data Type Visibility Description Key

scoreId Int + NOT NULL Primary Key

RegNo Int + NOT NULL Foreign Key

firstName Varchar - NOT NULL

middleName Varchar - NOT NULL

lastName Varchar - NOT NULL

mathematics Varchar - NOT NULL

english Float - NOT NULL

aptitude Float - NOT NULL

physics Float - NOT NULL

chemistry Float - NOT NULL

85
Biology Float - NOT NULL

Civics Float -

Totals Float -

Table 3. 7 Social Score

Field Name Data Type Visibility Description Key

scoreId Int + NOT NULL Primary Key

RegNo Int + NOT NULL Foreign Key

firstName Varchar - NOT NULL

middleName Varchar - NOT NULL

lastName Varchar - NOT NULL

mathematics Varchar - NOT NULL

English Float - NOT NULL

aptitude Float - NOT NULL

economics Float - NOT NULL

geography Float - NOT NULL

History Float - NOT NULL

Civics Float - NOT NULL

Totals Float - NOT NULL

86
 Table 3. 8 Field Natural

Field Name Data Type Visibility Description Key

fieldId Int + NOT NULL Primary Key

fieldname Int + NOT NULL Foreign Key

fieldcode Varchar - NOT NULL

Description Varchar - NOT NULL Primary Key

Table 3. 9 Field Social

Field Name Data Type Visibility Description Key

fieldId Int + NOT NULL Primary Key

fieldname Int + NOT NULL Foreign Key

fieldcode Varchar - NOT NULL

Description Varchar - NOT NULL Primary Key

Table 3. 10 Natural Capacity

Field Name Data Type Visibility Description Key

capacityId Int + NOT NULL Primary Key

heiId Int + NOT NULL Foreign Key

87
fieldId Int + NOT NULL Foreign Key

Capacity Varchar - NULL

Table 3. 11 Social Capacity

Field Name Data Type Visibility Description Key

capacityId Int + NOT NULL Primary Key

heiId Int + NOT NULL Foreign Key

fieldId Int + NOT NULL Foreign Key

Capacity Varchar - NULL

Table 3. 12 Placement

Field Name Data Type Visibility Description Key

placementId Int + NOT NULL Foreign Key

regno Int + NOT NULL Primary

fieldId Varchar - NULL

heiId Varchar - NULL

88
Table 3. 13 Comment

Field Name Data Type Visibility Description Key

commentId Int + NOT NULL Primary Key

fullname Varchar - NULL

email Varchar - NOT NULL

comment Text - NOT NULL

Table 3. 14 User

Field Name Data Type Visibility Description Key

userId Int + NOT NULL Primary Key

Email Varchar - NOT NULL Primary Key

Password Varchar - NOT NULL

userType Varchar - NOT NULL

tokencode Int - NOT NULL

Status Int - NOT NULL

Table 3. 15 Question

Field Name Data Type Visibility Description Key

QuestionId Int - NOT NULL Primary Key

Fullname Varchar - NOT NULL

89
Email Varchar - NOT NULL

Question Text - NULL

Table 3. 16 choice natural

Field Name Data Type Visibility Description Key

choiceId Int + NOT NULL Primary Key

Regno Varchar - NOT NULL Foreign Key

fieldId Int - NOT NULL Foreign Key

Choice Int NOT NULL

Table 3. 17 choice social

Field Name Data Type Visibility Description Key

choiceId Int + NOT NULL Primary Key

regno Varchar - NOT NULL Foreign Key

fieldId Int - NOT NULL Foreign Key

choice Int NOT NULL

Table 3. 18 university choice

Field Name Data Type Visibility Description Key

choiceId Int + NOT NULL Primary Key

regno Varchar - NOT NULL Foreign Key

90
heiId Int - NOT NULL Foreign Key

choice Int NOT NULL

Table 3. 19 upload

Field Name Data Type Visibility Description Key

uploadId Int + NOT NULL Primary Key

userId Int + NOT NULL Foreign Key

description Text + NOT NULL

file Object

Table 3. 20 REB

Field Name Data Type Visibility Description Key

regionId Int + NOT NULL Primary Key

code Int + NOT NULL Foreign Key

name Varchar + NOT NULL

town varchaar + NOT NULL

91
Figure 3.11 Persistence modeling

92
 3.9. Component Diagram

The Component Diagram helps to model the physical aspect of an Object-Oriented software
system. It illustrates the architectures of the software components and the dependencies between
them. Those software components including run-time components, executable components also
the source code components.

The purpose is also different from all other diagrams discussed so far. It does not describe the
functionality of the system but it describes the components used to make those functionalities, so
from that point component diagrams are used to visualize the physical components in a system.
These components are libraries, packages, files.
Generally the purpose of the component diagram is Visualize the components of a system,
Construct executable by using forward and reverse engineering and describes the organization
and relationships of the components.

Figure3. 11 Component diagram of the system

3.10. Deployment Diagram

Deployment diagram would show what hardware components exist For example web server, an
application server, a database server and what software components run on each node and how
the different pieces are connected. UML deployment diagrams show the physical view of the

93
system, bringing the software into the real world by showing how software gets assigned to
hardware and how the pieces communicate. The physical deployment model provides a detailed
model of the way components will be deployed across the system infrastructure. In other word
UML deployment diagrams shows the hardware for your system, the software that is installed on
that hardware, and the middleware used to connect the disparate machines to one another. You
want to create a deployment diagram for applications that are deployed to several machines. in
the deployment phase , we are concerned with getting the hardware and software to the end
users.

Figure3. 12 Deployment Diagram

94
 CHAPTER FOUR
IMPLEMENTATION
4.1. System Implementation

Systems implementation is the process of defining how the information system should be built
ensuring that the information system is operational and used, ensuring that the
information system meets quality standards. In this phase a lot of team members are working for
coding and get final successful result for software. The work is subdivided under a sub-phase
where each code is assigned to different team members, so the development process is working
faster. In this phase if runs on various systems. If the system runs smoothly without any flaws,
then it is considered to be launched. If error in generated then it goes to testing development for
testing and the team member writes a code and fix the error

4.2. Objective of the implementation

The main objective of the implementation is to replace the analysis and design phase automated
by writing a code.

Implementation refers to the Coding of the all documents gathered starting from requirement
analysis to Design phase. So now the team in a position of converting all documents gathered
and designed into the code so that the system will be implemented for the user to be used for the
purpose it developed. The main objective of the implementation is to replace or change the
current data handling which is manual handling mechanism into an automated system that is
based on database. Specifically the implementation is intended to meet the following goals:-

• To gain an easier and faster service.

• To satisfy customer

• To decrease work overload

95
 4.3. Interface design
Here, the implemented system is described. How the user interacts with the system and some of
the results of interaction with the system along with the screen shots are described. The system
has web user interfaces for different type of users and purposes. The interface will be accessible
by appropriate users to carry out their duties. A block diagram for the user interface used in
presented in Figure below.

Figure 4. 1 Home page for Web based Ethiopian Higher Education Student placement
system.

96
Figure 4. 2 Student Registration page of the System

Figure 4. 3 Registering Field Choice For Student

97
Figure 4. 4 Home page for Ministry of Education

Figure 4. 5 Processing placement page

98
 4.4. Testing
Testing is a process of executing a program or application with the intent of finding the software
bugs. It can also be stated as the process of validating and verifying that a software program or
application or product: Meets the business and technical requirements that guided it's design
and development. We use different types of testing to test the system. The types testes we use
are listed and described below.

Testing by requirement: the requirements that are tested during the implementation.
Testing through correctness: Mainly concerned on how the user use the system without
difficulty.

Testing through Accuracy: the system gives only valid data if only valid data is given to it is
tested.

Performance testing: term often used interchangeably with „stress‟ and „load‟ testing. To check
whether system meets performance requirements.

Security testing: can system be penetrated by any hacking way. Testing how well the system
protects against unauthorized internal or external access. Checked if system, database is safe
from external attacks.

Unit testing: Testing of individual software components or modules. Typically done by the
programmer and not by testers, as it requires detailed knowledge of the internal program design
and code, may require developing test driver modules or test harnesses.

Error handling Testing: testing whether a system provides good error handling when user
provides input to the system.

Beta testing: testing typically done by end-users or others. Final testing before releasing
application for commercial purpose.

99
 4.5. Sample source code

Sample source code for login

<?php

session_start();

include '../admin/include/connection.php';

$msg = '';

$de = '';

if (isset($_POST['login'])) {

if (isset($formData['remember_me'])) { // if user check the remember me checkbox

$twoDays = 60 * 60 * 24 * 2 + time();

setcookie('username', $formData['email'], $twoDays);

setcookie('password', $formData['password'], $twoDays);

} else { // if user not check the remember me checkbox

$twoDaysBack = time() - 60 * 60 * 24 * 2;

setcookie('email', '', $twoDaysBack);

setcookie('password', '', $twoDaysBack);

$email = $_POST['email'];

$password = md5($_POST['password']);

100
$query1 = mysql_query("select * from user WHERE email='$email' AND
password='$password'");

if (mysql_num_rows($query1) > 0) {

$row = mysql_fetch_array($query1);

$usertype = $row['usertype'];

$userId = $row['userId'];

if ($usertype == '') {

} if ($usertype == 'moe') {

$st = mysql_query("select * from user where userId='$userId'");

if (mysql_num_rows($st) > 0) {

$st1 = mysql_fetch_array($st);

$status = $st1['status'];

if ($status == '0') {

$_SESSION['email'] = $email;

$_SESSION['userId'] = $userId;

header("Location: ../admin/index.php");

} else {

$de = 'The user account is deactivated??';

101
 }

} if ($usertype == 'university') {

$in = mysql_query("select * from user where userId='$userId'");

if (mysql_num_rows($in) > 0) {

$in1 = mysql_fetch_array($in);

$status = $in1['status'];

if ($status == '0') {

$_SESSION['email'] = $email;

$_SESSION['userId'] = $userId;

$_SESSION['name'] = $name;

header("Location: ../university/index.php");

} else {

$de = 'The user account is deactivated??';

} elseif ($usertype == 'regionaleducation') {

$reg = mysql_query("select * from user where userId='$userId'");

if (mysql_num_rows($reg) > 0) {

$reg1 = mysql_fetch_array($reg);

$status = $reg1['status'];

102
 if ($status == '0') {

$_SESSION['email'] = $email;

$_SESSION['userId'] = $userId;

header("Location: ../regional/regional.php");

} else {

$de = 'The user account is deactivated??';

} elseif ($usertype == 'school') {

$ad = mysql_query("select * from user where userId='$userId'");

if (mysql_num_rows($ad) > 0) {

$ad1 = mysql_fetch_array($ad);

$status = $ad1['status'];

if ($status == '0') {

$_SESSION['email'] = $email;

$_SESSION['userId'] = $userId;

header("Location: ../school/index.php");

} else {

$de = 'The user account is deactivated??';

103
 }

} else {

echo "Your Email and password You enter did notmatch";

?>

<?php

$msg = '';

$de = '';

if (isset($_POST['login'])) {

$email = $_POST['email'];

$password = $_POST['password'];

$query1 = mysql_query("select * from user WHERE email='$email'");

if (mysql_num_rows($query1) > 0) {

$row = mysql_fetch_array($query1);

$usertype = $row['usertype'];

$userId = $row['userId'];

$status = $row['status'];

if ($status == 1) {

104
 ?>

<div class='alert alert-error'>

<button class='close' data-dismiss='alert'>&times;</button>

<strong>Sorry!</strong> This Account is not Activated Go to your Inbox and Activate

it.

</div><?php } ?>

<?php

?>

Sample sorce code for Natural science feield choice

<?php

if (isset($_POST["submit"])) {

$regno = $_POST["regno"];

$fieldCount = mysql_fetch_assoc(mysql_query("SELECT COUNT(*) AS COUNT FROM

field_natural"))["COUNT"];

$fieldsChoice = $_POST["field"];

$fieldList = explode(",", $fieldsChoice);

$check = mysql_query("SELECT * FROM choice_natural WHERE regno='$regno'");

if (mysql_num_rows($check) == 0) {

foreach ($fieldList as $key => $fieldId) {

$choice = $key + 1;

105
 $res=mysql_query("INSERT INTO choice_natural (regno, fieldId, choice) VALUES
('$regno', $fieldId, $choice)

} if($res){

$message= "You successfully Choose a field";

} if(!$res){

$error= "There is an Error in Choosing a field";

} else {

$error="The Field Choice Of the student is Registered Previously";

?>

106
 CHAPTER FIVE
CONCLUSION AND RECOMMENDATION
5.1. Conclusion

In this project we have seen the major work is related to student placement system. Currently
even if the ministry of education have a system that manages the students placement system but
this system cannot give full services or cannot satisfy the user of the system. To overcome this
problem we develop the system which is called Web based Ethiopian Higher Education student
placement system. When we conclude the web based Ethiopian Higher Education student
placement system has the role related to registering students, registering intake capacities of all
university, registering available fields and universities that found in our country, based all
information registered it process placement and place students with their respective field and
university and announces the placement result to students and others. The Ethiopian Higher
Education Student Placement system will be web based system, it is accessible from everywhere
within internet connection and only the allowed user can create account for other authenticated
users to maintain a security in the system.

5.2. Recommendation

 As it is known currently the number of students who are using mobile in increased from
day to day, so it is better in the system developing by integrating this web based system
with mobile application.
 Accessing the placement criteria of ministry of Education is is difficult for researchers
that is far apart from Addis Abeba, so the if the Ministry of Education prepares a well
document criteria and distribute to Regional Education bureau the researchers can get full
information about the criteria of Ministry of Education.

107
References

[1]. Scot W.Ambler, The object Primer, 2nd Edition, 2001.

[2]. Pankaj Jalote, An Integrated Approach to Software Engineering, Third Edition.

[3]. Peter R. Hill, Practical Software Project Estimation: A Toolkit for Estimating Software
Development Effort and Duration, 2010.

108