Assessing technical debt by identifying design flaws in software systems

Tough time-to-market constraints and unanticipated integration or evolution issues lead to design tradeoffs that usually cause flaws in the structure of a software system. Thus, maintenance costs grow significantly. The impact of these design decisions, which provide short-term benefits at the expense of the system's design integrity, is usually referred to as technical debt. In this paper, I propose a novel framework for assessing technical debt using a technique for detecting design flaws, i.e., specific violations of well-established design principles and rules. To make the framework comprehensive and balanced, it is built on top of a set of metrics-based detection rules for well-known design flaws that cover all of the major aspects of design such as coupling, complexity, and encapsulation. I demonstrate the effectiveness of the framework by assessing the evolution of technical debt symptoms over a total of 63 releases of two popular Eclipse® projects. The case study shows how the framework can detect debt symptoms and past refactoring actions. The experiment also reveals that in the absence of such a framework, restructuring actions are not always coherent and systematic, not even when performed by very experienced developers.

[1]  Oscar Nierstrasz,et al.  Object-oriented reengineering patterns , 2004, Proceedings. 26th International Conference on Software Engineering.

[2]  Adrian Trifu,et al.  Towards Automated Restructuring of Object Oriented Systems , 2007, 11th European Conference on Software Maintenance and Reengineering (CSMR'07).

[3]  Alessandro F. Garcia,et al.  On the Relevance of Code Anomalies for Identifying Architecture Degradation Symptoms , 2012, 2012 16th European Conference on Software Maintenance and Reengineering.

[4]  D. Campbell,et al.  EXPERIMENTAL AND QUASI-EXPERIMENT Al DESIGNS FOR RESEARCH , 2012 .

[5]  Dave Thomas,et al.  Practice , 2004, IEEE Softw..

[6]  Radu Marinescu,et al.  Detection strategies: metrics-based rules for detecting design flaws , 2004, 20th IEEE International Conference on Software Maintenance, 2004. Proceedings..

[7]  Roger S. Pressman,et al.  Software Engineering: A Practitioner's Approach , 1982 .

[8]  Renato De Mori,et al.  Pattern matching for design concept localization , 1995, Proceedings of 2nd Working Conference on Reverse Engineering.

[9]  Meir M. Lehman,et al.  Laws of Software Evolution Revisited , 1996, EWSPT.

[10]  M.J. Munro,et al.  Product Metrics for Automatic Identification of "Bad Smell" Design Problems in Java Source-Code , 2005, 11th IEEE International Software Metrics Symposium (METRICS'05).

[11]  簡聰富,et al.  物件導向軟體之架構(Object-Oriented Software Construction)探討 , 1989 .

[12]  Victor R. Basili,et al.  The TAME Project: Towards Improvement-Oriented Software Environments , 1988, IEEE Trans. Software Eng..

[13]  R. Geoff Dromey,et al.  A Model for Software Product Quality , 1995, IEEE Trans. Software Eng..

[14]  Jean-Francois Girard,et al.  An Activity-Based Quality Model for Maintainability , 2007, 2007 IEEE International Conference on Software Maintenance.

[15]  Stéphane Ducasse,et al.  Using history information to improve design flaws detection , 2004, Eighth European Conference on Software Maintenance and Reengineering, 2004. CSMR 2004. Proceedings..

[16]  Radu Marinescu,et al.  Quantifying the quality of object-oriented design: the factor-strategy model , 2004, 11th Working Conference on Reverse Engineering.

[17]  Thomas J. Mowbray,et al.  AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis , 1998 .

[18]  Peri L. Tarr,et al.  An enterprise perspective on technical debt , 2011, MTD '11.

[19]  Oliver Ciupke,et al.  Automatic detection of design problems in object-oriented reengineering , 1999, Proceedings of Technology of Object-Oriented Languages and Systems - TOOLS 30 (Cat. No.PR00278).

[20]  Martin Fowler,et al.  Refactoring - Improving the Design of Existing Code , 1999, Addison Wesley object technology series.

[21]  Cristina Marinescu,et al.  Are the Clients of Flawed Classes (Also) Defect Prone? , 2011, 2011 IEEE 11th International Working Conference on Source Code Analysis and Manipulation.

[22]  Oscar Nierstrasz,et al.  Finding refactorings via change metrics , 2000, OOPSLA '00.

[23]  Ward Cunningham,et al.  The WyCash portfolio management system , 1992, OOPSLA '92.

[24]  Frank Budinsky,et al.  Eclipse Modeling Framework , 2003 .

[25]  Carl G. Davis,et al.  A Hierarchical Model for Object-Oriented Design Quality Assessment , 2002, IEEE Trans. Software Eng..

[26]  Yann-Gaël Guéhéneuc,et al.  DECOR: A Method for the Specification and Detection of Code and Design Smells , 2010, IEEE Transactions on Software Engineering.

[27]  Arthur J. Riel,et al.  Object-Oriented Design Heuristics , 1996 .

[28]  Stéphane Ducasse,et al.  Object-Oriented Metrics in Practice , 2005 .

[29]  Karl J. Lieberherr,et al.  Object-oriented design , 1996, CSUR.

[30]  Jean-Louis Letouzey,et al.  The SQALE method for evaluating Technical Debt , 2012, 2012 Third International Workshop on Managing Technical Debt (MTD).

[31]  Foutse Khomh,et al.  An Exploratory Study of the Impact of Code Smells on Software Change-proneness , 2009, 2009 16th Working Conference on Reverse Engineering.

[32]  Foutse Khomh,et al.  An exploratory study of the impact of antipatterns on class change- and fault-proneness , 2011, Empirical Software Engineering.

[33]  R. Dromey,et al.  A Model for Software Product Quality , 1995, IEEE Trans. Software Eng..