Need for architecture recovery in OSS

Purpose: An architecture represents the components and connections between components of a software system. However, current software industry strategies such as small release time and quick delivery of products in the market lead to negligence of design-time architectural guidelines during development. This results in architectural erosion/decay of software and hinders its growth and maintenance. Moreover, knowledge of a software program's architecture is beneficial during its maintenance. In cases where such architecture is unavailable, software architecture recovery techniques play an important role by providing an idea of the original architecture of the software. In the literature, there exist several tools and techniques related to the architecture recovery of a software system and the total literature volume is huge. Therefore, the purpose of this research article is to summarize and present this literature knowledge by carrying out a literature survey of the solutions proposed for recovering software architectures. Method: The chapter considers performing a systematic literature survey (SLS) by following standard guidelines and protocols. Appropriately following standard guidelines and protocols enables the identification and aggregation of primary sources, inclusion, and exclusion of papers in accordance with previously described criteria, a systematic investigation of data, and synthesis of the papers. The SLS consists of three main steps that are followed sequentially, namely, (1) planning, (2) analysis (conducting), and (3) reporting (documentation). Results: The main aim behind carrying out an SLS in this chapter and results presented are related to answer questions that focus on the WHAT, WHY, and HOW of the software architecture recovery process. The questions formulated under the WHAT category are related to architecture recovery techniques/frameworks/mechanisms available in the literature and what standard datasets are used by different researchers to validate proposed approaches in the literature. The WHY category aims at identifying possible reasons for software architecture erosion/degradation. Finally, the HOW category is related to identifying different mechanisms available in the literature to validate any architectural recovery technique. Conclusion: The carried-out SLS is definitely going to encourage researchers and practitioners to carry out more deep-rooted study to find out reasons for architectural decay and improve recovery techniques. It is the strong belief of the authors that the carried-out study is helpful to researchers and practitioners for carrying out a more controlled empirical evaluation of their proposed approaches.