Architectural Debt Management in Value-Oriented Architecting

Li, Zengyang; Liang, Peng; Avgeriou, Paris

doi:10.1016/b978-0-12-410464-8.00009-x

Cited by 44 publications

(40 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…On the one hand, the glossary incorporates the most important financial terms used in technical debt research and provides definitions that can be used by the technical debt community. On the other hand, the classification schema consists of three levels; the upper one constitutes of the existing categories of technical debt management [24], the middle one represents the financial techniques used, and the lower level depicts the used software engineering technologies, methods or tools. Additionally, the schema provides details on the popularity of each technique, term, method or tool, plus an evaluation of the techniques of level 2, based on their limitations when they are used in technical debt research.…”

Section: Discussionmentioning

confidence: 99%

“…studies), (b) we identified general distinguishing characteristics of the objects, and (c) we grouped their characteristics so as to create our classification schema [29]. Specifically, in step (b) we identified three characteristics that will constitute the three levels of the proposed schema: the 1st level of the schema represents the existing activities within technical debt management [24] -extracted variable:…”

Section: Classification Scheme For Financial Approaches Used For Manamentioning

confidence: 99%

See 1 more Smart Citation

The financial aspect of managing technical debt: A systematic literature review

Ampatzoglou

Chatzigeorgiou

Avgeriou

2015

Information and Software Technology

Self Cite

153

142

View full text Add to dashboard Cite

Section: Discussionmentioning

confidence: 99%

Section: Classification Scheme For Financial Approaches Used For Manamentioning

confidence: 99%

The financial aspect of managing technical debt: A systematic literature review

Ampatzoglou

Chatzigeorgiou

Avgeriou

2015

Information and Software Technology

Self Cite

153

142

View full text Add to dashboard Cite

“…We have provided evidence about the significant negative correlation between IPCI, IPGF and ANMCC, which means that a greater IPCI or IPGF is linked to a smaller ANMCC (indicator of the amount of ATD). Like ANMCC, IPCI and IPGF are also not absolute quantifiable measures of ATD, but they can be used to relatively suggest whether one version of a software system has more or less ATD than another version [10]. This way, architects and project managers can get informed about the potential ATD of the software system.…”

Section: Implications For Practitionersmentioning

confidence: 98%

“…Management of ATD entails identifying and measuring it, so that it can be monitored and eventually repaid [10]. However, in practice ATD is difficult to identify and measure, since ATD does not yield observable behaviors to end users [3; 10; 16].…”

Section: Introductionmentioning

confidence: 99%

An empirical investigation of modularity metrics for indicating architectural technical debt

Liang

Avgeriou

et al. 2014

Proceedings of the 10th International ACM Sigsoft Conference on Quality of Software Architectures

Self Cite

View full text Add to dashboard Cite

Architectural technical debt (ATD) is incurred by design decisions that consciously or unconsciously compromise system-wide quality attributes, particularly maintainability and evolvability. ATD needs to be identified and measured, so that it can be monitored and eventually repaid, when appropriate. In practice, ATD is difficult to identify and measure, since ATD does not yield observable behaviors to end users. One indicator of ATD, is the average number of modified components per commit (ANMCC): a higher ANMCC indicates more ATD in a software system. However, it is difficult and sometimes impossible to calculate ANMCC, because the data (i.e., the log of commits) are not always available. In this work, we propose to use software modularity metrics, which can be directly calculated based on source code, as a substitute of ANMCC to indicate ATD. We validate the correlation between ANMCC and modularity metrics through a holistic multiple case study on thirteen open source software projects. The results of this study suggest that two modularity metrics, namely Index of Package Changing Impact (IPCI) and Index of Package Goal Focus (IPGF), have significant correlation with ANMCC, and therefore can be used as alternative ATD indicators.

show abstract

“…Architectural technical debt refers to the consequences faced late in the software development process due to suboptimal architecture decisions and trade‐offs. () Software teams accumulate architectural technical debt due to their own actions and due to external events related to natural software aging and evolution. Even though technical debt related to coding issues can be detected using various tools, architecture technical debt mostly remains invisible and grows over time .…”

Section: Background and Motivationmentioning

confidence: 99%

Impact of requirements volatility on software architecture: How do software teams keep up with ever‐changing requirements?

Dasanayake

Aaramaa

Markkula

et al. 2019

J Software Evolu Process

View full text Add to dashboard Cite

Requirements volatility is a major issue in software development, causing problems such as higher defect density, project delays, and cost overruns. Software architecture that guides the overall vision of software product is one of the areas that is greatly affected by requirements volatility. Since critical architecture decisions are made based on the requirements at hand, changes in requirements can result significant changes in architecture. With the wide adoption of agile software development, software architectures are designed to accommodate possible future changes. However, the changes has to be carefully managed as unnecessary and excessive changes can bring negative consequences. An exploratory case study was conducted to study the impact of requirements volatility on software architecture. Fifteen semistructured, thematic interviews were conducted in a European software company. The research revealed poor communication, information distortion, and external dependencies as the main factors that cause requirement volatility and inadequate architecture documentation, inability to trace design rationale, and increased complexity as the main implications of requirements volatility on software architecture. Insights from software teams' awareness of the requirement volatility, factors contribute to it, and possible ways to mitigate its implications will be utilized to improve the management of requirement volatility during software architecting process. KEYWORDS requirements management, requirements volatility, software architecture, software teams INTRODUCTIONRequirements are added, deleted, and modified throughout the software development life cycle. Despite being seen as a natural characteristic of software projects, improper management of requirement changes can have adverse consequences on project cost, schedule, and quality of the resulting product. 1 Therefore, uncertain requirements are identified as one of the main factors that contribute to project failures. 2 While it is widely accepted that requirements changes are inevitable, significance of the potential consequences demands software teams to be aware of its existence, factors, and impacts. 3 Multiple terms including requirements change, requirements uncertainty, requirements instability, and requirements volatility are commonly associated with or related to the same phenomenon. 1,4 Requirements volatility is selected as the preferred term to be used in this study, as it not only indicates the change of requirements but also highlights their fragile nature and the potential to be changed.Software architecture that guides the overall vision of the software product is one of the areas that is greatly affected by requirements volatility. 5,6 Software architecture plays a prominent role in software development and acts as the foundation of the software systems that shapes the final outcome. Making suboptimal architecture decisions can decrease system quality and cause problems later on. 7 Since critical architecture decisions are primarily made base...

show abstract

Architectural Debt Management in Value-Oriented Architecting

Cited by 44 publications

References 11 publications

The financial aspect of managing technical debt: A systematic literature review

The financial aspect of managing technical debt: A systematic literature review

An empirical investigation of modularity metrics for indicating architectural technical debt

Impact of requirements volatility on software architecture: How do software teams keep up with ever‐changing requirements?

Contact Info

Product

Resources

About