Object-oriented design
The WyCash portfolio management system
OOPSLA '92 Addendum to the proceedings on Object-oriented programming systems, languages, and applications (Addendum)
A Model for Software Product Quality
IEEE Transactions on Software Engineering
AntiPatterns: refactoring software, architectures, and projects in crisis
AntiPatterns: refactoring software, architectures, and projects in crisis
Refactoring: improving the design of existing code
Refactoring: improving the design of existing code
Finding refactorings via change metrics
OOPSLA '00 Proceedings of the 15th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
A Hierarchical Model for Object-Oriented Design Quality Assessment
IEEE Transactions on Software Engineering
Agile Software Development: Principles, Patterns, and Practices
Agile Software Development: Principles, Patterns, and Practices
Object-Oriented Design Heuristics
Object-Oriented Design Heuristics
Object-Oriented Software Construction
Object-Oriented Software Construction
Object Oriented Reengineering Patterns
Object Oriented Reengineering Patterns
Laws of Software Evolution Revisited
EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology
Automatic Detection of Design Problems in Object-Oriented Reengineering
TOOLS '99 Proceedings of the Technology of Object-Oriented Languages and Systems
Pattern matching for design concept localization
WCRE '95 Proceedings of the Second Working Conference on Reverse Engineering
Using History Information to Improve Design Flaws Detection
CSMR '04 Proceedings of the Eighth Euromicro Working Conference on Software Maintenance and Reengineering (CSMR'04)
Detection Strategies: Metrics-Based Rules for Detecting Design Flaws
ICSM '04 Proceedings of the 20th IEEE International Conference on Software Maintenance
Quantifying the Quality of Object-Oriented Design: The Factor-Strategy Model
WCRE '04 Proceedings of the 11th Working Conference on Reverse Engineering
Object-Oriented Metrics in Practice
Object-Oriented Metrics in Practice
Product Metrics for Automatic Identification of "Bad Smell" Design Problems in Java Source-Code
METRICS '05 Proceedings of the 11th IEEE International Software Metrics Symposium
Software Engineering: A Practitioner's Approach
Software Engineering: A Practitioner's Approach
DECOR: A Method for the Specification and Detection of Code and Design Smells
IEEE Transactions on Software Engineering
An enterprise perspective on technical debt
Proceedings of the 2nd Workshop on Managing Technical Debt
Are the Clients of Flawed Classes (Also) Defect Prone?
SCAM '11 Proceedings of the 2011 IEEE 11th International Working Conference on Source Code Analysis and Manipulation
An exploratory study of the impact of antipatterns on class change- and fault-proneness
Empirical Software Engineering
On the Relevance of Code Anomalies for Identifying Architecture Degradation Symptoms
CSMR '12 Proceedings of the 2012 16th European Conference on Software Maintenance and Reengineering
The TAME project: towards improvement-oriented software environments
IEEE Transactions on Software Engineering
Hi-index | 0.00 |
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.