Implementing an issue tracking system to seek coordination improvements

(1)

Software Engineering and Digital Transformation

Hien Nguyen

IMPLEMENTING AN ISSUE TRACKING SYSTEM TO SEEK COORDINATION IMPROVEMENTS

Master’s Thesis

Examiners: Antti Knutas D.Sc. (Tech.), Asst. Prof.

Jouni Ikonen D.Sc. (Tech.), Assoc. Prof.

Supervisors: Antti Knutas D.Sc. (Tech.), Asst. Prof.

(2)

LUT University

School of Engineering Science

Software Engineering and Digital Transformation

Hien Nguyen

Implementing an Issue Tracking System to Seek Coordination Improvements

Master’s Thesis 2020

80 pages, 25 figures, 39 tables, and 2 appendices.

Examiners: Antti Knutas D.Sc. (Tech.), Asst. Prof.

Keywords: computer-supported, collaboration, issue tracking, coordination, ticket

Agile methodologies have been putting emphasis on frequent release and communication between software development teams and their customers. These stakeholders have to collaborate with each other on a daily basis to reach collective decisions. Particularly, small and medium enterprises have to deal with enormous pressure from customers while struggling with great challenges and limited resources. Hence, an effective and efficient coordination mechanism is indispensable to streamline knowledge and make sure every- thing goes smoothly. The field of computer-supported cooperative work has opened many studies of applications and knowledge management. A software artifact, therefore, is also an object of interest in this research field to enhance coordination. This thesis work will excavate the coordination problems within software companies and propose a software solution.

(3)

This thesis work would never come to its end without Professor Antti Knutas, to whom I send my most sincere gratitude for his thorough supervision and indispensable guidance on this thesis work. I also truly appreciate Professor Jouni Ikonen for his invaluable feedback that helps me greatly complete this work.

Also, I am deeply thankful to my whole family, friends and colleagues in both Vietnam and Finland for their encouragement and support, which boosted me greatly over not only this thesis course but also the whole Master study. Finally, I would like to thank participants of the usability testing for their contribution to my work.

Lappeenranta, June, 2020

Hien Nguyen

(4)

ABBREVIATIONS AND SYMBOLS

SME Small and medium-sized enterprise SaaS Software-as-a-Service

B2B Business-to-business

VoIP Voice over Internet Protocol DevOps Development and Operations DSR Design Science Research UML Unified Modeling Language UI User Interface

CS Customer Service

CSCW Computer-supported Cooperative Work API Application Programming Interface CRUD Create, Read, Update and Delete DBMS Database Management System SQL Structured Query Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure TCP Transmission Control Protocol SHA Secure Hash Algorithm

ASR Architecturally Significant Requirement SD Standard Deviation

CRM Customer Relationship Management

(7)

List of Figures

1 Process of design research . . . 12

2 CSCW Matrix . . . 16

3 Lifecycle of an issue . . . 23

4 Activity of customer submitting a ticket . . . 28

5 Hierarchical decomposition of resolving a customer ticket . . . 28

6 System context . . . 32

7 System use-cases . . . 33

8 Functional view of the system . . . 40

9 Logical data model . . . 41

10 Deployment view of the system . . . 42

11 Login view . . . 43

12 Guest UI: Dashboard . . . 43

13 Guest UI: Submit ticket form . . . 44

14 Guest UI: Ticket details . . . 44

15 Employee UI: Homepage . . . 45

16 Employee UI: Workgroup . . . 46

17 Employee UI: Workgroup details . . . 46

18 Employee UI: Conversation details . . . 47

19 Employee UI: Task details . . . 47

20 Employee UI: Customer . . . 48

21 Employee UI: Customer details . . . 48

22 Employee UI: Ticket details . . . 49

23 Manager UI: Ticket Sector . . . 49

24 Manager UI: Issue . . . 50

25 Manager UI: User . . . 50

(8)

List of Tables

1 Structure of the thesis . . . 14

2 Problems in traditional group interactions and CSCW solutions . . . 18

3 The as-is and to-be characteristics . . . 27

4 Glossary of terms used in system . . . 29

5 List of features . . . 30

6 Stakeholder profiles . . . 31

7 Actor: Guest . . . 34

8 Actor: Staff . . . 34

9 Actor: Manager . . . 35

10 External interface requirements . . . 36

11 Quality attributes . . . 37

12 Business rules . . . 38

13 Quantitative values of survey answers . . . 52

14 Survey questions: Guest section . . . 52

15 Survey questions: Employee section . . . 53

16 Survey questions: General section . . . 54

17 Descriptive statistics from survey answers . . . 54

A1.1 Use-case: Manage customer . . . 66

A1.2 Use-case: Manage ticket . . . 67

A1.3 Use-case: Comment on ticket . . . 67

A1.4 Use-case: Manage workgroup . . . 68

A1.5 Use-case: Manage conversation . . . 69

A1.6 Use-case: Comment on conversation . . . 69

A1.7 Use-case: Manage task . . . 70

A1.8 Use-case: Manage issue . . . 70

A1.9 Use-case: Manage ticket sector . . . 71

A1.10 Use-case: Update profile . . . 72

A1.11 Use-case: Grant employee account . . . 72

A1.12 Use-case: Submit new ticket . . . 73

A2.1 Description of attributes on User table . . . 74

A2.2 Description of attributes on Customer table . . . 75

A2.3 Description of attributes on Workgroup table . . . 75

A2.4 Description of attributes on Conversation table . . . 76

A2.5 Description of attributes on ConversationComment table . . . 76

A2.6 Description of attributes on Task table . . . 77

A2.7 Description of attributes on TicketSector table . . . 78

(9)

A2.8 Description of attributes on Issue table . . . 78 A2.9 Description of attributes on Ticket table . . . 79 A2.10 Description of attributes on TicketComment table . . . 80

(10)

1 INTRODUCTION

1.1 Background

Agile methodologies have for long emerged as the prominent approach of software development since publication of the Agile Software Development Manifesto [1]. Its central values adhere the relationships among human roles in software contracts, frequent release of tested working software, and all participants are inclined to make changes [2]. One key issue is knowledge management, when the whole organization relies heavily on developers and cut off documentation, which can prove useful for communication and traceability.

Meanwhile, strong relationship with customers facilitates collaborative decision-making.

Tools play a significant role constituting successful software development, and their users must be trained to utilize them properly [3].

Operational problems and in-use practices vary greatly because every software company has a different size, culture, management style, product range, and geographical features.

At the moment, a large proportion in software industry is small and medium-sized enterprises (SMEs). Their utmost priority is on satisfying their customers, hence their help desk is usually under the pressure of troubleshooting, new requirements and guidance after sales [4]. In process, giving solution to customers, who are likely to demand it instantly, hampers formal procedure and good practices [5].

To inspect coordination problems in software enterprises, a small company, whose name is kept confidential here, is taken as an example. It is a Vietnamese start-up which develops an integrated call center management solution in Software-as-a-Service (SaaS) model. Their product, a business-to-business (B2B) one, is sold to other enterprises, with purpose to optimize resources in digitally transforming a call center for upgrading sales’

or service’s capacity by changing from landline telephone to a Voice over Internet Proto- col (VoIP) call center software. It is quickly expanding in both customers and consumers.

The company’s service is more likely to cope with rapid feedback from users, bug reports, new feature requests from current and potential customers. The process of changes may involve personnel from different departments: customer support agents to communicate with users, development and operations (DevOps) engineers to deal with underlying VoIP technology and network providers, frontend and backend developers to implement new functionalities and fix bugs, and marketing executive to prepare content and digital marketing for new updates.

(11)

At the moment, most of the workforce’s communication and task management is done via a chat service, and the customer issues are monitored through manually filled Excel worksheets. The current process offers limited traceability of customer issues and tasks, lacks focus on key information, and struggles to adapt increasing customer demand. The manual process is not effective. Updating the documents, which become more bulky and difficult to keep track, increasingly takes considerable amount of time and is easily to be neglected or omitted. As a small-sized software company, the personnel turnover is high. When a new customer support agent is onboard, there is no packaged template of describing how to deal with frequently recurring and/or similar customer issues, which the company and old employees have previously drawn established knowledge to deal with.

Besides, frequently recurring issues may imply underlying vulnerable parts in codebase, scope creeps and technical debts.

This thesis will examine current literature, then offer an evidence-based solution. The proposed solution is an issue tracking system, which emphasizes on organizing customer issues, managing tasks, managing knowledge, and establishing communication channels.

The values brought by this solution are highlighted by addressing several previous com- parative studies and evaluation from usability testing.

1.2 Objectives and Delimitations

The primary goal of this thesis is to build a web application as a software artifact to solve coordination problems within software companies. The thesis is fulfilled by complet- ing the first iteration of the software solution and evaluating it through usability testing, therefore seeking answers of the following questions:

• RQ1:Which coordination problems currently exist in software companies?

• RQ2: How can these problems be solved with an improved collaborative software platform?

1.3 Research Methodology

The thesis context is in software companies and their practical collaboration problems.

The solution is seeked through building an artifact (e.g. web application) rather than transforming organizational structure or teamwork process. Hence, the chosen method to

(12)

carry out the thesis is Design Science Research (DSR). The method choice is justified by Iivari and Venable’s definition of DSR as”a research activity that invents or builds new, innovative artifacts for solving problems or achieving improvements, i.e. DSR creates new means for achieving some general (unsituated) goal, as its major research contributions.

They also confirmed”such new and innovative artifacts create new reality, rather than explaining existing reality or helping to make sense of it”[6]. Also, Hevner et al. claimed that DSR ”creates and evaluates IT artifacts intended to solve identified organizational problem”[7].

The DSR is conducted by proceeding steps recommended by Pfeffers et al [8]. Accord- ingly, the thesis scope will act as the first iteration of the development lifecycle for this software artifact:

Figure 1.Stages of Design Science Research [8]

1. Problem identification and motivation: The background ideas of this thesis are clearly explained in this chapter. The motivation is to seek a software solution in context of software development company: how they deal with customers and bugs effectively, how to keep the knowledge shared and streamline tasks efficiently. To set a foundation for this research, a literature review is conducted by identifying and screening strictly through research papers and practical resources.

2. Objectives of a solution: Motivated by the topic problems generally and case company particularly, the purpose of this thesis is defined with expected outcomes as explained above.

(13)

3. Design and development: Overall functionalities of the actual artifacts are designed and implemented in this phase. The design is clearly made to solve the requirements, and development takes place to create a working artifact. Design decisions are considered and made with respect to different stakeholders and archi- tectural perspectives, represented via Unified Modeling Language (UML).

4. Demonstration:The artifact is illustrated by showing primary user interfaces (UI), providing a cognitive walkthrough to use the artifact resolving the given problem.

5. Evaluation:Feedback needs gathering to compare the actual artifact with its expectations. The success of this iteration is evaluated by approaching several test users, kindly asking them to participate in usability testing, then taking measurement.

6. Communication: The final step of this thesis is to encompass all outcomes into this thesis report and publish it to community.

1.4 Structure of the Thesis

This thesis consists of both theoretical and practical aspects. It reflects the principles of DSR by taking its steps into carrying out research and embodies the results as in the following structure:

(14)

Table 1.Thesis structure conducted in DSR

DSR stage Section Content

Problem identification and motivation

Chapter 1.1 Background ideas motivating the research Chapter 2 Literature review on relevant topics of this the-

sis. These topics are about computer-supported cooperative work (CSCW), particularly collaborative systems and issue tracking system, serv- ing as the foundation for research

Objectives of a solution Chapter 1.2 Research questions and projected outcomes of the thesis

Design and development

Chapter 3.1 Design decisions of the proposed solution in practitioner’s perspective, connected with literature in previous sections. The system context and features are explained through the use of practical templates in requirements engineering Demonstration Chapter 3.2 Architecture and demonstration of the system are addressed with UML diagrams and pictures Evaluation Chapter 3.3 Evaluation process is introduced and its results

are also given

Chapter 4 Results of this thesis are discussed by figuring out its limitations and prospects in future Communication None The thesis is published

(15)

2 LITERATURE REVIEW

This chapter provides literature review related with CSCW and its sub-fields. Different sources of materials are discussed to answer what CSCW is, and how its application domains including collaboration tools and issue tracking system intervene in software production processes.

2.1 Computer-supported Cooperative Work

CSCW was invented by Irene Greif and Paul Cashman in 1984 to describe how computers can support people in their work, especially at that time the world witnessed a massive rise of personal computers and minicomputers with huge potential to assist human in more sophisticated, interactive ways. Since then, many researchers and developers from different fields have embraced this area. Grudin considers it ”an effort by technologist to learn from economists, social psychologists, anthropologists, organizational theorists, educators, and anyone else who could shed light on group activity” [9]. From the collaboration of these different specialists, CSCW”looks at how groups work and seeks to discover how technology (especially computers) can help them work”. Ellis et al. reckon that CSCW, as the study of such systems, is a multidisciplinary field [10]. Dourish also agreed that, in its essence, CSCW has”a highly diverse discipline”[11].

2.1.1 Characteristics

The history of CSCW witnesses different definitions from different scientists. The objective of CSCW is to improve work efficacy, then there are two aspects of interests: group working process and technology. Subsequently, Kevin Mills observed that researchers in CSCW also adopt two respective viewpoints: work-centric and technology-centric [12].

Greif defines CSCW as”a distinct and identifiable research field focused on the role of the computer in support of group work”[13]. This viewpoint accentuates the technology that aids teamwork. Meanwhile, Bannon and Schmidt claimed that CSCW is ”an endeavor to understand the nature and characteristics of cooperative work with the objective of designing adequate computer based technologies”. Through this concept, they put more emphasis on the social aspect, where better insight of cooperative work will lead to better design of computer systems to support the work itself [14]. Wilson concludes that CSCW is”a generic term, which combines the understanding of the way people work in

(16)

groups with the enabling technologies of computer networking, and associated hardware, software, services and techniques”[15].

Today’s worldwide market pushes many software companies to increase effectiveness in production process, amplify product quality and reduce the time to launch their products to market. With growing complexity of problems, CSCW brings new research attempts to combine the effort of individuals in collaborative activities [16].

According to Bannon and Schmidt, most practitioners view CSCW as leverage point to build novel application, and equate the term CSCW with groupware [14]. Ellis et al.

define groupware as”computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment” [10].

These two broad concepts usually overlap each other.

To conceptualize CSCW systems, Johansen introduced the CSCW Matrix in 1988. Two dimensions are taken into consideration: time (interactions among users are synchronous or asynchronous) and space (users are at the same place or dispersed) [17]. It is suggested that there are four categories of CSCW systems, as depicted in the image below.

Figure 2.Time-space CSCW matrix by Johansen, image by Wikipedia [17]

(17)

There are three key areas that need attending to support group interactions [10] [18]:

• Communication:Exchange of information.

• Collaboration: The effort to complete a shared goal, being done interactively between two or more people.

• Coordination: The effort made individually but interdependently before getting combined. Coordination is the overhead when several parties are performing a task to achieve a common goal.

2.1.2 Benefits and Drawbacks

Kamel and Davison examined that there are generally four categories of problems that impair traditional face-to-face group interactions. CSCW systems are designed to miti- gate subsequent inefficiencies. The table below summarizes these four categories (time, space/distance, cost, and behaviour-related problems) with respective CSCW solutions [19].

(18)

Table 2.Problems in face-to-face group interactions and CSCW solutions [19]

Category Problem CSCW solution

Time-related Too much time spent in arranging meetings

Group calendar Insufficient time spent in analysing issues

during meetings

Distributed meeting systems Too much time in travelling to distant

meetings

Teleconferencing systems Too much time wasted in the collection

and tabulation of anonymous votes during meetings

Electronic voting systems

Difficulty in collecting and analysing multiscaled data from meeting members

Electronic survey tools Poor use of time in meetings due to poor

task focus

Electronic meeting agenda Too much time spent on filling in forms

and searching for documents

Workflow automation Space/distance-

Distributed meeting systems Shortage of meeting space Room scheduler

Rigid/inflexible table design Modular tables Paper documents occupy too much space Workflow automation Cost-related Expensive meeting space Teleconferencing systems

High travel costs Distributed meeting systems

High storage and human costs in archiv- ing and maintaining paper documents

Workflow automation Behaviour-

Idea generation, categorization and evaluation tools Lack of group cohesion Distributed meeting systems Intercultural difficulties Automatic translation Poor expression and miscomprehension Electronic communication High moderator influence through control

of procedural matters

Automated meeting or protocol facilitation

Discussion domination and yielding to higher normative status

Yielding to group pressure

Nonetheless, Kamel and Davidson still acknowledged potential drawbacks in the process of CSCW system adoption [19]:

• Even though asynchronous communication systems optimize participants’ time, there is very little peer pressure to participate. Hence, participation often only occurs at the last moment, if at all.

(19)

• Distributed meeting replacing face-to-face reduces intimacy and restricts media richness.

• In theory, CSCW use can reduce travel-related costs. In practice, however, this may not really reduce cost, but indeed prompt better interactions leading to better decisions for the same cost.

• The expense of implementing or acquiring CSCW systems must be taken into account. In the process, additional problems can arise, resulting in additional cost.

• In some CSCW systems, voting, idea generation, categorization and evaluation take place anonymously to avoid influence from dominant figures and promote active participation from lower-status members. Nevertheless, anonymity can be misused if used to criticize, causing subsequent conflicts, thus requiring strict and effective management.

• Individuals from different cultures have different ways of conducting interactions.

Especially in cross-cultural environments, if users are unable or unwilling to adapt their interaction style to fit a technology, the adoption will likely become a failure.

2.1.3 Challenges and Strategies

Ackerman explained that there is a social-technical gap, which means”the great divide between what we know we must support socially and what we can support technically”, since human activity is highly flexible, nuanced and contextualized. As a consequence, computer systems that support these activities should be flexible, nuanced and contextualized at a similar level likewise. It is a pivotal challenge for CSCW researchers to understand and close the gap [20].

In addition, members of organizations may have differing and multiple goals, leading to possible conflicts [20]. Koch and Gross also agreed that capturing requirements for a collaborative system is difficult, since there are many groups and aspects to consider.

Identifying accurately the needs of all group is extremely difficult, not to mention that these requirements are volatile as the research iteration progresses [21].

Thus, there is a critical mass problem for CSCW systems. Put it differently, both adequate number of users and high level of engagement are prerequisites for the success of the system. In order to secure active participation, a clear balance between effort and benefits for all users is negotiated to motivate the norms of CSCW system use [20] [21].

(20)

To overcome such challenges, CSCW systems should be constructed in ways that accom- modate particular to general, and harmonize the interests of different stakeholders. Ger- son observed the trends of hyper-distribution (decreasing face-to-face interactions and overcoming geographical barriers) andhyper-accessibility(increasing number of objects and tasks capable of communicating with one another across boundaries). Then, Gerson introduced two rules of thumb for CSCW developers: easier customization and easier reconciliation [22].

Generally, customization facilitates standardized coordination mechanism that suits contextualized articulation work. Such a CSCW system must be modifiable by users, so that changing circumstances and idiosyncrasies can be reflected in the system easily and quickly. Establishing reconciliation notably involves participant review, which means aggregating of individual views to make a unified decision. Prime examples for this approach are bulletin boards, blogs, forums, wikis. These modes offer collective messaging in threads and even editable shared content, and have flourished remarkably [22]. Such strategies matched several suggested proposals stated by Ackerman and Koch previously, which include user-friendly interface, good integration, information awareness and pri- vacy, flexibility to handle exceptions [20] [21].

2.2 Issue Tracking System

In the lifecycle of software development, maintenance is always a critical phase as changes are inevitable. As software keeps evolving, it rarely operates without defects, which are usually called “bugs”. A software’s defects are usually managed via abug tracking system, which proves an invaluable tool if effectively used. A bug tracking system assists software development team to specify, analyze, keep track, assign, monitor, and report bugs [23]. A bug generally includes the following significant information [24]:

• Which behaviour it produces

• How it is supposed to work

• Who reports the bug

• How severe it is

• Which component it affects

• How important it is

(21)

• How to reproduce it

• On which operating system it occurs

Moreover, agile software teams usually have to cope with frequent feedback, which include not only bug report but also new feature requests. A bug tracking system is regarded as one type of broader software package definition: issue tracking system. The core value of issue tracking system is to provide collaborative integrations with customers of a software system. These implementations usually revolve customer support tickets.

A ticket, within an issue tracking system, is an encompassment of a particular problem.

A customer of a software system submits a ticket element to report on a particular issue they have with the software. Once this issue is recorded in an issue tracking system in form of ticket, it facilitates staff of software company to communicate with customer and with each other more efficiently to locate where the problem lies, and what they have to do to resolve it collaboratively. An issue might represent not only a bug that customer encounters, but also a request to add or modify something in software functionalities, or a customer inquiry [25]. Essentially, an issue reports the following information:

• Who reports it

• Which status it currently is

• What kind of request it is

• Who is needed to analyse the issue

• What steps needed to resolve it

• Who will implement the solution

• When the issue is reported and resolved

Within an issue tracking system, an issue always follows one of several predefined se- quences, which start from its initial report until its final closure. At every stage of this lifecycle, a status will characterize the current state of the issue. Different issue tracking systems can adopt different succession of statuses and different terminology, but generally a reported issue shall undergo these stages [26]:

• New:The creation of the issue.

(22)

• Open: The acknowledgement of the issue, implying that this issue has been made aware of and is soon to be assigned to a resolver.

• Assigned:The indication that the issue has been assigned to resolver to handle.

• Resolved:The indication that corrective actions have been taken.

• Reopened:The feedback from customer that deems the provided response as inap- propriate or incomplete, requesting moreover solution.

• Closed: The ultimate state, confirming that the issue has been totally resolved, effectively ending its lifecycle.

(23)

Figure 3.Lifecycle of an issue in Bugzilla [27]

A strong benefit of issue tracking system is to keep shared knowledge. With task collaboration, issue tracking tool is an asset that increase transparency and accountability. Re- solving issues may involve multiple stakeholders’ activities, signifying effective communication and efficient collaboration. Although face-to-face communication is important, centralized information is fundamental to keep communication as less time-consuming as possible. Customers always demand prompt delivery and quick problem resolution. De- livering high quality customer service is of utmost importance for any company in highly competitive business environment [28].

(24)

Usually, after an issue is submitted, many follow-up questions are asked to seek resolution. However, replies among customer, customer support (CS) agent and developer can consume large amount of time. One crucial kind of information needed to ask is the location of a defect. These questions might be met by looking for screenshots, build identifiers, or certain menus or dialogs. Furthermore, question/answer pairs for a large number of similar fixed bugs help determine what to do next, what reply we should send to negotiate with customer, how we expect it resolved, and how we estimate the needed resources to handle [24].

Furthermore, Zimmermann et al. suggested building expert systems to make use of those prerequisite data. For example, location of problems can be predicted by machine learn- ing models thanks to previous similar questions and responses. An insightful report can also highlight the recurring issues so that the development team can put more effort in respective parts. In addition, it is useful for developers, CS agents and managers to draw experience in resource planning, task estimating to adjust suitable expectations for customers [24].

(25)

3 RESULTS

In this chapter, results of the research are presented. Many practical templates and techniques of requirements engineering come as useful means to represent the ideas of requirements and design decisions. To begin with, both functional and non-functional requirements are recorded as a consensus among stakeholders. Then, the design decisions are discussed according to requirements analysis. These decisions are made to solve the requirements, as grounds to proceed developing a working artifact. After that, the state of current application or prototyping is shown. Finally, the evaluation process is introduced, also with its outcomes.

The implementation is an issue tracking system, which emphasizes on organizing customer issues, managing tasks, managing knowledge, and establishing communication channels to facilitate collaboration between customers and employees, as well as within teamwork.

3.1 Requirements Analysis

The system design starts with requirements analysis. The focus is on the aforementioned case company in Vietnam, who develops and maintains their software product for various customers in SaaS model, hence must offer customer support. During this research, there are two primary techniques to gather requirements: interview and observation.

Interview is the most commonly used technique as it allows system designers to collect large amount of information quickly. Therefore, several interviews were carried out in both structured and unstructured form. Initially unstructured interview is done to explore the understanding of domain - in this case, customer support (CS) - structured one is subsequently utilized to focus on the right questions to ask, gather specific useful data [29]. The interviewees include CS executive, CS agent, and software developer from the case company as the main sources of requirements.

In addition, observation is a popular ethnographic technique to study the case activities in their natural settings. Observation has previously taken place in the background to inspect the contextual factors and collaborations among different system users. Hence, it is more expensive to perform and require more works [29]. Through these two techniques, stakeholder profiles and their requirements are clearly analyzed.

(26)

Outcomes of requirements analysis are organized in several document templates by Wiegers and Beatty [30]. The result system seeks solution conforming:

• Gerson’s two rules of thumb for CSCW developers:easier customizationandeas- ier reconciliation[22].

• Two types of data needed to improve issue tracking: information that developers use to find the location of a defect, andgeneric follow-up question/answer-pairs for a large number of fixed bugs[24].

3.1.1 Vision and Scope

The vision and scope document”collects the business requirements into a single deliver- able that sets the stage for the subsequent development work” [30]. In this section, the project scope is defined at high level, then stakeholders are identified, thus clarifying the business benefits of this system.

In the first place, the system attempts to innovate the teamwork synergy of the case software company. The result is a transformation from old-fashioned manual to software utilization, which is both modern and helpful. It will enhance customer service, keep the information in synchronization among members of organization, allow customer service agents to keep track of their customer interactions, improve work efficiency, and build some foundation to measure the productivity. Furthermore, the system can be generalized to adapt other types of company that requires customer support, rather than only software ones. The table below elaborates the as-is work process and to-be one that this system targets to achieve upon completion.

(27)

Table 3.The as-is and to-be characteristics

As-is To-be

Lack of ubiquitous and organized channel of communication, causing loss of information

Establishment of formal communication mechanism, keeping knowledge stream- lined

Customer interactions go through with manual tracking, which consumes considerable amount of time

Detailed history of customer feedback and interactions with company staff Same or similar problems occur again

and again without awareness, underlying technical debts stay unnoticed

Detailed history, custom categorization of recurring issues

High turnover rate leads to additional cost of training new CS agent

Custom categorization of recurring issues can be utilized as an effective method of documentation

Tasks may pass through unmonitored, or staff may simply forget some periodical tasks. For example, CS agent usually asks for customer feedback and contract re- newal as the contract is expiring

Task management and reminder functionalities

This research utilizes Activity Theory to analyze requirements by understanding the contextualized human activities. Activity Theory is defined by Kuutti as ”a philosophical and cross-disciplinary framework for studying different forms of human practices as development processes, both individual and social levels interlinked at the same time”[31].

The triangular figure below is an example of the structure of the most basic activity in this system: a customer submit a ticket of bug report or feature request. A key principle of activity theory is that a human activity is the basic unit of analysis. An activity indicates that a subject (individually or collectively) transforms an object into an outcome. Tools play the role of mediating the transformation process. The subject does not exist in isolation but have ones who share the same object (community). The relationship between subject and community is mediated by rules - which are conventions and policies that regulate activities in the system. Finally, the relationship between object and community is mediated by division of labour, which means the role of each individual in the community [31].

(28)

Figure 4.Activity of customer submitting a ticket

The figure below illustrates how to perform an activity from the root. The dashed line depicts the breakdown of a complex activity into small sub-activities, while the arrow line represents the sequence relationship that one action must be performed after another. This figure reflects how the case company deals with a customer issue explicitly step-by-step.

Figure 5. Hierarchical decomposition of resolving a customer ticket

For better clarification purpose, since this chapter, the meanings of several terms in system context are explained in the table below, to avoid any misunderstanding:

(29)

Table 4.Glossary of terms used in system

Term Meaning Value

Ticket An encompassment of a particular problem or request reported by customer. For example: Button X does not work as expected and yields unknown error

Aid CS agent to quickly locate and communicate with customer about their problem or request, call out for solution in background

Ticket sector The categorization of ticket that regards the component involved to resolve the reported ticket. Examples of ticket sector:

back-end error, system fault, integration error

Easy determinant of accountability of matter

Issue A template describes the classification of tickets. Every issue is already drawn with a systematic internal process to deal with.

An issue is driven by solving particular problems for customer empirically. For example: recurring defect X is repro- duced by specified steps, then assigned with a member from department Y, getting solved by following specified steps

Easy determinant of what to do with a ticket thanks to shared knowledge

Workgroup A collection of system users and their cooperative activities for internal shared goals. These activities include conversations, comments, and tasks

High participation review, knowledge sharing, information closure from others

The table below briefly explains the intended major features that will be included in system upon completeness of this iteration.

(30)

Table 5.List of features

Feature name Benefits

Create, view, modify, and delete customer information

Keep track of customer information and collaboration activities with them

Create, view, modify, and delete ticket sector categorization of ticket

Classify customer problem or request to easily iden- tify the location of interest in software system

Create, view, modify, and delete issue categorization of ticket

Make a set of recurring customer inquiries that have been standardized to systematic response process Create, view, modify, and

comment ticket

Keep track of collaborative interactions with customers, provide communication between the software company and reporting customers

Report problem/request through ticket

Make a statement about a particular problem with company’s software

Create, view, and modify workgroup

Group members into a team to easily keep relevant information shared and well-structured

Create and comment on conversation within workgroup

Make an announcement content about a certain topic relevant to workgroup, exchange information, express an opinion or reaction about the topic

Create, view, modify, and delete task

Keep track of what has been done and needs to be done, essentially in one place to follow and decide what to do next

Update profile Modify one’s own user profile

Grant employee account Provide an employee with an account with access to resources and usage of the system functionalities Authentication and authoriza-

tion

Confirm identity of employee through their credentials, verify whether they have access to particular resources and functionalities

Essentially, requirements engineering seeks to compromise rough and conflicting wishes of many stakeholders to a complete set of requirements. A stakeholder is defined as ”a person or organization who influences a system’s requirements or who is impacted by that system”[32]. The table below enumerates stakeholder profiles of the system, referencing template by Wiegers and Beatty [30].

(31)

Table 6.Stakeholder profiles

Stakeholder Major concerns Major values

Customer Effective and instant feedback response

Collaboration channel with software provider

Software company Standardized, time-saving work process

Template in solving typical issues

Less training for personnel upon turnover or exception

Coordination mechanism More competitive advantage,

increased revenue Software company’s

CS agent

Better interaction with customers, understanding customer’s pain

Standard in customer support, collaboration channel with customers

Better interaction with other members to achieve common goals, staying aware of crucial information and objectives

Sharing opinions, controlling tasks, reminding others and themselves

Software company’s developer

Effective maintenance of their software product

Aware of prominent issues, potential fragility of product Better interaction with other

members to achieve common goals, staying aware of crucial information and objectives

Sharing opinions, controlling tasks, reminding others and themselves

A context diagram is used to define the system as a whole and its input and output. The system lies in the center of the diagram, surrounded by all its interacting systems, environments and activities. The objective of context diagram is to figure out boundary of the system with its external factors in order to develop a complete set of system requirements and constraints [33]. Basically, the context diagram is very high-level, determining the software system to-be-built and entities around without any internal details itself [34].

(32)

Figure 6. System context

The figure above pictures the context view of the system. There are three types of users who interact with the system, and no external systems at the moment.

Although business risks can be mitigated by comprehensive planning and timely execution, nevertheless, the following risks are taken into consideration regarding the vision of the system:

• Employees resist to changes.

• Development and deployment of the system consumes time, causing delays as a consequence.

• Insufficient number of employees using the system will reduce the return on invest- ment from system development.

(33)

3.1.2 Use-cases

A use-case is a list of actions defining interactions between an actor and a system to achieve a goal. The use-case diagram below provides a high level visualization of user requirements. Every actor (stick figure) is connected with a use-case (oval figure) by a line to depict the interaction that actor can make with the system [30].

Figure 7. System use-cases

An actor specifies a role played by a user that interacts with the system. As shown in the use-case diagram, the system generally has 2 actors: EmployeeandGuest. Besides, Employee can be specialized into 2 actors: Staff and Manager. The tables below describes every actor and their associated use-cases with the system, templated by Wiegers and Beatty [30].

Guest represents a customer of the system, who has only limited privileges to their tickets - the primary element of reporting issues and receiving responses within system. Guest has access to limited functionalities through a guest account. A Guest account is created right when it is logged in for the very first time without any previous grant or registration.

(34)

Table 7.Actor: Guest

Use-case Description

Submit new ticket Guest can create a new ticket to report an issue to the company. This can be either a bug report on product they are using, change or new feature request

Comment on ticket Guest can make comment on ticket to communicate with the company, usually exchanging information with an assigned employee

Manage ticket Guest can view the list of tickets they have reported to the company through their guest account

Staff is a specialization of Employee, and inherits all use-cases of Employee. An Em- ployee has a granted account in the system, with privileges in workgroups, conversations, tasks, tickets, and issues they get involved with.

Table 8.Actor: Staff

Manage customer Employee can create, view, modify customer, who is a client of the product provided by the company

Manage workgroup Employee can create, view, modify workgroup in their organization. Each workgroup includes members, conversations and tasks

Manage conversation Employee can create, view, modify conversation within workgroup, which is about a relevant topic

Comment on conversation

Employee can make comment on conversation to communicate with other workgroup members and exchange information

Manage task Employee can create, view, modify tasks within workgroup

Manage ticket Employee can create, view, modify ticket Comment on ticket Employee can make comment on ticket to com-

municate with customer who has made this request previously

Update profile Edit information of the currently logged in user

Manager is a specialization of Employee, inherits all use-cases of Employee. Distin- guished from Staff, Manager has access to more privileges, namely granting employee account, manipulating business-related information - issue and ticket sector.

(35)

Table 9.Actor: Manager

Grant employee account

Manager can add a new employee to system and assign them with privileges

Manage issue Manager can create, view, modify issue - whose content can label, raise awareness of problem essence and how to deal with it

Manage ticket sector Manager can create, view, modify ticket sector - whose content helps determine the company’s responsible organizational department or related software product component

Each of these use-cases are fully explained in the tables ofAppendix 1.

3.1.3 External Interface Requirements

According to Wiegers and Beatty, external interface requirements describe the connections between the system and the rest of the universe. This section comprises 4 categories [30]:

• User interfaces: Describe the logical characteristics of the system user interface.

• Hardware interfaces: Describe the characteristics of each interface between the software and hardware components of the system.

• Software interfaces: Describe the connections between this system and other external software components.

• Communications interfaces: State the requirements for any communication func- tions the system will use.

The table below lists external interface requirements in this system context:

(36)

Table 10.External interface requirements

Category Requirements

User interfaces The system UI conforms to responsive web design

The system UI is subjective to role of user (customer, staff, manager), which means some specific screens and functionalities are only visible to designated role

The system UI is implemented in HTML and JavaScript as a single-page application

Hardware interfaces All devices with a web browser and network connectivity can access the system

Software interfaces None, as there is no interacting external software systems at the moment

Communications interfaces Front-end and back-end components communicate with each other through HTTP/HTTPS protocol

The application server communicates with database using a TCP connection

3.1.4 Quality Attributes

In software engineering, quality attributes are non-functional requirements used to evaluate the performance of a system. They are usually Architecturally Significant Require- ments (ASRs) that require consideration of architects [35]. This system design takes the following attributes into consideration:

• Availability:The proportion of time the system can operate normally.

• Reliability:The ability to perform specific actions within a certain amount of time with minimal failures and faults from interruptions.

• Performance:The number of events the system can handle in a certain period.

• Security: The ability to protect information safety and prevent any unauthorized actions.

• Usability: The measurement of how easy the users can interact with the system to accomplish their objectives effectively.

• Maintainability: The ability to have modifications and improvements with minimal cost and problems to the system’s current state.

• Portability: The ability to use the software in different environments.

(37)

Table 11.Quality attributes Attribute Requirements

Availability The system must be 24/7, and up for at least 99.7% (roughly below 5 minutes of down time each day), particularly operating with no fault for the whole office hours

Reliability Data rendering of any web components (except charts and graphs) must be complete within 0.7 seconds, any CRUD actions on any system objects must complete within 1 seconds with error prevention and recoverability

Performance The system must afford at least 10 employees and 40 customers at the same time, with at least 100 concurrent client requests

Security The system must provide at least 1 hash function to encrypt password, verify and validate user privileges whenever any access or manipulation attempt is made

Usability The system must consume no more than 5 interaction steps to perform any CRUD actions on any system objects Maintainability Any front-end change(s) within only 1 view must be im-

plemented within 1 working day only, while any back-end API(s) that affect only 1 object of the system must be implemented within 1 working day only

Portability The application must conform to responsive web design, and be usable on web browsers across multiple devices with different screen sizes

3.1.5 Business Rules

Business rules include policies, regulations, and standards. They are the origin of specific quality attributes that are then implemented. Business rules often impose constraints on business operations and hence on software systems [30]. The current rules in the system include:

(38)

Table 12.Business rules

Rule Type Nature

All passwords must be encrypted Constraint Static

Guest is logged in without any registration needed in ad- vance, and associated with one Customer

Computation Static Guest can only view their own tickets, with some limited

properties

Constraint Dynamic Guest can only comment on a ticket if it is not closed Constraint Dynamic Customer and assignee must be notified when a new ticket

comment is made

Computation Static

A ticket must associate to one customer Fact Static

A ticket must be accompanied with a status and severity Constraint Static A ticket can associate to one ticket sector Fact Dynamic

A ticket can associate to one issue Fact Dynamic

A new ticket must be assigned to one employee within 30 minutes after submission

Fact Dynamic

A ticket sector can only be created/updated by a manager Constraint Dynamic An issue can only be created/updated by a manager Constraint Dynamic A staff can only be added/removed by a manager Constraint Dynamic A workgroup’s tasks and conversations can only be seen and

taken actions by its members

Constraint Dynamic A workgroup’s creator cannot be removed from it Constraint Dynamic A non-creator member of a workgroup cannot update its

information or remove membership

Constraint Dynamic A task must be accompanied with a status, priority, and due

date

Constraint Static Workgroup members must be notified when a new conver-

sation is created

Computation Static Employee must get reminded 1 day before the due date and

every hour before the deadline

Computation Dynamic

3.2 Solution Design and Implementation

This section addresses the system architecture in several viewpoints through some diagrams. These diagrams reflect the main design decisions to meet the requirements in the previous section.

3.2.1 Functional View

This part includes a UML Component Diagram, describing the structure of software system to provide its functionalities, the list of software components and their communica-

(39)

tion interfaces. The main elements of the system are:

• Application UI: The front-end part in which system users can interact with the underlying system. User interface is shared between administrative and normal user actions, with the appropriate elements being rendered to the user depending on their role. The UI utilizes the application logic by communicating with back-end components through HTTP request/response.

• Business Logic:Including several back-end components. Providing REST API and accepting input from front-end, this layer handles the business rules of application.

These components command actions on underlying database according to the user input, then give corresponding data to front-end.

• Database: The organized storage of information within application where reading/writing actions on data are performed.

(40)

Figure 8.Functional view of the system

3.2.2 Information View

This part includes an Entity Relationship Diagram (ERD) as the logical data model, showing map of rules and data structures within system. In context of database, an entity is the abstraction of certain information of domain knowledge. Each entity has a set of attributes, which define its characteristics. Relationships express the associations or de- pendencies between entities [36].

(41)

Figure 9. Logical data model

The tables of Appendix 2 fully explain the structure and content of data within system, elaborating above logical model into physical sense, which will undergo actual implementation. The chosen Database Management System (DBMS) in-use is MongoDb.

3.2.3 Deployment View

This part will include a UML Deployment Diagram to model the physical deployment of software artifact on nodes, depicting which hardware components exist, and the execution environments run on each. Basically there are three basic nodes:

• Client Browser: Client will access the product through their browser, which will render thanks to HTML document and React script upon receiving HTTP responses from Server.

• Server: Consisting of two runtime environments. Firstly, the Node.js Application Service executes and listens client requests on a certain port, and Nginx acts as a reverse proxy and/or load balancer (if needed). In reality, there might be more than

(42)

one Server nodes to adapt scaling out the system if the number of client grows large enough.

• Database Server: This node hosts the MongoDb, which is a NoSQL database pro- gram that enables and keeps control of defining, reading and manipulating the data of the system. Database can allow access from Server(s) through a TCP connection.

Figure 10.Deployment view of the system

3.2.4 Demonstration

This section illustrates the product through pictures of the web application. This system is currently a prototype with basic representation of functionalities in mentioned scope. At the moment, the prototype is accessible oncollaborative-system-thesis.herokuapp.com.

(43)

Figure 11.Login view

At first, the user has to log in with either their Employee or Guest account. Guest account credentials are registered at the moment they first log in.

Figure 12.Guest UI: Dashboard

The overall of Guest account is pretty simple and has limited functionalities. Overall, a Guest can only have access over their basic information and associated tickets.

(44)

Figure 13.Guest UI: Submit ticket form

There is a plus button in this view to open a dialog, which includes a form to submit a ticket. By doing this, a request from this Guest user is sent to the company and awaits further response. At the moment, only text is available, in the future there is likely more data types attached to a ticket, e.g. image, file.

Figure 14.Guest UI: Ticket details

Ticket details view serves as the primary channel of information exchange about this particular customer request. Here Guest user can only view limited information, and make a reply by commenting on ticket. Both user and assignee (if any) will receive an email notifying the new activity on this ticket.

(45)

Figure 15.Employee UI: Homepage

Primary features focus on the Employee UI. Whatever view Employee is currently in, on the left side of the screen is there always a navigation bar. Through this sidebar, Employee can access to other objects of the system. The picture above captures the homepage after logging in. It renders the trends of tickets in statistical view, by visualizing several charts about ticket data recently. The area chart depicts the number of tickets by each sector for the last 30 days to observe which sector probably has underlying problems, while the doughnut chart shows the proportions of ticket by each issue in the meantime to detect the most recurring similar problems. This is especially useful for Manager and further decision-making, but it is extremely primitive now.

(46)

Figure 16.Employee UI: Workgroup

In Workgroup view, there is a grid of workgroups in the system. Employee can quickly create a new one and add more members to their own group. By clicking on an item, Employee gets redirected to its detailed view.

Figure 17.Employee UI: Workgroup details

There are 4 sections within workgroup. Firstly, the member list whose item can be added by all members but only removed by the creator. Secondly, the basic information of the workgroup can only be updated by the creator too. Furthermore, conversations and tasks

(47)

are organized by workgroup, which practically means internal discussion topics and tasks belonging to a certain department or project team.

Figure 18.Employee UI: Conversation details

Each conversation can be created by filling a form to make a place for discussing and exchanging information within the team. In Conversation details view, team members can send a comment reply quickly. At the moment, only text is available, in the future there is likely more data types attached to a conversation, e.g. image, file.

Figure 19.Employee UI: Task details

(48)

Task details view is split into two sections. The left side includes additional details about task, e.g. what it is, who is assigned, due date, priority. The right side consists of other objects in relation to this task: the workgroup it belongs to, parent task and children tasks (if any).

Figure 20.Employee UI: Customer

Customer view has a table list of customers in the system. By clicking on each item, Employee will get redirected to their detailed view.

Figure 21.Employee UI: Customer details

(49)

Customer details view consists of their information and associated tickets. Here User can update these contact details.

Figure 22.Employee UI: Ticket details

There are currently two ways to access ticket details. Firstly, by choosing Ticket view on sidebar then selecting ticket item in table. Secondly, by choosing ticket item in Customer details view. Differing from Guest dashboard, Employee dashboard allows user to see additional properties which are relevant to customer support business, e.g. severity and categorization. Right here Employee can also update these fields.

Figure 23.Manager UI: Ticket Sector

The following system objects can only be manipulated by a Manager: ticket sector, is-

(50)

sue, and user. There are also 3 views dedicated to these objects. Staff can still see these views with rendered information, but can neither create nor update any. The picture above shows the Ticket Sector view, which has a table of sector items. Each of them represents a relevant component of the service or product that the company sells to customer. Through these customized elements, Employee can categorize their tickets and determine the people who can take accountability of doing its background resolution. Its properties can be flexibly utilized according to company’s wishes. Unlike usual tag element which is just a string, a ticket sector is organized with its own properties, yet still too simplistic.

Figure 24.Manager UI: Issue

The picture above shows another kind of categorization entity: issue. As explained, an issue mainly represents question/answer pair which determines the follow-up steps of dealing with a set of similar or recurring bugs. These information focuses on the bug behaviour, how to reproduce it, and how to solve it step-by-step. The issue can prove useful means of standardizing further work process of dealing with reported bugs.

Figure 25.Manager UI: User

(51)

Finally, User view allows Manager to add a new Employee user into the system and grant them with either Staff or Manager privileges. After being added, the new Employee receives a notification email and they can use provided credentials to access the system functionalities on this web application.

3.3 Evaluation

In this section, the evaluation process and outcomes are presented. It is essential to evaluate the resultant system to examine its benefit, and relate it to the academic understanding of this topic.

3.3.1 Evaluation Process

The evaluation process takes the form of usability testing. The primary objectives of testing are to help develop more usable product and determine its contemporary usefulness. A survey was constructed to measure the usability of product. The questions of this survey are divided into three categories [37] [38]:

• Effectiveness: Measuring ability of users to complete actions using the product, and the quality of these outputs. Goal achievement and operability indicators (such as success rate, function usage) cover this aspect.

• Efficiency: Implying the resources needed to perform actions. Work rate indicators (such as speed) cover this aspect.

• Satisfaction: Illustrating subject reactions to using the system. Knowledge acquisi- tion indicators (such as learnability, memorability) cover this aspect.

To prepare for availability of test session, the system had been deployed on cloud hosting.

Each test session takes place remotely, through voice call with screen-sharing. There were five participants overall, each had to undertake the following steps:

1. They was given some basic information about the system, a cognitive walkthrough video about a small tour of system UI, instructions and test accounts.

(52)

2. They was asked to follow the instructions to experience UI and functionalities of Guest user class, then proceeding Employee’s.

3. Finally, they answered a survey on the usability of the product, with 33 quantitative and 2 qualitative questions. The former are close-ended for measurement, and the latter are open-ended for feedback.

Table 13.Quantitative values of survey answers Value Description

1 Totally disagree

2 Disagree

3 Neutral

4 Agree

5 Totally agree

As the test session starts with functionalities as Guest user, the survey also begins with questions evaluating Guest UI.

Table 14.Survey questions: Guest section

Question Effectiveness Efficiency Satisfaction Login view easy to learn and use

It is easy to submit ticket as Guest Submit Ticket view has error recognition and helps recover from error Ticket List view helps control and memorability of problems you reported to company

Ticket Details view is easy to learn and use

Ticket Details view provides sufficient level of information about interactions with CS agent

It is time-saving to report bug / request feature through ticket

Then, the next section in survey is around Employee UI.

(53)

Table 15.Survey questions: Employee section

Question Effectiveness Efficiency Satisfaction Workgroup view is easy to learn

and use

Conversation features facilitate effective communication with colleagues

Task view is easy to learn and use Task view has error recognition and helps recover from error

Customer view is easy to learn and use

Ticket List view helps control and memorability of problems your customer reported to your company Ticket List view helps control and memorability of problems your customer reported to your company Ticket Details view provides sufficient level of information about interactions with your customer It is time-saving to collaborate with customers through ticket

It is time-saving to coordinate with peers to resolve customer problems through ticket

Ticket Sector categorization is useful to determine problem’s location of interest

Ticket Sector categorization is useful to determine person/department of interest to resolve the problem Information in Ticket Sector has learnability and memorability Statistics with Ticket Sector is useful

Issue categorization is useful to determine what to do next to resolve the problem

Issue categorization saves the time of training for colleagues

Information in Issue has learnability and memorability

Statistics with Issue is useful

(54)

Finally, the last part of the survey includes general questions for participants to evaluate their experience of product use overall.

Table 16.Survey questions: General section

Question Effectiveness Efficiency Satisfaction The product solves your business

challenges

The product helps standardize work process of customer support

The product helps standardize internal coordination mechanism

The product is flexible to adapt customer support contexts of business The product supports decision- making in team’s shared objectives The product improves knowledge sharing and control

The product can save considerable amount of time during work

The product is easy to learn and use overall

3.3.2 Evaluation Results

The survey answers are taken into basic descriptive statistics to indicate levels of achievement in three usability characteristics:

Table 17.Descriptive statistics from survey answers

Participant Profile Effectiveness Efficiency Satisfaction

Mean SD Mean SD Mean SD

Participant 1 CS agent 3.63 1.38 3.20 0.84 3.56 1.67 Participant 2 Developer 4.63 0.68 4.40 1.34 4.44 0.73 Participant 3 Manager 3.89 0.74 4.00 0.00 4.22 0.67 Participant 4 Developer 3.37 0.60 3.40 0.89 3.00 0.87 Participant 5 DevOps 4.32 0.67 4.40 0.55 4.44 0.73 Participant 6 CS agent 4.47 0.61 4.40 0.55 4.33 1.00 Participant 7 CS agent 3.98 0.78 4.20 0.84 4.33 0.71

Based on both open- and close-ended answers given by participants, the following as- sumptions can be drawn:

(55)

• The product provides pretty sufficient functionalities for basic teamwork process.

Yet it brings new values to coordination mechanism. Particularly, two entities of categorization (”ticket sector” and ”issue”) are perceived as good ideas. ”Ticket sector” is quite similar to equivalent tag elements, but ”issue” is considered quite new to increase error recognition and resolution capabilities for customer support.

Therefore its flexibility is relatively high, at least on the scale of participants.

• The product allows customer to join in bug tracking process by having Guest user.

This is regarded as quite new idea to increase customer engagement in software maintenance, while most of existing tools may exclusively focus on either ticketing (highly sales-centric) or bug reporting (for internal use mostly).

• The product is pretty lightweight, quick, direct and easy to use, albeit some difficulties understanding terminology. The information included is not too sophisticated, or at least the customer is not required to submit too much details when they report an issue, and the amount of information revealed for different stakeholders is quite distinctly enough.

To draw comparison, the study collected from documents of several existing platforms and participants’ experience. Of course this prototype is primitive, and cannot be com- pared with these platforms in terms of completeness, since it lacks many features for convenient and extended use (e.g. search, filter, file sharing, chat, integrations). The following remarks distinguish how this product can be made use of in different ways than others:

• HubSpot: A platform focusing primarily on non-technical businesses, e.g. customer relationship, marketing, sales (customer deals). No categorization of tickets [39].

• Zendesk: A CRM platform, focusing on ticketing. Tickets categorized thanks to statuses mostly, have simple tags as primitive text. High subscription price [40].

• Bugzilla: A bug tracking platform with extended number of features. For internal staff-use only, rare or no immerse engagement of customer. Available categorization as custom field but not in such a flexible and organized [41].

• Redmine: A project management and issue tracking platform. For internal staff- use only, rare or no immerse engagement of customer. Available categorization as custom field but not in such a flexible and organized extent [42].

Implementing an issue tracking system to seek coordination improvements