Abstract: Enabling quick feature delivery is essential for product success and is therefore a goal of software architecture design. But how may we determine if and to what extent an architecture is “good enough” to support feature addition and modification, or determine if a refactoring effort is successful in that features may be added more easily? The applications may use Feature Space and Feature Dependency, derived from a software project's revision history that capture the dependency relations among the features of a system in a feature dependency structure matrix (FDSM), using features as first-class design elements. The applications may also use a Feature Decoupling Level (FDL) metric that may be used to measure the level of independence among features.

Abstract: Groups of architecturally connected files may incur and accumulate high maintenance costs as architectural debts. To quantify such debts, architectural debt, which is a term used herein, may be identified, quantified, measured, and modeled. A history coupling probability matrix for this purpose may search for architecture debts through the lens of 4 patterns of prototypical architectural flaws shown to correlate with reduced software quality. Further, a new architecture maintainability metric—Decoupling Level (DL)—measures how well the software can be decoupled into small and independently replaceable modules. The DL metric opens the possibility of quantitatively comparing maintainability between different projects, as well as monitoring architecture decay throughout software evolution.

Abstract: The method and system is called I-FAR: Interactive, Facet-based Architecture Recovery. Inspired by the idea that each system feature, pattern, or concern may have its own design space, the method defines a “facet” as a set of files that have one primary purpose, such as the implementation of a feature or the management of a cross-cutting concern such as performance, security, logging, etc.

Abstract: Enabling quick feature delivery is essential for product success and is therefore a goal of software architecture design. But how may we determine if and to what extent an architecture is “good enough” to support feature addition and modification, or determine if a refactoring effort is successful in that features may be added more easily? The applications may use Feature Space and Feature Dependency, derived from a software project's revision history that capture the dependency relations among the features of a system in a feature dependency structure matrix (FDSM), using features as first-class design elements. The applications may also use a Feature Decoupling Level (FDL) metric that may be used to measure the level of independence among features.

Abstract: Groups of architecturally connected files may incur and accumulate high maintenance costs as architectural debts. To quantify such debts, architectural debt, which is a term used herein, may be identified, quantified, measured, and modeled. A history coupling probability matrix for this purpose may search for architecture debts through the lens of 4 patterns of prototypical architectural flaws shown to correlate with reduced software quality. Further, a new architecture maintainability metric—Decoupling Level (DL)—measures how well the software can be decoupled into small and independently replaceable modules. The DL metric opens the possibility of quantitatively comparing maintainability between different projects, as well as monitoring architecture decay throughout software evolution.