Managing technical debt in software-intensive systems

摘要 如果金融债务得不到及时偿还，就会积累利息，导致破产。在软件开发中，技术债务是一个比喻，它传达了这样一个概念，即一些设计决策和一些“不太正确”的代码元素将减慢系统未来的开发速度，并可能逐渐使其停止。事实证明，这个比喻有助于在开发人员、架构师、产品经理等不同利益相关者之间就要做出的战术和战略决策展开对话。当使用高度迭代的开发周期、频繁甚至连续交付时，情况尤其如此。 更准确地说，软件密集型系统中的技术债务包括设计或实现构造，这些构造在短期内是有利的，但确实建立了一种技术背景，可能会使未来的更改成本更高，甚至不可能。因此，技术债务是一种或有负债，其影响仅限于内部系统质量，主要是可维护性和可演化性。技术债务不同于制度缺陷，制度缺陷影响制度的外部质量和功能。技术债务大多只对开发人员本身可见；它不会对系统的用户表现出来，除非对市场需求的反应速度减慢。 拟议的研究是为了调查管理技术债务的新方法：识别它、量化它，并更好地支持有关补救的决策；在无法全部偿还的情况下，我们现在应该偿还哪些技术债务？ 大多数行业实践和技术债务研究的重点都是基于静态源代码分析来检测技术债务，如代码气味、代码复杂性、代码标准违规和一些结构性问题，例如：高度耦合、循环依赖、错综复杂的组件依赖集。 这项研究方案的目标不仅仅是源代码，它有三个主要方面： 1.建筑技术债务的认定及可能的防范 2.协助确定潜在的技术债务 3.权衡分析：补救与持续利息支付。

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.