WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS

Web Based Cost Sharing Management System for Ethiopian

Higher Education

BY

NAME ID

1. Yordanos Masresha 316/09

2. Tizita Docter 340/09
3. Yenesew mola 332/09

Project Advisor: Mr. Worku Muluye(MSc.)

Wolkite University, Wolkite, Ethiopia

January 3, 2021

WOLKITE UNIVERSITY
|P a g e
 COLLEGE OF COMPUTIING AND INFORMATICS
DEPARTMENT OF INFORMATION SYSTEMS
Web Based Cost Sharing Management System for Ethiopian
Higher Education

SUBMITED TO DEPARTMENT OF INFORMATION SYSTEMS

IN PARTAIL FULLFILMENT OF THE REQUIREMENT FOR THE
DEGREE OF BACHELOR OF SCIENCE IN INFORMATION
SYSTEMS

BY

NAME ID

1. Tizita Docter 316/09

2. Yordanos masresha 340/09
3. Yenesew mola 332/09

Project Advisor: Mr. Worku Muluye(MSc.)

Wolkite University, Wolkite, Ethiopia

January 3, 2021

DECLARATION
This is to declare that this project work which is done under the supervision of Mr. Worku
Muluye and having the title Cost Sharing Management system is the sole contribution of:
Tizita Docter

|P a g e
Yordanos Masresha

Yenesew Molla

No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and have been
cited properly. We will be responsible and liable for any consequence if violation of this
declaration is proven.

Date: January 3, 2021

Group Members:
Full Name Signature
Yordanos Masresha
____________________
Tizita Docter
____________________
Yenesew Molla
____________________

|P a g e
 APPROVAL FORM
This is to confirm that the project report entitled Cost Sharing System submitted to Wolkite
University, College of Computing and Informatics Department of Information Systems by:
Yordanos Masrehsa,Tizita Docter, Yenesew Molla is approved for submission.

----------------------------------------------- ---------------------------- ----------------------

Advisor Name Signature Date

----------------------------------------------- ----------------------------
----------------------
Department Head Name Signature Date

----------------------------------------------- ----------------------------
---------------------

Examiner 1 Name Signature Date

---------------------------------------- ----------------------------
-----------------

Examiner 2 Name Signature Date

----------------------------------------------- ----------------------------
-----------------

Examiner 3 Name Signature Date

|P a g e
Contents
DECLARATION.................................................................................................................................iii
APPROVAL FORM.............................................................................................................................iv
Acknowledgment...............................................................................................................................viii
List of Figures......................................................................................................................................ix
List of Tables.........................................................................................................................................x
List of Acronyms and Abbreviation.....................................................................................................xi
Abstracts..............................................................................................................................................xii
............................................................................................................................................................ xii
CHAPTER ONE..................................................................................................................................1
1. Introduction...................................................................................................................................1
1.1. Background of the Organization............................................................................................1
1.3. Objective of the Project..............................................................................................................2
1.3.1. General Objective................................................................................................................2
1.3.2. Specific Objective................................................................................................................2
1.4. Feasibility Analysis....................................................................................................................2
1.4.1 Technical Feasibility.............................................................................................................2
1.4.2. Operational feasibility..........................................................................................................3
1.4.3. Economic Feasibility...........................................................................................................3
1.5. Scope and Limitation..................................................................................................................3
1.5.1. Scope of the project.............................................................................................................3
1.5.2. Limitation of the Project......................................................................................................4
1.6. Significance of the project..........................................................................................................4
1.7. Beneficiary of the Project...........................................................................................................4
1.8. Methodology of the project.........................................................................................................4
1.8.1. Data collection Tools/Techniques........................................................................................4
1.8.2. System Analysis and Design................................................................................................5
1.8.4. System Testing Methodology..............................................................................................5
CHAPTER TWO.................................................................................................................................7
2. Description of the existing system.................................................................................................7
2.1. Introduction to the existing system.............................................................................................7
2.2. Users of Existing System............................................................................................................8
2.3 . Major Function of Existing System.....................................................................................9
2.4. Forms and other document of Existing System......................................................................9
2.5. Drawback of Existing System..............................................................................................10
2.6. Business Rule of Existing System........................................................................................10
|P a g e
CHAPTER THREE...........................................................................................................................12
3. Overview of Proposed System.....................................................................................................12
3.1. Functional Requirement............................................................................................................12
3.2. Non-functional requirement......................................................................................................13
3.2.1. User interface and Human factor.......................................................................................13
3.2.2. Hardware Consideration....................................................................................................13
3.2.3. Security Issue.....................................................................................................................13
3.2.4. Performance.......................................................................................................................13
3.2.5. Error Handling and Validation...........................................................................................13
3.2.6. Quality Issue......................................................................................................................14
3.2.7. Backup and recovery..........................................................................................................14
3.2.8. Physical Environment........................................................................................................14
3.2.9. Resource Issue...................................................................................................................14
3.2.10. Documentation.................................................................................................................14
CHAPTER FOUR.............................................................................................................................15
4. System Analysis..........................................................................................................................15
4.1. System Model...........................................................................................................................15
4.1.1. Use Case Model.................................................................................................................15
4.1.1.1. Use Case Diagram...........................................................................................................15
4.1.1.3. Use case scenario............................................................................................................24
4.2. Object Model............................................................................................................................25
4.2.1 Class Diagram.....................................................................................................................25
4.2.3. Data Dictionary..................................................................................................................26
4.3. Dynamic Model...................................................................................................................30
4.3.1. Sequence Diagram.......................................................................................................31
4.3.2. Activity Diagram.........................................................................................................38
4.3.3. State Chart Diagram.....................................................................................................44
CHAPTE FIVE..................................................................................................................................45
5. System Design.............................................................................................................................45
5.1. Design Goal..............................................................................................................................45
5.2. Proposed System Architecture..................................................................................................46
5.2.1. Subsystem Decomposition and Description.......................................................................47
5.2.3. Detail class diagram...........................................................................................................50
5.2.4. Persistence data Management............................................................................................51
5.2.5. Access control and security................................................................................................53
5.3. Packages..............................................................................................................................54
|P a g e
 5.4. Algorithm.............................................................................................................................55
5.5. User Interface.......................................................................................................................55
CHAPTER SIX 6. IMPLEMENTATION AND TESTING..............................................................58
6.1 Introduction...............................................................................................................................58
6.2 Implementation of the Database................................................................................................59
6.3 Implementation of the Class Diagram........................................................................................60
6.5 Configuration of Application Security.......................................................................................60
6.6 Implementation of User Interface..............................................................................................61
6.7 Testing.......................................................................................................................................61
6.7.1 Test Case................................................................................................................................61
6.7.1 Testing Tools and Environment..............................................................................................62
6.7.2 Unit Testing............................................................................................................................62
6.7.3 Integration Testing..................................................................................................................63
6.7.4 System Testing.......................................................................................................................63
CHAPTER SEVEN...........................................................................................................................63
7. CONCLUSION AND RECOMMENDATION...............................................................................63
7.1. CONCLUSION........................................................................................................................63
7.2. RECOMMENDATION............................................................................................................63
References...........................................................................................................................................64

|P a g e
 Acknowledgment
We would like to acknowledge those who help us in working this project. Before all we would
like to thank to our GOD he gives us strength and knowledge to do our project. Next we would
like to thank our advisor Mr. Worku Muluye. he helps us with his all heart and Employees of
Wolkite university registrar Mr. Tesfaye Munta and Mr. Abrham Assefa to give the required
information regarding to cost sharing Finally, we thank our instructors and friends in College of
computing and informatics and every person help us in different way.

|P a g e
 List of Figures
Figure 2. 1 Student cost sharing form............................................................................................17
Y

Figure 5. 1 Proposed System Architecture....................................................................................74

Figure 5. 2 Sub System Diagram...................................................................................................76
Figure 5. 3 Deployment Diagram..................................................................................................77
Figure 5. 4 Detail Class Diagram..................................................................................................78
Figure 5. 5 Persistent Data Management Diagram........................................................................79
Figure 5. 6 Package Diagram.........................................................................................................81
Figure 5. 7 user interface for login................................................................................................83
Figure 5. 8 user interface for register students..............................................................................84
Figure 5. 9 user interface for fill cost sharing................................................................................85
Figure 4. 1 General Use Case Diagram.........................................................................................27
Figure 4. 2 class diagram ..............................................................................................................46
Figure 4. 3 Sequence Diagram for Login......................................................................................56
Figure 4. 4 Sequence Diagram for fill cost sharing.......................................................................57
Figure 4. 5 Sequence Diagram for calculate cost share................................................................58
Figure 4. 6 Sequence Diagram for Create Account.......................................................................59
Figure 4. 7 Sequence Diagram for generate report........................................................................60
Figure 4. 8 Sequence diagram for update Account.......................................................................61
Figure 4. 9 sequence diagram for search.......................................................................................62
Figure 4. 10 sequence diagram for set cost share..........................................................................63
Figure 4. 11 Activity Diagram for login........................................................................................65
Figure 4. 12 Activity Diagram for create account.........................................................................66
Figure 4. 13 Activity Diagram for search result............................................................................67
Figure 4. 14 Activity Diagram for Fill Cost Sharing.....................................................................68
Figure 4. 15 Activity Diagram for set Cost sharing.......................................................................69
Figure 4. 16 State chart diagram for Manage Account..................................................................70

|P a g e
 List of Tables
Table 5. 1 Access control and security..........................................................................................77
Y

Table 4. 1 Use case description for Login.....................................................................................27

Table 4. 2 Use case description for Fill Cost share form...............................................................28
Table 4. 3 Use case descriptions for Calculate cost share.............................................................29
Table 4. 4 Use case descriptions for Approve cost share form.....................................................30
Table 4. 5 Use case description for Generate report......................................................................31
Table 4. 6 Use case description for Register.................................................................................32
Table 4. 7 Use case description for Send request..........................................................................33
Table 4. 8 Use case description for View notification...................................................................34
Table 4. 9 Use case description for Create Account......................................................................35
Table 4. 10 Use case description for Update Account...................................................................36
Table 4. 11 Use case description for Search information..............................................................37
Table 4. 12 Use Case description for Set cost share......................................................................38
Table 4. 13 Use case description for Manage College..................................................................39
Table 4. 14 Use case Description for Set deducted tax Amount...................................................41
Table 4. 15 Use case Description for Calculate Deducted tax......................................................42
Table 4. 16 Data Dictionary for Admin.........................................................................................46
Table 4. 17 Data Dictionary for Account......................................................................................46
Table 4. 18 Data Dictionary for University registrar officer.........................................................47
Table 4. 19 Data Dictionary for Student........................................................................................48
Table 4. 20 Data Dictionary for Cost Share..................................................................................49
Table 4. 21 Data Dictionary for cost share Service.......................................................................50
Table 4. 22 Data Dictionary for ERCA officer .............................................................................51
Table 4. 23 Data Dictionary for Employer officer........................................................................52
Table 4. 24 Data Dictionary for Beneficiary Employee................................................................53

|P a g e
 List of Acronyms and Abbreviation
BR Business rule

CIMS Cost sharing information management system

CD Compact Disc

CSS Cascading Sheet Style

DB Database

DBMS Database Management System

DVD Digital Versatile Disc

ERCA Ethiopian Revenue and custom Authority

FK Foreign Key

HTTP Hyper Text Transfer Protocol

HTML Hyper Text Markup Language

ID Identification Number

MOE Ministry Of Education

OOA Object Oriented Analysis

OOD Object Oriented Design

PC Personal Computer

PK Primary Key

PHP Hypertext Preprocessor

UI User interface

UML Unified Modeling Language

|P a g e
 Abstracts
Cost sharing is defined in Ethiopia as a scheme by which beneficiaries of public higher
education institutions and the government share the cost incurred for the purpose of education
and other service. At the starting day of education higher education students make a cost
sharing agreement through university registrar. ERCA and university share this agreement
and store in file cabinet. Finally, the beneficiary repays the graduate tax through service, cash
or tax. The existing system work manually. Due to the existing system works manually it has
its own drawback, Difficult to handle students cost share file, difficult to generate report and
extracting useful information. Based on this scenario we have developed a web based cost
sharing application to manage higher education cost sharing system. This System should
allow to fills cost sharing, generating report, to send requests to approve requests, to reject
requests. This system also a user friendly, ensure security issue, have a best performance.

CHAPTER ONE
1. Introduction
Nowadays it is better if every activity is done using new technology in order to fulfill the
need of human being, organization, enterprise. Technology can add a new knowledge on the
existing one; can make easy our day today activities by providing different way of work
procedure. So web based cost sharing management system that we will develop is helpful
application to enhance the business activity of Ethiopian revenue and custom authority and
also for Ethiopian higher education to manage properly students cost share file. This system
will can avoid the problem that associated with the existing manual system.

1.1. Background of the Organization

Higher education participation in Ethiopia is very low (about 1.5 per cent) and is the major
source of the critical shortage of educated and skilled human resource. The higher education
system in Ethiopia is moving away from exclusive and dismally low enrolments towards
increasing participation. To expand access, to redress inequitable subsidies by taxpayers to a
small proportion of the age cohort and to diversify revenue the introduction of cost sharing is
necessitated to supplement public finance. Cost sharing serves as an alternative non‐
governmental source supplementing revenue opening more opportunities and making
students responsible citizens and customers. In the expanding system, covering the full tuition
|P a g e
and food and room cost for a small proportion of the age cohort from the taxpayers’ money is
inappropriate and inequitable distribution of resources.

A modified model of the Australian type Graduate Tax, as a more attractive, simple and
manageable scheme is adopted in the Ethiopian higher education landscape. The scheme is
expected to ensure equitable access to students of any background, as there is no need to
stipulate income of parents to arrive at the repayment amounts. Immediate removal of all
subsidies to food and room, calculating appropriate tuition fees and costs, provision of every
citizen a tax identification number and decentralization and strengthening the tax collection
and information system are essential for successful implementation of cost sharing in
Ethiopia.

1.2. Statement of the Problem

File handling problem: This problem occurs in Ethiopian revenue and custom authority
(ERCA) and also in Ethiopian higher education, difficult to handle and store students cost
share file since the file is growth year to year. Difficult to extract use full information. Data
inconsistency: Students are not willing to fill out the same biography on each cost share
agreement form at each year. Processing and calculating exact unpaid cost problem It takes
wastage of resource because it needs large space to store all documents Searching cost share
file problem: long time taking searching specific file of students: for example, when the
student dean wants to extract the students based on service that they demand (in cash or in
kind). Data duplication: the same data gets repeated over and over again. During move the
cost sharing form from every college registrar to main registrar and also from every campus
to ERCA may occur students’ data loses

1.3. Objective of the Project

1.3.1. General Objective

The general objective of the project will be developing a web-based cost sharing management
system for Ethiopian Higher Education.

1.3.2. Specific Objective

In order to achieve the general objective these specific objectives are needed.
|P a g e
  Construct an efficient database that store Beneficiaries cost share file
 To capable easily and quickly extract important information
 To design user friendly and attractive user interface
 System analysis and object design
 Implement the proposed system
 To test the system

1.4. Feasibility Analysis

1.4.1 Technical Feasibility
The proposed system can be easily maintained and repaired without high experts or technical
assistants, because the system will develop by familiar programming language or framework.
The project team members have learned programming languages that required for the
successful completion of the project such as java script, CSS, HTML, PHP, and MySQL, So
that the project will be technically feasible.

1.4.2. Operational feasibility

The system performs all operations to achieve the specified objective. It will be user friendly
and interactive with the environment and also the system will not have any difficulty or
procedures to perform the operation of the system.

1.4.3. Economic Feasibility

The system will be economically feasible it can minimize the cost that spent for manual
work. Let analyze the manual cots, there is around 46 higher educations in Ethiopia and in
each university there are many students which fill the cost sharing agreement in each year,
So, too sore their data need a huge amount of paper and also there is other material cost,
ERCA also need a large file cabinet to handle and store these students cost share file the point
is here these costs spent with every 1, 2, 3, ...Years, it will be a high cost for future. But if the
system is automated it is developed once, the cost of server, computers, network installation
and other costs spent once then the system give services through the life time of the business,
so this project is economically feasible.

|P a g e
1.5. Scope and Limitation
1.5.1. Scope of the project
This project focuses on the development and implementation of web application based on
cost sharing management system for Ethiopian Higher Education which solve the existing
problem regarding to management of the Ethiopian public universities students cost share.
The general Scopes of the system which is performed by different actors are:

 This system allow the students to fill their cost sharing form
 This system allows making record, updating, deleting, and creating based on
privileges.
 Generate report
 Send and view notifications
 Student’s send request about their original document
 This system should allow approved or disproved the request.
 Update the student cost share file if it is paid.

1.5.2. Limitation of the Project

 Cannot control the mobility of beneficiaries outside of the country
 Cannot do payment

1.6. Significance of the project

This project significant to Saving loss of document of student, having a central database that
sore and share student cost share file, Speed up the operation, reduce the organization cost
that spent in every year, add new knowledge because it is the result of technology, as a whole
this project is significant for give effective and efficient services.

1.7. Beneficiary of the Project

 For ERCA: this system solves the file handling problem, handle students cost share
file easily and also accessing the cost share file at each time.
 For Ethiopian public university registrar: This system reduce the resource like paper,
easily extraction of use full information, create well organized cost share data and
handle student cost share file easily..
 For students: Allow to fill the cost share form easily.

|P a g e
1.8. Methodology of the project
1.8.1. Data collection Tools/Techniques
We have to know that what the problem of students is, what is the problem of EARCA, what
is the problem of every college and departments registrar; totally we have to know the
problem of the existing system and how to solve it, in order to do this, we expected to gather
requirements by different data collection method:

 Interview: -Wolkite University registrar office workers and also students by

preparing different question.
 Observation: to get additional information without awareness of the workers by
exists in organization actual place we observe the operation to gather information.
 Document analysis: To get more information that help us to develop this project we
used documents like form and working guideline.

1.8.2. System Analysis and Design

We use object-oriented system analysis to analyze our proposed system. This technique has
two phases those are:-
 Object oriented analysis (OOA)[ CITATION pre04 \l 1033 ]: - During this phase our team
use to model the function of the system (use case modeling), find and identify the
business objects, organize the objects and identify the relationship between them and
finally model the behavior of the objects in detail.
 Object oriented design (OOD): - During this phase use Edraw max software to refine
the use case model and those for designing the class, sequence, collaboration, activity,
state diagram and to model object interactions and behavior that support the use case
scenario.

1.8.3. System Development Model

System development method is a frame work that is used to structure, plan and control the
process of developing a system so to develop this project we have selected iterative system
development method. The reason why we select this model: it is unusual to design a
complete project once. Therefore, to design this project we will required to review and
redesign in each phase iteratively to meet user requirements.

|P a g e
1.8.4. System Testing Methodology
Before and after the completion of the system we test the system we do, before deployment
of the system. It helps to make sure that the system meets the require goal. So we used unit
testing, integration testing and acceptance testing.

 Unit testing: tested by our team members

 Ensure how the sub procedures or functions are called correctly.
 Ensure if the correct output is produced for different inputs.
 Ensure the efficiency of the code with respect to the memory and CPU time.
 Integration testing: test how the new module integrate or work together with the
existing one to achieve the goal of the system.
 Acceptance testing beta testing of the system done by the end user in this level of
testing the system tested by the user who checks the system what the system looks
like by their own testing mechanism. This is the final testing in the system
development.

1.8.5. Development Tools and Technologies

 Frontend technologies: - HTML, CSS, and java script helps to design client side
 Backend technologies: -
 MYSQL DBMS for managing database it is a popular, free and open source
database management system.
 PHP for server side coding: The reason why we choose PHP it is object-
oriented, free, and compatible with many platforms, compatible with many
DBMS and much secured scripting language.
 Documentation and modeling tools or software tools
 Edrawmax: for designing UML diagrams.
 Text editor: a software tool sublime text, notepad++ for typing the code
 Microsoft word 2016: to prepare documentation
 Hardware tool
 Personal computer (PC): almost all tasks of this project will performed on
computer

1.9. Document Organization

This project consists of seven chapters.
|P a g e
Chapter one discusses about introduction, background of the existing system. Statement of
the problem, objective of the project (both general and specific objective), functionality, non-
functionality, significance of the project, scope of the project, limitation of the project,
delimitation, feasibility, Document Organization and methodology of the project is also
included.
Chapter two deals about description of the current system, major function of the existing
system, user of the existing system, organization structure and work flow the of the existing
system, strength and weakness existing system, forms and other documents of the existing
system follow, Bottlenecks of the existing system, and, expected outcome of our project after
finishing.
Chapter three deals about overview of the proposed system, business rule, functional
requirement, process requirement, input requirement, output requirement, storage
requirement, and nonfunctional requirement. Determine security and safety procedures for
our project.
Chapter four deals about we define system analysis and design for our projects include
scenarios, system model, user class and characteristics (actor specification), use case diagram
(system use case diagram and use case description), class diagram, dynamic model of our
system and this includes sequence diagram, activity diagram, Data Dictionary or Mapping,
and Normalization.
Chapter five covers System Overview, Design Considerations, Design Goals, Design Trade-
offs, Architecture of the proposed System, Sub-system Decomposition, Hardware/Software
mapping (Deployment design), Persistent data management, Class interfaces, and User
interface design.

CHAPTER TWO
2. Description of the existing system
2.1. Introduction to the existing system

The current student cost sharing management in all Ethiopian public universities and ERCA
governmental organization is manually based management system. This system mainly focus
on the students fill out their biography and cost share file per each year, after that the student
dean search a file to identify those students who want cash payment in order to prepare
amount of cash with respect to the students number that they want share the cost in cash.

|P a g e
Registrar or cost share office approve the form which fill by students and store the student
cost share file by using file cabinet and give one copy for students per each year. The
registrar or cost share office of each Ethiopian public university also sent the overall
graduated students cost share file including the total calculated unpaid cost of each graduated
students to ERCA. ERCA stores them students cost share file which sent from all Ethiopian
public university by using file cabinet. When a beneficiary completely repays their cost share
ERCA prepare a letter that allow to take their original document and the university registrar
give the original document to beneficiary by checking the letter that sent from ERCA.

2.2. Users of Existing System

Active users that use the system actively are:

 Ethiopian public university registrar (cost share office)

 Providing cost share form for students
 Breakdown the cost share form for students per each year
 Collecting the form while students are registered
 Putting signature while students return the cost share on submitted date
 Delivering one cost form for students, one form to ERCA and the left one
store using file cabinet.
 Finally preparing the total unpaid cost by each graduated students and
report to ERCA governmental organization manually.
 Give the original document for students whose completely pay the cost
share

 Students
 Receiving the cost share form from registrar and fill out their biography and
the cost share for current academic year.
 Providing their photo per each year.
 Finally return back the cost share form to registrar or cost share office.
 After complete their education repay the graduate tax in service or in cash
 Finally take their original document from learned university, if they are fully
pay the cost share
 Student dean
 Identify the students those who want the benefit in cash.
|P a g e
  ERCA
 Receiving the cost share of each student with in the total unpaid cost of
graduated students from all Ethiopian public university registrar or cost share
office.
 Store the cost share file with in file cabinet.
 Collect the graduate tax.
 Allow for beneficiary to get their original document if they are fully repaid the
cost share.
 Employer
 Request a copy of the contractual agreement between the beneficiary and the
higher education institution and a written document specifying the amount to
be deducted from a monthly salary.
 Forward to ERCA list of beneficiaries employed
2.3. Major Function of Existing System

The major function of cost sharing is university students make an agreement per each year to
accomplish their academic education process until they will be graduated and after that
students repay the cost share through service or in cash. In general: -

 Each university registrar or cost share office distribute a higher

education cost sharing regulation beneficiaries agreement form for
each students
 Students fill an agreement and put their photo on it then back to
registrar
 registrar approved an agreement which fill by each students
 Universities student dean identifies which student is requiring the
service in cash.
 Send the overall graduated students cost share file including their
unpaid cost to ERCA.
 Finally, beneficiaries get their original document after paid the cost
share.
2.4. Forms and other document of Existing System

|P a g e
The higher education cost sharing regulation beneficiaries agreement form which is prepared
by ministry of education and distribute for all Ethiopian higher education institution to make
an agreement with students starting from their first academic year up to the last academic
year of education. Students make this agreement per each year.

Figure 2. Student cost sharing form

2.5. Drawback of Existing System

Due to the existing system works manually it has its own drawback. The management of the
students cost share file needs much material like paper and other material. These materials
expected from Ethiopian public university and also from ERCA to manage those students
cost share file, So that those organization spent much more cost for needed material this is
economically very infeasible. Difficult to handle students cost share file , difficult to generate
report and extracting useful information, students data lose occur during move from one place
to another, make an error during calculating unpaid cost these problem make the Ethiopian
public universities and ERCA to lead a poor management system on cost share of the student.
|P a g e
 2.6. Business Rule of Existing System

BR1 All beneficiaries of public institutions of higher learning shall share full cots related
with boarding and a minimum 15% of tuition related cost.

BR2 The beneficiary shall pursue his education after entering a written contract agreement
with the respective institution.

BR3: The beneficiary must have an identification that identifies the particular higher
education student.

BR4: The beneficiary shall start paying the amount within six months after graduation if
earning income, or within a maximum of one year after graduation.

BR5: Completion of repayment of amount owed by beneficiaries shall, depending on the type
and duration of program, not exceed 15 years.

BR6: Only an Ethiopian national is eligible for pursuing his higher education or training
upon the contractual commitment for future payment, in cash or in service of his share of the
cost in the form of graduated tax.

BR7: follow up the implementation of the cost sharing system

BR8: Notify the beneficiary, at the beginning of the academic year, the appropriate amount
of cost the beneficiary has to share, and keep record of all necessary data

BR9: Provide the beneficiary with documents stating the amounts that are to be paid by
beneficiaries.

BR10: Manage properly the beneficiary file that sends from each Ethiopian public
university.

BR11: To follow up, supervise and collect the total amount for beneficiary who fully
discharges his/her obligation

BR12: To request a copy of the contractual agreement entered between the beneficiary and
the institution and a written document specifying the amount to be deducted from a monthly
salary.

|P a g e
 CHAPTER THREE
3. Overview of Proposed System

The new system is a web based application that capable all Ethiopian public universities
(EPUS) cost share office (registrar) and ERCA share the same database (DB). The proposed
system includes all functionality of the current system and side by side it works provides
useful information to ERCA and Ethiopian public universities. Mainly concern with how the
students fill out and registrar or cost share office manage cost share and how ERCA access
the overall Ethiopian public university students cost share file and generating report from
each university through internet. Generally, the proposed system: -

 Improving method in managing the Ethiopian university students cost

share
 Make easy in searching and fill outing cost share file
 Registrar can set the cost share by each year
 Cost share office or registrar can store accurate and non-redundant of
students cost share file
 Cost share office or registrar and ERCA can share the same database
 Each Ethiopian public university can deliver the student’s biography with
unpaid cost to ERCA without losing any student cost share file.

3.1. Functional Requirement

Functional system requirements should describe the system services in detail. This proposed
system functional requirements generally are:-

Login: The system should allow all users to login.

Manage Account: The administrator can Create Account, Delete Account to All users.
Fill cost share: The system should allow for students to fill their cost share
Calculate Cost: Calculating the cost that spent for bedding, food and tuition with
respective percentage.
Search: For all authorized user the system allows to search or extract important
information.
Notify: the system notifies the user if new messages are entering into the system.
|P a g e
 Generate report: the system allows universities registrar or cost share office and also
ERCA to generate report.
Register: the system should allow employer to register employees.
Send request: for beneficiary this system should allow to request their original
document.
View Notification: the system should allow viewing different notification.
Approved request: this system should allow approving requests.
Update: The system should allow updating the beneficiaries cost share file that fully
paid.
Logout: All user logout from the system after accomplish their task.

3.2. Non-functional requirement

3.2.1. User interface and Human factor

In order to make the proposed system more attractive, user friendly and also easy to use we
use different front end technologies like JavaScript, CSS, HTM and Bootstrap. Due to this we
can minimize the training cost.

3.2.2. Hardware Consideration

Because of this system is design and implement by PHP server-side scripting Language that
support platform independent, the proposed system is compatible for any hardware; it can run
on any platform.

3.2.3. Security Issue

This proposed system provides a high level of security by authenticate authorized user and
encrypt the user’s username and password through MD5 encryption to prevent the readability
of username and password in the database. The system also provides restriction in using
system functionality and information access by its user.

3.2.4. Performance
Because of this system developed by using PHP server side scripting language which can
increase a system performance and also MySQL query optimization using indexes the query
response time is very fast.

3.2.5. Error Handling and Validation

When the users of the system interact with the system error may appear. To control these
inaccuracies, the system makes validation and display different messages to the user. The

|P a g e
system also handle exceptions like input mismatch exception such as interchanging numeric
and characters, username and password mismatch by displaying alerts.

3.2.6. Quality Issue

In terms of reliability system shall provide reliable and accurate information which help in
increasing efficiency of the process and for ease of management decision. There could be
multiple parameters to meet for achieving reliability which depends on server infrastructure,
database implementation tool. In terms of availability this system able to be accessed by its
end users and behaves as expected when it is accessed. In terms robustness this system has an
ability of tolerating error that may affect the system functionality.

3.2.7. Backup and recovery

To reduce data loss and other risk there we use a frequent and full back up mechanism to
avoid any information loss using copy of the system to restore when hardware and software
failure is occur. In addition to this we use different storage devices like Hard Disk, CD, and
DVD to duplicate the data.

3.2.8. Physical Environment

This web-based cost sharing management system deployed for Ministry of Ethiopian Higher
Education.

3.2.9. Resource Issue

As our system is a web-based application it should use less resource.

3.2.10. Documentation
The proposed system provides required full documentation, help contents and tips to allow
further maintainability and to support and guide user how to use the system. The system
documentation will provide information about how to use it and all the essential information
about the system.

|P a g e
 CHAPTER FOUR
4. System Analysis
4.1. System Model

A system model[ CITATION HHi19 \l 1033 ] is composed of a use case diagram and accompanying
documentation describing the use cases, actors and associations. It helps to analysts to
understand the functionality of the system and models are used to communicate with the
customer.

4.1.1. Use Case Model

The Use Case Model[ CITATION HHi19 \l 1033 ] describes the proposed functionality of the new
system. A Use Case represents a discrete unit of interaction between a user (human or
machine) and the system. Use Cases are typically related to 'actors'. An actor is a human or
machine entity that interacts with the system to perform meaningful work.

Actors

 Ministry of education (MOE)

 University_registrar
 ERCA
 Student

4.1.1.1. Use Case Diagram

Use case diagrams[ CITATION HHi19 \l 1033 ] are valuable for visualizing the functional
requirements of a system that will translate into design choices and development priorities.
They also help identify any internal or external factors that may influence the system and
should be taken into consideration. They provide a good high level analysis from outside the
system. Use case diagrams specify how the system interacts with actors without worrying
about the details of how that functionality is implemented.

|P a g e
Figure 4. General Use Case Diagram

4.1.1.2. Use Case Description

A use case description[ CITATION Obj19 \l 1033 ] is a written description of how user will perform
tasks on the system.it out lines, from a user’s point of view, a system behavior as it responds
to a request. Each use case is represented as a sequence of simple steps, beginning with a
user’s goal and ending when that goal is fulfilled.

Table 4. 1 Use case description for Login.

Use case Name Login

Identifier UCID-01
Participating Actor All Actor
Pre-condition The user must have a username and password
Basic Course of Action
Step 1. The user open the home page
Step 2. The user click a login link

|P a g e
 Step 3 The system displays the login form
Step 4. The user inputs his/her username,
password and role
Step 5. The user click login Button
Step 6. The controller validate the input
Step 7. The system verifies that the user is
authorized to login into the system
Step 8. The user login to the system and
display the user page
Alternative Course of action If the entered username, password and role
not matched the system display re-enter and
the user go to Step 4
Post-Condition The user login into the system and do the
allowed operation based on his/her privilege.
Table 4. 2 Use case description for Fill Cost share form

Use case Name Fill Cost share form

Identifier UCID-02
Participating Actor Student
Pre-condition The actor should activate the system and login
to the system
Basic Course of Action
Step 1. The student login into the system
Step 2. The system display the student page
Step 3 The student click fill cost sharing link
Step 4. The system display cost sharing form
page
Step 5. The student fill cost sharing form
Step 6. The student click submit button
Step 7. The system validate user input
Step 8. The use case ends and information is
recorded into the database
Alternative Course of action If the user entered invalid input the system
displays please input valid data and the user
go to step 5
Post-Condition The user have fill the cost sharing form
Table 4. 3 Use case descriptions for Calculate cost share.

|P a g e
Use case Name Calculate cost share
Identifier UCID-03
Participating Actor University Registrar
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The user login to the system
Step 2. The user clicks on calculate cost share
link
Step 3 The system displays cost share
calculate form
Step 4. The user fill amount of expense
Step 5. The user click calculate button
Step 6. The system validate the user input
Step 7. The use case ends and the system
calculate the cost share and recorded into the
database.
Alternative Course of action If the user entered invalid input the system
displays please input valid data and the user
go to step 4
Post-Condition The annual cost share amount have calculated

Table 4. 4 Use case descriptions for Approve request.

Use case Name Approve request

Identifier UCID-04
Participating Actor University Registrar, Employer , ERCA
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The user login to the system
Step 2. The system displays user page
Step 3 The user click Approved link
Step 4. The system displays the request
approval form
Step 5 The user click the approved button
Step 6. The system validates the process and
|P a g e
 display successfully approved message.
Alternative Course of action If the user entered invalid input the system
displays please input valid data and the user
go to step 4
Post-Condition Approve and save data to the store database

Table 4. 5 Use case description for Generate report.

Use case Name Generate report

Identifier UCID-05
Participating Actor University Registrar, Employer, ERCA
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The user login to the system
Step 2. The system displays user page
Step 3 The user click generate report link
Step 4. The system displays the generate
report form
Step 5. The user fill the required information
Step 6. The user clicks on generate report
button
Step 7. The system validate the filled report
Step 8. The system display successfully
generated.
Alternative Course of action If the user entered invalid input the system
displays please input valid data and the user
go to step 5
Post-Condition The report is generated

Table 4. 6 Use case description for Register.

Use case Name Register

Identifier UCID-06
Participating Actor University registrar, employer
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The user login to the system
|P a g e
 Step 2. The system displays user page
Step 3 The user click register link
Step 4. The system displays the registration
page
Step 5. The user fill the required information
Step 6. The user click the registered button
Step 7. The system validates the user input.
Step 8. The use case ends when the filled
information is recorded into the database.
Alternative Course of action If the user entered invalid input the system
displays please input valid data and the user
go to step 5
Post-Condition The User is registered into the system

Table 4. 7 Use case description for Send request.

Use case Name Send request

Identifier UCID-07
Participating Actor Beneficiary employee
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The user login to the system
Step 2. The system displays user page
Step 3 The user click on request link
Step 4. The system displays the request form
Step 5. The user fill the form and click
request Button
Step 6. The system validate the filled request
information
Step 7. The system display successfully
requested message
Step 8. The user request register on the
system database
Alternative Course of action If the user entered invalid input the system
displays error message and the user go to step

|P a g e
 5
Post-Condition The request is successfully send

Table 4. 8 Use case description for View notification.

Use case Name view notification

Identifier UCID-08
Participating Actor Student
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The user login to the system
Step 2. The system displays user page
Step 3 The user click notification link
Step 4. The system displays the message sent
Step 5. Use case end
Alternative Course of action If the user enter invalid input the system
displays error message and the user go to step
3
Post-Condition New Notification is displayed

Table 4. 9 Use case description for Create Account.

Use case Name Create Account

Identifier UCID-09
Participating Actor Admin
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The Admin login to the system
Step 2. The system displays create account
page
Step 3 The system displays drop down option
links
Step 4. The Admin selects ‘Add new’ from
listed links
Step 5. The system displays the user interface
Step 6. The Admin fill all information on the

|P a g e
 form
Step 7. The Admin clicks the Create Button
Step 8. The system Validate the filled
information.
Step 9. The use case ends and the filled
information are recorded on the database.
Alternative Course of action If the user input is invalid the system displays
error message and the user go to step 6
Post-Condition The new account is created.
Table 4. 10 Use case description for Update Account.

Use case Name Update Account

Identifier UCID-10
Participating Actor All Authorized user
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The actor clicks on update Account
Button
Step 2. The system displays Update account
page
Step 3. The user enter Account key to search
the Account
Step 4. The system search result accurate to
the key and display
Step 5. The actor edit information and click
save
Step 6. The system displays successfully done
message.
Step 7. The use case ends.
Alternative Course of action If the user input is invalid the system displays
error message and the user go to step 3
Post-Condition The account updated successfully.

Table 4. 11 Use case description for Search information.

Use case Name Search information

Identifier UCID-11

|P a g e
Participating Actor ERCA. University registrar, Employer
Pre-condition The user must login into the system(UCID-
01)
Basic Course of Action
Step 1. The actor clicks on search button
Step 2. The system displays the search page
Step 3 user choose search result type and
write key for search result and click search
Step 4. The system search result accurate to
the key and display
Step 5. The use case ends.
Alternative Course of action If the search result is not found the system
displays the result is not found and the actor is
go to step 1 on basic course of action.
Post-Condition Search is done successfully.

4.1.1.3. Use case scenario

The following describes scenario of how the user use the systems to perform operations.

Scenario name: login

Participant actor: All users
1. The user click a login link

2. The system displays the login form

3. The user inputs his/her username, password and role

4. The user click login Button

5. The system validate the input

6. The user login to the system and display the user page

Extension

Incorrect username and password

Resume at step 5 of basic flow

Scenario name: fill cost share

|P a g e
Actor: student

1 The user click fills cost sharing link

2 The system displays the form
3 The user fill the cost sharing
4 The user click submit button
5 The system validate the input
6 The user fill the cost sharing successfully and the input data store in database
Extension
Invalid cost sharing information
Resume at step 5 of basic flow

4.2. Object Model

The object model[ CITATION Obj19 \l 1033 ] visualizes the elements in a software application in
terms of objects. An object is a real-world element in an object-oriented environment that
may have a physical or conceptual existence. Each object has identity that distinguishes it
from other objects in the system, state that determines the properties of objects as well as the
values of the properties that the object holds, behavior that represents externally visible
activities performed by an object in terms of changes in its state.

4.2.1 Class Diagram

The class diagram[ CITATION Obj19 \l 1033 ] is the main building block of object-
oriented modeling. It is used for general conceptual modeling of the structure of the
application, and for detailed modeling translating the models into programming code. Class
diagrams can also be used for data modeling. The classes in a class diagram represent both
the main elements, interactions in the application, and the classes to be programmed.

|P a g e
Figure 4. 1 class diagram for CIMS

4.2.3. Data Dictionary

Table 4. 12 Data Dictionary for Admin

Entity Attribute Description Data Data size Constraint

type
Admin Adminid Identification Varchar 10 Primary
number of key
Amin
Fname First name of Varchar 20 Not Null
Admin
Lname Admin last Varchar 20 Not Null
Name
|P a g e
 Address Admin Varchar 20 Not Null
address
Email Admin email Varchar 20 Not Null
PhoneNumber Admin int 10 Unique
phonenumbe
r

Table 4. 13 Data Dictionary for Account

Entity Attribute Description Data Data size constraint

type
Account Acid Identification Varchar 10 Primary
number of key
account
Username Username of Varchar 20 Not Null
accountholder
password Credential Varchar 30 Unique
information
Role Role of user Varchar 20 Not Null

Table 4. 14 Data Dictionary for University registrar officer

Entity Name Attribute Description Data Data Constraint

type Size
University_registra UniId Identification Varcha 20 Primary
r of universities r Key
UniName Name of the Varcha 20 Not NULL
university r
Responsible_offic The Varcha 20 Not NULL
e representative r
Of cost share
office
Rfname First name of Varcha 20 Not NULL
the r
representative
Rlname Last name the Varcha 20 Not NULL
representative r
EmailAddress Representative Varcha 20 Not NULL

|P a g e
 Email r
Phonenumber Representative varchar 10 Unique
phonenumber

Table 4. 15 Data Dictionary for Student

Entity Attribute Description Data Data Constraint

type Size
Student Stuid Identification Varcha 10 Primary
of students r key
Fname First name of Varcha 20 Not null
r
the student
Lname The student Varcha 20 Not null
r
last name
Gender The gender Varcha 5 Not null
r
of student
University University of Varcha 20 NotNull
r
student
College College of Varcha 20 Not Null
r
student
Department Department Varcha 20 Not Null
r
of student
Email Email of varchar 20 Null
student
PhoneNubmer phonenumbe varchar 10 Unique
r of student
Address Address of varchar 20 Not Null
student

Table 4. 16 Data Dictionary for ERCA Officer

Entit Attribute Description Data Data Size Constrai

y Type nt
ERC Id Identification of Varchar 10 Primary
A ERCA Key
Location The Location that the Varchar 20 Not Null
ERCA exists
Representativ The representative Varchar 20 Not
NULL
e_office Of cost share office
Rfname First name of the Varchar 20 Not
|P a g e
 representative NULL
Rlname Last name the Varchar 20 Not
NULL
representative
EmailAddress Representative Email Varchar 20 Not
NULL
Phonenumber Representative phone Int 10 Unique
number

4.3. Dynamic Model

The dynamic model[ CITATION Dyn14 \l 1033 ] shows the status of the object and the operations
performed on the occurrences of events and the subsequent changes in states. The state of the
object as result of the changes is shown in the object model. The main concepts of dynamic
model are State, which is the situation at particular condition during the lifetime of an object,
Transition: a change in the state, Action: an uninterrupted and atomic computation that occurs
due to some event and concurrency of transitions.

4.3.1. Sequence Diagram

A sequence diagram[ CITATION Dyn14 \l 1033 ] shows the sequence of interactions that
take place during a particular use case or use case instance. They are interaction diagrams
that detail how operations are carried out. They capture the interaction between objects in
the context of collaboration. Sequence Diagrams are time focus and they show the order of
the interaction visually by using the vertical axis of the diagram to represent time what
messages are sent and when. For this system we design some sequence diagrams for some
use cases that can identified the sequence of interaction.

|P a g e
Figure 4. 2 Sequence Diagram for Login

|P a g e
Figure 4. 3 Sequence Diagram for fill cost sharing

|P a g e
Figure 4. 4 Sequence Diagram for calculate cost share

|P a g e
Figure 4. 5 Sequence Diagram for Create Account

|P a g e
Figure 4. 6 Sequence Diagram for generate report

|P a g e
Figure 4. 7 Sequence diagram for update Account

|P a g e
Figure 4. 8 sequence diagram for search

4.3.2. Activity Diagram

An activity diagram[ CITATION Dyn14 \l 1033 ] show the activities involved in a process or in data
processing. We use activity diagram to illustrate the flow of control in a system and refer to a
steps involved in execution of use case. We depict work flows visually using an activity
diagram.

|P a g e
Figure 4. 11 Activity Diagram for login

|P a g e
Figure 4. 12 Activity Diagram for create account

|P a g e
Figure 4. 13 Activity Diagram for search result

|P a g e
Figure 4. 14 Activity Diagram for Fill Cost Sharing

|P a g e
Figure 4. 15 Activity Diagram for set Cost sharing

4.3.3. State Chart Diagram

|P a g e
State chart diagram[ CITATION Dyn14 \l 1033 ] 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. The most important purpose of State chart diagram is to model lifetime of an object from
creation to termination.

Figure 4. 9 State chart diagram for Manage Account

|P a g e
 CHAPTE FIVE

5. System Design
5.1. Design Goal
Design goal primarily emerged from nonfunctional requirement of the system and the
objectives of the design goal are to model a system with high quality that should achieved,
and addressed during the design of the system. The designer creates the nature of the design
and it is more important for the programmer to implement a high quality and error free
system.
5.1.1 Performance
The system should meet the following performance criteria’s; Response time: The speed
imposed on the system. The system should responsive maximum number of tasks with
minimum times; Throughput: number of tasks accomplished in a fixed period of times;
Memory: memory space available for speed optimizations should use efficiently. These
performance issues should have to be meeting in our system.

5.1.2 Dependability
The cost sharing management system should achieve the following dependability
characteristics in order to resist crash and be available and reliable.

Robustness: Since the system is a web based system that mainly uses a menu driven entry
there wouldn’t be an input problem by the user side. But for the server side there might be an
error during the process of entering a data. In this time the system will provide an error page
and the system will continue without failure or crush.

Security: the system should be secured, i.e., not allow unauthorized users to access the
database system.

Reliability: the information provided by the system is as reliable as it is presented on the web
page interface, and this is maintained by the persistent database.

5.1.3 Maintenance
|P a g e
In time of failure or need modification the system need to be maintained. To be maintainable
the system should meet the following maintenance criteria

Extensibility: if it is needed to add new functionality to the system, this must be achieved by
only making a separate page and integrate this page with the existing system.

Modifiability: if in the system, some functionality requires to be modified, this modification

must be done specifically to that function or page without affecting the overall system
organization.

5.1.4 Priorities of design goal

Priorities of design goal are a design goal which should be given priority when we compare
one design goal of the system with the other we have putted the priority of the system design
goal.

Security Vs Performance

Security is the degree of the system to be hard for accessing of unauthorized user and
performance is the quality of the system to do what it should do. System with high
performance of processing and performing but with less security control are exposed to
vulnerabilities and different attacks.so we select security factor in case of our system should
be secured and only be accessible by authorized users.

5.2. Proposed System Architecture

To achieve the system robustness, flexibility and resistance to potential change, the popular
three-tier architecture deployed in our system. The architecture is composed of three layers:
the user interface layer (web browser), the application logic layer (CIMS server) and the
database layer (CIMS database server). The three-tier architecture [ CITATION Thr15 \l 1033 ] aims
to solve a number of recurring design and development problems, hence to make the
application development work more easily and efficiently.

Client: End-users operate on this tier and they know nothing about any existence of the
database beyond this layer. At this layer, multiple views of the database could provide by the
application.

Application server: At this tier reside the application server and the programs that access the
database. For a user, this application tier presents an abstracted view of the database. End-
users are unaware of any existence of the database beyond the application. At the other end,

|P a g e
the database tier is not aware of any other user beyond the application tier. Hence, the
application layer sits in the middle and acts as a mediator between the end-user and the
database.

Database server: At this tier, the database resides along with its query processing languages .
A database server is a server which uses a database application that provides database
services to other computer programs or to computer as defined by the client-server model.
User access a database through a front end running on the user’s computer which displays
requested data.

Figure 5. 1 Proposed System Architecture

5.2.1. Subsystem Decomposition and Description

Account Management Subsystem: in this subsystem, Managing of information regard to
account and perform

 Create account
 Delete Account
 Update Account

Report Management Subsystem: this subsystem allows for managing report information and
performs this operation.

 Generate report
 View report

|P a g e
Request Management Subsystem: this subsystem allows for managing request and performs
this operation

 Send request
 Approve request
 Reject request

User Management subsystem: this subsystem allows for managing students and performs this
operation

 Register user
 Update user
 Delete user

Notification management Subsystem: this subsystem allows for managing Notification

information and performs this operation

 Create Notification
 Read Notification
 Reply Notification
 Delete Notification

Database connection subsystem: this subsystem used for established connection between
business class and database management system.

|P a g e
 Figure 5. 2 Sub System Diagram

5.2.2. Hardware/software Mapping

Deployment diagrams[ CITATION Jon16 \l 1033 ] are important for visualizing, specifying,
and documenting embedded, client/server, and distributed systems and also for managing
executable systems through forward and reverse engineering. They show the structure of the
run-time system, they capture the hardware that will be used to implement the system and the
links between different items of hardware. They model physical hardware elements and the
communication paths between them.
CIMS Deployment Diagram

|P a g e
 Figure 5. 3 Deployment Diagram

5.2.3. Detail class diagram

The detail class diagram[ CITATION Spa11 \l 1033 ] is the main building block of object-oriented modeling.
It is used for general conceptual modeling of the structure of the application, and for detailed modeling
translating the models into programming code. Class diagrams can also be used for data modeling.

|P a g e
 Figure 5. 4 Detail Class Diagram

5.2.4. Persistence data Management

Persistence data management [ CITATION per14 \l 1033 ] is about storing data permanently,
to manage flash constraints and to manage persistency within automotive lifecycle
constraints.

|P a g e
|P a g e
 Figure 5. 5 Persistent Data Management Diagram

5.2.5. Access control and security

Access control[ CITATION Acc19 \l 1033 ]  is a security technique that regulates who or what can
view or use resources in a computing environment. Access control is a security feature that
controls accessibility to a system and even minimizes security risks.

Table 5. 1 Access control and security

Activity MOE University_registrar Student ERCA Employer Employee

Login      
Manage    
Account
Fill cost 
sharing
|P a g e
Approve 
cost sharing
View      
Notification
Calculate 
cost share
Search      
Generate    
report
Register  
Send request 
Approve 
request

5.3. Packages
A package[ CITATION pre04 \l 1033 ] is a grouping of model elements which means
that a package can contain model elements of different kinds, including other packages to
create hierarchies. 

Figure 5. 6 Package Diagram

|P a g e
 5.4. Algorithm
An algorithm is a procedure or formula for solving a problem, based on conducting a
sequence of specified actions. It is a step by step process carried out to solve the given
problem.
Algorithm Design for login
1. Go to login page.

2. Fill out the field’s username and password and click Login.

3. The page process the fields, send them to MySQL database, and check it. If the Fields is
correct, go to step 5. If not, to step 4.

4. Show error page.

5. Start session; go to home page after login.

Algorithm Design for fill cost sharing

1. Go to fill cost sharing page.

2. Fill out the fields.

3. The page process the fields, send them to MySQL database, and check it. If the

Fields is correct, go to step 4. If not, to step 5.

4. Display successfully submit message.

5. Show incorrect input error.

5.5. User Interface

User interface is the interaction between a user and software running on a web server. The
user interface is the web browser and rendered. Since this system is a web based system we
designed a web interface to interact the users to the system.

|P a g e
Figure 5. 7 user interface for login

|P a g e
Figure 5. 8 user interface for register students

|P a g e
Figure 5. 9 user interface for fill cost sharing

CHAPTER SIX
6. IMPLEMENTATION AND TESTING
6.1 Introduction
The Implementation phase in the software life-cycle is where the actual software is
implemented. It is the critical phase in which it transforms the design and analysis of the
system into tangible system by writing the code to the system to be developed and make is
operational and applicable by testing debugging the functionalities that are done. The result
of this phase consists of source code, together with documentation to make the code more
readable. The main objective of this phase is generally is to deploy and enable operation of
the new information system in the production environment. During implementation and
operation, physical design specification must be turned into working computer code, and then
the code is tested until most of the errors have been detected and corrected. The user sites are
prepared for new system and user must come totally on the new system rather than the
existing.

6.2 Implementation of the Database

We have use MySQL database management system for the implementation of the data base.
Because MySQL is most stable, secure, reliable and higher performance than the rest; it takes
lower time for transactions (accessing and processing) data in a database. Which means its
faster to process transactions. MySQL reveals that it can perform efficiently regardless of its
workload.

After selecting MySQL database management system, we perform the following activities:
 We should create all tables which were identified and shown as persistent model in the
design document with their primary keys.

6.3 Implementation of the Class Diagram

In class implementation the following activities are performed.

 We Define attributes with the appropriate data type and access visibilities.
 We define all methods with appropriate return type, parameters and the corresponding
data types and access visibility.
|P a g e
6.4 Configuration of Application Server

We have been used XAMPP as application server because it is a simple, lightweight Apache
distribution that is extremely easy for us to create a local web server for testing and
deployment purposes. Since the basic job of all web servers is to accept requests from clients
(visitor of web browser) and then send the response to that request (the components of the
page that a visitor wants to see). And a web server is an essential part of any website, since
our developed system is web-based system, we had used Apache web Server which is open-
source software.

 In the configuration process its installation is straightforward and simple then set
upped and run the configuration to start, stop, and configure the services by opening
the dashboard.
 It is integrated with most popular operating systems. We use XAMPP for windows.
 It is automatically installed on our computer as we install it.
 It is free web server and supports many operating systems.
 It is used to easily run and test websites and web applications locally.

6.5 Configuration of Application Security

Since our system involves storing of some personal data, we put some security mechanisms
like unauthorized person cannot login into the system because the system requires a user
name and password. Web application security is the process of securing confidential data
stored online from unauthorized access and modification. We have implemented all input
validations properly in order to secure our system. Since the system developed to the users
who may senior to computer or may professional to computer so all inputs must be
implemented easily and sample to use.

When the user enters invalid inputs or empty, the system notifies to the user to inter valid
inputs. In order to secure our system, we have been performed the following activities: -

 mAll inputs were validated properly

 User accounts was assigned with necessary access privileges
 Sessions was implemented.

|P a g e
6.6 Implementation of User Interface
The user interface is user centered design (Place users in control of the interface) and the first
impression of the system where user interacts with a computer other software system.

Regarding to the user interface, we have to apply the following.

 The user interface that we develop is user adjusted design. It means we have to make
our user interface be attractive and eye catching for users by developing compatible,
well-matched and friendly user interface.
 The user interface that we develop is consistent and dependable
 Reduce user’s memory load –our user interface can be easily remembered for users in
long period of usage and it does not require any retention to use
 The user interface is consistent and stable which does not create any confusion for
users easily understandable with clear and steady navigation.

6.7 Testing

6.7.1 Test Case

Testing is the final step in which the entire system as a whole with all forms, code, and
modules are tested. It is the process of evaluating a system or its component(s) with the intent
to find whether it satisfies the specified requirements or not. Testing is executing a system in
order to identify any gaps, errors, or missing requirements in contrary to the actual
requirements. In this procedure we have tested all the functionalities of the System. All errors
in the forms, functions, Modules have been tested. Finally, System testing ensures that the
entire integrated software system meets the desired requirements. It tests a configuration to
ensure known and predictable results.

Features to be tested

When we test our project, we perform following testing.

 Input output functions. Checking what type of our system should be taken as input and produce as
output and checking input is produce expected output.
 Graphical user interface.in case we consider standard position of interface, standard of interface by
comparing with previously performed system and criteria written for graphical user interface.

|P a g e
  Sub system communication. Our system is decomposed into different module because of module
system easily managed and error easily detected and fixed. But communication between them should
be tested.
 Data base transaction. Ensuring transaction of our system database.
 Security. Identifying security of our system by identifying only identified user allowed access our
system and ensuring password of each individual user not seen by another. This thing is the thing we
consider on login capability.
 User interface and database interaction. Database is one that store data and user
interface one that user data is entered, so during our test we try to identify data
entered on user interface stored in database and another crud.

6.7.1 Testing Tools and Environment

Hardware testing tools

 Computer with windows platform

 Data cable
 Web browser

Software’s testing tools

 Operating system
 Windows 10

6.7.2 Unit Testing

In this phase of testing, every module of the System is separately tested. Each modules of the
system can be tested check the working of each classes, methods and attributes of the system.
It is done by the programmer to test that the unit implemented is producing expected output
against given input.

Sample we test in our system in unit testing are:

 Check whether entered input is validated correctly.

 Check how the sub procedures or functions are call correctly.
 Check if the correct output is produced for different inputs.
 Check the efficiency of the code with respect to the memory and CPU time.
 Check the input data that we write on the GUI must be submitted to the data base.
 Check the GUI can access the privileged data from the data base.

|P a g e
  Is password of the user hidden? This can be checked in database and performed using
code.

6.7.3 Integration Testing

In this level of testing, we have examined how the different procedures work together to
achieve the goal of the system. Check the interaction between individual functionality which
performs the specific task.

6.7.4 System Testing

In this level of testing process, examined how the whole subsystems work together to achieve
the desired goal user’s requirements of the system. The goals of testing are to detect faults
that can only be exposed by testing the entire integrated system or some major part of it.

CHAPTER SEVEN

7. CONCLUSION AND RECOMMENDATION

7.1. CONCLUSION
Currently Ethiopian higher education is using manual based cost sharing management
system. This existing system has a drawback, so we plan to develop new system, so we plan
to develop a new system which solves the drawbacks of existing system which is called web
based cost sharing management system.

7.2. RECOMMENDATION
This proposed system is does not make payment, Cannot control the mobility of beneficiaries
outside of the country, so we recommend for any revision to include this functionality during
modification.

|P a g e
 References

[1] p. Hall, "Object oreinted system analysis ana design," 12 january 2004. [Online]. Available:
www.prencil.com. [Accessed 20 october 2019].

[2] H. Hick, "system modeling concept," 23 Agust 2019. [Online]. Available: link springer.com.
[Accessed 15 january 2019].

[3] "Object Oreinted system analysis and design," 20 octobor 2019. [Online]. Available:
www.academia.edu. [Accessed 18 octobor 2019].

[4] "Dynamic Model Introduction," Apmonitor.com, 14 september 2014. [Online]. Available:

apmonitor.com. [Accessed 15 january 2019].

[5] "Three tier architecture," 8 january 2015. [Online]. Available: www.Ibm.com. [Accessed 28
february 2019].

[6] Jonhatan Kaplan, William Crow Ford, "J2EE Design Pattern," in Deployment Diagram, 2016.

[7] "persistent data management," 18 Agust 2014. [Online]. Available: at.project.genvil.org.

[Accessed 3 january 2020].

[8] "Access control Security," 26 Agust 2019. [Online]. Available: www.getkisi.com. [Accessed 28
december 2019].

[9] 20 octobor 2019. [Online]. Available: www.tutorialspoint.com. [Accessed 18 octobor 2019].

|P a g e
|P a g e