Identifying and quantifying architectural debt

Xiao, Lu; Cai, Yuanfang; Kazman, Rick; Mo, Ran; Feng, Qiong

doi:10.1145/2884781.2884822

Cited by 77 publications

(54 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We also found studies that have investigated the use of information other than code smells to identify design problems (44,45). In this case, Mo et al (44) proposed and evaluated the combination of structural, history and design information to identify potential design problems.…”

Section: Related Workmentioning

confidence: 96%

“…Our goal is to observe them working in practice, allowing us to find other symptoms that they may use. Indeed, there is a high chance that developers use other symptoms, which explains why other studies focused on proposing techniques that rely on other indicators (44,40,59,42,45). Unfortunately, this is knowledge that we do not have.…”

Section: Goal and Research Questionsmentioning

confidence: 98%

“…Furthermore, they consulted developers, who mentioned that these patterns comprised design problems. Posteriorly, Xiao et al expanded the DRSpace notion to include a conditional probability of a file change (45). Thus, they built a regression model to approximate the probabilities of change propagation among files.…”

Section: Techniques To Identify Design Problemsmentioning

confidence: 99%

“…In this case, Mo et al (44) proposed and evaluated the combination of structural, history and design information to identify potential design problems. Xiao et al (45) introduced an approach that uses a history coupling probability matrix to identify and quantify design problems. However, one disadvantage of such studies is they rely on design information, which may not exist for many software systems.…”

Section: Related Workmentioning

confidence: 99%

“…Unfortunately, there is limited understanding about how developers identify design problems in practice, in particular when the source code is the only artifact available in a project. Existing studies tend to focus on proposing solutions for assisting developers in identifying design problems (26,52,53,38,28,47,27,46,56,45). However, such proposed solutions may be misaligned with how developers identify design problems in practice.…”

Section: Investigating How Developers Identify Design Problemsmentioning

confidence: 99%

See 4 more Smart Citations

Understanding How Developers Identify Design Problems in Practice

SOUSA¹

View full text Add to dashboard Cite

Section: Related Workmentioning

confidence: 96%

Section: Goal and Research Questionsmentioning

confidence: 98%

Section: Techniques To Identify Design Problemsmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Investigating How Developers Identify Design Problemsmentioning

confidence: 99%

See 3 more Smart Citations

Understanding How Developers Identify Design Problems in Practice

SOUSA¹

View full text Add to dashboard Cite

A critical assessment of the design issues in e‐commerce systems development

Ehikioya

Guillemot

2020

Engineering Reports

View full text Add to dashboard Cite

Designers of electronic commerce (e-commerce) transaction system applications face many challenges; some are old while others are emerging because of the emerging nature of the e-commerce domain itself. This article examines the critical design challenges at different stages of the design process of e-commerce applications. The high-level designs have a large number of new issues specific to Web applications. Among them, the security and networking problems are the most determinant for the success of the applications. At the detailed design level, the languages and the user interface are major concerns. The user interface, specific to the Web, forces designers to redefine the traditional concept of the end user for the more appropriate customer-centric concept. This is necessary to address the needs of consumers and for the survival of e-commerce businesses.In addition, we also examine issues bothering the development team and the e-commerce environment. Designers experienced in non-Web applications can be more successful at developing e-commerce applications if they address the issues we identified in this article in a creative way. K E Y W O R D Sdesign issues, e-commerce, e-commerce systems/application INTRODUCTIONThe concept of electronic commerce (e-commerce) has crystallized into a fairly well understood concept 1-7 ; its popularity and fast paced acceptance as an alternative to the brick and mortar market economic model 3,8 tend to undermine a clear understanding, and clear exposition of the characteristics, of e-commerce. Most adherents of e-commerce often focus only on the exchange of value end product 6,7 without paying close attention to, or knowing the intricacies of, the underlying transaction itself. 1,4,[9][10][11][12][13] Therefore, a proper characterization of e-commerce applications is fundamental. We focus on the design challenges in e-commerce transactions in a typical business-to-consumer (B2C) e-commerce domain, which is more popular, more widely patronized by users, and attracts a higher volume of e-commerce transactions. The B2C e-commerce includes retail transactions of products or services from businesses to individual shoppers (ie, businesses sell products or services to individual consumers). Thus, the seller is a business organization whereas the buyer is a consumer.

show abstract

The Nature of Technical Debt in the Development of Descriptive Models for MBSE

Noguchi

2024

INCOSE International Symp

View full text Add to dashboard Cite

Model‐Based Systems Engineering (MBSE) is the growing practice of systems engineering (SE) in which descriptive models replace documents as the embodiment of SE knowledge. These descriptive models capture SE information in place of documents, are developed in a similar manner to software source code, and are encoded and used in machine‐to‐machine applications as data. This paper describes how the Technical Debt concept widely used in the software domain—rework deferred to the future for expediency—needs to be modified for the domain of descriptive models. Technical Debt is often associated with agile development practices of software or descriptive models, which emphasize the rapid creation and iterative evolution of a Minimum Viable Product (MVP). Consciously applying appropriate modeling principles and practices is essential to make informed decisions during the modeling process to prevent the accumulation of excessive model Technical Debt—particularly during this iterative evolutionary process—which can require substantial rework to correct. The paper establishes a foundation for characterizing the Technical Debt implications of key model architecture and implementation decisions that are made explicitly or implicitly by modelers when developing descriptive models. To illustrate the model Technical Debt concept, several examples of modeling principles pertaining to model purpose and implementation are described along with their implications on model Technical Debt.

show abstract

Identifying and quantifying architectural debt

Cited by 77 publications

References 28 publications

Understanding How Developers Identify Design Problems in Practice

Understanding How Developers Identify Design Problems in Practice

A critical assessment of the design issues in e‐commerce systems development

The Nature of Technical Debt in the Development of Descriptive Models for MBSE

Contact Info

Product

Resources

About