Zengyang Li

Architectural Debt Management in Value-oriented Architecting

Architectural technical debt (ATD) may be incurred when making architecture decisions. In most cases, ATD is not effectively managed in the architecting process: It is not made explicit, and architecture decision making does not consider the ATD incurred by the different design options. This chapter proposes a conceptual model of ATD and an architectural technical debt management process applying this ATD conceptual model in order to facilitate decision making in a value-oriented perspective of architecting. We also demonstrate how ATD management can be employed in architectural synthesis and evaluation in a case study. The contribution of this work provides a controllable and predictable balance between the value and cost of architecture design in the long term.

An empirical investigation of modularity metrics for indicating architectural technical debt

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.

Architectural Technical Debt Identification Based on Architecture Decisions and Change Scenarios

Architectural technical debt (ATD) is incurred by design decisions that intentionally or unintentionally compromise system-wide quality attributes, particularly maintainability and evolvability. ATD is harmful to the systems long-term health, thus it needs to be identified for further management. However, existing ATD identification approaches are mainly based on source code analysis and thus suffer from certain shortcomings: they can only identify issues at the system implementation, they can only be employed after the systems is implemented in code, they lack a mechanism to confirm whether the potential ATD identified is real ATD or not. To address these issues, we proposed an ATD identification approach based on architecture decisions and change scenarios. To evaluate the effectiveness and usability of this approach, we conducted a case study with an information system in a large telecommunications company. The results show that the proposed approach is useful and easy to use, and it supports release planning and ATD interest measurement.

Architectural design decision visualization for architecture design: preliminary results of a controlled experiment

Visualization of architectural design decision (ADD) and its rationale, as a kind of traceability information, is supposed to facilitate the understanding of architecture design and the reasoning behind the design rationale, which is supposed to improve the architecting process and gets better architecture design results. But the lack of empirical evaluation that supports this statement prevents industrial practitioners from using ADD visualization in their daily architecting activities. In this paper, we conducted a controlled experiment to investigate how visualization of ADD can improve the understanding of architecture design by using Compendium, an open source tool for rationale visualization. The preliminary results show that visualization of ADD and its rationale does not increase the total time for reading architecture document (including visualization diagrams of ADDs) plus designing task, and it improves the understanding of architects on existing architecture design with better new design results.

Architecture viewpoints for documenting architectural technical debt

Abstract Technical debt (TD) has attracted an increasing interest from researchers and practitioners in the software engineering domain. Currently, most approaches to managing TD focus on dealing with TD at source code level, while few methods deal with TD at architecture level. If architectural technical debt (ATD) is not effectively managed in the architecting process, the knowledge about ATD is not made available to involved stakeholders and the impact of ATD is not considered during architecture decision-making. Thus, the system’s maintainability and evolvability can be intentionally or unintentionally compromised. As a result, architectures are costly to maintain and new features are difficult to introduce. To facilitate the management of ATD, it needs to be documented so that it becomes explicit to stakeholders. To this end, we propose a set of architecture viewpoints related to ATD (ATD viewpoints in short). Each viewpoint frames a number of concerns related to ATD. These ATD viewpoints together help to get a comprehensive understanding of ATD in a software system, thereby providing support for architecture decision-making. To evaluate the effectiveness of the ATD viewpoints in documenting ATD, we conducted a case study in a large telecommunications company. The results of this case study show that the documented ATD views can effectively facilitate the documentation of ATD. Specifically, the ATD viewpoints are relatively easy to understand; it takes an acceptable amount of effort to document ATD using the ATD viewpoints; and the documented ATD views are useful for stakeholders to understand the ATD in the software project.

Technical debt in MDE: a case study on GMF/EMF-based projects

Technical Debt (TD) is a metaphor referring to immature software artifacts that can hurt the long-term maintenance of a system. Model-Driven Engineering (MDE) is a model-centric software development approach, which promises better maintainability. However, there is a lack of empirical evidence on the existence and influence of TD in the context of MDE. This paper investigates the code-level TD in MDE projects, which is incurred during code generation. We evaluated 16 open-source and non-trivial GMF/EMF-based MDE projects using bad smells, which are widely-accepted TD indicators. The results demonstrate that MDE is not TD-free, and code generators also incur TD, similarly to developers. In fact, the generated code usually contains more TD than handwritten code, which influences significantly the maintenance of MDE projects.

Do architectural design decisions improve the understanding of software architecture? two controlled experiments

Architectural design decision (ADD) and its design rationale, as a paradigm shift on documenting and enriching architecture design description, is supposed to facilitate the understanding of architecture and the reasoning behind the design rationale, which consequently improves the architecting process and gets better architecture design results. But the lack of empirical evaluation that supports this statement is one of the major reasons that prevent industrial practitioners from using ADDs in their daily architecting activities. In this paper, we conducted two controlled experiments, as a family of experiments, to investigate how presence of ADDs can improve the understanding of architecture. The main results of our experiments are: (i) using ADDs and their rationale in architecture documentation does not affect the time needed for completing architecture design tasks; (ii) one experiment and the family of experiments achieved a significantly better understanding of architecture design when using ADDs; and (iii) with regard to the correctness of architecture understanding, more experienced participants benefited more from ADDs in comparison with less experienced ones.Welcome to the 25th International Conference on Program Comprehension! This silver jubilee has seen several first times for ICPC. It is for the very first time that ICPC has been organised in South America, in Argentina, in Buenos Aires. Moreover, it is also for the first time that the main track of ICPC crossed the line of 80 submissions. This year the program committee has received 83 submissions originating from 97 abstracts and co-authored by researchers from 26 countries from Africa, Asia, Europe, North and South America and Oceania. This is more than double of the 39 submissions received back in 2000.1 Finally, for the very first time in the history of ICPC we have implemented the triple-blind reviewing process: the authors do not know who is reviewing their work (single), the reviewers do not know whose work they review (double), and the reviewers do not know who the other reviewers are (triple).

Automatic Detection of Public Development Projects in Large Open Source Ecosystems: An Exploratory Study on GitHub.

Hosting over 10 million of software projects, GitHub is one of the most important data sources to study behavior of developers and software projects. However, with the increase of the size of open source datasets, the potential threats to mining these datasets have also grown. As the dataset grows, it becomes gradually unrealistic for human to confirm quality of all samples. Some studies have investigated this problem and provided solutions to avoid threats in sample selection, but some of these solutions (e.g., finding development projects) require human intervention. When the amount of data to be processed increases, these semi-automatic solutions become less useful since the effort in need for human intervention is far beyond affordable. To solve this problem, we investigated the GHTorrent dataset and proposed a method to detect public development projects. The results show that our method can effectively improve the sample selection process in two ways: (1) We provide a simple model to automatically select samples (with 0.827 precision and 0.947 recall); (2) We also offer a complex model to help researchers carefully screen samples (with 63.2% less effort than manually confirming all samples, and can achieve 0.926 precision and 0.959 recall).

Relating alternate modifications to defect density in software development

A software developer tends to spend more effort to understand source code written by other developers than code written by herself. Existing research studying the impact of changes made by multiple developers on bug proneness did not consider quantitatively the influence of the order of the changes made by different developers. We found that a significant proportion of source files in many open source software systems had been modified alternately by different developers. We developed a metric, namely alternate modification index (AMI), to indicate the extent to which a source file is modified alternately by multiple developers. Our preliminary case study results show that AMI of source files has a strong positive correlation with their defect density.

Developer Role Evolution in Open Source Software Ecosystem: An Explanatory Study on GNOME

An open source software (OSS) ecosystem refers to an OSS development community composed of many software projects and developers contributing to these projects. The projects and developers co-evolve in an ecosystem. To keep healthy evolution of such OSS ecosystems, there is a need of attracting and retaining developers, particularly project leaders and core developers who have major impact on the project and the whole team. Therefore, it is important to figure out the factors that influence developers’ chance to evolve into project leaders and core developers. To identify such factors, we conducted a case study on the GNOME ecosystem. First, we collected indicators reflecting developers’ subjective willingness to contribute to the project and the project environment that they stay in. Second, we calculated such indicators based on the GNOME dataset. Then, we fitted logistic regression models by taking as independent variables the resulting indicators after eliminating the most collinear ones, and taking as a dependent variable the future developer role (the core developer or project leader). The results showed that part of such indicators (e.g., the total number of projects that a developer joined) of subjective willingness and project environment significantly influenced the developers’ chance to evolve into core developers and project leaders. With different validation methods, our obtained model performs well on predicting developmental core developers, resulting in stable prediction performance (0.770, F-value).