CHAPTER FOUR

DESIGN
4.1 INTRODUCTION
This chapter builds on the work done in the Analysis Chapter and gives documentation for the
Design of the Employee Management System. The EMS is modelled in terms of objects and
classes and their interactions with each other. Explanation of the proposed system is done as well
structure of the Entity Relationship Diagram (ERD). Design of the User Interface is also
discussed.

4.2 EXPLANATION OF THE PROPOSED SYSTEM

The proposed system is designed to eliminate all the drawbacks of the existing employee
management software. The system shall be responsible for maintaining information about
employees, thus their personal profile. The system shall incorporate leave management all the
way from application to acceptance/rejection of leave requests as well as all employee projects
with close monitoring of the projects from creation to completion and trainings to assist in
monitoring active and inactive employees.

The main features to be added include:

 Employee profiles
 Leave management
 Task management
 Trainings
 Projects (Work Breakdown Structure)
 Notifications
 Employee Self-Service (ESS)
4.3 REQUIREMENTS AND CONSTRAINTS
4.3.1 Functional Requirements

Authentication

 Login- The user can login to the HRMS system with his/her username and password.
 Logout- The user can log out from the HRMS system.
 Login failure- If the user does not exist in the database or the user has not yet been
authorized by the HRMS admin.
Authorization
 User role check- After logging in, the user role will be checked from the database and the
user interface will be displayed according to their role.
Process Data
 Display- User with defined roles can display the content of the database. Being more
specific, employee can only view his/her personal information. HOD can not only see
his/her personal information but also employee’s information who are under his/her
department or school. Admin and HR can display their personal information and all
employees’ information.
 Edit- A user with employee role can edit his/her specific personal information. Dean or
HOD can only edit employees’ personal information that is under his/her coverage
except user role type. Admin can edit all information related to all employees’ including
their user role type.
 Search- User with Dean/HOD role can search the content of database for the employees’
who are under his/her coverage. HR and admin roles can search all the employees’
information in the database. Search feature works on specific keywords showing
employee’s characteristics, peculiarities, skills, features, and etc. For example, HR wants
to find employees’ who are well trained in “Java Programming Language”. He/she will
write the specific keyword in the search bar and press the available search button.
Afterwards, he/she will find a list of all the employees’ who know “Java Programming”.
 Update authentication- This feature can be used only by admin role type. Admin can
update the role type of a specific user. For example, an employee got promotion and his
role type will be changed from employee role id to HOD or Dean role. Admin will be
able to update this authentication mechanism.
Leave Application/Approval

 Leave application- The user can be able to fill in leave application form in the
appropriate fields.
 Leave approval- The admin can be able to approve leave applications based on the
reasons stated, length of leave as well as available HR on a department.
 Leave days accrued- The user shall be able to check the number of leave days accrued.
Recruitment
 Add new employee- HR role type is able to add a new employee to the database. The
new employee will have all the required personal information related to him/her. The
new created employee will have an id.
 Add a new user- After a new employee has been created by HR role, admin role is
responsible for creating a new user by the specified id assigned in the “Add a new
employee” feature. The unique id will be given by the system. Admin will assign a new
role such as employee, Dean, HOD, HR, and admin to the new created user.

Report generation

 Report generation- HR shall be able to generate a report in pdf format for each employee
based on the information in the database.

Project Management

 Create project team: The HOD of department or project manager shall be able to create a
project and come up with a project team.
 Work Breakdown Structure (WBS): The HOD or project manager shall be able to assign
tasks to the project team as well as monitor their progress.

Trainings and Task Management

 Trainings: The HOD shall create trainings and assign employees that are required to
attend the trainings as well.
 Tasks: HOD shall assign tasks to employees in his/her department.
4.3.2 Non-Functional Requirements
Performance requirements

 There is no restriction on the number of the users to be added to the database.

Hardware requirements

 EMS should be able to work on a computer with the following minimum hardware
specifications:
 OS: Windows 7/8/10 and Linux
 CPU: Pentium III (700MHz) and above
 Memory: 128 MB and above
 Capacity: 4GB of hard drive
 Others: Network interface card, mouse, keyboard, and monitor.

Software requirements

Since EMS application is a web-based application, internet connection must be established.

The EMS software personal database model will support MySQL environment as DBMS.

4.4 SYSTEM DESIGN

4.4.1 Behavioural Diagrams

4.4.1.1 Activity Diagram

Activity Diagrams are used to model different aspects of a system. And used to describe the
dynamic aspect of the system. Usually, it is an extended version of a flow chart that model the
transition from one activity to another and it shows how system activity are coordinated to
provide a service that are at different level of abstraction. The following activity diagram is used
to model the leave application function.
Activity diagram for leave application
 Leave Acceptance/Rejection

4.4.1.2 Use case analysis

 A use case defines a goal-oriented set of interactions between external users and the system
under consideration or development. Thus, a Use Case Scenario is a description that illustrates,
step by step, how a user is intending to use a system, essentially capturing the system behaviour
from the user's point of view.

In order to create relevant use cases for the system, the following actors for the system have been
identified:

 Employee (could be lecturers, accountants, technicians)

 Head Of Department (HOD)
 Human Resource (HR)
 Admin

Actors, Use Cases and their Description

Actor Use case Description

Employee Edit Profile Employee will be able to edit personal

details such as emergency contacts as
well as technical skills acquired.

Employee Apply Leave Employee will be able to submit leave

request along with supporting
documents.

Employee View The employee will be able to view

tasks, projects and trainings assigned
by the HOD.

Employee Check Leave Status Employee will be able to check leave

days.

Admin Add New Employee Admin will be able to add or create

new employees.

Admin Edit User Role Admin will be able to edit user roles.
Admin Delete Employee Admin will be able to remove or
delete employees from the system.

HOD Assign Task HOD will assign tasks to employees

in his department.

HOD Create Project HOD will able to create projects to

employees in his department.

HOD View Dept Employee HOD will able to see employees in his
department.

HOD Create Trainings HOD will able to create trainings to

employees in his department.

HR Generate Reports HR will be able to generate reports

containing employee information.

HR Salary HR will be able to determine all

employee’s salary.

HR Approve Leave HR will be able to reject or accept

employee’s request.

Table shows: Actor, Use case and Description of all use cases.

Use case diagrams:

Employee Use Case
Admin Use case
Human Resource Use case
HOD Use case
4.4.1.3 Sequence Diagram

Sequence diagrams are interaction diagrams that detail how operations can be formed. They
capture the interaction between objects in the context of collaboration and show how elements
interacts over time and organized with respect to object horizontally and time vertically. So,
Sequence diagrams help in the identification of a detailed level of the operations required to
implement the functionality depicted by a use case model.

Scenario 1: Admin add new employee

1. The Admin logs in by providing correct username and password.

2. If username and password are not found on the database access into the system is denied.

3. If the credentials are identical to the ones found on the database, access is granted.

4. Admin enters the details of the new employee.

5. The Admin input is written to the database.

Add new user sequence diagram

Scenario 3: Employee leaves application
1. The user logs in by providing correct username and password.
2. If the username and password are not found in the database access into the system is denied.
3. If the credentials are identical to the ones found on the database, access is granted.
4. User requests for leave form.
5. User enters leave details.
6. Details are written to the database.
7. A message confirming details have been submitted is displayed to the user.

Employee Leave Application Sequence Diagram

 4.4.2 Structural Diagrams
4.4.2.1 Class diagram

In the class diagram below, the Employee and Admin classes inherit from the User class.
The employee class is also parent class to Human Resource class, Head of Department class
and Ordinary employee class. An ordinary employee may include lecturers, accountants and all
other employees that do not interact with the system with many privileges. These employees carry
out the same operations.

class diagram for employee management system

 CHAPTER 5
IMPLEMENTATION

5.1 INTRODUCTION
This chapter will explore the different aspects concerned with the implementation of the
developed system. This project was concerned with the development and implementation the
employee management system. We began with analysis of the current and proposed systems, the
design of the system to be developed, and in this chapter, we shall deal with implementation of the
developed system.
5.2 DESCRIPTION OF DEVELOPED SYSTEM
The developed system encompasses various activities associated with managing employee
information.
The main functionalities available in this system are:
 Maintaining employee profiles
 Leave management
 ESS
 Task management
 Employee Trainings
 Project Management

All these features include the ability to add user, update (edit), and retrieve through search
results. It also contains a report generation system that can be saved in a pdf file format.

The system works in the following manner:

5.2.1 Accessing the system

Various companies and organizations may have different employee structures and hierarchy.
Being generic, the developed System has four main access levels which are:

 Employee
 Head of Department (HOD)
 Human Resource Manager (HR)
 Administrator
All users are presented with the same login interface except Admin. User and Admin must login
the system by means of valid username/password combination. After access is granted to the
system, the admin can add a new user to the system by entering the basic information which are
the full names and email address. The admin also assigns the new user a role which will
determine the access level. During the process of user registration, the all users are issued with a
unique username and password combination. Seeing that the system holds private employee
information, the admin has the ability to monitor all activity logs into the system by date and
time. The newly added user logs into the system with a default password which can later be
changed to a more secure password. All employees can edit basic information such as newly
acquired technical skills and emergency contacts. Employees can apply for leave by filling in a
form as well as submitting an attachment to support their leave request.

The HOD has the ability to view all employees under his/her department, assign a task and
trainings. The HOD can also create a project, add members to the project and create a work
breakdown structure. Being an employee, the HOD can apply for leave as well as check leave
days accrued.

Upon logging in to the system, the HR manager gets notifications on the leave applications
submitted and has the ability to approve or reject leave requests as they are submitted. The HR
carries out all employee tasks which include the ability to view and edit basic details, view
pending tasks, projects and trainings. The HR also has to the ability to generate employee reports
in PDF format.

5.3 TECHNICAL DETAILS OF IMPLEMENTED SYSTEM

5.3.1 MySQL Triggers

5.3.1.1 Implementation of MySQL Triggers

In MySQL, a trigger is a set of SQL statements that is invoked automatically when a change is
made to the data on the associated table. A trigger can be defined to be invoked either before or
after the data is changed by INSERT, UPDATE or DELETE statements. MySQL allows you to
define maximum six triggers for each table.

 BEFORE INSERT – activated before data is inserted into the table.

 AFTER INSERT- activated after data is inserted into the table.
 BEFORE UPDATE – activated before data in the table is updated.
 AFTER UPDATE - activated after data in the table is updated.
  BEFORE DELETE – activated before data is removed from the table.
 AFTER DELETE – activated after data is removed from the table.

When you use a statement that makes change to the table but does not use INSERT, DELETE or
UPDATE statement, the trigger is not invoked. For example, the TRUNCATE statement
removes the whole data of a table but does not invoke the trigger associated with that table.

There are some statements that use the INSERT statement behind the scenes such as REPLACE
statement and LOAD DATA statement. If you use these statements, the corresponding triggers
associated with the tables if available will be invoked. [1]

5.3.2 System installation

The system was developed and tested on a laptop computer running Windows 10, and the
XAMP Server. In order for the Web application to be accessible via the Internet it will have to
be installed on a Web Server running Apache, PHP and MySQL. The suitable operating system
for the web server will be Linux as it is more stable and less prone to virus but a windows-based
platform will equally do the job just as well. A suitable domain name will have to be chosen and
registered in order for the web application to be accessed via a URL and hosting and
administration fees paid to the web hosting company of choice either annually or monthly
depending on the package and terms agreed upon. The web application will be accessible via
most of the popular web browsers on the market. A suitable web browser e.g., Mozilla Firefox
will have to be installed on the client machine wishing to access the web application. [1]

5.3.3 Algorithms

MD5 Encryption

MD5 algorithm was used for password encryption. MD5 stands for Message Digest algorithm 5
is a widely used cryptographic hash function. The idea behind this algorithm is to take up a
random data (text or binary) as an input and generate a fixed size “hash value” as the output. The
input data can be of any size or length, but the output “hash value” size is always fixed.
5.3.4 Pseudocode

 Login into the system

Start-up system
Enter username and password
On clicking the login button
Connect to database
Query database to know whether user credentials are correct
If not
Deny access and return login page with an error message
If correct
Check if credentials are for administrator
If yes
Allow login
Set admin session
Redirect administrator to admin home page
If no
Allow login
Set user session
Redirect user to user home page

 Add new user

Check if administrator is logged in

If correct
Check if all fields entered are correct
If not
System message: please enter all fields
If correct
Registration of new user successful
 Apply for leave

Check if employee is logged in

If correct
Check if all fields are entered
If not
System message: please enter fields
Check if file has been attached
If not
System message: please attach file
If correct
Leave request has been made
 CHAPTER SIX
TESTING AND VERIFICATION
6.1 INTRODUCTION

Testing is very important and critical to the success of any project that aims at delivering
working software. There are many types of testing that a system may be subjected to, however
only the ones in the testing objectives will be carried out for this system.

6.2 SCOPE

The overall purpose of testing is to ensure the Employee Management System meets all of its
functional and business requirements. The purpose of this chapter is to describe the overall test
plan and strategy for testing the system.

6.3 TESTING GOALS

The goals in testing this system include validating the quality, usability, reliability and
performance of the application. Testing will be performed from a black-box approach. Tests will
be designed around requirements and functionality.

6.4 CONFIRMATION TESTING

Confirmation testing or re-testing: When a test fails because of the defect then that defect is
reported and a new version of the software is expected that has had the defect fixed. In this case
we need to execute the test again to confirm that whether the defect got actually fixed or not.
This is known as confirmation testing and also known as re-testing. It is important to ensure that
the test is executed in exactly the same way it was the first time using the same inputs, data and
environments.

Hence, when the change is made to the defect in order to fix it then confirmation testing or
retesting is helpful.

6.5 REGRESSION TESTING

During confirmation testing the defect got fixed and that part of the application started working
as intended. But there might be a possibility that the fix may have introduced or uncovered a
different defect elsewhere in the software. The way to detect these ‘unexpected side-effects’ of
fixes is to do regression testing. The purpose of a regression testing is to verify that
modifications in the software or the environment have not caused any unintended adverse side
effects and that the system still meets its requirements. Regression testing are mostly automated
because in order to fix the defect the same test is carried out again and again and it will be very
tedious to do it manually. Regression tests are executed whenever the software changes, either as
a result of fixes or new or changed functionality.

6.6 TEST PLANS AND RESULTS

The Test Plan is derived from the Requirements, Functional Specifications, and detailed Design
Specifications. The Test Plan identifies the details of the tests, identifying the associated test
case areas within the product.

Test case Test Purpose Test Condition Expected Actual Result

Outcome

Login Check username If user details are Grant Access to User

and password not correct, the applicable successfully logs
display error main system into the system
message upon submission
of correct login
credentials.

Add new To ensure that a If user already New user should If email address
user new user is added exists in the be successfully entered already
to the system system, error added to the exists in the
successfully. message should system. system, error
display. message is
displayed. If the
email address of
the new
employee does
not exist in the
system, new
employee is
successfully
added.
Edit To ensure that once On the edit When the form is Once the data in
personal different details are personal details altered the details the form is
details provided on the form provide should be altered altered and the
edit personal different in the database submit button
details form and information from and a clicked the
submitted, these what is currently confirmation details in the
details are altered being displayed. message of the database are
in the database to change should be altered and a
reflect the recent displayed. confirmation
changes. message of the
change is
displayed.

Apply leave To test if all Whenever an Leave request Leave request is

employees can employee applies should be sent submitted as
successfully apply for leave, when all required required and a
for leave. information as fields are message of
well as submitted and success is
attachments necessary displayed.
should be documents have
submitted to the being attached to
HR manager. the request.

Create Test if a Head of Whenever a A project should Project is

project Department can project is created, be created as well created and
create a project and HOD should be as coming up HOD can view
later assign a able to assign with a project the project team.
project team. project team and team and WBS.
view members.

View Test if employee is If employee has Notifications Notifications

notification notified when leave being added to a should be appear on the
s has being accepted project, he/she displayed on the employee
or rejected and should get a employee interface.
when new tasks, notification. interface
 trainings or whenever a task
projects have being has been
assigned. assigned;
employee has
been added to a
project team
project, or
trainings. As well
as when a leave
request has been
accepted or
rejected.

Upload Test if users can Employee should Employee is able Message of

picture upload a profile be able to upload to upload profile success is
picture associated a profile picture if picture. displayed when
to their account. they so wish. employee
uploads picture
and they are
asked to log out
and back in for
changes to take
place.

Generate Test if HR can To ensure that the Once a choice of When the choice
reports generate employee selected report is report is made by of report is made
reports. displayed. clicking the link and link clicked
of choice the a report is
report should be displayed.
displayed.

6.7 SUMMARY
The chapter discussed how the proposed system was subjected to various types of testing. This
brought to light why it is very cardinal to test a new system before it is introducing on the main
stream of an organization’s business.

CHAPTER SEVEN

CONCLUSION

7.1 INTRODUCTION
The aim of this chapter is to draw conclusions of the work done or achieved and to give an
assessment of the completed system, discuss the Problems faced, limitations of the system and
give future recommendations on how the system can be improved.

7.2 RESULTS

The software product produced was fairly good, it achieved most of the user requirements, the
user interface is good and is very easy to navigate, and even novice users can find their way
around the web application easily. The client-side validation is excellent. The lack of integration
with a payroll system is the major drawback and the system was also unable to generate
structured reports i.e., reports based on specific information the Human Resource is interested in.