arXiv subjects

Krzysztof Wnuk

Publications and source records attributed to Krzysztof Wnuk.

At least 19 recordsLinked to original sources

arXiv2026

Towards a Software Architecture Description for Tax Compliance

The internal reuse of software components owned by organizational units in different countries constitutes an implicit form of licensing that may be taxable under international regulations, making tax authorities an often overlooked stakeholder in software architecture. This study assesses to what extent a deliberately minimal software architecture description can make implicit cross-border licensing visible and interpretable for tax experts. We define a deliberately minimal architecture viewpoint based on components, dependencies, ownership, and jurisdiction, and construct a view for a large-scale industrial microservice software system comprising 2,518 components and 16,533 dependencies. The resulting architecture description is evaluated in a judgment study with four experienced tax auditors and tax advisors using semi-structured interviews. The results show that the software architecture description provides a structured, evidence-based starting point for identifying cross-border reuse and supports tax audit discussions. However, experts consistently report limitations, including mismatches between software engineering and legal notions of ownership, unclear jurisdictional assignments, and the perceived risk of interpreting dependency counts as indicators of economic value. These limitations persist despite detailed architectural data. We conclude that software architecture descriptions can expose structurally relevant reuse relationships but cannot, on their own, support the legally meaningful interpretations required for tax assessment, indicating a fundamental mismatch between architectural abstractions and taxation concepts.

cs.SE↗

arXiv2026

Empirical Evaluation of Taxonomic Trace Links: A Case Study

Context: Traceability is a key quality attribute of artifacts that are used in knowledge-intensive tasks and supports software engineers in producing higher-quality software. Despite its clear benefits, traceability is often neglected in practice due to challenges such as granularity of traces, lack of a common artifact structure, and unclear responsibility. The Taxonomic Trace Links (TTL) approach connects source and target artifacts through a domain-specific taxonomy, aiming to address these common traceability challenges. Objective: In this study, we empirically evaluate TTL in an industrial setting to identify its strengths and weaknesses for real-world adoption. Method: We conducted a mixed-methods study at Ericsson involving one of its software products. Quantitative and qualitative data were collected across two traceability use cases. We established trace links between 463 business use cases, 64 test cases, and 277 ISO-standard requirements. Additionally, we held three focus group sessions with practitioners. Results: We identified two practically relevant scenarios where traceability is required and evaluated TTL in each. Overall, practitioners found TTL to be a useful solution for one of the scenarios, while less useful for the other. However, developing a domain-specific taxonomy and managing heterogeneous artifact structures were noted as significant challenges. Moreover, the precision of the classifier that is used to create trace links needs to be improved to make the solution practical. Conclusion: TTL is a promising approach that can be adopted in practice and enables traceability use cases. However, TTL is not a replacement for traditional trace links, but rather complements them to enable more traceability use cases and encourage the early creation of trace links.

cs.SE↗

arXiv2025

Reducing Friction in Cloud Migration of Services

Public cloud services are integral to modern software development, offering scalability and flexibility to organizations. Based on customer requests, a large product development organization considered migrating the microservice-based product deployments of a large customer to a public cloud provider. We conducted an exploratory single-case study, utilizing quantitative and qualitative data analysis to understand how and why deployment costs would change when transitioning the product from a private to a public cloud environment while preserving the software architecture. We also isolated the major factors driving the changes in deployment costs. We found that switching to the customer-chosen public cloud provider would increase costs by up to 50\%, even when sharing some resources between deployments, and limiting the use of expensive cloud services such as security log analyzers. A large part of the cost was related to the sizing and license costs of the existing relational database, which was running on Virtual Machines in the cloud. We also found that existing system integrators, using the product via its API, were likely to use the product inefficiently, in many cases causing at least 10\% more load to the system than needed. From a deployment cost perspective, successful migration to a public cloud requires considering the entire system architecture, including services like relational databases, value-added cloud services, and enabled product features. Our study highlights the importance of leveraging end-to-end usage data to assess and manage these cost drivers effectively, especially in environments with elastic costs, such as public cloud deployments.

cs.SE↗

arXiv2025

Taxonomic Trace Links: Rethinking Traceability and its Benefits

Traceability greatly supports knowledge-intensive tasks, e.g., coverage check and impact analysis. Despite its clear benefits, the \emph{practical} implementation of traceability poses significant challenges, leading to a reduced focus on the creation and maintenance of trace links. We propose a new approach -- Taxonomic Trace Links (TTL) -- which rethinks traceability and its benefits. With TTL, trace links are created indirectly through a domain-specific taxonomy, a simplified version of a domain model. TTL has the potential to address key traceability challenges, such as the granularity of trace links, the lack of a common data structure among software development artifacts, and unclear responsibility for traceability. We explain how TTL addresses these challenges and perform an initial validation with practitioners. We identified six challenges associated with TTL implementation that need to be addressed. Finally, we propose a research roadmap to further develop and evaluate the technical solution of TTL. TTL appears to be particularly feasible in practice where a domain taxonomy is already established

cs.SE↗

arXiv2025

Challenges of Requirements Communication and Digital Assets Verification in Infrastructure Projects

Background: Poor communication of requirements between clients and suppliers contributes to project overruns,in both software and infrastructure projects. Existing literature offers limited insights into the communication challenges at this interface. Aim: Our research aim to explore the processes and associated challenges with requirements activities that include client-supplier interaction and communication. Method: we study requirements validation, communication, and digital asset verification processes through two case studies in the road and railway sectors, involving interviews with ten experts across three companies. Results: We identify 13 challenges, along with their causes and consequences, and suggest solution areas from existing literature. Conclusion: Interestingly, the challenges in infrastructure projects mirror those found in software engineering, highlighting a need for further research to validate potential solutions.

cs.SE↗

arXiv2025

Auxiliary Artifacts in Requirements Traceability: A Systematic Mapping Study

Background: Traceability between software artifacts enhances the value of the information those artifacts contain, but only when the links themselves are reliable. Link quality is known to depend on explicit factors such as the traced artifacts and the expertise of the practitioner who judges each connection. Other factors, however, remain largely unexplored. We contend that one of these factors is the set of auxiliary artifacts -- artifacts that are produced and/or used during the tracing process yet are neither the source nor target artifacts. Because such auxiliary artifacts can subtly steer how links are created and validated, they merit a literature survey to identify these artifacts and further investigate them. Objective: We identify and map auxiliary artifacts used in requirements tracing, which could be additional factors that affect the quality of the trace links. Method: We conducted a systematic mapping study on auxiliary artifacts in requirements traceability. Results: We found 110 studies in which auxiliary artifacts are used in requirements tracing, and identified 49 auxiliary artifacts, and 13 usage scenarios. Conclusion: This study provides a systematic mapping of auxiliary artifacts in requirement tracing, including their usage, origin, type and tool support. The use of auxiliary artifacts in requirements tracing seems to be the norm, thus, these artifacts should be studied in depth to identify how they effect the quality of traced links.

cs.SE↗

arXiv2025

Language Models to Support Multi-Label Classification of Industrial Data

Multi-label requirements classification is a challenging task, especially when dealing with numerous classes at varying levels of abstraction. The difficulties increases when a limited number of requirements is available to train a supervised classifier. Zero-shot learning (ZSL) does not require training data and can potentially address this problem. This paper investigates the performance of zero-shot classifiers (ZSCs) on a multi-label industrial dataset. We focuse on classifying requirements according to a taxonomy designed to support requirements tracing. We compare multiple variants of ZSCs using different embeddings, including 9 language models (LMs) with a reduced number of parameters (up to 3B), e.g., BERT, and 5 large LMs (LLMs) with a large number of parameters (up to 70B), e.g., Llama. Our ground truth includes 377 requirements and 1968 labels from 6 output spaces. For the evaluation, we adopt traditional metrics, i.e., precision, recall, F1, and $F_β$, as well as a novel label distance metric Dn. This aims to better capture the classification's hierarchical nature and provides a more nuanced evaluation of how far the results are from the ground truth. 1) The top-performing model on 5 out of 6 output spaces is T5-xl, with maximum $F_β$ = 0.78 and Dn = 0.04, while BERT base outperformed the other models in one case, with maximum $F_β$ = 0.83 and Dn = 0.04. 2) LMs with smaller parameter size produce the best classification results compared to LLMs. Thus, addressing the problem in practice is feasible as limited computing power is needed. 3) The model architecture (autoencoding, autoregression, and sentence-to-sentence) significantly affects the classifier's performance. We conclude that using ZSL for multi-label requirements classification offers promising results. We also present a novel metric that can be used to select the top-performing model for this problem

cs.SE↗

arXiv2025

Multi-Label Requirements Classification with Large Taxonomies

Classification aids software development activities by organizing requirements in classes for easier access and retrieval. The majority of requirements classification research has, so far, focused on binary or multi-class classification. Multi-label classification with large taxonomies could aid requirements traceability but is prohibitively costly with supervised training. Hence, we investigate zero-short learning to evaluate the feasibility of multi-label requirements classification with large taxonomies. We associated, together with domain experts from the industry, 129 requirements with 769 labels from taxonomies ranging between 250 and 1183 classes. Then, we conducted a controlled experiment to study the impact of the type of classifier, the hierarchy, and the structural characteristics of taxonomies on the classification performance. The results show that: (1) The sentence-based classifier had a significantly higher recall compared to the word-based classifier; however, the precision and F1-score did not improve significantly. (2) The hierarchical classification strategy did not always improve the performance of requirements classification. (3) The total and leaf nodes of the taxonomies have a strong negative correlation with the recall of the hierarchical sentence-based classifier. We investigate the problem of multi-label requirements classification with large taxonomies, illustrate a systematic process to create a ground truth involving industry participants, and provide an analysis of different classification pipelines using zero-shot learning.

cs.SE↗

arXiv2024

Governing the Commons: Code Ownership and Code-Clones in Large-Scale Software Development

Context: In software development organizations employing weak or collective ownership, different teams are allowed and expected to autonomously perform changes in various components. This creates diversity both in the knowledge of, and in the responsibility for, individual components. Objective: Our objective is to understand how and why different teams introduce technical debt in the form of code clones as they change different components. Method: We collected data about change size and clone introductions made by ten teams in eight components which was part of a large industrial software system. We then designed a Multi-Level Generalized Linear Model (MLGLM), to illustrate the teams' differing behavior. Finally, we discussed the results with three development teams, plus line manager and the architect team, evaluating whether the model inferences aligned with what they expected. Responses were recorded and thematically coded. Results: The results show that teams do behave differently in different components, and the feedback from the teams indicates that this method of illustrating team behavior can be useful as a complement to traditional summary statistics of ownership. Conclusions: We find that our model-based approach produces useful visualizations of team introductions of code clones as they change different components. Practitioners stated that the visualizations gave them insights that were useful, and by comparing with an average team, inter-team comparisons can be avoided. Thus, this has the potential to be a useful feedback tool for teams in software development organizations that employ weak or collective ownership.

cs.SE↗

arXiv2024

The Upper Bound of Information Diffusion in Code Review

Background: Code review, the discussion around a code change among humans, forms a communication network that enables its participants to exchange and spread information. Although reported by qualitative studies, our understanding of the capability of code review as a communication network is still limited. Objective: In this article, we report on a first step towards evaluating the capability of code review as a communication network by quantifying how fast and how far information can spread through code review: the upper bound of information diffusion in code review. Method: In an in-silico experiment, we simulate an artificial information diffusion within large (Microsoft), mid-sized (Spotify), and small code review systems (Trivago) modelled as communication networks. We then measure the minimal topological and temporal distances between the participants to quantify how far and how fast information can spread in code review. Results: An average code review participants in the small and mid-sized code review systems can spread information to between 72% and 85% of all code review participants within four weeks independently of network size and tooling; for the large code review systems, we found an absolute boundary of about 11000 reachable participants. On average (median), information can spread between two participants in code review in less than five hops and less than five days. Conclusion: We found evidence that the communication network emerging from code review scales well and spreads information fast and broadly, corroborating the findings of prior qualitative work. The study lays the foundation for understanding and improving code review as a communication network.

cs.SE↗

arXiv2024

Towards identifying and minimizing customer-facing documentation debt

Software documentation often struggles to catch up with the pace of software evolution. The lack of correct, complete, and up-to-date documentation results in an increasing number of documentation defects which could introduce delays in integrating software systems. In our previous study on a bug analysis tool called MultiDimEr, we provided evidence that documentation-related defects contribute to many bug reports. First, we want to identify documentation defect types contributing to documentation defects, thereby identifying documentation debt. Secondly, we aim to find pragmatic solutions to minimize most common documentation defects to pay off the documentation debt in the long run. We investigated documentation defects related to an industrial software system. First, we looked at different documentation types and associated bug reports. We categorized the defects according to an existing documentation defect taxonomy. Based on a sample of 101 defects, we found that most defects are caused by documentation defects falling into the Information Content (What) category (86). Within this category, the documentation defect types Erroneous code examples (23), Missing documentation (35), and Outdated content (19) contributed to most of the documentation defects. We propose to adapt two solutions to mitigate these types of documentation defects. In practice, documentation debt can easily go undetected since a large share of resources and focus is dedicated to delivering high-quality software. We suggest adapting two main solutions to tackle documentation debt by implementing (i) Dynamic Documentation Generation (DDG) and/or (ii) Automated Documentation Testing (ADT), which are both based on defining a single and robust information source for documentation.

cs.SE↗

arXiv2024

MultiDimEr: a multi-dimensional bug analyzEr

Background: Bugs and bug management consumes a significant amount of time and effort from software development organizations. A reduction in bugs can significantly improve the capacity for new feature development. Aims: We categorize and visualize dimensions of bug reports to identify accruing technical debt. This evidence can serve practitioners and decision makers not only as an argumentative basis for steering improvement efforts, but also as a starting point for root cause analysis, reducing overall bug inflow. Method: We implemented a tool, MultiDimEr, that analyzes and visualizes bug reports. The tool was implemented and evaluated at Ericsson. Results: We present our preliminary findings using the MultiDimEr for bug analysis, where we successfully identified components generating most of the bugs and bug trends within certain components. Conclusions: By analyzing the dimensions provided by MultiDimEr, we show that classifying and visualizing bug reports in different dimensions can stimulate discussions around bug hot spots as well as validating the accuracy of manually entered bug report attributes used in technical debt measurements such as fault slip through.

cs.SE↗

arXiv2023

Taxing Collaborative Software Engineering

The engineering of complex software systems is often the result of a highly collaborative effort. However, collaboration within a multinational enterprise has an overlooked legal implication when developers collaborate across national borders: It is taxable. In this article, we discuss the unsolved problem of taxing collaborative software engineering across borders. We (1) introduce the reader to the basic principle of international taxation, (2) identify three main challenges for taxing collaborative software engineering making it a software engineering problem, and (3) estimate the industrial significance of cross-border collaboration in modern software engineering by measuring cross-border code reviews at a multinational software company.

cs.SE↗

arXiv2023

A Method for Identification and Ranking of Requirements Sources

Requirements engineering (RE) literature acknowledges the importance of early stakeholder identification. The sources of requirements are many and also constantly changing as the market and business constantly change. Identifying and consulting all stakeholders on the market is impractical; thus many companies utilize indirect data sources, e.g. documents and representatives of larger groups of stakeholders. However, companies often collect irrelevant data or develop their products based on the sub-optimal information sources that may lead to missing market opportunities. We propose a collaborative method for identification and selection of data sources. The method consists of four steps and aims to build consensus between different perspectives in an organization. We demonstrate the use of the method with three industrial case studies. We have presented and statically validated the method to support prioritization of stakeholders for MDRE. Our results show that the method can support the identification and selection of data sources in three ways: (1) by providing systematic steps to identify and prioritize data sources for RE, (2) by highlighting and resolving discrepancies between different perspectives in an organization, and (3) by analyzing the underlying rationale for using certain data sources.

cs.SE↗

arXiv2023

Monitoring and Maintenance of Telecommunication Systems: Challenges and Research Perspectives

In this paper, we present challenges associated with monitoring and maintaining a large telecom system at Ericsson that was developed with high degree of component reuse. The system constitutes of multiple services, composed of both legacy and modern systems that are constantly changing and need to be adapted to changing business needs. The paper is based on firsthand experience from architecting, developing and maintaining such a system, pointing out current challenges and potential avenues for future research that might contribute to addressing them.

cs.SE↗

arXiv2022

Only Time Will Tell: Modelling Information Diffusion in Code Review with Time-Varying Hypergraphs

Background: Modern code review is expected to facilitate knowledge sharing: All relevant information, the collective expertise, and meta-information around the code change and its context become evident, transparent, and explicit in the corresponding code review discussion. The discussion participants can leverage this information in the following code reviews; the information diffuses through the communication network that emerges from code review. Traditional time-aggregated graphs fall short in rendering information diffusion as those models ignore the temporal order of the information exchange: Information can only be passed on if it is available in the first place. Aim: This manuscript presents a novel model based on time-varying hypergraphs for rendering information diffusion that overcomes the inherent limitations of traditional, time-aggregated graph-based models. Method: In an in-silico experiment, we simulate an information diffusion within the internal code review at Microsoft and show the empirical impact of time on a key characteristic of information diffusion: the number of reachable participants. Results: Time-aggregation significantly overestimates the paths of information diffusion available in communication networks and, thus, is neither precise nor accurate for modelling and measuring the spread of information within communication networks that emerge from code review. Conclusion: Our model overcomes the inherent limitations of traditional, static or time-aggregated, graph-based communication models and sheds the first light on information diffusion through code review. We believe that our model can serve as a foundation for understanding, measuring, managing, and improving knowledge sharing in code review in particular and information diffusion in software engineering in general.

cs.SE↗

arXiv2022

Open innovation using open source tools: a case study at Sony Mobile

Despite growing interest of Open Innovation (OI) in Software Engineering (SE), little is known about what triggers software organizations to adopt it and how this affects SE practices. OI can be realized in numerous of ways, including Open Source Software (OSS) involvement. Outcomes from OI are not restricted to product innovation but also include process innovation, e.g. improved SE practices and methods. This study explores the involvement of a software organization (Sony Mobile) in OSS communities from an OI perspective and what SE practices (requirements engineering and testing) have been adapted in relation to OI. It also highlights the innovative outcomes resulting from OI. An exploratory embedded case study investigates how Sony Mobile use and contribute to Jenkins and Gerrit; the two central OSS tools in their continuous integration tool chain. Quantitative analysis was performed on change log data from source code repositories in order to identify the top contributors and triangulated with the results from five semi-structured interviews to explore the nature of the commits. The findings of the case study include five major themes: i) The process of opening up towards the tool communities correlates in time with a general adoption of OSS in the organization. ii) Assets not seen as competitive advantage nor a source of revenue are made open to OSS communities, and gradually, the organization turns more open. iii) The requirements engineering process towards the community is informal and based on engagement. iv) The need for systematic and automated testing is still in its infancy, but the needs are identified. v) The innovation outcomes included free features and maintenance, and were believed to increase speed and quality in development. Adopting OI was a result of a paradigm shift of moving from Windows to Linux.

cs.SE↗

arXiv2022

Requirements Analysis and Management for Benefiting Openness

Requirements Engineering has recently been greatly influenced by the way how firms use Open Source Software (OSS) and Software Ecosystems (SECOs) as a part of their product development and business models. This is further emphasized by the paradigm of Open Innovation, which highlights how firms should strive to use both internal and external resources to advance their internal innovation and technology capabilities. The evolution from market-driven requirements engineering and management processes, has reshaped the understanding of what a requirement is, and how it is documented and used. In this work, we suggest a model for analyzing and managing requirements that is designed in the context of OSS and SECOs, including the advances and challenges that it brings. The model clarifies how the main stages of requirements engineering and management processes can be adjusted to benefit from the openness that the new context offers. We believe that the model is a first step towards the inevitable adaptation of requirements engineering to an open and informal arena, where processes and collaboration are decentralized, transparency and governance are the key success factors.

cs.SE↗