The Design and Implementation of a Web Service...

111
The Design and Implementation of a Web Service Application for Human Resource Management Supervisor: Dr. Sandra Sampaio Author: Ihuoma Njoku BSc. Computer Science (Honors) The University of Manchester Third Year Project April 2013

Transcript of The Design and Implementation of a Web Service...

The Design and Implementation of a Web

Service Application for Human Resource

Management

Supervisor: Dr. Sandra Sampaio

Author: Ihuoma Njoku

BSc. Computer Science (Honors)

The University of Manchester

Third Year Project

April 2013

Third Year Project (Ihuoma Njoku) Page 2

The constantly evolving economy has lead to an increase in the shift towards service

based industries, thereby making employees the most valued assets of any company.

Research has shown that the success of any business today lies in the hands of the

employees and the need to support the driving force of these companies has become

inevitable. In order to boost the performance of employees in the work environment, the

individual careers of these employees must be managed from recruitment to retirement

and this is referred to as Human Resource Management.

The objective of this project is to implement a web based recruitment management tool.

Although there are several robust systems available online, most of the recruitment

tools are quite expensive. The proposed system would be a web service which enables

easy access over a network and also affordable to medium size or small enterprises.

The tool would offer main features needed for recruitment, from the application point to

the interview stage. Most importantly, the system would have an interface which is

easy to interact with in order to ensure proper utilization of the tool.

This report examines the entire life cycle of the project from its motivation, testing and

underlying technologies used for the implementation.

I would like to offer my very great appreciation to my supervisor, Dr. Sandra Sampaio

whose suggestions and advice helped immensely throughout the planning and

development of this project.

Special thanks to my family for encouragement and friends for their availability to help

test the system and also for providing constructive feedback.

Abstract

Acknowledgements

Third Year Project (Ihuoma Njoku) Page 3

Table of Contents

Abstract ...................................................................................................2

Acknowlegements ....................................................................................2

Chapter1: Introduction ..........................................................................8

1.1 Motivation & Problem Statement .................................................8

1.2 Project Objective ..........................................................................8

1.3 Project Scope ...............................................................................9

1.4 Report Structure ...........................................................................9

Chapter2: Background & Literature Survey .....................................11

2.1 Web Services .................................................................................11

2.1.1 Introduction to Web Services .................................................11

2.1.2 Advantages & Limitations .....................................................11

2.1.3 Web Services Technologies ...................................................12

2.2 Human Resource Management ...................................................15

2.2.1 Definition & Application .......................................................15

2.2.2 Web Services in HRM ...........................................................16

2.3 Tools and Technologies .................................................................16

2.3.1 Comparing tools .....................................................................16

2.3.2 Eclipse Juno ...........................................................................18

2.3.3 mySQL ...................................................................................18

2.3.4 Tomcat Server ........................................................................18

2.3.5 XML .......................................................................................18

2.3.6 JavaScript ...............................................................................18

2.3.7 JQuery ....................................................................................18

2.3.8 Java ........................................................................................19

Third Year Project (Ihuoma Njoku) Page 4

2.3.9 JSP ..........................................................................................19

2.3.10 JavaFreeChart ......................................................................19

2.3.11 JProgressBar ........................................................................19

2.3.12 Jasper Reporting tool ...........................................................19

Chapter3: Design ..................................................................................20

3.1 Use Cases .......................................................................................20

3.1.1 Sign Up use case description .................................................20

3.1.2 Login(Applicant) use case description...................................20

3.1.3 Logout use case description ...................................................21

3.1.4 Edit Profile use case description ............................................21

3.1.5 Apply for Position use case description .................................22

3.1.6 Assessment/Interview Schedule use case description............22

3.1.7 View Outcome of application use case description ...............22

3.1.8 Track Application progress use case description ...................23

3.1.9 Send Query use case description..........................................23

3.1.10 Login(Recruiter) use case description ..................................23

3.1.11 Add, Update and Terminate use case description .................24

3.1.12 Shortlist Candidates use case description .............................24

3.1.13 Shortlist applicants for Interview use case description .........24

3.1.14 Assessment & Interview Scheduling use case description ...25

3.1.15 View Interview Outcome use case description .....................25

3.1.16 Select Competent Applicant use case description ................26

3.1.17 Enter details of Interview use case description .....................26

3.2 Requirements ................................................................................26

3.2.1 Functional Requirements .......................................................27

3.2.2 Non-Functional Requirements ...............................................27

Third Year Project (Ihuoma Njoku) Page 5

3.3 Data Model ..................................................................................28

3.3.1 Data Flow Diagrams ............................................................28

3.3.1.1 Login DFD .......................................................................29

3.3.1.2 Edit Profile DFD ...............................................................30

3.3.1.3 Apply for Position DFD ....................................................30

3.3.1.4 View Assessment/Interview Schedule DFD .....................31

3.3.1.5 View Outcome of application DFD .................................31

3.3.1.6 Track Application progress DFD ......................................32

3.3.1.7 Send Query DFD .............................................................32

3.3.1.8 Add, Update and Terminate Job Vacancy DFD ...............33

3.3.1.9 Shortlist Candidates for Assessment DFD ......................34

3.3.1.10 Enter Assessment Scores DFD .......................................34

3.3.1.11 Shortlist applicants for Interview DFD ...........................35

3.3.1.12 Assessment Scheduling DFD ..........................................35

3.3.1.13 Interview Scheduling DFD .............................................36

3.3.1.14 View Interview Outcome DFD .......................................37

3.3.1.15 Select Competent Applicant DFD ..................................38

3.3.1.16 Enter details of Interview DFD ......................................39

3.3.2 Database Table Relationship Diagram ...............................39

3.3.3 Database Design ....................................................................40

3.4 Software Development .................................................................44

3.5 System Architecture.....................................................................45

3.6 Software Architecture .................................................................48

3.6.1 Applicant mode ..........................................................................48

3.6.2 Recruitment Manager mode .......................................................49

Third Year Project (Ihuoma Njoku) Page 6

3.6.3 Interviewer mode ......................................................................50

Chapter4: Implementation ...................................................................52

4.1 Database Implementation .............................................................52

4.2 Web Service Implementation ........................................................53

Chapter5: Results..................................................................................72

5.1 System Walk-through .................................................................72

Chapter6: Testing and Evaluation ......................................................97

6.1 Testing ........................................................................................97

6.1.1 User Acceptance Testing ......................................................97

6.1.2 Code Testing .......................................................................100

6.1.3 White Box Testing ...............................................................101

6.1.4 Black Box Testing ...............................................................104

6.2 Evaluation ................................................................................104

6.2.1 Strengths ..............................................................................104

6.2.2 Limitations ...........................................................................104

Chapter7: Conclusion .........................................................................105

7.1 Project Achievements and System Objectives ...........................105

7.2 Future Extensions ......................................................................107

7.3 Reflection ...................................................................................108

References ...........................................................................................109

Appendix .............................................................................................111

Project Plan .....................................................................................111

Third Year Project (Ihuoma Njoku) Page 7

Table of Figures

Figure[1] DFD notation ..........................................................................28

Figure[2] Spiral Model ..........................................................................44

Figure[3] Full Picture of Software development ...................................45

Figure[4] Detailed Web Service Process ...............................................45

Figure[5] Multi-tier layer architecture .................................................47

Figure[6] Web Client Design ................................................................ 51

Figure[7] Questionnaire for Applicants ................................................98

Figure[8] Questionnaire for Recruiters ................................................ 99

Figure[9] Analysis of Feedback ..........................................................100

Third Year Project (Ihuoma Njoku) Page 8

The aim and objectives of this project are presented in this chapter. Furthermore, a

brief overview of the report structure, the motivation from the problem statement

and the proposed solution are explained in the respective sections.

1.1 Motivation and Problem Statement

Human Resource Management commonly known as HRM, has gone from the use

of paper files to the use of enterprise resource platforms. There are so many HRM

system vendors available today, with most businesses having a special department

to carry out management using various tools. Despite the fact that there are full-

size to scalable applications depending on the companies needs, these applications

come with a great cost unaffordable to small enterprises that are later forced to

purchase these tools to keep up with the internet age and competitors. Flexibility

and maintenance of the purchased tool greatly hinders the growth of the enterprise

especially when there is a change in the company‟s strategy. All these factors

combined together inhibit these enterprises from making the desired profit

compared to their larger counterparts.

Due to the ease of reusability and its ability to exchange information over a

network, web services pertaining to service oriented architecture are dominant in

the business world [2]. For these reasons and some others that would be mentioned

in Chapter2, the solution to the problem stated above would be implemented using

a web service.

1.2 Project Objective

The intention of this project is to contrive and implement a user friendly web

service application for human resource management that would provide

recruitment support to small or medium size firms.

This tool would simplify the recruitment process with higher efficiency and serve

as a common meeting ground for job seekers and employers.

Chapter1: Introduction

Third Year Project (Ihuoma Njoku) Page 9

1.3 Project Scope

The application to be developed will be used to support the entire recruitment

process of medium size to small enterprises. Some of the features provided by the

recruitment tool include an assessment scheduler, interview scheduler, report

generator, applicant recommendatory, activity log, applicant data storage and a

recruitment progress tracker.

The system will comprise of three main modules for the different users which are

the applicants, interviewers and the recruitment manager. An applicant can be able

to store files on the system, view available jobs, apply for a position, edit or delete

account details, track the progress of the job application, send queries about an

application, view assessment scores, assessment schedules , interview schedules

and also confirm availability for an interview. The recruitment manager has full

authority over the system. This individual can be able to add, edit or delete jobs,

track the status of all jobs, shortlist candidates, select candidates for the job,

schedule assessments and interviews for applicants and also view the activity log

for security purposes. An interviewer would only be able to enter the details about

the applicant which was observed during the interview session.

1.4 Report Structure

Chapter1: Introduction

The chapter elucidates in detail, the motivation behind the project and also presents

the scope of the proposition.

Chapter2: Background and Literature Survey

In this chapter various HRM tools are reviewed and advantages of technologies

used to implement the prospective system are discussed.

Chapter3: Design

Explains how the problem stated in section 1.1 was solved in high level detail. The

structure of the database, architecture of the system, data flow diagrams and use

cases of the stakeholders are all presented in this chapter.

Third Year Project (Ihuoma Njoku) Page 10

Chapter4: Implementation

Using the technologies mentioned in chapter2, this chapter describes in low level

detail how the system was built.

Chapter5: Results

A walk through of the system is presented in this chapter and a scenario is created

in order to demonstrate how the system works.

Chapter6: Testing and Evaluation

The strengths and limitations of the system are evaluated and the testing techniques

used are discussed.

Chapter7: Conclusion

This chapter explores ways in which the system can be extended and discusses the

initial requirements of the system at variance with the project achievements.

Reflection about the personal learning experience is also covered.

Third Year Project (Ihuoma Njoku) Page 11

In this chapter, HRM tools built by various companies are reviewed and essential

background information of the technologies used to implement the proposed

system are evaluated.

2.1 Web Services

Web Services have evolved through the years since its adoption in 2001. It is

commonly described as a software system designed to handle machine to machine

communication over a network with the significant part of this description being its

support for interoperability and communication over a network [2].

2.1.1 Introduction to Web Services

Informally, a web service is understood to comprise of three main elements [1].

WSDL documents which capture interface descriptions.

SOAP, a communication protocol which uses XML to exchange messages.

A universal description, discovery and integration protocol that allows users

to find services offered by a particular provider.

The success of web services has enabled a vast amount of possibilities. It has the

potential to change the landscape of business to business communications with its

ability to adapt to the web and enable creation of applications [3]. The recognition

of web services is extensively befitting to the fact that they are built on XML based

standards like UDDI, SOAP and WSDL.

2.1.2 Advantages & Limitations

The benefits web services offer, compared to its limitations are numerous. In this

section, some of them would be mentioned and briefly explained.

Advantages [4]

Web services support interoperability and platform independence by using

XML technologies that allow operating systems and programming languages

adopt with ease. For instance, a company can link its application with those

of its partners as if it were their own.

Chapter2: Background and Literature Survey

Third Year Project (Ihuoma Njoku) Page 12

A web service based on service oriented architecture is a belief variant for

companies seeking inter-or-intra business interactions, considering it is fit

for communication in a loosely coupled environment.

Since web services are loosely coupled, a consumer is not tied directly with

the service thereby enabling the ease of upgrade and maintenance at any

given time.

Communication costs can be reduced using web services.

Web services do not serve an additional based model of application

development hence its support for reusability.

With proven alliance orthodoxy, the underlying security is built-in ahead.

Limitations [4]

Web service‟s credence on the integrity of a network is its primary

limitation.

When using web services with the stateless protocols HTTP and HTTPS, the

server needs a way to monitor the interaction with the client.

2.1.3 Web Services Technologies

Web services are XML based applications which use a variety of technologies to

describe its semantics. These technologies are briefly explained in this section.

XML XML the extensible markup language as it is widely known is the basis of web

services that allows structuring and description of data. It is the canonical for data

transaction on the web and due to its flexibility, it has been proposed as the

counter-statement to decode integration issues [1].

Servlets Servlets are faceless java objects, usually referred to as a protocol and platform

independent server-side software components. They receive requests and

generate responses based on the given request. Servlets do not need a graphical

user interface (GUI) since they run inside servers hence the term faceless. Its

Third Year Project (Ihuoma Njoku) Page 13

advantage over the traditional common gateway interface (CGI) is the ease of use

combined with their fast performance [5].

WSDL

WSDL is a web service description language similar to an interface. It is normally

used in consolidation with SOAP and an XML schema to publish and describe

functionalities offered by web services. A wsdl file contains information about the

operations to be performed on some data. This information is available on the

server and enables efficient user-to-web service interaction. If a probable user

sends a message, the web service which in this case is the receiver of the message

simply looks up the server for information on how to process the given message.

SOAP can be used to retrieve any of the operations listed in the wsdl file.

SOAP

The simple object access protocol otherwise known as SOAP defines the way in

which structured information is exchanged between the web service and other

systems. It consists of three parts :

The envelope for marking the start and end of a message.

The header which contains message attributes.

The body containing the message to be delivered.

The interoperability of web services is due to the platform independence of SOAP.

XML is responsible for its message format and for transmission, it relies on

application layer protocols such as HTTP. The major advantage SOAP has over its

counterparts is its ability to use different transport protocols and tunnel over

existing proxies with ease.

UDDI

UDDI, the universal description discovery and integration protocol provides a look

up platform service. It takes the form of an xml-based registry or repository that

facilitates a service consumer to find web services quickly and dynamically over

the internet. It also enables businesses register their web services by providing

contact information and the URL of the wsdl file is then registered for each

service. It is also highly flexible and supports service descriptions using any

interface.

JSP Various technologies could be used to provide an interface for web service

consumption. The advantages and limitations of these technologies such as

ASP.NET and PHP were compared and JSP was seen to be of greater advantage

than the others. Reasons behind this conclusion are further explained.

Third Year Project (Ihuoma Njoku) Page 14

Java Server page similar to php is a server-side scripting language which is based

on XML and HTTP. This technology helps create dynamically generated web

pages, responsible for communicating with the web services and providing an

interface for the user. A java server page is similar to a html page with regards to

its syntax. However, it has its own element tags and its deployment requires a

compatible web server with a servlet container.

Some of the advantages of java server pages include:

Its ability to separate dynamic and static content.

Scales nicely to several web pages.

Can be used alone.

Its platform independence.

It supports component reuse.

Its scripting and tag elements.

JSP Components [5] The components of the java server page which include Directives, Declarations,

Comments, Scriptlets and Expressions are listed and described below.

Directives:

A directive which is a global definition sent to the jsp engine remains valid

throughout the application. It enables the definition of dependent attributes to the

JSP page, importation of external files and allows custom extensions.

Declarations:

Although it is usually written in java, the declaration block supports syntax of

other scripts. It can also perform additional processing in the JSP engine by

introducing java beans that connects java units to external non java code.

Scriptlets:

Embedding fragments of java code is supported in this block. For instance the time

of the day could be output on a html page without having to declare the entire page

as java code.

Comments:

There are three comment styles available in JSP. The output comment which is in a

HTML format, enables a comment appear in the browser‟s output stream. For

exclusion of the comment block in the output, the second comment style can be

used and by embedding a scriptlet tag inside a comment tag, a dynamic content in

a comment can be created.

Third Year Project (Ihuoma Njoku) Page 15

Expressions:

These are fragments whose results after execution are converted to string and then

displayed in the browser.

JSP Configuration file [6] The configuration file such as “web.xml” which is automatically generated by the

IDE (Integrated Development Environment), defines how the web application is

deployed and links the JSP files to the java features of the application.

Summary of how JSP works

After a request has been made to a JSP page from a web browser, the contents of

the file are parsed by a JSP engine. A temporary source code is then created by the

engine based on this content and a generated servlet creates the dynamic elements

of the page. The servlet is later compiled and instantiated followed by the

execution of the servlet logic. Most of the business logic is carried out on the

server, hence its thin-client architecture. Finally, the static and dynamic elements

specified in the jsp page are sent through the servlet‟s output stream to the web

browser.

2.2 Human Resource Management

The lawful and coherent approach to govern an organisation‟s most valued

property is referred to as human resource management. In the course of this

management, a range of factors must be considered with respect to the employees

of the company. These factors amongst others include recruitment, payroll,

training, performance monitoring and attendance management [7]. In the sub-

sections, the application of human resource management and the role of web

services in HRM are explained in detail.

2.2.1 Definition & Application

The HRM critical emphasis is about leveraging the capabilities of employees to

achieve a competitive advantage [9]. With the increase in shift towards service

based industries, human resource management has become the driving force of

most companies and the competition in today‟s economy is so huge that HRM

departments must exist in any company.

Generally, the function of human resource departments are administrative and

these departments must provide the most conducive working environment for

productivity on the side of the employees. In order to reduce manual workload and

for organizations to compete, automated HRM systems were introduced in

Third Year Project (Ihuoma Njoku) Page 16

companies. Most of these automated systems are very costly and only affordable

to large enterprises or firms [8]. In the bid to aid smaller enterprises avoid these

huge costs and maintenance whilst carrying out HR activities, electronic human

resource management was introduced to improve the potential of HR department

clients.

2.2.2 Web Services in HRM

The need to purchase special standalone applications and specialist staff for

maintenance or customization has been scrapped by the introduction of web

services. Web services have become cost effective solutions and the information

distributed between applications, can now be united over different platforms. All

the advantages mentioned previously add up to significant cost savings for small

enterprises and with little or no additional technology investments required, the

HRM recruitment process solution for small firms would be implemented using

web services.

2.3 Tools and Technologies

Reviews on some of the available HRM tools are discussed in this section and the

implementation technologies used in chapter5 are also presented in the subsections.

2.3.1 Comparing Tools

Six existing recruitment management tools were examined using free trial versions.

The results from the analysis would be considered when implementing the

proposed system. Tools compared include PC recruiter [12], Hiring Thing [13],

Bullhorn ATS and CRM [14], Kronos [15], Orange HRM [16] and Arithon [17].

PC recruiter is a great software suite with different administration roles for any

recruitment process. The system has several modules including an inbuilt

assessment and applicant tracking tool. The flexible grouping method possessed

by PC recruiter is the main strength of the software. Names, job records, search

results and multiple resumes are placed in sub groups to control large amounts of

information. A huge turn off observed about PC recruiter is its clunky interface

making it difficult to use and its faulty table update functionality (e.g in order to

enter new information about an applicant, the page must be refreshed to update the

table).

Third Year Project (Ihuoma Njoku) Page 17

Hiring Thing is cost effective recruitment software focused on small companies. It

has few supple features such as integrated screening questionnaires, application

ranking, online partnerships and a well structured interface hence navigation

around the system was quite easy. However, it requires a noticeable amount of

installation time and does not integrate into all systems.

Bullhorn ATS (Applicant Tracking System) and CRM (Customer Relationship

Management) is plausible on the part of recruitment but limited on the client side

(e.g. only applicant‟s contact name can be retrieved and further information relies

on applicant CV). The system has issues of redundancy as it is unable to spot

duplicate entries when the same information is entered from multiple data entry

points. Although it is implemented using a web based approach, technical errors

when connecting to the database is clearly an obstacle to contend with in this

system.

Kronos is a non-web based application with a user friendly interface mainly

because of its blend of neutral colors. It is easy to integrate with other software

tools but the task of customization or maintenance, needs to be carried out by the

user of the system and requires months of studying the online manual to get

acquainted with the underlying functionality.

Orange HRM exhibits basic features required in a recruitment process. The

software provides social media recruitment, CSV extractor, applicant history,

resume parsing, keyword tagging and job vacancy RSS feeds. The major turn off

about this system is that it is not web based and has to be installed on the

company‟s system with disk space being an issue.

Arithon uses a graphical dash board which is wholly complex. For instance a large

part of the homepage is devoted to candidate and client call back which could be

considered highly unnecessary. It provides no user guide or manual therefore a

user must play around with the system in order to relatively get started. The search

functionality is also quite slow and cumbersome.

Scrutiny of these systems primarily highlights the importance of a good user

interface and also the defects of non-web based applications.

Third Year Project (Ihuoma Njoku) Page 18

2.3.2 Eclipse Juno

Eclipse Juno would be used as the integrated development environment (IDE)

because of its support for web services. The eclipse web tool project provides two

components JST web services and WST web services. JST web service component

which provides functionality for interacting with java web services, consists of

web service wizards for creation and consumption. The WST web service

component consists of a WSDL editor, UDDI publisher and web services

development tools that are not java specific. With the extensible ability of eclipse

juno, other external technologies could be integrated to work together with the web

services.

2.3.3 MySQL

MySQL runs a server that provides functionality of database access by different

users. It is the most widely used relational database management system and to

create JDBC applications, the structured query language can easily be combined

with java. This RDBMS would be used to store and maintain data in the HRM tool.

2.3.4 Tomcat Server

The open source web server Apache Tomcat, gears java servlets and java server

pages whilst providing a perfect ambiance for java code to run. Tomcat supports

deployment of system based web applications across different environments. It

would be used to manage sessions in the application across the network.

2.3.5 XML

Web services are typically based on XML which was explained in section 2.1.3. In

this application, XML syntax would be used to describe data and encode messages

exchanged between the web service consumer and server.

2.3.6 JavaScript

JavaScript is a dynamic server side scripting language. It is also prototype based

with functions which are objects themselves. For validation and to avoid server

side loading, javascript would be embedded in the web pages of the application.

2.3.7 JQuery

JQuery is a javascript library with the capabilities of creating javascript plug-ins.

The simplicity of client side scripting gives it an edge over its counterparts. It

Third Year Project (Ihuoma Njoku) Page 19

would be used to implement the interview and assessment scheduler in the

application.

2.3.8 Java

The programming language used for developing the back end functionality of the

web application would be java. The reason for this is that with the combination of

SQL, a JDBC application can be created in order to manipulate or access the

database.

2.3.9 JSP

Most of the capabilities of JSP have been explained in the section 2.1.3. The java

server page would be used in this application to create an interface for web clients

to interact with the web services.

2.3.10 JFree Chart

The java chart library JFreeChart, supports different chart types. It focuses on

server-side and client-side applications providing a flexible design for report

analysis. The proposed recruitment tool uses jfree chart to generate a graphical

report based on applicant nationality.

2.3.11 JProgressBar

JProgress bar is a java class that displays the progress of a task either graphically

or textually. Two modes exist in this java class, indeterminate and determinate.

The indeterminate indicates that the length of a task is unknown. This application

uses the determinate mode and the value of the progress bar is updated after each

task.

2.3.12 Jasper Reporting tool

JasperReports is a reporting engine that is capable of writing to several targets

which range from pdf, xml, html files to printers. It can be embedded in java

applications using scriptlets and can also be imported into jasper server for

sophisticated report management. The reporting tool would be used to generate pdf

reports produced by jfree chart.

Third Year Project (Ihuoma Njoku) Page 20

In this chapter, the system requirements and design phase of the system throughout

the project would be explained in high level. The design phase includes the

database design, table relationship diagram, data flow diagram and system

architecture. Three kinds of users can access the system, the applicant, the

interviewer and the recruitment manager. The use cases of these stake holders are

further explained.

3.1 Use Cases

Use cases are used to define interactions between stake holders and the system.

Most importantly, they capture the system requirements efficiently. Relevant use

case diagrams have been split into smaller bits for simplicity.

3.1.1 SignUp use case description

Fig[D1] SignUp use case description

3.1.2 Login use case description

Use Case Name Sign Up

Brief

Description

An applicant wants to be registered on the system. The

applicant then provides a unique username with other required

details such as contact phone number, address etc. If all

compulsory fields are completed, an account is created

successfully.

Stakeholder(s): Applicant

Notes: In order to use the system, every stakeholder must have an

account.

Use Case Name Login

Brief

Description

A Stakeholder is on the HRM recruitment site and wants to

use the system. The stakeholder with an account, enters

Chapter3: Design

Third Year Project (Ihuoma Njoku) Page 21

Fig[D2] Login use case description

3.1.3 Logout use case description

Fig[D3] Logout use case description

3.1.4 Edit Profile use case description

username and password and if details are valid, access to the

system is granted. If details given are invalid, access to the

system is denied and a username/password reminder email is

suggested to the user.

Stakeholder(s): Applicant

Notes: To keep records of the actions performed by stakeholders, a

user must login via an account.

Use Case Name Logout

Brief

Description

A Stakeholder decides to log out of the HRM recruitment site

and is navigated back to the home page.

Stakeholder(s): Applicant, Interviewer and Recruitment Manager

Notes: A stakeholder should be able to terminate a session with the

system. For security purposes, the user‟s login and logout

time are recorded.

Use Case Name Edit Profile

Brief Description A registered applicant decides to alter details entered

during sign up. The applicant edits the chosen field and if

valid details have been entered, the database is updated.

Stakeholder(s): Applicant

Notes: If details of the stakeholder changes, for example a

different name or address is obtained. The user must be

Third Year Project (Ihuoma Njoku) Page 22

Fig[D4] Edit Profile use case description

3.1.5 Apply for Position use case description

Fig[D5] Apply for Position use case description

3.1.6 View Assessment and Interview Schedule use case description

Fig[D6] View Assessment and Interview schedule use case description

3.1.7 View Outcome of application use case description

able to amend such information.

Use Case Name Apply for Job Position

Brief Description A registered applicant scans the job board for available

job positions. The candidate applies for the job after

viewing its description by uploading documents such as

a curriculum vitae.

Stakeholder(s): Applicant

Use Case Name View Assessment and Interview Schedule

Brief Description A registered applicant can view assessment or

interview schedules of a particular job if shortlisted.

The applicant must confirm availability for the

interview date scheduled and if unavailable, a

reschedule is made or the applicant is contacted via

telephone.

Stakeholder(s): Applicant

Use Case Name View Outcome of application

Brief Description A registered applicant can view the outcome of an

application and if successful, can confirm or decline a

Third Year Project (Ihuoma Njoku) Page 23

Fig[D7] View Outcome of application use case description

3.1.8 Track Application progress use case description

Fig[D8] Track Application Progress use case description

3.1.9 Send Query use case description

Fig[D9] Send Query use case description

3.1.10 Login use case description

job offer.

Stakeholder(s): Applicant

Use Case Name Track Application progress use case description

Brief Description The status of an application can be tracked by the

applicant. It is displayed to the user graphically with a

progress bar and also textually using a percentage.

Stakeholder(s): Applicant

Use Case Name Send Query

Brief Description A registered applicant who has a problem or questions

concerning an application can send a message to the

company through the system with an application code.

Stakeholder(s): Applicant

Use Case Name Login

Brief Description An interviewer or recruitment manager wants to gain

access to the system. The user then provides a unique

username and company „HR-id‟ with other required

details. If all details are valid, access is granted and the

Third Year Project (Ihuoma Njoku) Page 24

Fig[D10] Login use case description

3.1.11 Add, Update and Terminate Job Vacancy case description

Fig[D11] Add, Update and Terminate Job Vacancy use case description

3.1.12 Shortlist Candidates for Assessment use case description

Fig[D12] Shortlist candidates for assessment use case description

3.1.13 Shortlist applicants for Interview use case description

user is navigated to the appropriate mode.

Stakeholder(s): Recruitment Manager and Interviewer

Use Case Name Add, Update and Terminate Job Vacancy

Brief Description The Recruitment manager can add a new job or edit

and existing job on the job board. Depending on the

company‟s policy, a job can be terminated (closed) in

order to start processing documents and restrict

applicants from applying.

Stakeholder(s): Recruitment Manager

Use Case Name Shortlist Candidates for Assessment

Brief Description The recruitment manager scans through the supporting

documents of applicants and if the applicant satisfies a

certain criteria, the recruiter shortlists the candidate for

the assessment stage.

Stakeholder(s): Recruitment Manager

Use Case Name Shortlist Applicants for Interview

Brief Description The recruitment manager enters the score of the

Third Year Project (Ihuoma Njoku) Page 25

Fig[D13] Shortlist applicants for interview use case description

3.1.14 Assessment and Interview Scheduling use case description

Fig[D14] Assessment and Interview scheduling use case description

3.1.15 View Interview Outcome use case description

Fig[D15] View interview outcome use case description

assessment against the name of the applicant. The

minimum score and number of applicants required are

used to shortlist for the interview stage.

Stakeholder(s): Recruitment Manager

Use Case Name Assessment and Interview Scheduling

Brief Description The Recruitment Manager schedules an available date

and assessment center which is visible to shortlisted

applicants. After the assessment scores have been

entered, an interview is scheduled for the second set of

shortlisted applicants by selecting an available

interviewer and time which is later sent to the applicant

for confirmation of availability. The maximum number

of reschedules for an unavailable candidate is set

according to the company‟s policy. If an applicant

confirms unavailability, the applicant is contacted via

telephone and a suitable date must be agreed else the

applicant is automatically rejected.

Stakeholder(s): Recruitment Manager

Use Case Name View Interview Outcome

Brief Description The interviewer enters the interview details of the

respective applicant. The recruitment manager is then

notified when an interview detail has been set.

Stakeholder(s): Recruitment Manager

Third Year Project (Ihuoma Njoku) Page 26

3.1.16 Select Competent Applicant use case description

Fig[D16] Select competent Applicant use case description

3.1.17 Enter details of Interview use case description

Fig[D17] Enter details of interview use case description

3.2 Requirements

Realisation of the system requirements help identify the software development

methodology. This section presents and overview of the functional and non-

functional requirements of the software.

Functional requirements are tasks the system must be able to perform. As the name

implies, it specifies the main functionality of the system.

Use Case Name Select Competent Applicant

Brief Description The interview sessions have been carried out and

details of the applicants have been entered by several

interviewers. The recruitment manager is able to select

the best applicant by reviewing the interview details,

assessment scores and other documents. The system

can also recommend an applicant based on interview

details and assessment score analysis.

Stakeholder(s): Recruitment Manager

Use Case Name Enter details of Interview

Brief Description After an interview session, the interviewer is only

allowed to enter information related to the applicant. If

an applicant is successful at the interview, the reason

behind this decision is entered and if unsuccessful, the

reason is also noted.

Stakeholder(s): Interviewer

Third Year Project (Ihuoma Njoku) Page 27

Non-Functional requirements do not specify the system‟s behavior but they are

used to specify the criteria of the system‟s general operation.

3.2.1 Functional Requirements

An applicant must be able to create an account on the system.

A log in and log out feature must exist on the system.

The system must allow the recruitment manager add, update or delete job

vacancies.

The user must be able to update profile details.

The system should have an advanced search engine to search for jobs or

applicants.

The recruitment manager should be able to schedule assessments or

interviews and notify applicants automatically.

An applicant should be able to upload any format of documents on the

system.

The system should be able to generate a report about a particular job based

on some analysis.

An applicant should be able confirm availability for an interview schedule.

The system should allow the user browse job vacancies and apply.

The system should enable an applicant accept or decline a job offer.

Shortlisting applicants for assessments and interviews respectively should be

allowed on the system.

The system should allow details of an interview session to be entered.

Insertion of the assessment score of applicants should be allowed on the

system.

The system should disable unavailable dates on the scheduling calendar.

The system should display interviewer schedule for a given date.

The system should allow rescheduling of an interview for an applicant.

The recruitment progress of a job should be able to be tracked on the system.

3.2.2 Non- Functional Requirements

Multiple users should be allowed on the system.

Web services should be used to build the system.

The web application should have a simple and friendly user interface.

The system should enable integration with other tools or sites.

Connection to the web service by the client should be made effectively and

quickly.

Third Year Project (Ihuoma Njoku) Page 28

The system should allow a single sign on session for all areas.

The system should be easy to use whilst navigating to different pages and act

as a support for recruitment processes in HR departments.

There should be an online documentation or manual for the system.

The system should be able to run on any platform.

Validation of input fields should take place before any transaction.

3.3 Data Model

In the initial phase of database development, data modeling is performed. Data

modeling focuses on information gathered during requirement analysis and where

it should be stored. This section captures the analysis of the use cases described in

section 3.2 via data flow diagrams. It also gives a detailed explanation about the

entities and relationships present in the web application.

3.3.1 Data Flow Diagrams

Notation Representation

Database

System

External Entities

Data Flow

Figure[1]: DFD notation

Third Year Project (Ihuoma Njoku) Page 29

3.3.1.1 Login DFD

Validate

Credentials Role = Applicant

Role = Interviewer Enter Username

And Password

Role = Recruitment

Manager

Invalid Credentials

User Login

HRM DB Applicant

Subsystem

Interviewer

Subsystem

Recruiter

Subsystem

Third Year Project (Ihuoma Njoku) Page 30

3.3.1.2 Edit Profile DFD

Retrieve

information

based on user ID

Show Profile

Enter ID

Invalid ID

3.3.1.3 Apply for Job Position DFD

Store Document in DB

Retrieve Job Details

Apply for job

Enter ID

Invalid ID Invalid format

User Update

Profile

HRM DB

Subsystem

User

HRM DB

Job Board

Check

Document

Format

Third Year Project (Ihuoma Njoku) Page 31

3.3.1.4 View Assessment and Interview Schedule use case description

Retrieve schedules

for given ID

Display schedule

Enter ID

Invalid ID

3.3.1.5 View Outcome of application use case description

Retrieve results

for given ID

Display results

Enter ID

Invalid ID

User

HRM DB

Get

Schedules

Applicant Subsystem

User Results

HRM DB

Applicant Subsystem

Third Year Project (Ihuoma Njoku) Page 32

3.3.1.6 Track Application progress use case description

Retrieve all jobs

Applied by user

display progress

Enter ID of selected job

Invalid ID

3.3.1.7 Send Query use case description

Store applicant

queries

Enter query Enter ID details

Invalid ID

User

HRM DB

Job

Applications

Applicant Subsystem

User Applicant Subsystem

HRM DB

Query

Third Year Project (Ihuoma Njoku) Page 33

3.3.1.8 Add, Update and Terminate Job Vacancy case description

Store in db

Retrieve all

Jobs

Perform

Action

Enter ID

Invalid ID

User Find job

HRM DB

Create Job

Update Job

Terminate Job

Third Year Project (Ihuoma Njoku) Page 34

3.3.1.9 Shortlist Candidates for Assessment use case description

Store shortlist in db

Retrieve all

closed jobs

Retrieve documents

Shortlist

Applicants

Enter ID

Invalid ID Select Job

3.3.1.10 Enter Assessment Scores use case description

Store Scores in DB

Retrieve Assessment

Shortlist

Enter Score

Enter ID

Invalid ID

User Recruitment

Manager

Subsystem

HRM DB

Applicant Documents Review

Shortlisted Applicants

User Recruitment

Manager

Subsystem

Applicant Documents Review

HRM DB

Applicant

Scores

Third Year Project (Ihuoma Njoku) Page 35

3.3.1.11 Shortlist applicants for Interview use case description

Retrieve

assessment scores

for selected Job

Store Shortlist

in DB

Select Job

Enter Average Score

and maximum no.

of applicants

required

Enter ID

Invalid ID

3.3.1.12 Assessment Scheduling use case description

Retrieve Assessment

Shortlist

Store assessment

schedule for job

Select applicants Retrieve

available dates

Enter

details

Enter ID Select

Invalid ID date

User

Recruitment

Manager

Subsystem

HRM

DB Applicant

Assessment

Scores

Shortlisted

Applicants

User

Recruitment

Manager

Subsystem

HRM DB

Shortlisted Applicants (Assessment)

Available Dates

Assessment

Schedule

Third Year Project (Ihuoma Njoku) Page 36

3.3.1.13 Interview Scheduling use case description

Retrieve interview

shortlist

Store interview

schedule in DB

Retrieve interviewer‟s

schedule for given date

Select Job Enter Details

Enter ID Select interviewer

and date

Invalid ID

User

Recruitment

Management

Subsystem

Shortlisted Applicants (Interview)

Interview

Schedule

Interviewer‟s

Schedule

HRM DB

Third Year Project (Ihuoma Njoku) Page 37

3.3.1.14 View Interview Outcome use case description

Retrieve Interview Shortlist

Retrieve

interview details

Select job

Select applicant

Enter ID

Invalid ID

User

Recruitment Manager Subsystem

HRM DB

Applicant Shortlist (Interview)

Interview

Details

Third Year Project (Ihuoma Njoku) Page 38

3.3.1.15 Select Competent Applicant use case description

Retrieve Interview Shortlist

Select Job Retrieve

Details

display All Applicants

Enter ID

Invalid ID

Select an

Select System Applicant

Recommendatory

Store

Applicant

in DB

User

Recruitment Manager Subsystem

HRM DB

Applicant Shortlist (Interview)

Details (Scores,

interview-

outcome etc)

Selected

Applicant Recommended Applicant

Third Year Project (Ihuoma Njoku) Page 39

3.3.1.16 Enter details of Interview use case description

Store details

in DB

Retrieve

applicants

interviewed

by Interviewer

Select Applicant

and enter details

Enter ID

Invalid ID

3.3.2 Database Table Relationship Diagram

To describe the database, a table relationship diagram is drawn below. The square

shaped box represents database tables and the cardinality „1:m‟ states that at least

one record in table X can have several tuples in table Y. „m:m‟ states that several

records in table X can have several tuples in table Y. „m:1‟ states that several

records in table X must have exactly one tuple in table Y and „1:1‟ states that at

least one record in table X must have one tuple in table Y.

User Interviewer

Subsystem

HRM DB

Applicant

Interview

Details

Third Year Project (Ihuoma Njoku) Page 40

1:1 1:m

1:m m:m

1:1 m:m 1:m m:1 m:m m:m 1:1

m:1

Fig[D18] Table Relationship Diagram

3.3.3 Database Design

Table name: Users

Description: This table contains details of all users of the system.

No. Name Data Type Constraints

1. FirstName Varchar(30)

2. LastName Varchar(30)

3. UserID Varchar(20) PRIMARY KEY

4. Password Varchar(20)

5. Confirm Password Varchar(20)

6. DOB Date

7. Email Varchar(40)

8. Contact no. Varchar(20)

9. Address Varchar(60)

10. Country Name Varchar(30)

11. Mode Varchar(20)

12. HR-id Varchar(30) FOREIGN KEY

Users

Assessment

availability

Activity

table

Shortlisted

Applicants

Interviewer

Availability

Job

Details

File System_tbl

File_tbl

Non

Availability

Interview

Assessment

Schedules

Interview

Schedules

Ranking

Table

Recruiters

Third Year Project (Ihuoma Njoku) Page 41

Table name: File_system_tbl

Description: This table manages applicant files uploaded for storage on the system.

No. Name Data Type Constraints

1. User ID Bigint(20) FOREIGN KEY

2. File Name Varchar(50)

3. File Data Blob

4. File Date Datetime

5. Applicant File Varchar(30) PRIMARY KEY

Table name: File_tbl

Description: This table manages files uploaded on the system for a job application.

No. Name Data Type Constraints

1. User ID Bigint(20) FOREIGN KEY

2. File Name Varchar(50)

3. File Data Blob

4. File Date Datetime

5. Applicant File Varchar(30) PRIMARY KEY

6. Job Applied Varchar(30)

7. OpenDate Date

8. State Varchar(30)

Table name: Non availability interview

Description: This table contains information about interview reschedules that have

been requested by an applicant.

No. Name Data Type Constraints

1. User ID Varchar(20) FOREIGN KEY

2. Job Title Varchar(20) PRIMARY KEY

3. Date Posted Date FOREIGN KEY

4. Count Rejected Int(20)

5. Candidate Reply Varchar(20)

6. Interview Date Dated

7. Time Varchar(20)

8. Count Max Int(10)

Table name: Shortlisted applicants

Description: This table contains information about applicant documents that have

been shortlisted for the Interview stage.

No. Name Data Type Constraints

1. User ID Varchar(30) PRIMARY KEY

2. JobID Varchar(30) FOREIGN KEY

3. Job Applied Varchar(30)

4. Open Date Date

5. Interview Status Varchar(30)

Third Year Project (Ihuoma Njoku) Page 42

Table name: Activity Table

Description: This table keeps a timed record of a user‟s access to the system for

security reasons.

No. Name Data Type Constraints

1. User ID Varchar(30) PRIMARY KEY

2. Time LoggedIn Timestamp

3. Time LoggedOut Timestamp

Table name: Assessment Schedule

Description: This table contains information about applicant assessment schedules

and their respective scores.

No. Name Data Type Constraints

1. JobID Varchar(40) PRIMARY KEY

2. Assessment Date date

3. Time Varchar(40)

4. Address Text

5. Job Title Varchar(40)

6. Date Posted Date

7. Applicant name Varchar(40) FOREIGN KEY

8. Score Varchar(20)

9. Average Score Varchar(20)

Table name: Interview Schedule

Description: This table contains information about applicant interview schedules

and the respective outcome.

No. Name Data Type Constraints

1. JobID Varchar(40) PRIMARY KEY

2. UserID Varchar(40) FOREIGN KEY

3. Job title Varchar(40) FOREIGN KEY

4. Average score Varchar(30)

5. Applicant name Varchar(40) FOREIGN KEY

6. Interviewer Varchar(30)

7. Interview Date Date

8. Time Varchar(20)

9. Address Text

10. Dresscode Varchar(20)

11. Type Varchar(20)

12. Date posted Date

13. Outcome Varchar(20)

14. Comment Text

15. One word

Comment

Varchar(20)

16. General Outcome Varchar(30)

17. Decision Varchar(20)

Third Year Project (Ihuoma Njoku) Page 43

18. Candidate Reply Varchar(20)

19. Details Input Varchar(20)

Table name: Assessment Availability

Description: This table contains information of unavailable assessment centers and

dates.

No. Name Data Type Constraints

1. JobID Varchar(30) PRIMARY KEY

2. Job Title Varchar(30) FOREIGN KEY

3. Date Posted Date FOREIGN KEY

4. Time Varchar(20)

5. Assessment Date Date

6. Address Varchar(100)

7. Status Varchar(20)

Table name: Job Details

Description: This table contains details of all job vacancies created on the system.

No. Name Data Type Constraints

1. ID Int(100) PRIMARY KEY

2. Title Varchar(20)

3. Description Text

4. Type Varchar(20)

5. Location Varchar(20)

6. Open Date Date

7. Status Varchar(20)

8. Percentage Int(20)

9. Closing Date Date

10. Status Report Varchar(20)

Table name: Ranking Table

Description: This table contains interview details of all applicants merged with

their assessment scores.

No. Name Data Type Constraints

1. JobID Varchar(50) PRIMARY KEY

2. UserID Varchar(30) FOREIGN KEY

3. Job Title Varchar(50)

4. Date Posted date

5. Applicant Name Varchar(30)

6. Outcome Varchar(20)

7. Score Int(20)

8. Comment Text

9. One Word

Comment

Varchar(30)

Third Year Project (Ihuoma Njoku) Page 44

Table name: Recruiters

Description: This table contains the list of interviewers in the company.

No. Name Data Type Constraints

1. Interview ID Varchar(20) PRIMARY KEY

2. Address Varchar(100)

Table name: Interview Availability

Description: This table contains information about an interviewer‟s availability on

a given date.

No. Name Data Type Constraints

1. Job ID Varchar(30) FOREIGN KEY

2. Job Title Varchar(30)

3. Date Posted Date FOREIGN KEY

4. Time Varchar(20)

5. Interview Date Date

6. Address Varchar(100)

7. Interviewer ID Varchar(30) PRIMARY KEY

8. Interviewer Status Varchar(20)

9. Candidate Reply Varchar(20)

3.4 Software Development

The software development process used for this project is the spiral model. It

combines features of the waterfall model and an iterative development which

allows incremental refinement when requirements change. The spiral model

consists of four main parts as shown in the diagram below. The development

process includes objectives determination, alternative evaluation, design of

solution, implementation and system testing.

Requirements Analysis

Implementation Design

Figure[2]: Spiral Model

Third Year Project (Ihuoma Njoku) Page 45

The Full Picture

→ → →

↑ ↓

← ← ←

Figure[3]: Full picture of the Software Development

3.5 System Architecture

The Figure below shows how all technologies integrate to provide for the system‟s

functionality and it is followed by a table explaining the process and flow of

events.

Figure[4]:Detailed Web Service Process

Determine

the needs or

Problems

Select the

Technologies

to be used.

Develop the

Project Plan

Justify the

Technologies Technology

goes Live!

Measure

Effectiveness

Ensure that

the solution

solves initial

Problems

Provide a

Solution

Third Year Project (Ihuoma Njoku) Page 46

Event Description

0. For potential users to discover the

web service, the web service is

published to the UDDI by the

service provider.

1. The potential user searches the

UDDI for the appropriate web

service.

2. The user/client in form of a WSDL

file, acquires the description of the

web service which was selected .

3. A proxy is created locally for the

conversion of XML messages.

4. A SOAP request is created and

sent(e.g Add job) as specified on

the WSDL file to the URL .

5. A SOAP response is generated by

the listener that interprets the

messages at the host site to the web

service. (e.g Job already exists)

6. The web service interface after

performing its function, sends the

result over the internet to the client

through the listener and proxy.

Third Year Project (Ihuoma Njoku) Page 47

Multi-tier Architecture

The architecture of the recruitment system is n-tier. The presentation, application

refinement and data layers are separated. This gives an advantage of flexibility and

reusability instead of reworking the entire application when a modification is

required.

Figure[5]: Multi-tier Architecture

Language Embeddings: HTML, JSP &Java

Web Service Composition

Description: WSDL UDDI

Messaging: SOAP

Transport: HTTP Format: XML

Server: Apache Tomcat

Database Schema

Third Year Project (Ihuoma Njoku) Page 48

3.6 Software Architecture

In the sub sections below, the structure of the software for different modes are

presented diagrammatically.

3.6.1 Applicant mode

Guide

Menu

Login

(Applicant)

Home Page

Account

Menu

Application

Menu Schedule

Menu

View User Guide

Send Query

Profile

Saved Files

Assessment

Schedule

Interview

Schedule

Job Board

Application

Tracker

Application

Results

Third Year Project (Ihuoma Njoku) Page 49

3.6.2 Recruitment Manager mode

Guide

Menu

Login

(Recruiter)

Home Page

Job Board

Menu Schedule

Menu

Applicant

Menu

User Guide

Activity Log

Profile

Add Job

Update Job

Terminate Job

Applicant

Documents

Shortlists

Assessment

Schedule

Interview

Schedule

Recruitment

Menu

Recruitment

Status

Reports

Third Year Project (Ihuoma Njoku) Page 50

3.6.3 Interviewer mode

Login

(Interviewer)

Home Page

Add interview

Details

Interview

Schedule

Third Year Project (Ihuoma Njoku) Page 51

Web Service Consumer Design

The user interface of this application is fundamental, it must balance the visuals of

the system with the technical functionality. In order to achieve this, the needs of

potential users were analyzed and principles of human computer interaction (HCI)

were taking into account.

Figure[6]: Web Client Design

TITLE LOGO

MAIN MENU/NAVIGATION

PAGE CONTENT

SUB TITLE

Third Year Project (Ihuoma Njoku) Page 52

Using the technologies discussed in section 2.1, this chapter explains in low level

detail how the web application was created.

4.1 Database Implementation

PHPMyAdmin was used for MySQL database management via a web browser.

Tasks performed such as creating the database, tables and columns are shown in

the images below.

Task: Create Database

The highlighted text indicates, where the name of the new database is entered.

Task: Create tables

Chapter4: Implementation

Third Year Project (Ihuoma Njoku) Page 53

Task: Create Field

4.2 Web Service Implementation

A dynamic web project to abode the web service was created in the eclipse IDE.

For manipulation of data in the database, the web service operations and queries

(insert,create, update,delete) were carried out in accordance to a users request. To

perform any operation, the web service must connect to the database with the

database credentials, register the java database connectivity driver, open the

connection, execute the query and close on completion.

Task: Connect to database

A web application descriptor file shown below, is generated automatically with the

web service. This file contains information (servlets, filters, listeners, parameters,

jsp file names etc) which the server must have in order to function properly. It is

located in the /WEB-INF folder of the dynamic web project and updated

automatically when a new servlet is created.

Third Year Project (Ihuoma Njoku) Page 54

The TCP/IP monitor in eclipse IDE can be used to trace HTTP response and

requests that encapsulate SOAP messages. The HTTP communication is observed

by listening to a port being used by the web service and forwarding information to

a destination port as demonstrated below.

Task: Configuring TCP/IP monitor

Third Year Project (Ihuoma Njoku) Page 55

Task: TCP/IP monitor view

The screenshot shows a WSDL file highlighting the address location of SOAP

messages exchanged during sign up.

The screenshot shows a SOAP request when connecting to the database.

Third Year Project (Ihuoma Njoku) Page 56

The screenshot shows a SOAP response after a successful database connection

which returns „true‟.

The screenshot shows a SOAP request when a wrong password is used to login and

the following screenshot highlights the SOAP response after a failed login.

The screenshot shows a SOAP request when a correct password is used to login

and the following screenshot highlights the SOAP response after a successful

login.

Third Year Project (Ihuoma Njoku) Page 57

The screenshot shows a SOAP response when job vacancies are retrieved.

For the remainder of this chapter, some of the web service operations (ie

implementation of use cases described in chapter3) would be explained using

snippets of java code and screen shots of pseudo code would be presented were

necessary. The full implementation codes have been sent to the supervisor in a

zipped file and available on request.

In order to create an account on the system, an applicant through the web client is

required to enter details which would be saved in the database. Java Script was

used to validate user input before submission.

Third Year Project (Ihuoma Njoku) Page 58

The screenshot shows a snippet of Javascript code used to validate details during

sign up.

Third Year Project (Ihuoma Njoku) Page 59

The screenshot shows a snippet of Javascript code used for email address

validation.

Other validations implemented using JavaScript include:

Validation Description

1. Access to the system is denied if login details are invalid.

2. An applicant cannot apply for a job that is closed.

3. Compulsory fields on a form must be completed.

4. An Interview cannot be rescheduled when the maximum

reschedule limit has been reached.

5. A shortlist for a certain job must be confirmed before

proceeding to the scheduling stage of that job.

6. Job details must be confirmed before posted on the job board.

7. A job offer cannot be sent to more than one applicant at the

same time.

8. The date picked for an assessment or interview schedule must

be after the current date.

Third Year Project (Ihuoma Njoku) Page 60

The systemLogin method implemented in a java servlet takes credentials(ie.

username with password) and compares values in the „users‟ database table to find

a match. The highlighted text shows the SQL command used to search for a match.

When applying for a job, an applicant is required to upload supporting documents

and on the recruiter‟s side, the recruiting manager should be able to retrieve these

documents from the database. In both cases, the functionality of the upload and

download servlets have to consider the model of the system processor. For

example when uploading a file on a 32 bit processor, the buffer reader takes each

word as 4bytes and on a 64 bit processor, a word is considered as 8bytes. The

model of the system is checked and with respect to the conditions in the code, the

appropriate function is executed.

Third Year Project (Ihuoma Njoku) Page 61

The screen shot shows a snippet of the Upload Servlet.

Third Year Project (Ihuoma Njoku) Page 62

The screen shot shows a snippet of the Download Servlet in java code.

The data flow of the entire recruitment process was used to decide where the

progress bar handler would be increased by a certain percentage (in this case 6%).

1. When a job is created, the progress bar handler is increased to 12%.

2. A terminated job increases the progress bar handler to 18% (ie. 12+6).

3. 24% implies that the Recruitment manager has started reviewing applicant

documents.

4. 30% implies applicants have been shortlisted for the assessment stage.

5. 36% implies that the schedule for an assessment (ie. assessment center, date

etc) has been confirmed and visible to shortlisted applicants.

6. 42% implies that Assessment results have been published.

7. 48% implies that applicants have been shortlisted for the interview stage.

8. 54% implies that interview sessions have been scheduled for shortlisted

applicants.

Third Year Project (Ihuoma Njoku) Page 63

9. 60% implies that all interview sessions have been concluded and

interviewers have entered comments about applicants.

10. 66% implies that eligible applicants are currently being considered for the

job (ie. interview details, assessment scores and documents are being

reviewed).

11. 72% implies that an offer has been sent to successful applicant and a reply

is awaited.

12. 78% implies that the applicant has accepted the offer and a recruitment

contract has been sent.

13. 84% implies that the recruitment process is complete.

14. 100% implies that the recruitment report for the certain job has

been generated (84 + 16 in this case. However, the percentage increment

is customizable ).

In the snippet below, the progress handler percentage is retrieved from the database

and if it is 12%, the check box beside the „Open (Application period) ‟ is ticked.

Third Year Project (Ihuoma Njoku) Page 64

Screenshot shows the snippet of code used to tick the checkbox with respect to a

certain percentage.

The screen shot shows the percentage initialization of the progress bar.

While scheduling applicants for an assessment, unavailable dates are disabled on

the calendar. After an assessment center is selected, the dates in which the center is

unavailable are also disabled on the calendar.

A snippet of the date picker code is given below.

Third Year Project (Ihuoma Njoku) Page 65

The screenshot shows an SQL command used to retrieve unavailable dates.

Applicants are scheduled for an interview session after they have made the shortlist

from the assessment stage. The recruitment manager picks an interviewer for a

particular date and with the help of JQuery, the time range in which the interviewer

is unavailable is retrieved from the database. If the recruitment manager picks any

time within the range the interviewer is unavailable, the system returns an error

alert indicating that the interviewer cannot be booked.

Pseudo code for Interview Scheduling:

//Check if interview date picked, already exists in the database.

//If yes, check if it is for the same interviewer selected.

//If yes, get all booked times for that interviewer.

//get time range of all booked times and insert into a set (ie. if interviewer is

booked from 1pm to 2pm, get 1:00,1:01, 1:02,1:03 … 2:00).

//get difference of the time picked (ie. If the recruitment manager selected 1:50

to 2:50 then 2:50 – 1:50).

//using a loop get the time range of the selected time (ie. 1:50,1:51, 1:52 …2:50)

and insert into another set.

//compare the two sets and if the set intersection is empty, then interviewer is

available on the picked date and time.

//else the interviewer is unavailable.

Third Year Project (Ihuoma Njoku) Page 66

Code snippet of the Interviewer and Time picker.

The following screenshots presents the implementation of the pseudo code

mentioned above.

Third Year Project (Ihuoma Njoku) Page 67

Task: Get time range

Task: Compare Sets of Time Range

Third Year Project (Ihuoma Njoku) Page 68

The system is able to recommend the best applicant based on assessment scores

and interview comments. In a situation where the chosen applicant rejects the job

offer, the system suggests the second best applicant to the recruitment manager.

The Pseudo Code for the System Recommendatory is given below.

//The interviewer enters details about the interview session and summarizes the

performance of the applicant in one word (ie. excellent, very good ,satisfactory

or notqualified).

// Store applicant comments and scores in different lists

//First Loop: Iterate through the lists, recommend applicant with the comment

“excellent”.

//else recommend applicant with “very good” if no applicant has a comment

„excellent‟.

//else recommend applicant with “satisfactory” if no applicant has comments

excellent or very good.

//Second Loop: If more than one applicant has the comment “excellent”,

recommend applicant with the highest assessment score.

//if more than one applicant has the same score and the comment “excellent”

then recommend both candidates.

//same conditions hold when more than one candidate has the comment “very

good”.

//Third Loop: If all applicants have the comment “not qualified”, system

considers assessment scores and also returns an alert about the interview status of

the recommended applicant.

Third Year Project (Ihuoma Njoku) Page 69

The following screenshots shows the implementation of the system

recommendatory pseudo code.

A recruitment contract is sent to an applicant after the job offer has been accepted.

To increase the percentage of the progress handler bar, the java mail API was

tailored into the recruitment process. A Google mail account was set up and used

to send the recruitment contracts via email at the back end.

Third Year Project (Ihuoma Njoku) Page 70

The screenshot shows how the Gmail Port details were set up and authenticated.

A screenshot of a method used to increase percentage of the progress handler.

Report generation was implemented using JFreechart and jasper tools. The

function „JDBCCategoryDataset‟ was used to retrieve values from the database

and the chartfactory mapped these values to a 3D image with orientation settings.

The report generated can be placed in a pdf file using the jasper reporting tool.

Third Year Project (Ihuoma Njoku) Page 71

A screenshot of the Jasper PDF creator method.

Third Year Project (Ihuoma Njoku) Page 72

In this section the scenario below would be used to demonstrate how the system

works.

5.1 System Walk-through

1. A Job Vacancy is posted on the job board by the Recruitment Manager and the

status is marked as „Open‟.

2. An Applicant signs up, views Job board and applies for a Job marked as „Open‟

by uploading supporting documents e.g CV. ( An applicant cannot apply for a

job when it is closed) .

3. The Recruitment Manager terminates the Job Vacancy (ie. Job Status is marked

as „Closed‟) and starts processing the uploaded documents.

4. If the Recruitment Manager is satisfied with an applicant‟s document

(application), the applicant is then shortlisted for the assessment stage.

5. After going through all applications, the list of shortlisted applicants for the

assessment stage is confirmed and the Recruitment Manager then schedules an

available assessment date, time and venue which is sent to all shortlisted

applicants.

6. The applicant‟s individual score is entered after the Assessment.

7. When all scores have been published to applicants, the Recruitment Manager

then shortlists these applicants based on a chosen „cut off mark‟ for the

interview stage and can shortlist further by entering the maximum number of

applicants required (e.g Top 10 applicants that score over 70%).

8. The new list of shortlisted applicants for the interview stage is confirmed and

the Recruitment Manager schedules interviews for applicants by checking the

availability of the interviewer on a certain date picked.

Chapter5: Results

Third Year Project (Ihuoma Njoku) Page 73

9. The interview schedule is sent to the applicant for confirmation of availability.

10. Before sending out interview schedules for confirmation, the recruitment

manager sets the maximum number of reschedules allowed according to the

company‟s policy. If the applicant rejects the interview schedule indicating that

he/she would not be available, the recruitment manager can reschedule the

interview until the maximum number is reached. If there is no decision after

contacting the candidate via telephone, the applicant is automatically rejected.

11. After the interview has taken place, the interviewer enters detailed comments

about the interview session.

12. When all details have been entered by all interviewers, the Recruitment

Manager then selects a candidate manually or asks the system to recommend

the best candidate for the job.

13. A Job Offer is sent to the Applicant for confirmation and if the applicant

accepts this offer, the Recruitment Manager sends a contract statement to the

successful applicant.

14. If the applicant declines the job offer, the recruitment manager can choose

another candidate or ask the system to recommend a candidate again.

15. At the end of the entire recruitment process (ie. after an applicant has been

recruited), a nationality statistics report is generated.

The Screen shots of the recruitment tool while carrying out tasks in the scenario

are presented below.

Third Year Project (Ihuoma Njoku) Page 74

Screenshots

Task: Sign Up

Third Year Project (Ihuoma Njoku) Page 75

Task: Login as Applicant

Task: Applicant Homepage (navigation/Drop down menu):

Third Year Project (Ihuoma Njoku) Page 76

Task: View Job Board

Task: Apply For a Job

Third Year Project (Ihuoma Njoku) Page 77

Task: Upload Documents

Third Year Project (Ihuoma Njoku) Page 78

Task: Track Application Progress (Applicant view)

Task: View Assessment Schedule

Third Year Project (Ihuoma Njoku) Page 79

Task: View Interview Schedule

Task: Confirm Interview Availability

Third Year Project (Ihuoma Njoku) Page 80

Task: Accept Job Offer

Third Year Project (Ihuoma Njoku) Page 81

Task: Login as Recruiter (Recruitment Manager)

Task: Recruiter HomePage (navigation/ drop down menu):

Third Year Project (Ihuoma Njoku) Page 82

Task: View Activity Log

Task: Add Job

Third Year Project (Ihuoma Njoku) Page 83

Task: Edit Job Details

Task: Terminate Job

Third Year Project (Ihuoma Njoku) Page 84

Task: View Recruitment Progress (Recruiter View)

Task: Shortlist Applicants for Assessment based on documents

Third Year Project (Ihuoma Njoku) Page 85

Task: Confirm List of shortlisted Applicants

Task: Schedule Assessment for Applicants

Third Year Project (Ihuoma Njoku) Page 86

Task: Enter Applicant Assessment Scores

Third Year Project (Ihuoma Njoku) Page 87

Task: Shortlist Applicants for Interview

Task: Schedule Interview for Applicants

Third Year Project (Ihuoma Njoku) Page 88

Task: Send interview schedule to applicant

Third Year Project (Ihuoma Njoku) Page 89

Task: Reschedule Interview

Third Year Project (Ihuoma Njoku) Page 90

Task: Schedule Interview (when maximum reschedules reached)

Disabled

button

Third Year Project (Ihuoma Njoku) Page 91

Task: Job Offer (with response from successful applicant)

Third Year Project (Ihuoma Njoku) Page 92

Task: Send Statement Of Contract

Task: View Generated Report (Menu)

Third Year Project (Ihuoma Njoku) Page 93

Task: View Generated Report (Textually)

Task: View Generated Report (Graphically)

Third Year Project (Ihuoma Njoku) Page 94

Task: View Generated Report (Shortlisted Applicants)

Task: Log in as Recruiter (Interviewer)

Third Year Project (Ihuoma Njoku) Page 95

Task: Enter Details about Interview Session

Third Year Project (Ihuoma Njoku) Page 96

Task: View Interview Details

Third Year Project (Ihuoma Njoku) Page 97

This chapter evaluates the strengths and limitations of the newly built system. The

input validation and testing techniques used to measure the quality of the

application are also covered in this section.

6.1 Testing

Testing of the system was split into three methods and in the sub sections, the user

acceptance, black box and white box testing are further explained.

6.1.1 User Acceptance Testing

To verify that the system functions properly in relation to real world usage, the

user acceptance test (UAT) was carried out for the intended audience. Various

questionnaires used for the assessment of tools were examined in order to construct

a customized questionnaire to assess the recruitment tool. The reason behind the

chosen model is its simple but meaningful style of evaluation which requires only a

specific grade for a task. Feedback from the users were used for system

improvement and the description of feedback with respective solutions are shown

in the list below.

Students unfamiliar with the system played the role of applicants and

questionnaires were handed over to the users to report any problems whilst trying

features of the system. In other to perform UAT on the recruiter‟s side, there was

the challenge of user availability and analysis was based on the feedback from five

recruiters in different companies. Interface testing was done in parallel with the

user acceptance tests, in the light of users including comments with regards to the

interface in their respective feedback.

Chapter6: Testing and Evaluation

Third Year Project (Ihuoma Njoku) Page 98

Fig[7]: Questionnaire for Applicants

HRM Questionnaire

Role: Applicant

User Number: 001

Disagree Neutral Agree

1. Easy to perform basic system functionalities using the system‟s interface.

2. System responded in a predictable and consistent way.

3. Information was easy to find.

4. Appropriate amount of Graphics.

5. Clear and precise terminologies were used.

6. User manual provided was helpful .

7. Input validation error alerts were descriptive enough.

Other Comments:

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

Third Year Project (Ihuoma Njoku) Page 99

Figure[8]: Questionnaire for Recruiters

HRM Questionnaire

Role: Recruitment Manager

User Number: 001

Part1:

Disagree Neutral Agree

1. Easy to perform basic system functionalities using the system‟s interface.

2. Progress tracker gives a good idea of the job status with respect to the

recruitment process.

3. Information was easy to find.

4. Documents downloaded quickly.

5. The chart view of the report provides the data statistics quickly and nicely.

Role: Interviewer

Part2:

Disagree Neutral Agree

1. System helps manage applicants interviewed

2. Clear and precise terminologies were used.

Other Comments:

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

Third Year Project (Ihuoma Njoku) Page 100

Feedback Description Solution

1. The assessment scores should be

entered automatically after an

assessment and not manually by

the recruitment manager.

Future improvement of this system

would solve this problem due to lack of

implementation time. The easiest

solution is to integrate a third party

assessment tool with the system. The

applicants can take online tests in a

scheduled assessment center and their

scores automatically entered after

marks have been awarded.

2. System crashed while short

listing applicants for assessment

stage.

Problem was solved by closing all open

connections after use (i.e. using the

„close( )‟ operation in java).

3. Background color too dark and

fonts should be more legible.

Initially a dark blue background with

contrasting font color was used. To

solve the problem, the background

color was changed to a lighter blue and

the font color changed to black with an

increase in font size.

4. Too many alerts Solved by taking out alerts of less

importance.

Fig [9]: Analysis of Feedback

6.1.2 Code Testing

Code testing is a type of system testing where code syntax is reviewed for logical

errors. Part of the Eclipse components include an editor which compiles code

automatically as it is written. When a logical error is detected, the editor highlights

the reason for the error, the line number and solution to the problem. The image

below illustrates how eclipse editor detects a logical error and highlights the source

of the error (In this illustration, a result set containing values retrieved from the

database cannot be declared as type „int‟ but rather as type „ResultSet‟) .

Third Year Project (Ihuoma Njoku) Page 101

6.1.3 White Box Testing

White box testing was applied at unit level in order to test the functionalities of

individual components. This method helps detect hidden problems and

inconsistencies in the system. The control flow technique of white box testing was

used which involved noting the order in which components were called and

ensuring each component executed as intended. After errors were fixed in any

component, a smoke test was performed repeatedly to assure that the system would

not crash outright.

Eclipse provides a wizard for testing web service operations using a web client.

The images below elucidate how a web client was created to test the login

component of the system.

Type mismatch: cannot convert from ResultSet to int

Third Year Project (Ihuoma Njoku) Page 102

Task: Client Set Up

Third Year Project (Ihuoma Njoku) Page 103

Task: Test Login Functionality:

Task: Enter Username and Password:

Third Year Project (Ihuoma Njoku) Page 104

6.1.4 Black Box Testing

A form of system testing known as black box testing involves examining the

functionality of an application without peering into the code. To carry out the

testing process, a walkthrough of the system was performed and the system‟s

response had to be compared with the expected outcome in each case. Errors

detected during this process where fixed using white box testing explained

previously.

6.2 Evaluation

The subsections discuss strengths and limitations with respect to the newly built

recruitment tool.

6.2.1 Strengths

Using web services to implement this application serves as the main advantage

over its counterparts. The advantages have been explained previously in section

2.1. In summary, web services support application reusability, platform

independence, interoperability and cuts communication costs. Companies using

this tool do not need to worry about application maintenance or integration with

third party tools.

6.2.2 Limitations

A challenge for this web service is the time delay during communication between

server response to client request. Since customers demand twenty four seven

access to their data, this could be a huge turn off. However the delay problem can

be solved using a larger server with less traffic as opposed to the local sever used

during implementation.

Third Year Project (Ihuoma Njoku) Page 105

Lessons learnt in the course of the project implementation and ways in which the

recruitment system could be extended are discussed in this chapter. Initial project

objectives mentioned in section 2.2 and overall project achievements are compared

in the table below in order to see what requirements have been fully implemented.

7.1 Project Achievements and Project Objectives

Requirements (Functional) Comment

1. An applicant must be able to

create an account on the system.

Implemented Completely

2. A log in and log out feature must

exist on the system

Implemented Completely

3. The system must allow the

recruitment manager add, update

or deleted job vacancies

Implemented Completely

4. The user must be able to update

profile details

Implemented Completely

5. The system should have an

advanced search engine to search

for jobs or applicants.

Implemented Completely

6. The recruitment manager should

be able to schedule assessments

or interviews and notify

applicants automatically.

Implemented Completely

7. An applicant should be able to

upload any format of documents

on the system.

Implemented Completely

8. The system should be able to

generate a report about a

particular job based on some

analysis.

Implemented Completely

9. An applicant should be able

confirm availability for an

interview schedule.

Implemented Completely

10. The system should allow the user

browse job vacancies and apply.

Implemented Completely

11. The system should enable an

applicant accept or decline a job

offer.

Implemented Completely

Chapter7: Conclusions

Third Year Project (Ihuoma Njoku) Page 106

12. Shortlisting applicants for

assessments and interviews

respectively should be allowed on

the system.

Implemented Completely

13. The system should allow details

of an interview session to be

entered.

Implemented Completely

14. Insertion of the assessment score

of applicants should be allowed

on the system.

Implemented Completely

15. The system should disable

unavailable dates on the

scheduling calendar.

Implemented Completely

16. The system should display the

interviewer‟s schedule for a given

date.

Implemented Completely

17. The system should allow

rescheduling of an interview for

an applicant.

Implemented Completely

18. The recruitment progress of a job

should be able to be tracked on

the system.

Implemented Completely

Requirements (Non-Functional ) Comment

1. Multiple users (companies)

should be allowed on the system

at any given time.

Partially Implemented. The case study

was focused on a single company

initially but to enable several companies

use the web application, triggers can be

used to create new tables whenever a

new company is inserted into the

database.

2. Web services should be used to

build the system.

Implemented Completely

3. The web application should have

a simple and friendly user

interface.

Implemented Completely and the user

acceptance test was carried out.

4. The system should allow

integration with other tools or

sites.

Partially Implemented. The system can

integrate with sites but integration with

other tools has not been tested.

Third Year Project (Ihuoma Njoku) Page 107

7.2 Future Extensions

Although most of the requirements in the above table have been implemented fully,

some limitations present due to lack of time can be provided as future

developments. The system can be extended to include various modules of human

resource management such as payroll, leave, attendance and performance

management. The issue of manual insertion of assessment scores can be solved by

including an in-built assessment tool or integration with a third party tool. This is to

automate the assessment process and relieve the recruitment manager the duty of

entering individual assessment scores. The report generated on this system is based

on nationality statistics however the system can be extended to enable recruiters

choose the basis on which the report should be generated (e.g. Reports could be

based on the assessment performance of applicants from different years for the

same job). A functionality that allows different medium sized companies to use the

system at any given time can also be implemented and the tool can be implemented

as a mobile application. Finally, to extend the system further, a CV parser can be

used with key words to analyze documents and look out for specific skills. This

5. Connection to the web service by

the client should be made

effectively and quickly.

Implemented Completely

6. The system should allow a single

sign on session for all areas.

Implemented Completely

7. The system should be easy to use

whilst navigating to different

pages and act as a support for

recruitment processes in HR

departments.

Implemented Completely although

there is room for future development.

8. There should be an online

documentation or manual for the

system

Implemented Completely

9. The system should be able to run

on any platform.

Implemented Completely

10. The system should be able to

integrate with a security

framework.

Implemented Completely

11. The system should allow

validation of input fields before

any transaction.

Implemented Completely

Third Year Project (Ihuoma Njoku) Page 108

could hasten the process of reviewing applicant documents and present the

recruitment manager with a list of documents that meet the criteria of the job.

7.3 Reflection

The implementation of this project has been an excellent learning experience and

opportunity. Researching about human resource management and recruitment

management has given more insight about what goes on during the staffing process

ranging from large to small companies. Taking into consideration how the project

was started with a little background in java, the course of implementation has

greatly enriched ones knowledge base. Reviewing various technologies and trying

to solve problems using these technologies, despite errors made in this process has

bared the benefits of self learning.

At the beginning of this project, the complexity of human resource management

system was underestimated and the implementation of all modules (recruitment,

payroll, performance and more) was initially planned without considering the lack

of time. So far, I enjoyed implementing this project and indeed proud of the

amount of work done. Also, with the benefits of web services and technologies

that have been discovered through research, one intends to continue

implementation and extend the system in future.

Third Year Project (Ihuoma Njoku) Page 109

[1] Cardose and Sheth - Semantic Web Services, processes &

Application, 2006

[2] http://www.servicestack.net/docs/framework/history-of-webservices

(Accessed 02/01/2013)

[3] Eric Newcomer, Greg Lomow, A. Wessley - Understanding SOA

with Web Services, 2004

[4] Eric Newcomer, A. Wessley - Understanding

Web Services XML, WSDL, SOAP and UDDI, 2002

[5] Uehli Wahli, Deborah Shaddon, Mitch Fielding – IBM Red Books,

Servlet and JSP Programming, 2000

[6] Thierry Scheurer– Engineering Web Applications part2: Core, 2010

[7] Margaret Foot and Caroline Hook– Introducing Human Resource

Management, Fifth Edition, 2008

[8] http://en.wikipedia.org/wiki/Human_resource_management_system

(Accessed 02/01/2013)

[9] Bratton and Gold– Human Resource Management Theory and Practice, Fourth

Edition, 2001

[10] http://catmousavi.wordpress.com/2011/11/10/what-is-web-services-according-

to-w3c-big-web-services-vs-restful-services/

(Accessed 12/11/2012)

References

Third Year Project (Ihuoma Njoku) Page 110

[11] http://www.helium.com/items/1811186-why-employees-are-important-to-a

-business

(Accessed 12/11/2012)

[12] http://www.pcrecruiter.net/ - PC Recruiter Trial version

(Accessed 19/09/2012)

[13] http://www.hiringthing.com/ - Hiring Thing Trial version

(Accessed 19/09/2012)

[14] http://www.bullhorn.com/products/recruiting-software -BullHorn Trialversion

(Accessed 20/09/2012)

[15] http://www.kronos.com/ - Kronos Trial version

(Accessed 20/09/2012)

[16] http://www.orangehrm.com/ - Orange HRM Trial version

(Accessed 21/09/2012)

[17] http://www.arithon.co.uk/ - Arithon Trial version

(Accessed 22/09/2012)

Third Year Project (Ihuoma Njoku) Page 111

The image below shows the project plan followed during the course of this project.

Appendix