English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Tools annual

Global: Zendy Free Plan

Global: Zendy Tools monthly

Global: Zendy Plus monthly

As software systems evolve over a series of releases, it becomes important to know which components are stable compared to components that show repeated need for corrective maintenance. The latter is a sign of code decay. Code decay can be due to the deterioration of a single component. In this case it manifests itself in repeated and increasing problems that are local to the component. A second type of code decay is due to repeated problems that become increasingly di cult to x and are related to interactions between components. That is, components are repeatedly faultprone in their relationships with each other. The latter requires repairs in multiple components and is a sign of problems with the software architecture of the system. Software architecture problems are by far more costly to x and thus it is very desirable to identify potential architectural problems early and to track them across multiple releases. To do this, we adapt a reverse architecting technique to defect reports of a series of releases. Fault relationships among system components are identi ed based on whether they are involved in the same defect report, and for how many defect reports this occurs. There are degrees of fault-coupling between components depending on how often these components are involved in a defect x. After these fault-coupling relationships between components are extracted, they are abstracted to the subsystem level. We also identify a measure for fault cohesion (i.e. faultproneness of components locally.) The resulting fault architecture gures show for each release what its most fault-prone relationships are. Comparing across releases makes it possible to see whether some relationships between components are repeatedly faultprone, indicating an underlying systemic architecture problem. We illustrate our technique on a large commercial system consisting of over 800 KLOC of C, C++, and microcode. Copyright c 2000 John Wiley & Sons, Ltd.

Deriving fault architectures from defect history