Customer - Service - Desk Final Thesis

CUSTOMER SERVICE DESK
Thesis submitted towards the partial fulfillment of the requirements for

the Award of the degree of
MASTER OF COMPUTER APPLICATION
by
LALATENDU DAS
Roll. NO: UPC22MCA-017
DEPARTMENT OF MCA
GANGADHAR MEHER UNIVERSITY

SAMBALPUR, ODISHA INDIA
2022-2024
I
CERTIFICATE
This is to affirm that the thesis titled "Customer Service Desk" presented by Lalatendu Das
(Registration No: PC22MCA-017) for the Master of Computer Application degree at
Gangadhar Meher University, Sambalpur, reflects genuine research conducted under my
direct supervision. I attest that the thesis meets the requisite standards and adheres to the
guidelines governing the degree program.
Internal examiner External Examiner
Mr. Prateek Mahapatra
Assistance Professor
Department of MCA
II
DECLARATION
I hereby declare that the work which is being presented in this project entitled,
“CUSTOMER SERVICE DESK” submitted to Gangadhar Meher University, Amruta Vihar,
Sambalpur in the partial fulfillment of the requirements for the degree of Master of Computer
Application (MCA), is an authentic record of our own work carried out under the supervision
of Mr. Pramoda Kumar Sahu, Software Engineer, Smart 5 Solutions (p) Ltd., Bhubaneswar.
The matter embodied in this project report has not been submitted by us for the award of any
other degree.
Lalatendu Das
Roll no. UPC22MCA017
DEPT. OF MCA
Gangadhara Meher University
III
ACKNOWLEDGEMENT
I would first like to thank my thesis advisor Mr. Prateek Mahapatra Assistant Professor of the
Dept. MCA at Gangadhar Meher University, Sambalpur. The door to his office was always
open whenever I ran into a trouble spot or had a question about my research or writing. He
consistently allowed this paper to be my own work, but steered me in the right direction
whenever he thought I needed it.
I want to express my gratitude to Dr. Madhumita Panda (Head of the Dept) Department of
MCA for her guidance, support and encouragement all through the academic session. She has
enlightened me with many innovative ideas that form the framework of this thesis, and I most
certainly could not have completed this thesis without her.
I would also like to thank experts of the company Smart 5 Solution Pvt. Ltd. who guided me to
do this project and provided me the basic knowledge so that I could execute it in a better way.
Finally, I must express my very profound gratitude to my parents for providing me with
unfailing support and continuous encouragement throughout my years of study and through
the process of researching and writing this thesis. This accomplishment would not have been
possible without them. Thank you.
Lalatendu Das
UPC22MCA-017
IV
ABSTRACT
Today’s corporate world is more focused on client- centric association and all business
associations tries to make a palm- palm relationship with their client. Without client
satisfaction it's veritably delicate to be the not only a profitable association but also a great
association.
Client complain monitoring and operation is the big challenge of any association. Then, the
results I prepare will present as a software named client Service office comes with the
complete complain operation result for any types of business associations. In Bangladesh
unfortunately utmost of the association’s complaint operation system is traditional.
Customer Service Desk can overcome the walls of traditional client complain operation
system by easy penetrating the client information, complain and resolution. To be a successful
Organization and to maintain the position client satisfaction is abecedarian. numerous
association now has branch conception and maintaining global services, so it's really a poorly
need to cover and resolve the client complain along with internal support conditioning to all
over the world. It’s veritably vital for any business or services that the information must be
accurate and streamlined. But in homemade system it's generally veritably delicate because it
has large number of downsides.
This attestation will present software development process of Customer Service Desk. In
designing and developing this design Enterprise mastermind is used as a modeling tool. EA
rehearsed then considering that it'll give better understanding of conditions, clear design, and
more justifiable systems.
The programming language or front- end tool used then's PHP, HTML and database or back-
end used then's MySQL. Unified Modeling Language will be used to dissect current system
procedures and problems’ conditions, design a logical result to the problems, and also apply
the result through programming language and database.
My approaches allow the same generalities and memorandum to be used throughout the entire
software development process.
V
LIST OF FIGURES
Figure No. Page No
Fig 2.1-Project Schedule 11

Fig2.2-The Waterfall Model 14
Fig 2.3-Risk Graph 19
Fig 3.1-Customer Service desk structure 27
Fig 3.2-Use case diagram 37
Fig 3.3-Use case diagram 38
Fig 4.1-Screenshort of help star dashboard 46
Fig 5.2-Simplified network diagram 54
Fig 5.3-Current and proposed architecture 56
Fig 5.4-The execution model for web architecture 58
Fig 6.1-Application architecture 61
Fig 6.2-Customer Service desk and support call 62
Fig 6.3-Summery ER diagram 63
Fig 6.5-ER diagram 70
Fig 6.6-Before and after re design 71
Fig 6.7-Site structure 77
Fig 6.8-Submit Ticket 79
Fig 6.9-Home page of CSDTS 80
Fig 7.1-Data access 83
Fig 7.2-Page inheritance 84
Fig 7.3-Use case diagram of various page access 86
Fig 8.1-Testing 88
Fig 9.1-Implementation diagram 93
Fig 9.2-Home screen of CSDTS 95
Fig 9.3-User Manual 96
Fig 9.4-Submit Ticket 97
Fig 9.5-Ticket Submitted 97
Fig 9.6-View Existing Ticket 98
Fig 9.7-Case Tracking 99
VI
LIST OF TABLES
Table 1 Impact of Risk 18

Table 2 Risk Analysis 21
Table 3 Risk Planning 22
Table 4 Risk Monitoring 23
Table 5 SLAD-A 30
Table 6 SLAD-B 31
Table 7 SLAD-C 32
Table 8 SLAD-D 32
Table 9 ISSUE MANAGEMENT 34
Table 10 Manage support call 39
Table 11 Manage Clients 39
Table 12 Manage System 40
Table 13 Manage Contracts 40
Table 14 Resolve customer issues 40
Table 15 Non-User Specific 40
Table 16 User Table 73
Table 17 User Login Table 74
Table 18 User Password Reset Table 74
Table 19 Knowledge Base Table 74
Table 20 Support ticket table 75
Table 21 Support ticket Category Table 76
Table 22 Support Ticket Mail table 76
VII
TABLE OF CONTENTS
S
CERTIFICATE APPROVAL I
CERTIFICATE II
DECLARATION III
ACKNOWLEDGEMENT IV
ABSTRACT V
LIST OF FIGURE VI
LIST OF TABLES VII
Chapter 1 Introduction 1
1.1 Objectives 2
1.2 Knowledgebase 3
1.3 Challenges 3
Chapter 2 Literature Review 5
2.1 Initial Study 5
2.2 Background of the Study 5
2.3 Theoretical/Conceptual Framework 6
2.4 Project Vision and Aims 6
2.5 Project Scope 7
2.6 Hardware and Software Requirements 7
2.7 Further Enhancements 8
2.8 Project Approach 9
2.9 Project Management 9
Chapter 3 Methodologies 13
3.1 Development Methodologies 13
3.2 Risk Management 16
Risk Identification, impact, evaluation & prioritization: 16
Impact of risk: 17
Risk Priority: 19
Risk Analysis: 20
Risk Planning: 21
Risk monitoring: 22
3.3 Summary 23
3.4 Requirements Analysis 24
3.5 Business Analysis 25
Stakeholders 25
Customer Relationship 26
3.6 Requirements Capture 28
Research 28
Interviews 28
Sample Documents 29
Service Level Agreement Document 30
Questionnaires 35
Observation 35
Use Cases 36
3.8 Functional Requirements 39
3.9 Non-Functional Requirements 40
Incident Management 41
Problem Management 42
Configuration Management 43
Change Management 43
Release Management 43
Chapter 4 Customer service desk Software Market 44
4.1 Help STAR 44
4.2 Intuit Track-It! 45
4.3 Bugzilla 47
4.4 Summary 47
Chapter 5 Technical Analysis 48
5.1 Components of Technical Analysis 48
Task Identification 50
Short Term Memory 50
Execution-Evaluation Cycle 51
Form Filling 51
Menu’s 51
5.3 IT Infrastructure 52
Microsoft Exchange 2013 52
Microsoft Internet Information Services 53
Microsoft MYSQL Server 2016 53
Desktop Applications 54
Chapter-6 Implementation 55
6.1 Technology Options 55
6.2 Summary 59
6.3 System Design 59
6.4 Application Architecture 60
6.5 Database Modelling and Design 61
Conceptual Database Design 62
Logical Database Design 64
6.6 Physical Database Design 64
Normalization 70
Data Dictionary/Database Files 72
Data structureUser Table: 73
User Password Reset Table: 74
Support Ticket Table: 75
6.7 Functional Design 76
6.8 User Interface 79
6.10 Email Reminder 80
6.12 Data Access 82
6.13 Page Template 84
Chapter-7 Result Analysis 87
7.1 System Testing 87
7.2 Functional Testing 87
7.3 User Acceptance Testing 88
7.4 Usability Testing 89
7.5 Evaluation 91
7.6 Project Approach 91
7.8 Technical Analysis 92
7.9 System Design and Implementation 92
Choice of technology 93
User Interface 94
7.10 User Manual 96
Chapter-8 Future Enhancements 100
Conclusion 102
References 103
Chapter 1 Introduction
Customer Service Desk software offers multitudinous benefits to system director and IT pros.
Company workers always appreciate a helpful resource for their implicit issues and queries;
when workers submit a report, they ’re assured that their problems are encouraged to the
correct member of the support staff. Once a report has been submitted to the system, the hand
will have the capability to log in and track the progress of their ticket.
Customer service desk 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
each by precedence. At the same time, the software transfers them to the appropriate
department for issue resolution.
This type of software can also help reduce the quantum of training that’s demanded for the
support staff. As a result, my support staff can come experts in a shorter quantum of time.
Such an advantage allows for a important speedier resolution of hand’s IT issues, which in
turn frees up my support staff to support an indeed advanced volume of workers.
Support staff can also benefit from Customer service desk software as their jobs become
easier. In addition, workers will admit service in a more effective manner and stay 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 Customer service desk software is that managers have the
ability to keep track of members and their performance in the company. Since the typical
Customer service desk management solution has resolution and tracking tools, reports are
easily completed. Employees will eventually be more productive with shorter ages of time-
out, which benefits the company as a whole.
Customer Service Desk Ticketing System (CSDTS) is the Customer service desk system
which will ever need. Suitable to automatically assign support tickets, keep druggies informed
of the status of their ticket and help requester to cleave to SLA rules. CSDTS is the quicker
solutions for end users and higher productivity for IT technicians.
1
1.1 Objectives
Customer Service Desk is a part of client relationship that refers to practices, strategies and
technologies that companies use to manage and dissect client relations and data throughout
the client lifecycle, with the thing of perfecting client service connections and aiding in
client retention and driving deals growth.
CSDTS 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. CSDTS systems can also give
customer-facing staff detailed information on customers' personal information.
At the most basic level, CSDTS software consolidates customer information and documents
into a single database so business users can more easily access and manage it.
Over time, numerous fresh functions have been added to CSDTS systems to make it more
useful. Some of these functions include recording colorful client relations over dispatch,
phone, social media or other channels; depending on system capabilities, automating colorful
workflow robotization processes, similar as tasks, timetables and cautions; and giving
directors the capability to track performance and productivity grounded on information logged
within the system.
Few main objectives are-
- CSDTS designed to reduce tedious aspects of a support staff's job. colorful software
tools that integrate with the agent's desktop tools can handle client requests in order to
cut down on the time of calls and to simplify client service processes.
- Geolocation technology, or location-based services can use by CSDTS 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 beused as a networking or contact operation tool in order to
finddealsprospectsgrounded on a position.
- CSDTS 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 CSDTS, enabling support teams to
input, track and analyze data in one place.
- Analytics in CSDTS help create better customer satisfaction rates by analyzing user
data.CSDTS also termed as HDTS (Customer service desk Ticket System).
2
1.2 Knowledgebase
The Knowledge Base is a database that contains problems reported by druggies with the
corresponding results. It isn't a FAQ in the sense that a question does not need to be
constantly asked. A question should go into the knowledge base if a supporter considers that it
could be of general interest. This allows druggies to reduce the necessity of creating tickets by
consulting the Knowledge Base. A good knowledge base can save client service office staff so
important time. IT technicians will be suitable to check the knowledge base for judgments to
problems and so will druggies. We can make a number of judgments public to druggies
allowing them to break minor issues themselves. Also knowledgebase has the following
benefits:
o Produce knowledge rich papers to give results, workarounds, and

FAQs. Include rich textbook, images, and attachments to the knowledge
base content.
o Ensure the quality of knowledge base content with a streamlined
blessing medium.
o Organize knowledge papers under configurable motifs to let end druggies
and technicians fluentlybrowse and access.
o Provide advanced keyword hunt capability and the results bus
suggest point to enable enddruggies and technicians to snappily
pullout applicable knowledge papers.
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 Customer service desk services challenging for
organizations. Organizations must actively search for new ways to provide better Customer
desk services that can satisfy the growing customer demands and expectations.
Customer service 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
Customer service 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
3
solution(s) that satisfy the users.
Customer service desk 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. Customer service desk software is a solution
application that is used for managing organization’s Customer service desk. It is accessible to
customer support personnel who could direct request(s) to servicing department(s).
Technical concerns are getting a normal script in everyday work terrain both in education and
commercial. therefore, need to constantly and effectively cover these enterprises. These bear a
system that can handle them. With this in mind, an Automated client service office client
Support for Information Technology Resource Center is a fit result that can give effective
approach in handling all reported specialized enterprises with proper record keeping and
monitoring to guests and specialized labor force as well as systems directors.
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 Customer service desk Ticketing
System in any types of organizations willing to automate their support activities system
through online.
This design will help me to have a great chance to increase my ICT knowledge as well as
software development like design operation 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 conception, testing knowledge and perpetration.
It'll helps us to get a good job in future which is helpful our career.
4
Chapter 2 Literature Review
2.1 Initial Study
The concern of the study is to develop and design an Automated Customer service desk. The
system is deployed to South tech 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 Customer service desk
which isavailable to the clients reveals that Customer service 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 Customer service desk’s hours of
availability,allowing users to get answers to their questions when the Customer service
desk is not staffed. Even during the Customer service desk’s normal operating hours,
the availability of self- service resources can reduce demand for direct interaction with
the Customer service desk staff while keeping service availability and quality.
3. The assessment of the respondents in terms of proposed automated Customer service
desk performance shows that personnel has knowledge of information technologies to
enhance teaching and learning, research, administration with continuous updates.
Moreover, they appreciate the Customer service 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 Customer service desk automation
systems.
2.2 Background of the Study
Regularly the term Customer service desk is employed for interior backing within the
association or for outside care groups. multitudinous associations are turning to help work
area to denuclearize a mixed bag of errands and, at the same time, lessen costs by cutting staff
and giving further customer help from the current staff. Organizations need to give high
quality customer administration and backing to get by in moment's business surroundings.
Having the right help work area would guarantee high customer fulfillment. client help
consolidates gains that help a client or client fathom and benefit from effects limits by noting
5
request, handling issue and giving online information. The preferences of automated help
work area are introductory in that they permit smaller individualities to manage larger work
volume.
The client service office is adding its significance as companies move to customer- garçon
infrastructures. druggies who affiliate with the client service office frequently form a general
perception of the information system group. Information systems client service divisions
plays an important part within an association. The help work area is in charge of uniting an
association's means with a specific end thing to give its guests quality help and
administration.
2.3 Theoretical/Conceptual Framework
Customer service desk automation is for many companies the first application area of
knowledge-based systems. “The Customer service desk is an automated knowledge
distribution while payroll was an automation of record keeping. The theory above anchors
on the Customer service desk management system which has attracted a number of
research works. Such as, in developed world, Customer service 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 Customer service desk information retrieval mechanism will be suitable for users
in managing the complaints and proper system maintenance. The system helps improve
Customer service desk usability and functionality. The figure above shows Customer service
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.
2.4 Project Vision and Aims
Customer service desk is designed and customized to provide businesses with an internal
support system as well as a link for providing support to its customers. Customer service desk
applications host a number of benefits that includes:
➢ Giving being guests with information and constantly Asked Questions (FAQ's)
concerning theassociation's fabrics and approaches.
6
➢ 24- hour vacuity therefore feeding to the trend of office labor force working late and to
those overseas or in different time zones.
➢ Troubleshooting tricks gives guests the capacity to take care of multitudinous help
issues eachalone. This outfit gives the guests with brisk and simple arrangements and
sparing the association’s cash.
➢ Serves as an instrument for following and recording help work area enterprises,
which gives an information base of judgments to once exchanges concerning similar
issues.
➢ Inventories information concerning trends and other issues, which aids in the
continuing enhancement of products and services.
2.5 Project Scope
This is an Information Systems design that will cross numerous disciplines including
operation, software design, software development and systems architecture.
The features of this design will be most significant way of the resolution of the problem and
client satisfaction. This feature will be distinctive in comparison with the other analogous
types of operation. Application and benefits of this design may increase the effectiveness of
the association. The point will be as follows:
✓ Ticket Submission
✓ Ticket Assignment/Allocation
✓ Ticket Tracking/Monitoring
✓ Ticket Management
✓ Email integration
✓ Notification
✓ User Management
✓ Reports
✓ Knowledge Base
2.6 Hardware and Software Requirements
Recommended Hardware Requirements (Application and DB Server)
• Minimum 350 MB Hard Disk space for installation
7
• GB HDD space required for live system
• Minimum CPU - Pentium 4, 3.2 GHz
• Minimum RAM 2 GB
• Gigabit Ethernet Network card
Minimum Software Requirements:

• Operating System: Windows 7/upper or Linux RHEL 4.0
• Application Server: WAMP 2.5 or upper for Windows or XAMPP 2.1 or upper for Linux
• PHP Version: PHP 5.0.0 or upper
• Database: MySQL 5.0.7 or Upper
Other Software Requirements:

• Project Management Tools: Microsoft Project Server 2016
• Designing Tools: Enterprise Architect, Microsoft Visio
• Text Editor: Notepad++, MS Office
• Internet Browser: Mozilla Firefox, Google Chrome
2.7 Further Enhancements
Further enhancements could be made to the system prototype and will be implemented
depending on the time available.
• Further development based on the evaluation of the prototype;
• Integration with South tech Limited’ time recording system;
• Ability to store details of and assign calls to a third party engineer;
• Management reporting – enabling managers to obtain information from
support calls suchas response time and time taken to fix issues;
8
2.8 Project Approach
This section outlines the need for a structured approach in order to achieve a successful design.
I explosively believe that a well- defined development cycle with simple, yet rigorous
processes will allow us to deliver on time an effective software system for client complain
operation system.
The following phases represent software development life cycle process:
A. Planning
B. Analysis
C. Design
D. Prototyping
E. Coding
F. Testing
i. Unit Test
ii. System Test
iii. Acceptance Test
G. Deployment
H. Training
I. Maintenance & Support
J. Project Handover
2.9 Project Management
Before starting any design it's important to be clear of the issues that are anticipated and the
processes involved that will achieve those issues. There are a number of approaches that can
be taken in order to manage the resources that are needed to complete a successful design.
Outline the conditioning to be carried out in design operation 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 South
9
tech 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 South
tech 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 alternate exertion of design operation, If. It's argued that the only way of
erecting a full script of the design is to catch every scrap of detail as early as possible. easily, this
will be fulfilled by
considering precisely each aspect of the design before it's accepted. still, the planning is an
ongoing process of refinement and that each replication of planning becomes more detailed and
more accurate than the last. A similar information gathering will be needed at the morning of
each stage to ensure that it's 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.
10
Fig 2.1 Project schedule
Microsoft Project Server 2016 is a design operation tools that provides directors with tools to
carry out successful systems on time and within budget. Control over the design plans is
veritably much a part of the design operation frame. Controlling and reconsidering the design
plans ensure that the design:
• Is producing the needed products which meet the defined Acceptance Criteria
• Is being carried out to schedule and in agreement with its resource and cost plane
• Remains feasible against its Business case
As mentioned over, the final exertion involved in design operation is the design prosecution.
This stage frequently contains the design and perpetration stages which really requires a
satisfactory position of collaboration. With a clear understanding of the systems conditioning,
accessible communication channels are established in order to ensure that this collaboration
takes place. With all members of staff at South tech Limited having access to dispatch and
their office being in Leeds, this is fluently achieved.
There are a number of styles employed within the IT assiduity that can be espoused to achieve
good design operation. similar styles are designed for large scale systems involving complex
11
brigades of inventors and end druggies, and, as a result aren't entirely applicable to this
design. Although it's fairly small, it's hoped that by taking aspects of these fabrics and
maintaining a dynamic approach throughout, a successful design will be achieved.
12
Chapter 3 Methodologies
3.1 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.
Rapid Application Development:
This methodology puts emphasis on snappily producing prototypes for the druggies to
estimate. The methodology isn't suitable for all systems, particularly bones that bear
thorough planning. It's stylish used when there's a focused product compass, opinions can be
made by many people, there aren't numerous members in the design platoon, and the
specialized armature is clear.
This would not be a suitable system for this particular design because, as yet, there isn't a
focused product compass and the conditions aren't clear. It's possible to borrow formerly all
stoner analysis is complete, but also it'll not constitute a methodology that can be applied to
the design as a whole.
Joint Application Development:
Joint Application Development (JAD) is a methodology where inventors work intensely with
druggies in shops and agree proved 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 opinions to be made incontinently. On the other hand, the
sessions may not cover everything that needs to be covered in one go. Prototyping, for
illustration, couldn't take place unless numerous of these sessions were to be held.
Due to the nature of this design and of business itself, it's doubtful that JAD will be espoused
as the methodology used. It's veritably doubtful that the directors, administration and support
staff will have time to all sit down together for an extended period of time to discuss what,
basically, is a small design.
Still, assignments can be learned from the methodology, and being grounded in Leeds, it'
presumably a good idea that meetings are arranged when the crucial decision makers will be
13
around; this should help aid the communications process and ensure that opinions are made
by the applicable people.
The Waterfall Model:
This approach suggests making just one attempt at a design and getting it correct the first
time. When it works well, the cascade approach allows design completion times to be read
with further confidence than with some further iterative approaches allowing systems to be
controlled effectively.
Design
Fig 2.2: The waterfall model
Whilst the approach is generally suited to the design at South tech Limited, it's felt that a prototype
14
may be necessary to gauge druggies’ original passions about interface design and the functionality of
the system. The process has the advantage of being suitable to determine exactly which carry the
design is over to.
For this reason, the overall aspect of the Waterfall cycle will be espoused for this design,
although it'll be altered kindly in the coding, and testing stages. rather of clinging to the
cascade approach for these situations, a prototype approach should be espoused that will
allow for iterative perpetration ways to be utilized.
Software Prototyping
Software prototyping enables inventors to snappily 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 stoner or it's used in the coming replication of development. We also quote
a number of reasons to use prototyping; a many 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. numerous of the way needed 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 South tech Limited are a small organization, provides all parties with necessary feedback
early on in the development cycle.
15
3.2 Risk Management
A threat in software systems can be defined as an unwanted event that has negative
consequences software design pitfalls have two important characteristics.
- Uncertainty
- Loss
Risk may affect the project, the software being developed or the association associated with
the software. All projects carry some risks. For successfully completion of the design some
possible pitfalls will be linked at the morning of the design and reckoned for the project plan.
The risk management strategy for the proposed project consists of:
✓ Risk identification
✓ Risk Prioritization
✓ Impact and evaluation
✓ Risk analysis
✓ Risk planning
✓ Risk monitoring
Risk Identification, impact, evaluation & prioritization:
This exertion is a methodical attempt to specify pitfalls to the design. principally colorful
pitfalls likely to affects the design are linked. One system to identify pitfalls is to use a threat
check- list, a list of possible threat types. Following risk types can be considered.
Technology risk
• Hardware Unavailability
• Virus affect
• Database performance
• Software Component performance
People risk
• Data Theft
• Staff Turnover
16
• 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
17
Impact of risk:
Risk Type Description/Impact
Hardware Technology Risk The essential hardware will not be delivered on right time
unavailability and power problem can effect on project and cause of
delay.
Virus Technology risk The virus that can create a big impact on system and
hardware. Sometimes it can be damage full system.
Data Theft People risk Important information can be stolen or unauthorized
accessto create a big impact on project and effect to
delay project.
Staff turnover People risk Experience staff will leave the project as a result project
delivery can be delay.
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.
Tools unavailability Tools risk System development stage case tools must be require to
develop the system, if it is unavailable the right time then
system delivery can delay.
Time and cost Estimation risk When develop a system their time as fixed so delivery
system on specific time and also estimated cost.
Poor management Organizational Overall poor project management can cause of project
risk delay and make the project disaster.
Database Technology risk Performance slowness can make the customer unhappy
Performance andcan be failed to increase the usability.
Table 1 Impact of Risk
18
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
6 Estimation risk
Organizational risk
People risk
4
Requirement risk
0
Risk Type
Fig 2.3: Risk Graph
19
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
20
7. Poor management High Serious
8. Case tools High Serious
9. Requirement specification delay Moderate Serious
10. Time & cost estimation High Tolerable
Table 2 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
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
21
delay fulfill their requirement
10. Time & cost estimation Avoidance To use more people and complete
project just time.
Table 3 Risk Planning
Risk monitoring:
Risks monitoring that assess each identified risks regularly to decide whether or not it is
becoming lessor 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
22
5. Requirement risk Many requirements change request, customer
complaints
6. Estimation risk Failure to meet agreed schedule, failure to clear
reported defects.
Table 4 Risk Monitoring
3.3 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 stylish approach for
a small design. By taking strengths from a wide selection of styles, the design 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 stylish features of the cascade model with
evolutionary prototyping to form the perpetration and testing stages of the design. It's hoped
that in doing so the both the advantages are picked from the use of prototyping but the
disadvantages are avoided.
23
3.4 Requirements Analysis
In systems engineering and software engineering, requirement analysis encompasses those tasks that go
into determining the requirements 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 design.

The conditions should be proved, practicable, measurable, testable, traceable, affiliated to
linked business requirements or openings, and defined to a position of detail sufficient for
system design.
Conceptually, requirements analysis includes three types of activities:
a) 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.
b) Analyzing requirements: determining whether the stated requirements are clear,
complete, consistent and unambiguous, and resolving any apparent conflicts.
c) 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.
Requirement analysis can be a long and tiring process during which numerous delicate
cerebral chops are involved. Large systems may defy judges with hundreds or thousands of
system requirements. New systems change the terrain and connections between people, so it's
important to identify all the stakeholders, take into account all their requirements 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
24
identification of use cases, the use of plant observation or ethnography, holding interviews, or
concentrate groups (more aptly named in this context as requirements workshops, or
requirements review sessions) and creating conditions lists. Prototyping may be used to
develop an illustration system that can be demonstrated to stakeholders. Where necessary,
the critic will employ a combination of these styles to establish the exact conditions of the
stakeholders, so that a system that meets the business needs is produced.
Conditions quality can be bettered through these and other styles
o Visualization. Using tools that promote better understanding of the asked end- product
similaras visualization and simulation
o Consistent use of templates. Producing a consistent set of models and templates to
documentthe requirements.
o Documenting dependencies. Documenting dependencies and interrelationships among
requirements, as well as any assumptions and congregations.
3.5 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. South tech 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 crucial business units that operate in the company
administration, deals, development and structure. The development platoon is resolve down
into design brigades grounded on the different technologies with which the company
produces results. Because the sales department have no stake in the new Customer service
desk system, they will not be analyzed any further.
The administration business unit is made up of four workers that are responsible for the day-
today handling of the business. Amongst other tasks, including accounting and contract
management, these staff are responsible for the management of the support Customer service
desk. The development business unit makes up a large proportion of South tech 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
25
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 Customer service 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 Customer service desk 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 South tech Limited must
be considered. In the present environment, customers that require support will call or email the
Customer service 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's felt that icing the new system matches current working practices as
opposed to bringing with it organizational change is a more satisfactory system than
changing procedures and will lead to improved user relations that will ensure the customer
interfaces with South tech Limited in exactly the same method with the advantage that their
request is dealt with more effectively.
26
Customer Service Desk
Fig 3.1: Customer service desk structure
27
3.6 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 significance of requirement analysis isn’t just for functionality.
Without it, there would be no way of assessing the system, as there would be nothing to
estimate 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 South tech 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
numerous members of staff have to take over isn't apparent. Consequently, interviews have
been carried out with a number of labor force from different departments so that their
conditions can be captured. Although they can be time consuming, and delicate to arrange,
they've the capacity to be open- ended so that intriguing data can be explored when they
emerge. 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.
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:
28
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/tablet)
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 (Service Level Agreement Document) and a document
specifying the current call logging procedure (Internal Documentation). 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 precious input to the design process. In addition to
these sample documents, access has been handed to the current system so that its’ perpetration
can be anatomized and applicable processes abstracted. Care will be taken to ensure that the
current system doesn't limit the compass 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.
29
Service Level Agreement Document
Service Definition
Service Name SLA001 – Customer Service Desk
Service Description This service provides the Authority with access to, and use of the
South tech Limited’ Customer Service 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.
Process Summary
Table 5 SLAD-A
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. South tech 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
normalprocedures all reasonable endeavors will be made by South
tech 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.
30
Turn Around South tech Limited will assign appropriate technical resource to the
resolution of the issue, taking the following factors into
consideration:
Customer Impact (Severity)
Supported Status (Schedule Classification)
Table 6 SLAD-B
31
Volume There is a limit of 3 calls per week (up to 156 per annum) that will
normally be accepted under this agreement. However, South tech
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 Customer service desk are entitled to call the
Customer Service Desk
Notes Each call will be assigned one of three priorities:
Critical = System down or other serious business-impacting issue.
This equates to Coal Authority calls of priorities 1 and 2.
Moderate = Users affected but business not seriously impacted. This
equates to Coal Authority calls of priority 3.
Low = A problem that does not prevent user operation.
Table 7 SLAD-C
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: (0123) 220 1234 or Email: support@Smart5Solutions.com
Responsibility The primary IT Contact onsite must inform the South tech 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 South tech Account Manager on 918926080028.
Predicted Changes There are currently no major developments, which are predicted to
significantly impact this service.
Table 8 SLAD-D
32
Support options and strategies:
Problem Logging
As soon as a support call comes in, it receives the attention from the Customer service 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 Customer service 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 mastermind and the support call is streamlined to reflect any and all action
that's 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 mastermind comes to probe the problem, a first
call will be made to the Council to confirm the nature, compass and detail of the problem.
This forms the alternate 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.
33
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 3levels of severity:
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. Requests for
change or enhancements often start as a
support call with this status.
Table 9 ISSUE MANAGEMENT
34
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.
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. Though it
may be important to uncover as much detail as early on as possible 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.
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
35
system. This analysis forms an abecedarian part of the system design stage in structure on the
conditions captured in the former 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 South tech 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 illustration provides not only a simple way of communicating ideas with druggies
(7) but also, when complete, produces a high position 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 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 requirement list comprehensive.
36
uc Use Case Model
Support
Requester
Activity
Submit Ticket
Update Ticket
Recover Ticket ID
Support Requester
Search Help
Fig 3.2: Use case diagram
37
uc Use Case Model
Administrative Activity
Submit Ticket
Update Ticket
View Ticket
Resolve Tickets
Administrator
Assign Tickets
Support Staff
Delete Tickets
Manage
Knowledgebase
Manage Users
Manage Categories
Manage Settings
Manage Reports
Fig 3.3: Use case diagram
Each of the Use cases in Figure 3.2 are described in Use Case Description forms found in
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.
38
3.8 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.
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 guests Service Level Agreement. One question that must
now be raised is what's supposed 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.
Customer service desk Administrator

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
Table 10 Manage support call
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
Table 11 Manage Clients
39
Manage System
1.3.1. Add / Remove system users Y
Table 12 Manage System
Manage Contracts
1.4.1. View / Update default SLA response times Y
Table 13 Manage Contracts
Support Staff
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
Table 14 Resolve customer issues
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 15 Non-User Specific
3.9 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.10 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
40
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 South tech Limited
provideor 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 Customer service desk 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 South tech 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.
Incident Management
41
project.
Incident Management
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 South tech Limited receive is relatively few when compared
with many corporate Customer service desks. Additionally, with few technicians
communicating problems between them very effectively by email this is not currently a
priority. Whilst it's felt that having some form of problem operation mechanisms within the
system, it's hoped that a well- designed database will fluently support unborn operation
advancements without abecedarian system changes.
42
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 South tech Limited
may expect some form of management of their assets. The information that's held about the
guest systems is held in a Microsoft Word document, furnishing instructions on how to
remote control their systems and on what's installed on their waiters and workstations.
Although it may be salutary 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 Customer service desk 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 Customer service desk 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 Customer service desk. Whilst the need for certain changes may
arise from an underpinning system problem with, it's further than likely that any change
would be managed by an account director, not by a support technician. enforcing 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.
43
Chapter 4 Customer service desk Software Market
From the analysis undertaken in the previous chapter it is felt that South tech Limited’
requirements are quite unique. Whilst many businesses are likely to operate an IT Customer
service desk, they are unlikely to require the functionality needed within South tech Limited.
A comparison that could be made is with the Customer service desk at South tech Limited and
the Information Systems Services (ISS) Customer service desk 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, South tech Limited manage systems of many
different organizations, each with their own contract. Identified in this section are a number
of solutions aimed at corporate Customer service desks with the similar objective of South
tech 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 Help STAR
Help STAR is an out-of-the-box package aimed at the mid-market and has the functionality
that each of South tech 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 corridor of the
ITIL stylish practices and as a result rich functionality is handed through the addition of
problem operation and asset operation factors. Also, it meets South tech 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 South tech Management and to their clients. In
spite of these well-packed features, in a very nicely presented user interface, there is one
majorproblem with this software – it has absolutely no support for setting up different clients
and, assuch, 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
44
each of the customer and their employees as the package is only designed to be used on the
Customer service desk of an individual organization. Installing it for each association isn't 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 Help STAR, 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 Help STAR; 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 South tech 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
supportcalls that are open on the Customer service desk. 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.
45
Fig 4.1: Screenshot of the Help STAR Dashboard
46
4.3 Bugzilla
Bugzilla is currently used within South tech 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 shadowing of bugs within software packages as opposed to shadowing of issues with user's 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 design to be accepted in order for this to be and indeed also, 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
isopen 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
customer service desk 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 South tech Limited’ needs, are more than likely going to
outweighthe costs of implementing a system in house.
47
Chapter 5 Technical Analysis
Many 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 customer to verify that the final application actually matches
what wasinitially 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
48
3. Specific Requirements
4. Non-functional Requirements
o Browser Compatibility
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's perceivable that cutting the time it takes to carry out
a task by fragments 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 South tech 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
canbe achieved in the new system.
Getting Human Computer Interaction (HCI) issues solved in systems is not an easy task to
49
carry out and requires knowledge from many fields of science. The ideal developer of an
interactive system would have moxie in a range of motifs psychology and cognitive wisdom
to give her knowledge of the stoner’s perceptual, cognitive and problem- working chops;
ergonomics for the stoner’s physical capabilities; sociology to help her understand the wider
environment of the commerce; computer wisdom and engineering to be suitable to make 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 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's important that a
runner doesn't come so cluttered with information that the stoner can’t conceivably store
enough of the information in short term memory to be suitable to really complete their task.
50
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 stoner establishing their thing. The stoner also forms an
intention to carry out conduct and also decides on the factual conduct they're going to take.
The user then executes those actions and perceives the changes they have on the system. They
also interpret and estimate the system state after the action has been carried out. This shows
that stoner inputs should be intuitive and that the labors shouldn't give unanticipated 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 South tech
Limited expect.
Form Filling
One area of the system where usability will be unnaturally important is the data entry of new
support calls. frequently the calls will come in on the phone and so the runner must be easy to
navigate and to enter data into, conceivably using just one hand. The literature read on this
subject has not developed 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
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 task scan be done. This aids the navigation process and
an important factor in the Customer service desk system will be to ensure that, where
applicable, suitable measures are taken to make hierarchical menu structures effective rather
51
than hinder the user.
5.3 IT Infrastructure
South tech 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 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 South tech 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
52
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.
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. South tech
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 South tech 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 Customer service desk system. It is important
to know the limitations of using Microsoft’s MYSQL server product as opposed toothers such
as Oracle or MYSQL. These are discussed in section 5.3.
53
Fig 5.2: Simplified network diagram
Desktop Applications
Every member of staff at South tech 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.
54
Chapter-6 Implementation
6.1 Technology Options
Having now discussed the environment within which the new system must work, it is possible
to exam in ethe different development technologies available.
Client / Server Architecture
The infrastructure at South tech 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 Customer service desk system currently employed
by South tech 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, itis felt that moving to a thin-client
architecture would lead to a number of benefits that must be exploited in the new system.
55
MySQL DB
Fig 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 Customer service desk 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 South tech 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.
56
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 an understanding of the technologies available and their
limitations is fundamental to the correct implementation of the Customer service 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 South tech 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 terrain but it's
possible to write runners 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's a common transparent foundation subcaste
through which any programming language can pierce 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
Customer service 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
57
approximately 69% of the Worlds Web servers. It will also run on both Microsoft Windows
and on the Linux platform.
However, South tech 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 give all the functionality needed in the new system, it would
be unwise to plump 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 Customer
service desk system. However, Microsoft’s latest web development tool. Moreover, it is
technology that aligns perfectly with the current infrastructure and employee skill-set at South
tech Limited.
Fig 5.4: The execution model for Web architecture
58
6.2 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
South tech 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 South tech 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 South tech 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, still, be naïve to suppose that the areas of experience will help with this
design. It's clear that whichever system chosen would affect in a literacy wind but the choice
has been made because of the rates the technology brings to the design not because of an
understanding of syntax - this can be fluently learned.
6.3 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.
59
6.4 Application Architecture
The architecture of the application is designed to fit into the infrastructure at South tech
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 Customer service desk 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 for entire architecture). Eventually, the customer communicates with
just one garçon, which brings together each league in a single point of entry for the customer
and references other categories when they're needed.
Though the system architecture is reasonably complex it leads to a number of benefits for
South tech 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
illustration, that database could be moved to a briskly server; druggies would not know the details of the
change piecemeal fromthe fact that their queries had been executed in lower time).
60
Fig 6.1: Application Architecture - UML Deployment diagram
6.5 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 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:
A. Conceptual Database design
B. Logical database Design
C. 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.
61
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. 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 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 many errors were identified between the entities
‘Customer’, ‘Customer service desk’ 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 ‘Customer service desk’ entity. Ignoring the
‘Service Level Agreement’ entity, the relationship between ‘Customer’ and ‘Customer service
desk’ 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 Customer service
desk who logs a support call” there is no way of identifying which support call belongs to
which customer.
Fig 6.2: Customer, Customer service desk and Support calls relationships
To overcome this, the ‘Customer’ attribute must not relate to the Customer service desk; after
all it is a member of staff of the customer that will make the call not the customer itself.
62
Customer
Client Priorities Defines service desk
Administrator
Agrees Contract Logs
Customer Employs Staff Makes Support Call
Managed By
Call Assignee
Fig 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.
63
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 fulfilled. 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 needed domain.
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 Customer service desk
system this method provides a significant advantage over check constraints. Because the
constraints are stored in a lookup table, the on us to maintain these constraints can be removed
from the inventor and passed onto the client. This will produce 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.6 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 Database
Implementation Script; this specifies the entire database schema including the data type of
each attribute.
64
Database implementation script
65
66
67
68
69
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). Still, it's possible that
miscalculations may have been made during the modelling process so it's thus necessary to
check each of the functional dependences in each relation. A functional reliance “describes
the relationship between attributes and when it defines a super key of the relation, the relation
is said to be in BCNF. (Figure 6.5) shows the functional dependencies for all of the relations
in the database.
Fig 6.5: ER Diagram
70
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
‘Customer service desk 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.
Before:
After:
Fig 6.6: Before and after re design
71
Data Dictionary/Database Files
A Data Dictionary is simply a record of data about data. It may be manually collected or it
may be a completely automated package. All delineations of rudiments in the system – data
overflows, 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 roster- a depository of the rudiments in a system. These rudiments
center on data and the way they're structured to meet stoner conditions and association
requirements. The major rudiments 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 delineations for druggies and investigators
alive. It's the single source of answer of answers to all questions regarding the format and
environment 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.
Data structures
The Data Structure is a set of data items that are related to one another and that collectively
describe a component in the system. Data structure Tables shows the data structure of this
project below.
72
Data structure
User Table:
Table 16 User Table
73
User Login Table:
Table 17 User Login Table
User Password Reset Table:
Table 18 User Password Reset Table
Knowledge Base Table:
Table 19 Knowledge Base Table
74
Support Ticket Table:
Table 20 Support ticket table
75
Support Ticket Category Table:
Table 21 Support ticket Category Table
Support Ticket Mail table:
Table 22 Support Ticket Mail table
6.7 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
76
information. It's important to get a good understanding of how processes interact with one
another but because prototypes are being employed, the operation design should be
considered only as a companion.
77
Fig 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 demand 2 over is only
needed when the technician is dealing with a support call. For this reason the design of the
‘View call details’ runner must include an area that displays the details of the client so that
they can be fluently communicated.
The Customer service desk 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 won't be enforced. still, if it was to be designed into
the system, it would be a fresh top position runner. This means that it would be an easy
78
addition in an unborn interpretation and would not bear vast overhaul of the system.
Call Log
Central to the entire system is the call logging functionality. This runner 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.
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 also enables the Administrators to
log new calls for these guests. In addition to this, each client will be suitable to have a Service
position Agreement configured moreover to the system dereliction settings or to their own
tête-à-tête agreed contract with South tech 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 South tech Limited’ network.
79
Fig 6.8: Submit a Ticket
6.8 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 rather simply positions
factors on the page where they're considered to be most suitable. Figure6.9 outlines the main
page template and where the page details are a little more complex, farther images have been
created to aid the implementation of the pages.
80
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 easily be the content of the page
selected.
Fig 6.9: Home Page of CSDTS
6.10 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
81
o Send a final email when SLA has been broken
o Repeat every minute of the working day (defined in customers SLA)
6.11 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 South tech Limited. There are several reasons behind this decision. Firstly, if
the infrastructure at South tech 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 South tech 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 South tech
Limited without the need for excessive reconfiguration or coding.
Though not ideal and not identical to the infrastructure at South tech 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 South tech
Limited using their domain name, southtechgroup.com.
As discussed in Section 6.1 the system relies on many different server components. At South
tech 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 goods
82
on the performance of the system, it isn't a release terrain and only has one person interacting
with it. As such the performance issues aren't apparent, although it isn't a true reflection of the
final use of the operation where numerous druggies may interact coincidently with the system.
6.12 Data Access
The underlying requirement of this system is to store and retrieve information captured at
different stages of the Customer service desk 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 operation, it's possible to call data access functions
at any time which significantly decreases the development time and law duplication. The
access to the database enables MySQL queries to be executed and a Dataset returned to the
operation. Stored procedures are used in MySQL server so that query strings aren't needed in
the law. This creates two advantages. originally, lower data is transferred between the
customer and the server so the prosecution is more effective. 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.
83
84
Fig 7.1: Data Access

6.13 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 applicable sizes and placed into a general HTML runner which is also used as the
introductory template every time a new PHP file is needed. 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 preliminarily mentioned, all standard pages in a PHP operation inherit styles
and attributes from the page (System. Web. UI. Page) class. Rather of the pages of this
operation inheriting from the page class, they inherit for the page Base class that includes
fresh cross-site functionality.
Fig 7.2: Page inheritance
84
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 stoner controls were created; a
title(header.php) and a footer(footer.php). The footer control actually does nothing but close
the runner off, no functionality is included though it could fluently be fitted should the
demand arise. The primary element of the entire template is the header control. This contains
the functionality for carrying the druggies’ name that has logged onto the system, displaying
the date and time, and furnishing the stoner with applicable menu particulars. Figure 7.3
illustrate the use case diagram of various pages access by Administrator and support staff.
85
uc Use Case Model
Administrative
Activity
Submit Ticket
Update Ticket
View Ticket
Resolve Tickets
Administrator
Assign Tickets
Support Staff
Delete Tickets
Manage
Knowledgeb
ase
Manage Users
Manage Categories
Manage Settings
Manage Reports
Fig 7.3: Use case diagram of various pages access by Administrator and support staff
86
Chapter-7 Result Analysis
7.1 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
South tech 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 the users are satisfied that the functional
and non-functional requirements captured at the beginning of the project have been
implemented appropriately.
7.2 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 P provides a comprehensive list of what is and
what is not implemented in the system. Where certain functionality has not been implemented
South tech 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 quantum of work needed to incorporate the
functionality requested, time would be better spent enforcing the functionality that the
druggies would fete to be more salutary to them. As a result, field confirmation has been left
to be further of a tidying up exercise after the system has passed through another replication
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
87
evaluation).
7.3 User Acceptance Testing
At the beginning of this project, after all the requirements capture and analysis had been
undertaken, it was necessary for South tech 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 last column in each of the tables 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 druggies across each of the functional areas and
allowing them to use the system for a number of test cases prepared beforehand.
Fig 8.1: Testing
88
7.4 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
areaof 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.
still, by running the tests further than formerly, it's possible to make judgments on how easy
the system is to learn.
Consequently, 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
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.
89
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 ‘South tech Limited’
o Submit a ticket for ‘user-1 at ‘South tech 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 South tech Limited, is generally
more pleasant to work with than the old system.
90
7.5 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.
7.6 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
aroundit. 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.
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 bebrought to fruition early on in the project and as such included in prototypes that are
91
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 South tech 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.
7.8 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.
7.9 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.
92
Fig 9.1: Implementation diagram specifying the new system architecture
Choice of technology
Ensuring that the new system functioned on the infrastructure in place at South tech 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
South tech 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 Customer service desk 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
93
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 South tech Limited and as such, it can be
concluded that the right decision was made.
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 South tech 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.
94
Fig 9.2: Home screen of CSDTS
95
7.10 User Manual
User manuals are given at “User Manual” section:-
User Manual
How to submit a ticket in “Customer service desk”
1. Open your Internet Explorer Browser

2. Type this “ http:// Customer service desk ” in address bar
3. Now click on “Submit a ticket”
Fig 9.3: user manual

4. Now fill up all required information
96
Fig 9.4 : Ticket submit
5. And Click “Submit Ticket”
6. Then you get a ticket id like below, also you will get a email notification:
Fig 9.5 : Ticket Submit
97
How to view a ticket in “Customer service desk”
1. Go to Customer service desk home page and Click View existing

ticket.
2. Input your ticket id and click view ticket for view your support ticket
history.
Fig 9.6: View Existing Ticket
3. You will see this details screen and you may update as require.
98
Fig 9.7: Case Tracking
99
Chapter-8 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 South tech 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
projectand the frustration that more could not be achieved in the time spent so far.
The qualitative feedback in the former chapter provides a good base to start this section from.
The issues raised must be the first enhancement to be made to the system. They don’t form
advancements but abecedarian changes that will give acceptable functionality with a well-
established stoner interface. However, beyond this there are changes that can be truly
regarded as ‘enhancement’.
When scrutinizing the system with some developers at South tech 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
100
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 South tech 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
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.
101
Conclusion
Before it is able to fully control the support process at South tech 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 Customer service desk and make it more user
friendly, the system is ready to be used and the basic functionality has been achieved.
102
References
1) Jäntti, M., Cater-Steel, A., & Shrestha, A. (2012). Towards an improved it service
desk system and processes: a case study. International Journal on Advances in
Systems and Measurements, 5(3 & 4), 203-215.
2) Pogarcic, I., Jankovic, S. R., & Seturidze, R. (2017). How does the help desk quality
improve customer satisfaction?. In ATINER’s Conference Paper Series MED2017-
2255, ISSN (pp. 241-2891).
3) Padeletti, A., Coltrane, B., & Kline, R. (2005, November). Customer service: help for
the help desk. In Proceedings of the 33rd annual ACM SIGUCCS conference on User
services (pp. 299-304).
4) Alias, M. F. (2007). Front desk customer service for queue management
system (Doctoral dissertation, UMP).
5) Keller, A., & Midboe, T. (2010, April). Implementing a service desk: A practitioner's
perspective. In 2010 IEEE Network Operations and Management Symposium-NOMS
2010 (pp. 685-696). IEEE.
6) Tang, X., & Todo, Y. (2013). A study of service desk setup in implementing IT
service management in enterprises.
7) Oud, J., & Genzinger, P. (2016). Aiming for service excellence: Implementing a plan
for customer service quality at a blended service desk. Journal of Access
Services, 13(2), 112-130.
8) Suryotrisongko, H., & Mucharomah, M. D. Q. (2017, October). Ideal help
desk/service desk in e-government and service quality: A literature review. In 2017
11th International Conference on Information & Communication Technology and
System (ICTS) (pp. 203-208). IEEE.
9) Twitchell, M. C. (1997, November). Moving from helpless desk to help desk: practical
strategies for improving customer service in a multi-function university help desk.
In Proceedings of the 25th annual ACM SIGUCCS conference on User services: are
you ready? (pp. 303-306).
10) Rahman, R., Alarifi, A. H. E., Eden, R., & Sedera, D. (2014). Archival analysis of
service desk research: New perspectives on design and delivery. In Proceedings of the
25th Australasian Conference on Information Systems (pp. 1-10). ACIS/Auckland
University of Technology.
103

Customer - Service - Desk Final Thesis

Uploaded by

Copyright:

Available Formats

You might also like

Customer - Service - Desk Final Thesis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Customer - Service - Desk Final Thesis

Uploaded by

Copyright:

Available Formats

CUSTOMER SERVICE DESK

Thesis submitted towards the partial fulfillment of the requirements for

MASTER OF COMPUTER APPLICATION

GANGADHAR MEHER UNIVERSITY

Internal examiner External Examiner

Mr. Prateek Mahapatra

Figure No. Page No

Fig 2.1-Project Schedule 11

Table 1 Impact of Risk 18

- Geolocation technology, or location-based services can use by CSDTS systems

- CSDTS systems help businesses optimize processes by streamlining mundane

o Produce knowledge rich papers to give results, workarounds, and

2.1 Initial Study

2.2 Background of the Study

2.3 Theoretical/Conceptual Framework

2.4 Project Vision and Aims

2.5 Project Scope

2.6 Hardware and Software Requirements

Recommended Hardware Requirements (Application and DB Server)

• Minimum 350 MB Hard Disk space for installation

• Minimum CPU - Pentium 4, 3.2 GHz

• Gigabit Ethernet Network card

Minimum Software Requirements:

Other Software Requirements:

2.7 Further Enhancements

2.9 Project Management

3.1 Development Methodologies

Joint Application Development:

The Waterfall Model:

Fig 2.2: The waterfall model

Risk Identification, impact, evaluation & prioritization:

Risk Type Description/Impact

Table 1 Impact of Risk

Fig 2.3: Risk Graph

Sl. no Risk Probability Effects

Table 2 Risk Analysis

Sl. no Risk Strategies Description

Table 3 Risk Planning

Sl. no Risk Description

Table 4 Risk Monitoring

Requirements analysis is critical to the success or failure of a systems or software design.

Conceptually, requirements analysis includes three types of activities:

a) Eliciting requirements: (e.g. the project charter or definition), business process

3.5 Business Analysis

Fig 3.1: Customer service desk structure

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

Severity Response Description

Table 9 ISSUE MANAGEMENT

3.7 Requirements Analysis

Fig 3.2: Use case diagram

Fig 3.3: Use case diagram

Customer service desk Administrator

1.1.3. Obtain status of call Y

Table 10 Manage support call

Table 12 Manage System

Table 13 Manage Contracts

Table 14 Resolve customer issues

Table 15 Non-User Specific