Table of Contents

Employee management system for ASTU ......................................................................................................................... 2

Chapter -1 .......................................................................................................................................................................... 2
1.1. Introduction ....................................................................................................................................................... 2
1.2. Background ........................................................................................................................................................ 2
1.3. Statement of problem ....................................................................................................................................... 3
1.4. Purpose .............................................................................................................................................................. 3
1.5. Objective of the project ..................................................................................................................................... 3
1.5.1. General objective ....................................................................................................................................... 3
1.5.2. Specific objective ....................................................................................................................................... 4
1.6. Feasibility study ................................................................................................................................................. 4
1.6.1. Economic Feasibility................................................................................................................................... 4
1.6.2. Technical Feasibility ................................................................................................................................... 4
1.6.3. Operational feasibility................................................................................................................................ 4
1.7. Scope and limitation .......................................................................................................................................... 4
1.7.1. Scope .......................................................................................................................................................... 4
1.7.2. Limitation ................................................................................................................................................... 5
1.8. Significance of the project ................................................................................................................................. 5
1.9. Operating environment ..................................................................................................................................... 5
TOOLS USED Front end (PHP) ................................................................................................................................ 6
1.10. Methodology.................................................................................................................................................. 7
1.10.1. Method of data collection ......................................................................................................................... 7
1.10.2. Methodology for the system design and development ............................................................................ 7
1.11. Testing procedure .......................................................................................................................................... 8
1.11.1. Unit testing ................................................................................................................................................ 8
1.11.2. Integration testing ..................................................................................................................................... 8
1.12. Team composition ......................................................................................................................................... 8
1.13. Task and Schedule.......................................................................................................................................... 9
1.13.1. schedule ..................................................................................................................................................... 9
1.13.2. Team member’s activity............................................................................................................................. 9
1.14. Definition, acronym, and abbreviation .................................................................................................... 10
1.14.1. Definition ................................................................................................................................................. 10
1.14.2. Acronym ................................................................................................................................................... 10
1.15. Reference ..................................................................................................................................................... 10
3.4. Performance Requirements ............................................................................................................................. 13
4.2.1. Overview ........................................................................................................................................................ 41
Employee management system for ASTU

Chapter -1
1.1. Introduction
Employees are the backbone of any company, management of employee performance plays a major role in
deciding the success of the organization. The workshop is situated in ASTU has a problem in management of
employee performance. The current system running in the workshop is paper based. That is the workshop is
still using cabinet files to store records of stock and employee information. Useful data is scattered all over
the place. In this chapter we shall discuss the solutions to the problems being caused by the current system.
We shall try to understand the manager’s expectations of the new system we are to develop for him.

1.2. Background
There is a system that have been done before which addressed the employee management system to the
required employee through paper by writing on a sheet of paper for approval, registration, attendance and
soon. Nowadays the whole world is becoming technological, and among those, information technology is
the one which is leading the technology. Today there is no place where computer is unavailable. Now we
 proposed the system that is fully controlled by computerized system which allows us to submit employee
information. The proposed system will provide valuable opportunities for low expense, low time
consumption and high visibility commutations.

1.3. Statement of problem

The existing system at the organizations is manual and hence not integrated.
Many problems have arisen because of the manual system. Among this:
 Since the existing system is carried on paper, manually an employee must have write on a
sheet of paper for approval from their manager which is so tedious and time consuming.
 Suddenly if the manager absents from work due to some reason, there is no way to get an
information what Is going on and wether an employee arrived on time and working
properly or not.

 Information is stored in written in form of registers. This has many disadvantages, like
checking a record in a register takes more time.
 Registration of employee require more space, since it is manual system.
 Retrieving information from registers is more difficult, like if want to know at what day the
employee was present in particular department or office etc.
 It is difficult to find and modify existing records.
 Current system being manual is more error prone.
 The employee information loses, in case of different problems.
 Redundancy of information

1.4. Purpose
This Document includes software requirements for the EMS. Employee attendance, Payroll
accounting, Task Management, Salary calculations, new employee registration, the employee perform
their task according to the schedule etc. are the main objectives of this web application. In this
application Administrator creates branches and he assign Branch manager in each branch. Branch
manager will add employees to his branch and he assign tasks to his employees. Administrator is the
main user of this web application and Branch manager will manage employee records.

1.5. Objective of the project

1.5.1. General objective
 In order to change the manual system of managing employee in to computerized system.
 To manage the employee easy and effectively using computerized way of management
system.
 1.5.2. Specific objective
 To register new employees in easy manner
 To manage the task of the employee in efficient way
 To attend the employee whether he/she is absent or not
 To delete the information of the employee who leave the job.
 To retrieve /search the employee information easily
 Removing the boring and tired working style of the employee management system.
 To prevent different errors during manual system working style
 The new system provides easier work than existing system for the Human Resource
management
 The new system is secure system, that can be accessed only by authorized users.

1.6. Feasibility study

In feasibility study we analyze our proposed solution for being feasible or not.
Under this we take into consideration three types of feasibility studies.

1.6.1. Economic Feasibility

Since the computerization of EMS of Browse
Wire IT Solutions is given as a project for me, which is necessary for my course
completion. The Browse Wire IT Solutions should not have to pay for this therefore it is economically
feasible.

1.6.2. Technical Feasibility

The project team members have learned programming languages that required for the successful completion
of the project such as java script, CSS, HTML, PHP, MySQL, ORACLE BD. We also learned the OOSAD
(Object Oriented System Analysis and Design) methodology that we followed to develop this project. Team
members have the required skill to develop the system, so that the project can be said technically feasible.

1.6.3. Operational feasibility

This system brings better achievement for the operations performed by ASTU by providing efficient
registration and storage of employee information easy, updating, deletion, modification and task assignment
of the employee.

1.7. Scope and limitation

1.7.1. Scope
Computerized employee management system is a web based application that can be accessed from
anywhere within an operating system by the authorized user.

The system would be centrally managed and controlled which is designed to run on the organization.

Our project EMS is an online application we create a website to check Number of employees in each
branch, Employees records, Tasks and time frame, attendance records, salary details, etc.
The employees can submit their attendance, and the managers can check employee attendance and his task
details, applying for leave etc. Also Branch Manager can calculate and payouts salary to his employees.
Project can be developed for online services by which any employee can see their details anytime and
anywhere.
Our system does not include:
 Allocating dorm to employee
The project can be developed centralized database so that the data storage and backup services will be easy.

1.7.2. Limitation
 Shortage of written documents in the university
 Lack of sufficient information about the existing system because employers are not voluntary to give
such full information
 Shortage of possible data collecting device and instrument. Such as sound recorder, digital camera
 Financial problem
 Missing of class when we gather the information.
 Shortage of time

1.8. Significance of the project

 Helps to employee use their resource successfully such as: time and labor.
 To control/monitor/manage the employee using new technology.
 User can easily interact with the new technology.

 The authorized access to information resources files of the system is more advanced. This means
secured login to the system will be developed.

1.9. Operating environment

 Hardware and software tools
Software tools
Client side tools

Table1.1. Client side tools

tools Abbreviation and version Used for
Hypertext Html4/html5 For configuration to
markup develop and o
language
Cascading Css/css3 For layout design
style sheet ,content decoration in user
interface design
Java script Js For validating client
side monitoring
language
Table1.2. Server side tools
Tools Abbreviation and version Used for
Hypertext Php 5.6 Front end and
preprocessor programming
language,

MySQL MySQL 5.6 Backend or project

server database

Table1.3. other necessary tools

Other tools
 Tools Abbreviation and version Used for
Microsoft msword2013 For documentation
word
Microsoft Msppt 2013 For preparing
power point presentation
Notepad++ Npp6 For writing php ,html
css and js code
Mozilla fire Firefox30 and above For browsing document
fox in plain text form

Enterprise - For use case and

architecture diagram

TOOLS USED Front end (PHP)

PHP is a server side scripting technology that enables scripts (embedded in web pages) to
be executed by an XAMPserver.
PHP stands for Hypertext pre-processor
PHP is a program that runs inside wamp/xamp server in all OS.
Xamp is Microsoft's Internet explorer above 8 and Mozilla fire fox. Xamp comes as
open source any one can download use freely xamp is also a part of Windows 2000, XP
Professional up to latest version window 7, 8 and 10.
An PHP file is just the same as an HTML file
An PHP file can contain HTML, CSS, and java scripts
Scripts in an PHP file are executed on the xamp server
A PHP file has the file extension ".php"
When a browser requests an HTML file, the server returns the file
When a browser requests an PHP file, xamp passes the request to the php parser engine
on the server
The PHP parser engine reads the file, line by line, and executes the scripts in the file
• PHP file cannot returned to the browser as plain HTML rather than the browser request the
Xamp server in to display document.
• Finally, the PHP file is returned to the browser as plain HTML

 Database tools (MYSQL (front end))

Database Environment: MySQL is a typical environment for constructing

relational databases.
The database is the skeleton and the underlying framework of most of the contemporary
Information Systems. The evolution of the Database systems could be divided into
three phases: the Manual-filing System the forms, the File-based systems an
administrator home page and the database and the Database Management systems
 (PHPMyadmin). The manual-filing system contains files of information in
administrator home page and directly saved in the database. If them exist some
document it will update, related to a Project, product, task, client, or employee and they
are usually labeled and stored in one or files in administrator page. The file not only
may be located in the secure area of the building but also modify as per need, for safety
and. To facilitate the process of searching and to find out what we want, more quickly,
the different types of item can be put in separate folders and they remain logically
related. Actually, the needs of the contemporary industrial world could not be covered
or satisfied by using such kind of systems, and especially what concerns their reliability
and efficiency.

 Hardware tools
Personal computer(PC)or laptop: almost all tasks of our project are performed on computer
Flash: required for data movement
Disks (CD, DVD): necessary for the movement of relevant data and for backup and
recovery mechanism.
Internet Connection: since our system is web based, it is very necessary requirement. It
is also help us to extract relevant information about our project from internet
Printer: to print documentations Patient management system for HU student
clinic Page10
Stationeries (pen, paper): for writing all necessary documentations associated with the
project
Note book: to take notes during data collection and for other documentations

1.10. Methodology
1.10.1. Method of data collection
We used the following methods to collect relevant data required to our project.

Interview: - we gathered necessary information about the background of the management system, their
works activities and the function of their existing system using some structured (when did the university was
established, how does the existing system function, how many employees get are there? how many
employers are there etc.) and unstructured interview questions.

Observation: We also arrived to the department and observed how workers carrying out their work activities
in a natural setting. Observation allows us to collect data in real time where activities are being performed.

Document analysis: - we also collected certain relevant information from written documents in the
department. Not only that but also we tried to review other relevant documents to develop our project.

1.10.2. Methodology for the system design and development

We prefer OOSAD (Object Oriented System Analysis and Design) methodology and waterfall model to
develop our system. This is because an OOSAD provides the following advantages

 Promotes better understanding of user requirements

  Leads to clear design by using use case, activity diagrams, sequence diagrams

In comparison to SSAD, the development time, the level of organization, the robustness, and the
code reuse are all greatly enhanced by the OOAD methodology

 Allows to break down complicated systems into smaller, clearly defined and more manageable
parts
 Code reusability. This will reduce design, programming and validation costs
 Easy maintenance
 Enables the standardization of objects which increases design understanding and decreases the
risk associated with project development.

1.11. Testing procedure

1.11.1. Unit testing

Unit testing is every module of the System is separately tested. It will often done by the programmer to test
that the unit he/she has implemented is producing expected output against given input.
The module interface is tested to ensure that information properly flows into and out of the program unit
under test. The unit testing is normally considered as an assistant step to coding step. Because modules are
not a standalone program, drivers and/or stubs software must be developed for each unit. A driver is nothing
more than a “main program” that accepts test cases data and passes it to the module. A stub serves to replace
the modules that are subordinate to the modules to be tested.

1.11.2. Integration testing

If they all work individually, they should work when we put them together. The problem of course is
putting them together “This can be done in two ways:
A. Top down integration: Modules are integrated by moving downwards through the control
hierarchy, beginning with main control module are incorporated into the structure in either a
depth first or breadth first manner.
B. Bottom up integration: It begins with construction and testing with atomic modules i.e. modules
at the lowest level of the program structure. Because modules are integrated from the bottom up,
processing required for the modules subordinate to a given level is always available and the need
of stubs is eliminated.

1.12. Team composition

Project
Title
Employee management system in ASTU
Prepared NO NAME ID E-MAIL Responsibility
By HABTAMUWUBNEH R/2199/06 Habtamuwubneh5
@gmail.com Designing,
1
implementing,
monitoring
HALID AHMED R/2205/06 Halidlove1@gmail.com Requirement gathering,
2
designing
3 GRUM ABATE R/2191/06 Implementing,
requirement gathering
GETNET JEMBERIE R/2190/06 Implementing, testing,
4
mentainance
HABTAMU BIRHAN R/2196/06 Requirement gathering,
5
mentainance
6 ENYAW WUBETU R/2145/06 Testing, documenting
Advisor Instructor: Yordanos Gebeyew

1.13. Task and Schedule

1.13.1. schedule
Schedule time evaluation is the most important consideration in the development of
project. The time schedule required for the developed of this project is very important
since more development time effect machine time, cost and cause delay in the
development of other systems. A reliable Online voting system can be developed in the
considerable amount of time
Table 1.4. schedule

Months
Phases Mar15/2016 Apr8/2016- Apr17/2016 Apr28/2016 May16/2016-
- apr16/2016 - May15/2016 may20/2016
Mar31/2016 Apr27/2016

Requirement
gathering and
Analysis
Design

Implementation

Testing

Maintenance

1.13.2. Team member’s activity

The team members should participate in depth in making the system more effective by obeying
their responsibility, discussing the issue in broad, and asking some stack holders those who have
especially require our system mainly, an online student affair voting system. Also the team
member has the responsibility to meet with our advisor and they should have to generate a report
as required to the advisor.
 1.14. Definition, acronym, and abbreviation

1.14.1. Definition
Employee management system: - Is include a development presentation of an information system
for managing the staff data with in a small company or organization.

1.14.2. Acronym
 ASTU=Adama Science and Technology University
 OOSAD=Object-Oriented System Analysis and Design
 OOAD=Object Oriented Analysis and Design
 PHP=Hyper Text Pre-processor
 HTML=Hyper Text Markup Language
 CSS=Cascading Style Sheet
 OS=Operating System
 EMS=Employee Management System

1.15. Reference
 We used a sample template given from the lecture
 And we used also online notice board project documentation which is prepared last
year.
 Different projects that was done before.
 Prentice Object Oriented Software Engineering Using UML ,Patterns and Java 3rd
2012_2
Chapter Two:
2. Description of the existing system
The now application that is used in the employee management system is almost manual system. The data
stored and activities are performed like attendance filling and paying their salary is performed using paper
and pen Some time they use Microsoft-excel and Microsoft-word to store their data in the computer. But
the current system or the existing system have not any database to store such type of activities.

2.1. Major function of the current system

Now, a time the university office forward required purpose to develop an application to its system users.
The flow of manual system of the office is as follows: -
 The administrator or office members prepare manual forms or sheets.
 The administrative collect the detail information /document about the employee in order to register the
employee.
 The forms distribute to the users
 The users fill the manual forms or sheets of their requirement.
 The office members or workers check the forms or sheets for valid information
 Then the office members save the user and experience details in the manual document, some times in
the computer MS-offices.
 When office members need to check their data, they search in the documents.
 The employee goes in to the administrative office and fill the attendance form using a given paper
form.
 Generally, all activities are performed by filling the form from the paper.

2.2. Users of the current system

Now the user of the system are employee and manager or administrator.
 Manager: -
 Employee: -
2.3. Drawback of current system
The current system is difficult to manage, not easily searchable, hard to maintain, as there is enormous amount
of data handling involved in employee management. All this information is stored in various registers. All
information is handled manually which is really tedious and error prone. There is no organized manner to
perform the searching, registering and other related functions, resulting in redundant and ambiguous data.

As described from the description of existing system or the current system, the system is manual.
Due to that manual system, there are many problems exist in the office. Some of them are listed
below.
 Time consumption to write and edit because of manual system
 There is no network communication between workers.
 It is difficult to search required information’s
 Some manuals can be destroyed by some illegal actions and due to that security data can be
cost.
 Since the existing system is carried on paper, manually an employee must have write on a
sheet of paper for approval from their manager which is so tedious and time consuming.
 Suddenly if the manager absents from work due to some reason, there is no way to get an
information what Is going on and weather an employee arrived on time and working
properly or not.

 Information is stored in written in form of registers. This has many disadvantages, like
checking a record in a register takes more time.
 Registration of employee require more space, since it is manual system.
 Retrieving information from registers is more difficult, like if want to know at what day the
employee was present in particular department or office etc.
 It is difficult to find and modify existing records.
 Current system being manual is more error prone.
 The employee information loses, in case of different problems.
 Redundancy of information
 2.4. Business rule of the current system
Rule 1: Authorize to the system

Users must have a valid user name and password.

Rule2: Correct information

The user checks the filled employee information and the entered information are
correct.
Rule 3: Validate employee information

The authorized user the employee information and the system validates.

Rule 4: the employee does not have a permission to fill attendance twice or more in a day.

Rule 5: the employee must send a leave request to leave.

Rule 6: the employee who is not registered does not allowed to perform any activity.

Rule 7: when the employee does not fill attendance in a manager should manage the employee
attendance.

Rule 8: when the employee register by themselves they have not a permission to fill their position.

Rule 9: when the user registered once, he or she does not have a permission to registered twice
and more.

Rule 10: the employee can access a salary once in a month.

Rule 11: the employee has not responsibility delete, update and manage the activities.

CHAPTER THREE
3. PROPOSED SYSTEM
3.1. Overview
The proposed system is designed to replace the manual system of employee management in to computerized
system and also designed to store the employee information in the database for the purpose of reducing the
problem faced by manual system.
The application composes different forms to enter employee data to the database and retrieve required
employee information from the database.
3.2. Functional requirement
Functional requirement is described as functions or activities that the system provide.
EMS includes the following functional requirements.
New employee registration
Salary calculation and payment.
Attendance management activities such as filling attendance and view the attendance.
 View employee detail
Update employee detail
Leave application management activities such as manage leave and view leave history.
Login and logout
Manage attendance
Leave request
3.3. Nonfunctional requirement
The non-functional requirement describes constrains for implementing the project. Some of them
are; the central server has to be provided at secured area, the system must be maintainable and
expandable, the network infrastructure has to be private network, client machines at each of the
user side must be installed. In each of the each of user there should be technically supporting
people. The user should have also basic computer skills and training should be provided to the
employee on the demo version of the management application. The following non-functional
requirements are included in the system.
 Reliable
The system should be reliable, for handling the occurrence of errors.

 U s ab i l i t y
The users should be able to understand the menu and options provided by the system. The
system shall provide an easy-to-use interface so that the users do not strain to interact with the
system.

 P er f o r m a n c e
The system should respond fast. mostly depends the connection speed and processor of users
‘device.

 A c c es s i b i l i t y & Availability
The system should be up and running whenever needed.
 M a i n t ai n ab i l i t y
The system should include maintenance, since the system failure will dismiss the day of election.

 Security
The system should implement strategies to counter hacking and access by unauthorized
persons/users. The application needs to be secure enough and should enable users to access it
depending on the level of the user. i.e. the user must logged before start any activity.

3.4. Performance Requirements

1. The system is required a fair amount of speed especially while browsing through the catalogue and
presenting different possibilities. The outcomes of the product are not directly influenced by its speed,
 because all the operations are linked to each other and one operation cannot be computed before
the one causing it.
2. The reliability of the system is directly linked to the level of update of the documents to which it is
correlated, such as the catalogue or the employee’s database. The system and the external documents
must be updated constantly according to the necessities of the stakeholders.
3. Robustness or Fault-Tolerance Requirements of the system is disconnected or frozen due to over
access at the same time, it should save all the process of the users have made up to the point of
abnormal happenings. When the users log in with the same id, all the work should be provided.
4. Capacity of system should be able to manage all the information incoming from the database and the
catalogue.
 3.5. System model
3.5.1. Scenarios
Scenario 1
Use case name: registration
Goal: to register employee in the database
Flow event:
1. The employee or the manager open the system
2. The signup menu displayed on the system
3. The user clicks the menu and the registration form is displayed
4. Fill the complete information about his/her detail or the employee
5. Click register button
Exceptional flow:
 If the employee /manager does not fill the correct information, the system notifies the user to enter
the correct information
 The system does not work when there is no connection.
Alternative flow: the employee can register contact physically with the manager.

Scenario 2
Use case name: login
Goal: login to the system
Flow event:
1. The employee or the manager open the system
2. The login form is displayed on the index page.
3. Employee and manager fill the correct username and password.
4. Click login button
5. Logged successfully message is displayed.
Exceptional flow:
 If the employee /manager does register first, the system displays please register first message.
 If the user does not fill the correct username and password the system displays, please fill the correct
username and password message.
 The system does not work when there is no connection.
Alternative flow: none.
Scenario 3
Use case name: Give attendance
Goal: to register the attendance detail in the database.

Flow event:
1. The employee open the system logged in to the employee page by his/her correct username and
password.
2. The attendance menu is displayed on the employee page.
3. The user clicks the attendance menu and the attendance filling form is displayed
4. Fill the complete information about his/her detail or the employee on the attendance form.
5. Click submit button
Exceptional flow:
  If the employee does not fill the correct information in the form the system displays, please fill the
correct information message is displayed.
 If the employee fills their attendance twice in a day, the system displays and the attendance already
filled message is displayed.
Alternative flow: the employee can fill their attendance contact physically with the manager in the
office.

Scenario 4
Use case name: view attendance
Goal: to view the attendance detail of the employee
Flow event:
1. The manager open and logged in to the system.
2. The view attendance menu displayed on the system
3. The user clicks the menu and the form is displayed.
4. Enter the employee name and month.
5. Click view button.
6. The employee attendance detail is displayed.

Exceptional flow:
 If the employee /manager does not fill the correct information, the system notifies the user to enter
the correct information
 The system does not work when there is no connection.
Alternative flow: the employee can view their attendance contact physically with the manager.

Scenario 5
Use case name: View policy
Goal: to view the policy.
Flow event:
1. The user logged in to the system.
2. The view policy menu displayed on the system
3. The user clicks the menu.
4. Finally view the policy.
Exceptional flow:
 The system does not work when there is no connection.
Alternative flow: the employee can view policy by contact physically with the manager.

Scenario 6
Use case name: update record
Goal: to modify the records registered in the database.
Flow event:
 1. The manager open and logged in to the system.
2. The update menu displayed on the system.
3. The user clicks the menu and the form is displayed.
4. The manager enters the information on the update form.
5. Click update button.
6. The detail is updated successfully message is displayed.
Exceptional flow:
 If the manager does not fill the correct information in the form, please error displayed.
 If the manager does not fill the form the system displays, please fill the form message is displayed
 The system does not work when there is no connection.
Alternative flow: none.

3.5.2. Use case model

 Actor identification
Manager/administrator
He or she have all privilege in the system
Employee
 Use case identification
Registration
Delete record
Update record
View information
o View employee detail
o View leave history
o View policy
o View attendance
o View their detail
Manage attendance
o Fill attendance/give attendance

Calculate/pay salary
Give leave request
 Use case diagram
Use case diagrams are graphical representation of overview of behavior of the system. Use case diagram
shows the relationship between the actors and use cases in the system. Technically the use case diagram
helps in defining the boundary of the system. The most important role of a use case diagram is to
communicate the systems functionality and behavior to the customer or end user.
 EMS
registration

manage fill attendance

attendance <<Include>>

calculate/pay login
salary

<<Include>>

logout

give leave request

manage leave

<<extend>> view information

branch manager update record
create branch
<<extend>>

delete record

assign branch
manager
view policy

view employee view leave history view attendance

detail

Fig 3.1. use case diagram for EMS

 Use case description

 Registration
U ID: 01
Use case Name: Registration
Actors: Employee, manager
Pre-condition The employee must have complete information about
his/her selves. i.e. complete data about his/her detail.
Post condition The registered employee must have recorded in the
database. And returns successfully registered message.
Main flow 1. The employee or the manager open the system
2. The signup menu displayed on the system
3. The user clicks the menu and the registration form
is displayed
4. Fill the complete information about his/her detail
or the employee
5. Click register button

Alternative flow The employee can register coming in the university.

Exceptional flow  If the employee /manager does not fill the correct
information, the system notifies the user to enter
the correct information
 The system does not work when there is no
connection.

 Login
U ID: 02
Use case Name: Login
Actors: Employee, manager
Pre-condition The user must be registered in the university first.
Post condition The user logged successfully in to their respective page.
Main flow 1. The employee or the manager open the system
2. The login form is displayed on the index page.
3. Employee and manager fill the correct
username and password.
4. Click login button
5. Logged successfully message is displayed.

Alternative condition
Exceptional condition  If the employee /manager does register first, the
system displays please register first message.
 If the user does not fill the correct username and
password the system displays, please fill the correct
username and password message.

 The system does not work when there is no

connection.

 Give attendance

U ID: 03
Use case Name: Give attendance
Actors: Employee
Pre-condition The employee must be registered first in the database.
Post condition Give full attendance/record the attendance in to the
attendance table in the database.
Main flow 1. The employee open the system logged in to the
employee page by his/her correct username and
password.
2. The attendance menu is displayed on the
employee page.
3. The user clicks the attendance menu and the
attendance filling form is displayed
4. Fill the complete information about his/her detail
or the employee on the attendance form.
5. Click submit button

Alternative flow The employee can fill their attendance in the office.
Exceptional flow  If the employee does not fill the correct information
in the form the system displays, please fill the
correct information message is displayed.
  If the employee fills their attendance twice in a day,
the system displays and the attendance already filled
message is displayed.

 View monthly attendance

U ID: 04
Use case Name: View monthly attendance
Actors: Manager, employee
Pre-condition
Post condition The manager manages the attendance successfully.
Main flow 1. The manager open and logged in to the system.
2. The view attendance menu displayed on the
system
3. The user clicks the menu and the form is displayed.
4. Enter the employee name and month.
5. Click view button.
6. The employee attendance detail is displayed.

Alternative flow
Exceptional flow  If the employee does not fill their own employee
name, the system displays please login first message
is displayed.
 The system does not work when there is no
connection.

 View policy

U ID: 05
Use case Name: View policy
Actors: Manager, employee
Pre-condition
Post condition View the policy of employee management system.
Main flow 1. The user logged in to the system.
2. The view policy menu displayed on the system
3. The user clicks the menu.
4. Finally view the policy.
Alternative flow
Exceptional flow
 The system does not work when there is no
connection.
  Update record

U ID: 06
Use case Name: Update record
Actors: Manager
Pre-condition
Post condition The manager manages the updated record is registered in
the database successfully.
Main flow 1. The manager open and logged in to the system.
2. The update menu displayed on the system.
3. The user clicks the menu and the form is displayed.
4. The manager enters the information on the update
form.
5. Click update button.
6. The detail is updated successfully message is
displayed.

Alternative flow
Exceptional flow  If the manager does not fill the correct information
in the form, please error displayed.
 If the manager does not fill the form the system
displays, please fill the form message is displayed
 The system does not work when there is no
connection.
 Delete record
U ID: 07
Use case Name: Delete record.
Actors: Manager
Pre-condition The information that will be deleted must be registered
before.
Post condition The manager deletes the record successfully.
Main flow 1. The manager open and logged in to the system.
2. The delete menu displayed on the manager page.
3. The user clicks the menu and the form is displayed.
4. Enter the employee number.
5. Click delete button.
6. The record deleted successfully message is
displayed.
Alternative flow
Exceptional flow  If the employee does not fill their
own employee number, the
system displays please the
employee is not registered
message is displayed.
 The system does not work when
there is no connection.
  Salary payment and calculation
U ID: 08
Use case Name: Salary payment and calculation.
Actors: Manager
Pre-condition The employee must be the member of universities
employee.
Post condition o The payment detail is recorded in the employee
database at payment table.
o The employee birr is increased by the birr payed by
the manager.
o The university birr is decreased by the birr payed to
the employee.
o The total salary calculated successfully.
Main flow 1. The manager open and logged in to the system.
2. The calculate salary menu is displayed on the
manager page.
3. The user clicks the menu and the form is displayed.
4. Enter the employee salary payment detail.
5. Click on the total button and the total salary of the
employee is displayed.
6. Click pay button.
7. The payment made successfully message is
displayed.
Alternative flow  The employee can take their salary in the
administrative office.
Exceptional flow  If the manager does not fill the
payment detail, the system
displays please enter the payment
detail displayed.
 If the employee is not registered
in the database, the system
displays the user is not a member.
 If the manager pay salary to the
employee twice in a month, the
system displayed the employee is
already take his or her salary.
 The system does not work when
there is no connection.

 Give leave request

U ID: 09
Use case Name: Give leave request.
Actors: Employee
Pre-condition The employee must be a member.
Post condition The leave request is recorded in the database.
Main flow
 1. The leave request menu displayed on the system.
2. The user clicks the menu and the form is displayed.
3. The employee enters the information on the on
the leave application form.
4. Click send button.
5. The leave request is sent successfully message is
displayed.

Alternative flow
Exceptional flow  If the manager does not fill the correct information
in the form, please error displayed.
 The system does not work when there is no
connection.

 View leave history

U ID: 10
Use case Name: View leave history
Actors: Manager, employee
Pre-condition The user must have username and password.
Post condition The view the leave history detail.
Main flow 1. The user login the system and the view leave
History menu is displayed.
2. The view leave history menu displayed on the
system
3. The user clicks the menu and the form is displayed.
4. Enter the employee name and month.
5. Click view button.
6. The employee leave history detail is displayed.

Alternative flow
Exceptional flow  If the employee does not fill their own employee
name, the system displays please login first message
is displayed.
 The system does not work when there is no
connection.

Manage leave

U ID: 11
Use case Name: Manage leave
Actors: Manager
Pre-condition The employee sends the leave request.
Post condition The manager give permission to the according to the
reason.
Main flow 1. The view leave history menu displayed on the
system.
 2. The user clicks the menu and the employee
request is viewed.
3. The manager clicks on give permission button.
4. The permission form is displayed.
5. The manager enters the leave permission
information on the form.
6. Click send button.
7. The permission is recorded successfully message is
displayed.

Alternative flow
Exceptional flow  If the manager does not fill the correct information
in the form, please error displayed.

 The system does not work when there is no

connection.

a. Object Model
In this section the team discuss all about the object modeling of the system which include identifying class
which the system constitutes and drawing their relationship using class diagram.

i. Data Dictionary
 User is the central object in the EMS module. User have the following information
Identification information includes first name, middle name, Last name and date of birth and place
of birth.
Contact information includes e-mail address, cellular phone.
User authentication information includes user ID, username, and password.

For example:

 Employee
Field name Data type Field size Constraint Description
EmployeeName Char 50 Not null Full name of the employee
Employee No int Not null The identification name of
employee
Username Varchar 50 Primary key Username the employee
Password Varchar 50 Not null Password of the employee
Phone Number Int 20 Not null Mobile or home phone number of
the employee
Address Char 30 Not null Address of the address of the
employee
DateOfBirth Date Not null Birth date of the employee
Sex Varchar 10 Not null Gender of employee
Age Int Not null Age of employee
 Date Of join Date Not null The employee join date
Department Varchar 50 Not null The department of the employee h
e/she works
Table data dictionary for signup/registration/create account

Field name Data type Field size Constraint Description

Username Varchar 50 Primary key username of employee
Password Varchar 50 Not null Password of employee
Table: data dictionary for login
ii. Class Diagram
Class diagram is the main stage of object oriented analysis and design. Class model shows the
relationship including inheritance, aggregation and association, operation and attributes of the class. It
shows the static structure and relationships are participating. The main actions that show on class diagram
are class, object, operation and dependencies.
 UML Class Diagram

login

-username:varchar(50)
-password:varchar(50)

#login()

manager
employee
-ID:varchar(50)
-name:varchar(50) -employeeNumber:int
manages -employeeName:varchar(50)
1
-birthDate:date
1..* -gender:char(10)
+manageLeave() -age:int
+manageAttendance() -dateofJoin:date
+deleteRecord() -Dept:varchar(50)
+updateRecord() -address:varchar(50)
+calculatePaySalary() email:varchar(50)
+viewinfo() -
+viewpolicy() -
+viewattendance()
+fillAttendance()
+giveLeaveRequest()
viewinfo()
manage +viewpolicy()
+viewattendance()
manage fill

pay

leave to
Attendance
-emplo
-applic
y eeNum salary -employeeNumber:int
ationSh ber:int -Date:date
ift:varc h
(50) ar -AbsentDate:int
-leaveT -employeeNumber:int
y pe:varc -InTime:text(50)
-noOfD har(50) -basicPay:double -outTime:text(50)
ay s :int -tax:double
- -shiftCode:int
-spetialPay:double -dept:varchar(50)
-total:double mounth:varchar(50)

-payDate:date
month:varchar(50)

Fig.3.2 class diagram for EMS

b. Dynamic model
6. Dynamic model is represented by sequence diagram, state chart diagram and activity diagram so in the
preceding section we briefly discuss about these diagrams.
3.7.1. Sequence diagram
The following figure shows the high level sequence diagram of the system. The figure shows the
high level interaction of the actors with the system that specifies the work flow the system.

Registration_Fo Registartion_C Employee_

EMS Sign_up_Menu
user rm ontroler abase

Open()
Open_Sign_up_
Menu()
Open_Form()

View_Form()

Fill_Form()
Submit()
Check()

Validate()
Record()

Return_confirmat
ion()
Succesful_Mess
age()

Fig 3.2. sequence diagram for registration

 View_Leave_Hi Permition_Men Permition_Cont
EMS Permition_Form Database
story_Menu u roler

Manager
Log_in()
Click_Menu()
Initiate_Form() Check()

Display_Form() Submit()

Return()
View_History()

Click_Menu()
Initiate()
View_Form()

Fill_Form() Check()
Activate()

Validate()

Record()

Return()

Successful_Mes
sage()

Fig: sequence diagram for manage leave

 EMS Log_in Login_Controler Database`

User

Open()
Open_log_in_For
m()

Display_Form()

Fill_Form()
Submit()

Check()
Validate()
Sent()
Return()
Display_Page()

Fig 3.3. sequence diagram for login

View_Policy_M Policy_Controle
EMS Database
enu r
User
Log_in()
Click_Menu()

Display()

Fig 3.4. sequence diagram for view policy

 View_Leave_re View_History_c View_Leave_Hi
EMS Database
gistry_Form reation_Form story_Controller
User
Log_in()
Click_Menu()
Initiate_Form()

View_Form()

Fill_Form()
Self_Check()
Activate()

Validate()

Fill_Date_Search
()

Return()
Sucessfull_Mess
age()

Fig 3.5. sequence diagram for view leave history

Fill_Attendance Attendance_Fo Attendance_Co Employee_Dat

EMS
_Menu rm ntroller abase
Employee
Log_in()
Click_Menu()
Initiate_Form()

View_Form()

Fill_Form()
Activate() Check_Attendanc
e()
Validate_Form()
Record()

Return()
Sucessful_Mess
age()

Fig 3.6. sequence diagram for fill attendance

 View_Attendan Employee_Dat
EMS View_Form Controller
ce_Menu abase
users
Log_in()
Click_Menu()
Initiate_Form()

View_Form()

Fill_Form()
Activate() Check_Attendanc
e()
Validate_Form()
Record()

Return()
Display_Attenda
nce()

Fig 3.7. sequence diagram for view attendance

Update_Control
EMS Update_Menu Update_Form Database
ler
Manager
Log_in()
Click_on_update
_Menu()
Initiate_Form()

View_Form()

Fill_Form()
Activate() Check_Attendanc
e()
Validate_Form()
Search()

Return()
Sucessful_updat
e_Message()

Fig 3.8. sequence diagram for update record

 EMS Delete Menu Delete Form Delete controller Database

Manager
Log_in()
Click_Menu()
Initiate_Form()

View_Form()

Fill_Form()
Activate() Selfcheck()
Validate_Form()
save()

Return()
Sucessful_Mess
age()

Fig 3.9. sequence diagram for delete record

Payment
EMS Payment Menu Payment Form Database
controller
Manager
Log_in()
Click_Menu()
Initiate_Form()

Display_Form()

Fill_Form()
Activate() Selfcheck()
Validate_Form()
save()

Return()
Payment made
successfully
message()

Fig 3.10. sequence diagram for salary payment/calculation

 View_Leave_Hi Permition_Men Permition_Cont
EMS Permition_Form Database
story_Menu u roler
Manager
Log_in()
Click_Menu()
Initiate_Form() Check()

Display_Form() Submit()

Return()
View_History()

Click_Menu()
Initiate()
View_Form()

Fill_Form()
Check()
Activate()

Validate()

Record()

Return()

Successful_Mes
sage()

Fig 3.11. sequence diagram for manage leave

3.7.2. Activity diagram

The following figure shows the high level sequence diagram of the system. The figure shows the high level
interaction of the actors with the system that specifies the work flow the system.
 EMS

[OPEN]

signup menu

[click menu]

registration form

[fill form]

no
verify

yes

register successfully message

Fig 1.14 activity diagram for registration

 EMS

[open]

loginform

[fill form]

no
verify

yes

user page

Fig 1.15 activity diagram for login

 EMS

[open]

loginform

[fill form]

no
verify

yes

manager page

update form

[fill form]

no
verify

yes

updated successfully

Fig 3.16 activity diagram for update record

 EMS

[open]

login form

fill form

no
verify

yes

users page

[click on the view form]

view form

[fill form]

no
verify

yes

employee information displayed

Fig 3.17 activity diagram for view information

 EMS

[open]

loginform

[fillform]

no
verify

yes

employee page

[click attendance menu]

attendance form

fill form

no
verify

yes

successfull message

Fig 3.17 activity diagram for give attendance

3.7.3. State chart diagram

3.7.4. User interface
1. Login
 3.8. Reference
Chapter four
4. System design
4.1.Overview
Software design is the process of implementing software solutions to one or more set of problems.
One of the important parts of software design is the software requirements analysis (SRA). It is a
part of the software development process that lists specifications used in software engineering.
This is system design of EMS for ASTU. The module consists of the proposed system design and
object design. In this chapter we will try to consider identifying design goal, subsystem
decomposition and identifying the subsystems, hardware/software mapping, persistent data
storage, access control and boundary condition in EMS.
4.2. Purpose of the system
The design focuses on the capabilities, and there can be multiple designs for the same problem
depending on the environment that solution will be hosted. purpose of the software system design
focuses on the architectural system of the proposed systems.it also describes the basic decisions
of the architectural system that are made before (i.e.) it ensures for users, developers of the system
to understand the purpose by method of commonly called visual representation or abstraction. It
also beneficial to implement the system easily.
4.2.1. Design Goal

The goal of software design is dealing with the logical organization of the software which in turn
affects the non-functional requirements. These requirements include:

 P e r f o r m an c e
 D e p e n d a b i l it y
 M a in t a in ab i l it y
  E n d user
4.2.1.1. Performance

The software performs its tasks within a user-acceptable time. The software does
not consume too much memory.
 Response time: Depending the strength of the available network, the
should respond in short period.
 Storage space: To do work efficiently it needs the processor to be 2GB
RAM and above and the HD storage to be 20MB and above.
 Throughput:
4.2.1.2. Dependability

EMS is dependent on some functionalities including:

5. Robustness:
The software is able to operate under stress or tolerate unpredictable or
in valid input. For example, it can be designed with a resilience to low
memory condition.
 Availability: Since the system is scheduled with time and within the period
that it scheduled the system is available 24 hours a day if connection is
available and power is on.
 S e c u r i t y : The software is able to withstand hostile acts and influences.
The user does not perform any activity without login with their own
username and password and one employee cannot see other employee
detail.
4.1.2.3. Maintainability
A measure of how easily bug fixes or functional modifications can be accomplished.
 E x t e n s i b i l i t y : New capabilities can be added to the software without major
changes to the underlying architecture.
 M o d i f i ab i l i t y : The system accepts modification of the functionality or additional
featuring.
 R e u s a b i l i t y : the software is able to add further features and modification with
slight or no modification.
 Portability: the system is developed to be viewed and retrieved from any web browser
regardless of their version and platform it resides in it.
 Readability: the system code can be viewed by clicking on the current web page and
choose “view the source code” option.
4.1.2.4. End user
In online voting system end users/voters/students are those who interact specifically to the
system. So, that the system can achieve usability by the user.

 Utility: - in order to help the user, to easily understand and interact with the system,
the system must provide the following utilities of user requirements
 Mouse over tips
Keyboard alternative
 Usability

Since, online voting system dealing with specific target managing, the software user interface
must be usable for its target user/ end user and also compatible to any environment.

4.2. Proposed system architecture

4.2.1. Overview

The proposed system is expected to replace the existing manual system by web based for EMS which is the
software architecture used for the system is Repository architecture because subsystems access and modify
data from a single data structure which is called the central repository. This architecture allows different user
of the system access the data from center database server.
The central repository of the
central database
registrstion subsystem propuse

employee attendance
insertData()
subsystem
setData()
leave subsystem getData()
searchData()
modifyData()
salary sysbsystem deleteData()

4.2.2. System process

4.2.3. Subsystem decomposition

Subsystem decompositions will help us to reduce/minimizing the complexity of the system. So the team
identifies the following subsystem from the main system:

 Registration subsystem: this subsystem controls the registration of the employee in the
database and creating account to the user and also modifying or updating the employee detail in
the database.
  Attendance application subsystem: this subsystem controls the attendance related activities
such as filling attendance, view attendance detail, and manage attendance activities.
 Leave application subsystem: this subsystem controls the employee leave application activities
such us give leave request, view leave history and manage leave activities.
 Salary payment subsystem: this subsystem controls the salary calculation and payment activities.

attendance
application
subsystem

registration
subsystem attendanceinfo

employee
employeeInfo

leave application
subsystem
payment
subsystem
leaveinfo
employee
employee
salaryinfo
4.2.4. Hardware software mapping
In this section the team discuss about the overall hardware and software organization of the system so
deployment diagram is the important requirement to show system hardware/software mapping.

:webserver

:Laptop
registration
subsystem
webserver
attendance
application
subsystem

leave
application
subsystem
salary
payment
subsystem
 4.2.5. Persistent data management
In this section the team describes how the persistent data stored by the system and the data
management infrastructure required for it. The system will use the MYSQL database server for
storing data or relational database. This will allow the database to be easily integrated with and
accessed by the rest of the system. The database will retain (keep possession of, absorb and hold,
in place, secure the service of) information (name, password etc.), and also retain configuration
data such as authorized administrator. Each of these items will be store in a separate table.

In our system we many tables which are stored in MYSQL server. These are: -

 employee table: a table which store employee information.

 user table: a table which store user account.
 attendance table: a table which contain information about attendance.
 payment: a table which contain related with salary information.
 astu: a table which contain total birr in astu.
 Leave table: a table which contains information about leave record.

44 | P a g e
 4.2.6. Component diagram

client
application server
mozila
firefox

xamp

database server

employeeDB

4.2.7. Deployment diagram

A UML deployment diagram depict a view of run-time configuration of processing nodes and
component that run on those nodes, in other words deployment diagram on those nodes show the
hardware for our system, the software that is installed on that hardware and middle ware used to
connect the disparate machine to another.

In the other case deployment diagrams show how the software components process and objects
are deployed into physical architecture of the system. it shows the configuration of hardware units.

As we mention our project is web based system so there is different protocols that used to
transfer data from one object to another object in the system such as file transfer protocol (FTP)

45 | P a g e
 WEBSERVER
CLIENT

webbrowser registration

attendancce

leave
SQL SERVER

salary
employeeDb
payment

FIG: DIPLOYMENT DIAGRAM

46 | P a g e
 4.2.8. Boundary condition

Admin_AC

manageAttendance startServer

manageLeave stopServer

Manager
manageServer
configureServer

manageEmployee

47 | P a g e
 4.2.9. Database design
E_no B_date Sex Age
Phone

Name
Password
Address City

Name 1 N
Manager Manages Employee
Password E_mail

Join_date
E_no

Leaves
Pays Fills
Receives L_type

Leave

Absent_date

Date E_no
Special_pay

Time Attendance App_shift

Basic_pay Salary

Tax Shift_code
E_no Date
Total E_no

4.2.10. Access control

Each user has a security access level and each document has a sensitivity level. Depending upon
the access level of the user, they will see only the list of documents that is appropriate for their
security access level. Generally, all users have their own user names and passwords to control
security access levels and document sensitivity level.

Object actor registration attendance leave salary payment

updateAccount()
create account() manageAttendance()
manageLeave()
viewEmployeeDetail() viewAttendance() calculateSalary()
manager viewLeaveHistory()
updateEmployeeDetail() deleteAttendance() paySalary()
deleteLeaveHistory()
deleteEmployeeDetail()

GiveLeaveRequest()
register() fillAttendance()
employee viewLeaveHistory() -
viewDetail() viewAttendance()

48 | P a g e
 Chapter Five
5. Testing
5.1. Introduction
Final phase of implementation is testing. Testing is a process to show the correctness of the
program. Testing is checking of the system workability in an attempt to discover errors and
avoiding such errors from the system. In this the group members tested the entire system as a
whole with all forms, code, modules. In this we tested all the functionalities in the System. All
errors in the forms, functions, modules have been tested. The following are different testing
strategies.
5.2. Objective
Testing is a process of executing a program with the intent of finding an error. A good test case
is one that has a probability of finding an as yet undiscovered error. A successful test is one that
uncovers an as yet undiscovered error. Our Objective is to design test processes that
systematically uncover different classes of errors and do so with minimum amount of time and
effort.

5.3. Statement of scope

A description of the scope of the software testing is developed. All the features to be tested are
noted as follows. The basic principles that guides software testing are,

 All test cases should be traceable top employee requirements. The most severe defects from
the employee’s point of view are those that cause the program to fail to meet its
requirements.
 Test case should be planned long before testing begins. Testing plan can begin as soon as
the requirement model is complete. Detailed definition of the test cases can begin as soon
as the design is solidified. Therefore, the entire test can be planned before any code has
been generated.
 Testing should begin “in the small” and progress towards “in the large”. The first test
planned and executed generally focus on the individual modules. As testing progresses
testing shifts focus in an attempt to find errors in integrating clusters of modules and
ultimately in the entire system

49 | P a g e
  Generally, before doing any activity of the system we try to test whether the user is login
or not,
 We also test employee fill attendance once a day or not, the employee salary is payed once
in a month or not, the employee who takes the salary is the member of the university or
not.
5.4. Testing approach
5.5. Test case specification
In this topic we list some of the test cases in our system but not all: these are listed in
the following table.
Test case Id Test case name description Pass/fail
01 Login The user login to the system pass
using their own username and
password. If the username and
password wrong or the user does
not enter the username and
password. the system displays
notification to correct username
and password. Otherwise the
user login to the system.
02 registration To register employee detail in the pass
database. If the data not
correctly filled in the form or the
user pass the form without filling
the system displays error
message. Otherwise registered
successfully message is displayed
03 Fill attendance To test whether the employee fill pass
the attendance successfully or
not. To test whether the
employee is fill the attendance
twice or more a day or not.

50 | P a g e
 To test the employee is register
or login to the system before the
user filling the attendance.

04 Salary payment To test whether salary is payed or pass

not.
To test whether salary is payed
once in a month or not.

05 View detail To test the employee detail is pass

displayed or not
06 Update record To check the user, try to update pass
is modified or not
07 View attendance To test the attendance detail is pass
displayed or not.
To test whether the employee
view other person attendance or
not.

Test case scenario:

Test case ID:01
Test case name: login
Input: username and password
Expected output: login to the system
Produced output: login to the system
Test case ID:02
Test case name: registration
Input: employee detail
Expected output: record created successfully message
Produced output: record created successfully.

51 | P a g e
 Test case ID:03
Test case name: fill attendance
Input: attendance detail
Expected output: attendance filled successfully
Produced output: attendance filled successfully

Test case ID:04

Test case name: salary payment
Input: salary detail
Expected output: payed successfully message employee salary and astu birr database
updated.
Produced output: payed successfully message employee salary and astu birr database
Test case ID:05
Test case name: view detail
Input: employee name and employee number.
Expected output: employee detail
Produced output: employee detail

Test case ID:05

Test case name: 06
Input: employee detail
Expected output: updated successfully message
Produced output: updated successfully message

Test case ID:07

Test case name: view attendance
Input: employee number and month
Expected output: attendance detail.
Produced output: attendance detail.

52 | P a g e