DEBRE MARKOSE

UNIVERSITY
CHAPTER ONE:

INTRODUCTION
1 Background of the organization
Debar Marko’s University is one of the thirteen new university which wear established by
the federal democratic republic government of Ethiopian. Its foundation stone was laid in
1997 E.C/2005, as a newly opened higher governmental education institute by ministry of
education and hosting around 760 students as a beginner in 1997 E.C/2005.

In debre markos university student cost sharing has been organized in 1997 E.C/2005,
when the university started its function with one college and eight departments the office is
responsible for managing the academic record of students and is committed to serve
students. The student cost sharing started its function when the universities look off with
the first batch 760 students.

Debre markos university campus provides services like student’s registration, library
servicing, student cafeteria, store system, management servicing, cost sharing system and
internet access sing (resonate) servicing to the students etc.

The students cost sharing system works along with the registrar office. The government
incurs (invite) an over estimated expenses to gratify students need towards getting
services from the institutes on the pre requirements of the students to share the cost they
used in their time of duration in the campus. Ignored to compensate these costs, the
government of the Ethiopia designed student cost sharing regulation policy by house of
people representative and come to in action in 1996 E.C.

These regulations recommended that the students in their duration must share the cost
either in cash or in kind after graduated from. In order to apply this policy in action, an
automated student cost sharing system is required which enables to control the student’s
who does not share the cost and to understand the amount of resources spent for each
department.

2 Statement of the problem

In debre Markos University I observed the student cost sharing system most of its work is
done in manual system. Manual based documented system takes more time to find
students information. And also needs more workers, and leads to problem. In this project I
designed a system that can solve those problems, because the manual system cannot fulfill
the need of the recorder.

So the following problems are listed, it includes that:

 There is no full use computerized system student information.

 Manual documented system is time taking than computerized documented system.
 It is not easy to find students data in short period of time.
 Students’ information recorded document may be lost
 The retrieval of student cost sharing system record consumes use much time.
 Difficult to search student’s data as required when the numbers of Student s are
increased.
 Time wastage to the students as well as the customers.
 Tedious and complex data when the numbers of students are unbalanced with the
workers recording system.

The problem above is some of the problems are available due to the manual works and
there are described in the greater detail on the existing system analysis part of the project.

It is expected from us to develop or to recover the manual one by automated student cost
sharing system.

If the system is not automated the aforementioned problem may aggravated and the
government may not get the expected cost from the beneficiaries effectively at the right
time

3 Objective of the project

a. General objective:
The general objective of this project is to design and develop a database student cost
sharing system and that computerized the existing manual system would permit recorders
and other stockholders to get reliable and summarized information about the student on
time.

b. Specific objectives
Following are specific objectives

 Analyzing the existing system

 To produce the different reports
 study the existing system of the organization
 Identifying problems of the existing system
 testing the implementation of the system
  Designing student cost sharing system
 Develop student cost sharing system
 Produce documentation about the system and use the other specific objective.

4 Significance of the system

The project has a great benefit for the student cost sharing system and their workers of the
administrative center in case of solving the problems.

The benefits are listed below:

 Reduce the amount of resources that are wasted.

 Keeping information safely about DMU cost sharing.

 Faster decision making due to the report generation functionality.

 Giving work satisfaction for workers as well as the customers.
 Faster decision making due to the report generation functionality.
 Users will be allowed to interact with the system.
 Accessing information’s in fast way.
 Increased the speed to perform activities.

5 SCOPE AND LIMITATION OF THE PROJECT

a. Scope of the project

The project is designed or proposed to meet the functionalities of recording students
information in the database when they get the form ,generating report identify student in
accordance with their batch or registration date.

The implementation phase and the system support an automated data handling
mechanism, like database in order to keep the data in secured and consistence way without
any alteration, modification and unauthorized access. Finally this project is aimed to design
and develop a database student cost sharing system for Debre Markos University students.
Hence, the system is limited to the development of a database recording and reporting
student cost sharing system in DMU.

b. Limitation of the project

To accomplish the project if I have more time, I can do the proposed analyses and design
and implementation the system more efficient their shortage of time.
The materials that are limited in my project are:

 Time
 Budget
 Hardware limitations
 Software limitations
 Un experienced way of data gathering techniques
 References and research manuals etc.
 CHAPTER TWO
REQUEREMENT MODEL

1. Introduction
When this request gets acceptance by the students and implemented properly, it can plays
a vital role for the reconstruction of other public services in the national level. If the
regulation has such a lot contribution for the growth of one country, developing an
automated higher education cost sharing regulation form are mandatory and significant.

Having this in mind, the goal of the requirement phase is eliciting the requirements
from the user or customer. This is usually achieved by the development of modeling
diagrams and the requirement specifications after discussions with the user. The user
then reviews the modeling diagrams and specifications to determine if the system
developer has

1.1 Overview of the current system

Debre Markos University student cost sharing system officially began/organized its work
by engaging its own staff worker as an independent the staff in 1997 E.C. However, since
the staff applies the manual working system, it faces different problems at different time.

Even if the current system is a manual system, it provides the following activities:

 Get list of students

 Enforce that the students fill the form
 Documented students information based on their department
 Generating a manual report as needed
Input
Regulation form with student information
Process
The cost sharing office transfers the form to the department.
The department distributes the form down to the student
The students should fill the form and return back to the department
 The department checks the filled form whether the students are fill correctly the
form and return back to the cost sharing office.

Out put
Documented students information

Getting services like training, cafeteria, education, dormitory, medical etc…

1.2 Overview of proposed system

By observing the overall problem of the manual system, we develop online cost sharing
management system better than that of the existing system in different aspects. Online
Debremarkos university cost sharing management system is basically designed to access easily
different level of users. In this system, the actors are performing their regular duties in less time
and easily. The proposed system uses the functionality of existing system to advance speed,
performance, security and reliability of the system. Our proposed system will eliminate or
improve the weaknesses of the existing system by providing online service.
The main objective of the proposed system is:-

 Change the manual system into automated system

 To provide secure data
 To reduce resource wastage
 To store the data on the database
 The authorized users access the data

2 Software requirements
Requirement is a condition or capability possessed by a software or system components in
order to solve real problems. It is a description of the services that a software system must
provide and the constraints under which it must operate.
The main different software requirement tools are used to accomplish in this project
includes that:
 Asp.net with Visual basic 2010 software for coding and interfacing
 Rational rose for drawing different artifacts
 Use Microsoft sql server 2008 software database
 EDRAW software
  Microsoft word 2007 software etc

2.1 Functional requirements

The functional requirements also known as behavioral requirements that describes the
functionalities or services that software’s should provide. For this, functional requirements
describe the interaction of software with its environment and specify the inputs, outputs,
external interfaces, and the functions that should not be included in the software. Since I
develop an automating services that are given to the users via web, the system will be used
to manage and process data according to the rule & regulations of the organization. It will
also provide report generation facilities and notify the students of the university when
there is an issued case that helps the administration of the University for Decision making.

The database of the system provides the following functionality.

 Data entry:
This is the functionality that data is entered to the systems. The system have
different interface that can be used to perform different tasks and used to
manage data entry mechanisms in the university.

The main data entries are the following:

 Login: to identify the authorized customer to use the system

 Registration: needs to register students in each year

 Data update: needs to update data from the system when it is necessary
 Search information: needs when the user wants to search specific information
about the student information
 Data processing:
The system on input data will provide the following data processing:

 New Students registration

  Verify the requested information
 Report generation
 Validate user
 Search user request
 Updating the student
 Report generation:
 Produce report for top managers
 Produce the different reports.
In general the followings are the main functional requirements:

 Allow searching cost sharing records using different parameters

 Register cost sharing information about the students
 Load student cost sharing information from the database
 Generate various reports based on the requirements.
 Update the recorded information when it is needed

2.2 Non functional requirements

The non functional requirements (also known as quality requirements) related to system
attributes such as reliability and response time. These requirements are not related
directly to any particular function provided by the system. It should be accomplished in
software to make its performance more efficient. Non-functional requirements are often
called qualities of a system. Other terms for non-functional requirements are "constraints",
"quality attributes", "quality goals" and "quality of service requirements".

Some of the followings are the main points to express non functional requirements. They
include:-

 The user interface should be user friendly and interactive

 The system doesn’t allow unauthorized users to register and modify records
  The system should handle invalid inputs and displays informative error
message to users
 The system provides with an alternative message to operations committed
by users that distort the system

3. Usecase Model

3.1 Use case description

Use case 1: Login
Actor: Recorder

Precondition: The actor (Recorder) must have an account

Post condition: If the system accepts, displays the main form and displays all the necessary information
including reports.

Description: This enables the user to enter (log into) the system.

Flow of events:
1. The actor clicks on login link

2. The system displays the login Page.

3. The actor enters user name and password
4. The system provides page based on their privilege.
5. End use case.

Alternative course of action

1.1 The system displays the login page with error message
1.2 The system resumes at step2.

Use case2: Create account

Actor: System administrator

Precondition: The user should have logged in as an administrator.

Post condition: The administrator manages the user accounts

Description: This is used for managing user accounts

Flow of events
1. The system requests the user name of the new user to be added.
2. The system requests the password of the new user.
3. The system requests the account type of the new user
4. The system searches the record and finds no duplicates.
5. The new user details are added to the recorded.
6. End of the case.

Alternative course of action

1. The system searches the record and finds the username already existing in the record.
 2. The system displays error message stating username already exists.
3. The system requests the user to re-enter new username.
4. End use case.

Use case3: Deleting a user accounts.

Actor: System administrator

Precondition: The user should have logged in as Administrator. The user account should already exist
in the record.

Post condition: The user is logout to the system

Description: The happens when the user is log out or remove from the system

Flow of events:
1. The Administrator selects the user name which should be removed from the
records
2. The system removes the user details from the record.
3. End use case

Alternative course of action

1. System takes the Administrator to the previous menu.
2. System restores the original access rights for the user.
3. End of the case.
Use case4: Record data
Actor: Recorder

Precondition: The recorder must login.

Post condition: The student record is registered in the system.

Description: Allow recorder to register student cost sharing information.

Flow of events:
1. The recorder selects registration form with respect to their department.
 2. The system provides registration form which contains student’s full information and
the regulation requests.
3. The recorder fills student cost sharing information in the form and submits to the
system
4. The system registers the recorded information
5. The system displays acknowledge message
6. The use case ends.
Alternative course of action:

3.1 The system displays an error message

3.2 The system resumes at step 3.
Use case5: Search records

Actor: Recorder, User

Precondition: The student’s data should be available in the data base.

Post condition: If the user or recorder searched the available data and log out to the system.

Description: This is for searching the different type of records under various constraints specified by
the recorder

Flow of events:

1. This is started by clicking the search button.

2. The recorder or user checks the availability of student’s full information.
3. The recorder or user searches the available information
4. The recorder or user exits from the search menu after he gets the required
information.
5. Use case ends
Alternative course of action:

3.1 The recorder checks to the back end

3.2 Error message displays and resumes to back
3.3 Your searching process does not provide full information
 3.4 Use case ends

Use case6: update records:

Actor: recorder

Precondition: the updater provided with authentication.

Post condition: The recorder checks and load to the database

Description: This is a way of making any necessary change on the recorded data according to some
conditions.

Flow of events:

1. The recorder identifies the update information.

2. The recorder makes a desired change on the database.
3. The recorder trains the updated information to the user.
4. End use case
Alternative course of action:

1.1 The recorder identifies the update parts significantly.

1.2 The recorder resumes to loading and adding to the current dataset
1.3 End use case

Use case7: Generate report

Actor: Recorder, user, administrator

Precondition: The recorder, user or administrator clicks to the login link page.

Post condition: The manager verifies the consistence and availability of student’s information.

Description: This is to generate various reports of the cost sharing management system. Reports can be
generated under several constraints. This report generates to see either student are filled properly in each
year or general reports

Flow of events:

1. The system displays the form which contains the report menu.
2. The recorder clicks on the statistical menu.
3. The recorder selects the statistical criteria and clicks the report button.
4. The system searches the records and displays the records that match to the
constraints.
5. The system sends the output to the printer to provide with a hard copy of report.
6. The system generates the possible student’s information report and dispatches to
the intended body.
7. The system saves the reports for futures analysis.
8. End of the case.
Alternative course of action

1. The user entered invalid temporal constraints.

2. The system prompts an error message and requests the user to re-enter the constraints.
3. End use case

4. Activity diagram

Activity diagram are used to document the logic of a single operation/method, a single use case, or
flow of logic of business operation. In many ways activity diagram are the object oriented
equivalent of flow charts and data flow diagrams (DFD) from structured development. This part of
the project documentation consists of an activity diagram that depicts the flow of action in two
main use
 Enter User name
and Password

Display error message

Click()

Login Button

False

True
Open Main
Form

Figer 1 login activity diagram

 Manager

Fill()
Account
Form

Click()
Delete Account
button

Access()
Database
Error message display

Yes
Account is not present in the DB

Load()
Account deleted successfully
Account is
deleted

Fig 2 Account creation Activity diagram

 Manager

Fill()
Account
Form

Click()
Delete Account
button

Access()
Database
Error message display

Yes
Account is not present in the DB

Load()
Account deleted successfully
Account is
deleted

Fig 3 Account deletion activity diagram

Figure 4 Search information activity diagram
 Recorder

Click()
record form

Fill()
Enter the item to be
updated
Click()
Update record
Display the result to
button
updated and then load

Call()
Database
Display information Message

Yes
No present in DB
Successful()

Figure 5 Update recorded information activity diagram

 Recorder

Create()
Registration
form

Fill()
Cost sharing data

Click()

Add button

Display information error Message

Successfully added
Yes
If not added to DB
Successfuly to add
Load to the
Database

Figure 6 Add records activity diagram

 Recorder,User and
administrator

Click()
Report
button

choo...
Parametres

Access()
Database

Yes
No

Display()
Report
form

Figure 7 Report activity diagram

 Recorder

Click()
exit button

Display()
Conformation
message It resumes to the normal state

No

Yes
Exit form

Figure 8 Exit activity diagram

 5. Sequence diagram
Sequential diagrams are diagrams that model the sequential logic, in effect, the time
ordering of messages.

A sequence diagram in my system is used to formalize the behavior of the system and to
visualize the communication among objects. It helped us to identify additional objects and
participate in the use case. This phase of the document ties use cases with objects and
shows the behavior of a use case is distributed among its participating objects.

Actor Login Link Login Form Login Control Account Acknowledgement

1. Click ()

2. Fill (User name, Password)

3. Create ()
4. Validate Account ()

5. Create ()

Fig 1 Account creation activity diagram

 Delete user account Delete user Delete user Delete user
Manager button account control Account form account database

1. Click ()
2. Call ()

4. Load ()

3. Filled form ()

5. Delete user account ()

6. Return ()

Fig 2 Delete user account sequence diagram

 Recorder Register link Registration control Registration form Cost share record Acknowledge

1. Click ()
2. Create ()

3. Create ()

4. Fills cost sharing data ()

5. Submit ()

6. Add cost sharing Data ()

7. Create ()

Fig 3 Recorder sequence diagram

Update Record Button Update Record Control Update Record Form Student Database
Recorder
 1. Click ()
2. Call ()
4. Load ()

3. Fill Form ()

5. Update Record ()

6. Return ()

Fig 4 Updating sequence diagram

Recorder, user Generate report Generate Recorded Report displ

Report button report form
Administrator control Database form
form
 1. Click
() 2. Call
() 3. Load
()

4. Fill the form

()
4. Access from the database ()

5. Return ()

6. Load ()

Fig 5 Report generation sequence diagram

Exit button Control exit Conformation Login Form Acknowledg

User message
Message
 1.
Click
2. Call 3. Display
() ()

4. Click (yes or
no)
5. Return
()
6.[If no] hide
5. Create
() 7. [If yes] display
()
()

Fig 6 Exit sequence diagram

CHAPTER THREE
 Analysis model

2. INTRODUCTION
The analysis models of the system are represented with the functional model (Use case
diagram), object model (class diagram) and dynamic model (sequence diagram). A type of
this object oriented analysis model would describe computer software that could be used
to satisfy a set of user-defined requirements.

Static model (Class diagram, database design)

1 Class diagram

Class model (diagram) shows the classes of the system, their interrelationship and the
operations and attributes of the class. This model is involved further to include classes that
address the solution space as well as the problem space.

In design, we model classes to represent the static structure of how the system will be
built. The major difference between the class model in analysis and the class model in
design is that here the focus is on the solution domain & opposed to the problem domain in
analysis
 Student<UI>
Recorder SID: String
RecorderId : Number Fname: String
RecorderName : String Mname: String
Address : String Lname:String
Signature : String Age : number
Sex:String
Add() PlaceOFBirth:String
Delete() DateOfBirth: String
1
Update() AccademicYea : Number
Search() Semester : Number
Load() * Nationality : string
Close() *
Region : string
Zone : String
Woreda : String
1 Town : String
*
Kebele : Number
Administrator Phone : String
AdminName : String 1 Address : String
Password : String University : String
Faculity : String
Create() Department : String
Delete()
DisplayReport() Get Info()

Fig 1 Class diagram

2.Communication/collaboration/ diagram (At least four

use cases)
 CHAPTER FOUR

DESIGN MODEL
1 State chart diagram (At least one)

1.1. Component Diagram

A component is a container of logical elements and represents things that participate in the
execution of a system. Components also use the services of other components through one of its
interfaces. The purpose of component diagram is to visualize the components of a system and
relationships of the components.
 Fill Cost
Sharing
Student
Give Login
Feedback Security

View
Notice
Registrar
Officer
View Cost
Share

Upload
Student
File

Cost
Manage
Sharing
Account
Officer

Manage
Cost Share
Cost
Post Sharing
Inland Notice <<DB>>
Revenue
Officer
Manage
Payment

1.2. Deployment Diagram

Deployment diagrams are used to visualize the topology of the physical components of a
system, where the software components are deployed. Deployment diagrams are used to
describe the static deployment view of a system. Deployment diagrams consist of nodes and
their relationships. We have the following deployment diagram with three components like
client server, database server, and application server.
 Application
Server

Fill Cost
Sharing

Client Machine
Manage Database Server
Account

View Cost
Share

Give
Feedback

WEB mysql
BROWSER HTTP View
connection Cost Sharing
Notice
<<DB>>

Upload
Student
File

Post
Notice

Manage
Cost Share

Manage
Payment

2 Detailed design
2.1
 Chapter Five: Conclusion and Recommendation

5.1. Conclusion
We have developed online cost sharing management system for addressing some problems of
users such us wastage of time and resource, lose of data, redundancy of data, difficulty to search
a specific data and so on. To develop this system we use Object-oriented system analysis and
design (OOSAD) is a software engineering approach that models a system as a group of
interacting objects. And we use Unified Modeling Language (UML) for representing these
models. Object-oriented analysis (OOA) applies object-modeling techniques to analyze the
functional requirements for a system. Object-oriented design (OOD) elaborates the analysis
models to produce implementation specifications. We use PHP script language for back end and
HTML markup language for front end and MYSQL server as server during implementation of
the proposed system.

5. 2. Recommendation and future work

According to the scope of our project the teams develop this online application. Because of the
time constraints we may have some limitations which should be taken in considerations, but in
the future the team believes to that the system can be fully operational by making some
functionality that are not included in the proposed systems. During the development of this
project the group members faced many challenges. However, by the cooperation of all group
members work together and advisors there is now able to reach the final results in such away.

Finally the team would recommend that future work should be done on the system in order to
make the system performs better for universities or collages who would like to use online cost
sharing management system. For the future the online cost sharing system:-

 Connected with bank system

 Done with in mobile application
Reference
1. The Elements of UML Style, Scott W. Ambler Ronin International, Cambridg
university.2003
2. FDRE (Federal Democratic Republic of Ethiopia). (2003b). Council of Ministers Higher
Education Cost sharing Regulations No. 91/2003, Negarit Gazette, Addis Ababa.
3. Use case: https://en.wikipedia.org/wiki/Use_case last retrieved on Dec, 23, 2016.