Search

Agile methodologies have emerged as transformative paradigms in the ever-evolving software development landscape, emphasizing iterative development, customer collaboration, and adaptability. As the scope and complexity of projects and organizations expand, applying agile principles within the context of Large-Scale Agile Development (LSAD) encounters distinctive challenges. The majority of challenges encountered in LSAD, technical and non-technical, are attributed to the accrual of social debt. However, a conspicuous gap remains in understanding and addressing social debt in LSAD. This study aims to fill this void by investigating social debt in LSAD through an in-depth industrial case study with a leading Nordic company specializing in telecommunications software and services and focusing on producing secure 5G network solutions. The study investigates the causes of LSAD's social debt and examines its impacts on secure 5G telecom software development. By addressing these objectives, this research sheds light on a critical aspect of LSAD's social debt, caused by 3C challenges(communication, coordination and collaboration), social confines challenges, community smells challenges, and organisational social challenges in the telecom sector that have been underrepresented in the existing literature. [ABSTRACT FROM AUTHOR]

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. [ABSTRACT FROM AUTHOR]

The winter storm of late 2022 caused difficulties for many US-based airlines, but none more so than Southwest Airlines. Like other airlines, Southwest canceled flights in the early stages of the storm. Their attempted recoveries failed due to procedural and technology issues. The airline was unable to cope with the magnitude of canceled flights, aircraft and crews in the wrong places, disrupted passenger plans, and luggage separated from its owners. Over the next several days, Southwest canceled tens of thousands of flights, called in thousands of additional staff to support manual operations, and flew a reduced schedule for a time before returning to normal operations. The case provides numerous scenarios for you to analyze and research, to strengthen your understanding of the underlying concepts. [ABSTRACT FROM AUTHOR]

Context. Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims. To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method. We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results. Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion. This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study. [ABSTRACT FROM AUTHOR]

Technical Debt Management (TDM) can suffer from unpredictability, communication gaps and the inaccessibility of relevant information, which hamper the effectiveness of its decision making. These issues can stem from division among decision-makers which takes root in unfair consequences of decisions among different decision-makers. One mitigation route is Skin in the Game thinking, which enforces transparency, fairness and shared responsibility during collective decision-making under uncertainty. This article illustrates characteristics which require Skin in the Game thinking in Technical Debt (TD) identification, measurement, prioritisation and monitoring. We point out crucial problems in TD monitoring rooted in asymmetric information and asymmetric payoff between different factions of decision-makers. A systematic TD monitoring method is presented to mitigate the said problems. The method leverages Replicator Dynamics and Behavioural Learning. The method supports decision-makers with automated TD monitoring decisions; it informs decision-makers when human interventions are required. Two publicly available industrial projects with a non-trivial number of TD and timestamps are utilised to evaluate the application of our method. Mann–Whitney U hypothesis tests are conducted on samples of decisions from our method and the baseline. The statistical evidence indicates that our method can produce cost-effective and contextual TD monitoring decisions. [ABSTRACT FROM AUTHOR]

Organizations replace their legacy systems for technical, economic, and operational reasons. Replacement is a risky proposition, as high levels of technical and social inertia make these systems hard to withdraw. Failure to fully replace systems results in complex system architectures involving manifold hidden dependencies that carry technical debt. To understand how a process for replacing a complex legacy system unfolds and accumulates technical debt, we conducted an explanatory case study at a local manufacturing site that had struggled to replace its mission-critical legacy systems as part of the larger global company’s commercial-off-the-shelf (COTS) system implementation. We approach the replacement as a sociotechnical change and leverage the punctuated sociotechnical information system change model in combination with the design-moves framework to analyze how the site balanced creating digital options, countering social inertia, and managing (architectural) technical debt. The findings generalize to a two-level (local/global) system-dynamics model delineating how replacing a deeply entrenched mission-critical system generates positive and negative feedback loops within and between social and technical changes at local and global levels. The loops, unless addressed, accrue technical debt that hinders legacy system discontinuance and gradually locks the organization into a debtconstrained state. The model helps managers anticipate challenges that accompany replacing highly entrenched systems and formulate effective strategies to address them. [ABSTRACT FROM AUTHOR]

Model‐Based Systems Engineering (MBSE) is the next step in the evolution of systems engineering (SE) in which documents are replaced by descriptive models as the authoritative embodiment of SE knowledge. These descriptive models possess a unique combination of the features and characteristics of documents, software, and data. Conscientiously applying appropriate modeling principles and practices is essential to make informed decisions to moderate the accumulation of model technical debt. This paper briefly explains the concept of technical debt and its adaptation to the domain of descriptive models for MBSE. The paper then describes 18 foundational modeling principles that model architects should consider when making architectural and implementation decisions about their models and describes some of the key model technical debt tradeoffs that result when these principles are not followed. These principles address commonly observed challenges regarding model federation architecture, the selection and use of model layers, the modeling of the domain, and the semantics of modeling constructs. Applying disciplined model architecting practices to conscientiously manage the accrual and payoff of technical debt can make the difference between an enduring model that provides substantial value throughout the life cycle of the modeled entity and a model whose value collapses under the weight of uncontrolled technical debt. [ABSTRACT FROM AUTHOR]

Model‐Based Systems Engineering (MBSE) is the growing practice of systems engineering (SE) in which descriptive models replace documents as the embodiment of SE knowledge. These descriptive models capture SE information in place of documents, are developed in a similar manner to software source code, and are encoded and used in machine‐to‐machine applications as data. This paper describes how the Technical Debt concept widely used in the software domain—rework deferred to the future for expediency—needs to be modified for the domain of descriptive models. Technical Debt is often associated with agile development practices of software or descriptive models, which emphasize the rapid creation and iterative evolution of a Minimum Viable Product (MVP). Consciously applying appropriate modeling principles and practices is essential to make informed decisions during the modeling process to prevent the accumulation of excessive model Technical Debt—particularly during this iterative evolutionary process—which can require substantial rework to correct. The paper establishes a foundation for characterizing the Technical Debt implications of key model architecture and implementation decisions that are made explicitly or implicitly by modelers when developing descriptive models. To illustrate the model Technical Debt concept, several examples of modeling principles pertaining to model purpose and implementation are described along with their implications on model Technical Debt. [ABSTRACT FROM AUTHOR]

Technical debt presents sub-optimal choices made in development, which are beneficial in the short term but not in the long run. Consciously admitted debt, which is marked with a keyword, e.g., TODO, is called keyword-labeled self-admitted technical debt (KL-SATD). KL-SATD can lead to adverse effects in software development, e.g., to a rise in complexity within the developed software. We investigated the relationship between KL-SATD from source code comments and reports from the highly popular industrial program analysis tool SonarQube. The goal was to find which SonarQube metrics and issues are related to KL-SATD introduction and removal and how many KL-SATD in the context of an issue addresses that issue. We performed a study with 33 software repositories. We analyzed the changes in SonarQube reports (sqale index, reliability and security remediation metrics, and SonarQube issues) and the relationship to KL-SATD addition and removal with mixed model analysis. We manually annotated a sample to investigate how many KL-SATD comments are in the context of SonarQube issues and how many address them directly. KL-SATD is associated with a reduction in code maintainability measured with SonarQube's sqale index. KL-SATD removal is associated with an increase in code maintainability (sqale index) and reliability measured with SonarQube's reliability remediation effort. The introduction and removal of KL-SATD have a predominantly relationship with code smells, and not with vulnerabilities and bugs. Manual annotation revealed that 36% of KL-SATD comments are in the context of a SonarQube issue, but only 15% of the comment address an issue. This means that despite of statistical relationship between KL-SATD comments and SonarQube reports there is a large set of KL-SATD comments that are in areas that Sonarqube reports as clean or free of maintainability issues. KL-SATD introduction and removal are connected mainly to code smells, connecting them to maintainability rather than reliability or security. This is reinforced by the relationship with the sqale index, as well as the dominance of code smells in SonarQube issues. Many KL-SATD issues have characteristics going beyond static analysis tools and require future studies extending the capabilities of the current tools. As KL-SATD comments and SonarQube reports appear to have limited overlap, it suggests that they are complementary and both are needed for getting a comprehensive view coverage of code maintainability. The study also presents rules violations developers should be aware of regarding KL-SATD introduction and removal. [ABSTRACT FROM AUTHOR]

Static code analysis (SAST is a well-known concept) to identify security flaws in the code to improve software product quality. A SAST tool called SonarQube which can scan source code of an application and identify the vulnerabilities present in software. It can also find the RCA of the vulnerabilities found in software products. it helps in rehabilitating the securities flaws found in analysis of the software products. SAST tools analyses upside-down for an application. It does not need s system to be in running state to perform analysis. The scan provides instant feedback to developers in terms of reducing security risks for an application. It helps to resolve issues which was present during development and helps developers to increase their knowledge. As a result, developers become competent about knowledge of security for software product. The sonar analysis report provides on demand access to all recommendations. The user can navigate to line-of-code which have vulnerabilities and they can do faster discovery and auditing. And hence the developers can write more code which is less vulnerable. This way they have more secure and quality product delivered. To conduct static analysis, the Authors have used SonarQube as a tool, which compile and measure the code quality for the code kept in repositories. The Authors observed SAST is important step in conductingsecurity and vulnerabilities scan for software product, it was also observed that most of the organisationconduct this SAST at later stage in DevOps/DevSecOps Phase which actually increases pipeline execution time. This motivated Authors topropose a better Model to reduce the build pipeline execution time. As Devops/DevSecOps standards, SonarQube is used to do SASTin DevSecOps pipelines which normally increases the build pipeline execution time. This increases the effort and time to complete the build pipeline and hence it also impacts overall budget of the software product. In the proposed solution, the Authors tried to reduce build pipeline execution time by conducting static analysis early in DevSecOps phases using shift left. Proposed solution uses GitHub open-source project written in C#.NET language, Azure Devops, dotnet sonar scanner tool and SonarQube to conduct static analysis and testing. The authors(s) tried to enhance the software quality in early Devops phases which will be helpful in reducing the build time and cost. Proposed Model will be helpful in increasing reliability, efficiency, and performance of software product. [ABSTRACT FROM AUTHOR]

Monitoring technical debt (TD) is considered highly important for software companies, as it provides valuable information on the effort required to repay TD and in turn maintain the system. When it comes to TD repayment, however, developers are often overwhelmed with a large volume of TD liabilities that they need to fix, rendering the procedure effort demanding. Hence, prioritizing TD liabilities is of utmost importance for effective TD repayment. Existing approaches rely on the current TD state of the system; however, prioritization would be more efficient by also considering its future evolution. To this end, the present work proposes a practical approach for prioritization of TD liabilities by incorporating information retrieved from TD forecasting techniques, emphasizing on the class‐level granularity to provide highly actionable results. Specifically, the proposed approach considers the change proneness and forecasted TD evolution of software artifacts and combines it with proper visualization techniques, to enable the early identification of classes that are more likely to become unmaintainable. To demonstrate and evaluate the approach, an empirical study is conducted on six real‐world applications. The proposed approach is expected to facilitate developers better plan refactoring activities, in order to manage TD promptly and avoid unforeseen situations long term. [ABSTRACT FROM AUTHOR]

Technical debt (TD) is a metaphor used to refer to the added software system costs acquired from taking shortcuts. Unfortunately, large amounts of TD can lead to serious consequences, and, thus, the management of TD is essential. Due to TD being a relatively new subject of study, many aspects of TD remain ambiguous. Fortunately, Twitter has been proven to hold a wealth of information on many subjects. As such, this survey study aims to gain a better understanding on how interest in TD has evolved over time and how TD is addressed on Twitter. A total of 128,897 TD‐related tweets were scrapped from Twitter and analyzed using a number of proxy measures and Latent Dirichlet Allocation (LDA). The results revealed that interest in TD on Twitter has been generally increasing since the platform's early stages. Furthermore, TD‐related tweets were found to revolve around 11 distinct categories. The TD in games category was discovered to be the most popular category, followed by TD communication and TD repayment. The results highlight that TD is a diverse and overarching topic that contains many potential avenues for further exploration. Software engineering researchers, practitioners, and educators can utilize this study to help steer their TD‐related future efforts. [ABSTRACT FROM AUTHOR]

Technical debt (TD) poses a significant risk in the software industry, representing the compromises made during software development that result in long-term consequences. To facilitate the management of TD, it is important to explore the causes of TD and the effects of the presence of TD on software projects. While the concept of TD has been investigated in several countries, no study has explored TD in the context of Saudi Arabia. In this paper, we aim to investigate the familiarity of the TD concept within the Saudi software practitioners and identifying the common causes and effects of TD in the Saudi software industry. We replicated a global survey called InsighTD, using the same survey instrument and the analysis procedure but collecting the data from software practitioners in Saudi Arabia. A total of 48 Saudi software practitioners completed the survey. The study findings indicate that the TD concept is not well recognized among the Saudi software practitioners (50% of the survey respondents have never heard of it before). Additionally, we identify the common causes and effects of TD from the perspective of Saudi software practitioners. The top causes of TD were tight-release deadlines, work pressure, lack of experience, and inappropriate project planning. On the other hand, the top effects of TD were increased maintenance effort/cost, low software quality, and delayed delivery of new versions. In conclusion, our findings support previous research regarding the most common TD causes and effects. In addition, they highlight some important factors in the Saudi software industry. [ABSTRACT FROM AUTHOR]

Organizations dealing with mission-critical AI based autonomous systems may need to provide continuous risk management controls and establish means for their governance. To achieve this, organizations are required to embed trustworthiness and transparency in these systems, with human overseeing and accountability. Autonomous systems gain trustworthiness, transparency, quality, and maintainability through the assurance of outcomes, explanations of behavior, and interpretations of intent. However, technical, commercial, and market challenges during the software development lifecycle (SDLC) of autonomous systems can lead to compromises in their quality, maintainability, interpretability and explainability. This paper conceptually models transformation of SDLC to enable affordances for assurance, explanations, interpretations, and overall governance in autonomous systems. We argue that opportunities for transformation of SDLC are available through concerted interventions such as technical debt management, shift-left approach and non-ephemeral artifacts. This paper contributes to the theory and practice of governance of autonomous systems, and in building trustworthiness incrementally and hierarchically.

What new questions could ecophysiologists answer if physio-logging research was fully reproducible? We argue that technical debt (computational hurdles resulting from prioritizing short-term goals over long-term sustainability) stemming from insufficient cyberinfrastructure (field-wide tools, standards, and norms for analyzing and sharing data) trapped physio-logging in a scientific silo. This debt stifles comparative biological analyses and impedes interdisciplinary research. Although physio-loggers (e.g., heart rate monitors and accelerometers) opened new avenues of research, the explosion of complex datasets exceeded ecophysiologys informatics capacity. Like many other scientific fields facing a deluge of complex data, ecophysiologists now struggle to share their data and tools. Adapting to this new era requires a change in mindset, from data as a noun (e.g., traits, counts) to data as a sentence, where measurements (nouns) are associate with transformations (verbs), parameters (adverbs), and metadata (adjectives). Computational reproducibility provides a framework for capturing the entire sentence. Though usually framed in terms of scientific integrity, reproducibility offers immediate benefits by promoting collaboration between individuals, groups, and entire fields. Rather than a tax on our productivity that benefits some nebulous greater good, reproducibility can accelerate the pace of discovery by removing obstacles and inviting a greater diversity of perspectives to advance science and society. In this article, we 1) describe the computational challenges facing physio-logging scientists and connect them to the concepts of technical debt and cyberinfrastructure, 2) demonstrate how other scientific fields overcame similar challenges by embracing computational reproducibility, and 3) present a framework to promote computational reproducibility in physio-logging, and bio-logging more generally.

Refactoring, which aims to improve the internal structure of the software systems preserving their behavior, is the most common payment strategy for technical debt (TD) by removing the code smells. There exist many studies presenting code smell detection approaches/tools or investigating their impact on quality attributes. There are also studies that focus on refactoring techniques, their relation with quality attributes, tool supports, and opportunities for them. Although there are several studies addressing the gap between refactoring and TD indicators, the empirical evidence provided is still limited. In this study, we examine the distribution of 29 refactoring types among the different projects and their relation with code smells or faults. We explore the refactoring types that are most commonly performed together and other activities performed with refactorings. We conduct a large exploratory study with automatically detected 57,528 refactorings, 37,553 smells, 27,340 faults, and 134,812 commits of 33 Java projects. Results show that some refactoring types are more commonly applied by developers. Our analysis indicates that refactorings usually remove or do not affect the code smells, and this contradicts with the previous studies. Also, the commits in which refactoring(s) is performed are three times more fault inducing than those without refactoring. [ABSTRACT FROM AUTHOR]

Technical debt (TD) refers to the phenomenon that developers choose a compromise solution from a short-term benefit perspective during design or architecture selection. TD-related issues, such as code smells, may have a critical impact on important non-functional requirements. Different severity levels of TD issues require different measures to be taken by developers in the future. Existing studies mainly focus on detecting TD in software projects through source code or comments, but usually ignore the severity degree of TD issues. As a matter of fact, it is very important to identify the severity of TD issues and clarify which TD should be prioritized. In this paper, we propose an approach that combines the semantic and structural information of the code snippets to identify their severity at method level. In the approach, we first transform each method affected by TD issues into an abstract syntax tree (AST) and use the paths in the AST to represent its semantic information. Then, we extract different code metrics to measure the size, coupling, and complexity of methods affected by TD issues to represent their structural information. Finally, we build a stacking ensemble model to identify the severity of TD issues by using Random Forest (RF) and eXtreme Gradient Boosting (XGBoost) for the base classifiers and Support Vector Machine (SVM) for the meta-classifier. The evaluation results on the real dataset show that our approach achieves 65.77% in terms of precision, 68.18% in terms of recall, and 65.84% in terms of F1-score on average. In addition, the experimental results also demonstrate that the strategy of combining the semantic and structural information of code snippets is effective in improving the effectiveness of our approach. [ABSTRACT FROM AUTHOR]

The metaphor of technical debt (TD) has generated a conceptual framework on factors that weaken the quality of software and accumulate a repair cost. However, user-related aspects like user experience (UX) receive little consideration among TD types, for reasons like the substantial focus on code TD, some dynamics inherent to agile processes, and an apparent lack of cumulative cost over time. This article has two main goals: first, to present evidence of the existence of UXDebt as a type of TD, with a cumulative cost for the development team as well as stakeholders; second, to propose a definition and characterization of UXDebt that may serve as a frame for further research on methods and tools for continuous management within agile processes. For the first goal, we have compiled evidence on the current state of UXDebt from three sources: a literature review, a survey among software engineering professionals in agile teams, and the analysis of UX issues in GitHub. All sources have evidenced some form of UXDebt; surveyed practitioners have recognized its poor management with a cost for the entire team that accumulates over time. Moreover, issue tracking systems allow to visualize and measure a technical form of UXDebt. For the second goal, we have defined a conceptual model that characterizes UXDebt in terms of both technical and non-technical aspects. On the technical side, we propose the notion of UX smells which allows us to discuss concrete management activities. [ABSTRACT FROM AUTHOR]

Technical debt (TD) expresses the lack of internal quality directly affecting software evolution. Therefore, it has gained the attention of software researchers and practitioners recently. Software researchers have performed empirical studies to observe the perspective of TD in different software cultures and organizations. However, it is important to replicate such studies in more places and with more practitioners to strengthen the perception of TD. In this paper, we present the results of a set of new research questions from an evolved survey design of a survey replication in the Uruguayan software industry to characterize how the software industry professionals understand, perceive, and adopt TD management (TDM) activities. The results allow us to observe that different participant contexts (startups, government, job roles) show different levels of awareness and perception of TD. Details in the form of the adoption of each TDM activity were presented. We could observe some difficulties in conducting some TDM activities that the practitioners consider very important, especially in TDM and monitoring. Differences in specific organizational contexts like startups and government could indicate the need for research efforts in other software engineering communities that meet their specific TD challenges and needs. [ABSTRACT FROM AUTHOR]

Technical debt refers to maintenance obligations that stem from violations of established standards during the development and subsequent maintenance of enterprise systems. Technical debt remediation is particularly challenging in the outsourcing context due to information asymmetry between client and vendor teams. Control balancing—the periodic adjustments to the control configurations of outsourced projects—has been proposed as a process to help mitigate these information asymmetry challenges. Using data collected from 1,824 real-world projects, we tested to what extent control balancing improves the remediation of technical debt. After controlling for a number of technical and environmental factors, including system size, system lifespan, and contract parameters, we find that control balancing can benefit technical debt remediation, but primarily when processes for migrating technical debt-laden systems to new technological platforms have been identified. We highlight the role of technical debt in influencing the effects of relational flexibility in inter-firm engagements. [ABSTRACT FROM AUTHOR]

The metaphor of technical debt (TD) is widely adopted in the software engineering field, referring to short‐term compromises in software artifacts in exchange for speed or to meet release schedules or other constraints. The implication is that TDs accumulate over time, and may eventually make rework or maintenance very expensive or even impossible. The analogy is generally applicable in the systems engineering field, particularly concerning numerous program cancellation and obsolescence challenges due to premature decisions made in early acquisition phases. This paper adapts this metaphor of TD to the systems engineering field, and proposes a TD taxonomy to support the early identification and assessment of TD items in engineering complex systems, especially in the early life cycle phases of engineering complex, distributed systems. The taxonomy identifies seven TD types: functionality, performance, interoperability, version conflicts, documentation and support, system evolution, and organic, based on systematic indicators and signs discoverable during early acquisition activities. We expect that the notion and the taxonomy of TD will offer an additional perspective for design decisions that will help mitigate challenging integration and obsolescence issues in the engineering of complex systems. [ABSTRACT FROM AUTHOR]

The metaphor of "technical debt" is used in software engineering to describe technical solutions that may be pragmatic in the near‐term but may have a negative long‐term impact. Similar decisions and similar dynamics are present in the field of systems engineering. This work investigates the current body of knowledge to identify if, and how, the technical debt metaphor is used within the systems engineering field and which systems engineering lifecycle stages are most susceptible to technical debt. A systematic literature review was conducted on 354 papers in February 2022, of which 18 were deemed relevant for inclusion in the study. The results of the systematic literature review show that the technical debt metaphor is not prevalent within systems engineering research and that existing research is limited to specific fields and theoretical discussions. This paper concludes with recommendations for future work to establish a research agenda on the identification and management of technical debt within systems engineering. [ABSTRACT FROM AUTHOR]

Purpose: Development of the customer perceived value expression with the product use functions optimization model aiming particularly the case of new technology based innovations. Design/methodology/approach: Firstly, the role of customer is presented with particular attention payed to the client role in value creation process in the case of innovation based product. Then the perceived customer value and customer value definition are described. Those formulas are used in consequence as the base for expanded theoretic value concept, which is integrating the impact of used product brand and user functions mix. Finally, the introduced notion is developed in matrix form and briefly discussed. Findings: Extended formula of innovation based new product perceived customer value is presented in the form of the matrix notation, the possible application in the company innovation based product portfolio formation process is discussed. Research limitations/implications: Presented approach to the customer perceived value is based on the application of technical debt concept as the measure of analyzed product innovativeness, which is sensitive data and stay difficult to collect, particularly in case of new technologies. Practical implications: Proposed extended customer perceived value formula can be used as practical tool of new technology based innovative product, allowing to assess its market value in comparison to the existing company product cost structure. Makes possible to confront the customer product appreciation to those coming from the company interior analyzes. Hence its matrix form can serve as optimization model taking under consideration the possible market potential, impact of used brand and design and product use functions mix according to their technology life cycle. Social implications: Developed concept can reinforce the client role in commercialization process, particularly in case technology innovation. Also its use can be an interesting tool of prosumption development, making it more unambiguous and proactive. Originality/value: Presented extended formula of customer perceived vale can be applied as an interesting concept of research about nature the value of new technologies based innovation product also as base for practical managerial tool of optimization the new product mix during the commercialization process. [ABSTRACT FROM AUTHOR]

With the advent of regulations protecting users such as the General Data Protection Regulation, security and privacy concerns are playing a new role in small settings such as in very small entities. Their relevance is increasing, and privacy is being considered a Troy horse in software developments. In fact, privacy is a part of software architectural decisions, and they must be considered as a technical debt. The contributions of this paper are the following: a privacy debt definition with a principal and an interest, privacy‐related activities to be considered within the ISO/IEC 29110 basic profile, and the use of the net present value within this context. All these contributions help us to integrate privacy debt and VSE's software developments. [ABSTRACT FROM AUTHOR]

Technical debt, the long-term impact of decisions made to achieve a short-term benefit, has a unique impact on a project schedule. Technical debt does not impact the ability to complete the task on which it is incurred but rather impacts successor tasks causing unplanned schedule delays or budget increases. The impact of technical debt is uncertain and therefore must be modeled probabilistically. When unaccounted for and unmanaged, technical debt can build up in the project with increasing impact, eventually forcing forward progress to stop while the technical debt is remedied. Traditional project scheduling methods allow for uncertain task durations but do not provide explicit means of modeling the impacts of technical debt. Instead, they assume that each task is unaffected by the completion status of its predecessors and its duration is only dependent upon the initial estimates. This research addresses this gap by providing a novel model of the impact of technical debt on the project schedule through estimating the dynamics of value creation in the presence of technical debt. Equations are developed for estimating the probabilistic impacts of technical debt on the generation of earned value. These equations are then inverted and used to calculate task duration in the presence of technical debt and included in a Monte Carlo analysis. Comparisons are made to an existing Monte Carlo schedule analysis and technical debt impacts are explored.

The List, Evaluate, Achieve, Procure (LEAP) process defines a methodology for mathematically associating the delivery of system capabilities with the temporal satisfaction of stakeholder needs while identifying technologies at high risk of imparting technical debt into the system. The original process is qualitative, relying on binary definitions of timelines for technology development – the technology either is or is not developed in a specific time period. The binary definitions allow for rapid high-level assessments of the potential for technical debt. However, they fail to capture more realistic scenarios of uncertain technology development timelines. This paper resolves these issues by introducing probability into LEAP process. This paper also provides examples of using the probability in the LEAP process and compares the probabilistic (quantitative) and binary (qualitative) models. These examples show improvements in the ability to assess the likelihood of delivering capabilities in time to meet stakeholder needs when using the probabilistic version of the LEAP process. Since the impact of technical debt is uncertain, the inclusion of probabilities within the LEAP process provides a higher fidelity decision support system for iterative release planning and system development.

Technical debt is considered detrimental to the long-term success of software development, but despite the numerous studies in the literature, there are still many aspects that need to be investigated for a better understanding of it. In particular, the main problems that hinder its complete understanding are the absence of a clear definition and a model for its identification, management, and forecasting. Focusing on forecasting technical debt, there is a growing notion that preventing technical debt build-up allows you to identify and address the riskiest debt items for the project before they can permanently compromise it. However, despite this high relevance, the forecast of technical debt is still little explored. To this end, this study aims to evaluate whether the quality metrics of a software system can be useful for the correct prediction of the technical debt. Therefore, the data related to the quality metrics of 8 different open-source software systems were analyzed and supplied as input to multiple machine learning algorithms to perform the prediction of the technical debt. In addition, several partitions of the initial dataset were evaluated to assess whether prediction performance could be improved by performing a data selection. The results obtained show good forecasting performance and the proposed document provides a useful approach to understanding the overall phenomenon of technical debt for practical purposes. [ABSTRACT FROM AUTHOR]

Current Internet of Things (IoT) systems comprise multiple software systems that are deployed to provide users with the required functionalities. System architects create system blueprints and draw specifications for the software artefacts that are needed; subsequently, either custom-made software is developed according to these specifications and/or ready-made COTS/open source software may be identified and customized to realize the overall system goals. All deployed software however may entail vulnerabilities, either due to insecure coding practices or owing to misconfigurations and unexpected interactions. Moreover, software artefacts may implement a much broader set of functionalities than may be strictly necessary for the system at hand, in order to serve a wider range of needs, and failure to appropriately configure the deployed software to include only the required modules results in the further increase of the system attack surface and the associated risk. In this paper, we present a software vulnerability management framework which facilitates (a) the configuration of software to include only the necessary features, (b) the execution of security-related tests and the compilation of platform-wide software vulnerability lists, and (c) the prioritization of vulnerability addressing, considering the impact of each vulnerability, the associated technical debt for its remediation, and the available security budget. The proposed framework can be used as an aid in IoT platform implementation by software architects, developers, and security experts. [ABSTRACT FROM AUTHOR]