MADDA WALABU UNIVERSITY

COLLEGE OF COMPUTING
DEPARTMENT OF COMPUTER SCIENCE
PROJECT TITLE: WEB BASED ETHIOPIAN HIGHER EDUCATION
STUDENT PLACEMENT SYSTEM
FINAL PROJECT SUBMITED TO DEPARTMENT OF COMPUTER SCIENCE IN
PARTIAL FULFILLEMENT OF THE REQUIREMENTS FOR THE DEGREE OF
BACHELOR OF SCIENCE IN COMPUTER SCIENCE

ADVISOR NAME: EYOB ABERA (M.Sc.)

BY

GROUP MEMBERS: BERHANU MULATU [ECSR/0061/08]

DISASSA MERGA [ECSR/0070/08]
ABDI KENASA [ECSR/0046/08]
FERIHAN ABDOSH [ECSR/0073/08]

JUNE, 2019
BALE ROBE, ETHIOPIA
GROUP- 4
APPROVAL SHEET

NAME OF STUDENT SIGNATURE DATE

1. BERHANU MULATU [0061/08] _____________ _____________

2. DISASSA MERGA [0070/08] _____________ _____________

3. ABDI KENASA [0046/08] _____________ _____________

4. FERHIHAN ABDOSH [0073/08] _____________ _____________

ADVISOR SIGNATURE DATE

EYOB ABERA ___________ ____________

PROJECT COORDINATOR SIGNATURE DATE

ABDETA ___________ ____________

RAKEB ___________ _____________

HEAD OF DEPARTMENT SIGNATURE DATE

TEKALIGN ______________ ______________

PROJECT EXAMINER SIGNATURE DATE

……………………… ______________ ______________

i|Page
 Acknowledgment
We would like to express our special thanks of gratitude to our advisor Mr. Eyob Abera 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 Bale Zone Educational Bureau and
Director of Robe 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 the people who help us doing
this piece of projects.

ii | P a g e
 Abstract
The current student placement system consists of both manual and automated mechanisms .The
current system exhibits manual process for the selection which students use paper to select the
university, this paper provided by their high school contains a bulk of information regarding
university name, department available and number of students that the university needs for each
department. Relatively this information lacks accuracy. The automated placement system helps
students to view their placement at anywhere at any time with their account
The proposed system is developed with the aim of solving this problems and adding additional
features for the university placement system. We observed how the manual system is being
working and thus this helps us to develop the proposed system which improves all manual
process on the student side and makes all the process automated. In order to implement this
computerized system the proposed system uses PHP programing language as front end and
MYSQL as backend. Generally the proposed computerized student placement systems provides
services in more effective, user friendly and ease of use.

iii | P a g e
Table of Contents
Acknowledgment ........................................................................................................................................... ii
Abstract........................................................................................................................................................ iii
List of Figures ............................................................................................................................................. vii
List of Table .................................................................................................................................................. x
List of Abbreviations ................................................................................................................................... xii
Chapter One:-Introduction ........................................................................................................................... 1
1.1 Background of the project ...................................................................................................................... 1
1.2 Statement of the Problem ........................................................................................................................ 2
1.3 Significance of the project ...................................................................................................................... 3
1.4 Objective of the project ..................................................................................................................... 3
1.4.1 General Objective ......................................................................................................................... 3

1.4.2 Specific Objective ........................................................................................................................ 3

1.5 Scope and Limitation of the Projects ...................................................................................................... 4

1.5.1 Scope of the project ...................................................................................................................... 4

1.5.2 Limitation of the project ............................................................................................................... 4

1.6 Methodology and Tools of the Project .................................................................................................... 5

1.6.1 Data Collection Methodology ...................................................................................................... 5

1.6.2 System analysis and design Methodology.................................................................................... 6

1.7 Project Management Technique........................................................................................................ 7

1.7.1 Project Time Schedule ................................................................................................................. 7

1.7.2 Project Budget .............................................................................................................................. 8

1.7.3 Project work down structure and Responsibility .......................................................................... 8

1.7.4 Risk Analysis, identification, mitigation and monitoring ............................................................ 9

1.8 Feasibility of the Project ...................................................................................................................... 10

1.8.1 Economic Feasibility .................................................................................................................. 10

1.8.2 Technical Feasibility .................................................................................................................. 10

1.8.3 Political feasibility...................................................................................................................... 11

1.8.4 Operational Feasibility ............................................................................................................... 11

iv | P a g e
Chapter Two:-Current System .................................................................................................................... 12
2.1 Introduction .......................................................................................................................................... 12
2.2 Description of the Current System ........................................................................................................ 12
2.3 Literature review .................................................................................................................................. 12
2.4 Drawback of the existing system........................................................................................................... 13
2.5 Practice to be preserved from the current system ................................................................................ 13
2.6 Business Rule ........................................................................................................................................ 14
2.7 Alternative solution............................................................................................................................... 14
Chapter Three: Proposed system................................................................................................................ 15
3.1 Overview of the proposed system ......................................................................................................... 15
3.2 Systems Constraints and Assumptions .................................................................................................. 15
3.2.1 Constraints.................................................................................................................................. 15

3.2.2 Assumptions ............................................................................................................................... 16

3.3 Functional Requirement (FR) ............................................................................................................... 16

3.4 Non-Functional Requirements (NFR) ................................................................................................... 17
3.5 Graphical User Interface ...................................................................................................................... 17
3.5.1 Specification ............................................................................................................................... 18

3.5.2 Hardware and software requirements ......................................................................................... 19

3.6 User interface description .................................................................................................................... 19

3.7 Security and safety procedure............................................................................................................... 20
Chapter 4:-System Modeling ...................................................................................................................... 21
4.1 Introduction .......................................................................................................................................... 21
4.2 system use case diagram ....................................................................................................................... 21
4.2.1 Actor description ........................................................................................................................ 23

4.2.2 Use case description ................................................................................................................... 23

4.2.3 System Use case Description ..................................................................................................... 24

4.3 Object modeling .................................................................................................................................... 49

4.3.1 Class Diagram ............................................................................................................................ 49

4.4 Dynamic modeling ................................................................................................................................ 50

4.4.1 Sequence diagram ...................................................................................................................... 50

v|Page
Chapter Five: - System Design ................................................................................................................... 84
5.1 Introduction .......................................................................................................................................... 84
5.2 State chart diagram .............................................................................................................................. 84
5.3 Collaboration diagram ......................................................................................................................... 86
5.4 Component Diagram ............................................................................................................................ 87
5.5 Deployment diagram ............................................................................................................................ 88
5.6 Database design.................................................................................................................................... 89
5.7 ERD design and Normalization ............................................................................................................ 90
5.7.1 Normalization ............................................................................................................................. 91

5.8 Object diagram ..................................................................................................................................... 92

5.9 Persistence diagram ............................................................................................................................. 93
5.10 User interface prototype (snap shoot) ................................................................................................ 96
Chapter Six: - System Implementation........................................................................................................ 99
6.1 Introduction .......................................................................................................................................... 99
6.2 Coding (sample code) ........................................................................................................................... 99
6.3 Testing ................................................................................................................................................ 105
6.4 Features to be tested and not to be tested ........................................................................................... 106
6.4.1 Features to be tested ................................................................................................................. 106

6.4.2 Features not to be tested ........................................................................................................... 106

6.4.3 Pass/ fail criteria ....................................................................................................................... 106

6.5 Installation procedure ........................................................................................................................ 107

6.6 Manual preparation (Documentation)................................................................................................ 107
6.7 Support and service ............................................................................................................................ 107
6.8 Conclusion and Recommendation ...................................................................................................... 107
6.8.1 Conclusion................................................................................................................................ 107

6.8.2 Recommendation...................................................................................................................... 108

6.9 References ........................................................................................................................................... 109

6.10 Appendix ........................................................................................................................................... 110

vi | P a g e
 List of Figures
Figure 3.1:- graphical user interfaces .......................................................................................... 18
Figure 4.1:- the proposed system use case diagram ..................................................................... 22
Figure 4.2:-Class Diagram ........................................................................................................... 50
Figure 4.3:-sequence diagram for login ....................................................................................... 50
Figure 4.4:-sequence diagram of create account ......................................................................... 51
Figure 4.5:- sequence Diagram for Change password ................................................................. 52
Figure 4.6:- sequence diagram for register HEI .......................................................................... 53
Figure 4.7:- sequence diagram for register intake capacity ......................................................... 54
Figure 4.8:- sequence diagram for view Score ............................................................................. 55
Figure 4.9:-sequence diagram for view placement result ............................................................. 56
Figure 4.10:- sequence diagram for view HEI Information ......................................................... 57
Figure 4.11:- sequence diagram for Process Placement .............................................................. 58
Figure 4.12:- sequence diagram for Give comment ..................................................................... 59
Figure 4.13:- sequence diagram for view comment ...................................................................... 60
Figure 4.14:- sequence diagram for Ask question ........................................................................ 61
Figure 4.15:-sequence diagram for Register School .................................................................... 62
Figure 4.16:- sequence diagram for Register HEI ....................................................................... 63
Figure 4.17:- sequence diagram for Register Student .................................................................. 64
Figure 4.18:- sequence diagram for choice HEI .......................................................................... 65
Figure 4.19:- sequence diagram for download student data ........................................................ 66
Figure 4.20:- sequence diagram for upload HEI information ...................................................... 67
Figure 4.21:- Sequence diagram for View question ..................................................................... 68
Figure 4.22:- sequence diagram of delete account ....................................................................... 69
Figure 4.23:- Sequence diagram for update account ................................................................... 70
Figure 4.24:-Sequence diagram for logout ................................................................................... 71
Figure 4.25:-Activity Diagram for login ....................................................................................... 72
Figure 4.26:- Activity Diagram for create account ...................................................................... 73
Figure 4.27:- Activity Diagram for change password .................................................................. 73
Figure 4.28:-Activity Diagram for register score ......................................................................... 74

vii | P a g e
Figure 4.29:-Activity diagram for register field ........................................................................... 74
Figure 4.30:- Activity Diagram for register HEI .......................................................................... 75
Figure 4.31:- Activity Diagram for assign student ....................................................................... 75
Figure 4.32:- Activity diagram for register student ...................................................................... 76
Figure 4.33:- Activity Diagram for Register school ..................................................................... 76
Figure 4.34:- Activity Diagram for choice HEI ............................................................................ 77
Figure 4.35:- Activity Diagram for placement process ................................................................ 77
Figure 4.36:-Activity Diagram for view score .............................................................................. 78
Figure 4.37:-Activity Diagram for register intake capacity ......................................................... 78
Figure 4.38:- activity diagrams for download student data ......................................................... 79
Figure 4.39:- Activity Diagram for upload HEI information ....................................................... 79
Figure 4.40:-activity diagram for view HEI information ............................................................. 80
Figure 4.41:- Activity diagram for delete account ........................................................................ 80
Figure 4.42:- Activity Diagram for update account ..................................................................... 81
Figure 4.43:- Activity Diagram for Give comment ....................................................................... 81
Figure 4.44:- Activity Diagram for View comment ....................................................................... 82
Figure 4.45:-Activity Diagram for View Question........................................................................ 82
Figure 4.46:-Activity Diagram for ask question ........................................................................... 83
Figure 4.47:- Activity Diagram for logout .................................................................................... 83
Figure 5.1:- State charts for login ................................................................................................ 84
Figure 5.2:-State charts for create account .................................................................................. 85
Figure 5.3:- State chart for view placement result ....................................................................... 85
Figure 5.4:- Collaboration diagram for Login ............................................................................. 86
Figure 5.5:-Collaboration diagram for Create account ............................................................... 86
Figure 5.6:- Collaboration diagram for view placement result .................................................... 87
Figure 5.7:- Component diagram of the system ............................................................................ 88
Figure 5.8:-Deployment Diagram................................................................................................. 89
Figure 5.9:-Database Design ........................................................................................................ 90
Figure 5.10:- Entity relationship diagram .................................................................................... 91
Figure 5.11:-Object Diagram ....................................................................................................... 93
Figure 5.12:-Persistence modeling ............................................................................................... 95

viii | P a g e
Figure 5.13:- Home page for Web based Ethiopian Higher Education Student placement system
....................................................................................................................................................... 96
Figure 5.14: Ministry of education home page ............................................................................ 97
Figure 5.15:-University home page .............................................................................................. 97
Figure 5.16:-Preparatory school home page ................................................................................ 98
Figure 5.17:-Registering Field Choice for Student ...................................................................... 98

ix | P a g e
 List of Table
Table 1.1:- Development tools ........................................................................................................ 6
Table 1.2:- Gantt chart.................................................................................................................... 7
Table 1.3:- Budget plan ................................................................................................................... 8
Table 1.4:-Project work down structure and Responsibility........................................................... 9
Table 1.5:- Risk analysis table ........................................................................................................ 9
Table 4.1:- Use case documentation for login .............................................................................. 24
Table 4.2:-Use case documentation for Create Account .............................................................. 25
Table 4.3:- Use case documentation for Change Password ......................................................... 26
Table 4.4:- Use case documentation for View Comment .............................................................. 27
Table 4.5:- Use case documentation for Register student Score .................................................. 28
Table 4.6:- Use case documentation for View Placement Result ................................................. 29
Table 4.7:-Use case documentation for View Student Score ........................................................ 30
Table 4.8:- Use case documentation for View HEI information ................................................... 31
Table 4.9:- Use case documentation for View choice information ............................................... 32
Table 4.10:-Use case documentation for Register field choice .................................................... 33
Table 4.11:-Use case documentation for Register HEI choice ..................................................... 34
Table 4.12:- Use case documentation for Register intake capacity of HEI .................................. 35
Table 4.13:- Use case documentation for ask question ................................................................ 36
Table 4.14:- Use case documentation for process placement ....................................................... 37
Table 4.15:- Use case documentation for upload university information..................................... 38
Table 4.16:- Use case documentation for give comment .............................................................. 38
Table 4.17:- Use case documentation for give comment .............................................................. 39
Table 4.18:- Use Case Documentation for Register HEI .............................................................. 40
Table 4.19:- Use Case documentation for Register School .......................................................... 41
Table 4.20:-Use Case documentation for Register student........................................................... 42
Table 4.21:- Use case Documentation for Download Student data .............................................. 43
Table 4.22:- Use Case Documentation for Upload HEI information ........................................... 44
Table 4.23:- Use Case documentation for View Score detail ....................................................... 45
Table 4.24:- Use Case documentation for View field ................................................................... 46

x|Page
Table 4.25:- use case documentation for Register field ................................................................ 46
Table 4.26:- use case documentation for delete account .............................................................. 47
Table 4.27:- use case documentation for update account ............................................................. 48

xi | P a g e
 List of Abbreviations
ICT………………………….....Information Communication and Technology

HEI……………………….........Higher Education Institution

REB……………………………Regional Education Bureau

MOE……………………...........Ministry Of Education

FR………………………….......Functional Requirement

NFR……………………………Non Functional Requirement

OOSDA………………………..Object Oriented Software Development Approach

SDLC…………………………..Software Development Life Cycle

SQL………………………........Structured Query Language

HTML…………………….. …..Hyper Text Markup Language

CSS……………………….. …..Cascading Style Sheet

UML…………………………...Unified Modeling Language

PHP…………………………….Hypertext Preprocessor

ERD…………………………….Entity Relationship Diagram

xii | P a g e
Chapter One:-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, methodology, project plan, and budget
plan for the project.
1.1 Background of the project
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

1|Page
there are many number of private and governmental 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 students 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. Due to this students will confused when they choose HEI and field they want.

 In existing system students cannot see their choice of university and field choice before
placement is held. The student fill their choice by paper and they haven’t chance to see
their choice whether it is correct or not.

 Misplacement: Ministry of education has some criteria to place students but the current
system may not place students with their appropriate choice

 Disability: - there is no special consideration for disable student to get chance according
to their choice the place and field due to this reason many disable student are not get
place according to their interest.

 Question: - there is no direct communication between student and ministry of education.

2|Page
In general the existing 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 the system will improved.
1.3 Significance of the project
The main purpose of this system is to provide better services for student in campus
selection as well as field selection. There are many problems in association with this
process as described in the statement of problem and here are some of purposes.

 It saves paper which provided by schools to students to select their university.

 It minimizes man power.

 It minimizes loss of information which refers to the loss of paper that serve students to
choose their choice so if this paper gets lost may be it is difficult for further process

 It helps students to choose their interested university and field without any confused.

 The system helps the students and the agency to communicate each other easily, so it
minimizes information gap.

1.4 Objective of the project

1.4.1 General Objective
The general objective of the project is to develop a web based Ethiopian higher education
student placement system.

1.4.2 Specific Objective

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

 Perform requirement analysis.

 Analyzing data models

 Designing the system to implement easily

 Design database for student information.

 Manage user’s information.

3|Page
  Design and build a particular model of this proposed system.

 Deploy the system and maintain it until it fits to the needs of the organization.

 Implementing and testing the model.

1.5 Scope and Limitation of the Projects

1.5.1 Scope of the project
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 and the student will be easily down load their certificate.

1.5.2 Limitation of the project

When this project focus on web based Ethiopian higher education student placement
system, our scope includes the above one and there is also a limitation (out of scope) such
as:

 Our system is applicable for only first year regular degree students.

 We don’t make variation of mark for students who join the same department at different
university (means that if student who have 450 marks get engineering department in
MWU in another university he may be get nurse).

 Our system is not applicable for student who gets scholarship.

 Our system is only consider field announce and also only placement.

4|Page
1.6 Methodology and Tools of the Project
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 Collection 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:

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. We interview the
preparatory school director of Robe town and also we interview some students of those
take the entrance exam in this year. We get some information of existing system, how
they can select their interest choice. It is a manual system means the student can choose
on the paper.

Observation: This technique is used to gather accurate information about how the
system actually operates, particularly about the processes. We can’t observe when they
choose b/c the time was not when the students fill the form. But we observe the form
that the students use to choose their choice.

Document Analysis: Student’s 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|Page
 1.6.2 System analysis and design Methodology
The team members use Object Oriented Software Approach (OOSDA) to develop their
system because it is a system development approach encouraging and facilitating
software components. The development models are the various processes or
methodologies that are being selected for the development of the project depending on
the project’s aims and goals. We select water fall software process model, because:-
Each phase are organized in linear order, which much with our project schedule. Every
next page start up on completion of previous phase. Citation (fundamental software
engineering fourth edition).

Software requirement: -
This project uses the following system development tools for different activities.
Table 1.1:- Development tools

No Tools Activities
1 Macromedia Dreamweaver, For editing code
Notepad++
2
CSS For attractive layout

3 PHP Front end (Server side coding)

4
HTML Client side coding

5
MYSQL Back end(data base)

6
Apache Server As server

7 Mozilla Firefox, IE, Google

Browsers
Chrome, Opera
8

6|Page
 Ms office PowerPoint 2010 For Presentation

9 Ms office Visio 2007 To draw UML Diagram and for designs

10
Adobe Photo Shop CS3 To design back ground images

Hardware requirements:-

 Computer with internet connection

 Printer
 Flash disk (8 GB),
 CD 700MB
 Hard disk above 400GB

1.7 Project Management Technique

1.7.1 Project Time Schedule
The time allotted for our project by the team member is given in Gantt chart below.

Table 1.2:- Gantt chart

7|Page
 1.7.2 Project Budget
This describes the costs that we use when we develop our project from initial stage up to last
stage.

Table 1.3:- Budget plan

No Name of Tools Quantity Amount of cost

1 PC(personal computer) 1 13,500.00 birr
2 Smart phone 2 8,000.00 birr
3 Paper 1 pack 180.00 birr
4 Pen 4 24.00 birr
5 Flash disk 2 400.00 birr
6 For printing document - 200.00 birr
7 5CD 30.00 birr

8 Desktop By university

9 Network cable 2 40.00 birr

10 Notepad++ - Free down load

11 Microsoft windows 8.1/10 - Free down load

12 Microsoft Office - Free down load

13 MySQL and WAMP - Free down load

14 Edrawmax for UML diagrams / - Free down load

Microsoft Visio

15 Total Cost 22,374

1.7.3 Project work down structure and Responsibility

The project team consists of 4 members, one team leader and 3 members. Decision on
problem and approach are made by group agreement, which is much better than
individual decision.

8|Page
 Table 1.4:-Project work down structure and Responsibility

No Name Role Responsibility

1 Berhanu Mulatu Leader Data gathering, Requirement
analysis,
System Design, Implementation & Testing
2 Disassa Merga Member Data gathering,
implementation,
Requirement analysis, system design &
Testing
3 Ferihan Abdosh Member System Design ,Implementation & Testing
4 Abdi Kenesa Member Data gathering, Requirement analysis &
Testing

1.7.4 Risk Analysis, identification, mitigation and monitoring

Every programmer may face many problems when he/she want to develop any project.
While we are doing this project we encounter or come across different problems.

 Loss of data by different problem.

 Shortage of time while doing our project.
 The problem of contacting the office manager at the time we needed.
 Virus attack the software.
 Lack of enough reference.
Table 1.5:- Risk analysis table

No
Risk Actions/solution

1 Computer viruses, Backup the file, scanning with anti-viruses

computer failures and recovering the system.

2 When office administrator in not To arrange time for meet with manager.
available during we want.

9|Page
 3 Lack of enough reference To read information from different sites,
using internet when there is access.

4 Lack of financial support from the Use own money appropriately and
department effectively.

1.8 Feasibility of the Project

1.8.1 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.

Tangible economic feasibility: - it includes different materials that will replace

by the proposed system and reduce their costs in different percentage.
For example the current system requires at list 5 packet papers for one month i.e. it
requires 60 packets for a year and each packet costs up to 140 birr. But the current
system tries to reduce by 50%. i.e. it becomes 420 birr.

Intangible economic feasibilities:- are the benefit from the system that are
unquantifiable:-Instructor’s service satisfaction since the newly proposed system is
secure, efficient, available, speedy ,small response time, better service for house
registration for the property officer and for instructors generally the newly
proposed system is economical feasible regarding to moral and service satisfaction
to the concerned body.

1.8.2 Technical Feasibility

The project is 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.

10 | P a g e
 1.8.3 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.

1.8.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.

11 | P a g e
Chapter Two:-Current System
2.1 Introduction
System analysis is a main activity that must be done in any project to have a clear idea
of the proposed system. As we described in first chapter current time students join their
interested universities based on higher education placement scaling system so that
universities take their required number of students based on higher education placement
system. University and field of study selection and placement is major task. During this,
the huge problem is at the side of student and requires great human power, material and
other resources with manual based works and approaches. This makes us to involve in
developing web based Ethiopian higher educational student placement system.

2.2 Description of the Current System

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.3 Literature review

The Literature review is a text of a scholarly paper, which includes the current
knowledge including substantive findings, as well as theoretical and methodological
contributions to a particular topic. Literature reviews use secondary source (written
document) and do not report new or original experimental work. This chapter attempts
to provide a contemporary review of all the relevant higher education student placement
system literature for this work. A good literature review is critical of what has been
written, identifies area of controversy, raises, and questions and identifies areas which
need further research. Higher education student placement system is a comprehensive

12 | P a g e
solution designed to eliminate paper work and reduce manual efforts. It is designed with
an easy- to-use user interface.
To write this documentation we use different references and different guidelines that
support us in order to rises our feeling to do. The related source that we use to propose
and writing our project documentation is the guidance from different site [1]Object
Oriented and Classical Software Engineering to designing some use case diagram,
sequence diagram, activity diagram and etc. Dennis H.2008 [2] also object oriented to
use as a paradigm that provides many concepts to designing object, class and etc. and
also we use Software engineering text book and object oriented software engineering
book to get some idea from what we learned.

Also by referring some written documentation that is related to our project but different title
and that is used to manage the like to higher education student placement system. This is:

 Online Department selection and Registration system this is related to our project in
order to searching, managing, updating, deleting and selection department.

2.4 Drawback of the existing system

Currently Ministry of education has student placement system and this system has
different problems. The first is Misplacement ministry of education has criteria to place
a students but the current system cannot place a students with their appropriate choice
and their 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.5 Practice to be preserved from the current system

The existing system use file and forms that is used to perform the business rules,
describe the operations, definitions and constraints that apply in the maintenance and

13 | P a g e
deployment of system. Team member preserve the following practices from the existing
system.

 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.

2.6 Business Rule

The business rule in the existing system is as follow:-

BR1:-Students must submit their choice just after they finish entrance exam.

BR2:-The Agency must get information of student and information of HEI within a time and
also it must place students within time.

BR3:-System users should have secured username and password in order to access the
system.

2.7 Alternative solution

After identification of the real problems of the existing system, the team suggests
alternative solutions to overcome the problems. Since the new system we are interested
to develop is advanced than the existing system, it is believed to solve the short comings
in the existing system. We set the following alternative solutions to address these
problems.

 Changing the manual system (university and field selection) into an online system.

 Uses technological way to provide reliable services.

 Develop web based system to satisfy student placement system.

 Develop online web based system in order to secure placement system.

14 | P a g e
Chapter Three: Proposed system
The aim of proposed system is to develop a system of improved and enhanced area that
comfortable and secured environment to work with. The proposed system can overcome
some Limitations of the existing system. Thus the proposed system is mainly aimed at
minimizing the existing student’s problems as well as the agencies problems by changing
the computerized system by adding some future and does some of the following activities.
 It provides to register, search, update and view user information.
 Provides internal communication (messaging).
 The system stores the detailed records related to: registered students, existing
administrator, and generally system constraints.
3.1 Overview of the proposed 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
those 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.

3.2 Systems Constraints and Assumptions

3.2.1 Constraints
Constraint is the element factor or a subsystem that restricts an entity, project, or system
from achieving its potential (or higher level of output) with reference to its goal. Some
of the constraints are:-

 Time: - the time given to finish this project is short.

 Internet access: - there is a problem of internet access in the campus. This will be a big
challenge.

15 | P a g e
  Condition of environment: - Condition of this environment is not good and this will be a big
challenge to not finish the project on time.

3.2.2 Assumptions
During the development of the project there may be different problems that we may face.

These are:

 Time management problem: but we try to solve this problem by working

cooperatively, divide our time by schedule for each phase of the project and we try
to use this schedule effectively.

 It may be difficult for us to get information what we need directly from ministry
of education agency. To solve this problem we try to ask any thing politely the
preparatory school and Regional education bureau which nearly to us.

3.3 Functional Requirement (FR)

Functional requirements are fundamental building block requirements. It is a statement
exactly what the system must do. The new system will take the following functional
requirements:-

 This system must enable to register, login, update, delete and search user information
from the database.

 Release higher education institution information and view higher education institution
information.

 Enable students to select their interested universities and field.

 It also enables students to change their placement choose.

 The administrators post the placement.

 View student placement result, field of study and grade 12th score.

 If the student certificate will be lost, the students ask a question to the MOE to send
another certificate.

 The MOE view the question and send certificate to the student.

16 | P a g e
  Download Student data.

 Giving and receiving feedback(send request) like comment

3.4 Non-Functional Requirements (NFR)
The new System has the following non-functional requirements:-
Maintainability: - proposed system must correct defects and errors occurring, maximize a
system useful life, maximize efficiency, reliability and safety, and make future maintenance
easier

Privacy: - The domain of privacy partially overlaps security, which can include the concepts of
appropriate use, as well as protection of information.

Quality: - The qualities of the proposed system are its accuracy so that only accurate
information is provided to the users so they will be satisfied by correct information at the
right time.

Response time: -Response time is the total amount of time it takes to respond to a request
for service. So in our system, the service time is the time it takes to do the work you
requested generally the response time in our system is mostly short.

Usability: -is the ease of use and learnability of a human-made object. The proposed system
website site is highly user friendly and all the interfaces are interactive so that everybody
can use it easily.

3.5 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.

17 | P a g e
 Figure 3.1:- graphical user interfaces

3.5.1 Specification
A system requirements specification (SRS) is a comprehensive description of the intended

purpose and environment for software under development. The SRS fully describes what the

18 | P a g e
software will do and how it will be expected to perform. It defines how an application will

interact with system hardware, other programs and human users in a wide variety of real-

world situations. By using the connection we download the source code from w3 school and

also we will use what we are learned in the class and also by using the aid that we get from

our advisor we plan to develop this system for our Ethiopian student.

Those lists below are system requirements specification:-

 Our system using for register the student name in easily

way.

 Our system shows the student place and field.

 Our system generates report for all Ethiopian students to see information about education.

 Our system will using to update information and delete information

 Our system will give comment for ministry education.

3.5.2 Hardware and software requirements

Hardware requirements:-
 Computer
 Hard disk-931GB

 USB flash-16GB

Software requirements:-
 MY-SQL for database purpose
 PHP & HTML for programming language
 Micro dream media waver, sublime text 3,notepad++ in case of
application
 MS word and Edrawmax UML diagram in case of writing documentation
3.6 User interface description
How the user interacts with the system and some of the results of interaction
with the system. The system has web user interfaces for different type of users

19 | P a g e
and purposes. The interface will be accessible by appropriate users to carry out
their duties.
Student placement system (home):- used to select the operation that users want.

Login: - helps to validate user and used to enter in to the system.

Admin page:-used to select admin operation.

Registration: - this system is register student information like registration number, full name,
sex, id, region etc...

Choice:-This subsystem is used to register the choose field of study by each student where are
in all department in Ethiopian University.

Placement:-This subsystem is used to calculate the placement of students based on the criteria
set by all university registrars and the department capacity.

Download data:-This subsystem is used for the Students to download the certificate.

Post information:-This subsystem is used for the placement coordinator to post important
information for student.

3.7 Security and safety procedure

Security requirement represent the environment in which the system must operate as well as
the type and degree of security that must be provide .in this system, no one can modify the
users information after they register and know their departments. Because the system gives
one chance for the user to register and choose the department by displaying confirmation
message for the user. But one can use student’s information as his/her own and made a
change if he/she gets the registration number of the user. Note that only the database
administrator can access, delete or modification of information about the user. 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.

20 | P a g e
Chapter 4:-System Modeling
4.1 Introduction
We should have to follow SDLC (System Development Life Cycle) as conceptual model
because it is used in project management to describe the stages involved in the system
that we have proposed to develop from an initial feasibility study through final
document. System model describes the scenarios like use case diagrams, sequence
diagrams, class diagram and etc. for the system. In this project, we used an object
oriented system development methodology.

4.2 system use case diagram

Use case describes the behavior of the system as seen from an actor’s point view. A use
case describes a function provided by the system as a set of events that yield a visible
result for the actors. In the analysis phase they represent the functionality of the system.
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 outside’s or actor’s
perspective. The use case diagram of the system is shown in Figure below.

21 | P a g e
Figure 4.1:- the proposed system use case diagram

22 | P a g e
 4.2.1 Actor description
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, field, assign student, generate
announcement, register higher education Institution.

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 and downloads the information of the
students.

REB: A user of the systems registers all school that available in their region.

4.2.2 Use case description

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

 Login

 Manage account

 Register score

 Register field

 Register Higher Education institution (HEI)

 Assign student

 Register school

 Register student

 View placement result

23 | P a g e
  View score

 Register intake capacity of university

 Download student data

 View higher education institution information

 Ask question
 View question

 Post higher education institution information

 Give comment

 View comment

 Change password
 Logout.

4.2.3 System Use case Description

Table 4.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.

24 | P a g e
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

not activated

E7. Use Case ends.

Table 4.2:-Use case documentation for Create Account

Use Case Name Create Account

ID UC#2

25 | P a g e
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.

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

E6. Use Case ends.

Table 4.3:- Use case documentation for Change Password

Use Case Name Change Password

26 | P a g e
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

Table 4.4:- Use case documentation for View Comment

Use Case Name View comment

ID UC#4

Actors MOE

27 | P a g e
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.

Table 4.5:- 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.

28 | P a g e
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.

Table 4.6:- 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.

29 | P a g e
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,
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.

Table 4.7:-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.

30 | P a g e
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

incorrect.

E6.Use case ends.

Table 4.8:- 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

31 | P a g e
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.

Table 4.9:- Use case documentation for View choice information

Use Case Name View choice information.

ID UC#11

Actors Student, School.

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.

32 | P a g e
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.

Table 4.10:- 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.

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.

33 | P a g e
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.

Table 4.11:- Use case documentation for Register HEI 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.

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.

34 | P a g e
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.

Table 4.12:- Use case documentation for Register intake capacity of HEI

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
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.

35 | P a g e
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.

Table 4.13:- 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.
Alternative flow of Events A5. The entered information is incorrect. Please try again.
Message is displayed.

A6. Use Case Ends.

36 | P a g e
Exceptional view of an Event E5. Error! Please contact the system administrator.

E6.Use case ends.

Table 4.14:- 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 students 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.

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

E6.Use case ends.

37 | P a g e
 Table 4.15:- 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.

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

E6.Use case ends.

Table 4.16:- Use case documentation for give comment

38 | P a g e
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.

Table 4.17:- Use case documentation for give comment

Use Case Name View question

ID UC#19

39 | P a g e
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.

Table 4.18:- Use Case Documentation for Register HEI

Use Case Name Register HEI

ID UC#20

Actors MOE

Description To register the Higher Education Institution found in our

country.

Precondition The MOE must login to the system.

40 | P a g e
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.

Table 4.19:- 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.

41 | P a g e
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.

Table 4.20:-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.

42 | P a g e
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
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.

Table 4.21:- 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.

43 | P a g e
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.
Alternative flow of event A6: If placement is not held it display the data is not exist message.

Table 4.22:- 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.

44 | P a g e
 Table 2.23:- 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.

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.

45 | P a g e
 Table 2.24:- 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.

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.

Table 4.25:- use case documentation for Register field

Use Case Name View register field.

ID UC#27

46 | P a g e
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
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.

Table 4.26:- 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.

47 | P a g e
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.

Table 4.27:- 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.

48 | P a g e
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.

4.3 Object modeling

4.3.1 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 of MOE, School, Student, and Higher Education Institution. The class diagram
will be refined during system design to include classes representing the solution domain.
Classes are nothing but they represent participating objects found in use cases and sequence
diagrams and describe their attributes and operations. Objects can be anything having name,
attributes and properties.

49 | P a g e
Figure 4.2:-Class Diagram

50 | P a g e
4.4 Dynamic modeling
4.4.1 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
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.

The sequence Diagram for each Actor

Figure 4.3:-sequence diagram for login

50 | P a g e
Figure 4.4:-sequence diagram of create account

51 | P a g e
Figure 4.5:- sequence Diagram for Change password

52 | P a g e
Figure 4.6:- sequence diagram for register HEI

53 | P a g e
Figure 4.7:- sequence diagram for register intake capacity

54 | P a g e
Figure 4.8:- sequence diagram for view Score

55 | P a g e
Figure 4.9:-sequence diagram for view placement result

56 | P a g e
Figure 4.10:- sequence diagram for view HEI Information

57 | P a g e
 Figure 4.11:- sequence diagram for Process Placement
.

58 | P a g e
Figure 4.12:- sequence diagram for Give comment

59 | P a g e
Figure 4.13:- sequence diagram for view comment

60 | P a g e
Figure 4.14:- sequence diagram for Ask question

61 | P a g e
Figure 4.15:-sequence diagram for Register School

62 | P a g e
Figure 4.16:- sequence diagram for Register HEI

63 | P a g e
Figure 4.17:- sequence diagram for Register Student

64 | P a g e
Figure 4.18:- sequence diagram for choice HEI

65 | P a g e
Figure 4.19:- sequence diagram for download student data

66 | P a g e
Figure 4.20:- sequence diagram for upload HEI information

67 | P a g e
Figure 4.21:- Sequence diagram for View question

68 | P a g e
Figure 4.22:- sequence diagram of delete account

69 | P a g e
Figure 4.23:- Sequence diagram for update account

70 | P a g e
 Figure 4.24:-Sequence diagram for logout

4.5 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

71 | P a g e
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).

The Activity Diagram for each Actor

Figure 4.25:-Activity Diagram for login

72 | P a g e
 Figure 4.26:- Activity Diagram for create account

Figure 4.27:- Activity Diagram for change password

73 | P a g e
Figure 4.28:-Activity Diagram for register score

Figure 4.29:-Activity diagram for register field

74 | P a g e
 Figure 4.30:- Activity Diagram for register HEI

Figure 4.31:- Activity Diagram for assign student

75 | P a g e
 Figure 4.32:- Activity diagram for register student

Figure 3.33:- Activity Diagram for Register school

76 | P a g e
Figure 4.34:- Activity Diagram for choice HEI

Figure 3.35:- Activity Diagram for placement process

77 | P a g e
Figure 4.36:-Activity Diagram for view score

Figure 4.37:-Activity Diagram for register intake capacity

78 | P a g e
Figure 4.38:- activity diagrams for download student data

Figure 4.39:- Activity Diagram for upload HEI information

79 | P a g e
 Figure 4.40:-activity diagram for view HEI information

Figure 4.41:- Activity diagram for delete account

80 | P a g e
Figure 4.42:- Activity Diagram for update account

Figure 4.43:- Activity Diagram for Give comment

81 | P a g e
 Figure 4.44:- Activity Diagram for View comment

Figure 4.45:-Activity Diagram for View Question

82 | P a g e
Figure 4.46:-Activity Diagram for ask question

Figure 4.47:- Activity Diagram for logout

83 | P a g e
Chapter Five: - System Design
5.1 Introduction
In this part we can see about system design of Web based Ethiopian higher education student
placement system. Before this we have identified requirements. In system design we transform the
requirement 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 into smaller components that
can be easily realized, the software architecture and persistent data management and also user interface
of the system.
5.2 State chart diagram
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 diagram is 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:
 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.

Figure 5.1:- State charts for login

84 | P a g e
 Figure 5.2:-State charts for create account

Figure 5.3:- State chart for view placement result

85 | P a g e
5.3 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.

Figure 4.:- Collaboration diagram for Login

Figure 5.4:-Collaboration diagram for Create account

86 | P a g e
 Figure 5.5:- Collaboration diagram for view placement result

5.4 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.

87 | P a g e
 Figure 5.6:- Component diagram of the system

5.5 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 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

88 | P a g e
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.

Figure 5.7:-Deployment Diagram

5.6 Database design

To producing a detailed data model of a database we have designed the following database design
diagram. it is a process to identify the relationships between placement choice, process placement,

89 | P a g e
registration of the student, ask question, download student data and login into the system .This logical
data model contains all the needed logical and physical design choices and physical storage
Parameters needed to generate a design in a Data Definition Language, which can then be used to create a
database. A fully attributed data model contains detailed attributes for each entity. It can be used to
describe many different parts of the design of an overall database system. Principally, and most correctly,
it can be thought of as the logical design of the database structures used to store the data. The following
database design diagram shows the relationships, attributes, primary and foreign key in placement database
contained tables:-

Figure 5.8:-Database Design

5.7 ERD design and Normalization

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.

90 | P a g e
 Figure 5.9:- Entity relationship diagram

5.7.1 Normalization
First Normal Form:

Tables are said to be in first normal form when:

 No single attribute (column) has multiple values.

Second Normal Form

 Each non-key attribute in a row does not depend on the entry in another key column.

91 | P a g e
 Student Registration table

Student Fname Mname Lname Sex Age

Reg_no

School table

school-id school-name Email password

Admin table

Admin-id Fname Mname email password

University table

Univ-id Univ-name email password

Third Normal Form:

Tables are said to be in third normal form when:
 The tables meet the criteria for second normal form.
 Each non-key attribute in a row does not depend on the entry in another key column.
 In our system the above table is in their third normal form so no need of normalizing.
5.8 Object diagram
An object diagram could be viewed as an instance of a class diagram. Object diagrams describe the static
structure of a system .at a particular time and they are used to test the accuracy of class diagrams. They can
be used to test class diagrams for accuracy. Each object is represented as a rectangle, which contains the
name of the object and its class underlined and separated by a colon. You can illustrate multiple objects as

92 | P a g e
one symbol if the attributes of the individual objects are not important. Links are instances of associations.
You can draw a link using the lines Used in class diagrams.

Figure 5.10:-Object Diagram

5.9 Persistence diagram

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

93 | P a g e
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 contains 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.
 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.

94 | P a g e
Figure 5.11:-Persistence modeling

95 | P a g e
5.10 User interface prototype (snap shoot)
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 are shown by Figure below.

Figure 5.12:- Home page for Web based Ethiopian Higher Education Student placement system

96 | P a g e
Figure 5.13: Ministry of education home page

Figure 5.14:-University home page

97 | P a g e
Figure 5.15:-Preparatory school home page

Figure 5.16:-Registering Field Choice for Student

98 | P a g e
Chapter Six: - System Implementation
6.1 Introduction
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.

6.2 Coding (sample code)

Sample source code for login

<?php

session_start(); include

'../admin/include/connection.php'; $email =

$_POST['email'];

$password = $_POST['password'];

$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 == 'moe') {

99 | P a g e
 $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';

if ($usertype == 'university') {

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

if (mysql_num_rows($un) > 0) {

$un1 = mysql_fetch_array($un);

$status = $un1['status']; if ($status ==

'0') {

$_SESSION['email'] = $email;

100 | P a g e
 $_SESSION['userId'] = $userId;

$_SESSION['name'] = $name; header("Location:

../university/index.php");

} else {

$de = 'The user account is deactivated';

}
}

if ($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']; if ($status ==

'0') {

$_SESSION['email'] = $email;

$_SESSION['userId'] = $userId; header("Location:

../regional/regional.php");

} else {

$de = 'The user account is deactivated';

}
101 | P a g e
 }

if ($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';

} else {

$err= "Your Email and password You enter did notmatch";

?>

102 | P a g e
<?php include

'../admin/include/connection.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) {

?>

<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 source code for Natural science field choice

103 | P a g e
<?php

session_start(); include '../admin/include/connection.php'; if

(isset($_SESSION['userId']) && isset($_SESSION['email'])) {

$email = $_SESSION['email'];

$userId = $_SESSION['userId'];

} else { header("Location:

../index.php");

?>

<?php include

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

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

$regno = $_POST["regno"];

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

field_natural"));

$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;

104 | P a g e
 $res=mysql_query("INSERT INTO choice_natural (regno, fieldId, choice) VALUES ('$regno',
$fieldId, $choice)");

} if($res){
$message= "You successfully Choose a field";

} else {

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

?>

6.3 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 its design and development. We
use different types of testing to test the system. The type’s testes we use are listed and described
below.

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.
System testing: - This involves testing the entire system for errors & bugs. This test is carried by
interfacing the hard ware & software components of the entire system that have been previously unit tested
& integration tested so we will test our system as a whole in this testing
Acceptance testing: - 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.

105 | P a g e
6.4 Features to be tested and not to be tested
In order to see the performance of the system and failed of the system another programmer or another
professional person must see every activity that our system done.in order to know well see one by one as
follows:-

6.4.1 Features to be tested

The features to be tested will be described according to the test types that will be done on the system.
The tests that are done are as follow:-
 Test Register Student
 Test login
 Test Manage account
 Test process placement
 Test Student data download
 Test register school
 Test register university
 Test register REB
 Test register choice
 Test upload HEI information

6.4.2 Features not to be tested

A feature not to be tested in our system is the following:-
 Buying a domain name from a company with its corresponding Ip Address for the server.
 Hosting the database from the server

6.4.3 Pass/ fail criteria

Placement is inevitable in trying to achieve a particular design goal. One best case we don’t get full
information because the source code is done by private company. The student doesn’t getting into
the system and creating account for the student is also fail because if other students know the
registration numbers they may be change it. Our system have not keep full special consideration for
disable student because there is no well-defined criteria there is no rule and regulation defined on
education policy.

106 | P a g e
In our system process placement is well done it pass system testing another thing also well done on the
register school, student, university and regional education bureau.

Our systems have the following fail criteria:-

 On the registration student if we are not full fill information the system will display another from to
fill from.
 When we enter a character instead of numeric value, the system will display imp-id should be
number.
 When we enter a numeric value instead of character, the system will display user name should be
character
6.5 Installation procedure
Since the project is a web based System, there is no need to install it on a particular machine rather it will
be hosted on a server.

6.6 Manual preparation (Documentation)

Some important items or points will be explained and implemented for the users while giving short
training when the system is deployed. There is no need of preparing full user manual because it is only
published (hosted) on a single machine that is server.

6.7 Support and service

To be Support and service the system should have data file materials. This materials includes
 Internet to check how the software used manipulating the project.
 We see web page interface that minister of education is used.
 School will tell about interface.
 We get documentation that is appearing in the minister of education on the internet.

6.8 Conclusion and Recommendation

6.8.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

107 | P a g e
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.

6.8.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 difficult for

researchers that is far apart from Addis Ababa, so the if the Ministry of
Education prepares well document criteria and distribute to Regional
Education bureau the researchers can get full information about the criteria
of Ministry of Education.

108 | P a g e
 6.9 References
[1] Fundamentals of Software Engineering [fourth edition].
[2] Fairley, Richard, Managing and Leading Software Project, IEEE Press, 2009.
[3] Humphrey. Watts S., Introduction to the personal Software Process, Addison Wesley,
Longman, 1997.
[4] Scot W.Ambler, The object Primer, 2nd Edition, 2001.
[5] Pankaj Jalote, An Integrated Approach to Software Engineering, Third Edition.
[6] Peter R. Hill, Practical Software Project Estimation: A Toolkit for Estimating Software.
[7] Object Oriented and Classical Software Engineering Dennis H.2008
[8] Object Oriented Software engineering text book
[9] www.NEAEA.com
[10] Detail Reference from Robe preparatory school

109 | P a g e
 6.10 Appendix
Appendix I
Sample question during requirement gathering:-
1. How the current system works?
2. Is it manual?
3. If it is manual what is its drawback?
4. If we do it computerized what is your option?
5. If you like the computerized one what it should include in order to make it manageable for
you?
6. How students choose Field?
7. How to get some information about place to student?
8. How placement coordinators calculate the placement?
9. What are the criteria to assign students to HEI?

Appendix II
Functional requirements: - describe the interactions between the system and its environment independent
of its implementation
Non-functional requirements: - describe user-visible aspects of the system that are not directly related with
the functional behavior of the system
System models: -describes the scenarios, use cases, object model, and dynamic models describing the
system.
Hardware: - is computer equipment. It includes all the component use to make the computer.

Software: - computer programs, instruction that make hardware work

System:-any collection of component element that work together to perform task.

State diagram: - is a diagram to describe the behavior of a system considering all the possible states of an
object when an event occurs.

Sequence diagrams: - show the interaction between participating objects in a given use case.

Activity diagram: - describes a system in terms of activities

Use case diagrams: - graphically depict system behavior (use cases).

110 | P a g e
111 | P a g e