arXiv subjects

Daniela Damian

Publications and source records attributed to Daniela Damian.

25 records · Page 2Linked to original sources

arXiv2020

The Lack of Shared Understanding of Non-Functional Requirements in Continuous Software Engineering: Accidental or Essential?

Building shared understanding of requirements is key to ensuring downstream software activities are efficient and effective. However, in continuous software engineering (CSE) some lack of shared understanding is an expected, and essential, part of a rapid feedback learning cycle. At the same time, there is a key trade-off with avoidable costs, such as rework, that come from accidental gaps in shared understanding. This trade-off is even more challenging for non-functional requirements (NFRs), which have significant implications for product success. Comprehending and managing NFRs is especially difficult in small, agile organizations. How such organizations manage shared understanding of NFRs in CSE is understudied. We conducted a case study of three small organizations scaling up CSE to further understand and identify factors that contribute to lack of shared understanding of NFRs, and its relationship to rework. Our in-depth analysis identified 41 NFR-related software tasks as rework due to a lack of shared understanding of NFRs. Of these 41 tasks 78% were due to avoidable (accidental) lack of shared understanding of NFRs. Using a mixed-methods approach we identify factors that contribute to lack of shared understanding of NFRs, such as the lack of domain knowledge, rapid pace of change, and cross-organizational communication problems. We also identify recommended strategies to mitigate lack of shared understanding through more effective management of requirements knowledge in such organizations. We conclude by discussing the complex relationship between shared understanding of requirements, rework and, CSE.

cs.SE↗

arXiv2020

GDPR Compliance in the Context of Continuous Integration

The enactment of the General Data Protection Regulation (GDPR) in 2018 forced any organization that collects and/or processes EU-based personal data to comply with stringent privacy regulations. Software organizations have struggled to achieve GDPR compliance both before and after the GDPR deadline. While some studies have relied on surveys or interviews to find general implications of the GDPR, there is a lack of in-depth studies that investigate compliance practices and compliance challenges of software organizations. In particular, there is no information on small and medium enterprises (SMEs), which represent the majority of organizations in the EU, nor on organizations that practice continuous integration. Using design science methodology, we conducted an in-depth study over the span of 20 months regarding GDPR compliance practices and challenges in collaboration with a small, startup organization. We first identified our collaborator's business problems and then iteratively developed two artifacts to address those problems: a set of operationalized GDPR principles, and an automated GDPR tool that tests those GDPR-derived privacy requirements. This design science approach resulted in four implications for research and for practice. For example, our research reveals that GDPR regulations can be partially operationalized and tested through automated means, which improves compliance practices, but more research is needed to create more efficient and effective means to disseminate and manage GDPR knowledge among software developers.

cs.SE↗

arXiv2019

ECrits - Visualizing Support Ticket Escalation Risk

Managing support tickets in large, multi-product organizations is difficult. Failure to meet the expectations of customers can lead to the escalation of support tickets, which is costly for IBM in terms of customer relationships and resources spent addressing the escalation. Keeping the customer happy is an important task in requirements engineering, which often comes in the form of handling their problems brought forth in support tickets. Proper attention to customers, their issues, and the bottom-up requirements that surface through bug reports can be difficult when the support process involves spending a lot of time managing customers to prevent escalations. For any given support analyst, understanding the customer is achievable through time spent looking through past and present support tickets within their organization; however, this solution does not scale up to account for all support tickets across all product teams. ECrits is a tool developed to help mitigate information overload by selectively mining customer information from support ticket repositories, displaying that data to support analysts, and doing predictive modelling on that data to suggest which support tickets are likely to escalate.

cs.SE↗

arXiv2019

Towards a Live Anonymous Question Queue To Address Student Apprehension

In today's university climate many first and second year classes have over a hundred students. Large classrooms make some students apprehensive about asking questions. An anonymous method of submitting questions to an instructor would allow students to ask their questions without feeling apprehensive. In this paper we propose a Live Anonymous Question Queue (LAQQ), a system that facilitates anonymous question submissions in real time to mitigate student apprehension, increase student participation, and provide real-time feedback to the instructor. To study the necessary features of an LAQQ, we conducted a study of a system, namely Google Moderator, which best approached our concept of an LAQQ. We deployed Google moderator in large lectures and studied its support of a number of features that we envisioned for an LAQQ. Through our class observations, interviews with instructors, and surveys with the students, our results suggest that an LAQQ system must provide support for: notification of question submission to provide awareness for the instructor, and context for questions to allow an instructor to easily answer a question. Additionally our results suggest that an LAQQ system must be accessible and usable on multiple platforms. Finally our results suggest that in order to be successful in the classroom an LAQQ system must be fully adopted by the instructor and the classroom organizational structure must change to accommodate the use of the LAQQ.

cs.CY↗

arXiv2019

What do Support Analysts Know about Their Customers? On the Study and Prediction of Support Ticket Escalations in Large Software Organizations

Understanding and keeping the customer happy is a central tenet of requirements engineering. Strategies to gather, analyze, and negotiate requirements are complemented by efforts to manage customer input after products have been deployed. For the latter, support tickets are key in allowing customers to submit their issues, bug reports, and feature requests. Whenever insufficient attention is given to support issues, however, their escalation to management is time-consuming and expensive, especially for large organizations managing hundreds of customers and thousands of support tickets. Our work provides a step towards simplifying the job of support analysts and managers, particularly in predicting the risk of escalating support tickets. In a field study at our large industrial partner, IBM, we used a design science methodology to characterize the support process and data available to IBM analysts in managing escalations. Through iterative cycles of design and evaluation, we translated our understanding of support analysts' expert knowledge of their customers into features of a support ticket model to be implemented into a Machine Learning model to predict support ticket escalations. We trained and evaluated our Machine Learning model on over 2.5 million support tickets and 10,000 escalations, obtaining a recall of 79.9% and an 80.8% reduction in the workload for support analysts looking to identify support tickets at risk of escalation. Further on-site evaluations, through a prototype tool we developed to implement our Machine Learning techniques in practice, showed more efficient weekly support-ticket-management meetings. The features we developed in the Support Ticket Model are designed to serve as a starting place for organizations interested in implementing our model to predict support ticket escalations, and for future researchers to build on to advance research in ...

cs.SE↗

arXiv2018

SACRE: Supporting contextual requirements' adaptation in modern self-adaptive systems in the presence of uncertainty at runtime

Runtime uncertainty such as unpredictable resource unavailability, changing environmental conditions and user needs, as well as system intrusions or faults represents one of the main current challenges of self-adaptive systems. Moreover, today's systems are increasingly more complex, distributed, decentralized, etc. and therefore have to reason about and cope with more and more unpredictable events. Approaches to deal with such changing requirements in complex today's systems are still missing. This work presents SACRE (Smart Adaptation through Contextual REquirements), our approach leveraging an adaptation feedback loop to detect self-adaptive systems' contextual requirements affected by uncertainty and to integrate machine learning techniques to determine the best operationalization of context based on sensed data at runtime. SACRE is a step forward of our former approach ACon which focus had been on adapting the context in contextual requirements, as well as their basic implementation. SACRE primarily focuses on architectural decisions, addressing self-adaptive systems' engineering challenges. Furthering the work on ACon, in this paper, we perform an evaluation of the entire approach in different uncertainty scenarios in real-time in the extremely demanding domain of smart vehicles. The real-time evaluation is conducted in a simulated environment in which the smart vehicle is implemented through software components. The evaluation results provide empirical evidence about the applicability of SACRE in real and complex software system domains.

cs.SE↗

arXiv2013

Communication Practices in a Distributed Scrum Project

While global software development (GSD) projects face cultural and time differences, the biggest challenge is communication. We studied a distributed student project with an industrial customer. The project lasted 3 months, involved 25 participants, and was distributed between the University of Victoria, Canada and Aalto University, Finland. We analyzed email communication, version control system (VCS) data, and surveys on satisfaction. Our aim was to find out whether reflecting on communication affected it, if standups influenced when developers committed to the VCS repository, and if leaders emerged in the three distributed Scrum teams. Initially students sent on average 21 emails per day. With the reduction to 16 emails, satisfaction with communication increased. By comparing Scrum standup times and VCS activity we found that the live communication of standups activated people to work on the project. Out of the three teams, one had an emergent communication facilitator.

cs.SE↗