A multi-method research approach to understand the adoption of software product lines in small and medium-sized enterprises

Texto

(1)“A Multi-method Research Approach to Understand the Adoption of Software Product Lines in Small and Medium-Sized Enterprises” By. Jonatas Ferreira Bastos M.Sc. Dissertation. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, AUGUST/2011.

(2) Universidade Federal de Pernambuco Centro de Informática Pós-graduação em Ciência da Computação. Jonatas Ferreira Bastos. “A Multi-method Research Approach to Understand the Adoption of Software Product Lines in Small and Medium-Sized Enterprises”. Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. A M.Sc. Dissertation presented to the Centro de Informática of Universidade Federal de 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) I dedicate this dissertation to myself and all my family, friends and professors who gave me all necessary support to get here..

(4) Acknowledgements. Initially, I would like to thank my great family and friends. Especially, my parents, Arenilton and Elza, my sister Geisa and my nephew Iago, that always stood by me with everything I needed during my life. I love them and appreciate the efforts they have put into giving me the conditions I have now. I would like to express my heartiest thanks to my girlfriend, Islene for her understanding, endless patience and encouragement when it was most required 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. My sincere thanks are extended for the Brazilian National Research Council (CNPq). Without their grant, this M.Sc. would not have been possible. I cordially thank my friends and colleagues that I have met during my journey in Recife. I thank my housemates in Recife, Bruno, Ivan, Iuri and Leandro, and the Jardel, Marco André and Sancler in Salvador and for making me feel so comfortable in these places. I want to express my deep thanks to my colleague Paulo Anselmo for taking intense academic interest in this study as well as providing valuable suggestions that improved the quality of this study. I would like to thank all my friends from RiSE (Crescêncio, Fernando Almeida, Flavio, Heberth, Hernan, Ivonei, Leandro Marques, Luanna, Marcela, Padraig, Raphael, Ricardo, Simone, Thiago Fernandes, Williams, Vanilson, Vinicius e Yguaratã), and friends from LES (Renato, Bruno, Thiago). At the end, I would like to thank God who protected and guided me during this journey.. iv.

(5) Agradecimentos. Inicialmente, eu gostaria de agradecer a minha família e amigos. Especialmente aos meus pais, Arenilton e Elza, minha irmã Geisa e ao meu sobrinho, Iago, por seu apoio incondicional em todos os aspectos da minha vida. Saibam que é imenso o meu amor por vocês! Aprecio e agradeço, de coração, os esforços que vocês têm feito para possibilitar a vida que tenho agora. Gostaria de expressar meus mais sinceros agradecimentos a minha namorada Islene, por sua compreensão, paciência e encorajamento quando a mim mais foi exigido. Gostaria de agradecer a orientação do Professor Eduardo Almeida. Muitas sugestões úteis e incentivo durante o decorrer deste trabalho, que mostrou-se bastante desafiador, a mim foram concedidos. Expressar também o meu agradecimento ao Professor Silvio Meira, por ter me aceito como Estudante de Mestrado. Agradeço ainda ao demais docentes do CIn/UFPE com quem tive a oportunidade de trabalhar, por suas valiosas aulas e discussões. Meus sinceros agradecimentos ao Conselho Nacional de Pesquisa (CNPq), sem o apoio financeiro concedido por esta agência, não seria possível realizar este trabalho. Agradeço de coração a meus amigos e colegas que conheci durante a minha breve “viagem” ao Recife. Agradeço aos colegas que dividiram comigo o espaço de moradia em Recife, Bruno, Ivan, Iuri e Leandro, e a Jardel, Marco André e Sancler em Salvador e que puderam propiciar um ambiente divertido no período que estive nestes lugares. Quero manifestar o meu agradecimento a Paulo Anselmo, por participar diretamente do desenvolvimento deste projeto bem como proporcionar valiosas sugestões que objetivavam a melhoria na qualidade deste trabalho. Gostaria de agradecer aos meus amigos do RiSE (Crescêncio, Fernando Almeida, Flavio, Heberth, Hernan, Ivonei, Leandro Marques, Luanna, Marcela, Padraig, Raphael, Ricardo, Simone, Thiago Fernandes, Williams, Vanilson, Vinicius e Yguaratã), e do LES (Renato, Bruno, Thiago e o Professor Manoel Mendonça). No final, gostaria de agradecer a Deus que protegeu e me guiou durante esta jornada.. v.

(6) Face your fears, live your dreams. —AUTHOR UNKNOWN.

(7) Resumo. A abordagem de Linhas de Produtos de Software (SPL) pode ser considerada uma estratégia eficiente para o reuso de software. SPL oferece significativos benefícios econômicos para as empresas, tais como redução de custos, melhoria da qualidade, e redução do tempo de entrega de produtos. SPL baseia-se no reuso sistemático de artefatos, através da exploração de commonalities (pontos em comum), e o gerenciamento de variabilities (pontos de variação) entre os produtos, desenvolvidos sob uma arquitetura comum. No entanto, a percepção das vantagens de SPL tem um custo associado. Elas demandam maturidade nas técnicas de engenharia de software, planejamento e gerenciamento de reuso, adequadas práticas para gerenciamento e desenvolvimento, sendo capaz de lidar com questões organizacionais e de complexidade arquitetural. Na prática, não é relativamente fácil adotar a abordagem de linha de produto. No contexto de pequenas e medias empresas (SMEs), as dificuldades para adoção de linha de produto são ainda maiores, devido a baixa maturidade organizacional e falta de recursos comum a este tipo de organização. Neste contexto, esta dissertação apresenta um conjunto de evidências empíricas sobre a adoção de linhas de produto em pequenas e médias empresas. O conjunto de evidências contribui para o entendimento da adoção de linha de produto em SMEs por documentar barreiras, as melhores práticas existentes, experiências etc., facilitando a adoção da abordagem de SPL no futuro. Esta dissertação apresenta ainda uma abordagem multi-método para pesquisa empírica em engenharia de software, conduzida através da triangulação, combinando diferentes, mas complementares métodos de pesquisa, aumentando desta maneira a disponibilidade de conhecimento empírico na área.. Palavras-Chave: Software Engineeting; Software Product Lines; SPL Adoption.. vii.

(8) Abstract. Software Product Lines (SPL) can be considered an efficient approach to intra-organizational reuse of software. SPL delivers significant economic benefits for organizations, such as reduced cost, improved quality and time-to-market. It is based upon the systematic reuse of artifacts, through exploiting commonalities and managing variabilities among products, that are established under a common architecture. However, the SPL advantages do not come for free. They demand mature software engineering, planning and management of the reuse, adequate practices for the management and development, being capable of dealing organizational issues and architectural complexity. In practice, it is not relatively easy to adopt a product line approach. In the context of Small and Medium-sized Enterprises (SMEs), the difficulties for adopting SPL are bigger, due to low organizational maturity and lack of resources. Thus, this dissertation presents a set of empirical evidences about the adoption of software product lines in small and medium-sized enterprises. The set of empirical evidences contribute for the understanding of the product line adoption in SMEs by documenting barriers, existing best practices, experiences, and so on, facilitating the adoption of a SPL approach in the future. In addition, this dissertation also presents a multi-method approach to empirical software engineering research, in which triangulation combining different, but complementary, research methods are applied increasing the availability of empirical knowledge on the area.. KeyWords: Software Engineeting; Software Product Lines; SPL Adoption.. viii.

(9)

(10)

(11) Table of Contents. List of Figures. xiv. List of Tables. xvi. List of Acronyms. xvii. 1. 2. 3. Introduction 1.1 Motivation . . . . . . . . . . . 1.2 Scope . . . . . . . . . . . . . 1.2.1 Context . . . . . . . . 1.3 Out of Scope . . . . . . . . . 1.4 Statement of the Contributions 1.5 Dissertation Structure . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. Software Product Lines: An Overview 2.1 Software Product Lines (SPL) . . . . . . 2.1.1 SPL Essential Activities . . . . . Core Asset Development . . . . . Product development . . . . . . . Management . . . . . . . . . . . 2.2 SPL Adoption . . . . . . . . . . . . . . . 2.2.1 Aspects Peculiar to Product Lines 2.3 Small and Medium-sized enterprises . . . 2.4 SPL Adoption in SMEs . . . . . . . . . . 2.5 Chapter Summary . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . .. . . . . . . . . . .. The Multi-method Research Methodology 3.1 Research Philosophy . . . . . . . . . . . . . 3.1.1 Positivism vs. Interpretivism . . . . . 3.1.2 Quantitative vs. Qualitative . . . . . 3.1.3 Inductive vs. Deductive . . . . . . . 3.1.4 Constructive . . . . . . . . . . . . . 3.2 Research Design . . . . . . . . . . . . . . . 3.2.1 Overview of the Research Design . . First Phase - Initial Literature Review. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . .. . . . . . .. 1 2 3 4 6 6 7. . . . . . . . . . .. 9 10 11 11 13 14 15 16 17 18 19. . . . . . . . .. 21 22 22 22 23 23 23 24 25. ix.

(12) . . . . . . .. 26 27 27 28 29 29 29. . . . . . . . . . . . . . . . . . . . . . . .. 31 31 33 33 36 36 36 37 38 38 39 41 41 42 42 43 43 45 48 48 51 53 56 57. An Industrial Case Study on Small to Medium-Sized Organization 5.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Case Study Method . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59 60 60. 3.3. 3.4 4. 5. Second Phase - Mapping Study . . . . . . . . Third Phase - Industrial Case Study . . . . . . Fourth Phase - Survey based on Expert Opinion Research Validity . . . . . . . . . . . . . . . . . . . . 3.3.1 Handling Refinements . . . . . . . . . . . . . 3.3.2 Generalizing the Findings . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. A Systematic Mapping Study on Software Product Lines Adoption 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Related Work on SPL Adoption . . . . . . . . . . . . . . . . . 4.3 Literature Review Method . . . . . . . . . . . . . . . . . . . . 4.4 Research Directives . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Protocol Definition . . . . . . . . . . . . . . . . . . . . 4.4.2 Question Structure . . . . . . . . . . . . . . . . . . . . 4.4.3 Research Questions . . . . . . . . . . . . . . . . . . . . 4.5 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Search Strategy . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Studies Selection . . . . . . . . . . . . . . . . . . . . . Reliability of Inclusion Decisions . . . . . . . . . . . . 4.5.3 Data Extraction . . . . . . . . . . . . . . . . . . . . . . 4.6 Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Classification Scheme and Synthesis . . . . . . . . . . . 4.6.2 Main Findings . . . . . . . . . . . . . . . . . . . . . . Transition Strategies . . . . . . . . . . . . . . . . . . . Organizational Structure . . . . . . . . . . . . . . . . . Adoption Barriers . . . . . . . . . . . . . . . . . . . . . Maturiry Level . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Analysis of the Results and Mapping of Studies . . . . . 4.6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. x.

(13) 5.3 5.4 5.5. 5.6. 5.7 5.8 6. Case Study Context . . . . . . . . . . . . . . . . . . . . 5.3.1 MedicWare Background . . . . . . . . . . . . . Technology Transfer . . . . . . . . . . . . . . . . . . . 5.4.1 RiPLE - RiSE Product Line Engineering Process Case Study Design . . . . . . . . . . . . . . . . . . . . 5.5.1 Research Question . . . . . . . . . . . . . . . . 5.5.2 Case and Subjects Selection . . . . . . . . . . . 5.5.3 Data Collection Procedures . . . . . . . . . . . . Observation . . . . . . . . . . . . . . . . . . . . Interviews . . . . . . . . . . . . . . . . . . . . . 5.5.4 Analysis Procedure . . . . . . . . . . . . . . . . 5.5.5 Validity Procedure . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Transition Strategy . . . . . . . . . . . . . . . . 5.6.2 Organizational Structure and Maturity Level . . 5.6.3 Barriers to the Adoption . . . . . . . . . . . . . 5.6.4 Technology Transfer . . . . . . . . . . . . . . . 5.6.5 Drawbacks . . . . . . . . . . . . . . . . . . . . Threats To Validity . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. Survey based on Expert Opinion to Understand SPL Adoption 6.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Research Approach . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Survey Objectives and Design . . . . . . . . . . . . 6.2.2 Survey Instrument and Evaluation . . . . . . . . . . 6.2.3 The Questions . . . . . . . . . . . . . . . . . . . . 6.3 Expert Opinion . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 The Number of Experts . . . . . . . . . . . . . . . . 6.3.2 Expert Selection . . . . . . . . . . . . . . . . . . . 6.3.3 Expert Bias and Calibration . . . . . . . . . . . . . 6.3.4 Expert Opinion Aggregation . . . . . . . . . . . . . 6.3.5 Data Collection and Analysis . . . . . . . . . . . . . 6.3.6 Collected Data . . . . . . . . . . . . . . . . . . . . 6.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Role in SPL Projects . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. 62 62 65 66 67 68 69 69 69 70 71 72 74 74 75 76 78 79 79 80. . . . . . . . . . . . . . .. 81 82 82 84 84 84 85 86 87 87 88 88 89 89 89. xi.

(14) 6.4.2. 6.5 6.6 6.7 7. 8. Transition Strategies in the small and Medium-sized companies contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 The impact and the best organizational structure to the SPL adoption 6.4.4 Relationship between organizational structure and transition strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.5 Impact of the organizational maturity on the success of the SPL adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.6 Relationship between Transition Strategy and Maturity Level . . 6.4.7 SPL Adoption Barriers . . . . . . . . . . . . . . . . . . . . . . Main Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Research Synthesis and Evaluation of the Multi-Method Approach 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Justification for the Multi-Method Approach . . . . . . . . . . . 7.3 Research Synthesis . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Summary of the Findings . . . . . . . . . . . . . . . . . . . . . 7.4.1 Findings of the Multi-Method Approach . . . . . . . . . 7.5 Multi-Method Approach benefits and drawbacks . . . . . . . . . 7.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion 8.1 Research Contributions . 8.2 Related Work . . . . . . 8.3 Future Work . . . . . . . 8.4 Academic Contributions 8.5 Concluding Remarks . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . . . .. . . . . .. . . . . . . .. . . . . .. . . . . . . .. . . . . .. 90 91 93 94 95 96 97 98 99. . . . . . . .. 102 102 102 103 104 109 110 111. . . . . .. 114 115 116 116 116 117. Bibliography. 118. Appendices. 132. A Mapping Study 133 A.1 Search Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A.2 Journals and Conferences . . . . . . . . . . . . . . . . . . . . . . . . . 133. xii.

(15) B Survey Instrument. 135. xiii.

(16) List of Figures. 1.1 1.2. RiSE Labs Influences . . . . . . . . . . . . . . . . . . . . . . . . . . . RiSE Labs Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.1 2.2 2.3 2.4 2.5. Essential Product Line Activities . . . . . . . . . . . . . Core Asset Development . . . . . . . . . . . . . . . . . Product Development . . . . . . . . . . . . . . . . . . . Adoption Goals, Strategies, and Plans . . . . . . . . . . Distribution of the enterprises in Brazilian’s industry of services - Brazil, year 2005. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . software . . . . .. . . . . . . . . . . . . and . . .. 12 13 13 17. 3.1 3.2 3.3 3.4. Research Design . . . . . . Initial Review of Literature. . Mapping Study. . . . . . . . Industrial Case Study . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 25 26 27 28. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8. Essential Product Line Activities . . . . . . . . . . . . . Search Process workflow . . . . . . . . . . . . . . . . . Filters of the selection process . . . . . . . . . . . . . . Primary studies filtering categorized by source. . . . . . Distribution of primary studies by their publication years Number of studies by research topics. . . . . . . . . . . Number of studies by research questions. . . . . . . . . Research method vs Research questions. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 36 39 40 41 42 51 52 52. 5.1 5.2 5.3 5.4 5.5 5.6. The Case Study process steps (adapted from (Yin, 2008)). . . . . . . . . MedicWare products portfolio. . . . . . . . . . . . . . . . . . . . . . . MedicWare workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . Adoption plan steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . RiPLE Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research analysis process (adapted from Karlström and Runeson (2006)).. 62 63 64 66 66 71. 6.1 6.2 6.3 6.4. Steps Survey. . . . . . . . . . . . . Experts Roles. . . . . . . . . . . . . Experts roles working on Academy. Experts roles working on Industry. .. 83 89 90 90. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 4 5. 18. xiv.

(17) 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16. Transition Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact of the Organizational Structures. . . . . . . . . . . . . . . . . . Organizational Structures. . . . . . . . . . . . . . . . . . . . . . . . . Relationship between Transition strategy and Organizational Structure. . Impact of the organizational maturity on the success of the SPL adoption. Agreement level regarding to if the processes areas and maturity levels. Impact of the organizational maturity on the success of the SPL adoption. Relationship between Transition Strategy and Maturity Level. . . . . . Barriers: Project Sponsors and Customers view. . . . . . . . . . . . . . Barriers: Organization and Development groups view. . . . . . . . . . . Barriers: Organization and Development groups view. . . . . . . . . . . Correlation between barriers and maturity level. . . . . . . . . . . . . .. 91 92 92 93 94 95 95 96 96 97 100 101. B.1 Survey Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140. xv.

(18) List of Tables. 4.1 4.2 4.3 4.4 4.5. Search Strings. . . . . . . . . . . . . . . . . . . . . . Research Type Facet (Wieringa et al., 2005). . . . . . . Adoption Barriers. . . . . . . . . . . . . . . . . . . . Number of Studies per Research Questions. . . . . . . Relationship among Transition Strategies and Barriers.. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 38 43 49 53 55. 5.1 5.2 5.3. Countermeasures to validity threats in the study (adapted from Karlström and Runeson (2006)). . . . . . . . . . . . . . . . . . . . . . . . . . . . Adoption Plan Execution. . . . . . . . . . . . . . . . . . . . . . . . . . RiPLE Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 72 74 74. 6.1. List of the Study Experts. . . . . . . . . . . . . . . . . . . . . . . . . .. 87. 7.1. Number of Studies per Research Questions. . . . . . . . . . . . . . . . 112. A.1 Digital Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A.2 Journals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.3 Conferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134. xvi.

(19) List of Acronyms. C.E.S.A.R. Recife Center For Advanced Studies and Systems RiPLE. RiSE Product Line Engineering Process. RiSE. Reuse in Software Engineering Labs. SMEs. Small and Medium-sized Enterprises. SPL. Software Product Lines. xvii.

(20) 1 Introduction. In the software engineering field, researchers and practitioners have been searching for methods, techniques and tools that would allow for improvements in costs, time-tomarket and quality (Almeida et al., 2007), particularly due to the challenges of increasing complexity and size of software systems. Software reuse is a key aspect for software organizations interested in these gains (Mili et al., 2001), since a set of reusable assets is used to solve recurring problems instead of performing the same activities over and over again (Almeida et al., 2007). However, when the reuse initiative is based on an approach focusing on small-scale, ad-hoc reuse (i.e., typically restricted to the code level), these benefits may not be perceived (Linden et al., 2007). On the other hand, approaches that enables systematic assembling and configuring software parts to be reused across various products can enable organizations to experience the real software reuse benefits. In this sense, the Software Product Lines engineering (SPL), an innovative, growing concept in software engineering, was developed towards a systematic and prescribed way to achieve reuse (Pohl et al., 2005). SPL is a planned, systematic and pro-active reuse strategy, through exploiting the similarities within a set of products. SPL can enable organizations to achieve significant reductions in terms of development and maintenance costs and time to market as well (Clements and Northrop, 2001; Pohl et al., 2005) and remarkable quantitative improvements in productivity, product quality and customer satisfaction (Northrop, 2002), thus addressing the problems aforementioned. However, the SPL advantages do not come for free. They demand mature software engineering, planning and management of the reuse, adequate practices for the management and development, being capable of dealing organizational issues and architectural complexity. If these points are not considered, as otherwise huge economic benefits, the line success will be missed (Pohl et al., 2005). In practice, it is not relatively easy to adopt a product line approach because it involves. 1.

(21) 1.1. MOTIVATION. more than architectural issues alone; it also affects the company business, processes and organization (McGregor et al., 2002). Nevertheless, the product line adopters are more concerned about the issues related to the technical aspects of development, such as architecture development or domain analysis (McGregor et al., 2002; Böckle et al., 2002). However, these technical capabilities alone cannot guarantee the successful SPL adoption. In the context of small and medium-sized enterprises (SMEs), the difficulties for adopting SPL are bigger, due to low organizational maturity and lack of resources (Gacek et al., 2001). The adoption of software product lines in small and mediumsized enterprises is hence the focus of this dissertation, which presents on our work of investigating the state-of-the-art in this field and providing a set of empirical evidences in order to promote the understanding of the adoption of product lines. The remainder of this chapter describes the focus and structure of this dissertation. Section 1.1 starts presenting its motivations, and a clear definition of the problem scope and context are described in Section 1.2. Some related aspects that are not directly addressed by this work are shown in Section 1.3. In the Section 1.4, the main contributions of this work are discussed, and finally, Section 1.5 describes how this dissertation is organized.. 1.1. Motivation. The software industry is increasingly faced with a growing demand for customized products, in order to meet a wide variety of customer specific needs. It has led to increase in the product diversity the companies have to deal with. If scale and time were considered throughout the years, companies that have diverse implementations might probably redevelop assets that had already been developed. As a consequence, companies waste workforce and budget. SPL is in frame with this need of software companies, which requires more and more meeting their customer requirements and handling with a growing diversity of products. The SPL practices offer a systematic reuse approach which is focused on improving the development time-to-market, cost, quality, portfolio scale and scope and other business drivers, such as customer satisfaction (Northrop and Clements, 2007). An important principle behind SPL is that, among the different needs, i.e., diverse projects implementations, there might be large amounts of common parts, which enables a potential for high levels of reuse among different projects. Companies have discovered that a product line strategy can produce many benefits,. 2.

(22) 1.2. SCOPE. and ultimately give the organizations a competitive edge (Northrop and Clements, 2007). Even though the maturity of techniques and mechanisms for transfer SPL is considerable, there are many barriers to organizational adoption of product line (Northrop, 2004). Moreover, what is not as clear, is how to effectively achieve an operational software product line, often called product line adoption (Northrop, 2004). In this context, the stage of adoption contributes to a large extent to the success or failure of a product line effort and the potential benefits of product lines can be lost if the adoption stage is no well planed. Due to these factors, there is a growing interest, by the SPL community in the phases of adoption, but so far, the reports about successful applications of SPL in the Product Line Hall of Fame1 are mainly from large-scale project in large enterprises. However, in Brazil, SMEs are an important portion of the industry, it represents around 98% of all Brazilian software development companies (SOFTEX, 2009). Moreover, the systematic mapping study conducted in order to establish a basis for this study, as will be further detailed in Chapter 4, pointed out some topics, regarding SPL adoption, which deserve special attention, in special, there is a lack of research in this area combining evidences from different sources. Therefore, the focus of this dissertation is to understand the adoption of software product lines in small and medium-sized enterprises and provide a set of empirical evidences, in order to maximize the benefits of systematic reuse reducing the overall effort in SPL adoption in the context of SMEs.. 1.2. Scope. Motivated by the challenges presented 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 about the adoption of software product lines adoption in small and medium-sized enterprises. The set of empirical evidences can contribute for the understanding of the product line adoption in SMEs by documenting barriers, existing best practices, experiences, and so on, making the adoption of a SPL approach easier in the future. In order to achieve the goal stated, a multi-method approach to empirical software engineering research (Chapter 3) was proposed. A multi-method (Brewer and Hunter, 1 Software. Product Line Hall of Fame. http://splc.net/fame.html. 3.

(23) 1.2. SCOPE. 1989) approach, or triangulation (Martin, 1982) combines different, but complimentary, research methods. It involved the mapping study, an industrial case study, and a Survey based on Expert Opinion in software product lines adoption, which will be presented, respectively in Chapter 4, Chapter 5, and Chapter 6. Next, it is presented the context in which this work is inserted.. 1.2.1. Context. This dissertation is part of the RiSE Labs2 (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 showed 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 Figure 1.2: • RiSE Framework: Involves reuse processes (Almeida et al., 2004), component certification (Alvaro et al., 2006) and reuse adoption processes (Garcia et al., 2008). 2 http://labs.rise.com.br. 4.

(24) 1.2. SCOPE. • 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, 2008; Lisboa et al., 2007).. 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 et al., 2009; Cavalcanti et al., 2011a), implementation, test (Neto, 2010; Machado, 2010), and evolution management (Oliveira, 2009). • SOPLE: Development of a methodology for Software Product Lines based on services, based on the fundamentals of the RiPLE (Oliveira, 2009; Ribeiro et al., 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). • Exploratory Research: Investigates new research directions in software engineering and its impact on reuse;. 5.

(25) 1.3. OUT OF SCOPE. • CX-Ray: Focused on understanding the C.E.S.A.R. 3 , 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 framework for software product lines development has been designed. Thus, some SPL topics are not described in this work, and some specific issues regarding adoption are not considered in the scope of this dissertation, such as: • Systematic Process. It is known that a well-defined SPL adoption process can bring benefits for the organizations that adopt it. However, currently, several organizations have their own software development processes and context in which the roles and the activities are defined and coordinated, at least, in theory. Thus, this research provides a set of evidences and recommendations for organizations adopt SPL, but not define systematically steps to be followed. We believe that is important to understand it first and after that defines new solution proposals. • Product Development. An important issue in a SPL process is to create individual products by reusing the core assets, i.e. performing the products development with reuse. However, the adoption process investigated during this research, involves these related to creation of product line platform.. 1.4. Statement of the Contributions. As a result of the work presented in this dissertation, the following contributions can be highlighted: • An evolutionary multi-method approach, that combines primary and secondary studies in the composition of fundationsfor this work. The multi-method approach (Brewer and Hunter, 1989) is a new technique for performing empirical software engineering research. The application of the approach to investigate Software Product Lines Adoption in SMEs led to a three phased research program which demonstrates its strengths in comparison to a single-method approach. 3 http://www.cesar.org.br/. 6.

(26) 1.5. DISSERTATION STRUCTURE. • The realization of a systematic mapping study on software product lines adoption, which can provide for the research community the state-of-the-art in the field, besides open issues. • The definition, planning, operation and analysis of an industrial case study, in order to identify the evidences in this natural context. • A Survey based on Expert Opinion to reinforce the findings and open issues identified in the mapping and case study. In addition, the following paper, reporting on the mapping study we conducted was accepted for publication: • Bastos, J. F., Neto, P. A. M. S., Almeida, E. S., and Meira, S. R. L., “Adopting software product lines: A systematic mapping study”, in Evaluation and Assessment in Software Engineering - EASE, Durham, UK, 2011. In addition, we are working on two journals papers on it.. 1.5. Dissertation Structure. The remainder of this dissertation is organized as follows: • Chapter 2 reviews the essential topics used throughout this work: Software Product Lines, Software Product Lines Adoption, and SMEs. An initial discussion on the relation between SPL Adoption and SMEs is also presented. • Chapter 3 presents an evolutionary multi-method approach that combines primary and secondary studies in the development of researche in software engineering. The research design includes the selection of research methods and a description of how these methods were executed. Moreover, potential threats to the research validity are identified. • Chapter 4 presents a mapping study in order to investigate the state-of-the-art of SPL adoption practices, synthesize available evidence to suggest important implications for practice, as well as, identifying research trends, open issues, and areas for improvement.. 7.

(27) 1.5. DISSERTATION STRUCTURE. • Chapter 5 presents an industrial case study, performed in a small to medium-sized organization in order to gain a better understanding of the adoption of SPL in SMEs providing new findings and contributing by defining and improving the way to execute and report industrial case studies. • Chapter 6 presents a survey with SPL experts to investigate the adoption of SPL in SMEs, exploring several viewpoints, such as: the transition strategies, organizational structures, barriers and maturity. It combines ideas from (Kitchenham and Pfleeger, 2008) with good practices from expert opinion (Li and Smidts, 2003), providing an expert perspective in relation to the results obtained by Chapters 4 and 5. • Chapter 7 presents the approach for synthesis and evidences extracted of the application of the multi-method approach performed in this dissertation. Moreover, the strengths and weaknesses of the multi-method approach as well as the lessons learned are discussed. • Chapter 8 provides a set of conclusions discussing our contributions and limitations, presents the related work, and outline directions for future work. • Appendix A presents the information sources from where primary studies were extracted, to serve as basis for the mapping study analysis, as reported in Chapter 4. • Appendix B presents the self-administered questionnaire applied in the survey based on experts, as reported in Chapter 6.. 8.

(28) 2 Software Product Lines: An Overview. Software is everywhere and it increasingly becomes the key asset for modern, competitive products. No matter how simple or complex, no matter how large or small, there is hardly any modern product without software (Linden et al., 2007). Thus, software development is a complex composition of activities requiring knowledge about technologies, processes, people, and application domains, usually with volatile requirements. On the other hand, the market of software development needs to rapidly build software products with quality, reduction of costs, fast adaptation to changes, and reduced product time-to-market delivering software products that meet customers needs. In order to handle the complexity and the needs from these previous remarks, several approaches appeared in the software development scenario. One of them, Software Product Lines (SPL) aim to attend to these challenges through systematic and planned reuse of previous development efforts among a set of similar products (Pohl et al., 2005). But, the software product line activities demand mature software engineering, planning and management of the reuse, adequate practices for the development, being able of dealing with organizational issues and architectural complexity (Pohl et al., 2005). Thus, the adoption is an important step in the product line approach, since it involves more than architectural issues; it also affects the company business, processes and organization (McGregor et al., 2002). This Chapter describes relevant background concepts to this research. It is organized as follows: Section 2.1 introduces concepts regarding Software Product Lines; SPL adoption is introduced in Section 2.2; Section 2.3 presents the small and medium-sized enterprises; Section 2.4 sketches the relationship between the previously addressed concepts; finally, the Chapter Summary is addressed in Section 2.5.. 9.

(29) 2.1. SOFTWARE PRODUCT LINES (SPL). 2.1. Software Product Lines (SPL). In the intense business competitive situation, technical, business and environment requirements change at a tremendous speed. The ability to launch new products and services with major enhancements within short timeframe has become essential for companies to keep up with new business opportunities (Simon and Eisenbarth, 2002). Gradually, the number of people who could afford to buy various kinds of products increased (Pohl et al., 2005). Furthermore, it is important to point out that no two customers are identical. Each one has unique requirements that can only be completely satisfied by a custom solution. However, in many organizations, similar systems are developed by separate groups. Usually, these systems have the same origin, but in order to satisfy the different requirements and schedules of individual customers, different projects develop the systems in parallel. As a consequence, reuse across systems is ad-hoc. In other words, the same copy of code is maintained by different groups, resulting in increased development costs (Yoshimura et al., 2006). Companies of all sizes and in all markets develop strategies to meet the needs stated previously. A growing number of software development organizations are adopting strategies that emphasize proactive reuse, interchangeable components, and multi-product planning cycles to construct high-quality products faster and cheaper (McGregor et al., 2002), thereby meeting customer needs. The SPL engineering seamlessly address these strategies. Software product line engineering has proven to be the methodology for developing a diversity of software products and software-intensive systems at lower costs, in shorter time, and with higher quality (Pohl et al., 2005). By definition, a SPL is a set of softwareintensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way (Clements and Northrop, 2001). In SPL, products are developed from a common set of assets, in contrast to being developed separately, from scratch, or in an arbitrary fashion (Clements and Northrop, 2001). In addition, in constrast with what is customary, “design reuse” in SPL does not simply mean taking an existing design, copying it and modifying it to some particular need, but rather the development of a model (or set of models) that can be reused in a disciplined fashion. They formally manage and control the variations among the products in the product line. The identification of commonality (common features for the SPL members) and. 10.

(30) 2.1. SOFTWARE PRODUCT LINES (SPL). variability (difference among members) is crucial for product diversification. Architecture is also a key concept of software product line engineering. It determines how products are derived efficiently from the core assets. To allow the derivation of several different products, a product line architecture has to deal with variation. The architecture’s support for variation determines the scope of the product line (Pohl et al., 2005), so that, it can be configured to match a diverse range of requirements. The overall engineering efforts during software product line development can be divided into three essential interrelated activities: (i) Core Asset Development (Domain Engineering), (ii) Product Development (Application Engineering) and (iii) Management. These activities are further exploited in the next section. Different terms are adopted in the academy and industry to express the same meaning. They might refer to product line as a product family, to core asset set as platform, or to the products of the SPL as customizations or members instead of products. Besides, Core asset development might be referred as domain engineering, and product development as application engineering (Neto, 2010). In this work, the terms adopted are core asset development and product development.. 2.1.1. SPL Essential Activities. Software Product Lines combine three essential and highly iterative activities that blend business practices and technology. Firstly, the Core Asset Development activity that does not directly aim at developing a product, but rather aims to develop assets to be further reused in other activities. Secondly, Product Development activity which takes advantage of existing, reusable assets. Finally, Management activity, which includes technical and organizational management (Linden et al., 2007). Figure 2.1 shows 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). Each activity is next detailed: Core Asset Development Core Asset Development is the life-cycle that results in the common assets that in conjunction compose the product line’s platform (Linden et al., 2007). The goal of this activity is to define the commonality and the variability of the product line, and thus for establishing the reusable artifacts and then a production capability for products (Pohl. 11.

(31) 2.1. SOFTWARE PRODUCT LINES (SPL). Figure 2.1 Essential Product Line Activities. et al., 2005). Figure 2.2 shows the core asset development activity along with its outputs and necessary inputs. This activity, like counterparts, is iterative. The rotating arrows in Figure 2.2 suggest that there is no one-way causal relationship from inputs to outputs, they rather affect each other. For example, expanding the product line scope (one of the outputs) may admit whole new classes of systems to examine as possible sources of legacy assets (one of the inputs). Correspondingly, a production constraint may lead to restrictions on the product line architecture (an output). This restriction, in turn, will determine which preexisting assets (another contextual factor) are candidates for reuse or mining (Clements and Northrop, 2001). Core assets include, but are not limited to, the architecture and its documentation, specifications, software components, tools such as component or application generators, performance models, schedules, budgets, test plans, test cases, work plans, and process descriptions (Clements and Northrop, 2001). Although it can be possible to create core assets that can be used across the products without any adaptations, in many cases, some adaptations are required to make core assets usable in the broader context of a product line. Variation mechanisms used in core assets help to control the required adaptations and to support the differences among the software products (Bachmann and Clements, 2005). These adaptations should be planned before development and made easy for the product development team to use without putting at risk existing properties of the core. 12.

(32) 2.1. SOFTWARE PRODUCT LINES (SPL). Figure 2.2 Core Asset Development. assets. Product development In the product development activity, products are physically developed from core assets, based on the production plan, to satisfy the requirements of the software product line. The essential inputs of product development activity are requirements, product line scope, core assets and the production plan (Ahmed et al., 2009).. Figure 2.3 Product Development. In possession of the production plan, which details how the core assets will be used. 13.

(33) 2.1. SOFTWARE PRODUCT LINES (SPL). in order to build a product, the software engineer can assemble the product line members. The product requirement is also important to realize a product. It is crucial to avoid the product line decay and keep the core asset base healthy. Figure 2.3 illustrates the product development activity along with its outputs and influential contextual factors. As in Figure 2.2, the rotating arrows in Figure 2.3 indicate iteration and involved relationships. For example, the existence and availability of a particular product may well affect the requirements for a subsequent product. As another example, building a product that has previously unrecognized commonality with another product already in the product line will create pressure to update the core assets and provide a basis for exploiting that commonality for future products (Clements and Northrop, 2001). Moreover, this activity has an obligation to give feedback on any problems or deficiencies encountered with the core assets, in order to keep the core asset base in accordance with the products. Management Management plays a vital role in successfully institutionalizing software product line within an organization because it provides and coordinates the infrastructure required. Management activity involves essential activities carried out at technical and organizational level to support the software product line process (Ahmed et al., 2009). Technical management oversees the core asset development and the product development activities by ensuring that the groups that build core assets and the groups that build products are engaged in the required activities, follow the process defined for the product line, and collect sufficient to track progress (Clements and Northrop, 2001). This means, not only technical aspects, here represented by the development of core assets and products, are considered when developing SPL, but managerial and organizational activities as well. The set of assets and the plan for how they are used to build product do not just materialize without planning, and they certainly do not come free. They require organizational foresight, investment, planning and direction. The disciplined use of the assets to build products does not just happen either. Management must direct, track, and enforce the use of the assets. Software product lines are as much about business practices as they are about technical practices (Clements and Northrop, 2001). Although organizations are different, in terms of nature of their products, market or mission, business goals, organizational structure, culture and policies, software process disciplines, and so on, these essential activities apply in every situation, since they represent the highest level. 14.

(34) 2.2. SPL ADOPTION. of generality which involves the most important aspects regarding SPL development. In general, organizations accomplish this division of responsibility in a variety of ways. Some organizations have teams dedicated to each role and others use the same people for both (McGregor et al., 2002). It depends on the strategy, budget, staff availability, among other aspects. In fact, it is valid to mention that there is no "first" activity, i.e. in some contexts, existing products are mined for core assets, whereas in others, core assets may be developed or procured for future use. According to (Clements and Northrop, 2001), in many cases, organizational management is the authority that is responsible for the ultimate success or failure of the product line effort.. 2.2. SPL Adoption. In recent years, software development organizations have shown a growing interest in the adoption software product lines concept in order to compete in a global market that emphasizes cost, quality, and adherence to the delivery schedule. (Pohl et al., 2005) report that software product line engineering is a growing software engineering sub-discipline, and many organizations, are using it to achieve extraordinary gains in productivity, time to market, and product quality. The economic potential of software product line has also been recognized in the software industry (Clements and Northrop, 2001). However, for many organizations, there are considerable barriers to adoption of product line practices. Time to devote to product line activities and cultural resistance are the most significant barriers (Northrop, 2004). Moreover, the development of the product line infrastructure including new practices, processes, and tool support - also requires investment. Many organizations struggle with how to allocate the necessary start-up funds. Other barriers can also prove challenging and, in some cases, insurmountable. An organization that cannot overcome its barriers to product line adoption will not succeed. An organization that does not know what is necessary to succeed with software product lines is unlikely to succeed, at least in a cost-effective, timely way. An organization that does not know how to go about product line adoption is unlikely to succeed, at least not without great difficulty and cost (Northrop, 2004). For all the reasons cited above, software product line adoption is a special case of a technology change project in that it helps organizations adopt a new technology or new way of doing business (Northrop, 2004). Technology change projects are undertaken to help organizations prepare themselves to adopt a new technology or a new way of. 15.

(35) 2.2. SPL ADOPTION. doing business and are highly dependent on the context of the organization; an invariant sequence of steps to execute the project is inappropriate. Successful technology change projects take into account no only the specific technology involved but the nontechnical or human aspects of change (Clements and Northrop, 2001). According to (Matturro and Silva, 2005), all technology change involves assessing the current state, identifying the desired state, and bridging the gulf between the two. The differences between what an organization is already doing about its business and what it will have to do in the future, commonly called “strategy gap”, can lead to a “knowledge gap” between what the organization knows at present and what it must know in the future to implement its new strategy. Therefore, all change of technology - especially in cases that involves SPL adoption - requires vision, skills, incentives, resources, and a plan (Northrop, 2004).. 2.2.1. Aspects Peculiar to Product Lines. The adoption of software product lines differs in some sense for the adoption of other kinds of technology. Adopt product lines is about the judicious and timely application of product lines practices (Clements and Northrop, 2001). This involves moving from some form of developing software-intensive systems with a single-system mentality to developing them as a software product line (Northrop, 2004). The adoption objectives involves to have a core asset base, supportive processes, and organizational structures; to develop products from that asset base in a way that achieves business goals; and to institute mechanisms to improve and extend the software product line adoption effort as long as it makes sense. However, depending on the scenario, achieve the goal of adoption can become a complex activity. In order to avoid additional complexities during the stage of adoption (Bühne et al., 2003) argues that an organization that intends to adopt a product line approach must have goals in mind. To achieve its goals, the organization selects one or more adoption strategies that specify how it will embrace product lines practice. An adoption plan then shows in detail what activities or tasks must be accomplished to implement those strategies. Figure 2.4 shows the tightly knit connection between the adoption goals, strategies, and plans. In this sense, the whole concept of product line adoption becomes very personal to the organization; the exact context seems to play a significant role in shaping the adoption (Bühne et al., 2003). Therefore, the transfer must be systematically planned and realized.. 16.

(36) 2.3. SMALL AND MEDIUM-SIZED ENTERPRISES. Figure 2.4 Adoption Goals, Strategies, and Plans (Northrop, 2004). 2.3. Small and Medium-sized enterprises. Recent years have changed both the characteristic of the software industry and the composition of the companies engaged in development. In this scenario, the small and medium-sized companies have gained a prominent role in market. Based on the number of employees, small companies are under 50 employees, medium-sized companies have between 50 and 100 employees, and large companies have over 100 employees (SOFTEX, 2009). This categorization is not universal and can vary in different regions. For example, small companies are generally under 100 employees in the United States while fewer than 50 employees in the European Union (Greenwood, 1999). Small and medium-sized companies, together with large companies, have coexisted for quite a long time, which makes it difficult to trace the origin of so-called small business. However, for the small and medium-sized software companies, the true spring can be dated back to 1970s, when the third industrial revolution happened. The rapid advance in technology, which opened the well-known "Information Age" since 1974, is undoubtedly linked to Information Technology development, both for hardware and software (Greenwood, 1999). Though we often concentrate on large companies and their famous and widely used products, we cannot ignore the importance of the small and medium-sized companies in an economic system. According to (SOFTEX, 2009), these enterprises play a fundamental role in many national economies growth. In Brazil, they represent up to 99,4% all software organizations showed in Figure 2.5. Generally speaking, small companies are supplementary to large one from the market view. Large companies, with enough financial and managerial resources to develop and. 17.

(37) 2.4. SPL ADOPTION IN SMES. Figure 2.5 Distribution of the enterprises in Brazilian’s industry of software and services - Brazil, year 2005. (SOFTEX, 2009). market new technologies, aim to gain dominant share of a market (SOFTEX, 2009). On the other hand, small software companies, in order to survive in crucial competition, mainly concentrate on a market niche, which is disregarded by large companies.. 2.4. SPL Adoption in SMEs. Many parts of the software engineering community argues that “software product lines may be fine for large organizations, but not for small ones Small companies cannot afford the start-up cost. Further, the burdensome processes, the strict organizational roles, and the tedious planning all run completely counter to a small organization’s lean, nimble, leap-out-of-the-starting-gate culture”. It is not without a certain understandability, because many of the well-known and most publicized software product lines come with pedigrees written in large script, such as: Nokia, Motorola, Hewlett Packard, and others (Gacek et al., 2001). While running their businesses, small and medium-sized software companies often meet difficulties in finances and staffing. The majority of SMEs are independently financed and rather like a develop team than a company in size. By contrast, large organizations boast hundreds of developers, with budgets more than ample enough to cover an experiment or two with a new and untried paradigm. For small companies, it is an. 18.

(38) 2.5. CHAPTER SUMMARY. unaffordable luxury. No wonder the conventional some parts of the software engineering community views software product lines as a game only for the large enterprises (Verlage and Kiesgen, 2005). According to (Gacek et al., 2001), the conventional wisdom is utterly wrong. Time to market and economy of production are two of a product line’s best assets, and both are many times more critical for a small company. In fact, software product lines offer many SMEs their last best hope for success. She defends, based on her observations, that despite all the difficulties, small organizations appear to be exceptionally well-poised to adopt the software product line approach. In spite of, we cannot just apply the software engineering standards and solutions designed mainly for large companies to small ones. The challenges in adopting software product line engineering paradigm in small and medium-sized enterprises, goes beyond the technical aspect (Pohl et al., 2005). For this reason, the differences between SMEs and large companies have to be considered when introducing a software product line engineering paradigm. Though having similar objectives small and large companies cannot both apply the same development methodology or techniques without any modification and optimization.. 2.5. Chapter Summary. In this chapter, we discussed important issues related to software product lines, software adoption, small and medium-sized enterprises and then discussed how these concepts can interact. These underlying concepts are fundamental to understand the purpose of the work described in this dissertation. As described, substantial economies can be achieved when the systems in a software product line are developed from a common set of assets in a prescribed way, in contrast to being developed separately, from scratch, or in an arbitrary fashion (Clements and Northrop, 2001). It is exactly these production economies that make software product lines attractive (Clements and Northrop, 2001). The major distinction between SPL engineering and traditional software engineering, which is focused in developing singlesystems, is the presence of variation in some or all of the software assets. However, adopting the product line is not a trivial task, when considering small and medium-sized enterprises, the barriers are greater, which becomes increasingly difficult to determine the most suitable practices and/or strategies to be adopted. Besides, there is a wrong thinking in many parts of the software engineering community, who argues that software product lines is more suitable for large enterprises, since small and medium-sized. 19.

(39) 2.5. CHAPTER SUMMARY. enterprises cannot afford the start-up cost. It raises problems regarding how to efficiently and effectively adopt SPL in SMEs, because though small and large companies having similar objective, we cannot apply the same development methodology or techniques without any modification and optimization. These problems require techniques that consider the unique characteristics of SMEs, since techniques applied to large enterprises cannot solve such questions. Hence, it is necessary to figure out how the research community and practitioners have dealt with such aspects. In this context, next Chapter presents an evolutionary multi-method approach combining primary and secondary studies. It was developed in order to investigate and extract empirical evidences of the adoption of software product lines in small and medium-sized enterprises.. 20.

(40) 3 The Multi-method Research Methodology. In the recent years, there has been a growing interest in empirical research in Software Engineering (Runeson and Höst, 2009). One the main reasons is that the analytical research paradigm is not sufficient for investigating complex real life issues, involving humans and their interactions with technology (Wood et al., 1999). In SPL engineering is not different. Many studies have demonstrated the benefits of the SPL adoption (Gacek et al., 2001; Linden et al., 2007; Pohl et al., 2005), however, the reports represent singleshot studies. According to (Wood et al., 1999) “one experimental study on a topic, no matter how good, cannot, in isolation, demonstrate much of anything conclusively”. Replication (Brooks et al., 1996) helps to address some of the weaknesses of single-shot studies, but replications typically involve repeated investigation using the same research method, and are therefore vulnerable to the inherent weaknesses of any particular method. Thus, in this chapter we describe the multi-method approach to empirical software engineering research applied in this dissertation. A multi-method approach (Brewer and Hunter, 1989), or triangulation (Martin, 1982) combines different, but complimentary, research methods. It is argued that a multi-method approach can help to address the perceived weakness of single-shot studies by attacking research problems “with an arsenal of methods that have non-overlapping weaknesses in addition to their complementary strengths” (Brewer and Hunter, 1989). We define our approach in order to have a deep understanding of SPL adoption in SMEs, and increase the availability of empirical knowledge on the area based on the findings, new solution proposals can be developed by the research community. The reminder of this chapter is organized as follows: Section 3.1 presents the research philosophy; the research design is presented including the selection of research methods and brief description of how these methods were executed in Section 3.2; Section 3.3 discusses the validity; and finally, Section 3.4 presents the Chapter Summary.. 21.

(41) 3.1. RESEARCH PHILOSOPHY. 3.1. Research Philosophy. Klein and Myers (1999) recommend that “the intellectual basis for the research should be as transparent to the reader”. Therefore, in this section, the philosophical and epistemological debates underlying this research are discussed.. 3.1.1. Positivism vs. Interpretivism. Positivism research is seen as a progression and adoption of the natural sciences. Positivism research is typically associated with the testing of a predefined theory and therefore concerns itself with control, reduction and explanation. To achieve control, the research is performed in laboratory and the setting where the research is primarily an observer of events (Evered and Louis, 1981). The research in this study is not suited to the positivism paradigm because it is not feasible to operate the research in the controlled and managed laboratory type environment required by the positivist ideal. The stage of adoption of SPL in SMEs is continuous due to of their activities, which are an integral part of daily business. Moreover, before our work, there were no suitable and quantifiable measure of variables and the research is not concerned with testing a specific hypothesis. The main goal of interpretive research is “to describe, interpret, analyse, and understand the social world from the participants’ perspective” (Orlikowski and Baroudi, 1991). An important aspect of interpretative research is the subject matter be “set in its social and historical context so the reader can see how the current situation emerged” (Klein and Myers, 1999). The research in this dissertation uses an industrial context during the case study research. The result therefore must be observed and interpreted in this context. We believe that findings of the research are applicable to others who also operate in this environment. Given that the research is set in a defined context with which the results may be observer and interpreted, the interpretive research paradigm is appropriate.. 3.1.2. Quantitative vs. Qualitative. Quantitative techniques are based around formality, mathematics and statistics. They have their roots firmly in the positivist tradition. Qualitative tends to be associated with the interpretivist mindset. A qualitative study is an appropriate way to research an area where few previous studies have been carried out (Lee, 1989; Yin, 2008) and when it is the process that. 22.

(42) 3.2. RESEARCH DESIGN. is being studied rather than the product (Patton, 1987). SPL adoption in SMEs is an example of such an emergent research topic. Furthermore, the research is also looking at practices and process involved in the adoption of SPL in SMEs. Thus, the qualitative approach is therefore considered to be most appropriate for this study.. 3.1.3. Inductive vs. Deductive. Deductive reasoning is the belief structure behind much of mathematics. Deductive researchers believe their “justifications to be conclusive, in the special sense that it is impossible, on pain of self-contradiction, for the beliefs which are our reasons to be true and the conclusions that we draw from them to be false” (Galliers, 1992). Inductive reasoning occurs “when we take our reasons to be sufficient to justify our conclusions without conclusiveness”, or “we have some but not yet sufficient reasons for the conclusion, hoping that further reasons may be found” (Dancy, 1985). The key distinction between induction and deduction is that inductive reasoning does not involve such strong relationships between reasons and conclusion, as there “is an inferential jump beyond the evidence presented” (Cooper and Schindler, 1998). Inductive methods such as grounded theory (Strauss and Corbin, 1998) or case study research (Eisenhardt, 1985; Yin, 2008) seek to gather information and build theories from these methods. That is they argue from the particular to the general. In our work, we are investigating industry and academic adoptions of SPL in SMEs. Therefore, it can be classified as inductive research.. 3.1.4. Constructive. The study itself can be classified as constructive research. Jarvinen (2001) defines constructive research as typically involving the building of a new innovation based on existing (research) knowledge and new technical or organizational advancements.. 3.2. Research Design. We have observed among other issues, the lack of research into SPL adoption in SMEs combining evidences from different sources. In addition, we have noticed that researches in SPL adoption were centered on technological solutions that supported or partly automated the SPL process (Knauber et al., 2000; Gacek et al., 2001; Sellier et al., 2007) and are based largely on anecdotal rather than scientific evidence.. 23.

(43) 3.2. RESEARCH DESIGN. While such a large gap between research and practice presents many opportunities, it also brings many potential pitfalls. Without a mature body of theoretically founded knowledge to use as a guiding light, systematic research becomes somewhat more difficult. It is recommended that in instances where the study is broad, exploratory and where limited research currently exists, it is vital that the researcher parses the research project into a set of clearly defined steps (Cooper and Schindler, 1998). On the other hand, to define the research steps, the research methods must be selected. No single research method however is universally applicable and “all research approaches may have something to offer” (Gill and Johnson, 1991). There is a considerable range of research methods available (Galliers, 1992), all of which have distinct strengths and weaknesses. To compensate for these weaknesses, (Franz and Koeblitz, 1986) recommend a multi-method research design. Multi-method design is “the conduct of two or more research methods, each conducted rigorously and complete in itself, in one project” (Morse, 2003). By triangulating between methods and data, more plausible interpretations can emerge. According to (Wood et al., 1999), a multi-method research can be conducted from a complementary or evolutionary perspective. In this research, an evolutionary approach was followed. An evolutionary approach is used when there is little research conducted on a particular phenomenon. Rather than investigating an effect through two or more different empirical methods, seeking confirmatory power between them, an initial exploratory study gathering qualitative data is undertaken. At this early phase, the initial study is designed to explore a wide range of topics in the area under investigation. The collected data is then analyzed, and the important findings from the initial study are refined and used in the following study. This process is then repeated, usually using a different research method.. 3.2.1. Overview of the Research Design. The research design was influenced by (Spínola, 2008) and (O’Leary, 2010), which focuses on combining primary (case study, survey, expert opinion) and secondary (initial literature review, mapping study) studies as shown in Figure 3.1. The first phase of the research design is the base stage. It entails an initial literature review. This activity is performed iteratively and defines the initial body of knowledge in the area. The second phase is a mapping study. The mapping study is a defined method to build a classification scheme and structure the research (Petersen et al., 2008). The analysis of its results focuses on frequencies of publications for categories within the. 24.

(44) 3.2. RESEARCH DESIGN. Figure 3.1 Research Design.. scheme and allows the extraction of evidence. However, there are many differences among the evidences extracted from research and practice (Yin, 2008). To minimize this threat, the third phase is an industrial case study. The Case Study is especially helpful in situations where researchers are seeking to develop understandings of dynamics of a contemporary phenomenon in this natural context (Yin, 2008; Runeson and Höst, 2009). In a case study, the evidences extracted during the literature review can be confirmed and new evidence can be identified. The fourth and final phase of the research is a Survey based on Expert Opinion. Its objective is to extract evidence from experts and form a perception of reality from the comparison with the evidence extracted during the previous phases. Next, each phase of the research design are discussed in more details. First Phase - Initial Literature Review The definition of suitable objective is the most critical stage of any research project (O’Leary, 2010). Jenkins (1985) stated that it should be clear and unambiguous. In order to create a robust knowledge base and a well-defined research objective this phase was performed. In this phase was carried out an ad-hoc review in the literature on the area of SPL, its concepts and benefits, focusing in particular, on the adoption of SPL in SMEs. It. 25.

(45) 3.2. RESEARCH DESIGN. was performed iteratively and aimed to form the base of knowledge. The first iteration involved analyzing textbooks about software product lines engineering. The others iterations involved extraction and reading of articles discussing the adoption of SPL. At the end of each iteration, a presentation was made to members of the RiSE Labs1 to discuss and synthesize the knowledge extracted. This phase of the research is presented in Figure 3.2.. Figure 3.2 Initial Literature Review.. The choice of an iterative approach resulted in the creation of a robust knowledge base and a well-defined research objective. These results helped to define a more accurate and comprehensive protocol for the mapping study in the next phase of the research. Second Phase - Mapping Study With the purpose of to identify and characterize the evidence of the SPL adoption in the literature, this phase involves the planning and execution of the mapping study. Mapping study (Petersen et al., 2008) is an evidence-based approach, applied in order to provide an overview of a research area, and identify the quantity and type of research and results available within it. The results are gained from a defined approach to locate, assess and aggregate the outcomes from relevant studies, thus providing a balanced and objective summary of the relevant evidence. Hence, the goal of this phase is to identify, evaluate, and synthesize the state-of-the-art of the SPL adoption practices in order to suggest important implications for practice, as well as, identifying research trends, open issues, and areas for improvement. The mapping study overview is represented in Figure 3.3. This phase receives as input, the knowledge base and the research objective defined in the last phase. This information help in the development of the protocol and execution 1 RiSE. Labs. http://labs.rise.com.br. 26.