A Case Study in Locating the Architectural Roots of Technical Debt

Our recent research has shown that, in large-scale software systems, defective files seldom exist alone. They are usually architecturally connected, and their architectural structures exhibit significant design flaws which propagate bugginess among files. We call these flawed structures the architecture roots, a type of technical debt that incurs high maintenance penalties. Removing the architecture roots of bugginess requires refactoring, but the benefits of refactoring have historically been difficult for architects to quantify or justify. In this paper, we present a case study of identifying and quantifying such architecture debts in a large-scale industrial software project. Our approach is to model and analyze software architecture as a set of design rule spaces (DRSpaces). Using data extracted from the project's development artifacts, we were able to identify the files implicated in architecture flaws and suggest refactorings based on removing these flaws. Then we built economic models of the before and (predicted) after states, which gave the organization confidence that doing the refactorings made business sense, in terms of a handsome return on investment.

[1]  Mark Klein,et al.  Experience with performing architecture tradeoff analysis , 1999, Proceedings of the 1999 International Conference on Software Engineering (IEEE Cat. No.99CB37002).

[2]  Mauricio A. Saca Refactoring improving the design of existing code , 2017, 2017 IEEE 37th Central America and Panama Convention (CONCAPAN XXXVII).

[3]  Yuanfang Cai,et al.  Leveraging design rules to improve software architecture recovery , 2013, QoSA '13.

[4]  Leonard J. Bass,et al.  SAAM: a method for analyzing the properties of software architectures , 1994, Proceedings of 16th International Conference on Software Engineering.

[5]  Yuanfang Cai,et al.  Comparing four approaches for technical debt identification , 2014, Software Quality Journal.

[6]  Mark Klein,et al.  Quantifying the costs and benefits of architectural decisions , 2001, Proceedings of the 23rd International Conference on Software Engineering. ICSE 2001.

[7]  青島 矢一,et al.  書評 カーリス Y. ボールドウィン/キム B. クラーク著 安藤晴彦訳『デザイン・ルール:モジュール化パワー』 Carliss Y. Baldwin & Kim B. Clark/Design Rules, Vol. 1: The Power of Modularity , 2005 .

[8]  Andreas Zeller,et al.  Mining metrics to predict component failures , 2006, ICSE.

[9]  David M. Weiss,et al.  Architecture reviews: practice and experience , 2005, IEEE Software.

[10]  Harvey P. Siy,et al.  Predicting Fault Incidence Using Software Change History , 2000, IEEE Trans. Software Eng..

[11]  Linda Rising The patterns handbooks: techniques, strategies, and applications , 1998 .

[12]  Yuanfang Cai,et al.  Titan: a toolset that connects software architecture with quality analysis , 2014, SIGSOFT FSE.

[13]  Yuanfang Cai,et al.  Hotspot Patterns: The Formal Definition and Automatic Detection of Architecture Smells , 2015, 2015 12th Working IEEE/IFIP Conference on Software Architecture.

[14]  Elaine J. Weyuker,et al.  Predicting the location and number of faults in large software systems , 2005, IEEE Transactions on Software Engineering.

[15]  Yuanfang Cai,et al.  Improving the Efficiency of Dependency Analysis in Logical Decision Models , 2009, 2009 IEEE/ACM International Conference on Automated Software Engineering.

[16]  Philippe Kruchten,et al.  The 4+1 View Model of Architecture , 1995, IEEE Softw..

[17]  Kim B. Clark,et al.  Design Rules: The Power of Modularity Volume 1 , 1999 .

[18]  Chao Liu,et al.  SOBER: statistical model-based bug localization , 2005, ESEC/FSE-13.

[19]  Harald C. Gall,et al.  Detection of logical coupling based on product release history , 1998, Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272).

[20]  Alexander Chatzigeorgiou,et al.  Identification of Move Method Refactoring Opportunities , 2009, IEEE Transactions on Software Engineering.

[21]  Shinji Kusumoto,et al.  Refactoring Support Based on Code Clone Analysis , 2004, PROFES.

[22]  James E. Tomayko,et al.  Integrating the Architecture Tradeoff Analysis Method (ATAM) with the Cost Benefit Analysis Method (CBAM) , 2003 .

[23]  Yuanfang Cai,et al.  Design Rule Hierarchies and Parallelism in Software Development Tasks , 2009, 2009 IEEE/ACM International Conference on Automated Software Engineering.

[24]  Andrew Koenig,et al.  Patterns and Antipatterns , 1998, J. Object Oriented Program..

[25]  Yuanfang Cai,et al.  Modularity Analysis of Logical Design Models , 2006, 21st IEEE/ACM International Conference on Automated Software Engineering (ASE'06).

[26]  Nenad Medvidovic,et al.  Identifying Architectural Bad Smells , 2009, 2009 13th European Conference on Software Maintenance and Reengineering.

[27]  Rick Kazman,et al.  Decision-making techniques for software architecture design: A comparative survey , 2011, CSUR.

[28]  Victor R. Basili,et al.  Analyzing Error-Prone System Structure , 1991, IEEE Trans. Software Eng..

[29]  John T. Stasko,et al.  Visualization of test information to assist fault localization , 2002, ICSE '02.

[30]  Paul Clements,et al.  Software architecture in practice , 1999, SEI series in software engineering.

[31]  Audris Mockus,et al.  Software Dependencies, Work Dependencies, and Their Impact on Failures , 2009, IEEE Transactions on Software Engineering.

[32]  Yuanfang Cai,et al.  Design rule spaces: a new form of architecture insight , 2014, ICSE.

[33]  Kim B. Clark,et al.  The power of modularity , 2000 .

[34]  Yann-Gaël Guéhéneuc,et al.  A Domain Analysis to Specify Design Defects and Generate Detection Algorithms , 2008, FASE.

[35]  Kim B. Clark,et al.  The Option Value of Modularity in Design: An Example From Design Rules, Volume 1: The Power of Modularity , 2000 .

[36]  Xiangyu Zhang,et al.  Locating faulty code using failure-inducing chops , 2005, ASE.