Managing technical debt in software-intensive systems

点击翻译按钮获取中文摘要

Summary***A financial debt not promptly repaid will accumulate interests and lead to bankruptcy. In software development, technical debt is a metaphor to convey the notion that some design decisions and some elements of code which are “not quite right” will slow down the future developments of the system, and may gradually bring it to a halt. This metaphor has proven useful to initiate a dialog between various stakeholders: developers, architects, product managers, about tactical and strategic decision to make. This is especially the case when using a highly iterative development cycle, with frequent or even continuous delivery.*** *More precisely, technical debt in software-intensive systems consists of design or implementation constructs that are expedient in the short term, but which do set up a technical context that can make a future change more costly or impossible. Technical debt is therefore a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability. Technical debt is different from system defects, which affect the external quality and functionality of the system. Technical debt is mostly visible only to the developers themselves; it does not manifest itself to the users of the system, except through a slowdown in the responsiveness to market demands.*** *The proposed research is to investigate novel approaches to manage technical debt: identify it, quantify it, and better support decision-making about remediation; which elements of technical debt we should repay now, when repaying all is not an option?*** *Most of the industry practices and the focus of research on technical debt are based on static source-code analysis to detect technical debt, such as code smells, code complexity, coding standard violations, and a few structural issues, for example: high coupling, circular dependencies, convoluted set of component dependencies.***This research proposal aim at going further than mere source code and has three main facets:***1. Identification of architectural technical debt and possible prevention***2. Assisted identification of potential technical debt***3. Trade-off analysis: remediation vs. ongoing interest payments.***********