Variability Management in a Software Product Line Unaware Company: Towards a Real Evaluation

Variability Management in a Software Product Line Unaware Company: Towards a Real Evaluation Ana E. Chacón-Luna Department of Engineering Sciences University of Milagro Milagro, Ecuador [email protected] Elvira G. Ruiz José A. Galindo David Benavides Department of Languages and Computer Systems University of Seville Seville, Spain {elvgarrui,jagalindo,benavides}@us.es ABSTRACT Software Product Lines (SPL) enable systematic reuse within an organization thus, enabling the reduction of costs, efforts, development time and the average number of defects per product. However, there is little empirical evidence of SPL adoption in the literature, which makes it difficult to strengthen or elaborate adjustments or improvements to SPL frameworks. In this article, we present the first steps towards an empirical evaluation by showing how companies that do not know about of SPL manage variability in their products, pointing out the strengths and weaknesses of their approaches. To this end, we present the design of a case study that we plan to carry out in the future in two companies to evaluate how companies perform variability management when they are not aware of software product lines. Our assumption is that most of the companies manage variability but no many of them are aware of software product lines. In addition, the first preliminary results of the case study applied in a company are presented. CCS CONCEPTS •General and reference → Empirical studies ; Design ; • Software and its engineering → Software product lines;␣ KEYWORDS a case study, software product lines, variability management 1 INTRODUCTION Nowadays, Software Product Lines (SPL) are being increasingly used by organizations as a means to achieve improvements in quality and productivity, as well as decreasing time-to-market and costs. According to Clements and Northrop [5] , an SPL represents a set of software systems which share a common set of features, that satisfies the specific needs of a particular domain or market segment, and which is developed from a core assets common system in a pre-established way. The transition into a Software Product Line Engineering (SPLE) paradigm is not easy. In Ahnassay et al. [ 1 ], a systematic literature review of empirical evaluations in software product lines was carried out, the analyzed literature was collected between 2006 and 2011. After obtaining the information, the conclusion was that only 34% of these investigations involved industry professionals, and most of the articles did not provide any specific foundation for the problem statement but simply described the solution. They also revealed problems in several aspects of the quality assessment criteria for the research design and the report presentation. None of the studies found examples of companies which do not know about software product lines. In Benavides et al.[ 4 ], a study was carried out on how companies which do not know about software product line concepts manage variability. It was concluded that the company under observation had some variability management practices, such as the reuse of product assets among other aspects. However, this study was carried out in a non-systematic way, without putting into practice a formal method of empirical evaluation, such as experiments or case studies. To the best of our knowledge, there are no existing empirical systematic studies on how variability management is handled by companies which do not explicitly know the methods, processes, tools, strategic methodologies and technologies of software product line. Furthermore, there is not an established known path for the transition of companies which want to implement SPLE approaches. For this reason, we consider that there is a research gap. The contribution of this article focuses on the design of the case study applying the methodology described by Runeson et al . [13] ; to determine how variability is managed by companies which do not know the software product line concepts. We also present the first results of the execution of the case study in Company A. We are based on the hypothesis that, there are more companies managing variability than companies which know about SPL. We will study the methodologies applied in companies. Later, we will contrast them with the activities and/or processes of the SPL framework defined by Pohl et al . [11] . Finally, we will design a case study for companies which somehow manage variability in their products. The objective of this study is to determine which SPL concepts are used in practice. As future work,the results of the case study can let us define some adoption practices of transition to the SPL paradigm. The rest of the article is structured as follows: Section 2 briefly describes the software product lines framework, as indicated in Pohl et al . [11] ; Section 3 covers related studies. In Section 4, the case study design is developed specifying: the companies that will be involved, the analysis units to be studied, type of case study, research questions, data collection methods, data selection strategies, data analysis method according to the plan; in Section 5 presents the first preliminary results of the case study; in Section 6 we shown how the threats to validity were overcome in the case study execution; and Section 7 outlines the conclusions and future works. 2 SOFTWARE PRODUCT LINES There are several frameworks related to the processes, concepts or activities used in SPL engineering. In this case, we start from a widely accepted differentiation for all the proposals between domain engineering and application engineering proposed by Weiss and Lai [16]. According to Pohl et al . [11] , SPL engineering consists of the following two processes. Firstly, Domain engineering, whose objective is to produce the platform, including applications commonality and variability; It consists of five key sub-processes: product management, domain requirements engineering, domain design, domain development and domain tests. Secondly; Application engineering, which aims to achieve the highest possible reuse of domain assets when developing a product; It consists of four sub processes: application requirements engineering, application design, application implementation and application tests. With the aim of carrying out a good analytical procedure and considering that the studied companies are unaware of the existence of SPL, this study excludes the processes related to design, development, and testing. The reason for this decision is because the activities of those stages demand greater knowledge of the SPL paradigm. Therefore, the empirical study proposal focuses on three processes: product management, domain requirements engineering and application requirements engineering. These processes were chosen because they are the least strict concerning technology to be applied and because we understand that a company executes these processes implicitly or explicitly to manage variability. However, a similar empirical study could be performed in the other processes, but then the scope of the study would be too broad, and that is the reason we previously reduced the scope to these three processes in this work. Product management deals with the management aspects of the SPL and, particularly, the market strategy. Its purpose is the management of the organization’s product portfolio, using scope techniques to specify what is inside and outside the scope of the product line. As a result, a product map will be obtained. This map establishes the main common and variable characteristics of the future products, as well as a calendar with their expected release dates. SPL product management differs from individual systems product management due to the following: • An expected benefit of SPL engineering is the generation of product variants at a lower cost by reusing a large part of the assets developed in the domain engineering. • The products in the product portfolio are closely related since they are based on a common platform. • Product management takes into account the evolution of market needs, technology, and limitations for future applications, trying to anticipate possible changes in the features or legal limitations. The domain requirements engineering includes the activities to obtain and document the common and variable requirements of the product line. The input for this sub-process consists of the product roadmap. The aim is to determine the reusable requirements, based on the variability model of the product line. Therefore, the results will show the specification of the common and variable requirements for all the product line applications. Domain requirements engineering differs from requirements engineering for individual systems because: • The requirements are analyzed to identify those which are common to all applications and those which are specific to particular applications. The analysis of the requirements is documented in variability models. • Based on input from the product management, domain requirements engineering predicts changes in requirements, laws, standards, technological changes and market needs for future applications. The application requirements engineering performs the necessary activities to develop the specifications for application requirements. The reuse of domain artifacts depends on the requirements of the application. Therefore, an essential concern for application requirements engineering is detecting increments between the application requirements and the available capacities of the platform. The inputs of this sub process are the domain requirements and a road-map of the product containing the main features of the corresponding application. Also, there may be specific requirements (for example, from a client) for the particular application that was not observed during the domain requirements engineering. The output is the specification of requirements for the particular application. The application requirements engineering differs from the requirements engineering for individual systems due to the following reasons: • Obtaining the requirements is based on the communication of the common parts available and the variability of the software product line, considering that most of the requirements are derived from the domain requirements. • The convergence of the application requirements and the domain requirements must be detected, evaluated according to the required adaptation effort and adequately documented. If the required adaptation effort is known in advance, it is possible to make balanced decisions about the application requirements to reduce the effort and increase the reuse of domain artifacts. 3 RELATED WORK In Benavides and Galindo [4] , a study was performed on how companies which do not know about software product line concepts manage variability. It was concluded that the company under observation had some variability management practices, such as the reuse of product assets among other aspects. This study was carried out in a non-systematic way, without putting into practice a systematic method of empirical evaluation, such as experiments or case studies. Although there are no previous documented studies about SPL practices in companies that are still unaware of SPL existence, there are several studies that can be considered as a base for our work. In da Silva et al . [6] and Bastos et al . [2] the authors present a complete study about SPL adoption in small and medium companies in which they aim to justify the use of agile methods and the use of a multimethod approach respectively for the adoption SPL. In da Silva et al . [6] to achieve their goals, they present a singlecase study based on the scoping and requirements of software, given the fact that those disciplines are the ones which define SPL life-cycle. Our case study is also based on the first sub processes of SPL engineering, with two medium-sized companies instead of just one. This will enable us to compare, extract similarities on both companies’ practices and reach more robust conclusions. In Bastos et al . [2] it is concluded that significant findings are an important step to establish guidelines for SPL adoption. The execution of our case study aims to determine how variability is managed by companies which do not know the concepts of the software product lines and to verify which SPL concepts are used in practice. As in our study, Bastos also has as objective, to define some transition practices for the implementation of SPL techniques. In Rabiser et al . [12] a comparative study of the trend of research in SPL in the industrial and academic field is presented. This study revealed that more than one third (34%) of academic research provides artificial/toy examples only and 27% of the papers do not present any evaluation. This means that 61% of academic research is not properly validated. Based on the conclusion presented in the work of Rabiser et al . [12] where it is indicated that 61% of the studies are not correctly validated, we intend to validate through a case study the management of variability in companies which do not know SPL. 4 DESIGN OF THE CASE STUDY For the elaboration of the case study, we will rely on the steps described in Runeson et al. [13] and Wohlin et al. [17]. The first step is the study design, where the objectives of the case study are planned by and defined. The second step is the preparation for the data collection, where the procedures and protocols for data gathering are defined. The third step is the data collection, to gather the data. The fourth step, the analysis of the collected data, is the procedure of analysis of the data, which later allows obtaining the conclusions of the study. Finally, in the fifth step, the presentation of reports, the results and conclusions must be disseminated, showing sufficient evidence of the study. 4.1 Planned context of the empirical evaluation In this subsection, some context is given to the companies to achieve a better understanding of what small and medium-sized enterprises (PYMES) are. Because we do not have any legal authority to give the names of the companies, we will give them a generic name like A and B. Each company is located in a different part of the world, allowing the study to be less biased by social traditions of an area. It is expected to observe many differences in their working procedures, which will make it more interesting to get common factors in both of them. Company A is a private company in South America. Its mission is related to financial and commercial development systems. Among its departments, there is the information technology department, which is composed of the planning department, the development department and the support and customer service department. It has 18 software products developed. Company B is a public company located in Europe. Its mission is to implement the government policies of different municipal corporations in the field of modernization, innovation and implementation of ICTs and the computerization of different services for the benefit of several town halls and the self-management of town halls and other local entities of the province. They have developed 35 software products. 4.2 Analysis units As previously described, the study will be conducted in two companies. Our analysis units will be the product management, the domain requirements engineering, and the application requirements engineering obtained from the engineering framework of the SPL Pohl et al. [11] mentioned in Section 2. 4.3 Type of case study The research method to be applied in our case study will be: multiple embedded, flexible and exploratory case studies according to what is defined by Yin [18]. Multiple embedded case studies , as explained in Runeson et al . [13] „ it consists of two case studies of two different companies, with three analysis units each. The two companies studied use their methodologies in software development. The three analysis units are product management, domain requirements engineering and application requirements engineering [ 13 ]. The objective of this research is to study how software companies with similar features manage variability in their product development. Flexible , because new information can be entered during data collection that may be important or critical to the study. In this way, the study design could be updated [13]. Exploratory , since we are interested in understanding the methodologies that companies use to manage variability between their products, this will allow us to explore the nature and weaknesses associated with them within a specific context [10]. 4.4 Research questions The main objective of the study is to determine how the variability is managed by Companies which do Not Know about Software Product Line concepts (CNKSPL). We consider CNKSPL those companies that manage a family of systems and that might have solutions for variability management even if they are not aware of it. The definition of the research questions has been based on the description of the processes described in Pohl et al . [11] , considering the analysis units of the present study. We pose the following research questions: RQ1 . How does CNKSPL manage variability at product management level? To answer this question, we wondered: •RQ1.1 . What kind of measures are taken to manage the different products? The objective of this question is to identify if the products in the product portfolio handled by the company are related, since they are based on a common platform. Also, it makes it possible to verify if potential changes in characteristics, legal limitations and norms are foreseen for the future application of the SPL. As a result, the answer to this question can serve as an input for the definition and establishment of product management practices, and for generating product variants at an efficient developmental cost and time. •RQ1.2 . How do the strategies align with the product definition? The objective is to identify if the strategies of the department are aligned with the product definition and the choice of new product ideas. As a result from this question, through feedback from the roadmap, feature suggestions on the products can be included. •RQ1.3 . How is the maintenance of existing products carried out? The objective is to verify what activities are carried out in order to preserve and improve existing products in the market. •RQ1.4 . How is the market introduction of new products resolved? This involves identifying the distribution channels used, and the supply of new products, as well as the announcement of new products to potential customers •RQ1.5. How is the product control process carried out? We want to determine if follow-up and training of the product management process are carried out, observing the sales volume of each product obtained. •RQ1.6 . Is there a product list detailing the features of each product? If so, what is its purpose? The objective of this question is to verify if the main common and variable features of all applications of the existing product line are defined. We also want to know if there is a calendar for the delivery of applications to specific clients or for the release in the market. If it does not exist, it is expected to be revealed how they manage the products of the same line RQ2 . How do companies manage variability at the level of domain requirements engineering? •RQ2.1 . Which means are most frequently used to obtain the requirements of the product? It is necessary to list the documents, mechanisms or techniques used to obtain the requirements for the development of new software products, whether these are common, unique in their product range or variables •RQ2.2 . When it comes to documenting requirements for products, is this done through natural language or a model? The purpose of this question is to identify how companies document their analysis of requirements and to find common parts in previously developed software. It also aims to reveal how they manage this process to optimize the functionality and development of the new product. •RQ2.3 . What are the models of requirements used to evidence the obtaining and analysis of requirements? We want to know how they indicate the obtaining of requirements, either through function models, data or behavior analysis, product comparison matrix, requirements matrix or analysis of similarities based on priorities [11]. •RQ2.4 . What are the secondary sources used to obtain and create the requirements of the products? What is the purpose of using secondary sources? The goal is to identify all the sources they use to obtain the common and variable requirements. Also, to investigate whether creating a domain requirement artifact aims to reduce variability. RQ3 . How do the companies manage the variability at the level of application requirements engineering? •RQ3.1 . Is there clear documentation that shows the common and variable requirements of each application? The objective is to document the requirements of each application in their product portfolio. •RQ3.2 . When developing a new application, the requirements of another product are reused? The objective is to identify whether they have as a rule the reuse of artifacts from domain requirements •RQ3.3 . What happens when an application needs specific requirements for its creation? The objective is to know the criteria for modifying existing artifacts or developing a new artifact including the particular features of the application. As a summary, in Table 1 we present the research questions in column two, based on concepts from the SPLE framework, and in column three we present the propositions which give us a general view of the information that will be obtained through the execution of the study instruments. 4.5 Data collection methods Four data collection methods were used in this study: document analysis, observation, focus groups, and interviews Documentation analysis , The documentation analysis is a technique that focuses on the documentation generated by software engineers. All documents that seem relevant to the investigation and that relate to their methodologies for product development will be analyzed. Product road-maps, application delivery schedule, documents that show product features, models of orthogonal variability and matrix of application requirements will be the main focus of this analysis. We expect companies to use different organizational schemes and therefore different names and techniques for documents containing that information. Observation , This method will be applied as in [ 15 ] using the techniques of thinking aloud and direct observations, 120 hours will be used to make the observations in each company. It was planned to carry out 120 hours of observation considering the research team available time. Nevertheless, this suggestion may be changed depending on the company needs or requests, since we IDs RQs PROPOSITIONS How does CNKSPL manage variability at the level of product management? RQ1.1 What kind of measures are taken to manage the different products? If product management measures are taken then the potential changes in the features, legal limitations and norms for future applications will be shown in advance. If product scope techniques are used, then those products that are part of a line and those that are outside the line will be specified. If product scope methods are defined then Product portfolio scoping or domain scoping or asset scooping are applied. RQ1.2 How do the strategies align with the product definition? If a product portfolio exists then the features specifications of each product will be provided. If there is a product portfolio then its usefulness is positively valued. RQ1.3 How is the maintenance of existing products carried out? If a list of products or development artifacts exists then maintenance is optimized. If existing artifacts that have already been developed in previous projects are identified then time and money in the creation of artifacts will be saved. RQ1.4 How is the market introduction of new products resolved? If a product delivery schedule is defined then marketing is optimally managed. RQ1.5 How is the product control process carried out? If there is a follow-up control of the products then the volume of sales of each product obtained may be determined RQ1.6 Is there a product list detailing the features of each product? If so, what is its purpose? If there is a roadmap then it has an important value for the company because it contains the features of the product and a schedule for market introduction. If tthe characteristics of each product are specified then the commonality and variability of the products are analyzed. If commonality and variability of products are analyzed then time and resources for the creation of new products will be saved. How does CNKSPL manage variability at the level of domain requirements engineering? RQ2.1 Which means are most frequently used to obtain the requirements of the product? If there are communication methods to obtain requirements common or variable requirements for the different products of the family then it is easier to collect them for later analysis. RQ2.2 When it comes to documenting requirements for products, is it documented through natural language or a model? If conceptual models exist for the definition of requirements then its usefulness is positively valued. RQ2.3 What are the models of requirements that are used to evidence the obtaining and analysis of requirements? If they use a requirements matrix of the applications then the concordance analysis will be more accessible. If commonality and variability requirements artifacts are defined, then an efficient analysis based on priorities is made. If an orthogonal variability model is used then an efficient analysis of the variants between products is performed. RQ2.4 What are secondary sources used to obtain and create the requirements of the products? What is the purpose of using secondary sources? If requirements from different sources are obtained, then the domain requirements artifacts will be more effective If the analysis of the domain requirements artifacts tries to minimize the variability of the requirements, then the effort that is invested on the flexibility of the design will be lower How does CNKSPL manage variability at the level of application requirements engineering? RQ3.1 Is there clear documentation that shows the common and variable requirements of each application? If there is documentation of the application requirements then the application variability model can be obtained. RQ3.2 When developing a new application, the requirements of other product are reused? If the application requirements specifications are common to the existing ones, then reuse the existing domain artifacts. RQ3.3 What happens when an application needs specific requirements for its creation? If the requirements for the application cannot be met by reusing artifacts from domain requirements then requirements artifacts are created for a specific application. If artifacts of specific requirements are needed for an application then the variable artifacts will be adapted to meet the needs. If specific requirement artifacts are needed for an application then the delta analysis should be performed to decide whether the delta requirements should be made for the application or not Table 1: Research questions are aware of how difficult it is for them to make a non-profitable collaboration with research groups. Even so, the time spent on each company will be even, so that we get the same depth of knowledge in both. Database developers, business programmers, front-end programmers, architects, and requirement analysts will be observed. The objective is to observe the process involved when obtaining the requirement of a new product, the support of existing products, the introduction of new products in the market, the process of product control, the creation of domain artifacts and their reuse. Focus group , will meet as recommended in Kontio et al . [7] . These meetings will be held no more than 30 minutes once a week, in which it will be discussed how they manage their product variability, what methodologies they use to derive product requirements and address issues such as challenges and lessons learned and their relation to the development of SPL. Six principal analysts were selected to participate in the focus group, as they are the ones who actively interact in the definition of requirements and the definition of the scope of their products. Interviews, face-to-face interviews will be conducted with product managers, company programmers, and requirements analysts 4.6 Data selection strategy The basic conditions to address our problem, goal, and research questions are: any SME ' s that have a software development department in a specific domain and share products, and the company is involved with the study. In the companies under study, participants will be selected based on the convenience sampling method [ 17 ]. This selection considers different roles and profiles involved within the company, which will be relevant to the investigation. For research purposes, it is proposed to select roles that involve project managers, product managers, business programmers, front-end programmers, architects, and requirements analysts, as well as all the roles that exist in the company related to the stages to be studied. For the specific selection, it is planned to have previous meetings with the company’s managers as well as study the organizational documentation to know which specific roles would be the most appropriate to be linked to the study. 4.7 Data analysis methods This study will analyze the data collected qualitatively, based on Miles and Huberman [9] . For data analysis, the tool Nvivo will be used, due to its qualitative characteristics of data analysis [3]. After the data collection, we will encode the data, which means that parts of the text will be given a code that represents a particular area, based on the objectives of the study. For each code a memo will be attached, that is, comments and reflections from the investigators with some problems or descriptions that allow describing the analysis units. Then, the first set of hypotheses will be paired, identifying, for example, phrases that are similar in different parts of the material and patterns in the data. We must consider that the process is executed iteratively and affect each other, it is not a simple sequence of steps. Therefore, in the activity where hypotheses are identified if more information is required, more data collection is carried out in the field. 4.8 Threats to validity Research questions: The research questions defined in this study may not focus on the most important aspects related to the three sub processes studied. Interview questions: The proposed set of interview questions may not be explicit and prevent obtaining the necessary information. To mitigate this threat, an interview will be held in several sessions. Observations: The observation will be carried out observing the employees who perform the activities related to the administration of the products and the analysis of requirements, documentation and artifacts. However, the company may not show all the required documentation. To mitigate this threat, confidentiality agreements will be signed with the company. Selection of participants: As the selection was based on convenience sampling, we believe that the most appropriate participants will be selected to provide the appropriate information. We believe that the threat against the results obtained is reduced because the investigation will be carried out in two companies. However, when applying the study in SME‘s it is possible that a participant has more than one role within the company. 5 PRELIMINARY RESULTS In this section we present the first series of results obtained from the intervention in company A. 5.1 Context We have carried out the case study in an Ecuadorian company dedicated to financial and commercial payment means development since 1999. The company currently has more than seventeen national and foreign clients. In the technology and development department, there are approximately twenty two employees; Around nine project leaders, four analysts, six developers and three product certifiers. Currently, they have two star products: one desktop solution and another in web environment. The products have features that allow managing the operation of a financial company through five modules (transactional switch, credit cards, debit cards, payment points and Batch process). 5.2 Purpose of the study The purpose of this case study is to determine how company A handles variability considering that it unaware of software product lines, however, it manages a portfolio of similar products which share common requirements. 5.3 Type of case study and Analysis Units As previously described, the study will be conducted in two companies. Our analysis units will be the product management, the domain requirements engineering, and the application requirements engineering obtained from the engineering framework of the SPL [ 11 ] mentioned in Section 2. The method applied in this study was multiple embedded, flexible and exploratory case study. Embedded, since two areas of company A were analyzed, these units were related to the scope of the product and the requirements analysis unit. With the information collected in company A, the analysis units of the present study were analyzed. Exploratory, since we are interested in understanding how companies manage variability in their products. For this purpose, four methods were used to gather data which allow knowing if company A performed tasks applying SPL approaches. Flexible, because we adapt to the needs presented in the study when gathering important data for analysis. 5.4 Data collection procedures This study used four methods of data collection: interviews, focus groups, documentation analysis and observation. It is worth mentioning that, in order not to affect the obtaining of data and, because the people who collaborated in this study did not know about the SPL paradigm, all the instruments used were generic, subjective to the methodology that the company A uses. that is, SPL issues were not mentioned in the questions. However, the data collected allowed us to find out how they manage variability in their products. The instrument used can be found at Zenodo 1 The main source of information in this study was the semistructured interviews we conducted with the selected professionals in the company. It is worth mentioning that some of them perform more than one role within the company. Interviews were conducted with the manager, two project leaders with three analysts and one certifier. Each interview was conducted in two sessions each of 1 hour. All the interviews were recorded in audio files that were then transcribed and coded for analysis. A focus group was also carried out following the recommendations of Kontio et al . [8] . The focus groups were formed by seven employees who performed analysts, developers and certifiers roles. There were three sessions each of 30 minutes on Thursday morning. An important factor to mention was the willingness of the group to agree on criteria and to show examples of how they managed their product portfolio, and how they obtained the requirements of their new and old clients. We codified all the answers to the open questions posed to the participants. In the development and technology deparment, documentation analysis was carried out, it was related to the product management processes and requirements analysis. Among these documents, the following were reviewed: Request for Information (RFI) this document is generated by the client, it contains: customer data and describes the current business scenario, it also details how they carry out the processes and finally describes the future scenario detailing what they need, that is, specifying the features needed for the product to comply. Request for Proposal (RFP) this document is generated by the company and it details the features the product will have. Agreement act between the clients and the company, this document details the information collection requested by the client, also in this document, it is found the delivery planning of the product through a Gantt chart which systematically details the resources and the time allocated for the execution of each activity within the project for the delivery of the product. Another method used was: observation . This method followed the advice of Seaman Seaman [14] . Direct observations were made, field notes in place. The observed roles were: manager, analysts, 1https://doi.org/10.5281/zenodo.3261266 certifiers. The time allocated to perform the observations to extract information on the first unit of analysis (product scope) was 40 hours and another 50 hours were allocated for the observation of the second unit of analysis, that is, the requirements analysis. Through this method, valuable information was gathered, such as the face-to-face interactions between clients and the company’s personnel when obtaining and negotiating the requirements of a product. E-mail messaging was also observed in order to know the product requirements are collected. It could be observed that the company has two basic products, the ProdN1 can be defined as a single product, but there are many ways to use it. The system is modular. It has five main modules and also other submodules. The implementation of these modules varies, some modules are central and are always implemented, whereas the use of the other modules depends on the requirements of each client. company A clients vary in size and operation, the ProdN1 tool is built to be customizable. The business operation of the company A is based on managing a set of predefined configurations for the most common product requirements, but if the client requests a variant of the modules available, there is also a support option for the customization of more variants. However, in some cases, a customer has needs beyond the functionality available on the ProdN1 and ProdN2 platform they maintain. In these cases, company A can provide a tailor-made solution as a last resort, developing the new requirement for the client even if it is out of reach. 5.5 key finding(s) After analyzing the data collected from company A, the following key findings were obtained: Product Management • The products of company A are related, since they are based on a star product or common platform. • The products they develop are always within the scope of the company’s mission. In other words, they only develop products related to financial and commercial development systems. • The maintenance of existing products is carried out when the client requests it, that is, they do not anticipate modifications to their star product. • They do not anticipate the creation of new products without the customer’s requirement. • There is a list of the products with the particular features or functions of each product. However, this list is purely informative. There is no matrix where the common or variable characteristics of each product are related. The objective of this list is to know the variants of the products to offer new customers products with similar features in order to save cost and development time. Requirements domain engineering • To obtain the requirements of their products, they do so through forms that detail the functions and features of each product through natural language. No comparisons are made with other products. • One of the objectives of the star product or base platform is to minimize particular requirements for each product. • There is no document that relates or compares the common and variable features among the products. Requirements application engineering • When developing a new application, the requirements of another product are reused. • When a new client requests the development of a product, a large part of the star product is always reused, configuring or adapting the existing parts. Rarely, a new module was developed, always trying to configure to use the existing ones. 6 DISCUSSION In the present study, the first preliminary results of the application and execution of the case study were presented. However, it must be emphasized that, this first approach to the industry allowed to improve the initial planning of the case study design. For example, we had to rethink the number of hours planned to make observations in the company. Even though we had the authorization and the commitment to collaborate with the company, 120 hours of observation seemed to be excessive for the company since they were dealing with business processes, therefore, observation time had to be shortened to 40 hours in order to observe information on topics related to the scope of the product and 50 hours to observe how they manage the requirements analysis. Another rethinking of the original design of the case study was related to the execution of the first interview with an analyst, because it allowed us to realize that the instrument was not so explicit and avoided obtaining all the necessary information relevant to how they performed their products maintenance process. For the next session, modifications were made to this instrument so that the pertinent information could be obtained. 7 CONCLUSIONS In this paper, we present the design of the study, defining the objectives and scope, and also identify the protocols and procedures to be followed for the collection of data. After the execution of the case study in the first company, it was concluded that company A has defined a portfolio of products that specifies each product features, additionally, the scope of its products is defined, it also has a common platform. However, they do not have a document that analyzes the common or variable parts of their product portfolio. In addition, they do not anticipate maintenance of their products either. We can infer that the variability at the level of product management in company A. is partially managed. However, no positive results were obtained from variability management at domain requirements levels since there are no conceptual models for the definition of requirements, they do not perform an analysis of the product requirements, nor do they use orthogonal variability models. We infer that, company A does not comply with activities carried out in the domain requirements engineering. Since it does not manage variability at domain requirements engineering level. Regarding Variability management at the engineering level of application requirements, the principle of reuse is respected, that is, if the specifications of the application requirements are common to those already existing, then what is already existing is reused. As future work, we consider the execution of the case study in more companies, the objective is to analyze the joint results and determine the approaches or methodologies applied by the companies, we intend to contrast with the SPL concepts seeking to reveal how these companies manage variability. It will also be possible to determine to what extent companies are applying SPL approaches in industrial contexts. These results will define some adoption practices to make the transition to SPL, which will strengthen the SPL framework as a result of these studies. 8 ACKNOWLEDGEMENTS This work has been partially funded by the EU FEDER program, the MINECO project OPHELIA (RTI2018-101204-B-C22); the Juan de la Cierva postdoctoral program; the TASOVA network (MCIU-AEI TIN2017-90644-REDT); University of Milagro; and the Junta de Andalucia METAMORFOSIS project. REFERENCES [1] Alvin Ahnassay, Ebrahim Bagheri, and Dragan Gasevic. 2013. Empirical evaluation in software product line engineering. Technical Report. Tech. Rep. TR-LS3130084R4T, Laboratory for Systems, Software and Semantics, Ryerson University. [2] Jonatas Ferreira Bastos, Paulo Anselmo da Mota Silveira Neto, Pádraig O’Leary, Eduardo Santana de Almeida, and Silvio Romero de Lemos Meira. 2017. Software product lines adoption in small organizations. Journal of Systems and Software 131 (2017), 112–128. https://doi.org/10.1016/j.jss.2017.05.052 [3] Patricia Bazeley and Kristi Jackson. 2013. Qualitative data analysis with NVivo. Sage Publications Limited. [4] David Benavides and José A. Galindo. 2014. Variability management in an unaware software product line company: an experience report. In The Eighth International Workshop on Variability Modelling of Software-intensive Systems, VaMoS ’14, Sophia Antipolis, France, January 22-24, 2014. 5:1–5:6. https://doi.org/ 10.1145/2556624.2556633 [5] Paul Clements and Linda Northrop. 2002. Software product lines. Addison-Wesley,. [6] Ivonei Freitas da Silva, Paulo Anselmo da Mota Silveira Neto, Pádraig O’Leary, Eduardo Santana de Almeida, and Silvio Romero de Lemos Meira. 2014. Software product line scoping and requirements engineering in a small and medium-sized enterprise: An industrial case study. Journal of Systems and Software 88 (2014), 189–206. https://doi.org/10.1016/j.jss.2013.10.040 [7] Jyrki Kontio, Johanna Bragge, and Laura Lehtola. 2008. The focus group method as an empirical tool in software engineering. In Guide to advanced empirical software engineering. Springer, 93–116. [8] Jyrki Kontio, Johanna Bragge, and Laura Lehtola. 2008. The focus group method as an empirical tool in software engineering. In Guide to advanced empirical software engineering. Springer, 93–116. [9] Matthew B Miles and A Michael Huberman. 1994. Qualitative data analysis: An expanded sourcebook. SAGE Publications, inc. [10] Michael Quinn Patton. 1990. Qualitative evaluation and research methods. SAGE Publications, inc. [11] Klaus Pohl, Günter Böckle, and Frank J van Der Linden. 2005. Software product line engineering: foundations, principles and techniques. Springer Science & Business Media. [12] Rick Rabiser, Klaus Schmid, Martin Becker, Goetz Botterweck, Matthias Galster, Iris Groher, and Danny Weyns. 2018. A study and comparison of industrial vs. academic software product line research published at SPLC. In Proceeedings of the 22nd International Systems and Software Product Line Conference - Volume 1, SPLC 2018, Gothenburg, Sweden, September 10-14, 2018. 14–24. https://doi.org/10. 1145/3233027.3233028 [13] Per Runeson, Martin Höst, Austen Rainer, and Björn Regnell. 2012. Case study research in software engineering. In Guidelines and examples. Wiley Online Library. [14] CB Seaman. 2008. Qualitative methods. Guide to advanced empirical software engineering: 35–62. [15] Carolyn B. Seaman. 1999. Qualitative methods in empirical studies of software engineering. IEEE Transactions on software engineering 25, 4 (1999), 557–572. [16] David M. Weiss and Chi Tau Robert Lai. 1999. Software product-line engineering: a family-based software development process. (1999). [17] Claes Wohlin, Per Runeson, Martin Höst, Magnus C Ohlsson, Björn Regnell, and Anders Wesslén. 2012. Experimentation in software engineering. Springer Science & Business Media. [18] Robert K Yin. 2003. Investigación sobre estudio de casos. Diseño y métodos. Applied Social Research Methods Series 5 (2003).