Finding Architectural Debt in Historical Data

Abstract

The metaphor Technical Debt (TD) is the description of a sacrifice made in the software development in order to reach a short term goal. For example, implementing a suboptimal solution in a software product in order to meet a deadline. TD can be created both intentionally and unintentionally and are often hard to identify. This is especially the case when the debts exist in the architecture since they are not as visible as for example badly written code. When left unidentified, the debts are accumulating in unexpected costs such as higher maintenance but more importantly increased lead time in new development. And after a time, expensive and comprehensive refactoring activities are needed. It is often the case that budget constraints prohibit complete refactoring activities. Therefore, it is necessary to focus on fixing the problems that are the worst, i.e. prioritizing the debts. This master thesis has conducted a case study at Ericsson with the goal to find methods that can both identify and prioritize Architectural Technical Debts (ATD). The results from this work includes a Measurement System (MS) developed by the ISO standard 15939 which successfully identifies ATD:s in the form of non-allowed dependencies. Additionally, the MS prioritizes the dependencies based on how high risk they have of being difficult-to-maintain.