BZPEERPapers, people, evidence and research paths
Menu

Discover

SearchFind papers, people, topics, institutions and opportunities from one place.GraphSee how papers, authors, topics and evidence connect.

Research tools

HomeContinue from the papers, people and topics that matter now.CollectionsTurn saved papers into reading lists, evidence maps and shareable context.ResearchReconstruct the path that led you from search to paper to question.CollaborationMove from a paper, topic or expert request into a focused thread.PublishCreate full-text research articles with metadata, formulas and versions.

Network

ExpertsFind specialists whose work and reviews explain why they can help.CommunitiesJoin research groups organized around papers, topics and shared evidence.

Opportunities

ListingsBrowse roles, calls and collaborations connected to real research context.

Account

Log inReturn to your saved papers, graph views and active threads.Create accountStart saving papers, building a research trail and joining teams.
Log inCreate account

Source author record

Daniela Damian

Daniela Damian appears in the imported research catalog. Authorship, coauthor and topic links are available while profile ownership is still unclaimed.

ResearcherUnclaimed source record
Software EngineeringSocial and Information Networks

Catalog footprint

What is connected

6works
2topics
4close collaborators

Actions

Connect this record

Log in to claim
Open graphBrowse works

Research graph

See the researcher in context

Open full explorer

Inspect adjacent papers, topics, institutions and collaborators without losing the researcher page.

Building this map preview

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

6 published item(s)

preprint2022arXiv

A Case Study of Building Shared Understanding of Non-Functional Requirements in a Remote Software Organization

Building a shared understanding of non-functional requirements (NFRs) is a known but understudied challenge in requirements engineering, especially in organizations that adopt continuous software engineering (CSE) practices. During the peak of the COVID-19 pandemic, many CSE organizations complied with working remotely due to the imposed health restrictions; some continued to work remotely while implementing business processes to facilitate team communication and productivity. In remote CSE organizations, managing NFRs becomes more challenging due to the limitations to team communication coupled with the incentive to deliver products quickly. While previous research has identified the factors that lead to a lack of shared understanding of NFRs in CSE, we still have a significant gap in understanding how CSE organizations, particularly in remote work, build a shared understanding of NFRs in their software development. We conduct a three-month ethnography-informed case study of a remote CSE organization. Through thematic analysis of our qualitative data from interviews and observations, we identify a number of practices in developing a shared understanding of NFRs. The collaborative workspace the organization uses for remote interaction is Gather, which simulates physical workspaces, and which our findings suggest allows for informal communications instrumental for building shared understanding. As actionable insights, we discuss our findings in light of proactive practices that represent opportunities for software organizations to invest in building a shared understanding of NFRs in their development.

0 citations0 reviewsNo code linkedOpen access
preprint2022arXiv

A Community Strategy Framework -- How to obtain Influence on Requirements in Meritocratic Open Source Software Communities?

Context: In the Requirements Engineering (RE) process of an Open Source Software (OSS) community, an involved firm is a stakeholder among many. Conflicting agendas may create miss-alignment with the firm's internal requirements strategy. In communities with meritocratic governance or with aspects thereof, a firm has the opportunity to affect the RE process in line with their own agenda by gaining influence through active and symbiotic engagements. Objective: The focus of this study has been to identify what aspects that firms should consider when they assess their need of influencing the RE process in an OSS community, as well as what engagement practices that should be considered in order to gain this influence. Method: Using a design science approach, 21 interviews with 18 industry professionals from 12 different software-intensive firms were conducted to explore, design and validate an artifact for the problem context. Results: A Community Strategy Framework (CSF) is presented to help firms create community strategies that describe if and why they need influence on the RE process in a specific (meritocratic) OSS community, and how the firm could gain it. The framework consists of aspects and engagement practices. The aspects help determine how important an OSS project and its community is from business and technical perspectives. A community perspective is used when considering the feasibility and potential in gaining influence. The engagement practices are intended as a tool-box for how a firm can engage with a community in order to build influence needed. Conclusion: It is concluded from interview-based validation that the proposed CSF may provide support for firms in creating and tailoring community strategies and help them to focus resources on communities that matter and gain the influence needed on their respective RE processes.

0 citations0 reviewsNo code linkedOpen access
preprint2022arXiv

A method for analyzing stakeholders' influence on an open source software ecosystem's requirements engineering process

For a firm in an open source software (OSS) ecosystem, the requirements engineering (RE) process is rather multifaceted. Apart from its typical RE process, there is a competing process, external to the firm and inherent to the firm's ecosystem. When trying to impose an agenda in competition with other firms, and aiming to align internal product planning with the ecosystem's RE process, firms need to consider who and how influential the other stakeholders are, and what their agendas are. The aim of the presented research is to help firms identify and analyze stakeholders in OSS ecosystems, in terms of their influence and interactions, to create awareness of their agendas, their collaborators, and how they invest their resources. To arrive at a solution artifact, we applied a design science research approach where we base artifact design on the literature and earlier work. A stakeholder influence analysis (SIA) method is proposed and demonstrated in terms of applicability and utility through a case study on the Apache Hadoop OSS ecosystem. SIA uses social network constructs to measure the stakeholders' influence and interactions and considers the special characteristics of OSS RE to help firms structure their stakeholder analysis processes in relation to an OSS ecosystem. SIA adds a strategic aspect to the stakeholder analysis process by addressing the concepts of influence and interactions, which are important to consider while acting in collaborative and meritocratic RE cultures of OSS ecosystems.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2013arXiv

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.

0 citations0 reviewsNo code linkedOpen access