Using multiple case studies to understanding the product derivation process in industrial settings

Texto

(1)“Using Multiple Case Studies to Understanding the Product Derivation Process in Industrial Settings” By. Leandro Oliveira de Souza M.Sc. Dissertation. www.cin.ufpe.br/~posgraduacao. RECIFE, AUGUST/2011.

(2) Federal University of Pernambuco Center for Informatics Graduate in Computer Science. Leandro Oliveira de Souza. “Using Multiple Case Studies to Understanding the Product Derivation Process in Industrial Settings”. A M.Sc. Dissertation presented to the Center for Informatics of Federal University of Pernambuco in partial fulfillment of the requirements for the degree of Master of Science in Computer Science.. Advisor: Silvio Romero de Lemos Meira Co-Advisor: Eduardo Santana de Almeida. RECIFE, AUGUST/2011.

(3) Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571. Souza, Leandro Oliveira. Using multiple case studies to understanding the product derivation process in industrial settings / Leandro Oliveira de Souza - Recife: O Autor, 2011. xv 131 folhas: il., fig., tab. Orientador: Silvio Romero de Lemos Meira. Dissertação (mestrado) - Universidade Pernambuco. CIn, Ciência da Computação, 2011.. Federal. de. Inclui bibliografia e apêndice. 1. Engenharia de software. 2. Reuso de software. 3. Linha de produto de software. I. Meira, Silvio Romero de (orientador). II. Título. 005.1. CDD (22. ed.). MEI2011 – 161.

(4)

(5) I dedicate this thesis to my son Leonardo and to the memory of my sister Letícia..

(6) Acknowledgements. Initially, I would like to thank my greatest teacher of all: God, for providing me this opportunity and granting me the capability to proceed successfully. I would like to thank my great family. Especially, my parents that always stood by me with everything I needed during my life, and my wife for her patience and comprehension. I would like to gratefully acknowledge the supervision of Dr. Eduardo Almeida during this work. He provided me with many helpful suggestions and encouragement during the course of this work as well as the challenging research that lies behind it. I also wish to express my appreciation to Dr. Silvio Meira, for accepting me as M.Sc. Student. Special Gratitude goes to the rest of the teaching staff of the CIn/UFPE, for their valuable classes. I want to express my deep thanks to my friend Padraig O’Leary for taking intense academic interest in this study as well as providing valuable suggestions that improved the quality of this study. Some key researchers in the software reuse area offered valuable feedback for this work. My gratitude to Dr. John D. McGregor and Dr. David Weiss for their suggestions during our discussions that improved the quality of my work. I would like to thank all my friends from RiSE (Crescencio, Fernando Almeida, Flavio, Heberth, Hernan, Ivonei, Leandro Marques, Luanna, Marcela, Raphael, Ricardo, Simone, Thiago Fernandes, Williams, Vanilson, Vinicius e Yguarata), friend from LES (Renato). Finally, I want to express my deep thanks to my friends Iuri, Ivan, Jonatas, Jardel, Marco André and Sancler for their friendship, advices and incentives during this journey.. iv.

(7) Resumo. A indústria de software tem sido cada vez mais desafiada a melhorar suas praticas de engenharia com o objetivo de oferecer produtos de forma mais rápida e confiável. Assim, as práticas de desenvolvimento de software sofreram significativas mudanças nos últimos anos, uma vez que novas e acessíveis estratégias tem sido aplicadas de forma a alcançar tal desafio. Neste contexto, Engenharia de Linhas de Produto de Software surgiu como uma estratégia de engenharia de software destinada a fornecer à indústria oportunidades para alcançar os objetivos de negócio acima mencionados. No entanto, para garantir o retorno do investimento com uma abordagem de Linhas de Produto de Software, um processo de derivação de produtos bem definido é muito importante. Sem esse processo, os produtos podem ser instanciados de maneira não sistemática, aumentando o tempo e o custo de produção. Por outro lado, mesmo com esta relevância, quando comparado com a grande quantidade de pesquisas em desenvolvimento sobre linhas de produtos, relativamente poucos trabalhos tem sido dedicados ao processo de Derivação de Produtos. Alêm disso, ainda existem poucos relatórios disponíveis sobre como as organizações de desenvolvimento de software derivam seus produtos a partir de uma linha de produtos, e, em geral, os existentes têm sido realizados como estudos informais, sem rigor científico suficiente, tornando difícil a sua repetição e validação. Assim, esta dissertação tem como objetivo obter uma melhor compreensão sobre como derivação do produto é realizada e quais práticas são utilizadas na indústria. Reunimos descobertas através de dois estudos de caso realizados na indústria. Alem disso, as evidências obtidas a partir dos estudos de caso, foram comparados entre os casos através da análise Cross-case, com o objetivo de identificar padrões entre eles. A definição do estudo e relatório foram estruturados com base nas diretrizes consolidadas para estudos empíricos de acordo com orientações bem definidas, o que permite a replicação dos estudos e extensão. Palavras-chave: Derivação de Produto, Estudo de Caso, Estudo Empírico, Linhas de Produto de Software, Reuso de Software e Processo de Software.. v.

(8) Abstract. The software industry has increasingly been challenged to improve its engineering practice aiming at delivering products in a faster and more reliable way. Thus, software development practices have changed significantly in recent years, since new and affordable strategies should be applied towards reaching such a challenge. In this scenario, Software Product Lines Engineering has emerged as a software engineering strategy aimed at providing industry with opportunities to reach the aforementioned business goals. Nevertheless, in order to ensure the return of investment with Software Product Lines (SPL) approach, a well-defined Product Derivation (PD) process is very important. Without this process, the products can be instantiated in an ad-hoc manner with success relying on the effort of a few individual members, what may increase the production costs and time-to-market. On the other hand, even with this relevance, when compared to the vast amount of research on developing product lines, relatively little work has been dedicated to the process of product derivation. Additionally, there are still only few reports available about how the software development organizations derive their products from a product lines, and, in general, they have been conducted as informal case studies, without sufficient scientific rigor, making hard their repetition and validation. Thus, this dissertation aims to gain a better understanding on how product derivation is performed and what practices are used in industry. We gathered findings through two case studies performed in real organizations and validated across comparatives analysis about their support for key activities for product derivation. In addition, the findings gathered in case studies were compared across Cross-case analysis, aiming to identify patterns across them. The study definition and reporting were structured based on consolidated guidelines to empirical studies according to well-defined guidelines, allowing the study replication and extension. Keywords: Product Derivation, Case Study, Empirical Study, Software Product Lines, Software Reuse and Software Process.. vi.

(9) Table of Contents. List of Figures. xii. List of Tables. xiv. List of Acronyms. xv. 1. 2. 3. Introduction 1.1 Motivation . . . . . . . . . . . . . . . . . . 1.2 Problem Statement . . . . . . . . . . . . . 1.2.1 Overview of the Proposed Solution 1.2.2 Context . . . . . . . . . . . . . . . 1.3 Out of Scope . . . . . . . . . . . . . . . . 1.4 Statement of the Contributions . . . . . . . 1.5 Research Design . . . . . . . . . . . . . . 1.6 Dissertation Structure . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. Software Product Lines: An Overview 2.1 Software Product Line Engineering . . . . . . . . 2.2 Software Product Line Essential Activities . . . 2.3 Industrial Experiences with SPL . . . . . . . . . 2.4 Chapter Summary . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. . . . . . . . .. . . . .. A Brief Review on Product Derivation 3.1 Product Derivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 The Challenges and Difficulties . . . . . . . . . . . . . . . . . . . . 3.3 Key Activities for Product Derivation . . . . . . . . . . . . . . . . 3.3.1 Key activity 1: preparing for derivation . . . . . . . . . . . 3.3.2 Key activity 2: product derivation/configuration . . . . . . . 3.3.3 Key activity 3: additional development/testing . . . . . . . 3.4 Product Derivation Approaches . . . . . . . . . . . . . . . . . . . . 3.4.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Support to additionally required developments . . . . . . . 3.4.3 Tools support for product derivation . . . . . . . . . . . . . 3.4.4 Provide detailed of their steps, activities, roles, and artifacts 3.4.5 Flexible and easily adaptable . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . .. . . . . . . . . . . . .. . . . . . . . .. 1 2 3 4 4 6 6 7 8. . . . .. 9 10 11 14 16. . . . . . . . . . . . .. 17 17 19 20 21 22 22 23 29 30 30 30 30. vii.

(10) 3.5 4. Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31. An Industrial Case Study on a Product Derivation Process 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Case Study Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Case Study Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Case and Subjects Selection . . . . . . . . . . . . . . . . . . . 4.3.3 Data Collection Procedures . . . . . . . . . . . . . . . . . . . . Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . Participant-Observation . . . . . . . . . . . . . . . . . . . . . 4.3.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . Step One - Open Coding . . . . . . . . . . . . . . . . . . . . . Step Two - Axial Coding . . . . . . . . . . . . . . . . . . . . . Step Three - Selective Coding . . . . . . . . . . . . . . . . . . 4.3.5 Process Model Validation . . . . . . . . . . . . . . . . . . . . 4.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Product Derivation Techniques and Practices . . . . . . . . . . Parameterization mechanism . . . . . . . . . . . . . . . . . . . Mapping Workflow . . . . . . . . . . . . . . . . . . . . . . . . Use of Database Templates . . . . . . . . . . . . . . . . . . . . 4.4.2 Product Derivation Process . . . . . . . . . . . . . . . . . . . . 4.4.2.1 Phases of Product Derivation Main Flow . . . . . . . . 4.4.2.2 Phases of Customization Flow . . . . . . . . . . . . . . 4.4.2.3 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2.4 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Discuss on the Results . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Validity Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Construct validity . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 External validity . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 The reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Analyzing the MedicWare PD process regarding its support for the Key Activities for Product Derivation . . . . . . . . . . . . . . . . . . . . . 4.7.1 Discussion of results . . . . . . . . . . . . . . . . . . . . . . .. 32 32 33 34 36 36 37 37 39 39 40 41 42 42 43 43 43 43 44 45 45 46 55 62 64 66 68 68 69 69 69 70. viii.

(11) 4.8 5. MedicWare PD process regarding its support for the Preparing for Derivation activities . . . . . . . . . . . . . . . . MedicWare PD process regarding its support for the Configuration activities . . . . . . . . . . . . . . . . . . . . . . MedicWare PD process regarding its support for the Additional development/testing activities . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. A Replicated Case Study on a Product Derivation Process 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Data Collection Procedures . . . . . . . . . . . . . . . . . . . . . . . . Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . Participant-observation . . . . . . . . . . . . . . . . . . . . . . 5.3 Case Study Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Product Derivation Techniques and Practices . . . . . . . . . . Iterative and Incremental Cycles . . . . . . . . . . . . . . . . . Database by Subsystem . . . . . . . . . . . . . . . . . . . . . . Product Derivation from Base Configuration . . . . . . . . . . Use of Requirements Forms to making decision . . . . . . . . . Mapping of the users workflows . . . . . . . . . . . . . . . . . 5.4.2 Product Derivation Process . . . . . . . . . . . . . . . . . . . . 5.4.2.1 Product Derivation Phases . . . . . . . . . . . . . . . . 5.4.2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2.3 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.3 Discuss of Results . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Analyzing the Atena PD process regarding its support for the Key Activities for Product Derivation . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Discussion of results . . . . . . . . . . . . . . . . . . . . . . . Atena PD process regarding its support for the Preparing for Derivation activities . . . . . . . . . . . . . . . . . . Atena PD process regarding its support for the Configuration activities . . . . . . . . . . . . . . . . . . . . . . . .. 70 71 72 72 73 74 74 75 75 75 76 76 77 77 77 78 79 80 80 81 81 96 98 99 101 101 101 102. ix.

(12) 5.6 6. 7. Analyzing of Atena PD process regarding its support for the Additional development/testing activities . . . . . . . 103 5.5.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104. Cross-case Analysis on the Multiple Case Studies 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Cross-case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 The Analysis and Interpretation . . . . . . . . . . . . . . . . . . . . . . 6.3.1 RQ1: How is product derivation performed, in terms of applied strategies and techniques? . . . . . . . . . . . . . . . . . . . . Production mechanism to instantiate products (Product Configuration) . . . . . . . . . . . . . . . . . . . . . . . . . Specify and translate Customer requirements . . . . . . . . . . Resolving variability by selecting features or Making decision . Database Derivation . . . . . . . . . . . . . . . . . . . . . . . Derive products from base configuration . . . . . . . . . . . . . Product Customization . . . . . . . . . . . . . . . . . . . . . . 6.3.2 RQ2: What are the key phases, activities, artifacts, and roles, in the product derivation process? . . . . . . . . . . . . . . . . . . Sales and platform demonstration . . . . . . . . . . . . . . . . Customer requirement elicitation . . . . . . . . . . . . . . . . Analysis of new features . . . . . . . . . . . . . . . . . . . . . Product deployment . . . . . . . . . . . . . . . . . . . . . . . Additional development and testing . . . . . . . . . . . . . . . 6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion 7.1 Research Contributions 7.2 Related work . . . . . 7.3 Future Work . . . . . . 7.4 Concluding Remarks .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 105 105 106 106 107 108 109 109 109 110 110 111 111 111 111 112 112 112 113 115 116 116 117 117. References. 119. Appendices. 128. x.

(13) A Interview Guide 129 A.1 Open questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.2 Specific questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130. xi.

(14) List of Figures. 1.1 1.2 1.3. RiSE Labs Influences . . . . . . . . . . . . . . . . . . . . . . . . . . . RiSE Labs Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4 5 7. 2.1 2.2. The software product line engineering framework (Pohl et al., 2005) . . Essential Product Line Activities (Clements and Northrop, 2001). . . .. 13 14. 3.1. The product derivation process during application engineering (Rabiser et al., 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key activities for product derivation (Rabiser et al., 2011) . . . . . . . . Research on product derivation processes timeline. . . . . . . . . . . .. 18 21 23. 3.2 3.3 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14. 5.1 5.2 5.3 5.4 5.5 5.6 5.7. MedicWare products portfolio. . . . . . . . . . . . . . . . . . . . . . . Case Study Method (Yin, 2008) . . . . . . . . . . . . . . . . . . . . . Research analysis process. . . . . . . . . . . . . . . . . . . . . . . . . Graphical representation of the categories and codes with their associations. Pre-hospitalization workflow supported by the SMART Platform. . . . . Key phases of the MedicWare Product Derivation Process. . . . . . . . Commercialization Activities. . . . . . . . . . . . . . . . . . . . . . . Modeling Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . Modeling Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . Training Specific Guide Instantiation. . . . . . . . . . . . . . . . . . . Strategy of Implementation at different abstraction levels. . . . . . . . . Analysis Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customization phase (Kind of customization requested for the implementation team). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33 35 40 42 45 46 47 49 50 52 55 56 57. Iterative and incremental product derivation lifecycle Interaction among platform databases . . . . . . . . Base Configuration Selection . . . . . . . . . . . . . Key phases of the Atena Product Derivation Process . Sales Activities. . . . . . . . . . . . . . . . . . . . . Project Activities. . . . . . . . . . . . . . . . . . . . Assembly Activities. . . . . . . . . . . . . . . . . .. 78 79 80 81 82 85 89. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 59. xii.

(15) 5.8 5.9. Production Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . Closing Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 93 95. xiii.

(16) List of Tables. 2.1. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8. Software Product Line Industrial Cases (Pohl et al., 2005; Linden et al., 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Key elements to process description (SEI, 2006) . . . . . . . . . . . . . Summary of the Commercialization phase. . . . . . . . . . . . . . . . . Summary of the Modeling phase. . . . . . . . . . . . . . . . . . . . . . Summary of the Deployment phase. . . . . . . . . . . . . . . . . . . . Summary of the Training phase. . . . . . . . . . . . . . . . . . . . . . Summary of the Analysis phase. . . . . . . . . . . . . . . . . . . . . . Summary of the Specific Product Customization strategy. . . . . . . . . Summary of the Reative Product Customization and Platform Evolution strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Coutermeasures to validity thereats in the study (Adapted from (Karlström and Runeson, 2006)). . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Summary of mapping Key Activities for PD to the MedicWare PD Process: Preparing for Derivation activities. . . . . . . . . . . . . . . . . . 4.11 Summary of mapping Key Activities for PD to the MedicWare PD Process: configuration activity. . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Summary of mapping Key Activities for PD to the MedicWare PD Process: development and testing activity. . . . . . . . . . . . . . . . . . . 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8. 6.1. 15 38 49 52 54 55 58 60 62 68 71 72 72. Summary of the Sales phase. . . . . . . . . . . . . . . . . . . . . . . . 84 Summary of the Project phase. . . . . . . . . . . . . . . . . . . . . . . 88 Summary of the Assembly phase. . . . . . . . . . . . . . . . . . . . . 92 Summary of the Production phase. . . . . . . . . . . . . . . . . . . . . 94 Summary of the Production phase. . . . . . . . . . . . . . . . . . . . . 96 Summary of mapping Key Activities for PD to Atena PD Process: Preparing for Derivation activities. . . . . . . . . . . . . . . . . . . . . . . . 102 Summary of mapping Key Activities for PD to Atena PD Process: configuration activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Summary of mapping Key Activities for PD to Atena PD Process: development and testing activity. . . . . . . . . . . . . . . . . . . . . . . . . 103 The cross-case array . . . . . . . . . . . . . . . . . . . . . . . . . . . 108. xiv.

(17) List of Acronyms. PD. Product Derivation. RiSE. Reuse in Software Engineering Labs. SPL. Software Product Lines. UFPE. Federal University of Pernambuco. xv.

(18) 1 Introduction. Software reuse is a considerable alternative to enterprises interested in productivity gains, minimize development costs and time-to-market, and maximize quality and productivity (Northrop, 2002). However, these benefits are not assured by the application of ad-hoc reuse, which is generally an opportunistic reuse, not systematic, and typically restricted to the code level. In this way, Software Product Lines emerges as a systematic way to achieve reuse (Pohl et al., 2005). It applies a strategy that plans the use of assets in multiple products rather than ad-hoc approaches that reuse assets only if they happen to be suitable (McGregor et al., 2002). The SPL approach makes a distinction between domain engineering, where a common platform for a number of products is designed and implemented, and application engineering, where a product is derived based on the platform components (Hotz et al., 2003). The separation into domain engineering and application engineering enables the distinction between the platform building process and specific-products building. However, even developed in different moments, such processes must interact in a manner that is beneficial to both. The process of creating these individual products during application engineering is known as Product Derivation. It is the process of constructing a product from a product line of software assets that is developed using shared product family artifact (Deelstra et al., 2005). In a product line organization, the use of an effective product derivation process can help to ensure the return on investiment required to develop the platform assets (O’Leary, 2010). Product derivation is hence the focus of this dissertation, which reports on our work of investigating the state-of-the-art in this field and provides two industrials case studies which detail empirical evidences on how product derivation is performed in a real organization environment.. 1.

(19) 1.1. MOTIVATION. The remainder of this chapter describes the focus of this dissertation and starts by presenting its motivation in Section 1.1 and a clear definition of the problem in Section 1.2. Section 1.3 describes some related aspects that are not directly addressed by this work. Section 1.4 presents the main contributions. The research design is presented in Section 1.5, and finally, Section 1.6 describes how this dissertation is organized.. 1.1. Motivation. The way that software is produced has changed significantly. The software industry and academia has continuously been challenged to improve engineering practices aiming at delivering products in a faster and more reliable way. For the past decade, several efforts were conducted to achieve effective ways of dealing with the software industry competitive needs. The competitiveness increases according to industry capacity to quickly react to market changes and users requirements (Atkinson et al., 2002). On the other hand, some studies show the quality improvement and time to market reduction in software development when a SPL approach is adopted (Atkinson et al., 2002; Mili et al., 2001; Pohl et al., 2005). Nevertheless, developing a SPL requires time, an high investiments and systematic planning to present positive results, otherwise, the investment can be lost due to failures in the project (Chastek and McGregor, 2002; Clements and Northrop, 2001). In this context, an effective product derivation process is important to an SPL organization in order to ensure that the effort required to develop the platform assets is less than the benefits achieved through using these shared assets by products belonging to products line (Deelstra et al., 2005). However, the area of product derivation is still rather immature (Rabiser et al., 2010). In comparison with the great amount of research outcomes on developing and modeling product lines, only few approaches and tools are available for product derivation (Rabiser et al., 2010). Additionally, existing approaches do not give detailed information on the strategies for product customization, resolving variability, and database model derivation. Also, there is little support for the derivation process other than a high level description of the activities required (O’Leary, 2010). In general, they do not provide guidance on how the approach could be applied or tailored to an industrial settings. In addition, there are few reports (Bosch and Högström, 2001; Deelstra et al., 2005) available describing how SPL organizations derive their products from a product line. Those available have been conducted as informal case studies without sufficient attempt. 2.

(20) 1.2. PROBLEM STATEMENT. to provide scientific rigor with empirical research methods. This lack of scientific rigor makes it hard their validation and replication. Additionally, the existing studies provide few details on the required steps, techniques and practices for the product derivation process. These and other gaps, associated with product derivation, demonstrate a strong need for more research, in order to improve the process efficience and also understanding their key particularities and aspects. One alternative can be through empirical studies, which provide reports on industrial experience describing details about how actual software organizations derive their products from shared product family artifacts. Therefore, the focus of this dissertation is to provide industrial reports which present empirical evidences on how product derivation is performed and what practices are used in a real organization environment. Evidences gathered in the organization were used to understand how the process can be used for other companies interested in the approach.. 1.2. Problem Statement. Encouraged by the motivation depicted in the previous section, the goal of the work described in this dissertation can be stated as follows: This work presents a set of empirical evidences on how product derivation is performed and what practices are used in industrial settings. Evidences gathered in the organizations were used to understand how the process is conducted. The findings and evidences achieved with this work can be used in future research in the product derivation area. Researchers may use this work as a basis for defining, adapting or evaluating their product derivation approaches. Futhermore, it can be used as a starting point for new industrial reports which presenting the companies’s experiences with the product derivation process. In order to achieve the goals stated above, two empirical case studies were performed at two industrial organizations and validated through comparatives analysis on their support for the “Key Activities for Product Derivation” (Rabiser et al., 2011). The studies definition and reports were influenced by (Yin, 2008) and structured based on consolidated guidelines defined in (Runeson and Höst, 2009; Brereton et al., 2008), which allows the study replication and extension.. 3.

(21) 1.2. PROBLEM STATEMENT. 1.2.1. Overview of the Proposed Solution. In order to provide evidence on how product derivation is performed in industrial settings, two case studies were conduced. The remainder of this section presents the context where it was developed.. 1.2.2. Context. This dissertation is part of the RiSE Labs1 (Almeida et al., 2004), formerly called RiSE Project, whose goal is to develop a robust framework for software reuse in order to enable the adoption of a reuse program. RiSE Labs is influenced by a series of areas, such as software measurement, architecture, quality, environments and tools, and so on, in order to achieve its goal. The influence areas are depicted in Figure 1.1.. Figure 1.1 RiSE Labs Influences. Based on these areas, the RiSE Labs is divided in several different projects related to software reuse, as shown in 1.2: • RiSE Framework: Involves reuse processes (Almeida et al., 2004; Nascimento, 2008), component certification (Alvaro et al., 2006) and reuse adoption process 1 http://riselabs.dcc.ufba.br/. 4.

(22) 1.2. PROBLEM STATEMENT. (Garcia, 2010); • RiSE Tools: Research focused on software reuse tools, such as the Admire Environment (Mascena, 2006), the Basic Asset Retrieval Tool (B.A.R.T) (Santos et al., 2006), which was enhanced with folksonomy mechanisms (Vanderlei et al., 2007), semantic layer (Durao, 2008), facets (Mendes, 2008) and data mining (Martins et al., 2008), and the Legacy InFormation retrieval Tool (LIFT) (Brito, 2007), the Reuse Repository System (CORE) (Melo et al., 2008), and the Tool for Domain Analysis (ToolDAy) (Lisboa et al., 2007, 2010);. Figure 1.2 RiSE Labs Projects. • RiPLE: Stands for RiSE Product Line Engineering Process and aims at developing a methodology for Software Product Lines, composed of scoping (Moraes, 2010), requirements engineering (Neiva, 2009), design (Dilorenzo and Meira, 2009; Cavalcanti et al., 2011) , implementation, test (Neto, 2010; Machado, 2010), and evolution management (Oliveira, 2009); • SOPLE: Development of a methodology for Software Product Lines based on services, with some idea of the RiPLE (Medeiros, 2010; Ribeiro and Meira, 2011); • MATRIX: Investigates the area of measurement in reuse and its impact on quality and productivity; • BTT: Research focused on tools for detection of duplicated change requests (Cavalcanti, 2009; Cavalcanti et al., 2009);. 5.

(23) 1.3. OUT OF SCOPE. • Exploratory Research: Investigates new research directions in software engineering and its impact on reuse; • CX-Ray: Focused on understanding the C.E.S.A.R.2 , and its processes and practices in software development.. 1.3. Out of Scope. This work is part of a broader context, as mentioned in the previous Section, in which a complete process for software product lines development has been defined. Thus, the following issues are not directly addressed by this work: • Systematic Process: Systematic and well-defined product derivation process can be assured with maximum return on investment with building the reusable assets (Deelstra et al., 2005). An important issue in a SPL process is to create individual products by reusing the core asset, i.e. performing the product derivation process. However, this aspect can be as complex as core assets development, involving the definition of activities, inputs, outputs, guidelines and roles. Thus, it is out of the scope of this work, but it has direct relationship with this process. • Tool Development: Based on the complexity of the product derivation process, there is explicitly the need for product derivation tools (Cirilo, 2008; Rabiser et al., 2010). However, this aspect can be as complex as individual products creation from shared assets, involving the definition of architecture, infrastructure, patterns, a lot of technologies decisions and requirements. Thus, this issue is out of scope of this work.. 1.4. Statement of the Contributions. As a result of the work presented in this dissertation, a list of contributions can be enumerated: • The empirical studies. Two empirical case studies were conducted in industrial settings to collect evidences on how they derive their products from shared assets. 2 http://www.cesar.org.br/. 6.

(24) 1.5. RESEARCH DESIGN. • Cross-case Analysis. The cross-case analysis to seek a chain of evidences for the relationships found from the analysis of both case studies. By identifying similarities and differences, we intend to provide further insight into issues concerning the processes in order to try to make generalizations base on the results.. 1.5. Research Design. The first activity of the research design defined in this dissertation is the base stage. In this phase was carried out an ad-hoc review in the literature on the Product Derivation area aimed to form a body of knowledge to the next research steps. It aimed at analyzing the available literature on product derivation research. After that, we conducted an industrial case study. This study aimed to investigate and collect information on how the product derivation process is performed in industry. Then, the first case study was replicated in another company in order to provide more robust evidences. Based on the results, we analyzed if the companies processes support the key activities for product derivation (Rabiser et al., 2011) in order to identity the relationship between the state of the practice and art. From the results, we performed a “Cross-case” (Eisenhardt, 1989) analysis between both cases in order to identify similarities and differences in their findings. Figure 1.3 depicts an overview of the research design.. Figure 1.3 Research Design.. 7.

(25) 1.6. DISSERTATION STRUCTURE. 1.6. Dissertation Structure. The remainder of this dissertation is organized as follows: • Chapter 2 presents a brief overview on software product line basic concepts, activities, motivations, as well as some successful industry experiences. • Chapter 3 depicts an overview on current product derivation approaches. Futhermore, it discusses the requirements and important issues that a systematic product derivation processes must consider. • Chapter 4 presents an industrial case study performed at MedicWare3 company in order to gain evidences on how the company derive their products from a shared. product assets. • Chapter 5 describes an industrial case study replication on a PD process conducted at Atena Technology4 company. • Chapter 6 discusses the findings achieved from the cross-case analysis between both case studies carried out in our research. • Chapter 7 provides a set of conclusions based on this work, discussing the main contributions and limitations, the related work, and directions for future work.. 3 http://www.medicware.com.br/ 4 http://www.atenaonline.com.br/. 8.

(26) 2 Software Product Lines: An Overview. The software industry has increasingly been challenged to improve its engineering practice aiming at delivering products in a faster and more reliable way. Thus, software development practices have changed significantly in recent years, since new and affordable strategies should be applied towards reaching such a challenge. In this context, a growing number of software development organizations are adopting strategies that emphasize proactive reuse, interchangeable components, and multiproduct planning cycles aiming construct high-quality products faster and cheaper (McGregor et al., 2002). Software Product Lines Engineering has emerged as a software engineering strategy aimed at providing industry with opprtunities to reach the aforementioned business goals. In SPL development, software reuse is planned, enabled, and enforced (McGregor et al., 2002). As a development strategy, SPL plans the use of software artifacts in several products rather than usual development strategies that apply reuse practices only when necessary or applicable scenarios are identified, i.e., by chance, without any strategic plan (McGregor et al., 2002). The basic characteristic of SPL is to develop a software core asset base that can be (re-)used by every product line member. Thus, instead of developing each products independently, from scratch, components are designed in a way that reuse is encouraged, since it is manageable. The remainder of this chapter is organized as follows: Section 2.1 introduces concepts about software product line engineering, and motivations to introduce software product lines practices. Section 2.2 presents the essential activities of product lines engineering. Section 2.3 presents software product line successful industrial cases and Section 2.4 summarizes the chapter.. 9.

(27) 2.1. SOFTWARE PRODUCT LINE ENGINEERING. 2.1. Software Product Line Engineering. The ability to launch new products and services within a short timeframe has become essential for software development companies, which search new business opportunities (Simon and Eisenbarth, 2002). In this way, mass-customization emerged as a competitive strategy to achieve these goals. However, while for their customers, mass customization means the ability to have an individualized product, for the companies, it means technological investments, which leads to increased products prices or even lower profit margins (Pohl et al., 2005). Hence, a growing number of companies started to introduce common platforms for their different types of products in order to reduce their production cost for a particular kind of product. The systematic combination of mass customization and common platforms is the key for product lines. The platform development consists in building a software standardized infrastructure, planned proactively for reuse, building reusable parts aiming their reuse. Developing products for mass customization means develop this platform employing the variability management concept, i.e. the commonalities and the differences in the products of the product line modeled in a common way (Pohl et al., 2005). A Software Product Lines can be defined as “is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and are developed from a common set of core assets in a prescribed way” (Clements and Northrop, 2001). It captures the commonalities between a set of products while providing for the differences between different instances of the product. The SPL development consists in building a software standardized infrastructure, planned proactively for reuse, building reusable parts aiming their reuse. Developing products for mass customization means develop this platform employing the variability management concept, i.e., the commonalities and the differences in the products of the product line modeled in a common way (Pohl et al., 2005). There are several reasons to develop a family of related products using the software product line paradigm. According to Pohl et al. (2005), the main motivations are: • Reduction of development costs: An essencial reason for introducing product line engineering is the reduction of costs (Pohl et al., 2005). When artifacts are reused in several different kinds of systems from the platform, rather than being developed from scratch to each product, implying in cost reduction. Thus, the fundamental idea of product lines is that it takes a family perspective instead of a. 10.

(28) 2.2. SOFTWARE PRODUCT LINE ESSENTIAL ACTIVITIES. single product perspective, that enables large scale reuse across the family members (Schmid, 2003). • Quality improvements: The product line adoption has also high influence on the quality of the resulting software (Pohl et al., 2005). Since each product is resulted from a set of tested and reviewed assets, the number of defects expected to each new product can be considerably lower and consequently the quality level can be increased; • Reduction of time-to-market: Several products are developed from a common set of assets, leading to significant reductions in both the development costs and timeto-market for individual products. However, product line engineering demands for a higher upfront investment, if compared to single-systems engineering, hence, the initial time-to-market may be higher since, in order to build the reusable platform it is necessary a long and dedicated time to the core assets development; • Benefits for the customers: In a software product line, the products may be customized to specific customers in a simpler way, since variations among products are defined in anticipation, so that a same artifact may attend to different customer needs. Thus, customer can purchase products that fit their individual needs and wishes; • Reduction of maintenance and evolution costs: When artifacts of the platform are changed (e.g. for the purpose of error correction) or new artifacts are added into it, these changes are propagated to all products derived from the platform. It usually leads to a simpler and cheaper maintenance and evolution, if compared to maintain and evolve a bunch of single products in a separate way; • Improved cost estimation: When the reusable core assets are developed, the cost estimations for products from the product line are straightforward and do not include much risks. Consequently, the platform provides a sound basis for cost estimation.. 2.2. Software Product Line Essential Activities. The software product line engineering paradigm is divided into domain engineering and application engineering, as follows:. 11.

(29) 2.2. SOFTWARE PRODUCT LINE ESSENTIAL ACTIVITIES. • Domain engineering (also known as Core Asset Development (Clements and Northrop, 2001)) corresponds to the process of establishing a reusable and customizable platform, by defining what will be shared among the products, as common parts, as well as by defining the variation points expressed in the artifacts, that will enable customizations. This activity is iterative, and should consider the creation of assets that are generic enough to fit different environments and products in a same domain. During domain engineering, the common platform is designed and implemented. It also involves the evolution of the assets in response to product feedback, new market needs, and so on (Clements and Northrop, 2001); • Application engineering (or Produt Development (Clements and Northrop, 2001)) corresponds to the phase where components previously developed are assembled to compose a product. This is the phase where variability is realized so that artifacts customizations come into place. According to (Pohl et al., 2005), “the main goal of application engineering is to derive a software product line application by reusing as many domain artifacts as possible. This is achieved by exploiting the commonality and variability of the product line established in domain engineering”. Product engineers have also the responsibility to provide feedback on any problem or deficiency encountered, in the core assets in order to keep the core asset base in accordance with the products. The separation into domain engineering and application engineering enables the distinction between the platform building process and specific-products building. However, even developed in different moments, such processes must interact in a manner that is beneficial to both. Figure 2.1 illustrates the product line engineering framework representing the domain and application engineering phases and their development disciplines, as defined by (Pohl et al., 2005).. 12.

(30) 2.2. SOFTWARE PRODUCT LINE ESSENTIAL ACTIVITIES. Figure 2.1 The software product line engineering framework (Pohl et al., 2005). Besides the two aforementioned activities, some authors (such as (Clements and Northrop, 2001)) include a third essential activity, named Management. This activity includes technical and organizational management (Linden et al., 2007), where technical management is responsible for requirement control and the coordination between core asset and product development and the organizational management is responsible for the production constraints and ultimately determines the production strategy. Each of these activities is essential, as is the blending of all three. Figure 2.2 illustrates this triad of essential activities. Each rotating circle represents one of the essential activities. All three are linked together and in perpetual motion, showing that all three are essential, are inextricably linked, can occur in any order, and are highly iterative (Clements and Northrop, 2001).. 13.

(31) 2.3. INDUSTRIAL EXPERIENCES WITH SPL. Figure 2.2 Essential Product Line Activities (Clements and Northrop, 2001).. 2.3. Industrial Experiences with SPL. More and more software development organizations are turning to software product lines as a strategies to achieve the reduction of cost and time to market, as well as the improvement the quality of their products. The Celsius Tech, Naval Undersea Warfare Center, Cummins Inc., General Motors, and Nokia are some example of successful industrial cases of applying the software product line engineering paradigm as discribed in Table 2.1. It shows the previous and current scenario, some challenges and some results and metrics of each case.. 14.

(32) A-7E Operational Flight Program. Diesel engine SPL. General Motors Powertrain. Naval Undersea Warfare Center. Cummins Inc.. General Motors. Mobile Phones. Ship System 2000. Celsius Tech. Nokia. Case Study. Company. The initial software architecture for this product line addressed variations in hardware, communication standards, and user interfaces.. Powertrains consist of an engine, transmissions and the associated control system; In the control system, there are electrical components, an electronic control module, and the software that runs this system (General Motors Powertrain SPL).. Modern engines can contain over 100KSLOC of software to microcontrol ignition to produce an optimum mix of power, economy, and emissions.. The NUWC develops and supports different range facilities, including those to test and evaluate systems for the military forces of the USA; In the past, these range facilities were built for specific categories of weapon systems and missions, but these systems have become more and more complex.. Systems comprise 1-1.5 million SLOC of Ada code, are hard-realtime, embedded, and safety-critical.. Previous Scenario. Language Challenge Abstract; The Hardware Challenge; The Feature Challenge.. GMPT began its transition to a product line approach for its embedded powertrain control software in the late 1990’s.. In 1993, faced with the need to produce almost 20 new systems but with staff and resources available only for six.. Challenges Support systems with more than fifty variants; Create a family members including systems for ships from coastal corvettes to cruisers to submarines; Complexity increase; Late system testing; Not a trivial assembling process. Manage the commonality and complexity of the range facilities; Structure the software product line by a reference architecture intended to cover the complete set of range operations; Use the reference architecture for building range systems, some assets have to be tailored for rangeunique capabilities.. 32 different phones are manufactured covering six different protocol standards, a wide variety of functional features and capabilities, different user interface designs, and many platforms and environments.. Controller products built using the GMPT software product line cleanly interface with over 100 vehicle platforms.. TheCummins SPL covers 9 basic engine types ranging over 4- 18 cylinders and 4-164 liters of displacement, with 12 kinds of electronic control modules, 5 kinds of processors, and 10 kinds of fuel systems.. In the year 2004, the software product line included seven systems already installed, with five to six new projects per year.. Able to slash production time, build more systems with fewer people, and increase quality. Current Scenario. Table 2.1 Software Product Line Industrial Cases (Pohl et al., 2005; Linden et al., 2007).. Nokia Mobile Phones is the world’s largest mobile phone manufacturer, and they believe that software product line engineering has helped it to reach that position.. The GMPT software product line is now the basis for nearly all new control modules being developed within GMPT; GMPT expects to take the number of software sets supporting gasoline engine programs from 17 down to 3.. To date, 20 basic software builds have been parlayed into well over 1000 separate products; Cycle time has been reduced from around 250 person months to a few person months; Productivity improvement of 3.6, and an ROI of 10:1.. Cost reduce about 50% using RangeWare SPL; The development time has been reduced from years to months; Staff resources are cut by up to 75%; Increase customer satisfaction.. Decrease time to market - 9 years to 3 years; Reduce costs; Schedule on time and predictable met; Reduce the number of developers - 210 to 30; Stable architecture from start of new project.. Results and Metrics. 2.3. INDUSTRIAL EXPERIENCES WITH SPL. 15.

(33) 2.4. CHAPTER SUMMARY. 2.4. Chapter Summary. This chapter presented a brief overview on software product line concepts. It included fundamental aspects of software product lines and some of motivations for applying it as a suitable software development strategy, highlighting its economical benefits that can be achieved across the large scale and planned reuse of family members. It is exactly these production economies that make software product lines attractive (Clements and Northrop, 2001). However, the real return on investment with building the reusable assets are ensured by the benefits of rapid derivation of individual products (Deelstra et al., 2005). In this context, the next Chapter presents an overview on the product derivation area discussing their fundamental concepts and challenges. Besides, the current approaches to product derivation are discussed along with their outstanding issues.. 16.

(34) 3 A Brief Review on Product Derivation. Product Derivation (PD) is one of the central activities in Software Product Lines (Botterweck et al., 2007). The PD is the process of constructing a product from a product line of software assets that is developed using shared product family artifacts (Deelstra et al., 2005). In a product line organization, the use of an effective product derivation process can help to ensure the return of investiment required to develop the platform assets (O’Leary et al., 2009). Unfortunately, the existing product derivation approaches and tools have developed with different goals, for different purposes, and in different domains. Some approaches apply model-driven development techniques; while others boil down to a collection of guidelines or, in many cases, they provide a high-level methodology or process framework. (O’Leary et al., 2009). The fact is that, although there are a considerable number of approaches, which consider product derivation, still there are many challenges to be overcomed within product derivation field. In this context, the remainder of this Chapter is organized as follows: Section 3.1 presents an overview on the product derivation. In Section 3.2, the challenges are discussed, and the key activities for product derivation process are presented in Section 3.3. Section 3.4 discuss the current approaches to product derivation, and, Section 3.5 summarizes the chapter.. 3.1. Product Derivation. Deelstra, Sinnema, and Bosch define product derivation by, “A product is said to be derived from a product family if it is developed using shared product family artifacts. The term product derivation therefore refers to the complete process of constructing a product from product family software assets” (Deelstra et al., 2005). Thus, in this context, the product derivation process encompasses not only configuration and integration activities,. 17.

(35) 3.1. PRODUCT DERIVATION. but also all activities necessary to assembly products from shared assets. The focus of application engineering is product derivation, which includes the derivation of product artifacts created during domain engineering activities, as for example: the derivation of product requirements from the requirements platform, product architecture from the reference architecture, a set of components from the reusable platform components, and so on (Botterweck et al., 2007). This is achieved by exploiting the commonality and variability of the product line established in domain engineering (Pohl et al., 2005). Figure 3.1 presents a high-level application engineering process adapted by (Rabiser et al., 2010) from the product line engineering framework representation (Pohl et al., 2005). The product derivation is represented by the upper white vertical arrows, which represent the selection and customization of reusable assets during the application engineering. In the same way, the lower white vertical arrows represent deployment activities necessary to achieve a final product (e.g., deploying and integrating new components developed to address customer requirements with the existing derived components) (Rabiser et al., 2010).. Figure 3.1 The product derivation process during application engineering (Rabiser et al., 2010). A well-defined domain engineering associated with a systematic product derivation process, where adequated tools support the activities can lead to automatic generation of products. On the other hand, even with all of these atributes, in many cases, the additional developments are necessary, since that, in practice, many requirements are not accounted. 18.

(36) 3.2. THE CHALLENGES AND DIFFICULTIES. for in the shared product family artefacts and can only be accommodated by adaptation of existing components and assets or even new development (Wolter et al., 2006). Thus, an effective product derivation approach must also consider those cases. Much of the SPL research to date has been focused on the domain engineering activities in a way that application engineers can derive the products with greater ease. However, there are few research dedicated to the product derivation process (O’Leary et al., 2009). In the same way, there are only few reports available about how the software development organizations derive their products from a product lines. These and other difficulties and challenges are discussed in next sections.. 3.2. The Challenges and Difficulties. Deelstra et al. (2005) states “there is a lack of methodological support for application engineering and, consequently, organisations fail to exploit the full benefits of software product families”. Rabiser et al. (2010) identified that in comparison with the great amount of research results on domain engineering activities, only few approaches and tools are available for product derivation. Much of the SPL research to date has been focused more on how to scope, define, and develop product lines rather than on how to effectively utilize them (Rabiser et al., 2010). These issues demonstrate the real necessity of more researches on product derivation field. Despite the importance of product derivation, there are difficulties associated with the process. Hotz et al. (2003) describes it as “slow and error prone, even if no new development is involved”. Griss (2000) identifies the inherent complexity and the coordination required in the derivation process by stating that “. . . as a product is defined by selecting a group of features, a carefully coordinated and complicated mixture of parts of different components are involved”. Therefore, the derivation of individual products from shared assets is still a time-consuming and expensive activity in many organisations (Deelstra et al., 2005). Rabiser et al. (2007) enforce this point when they claim “guidance and support are needed to increase efficiency and to deal with the complexity of product derivation”. According to Rabiser et al. (2010), the area of product derivation is still considered immature. Existing approaches do not give detailed information on the strategies for product customization, resolving variability, and database model derivation. Besides, the existing studies provide few details on the required steps, techniques and pratices to a product derivation process. Additionally, there is little support for the derivation process. 19.

(37) 3.3. KEY ACTIVITIES FOR PRODUCT DERIVATION. other than a high level description of the required activities. In general, no guidance is provided on how the approach could be applied or tailored to an industrial setting. In addition, there are only few reports available about how the software development organizations derive their products from a product lines, and, in general, they have been conducted as informal case studies (Bosch and Högström, 2001; Deelstra et al., 2005) without sufficient attempt to scientific rigor, making hard their repetition and validation. These and other gaps, associated with product derivation, demonstrate a strong need for more research, in order to improve the process efficience and also understanding their key particularities and aspects. One alternative can be through empirical studies, which provide reports on industrial experience describing details about how actual software organizations derive their products from shared product family artifacts.. 3.3. Key Activities for Product Derivation. A recent work “Key Activities for Product Derivation in Software Product Lines” (Rabiser et al., 2010) was developed with the goal to define a set of key activities for product derivation through the comparison of two product derivation approaches. The authors proposed a list of key activities that are common in existing approaches with the purpose of helping researchers and practitioners when developing, adapting or evaluating a product derivation approach. According to Rabiser et al. (2011), from a high-level point of view, Key Activities for PD in SPL comprise the following activities, which need to be conducted in an iterative manner (see Figure 3.2): • Preparing for Derivation: It comprises the preparatory steps required before the actual derivation begins; • Product Derivation/Configuration: It builds the product by reusing as much as possible the platform artifacts, minimizing the amount of product-specific development effort; • Product Development/Testing: It is responsible for the product-specific development, changes and also responsible for the final product testing, to ensure it satisfies customer expectations.. 20.

(38) 3.3. KEY ACTIVITIES FOR PRODUCT DERIVATION. Figure 3.2 Key activities for product derivation (Rabiser et al., 2011). 3.3.1. Key activity 1: preparing for derivation. • Specify and translate customer requirements: In this activity, the customer requirements are specified and if necessary, they are translated into the internal organizational language. This has to be done in close collaboration with the customer; • Define base configuration: It aims to define a base configuration from a set of existing platform configurations. A base configuration is a partial configuration that forms the core of a certain group of products (Deelstra et al., 2005). The base configuration definition allows that experiences made in past projects could be considered during new products derivation, since similar customers often have comparable requirements. • Map customer requirements: Customer requirements are mapped to the base configuration. Requirements presented during product derivation might not be covered by the shared assets have to be negotiated with the customer. The goal is to meet as many of the customer’s needs as possible while retaining the profitability of the platform. • Define role and task structures: The role and task structures for the product derivation project have to be defined. Thus, variability is managed through assigning responsibility to different members of the product team. The goal is to define who is responsible for resolving what remaining variability in product derivation. Also, as the duration of product derivation projects can be quite long, it is important to know who decided what and when.. 21.

(39) 3.3. KEY ACTIVITIES FOR PRODUCT DERIVATION. • Create derivation guidance: Guidance for decision-makers has to be created. “Guidance is essential, especially for domain experts like customers and sales people, who are confronted with many - often technical - decisions or features” (Rabiser et al., 2011). It includes remaining variability explanation in order to deal with complexity issues in representing product line variability since, different people involved in project need to understand different aspects of the provided variability. “Depending on the roles and tasks of the people involved, different representations of variability are required” (Rabiser et al., 2011).. 3.3.2. Key activity 2: product derivation/configuration. • Select assets: Based on the role and task structures previously defined, the assets have to be selected (and customized) from the product line. The use of tool support is necessary for this activity in order to evaluate dependencies and constraints in the variability description and among assets. • Create partial product configuration: A Partial Product Configuration is iteratively created based on the product specific requirements and using existing configurations and components.. 3.3.3. Key activity 3: additional development/testing. • Component development: It develops a new component or adapt an existing platform component in order to implement new functionality. New components should be developed considering the probability of becoming a platform asset member; • Component testing: The components built or adapted have to be tested rigorously, for example through unit testing; • Component integration with partial product configuration:Product derivation involves an integration phase where the new developed and adapted assets are integrated into partial product configuration; • Integration testing: It is performed in order to ensures that no new errors appear due to the integration of the newly developed and adapted assets with the existing architecture, checking the product consistency and correctness.. 22.

(40) 3.4. PRODUCT DERIVATION APPROACHES. • System testing: In a product derivation process, the System testing is performed in order to verifies if a product conforms to the product-specific requirements. If the specific requirements for this iteration have been satisfied, the product is delivered.. 3.4. Product Derivation Approaches. A recent systematic literature review (Rabiser et al., 2010) shows an increasing number of publications, conference tracks, and workshops over the last decade, which demonstrates a growing interest of researchers and practitioners in product derivation. However, there are still few work related to product derivation when compared to the vast amount of research on domain engineering (O’Leary et al., 2009). As showed in the previous Section several researches, such as (Deelstra et al., 2004, 2005; O’Leary et al., 2009), highlight the difficulties and challenging associated with product derivation. In order to address part of these challenges, some approaches have been proposed by academy and industry. A brief description about them is presented in chronologic order of publication. Figure 3.3 summarizes the timeline of research on the product derivation area, in which are marked (with an “X”) the specific-processes to product derivation.. Figure 3.3 Research on product derivation processes timeline.. Next, we briefly describe each approach, their steps and how they support product derivation. Feature-Oriented Reuse Method (FORM) (Kang et al., 1998): It was derived and developed from FODA approach (Kang et al., 1990) and extends it to the software design. 23.

(41) 3.4. PRODUCT DERIVATION APPROACHES. phases. FORM is an approach oriented to feature model and was developed in order to consider both domain and application engineering. The idea of FORM is to analyze domain features and use the identified features to derive products. FORM supports development of such reusable architectures and components (through a process called the (“domain engineering”) and development of applications using the domain artifacts produced from the domain engineering (Kang et al., 1998). The FORM application engineering process is responsible to requirements analysis and feature selection, architecture model selection and application development. The approach starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques. The feature model constructed during the analysis captures features commonality selectable for different applications. Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during actual application development (Kang et al., 1998). However, few orientations are defined related with the architectural model selection and the products derivation using the existing components. FAST (Weiss and Lai, 1999): Based on industrial experiences in software development, Weiss and Lai proposed the Family-Oriented Abstraction, Specification and Translation (FAST) process. The FAST application engineering process covers requirements elicitation, requirements analysis, product configuration, and additional development and testing. Product derivation is greatly simplified by describing the products in the application modelling language and individual products can be developed quickly. The FAST approach is based on semi-automated product derivation where the product is developed through a combination of generation tools and manual product development. However, to enable automatic product derivation, system specifications must be precisely defined and specified. Additionally, as requirements are specified in custom domain specification language, its adoption, in organizations, can be hard. PuLSE/PuLSE-I (Bayer et al., 1999, 2000): Developed by the Fraunhofer IESE, PuLSE (Product Line Software Engineering) is a method engineering framework consisting of three basic elements: Deployment Phases, Support Components and Technical Components. The PuLSE method includes the application engineering process PuLSE-I (I for instantiation) which details how singles systems can be built from the reusable product line infrastructure built during the other PuLSE activities. The PuLSE-I activities encompass planning product derivation, product line model and product architecture instantiation,. 24.

(42) 3.4. PRODUCT DERIVATION APPROACHES. product construction, delivery and maintenance processes. PuLSE can be applied to a variety of enterprise contexts through customizability of components, incremental introduction capability and a maturity scale for structured evolution. However, the approach defines roles and tasks on a very high-level. Futhermore, according to Atkinson et al. (2000), while PuLSE proved to be helpful for introducing sound documentation and development techniques into existing development practices, where a formalised process did not exist, the introduction of PuLSE in industry turned out to be problematic. KobrA Komponentenbasierte Anwendungsentwicklung (Atkinson et al., 2000): It has been derived as an instantiation of PuLSE with the intention of rapid use. It makes use of UML diagrams and templates for the defined development items. The approach is centred on component-based product line development and integrates existing software engineering technologies such as framework and process modelling. “The application engineering process is explicitly defined and is based on decision models to present variability to the customer and to instantiate a concrete application based on framework models” (Rabiser et al., 2010). However, during the framework engineering activity, it does not present guidelines to perform systematic tasks such as domain analysis and domain design. Furthermore, it does not provide a detailed support for product specific development. SEI Product Line Practice Framework (PLPF) (Clements and Northrop, 2001): The Framework describes the essential practice areas for software product line engineering. A practice area is a collection of essencial activities for the software product line engineering that an SPL organization must master (Clements and Northrop, 2001). In addition to the PLPF, the SEI also supports the automation of product derivation. Mcgregor (2005) describes a high-level framework of practices for deciding when to automate product derivation, how to choose the right technology, and how to plan and carry out the derivation process. According to the framework, production plans are used to prepare the derivation process. Such plans are documents describing inputs, necessary activities, and desired outputs of product derivation. Chastek and McGregor (2002) propose detailed guidelines for creating, using, and evaluating such production plans. Although the framework defined by the SEI is a robust description of best practice involving important technical and non-technical aspects grouped in SPL practical areas, it is generic and does not define process support (Almeida, 2007). There is a strong focus. 25.

(43) 3.4. PRODUCT DERIVATION APPROACHES. on planning product derivation with the ultimate goal to automate the derivation process (O’Leary, 2010). Kumbang/Koalish (Asikainen et al., 2004): Based on an extension to the architecture description language Koala (van Ommering et al., 2000), it is an approach for modelling configurable software product families and for automated configuring of product individuals using the models. The approach consists in the idea of the feture and architecture integration in a combined meta-model. From on such models, the Kumbang Configurator tool1 supports the configuration of product models by using an AI inference engine called smodels (Rabiser et al., 2010). However, the approach gives few details on how deal with additional development necessity. AHEAD methodology (Díaz et al., 2005): It is a methodology for SPLs which defines products as “a sequence of refinements applied to the core artifacts” based on the wellknown paradigm. Fine-grained pieces are assembled into components, which are then assembled to products. To this end, the methodology is supported by AHEAD tool suite2 . The tool suite provides supports in specifying the “product build-pro-cess” based on build files, feature selection and component composition capabilities. The AHEAD methodology and tool suite are mainly focused on code assets (Rabiser et al., 2010). Although, the approach applies software engineering principles, it gives only a few suggestions regarding implementation. DRamatically Effective Application development Methodology (Dream) (Kim et al., 2005): Proposed by Kim, the Dream approach integrates both SPL engineering and model-driven architecture. The Dream methodology adopts key activities of SPL and model transformation features of Model-Driven Architecture (MDA). The Dream approach allows the semi-automatic development of products within the product line. Nevertheless, there is little support for the derivation process other than a high level description of the activities required. No guidance is provided as to its use within an industrial setting. Staged configuration (Czarnecki et al., 2005): Based on several extensions to FODA feature models (Kang et al., 1990), Czarnecki et al. (2005) propose to perform derivation in stages, where in each stage some configuration choices are eliminated. The Staged 1 http://www.soberit.hut.fi/KumbangTools/ 2 http://www.cs.utexas.edu/. schwartz/ATS.html. 26.

(44) 3.4. PRODUCT DERIVATION APPROACHES. configuration is an approach oriented to feature model and was developed in order to consider application engineering. In it, a member of a system family is specified by selecting the desired features from the feature model within the variability constraints defined by the model (e.g., the choice of exactly one feature from a set of alternative features). The output of each stage is a more specialized feature model. Although, the staged configuration defines complex models possible choices among reusable assets and diverse interdependencies, the use of such models in actual projects is often not straightforward and intuitive. Futhermore, it focuses on product configuration and is only a high-level attempt at providing the methodological support. Also, tool support is inevitable for its application. PLUS Product Line UML-Based Software Engineering (Gomaa, 2005): The PLUS method provides a set of concepts, modeling techniques and notations to extends the UML-based design methods, used in single systems development, in order to handle software product lines. The method is an iterative object-oriented software process that is compatible with the Unified Software development process (Jacobson et al., 1999) and the spiral process model (Boehm, 1986). The PLUS considers application engineering, performed by tailoring the UML product line models by selecting application features through the feature dependency model. However, it does not define how to identify and group components of the architecture. Moreover, issues related to component implementation and documentation are not discussed (Almeida, 2007). Configuration in Industrial Product Families (conipf) Variability Modeling Framework (COVAMOF) (Hotz et al., 2006; Sinnema et al., 2006): The work by Sinnema et al. (2006) presents a product derivation approach developed from two industrial case studies conducted by Deelstra et al. (2005). The COVAMOF (Configuration in Industrial Product Families (conipf) Variability Modeling Framework) is a variability modeling approach that supports modeling variation points and dependencies at different levels of the software product family, e.g., feature, architecture, and implementation. COVAMOF is supported by the COVAMOF-VS tool suite3 . It provides variation point and dependency views on variability models and allows defining, configuring, and realizing products following the COVAMOF derivation process. The COVAMOF derivation activities cover product definition, product configuration, product realization 3 http://www.cov-amof.com/. 27.