A large-scale study of architectural evolution in open-source software systems

Behnamghader, Pooyan; Le, Duc Minh; Garcia, Joshua; Link, Daniel; Shahbazian, Arman; Medvidović, Nenad

doi:10.1007/s10664-016-9466-0

Cited by 50 publications

(33 citation statements)

References 37 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Their experiments show evidence that this proactive detection (as per JITTAC) is beneficial and leads to higher quality models and quicker inconsistency resolution. Another approach, proposed by Behnamghader et al, looked at the related field of assessing architecture change over a system's evolution, by comparing older versions of the architecture to newer versions of the architecture (Behnamghader et al 2016). They did so using metrics that quantified the amount of architectural change (a2a) and architectural overlap (measured at a component-implementation level: c2c) over time.…”

Section: Existing Approachesmentioning

confidence: 99%

“…When a software system's implementation diverges from its designed architecture, it is referred to as architectural drift or architectural erosion (De Silva and Balasubramaniam 2012). This usually happens during software evolution (Behnamghader et al 2016;Ming et al 2015) when the software undergoes changes as a result of bug fixes and updates, but may also happen during initial implementation of the system (Garlan and Schmerl 2004). Architectural drift can hinder evolution of systems, inhibit fulfilment of the goals of the architectural design (Bang and Medvidovic 2015) and, even if recognized, can prove costly to resolve (Knodel 2010).…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Architecture consistency: State of the practice, challenges and requirements

Alí

Baker

O’Crowley³

et al. 2017

Empir Software Eng

View full text Add to dashboard Cite

Architecture Consistency (AC) aims to align implemented systems with their intended architectures. Several AC approaches and tools have been proposed and empirically evaluated, suggesting favourable results. In this paper, we empirically examine the state of practice with respect to Architecture Consistency, through interviews with nineteen experienced software engineers. Our goal is to identify 1) any practises that the companies these architects work for, currently undertake to achieve AC; 2) any barriers to undertaking explicit AC approaches in these companies; 3) software development situations where practitioners perceive AC approaches would be useful, and 4) AC tool needs, as perceived by practitioners. We also assess current commercial AC tool offerings in terms of these perceived needs. The study reveals that many practitioners apply informal AC approaches as there are barriers for adopting more formal and Empir Software Eng (2018) 23:224-258 DOI 10.1007 The original version of this article was revised due to a retrospective Open Access order. Karlstad University, Karlstad, Sweden explicit approaches. These barriers are: 1) Difficulty in quantifying architectural inconsistency effects, and thus justifying the allocation of resources to fix them to senior management, 2) The near invisibility of architectural inconsistency to customers, 3) Practitioners' reluctance towards fixing architectural inconsistencies, and 4) Practitioners perception that huge effort is required to map the system to the architecture when using more formal AC approaches and tools. Practitioners still believe that AC would be useful in supporting several of the software development activities such as auditing, evolution and ensuring quality attributes. After reviewing several commercial tools, we posit that AC tool vendors need to work on their ability to support analysis of systems made up of different technologies, that AC tools need to enhance their capabilities with respect to artefacts such as services and meta-data, and to focus more on non-maintainability architectural concerns.

show abstract

Section: Existing Approachesmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Architecture consistency: State of the practice, challenges and requirements

Alí

Baker

O’Crowley³

et al. 2017

Empir Software Eng

View full text Add to dashboard Cite

show abstract

“…To the extent that we can show that some or all of these conditions are not satisfied, a given recovery method will be of limited use for the purposes of incremental development. We have therefore for the first time studied how several available recovery methods that have been used for studies such as [13], [22], [19] and [3] measure up against the criteria listed above. We have not directly measured their accuracy but instead addressed the utility of "ground truth" architectures.…”

Section: Recover Architecturementioning

confidence: 99%

The Value of Software Architecture Recovery for Maintenance

Link¹,

Behnamghader²,

Moazeni

et al. 2019

Proceedings of the 12th Innovations in Software Engineering Conference (Formerly Known as India Software Engineering Conference

Self Cite

View full text Add to dashboard Cite

In order to maintain a system, it is beneficial to know its software architecture. In the common case that this architecture is unavailable, architecture recovery provides a way to recover an architectural view of the system. Many different methods and tools exist to provide such a view. While there have been taxonomies of different recovery methods and surveys of their results along with measurements of how these results conform to expert's opinions on the systems, there has not been a survey that goes beyond a simple automatic comparison. Instead, this paper seeks to answer questions about the viability of individual methods in given situations, the quality of their results and whether these results can be used to indicate and measure the quality and quantity of architectural changes. For our case study, we look at the results of recoveries of versions of Android, Apache Hadoop and Apache Chukwa obtained by running PKG, ACDC and ARC.

show abstract

“…It enables analysis of the conflicts and synergies between different quality attributes and the difference between developers in terms of their impact on software quality. Our integrated tool‐based approach has been documented in multiple research publications empowering their empirical studies and is used by a major governmental entity.…”

Section: Squaad Toolsetmentioning

confidence: 99%

Anticipatory development processes for reducing total ownership costs and schedules

Boehm

Behnamghader

2019

Systems Engineering

Self Cite

View full text Add to dashboard Cite

Many systems and software processes overfocus on getting a project and product from an initial set of requirements to an Initial Operational Capability (IOC). Examples are most waterfall and V models. Projects following such processes may pass acceptance tests for functionality and performance, but may leave the product with serious maintainability shortfalls. Many agile processes focus on users' initial usage priorities, but often make development commitments for earlier needs that are incompatible with achieving later critical needs (eg, security, safety). Incremental development process models can do better, but often later increments may find that the earlier increments have not prepared them for ease of modification and repair. Besides increasing Total Ownership Costs (TOCs), long mean times to repair result in long downtimes, which can be critical to an organization's income and reputation. Furthermore, many of these shortfalls take the form of Technical Debt (TD), in that the later they are fixed, the more slow and expensive will be the fixes. This paper summarizes three process frameworks and tools providing more anticipatory ways to improve systems and software maintainability and life‐cycle cost‐effectiveness. The first framework is an Opportunity Tree for identifying and anticipating such ways. The second framework, Software Quality Understanding by Analysis of Abundant Data (SQUAAD), is a toolset for tracking a software project's incremental code commits, and analyzing and visualizing each commit's incremental and cumulative TD. The third framework is a Software/Systems Maintenance Readiness Framework (SMRF), that identifies needed maintenance readiness levels at development decision reviews, similar to the Technology Readiness Levels (TRLs) framework.

show abstract

A large-scale study of architectural evolution in open-source software systems

Cited by 50 publications

References 37 publications

Architecture consistency: State of the practice, challenges and requirements

Architecture consistency: State of the practice, challenges and requirements

The Value of Software Architecture Recovery for Maintenance

Anticipatory development processes for reducing total ownership costs and schedules

Contact Info

Product

Resources

About