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.***********