Search Results (5)

Environmental assumptions, which are expectations about a system’s operating context, play a critical yet often underexplored role in the emergence of requirements technical debt (RTD). When these assumptions are incorrect, incomplete, or evolve over time, they can compromise the validity of system requirements and lead to costly rework in later stages of development. This paper investigates how environmental assumptions influence the identification of RTD through the analysis of a real-world case study in the domain of small uncrewed aerial systems (sUASs). A structured qualitative analysis of safety-related requirements and their associated assumptions was conducted to examine how deviations in these assumptions can introduce various forms of RTD. This work addresses a gap in the literature by explicitly focusing on the role of environmental assumptions in RTD identification. A classification framework is proposed, highlighting five distinct types of assumption-driven RTD. This framework serves as a foundation for supporting early detection of debt and improving the sustainability and resilience of software-intensive systems. Full article

In the context of increasing digitization, integrating ICT technologies, artificial intelligence, and remote working is altering residential mobility patterns and housing preferences. This study examines the housing market’s impact, focusing on how residential affordability affects residential choices, using a case study of the Metropolitan City of Florence. The analysis employs a methodology centered on the Debt-to-Income Ratio (DTI), which cross-references real estate market values (source: Agenzia delle Entrate and leading real estate portals) with household income brackets to identify affordable areas. The results reveal a clear divide: households with incomes below EUR 26,000 per year (representing about 69% of the population) are excluded from the central urban property market. This evidence confirms regional and national trends, emphasizing a growing mismatch between housing costs and disposable incomes. The study concludes that affordability is a technical–financial parameter and a valuable tool for supporting inclusive urban planning. Its application facilitates the orientation of effective public policies and the identification of socially sustainable housing solutions. Full article

Self-admitted technical debts (SATDs) refer to a solution in software development that selects suboptimal solutions to meet the current requirements and are intentionally introduced and documented by developers. SATDs in issue-tracking systems are a complement to those within source code comments. The effective identification of SATDs is crucial for software quality assurance and maintenance. Current studies focus on whether issue sections contain debt, but overlook specific SATD types. Meanwhile, they lack solutions for the challenge that SATD features are hard to learn due to the scarcity of instances containing SATDs. To address these problems, we propose a novel method, which is a weighted prompt tuning to identify SATDs, called WPTD. Specifically, WPTD employs a weighted prompt tuning to adapt the model with few-shot samples for insufficient training data. Moreover, to improve the performance of the model, WPTD constructs an SATD verbalizer by extracting keywords through mutual information and refining it with prior contextual information. Furthermore, it also improves SATD representation by extracting weights using the chi-square method and integrating them into the text. Finally, to reduce bias, WPTD computes the average score of results as final predicted distributions. We conduct comprehensive experiments on seven projects and the results show that our method significantly outperforms baseline approaches. In addition, we summarize the project-specific keywords, which can help developers better understand SATDs. Full article

This paper focuses on application of a technical debt prioritisation technique in telecommunication software managing a fleet of devices for a video surveillance system. Technical debt for this application was gathered, categorised and prioritised according to the Continuous Debt Valuation Approach (CoDVA), previously proposed by the authors. The following research question was posed: Is prioritising technical debt reduction based on CoDVA effective (i.e., executed as per plan, bringing tangible benefits)? The outbreak of COVID-19 pandemic caused unprecedented disturbance to the engineering organisations worldwide, therefore the technical debt identification phase had to be adapted to cope with a switch to forced working-from-home mode. This was achieved by applying the Wisdom of Crowds method, ensuring broad participation of engineers, and providing a fairly complete picture of the accrued technical debt. Nevertheless, the actual technical debt reduction activities did not follow exactly the expected guidelines. The three main causes of this phenomenon were discovered: continuous refactoring approach, sizing of technical debt items, and the broadened scope of refactoring activities. Therefore, as a result of this case study we propose to adopt a specific broadened definition of technical debt and follow a few rules for defining its scope and granularity. Full article

Technical debt is a well understood and used concept in IT development. The metaphor, rooted in the financial world, captures the amount of work that development teams owe to a product. Every time developers take a shortcut within development, the technical debt accumulates. Technical debt identification can be accomplished via manual reporting on the technical debt items, which is called self-admitted technical debt. Several specialised methods and tools have also emerged that promise to measure the technical debt. Based on experience in the community, the impression emerged that the measured technical debt is of a significantly different amount than the self-admitted debt. In this context, we decided to perform empirical research on the possible gap between the two. We investigated 14 production-grade software products while determining the amount of accumulated technical debt via (a) a self-admitting procedure and (b) measuring the debt. The outcomes show clearly the significant difference in the technical debt reported by the two methods. We urge development and quality-assurance teams not to rely on technical debt measurement alone. The tools demonstrated their strength in identifying low-level code technical debt items that violate a set of predefined rules. However, developers should have additional insight into violations, based on the interconnected source code and its relation to the domain and higher-level design decisions. Full article