Predicting the Vector Impact of Change - An Industrial Case Study at Brightsquid

Kabeer, Shaikh Jeeshan; Nayebi, Maleknaz; Ruhe, Guenther; Carlson, Chris; Chew, Francis

doi:10.1109/esem.2017.20

Cited by 5 publications

(2 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The company is facing the typical problem of software start-ups: The need to quickly enter a competitive market with innovative product ideas while having the goal of short-term revenue generation by satisfying current users and their expectations. At the same time, the company is facing the demand of enlarging their customer base [17].…”

Section: Context and Motivation: User Request Management At Brightsquidmentioning

confidence: 99%

ESSMArT way to manage customer requests

et al. 2019

Self Cite

View full text Add to dashboard Cite

Quality and market acceptance of software products is strongly influenced by responsiveness to user requests. Once a request is received from a customer, decisions need to be made if the request should be escalated to the development team. Once escalated, the ticket must be formulated as a development task and be assigned to a developer. To make the process more efficient and reduce the time between receiving and escalating the user request, we aim to automate of the complete user request management process. We propose a holistic method called ESSMArT. The methods performs text summarization, predicts ticket escalation, creates the title and content of the ticket used by developers, and assigns the ticket to an available developer. We internally evaluated the method by 4,114 user tickets from Brightsquid and their secure health care communication platform Secure-Mail. We also perform an external evaluation on the usefulness of the approach. We found that supervised learning based on context specific data performs best for extractive summarization. For predicting escalation of tickets, Random Forest trained on a combination of conversation and extractive summarization is best with highest precision (of 0.9) and recall (of 0.55). From external evaluation we found that ESSMArT provides suggestions that are 71% aligned with human ones. Applying the prototype implementation to 315 user requests

show abstract

Section: Context and Motivation: User Request Management At Brightsquidmentioning

confidence: 99%

ESSMArT way to manage customer requests

et al. 2019

Self Cite

View full text Add to dashboard Cite

show abstract

“…The company is facing the typical problem of software start-ups: they need to quickly enter a competitive market with innovative product ideas to produce revenue in the near-term; simply put they need to satisfy current users and their expectations. At the same time, the company is facing the demands of growing their customer base and satisfying their requirements [8]. As Brightsquid's product manager puts it: "The job of the start-up is to find a sustainable business model-in other words, to discover an important and urgent problem, that a defined and accessible segment of customers will pay for to have solved.…”

Section: Introductionmentioning

confidence: 99%

A Longitudinal Study of Identifying and Paying Down Architecture Debt

Nayebi

Cai

Kazman

et al. 2019

2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)

Self Cite

View full text Add to dashboard Cite

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-anddirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.

show abstract