1.1.

Background

Haramaya University (HU) was established as an institute of higher education

1954, when thegovernments of Ethiopia and United States of America agree to
jointly establish the Ale MayaCollege of Agriculture. It was aimed and designed to
conduct institution, research and extension(demonstration, popularization) and
other education activities that promote the development anduse of agriculture.In
1985, the College was upgraded to an agricultural University and was renamed Ale
MayaUniversity of agriculture. In 1996 the university launched faculties of
education and Health scienceand was promoted to a full-fledged in 1999, renamed
Ale Maya University. Additional facultiesincluding Faculty of Business and
Economics and Faculty of Law, Faculty of veterinary Medicineand Faculty of
technology was opened. HU runs both under graduate and post graduate (M. Sc
andPHD) program in various fields of study. In 2006 Alemaya University was
renamed HU. The HUFinancial system was housed in administration building
basement hall and Finance ManagementSystem of HU has the same age with
HU. This finance management system was established forthe primary purpose of
improving finance management and accountability in the public sector.Currently
this finance has many sections, such as payroll section, accountant room, cashier
roomand manager room. Manage are control over all activity of finance.

1.2. Problem definition

Currently the finance is facing many problems due to the use of manual system in
its day to dayactivity.

The problems are:

Loss of document.


Problem in Organized Data.



Problem of duplication of items i.e. it needs to manipulate all the items

individually in allusers client by transferring the items which need modification
manually.
1.3. Objective of the Project1.3.1. General Objective
In general our project objective is to develop Haramaya University Finance
Management System.
1.3.2. Specific Objective
Included in the general objective, our project is also expected to fulfill or achieve
the followingspecific objective.
To keep HU employees information in efficient, reliable and secured way.
To get HU employees information as quickly as possible when he or she comes to
receivemoney.

To provide a good controlling system for the manager.

Analyzing the requirements of the users.

Designing computerized system based on users’ request.

Making things easier for the employers by developing, organizing and

normalizingdatabase with updating information gathered from employers.

To increase ease of information exchange between each of department members of

thefinance.

1.4. Scope the project

The project automates the activities by providing, updating, searching, deleting and
so onactivities. The major area of the finance system includes:
Solving the problem of payroll system.
Solving the problem of data base system which means preparing data base for the
mostknown finance.
Solving the problem or file management system. This point explains how to put
profile foremployees and how to get the profile from the data base.
Solving the problem of document preparation. At this point the systems enhance
the systemof preparing document simultaneously.
 Solving the problem of knowing the activity of the finance in a specified time
interval inthis point the document clarify that how many employer join the finance.
Solving the problem of getting information about the employees. This point
is also explainthat how to get information about the employees as well as the
activity of the finance atany time.
Solving the problem of information about how much employees is received
money.
1.5. Methodology used
During information gathering we have used a number of techniques that helps us
to get fullinformation about the system. These techniques are: -

1.5.1. Observation
We all have observed physically by going to the place. That most of the finance
activates arecarried out manually. We have seen that there was no any well-
developed computerized system inthe finance. And also information about the
finance and the services that the finance provides werenot available easily.
1.5.2. Interview
The other most important method that helps us to get the most important and
critical informationabout the general view of the finance is by interviewing the
different staff members of the finance.They also told us the background of the
finance. The other method that we are going to use fordesigning our system is the
structured methodology. This designing method helps us to understandthe system
more easily. Under structured methodology we have other two methods.

1.6. Definition, Abbreviations, Acronym

HU-
Haramaya University.
 Id-Identification number
 HUFMS-Haramaya University Finance Management System

CHAPTER TWO
2. Proposed System

2.1. Functional RequirementsIn our newly developed system we need to include

different features about the finance. We haveso many functional requirements in
our newly developed system but the main are as follows.
The system store and display data about the employees.
Payroll system.
The system would be able to search, update and delete the information of
employees.
2.2. Non-Functional Requirements

Our newly developed system will provide the following functionalities:-

Documentation: The system will provide information about how to use it and all
theindispensable information about the system.
Error handling: our system handles error by showing the message” invalid input”
when the user enters invalid input.
Performance: The system has high performance example accessing information
and performance activities in a short period of time.
Security: Except the concerned body any one cannot change, delete retrieve or
append data.
2.3. System Models
To produce a model of the system which is correct, complete and consistent we
need to constructthe analysis model which focuses on structuring and formalizing
the requirements of the system.Analysis model contains three models: functional,
object and dynamic models. The functionalmodel can be described by use case
diagrams. Class diagrams describe the object model. Dynamicmodel can also be
described in terms of sequence, state chart and activity diagrams. For the purposeof
this project we have described the analysis model in terms of the functional model
and dynamicmodels using use case and sequence diagrams.
2.3.1. Use cases
Use case defines set of interaction between actors and proposed system models
considerations.It is a methodology used in system analysis to identify, clarify and
organize all system activitiesthat have significations to contain
.
Use cases of the system are identified as can be seen from thediagram each actor

has access to different Use Case.Use cases of the system are identified to be create
account, login, register, receive money, calculate payroll, search employee
information, add employee information, update employee information,delete
employee information and detail report.

3.2.1.1. Use case diagram

The simplest possible class diagram of our proposed system is shown in Fig.1
2.3.1.2 Use Case DescriptionUse case description for create accountUse case name
Create account
Actor
Administrator
Description
TAdministrator needs to create an account andthis enables further communication
and othertasks in the forum.
Precondition
Clicks create account.
Basic course action
1. Clicks create administrator account menu
2. .2. Fills the following details:
User name
password
3. Saves the account information.
4. Displays acknowledgment
.5. Clicks close
.Post condition
Closes the window.
Use case description for calculate payroll
Use case name
Calculate payroll
Actor
Accountant
Description
Accountant calculate payroll.
Pre condition
he or she must login in to the home pagelogin form and calculate payroll
.Basic course action
1. The administrator ordered to accountant to calculate payroll.2. The accountant
accepts the employee information.3. Calculate payroll for all employee.
Post condition
The aroll will be calculated .
Use case name
register
Actor
Administrator
Description
when the new employee added to the existingmember.
Precondition
he or she must login in to the home page login formand accept the information of
employee.
Basic course action
1. Open employee registration page from menu2. Fill the employee registration
page and Click save3. Display the registration page4. Display registration
successful or failed
Post condition
Employee registered

Use case name

Add employee Information
Actor
Administration
Description
Administration can add employee information.
Pre Condition
he or she must login in to the home page and addemployee information.
Basic course action
1. Open add Page form from menu.2. Fill the add form and Click add.3. Display
the add page form.4. Display add Successfully.
Post Condition
Employee information is added

Use case name

Search Employee Information
Actor
Administrator and Cashier
Pre Condition
he or she must login in to the home page and sesearch employee Information.
Basic course action
1. Open Search form from menu.2. Enter the ID of employee and Click search.3.
Display the Search form.
Post Condition
Search is Successful

Use case name

Update employee Information
Actor
Administration
Description
Administration can update employee information.
Pre Condition
he or she must login in to the home page andupdate employee information.
Basic course action
1. Open Update Page form from menu.2. Fill the update form and Click Update.3.
Display the Update page form.
Post Condition
Employee information is updated

Use case name

Delete employee Information
Actor
Administration
Description
Administration can delete employee information.
Pre Condition
he or she must login in to the home page anddelete employee information
Basic course action
1. Open deleted Page form from menu2. Fill the delete form and Click delete.3.
Display the delete page form4. Display delete successfully
Post Condition
Employee information is deleted

Use case name

detail report
Actor
Accountant and cashier
Description
Manager needs detail report from accountant and
c
ashier.
Precondition
he or she must login in to the home page login formAdministrator

tells them to prepare the detail report.

Basic course action1
. Administrator

tells them to prepare the detail report2. They prepared their detail report.3. Finally
they send to administrator.
Post condition
Administrator checks the detail report.

3.2.1.3. Actor description

For our systems actors that we identified are:
Actor:
Admin
Description
: Administrator is able to manage over all the activity such as: create account,
login,add employee information, search employee information, update employee
information and deleteemployee information.
Actor:
Employee
Description
: receive money from cashier.
Actor
Cashier
Description
: login the system, search employee information and pay money for employee.
Actor:
Accountant
Description
: login the system and calculate the payroll

3.2.1.4. Class Diagram

A class diagram depicts classes and their interrelationships. Class diagrams
describe the structure of the system in terms of classes and objects. Classes are
abstractions that specify the attributes and behavior of a set of objects. Objects are
entities that encapsulate state and behavior. In our new proposed system boxes
including three compartments because it is a standard convention depict classes
and objects. The top compartment displays the name of the class or object. The
center compartment displays its attributes, and the bottom compartment displays its
operations. The attribute and operation compartment can be omitted for clarity.
Object names are underlined to indicate that they are instances
The simplest possible class diagram of our proposed system isshown in Fig.2.

The sequence diagram is used primarily to show the interactions between objects
in thesequential order that those interactions occur. Much like the class diagram,
typically thinksequence diagrams were meant exclusively for them. Besides
documenting an organization'scurrent affairs, a business level sequence diagram
can be used as a requirements document to communicate requirements for a
future system implementation. The simplest possible Sequencediagram of our
proposed system is shown in Fig.3, Fig.4 and Fig.5.
Fig.3 Sequence Diagram for create account
Fig.4Sequence Diagram for register
Fig.5 Sequence Diagram for search
Interface is a device or program enabling a user to communicate with a computer,
or for connectingtwo items of hardware or software. User interface design shows
interfaces of this system how itinteracts to its users. In the following section we
are going to show the UI design we are going touse to our Web application
system. In addition to hardware and software interfaces, an interfacemay refer to
the means of communication between the computer and the user by means
of peripheral devices such as a monitor or a keyboard and point of communicatio
n involving acomputer

2.4.1. Form
The simplest possible form of our proposed system is shown in Fig.6 and Fig.7
Fig 7 home page

2.4.2. Activity Diagram

Activity diagram shows the conditional logic for the sequence of the system
activities needed toaccomplish a business process. It clearly shows parallel and
alternative behaviors that can be usedto show the logic the activities in the system.
The simplest possible activity diagram of our proposed system is shown in Fig.8,
Fig.9 and Fig.10
Fig.9 Activity diagram for registration
CHAPTER THREE3. System Design3.1. Introduction

System design has a great part which describes the first solution of the system
problem. Sodesigning a system is the important and necessary step in any
computer system. System
design provides a clear description of the overall design of the HUFMS and bridgin
g the gap betweendesired and existing system in a manageable way.The internal
part of this system design document is organized as: subsystem
decomposition,software and hardware mapping, persistent data management,
access control, object design anddatabase design.
3.1.1. Purpose
The purpose of this project is to support the finance in many ways. From those
ways some of themare:-


Save the time that is lost while doing some jobs manually.


Protect the data of the finance from access by unauthorized person.



Support simulations document preparation of different office of the organization

andfinally to enable the insurance performance.
3.1.2. Design Goals
The design part is very important so as to make the implementation very easy. The
non-functionalrequirement is the description of the feature characters and attributes
of the system. Some of thedesign goals are:
1. The system should be secured:
as the system is finance system the security requirement is acritical issue. So that
the system should prevent unauthorized access to the data stored in thedatabase,
and in addition the system should maintain data about what activities are
performed bywhom and when.
2. Ease of access to the required data:
any data can be required at any time for some purpose,i.e. modify or view. So that
the system should enable the user acquire the required data easily andtimely with
no need of navigating too many files.
3. Error handling:
The system should be able to give response (error message) when the userenter
incorrect input. This recommends the user to enter correct input

3.1.3. Definition, Abbreviations, Acronym



HUFMS
-Haramaya University Finance Management System


UML
-Unified Modeling Language


DBMS
-Database Management System


DB
-Database


ER
-Entity Relationship
3.2. System Design Model

3.2.1 Subsystem decomposition

To reduce the complexity of the system we decomposed the system into different
and simplesubsystems. The following are identified to be subsystems of the
systems:-Administrationsubsystem, Register subsystem and Payroll subsystem.

Administration subsystem
Administration Subsystem

Select from the menu

Click on your choice

Register subsystem:-Payroll subsystem:-

Register subsystemFill the formSubmitPayroll subsystemFill the formSubmit
3.2.2. Hardware/software mapping
The DBMS subsystem is mapped to a server which has more processing power and
storingcapacity, hence the system is build as a client/server application and
communicates to anyother computers, so the system is a dependent component that
runs on any computer node.UML deployment diagram illustrate the
hardware/software mapping of the system.
3.2.2.1. Deployment modeling
Deployment diagram shows a static view of the non-run time configuration of
processing nodesand the component that run on those nodes. Deployment show the
hardware for your system, thesoftware that is installed on the hardware and the
middleware used to connect the disparatemachines to one another. We create
deployment model for applications that are deployed to severalmachines. The
simplest possible deployment diagram of our system design is shown in Fig.11
Persistence data maqnagement

Persistence data management

The system requires persistent data management since it needs:

To store employee information.



To store payroll information.


To permit different user to have different views of the system.


To allow concurrent access to the system information and other related

issues.Identification of the persistent is realized from dynamic model in the
application domain.A relational database management will be used to maintain the
persistent data in itsadvantages that it provides several services and utilities that
help to attain the design goalsof the system.
3.2.4. Access Control
The system uploaded on a central server to be accessed by multiple users. It will
have userinterfaces to interact with the users easily. User will type their user name
and password on thelogin form and the system will check the validity of the user in
the database. If a match is foundthe user will be allowed to access the system with
the privilege level assigned to him/her. If amatch is not found in the database the
system will display a message telling the user to re-enter theuser name and
password or else service will be denied.
3.3. Detailed Design3.3.1 Object design
Conceptually, we think of system development as filing gap between the
problem and the machine.The activities of the system development incrementally
close this gap by identifying and definingobjects that realizes part of the system.

System design reduces the gap between the problem and the machine by defining a
hardware andsoftware platform that provides a higher level of abstraction than the
computer hardware. Duringobject design, we the analysis and system design
models identify new objects, and close the
gap between the application object and off-the-shelf components. This includes ide
ntification ofcustom objects and the precise specification of each subsystem
interface and class. As a result, theobject design model can be partitioned into set
of classes such that they can be implemented byindividual developers.

In object design documentation we try to find out all the definition of the class and
association thatwill be used in the implementation as well as the interface s
documentation and pseudo code ofthe method used to implementation
Object design trade off
The trade-off that we come across during design phase of HUFMS is between
modularity,reusability and efficiency cost of the system. We want to design class
as modular as possiblehowever this would result to inefficient due to function call
overload and cost more because of thetime spent. Therefore we need balance
these groups of properties. We applied modularity andreusability principles to
whatever suitable but we also tuned critical functions for efficiency.Developing a
modularity designed for HUFMS will be different from mainstream of manual.
Thisis because the focus will be less on performance and more on durability and
flexibility.
Performance:
The performance of the system includes response time, the ability and speed of
thesystem while the system is running like for log in, registration, searching etc.
Durability:

Having the system running with great speed today doesn’t help users in the future
if
the system
doesn’t work on newer platforms.
Flexibility:
If the system is flexible it is easy to configure and less tight to get the
maximum performance. Therefore, flexibility is higher priority than performance.
3.3.2. Database design
The design of the DB is portrayed as a special model, database schema. It is the
physical model or blueprint for a DB, which represents
the technical implimentations of the logical data model. Arelational DB schema
defines the DB structure interms of tables, keys,indexs and integrity rules.A DB
schema specifiece details based on the capablities, terminologies, and constraints
the chosenDBMS.
3.3.2.1. Entity Relationship (ER) diagram

ER diagram of the database can be seen in Fig.12.

ER mapping to relational database

Employee registration table

: - It is one part of our database system which contains personal information of the
employee

Cashier registration table

: - It is one part of our database system which contains personalinformation of the
cashier
Accountant registration table
: - It is one part of our database system which contains personal information of the
accountant
The finance management system conversion from the present system the new
system is based onthe radical change which based an acceptance from the users of
the system.Moreover, the system will bring radical change to the finance current
working condition of the payroll system department.Finally, we concluded that the
finance management system will be give efficient and effectiveservice for
employee.
5. Recommendations
Finally, the team members recommend the following points:


This system will give a solution for some of the problems in the registration
process of theemployee.

We recommend to the University department of computing science to provide its

studentsthe opportunity to work on developing systems that are aimed in solving
the real problems.
6. Appendix

The simplest possible Sequence diagram of our proposed system is shown in

Fig.14, and Fig.15
 7. References

1. Software Engineering book (Jalote).

 2. Jeffery, D.Bently (2001) Object Oriented System Analysis and Design Method
(5
th
edition). 3.Joseph, S.Valacich. (2004)Essentials of Systems Analysis and Design (2
nd
edition)