Employee Management System For ASTU

Employee management system for ASTU .........................................................................................................................
4
Chapter -1 .......................................................................................................................................................................... 4
1.1. Introduction ....................................................................................................................................................... 4
1.2. Background ........................................................................................................................................................ 4
1.3. Statement of problem ....................................................................................................................................... 4
1.4. Purpose .............................................................................................................................................................. 5
1.5. Objective of the project ..................................................................................................................................... 5
1.5.1. General objective ....................................................................................................................................... 5
1.5.2. Specific objective ....................................................................................................................................... 5
1.6. Feasibility study ................................................................................................................................................. 6
1.6.1. Economic Feasibility................................................................................................................................... 6
1.6.2. Technical Feasibility ................................................................................................................................... 6
1.6.3. Operational feasibility................................................................................................................................ 6
1.7. Scope and limitation .......................................................................................................................................... 6
1.7.1. Scope .......................................................................................................................................................... 6
1.7.2. Limitation ................................................................................................................................................... 7
1.8. Significance of the project ................................................................................................................................. 7
1.9. Operating environment ..................................................................................................................................... 7
TOOLS USED Front end (PHP) ................................................................................................................................ 8
1.10. Methodology.................................................................................................................................................. 9
1.10.1. Method of data collection ......................................................................................................................... 9
1.10.2. Methodology for the system design and development .......................................................................... 10
1.11. Testing procedure ........................................................................................................................................ 10
1.11.1. Unit testing .............................................................................................................................................. 10
1.11.2. Integration testing ................................................................................................................................... 10
1.12. Team composition ....................................................................................................................................... 11
1.13. Task and Schedule........................................................................................................................................ 11
1.13.1. schedule ................................................................................................................................................... 11
1.13.2. Team member’s activity........................................................................................................................... 12
1.14. Definition, acronym, and abbreviation .................................................................................................... 12
1.14.1. Definition ................................................................................................................................................. 12
1.14.2. Acronym ................................................................................................................................................... 12
1.15. Reference ..................................................................................................................................................... 12
Chapter Two:.................................................................................................................................................................... 12
1|Page
2. Description of the existing system ........................................................................................................................... 12
2.1. Major function of the current system ............................................................................................................. 13
2.2. Users of the current system............................................................................................................................. 13
2.3. Drawback of current system ............................................................................................................................ 13
2.4. Business rule of the current system ................................................................................................................ 14
CHAPTER THREE ............................................................................................................................................................... 15
3. PROPOSED SYSTEM .................................................................................................................................................. 15
3.1. Overview .......................................................................................................................................................... 15
3.2. Functional requirement ................................................................................................................................... 15
3.3. Nonfunctional requirement ............................................................................................................................. 15
3.4. Performance Requirements ............................................................................................................................. 16
3.5. System model ....................................................................................................................................................... 17
3.4.1. Scenarios .................................................................................................................................................. 17
3.4.2. Use case model ........................................................................................................................................ 19
3.5. Object Model ................................................................................................................................................... 26
3.5.1. Data Dictionary ........................................................................................................................................ 26
3.5.2. Class Diagram ........................................................................................................................................... 27
3.6. Dynamic model ................................................................................................................................................ 28
3.6.1. Sequence diagram ................................................................................................................................... 28
3.7.1. Activity diagram ....................................................................................................................................... 36
3.7.2. State chart diagram.................................................................................................................................. 41
3.7.3. User interface .......................................................................................................................................... 45
3.8. Reference ......................................................................................................................................................... 48
Chapter four ..................................................................................................................................................................... 49
4. System design .......................................................................................................................................................... 49
4.1. Overview .......................................................................................................................................................... 49
4.2. Purpose of the system ..................................................................................................................................... 49
4.2.1. Design Goal .............................................................................................................................................. 49
4.3. Proposed system architecture ......................................................................................................................... 50
4.3.1. Overview .................................................................................................................................................. 51
4.3.2. System process ........................................................................................................................................ 52
4.3.3. Subsystem decomposition ....................................................................................................................... 52
4.3.4. Hardware software mapping ................................................................................................................... 54
4.3.5. Persistent data management................................................................................................................... 55
4.3.6. Component diagram ................................................................................................................................ 55
4.3.7. Deployment diagram ............................................................................................................................... 56
2|Page
4.3.8. Boundary condition ................................................................................................................................. 57
4.3.9. Database design ....................................................................................................................................... 58
4.3.10. Access control .......................................................................................................................................... 59
References ................................................................................................................................................................... 59
Chapter Five ..................................................................................................................................................................... 59
5. Testing...................................................................................................................................................................... 59
5.1. Introduction ..................................................................................................................................................... 59
5.2. Objective .......................................................................................................................................................... 60
5.3. Statement of scope .......................................................................................................................................... 60
5.4. Testing approach ............................................................................................................................................. 60
5.4.1. Unit testing .............................................................................................................................................. 60
Table Test Case1 –for User login............................................................................................................................. 61
Test Case2: for registration...................................................................................................................................... 64
5.4.2. Integration testing ....................................................................................................................................... 64
5.5. Test case specification ..................................................................................................................................... 65
Test case scenario .................................................................................................................................................... 66
Chapter 6 ......................................................................................................................................................................... 68
6.Implementation ............................................................................................................................................................ 68
6.1. Overview .......................................................................................................................................................... 68
6.2. Tool and technology utilized during System development ............................................................................. 68
6.3. Implementation detail .......................................................................................................................................... 68
7. Conclusion................................................................................................................................................................ 78
8. Recommendation..................................................................................................................................................... 79
References ....................................................................................................................................................................... 79
3|Page
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:
4|Page
 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 whether 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
5|Page
 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, 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
6|Page
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
7|Page
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))
8|Page
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.
9|Page
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.
10 | P a g e
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.12. Team composition
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
11 | P a g e
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
12 | P a g e
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
13 | P a g e
 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.
14 | P a g e
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
Create branch
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.
15 | P a g e
 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.
16 | P a g e
3.5. System model
3.4.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.
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.
17 | P a g e
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
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:
18 | P a g e
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.
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
Alternative flow: none.
3.4.2. Use case model

 Actor identification
Manager/administrator
branch Manager
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
19 | P a g e
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 employee
create branch
<<extend>> view information
branch manager update record
<<extend>>
delete record controlSystem
view policy
assign branch
view employee view leave history view attendance
manager manager
detail
Fig 3.1. use case diagram for EMS

 Use case description
 Registration
U ID: 01
Use case Name: Registration
Actors: Employee, branch manager, 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
20 | P a g e
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 system does not work when there is no
connection.
 Login
U ID: 02
Use case Name: Login
Actors: Employee, manager, branch 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.

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.
21 | P a g e
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: Branch 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
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.
connection.
 View policy
U ID: 05
Use case Name: View policy
Actors: Manager, employee, branch manager
Pre-condition
Post condition View the policy of employee management system.
Main flow 1. The user logged in to the system.
22 | P a g e
2. The view policy menu displayed on the system
3. The user clicks the menu.
4. Finally view the policy.
Alternative flow
Exceptional flow
connection.
 Update record
U ID: 06
Use case Name: Update employee record
Actors: branch manager
Pre-condition
Post condition The manager manages the updated record is registered in
the database successfully.
Main flow 1. The manager opens and logged in to the system.
2. The update menu displayed on the system.
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
connection.
 Delete record
U ID: 07
Use case Name: Delete employee record.
Actors: branchManager
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.
23 | P a g e
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: Branch 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 opens and logged in to the system.
2. The calculate salary menu is displayed on the
manager page.
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
24 | P a g e
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.
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
connection.
 View leave history

U ID: 10
Use case Name: View leave history
Actors: Branch 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
6. The employee leave history detail is displayed.
Alternative flow
Exceptional flow  If the employee does not fill their own employee
25 | P a g e
name, the system displays please login first message
is displayed.
connection.
 Manage leave
U ID: 11
Use case Name: Manage leave
Actors: Branch 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

connection.
3.5. 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.
3.5.1. 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.
26 | P a g e
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
3.5.2. 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.
27 | P a g e
user
-username:varchar(50)
-password:varchar(50)
+login()
+logout()
includes
branchmanager Employee
Manager
-managerNo:int -employeeNo:int
-managerName:varchar(50) -employeeName:varchar(50)
-dateofbirth:date -dateofbirth:date
-gender:varchar(10) -gender:varchar(10)
-dateofjoin:date -dateofjoin:date
+createbranch() -depatment:varchar(50) -depatment:varchar(50)
+viewBranchDetail() -phone:int
+deleteBranch() -address:varchar(50) -address:varchar(50)
+updateBranch() -branchnmae:varchar(50) -branchnmae:varchar(50)
-email:varchar(50) -email:varchar(50)
1 +addEmployee() +fillAttendance()
+viewDetail() +Register()
create * +paySalery() +viewAttendance() give *
+updatedetail() +viewpersonalDetail() 1
+deleteDetail() +viewPolicy()
+viewAttendance() +viewLeaveHistory() Attendance
+viewLeaveHistory()
* * -employeeCode:int
1 manages applay employeeName:varchar(50)
1 1
-month:varchar(50)
pays Leave -absecentDate:date
* intime:text
-employeeCode:int
salary outtime:text
employeeName:varchar(50)
shiftCode:int
-ApplicationShift:varchar(50)
-employeeNO:int dept:varchar(50)
-leaveType:varchar(50)
employeeName:varchar(50)
-NoDays:int
-basicpay:double
-tax:double
-specialPay:double
-total:double
-paidDate:date
-month:varchar(50)
Fa
Fig.3.2 class diagram for EMS
3.6. Dynamic model

Dynamic model is represented by sequence diagram, state chart diagram and activity diagram so in the
preceding section we briefly discuss about these diagrams for some usecases .
3.6.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.
28 | P a g e
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()
Succesful_Mess
age()
Fig 3.2. sequence diagram for registration
29 | P a g e
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
30 | P a g e
Login_Controlle
login interface Log_in Database`
r
User
1.Open()
2.Open_log_in_F
orm()
3.Display_Form()
4.Fill_Form()
5. Submit()
6.Check()
7.Validate()
8.Sent()
10.Display_Page
()
Fig 3.3. sequence diagram for login
View_Policy_M Policy_Controle
EMS Database
enu r
User
1.Log_in()
2.Click_Menu()
3.Display()
31 | P a g e
Fig 3.4. sequence diagram for view policy
employeeInterfa Fill_Attendance Attendance_Fo Attendance_Co Employee_Dat

ce _Menu rm ntroller abase Fig 3.5.
Employee sequence
1.Log_in()
diagram for
view leave
2.Click_Menu()
history
3.Initiate_Form()
4.View_Form()
5.Fill_Form()
6.Activate() 7.Check_Attendan
ce()
8.Validate_Form
() 9.Record()
32 | P a g e 10.Sucessful_Me
ssage()
Fig 3.6. sequence diagram for fill attendance
attendance View_Attendan Employee_Dat

View_Form Controller
interface ce_Menu abase
users
1.Log_in()
2.Click_Menu()
3.Initiate_Form()
4.View_Form()
5.Fill_Form()
5.Activate()
6.Check_Attendan
ce()
7.Validate_Form
() 8.Record()
9.Display_Attend
ance()
Fig 3.7. sequence diagram for view attendance
33 | P a g e
branchManager Update_Control
Update_Menu Update_Form Database
Interface ler
branchManager
1.Log_in()
2.Click_on_upda
te_Menu()
3.Initiate_Form()
4.View_Form()
5.Fill_Form()
6.Activate() 7.Check_Attendan
ce()
8.Validate_Form
()
9.Search()
10.Sucessful_up
date_Message()
Fig 3.8. sequence diagram for update record
34 | P a g e
branchManager Delete controller
Delete Menu Delete Form Database
Page
Manager
1.Log_in()
2.Click_Menu()
3.Initiate_Form()
4.View_Form()
5.Fill_Form()
6.Activate() 7.Selfcheck()
8.Validate_Form
()
9.save()
10.Sucessful_M
essage()
35 | P a g e
Fig 3.9. sequence diagram for delete record
branchManager Payment
Payment Menu Payment Form Database
Interface controller
branchManager
1.Log_in()
2.Click_Menu()
3.Initiate_Form()
4.Display_Form()
5.Fill_Form()
6.Activate() 7.Selfcheck()
8.Validate_Form
() 9.save()
10.Payment
made
successfully
message()
Fig 3.10. sequence diagram for salary payment/calculation
3.7.1. 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.
36 | P a g e
EMS
[OPEN]
signup menu
[click menu]
registration form
[fill form]
no
verify
yes
register successfully message
Fig 1.14 activity diagram for registration
37 | P a g e
EMS
[open]
loginform
[fill form]
no
verify
yes
user page
Fig 1.15 activity diagram for login
38 | P a g e
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.16 activity diagram for view record
39 | P a g e
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
40 | P a g e
3.7.2. State chart diagram
EMS
registration menu
registration form
fill form
validate
registered
state chart diagram for registration
41 | P a g e
login
branch managermanager page
update menu
update form
fill form
validate
registered
state chart update record
42 | P a g e
login
employee
page
leave menu
leave form
fill form
validate
successfull
State chart employee leave
43 | P a g e
login
employee
page
give attendance
menu
attendance form
fill form
validate
filled successfully
State chart diagram for attendance
44 | P a g e
login
branchmanagerpage
salary payment menu
salary payment form
fill form
validate
successfull
State chart diagram for payment
3.7.3. User interface
45 | P a g e
Employee page
Manager page
Homepage
46 | P a g e
Login
Registration
47 | P a g e
Attendance
3.8. Reference

 And we used also online notice board project documentation which is prepared
last year.
2012_2
48 | P a g e
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
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.
49 | P a g e
Dependability
EMS is dependent on some functionalities including:

 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.
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.
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.3. Proposed system architecture
50 | P a g e
4.3.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 client server architecture because client request services from the
server and the server provides service to the client.
EMPLOYE
LAN E DATABA
EMPLOYEE MANAGEMENT SYSTEM FOR ASTU
SE
SYSTEM USER
APPLICATION
SCRIPTING
SERVER WEB SERVER
ENGINE
51 | P a g e
4.3.2. System process
https
request
internet connection
https
client output
database
server
4.3.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.
 Employee management system: to control all the system.
52 | P a g e
employee
management
system subsystem
employee
management info
attendance
application
subsystem
registration
subsystem attendanceinfo
employee
employeeInfo
leave application
subsystem
payment
subsystem
leaveinfo
employee
employee
salaryinfo
Subsystem decomposition
53 | P a g e
4.3.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
54 | P a g e
4.3.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.
4.3.6. Component diagram
server
laptop
database
browser
55 | P a g e
4.3.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)
WEBSERVER
CLIENT
webbrowser registration
attendancce
leave
SQL SERVER
salary
employeeDb
payment
FIG: DIPLOYMENT DIAGRAM
56 | P a g e
4.3.8. Boundary condition
System
manage server start server
stop server
manager
manage system
configer server
57 | P a g e
4.3.9. Database design
ERD
specialpay total
tax date email city
age
employee Id
basicpay
Name
phone
salary
address bDate
employeeId
N
employee
managerid to
sex
password
time
manages ShiftCode
manager Date
username pays Belong
attendance
create employeeId
absentDate
organization name manager Id

N 1
gives leave
manager Id branch manager
manager Id
Name
sex
employeeId NoOfdays
branchName
phone
leave type AppShift
employeeid
58 | P a g e
4.3.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 salary leave
-createBranch()
-AddBranceMan()
manager - - -
-deletebranch()
-updateBranch()
-giveAttendance()
-request()
employee -viewTheirDetail() -viewMonthlyAttendance -view()
-view()
()
-AddEmployee() -pay()
-give()
-deleteEmployee() -View()
branchmanager -viewAttendanceReport() -delete()
-updateEmployee() -delete()
-view()
-viewEmployeeDetail() -update()
References
 And we used also online notice board project documentation which is prepared last
year.
2012_2
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
59 | P a g e
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. generally, the main objective of testing is finding faults.
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
 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.4.1. Unit testing

Black box testing
60 | P a g e
we are going to test login and registration use case using unit testing as a sample
Test Case ID = ORS– TestCase1
Unit to Test = Authentication of login users
Assumptions = Login into appropriate page
Test Data = User Name (empty, invalid user Name, valid user Name)
Password (empty ,invalid password, valid password)
STEPS TO BE EXECUTED Data Expected Results
Empty User Name and Click Login

Any valid data for the other fields “Please enter User
button
Name ”
User Name=habtamu wubneh

Enter invalid User Name and Click Doesn’t exist in the user account “Invalid Username or
Login button table Password.
Any valid data for the other fields Please Enter Again ... ”
Enter valid user Name ,empty Username= habtamu wubneh

Password and Click Login button “Please Enter
Any valid data for the other fields
Password”
User Name =habtamu wun

Enter User Name, invalid Password bneh “Please Enter
and Click Login button Password =habta@2w Password Again! Max
Any valid data for the other fields length 8
Enter valid User ID and Password then “Login in to

All fields Fulfill with valid data approprate page”
Click Login button
Table Test Case1 –for User login

Test Case ID = ORS – Test Case2
Unit to Test = Create Account
Assumptions= The user account is created
61 | P a g e
Test Data= First name (empty ,invalid First name, Valid First name)
Phone number ( empty)
Gender ( empty)
address (empty)
Region (empty)
email ( empty ,Invalid email, Valid email)
Password ( empty ,Invalid Password, Valid Password)
Steps to be Executed Data Expected Results
Empty First name and Click Any valid data for the other fields “Please enter first
create button name!”
Invalid First name and Click name=kalyu “Please Enter again!
create button Any valid data for the other fields Your first name must
have only letters”.
Enter valid First Name, name= kalayu “Please Enter Your Last
empty Last Name Click Any valid data for the other fields Name!”
create button
Enter First name, invalid Last name= kalayu “Please Enter again!
Name and Click create Any valid data for the other fields Your Last Name must
button have only letters”
Enter Valid First name, and name= kalayu “Please Enter Your
Last Name, empty Email and Email!”
Click create button Any valid data for the other fields
Enter Valid First name, and name= kalayu “Please Enter Your
Last Name, invalid Email and Email Again! You have
Click create button Email address=kaleweet21.com entered an invalid
Any valid data for the other fields email address!”
Enter Valid First name, Last name= kalayu “Please Select your
Name and Email, empty Email country from the
country and Click create address=kaleweet21@gmail.com list.
button Any valid data for the other fields
Enter Valid First name, Last name= kalayu
Name, Email and country
,empty Region and Click Email “Please enter your
create button address=kaleweet22@gmail.com address .”
address=ETHIOPIAN
Name, Email, country and Email
Region, empty Phone address=kaleweet21@gmail.com
Number and Click create address =ETHIOPIAN
button Any valid data for the other fields “Please Enteryour
Phone Number!”
62 | P a g e
Name, Email, country and Email
Region, Invalid Phone address=kaleweet21@gmail.com
Number and Click create country=ETHIOPIAN
button Phone No=+251914790868Any
valid data for the other fields
“The Phone Number is
already exist,please
enter Phone Number
again”
Name, Email, Country Region Email
and Phone Number ,empty address=kaleweet21@gmail.com “Please Select your
Gender and Click create Country=ETHIOPIAN Gender from the
button Region=Amhara list.”
Phone No=+251914790868

Name, Email, Country Region Email
and Phone Number ,empty address=kalesweet21@gmail.com
Password and Click create Country=ETHIOPIAN
button Region=Tigray
Gender = M
Phone No=+251914790868
“Please Enter
Any valid data for the other fields Password”
Enter Valid name, Name, name= kalayu

Email, address, and Phone Email
number, Invalid Password address=kalesweet21@gmail.com
and Click create button address=ETHIOPIAN
Phone No=+251914790868
Password=kale12love
Any valid data for the other fields “Please Enter
Password Again! Max
lenget 8”
63 | P a g e
Enter Valid First name, Last
Name, Email, Country
Region, Phone number and All fields Fulfill with valid data
Password and Click create
button “The user account is
created”
Test Case2: for registration
5.4.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:
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.
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.
 Testing includes
 Verification and Validation
 Verification: -is a process of confirming that software meets its specification.
 Validation: - is the process of confirming that software meets the customer’s
requirements.
c) Validation Testing
Validation succeeds when software functions in a manner that can be reasonably expected by the
customer. It covers the following: -
Validation test criteria: Performance, functional characteristics and uncovered deviation from
specification
64 | P a g e
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 Test case name Description Pass/fail
Id
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 Pass
the 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 Pass
fill the attendance successfully
or not. To test whether the
employee is fill the attendance
twice or more a day or not.
To test the employee is
65 | P a g e
register or login to the system
before the user filling the
attendance.
04 Salary payment To test whether salary is payed Pass

or 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 Pass
update is modified or not
07 View To test the attendance detail is Pass
attendance displayed or not.
To test whether the employee
view other person attendance
or not.
Test case scenario:

In the following scenario we are documenting the some of test cases as a sample
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
66 | P a g e
Test case name: registration
Input: employee detail
Expected output: record created successfully message
Produced output: record created successfully.
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: update record
Input: employee detail
Expected output: updated successfully message
67 | P a g e
Produced output: updated successfully message
Chapter 6
6.Implementation
6.1. Overview
Implementation is the final and the most important phase of Software
development life cycle(SDLC) since obtaining a working software product is
the main objective of software development. Without implementation the
whole effort made will be vain since the other phases are intended to help
the implementation phase. It includes interface implementation and most
importantly, coding.
6.2. Tool and technology utilized during System development
We use different tools and technologies for the development of Online Ordering System. The
bulk of these tools are webpage development tools. There are also stand-alone application
development tools but their use is not substantial. We use the latest version of these
development tools to increase technological capacity. The major software development tools to
be used to develop the system are:
- WAMP server (which has MYSQL, PHP and APACHE embedded inside it) and editor
(sublime, notepad++ and bracket) is the main development tool for our system since the
system to be developed is web based system.
6.3. Implementation detail

User Login
<?php
session_start();
?>
<?php
//create connection
$con=mysqli_connect("localhost","root","","employee");
68 | P a g e
//check connection
if(mysqli_connect_errno()){
echo "Failed to connect".mysqli_connect_errno();
}
$username=$_POST["username"];
$password=$_POST["password"];
$result=mysqli_query($con,"SELECT * FROM users WHERE username='$username' and

password='$password'");
if (mysqli_num_rows($result)>0) {
while($row=mysqli_fetch_array($result)){
$Position=$row["dept"];
$username=$row["username"];
$branch=$row["branchName"];
$_SESSION["branchName"]=$branch;
if($Position=="manager"){
$_SESSION["username"]=$username;
$_SESSION["dept"]=$Position;
header("location:manager.php");
}else if ($Position=="branchmanager") {
69 | P a g e
header("location:branch.php");
}else if ($Position=="employee") {
header("location:employee.php");
}else{
header("location:index.php");
}
}
}
else if ($username==""||$password==""){
echo "<script>alert('the username is not registerd');
</script>";
}
else{
echo "<script>alert('the username is not registerd');
window.location.href=('registeration.php')
</script>";
}
mysqli_close($con);
?>
Employee registration
70 | P a g e
<?php
if (isset($_POST['submit'])) {
error_reporting(1);
$servername = "localhost";
$username = "root";
$password = "";
$dbname = "employee";
// Create connection
$conn = mysqli_connect($servername, $username, $password, $dbname);
// Check connection
if (!$conn) {
die("Connection failed: " . mysqli_connect_error());
}
$_name=$_POST['Ename'];
$_no=$_POST['employeeno'];
$pass=$_POST['password'];
$_bd=$_POST['Bdate'];
$_gender=$_POST['gender'];
$_dj=$_POST['Djoin'];
$_dep=$_POST['Dept'];
$addr=$_POST['address'];
$pos=$_POST["branchName"];
$phone=$_POST['ph'];
$email=$_POST['image'];
if
($_no==""||$pass==""||$_bd==""||$_gender==""||$_dj==""||$_dep==""||$addr==
""||$phone==""||$email=="") {
71 | P a g e
echo "<script> alert('please enter the data')</script>";
}
else if ($phone.length<10) {
echo "<script> alert('please enter 10 digit')</script>";
# code...
}
else if (filter_var($email, FILTER_VALIDATE_EMAIL)==false){
echo "<script> alert('invalid email')</script>";
}
else{
$q="select * from employee where employeeNO='$_no' ";

$rs=$conn->query($q);
if($rs->fetch_row()>0)
{
echo "<script> alert('already registered')</script>";
}
else
{
$sql=$q="select * from branchmanager";
$qr=$conn->query($sql);
while($row = $qr->fetch_assoc()) {
$br=$row["branchName"];
}
72 | P a g e
$sql="INSERT into employee
(employeeNO,password,employeeName,birthDate,gender,dateOfJoin,dept,address,
email,position,phone)
VALUES ('$_no', '$pass',
'$_name','$_bd','$_gender','$_dj','$_dep','$addr','$email','$pos','$phone')";
if (mysqli_query($conn, $sql)) {
} else {
echo "Error: " . $sql . "<br>" . mysqli_error($conn);
}
$sq="INSERT into users (username,password,dept,branchName)
VALUES ('$_name', '$pass', '$_dep','$pos')";
if (mysqli_query($conn, $sq)) {
echo "<script> alert('registration made successfully')</script>";
}
else {
echo "Error: " . $sq . "<br>" . mysqli_error($conn);
}
}
}
mysqli_close($conn);
}
?>
Attendance
<?php
if (isset($_POST['register'])) {
73 | P a g e
$username = "root";
$password = "";
// Check connection
if (!$conn) {
}
$_name=$_SESSION['username'];
$_no=$_POST['Ecode'];
$_d=$_POST['dt'];
$_at=$_POST['At'];
$_it=$_POST['It'];
$_ot=$_POST['Ot'];
$sc=$_POST['shiftcode'];
$_dep=$_POST['Dept'];
$mounth=$_POST['date'];
if
($_no==""||$_name==""||$_d==""||$_at==""||$_it==""||$_ot==""||$sc==""||$_d
ep=="") {
echo "<script> alert('please enter the data')</script>";
}
else{
$q="select * from employee where employeeNo='$_no' and

employeeName='$_name' ";
74 | P a g e
$rs=$conn->query($q);
if($rs->fetch_row()>0)
{
$qr="select * from attendance where employeeNO='$_no'and dateTime='$_d'";

$rstt=$conn->query($qr);
if($rstt->fetch_row()>0)
{
while($row=$rstt->fetch_assoc()){
$date=$row['dateTime'];
}
echo "<script>alert('attendance filled already')</script>";
}
else{
$sql="INSERT into attendance
(employeeNO,employeeName,dateTime,absentDate,inTime,outTime,shiftcode,dept,
month)
VALUES ('$_no', '$_name','$_d','$_at','$_it','$_ot','$sc','$_dep','$mounth')";
echo "<script>alert('attendance filled successfully')</script>";
} else {
echo "Error: " . $sql . "<br>" . mysqli_error($conn);
}
}
75 | P a g e
else {
echo "<script>alert('pls register and login first b/c the employee is not
registered')</script>";
}
}
mysqli_close($conn);
}
?>
View employee detail
<?php
$username = "root";
$password = "";
// Check connection
if (!$conn) {
}
$sql = "SELECT * FROM employee";
$result = $conn->query($sql);
if ($result->num_rows > 0) {
echo "<table bgcolor='white'
border='1'><tr><th>Code</th><th>Name</th><th>dateofbirth</th><th>gender</th
76 | P a g e
><th>dateofjion</th><th>position</th><th>department</th><th>address</th><th>
E-mail</th><th>delete</th><th>update</th></tr>";
// output data of each row
while($row = $result->fetch_assoc()) {
$no=$row['employeeNo'];
echo "<tr>
<td>".$row["employeeNo"]."</td><td>".$row["employeeName"]."</td><td>".$row[
"birthDate"]."</td><td>".$row["gender"]."</td><td> ".$row["dateOfJoin"].
"</td><td>".$row["dept"]."</td><td>".$row["position"]."</td><td>".$row["address"
]."</td><td>".$row["email"]."</td>
<td>"."
<form method='post' action=''>
<input type='submit' name='delete' value='delete' class='delete'>
</form>
</td>
<td>
<form action='update.php' method='post'>

<input type='submit' name='update' value='update' class='update'>
</form>
</td>
</tr>";
}
echo "</table>";
77 | P a g e
} else {
echo "0 results";
}
if(isset($_POST['delete'])){
error_reporting(0);
$sql = "DELETE FROM employee WHERE employeeNo='$no'";
}
$sq = "DELETE FROM users WHERE employeeNO='$no'";
if (mysqli_query($conn, $sq)) {
}
else if (isset($_POST['update'])) {
echo"<script>window.location.href=('update.php')</script>";
}
}
$conn->close();
?>
7. Conclusion
The objective of this project was to build a web based program for EMS FOR ASTU in
order to manage employees safely and securely. The system developed is able to meet all
the basic requirements. It will provide the facility to the end-user and staffs members of
the office. The EMS OF ASTU will be also benefited by the proposed system, as it will
automate the whole procedure, which will reduce the workload. The security of the
system is also one of the prime concerns.
There is always a room for improvement in any software, however efficient the system
may be. The important thing is that the system should be flexible enough for future
78 | P a g e
modifications and to maintain. Every effort has been made to cover all user requirements
and make it user friendly.
8. Recommendation
The project team wants to recommend some ideas considering the project. This project is
developed based on the current problems of employee management system of ASTU, so we
think that this project is the best solution for the problems raised based on the manual system of
the office. And help the office to save time, money and man power whenever the project is small
scale. Finally, the project teams conclude that the department should give a special consideration
for the computer lab, because during the development of the project the group members faced
some problems based on the lab.
References
 And we used also online notice board project documentation which is
prepared last year.
 Prentice Object Oriented Software Engineering Using UML, Patterns and
Java 3rd 2012_2
79 | P a g e

Employee Management System For ASTU

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Employee Management System For ASTU

Uploaded by

Copyright:

Available Formats

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

1.3. Statement of problem

1.5. Objective of the project

1.5.2. Specific objective

1.6. Feasibility study

1.6.1. Economic Feasibility

1.6.2. Technical Feasibility

1.6.3. Operational feasibility

1.7. Scope and limitation

1.8. Significance of the project

1.9. Operating environment

Table1.1. Client side tools

MySQL MySQL 5.6 Backend or project

Enterprise - For use case and

TOOLS USED Front end (PHP)

 Database tools (MYSQL (front end))

1.10.2. Methodology for the system design and development

 Promotes better understanding of user requirements

1.11. Testing procedure

1.11.2. Integration testing

Advisor Instructor: Yordanos Gebeyew

1.12. Team composition

1.13. Task and Schedule

1.13.2. Team member’s activity

1.14. Definition, acronym, and abbreviation

2. Description of the existing system

2.1. Major function of the current system

2.2. Users of the current system

2.3. Drawback of current system

2.4. Business rule of the current system

Users must have a valid user name and password.

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

3.2. Functional requirement

3.3. Nonfunctional requirement

3.4. Performance Requirements

3.4.2. Use case model

manage fill attendance

give leave request

delete record controlSystem

Fig 3.1. use case diagram for EMS

Alternative flow The employee can register coming in the university.

 The system does not work when there is no

 View monthly attendance

 Salary payment and calculation

 Give leave request

 View leave history

 The system does not work when there is no

3.5. Object Model

3.5.1. Data Dictionary

Field name Data type Field size Constraint Description

3.5.2. Class Diagram

3.6. Dynamic model

3.6.1. Sequence diagram

Fig 3.2. sequence diagram for registration

Fig: sequence diagram for manage leave

Fig 3.3. sequence diagram for login

employeeInterfa Fill_Attendance Attendance_Fo Attendance_Co Employee_Dat

attendance View_Attendan Employee_Dat

Fig 3.7. sequence diagram for view attendance

Fig 3.8. sequence diagram for update record

Fig 3.10. sequence diagram for salary payment/calculation

3.7.1. Activity diagram

register successfully message