IN DEGREE PROJECT TECHNOLOGY,FIRST CYCLE, 15 CREDITS

, STOCKHOLM SWEDEN 2021

A case study on pragmatic software reuse

ELENA GONCHARUK

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

A case study on pragmaticsoftware reuse

Elena Goncharuk

Supervisor: Patric Dahlqvist Examiner: Fredrik Kilander

Degree Programme in Information and Communication Technology

School of Electrical Engineering and Computer Science

KTH Royal Institute of Technology

June 1, 2021

Abstract

Software reuse became a very active and demanding research area. The research on thistopic is extensive, but is there is gap between theory and industrial reuse practices. Thereis a need to connect the theoretical and practical aspects of reuse, especially on the topic ofthe reuse which is not performed in a planned, systematic manner.

This case study investigates a real-world case of pragmatic software reuse with help of anexisting academic research. The investigation includes a literature study on software reuseprocesses which are summarised in a form of a general process model of pragmatic softwarereuse. A case of pragmatic reuse performed in the industry is then analysed and comparedto the proposed model, as well additional academic research. The real-world reuse processis shown to closely follow the proposed general model.

Sammanfattning

Ateranvandning av mjukvara ar ett kravande och valdigt aktivt forskningsomrade. Detforskas mycket i amnet, men det finns en glipa mellan teorin och hur ateranvandning gartill i industriella miljoer. Det finns ett behov av att koppla samman teoretiska och prak-tiska aspekter av ateranvandning, speciellt for sadan som ar inte utford pa ett planerat,systematiserat satt.

Den har fallstudien undersoker ett fall av pragmatisk mjukvaruateranvandning i prak-tiken med hjalp av existerande akademisk forskning. Den inkluderar en litteraturstudie omateranvandningsprocesser som sammanfattas i en form av en generell processmodell av prag-matisk ateranvandning. Ett industriexempel pa sadan process sedan analyseras och jamforasmed processmodellen och annan akademisk forskning. Det analyserade ateranvandningsfalli praktiken har visat dig att stamma val overens med den generella processmodellen.

Contents

1 Introduction 3

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.6 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Theoretic Background 5

2.1 Software reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Case-related information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Software testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.2 Radio Base Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Erlang Common Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.4 Java Common Auto Tester . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Methodology 9

3.1 Research process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Design and preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.6 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Software reuse processes 13

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Early frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 Artifact repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4 Domain Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.5 Software Product lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.6 Service-Oriented Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.7 Reengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Pragmatic reuse 17

5.1 Existing research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2.1 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2.2 Code analysis and adaptation . . . . . . . . . . . . . . . . . . . . . . . 18

5.2.3 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1

6 Pilot project 196.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.3 Test case analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.4 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Project results 237.1 Test case allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237.2 Test cases with unsupported functionality . . . . . . . . . . . . . . . . . . . . 237.3 Overlapping between the systems . . . . . . . . . . . . . . . . . . . . . . . . . 247.4 Summary and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8 Analysis 25

9 Summary 279.1 Revisiting research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . 279.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2

Chapter 1

Introduction

The software has become an integral part of our lives in many aspects such as banking,automation, remote work, e-commerce and online schooling. Due to the high demand forsoftware and growing complexity in IT industries, software reuse became a very active anddemanding research area. Most of the research, however, is focused on the academic aspectsof software reuse. This thesis presents a case study on the software reuse performed in anindustrial setting.

1.1 Background

Software programming is a highly specialized and intellect-oriented task mainly due to thecomplexity involved in the process. As the demand and functionality requirements growexponentially, we can no longer afford to custom-develop every system. On the other hand,reusing various software has never been easier, thanks to the internet and the increasedavailability of open-source software. Reusing existing artifacts while developing new softwareis an attractive way to reduce development time and decrease defect density[1]. To get thesebenefits, industry and different organizations promote reuse during software development.Academia has also been investigating reuse as the solution for many problems plaguingsoftware engineers. However, reusing software comes with various challenges that includearchitecture mismatch between components, artifact misuse[2] and the lack of research onreuse in practice[3].

1.2 Problem

Most of the research on software reuse covers its purely theoretical aspects. There is someliterature on software reuse in real-world applications, but more information is needed,specifically on a more spontaneous form of software reuse called pragmatic reuse[4]. Prag-matic reuse involves ad-hoc reuse of artifacts that were not built for reuse[3]. There is a gapbetween theoretical process models and real-world reuse practices of such reuse. Processesare abstract, and there is a need to connect the theoretical and practical aspects of prag-matic reuse. Thus, this study examined two research questions that are further explored inChapter 3:

RQ1 What might pragmatic reuse practices look like?

RQ2 How does pragmatic reuse in practice relate to the theoretical process?

1.3 Purpose

The purpose of this thesis is to investigate and analyze the pragmatic reuse process performedduring a real-life case in an industrial setting using available research on reuse processes.The thesis describes a case study of reuse in the telecommunications industry: a pilot projecton test reuse carried out at Ericsson.

3

1.4 Goal

This work aims to achieve a better understanding of how pragmatic reuse is performed, bothin a theoretical and practical sense. The resulting insights may help software developers tocarry out pragmatic reuse more effectively and with better success. The main focus of thisstudy is on a one-time-only reuse process that is done simultaneously with regular productdevelopment.

1.5 Methodology

The case study mainly consisted of two parts: a literature review of software reuse processesand an investigation of a real-world case of pragmatic reuse. The research methodology isdescribed more thoroughly in Chapter 3.

1.6 Delimitations

The main problem of this study was a lack of literature on pragmatic reuse process models.Another issue is that the object of this study, a pilot project at Ericsson, had already beencompleted at beginning of the study. Thus, the study had to rely on the project docu-mentation to understand the reuse process. There was no opportunity for observation ofthe developers, which is routinely performed during case studies. Additionally, the circum-stances of this project are specific and one-time-only, which is why this study would be hardto replicate. This issue, however, is common for the case studies as they highly depend onthe context. Finally, this study had only analyzed one real-world case of pragmatic reuse,which may reduce the relevance of a general process model analysis. This can be addressedwith future work.

1.7 Outline

The rest of the thesis presented as follows. Chapter 2 covers the theoretical backgroundneeded for this study, along with related work. In Chapter 3, the methodology for thiscase study is presented. Chapter 4 provides an overview of software reuse processes, whileChapter 5 focuses on the pragmatic reuse process and presents the process model. Chapter6 describes how the pilot project was executed. Project results are covered in Chapter7. Chapter 8 presents the analysis of the project’s reuse process in relation to both thepragmatic reuse process model and other academic research. Finally, Chapter 9 summarisesthe case study and suggestions for future work.

4

Chapter 2

Theoretic Background

This chapter starts with a brief introduction to software reuse. After that, informationrelated to the case of this study is presented, which includes basics of software testing,System Under Test (SUT) and testing frameworks relevant to the pilot project.

2.1 Software reuse

Software reuse is defined as a process of creating software from preexisting software artifactsinstead of creating them from scratch[3]. Reuse applies not only to source code but to allintermediate work products generated during software development. They vary, rangingfrom those found in the requirements phase to the design phase and the implementationand testing phases. The artifacts include requirements, architectural and design patterns,domain architecture, elements of the user interface, test case suites, code documentation andany information the developer needs to create software. Also, the production of multipleparallel versions of the same program or subsystem, which operate for different users and/orin several applications, can be considered a form of reuse.

There is a varied set of opinions and approaches to software reuse. Reuse can be classifiedby how it is conducted (as systematic/planned or pragmatic/ad-hoc). Systematic reuseencompasses an institutionalized organizational approach where assets are purposely createdor acquired and then used to construct new software systems in a planned formal way. Onthe other hand, pragmatic reuse is an activity with little or no planning that is dependent onindividual knowledge and initiative where existing artifacts are selected without a definedprocedure. Usually, it is not deployed consistently throughout the organization[5].

Classification by intention defines reuse by how the artifacts are reused. In black-boxreuse, the artifact is reused without changes, whereas in white-box reuse the artifact ismodified to fit the target product[5].

Software reuse can also be categorized by the artifact’s initial purpose, namely devel-opment for reuse and development with reuse. The former refers to the development ofartifacts designed for later reuse in other systems, while the latter deals with how existingreusable artifacts can be used in existing and new applications and systems[6].

Software reuse results in significant improvements in software productivity by reducingdevelopment time and required cognitive effort[7][3]. It requires fewer people than to developoriginal software. It also reduces software development and maintenance costs. By usingcomponents that are pre-tested and proven to have high quality, reuse improves the softwarequality and reliability[6].

2.2 Case-related information

This section provides information relevant to the case of this study, a pilot project performedat Ericsson. Ericsson is a Swedish company that produces telecommunication equipment.The project aimed to reuse software tests by moving them from one testing framework tothe other. Consequently, this section provides information on software testing, SUT andboth testing frameworks.

5

2.2.1 Software testing

Software applications are complex products that may exhibit unexpected and undesiredbehavior. Software testing represents actions that are needed to be performed to confirmthat software is reliable. Automation testing comes with its advantages and disadvantages.Studies show that the main advantages of automation in software testing are the reusabilityof test cases and a reduced amount of time needed for test execution. Its drawbacks are costsinvolved in buying the tools, training employees and designing test cases. In this thesis, atest case is regarded as a series of test steps that should be executed in a specific order. Atest step consists of a stimulus and an expected reaction. A test suite is a set of test casesperformed in succession.

Software testing techniques can be classified based on the source of information usedto derive test cases. Using that criterion software testing can be described in two ways:black-box testing and white-box testing[8]. With the black-box approach, the tester doesnot consider the internal logical structure and focuses on what SUT is supposed to do[9].A description of its behavior may come from a formal specification or a well-defined set ofpre- and post-conditions. The tester determines if the outputs produced by the tests areequivalent to those in the specification. Since the black-box testing only considers softwarebehavior and functionality, it is often called functional or specification-based testing[8].On other hand, white-box (or glass-box) testing takes into account the way software isimplemented. To design test cases using this strategy, the tester must have a knowledge ofthe internal logical structure[9]. The tester selects test cases to exercise specific structuralelements to determine if they are working correctly[8].

2.2.2 Radio Base Station

Software tested in the project is for the Radio Base Stations (RBS), a commercial namegiven to the family of mobile telephony (base transceiver stations) developed by Ericsson.RBS is responsible for handling traffic between a mobile phone and the GSM network. Thecurrent main focus of RBS software development is implementing a fifth-generation (5G) ofmobile telephony technology, which is being deployed around the world[10].

2.2.3 Erlang Common Test

Common Test (CT) is one of the standard Erlang frameworks for automated testing[11]. Itsupports distributed testing, which is very useful for large-scale testing. CT is widely usedwithin Ericsson with the amount of approximately 18 000 implemented test cases. In CT,test cases are defined as single functions. A test suite is a module that contains a set ofrelated test cases. Test cases within a suite can be grouped to alter the running order orenable parallel execution.

CT allows users to extend its default behavior by using a Common Test Hook (CTH)framework. A hook is used to manipulate configuration functions and test results[12]. A setof CTHs is developed by Ericsson to support different operations on RBS, such as upgradesupport, access to REST services and Remote Procedure Calls (RPCs).

2.2.4 Java Common Auto Tester

Java Common Auto Tester (JCAT) is a Java-based test automation framework that extendsthe functionality of TestNG (a popular Java-based unit testing framework)[13] and JUnit(test case execution engine)[14]. JCAT is an inner-source tool (i.e. open-source withinEricsson) developed by the largest community within Ericsson. JCAT is a lightweight,flexible and low maintenance framework. It can be used by either creating new extensionsor reusing existing ones. Users can pick only a selected number of modules to use.

2.3 Related work

The research on software reuse processes revealed an abundance of information on systematicreuse. Several researchers have previously explored this area. For instance, Frakes and Kanggave an insight into active areas of software reuse research. Their paper provided valuable

6

information on product line and domain engineering[1]. In 2005, Almeida et al. conducteda survey on software reuse processes[15], describing eleven reuse processes. All of them weresystematic in nature.

Walker and Cotrell conducted a survey on how pragmatic reuse is performed by industrialsoftware developers. They found out that developers perform pragmatic reuse frequently,and the majority carefully investigate the originating system before reuse[16]. Some infor-mation on the generic pragmatic reuse process is provided by Krueger et al.[7] and Maraset.al.[17]

In 2013, Petter Isberg and Thomas Akerlund researched a way to integrate CT test casesinto JCAT[18]. In the thesis, they tried to find a way to execute CT test cases from JCATand send the test results back to JCAT for evaluation and logging. Their report provideda lot of information on both frameworks, and the way test cases are executed. The pilotproject can be viewed as a continuation of their thesis since the integration was a temporarysolution before moving tests to JCAT.

7

8

Chapter 3

Methodology

This chapter presents the research methodology for this case study. First, the choice of thecase study as a research method is discussed. Then, the case study steps are presented. Atlast, the validity of this study and ethical considerations are discussed.

3.1 Research process

The purpose of this thesis project was to investigate the pragmatic reuse process, includingits application in a real-world setting. With this in mind, a case study was chosen asthe research method as it allows for a more practical and hands-on connection to real life.According to Runeson and Host, a case study ”is an empirical method aimed at investigatingcontemporary phenomena in their context” [19]. To ensure the resulting quality, this casestudy was conducted according to the guidelines defined by Runeson and Host[19].

3.2 Design and preparation

The objective of the study was to analyze the pragmatic reuse process in the industry and itsconnection to the theoretical process models. Based on this objective, two research questionswere formulated.

RQ1 What might pragmatic reuse practices look like?

This RQ includes two relevant aspects: 1) current research on pragmatic reuse and2) a process in theory (a pragmatic reuse process model). The study added to existingknowledge on software reuse while being based on previously established theory. Thus, aliterature review was conducted on the topic of pragmatic reuse and its activities. The datawas collected from scientific research databases. Academic articles and research papers werethen used to propose a model of a general pragmatic reuse process.

RQ2 How does pragmatic reuse in practice relate to the theoretical process?

This RQ investigates how reuse is performed in practice and involves a case of this study,a pilot project that was carried out at a large telecommunications company. The project wasstudied as an example of how pragmatic reuse is conducted by organizations. Its processeswere analysed and compared to the available research on pragmatic reuse.

The project was completed before the start of the case study. Since case studies inves-tigate the phenomena in their context, it is important to have a thorough understanding ofreuse activities within the project, which usually requires contact with the participants. Asthe author of this thesis is the developer that was conducting the pragmatic reuse in theproject, there is a lot of insight into how it was performed. Thus, no additional interviewswith other participants were required during the case study’s course. Information related tothis project was obtained from Ericsson, specifically the documentation and artifacts createdduring the project.

9

3.3 Data collection

According to classification by Lethbridge et al.[20], this case study used the third degreeof data collection techniques. These methods perform an independent analysis of alreadyavailable data. Third-degree methods are mostly less expensive but do not offer the samecontrol over data quality since the data has been created for another purpose than to providedata to research in a case study[20].

For the literature review, information was obtained from academic databases, namelyIEEE Xplore, ACM Digital Library and ScienceDirect. Collected data included journalarticles, conference proceedings, books and research papers. In order to maintain relevanceand validity, specific criteria were applied to the literature. Specifically, that the literaturemust be published by a reliable publisher and must be relevant to the research topic.

A variety of information was collected about the pilot project and its processes. The dataincluded documents created during the project, its journal, Ericsson software documentationand reports on the project results.

3.4 Data analysis

During the literature study, the current state of the academic research on pragmatic reuseprocesses was examined and summarized. As there is not a lot of research on, specifically,research processes involved in pragmatic reuse, information about reuse processes in generalwas analyzed to complement the existing information about pragmatic reuse processes. Atheoretical model of a pragmatic reuse process was created as the result.

Subsequently, pilot project documentation was analyzed to gain an understanding of howthe reuse process was performed. Information in the study’s journal was helpful to determinewhich reuse processes were conducted and in what sequence. The codified information ontest cases was useful to understand how the selection process was performed. The processesand techniques used during the project were then compared to an previously establishedtheoretical model, as well as additional research on reuse.

3.5 Validity

In order to ensure the accuracy of the findings, it is important to analyze possible threats tothe validity of the case study and how they can be mitigated. Runeson and Host describefour different aspects of validity for case studies: construct validity, internal validity, externalvalidity and reliability[19].

1. Construct validity refers to the extent to which a study investigates what it claimsto investigate[21]. It can be enhanced by data triangulation. Triangulation meansstudying the object from different angles, which will provide a deeper understandingand lead to stronger conclusions[19]. In this study, data was triangulated by retrievingacademic papers from several databases as well as by using different sources to getinformation about the pilot project (software documentation, project journal, etc.)Another way to enhance construct validity is to provide a clear chain of evidence, withthe goal to give enough information so that readers will be able to follow how specificdecisions and conclusions had been made[21].

2. Internal validity is concerned with the data analysis phase and that correct conclusionshad been made by the researchers[19]. Pattern matching can be used to increaseinternal validity, where the researchers match the observed empirical evidence to thepreviously established patterns. In this study, a real-world pragmatic reuse processwas compared to the theoretical process model derived from the academic literature.

3. External validity reflects to what extent the findings are relevant outside the scope ortime span of the study[19]. This study investigated only one case of the real-worldpragmatic reuse process. However, the transplantation of reuse artifacts from onesystem to another can be considered a representative case of software reuse. Thisassumption was confirmed by its close resemblance to the similar processes describedby the existing research.

10

4. Reliability is concerned with how much the data and the analysis might be influencedby the researchers[19]. In order to mitigate the researcher bias, this case study usedtheory triangulation. Namely, the pragmatic reuse process was viewed from both thereal-life perspective and the academic point of view with the support of the alreadyexisting research. In addition, the case study was documented in detail so that can bereplicated by other researchers[21].

3.6 Ethical considerations

A consent to perform research on the pilot project was obtained from Ericsson. Since thiscase study investigated a pragmatic reuse process as it is done within a company, the researchhad access to confidential information. Thus, raw data related to the project is not publishedor revealed to the third party. The details on how the project was conducted are generalizedto illustrate the reuse process and avoid exposing sensitive information.

11

12

Chapter 4

Software reuse processes

This chapter describes software reuse processes, including various concepts that have evolvedover the years and some examples of reuse process models.

4.1 Introduction

Given the payoff of reusing software, developers are eager to adopt the practice. Manyattempts at improving the software process by reusing software components have been pro-posed and tried, with varying degrees of success. Software reuse processes refer to all thetasks necessary for successful software reuse within an organization. Several conceptualframeworks for software reuse have been proposed to help organize and place various con-cepts and models of reuse. Due to the extensive amount of academic research on reuseprocesses, this chapter focuses on the concepts relevant to pragmatic reuse and providessome examples of the models that can be used in practice to incorporate reuse into a soft-ware development process.

4.2 Early frameworks

One of the earliest methodologies for software reuse was developed in 1992 by the SoftwareTechnology for Adaptable, Reliable Systems (STARS) program. A Conceptual Frameworkfor Reuse Processes (CFRP) was created to integrate reuse-related software developmentprocesses into product life cycle models[22]. This approach is called software engineering forreuse.

The CFRP consists of two interconnected ”process idioms” called Reuse Management andReuse Engineering that describe a set of activities inherent to the process management andproduct engineering aspects of reuse, respectively. The separation between them providesflexibility and easy customization for organizational needs. Reuse Management idiom focuseson processes for planning, enacting and learning about reuse within an organization. ReuseEngineering idiom addresses development and improvement of the assets, including assetcreation, management and utilization[22].

CFRP by itself is a generic framework and places too much emphasis on the reuseprocesses, which makes it not suitable to serve as the sole basis for developing a tailoredreuse-based software engineering life cycle model. Thus, a Reuse-Oriented Software Evo-lution Process Model (ROSE PM) was developed specifically to bridge the gap betweenthe high-level generic framework and the detailed prescriptive methods[23]. It combinednon-reuse related software engineering processes with the CFRP model.

ROSE PM is divided into four iterative sub-models: Organization Management, DomainEngineering, Asset Management, and Application Engineering. Organization Managementsubmodel consists of the highest-level organizational Plan, Enact, and Learn activities aimedat facilitating the reuse processes within the organization. The goal of Domain Engineeringis to capture, organize and represent knowledge about a domain and produce reusable as-sets that can be applied to produce a family of systems covering that domain. The AssetManagement submodel aims to acquire, evaluate, and organize assets produced by domain

13

engineering, and arrange them in a managed collection that serves as a mediation betweenasset creators and asset utilizers. Finally, in Application Engineering the goal is to develop,re-engineer, maintain, or evolve software systems, making use of assets created in domainengineering[23].

The key objective of the ROSE model is to integrate software maintenance and re-engineering to produce a general reuse-oriented approach to software evolution. Despite theintention to facilitate a transition to a software reuse-oriented approach for organizations,ROSE PM does not manage to provide clear guidance. Upon close examination, its mainproblem is that activities are presented generically without specifying how they should beperformed.

4.3 Artifact repositories

In object-oriented programming, objects are created with at least some amount of reuse inmind. The need to catalog and classify the objects for easier retrieval and reuse gave a startto the object libraries. Today, artifact repositories and libraries are widely used techniquesin software reuse. Numerous process models utilizing them have been used over time. Forexample, models that include a software repository for the storage of reuse components andeffectively support the process of finding suitable reusable artifacts[24][25].

4.4 Domain Engineering

Quite often, the process of developing a system involves reuse of the software artifacts thatoccur in the existing systems within the same field. A process based on the reuse of suchartifacts is called domain engineering. It involves the reuse of domain knowledge in theproduction of new software systems.

The Feature-Oriented Reuse Method (FORM) describes systematic methods for discov-ering commonality across related software systems and using this information to engineersoftware for reuse[26]. Its aim is on capturing commonalities and differences of applica-tions in a domain in terms of ”features” and using the analysis results to develop domainarchitectures and components. FORM has a specific goal of applying domain analysis re-sults (commonality and variability) to the engineering of reusable and adaptable domaincomponents. FORM consists of two major engineering processes: domain engineering andapplication engineering. There are three phases in the domain engineering process: contextanalysis, domain modeling, and architecture (and component) modeling. The applicationengineering process consists of activities for developing applications using the artifacts cre-ated in the domain engineering[26]. Thus, FORM includes both development for and withreuse.

The main focus of the FORM lies in the analysis of domain features and the use ofthese features in the creation of reusable domain artifacts. More specific aspects such asspecification, implementation and packaging of the components are scarcely explored[15].

4.5 Software Product lines

After a while, domain engineering processes started to evolve into a product line approach. Aproduct line is a set of products that share many (structural, behavioral, etc.) commonalitiesand together address a particular domain. With a reuse process in place, every new systemcan be built from a set of core assets rather than rebuilding a system from scratch for eachnew customer’s requirements[27]. However, until the late ’90s, there were few guidelinesor methodologies available to develop and deploy product lines beyond existing domainengineering approaches.

On the other hand, domain engineering approaches have not proved to be as effectiveas expected. According to Bayer et al.[28], there are basically three reasons for this: lackof operational guidance, too much emphasis on organizational issues and misplaced focuson domains, as opposed to products. Moreover, domains have proved to be difficult toscope and engineer from an enterprise point of view because a domain captures many non-essential elements that are of no interest to an enterprise. Hence, the domain view provides a

14

little economic basis for scoping decisions. Instead, enterprises focus on particular products(existing, under development, and anticipated). This difference in focus is essential forpractically supporting the product-driven needs of enterprises.

In this context, based on the mentioned domain engineering’s limitations and lack ofproduct-lines approaches, Bayer et al. proposed the Product Line Software Engineering(PuLSE) methodology[28]. The methodology was developed with the intention of enablingthe conception and deployment of software product lines within a large variety of organiza-tions.

PuLSE is composed of three main elements: the deployment phases, the technical compo-nents, and the support components. The deployment phases are a set of stages that describeactivities for initialization, infrastructure construction and usage, as well as evolution andmanagement of product lines. The technical components provide the technical know-howthat is needed to operationalize the product line development. At last, the support compo-nents are packages of information, or guidelines, which enable a better adaptation, evolution,and deployment of the product line[28].

The PuLSE methodology presents an initial direction to develop software product lines.Nevertheless, this approach is hard to apply in the industrial environment due to the lackthe essential details of how to implement processes in practice[15].

4.6 Service-Oriented Architectures

With the rise of network connectivity and usage of distributed systems emerged a new style ofsoftware design where an application is composed of different loosely-coupled self-containedcomponents made accessible as services over a network. With this style, called Service-Oriented Architecture (SOA), services communicate with each other, either to exchangeinformation or to coordinate an activity. The service can be built from scratch, or byexposing the service of an already existing system to a network[29]. Thus, SOA promotesthe reuse at the macro (service) level rather than the micro (classes) level.

Integration of Software-Intensive Systems Initiative created a technique that aims to helporganizations to enable existing legacy systems to reuse their functionality as services in aSOA [30]. Service-Oriented Migration and Reuse Technique (SMART) consists of five majoractivities, each divided into several tasks:

• Establish Stakeholder Context activity aims to identify who knows most about thelegacy system, which relevant features it has, and what it should do as a service or setof services.

• Describe Existing Capability activity obtains descriptive data about the componentsof the legacy system.

• Describe the SOA State activity produces information about target SOA and potentialservices created from the legacy components.

• Analyze the Gap activity determines the cost and effort level needed to convert thelegacy components into the services.

• Develop Migration Strategy activity provides recommended component/service op-tions with the strategies most appropriate for the migration effort.

4.7 Reengineering

As new technologies and practices emerge, organizations have trouble keeping up to date.Legacy software becomes harder to run and maintain as its life cycle comes to an end.Additionally, legacy applications can be a real impediment due to their inflexibility andinability to get new features or adopt emerging technologies. Thus, organizations need helpwith updating software to prevent it from becoming obsolete. Software reengineering is aprocess that includes examination, study, capture and alteration of an existing system orproduct in order to restructure it in a new form. Software functionality is not changed and,normally, the system architecture also remains the same. The term ”reengineering” can

15

also mean some sort of reworking or retrofit of an already engineered product and can beinterpreted as maintenance or refurbishment.

Much of the software reengineering is closely associated with reverse engineering to re-cover either design specifications or user requirements. Reverse engineering, sometimescalled inverse engineering, is the process through which a given system or product is ana-lyzed to identify or specify its definition either at the level of technical design specificationsor at the system- or user-level requirements.

The Reuse in Software Engineering (RiSE) group started in 2004 is aiming to help orga-nizations in adopting an effective reuse process[31]. RiSE group combines the research onsoftware reuse with best practices outside academia. They proposed a reverse engineeringmodel that is meant to be used to recover legacy systems and allow their evolution. It con-sists of six main steps: Define objectives, Analyze legacy system, Organize and decompose,Reconstruct Documentation, Redesign, Reimplementation.

4.8 Summary

As shown, existing research on systematic software reuse processes is quite extensive. Reuseprocesses cover different areas, such as domain engineering, software product lines[32],reengineering[33] and service-oriented software engineering. Process models’ main focusis on guidelines and procedures that will facilitate software reuse in an organization. Theyexhibit a high level of abstraction and often do not provide adequate information on actualreuse processes. The next chapter will describe the pragmatic reuse process.

16

Chapter 5

Pragmatic reuse

This chapter describes a pragmatic reuse process and presents relevant process models. Therest of this chapter covers a proposed model of the pragmatic reuse process, addressing thefirst research question introduced in Section 3.2 of this report.

5.1 Existing research

A great deal of research has focused on the software reuse processes. While systematic(preplanned) reuse is significantly more popular in the research community, there are notmany reports on the opportunistic reuse of already existing artifacts even though such reuseis known to be a daily practice for software developers[3][34][35].

This type of reuse is known as pragmatic reuse. It allows developers to leverage mature,high-quality source code in cases where its creators did not anticipate or plan for suchreuse. In addition, it avoids the need to restructure the original system for the sake ofcreating needed reusable artifacts. Pragmatic reuse correlates with the way developers workintuitively, so it facilitates reuse within an organization without forcing developers to adoptnew methods.

Pragmatic reuse is also known as code scavenging[7], opportunistic[4] or ad-hoc [5] reuse.It differs from the library[36] or component reuse in that there is no interface to the reusedcode – the code must be transplanted from one program into another. Pragmatic reuse isproject-oriented rather than line- or function-oriented. Unlike systematic reuse, for whichreusable artifacts are well-defined and easily located, pragmatic reuse requires that thedeveloper not only be aware of the opportunities for reuse but also search for and retrievereusable artifacts.

As it is different from the preplanned approach, pragmatic reuse has long been criticizedfor its ad-hoc nature and lack of a structured process[7][3]. Due to its focus on projects,pragmatic reuse is hard to generalize. A lot of research focuses on automatizing some of theaspects of the pragmatic process, for example, locating the artifacts[37] or validating themafter integration[38]. However scarce, there are attempts to describe a general pragmaticprocess. According to Krueger et al., the reuse process consists of design and code scavengingwith the goal of reducing the time and effort required to create a new software system. Itinvolves three main steps: selecting high-quality source code, adapting it for reuse, andintegrating it into a target system[7]. Maras et al. specified the generic pragmatic reuseprocess, dividing it into three steps: Feature Location, Code Analysis and Modificationand Feature Integration. The model gives an overview of each step and describes differenttechniques that may be used during the process[17].

5.2 Process model

By studying the available research on pragmatic reuse practices, a model for the pragmaticresearch process was developed. It consists of three steps: selection, code analysis andadaptation, and integration.

17

5.2.1 Selection

During this step, the developer selects artifacts in the already existing system that can beused as a part of a new system (called the target system). To be successfully reused, selectedartifacts should have certain similarities to the artifacts in the target system that allow themto be successfully integrated. These similarities can be used as a part of selection criteria.The artifacts in the originating system are treated as a library from which the relevant onesare selected[7].

Extracting reusable components from existing software systems means locating partsthat implement the data or functional abstractions. Thus, the source system (or relevantparts of it) has to be analyzed in order to locate desired artifact features. Since a system wasnot designed for reuse, the code that implements a particular feature is often not containedin an entity that can be easily copied from one system into the other. Instead, the code ofa feature is scattered throughout the system. In such cases, the main problem is correctlyidentifying the code responsible for the implementation of a feature – feature location.

Feature location incorporates analysis of different aspects of the source system. Thetextual analysis examines source code and comments in search of domain knowledge thatencodes the desired feature. On the other hand, the dynamic analysis shows the actualinterplay between program components during execution and is often used when featurescan be invoked and observed during runtime. Static analysis analyses data and controldependencies for all possible program inputs without executing the application[17].

The result of the analysis is a mental model that consists of abstractions of the existingsystem. Developer often builds an informal abstraction of a design, but different models canbe used to represent the system[3]. The selection process is often performed manually, andbased on instinct and former experience. Finding the right artifacts is often a most chal-lenging or time-consuming part of the pragmatic reuse process[39]. Thus, several automatedand semi-automated techniques have evolved to facilitate the selection[3][39][40].

5.2.2 Code analysis and adaptation

After a set of relevant artifacts is retrieved, a detailed analysis of this asset is required inorder to find those most suitable for reuse. Reuse is dependent upon both similarities anddifferences between the systems in which the artifact is being used. Thus, in order to use ormodify an artifact, it is necessary to understand the functionality of each artifact and assessits suitability in the target system.

Chosen artifacts can be directly used in the target system in so-called black-box reuse.Artifacts reused without revision tend to be small, well-documented modules with simpleinterfaces and little input-output processing. However, most often pragmatic reuse usesthe white-box approach, where the existing software requires reengineering or packaging tomake it suitable for reuse[5]. The extent of the source code and the scope of its dependenciesupon the system must be understood to successfully adapt it to its new context. Errors maybe introduced while modifying the code, so the validation, testing, and debugging must berepeated each time an artifact is reused.

This step may also be called the Specialisation step[7]. Maras et al. incorporate themitigation of integration conflicts into this step as the feature source code may require amodification for the successful change of executing environment as well as possible adjust-ments to the target system[17].

5.2.3 Integration

At last, after the artifact has been identified, extracted, and both its source code and thetarget system code prepared for integration, the actual reuse is performed by embedding thefeature source code into the target system. This step may inject errors in the original codethat are to be resolved by the developer[38].

Often, verification is required to ensure that the reused artifact does not affect the systemnegatively. Additionally, tests are needed to be performed to validate that artifact stillprovides its functionality within the destination system. This requires high-quality testingfor both the artifact and the target system. In case the tests are not already available, theycan be automatically generated[17].

18

Chapter 6

Pilot project

This chapter describes the case of pragmatic reuse in an industrial setting, including itsbackground and the description of how the test cases were selected in the source system,analyzed and moved to another system.

6.1 Background

In order to better understand how pragmatic reuse is performed in practice, a pilot projectperformed at Ericsson was studied. This project intended to reuse test cases between thecompany’s frameworks for testing. A description of the frameworks is presented in Section2.2.

Today, many software testing activities revolve around the idea of a test-driven develop-ment which is usually practiced as part of Continuous Integration (CI)[41]. The unit testcases are written in order to verify a piece of the software’s functional behavior. The codeand tests are supposed to be integrated frequently into the shared codebase (a softwarerepository under version control). The tests are executed in a repeated, usually automatedmanner, and therefore called CI loop.

The unit tests should last a maximum of one hour, so that developer would get feedbackquickly and do not need to pause the work waiting for the result. The short duration oftests means a challenge since the tests are supposed to detect the faults in a run time thatis relatively short compared to the system scope.

Java Common Auto Tester (JCAT) is one of the test frameworks used for continuousintegration. It is based on TestNG[13] and is developed by Ericsson. A bigger and oldersystem is written in Erlang and uses the Common Test (CT) framework[11]. Ericsson strivesto move current testing to JCAT. To create a better understanding of what will be requiredfor such transition a pilot project was conducted by a team working with JCAT.

The project was done by one developer with the support of two experts on the JCATdomain and a developer with a knowledge of the CT system. The team was working onsoftware for the 5G base stations, called the nodes. Reused artifacts are functional tests forthis software.

6.2 Selection

Since the team was aiming to extend the test coverage on backup, restart or upgrade of thenodes, the chosen test cases were supposed to cover these areas. Hence, tests on the olderversions of the software were excluded from consideration.

Information about test location in the CT system was extracted from CI loop logs sincethey contain information about all tests currently performed on the nodes. The logs wereanalyzed using a top-down approach, extracting information about tested functions fromthe test names and comments.

Information about selected tests was recorded in a structural manner. The data includedtest suite names, along with short descriptions of the functionality provided in the source

19

code and a link to a corresponding log. After this step, a resulting list contained 25 testsuites. Each of these suites consisted of approximately 5-15 unique test cases.

6.3 Test case analysis

After a list of the eligible test suites was derived, they had to be analyzed in order tounderstand how to move them from the CT written in Erlang to JCAT written in Java.The functionality of tests was mapped using static analysis of the documents related to theCT system.

Performed actions and expected outcomes of every test were summarised and noted inthe pilot project documentation. To obtain information on whether a test will fit into JCAT,meetings with a JCAT domain expert were conducted. The meetings were held 2-3 timesa week for approximately 15-20 minutes. During every meeting, a set of test suites werepresented and discussed. A decision on whether the JCAT system can implement the testcase was made by the expert and noted in the documentation.

The analysis and review were performed in an iterative fashion. After a number of testcases were analyzed, they were reviewed at the meetings. Results of the reviews were thenused in the analysis and categorization of the next batch of test cases. For example, CThas an access to certain interfaces that JCAT has not. Consequently, test cases that requireaccess to these interfaces were deemed not eligible for reuse. As a result, the list of criteriafor the test cases became longer since tests implementing a function unsuitable for JCATwere cast aside during the initial analysis.

Decisions made during this step are illustrated by a flowchart in Figure 6.1. Majorimpediments for JCAT test reuse include differences in access to the interfaces and theboard, as well as testing the same functionality. These findings are described further inChapter 7.

6.4 Integration

After the analysis was performed, selected test cases were implemented in JCAT. Since theJCAT team combines continuous integration with an agile mindset, implementation followedthe same practices. Successful integration was confirmed by running the implemented testcases in the current CI loop. Namely, the tests reported correct results performing tests ondifferent boards over a certain amount of time.

20

Figure 6.1: A flowchart of the decision process during the analysis

21

22

Chapter 7

Project results

This chapter presents the results of the performed pilot project with regard to the companycontext.

7.1 Test case allocation

The main objective of the pilot project was to get a list of test cases that can be movedinto JCAT. However, results showed that that the majority of the CT test cases were noteligible for reuse due to either requiring unsupported JCAT functionality or being alreadyimplemented. As seen in Figure 7.1, a larger part of test cases (72) was deemed not suitablefor reuse, 61 of analyzed test cases were found to test the same functionality as tests inJCAT, and three cases were fit for the reuse.

Figure 7.1: Distribution of test case reusability

7.2 Test cases with unsupported functionality

Since the aim of the project was to find test cases that can be transferred to JCAT withminimal alterations, test cases that require modification were deselected for transfer. Theybelong to two categories. The majority of the unsupported test cases (60 of 72) performswhite-box testing, while the rest requires access to the interfaces that could not be providedby JCAT at the time, for example, RPC (Remote Procedure Call).

As described in Section 2.2.3, CT implements a number of Common Test Hooks (CHTs)to support different operations on the nodes. As CTHs are often used to allow access topreviously inaccessible interfaces, the CTH documentation was referenced during analysisto identify those providing access to interfaces unsupported in JCAT. A call for these CTHsin the source code served as a reuse elimination criteria.

23

A part of the JCAT system at the receiving end of the reuse in the project scope performsblack-box testing. The tests are conducted on secured nodes, which require a certificate andcredentials to get access or to perform any operations on the board. However, the analyzedpart of the CT system was found to perform both white- and black-box testing. A part ofthe test cases required root access to the nodes or to perform actions on an unsecured board.Thus, they did not fit into the reuse criteria. However, these cases might be a better fit inanother part of the JCAT system that performs white-box testing and supports requiredfunctionality.

7.3 Overlapping between the systems

A significant part of the CT test cases was found to test the same functionality as theJCAT but on different access levels. JCAT tests are closer to the customer level, while CTperforms mainly functional testing closer to the hardware. Theoretically, testing the samefunctionality is redundant, and the overlaps should be minimized. However, such alterationshould be performed with caution to ensure that test coverage is not affected negatively.

7.4 Summary and future work

Results of the pilot project were presented to the JCAT team members including the struc-ture and description of analyzed CT test cases and the project’s findings. Despite an initialassumption, the majority of test cases were not ready to be moved to JCAT. However, theresults of the analysis showed which functionality was required to be implemented in JCATfor successful integration of 72 test cases.

A proper investigation of test cases testing similar functionality in both systems is asuggestion for a future case study. Since testing of these parts of functionality is alreadyperformed in JCAT, a point can be made that the reuse is already in place. However, thecorrelation between tests in both test systems should be analyzed to order to understandthe further course of action.

24

Chapter 8

Analysis

During the literature study, a process of pragmatic reuse was explored, and Chapter 5presents a model of how the reuse might look in a real-world setting. This chapter presentsan analysis of the processes applied during the pilot project and how they correlate with theproposed theoretical model and academic research.

As described in Chapter 5, a general pragmatic reuse process consists of three steps. Asshown in Chapter 6, the pilot project adheres quite closely to the three steps of the proposedprocess model.

During the first step, Selection, information on the available artifacts is gathered. Testcases are collected based on chosen criteria using recent test logs as a source of information.The information is extracted by means of textual analysis of the logs. This method isbriefly covered by Maras et al.[17] Since text is commonly used to represent informationamong various artifacts at different levels of abstraction, textual analysis is often appliedto retrieve the information during the software reuse process. It can be used during everypart of the process. For example, Kruger et al.[42] described how textual analysis is appliedto facilitate feature location. Release logs, pull requests and other information available ontwo open-source projects were used to identify and locate system features.

Similarities and variabilities between source and destination systems are explored inorder to find the test cases most suitable for reuse. Both systems’ functionality is capturedusing domain analysis. Information about the process of domain analysis from the softwareengineering perspective can be found in the article by Prieto-Dıaz[43]. He describes theprocedure, sources of domain knowledge and the actors. A process model for domain analysisis also proposed.

After artifacts are gathered, they are analyzed on the matter of compatibility with thetarget system. This part of the project corresponds to the second step in the proposedprocess model named ”Code analysis and adaptation.” According to the pilot project re-quirements, test cases were meant to be reused using the black-box approach. Therefore,they were not modified to suit the target system, and no adaptation is performed.

During this step, source code is analyzed in order to understand how the system isstructured. A concept of a code is created by a developer in order to be able to understandwhat it does and define the boundaries of where it exists in the source system. In thiscase, static analysis was used to understand which functionality was being tested. Sourcesystem documentation is used when more context is needed. Holmes and Walker created asemiautomatic tool that aids developers in pragmatic tasks. They described how developersperform similar tasks to understand the source system’s functionality[3].

Since the source system was not developed with reuse in mind, an investigation into itsfunctions and features is required to understand the context of reuse. This process utilizessimilar techniques to those used during reengineering. As described in Section 4.7, duringreengineering a system is studied and captured so it can be altered to a new form. Withthe help of reverse engineering, the software system under consideration can be examinedthoroughly.

Kazman et al. described a reengineering process which is presented as a horseshoe.The horseshoe model is illustrated in Figure 8.1. The left side of the horseshoe representsthe architecture recovery process, going up from the source code level. On the top, the

25

architecture is transformed in accordance with new requirements. The process then evolvesinto an architecture-based development going down the right side of the horseshoe. Fourlevels of the horseshoe symbolize levels of software representation. They are described fromthe bottom up: source text, code structure, functional level and architecture[44].

Figure 8.1: A horseshoe representation model of the reengineering process

After the reengineering and categorization, selected test cases are transferred to thetarget system. This part is described in the Integration step of the pragmatic reuse model.Due to the previous reengineering efforts, the functional structure of test cases was easy tofollow and implement in another programming language. Regression testing is performed toensure that implemented test cases have not caused unintended side effects on the destinationsystem. This technique is given an overview by Li and Wahl[45], describing a generalprocess, different types of regression testing and some examples of used techniques. Theobjective of regression testing is to test a modified system to confirm that recent changeshave not adversely affected existing features that the system still meets its requirements.A qualitative survey by Engstrom och Runeson provides an insight on how it is used inindustrial practice[46]. It has shown that regression testing is carried out at different stagesof the development process and at different levels. Most of the good practices and challengesare similar to software testing in general. Some specific challenges of regression testing aretest case selection, cost and environment for automated testing, as well as a need for test-friendly design[46].

26

Chapter 9

Summary

This chapter presents a summary of this case study and suggestions for future work. Re-search questions are revisited, and answers for them are given based on the findings of thestudy. At last, possible future research areas are discussed.

9.1 Revisiting research questions

This thesis describes a case study of the pragmatic reuse process and its implementation in areal-world setting. The study includes a literature review of the reuse processes and proposesa general model for pragmatic reuse. It also includes an analysis of a pilot project wherepragmatic software reuse was performed at a large-sized telecommunications company. Inorder to achieve the purpose of this case study, two research questions were formulated. Inthis section, a summary of the main findings and conclusions for the respective researchquestion are provided.

RQ1 What might pragmatic reuse practices look like?To answer this question, a literature study on software reuse processes was performed.

These processes were summarised, and a general model of the pragmatic reuse process wasproposed. The model includes processes of selection, analysis and modification.

RQ2 How does pragmatic reuse in practice relate to the theoretical process?For a better understanding of the pragmatic reuse process, it was studied in an industrial

setting. A pilot project done at Ericsson was evaluated on the basis of compliance to theproposed pragmatic reuse process model. Pragmatic reuse processes involved in this projectwere identified, analyzed and connected to the corresponding processes in the academicliterature. The pilot project had been shown to follow the process model quite closely. Itsreuse process incorporated several software processes and techniques, specifically, static andtextual analysis, reengineering, domain analysis and regression testing.

9.2 Future work

This thesis investigates both theoretical and practical aspects of pragmatic software reuse.Results of the case study add to the body of knowledge on the pragmatic reuse process, whichis important since the amount of research on the practice of reuse in real-world settings islimited. Future work may include an analysis of more projects and their consistency withthe proposed model.

27

28

References

[1] G. B. Frakes and K. Kang, “Software reuse research: Status and future,” IEEE Trans-actions on Software Engineering, vol. 31, no. 7, pp. 529–536, Jul. 2005, issn: 0098-5589.[Online]. Available: https://doi.org/10.1109/TSE.2005.85 (cit. on pp. 3, 7).

[2] D. Garlan, R. Allen, and J. Ockerbloom, “Architectural mismatch: Why reuse is stillso hard,” IEEE Software, vol. 26, no. 4, pp. 66–69, Jul. 2009, issn: 0740-7459. [Online].Available: https://doi.org/10.1109/MS.2009.86 (cit. on p. 3).

[3] R. Holmes and R. J. Walker, “Systematizing pragmatic software reuse,” ACM Trans.Softw. Eng. Methodol., vol. 21, no. 4, Nov. 2012, issn: 1049-331X. [Online]. Available:https://doi.org/10.1145/2377656.2377657 (cit. on pp. 3, 5, 17, 18, 25).

[4] B. Hartmann, S. Doorley, and S. Klemmer, “Hacking, mashing, gluing: Understandingopportunistic design,” IEEE Pervasive Computing, vol. 7, no. 3, pp. 46–54, Jul. 2008,issn: 1536-1268. [Online]. Available: https://doi.org/10.1109/MPRV.2008.54(cit. on pp. 3, 17).

[5] R. Prieto-Diaz, “Status report: Software reusability,” IEEE Software, vol. 10, pp. 61–66, 3 May 1993, issn: 0740-7459. [Online]. Available: https://doi.org/10.1109/52.210605 (cit. on pp. 5, 17, 18).

[6] M. Ezran, M. Morisio, and C. Tully, Practical Software Reuse, 1st ed., ser. PractitionerSeries. London: Springer, 2002, 222 pp., isbn: 978-1-85233-502-1. [Online]. Available:http://doi.org/10.1007/978-1-4471-0141-3 (cit. on p. 5).

[7] C. W. Krueger, “Software reuse,” ACM Comput. Surv., vol. 24, no. 2, pp. 131–183,Jun. 1992, issn: 0360-0300. [Online]. Available: https://doi.org/10.1145/130844.130856 (cit. on pp. 5, 7, 17, 18).

[8] H. V. Vliet, Software Engineering: Principles and Practice. John Wiley and Sons Ltd,Jul. 2008, 740 pp., isbn: 0470031468 (cit. on p. 6).

[9] P. Ammann and J. Offutt, Introduction to Software Testing. Cambridge UniversityPress, Jan. 2008, 322 pp., isbn: 9780521880381 (cit. on p. 6).

[10] S. McCaskill. (Dec. 3, 2020). “Ericsson says a billion people will have access to 5g byend of 2020,” TechRadar, [Online]. Available: https://www.techradar.com/news/ericsson-says-a-billion-people-will-have-access-to-5g-by-end-of-2020

(visited on 2021-05-14) (cit. on p. 6).

[11] Common test user’s guide, Erlang. [Online]. Available: http://erlang.org/doc/apps/common_test/users_guide.html (visited on 2021-04-29) (cit. on pp. 6, 19).

[12] Common test hooks, Erlang. [Online]. Available: http://erlang.org/doc/apps/common_test/ct_hooks_chapter.html (visited on 2021-04-29) (cit. on p. 6).

[13] TestNG. [Online]. Available: http://testng.org/ (visited on 2021-05-22) (cit. onpp. 6, 19).

[14] JUnit. [Online]. Available: https://junit.org/junit5/ (visited on 2021-05-22) (cit.on p. 6).

[15] E. Santana de Almeida, A. Alvaro, D. Lucredio, V. Garcia, and S. de Lemos Meira, “Asurvey on software reuse processes,” in IRI -2005 IEEE International Conference onInformation Reuse and Integration, Conf, 2005., Las Vegas, NV, USA: IEEE, 2005,pp. 66–71, isbn: 9780780390935. [Online]. Available: http://doi.org/10.1109/IRI-05.2005.1506451 (cit. on pp. 7, 14, 15).

29

[16] R. Walker and R. Cottrell, “Pragmatic software reuse: A view from the trenches,”Tech. Rep. 2016-1088-07, Sep. 2016, p. 17. [Online]. Available: https://doi.org/10.11575/PRISM/31120 (cit. on p. 7).

[17] J. Maras, M. Stula, and I. Crnkovic, “Towards specifying pragmatic software reuse,”in Proceedings of the 2015 European Conference on Software Architecture Workshops,ser. ECSAW ’15, Dubrovnik, Cavtat, Croatia: Association for Computing Machinery,Sep. 2015, pp. 1–4, isbn: 9781450333931. [Online]. Available: https://doi.org/10.1145/2797433.2797489 (cit. on pp. 7, 17, 18, 25).

[18] P. Isberg and T. Akerlund, “Researching integration of ART test cases into JCAT,”Malardalen University, Vasteras, 2013. [Online]. Available: http://urn.kb.se/

resolve?urn=urn:nbn:se:mdh:diva-19227 (cit. on p. 7).

[19] P. Runeson and M. Host, “Guidelines for conducting and reporting case study researchin software engineering,” Empirical Software Engineering, vol. 14, no. 2, pp. 131–164,Dec. 2008, issn: 1573-7616. [Online]. Available: https://doi.org/10.1007/s10664-008-9102-8 (cit. on pp. 9–11).

[20] T. C. Lethbridge, S. E. Sim, and J. Singer, “Studying software engineers: Data col-lection techniques for software field studies,” Empirical Software Engineering, vol. 10,pp. 311–341, 3 Jun. 2005, issn: 1573-7616. [Online]. Available: https://doi.org/10.1007/s10664-005-1290-x (cit. on p. 10).

[21] M. Gibbert, W. Ruigrok, and B. Wicki, “What passes as a rigorous case study?”Strategic Management Journal, vol. 29, no. 13, pp. 1465–1474, Dec. 2008, issn: 0143-2095. [Online]. Available: https://doi.org/10.1002/smj.722 (cit. on pp. 10,11).

[22] R. E. Creps, M. A. Simos, and D. R. Prieto-Diaz, “The STARS conceptual frameworkfor reuse processes,” In Proceedings of the Fifth Annual Workshop on Software Reuse,Tech. Rep., Nov. 1992, p. 14 (cit. on p. 13).

[23] C. D. Klingler and D. Creps, “The reuse-oriented software evolution (ROSE) processmodel version 0.5 - draft,” Paramax Systems Corporation, Reston, VA, Tech. Rep.STARS-UC-05155/001/00, Jul. 1993, 129 pp. [Online]. Available: https://apps.

dtic.mil/sti/citations/ADA284867 (cit. on pp. 13, 14).

[24] S. Henninger, “An evolutionary approach to constructing effective software reuserepositories,” ACM Trans. Softw. Eng. Methodol., vol. 25, no. 2, pp. 111–140, 6 Apr.1997, issn: 1049-331X. [Online]. Available: https://doi.org/10.1145/248233.248242 (cit. on p. 14).

[25] V. A. Buregio, E. S. de Almeida, D. Ludredio, and S. L. Meira, “A reuse repositorysystem: From specification to deployment,” in High Confidence Software Reuse inLarge Systems, H. Mei, Ed., ser. Lecture Notes in Computer Science. Springer, 2008,pp. 88–99, isbn: 978-3-540-68062-8. [Online]. Available: https://doi.org/10.1007/978-3-540-68073-4_8 (cit. on p. 14).

[26] K. C. Kan, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh, “FORM: A feature-orientedreuse method with domain-specific reference architectures,” Annals of Software En-gineering, vol. 5, no. 143, pp. 143–168, 1998, issn: 1022-7091. [Online]. Available:https://doi.org/10.1023/A:1018980625587 (cit. on p. 14).

[27] P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, 3rd ed.Addison-Wesley Professional, Aug. 2001, 608 pp., isbn: 978-0201703320 (cit. on p. 14).

[28] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, andJ.-M. DeBaud, “PuLSE: A methodology to develop software product lines,” in Pro-ceedings of the 1999 Symposium on Software Reusability, ser. SSR ’99, Los Angeles,California, USA: Association for Computing Machinery, May 1999, pp. 122–131, isbn:1581131011. [Online]. Available: https://doi.org/10.1145/303008.303063 (cit. onpp. 14, 15).

[29] N. M. Josuttis, SOA in practice, 1st ed. O’Reilly, Aug. 2007, 315 pp., isbn: 978-0-596-52955-0 (cit. on p. 15).

30

[30] G. Lewis, E. Morris, D. Smith, and L. O’Brien, “Service-oriented migration and reusetechnique (SMART),” in 13th IEEE International Workshop on Software Technologyand Engineering Practice (STEP’05), Budapest: IEEE, 2005, pp. 222–2293, isbn: 978-0-7695-2639-3. [Online]. Available: https://doi.org/10.1109/STEP.2005.24 (cit.on p. 15).

[31] E. Santana de Almeida, A. Alvaro, D. Lucredio, V. Cardoso Garcia, and S. Romerode Lemos Meira, “RiSE project: Towards a robust framework for software reuse,”in Proceedings of the 2004 IEEE International Conference on Information Reuse andIntegration, 2004. IRI 2004., Las Vegas, USA, 2004, pp. 48–53, isbn: 978-0-7803-8819-2. [Online]. Available: https://doi.org/10.1109/IRI.2004.1431435 (cit. on p. 16).

[32] S. Apel, D. Batory, C. Kastner, and G. Saake, Feature-Oriented Software ProductLines, 1st ed. Springer, Oct. 2013, 315 pp., isbn: 9783642375200. doi: 10.1007/978-3-642-37521-7_1 (cit. on p. 16).

[33] I. Jacobson and F. Lindstrom, “Reengineering of old systems to an object-orientedarchitecture,” in Conference Proceedings on Object-Oriented Programming Systems,Languages, and Applications, ser. OOPSLA ’91, Phoenix, Arizona, USA: Associationfor Computing Machinery, 1991, pp. 340–350, isbn: 0201554178. [Online]. Available:https://doi.org/10.1145/117954.117980 (cit. on p. 16).

[34] S. Jansen, S. Brinkkemper, I. Hunink, and C. Demir, “Pragmatic and opportunisticreuse in innovative start-up companies,” IEEE Software, vol. 25, no. 6, pp. 42–49, Nov.2008, issn: 0740-7459. [Online]. Available: https://doi.org/10.1109/MS.2008.155(cit. on p. 17).

[35] J. Brandt, P. J. Guo, J. Lewenstein, M. Dontcheva, and S. R. Klemmer, “Two studiesof opportunistic programming: Interleaving web foraging, learning, and writing code,”in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems,ser. CHI ’09, Boston, MA, USA: Association for Computing Machinery, Nov. 2009,pp. 1589–1598, isbn: 9781605582467. [Online]. Available: https://doi.org/10.

1145/1518701.1518944 (cit. on p. 17).

[36] G. Caldiera and V. R. Basili, “Identifying and qualifying reusable software compo-nents,” Computer, vol. 24, no. 2, pp. 61–70, Feb. 1991, issn: 1558-0814. [Online].Available: https://doi.org/10.1109/2.67210 (cit. on p. 17).

[37] S. P. Reiss, “Semantics-based code search,” in 2009 IEEE 31st International Con-ference on Software Engineering, Vancouver, BC, Canada: IEEE, 2009, pp. 243–253,isbn: 978-1-4244-3453-4. [Online]. Available: http://doi.org/10.1109/ICSE.2009.5070525 (cit. on p. 17).

[38] S. Makady and R. J. Walker, “Validating pragmatic reuse tasks by leveraging existingtest suites,” Software: Practice and Experience, vol. 43, no. 9, pp. 1039–1070, Sep.2013, issn: 0038-0644. [Online]. Available: https://doi.org/10.1002/spe.2134(cit. on pp. 17, 18).

[39] M. Kessel and C. Atkinson, “Ranking software components for pragmatic reuse,” in2015 IEEE/ACM 6th International Workshop on Emerging Trends in Software Met-rics, Florence, Italy: IEEE, May 2015, pp. 63–66, isbn: 978-1-4673-7103-2. [Online].Available: http://doi.org/10.1109/WETSoM.2015.16 (cit. on p. 18).

[40] J. Rubin and M. Chechik, “A survey of feature location techniques,” in Domain En-gineering, I. Reinhartz-Berger, A. Sturm, T. Clark, S. Cohen, and J. Bettin, Eds.Springer, 2013, pp. 29–58, isbn: 978-3-642-36653-6. [Online]. Available: https://

doi.org/10.1007/978-3-642-36654-3_2 (cit. on p. 18).

[41] D. Stahl and J. Bosch, “Modeling continuous integration practice differences in indus-try software development,” Journal of Systems and Software, vol. 87, pp. 48–59, Jan.2014, issn: 0164-1212. [Online]. Available: https://doi.org/10.1016/j.jss.2013.08.032 (cit. on p. 19).

[42] J. Kruger, M. Mukelabai, W. Gu, H. Shen, R. Hebig, and T. Berger, “Where is myfeature and what is it about? A case study on recovering feature facets,” Journal ofSystems and Software, vol. 152, pp. 239–253, Jun. 2019, issn: 0164-1212. [Online].Available: https://doi.org/10.1016/j.jss.2019.01.057 (cit. on p. 25).

31

[43] R. Prieto-Dıaz, “Domain analysis: An introduction,” ACM SIGSOFT Software Engi-neering Notes, vol. 15, no. 2, pp. 47–54, Apr. 1990, issn: 0163-5948. [Online]. Available:https://doi.org/10.1145/382296.382703 (cit. on p. 25).

[44] R. Kazman, S. Woods, and S. Carriere, “Requirements for integrating software archi-tecture and reengineering models: Corum II,” in Proceedings Fifth Working Conferenceon Reverse Engineering (Cat. No.98TB100261), Honolulu, HI, USA, 1998, pp. 154–163, isbn: 978-0-8186-8967-3. [Online]. Available: http://doi.org/10.1109/WCRE.1998.723185 (cit. on p. 26).

[45] Y. Li and N. J. Wahl, “An overview of regression testing,” ACM SIGSOFT SoftwareEngineering Notes, vol. 24, no. 1, pp. 69–73, Jan. 1999, issn: 0163-5948. [Online].Available: https://doi.org/10.1145/308769.308790 (cit. on p. 26).

[46] E. Engstrom and P. Runeson, “A qualitative survey of regression testing practices,”in Product-Focused Software Process Improvement, M. Ali Babar, M. Vierimaa, andM. Oivo, Eds., Springer Berlin Heidelberg, 2010, pp. 3–16, isbn: 978-3-642-13792-1.[Online]. Available: https://doi.org/10.1007/978-3-642-13792-1_3 (cit. onp. 26).

32

TRITA-EECS-EX-2021:279

www.kth.se