Purpose:
The primary goal is supporting for identification ATD (Architecture Technical Debt) based on ADs (Architecture Decisions) made during the architecting process and change scenarios for software maintenance and evolution.
This approach considers that a change scenario “is a maintenance or evolution task to be performed in the software system“.
Therefore, the proposed approach “ takes ADs and change scenarios as input, and then comes up with ATD items that are caused by the ADs or negatively impact the change scenarios.”
How this technology can be used?
“In summary, the proposed approach is comprised of two parts: “a decision-based part and a scenario based part. The two parts can be executed in an arbitrary order. It is not mandatory to execute both parts. Instead, users may choose to execute one of the two parts and skip the other one. Since new ADs and change scenarios may be added during the execution of the approach, it can be executed iteratively to recheck those ADs and scenarios until the iteration in which no new ADs and change scenarios are added. Note that the execution of the ATD identification approach requires the project members (the architects, project manager, and development team members) to work together in a workshop, physically or virtually.“
Detailed instructions regarding how to use the ATD Identification Approach, their artifacts, and concerns can be found in Li, Liang, and Avgeriou (2015).
Prerequisite for use it: None.
Supported TD type(s): Architectural Debts.
Supported TDM activity (ies): Identification
Source/Input Artifact(s): Information and/or artifacts related to the archicteture of software products. Information and/or artifacts related to archicteture of software products.
Project Context, Programming Language or Domain Application: The using of ATD Identification Approach is independent of project context, programming language and domain application.
Evidence Type(s): Source(s): Case Study.
Reference: