Project Report

On
Help Desk Ticketing System (HDTS)

SUBMITTED BY
MONZUR ALAM
ID: 171216
Batch # 11 (Prerequisite)
PMIT January 2017 Intake

SUPERVISOR NAME
MS. FAHIMA TABASSUM
ASSOCIATE PROFESSOR & COORDINATOR
PMIT COORDINATION COMMITTEE
INSTITUTE OF INFORMATION TECHNOLOGY
JAHANGIRNAGAR UNIVERSITY

INSTITUTE OF INFORMATION TECHNOLOGY (IIT)

JAHANGIRNAGAR UNIVERSITY, SAVAR, DHAKA
APRIL 2018
 Help Desk Ticketing System (HDTS)

Declaration

This project is submitted to the Institute of Information Technology, Jahangirnagar University,

Savar, Dhaka in partial fulfillment of the requirements for the degree of Master of Science in
Information Technology.

So, I, hereby declare that, this project has been done by me under the supervision of Ms.
Fahima Tabassum, Associate Professor, Institute of Information Technology, Jahangirnagar
University. I also declare that neither this project nor any part of this project or project report
has been submitted elsewhere for any kind of degree, diploma, publication or award.

……………………………………………………..
MONZUR ALAM
ID: 171216
Batch # 11 (Prerequisite)
PMIT January 2017 Intake
Institute of Information Technology
Jahangirnagar University, Savar, Dhaka

Page 2 of 106
 Help Desk Ticketing System (HDTS)

ACCEPTANCE
This Project entitled “Help Desk Ticketing System (HDTS)”, submitted by Monzur Alam to the
Institute of Information Technology, Jahangirnagar University, Savar, Dhaka has been
accepted as satisfactory for the partial fulfillment of the requirements for the degree of
Masters of Science in Information Technology and approved as to its style and contents.
Date of Submission: 13 April 2018.

Project Supervisor & Coordinator Coordination Committee

…………………………………………………….. …………………………………………………...
Ms. Fahima Tabassum Member
Associate Professor & Coordinator, PMIT Khan Mohammad Akkas Ali
Institute of Information Technology Associate Professor & Director
Jahangirnagar University Institute of Information Technology

…………………………………………………...
Member
Fazlul Karim Patwary
Associate Professor
Institute of Information Technology

…………………………………………………...
Member
Jesmin Akhter
Associate Professor
Institute of Information Technology

…………………………………………………...
Member
Risala Tasin Khan
Associate Professor
Institute of Information Technology

Page 3 of 106
Help Desk Ticketing System (HDTS)

Page 4 of 106
 Help Desk Ticketing System (HDTS)

Acknowledgement
First of all I am grateful to The Almighty for making me eligible to complete this project.

Then I would like to thank my honorable supervisor Ms. Fahima Tabassum, Associate Professor,
Institute of Information Technology, Jahangirnagar University. I am extremely grateful and
indebted to her for her expert, sincere and valuable guidance and encouragement.

The project Help Desk Ticketing System (HDTS) has been built under the supervision of
Institute of Information Technology, Jahangirnagar University. It has been a pleasure working
for this project as I have learned many new things while doing this project which were
unknown to me. This has helped to widen my views and horizon of knowledge. Hence I adage
reach this far.

I would like to express my profound gratitude to all of the faculty members of IIT for their
motivation, enthusiasm, encouragement and immense knowledge. Without their co-operation
it would have been a hard task for me to complete this Project. These people have provided
immense amount of support and assistance to me while completing this project and without
their guidance I would not have reach this far.

And I am going to take this opportunity to record my sincere thanks to course coordinator and
support staffs of IIT for sparing their valuable time for my project.

Last but not least, I would like to thank to my family for their unconditional support and
without their moral support I would not have come this far.

Page 5 of 106
 Help Desk Ticketing System (HDTS)

Abstract

Today’s corporate world is more focused on customer-centric organization and all business
organizations tries to make a win-win relationship with their customer. Without customer
satisfaction it is very difficult to be the not only a profitable organization but also a great
organization.

Customer complain monitoring and management is the big challenge of any organization. Here,
the solutions I prepare will present as a software named Help Desk ticketing System (HDTS)
comes with the complete complain management solution for any types of business
organizations. In Bangladesh unfortunately most of the organization’s complaint management
system is traditional. HDTS can overcome the barriers of traditional customer complain
management system by easy accessing the customer information, complain and resolution.

To be a successful Organization and to maintain the position customer satisfaction is

fundamental. Many organization now has branch concept and maintaining global offices, so it
is really a badly need to monitor and resolve the customer complain along with internal
support activities to all over the world.

It’s very vital for any business or services that the information must be accurate and updated.
But in manual system it is usually very difficult because it has large number of drawbacks.

This documentation will present software development process of HDTS. In designing and
developing this project Enterprise Architect is used as a modeling tool. EA practiced here
considering that it will provide better understanding of requirements, clear design, and more
maintainable systems.

The programming language or front-end tool used here is PHP, HTML and database or back-
end used here is MySQL. Unified Modeling Language will be used to analyze current system
procedures and problems’ requirements, design a logical solution to the problems, and then
implement the result through programming language and database.

My approaches allow the same concepts and notation to be used throughout the entire
software development process.

Page 6 of 106
 Help Desk Ticketing System (HDTS)

Objectives

Help Desk ticketing System (HDTS) is a part of customer relationship management that refers
to practices, strategies and technologies that companies use to manage and analyze customer
interactions and data throughout the customer lifecycle, with the goal of improving customer
service relationships and assisting in customer retention and driving sales growth
HDTS compile customer data across different channels -- or points of contact between the
customer and the company -- which could include the company's website, telephone, live chat,
direct mail, marketing materials and social media. HDTS systems can also give customer-facing
staff detailed information on customers' personal information.
At the most basic level, HDTS software consolidates customer information and documents into
a single database so business users can more easily access and manage it.
Over time, many additional functions have been added to HDTS systems to make it more
useful. Some of these functions include recording various customer interactions over email,
phone, social media or other channels; depending on system capabilities, automating various
workflow automation processes, such as tasks, calendars and alerts; and giving managers the
ability to track performance and productivity based on information logged within the system.
Few main objectives are-
- HDTS designed to reduce tedious aspects of a support staff's job. Various software tools that
integrate with the agent's desktop tools can handle customer requests in order to cut down
on the time of calls and to simplify customer service processes.
- Geolocation technology, or location-based services can use by HDTS systems include
technology that can create geographic support activity based on customers' physical
locations, sometimes integrating with popular location-based GPS apps. Geolocation
technology can also be used as a networking or contact management tool in order to find
sales prospects based on a location.
- HDTS systems help businesses optimize processes by streamlining mundane workloads,
enabling employees to focus on creative and more high-level tasks.
- Repetitive support activity can be tracked through HDTS, enabling support teams to input,
track and analyze data in one place.
- Analytics in HDTS help create better customer satisfaction rates by analyzing user data.

Page 7 of 106
 Help Desk Ticketing System (HDTS)

Table of Contents

Declaration.................................................................................................................................................2
ACCEPTANCE..............................................................................................................................................3
Acknowledgement.....................................................................................................................................4
Abstract......................................................................................................................................................5
Objectives...................................................................................................................................................6
Chapter 1..................................................................................................................................................11
1.1 Introduction........................................................................................................................................11
1.2 Knowledgebase...................................................................................................................................11
1.3 Challenges...........................................................................................................................................12
1.4 Initial Study.........................................................................................................................................13
1.5 Background of the Study.....................................................................................................................13
1.6 Theoretical/Conceptual Framework...................................................................................................13
1.7 Project Vision and Aims......................................................................................................................14
1.8 Project Scope......................................................................................................................................14
1.9 Hardware and Software Requirements...............................................................................................15
1.10 Further Enhancements.....................................................................................................................15
Chapter 2..................................................................................................................................................16
Project Approach......................................................................................................................................16
2.1 Project Management..........................................................................................................................16
2.2 Development Methodologies.............................................................................................................17
2.3 Risk Management...............................................................................................................................19
2.4 Summary.............................................................................................................................................23
Chapter 3..................................................................................................................................................24
Requirements Analysis.............................................................................................................................24
3.1 Business Analysis................................................................................................................................25
Stakeholders.....................................................................................................................................25
Customer Relationship......................................................................................................................25
3.2 Requirements Capture........................................................................................................................26
Research...........................................................................................................................................26
Interviews.........................................................................................................................................26
Sample Documents...........................................................................................................................27

Page 8 of 106
 Help Desk Ticketing System (HDTS)

Questionnaires..................................................................................................................................27
Observation......................................................................................................................................27
3.3 Requirements Analysis.......................................................................................................................27
Use Cases..........................................................................................................................................27
3.4 Functional Requirements............................................................................................................29
Non-Functional Requirements..........................................................................................................31
3.5 Best Practice Guidelines.....................................................................................................................31
Incident Management......................................................................................................................31
Problem Management......................................................................................................................31
Configuration Management..............................................................................................................32
Change Management........................................................................................................................32
Release Management.......................................................................................................................32
Chapter 4..................................................................................................................................................33
Helpdesk Software Market.......................................................................................................................33
4.1 HelpSTAR............................................................................................................................................33
4.2 Intuit Track-It!.....................................................................................................................................33
4.3 Bugzilla...............................................................................................................................................34
4.4 Summary............................................................................................................................................34
Chapter 5..................................................................................................................................................35
Technical Analysis.....................................................................................................................................35
5.1 Components of Technical Analysis......................................................................................................35
5.2 User Interface.....................................................................................................................................36
Task Identification.............................................................................................................................36
Short Term Memory.........................................................................................................................37
Execution-Evaluation Cycle...............................................................................................................37
Form Filling.......................................................................................................................................37
Menu’s..............................................................................................................................................37
5.3 IT Infrastructure..................................................................................................................................38
Desktop Applications........................................................................................................................39
5.4 Technology Options............................................................................................................40
Active Server Pages..................................................................................................................................41
PHP..........................................................................................................................................................41
PHP..........................................................................................................................................................41
5.5 Summary.....................................................................................................................................42
Chapter 6..................................................................................................................................................43
System Design...........................................................................................................................................43

Page 9 of 106
 Help Desk Ticketing System (HDTS)

6.1 Application Architecture.....................................................................................................................43

6.2 Database Modelling and Design.........................................................................................................44
Conceptual Database Design............................................................................................................44
Logical Database Design...................................................................................................................46
6.3 Physical Database Design............................................................................................................46
Normalization...................................................................................................................................46
6.4 Data Dictionary/Database Files...................................................................................................48
Data Elements...................................................................................................................................48
6.5 Functional Design...............................................................................................................48
6.6 User Interface.......................................................................................................................51
6.7 Email Reminder...................................................................................................................51
Chapter 7..................................................................................................................................................52
System Implementation............................................................................................................................52
7.1 Development Environment................................................................................................................52
7.2 Data Access.........................................................................................................................................52
7.3 Database implementation script.........................................................................................................54
7.4 Data structure.....................................................................................................................................58
7.5 Page Template....................................................................................................................................62
Chapter 8..................................................................................................................................................64
System Testing..........................................................................................................................................64
8.1 Functional Testing...............................................................................................................................64
8.2 User Acceptance Testing....................................................................................................................64
8.3 Usability Testing.................................................................................................................................65
Comparison with the Old System......................................................................................................66
Chapter 9..................................................................................................................................................67
Evaluation.................................................................................................................................................67
9.1 Project Approach................................................................................................................................67
9.2 Requirements Analysis.......................................................................................................................67
9.3 Technical Analysis...............................................................................................................................68
Choice of technology........................................................................................................................68
9.4 System Design and Implementation...................................................................................................68
9.5 User Interface.............................................................................................................................69
9.6 User Manual.......................................................................................................................................77
How to submit a ticket in “Helpdesk”.......................................................................................................77
9.7 Future Enhancements.........................................................................................................................80
9.8 Conclusion..........................................................................................................................................81

Page 10 of 106
 Help Desk Ticketing System (HDTS)

References................................................................................................................................................84
Appendix A – Reflection............................................................................................................................85
Appendix B – Interviews...........................................................................................................................86
Meeting with Asst. System Administrator................................................................................................86
Appendix C – Use Case Description Forms................................................................................................87
Appendix D – Service Level Agreement document...................................................................................92
Appendix E – Internal Documentation......................................................................................................94
Problem Logging.......................................................................................................................................94
Problem appraisal.....................................................................................................................................94
Problem confirmation...............................................................................................................................94
Issue Management...................................................................................................................................94
Escalation Procedures...............................................................................................................................95
Appendix F – Southtech Limited network topology..................................................................................96
Appendix G – Southtech Limited standard workstation build..................................................................97
Appendix H – First draft E-R diagram........................................................................................................98
Appendix I – Final E-R diagram.................................................................................................................99
Appendix J – System Architecture..........................................................................................................100
Appendix K – Support call process..........................................................................................................101
Appendix L – Support status...................................................................................................................102
Appendix M – Functional Test Execution Document..............................................................................103

Page 11 of 106
 Help Desk Ticketing System (HDTS)

Chapter 1
1.1 Introduction

Help desk management software offers numerous benefits to system administrator and IT pros.
Company employees always appreciate a helpful resource for their potential issues and queries; when
employees submit a report, they’re assured that their problems are forwarded to the correct member
of the support staff. Once a report has been submitted to the system, the employee will have the ability
to log in and track the progress of their ticket.

Help desk management software acts as a web-based ticket system that manages inquiries, as well as
other types of support processes. The software also ranks inquiries and classifies them all by priority. At
the same time, the software transfers them to the appropriate department for issue resolution.
This type of software can also help reduce the amount of training that’s needed for the support staff. As
a result, my support staff can become experts in a shorter amount of time. Such an advantage allows for
a much speedier resolution of employee’s IT issues, which in turn frees up my support staff to support
an even higher volume of employees.

Support staff can also benefit from help desk management software as their jobs become easier. In
addition, employees will receive service in a more efficient manner and wait times are dramatically
reduced. Because ticket history is stored, the support staff is better able to accurately assess issues and
take appropriate action.

Another benefit to leveraging help desk management software is that managers have the ability to keep
track of members and their performance in the company. Since the typical help desk management
solution has resolution and tracking tools, reports are easily completed. Employees will ultimately be
more productive with shorter periods of downtime, which benefits the company as a whole.

HDTS is the help desk management system which will ever need. Able to automatically assign support
tickets, keep users informed of the status of their ticket and help requester to adhere to SLA rules. HDTS
is the quicker solutions for end users and higher productivity for IT technicians.

1.2 Knowledgebase

The Knowledge Base is a database that contains problems reported by users with the corresponding
solutions. It is not a FAQ in the sense that a question doesn't need to be frequently asked. A question
should go into the knowledge base if a supporter considers that it could be of general interest. This
allows users to reduce the necessity of creating tickets by consulting the Knowledge Base.

Page 12 of 106
 Help Desk Ticketing System (HDTS)

A good knowledge base can save help desk staff so much time. IT technicians will be able to check the
knowledge base for resolutions to problems and so will users. We can make a number of resolutions
public to users allowing them to solve minor issues themselves. Also knowledgebase has the following
benefits:

o Create knowledge rich articles to provide solutions, workarounds, and FAQs.

o Include rich text, images, and attachments to the knowledge base content.
o Ensure the quality of knowledge base content with a streamlined approval mechanism.
o Organize knowledge articles under configurable topics to let end users and technicians easily
browse and access.
o Provide advanced keyword search capability and the solutions auto suggest feature to enable end
users and technicians to quickly pull out relevant knowledge articles.

1.3 Challenges

Information Technology (IT) support for end-users has emerged as one of the leading concerns of
organizations. Continuous adapting and updating of new technologies have made development of
effective and efficient help desk services challenging for organizations. Organizations must actively
search for new ways to provide better help desk services that can satisfy the growing customer
demands and expectations.

Help desk is a customer support center in an organization that provides information, administrative and
technical supports to users, with the view to solving problems that users encountered in the course of
using the organization resources or facilities. A help desk could comprise of one person or group of
persons that make use of telephone devices or software applications to keep track of problem(s) status
and thus provide solution(s) that satisfy the users.

Helpdesk could also be seen as an information and assistance resource that supports the functionality
of an organization by responding to users’ requests in a timely manner. It is hence, a core sector
through which problems, complaints and requests are reported, managed, coordinated and resolved.
Help desk software is a solution application that is used for managing organization’s help desk. It is
accessible to customer support personnel who could direct request(s) to servicing department(s).

Technical concerns are becoming a normal scenario in everyday work environment both in education
and corporate. Thus, need to constantly and effectively monitor these concerns. These require a system
that can handle them. With this in mind, an Automated Help Desk: Customer Support for Information
Technology Resource Center is a fit solution that can provide effective approach in handling all reported
technical concerns with proper record keeping and monitoring to clients and technical personnel as well
as systems administrators.
The most business area is converting into computerized system. I will take a challenge to make a
project, which is based on the common concept for Help Desk Ticketing System in any types of
organizations willing to automate their support activities system through online.
This project will help me to have a great chance to increase my ICT knowledge as well as software
development like project management knowledge, programming knowledge etc. and serve the society
as well.
Also we will gather knowledge about real life Software development like software analysis, software
design and development, database concept, testing knowledge and Implementation. It will helps us to
get a good job in future which is helpful our career.
Page 13 of 106
 Help Desk Ticketing System (HDTS)

1.4 Initial Study

The concern of the study is to develop and design an Automated Help Desk. The system is deployed to
Southtech Limited, a leading software company in Bangladesh to test its functionality and usefulness.
Based from the findings, we can herewith drawn the following conclusions:
1. The assessment of the respondents in terms of support tools to help desk which is available to
the clients reveals that help desks provide a variety of online tools and resources for the clients
to use to resolve their IT-related problems.
2. Self-help tools can effectively extend the help desk’s hours of availability, allowing users to get
answers to their questions when the help desk is not staffed. Even during the help desk’s
normal operating hours, the availability of self-service resources can reduce demand for direct
interaction with the help desk staff while keeping service availability and quality.
3. The assessment of the respondents in terms of proposed automated help desk performance
shows that personnel has knowledge of information technologies to enhance teaching and
learning, research, administration with continuous updates. Moreover, they appreciate the help
desk especially the features and tools that it provided them as they utilized the system. These
tools can stand alone, and are functionally interrelated and integrated to the help desk
automation systems

1.5 Background of the Study

Regularly the term help desk is utilized for interior backing within the organization or for outside care
groups. Numerous organizations are turning to help work area to mechanize a mixed bag of errands
and, at the same time, lessen costs by cutting staff and giving more client help from the current staff.
Organizations need to give high caliber client administration and backing to get by in today's business
surroundings.

Having the right help work area would guarantee high client fulfillment. Customer help consolidates
profits that help a customer or customer fathom and benefit from things limits by noting request,
handling issue and giving online information. The preferences of automated help work area are basic in
that they permit fewer individuals to manage larger work volume.

The help desk is increasing its importance as companies move to client-server architectures. Users who
interface with the help desk often form a general perception of the information system group.
Information systems help desks plays an important role within an organization. The help work area is in
charge of uniting an association's assets with a specific end goal to give its clients quality help and
administration.

1.6 Theoretical/Conceptual Framework

Page 14 of 106
 Help Desk Ticketing System (HDTS)

Help desk automation is for many companies the first application area of knowledge-based systems.
“The help desk is an automated knowledge distribution while payroll was an automation of record
keeping.

The theory above anchors on the help desk management system which has attracted a number of
research works. Such as, in developed world, help desk has been established as a tool for inquiries
made by users like students and staff of an institution for facilities and services.

Further, the help desk information retrieval mechanism will be suitable for users in managing the
complaints and proper system maintenance. The system helps improve help desk usability and
functionality. The figure above shows help desk system entails the following, receiving requests queries
and complaints, generating reports on identified problems, classification of mails received, filing mails,
responding to problems/ queries/ complaints stated in mails, and keeping track of problem status.

1.7 Project Vision and Aims

Help desk is designed and customized to provide businesses with an internal support system as well as a
link for providing support to its customers. Help desk applications host a number of benefits that
includes:

 Giving existing clients with information and Frequently Asked Questions (FAQ's) concerning the
organization's frameworks and approaches.
 24-hour availability thus catering to the trend of office personnel working late and to those
overseas or in different time zones.
 Troubleshooting peculiarities gives clients the capacity to take care of numerous help issues all
alone. This apparatus gives the clients with brisk and simple arrangements and sparing the
organization’s cash.
 Serves as an instrument for following and recording help work area concerns, which gives an
information base of resolutions to past exchanges concerning comparable issues.
 Supplies information concerning trends and other issues, which aids in the continuing
improvement of products and services.

1.8 Project Scope

This is an Information Systems project that will cross many disciplines including management, software
design, software development and systems architecture.

The features of this project will be most significant way of the resolution of the problem and customer
satisfaction. This features will be distinctive in comparison with the other similar types of application.
Utilization and benefits of this project may increase the efficiency of the organization. The feature will
be as follows:
 Ticket Submission
 Ticket Assignment/Allocation
 Ticket Tracking/Monitoring
 Ticket Management
 Email integration
 Notification
 User Management
 Reports
Page 15 of 106
 Help Desk Ticketing System (HDTS)

 Knowledge Base

1.9 Hardware and Software Requirements

Recommended Hardware Requirements (Application and DB Server)

o Minimum 350 MB Hard Disk space for installation

o 4 GB HDD space required for live system
o Minimum CPU - Pentium 4, 3.2 GHz
o Minimum RAM 2 GB
o Gigabit Ethernet Network card

Minimum Software Requirements:

o Operating System: Windows 7/upper or Linux RHEL 4.0

o Application Server: WAMP 2.5 or upper for Windows or XAMPP 2.1 or upper for Linux
o PHP Version: PHP 5.0.0 or upper
o Database: MySQL 5.0.7 or Upper

Other Software Requirements:

o Project Management Tools: Microsoft Project Server 2016

o Designing Tools: Enterprise Architect, Microsoft Visio
o Text Editor: Notepad++, MS Office
o Internet Browser: Mozilla Firefox, Google Chrome

1.10 Further Enhancements

Further enhancements could be made to the system prototype and will be implemented depending on
the time available.

o Further development based on the evaluation of the prototype;

o Integration with Southtech Limited’ time recording system;
o Ability to store details of and assign calls to a third party engineer;
o Management reporting – enabling managers to obtain information from support calls such as
response time and time taken to fix issues;

Page 16 of 106
 Help Desk Ticketing System (HDTS)

Chapter 2

Project Approach

This section outlines the need for a structured approach in order to achieve a successful project. I
strongly believe that a well-defined development cycle with simple, yet rigorous processes will allow us
to deliver on time an efficient software system for customer complain management system.
The following phases represent software development life cycle process:
1. Planning
2. Analysis
3. Design
4. Prototyping
5. Coding
6. Testing
a. Unit Test
b. System Test
c. Acceptance Test
7. Deployment
8. Training
9. Maintenance & Support
10. Project Handover

2.1 Project Management

Before starting any project it is important to be clear of the outcomes that are expected and the
processes involved that will achieve those outcomes. There are a number of approaches that can be
taken in order to manage the resources that are required to complete a successful project. Outline the
activities to be carried out in project management as:

1. The feasibility study

2. Planning
3. Project execution
When faced with this particular project one finds oneself in a unique position. Whilst it is an academic
assignment, it is also a live project that brings genuine business benefits to Southtech Limited. Despite
this, the feasibility study will not be carried out within the scope of the project. It is assumed that, since
the project is being undertaken at next to no cost to Southtech Limited and the risks involved with
creating the software are minimal, that, if such analysis was required, management would carry out the
task before contracting the work to a third party.
If, however, the second activity of project management, planning, was not carried out the project would
be doomed to failure from the outset. It is argued that the only way of building a full scenario of the
project is to catch every fragment of detail as early as possible. Clearly, this will be accomplished by
considering carefully each aspect of the project before it is undertaken. However, the planning is an
ongoing process of refinement and that each iteration of planning becomes more detailed and more

Page 17 of 106
 Help Desk Ticketing System (HDTS)

accurate than the last. As such information gathering will be required at the beginning of each stage to
ensure that it is carried out effectively and on time.
Taking heed of this, the following Gantt chart (Figure 2.1) shows the breakdown of tasks with the planned
execution dates, whilst the detail of these tasks will be discussed in later chapters.

Figure 2.1: Project schedule

Microsoft Project Server 2016 is a project management tools that provides managers with tools to carry
out successful projects on time and within budget. Control over the project plans is very much a part of
the project management framework. Controlling and revisiting the project plans ensure that the
project:

oIs producing the required products which meet the defined Acceptance Criteria
oIs being carried out to schedule and in accordance with its resource and cost plane
oRemains viable against its Business case
As mentioned above, the final activity involved in project management is the project execution. This
stage often contains the design and implementation stages which undoubtedly requires a satisfactory
level of coordination. With a clear understanding of the projects activities, convenient communication
channels are established in order to ensure that this coordination takes place. With all members of
staff at Southtech Limited having access to email and their office being in Leeds, this is easily achieved.

There are a number of methods employed within the IT industry that can be adopted to achieve good
project management. Such methods are designed for large scale projects involving complex teams of
developers and end users, and, as a result are not entirely relevant to this project. Although it is
relatively small, it is hoped that by taking aspects of these frameworks and maintaining a dynamic
approach throughout, a successful project will be achieved.

2.2 Development Methodologies

Having decided on a general approach to managing the project, a decision must be made on how best
to execute the project plan.
Page 18 of 106
 Help Desk Ticketing System (HDTS)

Rapid Application Development:

This methodology puts emphasis on quickly producing prototypes for the users to evaluate. The
methodology is not suitable for all projects, particularly ones that require thorough planning. It is best
used when there is a focused product scope, decisions can be made by few people, there are not many
members in the project team, and the technical architecture is clear.

This would not be a suitable method for this particular project because, as yet, there is not a focused
product scope and the requirements are not clear. It is possible to adopt once all user analysis is
complete, but then it will not constitute a methodology that can be applied to the project as a whole.

Joint Application Development:

Joint Application Development (JAD) is a methodology where developers work intensively with users in
workshops and agree documented business processes. The advantage of using such a process is that all
decision makers are generally in one room. This should speed up the communication process and
enable decisions to be made instantly. On the other hand, the sessions may not cover everything that
needs to be covered in one go. Prototyping, for example, could not take place unless many of these
sessions were to be held.

Due to the nature of this project and of business itself, it is unlikely that JAD will be adopted as the
methodology used. It is very unlikely that the directors, administration and support staff will have time
to all sit down together for an extended period of time to discuss what, essentially, is a small project.
However, lessons can be learned from the methodology, and being based in Leeds, it is probably a good
idea that meetings are arranged when the key decision makers will be around; this should help aid the
communications process and ensure that decisions are made by the relevant people.
The Waterfall Model:
This approach suggests making just one attempt at a project and getting it correct the first time. When
it works well, the waterfall approach allows project completion times to be forecast with more
confidence than with some more iterative approaches allowing projects to be controlled effectively.

Page 19 of 106
 Help Desk Ticketing System (HDTS)

Figure 2.2: The waterfall model

Whilst the approach is generally suited to the project at Southtech Limited, it is felt that a prototype
may be necessary to gauge users’ initial feelings about interface design and the functionality of the
system. The process has the advantage of being able to determine exactly which stage the project is up
to.

For this reason, the overall aspect of the Waterfall cycle will be adopted for this project, although it will
be altered somewhat in the coding, and testing stages. Instead of adhering to the waterfall approach
for these levels, a prototype approach should be adopted that will allow for iterative implementation
techniques to be utilized.

Software Prototyping Design

Software prototyping enables developers to quickly portray the system functionality, can be classified
as either throw-away or evolutionary – that is, the prototype is either discarded after demonstrating it
to the user or it is used in the next iteration of development. We also quote a number of reasons to
use prototyping; a few are outlined here:

o Learn by doing
o Clarification of partially known requirements
o Production of expected results

Despite these advantages, there are a number of disadvantages that must be taken into consideration
when using such an iterative process. Many of the steps required in good programming practice may
be overlooked. Documentation, system testing and efficient programming may be overlooked if the
final prototype is deemed acceptable to implement by the project champion. These issues can be
avoided by making the link between the waterfall model and prototyping methodologies. This ensures
that the design is well documented and, as Southtech Limited are a small organization, provides all
parties with necessary feedback early on in the development cycle.

2.3 Risk Management

A risk in software projects can be defined as an unwanted event that has negative consequences
software project risks have two important characteristics.
- Uncertainty
- Loss
Risk may affect the project, the software being developed or the organization associated with the
software. All projects carry some risks. For successfully completion of the project some possible risks
will be identified at the beginning of the project and accounted for the project plan.

The risk management strategy for the proposed project consist of:
 Risk identification
 Risk Prioritization
 Impact and evaluation
 Risk analysis
Page 20 of 106
 Help Desk Ticketing System (HDTS)

 Risk planning
 Risk monitoring

Risk Identification, impact, evaluation & prioritization:

This activity is a systematic attempt to specify threats to the project. Basically various risks likely to
affects the project are identified. One method to identify risks is to use a risk check-list, a list of possible
risk types. Following risk types can be considered.

 Technology risk
- Hardware Unavailability
- Virus affect
- Database performance
- Software Component performance

 People risk
- Data Theft
- Staff Turnover

 Organizational risk
- Unable to implement new technology
- Poor management
- Financial problem

 Tools risk
- Tools unavailability

 Requirement risk
- Requirement specification delay

 Estimation risk
- Time and Cost estimation risk

Impact of risk:

Once the risks to the computer system have been identified, the next step is to estimate the impact of
the occurrences of each individual threats or risks. The identified risks are creating a bad effect on this
project below the table to show the impact of risk:

SL Risk Type Description/Impact

1. Hardware Technology The essential hardware will not be delivered on right time
unavailability Risk and power problem can effect on project and cause of
delay.
2. Virus Technology risk The virus that can create a big impact on system and
hardware. Sometimes it can be damage full system.
3. Data Theft People risk Important information can be stolen or unauthorized
access to create a big impact on project and effect to
delay project.
4. Staff turnover People risk Experience staff will leave the project as a result project
delivery can be delay.

Page 21 of 106
 Help Desk Ticketing System (HDTS)

5. Implement new Organizational The underlying technology on which the system is built is
system risk superseded by new one. As a result the absence the new
technology on project.

6. Tools Tools risk System development stage case tools must be require to
unavailability develop the system, if it is unavailable the right time then
system delivery can delay.
7. Requirement Requirement User requirement is very important to develop system if
specification risk user requirement or demand cannot fulfill the system
delay then it could be rejected by user or delay requirement
system also delay.
8. Time and cost Estimation risk When develop a system their time as fixed so delivery
system on specific time and also estimated cost.
9 Poor Organizational Overall poor project management can cause of project
management risk delay and make the project disaster.

10 Database Performance slowness can make the customer unhappy

Technology risk
Performance and can be failed to increase the usability.

Risk Priority:

At this stage, priority the risk that are identified in previous stage. The main aim of priority is to
determine their importance. This importance is based on some criteria such as, money loss, time loss,
liability, quality assurance etc. prioritizing of risk in this project shown in following bar charts.

Risk Priority
12

10

8
Technology risk
Tools risk
Risk Level

Estimation risk
6 Organizational risk
People risk
Requirement risk
4

Risk Type

Page 22 of 106
 Help Desk Ticketing System (HDTS)

Fig 2.3: Risk Graph

The bar chart shows technology risks are the major risk which is content hardware unavailable, virus in
this project. In the development stage hardware can be failed or virus can be affected as a result
development time can be delay and bad effect on project. People risk, tools risk, estimation risk are also
priority this project. Organizational risk and requirement risk are low priority.

Risk Analysis:

All risk is defining priority in my project. The main risk are define technology risk because, I will work for
developing this projects there has occurred electricity voltage up-down many times of each day, virus
can affect and also unavailable of necessary hardware like RAM, HDD, Printer etc. so for that reasons I
need to back up my project work daily and collect my necessary hardware at right time. The second
priority is people risk, projects could be affected by the unauthorized people, try to access data, and
loss of information. So I need security in my computer as well as my project hand writing documents.

The risk analysis is assessing probability and seriousness of each risk. Probability may be very low,
moderate, high or very high. Risk effects might be catastrophic, serious, tolerable or insignificant. Below
the table,

Sl. no Risk Probability Effects

1. Hardware unavailable Low Catastrophic
2. Virus High Serious
3. Database performance High Serious
4. Data Theft Low Catastrophic
5. People turnover Moderate Tolerable
6. Unable to use new technology Moderate Tolerable
7. Poor management High Serious
8. Case tools High Serious
9. Requirement specification delay Moderate Serious
10. Time & cost estimation High Tolerable
Table: Risk Analysis

Risk Planning:
For dealing with those risks I have categories three strategies there are avoidance strategies,
minimization strategies, and contingency strategies plans.

Sl. no Risk Strategies Description

1. Hardware unavailable Minimization Ready to backup hardware and use
it appropriated time
2. Virus Avoidance Use antivirus software to avoid
virus risk
Page 23 of 106
 Help Desk Ticketing System (HDTS)

3. Database performance Avoidance Use best or higher and original

database to avoid bad performance

4. Data Theft Minimization Use security tools to prevent

unauthorized access
5. People turnover Minimization Higher experiences staff
6. Unable to use new Contingency Organization able to develop
technology system by new technology
7. Poor management Contingency Solve the problem by organization
meeting
8. Case tools Avoidance Collect available case tools
9. Requirement specification Avoidance Contact user by every stage to
delay fulfill their requirement
10. Time & cost estimation Avoidance To use more people and complete
project just time.

Risk monitoring:
Risks monitoring that assess each identified risks regularly to decide whether or not it is becoming less
or more probable, also assess whether the effects of risk have changed.

Sl. no Risk Description

1. Technology risk Late delivery of hardware or support software, many
reported technology problem
2. People risk Poor quality of staff, liability problem. Job availability ,
higher staff
3. Organizational risk Lack of quality, gossip, not punctual, lack of action taken
by management
4. Tools risk Reluctance by team members to use tools, complaints
about case tools, demands for higher or powered tools
5. Requirement risk Many requirement change request, customer
complaints
6. Estimation risk Failure to meet agreed schedule, failure to clear
reported defects.
Table: Risk Monitoring

2.4 Summary

Many of the development methodologies and project management techniques above have been
designed for large scale projects that require teams of developers working alongside numerous people
with the client. In such a scenario it is clear to see that meticulous planning is essential to the success
of the project. However, these may not form the best approach for a small project. By taking strengths
from a wide selection of methods, the project should be made a success as long as care is taken
throughout to ensure that the work is on schedule and that planning is communicated effectively.

The decision has been made to use marry the best features of the waterfall model with evolutionary
prototyping to form the implementation and testing stages of the project. It is hoped that in doing so
the both the advantages are gleaned from the use of prototyping but the disadvantages are avoided.

Page 24 of 106
 Help Desk Ticketing System (HDTS)

Chapter 3

Requirements Analysis

In systems engineering and software engineering, requirements analysis encompasses those tasks that
go into determining the needs or conditions to meet for a new or altered product or project, taking
account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting,
validating and managing software or system requirements.

Requirements analysis is critical to the success or failure of a systems or software project. The
requirements should be documented, actionable, measurable, testable, traceable, related to identified
business needs or opportunities, and defined to a level of detail sufficient for system design.

Conceptually, requirements analysis includes three types of activities:

1. Eliciting requirements: (e.g. the project charter or definition), business process documentation,
and stakeholder interviews. This is sometimes also called requirements gathering or
requirements discovery.
2. Analyzing requirements: determining whether the stated requirements are clear, complete,
consistent and unambiguous, and resolving any apparent conflicts.
3. Recording requirements: Requirements may be documented in various forms, usually including
a summary list and may include natural-language documents, use cases, user stories, process
specifications and a variety of models including data models.

Requirements analysis can be a long and tiring process during which many delicate psychological skills
are involved. Large systems may confront analysts with hundreds or thousands of system requirements.
New systems change the environment and relationships between people, so it is important to identify
all the stakeholders, take into account all their needs and ensure they understand the implications of
the new systems.

Analysts can employ several techniques to elicit the requirements from the customer. These may
include the development of scenarios (represented as user stories in agile methods), the identification
of use cases, the use of workplace observation or ethnography, holding interviews, or focus groups
(more aptly named in this context as requirements workshops, or requirements review sessions) and
creating requirements lists. Prototyping may be used to develop an example system that can be
demonstrated to stakeholders. Where necessary, the analyst will employ a combination of these
methods to establish the exact requirements of the stakeholders, so that a system that meets the
business needs is produced. Requirements quality can be improved through these and other methods

o Visualization. Using tools that promote better understanding of the desired end-product such as
visualization and simulation.
o Consistent use of templates. Producing a consistent set of models and templates to document
the requirements.
o Documenting dependencies. Documenting dependencies and interrelationships among
requirements, as well as any assumptions and congregations.

Page 25 of 106
 Help Desk Ticketing System (HDTS)

3.1 Business Analysis

Stakeholders
Before starting any analysis of the users’ requirements for the proposed system, it is imperative that
every stakeholder with a claim in the new system is identified to ensure that a full analysis can be
carried out. Southtech Limited is a relatively big company that provide customized solutions in
Information Management to a number of corporate and government bodies. The company employs
approximately 200 employees who work both in local and global remote locations. There are four key
business units that operate in the company: administration, sales, development and infrastructure. The
development team is split down into project teams based on the different technologies with which the
company produces solutions. Because the sales department have no stake in the new helpdesk system,
they will not be analyzed any further.

The administration business unit is made up of four employees that are responsible for the day-to-day
running of the business. Amongst other tasks, including accounting and contract management, these
staff are responsible for the management of the support helpdesk. The development business unit
makes up a large proportion of Southtech Limited’ workforce and have the both writing software for
clients and supporting these clients should any issues arise with their systems. The infrastructure team
manage all of the internal systems and, where contracted, the systems of individual clients. They
primarily deal with networking and software support issues and are very much support based as
opposed to development. Heading the company is a team of directors though the only one with an
input in the system is the Delivery Director who has overall control of the help desk.
From this high-level stakeholder analysis, it is clear that the sales team will have no interest in the new
system, and as such will not be discussed any further. The remaining stakeholder groups can be
grouped to form the following user groups:
o Helpdesk administrators
o Support technicians
o Directors
Further elaboration of these user groups will be necessary during the requirements analysis in order to
gain a complete understanding of what the new system must achieve.

Customer Relationship
The analysis so far has only discussed the internal company but it is important to think of all
stakeholders that have an interest in a system, and as such clients of Southtech Limited must be
considered. In the present environment, customers that require support will call or email the help desk
with their problems. This provides the customer with a single point of contact and ensures that
resources are assigned according to the business impact to that customer (Figure 3.1). It is felt that
ensuring the new system matches current working practices as opposed to bringing with it
organizational change is a more satisfactory method than changing procedures and will lead to
improved user relations that will ensure the customer interfaces with Southtech Limited in exactly the
same method with the advantage that their request is dealt with more effectively.

Page 26 of 106
 Help Desk Ticketing System (HDTS)

Figure 3.1: Helpdesk structure

3.2 Requirements Capture

Grasping a full understanding of the clients’ requirements is fundamental to the success of the project.
There are a number of approaches for obtaining the users requirements and each of these will be
explored in order to acquire the broadest and deepest appreciation of what must be achieved in the
system. The importance of requirements analysis isn’t just for functionality. Without it, there would be
no way of evaluating the system, as there would be nothing to evaluate against. There are five
commonly regarded methods of gathering the requirements of a new information system that may be
relevant to the project in hand.

Research
Many projects are undertaken by a third party that have limited understanding of the organization they
are about to carry out the project for. In many cases it is the first opportunity the analyst has to gauge
an understanding of the business activities, processes and practices that may go on within the
company. There is no necessity for research or background reading into Southtech Limited because of
the twelve months the author spent there as a support technician gaining understanding and
experience of the procedures within the company.

Interviews
Though an understanding of the business is known, in-depth knowledge of the procedures many
members of staff have to undertake is not apparent. Accordingly, interviews have been carried out
with a number of personnel from different departments so that their requirements can be captured.
Although they can be time consuming, and difficult to arrange, they have the capacity to be open-
ended so that interesting facts can be explored when they emerge. The results of the interviews (
Appendix B) will be analyzed in depth in the following sections. One difficulty experienced during
interviewing was ensuring that the answers given were on track. Quite often it was found that
interviewees moved off on tangents and wanted to discuss things that would relate to other systems
and would not form part of this project.

Page 27 of 106
 Help Desk Ticketing System (HDTS)

Sample Documents
The use of document sampling to determine the information that is used by people in their work, and
the inputs to and outputs from processes which they carry out, either manually or using an existing
computer system. The sample documents collected from the interviews include a completed SLA form
(Appendix D) and a document specifying the current call logging procedure (Appendix E). These will be
particularly beneficial when designing the database as they outline exactly what data should be stored
and some of the processed behind storing this information. However, it would be risky to rely solely on
sample document. If the procedures are going to change then they are unlikely to form a reliable
framework on which to base the new system but. They do however help to model the data structures
and give valuable input to the design process In addition to these sample documents, access has been
provided to the current system so that its’ implementation can be analyzed and relevant processes
abstracted. Care will be taken to ensure that the current system does not limit the scope of the new
system. Whilst many of the features may need porting to the new system, they may also require
substantial re-thinking of the processes going on behind them. As such, like the other documentation,
the software shall only be used as a guide.

Questionnaires
It is felt that questionnaires are not suitable for this project. Although the system is in place for much
of the company, by holding interviews with few people, but across the spectrum, interviews are
regarded as being more efficient than a questionnaire. Although it is cited that it can be an economical
way of gathering a lot of data, it is difficult to construct a good questionnaire. There are too few people
involved in the system to warrant spending time on creating a good questionnaire when this time
would be better spent probing fewer people in interviews.

Observation
By watching people in their own environment it is possible for parts of their jobs to be uncovered that
may not generally be brought out during an interview. It is also noted that people are not good at
estimating the times it takes them to complete certain tasks [6]. Though it may be important to
uncover as much detail as early on as possible [2] the prototyping methodology chosen for this project
implementation was chosen in order to save on time consuming tasks such as observation. Whilst
certain details may be neglected in early prototyping stages, these should be uncovered later on during
system testing. As such it is felt that continuing to the design and implementation stages as quickly as
possible will be beneficial to the project overall.

3.3 Requirements Analysis

The output from the requirements capture must be analyzed to obtain a complete list of functional and
non-functional requirements that can then be used to design and implement the system. This analysis
forms a fundamental part of the system design stage in building on the requirements captured in the
previous section and creating a comprehensive appreciation of what must be achieved.

Use Cases
One of the main uses of the interviews that were held at Southtech Limited has been to create Use
Case diagrams that provide a high level model of what should be achieved in the system. A Use Case
diagram provides not only a simple way of communicating ideas with users [7] but also, when
complete, produces a high level understanding of what must be achieved in the system. The Use Cases
were built up over a number of interviews with different people within the organization including
stakeholders and a number

Page 28 of 106
 Help Desk Ticketing System (HDTS)

of Developers and Support Technicians. These results were then summarized both to create the Use
Case diagram but also to elaborate on each use case and generate a comprehensive requirements list.

uc Use Case Model

Support Requester Activity

Submit Ticket

Update Ticket

View Ticket

Recover Ticket ID

Support Requester

Search Help

View Knowledgebase

Close Own Ticket

Figure 3.2: Use case diagram

Page 29 of 106
 Help Desk Ticketing System (HDTS)

uc Use Case Model

Administrative Activity

SubmitTicket

Update Ticket

View Ticket

Resolve Tickets

Administrator
Assign Tickets
Support Staff

Delete Tickets

Manage
Knowledgebase

Manage Users

Manage Categories

Manage Setti ngs

Manage Reports

Figure 3.3: Use case diagram

Each of the Use cases in Figure 3.2 are described in Use Case Description forms found in Appendix C
which discusses the functionality required in more depth, these should then, in turn, provide a better
understanding of the system must achieve to aid the design process.
3.4 Functional Requirements
Based on the Use Case diagram above, a list of requirements is produced at a lower level of abstraction
to that the design and implementation incorporate the appropriate functionality

Page 30 of 106
 Help Desk Ticketing System (HDTS)

One of the minimum requirements for the project is to produce a suitable prototype call logging system
with the ability to track cases and create reminders for support staff when deadlines approach in line
with the clients Service Level Agreement. One question that must now be raised is what is deemed to
be suitable for a prototype system. The decision taken in Chapter 2 to use hi-fidelity, evolutionary
prototyping must be used, to some degree, as a guide. The following list of requirements outlines
exactly what is considered necessary in the system, and whether or not the function forms one of the
minimum requirements of the project.

1. Helpdesk Administrator
1.1. Manage support call
Minimum
Requirement?
1.1.1. Log a new call Y
1.1.2. Update support call log Y
Assign support call to a technician
Close support call log
1.1.3. Obtain status of call Y

1.2. Manage Clients

1.2.1. Add customer to list Y
1.2.2. Display all customers Y
1.2.3. Display customer details Y
1.2.4. Update customer details Y
1.2.5. Enter SLA details Y
1.2.6. Add / Remove client employee Y

1.3. Manage System

1.3.1. Add / Remove system users Y

1.4. Manage Contracts

1.4.1. View / Update default SLA response times Y

2. Support Staff
2.1. Resolve customer issues
2.1.1. View assigned calls Y
2.1.2. Update call log with action taken Y
2.1.3. View customer contract details Y
2.1.4. Pass call to third party N

3. Non-User Specific
3.1. Email Support call details to a system user N
3.2. Email support technician when about to break SLA Y

Table 3.1: Requirements list

Page 31 of 106
 Help Desk Ticketing System (HDTS)

Non-Functional Requirements
The non-functional requirements for the system form a set of the main desires of the users
interviewed. It is wished that the system currently in place is improved upon in terms of the user
interface. The security aspects must kept simple by relying on the user credentials entered when the
user first logs in to Windows and, finally, the system must be easy to manage from a technical point of
view. Though these will not be explicitly dealt with in terms of functional requirements, the design
must be based around these concepts – they are no less important than the functional requirements.

3.5 Best Practice Guidelines

The IT Infrastructure Library (ITIL) is a set of best practice guidelines that has been widely accepted as
the industry de facto standard. The ITIL standards break down service requests into several distinct
areas:

o Incident Management
o Problem Management
o Configuration Management
o Change Management
o Release management
Understanding how the system should incorporate these areas is important before the design stage is
entered. This section concentrates on the relevance of each of these areas and considers their inclusion
in the new system. Whilst these are arrived at from best practice guidelines, they may not be
appropriate for the kind of support that Southtech Limited provide or may be out of the scope of what
the system should deal with.

Incident Management

The primary goal of the Incident Management process is to restore normal service operation as quickly
as possible and minimize the adverse impacts on business which must be considered to be the main
function of the helpdesk system because it is a fundamental role within IT Support that incidents are
managed effectively. When not appropriately dealt with, incidents will lead to extended periods of
decreased productivity or none whatsoever. Normal operation should be defined within the service
level agreement. Whilst this may be done at Southtech Limited, there is nothing in their current system
to ensure that the service level agreement is met. Functionality in the new system support would
ensure that the clients’ SLA agreements are adhered to and that penalties imposed upon failing to
reach these agreements are minimized. The requirements capture has stated that this must be in the
new system and, as such, forms part of the minimum requirements of the project.

Problem Management

Going a stage beyond incident management leads towards an enriched system capable of managing
problems – the underlying causes of many incidents. The goal of Problem Management is to minimize
the adverse impact of Incidents and Problems on the business that are caused by errors within the IT
Infrastructure, and to prevent recurrence of Incidents related to these errors. By incorporating
problem management into the new system the project would be made much more complex. It is felt
that this area should be kept outside the scope of the project for several reasons.
Firstly, the number of calls that Southtech Limited receive is relatively few when compared with many
corporate helpdesks. Additionally, with few technicians communicating problems between them very
Page 32 of 106
 Help Desk Ticketing System (HDTS)

effectively by email this is not currently a priority. Whilst it is felt that having some form of problem
management mechanisms within the system, it is hoped that a well-designed database will easily
support future application enhancements without fundamental system changes.

Configuration Management

The support that must be provided to customers is the configuration of their network, servers and
personal workstations. The customers who outsource all of their IT to Southtech Limited may expect
some form of management of their assets. The information that is held about the customers systems is
held in a Microsoft Word document, providing instructions on how to remote control their systems and
on what is installed on their servers and workstations. Although it may be beneficial to hold this
information together with the incident log (for example, to provide a sound basis for support of an
incident or to identify the computer that a certain user has allocated to them) it expands the scope of
this project too far and would push timescales significantly. This is something that could, and probably
should be considered and implemented in future versions of the helpdesk system but, because the
documentation is already held elsewhere, it does not form part of the minimum functional
requirements for the successful day-to-day management of the helpdesk process.

Change Management

As described in the ITIL guidelines “change arises as a result of Problems, but many Changes can come
from proactively seeking business benefits such as reducing costs or improving services.” It is felt that
change management should have processes that remain separate from the day-to-day running of the
helpdesk. Whilst the need for certain changes may arise from an underlying system problem with, it is
more than likely that any change would be managed by an account manager, not by a support
technician. Implementing this kind of functionality may increase the complexity of the system
unnecessarily because current systems (be them software or human) already deal effectively with this
process.

Release Management

Release management however, it does not deal primarily with support issues, or more precisely,
problem issues. Whilst it may be important to the entire support process to manage releases of
hardware and software to the customer, the aim of the system is to provide functionality that aids the
technician when faced with a new support call, not when undertaking a new project for a customer,
which, in itself will have a different set of procedures to adhere to.

Page 33 of 106
 Help Desk Ticketing System (HDTS)

Chapter 4

Helpdesk Software Market

From the analysis undertaken in the previous chapter it is felt that Southtech Limited’ requirements are
quite unique. Whilst many businesses are likely to operate an IT helpdesk, they are unlikely to require
the functionality needed within Southtech Limited. A comparison that could be made is with the
helpdesk at Southtech Limited and the Information Systems Services (ISS) helpdesk operated by the
various organizations. They are very different indeed. Whilst the ISS manage all of the systems for one
body, split into numerous departments, Southtech Limited manage systems of many different
organizations, each with their own contract. Identified in this section are a number of solutions aimed
at corporate helpdesks with the similar objective of Southtech Limited – to provide the user with a
customer focused support environment that facilitates the successful management of individual system
issues. Whilst it may be interesting to focus on the technological aspects of the each system, analysis
will be carried out, and a decision made about the best approach to be taken for the project based
upon the benefits the software brings to the company not the technology it utilizes.

4.1 HelpSTAR

HelpSTAR is an out-of-the-box package aimed at the mid-market and has the functionality that each of
Southtech Limited’ individual clients are likely to require. One particularly nice feature of the system is
its business workflow rules that allow an administrator to control requests from the users to the correct
people in the organization. It also takes parts of the ITIL best practices and as a result rich functionality
is provided through the inclusion of problem management and asset management components.
Additionally it meets Southtech Limited’ requirement to escalate the priority of a call and to generate
alarms for when this is done. The Advanced and Enterprise versions of the software are also packed
with a web portal and comprehensive reporting solutions that are both useful to the Southtech
Management and to their clients. In spite of these well-packed features, in a very nicely presented user
interface, there is one major problem with this software – it has absolutely no support for setting up
different clients and, as such, would make charging customers for work more than a headache. In fact,
charging for work would not be the first problem. It would be completely impossible to store details
for each of the customer and their employees as the package is only designed to be used on the
helpdesk of an individual organization. Installing it for each organization is not a possibility either, both
down to the practicalities of this and the fact that it would not be possible to track calls efficiently from
one central location.

4.2 Intuit Track-It!

Like HelpSTAR, Track-It! has a well presented user interface that, without performing a comprehensive
Human-Computer Interaction analysis, seems to lead to good usability. Many of the features are
similar to those in HelpSTAR; it is hard to differentiate the two products. Again, this product has no
facility for creating numerous customers and will not support the requirements of Southtech Limited.
However, a feature from both this and the previous package could be nicely adapted into the new
system. Each system provides a statistical analysis screen (Figure 4.1) that provides the user with real-
time information about the support calls that are open on the helpdesk. It outlines how many calls are
within and in breach of internally configured service level agreements and displays this information
through the use of graphs.

Page 34 of 106
 Help Desk Ticketing System (HDTS)

Figure 4.1: Screenshot of the HelpSTAR Dashboard (System Statistics)

4.3 Bugzilla

Bugzilla is currently used within Southtech Limited for bug tracking in the software that they produce
for clients. It is an open source package from the makers of the Mozilla web browser, that, when
installed is very bare. It therefore requires a lot of configuration and personalization before it can be
used effectively. As the package stands, it is not suitable for issue tracking of support calls like the
previous two packages. It is very much designed around the tracking of bugs within software packages
as opposed to tracking of issues with users’ computer systems (for example, it does not have a field for
the type of call such as ‘hardware’ or ‘software’). In order to get the system running as a suitably
featured issue tracking system, it would need a huge integration project to be undertaken in order for
this to happen and even then, it may not be as good a solution as the previous two packages. However,
the system has several advantages. It is web based and as such can be accessed from anywhere within
the organization, without the need for software to be installed on the clients PC. Also, because it is
open source it is possible to adapt the system to the companies’ requirements. However, the work
required to do this is likely to outweigh the work required to create an entirely new system from
scratch. It is often harder to look at code and determine what it is doing than to sit down, design and
implement a package from scratch.

4.4 Summary

The market research has shown that no solution provides the functionality for setting up different
organizations but, at best, only allows for different departments to be configured within the company.
Whilst this sort of ‘off the shelf’ approach may be acceptable for a helpdesk that serves just one
organization, it is far from ideal for an organization that has to serve many separate businesses with
numerous contractual arrangements. Although it may be possible to track a package down that has the
functionality required, the costs involved in performing the research and in procuring software that
may still require changes, or may be too sophisticated for Southtech Limited’ needs, are more than
likely going to outweigh the costs of implementing a system in house.

Page 35 of 106
 Help Desk Ticketing System (HDTS)

Chapter 5

Technical Analysis
Many a software project has failed due to an incomplete or inaccurate analysis process, especially
technical analysis. Technical Analysis is a key step while developing a software application. It can be
useful to-

 Confirm with the customer that we have gathered all business requirements accurately, and begin
with designing and building the application after approval from the customer.

 It can be used by the Designers and Developers as a reference when building the application.

 It can be used by the client to verify that the final application actually matches what was initially
agreed upon.

5.1 Components of Technical Analysis

There are two parts to Technical Analysis – drafting an Application Specification Document and
generating Use Cases. An Application Specification Document is usually derived from the Requirements
Documentation from a Business Analyst. This document briefly specifies various features of the
application, details parameters of how the application will be built, etc.
A sample structure of an Application Specification Document for a typical Web Development project
would be as follows:
1. Introduction

o Background

o Purpose

o Scope

o Definitions, Acronyms and Abbreviations

o References

o Overview

2. Overall Description

o Use-Case Model Survey

o Assumptions and Dependencies

3. Specific Requirements

4. Non-functional Requirements

o Browser Compatibility

Page 36 of 106
 Help Desk Ticketing System (HDTS)

o Layout

o Graphics and Web Design

o Resolution

o Log History Analysis

o Cookies

o SMTP Server

o Secure Sockets Layer

o Accessibility

o Performance

5.2 User Interface

The issue of usability is an important issue that must be addressed during the design of the user
interface. Though the system is not intensively used, it is still important to try to reduce the time it
takes to carry out a task. While it is perceivable that cutting the time it takes to carry out a task by
fractions of a second may save certain companies, employing hundreds of people carrying out the same
task, a lot of money, it simply won’t be the case at Southtech Limited. More importantly for the
company is the need for the interface to be designed so that learning the system is simple and carrying
out day-to-day tasks is more efficient than the current system. Many web based systems fail to combat
basic usability issues and end up being less efficient than their predecessors.

It is believed that by looking at current methods and theories in Human-Computer Interaction (HCI) and
by evaluating the user interface on the current system, a more effective interface can be achieved in
the new system.

Getting Human Computer Interaction (HCI) issues solved in systems is not an easy task to carry out and
requires knowledge from many fields of science. The ideal designer of an interactive system would
have expertise in a range of topics: psychology and cognitive science to give her knowledge of the
user’s perceptual, cognitive and problem-solving skills; ergonomics for the user’s physical capabilities;
sociology to help her understand the wider context of the interaction; computer science and
engineering to be able to build the necessary technology; business to be able to market it; graphic
design to produce an effective interface presentation. Clearly, an Information Systems degree program
is not going to cover every area that is preferred in HCI but it is possible to pay careful attention to the
design of the system to increase, as much as possible, the usability to its users. This will be the focus of
this section.

Task Identification

There are number of principles in interface design. We need to identify and think carefully about the
tasks that the user must carry out. This has been achieved in the requirement analysis above.
However, we have to go further by monitoring the frequency at which users carry out the tasks. They

Page 37 of 106
 Help Desk Ticketing System (HDTS)

also explain how tasks with a high frequency will benefit by assigning shortcut keys to them thus aiding
the user in quick navigation. Although no formal frequency observation has been carried out, it is clear,
due to the limited number of tasks they carry out, that the administrators’ task of managing a support
call will be most frequent, with client, contract and system management being used much less
frequently. In terms of the support technicians and administrator, because they only have one high-
level task to carry out, this form of analysis is not relevant and breaking these functions into smaller
tasks is not feasible beyond those tasks discussed in the requirements analysis.

Short Term Memory

The short term memory of a human is used to remember details to carry out everyday tasks. For
example, a simple multiplication may be divided up into separate blocks, each block requiring its short
term storage in memory. The capacity of this memory is very limited and people can usually remember
7 ± 2 facts. It is important to note that a system should not rely on the user’s short term memory very
much at all. For example, they should not have to remember information from one page to complete
the next. However, it is important that a page does not become so cluttered with information that the
user cannot possibly store enough of the information in short term memory to be able to realistically
complete their task.

Execution-Evaluation Cycle

This is a model of user behavior designed around the execution of a command on a computer system.
If the user moves the mouse, the system then moves the cursor on the screen, and the user then
evaluates the response the system had to their command. There are several stages in this process
which starts off by the user establishing their goal. The user then forms an intention to carry out
actions and then decides on the actual actions they are going to take. The user then executes those
actions and perceives the changes they have on the system. They then interpret and evaluate the
system state after the action has been carried out. This shows that user inputs should be intuitive and
that the outputs should not give unexpected results. It is important to ensure that the system adheres
to common standards that users have grown to expect and to ensure that it does behave in a manner
that the particular users at Southtech Limited expect.

Form Filling

One area of the system where usability will be fundamentally important is the data entry of new
support calls. Often the calls will come in on the phone and so the page must be easy to navigate and
to enter data into, possibly using just one hand. The literature read on this subject has not elaborated
on how one should make a form usable. Most form filling interfaces allow easy movement around the
form and allow some files to be left blank. They also require correction facilities, as users may change
their minds or make a mistake about the value that belongs in each field. However, we must go further
if we are to pay real attention to the data entry form. As mentioned, the form must allow for easy
movement around it. In theory it should be as easy as moving a pen to the relevant area on a paper
form. Though this may not be possible in practice, by simply ensuring that the ‘Tab’ key results in the
cursor being moved to the next field and not some random space is one step towards a usable system.

Menu’s

Page 38 of 106
 Help Desk Ticketing System (HDTS)

A system that has many different parts will, by definition, require some form of navigation to those
parts. Because menus rely on recognition, rather than recall, it is important to ensure that they are
meaningful and by clicking on them have the desired effect. Menus can be hierarchical and as such
grouping of tasks can be done. This aids the navigation process and an important factor in the helpdesk
system will be to ensure that, where applicable, suitable measures are taken to make hierarchical menu
structures effective rather than hinder the user.

5.3 IT Infrastructure

Southtech Limited run a mainly Microsoft based server infrastructure with just a couple of Linux servers
utilized for support certain customers. The business infrastructure is broadly supported by:

o Microsoft Active Directory 2012

o Microsoft Exchange Server 2013
In addition to these, there are a number of servers that host the Intranet and development projects.
Figure 5.2 below is a simplified model of the, more complex, internal network (Appendix F) but it does
show the servers that must be analyzed.
Microsoft Active Directory 2012

Microsoft Active Directory (AD) is a Directory Service based on the open Lightweight Directory Access
Protocol (LDAP) standard. The LDAP directory service is a system in which the organizational hierarchy
can be stored and attributes of the users such as their password and contact details are managed.
Because AD is based on open standards it is interoperable with other directory services that employ the
same standard. More importantly, there are several application programming interfaces (APIs) that
enable easy integration of LDAP directories into any software application. All of the employees at
Southtech Limited have their own AD entry configured with their password and contact details. Given
an appropriate choice of development platform integration of AD in the new system will be possible.

Microsoft Exchange 2013

Microsoft Exchange server is an email server with which Microsoft’s email client, Outlook, is designed
to cooperate with. Each user has their own mailbox on the server that they connect to every time they
open Outlook. No email is stored on the clients’ computer unless they specify local caching of email.
Like AD, Exchange enables the use of standard protocols such as SMTP and POP3. In addition,
Exchange integrates with AD and as a result enables central management of users’ mailboxes as well as
easy lookup of email addresses within the organization.

Microsoft Internet Information Services

Internet Information Services (IIS) is a component of the Microsoft Windows Server operating system
that, given the appropriate infrastructure, provides web hosting capabilities to the machine it is
installed on. IIS provides support for Active Server Pages (ASP) and PHP applications. These are
proprietary web development platforms discussed later. Like many other Microsoft products, IIS
integrates completely within the AD infrastructure but can also be used as a standalone server that
manages its own security.

Page 39 of 106
 Help Desk Ticketing System (HDTS)

Microsoft MYSQL Server 2016

There are many different relational database management systems (RDBMSs) from a number of
software manufacturers both from the open source and proprietary markets. Southtech Limited’
decision to use Microsoft MYSQL Server 2016 is consistent with the choices made with the rest of the
infrastructure. All of the products marketed by Southtech Limited use this product so the knowledge
within the company is high. However, their decision to use this software may have impacts on the
design of the helpdesk system. It is important to know the limitations of using Microsoft’s MYSQL
server product as opposed to others such as Oracle or MyMYSQL. These are discussed in section 5.3.

Page 40 of 106
 Help Desk Ticketing System (HDTS)

Figure 5.2: Simplified network diagram

Desktop Applications

Every member of staff at Southtech Limited has a personal computer or laptop with a standard
configuration. Though some staff may require additional software the core components will always be
installed. Knowing exactly what the clients configuration is makes implementation of a system much
easier. For example, web developers often have difficulty in ensuring their pages are compatible with a
range of web browsers (Mozilla Firefox and Internet Explorer being prime examples). Because it is
known that all the clients will be running Internet Explorer 6 designing the page will be much easier.

5.4 Technology Options

Having now discussed the environment within which the new system must work, it is possible to
examine the different development technologies available.

Client / Server Architecture

The infrastructure at Southtech Limited provides an environment that allows for a client / server
architecture. The decision that must be made is whether to implement a thin-client or fat-client
architecture. A thin-client architecture ensures that all of the business logic is controlled and the
information is received from the server is in its final state and as such has no further processing to do
before it displays the information. A good example of a thin-client architecture is that of a webpage
where processing may be done on the server to obtain data to be displayed, but the client receives only
the information in its final state – the HTML. In contrast, with a fat-client, much of the processing of
data is done on the client’s computer and as such, requires more powerful machines. However, the
latter results in much of the load being taken away from the server. There are many examples of fat-
client applications, but perhaps the most relevant example is the helpdesk system currently employed

Page 41 of 106
 Help Desk Ticketing System (HDTS)

by Southtech Limited. This is a Windows application that must be installed onto each of the individual
machines that require access to the system.

There are a number of issues encountered with this architecture. Installation of the application is
nontrivial; it takes approximately ten minutes to install onto each machine and requires manual ODBC
configuration. Any updates made to the application also result in a requirement to redeploy
throughout the company – far from ideal. Whilst the current architecture takes load away from the
server, much more data will be transferred between the client and the server than with a thin-client.
Consequently, it is felt that moving to a thin-client architecture would lead to a number of benefits that
must be exploited in the new system.

MySQL DB

Figure 5.3: Current and proposed architectures

All the servers within the company are connected via a Gigabit network; workstations only benefit from
a tenth of this speed. In recognition of this it is advantageous to have most data transferred between
the servers and not the workstations (Figure 5.3). By transferring only the presentation of the
application, the bandwidth restrictions between the server and the workstation are less of an issue. It
is also useful to be aware that the power provided by a dedicated server is more appropriate use of
processor power than relying on a PC tasked with doing a number of jobs.

This leads to two options. Either the new helpdesk system is developed using web based technology or
an architecture is sought after through the deployment of technology such as the Citrix Meta Frame
Server. As Southtech Limited do not have the infrastructure in place to support this style of thin-client
architecture, a client-server approach will be adopted in the form of a locally hosted Intranet site using
the existing infrastructure.

Web Technologies

Since the birth of the World Wide Web technology has moved on considerably from static HTML pages
to dynamic, data-driven solutions that have the capacity to support entire business processes. Having

Page 42 of 106
 Help Desk Ticketing System (HDTS)

an understanding of the technologies available and their limitations is fundamental to the correct
implementation of the help desk system. Three technologies are to be discussed: PHP, Active Server
Pages (ASP) and PHP. It must be decided if, and how, each of them would fit into the infrastructure at
Southtech Limited and an understanding of how the technology would integrate with the requirements
outlined above must be gained.

Active Server Pages

Much like PHP, Active Server Pages (ASP) offers a server side scripting environment but it is possible to
write pages using a number of different programming languages. Again, like PHP, ASP development
provides a server-side scripting environment in which pages are rendered ‘on-the fly’ to return
dynamic, data-driven content in an HTML page. PHP maybe a more appropriate and advanced
technology for the application development.

PHP
Before discussing the use of PHP a short introduction to Microsoft’s .NET framework should provide the
reader with a better understanding behind the technology that supports it. The .NET framework as An
environment in which there is a common transparent foundation layer through which any
programming language can access either data or operating system functionality. Two key parts of the
framework are the .NET class library and the Common Language Runtime (CLR). The CLR enables the
framework to interpret a number of different languages supported by .NET. Regardless of the language
used (VB.NET, C# or a number of others) the source code is interpreted by the CLR into a lower level
managed code, Microsoft Intermediate Language (MSIL), that is then executed within the .NET
environment.

PHP
PHP is a server-side scripting language that provides database access, form processing, user
authentication and many other tasks. In short, it has the capabilities for developing the help desk
system with all of the functionality described in the requirements’ analysis. Often it is used in
conjunction with the Apache web server that is run on approximately 69% of the Worlds Web servers.
It will also run on both Microsoft Windows and on the Linux platform.

However, Southtech Limited use both Apache and have IIS enabled on their internal facing Intranet
server. It is possible to install PHP on an IIS installation but no-one in the company would be able to
support this as well as the Microsoft technologies they have already adopted. Despite the fact the PHP
would provide all the functionality required in the new system, it would be unwise to endorse its use in
this environment. Trying to incorporate existing Microsoft application data into a PHP run Web site
would require starting from scratch with a great deal of headaches including purchasing new programs.
This, coupled with the issue of no direct support for Windows, leads to an alternative that offers similar
functionality but integrates more transparently into the infrastructure to be sought after. On the face of
it, PHP appears to be a suitable environment for the helpdesk system. However, Microsoft’s latest web
development tool. Moreover, it is technology that aligns perfectly with the current infrastructure and
employee skill-set at Southtech Limited.

Page 43 of 106
 Help Desk Ticketing System (HDTS)

Figure 5.4: The execution model for Web architecture

5.5 Summary

Throughout this section a number of options have been considered and the decision to embrace the
PHP & MySQL platform has been taken. Although this is not the preferred method of Southtech
Limited, because of their expertise in the area and their ability to support it is goes to Microsoft
technologies, the decision has been taken on the merits of the technology itself as it is a smaller part of
our Southtech developments. This technology provides the most advanced functionality with better
flexibility from the alternative approaches discussed. It addresses issues that have been uncovered
historically and also integrates into the infrastructure that Southtech Limited’ core business relies on.

The choice of technology has not been a trivial one. It is accepted that whichever tool was chosen there
would be somewhat of a learning curve during the implementation. However, whilst the author has
experienced both ASP and PHP, very little experience of PHP has been encountered. It would, however,
be naïve to think that the areas of experience will help with this project. It is clear that whichever
method chosen would result in a learning curve but the choice has been made because of the qualities
the technology brings to the project not because of an understanding of syntax – this can be easily
learned.

Chapter 6

System Design
It has already been decided that an evolutionary prototyping approach is to be taken, so why
concentrate on the design of the system? The answer to this is simple, without a suitable system
design the issues discussed in Section 2.2 will not be overcome. Whilst the prototyping method is
considered the best approach for this project, it is also felt that documentation and efficient
programming practices must be realized. As a result, the analysis from the previous chapter will aid the
design of the system before any implementation is to take place.

Page 44 of 106
 Help Desk Ticketing System (HDTS)

6.1 Application Architecture

The architecture of the application is designed to fit into the infrastructure at Southtech Limited which
leads to a distributed n-tier application. This is defined as a model that helps developers to create
flexible and reusable applications by breaking it up into different tiers. As a result, it is likely that if
changes are made to a single tier, it is possible that the entire application will not need updating when
those changes are made.

Taking the n-tier path also leads to a number of benefits created by the integration of the internal
infrastructure. The helpdesk application itself will not deal with the security aspects – Active Directory
will handle this. The solution will use the current MySQL Server and will utilize email facilities provided
by the Exchange server (see Figure 6.1 for the architecture summary or Appendix G for entire
architecture). Finally, the client communicates with just one server, which brings together each tier in a
single point of entry for the client and references other tiers when they are required.

Though the system architecture is reasonably complex it leads to a number of benefits for Southtech
Limited that will simplify the management of the new system. Because IIS will not have to deal with
security, password management remains centralized in the organization, and a single logon is retained.
By including a tier for dealing with email the system will be capable of fulfilling one of the minimum
requirements of sending email when a call is close to breaking its SLA. Finally, by keeping data separate
from the application it provides a much more flexible framework. The application could be easily
redesigned without having to redesign the data structures. Likewise, in theory at least, the data
storage mechanism could be altered without having to make changes to the actual application. In
addition, unless the application itself changes, significant improvements could be made to the
implementation in the future without the users of the system being aware of the details of these
changes (for example, that database could be moved to a faster server; users would not know the
details of the change apart from the fact that their queries had been executed in less time).

Page 45 of 106
 Help Desk Ticketing System (HDTS)

Figure 6.1: Application Architecture - UML Deployment diagram

6.2 Database Modelling and Design

A sound database design will be the key to the success of this system. By ensuring that, at this stage, all
the relevant information is incorporated into the system, the rest of the system design will fall easily

Page 46 of 106
 Help Desk Ticketing System (HDTS)

around the database. Database design is generally thought to involve the modelling of different
Entities, Relationships and Attributes. Breaking down the design of the database is broken down into
different stages:

o Conceptual database design

o Logical database design
o Physical database design

The conceptual design stage is used to build an understanding of each of the entities, relationships and
attributes that have been identified. This is then translated to form a logical design by creating valid
relations. The physical design must then be created and will be dependent on the Database
Management System in use.

Conceptual Database Design

The Entity-Relationship (ER) diagram allows the database designer to get a clear picture of how
different entities relate to one-another. Requirements analysis is the most important step (step I) of
the database life cycle and is typically the most intensive and as such the previous analysis is extremely
important. In order to determine the relevant entities, relationships and attributes, the internal
documentation is the most useful (see Appendix D and Appendix E). These documents outline the
entire call logging process and also give an insight into the data that has to be captured with each call.

The E-R diagram in Appendix I illustrates the entire conceptual database design. This is summarized
below by displaying just the entities and their relationships. However, this design was not conceived in
just one attempt. Each time an E-R diagram is completed it is imperative that it is validated to ensure
no traps have been fallen into.

In the first draft on the E-R diagram (Appendix J) many errors were identified between the entities
‘Customer’, ‘Helpdesk’ and ‘Support Call’. The relationship ‘agrees’ comes from the entity relationship
between ‘Customer’ and ‘Service Level Agreement’ but has no meaning between the ‘Customer’ entity
and ‘Helpdesk’ entity. Ignoring the ‘Service Level Agreement’ entity, the relationship between
‘Customer’ and ‘Helpdesk’ would be calls. However, as identified in Figure 2.1, just doing this causes in
a connection trap. Though the relation would be read “A customer calls the helpdesk who logs a
support call” there is no way of identifying which support call belongs to which customer.

Page 47 of 106
 Help Desk Ticketing System (HDTS)

Figure 6.2: Customer, Helpdesk and Support calls relationships

To overcome this, the ‘Customer’ attribute must not relate to the helpdesk; after all it is a member of
staff of the customer that will make the call not the customer itself.

Helpdesk
Client Priorities Defines Administrator

Agrees Contract Logs

Customer Employs Staff Makes Support Call

Managed By

Call Assignee

Figure 6.3: Summary E-R diagram

The example above outlines the importance of getting the design correct. If this task had not been
carried out and a database had been implemented without due care and attention, it is likely that
during the implementation of the web front-end issues would be encountered or at the very least,
writing valid MySQL queries would much more complex.

Logical Database Design

With a conceptual model completed, the logical database design which incorporates the tasks of
deriving relations, validating the relations using normalization and ensuring that all constraints are
checked. From the conceptual model (the E-R diagram) Connolly and Begg state that the following
must be carried out:

o For each strong entity in the model, create a relation that includes each attribute
o For one-to-many relationships a copy of the primary key attributes is passed from the parent to
the child relation as a foreign key.

In addition to this, some of the attributes associated with the ‘Support call’ entity may themselves need
to be promoted to entities. The ‘Action’ attribute is multi-valued and requires promotion to an entity
with the ‘Support_ref’ primary key attribute of the ‘Support Call’ entity passed as a foreign key
attribute. The ‘Problem category’, ‘Status’ and ‘Priority’ attributes must contain values held within an
attribute domain which requires some form of integrity constraint. There are a number of ways that
this can be accomplished. Firstly, within the DBMS, in this case it will be Microsoft MYSQL Server, check
constraints can be utilized to ensure that the values entered are from the required domain.

Page 48 of 106
 Help Desk Ticketing System (HDTS)

Another method is to promote the attribute to an entity in the design and pass the primary key of the
parent entity into the new entity as a foreign key attribute. For the helpdesk system this method
provides a significant advantage over check constraints. Because the constraints are stored in a lookup
table, the onus to maintain these constraints can be removed from the developer and passed onto the
user. This will create an environment in which the system can be updated dynamically instead of
requiring the skills of a database programmer. However, by choosing this method, the database design
is made more complex.

6.3 Physical Database Design

Having decided on a suitable logical design, the physical database design is reasonably easy. A full
script containing the implementation of the database can be found in Appendix L; this specifies the
entire database schema including the data type of each attribute.

Normalization

By following sound database design techniques using E-R modelling, the database should be fully
normalized, that is, it is in Boyce-Codd Normal Form (BCNF). However, it is possible that mistakes may
have been made during the modelling process so it is therefore necessary to check each of the
functional dependencies in each relation. A functional dependency “describes the relationship
between attributes and when it defines a super key of the relation, the relation is said to be in BCNF.
Appendix M shows the functional dependencies for all of the relations in the database.

Page 49 of 106
 Help Desk Ticketing System (HDTS)

Figure 6.5: ER Diagram

There are a number of other design considerations that need to be taken into account when creating
the logical database design. The way in which the conceptual design models the users of the system
over complicates the database schema. Instead of having two entities named ‘Helpdesk Administrator’
and ‘Call Assignee’, one entity named ‘Internal Staff’ is more appropriate. A member of staff then has
the attributes of ‘Username’ and ‘Role’. The reason for the choice of these attributes is because the
environment that the database is sitting in must be considered. Because the system is to integrate with
Active Directory to deal with user authentication, it generally uses usernames as opposed to their full
name. Though it would be possible to deal with full names, this would make the implementation of the
system more complex.

Page 50 of 106
 Help Desk Ticketing System (HDTS)

Before:

After:

Figure 6.6: Before and after redesign

6.4 Data Dictionary/Database Files

A Data Dictionary is simply a record of data about data. It may be manually compiled or it may be a fully
automated package. All definitions of elements in the system – data flows, processes, and data stores –
are stored in Data Dictionary.

Data Dictionary is an integral component of structured analysis. Data Dictionary provides additional
information about the system.

A Data Dictionary is a catalog- a repository --- of the elements in a system. These elements center on
data and the way they are structured to meet user requirements and organization needs. The major
elements are data flows, data stores and processes. The data Dictionary stores details and descriptions
of these elements

The Data Dictionary is the only common source of definitions for users and investigators alive. It is the
single source of answer of answers to all questions regarding the format and context of the data sets
used in the system.

Data Elements

The most fundamental level of data is the data element. Data elements are building blocks for all other
data in the system like Data Names, Data Description, Aliases, Length, and Data Values.

6.5 Functional Design

Modelling of the data structures has specified exactly what information is stored in the new system.
This section details the processes that must be undertaken in order to store that information. It is
important to get a good understanding of how processes interact with one another but because
prototypes are being utilized, the application design should be considered only as a guide.

Page 51 of 106
 Help Desk Ticketing System (HDTS)

Figure 6.7: Site structure

The structure of the site is determined very much by the use case diagram formed during the
requirements analysis stage (see Figure 3.2). From this use case diagram, the technician has the
following requirements:

1. View support calls

2. View customer details
3. Add actions to a support call
In the design of the system, these use cases have been combined into one section of the site titled ‘Call
Log’. Sub-pages off the call log will allow the technician to view the details of a call and add actions to
that support call. It has been decided that requirement 2 above is only required when the technician is
dealing with a support call. For this reason the design of the ‘View call details’ page must include an
area that displays the details of the customer so that they can be easily contacted.

The Helpdesk Administrators inherit the functionality of the technicians but are provided with more
facilities to manage the support call process. Figure 6.7 displays this extra functionality which again
relates to the use cases of these actors.
The Delivery Director has an additional use case labelled ‘View call Statistics’. In the first prototype of
the system, this functionality will not be implemented. However, if it was to be designed into the
system, it would be an additional top level page. This means that it would be an easy addition in a
future version and would not require vast overhaul of the system.

Call Log

Central to the entire system is the call logging functionality. This page displays the calls and will allow
the user to filter the results depending on a set of criteria (see Figure 6.8). From the page it will be
possible to log a new call and to enter any calls that have already been logged. This will then enable
the users to enter further details to the call.

Page 52 of 106
 Help Desk Ticketing System (HDTS)

Customers

As was mentioned in Chapter 4 there are no systems that make it possible to log calls for a number of
different clients. To overcome this, the customers screen allows administrators to add new customers
and to attach employees to them. This then enables the Administrators to log new calls for these
clients. In addition to this, each customer will be able to have a Service Level Agreement configured
either to the system default settings or to their own personally agreed contract with Southtech Limited.

System Maintenance

The system maintenance screen will simply allow the core functionality of the system to be maintained
and configured. The global settings such as default SLA response times, default priorities will be
configured here as well as adding and removing authorization for certain users within Southtech
Limited’ network.

Figure 6.8: Submit a Ticket

Page 53 of 106
 Help Desk Ticketing System (HDTS)

6.6 User Interface

With the aim of ensuring an acceptable user interface that addresses the HCI issues discussed in
Section 5.1 a page template has been developed using the popular CSS and JavaScript . This design has
not included the use of any HTML mark-up but instead simply positions components on the page where
they are considered to be most suitable. Figure 6.9 outlines the main page template and where the
page details are a little more complex, further images have been created to aid the implementation of
the pages.

The page template is divided into five distinctive areas, the header, menu bar, sub menu, page options
menu and the main content. The header and the menu bar will remain the same throughout the site
and will not change. The sub-menu and page-options sections will be dependent upon the selected
page and the content will clearly be the content of the page selected.

Figure 6.9: Home Page of HDTS

6.7 Email Reminder

The Email Reminder required in the system will send an email out to members of staff that are
responsible the calls that they have assigned. This engine is not suited to a Web application because it
would require somebody to have the page open all the time. Because it is a service that must run
constantly (during business hours) a Windows Application running as a scheduled task will be
developed.

Before the engine can be created rules must be defined for when the emails must be sent, and when
reminders should be terminated. These are variables that may change over time so a configuration
screen should be provided in the ‘System’ section of the site.
The process of sending reminders will be:

o Read database
o Find calls that have had no update since being logged and are X minutes from breaking SLA
o Repeat the reminder every Y minutes
o Send a final email when SLA has been broken

Page 54 of 106
 Help Desk Ticketing System (HDTS)

o Repeat every minute of the working day (defined in customers SLA)

Chapter 7

System Implementation

7.1 Development Environment

Before the implementation of the system, and in addition to the minimum requirements of the project,
a development environment has been created, instead of having to use the internal infrastructure at
Southtech Limited. There are several reasons behind this decision. Firstly, if the infrastructure at
Southtech Limited was utilized either the development would have to take place in the office or a
connection through their VPN would have to be made. This would not be satisfactory because the
bandwidth of the connection restricts what can be done and it would not be practical to visit the office
on a daily basis. The second reason for this decision was that in implementing the system, it is not
necessarily known what the impacts on other systems might be. It is extremely dangerous to make
changes on business critical systems unless full testing has been undertaken and this is a risk that the
author was not prepared to take.

It is not entirely necessary for the environment at Southtech Limited to be replicated for the
development of the first prototype. However, by undertaking this task now as opposed to future
iterations of development, it is possible to build a higher fidelity prototype which encompasses more
functionality such as email and the integration of Active Directory. This is beneficial for evaluation of
the new system because, from as early a stage as possible, users will have an understanding of the
functionality that will exist in the final product. Possibly more compelling than this is that by creating
the environment that the system will sit as soon as possible ensures that the final product will work
within the infrastructure at Southtech Limited without the need for excessive reconfiguration or coding.
Though not ideal and not identical to the infrastructure at Southtech Limited, the development
environment consisted of a Personal Computer of reasonable specification connected to a broadband
connection through a firewall and router. In order to configure Active Directory and the email server,
Microsoft Exchange, a domain name was required. For the purposes of the project, the author already
had an unused domain name, skiint.com, and decided to use it in this environment. In doing so it is, in
essence, the equivalent to Southtech Limited using their domain name, southtechgroup.com.

As discussed in Section 6.1 the system relies on many different server components. At Southtech
Limited these are generally hosted on different servers, however, in this development environment,
they are all packed onto the same machine. Whilst this may have adverse effects on the performance
of the system, it is not a release environment and only has one person interacting with it. As such the
performance issues are not apparent, although it is not a true reflection of the final use of the
application where many users may interact concurrently with the system.

7.2 Data Access

The underlying requirement of this system is to store and retrieve information captured at different
stages of the helpdesk procedure. In order to achieve this access to the database must be provided to
the web front end of the system. Having chosen the technology for this, ADO.NET, an easy way of
calling common methods is to create a data class. By including the class in the namespace of the
application, it is possible to call data access functions at any time which significantly decreases the

Page 55 of 106
 Help Desk Ticketing System (HDTS)

development time and code duplication. The access to the database enables MySQL queries to be
executed and a Dataset

returned to the application. Stored procedures are used in MySQL server so that query strings are not
required in the code. This creates two advantages. Firstly, less data is transferred between the client
and the server so the execution is more efficient. Secondly, the detail of the query is hidden from the
application as so another layer of abstraction is formed. This deskills the MySQL required but ensures
that any developer can still work with the database.

Page 56 of 106
 Help Desk Ticketing System (HDTS)

Figure 7.1: Data Access

7.3 Database implementation script

Page 57 of 106
Help Desk Ticketing System (HDTS)

Page 58 of 106
Help Desk Ticketing System (HDTS)

Page 59 of 106
Help Desk Ticketing System (HDTS)

Page 60 of 106
 Help Desk Ticketing System (HDTS)

7.4 Data structure

User Login Table:

Page 61 of 106
 Help Desk Ticketing System (HDTS)

User Table:

User Password
Reset Table:

Page 62 of 106
 Help Desk Ticketing System (HDTS)

Knowledge Base Table:

Support Ticket Category Table:

Page 63 of 106
 Help Desk Ticketing System (HDTS)

Support Ticket Table:

Page 64 of 106
 Help Desk Ticketing System (HDTS)

Support Ticket Mail table:

7.5 Page Template

The implementation of the system requires the page design from Section 6.4 to be translated from a
simple two-dimensional image into a fully rendered PHP page. All the images are sliced into relevant
sizes and placed into a generic HTML page which is then used as the basic template every time a new
PHP file is required. The newly created .php file can then have its main content inserted within the
development environment depending on which page is being implemented.

The Object Orientated approach of PHP allows for inheritance of classes that lends itself to the creation
of these page templates. Figure 7.2 illustrates how the page template structure works. As was
previously mentioned, all standard pages in a PHP application inherit methods and attributes from the
Page (System.Web.UI.Page) class. Instead of the pages of this application inheriting from the
Page class, they inherit from the Page Base class that includes additional cross-site functionality.

Page 65 of 106
 Help Desk Ticketing System (HDTS)

Figure 7.2: Page inheritance

Web User Controls form another component of the page template model and are used to encapsulate
common elements of code into a single component that can be used on many different pages [28]. In
the implementation of this system, two user controls were created; a header (header.php) and a
footer (footer.php). The footer control actually does nothing but close the page off, no functionality
is included though it could easily be inserted should the requirement arise. The primary component of
the entire template is the header control. This contains the functionality for obtaining the users’ name
that has logged onto the system, displaying the date and time, and providing the user with applicable
menu items. Figure 7.3 illustrate the use case diagram of various pages access by Administrator and
support staff.

Page 66 of 106
 Help Desk Ticketing System (HDTS)

uc Use Case Model

Administrative Activity

SubmitTicket

Update Ticket

View Ticket

Resolve Tickets

Administrator
Assign Tickets
Support Staff

Delete Tickets

Manage
Knowledgebase

Manage Users

Manage Categories

Manage Settings

Manage Reports

Figure 7.3: Use case diagram of various pages access by Administrator and support staff
Chapter 8

System Testing

Before an evaluation of the system can be carried out it is vital that system testing is performed so that
the requirements can be measured against the achievements made. For Southtech Limited, testing
represents a more vital stage that ensures the development carried out fulfils their requirements and
that the system is adept enough to deal with every user’s requests. Two forms of assessment must
therefore be carried out; firstly, internal validation testing to ensure data integrity and that the
software runs without any adverse issues being apparent. Secondly, acceptance testing to ensure that
Page 67 of 106
 Help Desk Ticketing System (HDTS)

the users are satisfied that the functional and non-functional requirements captured at the beginning
of the project have been implemented appropriately.

8.1 Functional Testing

The sole aim of the functional testing carried out is to ensure that the user cannot ‘break’ the system by
entering erroneous data. Creating a list of every function implemented in the system, and considering
the different approaches users may take that could break the system is a good way of achieving this.
Appendix M provides a comprehensive list of what is and what is not implemented in the system.
Where certain functionality has not been implemented Southtech Limited have agreed that future
developments will address this absence.

Because of the prototyping approach, coupled with the fact that a second iteration now needs to be
developed, it is felt that the tests provide some very positive feedback about the system. One of the
most significant outcomes of the functional testing is the uncovering of the fact that field validation
needs to be implemented on each of the forms. It was felt through the implementation of the system
that, because of the amount of work required to incorporate the functionality requested, time would be
better spent implementing the functionality that the users would recognize to be more beneficial to
them. As a result, field validation has been left to be more of a tidying up exercise after the system has
passed through another iteration of development. The forms implemented successfully provide the
functionality required with just a few omissions that do not form the minimum requirements (discussed
in the project evaluation).

8.2 User Acceptance Testing

At the beginning of this project, after all the requirements capture and analysis had been undertaken, it
was necessary for Southtech Limited to sign-off the requirements list and for them to have an
understanding of what would be included in the first prototype. More important than the validation
testing in Section 8.1 is the acceptance from the Users that it works as they expect it to. The below
figure 8.1 shows whether or not the implementation has been formerly accepted by all the users
questioned. This was determined by holding demonstrations with a number of users across each of the
functional areas and allowing them to use the system for a number of test cases prepared beforehand.

Page 68 of 106
 Help Desk Ticketing System (HDTS)

Figure 8.1: Testing

8.3 Usability Testing

In response to the poor efforts made in the previous system to address HCI issues, much emphasis has
been put on usability throughout this project. There are many defects that can be encountered with
usability including the navigation, screen design, terminology, and feedback. It is hoped that the
careful planning and design of the user interface will pay dividends with a system that is easy to learn
an intuitive to the user. However, it is acknowledged that interface design is an iterative process and
that addressing the issues of being able to learn the system quickly and creating an intuitive user
interface in the first iteration of development is unlikely. The test plan developed uses a task based
approach to determine how well the user interacts with the system; both with navigability and their
comprehension of responses they receive from the system. The test does not explore every area of the
system but ensures that a good cross-section of the functionality is encountered. By measuring the
time it takes to complete a task, comparisons may be made to the old system. However, by running
the tests more than once, it is possible to make judgments on how easy the system is to learn.

Accordingly, the tests were repeated three time. The tasks performed were:
1. Change the SLA for a specified customer from the default agreement to a customized
agreement
2. Add a specified employee to a specified customer

Page 69 of 106
 Help Desk Ticketing System (HDTS)

3. Log a support call for a specified customer employee and assign it to a specified
technician
4. Update the status of the call logged to show that it has been cancelled by the user
The testing was performed with a sample of four Administration employees as it is they who require
the most functionality and use the system most frequently. It is also arguable that they do not have as
deep an understanding with computer systems as the support technicians and as such provide a better
sample for testing the learning aspects of the system.

Comparison with the Old System

Given the latency issues encountered with the system testing above, a fair comparison could not be
made from the office in Leeds between the old and the new systems. However, it is preferable that
some comparison is made so instead of getting end users to perform the test, an ‘expert’ (the author)
user will be used with local copies of each system hosted on the development environment. The
author is considered to be an expert user because they have developed the new system and had
substantial exposure to the old system. As such it is felt that the test is being conducted fairly.

Comparison between two tasks provides enough feedback to assess the usability differences between
each system:
o Add the employee ‘User-1’ to the customer ‘Southtech Limited’
o Submit a ticket for ‘user-1 at ‘Southtech Limited’ assign to ‘Support Staff-1’
On the first task, the new system performed better than the old system by ten seconds, the second task
was performed just five seconds faster on the new system. This latter result is interesting. Though
much of the real-estate has been cleaned up and invalid fields have been removed, a gain of only five
seconds advantage is reaped. The test does however show that the user interface is improved and,
from talking to people at Southtech Limited, is generally more pleasant to work with than the old
system.

Page 70 of 106
 Help Desk Ticketing System (HDTS)

Chapter 9

Evaluation
The focus of the project must now progress from one of creation and innovation to one of
contemplation. From the approach taken right through to the testing of the development work carried
out, evaluating these sections provides a way in which future iterations can be embarked upon more
successfully.

9.1 Project Approach

A methodology for the approach to this project was not sought after simply because one existed. It
could have been decided to just use a single methodology because it had successfully been utilized
elsewhere. This, however, would have been missing the point. The approach was decided on many
aspects of many different methodologies that were each felt to bring individual strengths to the
project. The question now is, was the approach successful? And can the project be deemed a success?

The decision to use the Waterfall model incorporating the use of prototyping was taken to try and
create a structured environment that was dynamic enough to adapt to the changes around it. This
method worked to a degree. The design of the system took two weeks longer than originally planned
because it was deemed more necessary to build sound foundations based on an excellent
understanding of the requirements than to move onto developing a system without all the required
modelling having been carried out. However, taking this decision forced proceeding stages to be
delayed and as such the implementation the project write-up each suffered a one week delay. So was
the approach right? It is easy to say yes because it was delivered on time. It is felt that the approach
was probably too dynamic with deadlines not enforced strictly enough. For a relatively complex project
with limited time boundaries and numerous other factors affecting one’s ability to be able to complete
work on it controls needed to be applied as soon as slippage was sensed.

9.2 Requirements Analysis

As previously mentioned, getting a sound understanding of the user’s requirements was reckoned to be
the most important aspect of this project. It is felt that the reason for this is two-fold. Firstly, by
carrying out exhaustive requirements analysis from an early stage, ideas can be brought to fruition
early on in the project and as such included in prototypes that are very high fidelity. This means that
what the users see in the first prototype is a good representation of what they will be delivered in the
final product. Secondly, and linked to the first reason, by capturing as many requirements as possible
the system can be based upon sound design and is unlikely to require significant changes as more
requirements are uncovered later on.

The capture and analysis of the requirements at Southtech Limited was carried out early on and
covered many aspects of what must be included in the product. Having known the company for
approximately 18 months by this stage it is felt that a good understanding of the business and of their
requirements was gained. Obtaining the requirements early on meant that the design could be carried
out properly and with enough relevant information.

Page 71 of 106
 Help Desk Ticketing System (HDTS)

9.3 Technical Analysis

The technical analysis covered an extremely broad range of study from the design considerations of the
user interface through to the architecture of the environment the system fits in. The analysis carried
out in these areas was justly thorough and aided significantly in the design of the new system.

Choice of technology

Ensuring that the new system functioned on the infrastructure in place at Southtech Limited was the
key motivator to researching the technology that was available for this project. The focus, and
outcome of the analysis may have been somewhat biased towards

Microsoft technology but this is easily justified by the fact that nearly all of the software Southtech
Limited rely on is Microsoft’s.

Once the technology has been bought into, it is a costly business to then go and reengineer the
infrastructure. However, as mentioned when the decision was made, PHP was utilized because of the
merits it brought to the project and, having now gained experience with the framework, it is felt that it
was indeed the right decision to make. Though the learning curve was steep the technology was clearly
suited to the helpdesk system. The design choice based on the decision to use PHP of integrating the
system with Active Directory worked well. Users are not required to log on to the system explicitly but
security and access has been provided through the use of Active Directory. Again, the marriage
between PHP and the Microsoft Exchange Server worked well. Email facilities were provided through
the use of the Email class and were entirely transparent to the user.
Though other technologies could have been used it is felt that they would have not been deployed as
rapidly as was achieved by using PHP. They almost certainly wouldn’t have integrated into the
infrastructure as successfully at Southtech Limited and as such, it can be concluded that the right
decision was made.

9.4 System Design and Implementation

The importance of a sound system design has been emphasized throughout this chapter and, having
concentrated on it so much throughout the project, it was successfully achieved. The design provided a
sound platform on which to build the first prototype to a high level of fidelity, that is, to a high
specification that exceeds the projects minimum requirements. Choosing to implement the system in a
development environment ensured that full functionality was included without having to use the
infrastructure hosted at the offices in Leeds. Though it was not entirely necessary, the time spent in
creating the environment at the beginning of the implementation stage has saved somebody the task
of having to integrate the solution into the existing infrastructure.

Page 72 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.1: Implementation diagram specifying the new system architecture

9.5 User Interface

It has been discussed that the user interface must ensure that standards have been adhered to and that
the feedback the users get from the system is in line with their expectations. The ability to easily learn
the system was also considered to be of utmost importance. By designing the interface in a graphics
package before the implementation was undertaken, aspects of the learn-ability of the system were
considered before vast overhaul of the interface was required. The feedback from the testing of the
first prototype is very positive though it is clear that more work is required with some of the more
intricate detail of the system. Some of the menu items or page options require slight rewording but,
generally, the interface has been received well by Southtech Limited. It is also recognized that the new
interface design, despite being in prototype stages, performs more efficiently than the old layout. It is
reassuring that the effort put into the design has been rewarded by these benefits and that the time
spent was not pointless.

Page 73 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.2: HDTS Home Screen

Figure 9.3: HDTS

Submit ticket Screen

Page 74 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.4: HDTS View Existing Ticket Screen

Figure 9.5: HDTS Staff Login Screen

Page 75 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.6: Admin dashboard

Figure 9.7: User settings Screen

Page 76 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.8: Report Export Screen

Figure 9.9: Email Settings Screen

Page 77 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.10: General Settings Screen

Figure 9.11: View knowledgebase Screen

Page 78 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.12: Add Knowledgebase Screen

Page 79 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.13: Manage Knowledgebase Screen

Figure 9.14: Logout Screen

Page 80 of 106
 Help Desk Ticketing System (HDTS)

9.6 User Manual

How to submit a ticket in “Helpdesk”

1. Open your Internet Explorer Browser

2. Type this “ http:// helpdesk ” in address bar

3. Now click on “ Submit a ticket ”

Click Here

4. Now fill up all required information

Page 81 of 106
 Help Desk Ticketing System (HDTS)

5. And Click “ S ubmit Ticket ”.

6. Then you get a ticket id like below, also you will get a email notification:

Page 82 of 106
 Help Desk Ticketing System (HDTS)

How to view a ticket in “Helpdesk”

1. Go to Help Desk home page and Click View existing ticket.

2. Input your ticket id and click view ticket for view your support ticket history.

3. You will see this details screen and you may update as require.

Page 83 of 106
 Help Desk Ticketing System (HDTS)

9.7 Future Enhancements

When the project was originally conceived there was a sense that it may be a little over simplistic for a
final year project. After a small amount of market research opinion was quickly altered as it became
apparent how a new system could bring numerous business benefits to Southtech Limited. Having now
developed the first prototype of the system, the future vision has to be discussed in order to
understand the authors’ excitement with the project and the frustration that more could not be
achieved in the time spent so far.

The qualitative feedback in the previous chapter provides a good basis to start this section from. The
issues raised must be the first improvement to be made to the system. They don’t form enhancements
but fundamental changes that will provide adequate functionality with a well-established user
interface. However, beyond this there are changes that can be truly regarded as ‘enhancements’.

When scrutinizing the system with some developers at Southtech Limited, they were generally satisfied
with the method in which the system had been implemented. They particularly like the interface and
the method in which the template had been developed. The more compelling critique though, came
from the improvements that could be made to the systems implementation. PHP includes a number of
tools that had not been uncovered during the analysis of the development environment – namely the
Regular Expression Validator and Required Field Validator. The Regular Expression Validator control
enables validation to be performed on a field based upon a developer-defined rule (the regular
expression). Both of these controls provide an improved method of implementing the forms in the
system. When validation is implemented in the solution the Regular Expression Validator can be used.
Likewise, where required fields have been implemented manually in the system, they can be replaced
by the Required Field Validator control.

The final point to make about improvements that should be made to the implementation methods
relate to data access. The system, in its first prototype form, would not support concurrent usage
because of the data access implementation. Because the Web technology used leads to a disconnected
front-end, controlling data becomes much more complex when many users are to use the same data
source. Some form of record locking needs to be implemented in order to ensure that when one
person makes a change no one else makes a change while they are editing the data. This is a complex
area of research and will not be discussed any further, though, in the final version it is imperative that
some method is implemented.

There are a number of further enhancements that could be implemented in the system that would
make it an exciting contender to the products marketed and discussed in Chapter 4. Taking
functionality from these items of software, such as the Statistical Dashboard would ensure that the
system provided Southtech Limited with a solution that met their requirements entirely. However,
other features that have not been seen on the market could be added. Discussed in the best practice
guidelines was the inclusion of configuration management. This is something that is seen to be
relevant and should really be implemented at a future date. Once this is implemented the system
could go a stage further than any other package on the market by incorporating Remote Control Clients
such as PC Anywhere, VNC or Microsoft Remote Desktop. This would not create just a call tracking
package but would result in an entire support management where support technicians could receive a
call and instead of having to lookup separate documentation, simply click a button and be connected to

Page 84 of 106
 Help Desk Ticketing System (HDTS)

the clients system. Finally, it is felt that, although email is a powerful tool, a different method of
notifying employees when they have

a new call logged to them or when they are close to breaching an SLA. It has been considered that a
Java application could be used to notify the users. Another option could be integrating the system with
Instant Messaging technology to send messages over the Internet or even via SMS. The possibilities are
exciting and endless. The prototype is a distance away from the vision, but is a good start to a product
that was not available on the open software market.

9.8 Conclusion

Before it is able to fully control the support process at Southtech Limited, the implementation of the
new system requires further development. It is hoped that at least some of the enhancements
discussed can find their way to completion and enhance not only the users experience of the system,
but also improve the company’s relationship with the numerous clients that interact indirectly with the
system on a daily basis by ensuring a better level of service is achieved.

Even if it is always possible to improve the Helpdesk and make it more user friendly, the system is ready
to be used and the basic functionality has been achieved. When the first version was released we
started a period for testing the helpdesk but we did not get too much feedback. After that, the system
went into production. Nowadays there are about 10 registered support staff and more than 200 users.
As of April 2018 only 36 tickets have been created and all of them are real support tickets shown in
figure below.

I would like to thanks to Ms. Fahima Tabassum Madam for her valuable comments and suggestions
about functioning of the system.

Figure 9.15: User wise report of HDTS

Page 85 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.16: Monthly Report

Figure 9.17: Daily Report

Page 86 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.18: Category wise Report

Page 87 of 106
 Help Desk Ticketing System (HDTS)

Figure 9.19: User wise Report

References

[1] Software Engineering, Ninth Edition, Ian Sommerville

[2] Making Things Happen: Mastering Project Management

[3] Human Computer Interaction, 3rd Edition, Alan Dix, Janet Finlay, Gregory D. Abowd, Russell Beale

[4] The Joy of PHP Programming: A Beginner’s Guide – by Alan Forbes

[5] PHP & MySQL Novice to Ninja – by Kevin Yank

[6] Learning PHP, MySQL, JavaScript, and CSS: A Step-by-Step Guide to Creating Dynamic Websites –
by Robin Nixon

[7] PHP & MySQL Web Development – by Luke Welling & Laura Thompson

[8] PHP: A Beginner’s Guide – by Vikram Vaswani

[9] https://stackoverflow.com/

[10] https://www.w3schools.com/php/default.asp

[11] http://php.net/manual/en/tutorial.php

[12] https://www.tutorialspoint.com/php/index.htm

Page 88 of 106
 Help Desk Ticketing System (HDTS)

Appendix A – Reflection

If there is one thing I will take away with me after I hand this report in it is how important time
management. Not just for the project but for the final year in general. I was faced with the daunting
task of having to juggle few credits of modules in the first semester with the need to do work on the
project. It is vitally important that when there are small gaps in module commitments that progress is
made on the project. The first thing that I would recommend to myself about to undertake any project
would be to utilize our spare time as much as possible. Even if all I spend 15 minutes on reading, it is 15
minutes I won’t have to spend closer to the deadline date.

I was in a fortunate position of being able to return to the company that I worked for last few years.
This provided me with an opportunity to not only show them what I was capable of doing for future
employment but also to base my project on a real world situation. This forms a significant portion of my
degree and begins to take over my life.
Having carried out the project for a third party I have seen the company I worked for very differently.
Going in and arranging meetings made me feel more as a third party consultant than an employee. It
was nice to be able to go back and continue the professional relationships that I had formed in the last
couple of months but it also provided me with an ideal opportunity of building skills required
throughout my professional life. I now find myself in the extremely fortunate position of having found
good position of my employment upon post-graduation.
Throughout the final year one often finds oneself reflecting on the first years of University – some may
say wishing those days were still here! The project is the one true chance of be able to study
something that is a genuine choice, not something that the University have enforced on me. It has
given me the opportunity to explore new technologies and to research the areas that I am interested
in.

Finally, to reiterate the point I made at the beginning, time management has been an area where I find
my biggest weakness. The project has been an enjoyable yet testing experience. Don’t underestimate
the amount of time it takes to carry out each deliverable of this project, plan my work carefully, do as
much work as I can as early as possible and I will hopefully find that no one won’t be reflecting on time
management skills like me!

Page 89 of 106
 Help Desk Ticketing System (HDTS)

Appendix B – Interviews

Meeting with Asst. System Administrator

The purpose of this meeting is to ascertain the overall objective of the new system. It is very open
ended and is designed to answer one overriding question – what is required from the new system?

The outcome of the meeting follows.

The new system must:

o Have the ability to log a call – with type and description fields
o Be able to track a call
o Be able to escalate the call including deadlines
o Report against clients calls
o Success of handling calls against SLA
o Track against SLA
o Log how a ticket was resolved

It would be nice to have a real-time graph showing different statistics.

The system could eventually be used on a number of different devices (mobile/pda/tablet)

Page 90 of 106
 Help Desk Ticketing System (HDTS)

Appendix C – Use Case Description Forms

A Full Use Case Description should fill in all boxes, write None if appropriate.

* = Mandatory whenever this form is used, R = Recommended whenever this form is used
* Use Case Name:
(The name as it appears in the Create / Update customer details
Use Case Model)
* Primary Actor: Helpdesk Administrator
(Actor that initiates Use Case)
R Other Actors: None
R Value Proposal to Actor(s) Upon completing this use case the helpdesk administrator will have
(the goal of the Use Case from the stored up to the date information about the customer and be able to
Actor’s perspective)
add employees of that customer to the system
R Basic Course of Events: This use case begins when the helpdesk administrator is made aware
(The Normal Flow) of a new customer. All the relevant details are noted down by the
administrator and processed into the system

Alternative Paths: A current customer may need their details updating on the system
(Other paths through the use case (e.g new telephone number).
which result in a successful
outcome – typically variations to
the basic course of events,
determined by the actor and their
needs).
Exception Paths: None
(Other paths through the use case
which result in an unsuccessful
outcome – typically when
something goes wrong)
Assumptions:

Pre-conditions: Helpdesk administrator is set up on the system

Post-conditions:

Related Business Rules:

(Reference to our Business Rules
list)
Related Non-Functional
requirements – Usability,
Performance, Security:
(Any non-functional requirements
that are specific to this Use Case
rather than the system as a
whole)
* Project: Helpdesk Management System
* Author: Monzur Alam
* Date:

Page 91 of 106
 Help Desk Ticketing System (HDTS)

A Full Use Case Description should fill in all boxes, write None if appropriate.
* = Mandatory whenever this form is used, R = Recommended whenever this form is used
* Use Case Name:
(The name as it appears in the Create / Update staff details
Use Case Model)
* Primary Actor: Helpdesk Administrator
(Actor that initiates Use Case)
R Other Actors: None
R Value Proposal to Actor(s) Upon completing this use case the Helpdesk administrator will know
(the goal of the Use Case from the who works for the client and will be able to log support calls for them
Actor’s perspective)
R Basic Course of Events: This use case begins when the helpdesk administrator is made aware
(The Normal Flow) of a new member of staff being employed by one of Southtech
Limited’ customers. Their details are noted down and input into the
system

Alternative Paths:
(Other paths through the use case
which result in a successful
outcome – typically variations to
the basic course of events,
determined by the actor and their
needs).

Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome – typically when
something goes wrong)

Assumptions:

Pre-conditions: The Customer has been set up on the system

Post-conditions:

Related Business Rules:

(Reference to our Business Rules
list)
Related Non-Functional
requirements – Usability,
Performance, Security:
(Any non-functional requirements
that are specific to this Use Case
rather than the system as a
whole)
* Project: Helpdesk Management System
* Author: Monzur Alam
* Date:

Page 92 of 106
 Help Desk Ticketing System (HDTS)

A Full Use Case Description should fill in all boxes, write None if appropriate.
* = Mandatory whenever this form is used, R = Recommended whenever this form is used
* Use Case Name:
(The name as it appears in the Create / Update Support Ticket
Use Case Model)
* Primary Actor: Helpdesk Administrator
(Actor that initiates Use Case)
R Other Actors:
R Value Proposal to Actor(s) Upon completing this use case the helpdesk administrator can
(the goal of the Use Case from the manage the support call effectively by liaising with relevant
Actor’s perspective)
technicians/
R Basic Course of Events: A customer calls the helpdesk with a problem. The details are taken
(The Normal Flow) down and saved in the system. The call is then assigned to a
technician to be actions

Alternative Paths: A customer may email a call instead.

(Other paths through the use case
which result in a successful
outcome – typically variations to
The helpdesk administrator may have been assigned the call back
the basic course of events, from a technician for the call to be closed
determined by the actor and their
needs).
Exception Paths: The support call requested by the customer is not in the covered by
(Other paths through the use case the contract they purchased.
which result in an unsuccessful
outcome – typically when
something goes wrong)
Assumptions:
Pre-conditions: Customer and employee have been entered into the system.

Post-conditions:

Related Business Rules:

(Reference to our Business Rules
list)

Related Non-Functional
requirements – Usability,
Performance, Security:
(Any non-functional requirements
that are specific to this Use Case
rather than the system as a
whole)
* Project: Helpdesk Management System
* Author: Monzur Alam
* Date:

Page 93 of 106
 Help Desk Ticketing System (HDTS)

A Full Use Case Description should fill in all boxes, write None if appropriate.
* = Mandatory whenever this form is used, R = Recommended whenever this form is used

* Use Case Name:

(The name as it appears in the View Support Ticket
Use Case Model)
* Primary Actor: Helpdesk Administrator
(Actor that initiates Use Case)
R Other Actors: Support technician & Delivery Director
R Value Proposal to Actor(s) Upon completing this use case the actors are made aware of calls
(the goal of the Use Case from the logged to them and other people in the organisation
Actor’s perspective)
R Basic Course of Events: The actor requests to see calls logged to them depending on certain
(The Normal Flow) criteria and the calls are displayed.

Alternative Paths:
(Other paths through the use case
which result in a successful
outcome – typically variations to
the basic course of events,
determined by the actor and their
needs).
Exception Paths: There are no support calls
(Other paths through the use case
which result in an unsuccessful
outcome – typically when
something goes wrong)
Assumptions:
Pre-conditions:

Post-conditions:

Related Business Rules:

(Reference to our Business Rules
list)
Related Non-Functional
requirements – Usability,
Performance, Security:
(Any non-functional requirements
that are specific to this Use Case
rather than the system as a
whole)
* Project: Helpdesk Management System
* Author: Monzur Alam
* Date:

Page 94 of 106
 Help Desk Ticketing System (HDTS)

A Full Use Case Description should fill in all boxes, write None if appropriate. * =
Mandatory whenever this form is used, R = Recommended whenever this form is used

* Use Case Name:

(The name as it appears in the View Customer details
Use Case Model)
* Primary Actor: Helpdesk Administrator
(Actor that initiates Use Case)
R Other Actors: Support technician
R Value Proposal to Actor(s) Upon completing this use case the actors are made aware of how the
(the goal of the Use Case from the customer can be contacted
Actor’s perspective)
R Basic Course of Events: The actor requests to see the customer’s contact details. They are
(The Normal Flow) displayed

Alternative Paths: Technicians only see the contact details when they need to call the
(Other paths through the use case customer. They only need to contact the customer when they are
which result in a successful
outcome – typically variations to
dealing with a call so this is the only time they may request the
the basic course of events, details
determined by the actor and their
needs).
Exception Paths:
(Other paths through the use case
which result in an unsuccessful
outcome – typically when
something goes wrong)
Assumptions:
Pre-conditions:

Post-conditions:

Related Business Rules:

(Reference to our Business Rules
list)
Related Non-Functional
requirements – Usability,
Performance, Security:
(Any non-functional requirements
that are specific to this Use Case
rather than the system as a
whole)
* Project: Helpdesk Management System
* Author: Monzur Alam
* Date:

Page 95 of 106
 Help Desk Ticketing System (HDTS)

Appendix D – Service Level Agreement document

Service Definition
Service Name SLA001 – Help Desk
Service Description This service provides the Authority with access to, and use of the Southtech
Limited’ Help Desk.

Service Benefits Single point of contact for all IT issues.

Time logged against calls can be monitored.
Calls can be checked against previous occurrences.
Ensures resources are assigned according to business impact. (See notes).

Process Summary

Service Parameters
Availability 08:00 to 18:00 Monday to Friday except public holidays.
No service outside these hours.
Response Time Calls will be acknowledged within 1 working hours, either verbally or via Email.
Southtech Limited will aim to resolve all support calls thus:
Critical issues within 4 hours with engineer/analyst work through. For critical
calls that cannot be resolved within 4 hours using normal procedures all
reasonable endeavors will be made by Southtech
Limited to find a resolution to the call within the next working day.
Moderate issues within 2 working days
Low priority issues within 5 working days.

Turn Around Southtech Limited will assign appropriate technical resource to the resolution
of the issue, taking the following factors into consideration:
o Customer Impact (Severity)
o Supported Status (Schedule Classification)
o Previous Occurrences (History)
Scope The schedules of Directly-Supported, Indirectly-Supported
and
Unsupported software will provide a definitive list of supported software.
See Appendix A

Page 96 of 106
 Help Desk Ticketing System (HDTS)

Volume There is a limit of 3 calls per week (up to 156 per annum) that will normally be
accepted under this agreement. However, Southtech Limited will periodically
review the time spent by employees in the resolution of support calls and
reserve the right to modify future premiums accordingly.

Access Any designated Coal Authority employee (up to a maximum of 3) and the
Cap Gemini Helpdesk are entitled to call the Help Desk
Notes Each call will be assigned one of three priorities:
Appendix A Critical = System down or other serious business-impacting issue.
This equates to Coal Authority calls of priorities 1 and 2.
Appendix B Moderate = Users affected but business not seriously impacted.
This equates to Coal Authority calls of priority 3.
Appendix C Low = A problem that does not prevent user operation.

Service
Accountability
Reporting As part of the monthly report, all service parameters will be reported and any
variances from the agreed service levels noted.

Contact Tel: (0113) 220 8379 or Email: [email protected]

Responsibility The primary IT Contact onsite must inform the Southtech Account Manager of
any predicted change to business plans or technical implementation which
may affect the way this service is delivered.

Review Period No formal review will be carried out. All service issues should be raised with
the Southtech Account Manager on 0113 220 8377.

Predicted Changes There are currently no major developments, which are predicted to
significantly impact this service.

Page 97 of 106
 Help Desk Ticketing System (HDTS)

Appendix E – Internal Documentation

Support options and strategies

Problem Logging
As soon as a support call comes in, it receives the attention from the help desk staff that classifies the
problem according to the impact it is having on the customer. The problem is then emailed to the most
appropriate person. The help desk staff have a skills matrix in place which assists them in assigning the
support call to the most appropriate member of staff. Where the priority of the call is anything other
than “low” a verbal call is made to the staff member to verify that they have received it. The support
call is logged on the incident recording system which records, amongst other things, the time the call is
received, it’s priority, the customer contract name and phone number, to who within DS the call is
assigned, and when a follow-up call to that engineer should be made. This last field enables a “double-
check” to be made which helps to ensure that all calls are managed. The responsibility for the
resolution of the call rests with the engineer to whom the problem is assigned.

Problem appraisal
The Engineer will then immediately read the text of the support call and appraise the problem. The SLA
outlined later in this document is followed and at this time the call status may be elevated or reduced
as necessary. This is the primary problem appraisal. The engineer will then decide what action to take
or whether to pass the call onto a third party. Responsibility still lies with the engineer and the support
call is updated to reflect any and all action that is taken. The nature of the problem (Hardware,
Network, Operating System, Application etc) may be determined at this point.

Problem confirmation
Within the limits set out in the SLA, when the engineer comes to investigate the problem, a first call will
be made to the Council to confirm the nature, scope and detail of the problem. This forms the second
appraisal of the issue and status may be elevated or reduced as necessary. The support call log is
updated with any action taken. If not already identified, the nature of the problem (Hardware,
Network, Operating System, Application etc) is normally determined at this point.

Issue Management
All support calls are the overall responsibility of the DS Delivery Director and will be escalated to that
level as necessary under the SLA. Once again, the support call log is updated at all level, whenever
there is work done on that particular support call. This includes contracts with third parties.

Impact Status
Since support calls have different impacts to different businesses, and due to the sheer variety of topics
that support calls may cover, Engineers will allocate time accordingly. For this reason, DS only operate
3 levels of severity:

Page 98 of 106
 Help Desk Ticketing System (HDTS)

Severity Response Description

Time
High 2 hours The issue is preventing the customer from doing business,
either totally or significantly. This covers things like:
Mission-Critical system down, total loss of functionality
with a field etc.

Medium 4 hours The issue is not significantly preventing the customer

from doing business, but has the potential to do so if the
issue is not resolved in a timely fashion. This would
normally cover issues like: Non-Mission-Critical system
down, Mission-Critical system performance or
functionality issues, partial loss of functionality within a
field, or total loss but where a workaround exists.
Low 8 hours The customer is not prevented from carrying on business
in any way, or is only marginally inconvenienced by the
issue. Mission-Critical systems are unaffected but Non
Mission-Critical systems may be experiencing
performance or functionality issues. Requests for change
or enhancements often start as a support call with this
status.

Escalation Procedures
Like most IT companies, we cannot guarantee that a fix will be found for any given problem. We will
however pursue all reasonable endeavors to resolve any customer issues where a support contract
exists. DS will guarantee that a response to a customer will occur within agreed SLA standards. we
have a demonstrable track record in resolving customer issues.

Page 99 of 106
 Help Desk Ticketing System (HDTS)

Appendix F – Southtech Limited network topology

Figure 1: Southtech Limited network topology (internal documentation)

Page 100 of 106

 Help Desk Ticketing System (HDTS)

Appendix G – Southtech Limited standard workstation

build

Operating System:
o Microsoft Windows 7/8.1/10

Other components:
o DirectX 9.0b
o Windows Media Player 9 series
o MDAC 2.8
o MSXML4.0 SP2
o Microsoft .NET Framework 4.0
o MS Office 2010/2013 Professional
o MS Visio 2016
o Acrobat Reader
o Winzip/Winrar
o Kaspersky Antivirus

Page 101 of 106

 Help Desk Ticketing System (HDTS)

Appendix H – First draft E-R diagram

Page 102 of 106

 Help Desk Ticketing System (HDTS)

Appendix I – Final E-R diagram

Page 103 of 106

 Help Desk Ticketing System (HDTS)

Appendix J – System Architecture

UML Implementation diagram specifying the new system architecture

Page 104 of 106

 Help Desk Ticketing System (HDTS)

Appendix K – Support call process

UML
Activity diagram showing the support call process.

Page 105 of 106

Help Desk Ticketing System (HDTS)

Page 106 of 106

 Help Desk Ticketing System (HDTS)

Appendix L – Support status

Awaiting Authorization

[Not supported]
Rejected
[Supported]

Authorized

In Progress

Awaiting Closure [Issue not resolved]

[Issue resolved]

Complete

UML State chart displaying call status

Page 107 of 106

 Help Desk Ticketing System (HDTS)

Appendix M – Functional Test Execution Document

Accepted
Task Description Success?
1.1.1. Log a new call Y
Successfully complete task Y
Insert special characters into ‘Brief Description’ field Y
Insert special characters into ‘Problem Outline’ field Y
Successfully emails assignee the call details Y

Accepted?
Task Description Success?
1.1.2. Update support call log Y
Successfully complete task Y
Insert special characters into ‘Add detail to call’ field Y

Task Description Success? Accepted?

1.1.3. Obtain status of call

Successfully obtain the status of a call Y

Accepted?
Task Description Success?
1.2.1. Add customer to list Y
Successfully add a customer to the list Y
Insert special characters into ‘Company Name’ field Y
Insert special characters into ‘Address 1’ field Y
Insert special characters into ‘Address 2’ field Y
Insert special characters into ‘Address 3’ field Y
Insert special characters into ‘Address 4’ field Y
Insert special characters into ‘Postcode’ field Y
Insert special characters into ‘Telephone’ field Y
Insert special characters into ‘Fax’ field Y
‘Telephone’ field accepts only numbers? N
‘Fax’ field accepts only numbers? N
‘Postcode’ field is properly validated N

Task Description Success? Accepted?

1.2.2. Display all customers Y

Successfully display all the users Y

Task Description Success? Accepted?

1.2.3. Display customer details Y

Page 108 of 106

 Help Desk Ticketing System (HDTS)

Successfully display all the customers details Y

Accepted?
Task Description Success?
1.2.4. Update customer details Y
Successfully update the details of the customer Y
Fields are validated N
Insert special characters into fields Y

Accepted?
Task Description Success?
1.2.5. Enter SLA details Y
Successfully change SLA from system default to custom Y
Successfully change SLA from custom to system default Y
Validate for only numbers N
Acceptable for first prototype

Accepted?
Task Description Success?
1.2.6. Add / Remove client employee Y
Successfully add an employee against a client Y
Successfully remove a client from an employee N
Can insert special characters into employee name Y
Acceptable for first prototype

Accepted?
Task Description Success?
1.3.1. Add / Remove system users Y
Successfully add an user onto the system Y
Successfully remove a user from the system N
Acceptable for first prototype

Task Description Success? Accepted?

1.4.1. View / Update default SLA response times Y

Can view and update the system default SLA response times N
Hard coded variables are acceptable for first prototype

Task Description Success? Accepted?

2.1.1. View assigned calls Y
Can view calls assigned to member logged on Y

Accepted?
Task Description Success?

Page 109 of 106

 Help Desk Ticketing System (HDTS)

2.1.2. Update call log with action taken Y

Can successfully log action taken to the call Y
Field accepts special characters Y
Can alter status and assignee Y
Can email assignee when updated N
Acceptable for first prototype – email functionality has been demonstrated elsewhere

Task Description Success? Accepted?

2.1.3. View customer contract details Y

Can view and the contract details Y

Task Description Success? Accepted?

2.1.4. Pass call to third party N
Can successfully pass he call to a third party N
Does not form any of the minimum requirements agreed. Accept that this is a future development

Accepted?
Task Description Success?
3.1.1. Chase technicians that have not updated an open call in a week Y
Successfully obtain a list of technicians not updated call in the
N
week
Can email technicians who have not updated their calls in the
Y
week
Email is acceptable for first prototype though it would be nice to view a list in the actual system

Accepted?
Task Description Success?
3.1.2. Beware of calls breaching / about to breach SLA Y
Is able to obtain list of calls breaching SLA N
Email is acceptable for first prototype though it would be nice to view a list in the actual system

Task Description Success? Accepted?

3.1.3. Raise priority of a call Y
Can raise the priority of the call Y

Task Description Success? Accepted?

3.1.4. Get statistics out of the system Y
Can successfully obtain statistics from the system N
Does not form any of the minimum requirements agreed. Accept that this is a future development

Page 110 of 106

 Help Desk Ticketing System (HDTS)

====================END====================

Page 111 of 106