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.